Shared CAC for SIP Forked Calls

A forked call is one which has multiple INVITEs for the same call. For example, if an Application Server in the provider core network forks a call attempt, the application server sends several INVITEs for the same call toward the Oracle® Enterprise Session Border Controller. Each INVITE is destined for a unique device that belongs to the same user. Ideally, that user will only answer one device. The Oracle® Enterprise Session Border Controller treats each INVITE as a unique call request.

By default, each of the multiple INVITE forks are checked against CAC bandwidth limits, and thus they each consume bandwidth resources when they are received, even though only one of the forks will succeed in establishing a permanent session. Therefore, for many operators the CAC behavior of the SD is too restrictive and results in rejected call attempts which should have been allowed.

The following diagram shows a forked call scenario. The total bandwidth counted against the realm is 60 kbps. If the realm has a bandwidth ceiling of 50 kbps, one of the INVITEs will be rejected.

This image shows the OCSBC dividing bandwidth between multiple legs of a forked call.

You can, however, enable the system to enforce CAC limits only once for SIP forked calls as long as the calls are identified as such, meaning that they will use the same bandwidth resources. The Oracle® Enterprise Session Border Controller counts the forked call’s most bandwidth-hungry codec at the time it arrives at the Oracle® Enterprise Session Border Controller. In the above diagram, with shared bandwidth for forked calls enabled, the Oracle® Enterprise Session Border Controller counts 30 kbps against the realm’s total bandwidth after that INVITE arrives, even after the first two INVITES have passed into the final realm.

Bandwidth Sharing Scenarios

The following table summarizes how bandwidth would be shared given certain ingress and egress realms with this feature enabled. Realms A and C are call ingress realms.; realms B and D are egress realms. For the bandwidth to be shared, Call A and Call B must have the same forked Call-ID in the P-Multiring-Correlator header and be entering or exiting the Oracle® Enterprise Session Border Controller on the same realm.

Illustration of the matrix of where band width is shared and not shared with bandwidth sharing enabled.

Bandwidth Sharing Configuration

To enable bandwidth sharing of forked calls, set the forked-cac-bw parameter in the SIP profile configuration to shared. Although there are other parameters available in the SIP profile configuration, you only have to set the name and the forked-cac-bw values to use this feature.

After you set up the SIP profile, you apply it to a realm, SIP interface, or session agent.

Configuring a SIP Profile

The SIP profile is an element in the ACLI’s session-router path, and you can configure multiple SIP profiles.

To configure a SIP profile:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type session-router and press Enter.
    ORACLE(configure)# session-router
    ORACLE(session-router)#
  3. Type sip-profile and press Enter.
    ORACLE(session-router)# sip-profile
    ORACLE(sip-profile)#
  4. name—Enter a name for this SIP profile configuration. This parameter is blank by default, and it is required. You will need the SIP profile’s name when you want to apply this profile to a realm, SIP interface, or SIP session agent.
  5. forked-cac-bw—Set this parameter to shared if you want forked sessions to share bandwidth resources, or set it to per-session if you want bandwidth to be counted for each session individually. There is no default for this parameter, and leaving it blank means:
    • For an ingress session agent without a SIP profile or with a SIP profile where the forked CAC mode is blank, the Oracle® Enterprise Session Border Controller will reference the associated realm.

    • For an ingress realm without a SIP profile or with a SIP profile where the forked CAC mode is blank, the Oracle® Enterprise Session Border Controller will reference the associated SIP interface.

    • For an ingress SIP interface without a SIP profile or with a SIP profile where the forked CAC mode is blank, the Oracle® Enterprise Session Border Controller will not perform bandwidth sharing for forked calls.

  6. Save your work.

Applying a SIP Profile

Once you have configured one or more SIP profiles, you can apply them to realms, SIP interfaces, and SIP session agents. As an example, this section shows you how to apply a SIP profile to a SIP interface. But the parameter name is the same in these configurations:

  • realm-config
  • sip-interface
  • session-agent

    To apply a SIP profile to a SIP interface:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type session-router and press Enter.
    ORACLE(configure)# session-router
    ORACLE(session-router)#
  3. Type sip-interface and press Enter.
    ORACLE(session-router)# sip-interface
    ORACLE(sip-interface)#
  4. sip-profile—Enter the name of SIP profile configuration that includes the forked-cac-bandwidth parameter configured.
  5. Save your work.

RADIUS Accounting Support

VSA 171, Acme-Session-Forked-Call-Id, is part of the Oracle RADIUS dictionary. The VSA is a string value, and appears as the header-value without the header parameters from the P-Multiring-Correlator header for a session identified as part of a forked call.

Monitoring

Using the ACLI show sipd forked command, you can display the total number of forked sessions the Oracle® Enterprise Session Border Controller received and the total number it rejected. The Oracle® Enterprise Session Border Controller counts forked sessions when it receives a dialog-creating INVITE and is enabled to shared bandwidth. Further, it counts as forked all session with the P-Multiring-Correlator header.

ORACLE# show sipd forked
11:19:20-116
Forked Sessions               ---- Lifetime ----
                       Recent      Total  PerMax
Forked Sessions             0          0       0
Forked Sessions Rej         0          0       0