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 0dsp services dspfarmdspfarm profile 1 transcode universalcodec g729r8codec g729br8codec g711ulawcodec g711alawcodec g729ar8codec g729abr8maximum sessions 4associate application CUBE <--- this command makes the profile to register and interact with CUBEno shutdown <--- Don't forget this, the profile is shutdown by default |
First, checking that DSPFarm profile has registered successfully:
#show dspfarm profileDspfarm 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: 2Port 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
|
Here are the active sessions on configured DSPFarm:
#show dspfarm allDspfarm 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 : 60SLOT 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:v=0o=root 4037 4037 IN IP4 X.X.X.1s=sessionc=IN IP4 X.X.X.1t=0 0m=audio 10012 RTP/AVP 8 0 101a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20a=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.0Via: SIP/2.0/UDP Y.Y.Y.68:5060;branch=z9hG4bK24310A3Remote-Party-ID: "3309" <sip:3309@Y.Y.Y.68>;party=calling;screen=no;privacy=offFrom: "3309" <sip:3309@Y.Y.Y.68>;tag=12587968-2B6To: <sip:3000@Y.Y.Y.147>Date: Fri, 08 Jan 2016 15:14:29 GMTCall-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68Supported: 100rel,timer,resource-priority,replaces,sdp-anatMin-SE: 1800Cisco-Guid: 1490163159-3041989093-2599734236-3876816822User-Agent: Cisco-SIPGatewayAllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTERCSeq: 101 INVITETimestamp: 1452266069Contact: <sip:3309@Y.Y.Y.68:5060>Call-Info: <sip:Y.Y.Y.68:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"Expires: 180Allow-Events: telephone-eventMax-Forwards: 69Content-Type: application/sdpContent-Disposition: session;handling=requiredContent-Length: 289v=0o=CiscoSystemsSIP-GW-UserAgent 3992 8898 IN IP4 Y.Y.Y.68s=SIP Callc=IN IP4 Y.Y.Y.68t=0 0m=audio 17884 RTP/AVP 8 0 101 19c=IN IP4 Y.Y.Y.68a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=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.0Via: SIP/2.0/UDPY.Y.Y.68:5060;branch=z9hG4bK244210DRemote-Party-ID: "3309" <sip:3309@Y.Y.Y.68>;party=calling;screen=no;privacy=offFrom: "3309" <sip:%239193093803@Y.Y.Y.68>;tag=12587AFC-2DCTo: <sip:3000@Y.Y.Y.147>Date: Fri, 08 Jan 2016 15:14:29 GMTCall-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68Supported: 100rel,timer,resource-priority,replaces,sdp-anatMin-SE: 1800Cisco-Guid: 1490163159-3041989093-2599734236-3876816822User-Agent: Cisco-SIPGatewayAllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTERCSeq: 102 INVITETimestamp: 1452266069Contact: <sip:3309@Y.Y.Y.68:5060>Call-Info: <sip:Y.Y.Y.68:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"Expires: 180Allow-Events: telephone-eventMax-Forwards: 69Content-Type: application/sdpContent-Disposition: session;handling=requiredContent-Length: 337v=0o=CiscoSystemsSIP-GW-UserAgent 3992 8899 IN IP4 Y.Y.Y.68s=SIP Callc=IN IP4 Y.Y.Y.68t=0 0m=audio 17884 RTP/AVP 8 0 18 101 19c=IN IP4 Y.Y.Y.68a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=yesa=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=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 OKVia: 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-2DCTo: <sip:3000@Y.Y.Y.147>;tag=as25e69ab7Call-ID: 58D34E27-B55111E5-9AFACBDC-E71387B6@Y.Y.Y.68CSeq: 102 INVITEServer: Remote PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGESupported: replaces, timerSession-Expires: 1800;refresher=uasContact: <sip:3000@Y.Y.Y.147:5060>Content-Type: application/sdpRequire: timerContent-Length: 263v=0o=root 1736022661 1736022661 IN IP4 Y.Y.Y.147s=Asterisk PBX 11.14.2c=IN IP4 Y.Y.Y.147t=0 0m=audio 12818 RTP/AVP 18 101a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:20a=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.