Codec Policy Configuration

Codec policies describe how to manipulate SDP messages as they cross the Oracle® Enterprise Session Border Controller (ESBC). The ESBC 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 which codecs are retained or removed, and how they are ordered within SDP.

When configuring transcoding, you create a codec policy and associate the policy to a realm. In the codec policy, you specify:

  • Which codecs to allow and which codecs to deny within a realm.
  • Which codecs to add to the SDP m= lines for an egress realm.
  • The preferred order of codecs shown in an SDP m= line.
  • The packetization time to enforce within a realm for transrating.

Terms Used in Codec Policies

Understand the following definitions for terms used in codec policies.

DTMF Codecs—Uncompressed codecs capable of properly transmitting a Dual-tone Multi-frequency (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, and 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 ESBC. 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 (for example, sendrecv, inactive, and rtcponly) 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 (ESBC) applies the egress codec policy to the SDP that was processed by the ingress policy. The ESBC 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 ESBC 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 ESBC disables the m= image line. Otherwise if T.38 is allowed, passing it through the regular offer processing.

  • When adding a codec on the egress side, the ESBC checks to see if the payload presented is already in that direction's codec list. The system does this by matching all parameters for that codec. This check includes the codec type itself. If present, the system uses that PT. If not, the system generates a new payload for the new codec.

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 is ordered according to the 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.

You can use codec policies to normalize codecs and packetization time 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

Use the allow-codecs parameter to configure the codecs that you want to allow and remove from the SDP. A blank list allows nothing, * allows all codecs, none removes all codecs, :no blocks the specific codec or class of media, and :force removes all non-forced codecs.

Use the following settings to configure the allow-codecs parameter:

  • <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 to go on to the next step of transcoding processing, and all other codecs are removed.

The following list describes the order of precedence for removing codecs according to the codec policy:

  1. <codec>:no—Overrides all other allow-codecs parameter actions.
  2. audio:no and video:no. An allow-codecs line such as “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. *—The lowest precedence of all flags. For example "allow-codecs * PCMU:no" allows all codecs except PCMU.

order-codecs

Use the order-codecs parameter 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. Use the following 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 following examples.

  • <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

Use the add-codecs-on-egress parameter to add a codec to the SDP’s m= line only when the codec policy is referenced from an egress realm (except in one 2833 scenario). The codecs you enter 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 scenario 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

Use the packetization-time parameter to specifiy a media packetization time in milliseconds (ms) to use within the realm referencing this codec policy. You must also enable the force ptime parameter to enable transrating in conjunction with configuring the packetization time. See Transrating for more information.

Set a User-Defined Ptime per Codec

To change the default packetization time (ptime) on the Oracle® Enterprise Session Border Controller for a specific codec, you must create a media profile configuration element. In the parameter parameter, you can set the ptime to the value you want.

  • Confirm that the system is in Superuser mode.

If you are adding ptime to a pre-existing media profile, then you must select the configuration that you want to edit (using the ACLI select command). If you are adding ptime to an undefined media profile, you must create the profile first.

Note:

The frames-per-packet parameter in the media profile configuration element is not used for setting a user defined ptime for that codec.

To configure a new ptime value for a codec:

  1. Access the media-profile configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# session-router
    ORACLE(session-router)# media-profile
    ORACLE(media-profile)# 
  2. name—Type the name of the codec for which you are creating a new default ptime.
    ORACLE(media-profile)# name pcmu
  3. payload-type—Enter the well-known payload type for this codec.
    ORACLE(media-profile)# payload-type 0
  4. parameter—Set the ptime by typing parameter, a Space, ptime=, the new ptime value. Then press Enter. For example:
    ORACLE(media-profile)# parameter ptime=40
  5. Type done to save your configuration.

Name a Codec Policy

The name of the codec policy is important not only because it uniquely identifies the policy, but because it is the name you will enter into the codec-policy parameter in your realm configuration. It is important to apply the correct policy to the appropriate realm.

To set the codec policy’s name:

  1. name—Set the name for this codec policy, and note it for future reference when you apply codec policies to realms. This parameter is required, and has no default.
    ORACLE(codec-policy)# name private

Order Codecs

In the codec policy, you can specify the order that codecs appear in the SDP offer or answer.

To configure an order which codecs appear in the offer:

  1. order-codecs—Enter the order in which you want codecs to appear in the SDP offer or answer. See "order-codecs" for the possible ways to set the order.
    ORACLE(codec-policy)# order-codecs G711 * G729

Allow, Remove, and Add Codecs for Transcoding

The Oracle® Enterprise Session Border Controller (ESBC) allows and removes codecs by way of the following parameters in codec-policy.

allow-codecs

The ESBC uses the list that you create in the allow-codecs parameter in codec-policy to pass through the codecs that you want by allowing them to remain in the SDP for the next step. The ESBC removes codecs that do not match entries on the list. This parameter is required.

Enter a list of codecs that are allowed to pass through the ESBC. Use the syntax in the Transcodable Codecs section of this chapter. To allow all codecs, enter an asterisk (*).

ORACLE(codec-policy)# allow-codecs *

When multiple items are added, enclose them in quotes. For example:

ORACLE(codec-policy)# allow-codecs G729 G711 AMR

add-codecs-on-egress

The ESBC uses the list that you create in the add-codecs-on-egress parameter in codec-policy to set the codecs that the ESBC adds to an offer when they are not present in the offer. This parameter applies only to the egress policy.

Enter the codecs that you want added to the SDP offer for the egress codec policy. If you leave this parameter blank, the ESBC does not add codecs to the SDP answer. You cannot use this parameter as a wildcard.

To remove items from the allow-codecs list, simply replace the add command you see in these example with delete and remove the items you want.

ORACLE(codec-policy)# add-codecs-on-egress G729

Remove Codecs

To remove items from the allow-codecs and add-codecs-on-egress lists, replace the add command with delete and remove the items you want.

ORACLE(codec-policy)# delete-codecs G729
ORACLE(codec-policy)# delete-codecs-on-egress G729

Note:

When you need to modify the list of configured codecs, you must enter the complete list at one time.

Configure a Codec Policy

  • Confirm that the system is in Superuser mode.

You can use a single codec policy for any number of realms.

  1. Access the codec-policy configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# media-manager
    ORACLE(media-manager)# codec-policy
    ORACLE(codec-policy)# select
  2. Do the following:
    Name Description
    Name Type a name for this policy.
    Allow codecs Type the name of the codecs that you want to allow on ingress, any exceptions. See "allow-codecs."
    Add codecs on egress Type the names of the codecs that you want to add on egress. See "Add on Egress."
    Order codecs Type the names of the codecs in the order you want them processed. See "order-codecs."
    Packetization time Set the time, in milliseconds, that you want the system to wait before enforcing packetization on the outgoing SDP offer. See "Packetization Time." Requires enabling Force Ptime. Default: 20. Range: 0-4294267295.
    Force ptime Enable to enforce the packetization time.
    Secure dtmf cancellation Enable to completely remove all DTMF tones on ingress to make them undetectable on egress. Default: Disabled.
    Dtmf in audio Set how you want the system to handle DTMF in audio streams. Default: Disabled. Valid values: Disabled | Preferred | Dual.
    Tone detect renegotiate timer Set the time in milliseconds that you want the system to wait before sending a REINVITE if the SBC does not receive a REINVITE from the endpoint. Default: 500. Range: 50-32000.
    Reverse fax tone detection reinvite Enable to force the SBC to send a REINVITE to a realm other than the one on which the FAX tone detection is enabled. Default: Disabled.
    Evrc tty baudot transcode Enable to transcode EVRC, TTY, and TDD calls to Baudot in EVRC-G7.11 transcoded calls.
  3. Type done to save your configuration.

Configure Transrating

The following procedure explains how to configure transrating for a codec policy. You must apply this codec policy as an egress codec policy.

  • Confirm that the system is in Superuser mode.

If you are adding support for this feature to an existing configuration, you must select the specific configuration instance using the ACLI select command.

To configure forced ptime for a codec policy:

  1. Access the codec-policy configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# media-manager
    ORACLE(media-manager)# codec-policy
    ORACLE(codec-policy)# select
  2. Select the codec-policy object to edit.
    ORACLE(codec-policy)# select
    <name>:
    1:  name=cp1
    2:  name=cp2
    
    selection: 2
    ORACLE(codec-policy)#
  3. force-ptime—Set this parameter to enabled to enable forced ptime for this codec policy.
  4. packetization-time—Enter the ptime in milliseconds (ms) to use in the realm where this codec policy is active. Default: 20ms. Valid values: 10, 20, 30, 40, 50, 60, 70, 80, 90 ms.
  5. Type done to save your configuration.

Apply a Codec Policy to a Realm

After you configure a codec policy, you apply it to a realm by policy name.

  • Confirm that the system is in Superuser mode.

To apply a codec policy to a realm:

  1. Access the realm-config configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# media-manager
    ORACLE(media-manager)# realm-config
    ORACLE(realm-config)# 
  2. Select the realm-config object to edit.
    ORACLE(realm-config)# select
    identifier:
    1: realm01 left-left:0 0.0.0.0
    
    selection: 1
    ORACLE(realm-config)#
  3. codec-policy—Enter the name of the codec policy that you want to apply to this realm. This value is the same as the one you entered in the name parameter for the codec policy you want to use for this realm. There is no default for this parameter.
    ORACLE(realm-config)# codec-policy private
  4. Type done to save your configuration.

Secure DTMF Cancellation

For security and privacy reasons, you can remove all Dual-Tone Multi-Frequency (DTMF) information that the Oracle® Enterprise Session Border Controller (ESBC) processes by enabling secure-dtmf-cancellation within the codec-policy. For example, you might want to cancel all DTMF tones when processing credit card numbers, debit card numbers, PIN numbers, and other DTMF-based passwords that you want to remove from the media stream. When an incoming call requires DTMF cancellation, the ESBC uses the built-in detection and cancellation mechanism to completely remove all sixteen DTMF tones on ingress making the tones undetectable on egress. (0-9, *, #, A,B,C,D)

The ESBC supports secure DTMF cancellation for all use cases and call scenarios that include in-band DTMF detection, such as DTMF in-band to SIP-INFO, DTMF in-band to RFC2833, DTMF in-band to None and DTMF over RFC2833. Oracle recommends that you enable this feature for codec policies that use codecs that support reliable in-band DTMF detection on ingress, such as PCMU.

Standard DTMF cancellation can leave some residual signal energy at the beginning and ending of each DTMF digit. The practical result of this is that an important piece of data, such as a card number, is still detectable within the egress stream. The ESBC performs a second function with secure-dtmf-cancellation to remove this leftover signaling from the media stream. To do this, the ESBC uses process timing as opportunities to identify any immediately identified or residual DTMF and cancels it.

The result is silence for the entire duration of each DTMF digit and the elimination of all stray DTMF data.

This feature works on all flows, including TLS/SRTP.

In addition to enabling secure-dtmf-cancellation in the codec policy, you must set dtmf-in-audio in the codec policy such that it is not disabled.

Note:

An endpoint configured as secure at the session startup stays in the secure mode throughout the call because you cannot re-configure the DTMF cancellation mode during the call.

Note:

The secure-dtmf-cancellation option does not remove DTMF bleed unless transcoding is enabled for the call.

Enable Secure DTMF Cancellation

When you want to completely remove all traces of Dual-Tone Multi-Frequency (DTMF) information that the Oracle® Enterprise Session Border Controller (ESBC) processes, enable secure-dtmf-cancellation to make the DTMF tones undetectable.

Secure-dtmf-cancellation requires that you also enable dtmf-in-audio. If dtmf-in-audio is not already enabled, you can enable both attributes in the following procedure.

  1. Access the codec-policy configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# media-manager
    ORACLE(media-manager)# codec-policy
    ORACLE(codec-policy)# select
  2. Select the codec-policy object to edit.
    ORACLE(codec-policy)# select
    <name>:
    1:  name=cp1
    2:  name=cp2
    
    selection: 2
    ORACLE(codec-policy)#
  3. Enable the secure-dtmf-cancellation parameter.
    
    ORACLE(codec-policy)#secure-dtmf-cancellation enabled
  4. Enable the dtmf-in-audio parameter.
    
    ORACLE(codec-policy)#dtmf-in-audio dual
  5. Type done to save your configuration.