This document describes how CVP (Cisco Voice Portal) call flow handle Mid Call Mixed Codec Change.
There are no specific requirements for this document.
Problem: Before CVP 8.(x) and IOS 15.1(2)T Transcoder Must be Used
In the old version of CVP eg. 7.(X), CVP deployment only supported flat codec through out the entire call flow, ie. from call queueing to agent answered calls, and agent subsequent transfers. Because VXML gateway only negotiate G711ulaw codec, that dictated the only codec supported in CVP deployment is G711ulaw. if the agent phones can only support G729 codec, eg in a multi-sites distributed environment, transcoders will have to be inserted between gateway/trunk and agent phones using Callmanager Region configuration, this will shield media update to reach CVP. From CVP's perspective, call is being delivered to an agent with G711ulaw codec.
When IP to IP gateway, or CUBE entered the market and replaced portion of PSTN gateway's functions, CUBE also brought in another variable to consider. ie. incoming call into CUBE ingress gateway may be using G729. eg. from a remote site. In this scenario, CUBE will have to have a local transcoder resource which is registered to a local CME telephony-service, and to force all calls entering CVP call flow with G711ulaw codec. Such a transcoder resource is enforced by matching between a incoming dial-peer which allows only G729 codec and the a outgoing dial-peer which allow only g711ulaw towards CVP. eg.
dial-peer voice 102 voip description incoming to CUBE service cvp-survivability session protocol sipv2 incoming called-number ^6128446...$ dtmf-relay rtp-nte no vad
dial-peer voice 201 voip description outgoing to central CVP1 translation-profile outgoing deprefix destination-pattern 61284466...$ session protocol sipv2 session target ipv4:10.201.198.234 codec g711ulaw voice-class sip rel1xx disable dtmf-relay rtp-nte no vad
With this type of CVP deployment with CUBE, 2 transcoder resources are consumed if the incoming call is g729, and the calls to reach agent phones are limited to g729 codec as well.
From CVP 8.(x) and upwards, as well as IOS version 15.1(2)T onwards, codec change is allowed in the mid cvp call, and CUBE allowed mixed codec listing.
CVP configuration guide and SRND guide gave some examples to implement such a CUBE feature. They can be summerized into following 2 steps.
Step 2. Apply the voice class codec list to the outbound dial-peer to CVP.
dial-peer voice 201 voip description outgoing to central CVP1 translation-profile outgoing deprefix destination-pattern 61284466...$ session protocol sipv2 session target ipv4:10.201.198.234 voice-class codec 1 voice-class sip rel1xx disable dtmf-relay rtp-nte no vad
Incoming dial-peer can maintain the original configuration based on whether the incoming call to reach CUBE is a G729 or G711 call
In theory, the CUBE feature should allow following call scenario.
Incoming G711 to CUBE --> outgoing codec from voice class code list from CUBE to CVP --> CVP invite VXML GW G711 --> CUBE allow media negotiation G711 to VXML g711 --> CVP invite call to reach agent phone region G729 via CUCM --> CUCM region configuration enforeced a transcode resource between CVP SIP trunk and agent phones.
Incoming G729 to CUBE --> outgoing codec from voice class code list from CUBE to CVP --> CVP invite VXML GW G711 --> CUBE invoke local transcoder resource to allow transcode from g729 to g711 vxmlgw --> CVP invite call to reach agent phone region G729 via CUCM --> CUBE drops the local transcode in the original call flow to reach vxmlgw --> CUBE allow media incoming call leg g729 and g729 to reach agent.
WIth this new mixed codec feature by CUBE, only 1 transcode is required in either call scenario, if the agent phones are limited with only G729 codec.
Problem Encountered During Testing
Set up a CVP lab with all SIP signallings. Tested both scenario mentioned above, but only scenario 1 went through successfully. scenario 2 failed at SENT to VRU.
Following analyses are used to demonstrate the SIP messages flow through the CUBE ingress gateway, and reveal the reason why the call worked and why the call scenario failed.
With the codec class configured in the outbound dial-peer towards CVP, it was expected the INVITE sent towards CVP with 2 codecs from the codec list.
Though the call worked in scenario 1, but the mixed codec feature in the CUBE was not confirmed. Call scenario 1 worked because the incoming call came in with codec g711ulaw, media was negotiated first on G711ulaw with VXML gateway, it was then upto callmanager to insert a preconfigured transcoder resource based on the regions before call was established with agent phones.
However, such a call would fail directly if the incoming call comes with G729 codec, because VXML gateway would reject the call with with media not found. The reason is CUBE only forwarded 1 codec from the allowed codec list.
VXML gateway shutdown the call due to media unavailable 488 error
Jun 19 23:55:00.429: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 488 Not Acceptable Media Via: SIP/2.0/TCP 10.201.198.234:5060;branch=z9hG4bKYQWOW8fAI+ImDxlBCuLJrA~~209 From: "--CVP_9_0_1_0_0_0_670" <sip:email@example.com:5060>;tag=ds86a9d8ef To: <sip:firstname.lastname@example.org;transport=tcp>;tag=43D5C50-136 Date: Thu, 19 Jun 2014 23:55:00 GMT Call-ID: F356B29DF74311E38066A2F4BE06D22Cemail@example.com CSeq: 1 INVITE Allow-Events: telephone-event Warning: 304 10.201.179.46 "Media Type(s) Unavailable" Reason: Q.850;cause=65 Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0
That was the reason why the call failed at SENT to VRU.
The idea was to let CUBE forward both codecs configured in the codec list on the outbound call dial-peer to CVP upon having received an invite from incoming dial-peer.
Further investigation and research indicated CUBE by default apply codec filter on the list. Following command has to be issued in the dial-peer in order for CUBE to present all of the codecs configured in the codec list.
eg. voice-class codec 1 offer-all
dial-peer voice 201 voip description outgoing to central CVP1 translation-profile outgoing deprefix destination-pattern 61284466...$ session protocol sipv2 session target ipv4:10.201.198.234 voice-class codec 1 offer-all voice-class sip rel1xx disable dtmf-relay rtp-nte no vad
CUBE received an invite with single codec in SDP g729r8
This allowed subsequent codec negotiation with VXML gw and allows CUBE invoking local transcoder.
The call was queued and connected with VXML gw. CUBE successfully invoked local transcode resource.
cubegw#sh voip rtp conn VoIP RTP active connections : No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP 1 388 389 17872 18056 10.201.198.250 10.201.182.137 2 389 388 19090 18316 10.201.198.250 10.201.179.46 3 390 391 17630 2000 10.201.198.250 10.201.198.250 4 392 391 19308 2000 10.201.198.250 10.201.198.250 Found 4 active RTP connections
cubegw#sh call active voice compa <callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp> Total call-legs: 4 388 ANS T68 g729r8 VOIP P61384461001 10.201.182.137:18056 389 ORG T68 g711ulaw VOIP P84466001 10.201.179.46:18316 390 ORG T68 g729r8 VOIP P 10.201.198.250:2000 392 ORG T68 g711ulaw VOIP P 10.201.198.250:2000
When the call got sent to Callmanager and connected with Agent Phone, CUBE successfully re-negotiated the codec and dropped transcoder, because the it was all G729r8 codec on both sides of CUBE.
cubegw#sh voip rtp connections VoIP RTP active connections : No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP 1 388 389 17872 18056 10.201.198.250 10.201.182.137 2 389 388 19090 24614 10.201.198.250 10.201.198.227 Found 2 active RTP connections
cubegw#sh call active voice comp <callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp> Total call-legs: 2 388 ANS T298 g729r8 VOIP P61384461001 10.201.182.137:18056 389 ORG T298 g729r8 VOIP P84466001 10.201.198.227:24614