The SBC Core is integrated with Juniper Session Resource Controller (JSRC) using SOAP interface to perform enhanced call processing such as bandwidth reservation and Gateway client process creation.
For example, when a call comes in, the SBC acting as a Gateway client contacts the SRC and reserves bandwidth for the session. Once the call completes, the bandwidth reservation is released. Currently, each business partner can have three users (user1, user 2, user3). Each of these users has a 6M (6000000) link to the DSLAM.

A generalized deployment scenario is shown in the figure below  to illustrate the basic flows and interactions between the SBC 5000 series series server and Juniper equipment.

Juniper SRC Deployment Scenario


Using the figure above, consider a call where session establishment is originating on the left side of the figure. At a high-level, SBC behavior as it relates to the Juniper SRC for basic session establishment is as follows:

  • End-to-end session establishment starts Sonus SBC #1.
  • Sonus SBC #1 examines the global configuration to determine if the SRC bandwidth reservation feature is enabled (for the example above, SRC bandwidth reservation is enabled).
  • Sonus SBC #1 examines the offered session attributes, determines worst case bandwidth requirements and performs three Subscriber_activateService API calls to reserve bandwidth:
  • SIP trunk #1 (reservation is optional, depending on network topology)
  • Ingress trunk #1
  • Egress trunk #1
  • Sonus SBC #1 forwards session establishment signaling to Sonus SBC #2.
  • Sonus SBC #2 examines global configuration to determine if SRC bandwidth reservation is enabled (for example above, SRC bandwidth reservation is enabled).
  • Sonus SBC #2 examines the offered session attributes, determines worst case bandwidth requirements and performs three Subscriber_activateService API calls to reserve bandwidth:
  • SIP trunk #2 (reservation is optional, depending on network topology)
  • Ingress trunk #2
  • Egress trunk #2
  • Once the session attributes are negotiated end-to-end, both Sonus SBCs have knowledge of the actual bandwidth used by the session on each trunk.
  • At this point both of the Sonus SBCs perform Subscriber_modifyService API calls to adjust down the bandwidth as needed.
Bandwidth requirements may be different on each trunk depending on the media transcoding that SBC is performing.
  • The Sonus SBCs perform Subscriber_deactivateService API calls when the session signaling indicates that the session had ended.

The example above illustrates a bandwidth reservation for a single flow through the Sonus SBC. In practice, there can be as many as three flows associated with multimedia sessions. The flow types that the Sonus SBC supports are audio, video and collaborative data share that presents as a second video stream. The Sonus SBC performs bandwidth reservations for each flow type associated with the session.

 

  • No labels