Transcoding Configuration

The Oracle Communications Session Border Controller performs transcoding functions— allowing the entities with incompatible codecs to communicate with each other— between two call legs. The two endpoints can be located in one or two realms or networks. The Oracle Communications Session Border Controller decides to transcode a call by evaluating messages in the SDP offer-answer transaction with respect to system configuration. An SDP offer can be in a SIP message such as an INVITE or a reINVITE, and contains information about the codecs the offerer would like to use. The answerer answers the SDP offer with its own set of supported codecs. reINVITEs are treated as new negotiations, with respect to the actual SDP offerer and answerer. The Oracle Communications Session Border Controller can manipulate an SDP message by reordering codec preference, and by adding and deleting codecs.

Transcoding Processing Overview

Transcoding processing is viewed in terms of the ingress and egress realms. The ingress realm is where the SDP offer is received by the Oracle Communications Session Border Controller. The egress realm is where the SDP offer is sent, and where the SDP answer is expected to be received from (i.e., the answerer's realm). A call is defined as transcodable if an egress or ingress policy exists for the session and if the session is not subject to media release, as specified in the realm configuration.

To understand the details of transcoding processing, refer to the following diagram. An SDP offer, O0, is received by the Oracle Communications Session Border Controller in the ingress realm. The ingress codec policy is applied here and the SDP offer is transformed into O1. O1 is then passed to and processed by the egress codec policy. This SDP message is then forwarded to the answerer as O2. The answerer replies with A0 to the Oracle Communications Session Border Controller, which is subjected to the egress codec policy again and transformed into A1.

When policy dictates not to transcode the call, the Result SDP sent back to the offerer is based on the common codecs shared between A1 and O1. The Oracle Communications Session Border Controller first constructs the list of codecs that are present in both in O1 and A1. Then, the Oracle Communications Session Border Controller maintains the codec order from A1 for the Result as it is sent to the offerer.

When policy dictates to transcode the call, the top transcodable codec in O1 is used in the ingress realm and the top non-signaling codec in A1 is used in the egress realm.

This illustration shows the ingres and egress flow of call traffic from an offerer to an answerer across the SBC.

Defining Codec Policies

The following definitions are required for understanding transcoding processing:

DTMFable Codecs—Uncompressed codecs that are capable of properly transmitting a DTMF waveform. The only codecs designated as DTMFable are PCMU and PCMA.

FAXable Codecs—Uncompressed codecs that are capable of properly transmitting a T.30 waveform. The only codecs designated as FAXable are PCMU and PCMA.

Signaling Codecs—Non-audio codecs that are interleaved into a media stream but cannot be used on their own. The only codecs designated as Signaling Codecs by the Oracle Communications Session Border Controller are telephone-event and CN (comfort noise).

Disabling an m= line—This is in reference to an m= line in an SDP message. It means setting the m= line’s port to 0 (RFC 3264). Enabling an m= line means it has a non-zero port. The m= line’s mode attribute (sendrecv/inactive/rtcponly, etc) is not considered.

A codec policy is created by configuring the following information:

Which Codecs are allowed and which are denied in a realm.
Which Codecs should be added to the SDP m= lines for an egress realm.
The preferred order of codecs to indicate in an SDP m= line.
The packetization time which should be enforced within a realm.

Ingress Policy

Incoming SDP is first subject to the ingress codec policy. If no codec policy is specified in the realm config for the ingress realm, or the m= lines in the SDP offer are disabled (by a 0 port number), the SDP is transformed to O1 unchanged.

The ingress codec policy first removes all un-allowed codecs, as configured in the allow-codecs parameter by setting their port to 0 or removing the codecs from a shared m-line. For example, if two codecs share an m-line and one of them is un-allowed, the resulting m-line will not include the un-allowed codec and its attribute lines will be removed. If a single codec is used, the resulting m-line will include the codec, but its port will be set to 0 and its attribute lines will remain. Next, the remaining codecs are ordered with the order-codecs parameter. Ordering is when the codec policy rearranges the codecs in the SDP m= line. This is useful to suggest the codec preferences to impose within the egress realm. O1 is then processed by the egress codec policy after a realm is chosen as the destination.

In practical terms, the ingress policy can be used for filtering high-bandwidth codecs from the access realm. It can also be used for creating a suggested, prioritized list of codecs to use in the ingress realm.

Egress Policy

The Oracle Communications Session Border Controller (OCSBC) applies the egress codec policy to the SDP that was processed by the ingress policy. The OCSBC applies the egress policy the SDP exits the system into the egress realm. When no egress codec policy is defined, or the SDP’s m= lines are disabled (with a 0 port), the SDP is passed untouched from the ingress policy into the egress network.

The egress codec policy first removes all disallowed codecs in the allow-codecs parameter (<codec>:no). Codecs on the add-codecs-on-egress list are not removed from the egress policy regardless of the how the allow-codecs parameter is configured. If the result does not contain any non-signaling codecs, the ptime attribute is removed from the SDP. Codecs not present in O1 that are configured in the add-codecs-on-egress parameter are added to the SDP, only when O1 contains one or more transcodable codecs.

Note:

Transcoding can only occur for a call if you have configured the add-codecs-on-egress parameter in an egress codec policy.

If codecs with dynamic payload types (those between 96 and 127, inclusive) are added to the SDP, the lowest unused payload number in this range is used for the added codec.

The following rules are also applied for egress policy processing:

When O1 contains at least one transcodable codec the system adds the codecs listed in the Egress policy to the SDP, as follows.

telephone-event—added only when O1contains at least one DTMF-suppported codec.
comfort-noise—added only when O1 contains at least one non-signaling transcodable audio codec, and when O2 contains a comfort noise interoperable codec (either present in O1 and allowed, or also added on egress).
T.38—added when there is no T.38 and there is at least one FAX-supported codec (G711Fall Back (FB)) in O1. T.38 added as a new m= image line to the end of SDP.
When the egress policy does not allow G711FB, the OCSBC disables the m= line with the FAX-supported codec. Otherwise when G711FB is allowed; pass it through the regular offer processing allowing/adding only FAX-supported codecs.
G711FB, added when there is no G711FB and there is T.38 in O1. The system adds G711FB as a new m= audio line to the end of SDP.
When the egress policy does not allow T.38, the OCSBC disables the m= image line. Otherwise if T.38 is allowed, passing it through the regular offer processing.

When the result of the egress policy does not contain any non-signaling codecs (audio or video), the m= line is disabled by setting the port number to 0.

The m= line—ordered according to rules for the order-codecs parameter.

All attributes, a= lines, ptime attribute, and all other unrecognized attributes are maintained from O1. Appropriate attributes for codecs added by the add-on-egress parameter are added to SDP. The rtpmap and fmtp parameters are retained for codecs not removed from the original offer. The result is O2, as shown in the overview diagram.

You can use codec policies to normalize codecs and packetizationtime in the core realm, where the network conditions are clearly defined.

You can also use codec policies to force the most bandwidth-conserving codecs anywhere in the network.

Post Processing

If any errors are encountered during the Ingress and Egress policy application, or other violations of RFC3264 occur, the call is rejected. If O2 does not contain any enabled m= lines at the conclusion of the initial call setup, the call is rejected. If O2 does not contain any enabled m= lines at the conclusion of a reINVITE, the reINVITE is rejected and the call reverts back to its previous state.