CAF: Call Legs Resync - Revision history

Abrassard at 11:32, 23 January 2014

2014-01-23T11:32:32Z

Abrassard at 12:42, 19 October 2012

2012-10-19T12:42:33Z

Abrassard at 12:41, 19 October 2012

2012-10-19T12:41:44Z

Abrassard: /* Example scenarios */

2012-10-19T12:38:51Z

Example scenarios

Abrassard: /* CAF application */

2012-10-19T12:01:57Z

CAF application

Abrassard: /* Call Legs Resynchronization */

2012-10-19T12:00:42Z

Call Legs Resynchronization

Abrassard: /* Scenario 2: toolpack_engine stopped (disconnected) for more than 10 seconds */

2012-10-19T11:55:29Z

Scenario 2: toolpack_engine stopped (disconnected) for more than 10 seconds

Abrassard: /* Example scenarios */

2012-10-19T11:55:04Z

Example scenarios

Abrassard: /* Re-sync timeout */

2012-10-19T11:35:19Z

Re-sync timeout

Abrassard at 11:34, 19 October 2012

2012-10-19T11:34:15Z

@@ Line 103: / Line 103: @@
 [[Image:CAFCallFlow_examples_scenario_3.png|thumb|480px|Example scenario 3]]
-This is exactly same scenario as the end of Scenario 2 after toolpack_engine pushes information to CAF library.
+* If the application is quitting in a 'clean' manner
 = For more information... =

@@ Line 41: / Line 41: @@
 === Scenario 1: toolpack_engine quickly restarted ===
-[[Image:CAFCallFlow_examples_scenario_1.png|thumb|480px|Example scenario: Initial state]]
+[[Image:CAFCallFlow_examples_scenario_1.png|thumb|480px|Example scenario 1]]
 * CAF Application is notified
@@ Line 64: / Line 64: @@
 === Scenario 2: toolpack_engine stopped (disconnected) for more than 10 seconds ===
-[[Image:CAFCallFlow_examples_scenario_2.png|thumb|480px|Example scenario: Initial state]]
+[[Image:CAFCallFlow_examples_scenario_2.png|thumb|480px|Example scenario 2]]
 * CAF Application is notified
@@ Line 101: / Line 101: @@
 === Scenario 3: CAF application is restarted ===
-[[Image:CAFCallFlow_examples_scenario_3.png|thumb|480px|Example scenario: Initial state]]
+[[Image:CAFCallFlow_examples_scenario_3.png|thumb|480px|Example scenario 3]]
 This is exactly same scenario as the end of Scenario 2 after toolpack_engine pushes information to CAF library.

@@ Line 28: / Line 28: @@
 == Example scenarios ==
 In all the scenarios below, let's consider the following situation:
 * Leg-A:   Ringing
@@ Line 37: / Line 39: @@
 * Mixer-1: Ready
 * Leg-E and Mixer-1 are joined (connected)
 === Scenario 1: toolpack_engine quickly restarted ===
 * CAF Application is notified
 ** ''OnCmcLibNotReady()''
@@ Line 60: / Line 62: @@
 * Ready to continue
 ** ''OnCmcLibReady()''
 === Scenario 2: toolpack_engine stopped (disconnected) for more than 10 seconds ===
 * CAF Application is notified
 ** ''OnCmcLibNotReady()''
@@ Line 98: / Line 100: @@
 ** ''OnCmcLibReady()''
-[[Image:CAFCallFlow_examples_scenario_2.png|thumb|480px|Example scenario: Initial state]]
+=== Scenario 3: CAF application is restarted ===
 This is exactly same scenario as the end of Scenario 2 after toolpack_engine pushes information to CAF library.
 = For more information... =

@@ Line 37: / Line 37: @@
 * Mixer-1: Ready
 * Leg-E and Mixer-1 are joined (connected)
 === Scenario 1: toolpack_engine quickly restarted ===
@@ Line 58: / Line 60: @@
 * Ready to continue
 ** ''OnCmcLibReady()''
 === Scenario 2: toolpack_engine stopped (disconnected) for more than 10 seconds ===
@@ Line 93: / Line 97: @@
 * Ready to continue
 ** ''OnCmcLibReady()''
 === Scenario 3: CAF application is restarted ===
 This is exactly same scenario as the end of Scenario 2 after toolpack_engine pushes information to CAF library.
 = For more information... =

@@ Line 20: / Line 20: @@
 === CAF application ===
-The call control application based on the [[CAF_Call_interface]] API will re-build it's call leg contexts by getting information from [[Toolpack_Application:toolpack_engine|toolpack_engine]].
+The CAF call control application that was disconnected from [[Toolpack_Application:toolpack_engine|toolpack_engine]] will update (or re-build) it's call leg contexts by getting information automatically pushed by [[Toolpack_Application:toolpack_engine|toolpack_engine]] upon re-connection.
 All active (answered) calls will be re-synchronized from [[Toolpack_Application:toolpack_engine|toolpack_engine]].

@@ Line 2: / Line 2: @@
 Since the [[Toolpack]] framework has been designed for HA ([[High_Availability_Overview]]), it's mandatory that an application that manage calls through [[CAF_Call_interface]] is able to deal with call legs re-synchronization.
-The current page contains an overview of how re-synchronization works. For more details, please refer to the following page:
+The current page contains an overview of how re-synchronization works. For more details, please refer to the following section of the this page:
 [[CAF:_Working_With_Caf_Call_Legs#Re-synchronizing_with_toolpack_engine]]

@@ Line 26: / Line 26: @@
 * Calls unknown by the application will be re-constructed (or refused): ''OnCallLegSync'', ''OnLinkSync''
 * Calls known by the application, but no more present in [[Toolpack_Application:toolpack_engine|toolpack_engine]] are terminated: ''OnCallLegTerminated''
 == Example scenarios ==

@@ Line 1: / Line 1: @@
 = Call Legs Resynchronization =
 Since the [[Toolpack]] framework has been designed for HA ([[High_Availability_Overview]]), it's mandatory that an application that manage calls through [[CAF_Call_interface]] is able to deal with call legs re-synchronization.
 == Situations where call leg resynchronization is required ==
 Call legs re-synchronization is required whenever the CAF application looses communication with [[Toolpack_Application:toolpack_engine|toolpack_engine]]:
-- CAF application was restarted
+* The CAF application was restarted
-- [[Toolpack_Application:toolpack_engine|toolpack_engine]] was restarted
+* The [[Toolpack_Application:toolpack_engine|toolpack_engine]] was restarted
-- HA swithover caused CAF application, [[Toolpack_Application:toolpack_engine|toolpack_engine]], or both, to be activated on a redundant host
+* Network connection between CAF application and [[Toolpack_Application:toolpack_engine|toolpack_engine]] was momentarily down
-- Network communication was interrupted between CAF application and [[Toolpack_Application:toolpack_engine|toolpack_engine]]
 == General principles of call legs re-sync ==
 === Toolpack Engine ===
 The [[Toolpack_Application:toolpack_engine|toolpack_engine]] application, when restarted, will re-build it's call leg contexts by querying information on the TMedia Units.
-- Transient calls (not yet answered) will be dropped
+* Transient calls (not yet answered) will be dropped
-- Terminating calls will be dropped
+* Terminating calls will be dropped
-- Active (answered) calls will be re-build like they were before [[Toolpack_Application:toolpack_engine|toolpack_engine]] was restarted
+* Active (answered) calls will be re-build like they were before [[Toolpack_Application:toolpack_engine|toolpack_engine]] was restarted
-=== [[CAF_Call_interface]] application ===
+=== CAF application ===
 The call control application based on the [[CAF_Call_interface]] API will re-build it's call leg contexts by getting information from [[Toolpack_Application:toolpack_engine|toolpack_engine]].
 All active (answered) calls will be re-synchronized from [[Toolpack_Application:toolpack_engine|toolpack_engine]].
-- Calls already known by the application will remain valid
+* Calls already known by the application will remain valid
-- Calls unknown by the application will be re-constructed: ''OnCallLegSync'', ''OnLinkSync''
+* Calls unknown by the application will be re-constructed (or refused): ''OnCallLegSync'', ''OnLinkSync''
-- Calls known by the application, but no more present in [[Toolpack_Application:toolpack_engine|toolpack_engine]] are terminated: ''OnCallLegTerminated''
+* Calls known by the application, but no more present in [[Toolpack_Application:toolpack_engine|toolpack_engine]] are terminated: ''OnCallLegTerminated''
 In this situation, the CAF application was restarted (on purpose, or after a crash). It does a cold start up, without any call leg contexts.