- Contents
- Prerequisites for Implementing Transcoding
- Restrictions for Implementing Transcoding
- Restrictions for Media Gateway-Assisted DMTF Interworking
- Information About Transcoding
- Configuration Examples for Implementing Transcoding
- Verification
- Voice Transcoding Per Adjacency Statistics
- Media Gateway-Assisted DTMF Interworking
- Blended Transcoding
- Configuration Example for Blended Transcoding
Implementing Transcoding
Transcoding is the process of translating a media stream encoded using one codec into a media stream encoded using another codec. For example, translating a media stream encoded as Pulse Code Modulation u-law (PCMU) into one encoded as ITU-T G.726-32.
The primary reason for transcoding configurations is to configure the capabilities of external media transcoding devices when these devices cannot be discovered automatically. In-band auto discovery of transcoder capabilities is currently not supported. Therefore, this step must be done when configuring all connections to all current remote transcoding devices.
![](/c/dam/en/us/td/i/templates/note.gif)
Note Transcoding configurations can be skipped altogether if the described reason does not apply.
Media gateways are allowed to connect whether or not configuration has been supplied for them. To help avoid configuration errors, the signaling border element (SBE) logs a warning if an incoming connection is received from a media gateway that is not a data border element (DBE) and does not have transcoding configured.
![](/c/dam/en/us/td/i/templates/note.gif)
Note The Transcoding feature is supported in the unified model for Cisco IOS XE Release 2.5 and later.
Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).
For a complete description of the commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at:
http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html .
For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
Feature History for Implementing SBC Transcoding
Contents
This chapter contains the following sections:
- Prerequisites for Implementing Transcoding
- Restrictions for Implementing Transcoding
- Restrictions for Media Gateway-Assisted DMTF Interworking
- Information About Transcoding
- Configuration Examples for Implementing Transcoding
- Verification
- Voice Transcoding Per Adjacency Statistics
- Configuring the Voice Transcoding Per Adjacency Statistics
- Media Gateway-Assisted DTMF Interworking
- Blended Transcoding
Prerequisites for Implementing Transcoding
The following prerequisites are required to implement SBC transcoding:
Restrictions for Implementing Transcoding
The following are restrictions of the Implementing Transcoding feature:
- The H.323 fast-start calls will be dropped to slow-start procedure if transcoding is required. This can be achieved by the callee side rejecting the fast-start request.
- No transcoding support for H.323 to SIP interworked calls.
- No transcoding support for H.323 to H.323 interworked calls.
- The only codecs supported for H.323 transcoding are G.711 (PCMU and PCMA) and G.729 (with and without annex B).
- When audio transcoding is in operation, the SBC does not support sending and receiving RFC 2833 in-band packets to and from the SBC and interworking RFC 2833 packets with out-of-band SIP INFO or SIP NOTIFY Relay messages on the other call leg.
The following are DTMF interworking restrictions when transcoding is used:
- Signaling and media DTMF interworking is not supported when transcoding is performed on the call
- When audio transcoding is in operation, the SBC does not support sending and receiving RFC 2833 in-band packets to and from the SBC and interworking RFC 2833 packets with out-of-band SIP INFO or SIP NOTIFY Relay messages on the other call leg.
Restrictions for Media Gateway-Assisted DMTF Interworking
Following are the restrictions of the Media Gateway-Assisted DMTF interworking feature:
- The SBC supports the use of transcoders, such as a Cisco MGX 8880, only in SIP-SIP calls. DTMF interworking with transcoders are not supported for H.323 calls.
- The SBC cannot interwork DTMF with transcoders that cannot pass through DTMF.
- When a Cisco MGX 8880 is not used as transcoders, only SIP-SIP calls are supported.
Information About Transcoding
Transcoding is the process of translating a media stream encoded using one codec into a media stream encoded using another codec. For example, translating a media stream encoded as PCMU into one encoded as G.726-32.
Transcoding is supported using external digital signal processor (DSP) hardware. A Cisco MGX 8880 Media Gateway can be used to provide the transcoding function for one or more SBCs.
The SBC supports two types of transcoding:
- Transcoding After Rejection
- Codec Filtering
- Configuring Transcoding After Rejection
- Configuring Codec Filtering Transcoding
Transcoding After Rejection
The SBC automatically brings the transcoding device into use for any call requiring transcoding between these codecs, as long as the Call Admission Control (CAC) policy configuration does not preclude the transcoder service from being supplied for the call. When a call that requires transcoding is set up, the SBE goes through the following steps:
- Receives an initial signaling request from the calling endpoint. This triggers the SBC to perform initial call setup on the incoming and outgoing local media termination points. The SBC then forwards the set up request towards the callee.
- Receives a response from the called endpoint that indicates that none of the codecs in the initial request are acceptable. These responses include:
– 415—Unsupported media type (SIP)
– 488—Not acceptable here (SIP)
– Failure to identify common codec during Terminal Capability Exchange procedure of H.245 protocol.
This triggers the SBC to bring a transcoder into the call that is inserted in the media path between the incoming and outgoing local media terminations. A new request is sent to the called endpoint, indicating the new codec type generated by the transcoder.
- SBE may then have to iterate through the list of codecs the transcoder supports until it finds one that is acceptable to the called endpoint. When this is done, the call is connected and media transmission begins.
Figure 40-1 shows where the transcoder sits in the network, and the path taken by the media in a transcoded call.
Figure 40-1 Transcoding Configuration
![](/c/dam/en/us/td/docs/i/200001-300000/270001-280000/277001-278000/277334.eps/_jcr_content/renditions/277334.jpg)
![](/c/dam/en/us/td/i/templates/note.gif)
Note Although Figure 40-1 shows two DBEs, transcoding is possible with a single DBE. With a single DBE, the media flows through the DBE twice, once on its way from the sending endpoint to the transcoder and a second time as it flows from the transcoder to the receiving endpoint.
For the Session Border Controller (SBC) to program the transcoder, it must be registered. The transcoding device acts as an H.248 media gateway, so it needs to be configured with the IP address and port of the SBE or SBC to connect to. The SBE or SBC acts as an H.248 Media Gateway Controller. See the documentation for your transcoder device for notes on how to do this. The documentation for the Cisco MGX 8880 Media Gateway can be found at:
http://www.cisco.com/en/US/docs/switches/wan/mgx/software/mgx_r5.0/data/configuration/guide/scg.html
In addition, the SBE must have the following specific configuration:
- An H.248 control address and port must be configured (using the sbe control address ipv4 and sbe control address h248 port commands). By default, this is on port 2944, and it is the address and port to which the transcoder must connect.
- An explicit media gateway needs to be configured (using the sbe media-gateway ipv4 command). The explicit media gateway must have its list of supported codecs defined so that the SBC knows which codecs the transcoder can translate between, and it must be identified as a transcoder (using the sbe media-gateway ipv4 codecs and sbe media-gateway ipv4 transcoder commands).
- The show sbc sbe media-gateway-associations command can be used to check that the transcoder has correctly registered with the SBE. If this has happened, the transcoder should appear in the list of known media gateways with an active association.
For configuration step information, see the “Configuring Transcoding After Rejection” section.
Troubleshooting Tip for Media-Timeout Transcoded Call Using a VXSM card
A Cisco MGX 8880 equipped with one or more Cisco Voice Switch Service Module (VXSM) card sets can operate as a media gateway. In a network where the SBC uses the Cisco MGX 8880 as a transcoding device to act as an H.248 media gateway, some additional configuration is required on the VXSM card for media-timeout to work properly in a transcoded call.
The following additional steps need to be configured on the VXSM card in the Cisco MGX 8880 Media Gateway:
Step 1 Enable the RTCP control with the following command.
Step 2 Set the RTCP timer control to startRtpOrRtcpPktRcvd with the following command:
Step 3 Verify that the settings are correct using the following command to show a list of DSP parameters:
For more information on the VXSM card, see the “VXSM as a Transcoding Gateway” chapter in the Cisco Voice Switch Service Module (VXSM) Configuration Guide Release 5.5 at: http://www.cisco.com/en/US/docs/switches/wan/mgx/software/mgx_r5.5/voice/vxsm/configuration/guide/config5.html
Codec Filtering
The SBC allows you to restrict which codecs a particular call, caller and callee are allowed to use by whitelisting certain codecs. Initially all recognized codecs are on the whitelist. If a codec is requested which is absent from the call, caller, or callee codec whitelist, then the call still proceeds, but the forbidden codecs are removed from the offer and media gate configuration.
By supporting caller and callee codec lists, the SBC is able to make more intelligent transcoding decisions. If the codec support of either the calling or the called endpoint is known, then setting the caller and/or callee lists in a CAC policy is appropriate. However it may be that other considerations, such as the source adjacency, will affect the codec decision, in which case the per-call codec list can still be used.
For example, if the caller and callee codec lists are set to 'A and B', then all calls would use codec A. However, if a call had come across a transit network X (as indicated by the source adjacency) that only supported codec B, then the user could have an extra policy matching on source adjacency X, setting the per-call codec list to B. Calls crossing network X would then be forced to use codec B.
You can also limit the minimum packetization period of each codec, by configuring a value for the lowest acceptable minimum packetization period for each permitted codec. If a session is requested with a packetization period below this limit, the call still proceeds, but SBC increases the packetization period to the configured minimum value.
For configuration step information, see the “Configuring Codec Filtering Transcoding” section.
Configuring Transcoding After Rejection
In this configuration area, the user supplies a configuration for a list of remote media gateways that may need to be managed by the SBE. This is not required when transcoding is not needed.
The primary reason for transcoding configurations is to configure the capabilities of external media transcoding devices when these devices cannot be discovered automatically. In-band auto-discovery of transcoder capabilities is currently not supported. Therefore, this step must be done when configuring all connections to all current remote transcoding devices.
![](/c/dam/en/us/td/i/templates/note.gif)
Note Transcoding configurations can be skipped if the described reason does not apply.
By default, media gateways are allowed to connect whether or not configuration has been supplied for them. To help avoid configuration errors, the SBE logs a warning if an incoming connection is received from a media gateway that is not a DBE and does not have transcoding configured.
The basic steps for implementing transcoding are as follows:
1. Configure the IP address, port, and transport protocol for H.248 media gateway controller on SBC. This step may not be required if the Media Gateway Controller has already been configured.
2. Configure the media gateway IP address.
3. Configure the codecs to be transcoded (for example, between ITU-T G.711 ulaw and ITU-T G.729A).
4. Specify the media gateway as a transcoder.
This task implements transcoding for SBC.
Once configured, the SBC automatically brings the transcoding device into use for any call requiring transcoding between the codecs as long as the call admission control (CAC) policy configuration does not preclude the transcoder service from being supplied for the call using the transcode-deny command (See the Configuring Call Admission Control Policy Sets, CAC Tables, and Global CAC Policy Sets section in the “Implementing Cisco Unified Border Element (SP Edition) Policies” module).
![](/c/dam/en/us/td/i/templates/note.gif)
Note In an H.323 adjacency configuration, you must use the h245-tunnel disable command for H.323 FastStart transcoded calls.
SUMMARY STEPS
4. control address h248 index index-number
7. transport [ transport-type ]
DETAILED STEPS
DETAILED STEPS
Configuration Examples for Implementing Transcoding
The example below is a configuration of transcoding after rejection.
Verification
Use the following show sbc sbe media-gateway-associations command to display a list of known media gateways with an active association and to verify the operation:
The following example shows the SBC and media communications.
Voice Transcoding Per Adjacency Statistics
The Voice Transcoding Per Adjacency Statistics feature provides the transcoding statistics to the user for voice calls at both global and adjacency levels. The feature analyzes the consumption of the cards, such as the DSP cards, that provide the transcoding functions.
The transcoding statistics include the following information:
- The number of active transcoding media stream for each codec pair over several summary periods at global and adjacency scopes. The statistic also provides a high water mark for the corresponding codec pair.
- The number of active transcoding calls both per-adjacency and globally are listed. The statistics can be listed both at global and adjacency scopes for the list of codec pairs.
- The statistics display the codec names for the following codecs, if the transcoding call uses any other codecs, the codec name is displayed as Other :
Configuring the Voice Transcoding Per Adjacency Statistics
This task shows how to configure the Voice Transcoding Per Adjacency Statistics feature, list the transcoding statistics as per the scope and summary period, and also reset the transcoding statistics.
SUMMARY STEPS
6. show sbc sbc-name sbe transcoding-stats { global | adjacency adjacency-name } { current15mins | current5mins | currentday | currenthour | current-indefinite | previous15mins | previous5mins | previousday | previoushour }
7. clear sbc sbc-name sbe transcoding-stats [ global | adjacency adjacency-name ] [ all | current-indefinite ]
DETAILED STEPS
The following example shows the output of the show sbc sbe transcoding-stats adjacency current15mins command:
Media Gateway-Assisted DTMF Interworking
The SBC enables inband DTMF interworking using media gateway switches such as the MGX 8880. A Cisco MGX 8880 is used with DTMF interworking in the following scenarios:
- As a transcoder—DTMF interworking between media plane and signaling is supported.
- As an inband DTMF extractor or injector.
The SBC supports two types of media plane DTMF:
- RFC2833 (telephone-event)
- Inband DTMF—DTMF inband audio stream, such as G.711. To support inband DTMF, MGX performs the following tasks:
– Reports or injects the DTMF signal into the voice band, and vice versa.
DTMF Interworking with MGX as Transcoder
When the SBC uses an external transcoder, such as MGX, DTMF interworking is supported for the following:
Inband DTMF Support—Interworking Without a Transcoder
The SBC supports a call or adjacency policy to indicate when an inband DTMF tone is monitored. Monitoring an inband DTMF tone can either be forced, or an optional task in the absence of any other DTMF support.
The SBC enables interworking between any two of the three supported DTMF formats, which include:
In the event of a failover, active calls using any DTMF interworking option are protected, and the interworking capability is retained on restoration.
The SBC provides a per-adjacency option to enforce an inband DTMF-compatible codec negotiation if no other methods are available for receiving or sending DTMF.
Configuring Inband DTMF Interworking
To configure inband DTMF interworking, perform the following steps.
![](/c/dam/en/us/td/i/templates/note.gif)
Note The caller and callee commands have been used in this procedure. In some scenarios, the branch command can be used as an alternative to the caller and callee command pair. The branch command has been introduced in Release 3.5.0. See the “Configuring Directed Nonlimiting CAC Policies” section for information about this command.
SUMMARY STEPS
4. cac-policy-set policy-set-id
8. table-type {policy-set | limit {list of limit tables}}
10. cac-scope {list of scope options }
11. callee inband-dtmf-mode {always | inherit | maybe | never}
12. caller inband-dtmf-mode {always | inherit | maybe | never}
14. active-call-policy-set policy-set-id
16. show sbc service-name sbe cac-policy-set id table name entry entry
DETAILED STEPS
Configuring Codecs to Support Inband DTMF
To configure the codecs to support inband DTMF, perform the following tasks:
SUMMARY STEPS
4. codec system system-name id
DETAILED STEPS
Blended Transcoding
The Blended Transcoding feature enables the SBC to establish sessions without transcoding.
Do not enable the Blended Transcoding feature in the following situations:
- When using H.323 or SIP-H.323 interworking calls
- When the calls are under transcoding video streams
- When the calls are in fax transcoding
The Blended Transcoding feature does not work with the following features:
- Media Bypass
- H.323 Calls and SIP-H.323 Interworking
- Late-Early Interworking
- Downstream Forking with Codec Change
- Local Call Transfer
- IMS (Gq and Rx)
Before you enable the Blended Transcoding feature, make sure that the DSP farm codec is already configured. For more information about the DSP farm codec configuration, see the Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model at:
http://www.cisco.com/en/US/partner/docs/routers/asr1000/configuration/guide/sbcu/sbc_spadsp.html#wp1157164
Enabling Blended Transcoding
To enable the Blended Transcoding feature, perform the following steps: