Normal scenarios

Last Updated : Nov 29, 2023 |

The normal scenarios explained in this topic are generic and are regardless of the Branch Session Manager survivability type, that is, Enterprise branch survivability and Edge friendly branch survivability.

However, in an Edge friendly branch survivability configuration, Avaya Session Border Controller (SBC) is required at the core edge for connectivity to the branch. The branch network is distinct from the enterprise network (core) and the connectivity between them is over the Internet rather than the VPN.

Generic diagram depicting branch survivability in a normal scenario

  • SIP phones in the branch locations are simultaneously registered with core Session Manager and Branch Session Managers (BSM)

  • SIP phones are registered with one of the core SMs as the active controller.

  • Media Gateways are registered with Communication Manager (CM) in the core.

  • BSM has direct connectivity with SIP Service Provider (SP).

  • BSM and SM have direct connectivity.

The following are some example call scenarios to illustrate the behavior of the feature. The scenarios listed here are not intended to be a complete list of all possible configurations and call scenarios.

Case 1: Calls incoming from the SP branch SIP trunk to a branch SIP user

  1. Request arrives at BSM from SIP SP interface.

  2. BSM perform ingress adaptation and routes the request to primary core SM of the called party.

  3. SM invokes core CM as the sequenced application and completes sequenced application invocation.

  4. SM performs contact resolution and routes the call to the SIP endpoint at the branch.

Case 2: Calls going to the SP branch SIP trunk from a branch SIP user

  1. Branch SIP user initiates a call to an external number.

  2. Core SM invokes core CM as a sequence application and completes sequenced application invocation.

  3. Based on dial patterns, SM routes the request to the SIP SP connected with the BSM.

  4. SM performs egress adaptation and Call Admission Control (CAC).

  5. SM routes the request to BSM with route-through to SIP SP. Based on route-header, BSM routes the request to SIP SP.

Case 3: Calls incoming from the SP branch SIP trunk to a branch non-SIP user

  1. Request arrives at BSM from SIP SP interface.

  2. BSM perform ingress adaptation and then routes the request to one of the core SM instances.

  3. Based on the dial pattern, SM routes the request to core CM.

    Note:

    CM-ES does CAC for this call.

  4. CM processes the request and terminates the request at the branch non-SIP endpoint.

Case 4: Calls going to the SP branch SIP trunk from a branch non-SIP user

  1. Branch non-SIP endpoint initiates a call to an external number.

  2. CM performs call processing and routes the request to SM.

  3. Based on dial patterns, the SM determines the request should be routed to SIP SP connected with BSM. SM performs egress adaptation and CAC. Finally, SM routes the request to BSM with route-through to SIP SP.

  4. Based on the Route header, BSM routes the request to SIP SP.

Case 5: Calls incoming from the SP branch SIP trunk for a non-branch SIP user

  1. Request arrives at BSM from SIP SP interface.

  2. BSM performs ingress adaptation and then routes the request to one of the core SMs.

  3. The authoritative SM performs CAC and invokes core CM as the sequenced application and completes sequenced invocation.

  4. SM performs contact resolution and routes the call to the non-branch SIP user.