VoIP

TranslatorX – Analyzer for Cisco Voice Debugs and Traces

TranslatorX is a very nice and simpre tool that allows you to parse and browse through text debug/trace outputs. It works with CUCM Trace outputs and Call Detail Records as well as SIP, H.323, MGCP and Q.931 debugs from Voice Gateways.

Here is an example of TXT-file with debug ccsip messages opened with the tool:

TranslatorXSIP1

Based on this it can present you a call flow ladder:

TranslatorXSIP2

Here is an example for Q.931 debug:

Q931Msg1

Q931Msg2

Different colors here mean different calls.

By clicking on message string or arrow in the diagram you get the message text:

Q931Msg3

More info and download on www.translatorx.org

Transcoding on Cisco Unified Border Element

Previously to use hardware (PVDM-based) transcoding you needed to register DSPFarm on CUCM or CME. But what if you don’t use any of these call control platforms, just have a router working as CUBE and want to accept one call leg and set up another with a codec different from originating? Starting with CUBE 9.0 Cisco has introduced Local Transcoding Interface (LTI) feature that permits you to register transcoding DSPFarm profile on CUBE itself.

CUBE version is mapped to IOS version, some information on version correspondence can be found here. The exact CUBE version on your router can be verified with show cube status command.

The call flow I used to test the feature is the following:

SIPCallFlow

Here is a configuration example:

voice-card 0
dsp services dspfarmdspfarm profile 1 transcode universal
codec g729r8
codec g729br8
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 4
associate application CUBE <--- this command makes the profile to register and interact with CUBE
no shutdown <--- Don't forget this, the profile is shutdown by default 

First, checking that DSPFarm profile has registered successfully:

#show dspfarm profile
Dspfarm Profile ConfigurationProfile ID = 1, Service =Universal TRANSCODING, Resource ID = 1
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 4
Number of Resources Out of Service : 0
Number of Resources Active : 0
Codec Configuration: num_of_codecs:6
Codec : g729r8, Maximum Packetization Period : 60
Codec : g729br8, Maximum Packetization Period : 60
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60

Then trying to establish the call.

Verification

After the remote party answered the call, we can see RTP streams for both call legs up:

#sh voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 2
Port range not configured, Min: 16384, Max: 32767Ports Ports Ports
Media-Address Range Available Reserved In-useDefault Address-Range 8091 101 2VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 510647 510648 17882 10012 X.X.X.6 X.X.X.1
2 510648 510647 17884 12818 Y.Y.Y.68 Y.Y.Y.147
Found 2 active RTP connections

It doesn’t tell us though which codec both call legs are using. Show call active voice command does that:

#show call active voice brief

Telephony call-legs: 0
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
2CD9 : 510647 307788128ms.1 () +16290 pid:520 Answer 3309 active
dur 00:00:36 tx:1831/292960 rx:1826/292160 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP X.X.X.1:10012 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off Transcoded: Yes
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a

2CD9 : 510648 307788138ms.1 () +16270 pid:521 Originate 3000 active
dur 00:00:36 tx:1825/36500 rx:1831/36620 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP Y.Y.Y.147:12818 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 TextRelay: off Transcoded: Yes
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a

Here are the active sessions on configured DSPFarm:

#show dspfarm all
Dspfarm Profile ConfigurationProfile ID = 1, Service =Universal TRANSCODING, Resource ID = 1
Profile Description :
Profile Service Mode : Non Secure
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : CUBE Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 4
Number of Resources Out of Service : 0
Number of Resources Active : 1
Codec Configuration: num_of_codecs:6
Codec : g729r8, Maximum Packetization Period : 60
Codec : g729br8, Maximum Packetization Period : 60
Codec : g711ulaw, Maximum Packetization Period : 30
Codec : g711alaw, Maximum Packetization Period : 30
Codec : g729ar8, Maximum Packetization Period : 60
Codec : g729abr8, Maximum Packetization Period : 60
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED0 1 33.1.0 UP 1 USED xcode 1 510648 799 807
0 1 33.1.0 UP 1 USED xcode 1 510647 804 797
0 1 33.1.0 UP N/A FREE xcode 1 - - -
0 1 33.1.0 UP N/A FREE xcode 1 - - -
0 1 33.1.0 UP N/A FREE xcode 1 - - -Total number of DSPFARM DSP channel(s) 4

Codec negotiation process

All the output below is taken using debug ccsip messages. Messages not related to codec negotiation are omitted.

First, CUBE receives SIP INVITE from Local IP PBX with SDP containing G.711 A-law and µ-law:

Received:
INVITE sip:3000@x.x.x.6 SIP/2.0
Via: SIP/2.0/UDP x.x.x.1:5060;branch=z9hG4bK23d6e61b;rport
From: "3309" <sip:3309@pbx.local>;tag=as3d61976b
To: <sip:3000@x.x.x.6>
Contact: <sip:3309@x.x.x.1>
Call-ID: 763b91d53953a6f118dda08347245740@pbx.local
CSeq: 102 INVITE
User-Agent: Local PBX
Max-Forwards: 70
Date:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 235
v=0
o=root 4037 4037 IN IP4 X.X.X.1
s=session
c=IN IP4 X.X.X.1
t=0 0
m=audio 10012 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

Then it resends the INVITE to Remote IP PBX proposing the same codecs:

Sent:
INVITE sip:3000@Y.Y.Y.147:5060 SIP/2.0
Via: SIP/2.0/UDP Y.Y.Y.68:5060;branch=z9hG4bK24310A3
Remote-Party-ID: "3309" <sip:3309@Y.Y.Y.68>;party=calling;screen=no;privacy=off
From: "3309" <sip:3309@Y.Y.Y.68>;tag=12587968-2B6
To: <sip:3000@Y.Y.Y.147>
Date: Fri, 08 Jan 2016 15:14:29 GMT
Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1490163159-3041989093-2599734236-3876816822
User-Agent: Cisco-SIPGateway
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1452266069
Contact: <sip:3309@Y.Y.Y.68:5060>
Call-Info: <sip:Y.Y.Y.68:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 289v=0
o=CiscoSystemsSIP-GW-UserAgent 3992 8898 IN IP4 Y.Y.Y.68
s=SIP Call
c=IN IP4 Y.Y.Y.68
t=0 0
m=audio 17884 RTP/AVP 8 0 101 19
c=IN IP4 Y.Y.Y.68
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000

The Remote PBX responds with an error message:

Received:
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP Y.Y.Y.68:5060;branch=z9hG4bK24310A3;received=Y.Y.Y.68
From: "3309" <sip:3309@Y.Y.Y.68>;tag=12587968-2B6
To: <sip:3000@Y.Y.Y.147>;tag=as55df16aa
Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68
CSeq: 101 INVITE
Server: Remote PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

The response means that some media capability (we know it’s a codec) is not acceptable at the remote end. RFC3261 says this type of message MAY include a description of media capabilities that weren’t accepted so this could have told us what exactly the remote end didn’t like, but unfortunately in this case it doesn’t.

Anyway, CUBE sends another INVITE message, proposing G.729 codec:

Sent:
INVITE sip:3000@Y.Y.Y.147:5060 SIP/2.0
Via: SIP/2.0/UDPY.Y.Y.68:5060;branch=z9hG4bK244210D
Remote-Party-ID: "3309" <sip:3309@Y.Y.Y.68>;party=calling;screen=no;privacy=off
From: "3309" <sip:%239193093803@Y.Y.Y.68>;tag=12587AFC-2DC
To: <sip:3000@Y.Y.Y.147>
Date: Fri, 08 Jan 2016 15:14:29 GMT
Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1490163159-3041989093-2599734236-3876816822
User-Agent: Cisco-SIPGateway
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Timestamp: 1452266069
Contact: <sip:3309@Y.Y.Y.68:5060>
Call-Info: <sip:Y.Y.Y.68:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 337v=0
o=CiscoSystemsSIP-GW-UserAgent 3992 8899 IN IP4 Y.Y.Y.68
s=SIP Call
c=IN IP4 Y.Y.Y.68
t=0 0
m=audio 17884 RTP/AVP 8 0 18 101 19
c=IN IP4 Y.Y.Y.68
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000

which remote PBX accepts sending an OK response with acceptable media capabilities list including G.729. This actually happens when remote user picks up the phone. Here is the message:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP Y.Y.Y.68:5060;branch=z9hG4bK244210D;received=Y.Y.Y.68From: "3309" <sip:3309@Y.Y.Y.68>;tag=12587AFC-2DC
To: <sip:3000@Y.Y.Y.147>;tag=as25e69ab7
Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68
CSeq: 102 INVITE
Server: Remote PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:3000@Y.Y.Y.147:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 263v=0
o=root 1736022661 1736022661 IN IP4 Y.Y.Y.147
s=Asterisk PBX 11.14.2
c=IN IP4 Y.Y.Y.147
t=0 0
m=audio 12818 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

The call proceeds with two legs using different codecs as expected.

The whole flow looks the following way (Red bars mark messages listed above, the ones containing codecs information):

CallDiagram

An error 488 Not acceptable here could be avoided by changing the outgoing dial-peer configuration. CUBE proposes G.711 codecs first because of the voice-class applied to its outgoing dial-peer. This voice-class lists the codecs with the following preference order:

voice class codec 3
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
codec preference 4 g729br8

Changing the priority or leaving just G.729 will do the trick.