INTRODUCTION
This document is to demonstrate how codec negotiation is done between calls involving CUBE, SIP Trunks, CUCM, IP Phones and Cisco Unity connection. In some scenarios a transcoder will be invoked and we shall look at why and how to properly design your network to know if you need a transcoder or not.
This will be based on a very practical approach as seen from a production environment. The call flow will be divided into different call scenarios and we will examine what codec is used for each call and if a transcoder is needed or not. Each of the call scenarios will also be discussed based on the direction of the call; Inbound or Outbound. This is because different rules apply depending on which direction the call originates and terminate.
The region settings involved in each of the call flow will also be considered as they play a key role in codec negotiation.
NB: Some of the call scenario use voice-class codec on the dial-peers. There is a general good practice on using voice-class codec on CUBE.
- for voice-class codec to work well on cube, ensure the codec preference and order is the same on both inbound and outbound dial-peer.
THE ENVIRONMENT
This environment is a cluster of 8 CUCM servers with four call processing servers (CUCM service activated), two Unity connection clustered servers and two CUBES
CUCM version: 8.6.2.21900-5
CUBE IOS version:c3900e-universalk9-mz.SPA.151-4.M4.bin
IP Phones: 7940 and 7960
Unity connection with Sip trunk Integration:8.6.2.21900-5
CUBE is configured with early offer forced; hence all traffic from CUBE goes out with advertised SDP.
Voice service voip
sip
early-offer forced
CUCM does delayed offer.
INBOUND CALLS
Lets start with inbound calls:
CALL SCENARIO 1, CALL FLOW
ITSP--------sip----------->CUBE--------sip----->CUCM----sccp---->IP Phone
SCENARIO 1------Inbound call to an IP Phone(no xcoder invoked)
++++Inbound dial-peer to CUBE++++
dial-peer voice 1 voip
modem passthrough nse codec g711ulaw
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
+++++Outbound dial-peer config to CUCM++++
dial-peer voice 50 voip
description Inbound calls to CUCM
translation-profile outgoing IN_PORT
destination-pattern 44T
modem passthrough nse codec g711ulaw
session protocol sipv2
session target ipv4:10.10.4.74
session transport tcp
dtmf-relay rtp-nte digit-drop h245-alphanumeric
voice-class codec 1
fax rate disable
Region between phone and cube is set to use G711. Inbound and outbound dial-peer set to use voice class codec with g729 as preferred codec
CALL ANALYSIS
1. Call arrives on CUBE and matched inbound DP=1 with voice-class codec set.
2. Call matches outbound dial-peer 50, voice-class codec set
3. When a voice-class is configured on a DP, the codec used will depend on the region setting between the source and the destination. Here, the source is cube (sip trunk), the destination is an IP Phone. Because the region setting between the CUBE and IP Phone is G711, the call will use G711. The region setting becomes the prevailing factor here. CUCM will send a 200 OK to the invite received from CUBE with the codec set between the endpoint and destination. In actual fact whatever the region setting between the IP phone and the CUBE is, that’s the codec that will be used. If its G729, then the call will use G729.
An abbreviated trace is shown below:
Cube receives invite from ITSP with early offer and all supported codecs
Received:
INVITE sip:441925573222@10.10.4.174:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <sip:078969786543@212.136.178.216:5060;user=phone>;tag=451687893-1338998863036-
To: " -SPK TestGrid"<sip:441925573222@pbx.testGridemea.globalipcom.com>
Content-Type: application/sdp
v=0
o=BroadWorks 161384816 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 15382 RTP/AVP 18 0 8 101-------------Advertised CODECS
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends invite to cucm with early offer and codecs matched on voice-class codec
Sent:
INVITE sip:901925573222@10.10.4.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F
Remote-Party-ID: <sip:078969786543@10.10.4.174>;party=calling;screen=no;privacy=off
From: <sip:078969786543@10.10.4.174>;tag=4C85AF62-DA1
To: <sip:901925573222@10.10.4.14>
User-Agent: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 10.10.4.174
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 16668 RTP/AVP 18 0 8 100 101--------->CUBE advertises Codec to CUCM
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
After a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint codec and IP.
Codec chosen based on the region between endpoint and CUBE sip trunk (CUBE-CUBE in this case)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F
From: <sip:078969786543@10.10.4.174>;tag=4C85AF62-DA1
To: <sip:901925573222@10.10.4.14>;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-
v=0
o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.10.4.14
s=SIP Call
c=IN IP4 10.54.117.13------••àRTP sent directly to IP Phone
t=0 0
m=audio 27770 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000---------------••àG711Ulaw selected to use for the call
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
A show voip rtp connection shows the flow of RTP stream for the two call legs
Sh voip rtp connection:
13 91498 91499 31298 23516 10.10.4.174 10.10.10.10 (ITSP-CUBE)
14 91499 91498 17432 25092 10.10.4.174 10.54.117.13 (CUBE to IP phone)
Scenario 2, Call Flow
ITSP--------sip----------->CUBE(1)--------sip----->CUCM---->Ip Phone
<---------------------G729-------------------------> (Reg btw IP phone-Cube)
SCENARIO 2------Inbound call to an IP Phone(xcoder invoked)
++++Inbound dial-peer to CUBE++++
dial-peer voice 1 voip
modem passthrough nse codec g711ulaw
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
+++++Outbound dial-peer config to CUCM++++
dial-peer voice 50 voip
description Inbound calls to CUCM
translation-profile outgoing IN_PORT
destination-pattern 44T
modem passthrough nse codec g711ulaw
session protocol sipv2
session target ipv4:10.10.4.74
session transport tcp
dtmf-relay rtp-nte digit-drop h245-alphanumeric
codec g711ulaw
fax rate disable
Region between phone and cube is set to use G729. Outbound dial-peer is hard coded to use g711ulaw
CALL ANALYSIS
1. Call arrives on CUBE and matched inbound DP=1 with voice-class codec set.
2. Call matches outbound dial-peer 50, codec set to G711ulaw
3. At this point regardless of the region setting between the ip phone and cube or sip trunk to the CUBE, G711u will be used. This is because the CUBE sends an early offer with only g711ulaw advertised. So CUCM is forced to send an ACK back with only g711u as the codec to use for the call. The region setting between the phone and cube will now determine if a xcoder is invoked or not. Since the region setting between the phone and CUBE is set to G729 in this case, a xcoder must be invoked and available otherwise the call will fail.
The two call legs look like this:
Callleg1=g711……..inbound call leg to CUBE (DP Is set to G711ulaw
Callleg2=G729…….outbound call leg to ip phone (region between phone and cube=g729).
In this case which I looked at, the system was not properly designed; hence there was no transcoder available for use in the MRGL of the cube.
NB: There was a transcoder in the MRG but the region between the CUBE and the transcoder was set to G729. Hence the CUBE couldn’t use it. CUCM however found a transcoder in the default MRGL which was an unassigned transcoder. The problem with this is, the system administrators had no idea that calls were been redirected to this transcoder. After a while users started reporting that calls come into their phone and they are unable to pick up. When they pickup the headset, calls don’t connect. This was because the remote transcoder in use didn’t have enough sessions on it to support the call traffic redirected to it. The system was not designed for this transcoder to be used; hence no one made such provisions.
This is why it’s crucial to design your system very well and to understand each element of your solution and how they interact.
An abbreviated trace is shown below:
Cube receives invite from ITSP with early offer and all supported codecs
Received:
INVITE sip:441925573222@10.10.4.174:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <sip:078969786543@212.136.178.216:5060;user=phone>;tag=451687893-1338998863036-
To: " -SPK TestGrid"<sip:441925573222@pbx.testGridemea.globalipcom.com>
Content-Type: application/sdp
v=0
o=BroadWorks 161384816 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 15382 RTP/AVP 18 0 8 101-------------Advertised CODECS
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends invite to cucm with early offer and G711 as the only advertised codec
Sent:
INVITE sip:901925573222@10.10.4.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F
Remote-Party-ID: <sip:078969786543@10.10.4.174>;party=calling;screen=no;privacy=off
From: <sip:078969786543@10.10.4.174>;tag=4C85AF62-DA1
To: <sip:901925573222@10.10.4.14>
User-Agent: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 10.10.4.174
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 16668 RTP/AVP 0 100101-------->CUBE advertises G711u Codec to CUCM
c=IN IP4 10.10.4.174
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
CUCM sends a 200 OK, agreeing on G711ulaw as the codec to use and the Xcoder IP for RTP streaming
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F
From: <sip:078969786543@10.10.4.174>;tag=4C85AF62-DA1
To: <sip:901925573222@10.10.4.14>;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-
v=0
o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.10.4.14
s=SIP Call
c=IN IP4 10.10.10.40------>RTP sent directly to Xcoder
t=0 0
m=audio 27770 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000--------------->G711Ulaw selected to use for the call
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
A show voip rtp connection shows the flow of RTP stream for the two call legs
- Show voip rtp conn on CUBE
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 175914 175915 17600 19092 10.10.4.174 10.10.10.10 (ITSP-->CUBE)
2 175915 175914 28214 29680 10.10.4.174 10.10.10.40 (CUBE--->Xcoder)
- Show sccp conn on transcoder
sess_id conn_id stype mode codec sport rport ripaddr
536967492 537049324 xcode sendrecv g729ab 31246 16384 10.24.14.79 (region to xcoder =g729)
536967492 537049323 xcode sendrecv g711u 29680 28214 10.10.4.174 (reg to xcoder=G711)—This is the device that invoked the xcoder
Scenario 3, Call Flow
ITSP--------sip----------->CUBE(1)--------sip----->CUCM---->IP Phone---CFWDall--->CUBE(2)----->ITSP
<----------------G729-------------------->(cubetoiphone=g729)
<------------------------------G729------------------------------------->(cubetocube=g729)
SCENARIO 3------CALL FORWARDING
Scenario 3, an inbound call comes to an IP phone via CUBE. The IP phone has a CFWdall set to a cell phone.
Configurations:
+++Voice-class codec++++
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711ulaw
codec preference 3 g711alaw
++++Inbound dial-peer to CUBE++++
dial-peer voice 1 voip
modem passthrough nse codec g711ulaw
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
+++++Outbound dial-peer config to CUCM++++
dial-peer voice 50 voip
description Inbound calls to CUCM
translation-profile outgoing IN_PORT
destination-pattern 44T
modem passthrough nse codec g711ulaw
session protocol sipv2
session target ipv4:10.10.4.74
session transport tcp
dtmf-relay rtp-nte digit-drop h245-alphanumeric
codec g711ulaw
fax rate disable
Region Settings between CUBE= G.729, region setting between cube and IP Phone=g729
CALL ANALYSIS
1. Call arrives on CUBE and matched DP=1 with voice-class codec set.
2. Call matches outbound dial-peer 50, codec set to G711ulaw
3. At this point regardless of the region setting between the ip phone and cube or sip trunk to the CUBE, G711u will be used. This is because the CUBE sends an early offer with only g711ulwa advertised. So CUCM is forced to send an ACK back with only g711u as the codec to use for the c all.
4. When the call arrived on ip phone, it was cfwdall to a cell, hence the call goes out via the same CUBE again (hairpinned)
5. Hence RTP connection is setup inbound to cube and outbound to cube. So in this case the second call leg of the call will be between CUBE-CUBE
Now the region setting between CUBE-CUBE=G729.
So we have a call flow like this:
Callleg1=g711
Callleg2=G729
Hence a xcoder is needed. The CUBE invokes a xcoder. If there is no transcoder available, then this call will fail.
Here is a trace for the call with only the relevant bits shown:
Invite received from ITSP with early offer and SDP capabilities
Received:
INVITE sip:441708659780@10.10.4.20:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKefn9r620a8p1h5dr1681.1
From: <sip:17086598000@212.136.178.216:5060;user=phone>;tag=286652269-1336598892064-
To: "solihull-SPK TestGrid"<sip:441708659780@pbx.testGridemea.globalipcom.com>
Content-Type: application/sdp
Content-Length: 207
v=0
o=BroadWorks 130097753 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 17652 RTP/AVP 18 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
Invite sent to CUCM with only G711u advertised
Sent:
INVITE sip:901708659780@10.10.4.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.4.20:5060;branch=z9hG4bK375566FA
Remote-Party-ID: <sip:17086598000@10.10.4.20>;party=calling;screen=no;privacy=off
From: <sip:17086598000@10.10.4.20>;tag=306F1686-1BE5
To: <sip:901708659780@10.10.4.14>
Date: Wed, 09 May 2012 21:28:12 GMT
Call-ID: B6C874A3-995411E1-973ED5AE-7283D592@10.10.4.20
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3066570383-2572423649-2537084334-1921242514
User-Agent: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP-GW-UserAgent 8398 8261 IN IP4 10.10.4.20
s=SIP Call
c=IN IP4 10.10.4.20
t=0 0
m=audio 29550 RTP/AVP 0 100 101
c=IN IP4 10.10.4.20
a=rtpmap:0 PCMU/8000-----------------••àG711Ulaw advertised
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
CUCM sends a 200 OK, agreeing on G711ulaw as the codec to use
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.4.20:5060;branch=z9hG4bK375566FA
From: <sip:17086598000@10.10.4.20>;tag=306F1686-1BE5
To: <sip:901708659780@10.10.4.14>;tag=189823~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477054169
Date: Wed, 09 May 2012 21:28:12 GMT
Call-ID: B6C874A3-995411E1-973ED5AE-7283D592@10.10.4.20
CSeq: 101 INVITE
Content-Type: application/sdp
Content-Length: 214
v=0
o=CiscoSystemsCCM-SIP 189823 1 IN IP4 10.10.4.14
s=SIP Call
c=IN IP4 10.10.10.40--------->àCUCM informs CUBE to send RTP to Transcoder
t=0 0
m=audio 17496 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000------------------>àG711ulaw accepted
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
So on the first call leg G711ulaw is used
Below is the Sh sccp connection on the Xcoder
Tag13=ITSP--->CUBE call leg
Tag14= CUBE--->Xcoder Call leg
Sh voip rtp connection:
13 91498 91499 31298 23516 10.10.4.174 10.10.10.10
14 91499 91498 17432 25092 10.10.4.174 10.10.10.40
Observe that the region between the IP phone and the CUBE does not even come into play here. This is because the call was diverted, hence no RTP stream is sent to the phone.It is the destination where RTP stream will be sent to that codec negotiation will be considered for
In this call setup, a xcoder at a remote site was used even though transcoder resources are configured on the CUBE and registered to CUCM.
This is because the region setting between the Xcoder and the CUBE were wrongly configured. Hence the CUBE found an available transcoder in the default MRGL. This is a very crucial part of your design. Ensure that:The region setting between a XCODER and the Device invoking it is G711.
sh sccp connections on the transcoder:
NB: that the codec section has two main distinctions
1. The leg that invokes a xcoder will always be G711
2. The other leg of the call will use whatever region setting is configured between it and the xcoder. So if its G711, you will see G711, if its G729, you will see G729.
sess_id conn_id stype mode codec sport rport ripaddr
536967470 469864467 xcode sendrecv g711u 32106 16882 10.10.4.174
536967470 469864466 xcode sendrecv g711u 25092 17432 10.10.4.174
We are seeing the CUBE ip here duplicated because this is a hairpinned call. The same CUBE is sending rtp connection to the xcoder.
SCENARIO 4
Scenario 4 is similar to scenario 3 but the region settings are different and we use voice class codec on the outbound dial-peer to CUCM.An inbound call comes to an IP phone via CUBE. The Ip phone has a CFWdall set to a cell phone.
ITSP------->CUBE--------->CUCM---->Ip Phone---CFWDall--->CUBE----->ITSP
<----------------G729-------------------->(cubetoiphone=g729)
<------------------------------G711------------------------------------->(cubetocube=g711)
Configurations:
+++Voice-class codec++++
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711ulaw
codec preference 3 g711alaw
++++Inbound dial-peer to CUBE++++
dial-peer voice 1 voip
modem passthrough nse codec g711ulaw
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
+++++Outbound dial-peer config to CUCM+++++
dial-peer voice 50 voip
description Inbound calls to CUCM
translation-profile outgoing IN_PORT
destination-pattern 44T
modem passthrough nse codec g711ulaw
session protocol sipv2
session target ipv4:10.10.4.74
session transport tcp
dtmf-relay rtp-nte digit-drop h245-alphanumeric
voice-class codec 1
fax rate disable
Region Settings between CUBE(s)= G.711, region setting between cube(s) and IP Phone=g729
CALL ANALYSIS
1. Call arrives on CUBE and matched inbound DP=1 with voice-class codec set.
2. Call matches outbound dial-peer 50, voice-class codec set
3. When a voice-class is configured on a DP, the codec used will depend on the region setting between the source and the destination. Here, the source is cube (sip trunk), the destination is another cube (or the same cube depends on which cube cucm chose for the outbound leg of thecall (we have two cubes in our environment). The region setting between the CUBES is G711, hence the call will use G711 all the way.
4. RTP connection is setup inbound to cube and outbound to cube. So in this case both call legs will look like this
Callleg1=g711---inbound call to cube
Callleg2=G711..outbound calleg to cube from cube
An abbreviated trace is shown below:
Cube receives invite from ITSP with early offer and all supported codecs
Received:
INVITE sip:441925573222@10.10.4.174:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <sip:078969786543@212.136.178.216:5060;user=phone>;tag=451687893-1338998863036-
To: " -SPK TestGrid"<sip:441925573222@pbx.testGridemea.globalipcom.com>
Content-Type: application/sdp
v=0
o=BroadWorks 161384816 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 15382 RTP/AVP 18 0 8 101-------------Advertised CODECS
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends invite to cucm with early offer and codecs matched on voice-class code
Sent:
INVITE sip:901925573222@10.10.4.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F
Remote-Party-ID: <sip:078969786543@10.10.4.174>;party=calling;screen=no;privacy=off
From: <sip:078969786543@10.10.4.174>;tag=4C85AF62-DA1
To: <sip:901925573222@10.10.4.14>
User-Agent: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 10.10.4.174
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 16668 RTP/AVP 18 0 8 100 101---------••àCUBE advertises Codec to CUCM
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
After a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint codec and IP.
Codec chosen based on the region between endpoint and CUBE sip trunk (CUBE-CUBE in this case)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F
From: <sip:078969786543@10.10.4.174>;tag=4C85AF62-DA1
To: <sip:901925573222@10.10.4.14>;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-
v=0
o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.10.4.14
s=SIP Call
c=IN IP4 10.10.4.174------>RTP sent directly to CUBE (no xcoder involved)
t=0 0
m=audio 27770 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000--------------->G711Ulaw selected to use for the call
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
In this call scenario we can see that no transcoder is involved because of the homogeneity of the codecs used.
SCENARIO 5, Call Flow
ITSP------------->CUBE---------->CUCM---->Ip Phone---CFWD--->UCXN
<----------------G729------------------->(cubetoiphone=g729)
<-----------------------------G711---------------------------------->(cubetocube=g711)
SCENARIO 5------CALL FORWARDING TO Voice Mail (Xcoder Invoked)
+++++=Calls forwarded to Unity connection from CUBE+++ using a xcoder
Configurations:
+++Voice-class codec++++
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711ulaw
codec preference 3 g711alaw
++++Inbound dial-peer to CUBE++++
dial-peer voice 1 voip
modem passthrough nse codec g711ulaw
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
+++++Outbound dial-peer config to CUCM++++
dial-peer voice 50 voip
description Inbound calls to CUCM
translation-profile outgoing IN_PORT
destination-pattern 44T
modem passthrough nse codec g711ulaw
session protocol sipv2
session target ipv4:10.10.4.74
session transport tcp
dtmf-relay rtp-nte digit-drop h245-alphanumeric
codec g711u
fax rate disable
CALL ANALYSIS
1. Call arrives on CUBE and matched DP=1 with voice-class codec set.
2. Call matches outbound dial-peer 50, codec set to G711ulaw
3. At this point regardless of the region setting between the ip phone and cube or sip trunk to the CUBE, G711u will be used. This is because the CUBE sends an early offer with only g711ulwa advertised. So CUCM is forced to send an ACK back with only g711u as the codec to use for the c all.
4. When the call arrived on ip phone, it was cfwd to voice mail,
5. Hence RTP connection is setup inbound to cube and outbound to unity connection. So in this case the second call leg of the call will be between CUBE->Unity connection
Now the region setting between CUBE-Unity Connection=G729.
So we have a call flow like this
Callleg1=g711
Callleg2=G729
Hence a xcoder is needed. The CUBE invokes a xcoder. If there is no transcoder available, then this call will fail.
- show sccp connections on transcoder:
sess_id conn_id stype mode codec sport rport ripaddr
536967470 469864467 xcode sendrecv g711u 32106 16882 10.10.4.70—UCXN Server
536967470 469864466 xcode sendrecv g711u 25092 17432 10.10.4.174------CUBE
- Show voip rtp connection on CUBE
13 91498 91499 31298 23516 10.10.4.174 10.10.10.10 (ITSP->CUBE)
14 91499 91498 17432 25092 10.10.4.174 10.10.10.40 (CUBE->Xcoder)
NB: This is a really bad design. You don’t want calls to unity connection using a transcoder. This is happening because the codec and region configurations were poorly done without the consideration of how they interact.
Now we have covered quite a few scenarios that are involved in our day to day call requirements on the inbound direction. Here is a quick recap
In summary, rule on dial-peer and region settings is this
- When voice-class codec is used, the codec set on the region between the calling device and called device wil be used. E.g Cube calling ip phone and region set to G729, G729 will be used.
- If the same call is forwarded, then the ff: will happen
- If the region between the calling CUBE/Gateway, and the gateway used to make the Forwarded call is set to g729, then G729 will be used.
- If the region set between calling gateway and the gw making forwarded call = G711, then G711 will be used
- If the DP=G711 hard coded, and the region between the gateways is G729, then a xcoder will be invoked. as explained above
- If DP=g729 and region between gateways is G711, then g729 will be used (it’s as if G711 can step down to G729)
Next lets look at Outbound Calls
OUTBOUND CALLS
IP phone----sccp----------->CUCM---------sip---------->CUBE--------sip----->ITSP
In the outbound direction...............
The advertised codec to ITSP will be used; because ITSP is the one making decision which codec to use based on advertised codec. So here with voice class codec, the preferred codec in the list will be selected by the ITSP and this will be used for the call regardless of what the region setting is on the phone to the cube gateway.
If the codec is hardcoded, if its set to g711, then g711 response will be obtained from the ITSP and that codec will be used for the call. If its g729 then it will be g729.
So the outbound leg is independent of the region settings because it is the far end that is choosing what codec to use for the call.
It is important to understand this so that you know that the region setting will not determine what codec will be used for your outbound call leg.
So if you want to choose a codec for your outbound leg, you have to either set it as preferred in your voice class list or hardcode it such that it is the codec been advertised as the preferred to your ITSP
Configurations:
+++Voice-class codec++++
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711ulaw
codec preference 3 g711alaw
++++Inbound dial-peer to CUBE++++
dial-peer voice 1 voip
modem passthrough nse codec g711ulaw
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
+++++Outbound dial-peer config to ITSP++++
dial-peer voice 100 voip
description Voice Calls To Verizon SIP Trunk
translation-profile outgoing OUT_PORT
destination-pattern .T
session protocol sipv2
session target sip-server
session transport udp
voice-class codec 1
voice-class sip profiles 2
dtmf-relay rtp-nte digit-drop h245-alphanumeric
fax rate disable
ip qos dscp cs3 signaling
no vad
Abbreviated trace below:
Invite sent to ITSP From CUBE
Sent:
From: "codec test" <sip:447777777777@10.10.4.174>;tag=4C8AB41A-1D46
To: <sip:5555555501@10.106.33.24>
Date: Wed, 06 Jun 2012 16:40:14 GMT
Call-ID: 1FD8C261-AF2D11E1-8E25FE93-B3867CA6@10.10.4.174
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Contact: <sip:447777777777@10.10.4.174:5060>
v=0
o=CiscoSystemsSIP-GW-UserAgent 6874 7727 IN IP4 10.10.4.174
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 21956 RTP/AVP 18 0 8 100 101----Codecs advertised in the order preferred
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
CUBE receives Session progress from ITSP
NB that the provider is only sending G729 back. (based on the preferred codec in our list)
Received:
SIP/2.0 183 Session Progress
v=0
o=BroadWorks 161411162 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 18758 RTP/AVP 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends 183 to CUCM with G729
Sent:
SIP/2.0 183 Session Progress
v=0
o=CiscoSystemsSIP-GW-UserAgent 2278 8254 IN IP4 10.10.4.174
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 29694 RTP/AVP 18 100 101
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
We received 200 ok from ITSP
Received:
SIP/2.0 200 OK
v=0
o=BroadWorks 161411162 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 18758 RTP/AVP 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends 200 OK to CUCM with only G729 advertised
sent:
SIP/2.0 200 OK
v=0
o=CiscoSystemsSIP-GW-UserAgent 2278 8254 IN IP4 10.10.4.174
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 29694 RTP/AVP 18 100 101
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
And the most important part cucm sends ACK with SDP with endpoint codec and IP
NB: Even though the region between ip phone and Cube was set to G711, cucm sends ACK with G729.
Received:
ACK sip:55555555555@10.10.4.174:5060 SIP/2.0
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp
v=0
o=CiscoSystemsCCM-SIP 812149 1 IN IP4 10.11.11.10
s=SIP Call
c=IN IP4 10.50.17.20
t=0 0
m=audio 28170 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
SUMMARY/CONCLUSION
Finally, Summarising both call scenario,
In both cases the codec selected by the far end will determine what codec is used for the call.
- Inbound leg, far end is CUCM, region takes effect
- Outbound leg, far end is ITSP, prefered codec in advertised codec will take effect. Simples!
