> For the complete documentation index, see [llms.txt](https://prosbcdocs.telcobridges.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prosbcdocs.telcobridges.com/telecom-references/apis-and-integration/caf-call-legs-resync.md). # CAF: Call Legs Resync ## Call Legs Resynchronization Since the [Toolpack](https://telcobridges.com/products/development-platforms-tdev/) framework has been designed for HA ([High\_Availability\_Overview](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/sip-voip/redundancy-and-high-availability/README.md)), it's mandatory that an application that manages calls through [CAF\_Call\_interface](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/voice-media/caf-call-interface/README.md) 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/api/caf-working-with-caf-call-legs/README.md#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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md): * The CAF application was restarted * The [toolpack\_engine](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md) was restarted * Network connection between CAF application and [toolpack\_engine](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md) was momentarily down ### General principles of call legs re-sync #### Toolpack Engine The [toolpack\_engine](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md) 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md) was restarted #### CAF application The CAF call control application that was disconnected from [toolpack\_engine](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md) will update (or rebuild) its call leg contexts by getting information automatically pushed by [toolpack\_engine](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md) upon reconnection. All active (answered) calls will be resynchronized from [toolpack\_engine](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md). * 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/misc/toolpack-engine/README.md) are terminated: *OnCallLegTerminated* ### Example scenarios ![Example scenario: Initial state](https://docs.telcobridges.com/w/images/9/98/CAFCallFlow_examples_initial.png) 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](https://docs.telcobridges.com/w/images/f/fe/CAFCallFlow_examples_scenario_1.png) * 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](https://docs.telcobridges.com/w/images/8/86/CAFCallFlow_examples_scenario_2.png) * 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](https://docs.telcobridges.com/w/images/c/cd/CAFCallFlow_examples_scenario_3.png) * 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/api/caf-working-with-caf-call-legs/README.md#re-synchronizing-with-toolpack-engine) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://prosbcdocs.telcobridges.com/telecom-references/apis-and-integration/caf-call-legs-resync.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.