Cisco Voice Switch Service Module (VXSM) Configuration Guide Release 5.5
VXSM as a Transcoding Gateway
Downloads: This chapterpdf (PDF - 407.0KB) The complete bookPDF (PDF - 3.04MB) | Feedback

VXSM as a Transcoding Gateway

Table Of Contents

VXSM as a Transcoding Gateway

Considerations and Limitations

Information About VXSM Transcoding

Transcoding Support

Codec Templates

Voiceband Data Support

T.38 Support

Dual-tone Multifrequency Relay

Configuring Transcoding Resources


VXSM as a Transcoding Gateway


This chapter describes VXSM application as a transcoding gateway in a Cisco MGX 8880 or Cisco MGX 8850.

Transcoding compresses and decompresses voice streams to match endpoint-device capabilities. Transcoding is required when an incoming voice stream is digitized and compressed (by means of a codec) to save bandwidth, but the local device does not support that type of compression.

VXSM transcoding employs a general transcoding facility, where one supported codec is converted to any other supported codec. This functionality interconnects a diverse array of topologies. VXSM transcoding works between two voice sessions that are encoded by using different codecs, different packetization periods, or a combination of the two. The VXSM transcoding channel operates only on IP terminations.

VXSM supports transcoding for an incoming voice stream with the following bearer properties:

Codec

Packetization period

VAD

DTMF relay


Note If the bearer properties of an incoming voice stream is the same then the call is established in fast routing, normal, or transparent mode.


Although VXSM transcoding allows interconnection between endpoints that encode voice by using different codec algorithms, transcoding causes distortion of the voice and reduces the quality of the received signal. VXSM transcoding causes the voice signal to be encoded and decoded two times. Each time that a voice signal is encoded and decoded, distortion is added and the listening quality is reduced. Additionally, transcoding adds additional dejitter delays to the voice path.

Considerations and Limitations

This sections lists the considerations and limitations in configuring VXSM transcoding:

For voice calls established in fast-routing mode, VBD in the non-NSE mode is not supported.

For a voice calls established in the fast-routing mode, DTMF relay is supported, whereas DTMF detection is not supported.

For a VBD call established in fast-routing mode, reverting the call to voice mode is not supported.

For a T.38 call established in transparent mode, the fallback mechanism to pass through from a T.38 session is not supported. Similarly, reverting to voice mode after completion of a fax is not supported.

Negotiation of the codec and packetization period for VBD is not supported.

VXSM supports NTEs (0-15); all other NTEs are ignored by the interconnected CPE or MGW.

DTMF interworking in fast-routing mode is not supported.

Information About VXSM Transcoding

To configure transcoding support, you should understand the following concepts:

Transcoding Support

Configuring Transcoding Resources

Transcoding Support

VXSM as a transcoding gateway supports the following bearer properties for an incoming voice stream:

Codec Templates

Voiceband Data Support

T.38 Support

Dual-tone Multifrequency Relay

Codec Templates

VXSM transcoding supports four codec templates. For more information, see VXSM Codec Templates, page 2-7.

Voiceband Data Support

VXSM supports Voiceband Data (VBD) calls on IP-IP connections. When a VBD call on IP-IP connections is created with the same codec, VAD, and packetization period at each end of the bearer leg, then the connection can be established in either fast-routing mode or normal mode. VXSM supports G.711 A, G.711 U, G.726-32, and Clear Channel codecs.

VXSMs that function as transcoding gateways can be configured to support VBD calls. The requirements include:

VBD - T.38 Negotiations—VXSM supports NSE in conjunction with H.248 for VBD calls. For call negotiation, the mechanism for exchanging the NSE payload type is configured, which determines the payload type to be used for the NSEs. For more information, see H.248 Support for Named Signaling Events (NSEs), page 2-24.

Table 7-1 describes scenarios under which VXSM switches to VBD or T.38 mode.

When negotiating SDP parameters, VXSM ensures that the value of the NSE payload type is not the same as voice codecs or NTE. VXSM disables NSE functionality if NSE is not received in remote SDP.


Note VXSM uses dynamic payload type as the range for negotiating NSE.


Table 7-1 NSE and Non-NSE Interworking Scenarios

Scenario
Action
Switch to VBD or T.38 mode

Both legs support NSE

Call will switch to VBD/T.38

Yes

First leg supports NSE and the other does not.

NSE is received from the first call leg.

SDP for the first call leg is acknowledged with support for NSE.

SDP for the second call leg is acknowledged but does not contain NSE parameters.

No

First leg does not send NSE, and other IP leg sends NSE-related parameters.

SDPs for both the legs are acknowledged but do not contain NSE parameters.

No


VBD in NSE mode—An IP-IP connection on detecting an NSE on one of the IP legs switches both the IP terminations to VBD codec in normal or fast-routing mode (depending on the codec configuration on the gateway).

VBD in non NSE mode—An IP-IP connection relies on the IP side for tone detection. Voice calls set in this mode uses low-complexity codecs such as G.711A, G.711U or G.726. On detecting a tone, the remote gateway switches to VBD mode and transfers the VBD packets to the IP leg. On detecting a tone from the IP side, the IP leg switches both the IP terminations to VBD codec in normal or fast-routing mode (depending on the codec configuration on the gateway).

If bidirectional silence is detected, the terminating gateway switches to voice mode, but the VXSM transcoding gateway continues to be in VBD mode. The packets received at the IP leg are dropped due to payload type violation.


Note Bidirectional silence is detected only on the TDM side.


CA controlled VBD—Upon detection of a CED tone, the remote gateway sends a notification message to the call agent and switches to VBD mode. The call agent sends a MODIFY message to the IP legs of the transcoding gateway to switch to the VBD codec.

T.38 Support

VXSM transcoding supports T.38 calls on the IP-IP terminations. The T.38 calls are supported on NSE and CA controlled mode. To support T.38 calls on the VXSM transcoding gateway, image type, transport type, and packetization period are considered.

If the bearer properties of the T.38 calls are same on both the legs of IP-IP connection, then the call is established as an IP-IP UDPTL T.38 fax call.

T.38 - NSE support—VXSM supports NSE in conjunction with H.248 for T.38 calls. For call negotiation, the mechanism for exchanging the NSE payload type is configured, which determines the payload type to be used for the NSE events. For more information, see H.248 Support for Named Signaling Events (NSEs), page 2-24.

An IP-IP connection on detecting a NSE event on one of the IP leg, switches both the IP terminations to UDPTL T.38 in transparent mode. On completion of a fax transmission, terminating gateway switches to voice mode. The VXSM transcoding gateway continues to be in UDPTL transparent mode, resulting in voice packets being dropped at the terminating gateway.

CA Controlled Fax SDP parameters—To support a fax call in UDPTL transparent mode, the SDP message should contain the same T.38 parameters on both the IP legs. CA negotiates T.38 parameters end to end, before transferring the T.38 parameters to the transcoding gateway.

If a transcoding call is established in voice or VBD mode, the terminating gateway, upon detecting a V.21 preamble, sends a notification message to the call agent. The CA sends a MODIFY message to the IP legs of the transcoding gateway and the terminating gateways to switch to T.38 mode.

Dual-tone Multifrequency Relay

Dual tone multifrequency (DTMF) tones are generated, compressed, and transported to the other party, and then decompressed. If a low-bandwidth codec, such as G.729 or G.723, is used without a DTMF relay method, the tone may be distorted during compression and decompression.

In a transcoding gateway, if two networks have different ways of transmitting digits, the digits are translated to one kind.

Table 7-2 summarizes the DTMF interworking scenarios and the transcoding conversions.

Table 7-2 DTMF Interworking Scenarios

DTMF Interworking
Transcoding Conversions

InBand - InBand

The RTP termination on the transcoding gateway receives the digit from the IP side. The digits are processed by the DSP. On the other RTP termination the digits are packetized and encoded with the configured codec before transferring to the terminating gateway.

Note If different codecs are configured on the gateways, then codec conversion takes place.

Note If the IP leg uses a low bit-rate codec, then the digits may be distorted.

InBand - DTMF

The transcoding gateway receives the digit in the form of RTP voice packets from the IP side. The voice packets are converted into linear samples. They are transferred as NTE packets to the other end. For information on NTE, see H.248 Support for Named Telephone Events, page 2-24.

DTMF - InBand

The transcoding gateway receives the NTE packet. The digits are extracted from the NTE payload and passed on to the DSP channel associated with the second RTP termination. The digits are transferred as RTP packets to the other end.

DTMF - DTMF with different codecs

VXSM supports NTE negotiations for different codecs on the end gateway and the transcoding gateway. For information on NTE, see H.248 Support for Named Telephone Events, page 2-24.

The digits extracted from the NTE packets are converted to linear samples and are transferred to the other end. The RTP termination converts the linear samples to NTE packet with negotiated NTE payload.


Configuring Transcoding Resources

VXSM transcoding parameters are set as part of the default settings on the IP-IP terminations. The parameters are applied by specifying the particular profile when IP-IP connections are created using the cnfdspparam command (see Configuring H.248 Transparent RTP IP-IP Connections, page 3-31). When VXSM operates in the transcoding mode, the selected profile largely determines the processing that the DSPs perform on the voice payload.

VXSM trancoding configuration consists of:

Configuring different Transcoding modes

Configuring voice quality parameters for IP-IP terminations

Configuring Fax and Modem Services

Configuring voice connection

Associating fax profile with RTP termination

To set up VXSM transcoding, use the following procedure.


Step 1 Use the cnfdspparam command to configure the voice connection. Use the dspdspparam command to display the default values.

The syntax of the cnfdspparam command is:

cnfdspparam [-ptype <PayloadType>][-control <RTCPControl>][-interval <RTCPTxInterval>] [-multi <RTCPRxMultiplier>][-vadapt <VADAdaptive>] [-plc <Packet Loss Concealment>][-dtmfpl <DTMFPowerLevel>] [-dtmfpt <DTMF Power Twist>][-rtcptm <RTCP Timer Control>] [-vqm <VQM Control>][-xrcontrol <RTCPXR Control>] [-xrmulti <RTCPXR Report Freq.>][-gmin <VQM default minimum gap>] [-rext <RTCPXR ext. R factor>][-sest <SES Threshold>] [-ipip <IPIP mode for voice calls>]

For [-ipip <IP-IP mode for voice calls>], enter 1 for normal(default) mode, 2 for fastRoute mode, or 3 for transparent mode.

Step 2 If any of the current values in the DSP profile for the IP-IP terminations on the transcoding gateway needs modification, use the cnfgwdsp command to make the changes. This command permits a set of values to be configured in the profile as follows:

cnfgwdsp -vad [-nm <NoiseMatching>][-so <SidOptions>] [-itusmtr <SidMinTxRate>][-smtr <SidMinTxRate>]

cnfgwdsp -vpb [-pt <PlayoutType>][-flc <FrameLossConcealment>] [-ct <ComfortNoiseType>][-cfl <ComfortNoiseFixedLvl>]

cnfgwdsp -g726enc [-en <Encoding>]

Step 3 VXSM automatically creates an event mapping table (index 1 for VoIP switching, index 11 for AAL2 trunking) that contains records for event mapping types and pointers to profiles. Use the dspeventmapping command to display the default values. For more information, see Configuring Fax and Modem Services, page 5-18

If the default values must be changed, use the appropriate cnfeventmapping command.

For fax or modem passthrough use

cnfeventmapping -ced<EventMappingIndex>[-htype <HandleType>]
[
-prof <ProfileIndex>] [-mode<HandleMode>]

For TTY passthrough use

cnfeventmapping -v18aTone<EventMappingIndex>[-htype <HandleType>]
[
-prof <ProfileIndex>] [-mode<HandleMode>]

For T.38 fax relay use

cnfeventmapping -v21Tone<EventMappingIndex>[-htype <HandleType>]
[
-prof <ProfileIndex>] [-mode<EventHandleMode>]

Step 4 Use the cnftermtype command to configure the fax profile id for the RTP termination. Use the dsptermtype command to display the default values.

The syntax of the cnftermtype command is:

cnftermtype -rtp <Index> <PackageIds> <ProfileId> <FaxProfileId>