CAF: Call Legs Resync

From TBwiki
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.

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

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 CAF call control application that was disconnected from toolpack_engine will update (or re-build) it's call leg contexts by getting information automatically pushed by toolpack_engine upon re-connection.

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

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 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

Personal tools