CAF: Call Legs Resync

From TBwiki
Revision as of 06:24, 19 October 2012 by Abrassard (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Situations where call leg resynchronization is required

Call legs re-synchronization is required whenever the CAF application looses communication with toolpack_engine: - CAF application was restarted - toolpack_engine was restarted - HA swithover caused CAF application, toolpack_engine, or both, to be activated on a redundant host - Network communication was interrupted between CAF application and toolpack_engine

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_Call_interface 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: OnCallLegSync, OnLinkSync - Calls known by the application, but no more present in toolpack_engine are terminated: OnCallLegTerminated

CAF application was restarted

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.

Personal tools