The
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
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
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,
behavior as it relates to the Juniper SRC for basic session establishment is as follows:
- End-to-end session establishment starts Ribbon #1.
- Ribbon #1 examines the global configuration to determine if the SRC bandwidth reservation feature is enabled (for the example above, SRC bandwidth reservation is enabled).
- Ribbon #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
- Ribbon #1 forwards session establishment signaling to Ribbon #2.
- Ribbon #2 examines global configuration to determine if SRC bandwidth reservation is enabled (for example above, SRC bandwidth reservation is enabled).
- Ribbon #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 Ribbon s have knowledge of the actual bandwidth used by the session on each trunk.
- At this point both of the Ribbon s perform Subscriber_modifyService API calls to adjust down the bandwidth as needed.
| Note |
|---|
| Bandwidth requirements may be different on each trunk depending on the media transcoding that SBC is performing. |
- The Ribbon s 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 Ribbon
. In practice, there can be as many as three flows associated with multimedia sessions. The flow types that the Ribbon
supports are audio, video and collaborative data share that presents as a second video stream. The Ribbon
performs bandwidth reservations for each flow type associated with the session.