Transcoding Configuration

The Oracle® Enterprise Session Border Controller (E-SBC) uses codec policies to describe how to manipulate SDP messages as they cross the E-SBC. The E-SBC bases its decision to transcode a call on codec policy configuration and the SDP. Each codec policy specifies a set of rules to be used for determining what codecs are retained, removed, and how they are ordered within SDP.

Terms Used in Codec Policies

Understand the following definitions for terms used in codec policies.

DTMF Codecs—Uncompressed codecs capable of properly transmitting a DTMF waveform. Supported codecs: PCMU and PCMA.

FAX Codecs—Uncompressed codecs capable of properly transmitting a T.30 waveform. Supported codecs: PCMU and PCMA.

Signaling Codecs—Non-audio codecs interleaved into a media stream, but cannot be used on their own. Supported Codecs: Telephone-event and Comfort Noise (CN).

Comfort Noise Codecs—Interoperable codecs used to transcode silence to Comfort Noise on the E-SBC. Supported codecs: PCMA, PCMU, and G.726.

Disable an m= line in an SDP message—Use to set the m= line port to 0 (RFC 3264).

Enable an m= line in an SDP message—Use to set the m= line port to non-0 (RFC 3264). The m= line’s mode attribute (sendrecv/inactive/rtcponly, etc) is not considered.

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® Enterprise Session Border Controller (E-SBC) applies the egress codec policy to the SDP that was processed by the ingress policy. The E-SBC 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 E-SBC 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 E-SBC 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.

allow-codecs

allow-codecs—The allow-codecs parameter configures the codecs that are allowed and/or removed from the SDP. A blank list allows nothing, * allows all codecs, none removes all codecs, the :no designation blocks the specific codec or class of media, and the :force designation is used to remove all non-forced codecs.

The allow-codecs parameter is configured in the following way:

• <codec>:no—blocks the specific codec
• *—allow all codecs.
• <codec>:force—If any forced codec is present in an SDP offer, all non-forced codecs are stripped from the m- line.
• audio:no—audio m= line is disabled
• video:no—video m= line is disabled

For example, if you configure PCMU in the allow-codecs parameter, the PCMU codec, received in an SDP message is allowed on to the next step of transcoding processing, and all other codecs are removed.

The order of precedence is for removing codecs according to codec policy is:

1. <codec>:no—Overrides all other allow-codecs parameter actions.
2. audio:no / video:no. An allow-codecs line like “allow-codecs PCMU audio:no” disables the PCMU m= line because audio:no has a higher precedence than the specific codec.
3. <codec>:force
4. <codec> Specific codec name and those codecs configured in the add-codecs-on-egress list.
5. * has the lowest precedence of all flags. For example "allow-codecs * PCMU:no" allows all codecs except PCMU.

order-codecs

order-codecs—The order-codecs parameter is used to re-order the codecs in the m= line as the SDP is passed on to the next step. This parameter overwrites the order modified by the add-codecs-on-egress command, when relevant. The following is valid syntax for this parameter:

• <blank>—Do not re-order codecs
• *—You can add a <codec> before or after the * which means to place all unnamed codecs before or after (the position of the *) the named codec. For example:
• <codec> *—Puts the named codec at the front of the codec list.
• * <codec>—Puts the named codec at the end of the codec list.
• <codec1 > * <codec2>—Puts <codec1> first, <codec2> last, and all other unspecified codecs in between them.
• <codec>—When the * is not specified, it is assumed to be at the end.

Any codec name is allowed in the order-codecs parameter, even those not defined or not transcodable. An * tells the order-codecs parameter where to place unspecified codecs with respect to the named codecs. Refer to the examples below.

• <blank>—do not reorder m= line
• PCMU *—Place PCMU codec first, all others follow
• * PCMU—Place PCMU codec last, all others proceed PCMU
• G729 * PCMU—Place G729 codec first, PCMU codec last, all others remain in between
• PCMU—If * is not specified, it is assumed to be at the (PCMU *).

Add on Egress

add-codecs-on-egress—This parameter adds a codec to the SDP’s m= line only when the codec policy is referenced from an egress realm (except in one 2833 scenario). Codecs entered for this parameter are added to the front of the m= line. Signaling codecs are added to the end of the m= line.

Transcoding can only occur if this parameter is configured. There is a special case for 2833 support where the add-codecs-on-egress parameter is configured for an ingress realm. See RFC 2833 Scenario 2 for details.

Packetization Time

packetization-time—This parameter specifies a media packetization time in ms to use within the realm referencing this codec policy. Packetization time You must also enable the force ptime parameter to enable transrating in conjunction with configuring the packetization time. See the Transrating section for more information.