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.