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:
Here is a configuration example:
voice-card 0 dsp services dspfarm dspfarm 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 Configuration Profile 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: 32767 Ports Ports Ports Media-Address Range Available Reserved In-use Default Address-Range 8091 101 2 VoIP 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
|
Here are the active sessions on configured DSPFarm:
#show dspfarm all Dspfarm Profile Configuration Profile 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_RXED 0 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: 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: 289 v=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: |
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: 337 v=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.68 From: "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: 263 v=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):
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.