Rx Interface Features

The Oracle Communications Session Border Controller can run the Rx interface over a Diameter connection and act as a P-CSCF communicating with a PCRF. The application ID field must be set to 16777236 to run the Rx reference point. When running in this mode, the Oracle Communications Session Border Controller will send two AVPs, in addition to other information:

  • The Codec-Data AVP is then included for non-priority calls. This AVP is one of several that together comprise a Group AVP structure.
  • The Reservation-Priority AVP is included for priority calls. This AVP will be the main AVP within the AAR message.

Non-Priority Call Handling

When a SIP signaling event triggers external bandwidth management use, the Oracle Communications Session Border Controller removes all SDP information from the signaling message that was the trigger. The Oracle Communications Session Border Controller repackages this bandwidth information so that it can form a Bandwidth Request and decide on an external bandwidth manager to which it should be sent. If the appropriate external bandwidth manager is configured for Rx interface use, then Oracle Communications Session Border Controller then reformats the SDP information to construct a Codec-Data AVP.

If the external bandwidth manager that receives the request ignores the SDP information, then it does not include the Codec-Data AVP in the AAR.

For calls that do not require special treatment, the Codec-Data AVP is required to have the:

  • AVP code 599
  • 3GPP vendor identification number (10415)
  • V (vendor) bit set in the AVP
  • M (mandatory) bit set when sending this AVP
  • Type octet string

In addition, the Codec-Data AVP appears as described in the following table.

AVP section/line Requirement
Line 1 Must specify the direction of the flow by including the ASCII “uplink” or downlink:

uplink—Identifies the SDP as having come from the UE and sent to the network

downlink—Identifies the SDP as having come from the network and sent to the UE

Line 2 Must specify whether the offer or answer codec is at issue by including the ASCII “offer” (from an SDP offer according to RFC 3264) or answer (from an answer according to RFC 3264)
Remainder of the AVP Must include lines found in the signaling SDP, formatted in ASCII and separated by new-line characters; the first line of this section must be the m line, followed by any “a” or “b” lines related to that m line

Priority Call Handling

The Oracle Communications Session Border Controller determines that a call is priority call when it matches a defined network management control (NMC) priority rule. No other scenario triggers the priority call handing treatment described in this section.

When a SIP signaling event triggers external bandwidth management use for a priority call, the Oracle Communications Session Border Controller sends the Reservation-Priority AVP in the AAR message. The Reservation-Priority AVP is required to:

  • Use the ETSI Vendor identification number (13019)
  • Have the V (vendor) bit set in the AVP
  • Not to have the M (mandatory) bit set when sending this AVP
  • Be of type enumeration
  • Set to PRIORITY-SEVEN (7)

Rx bearer plane event

The Rx reference point is used to exchange application level session information between the PCRF and the AF which is the Oracle P-CSCF/SBC. The PCRF exchanges the Policy and Charging Control (PCC) rules with the PCEF (Policy and Charging Enforcement Function) and QoS rules with the BBERF (Bearer Binding and Event Reporting Function). The role of the former is typically performed by a 3GPP/GGSN, 3GPP-R9/PGW, 3GPP2/PDSN, WiFi/Max/ASN-GW. The role of the latter may be a standalone element or typically it’s incorporated within the system acting as the PCEF. The Oracle P-CSCF/SBC offers applications that require policy and charging control of traffic plane resources (e.g. UMTS PS domain/GPRS domain resources). Currently support for Rx within the Oracle Communications Session Border Controller supports policy, the present requirement will enhance Rx to incorporate traffic plane event notifications north bound. The PCRF receives session and media related information from the Oracle Communications Session Border Controller currently and with this enhancement the PCRF will report traffic plane events to the Oracle Communications Session Border Controller.

BN-Bearer-0040: When not all the service data flows within the AF session are affected, the PCRF will send an RAR command that includes the deactivated IP flows encoded in the Flows AVP and the cause encoded in the Specific-Action AVP.

BN-Bearer-0050: The Oracle SBC/P-CSCF shall acknowledge the receipt of this RAR command by sending an RAA. It shall then proceed to release the entire session at the SIP signaling layer and proceed to send the corresponding Diameter STR command to the PCRF and receive the STA.

AA-Request (AAR) Command

The following Specific-Action notifications will be added to the AA-Request command:

  • INDICATION_OF_LOSS_OF_BEARER (2)
  • INDICATION_OF_RECOVERY_OF_BEARER (3)
  • INDICATION_OF_RELEASE_OF_BEARER (4)
  • INDICATION_OF_OUT_OF_CREDIT (7)
  • INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION (8)
  • INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9)

Re-Auth-Request (RAR) Command Handling

The Flows AVP (510) and Abort-Cause AVP (500) will be ignored if they are received in the RAR command.

The Specific-Action AVP (513) will be handled as follows:

  • Notification: INDICATION_OF_LOSS_OF_BEARER (Action: Terminate SIP Session * Send RAA BYE will be sent to both the EU and the core. This is similar to the Abort-Session--Request (ASR) handling).
  • Notification: INDICATION_OF_RELEASE_OF_BEARER (Action: Terminate SIP Session * Send RAA BYE will be sent to both the EU and the core. This is similar to the Abort-Session--Request (ASR) handling).
  • Notification: INDICATION_OF_OUT_OF_CREDIT(Action: Terminate SIP Session * Send RAA BYE will be sent to both the EU and the core. This is similar to the Abort-Session--Request (ASR) handling).
  • Notification: INDICATION_OF_FAILED_RESOURCES_ALLOCATION (Action: Terminate SIP Session * Send RAA BYE will be sent to both the EU and the core. This is similar to the Abort-Session--Request (ASR) handling).
  • Notification: INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION (Action: Send RAA).
  • Notification: INDICATION_OF_RECOVERY_OF_BEARER (Action: Send RAA)

2836 - Early Media Suppression for Rx

The Oracle Communications Session Border Controller supports early media suppression where it does not allow media to flow between the endpoints it connects until the session is fully established as noted by receiving a 200 OK. Early media supression is configured by setting the early-media-allow parameter on a realm, realm group, or session agent to none.

The Oracle Communications Session Border Controller also relays the state of early media suppression in the Flow-Status AVP in an AAR message to the PCRF as the call is being set up. When the call’s media is still in a suppressed state, the Flow-Status AVP is set to Disabled. The following image illustrates when the Flow-Status changes from disable to enable.

Depicts a call flow signaling early media suppression via diameter.

Media-Component-Number and Flow-Number AVP Values

The values assigned to the Media-Component-Number and Flow-Number AVPs are not derived in compliance with 3GPP standards. Version S-CZ7.2.0 provides the capability to derive compliant values.

AA-Request (AAR) messages are sent, via the Rx Interface, by an Access Function (AF) to a Policy and Charging Rules Function (PCRF) in order to provide it with the session information. Among other fields, these messages contain a Media-Component-Number AVP and a Flow-Number AVP, used to identify specific media sessions, and the individual IP flows associated with these sessions.

The values assigned to the Media-Component-Number and Flow-Number AVPs are not derived in compliance with 3GPP standards.

Release S-CZ7.2.0 provides a new option that enables compliance with 3GPP requirements. Note that this support is limited to the Rx Interface

Media-Component-Number AVP

The Media-Component-Number AVP (AVP code 518) is of type Unsigned32; it contains the ordinal number of the media component (the SDP m= line) as specified in 3GPP TS 29.214. When this AVP refers to AF signalling, it contains the value 0. The Media-Component-Number AVP provides an index to the grouped Media-Component-Description AVP (AVP code 517).

3GPP compliance requires that:

  1. Number should start from 1
  2. It should contain the ordinal number of the position of the m= line in the SDP.
  3. When this AVP refers to AF Signalling, this is indicated by using the value 0.
  4. The ordinal number of a media component shall not be changed when the session description information is modified.

Flow-Number AVP

The Flow-Number AVP (AVP code 509) is of type Unsigned32; it contains the ordinal of the IP flows created to support a specific SDP m= line as specified in 3GPP TS 29.214. The Flow-Number AVP provides an index to the grouped Media-Sub-Component AVP (AVP code 519).

3GPP compliance requires that:

  1. Number should start from 1
  2. It should contain the ordinal number of the IP flow(s) within the m= line assigned in the order of increasing downlink destination port numbers, if downlink destination port numbers are available.
  3. It should contain the ordinal number of the IP flow(s) within the m= line assigned in the order of increasing uplink destination port numbers, if no downlink destination port numbers are available.
  4. The ordinal number assigned should not be changed when the session description information is modified.

Flow Examples

The following example illustrates the derivation of flow identifiers from SDP as specified by 3GPP TS 29.214 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Rx reference point (Version 9.3.0).

A flow identifier consists of two digits in the form #,# with the digit identifying a specific SDP m= line (defining a media session), and the second digit identifying a specific IP flow (for example, an RTP stream) supporting the media session. 3GPP standards require that the Media-Component-Number AVP be populated with the first digit if the flow identifier and the Flow-Number AVP be polulated with the second digit.

A UE, as the offerer, sends a SDP session description (relevant sections shown below) to an application server.

v=0
o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A
s=MM01
i=One unidirectional audio media and one unidirectional video media and one bidirectional application
media
t=3262377600 3262809600
m=video 50230 RTP/AVP 31                          Ordinal 1 (3 media flows, 1 RTP & 2 RTCP)
c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A
a=recvonly
m=audio 50330 RTP/AVP 0                           Ordinal 2 (3 media flows, 1 RTP & 2 RTCP)
c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A
a=sendonly
m=application 50430 udp wb                        Ordinal 3 (2 media flows, up & down links)
c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A
a=sendrecv

The application returns (relevant sections):

v=0
o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A
s=MM01
i=One unidirectional audio media and one unidirectional video media and one bidirectional application
media
t=3262377600 3262809600
m=video 51372 RTP/AVP 31                          Ordinal 1 
c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014
a=sendonly
m=audio 49170 RTP/AVP 0                           Ordinal 2
c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014
a=recvonly
m=application 32416 udp wb                        Ordinal 3
c=IN IP6 2001:0646:000A:03A7:0250:DAFF:FE0E:C6F2
a=sendrecv

From this offer–answer exchange of SDP parameters the UE and the application server each creates a list of flow identifiers as shown below.

Order of m= line Type of IP Flows Destination IP Address/Port Number of Flows Flow Identifier
1 RTP (Video) DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50230 <1,1>
1 RTCP DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50231 <1,2>
1 RTCP UL 2001:0646:000A:03A7:02D0:59FF:FE40:2014 / 51373 <1,2>
2 RTP (Audio) UL 2001:0646:000A:03A7:02D0:59FF:FE40:2014 / 49170 <2,1>
2 RTCP DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50331 <2,2>
2 RTCP UL 2001:0646:000A:03A7:02D0:59FF:FE40:2014 / 49171 <2,2>
3 UDP (application) DL 2001:0646:00F1:0045:02D0:59FF:FE14:F33A / 50430 <3,1>
3 UDP (application) UL 2001:0646:000A:03A7:0250:DAFF:FE0E:C6F2 / 32416 <3,1>

Media-Component AVP 3GPP Compliance Configuration

Use this procedure to enable compliance with 3GPP requirements. Compliance is enabled with the format-flow-id option available in ext-policy-server configuration mode.
  1. Access the ext-policy-server configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# media-manager
    ORACLE(media-manager)# ext-policy-server
    ORACLE(ext-policy-server)# 
  2. Select the ext-policy-server object to edit.
    ORACLE(ext-policy-server)# select
    <name>:1:  name=extpol1
    
    selection: 1
    ORACLE(ext-policy-server)#
  3. format-flow-id—Add this option to enable 3GPP compliance.
    ACMEPACKET(ext-policy-server)# options +format-flow-id
  4. Type done to save your configuration.

Rx Interface Reason Header Usage

The Oracle Communications Session Border Controller has increased capability to map network events to a configurable SIP Reason header. The extended capability provides for the mapping of specific disconnect events on the Rx Interface.

Release S-CZ7.2.0, and later releases expands the usage of the Reason header and its associated parameters to include mapping of disconnect events on the Rx interface between an SBC (functioning in the P-CSCF role) and a Policy and Charging Rules Function (PCRF). With the expanded capability enabled, contents of the Reason header are based on either the contents of the Specific-Action AVP in Re-Authorization Request (RAR) messages issued by the PCRF, or the contents of the Abort-Cause AVP in Abort Session Request (ASR) messages issued by the PCRF.

To use this feature, set the session-router, sip-interface, rx-sip-reason-mapping parameter to enabled.

Specific-Action AVP

The Specific-Action AVP (AVP code 513) is of type Enumerated.

Within a PCRF initiated Re-Authorization Request, the Specific-Action AVP determines the type of the action.

The following reported disconnected events can be mapped to SIP Reason headers using the corresponding value to configure in a local-response-map-entry, local-error.

Specific-Action AVP Value local-error configuration
2 -- INDICATION_OF_LOSS_OF_BEARER rx-rar-loss-of-bearer
4 -- INDICATION_OF_RELEASE_OF_BEARER rx-rar-release-of-bearer
7 -- INDICATION_OF_OUT_OF_CREDIT rx-rar-out-of-credit
9 -- INDICATION_OF_FAILED_RESOURCES_ALLOCATION rx-rar-failed-resources-allocation

Abort-Action AVP

The Specific-Action AVP (AVP code 500) is of type Enumerated.

Within a PCRF initiated Abort Session Request (ASR), the Abort-Cause AVP identifies the cause of the ASR.

The following reported disconnected events can be mapped to SIP Reason headers using the corresponding value to configure in a local-response-map-entry, local-error.

Abort-Cause AVP Value local-error configuration
0 -- BEARER_RELEASED rx-asr-bearer-released
1 -- INSUFFICIENT_SERVER_SERVICES rx-asr-insufficient-server-resources
2 -- INSUFFICIENT_BEARER_SERVICES rx-asr-insufficient-bearer-resources
3 -- PS_TO_CS_HANDOVER rx-asr-ps-to-cs-handover
4 -- SPONSORED_DATA_CONNECTIVITY_DISALLOWED rx-asr-sponsored-data-connectivity-disallowed

Message Flows

Mapped headers will appear in either a BYE or a CANCEL message from the P-CSCF. As shown in the following illustrations, a BYE message is issued when the disconnect event occurs after establishing the SIP session. A CANCEL message is issued when the disconnect event occurs before establishing the SIP session.

RAR Loss-of-Bearer After Session Establishment

If mapping is not enabled, the Reason header defaults to SIP;cause=503;text="Service Unavailable”.