Actions

CAF: Call Legs Resync: Difference between revisions

m (typos)
 
Line 108: Line 108:
** Destructor of all call flows is called
** Destructor of all call flows is called
* When the application is restarted
* When the application is restarted
** => This is exactly the same scenario as the end of Scenario 2 after step 'toolpack_engine pushes information to CAF library'.
** This is exactly the same scenario as the end of Scenario 2 after step 'toolpack_engine pushes information to CAF library'.


= For more information... =
= For more information... =

Latest revision as of 10:29, 6 September 2022

Call Legs Resynchronization

Since the Toolpack framework has been designed for HA (High_Availability_Overview), it's mandatory that an application that manages calls through CAF_Call_interface is able to deal with call legs re-synchronization.

This article contains an overview of how resynchronization works. For more details, please refer to the following section:

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 loses 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 its 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 rebuilt like they were before toolpack_engine was restarted

CAF application

The CAF call control application that was disconnected from toolpack_engine will update (or rebuild) its call leg contexts by getting information automatically pushed by toolpack_engine upon reconnection.

All active (answered) calls will be resynchronized from toolpack_engine.

  • Calls already known by the application will remain valid
  • Calls unknown by the application will be reconstructed (or refused): OnCallLegSync, OnLinkSync
  • Calls known by the application, but no more present in toolpack_engine are terminated: OnCallLegTerminated

Example scenarios

Example scenario: Initial state

In all the scenarios below, let's consider the following situation:

  • Leg-A: Ringing
  • Leg-B: Terminating
  • Leg-C: Active (answered)
  • Leg-D: Active (answered)
  • Leg-E: Active (answered)
  • Leg-C and Leg-D are joined (connected) together
  • Mixer-1: Ready
  • Leg-E and Mixer-1 are joined (connected)

Scenario 1: toolpack_engine quickly restarted

Example scenario 1
  • CAF Application is notified
    • OnCmcLibNotReady()
    • OnSyncLost() for Leg-A, Leg-B, Leg-C, Leg-D and Leg-E
    • OnMixerSyncLost() on Mixer-1
  • toolpack_engine restarts
    • Queries information from all TMedia units
    • Drop incomplete legs and mixers (here Leg-A and Leg-B)
    • Re-build contexts for active legs and mixers (here Leg-C, Leg-D, Leg-E and Mixer-1)
    • Re-build connections between legs/mixers (here Leg-C with Leg-D, Leg-E with Mixer-1)
  • toolpack_engine pushes information to CAF library:
    • Legs: Leg-C, Leg-D and Leg-E
    • Mixers: Mixer-1
    • Connections: Leg-C with Leg-D, Leg-E with Mixer-1
  • CAF library compares with it's own contexts:
    • OnCallLegTerminated() for Leg-A and Leg-B
    • OnSyncDone() for Leg-C, Leg-D and Leg-E
    • OnMixerSyncDone() for Mixer-1
  • Ready to continue
    • OnCmcLibReady()

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

Example scenario 2
  • CAF Application is notified
    • OnCmcLibNotReady()
    • OnSyncLost() for Leg-A, Leg-B, Leg-C, Leg-D and Leg-E
    • OnMixerSyncLost() on Mixer-1

(... 10 seconds elapse...)

  • CAF Application declares toolpack_engine "dead", destroys all it's local contexts:
    • OnCallLegTerminated() for all legs: Leg-A, Leg-B, Leg-C, Leg-D and Leg-E
    • OnMixerTerminated() for all mixers: Mixer-1

(... some time elapse...)

  • toolpack_engine is restarted
    • Queries information from all TMedia units
    • Drop incomplete legs and mixers (here Leg-A and Leg-B)
    • Re-build contexts for active legs and mixers (here Leg-C, Leg-D, Leg-E and Mixer-1)
    • Re-build connections between legs/mixers (here Leg-C with Leg-D, Leg-E with Mixer-1)
  • toolpack_engine pushes information to CAF library:
    • Legs: Leg-C, Leg-D and Leg-E
    • Mixers: Mixer-1
    • Connections: Leg-C with Leg-D, Leg-E with Mixer-1
  • CAF library compares with it's own contexts (none!):
    • OnCallLegSync() for Leg-C, Leg-D and Leg-E
      • Application may refuse them: RefuseLeg()
      • Application may re-allocate new contexts for these legs
    • OnMixerSync() for Mixer-1
      • Application may refuse: RefuseMixer()
      • Application may re-allocate new contexts for these mixers
    • OnLinkSync() for Leg-C with Leg-D
      • Application may refuse: RefuseLink()
      • Application may re-allocate new "call flow" contexts, re-bind legs to them (BindCallLeg)
    • OnMixerLinkSync() for Leg-E with Mixer-1
      • Application may refuse: RefuseMixerLink()
      • Application may re-allocate new "call flow" contexts, re-bind legs/mixers to them (BindCallLeg, BindMixer)
  • Ready to continue
    • OnCmcLibReady()

Scenario 3: CAF application is restarted

Example scenario 3
  • If the application is quitting in a 'clean' manner
    • 'OnLegFreed()' is called for all call legs (Leg-A, Leg-B, Leg-C, Leg-D and Leg-E)
    • Destructor of all call flows is called
  • When the application is restarted
    • This is exactly the same scenario as the end of Scenario 2 after step 'toolpack_engine pushes information to CAF library'.

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