Dial-peer Codec Selection, CUCM Region Settings And Transcoders IN A SIP Deployment

Document

Jul 19, 2012 8:42 AM
Jul 19th, 2012

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!
Average Rating: 0 (0 ratings)

Comments

Actions

Login or Register to take actions

This Document

Posted July 19, 2012 at 8:42 AM
Stats:
Comments:1 Avg. Rating:0
Views:7344 Contributors:1
Shares:3

Related Content

Documents Leaderboard