Troubleshooting Transcoding

Cisco CME 3.2 introduces support for transcoding services. You need transcoding services when you have devices and applications in the network that don't support lower-bandwidth codecs, and you don't have enough bandwidth available in your network. In such a case, the devices that don't support lower-bandwidth codecs are colocated with a transcoding device that converts media streams of different codecs. This section discusses the configuration and troubleshooting of such transcoding devices.

Configuring Transcoding Services

One key example of a transcoding scenario is when Cisco UE terminates AA or voice mail calls that must be G.711. If these calls originate from other sites across your WAN, they likely use G.729 to conserve bandwidth. For such calls to divert successfully into Cisco UE, transcoding services are needed. Also, if Cisco CME has to establish a three-party conference in which one of the endpoints is on a G.729 gateway, a transcoder is needed to complete and mix the conference. This section discusses the configuration of a transcoding device for Cisco CME and how to troubleshoot issues relating to transcoding services.

Assume in the topology given earlier in Figure 18-6 that Cisco CME 2 has a high-density voice network module (NM-HDV2) with digital signal processors (DSPs) that can be configured for transcoding services. Example 18-29 shows such a configuration with the NM-HDV2 present in slot 4 of the Cisco CME 2 router.

Example 18-29. DSP Farm Configuration for Transcoding Services

CME2#show running-config
voice-card 4
 dspfarm
 dsp services dspfarm

The DSP farm (for transcoding services) has to register with Cisco CME. The DSP farm does not need to be physically present in the Cisco CME router chassis with which it is registered. It may be present in a separate PSTN gateway router chassis at the same site. In this example, however, the DSP farm is hosted on the Cisco CME router itself, which is a common deployment.

Example 18-30 shows the configuration required to register the DSP farm to Cisco CME 2. You have to identify an interface whose IP address can be used in media setup for the services. In Example 18-30, FastEthernet interface 0/0 is used. The Cisco CME IP address that this transcoding device registers with is also configured (192.168.0.1 in Example 18-30). A transcoding profile is created in which you mention all the codecs that should be transcoded. Several commands start with sccp, because the transcoding device uses SCCP to register with Cisco CME, and it is controlled by using SCCP.

Example 18-30. Configuration to Register the DSP Farm to a Cisco CME

CME2#show running-config
sccp local FastEthernet0/0 
sccp ccm 192.168.0.1 identifier 1 
sccp ip precedence 3
sccp
!
sccp ccm group 1 
 bind interface FastEthernet0/0
 associate ccm 1 priority 1
 associate profile 1 register mydsp1
!
dspfarm profile 1 transcode 
 codec g711ulaw
 codec g711alaw
 codec g729ar8
 codec g729r8
 codec g729br8
 maximum sessions 4
 associate application SCCP
......
telephony-service
 max-ephones 100
 max-dn 288
 ip source-address 192.168.0.1 port 2000
 system message Sopranos
 sdspfarm units 1 
 sdspfarm transcode sessions 4 
 create cnf-files version-stamp 7960 Apr 10 2004 15:27:09
 voicemail 6800
max-conferences 4
 web admin system name aesop password aesop
 transfer-system full-consult
 transfer-pattern 5...
 transfer-pattern 6...

After you enter this configuration, ensure that the transcoding device is registered with Cisco CME. Example 18-31 shows the output of the show sccp all command used to check the status of the transcoding device.

Example 18-31. Checking the Status of a Transcoding Device

CME2#show sccp all
SCCP Admin State: UP 
Gateway IP Address: 192.168.0.1, Port Number: 0
IP Precedence: 3
User Masked Codec list: None
Call Manager: 192.168.0.1, Port Number: 2000
 Priority: N/A, Version: 3.1, Identifier: 1

Transcoding Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 192.168.0.1, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 1
Reported Max Streams: 8, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30

SCCP Application Service(s) Statistics:

Profile ID: 1, Service Type: Transcoding 
TCP packets rx 114, tx 110
Unsupported pkts rx 1, Unrecognized pkts rx 0
Register tx 1, successful 1, rejected 0, failed 0
KeepAlive tx 103, successful 103, failed 0
OpenReceiveChannel rx 2, successful 2, failed 0
CloseReceiveChannel rx 2, successful 2, failed 0
StartMediaTransmission rx 2, successful 2, failed 0
StopMediaTransmission rx 2, successful 2, failed 0
Reset rx 0, successful 0, failed 0
MediaStreamingFailure rx 0
Switchover 0, Switchback 0

CCM Group Identifier: 1
Description: None
Binded Interface: FastEthernet0/0, IP Address: 192.168.0.1
Associated CCM Id: 1, Priority in this CCM Group: 1
Associated Profile: 1, Registration Name: mydsp1
Registration Retries: 3, Registration Timeout: 10 sec
Keepalive Retries: 3, Keepalive Timeout: 30 sec
CCM Connect Retries: 3, CCM Connect Interval: 10 sec
Switchover Method: GRACEFUL, Switchback Method: GRACEFUL_GUARD
Switchback Interval: 10 sec, Switchback Timeout: 7200 sec
Signaling DSCP value: default, Audio DSCP value: default

Total number of active session(s) 0, and connection(s) 0
Total number of active session(s) 0, and connection(s) 0
Total number of active session(s) 0, connection(s) 0, and callegs 0

SCCP Application Service(s) Statistics Summary:
Total Conferencing Sessions: 0, Connections: 0
Total Transcoding Sessions: 0, Connections: 0
Total MTP Sessions: 0, Connections: 0
Total SCCP Sessions: 0, Connections: 0

 

Debugging Transcoded Calls

Now that the transcoding device is successfully registered with a Cisco CME, this section covers how it is used in calls that require transcoding services. Assume that extension 6002 on Cisco CME 2 receives a call from the PSTN. This call uses the G.711 codec, as shown in Example 18-32.

Example 18-32. Call Between the PSTN and Extension 6002

CME2#show ephone offhook
ephone-90 Mac:0030.94C2.D2C6 TCP socket:[2] activeLine:1 REGISTERED
mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0
IP:19.19.19.2 49500 Telecaster 7960 keepalive 5 max_line 6
button 1: dn 62 number 6002 CH1 CONNECTED 
button 2: dn 64 number 6004 CH1 IDLE
Active Call on DN 62 chan 1 :6002 19.19.19.2 29146 to 1.4.13.29 2000 via
 19.19.19.2
G711Ulaw64k 160 bytes no vad 
Tx Pkts 225 bytes 38700 Rx Pkts 227 bytes 39044 Lost 0
Jitter 0 Latency 0 callingDn -1 calledDn -1 (media path callID 12 srcCallID 11)

Assume further that extension 6002 wants to conference in extension 8010 on Cisco CME 1 and that the configuration on Cisco CME 2 is such that calls to Cisco CME 1 use G.729. Setting up this conference requires transcoding from G.729 to G.711. At this point, Cisco CME recognizes that it must insert the transcoder in the media path for this call to succeed. Example 18-33 shows that the consult call before the conference uses G.729 between extension 6002 and extension 8010.

Example 18-33. Extension 6002 on Cisco CME 2 Calls 8010 on Cisco CME 1 for a Conference

CME2#debug ephone state
CME2#debug ephone mtp
Apr 11 15:34:22: ephone-90[2]:HoldButtonPress (allow_toggle = 0)
Apr 11 15:34:22: ephone-90[2]:HoldButtonPress HOLD activated for DN 62 chan 1
Apr 11 15:34:22: ephone-90[2]:SetCallState line 1 DN 62 chan 1 ref 3 TsHold
Apr 11 15:34:22: ephone-90[2]:CloseReceive
Apr 11 15:34:22: ephone-90[2]:StopMedia
Apr 11 15:34:22: ephone-90[2]:SpeakerPhoneOffHook mute 0
Apr 11 15:34:22: ephone-90[2]:OFFHOOK
Apr 11 15:34:22: ephone-90[2]:SIEZE on activeLine 2 activeChan 1
Apr 11 15:34:22: ephone-90[2]:SetCallState line 2 DN 64 chan 1 ref 5 TsOffHook
Apr 11 15:34:22: ephone-90[2]:Check Plar Number
Apr 11 15:34:22: DN 64 chan 1 Voice_Mode
Apr 11 15:34:22: dn_tone_control DN=64 chan 1 tonetype=33:DtInsideDialTone
 onoff=1 pid=159
Apr 11 15:34:24: dn_tone_control DN=64 chan 1 tonetype=0:DtSilence onoff=0
 pid=159
Apr 11 15:34:24: dn_tone_control DN=64 chan 1 tonetype=0:DtSilence onoff=0
 pid=159
Apr 11 15:34:26: 20
Apr 11 15:34:26: ephone-90[2]:SetCallState line 2 DN 64 chan 1 ref 5 TsProceed
Apr 11 15:34:26: ephone-90[2]:SetCallState line 2 DN 64 chan 1 ref 5 TsRingOut
Apr 11 15:34:26: ephone-90[2]::callingNumber 6004
Apr 11 15:34:26: ephone-90[2]::callingParty 6004
Apr 11 15:34:26: ephone-90[2]:Call Info DN 64 line 2 ref 5 called 8010
 calling 6004 origcalled 8010 calltype 2
Apr 11 15:34:26: ephone-90[2]:Call Info for chan 1
Apr 11 15:34:26: ephone-90[2]: No-Name calling
Apr 11 15:34:26: ephone-90[2]: No-Name
Apr 11 15:34:26: dn_tone_control DN=64 chan 1 tonetype=36:DtAlertingTone onoff=1
 pid=159
Apr 11 15:34:30: dn_tone_control DN=64 chan 1 tonetype=0:DtSilence onoff=0
 pid=159
Apr 11 15:34:30: DN 64 chan 1 End Voice_Mode
Apr 11 15:34:30: DN 64 chan 1 Voice_Mode
Apr 11 15:34:30: SKINNY_CALL_RESTART for DN 64 ignored
Apr 11 15:34:30: ephone-90[2]:OpenReceive DN 64 chan 1 codec 11:G729 duration
 20 ms bytes 20
Apr 11 15:34:30: ephone-90[2]:SetCallState line 2 DN 64 chan 1 ref 5 TsConnected
Apr 11 15:34:30: ephone-90[2]:OpenReceiveChannelAck:IP 19.19.19.2, port=17770,
 dn_index=64, dn=64, chan=1
Apr 11 15:34:30: ephone-90[2]:StartMedia 1.4.13.29 port=2000
Apr 11 15:34:30: DN 64 chan 1 codec 11:G729 duration 20 ms bytes 20
Apr 11 15:34:31: ephone-90[2]::callingNumber 6004
Apr 11 15:34:31: ephone-90[2]::callingParty 6004
Apr 11 15:34:31: ephone-90[2]:Call Info DN 64 line 2 ref 5 called 8010 calling
 6004 origcalled 8010 calltype 2
Apr 11 15:34:31: ephone-90[2]:Call Info for chan 1
Apr 11 15:34:31: ephone-90[2]: No-Name calling
Apr 11 15:34:31: ephone-90[2]: No-Name

After the consultation, extension 6002 decides to conference in all three parties. Cisco CME 2 now introduces the transcoding device. Example 18-34 shows that Cisco CME 2 instructs the transcoding device to open two RTP streams (using SCCP messages): one for G.729 and another for G.711. The messages that have MTP-1 in them go to the transcoding device. Note the IP addresses and RTP port numbers used in these messages. The IP addresses used for the transcoder are the same as that of the Cisco CME router, because the transcoding device is hosted in the Cisco CME router. You should see different IP addresses if the transcoder device is hosted in a separate router.

Example 18-34. Cisco CME 2 Inserts a Transcoder for the Conference

CME2#debug ephone state
CME2#debug ephone mtp
Apr 11 16:59:36: SkinnyXcodeGetStreamsForDn: dn=64, chan=1, codec=4, bytes=160
Apr 11 16:59:36: skinny_xcode_associate_stream: seize stream 3, confID=3, peer=4,
 far_end=0
Apr 11 16:59:36: skinny_xcode_associate_stream: seize stream 4, confID=3, peer=3,
 far_end=1
Apr 11 16:59:36: ***SkinnyResetDnCodec DN 64 chan 1 to skinny-codec 4 bytes 160
 was codec 11 ephone-(90)
Apr 11 16:59:36: ephone-90[2]:SkinnyResetDnCodec DN 64 chan 1 OpenReceiveAck
 already done
Apr 11 16:59:36: ephone-90[2][SEP003094C2D2C6]:SkinnyAssignConference line 2 conf
_dn 64 conf_chan 1
Apr 11 16:59:36: ephone-90[2]:SetCallState line 1 DN 62 chan 1 ref 1
 TsCallRemoteMultiline
Apr 11 16:59:36: ephone-90[2]:SkinnyAssignConference 0 OK with 1 active
Apr 11 16:59:36: ephone-90[2]:DN 62 chan 1 state changed to CONNECTED for
 conference with DN 64 chan 1 codec 4
Apr 11 16:59:36: ephone-90[2]:SetCallState line 2 DN 64 chan 1 ref 2 TsConnected
Apr 11 16:59:36: ephone-90[2]:SpeakerPhoneOffHook mute 0
Apr 11 16:59:36: skinny_xcode_open_receive_channel: stream=4, confID=3,
 pTPartyId=4
Apr 11 16:59:36: mtp=1, socket=1
Apr 11 16:59:36: MTP-1[1]:OpenReceive stream 4 codec 11:G729 duration 20 ms
bytes 20 
Apr 11 16:59:36: skinny_xcode_open_receive_channel: stream=3, confID=3, 
pTPartyId=3 
Apr 11 16:59:36: mtp=1, socket=1 
Apr 11 16:59:36: MTP-1[1]:OpenReceive stream 3 codec 4:G711Ulaw64k duration 20 ms 
bytes 160 
Apr 11 16:59:36: ephone-90[2]:CloseReceive
Apr 11 16:59:36: ephone-90[2]:StopMedia
Apr 11 16:59:36: ephone-90[2]:OpenReceive DN 64 chan 1 codec 4:G711Ulaw64k
 duration 20 ms bytes 160
Apr 11 16:59:36: MTP-1[1]: SkinnyXcodeOpenReceiveChannelAck: stream=4, 
addr=1.4.13.29 port=18918 laddr=1.4.13.29 lport=2000 
Apr 11 16:59:36: SkinnyXcodeStartMedia: stream=4, confID=3, pTPartyId=4 
Apr 11 16:59:36: MTP-1[1]:StartMedia 1.4.13.29 port=18918 
Apr 11 16:59:36: stream 4 codec 11:G729 duration 20 ms bytes 20 
Apr 11 16:59:36: MTP-1[1]: SkinnyXcodeOpenReceiveChannelAck: stream=3, 
addr=1.4.13.29 port=17834 laddr=1.4.13.29 lport=2000 
Apr 11 16:59:36: SkinnyXcodeStartMedia: stream=3, confID=3, pTPartyId=3 
Apr 11 16:59:36: MTP-1[1]:StartMedia 1.4.13.29 port=17834 
Apr 11 16:59:36: stream 3 codec 4:G711Ulaw64k duration 20 ms bytes 160 
Apr 11 16:59:36: ephone-90[2]:OpenReceiveChannelAck:IP 19.19.19.2, port=21848, 
 dn_index=64,dn=64, chan=1 
Apr 11 16:59:36: ephone-90[2]:StartMedia 1.4.13.29 port=2000
Apr 11 16:59:36: DN 64 chan 1 codec 4:G711Ulaw64k duration 20 ms bytes 160

At this point, the transcoder is successfully inserted into the conference, and all three parties are in the conversation.

You can use the commands shown in Example 18-35 to view the current transcoding sessions and the endpoints involved.

Example 18-35. Checking the Transcoding and RTP Sessions

CME2#show voip rtp connections
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 7 6 17652 18554 1.4.13.29 1.4.14.34
2 8 9 18918 2000 1.4.13.29 1.4.13.29
3 10 9 17834 2000 1.4.13.29 1.4.13.29
Found 3 active RTP connections

CME2#show sdspfarm sessions
Stream-ID:1 mtp:1 0.0.0.0 0 Local:0 IDLE
 usage: Ip-Ip (Res)
 codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:2

Stream-ID:2 mtp:1 0.0.0.0 0 Local:0 IDLE
 usage: Ip-Ip (Res)
 codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:1

Stream-ID:3 mtp:1 1.4.13.29 17834 Local:2000 START 
usage: Conf (DN=64 , CH=1) FE=FALSE 
codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:4 

Stream-ID:4 mtp:1 1.4.13.29 18918 Local:2000 START 
usage: Conf (DN=64 , CH=1) FE=TRUE 
codec:G729 duration:20 vad:0 peer Stream-ID:3 

Stream-ID:5 mtp:1 1.4.13.29 16722 Local:2000 START
 usage: Ip-Ip
 codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:6

Stream-ID:6 mtp:1 1.4.13.29 18550 Local:2000 START
 usage: Ip-Ip
 codec:G729AnnexA duration:20 vad:0 peer Stream-ID:5

Stream-ID:7 mtp:1 0.0.0.0 0 Local:0 IDLE
 usage:
 codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:0
Stream-ID:8 mtp:1 0.0.0.0 0 Local:0 IDLE
 usage:
 codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:0

The show voip rtp connections command shows the RTP streams established from the Cisco CME router to the other endpoints. This also includes the far-end Cisco CME router with an endpoint that is part of the conference. The show sdspfarm session command shows the RTP streams set up for transcoding purposes. This includes only the streams between the Cisco CME router and transcoding device.

Also note here the Usage field in the output of the show sdspfarm session command. In the first highlighted lines in Example 18-35, the Usage field says Conf, indicating that this transcoding is used for a conference session.

A few lines lower, you see a session where the Usage field is IP-IP. This means that this transcoding session is used for an IP-IP hairpinned call that Cisco CME has bridged and that the two call legs involved in the hairpin use different codecs. An example of such a scenario is a G.729 H.323 call coming from another PSTN gateway to Cisco UE. In this case, Cisco CME bridges the H.323 call from the PSTN gateway to the SIP call toward Cisco UE and introduces a transcoder. Another example is a call transfer from Cisco CME 2 to another PSTN gateway that does not support H450.2 and, hence, the call legs bridged by Cisco CME 2. The far-end PSTN gateway uses G.729 in this casehence, the need for a transcoder.

Troubleshooting H 323 GK Integration