CAF: Call Legs Resync
From TBwiki
(Difference between revisions)
(Under construction...) |
|||
| Line 1: | Line 1: | ||
= Call Legs Resynchronization = | = 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. | 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: | ||
| + | |||
| + | [[CAF:_Working_With_Caf_Call_Legs#Re-synchronizing_with_toolpack_engine]] | ||
== Situations where call leg resynchronization is required == | == 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]]: | Call legs re-synchronization is required whenever the CAF application looses communication with [[Toolpack_Application:toolpack_engine|toolpack_engine]]: | ||
| − | + | * The CAF application was restarted | |
| − | + | * The [[Toolpack_Application:toolpack_engine|toolpack_engine]] was restarted | |
| − | + | * Network connection between CAF application and [[Toolpack_Application:toolpack_engine|toolpack_engine]] was momentarily down | |
| − | + | ||
== General principles of call legs re-sync == | == General principles of call legs re-sync == | ||
=== Toolpack Engine === | === 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. | 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 | |
| − | + | * Terminating calls will be dropped | |
| − | + | * Active (answered) calls will be re-build like they were before [[Toolpack_Application:toolpack_engine|toolpack_engine]] was restarted | |
| − | === | + | === 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 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]]. | 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 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'' | |
| + | |||
| + | === Re-sync timeout === | ||
| + | Upon disconnection with [[Toolpack_Application:toolpack_engine|toolpack_engine]], the [[CAF_Call_interface]] API has a 10 seconds internal timeout waiting for a re-connection. | ||
| + | * During these 10 seconds, call contexts remain valid | ||
| + | * After these 10 seconds, call contexts are locally destroyed (''OnCallLegTerminated'') | ||
| + | * Calls that would still be present upon a later re-connection with [[Toolpack_Application:toolpack_engine|toolpack_engine]] can be re-constructed (''OnCallLegSync'') | ||
| + | |||
| + | '''Note''': After 10 seconds of disconnection with [[Toolpack_Application:toolpack_engine|toolpack_engine]], it makes sense that an application "forgets" about active calls, and writes CDR "END" logs, for example, to avoid billing users for calls that may no more be connected. | ||
| + | |||
| + | |||
| + | == Example scenarios == | ||
| + | In all the scenarios below, let's consider the following situation: | ||
| + | * | ||
| + | |||
| − | |||
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. | 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. | ||
| + | |||
| + | |||
| + | = For more information... = | ||
| + | The current page contains an overview of how re-synchronization works. For more details, please refer to the following page: | ||
| + | |||
| + | [[CAF:_Working_With_Caf_Call_Legs#Re-synchronizing_with_toolpack_engine]] | ||
Revision as of 06:34, 19 October 2012
Contents |
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.
The current page contains an overview of how re-synchronization works. For more details, please refer to the following page:
CAF:_Working_With_Caf_Call_Legs#Re-synchronizing_with_toolpack_engine
Situations where call leg resynchronization is required
Call legs re-synchronization is required whenever the CAF application looses communication with toolpack_engine:
- The CAF application was restarted
- The toolpack_engine was restarted
- Network connection between CAF application and toolpack_engine was momentarily down
General principles of call legs re-sync
Toolpack Engine
The 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
- Terminating calls will be dropped
- Active (answered) calls will be re-build like they were before toolpack_engine was restarted
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_engine.
All active (answered) calls will be re-synchronized from toolpack_engine.
- Calls already known by the application will remain valid
- Calls unknown by the application will be re-constructed (or refused): OnCallLegSync, OnLinkSync
- Calls known by the application, but no more present in toolpack_engine are terminated: OnCallLegTerminated
Re-sync timeout
Upon disconnection with toolpack_engine, the CAF_Call_interface API has a 10 seconds internal timeout waiting for a re-connection.
- During these 10 seconds, call contexts remain valid
- After these 10 seconds, call contexts are locally destroyed (OnCallLegTerminated)
- Calls that would still be present upon a later re-connection with toolpack_engine can be re-constructed (OnCallLegSync)
Note: After 10 seconds of disconnection with toolpack_engine, it makes sense that an application "forgets" about active calls, and writes CDR "END" logs, for example, to avoid billing users for calls that may no more be connected.
Example scenarios
In all the scenarios below, let's consider the following situation:
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.
For more information...
The current page contains an overview of how re-synchronization works. For more details, please refer to the following page:
CAF:_Working_With_Caf_Call_Legs#Re-synchronizing_with_toolpack_engine
