CAF: Call Legs Resync

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(Re-sync timeout)
Line 26: Line 26:
 
* Calls unknown by the application will be re-constructed (or refused): ''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''
 
=== 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 ==
 
== Example scenarios ==

Revision as of 06:35, 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

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

Personal tools