Codec Policy Configuration
Codec policies describe how to manipulate SDP messages as they cross the Oracle Communications Session Border Controller (OCSBC). The OCSBC 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 OCSBC. 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 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 adding a codec on the egress side, the OCSBC 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:
- <codec>:no—Overrides all other allow-codecs parameter actions.
- 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.
- <codec>:force
- <codec> Specific codec name and those codecs configured in the add-codecs-on-egress list.
- *—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 Communications 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:
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:
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:
Allow, Remove, and Add Codecs for Transcoding
The Oracle Communications Session Border Controller (OCSBC) allows and removes codecs by way of the following parameters in codec-policy.
allow-codecs
The OCSBC 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 OCSBC 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 OCSBC. 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 OCSBC uses the list that you create in the add-codecs-on-egress parameter in codec-policy to set the codecs that the OCSBC 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 OCSBC 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.
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:
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:
Secure DTMF Cancellation
For security and privacy reasons, you can remove all Dual-Tone Multi-Frequency (DTMF) information that the Oracle Communications Session Border Controller (OCSBC) 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 OCSBC 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)
In contrast to standard DTMF cancellation, which leaves some residual signal energy at the beginning and ending of each DTMF digit, secure-dtmf-cancellation removes all signal energy from the media stream by adding an extra 10μs to the leading and trailing edges of the DTMF tones. The result is silence for the entire duration of each DTMF digit because the system mutes all audio when you suppress DTMF tones with secure-dtmf-cancellation.
- PCMU
- PCMA
- G.726-32 (and higher)
- G.722
Secure DTMF cancellation supports hardware transcoding only. You must own the transcoding license and you need transcoding resources, such as a Digital Signal Processor (DSP). In addition to enabling secure-dtmf-cancellation in the codec policy, you must enable dtmf-in-audio in the codec policy. You can enable secure-dtmf-cancellation and dtmf-in-audio in the ACLI and the Web GUI.
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.Enable Secure DTMF Cancellation
When you want to completely remove all traces of Dual-Tone Multi-Frequency (DTMF) information that the Oracle Communications Session Border Controller (OCSBC) 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.