H323-CUBE-SIP possible in GNS3 ?

[Yan Tian]

Hello all,

I have set up a voice lab with below topology

SCCP Extension (2001/ Mask: +14082022001)----CUCM 7.0---H323-----CUBE-----SIP------CUCME---SCCP Extension (6001/Mask: +861062286001)

However, when 2001 call 6001, 6001 only rings for 1 time, and 2001 hears busy tone.

debug voice ccapi inout on CUBE, call disconnect with cause value=47, no resource available.

debug ccsip message on CUBE, CUBE sends SIP CANCEL message after it receives SIP 180 Ringing without SDP.

Obviously, call disconnects because CUBE has no DSP to generate local ringback tone.

Even though we enable CUCME to send SIP 183 Session Progress, CUCME also needs DSP to generate early-media.

So, I conclude that GNS3 is not able to emulate H323-CUBE-SIP scenario due to inablility to emulate DSP.

Just want to double confirm with you experts here?

Thanks in advance.

[Yan Tian]

I have tried to change connection btween CUCM and CUBE from H323 to SIP,

CUCM---SIP---CUBE---SIP---CUCME

Still failed with the same cause value=47, Calling Party hear busy tone (no ringback tone) after Called Phone rings for just 1 time. Because CUBE is still receiving SIP 180 Ringing without SDP from CUCME, which again triggers CUBE to generate ringback tone locally.

Then I replace all SIP connections with H323, I can hear the ringback tone on Calling Phone now, and Called Phone rings normally and continuously.

CUCM---h323---CUBE---h323---CUCME

But when called party pickup the call, calling party still hear the ringback tone. Then after a few seconds, call disconnects autometically and calling party hear busytone. Call Disconnect cause value=47, It seems that CUBE lacks DSP resouce to bridge or conference the 2 H323 call legs, which produces above problems.

It seems that playing with CUBE in a pure VMware+GNS3 based Lab is not possible ? Anyone ever succeed on this ?

Thanks in advance.

[Ayodeji Okanlawon]

Tian,

Its all IP based, hence it hsould be possible. You dont need DSP for SDP...Can you send me the ff:

1. Sh run of your CUBE

2. debug ccsip messages..I suggest you use only sip to sip connections...

3. debug voip ccapi inout

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Yan Tian]

Hey aokanlawon,

Many thanks for your reply.

Can you please also share why sip to sip is preferred over h323 to sip ?

Attached is the debug output as you required. Topology and Backgroud info is as below:

SCCP Extension (2001/ Mask: +14082022001)----CUCM 7.0---SIP-----CUBE-----SIP------CUCME---SCCP Extension (6001/Mask: +861062286001)

10.11.11.2: the ip address of interface on CUBE which connect to interface (10.11.11.1) on CUCME Router.

10.10.10.10: the ip address from which CUCME deliver telephy-service. (ip source-address 10.10.10.10 port 2000).

When 2001 dial 6001, 6001 just rings for 1 time and call disconnects. 2001 hears no ring back tone but busy tone.

I have tried many tweakings, like no vad, codec g711ulaw under dial peer, force early-offer on SIP Trunk on CUCM, all failed. Beside, I am not access to command "early-offer forced" under "voice service voip->sip" subconfig mode.

Any advices are highly appreciated.

[Ayodeji Okanlawon]

Tian,

I have looked at the  logs and it appears that the issue is around PRACK... From this logs, we can see that when the CCME sent 180 ringing, it requested reliable transmission of the 180 ringing.. Under normal circumstances, CUBE should send PRACK upon receiving a require 100rel: but inb this case CUBE sends a CANCEL immediately,Which suggests that your IOS may not support PRACK

Mar  1 00:27:03.311: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP  10.11.11.2:5060;branch=z9hG4bK41D48
From: "HQ Phone 1" <>;tag=18C2C0-24D1
To: <861062286001>;tag=18BA2C-1091
Date: Fri, 01 Mar 2002 00:27:02 GMT
Call-ID: E2D389AB-2BE111D6-801096B3-53E51755@10.11.11.2
Timestamp: 1014942422
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Require: 100rel
RSeq: 4654
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
Allow-Events: telephone-event
Contact: <861062286001>
Content-Length: 0

Mar  1 00:27:03.371: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:861062286001@10.10.10.10:5060 SIP/2.0
Via: SIP/2.0/UDP  10.11.11.2:5060;branch=z9hG4bK41D48
From: "HQ Phone 1" <>;tag=18C2C0-24D1
To: <861062286001>
Date: Fri, 01 Mar 2002 00:27:02 GMT
Call-ID: E2D389AB-2BE111D6-801096B3-53E51755@10.11.11.2
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1014942423
Content-Length: 0

You can try the ff solutions and see which works..

1. Enable support for PRACK (this is on by default..but try this command again)

voice service voip

  sip

   rel1xx supported 100rel

voice service voip

  sip

   rel1xx supported 100rel

voice service voip

If this doesnt work, then I suggest you disable PRACK on the CCME side

2. voice service voip
  sip
   rel1xx disabled

Test again and send me debug ccsip messages

SIP to SIP is preferred for a few reasons, although  must mention that h323-sip is preferred on the cucm version you are running, because SIP wasnt mature in that cucm version. Below are two of the reasons why it is preferred

1. Interoperability reasons..sip to sip works better than h323 to sip

2. Troubleshooting purposes. it is easier to troubleshoot sip to sip than sip to h323
 

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Yan Tian]

Hey aokanlawon,

Thanks for your valuable input.

1. enable PRACK on CUBE, everything (including symptom, debug output etc) is exactly the same.

2. disable PARCK on CUCME, CUCME does not request PRACK again, But problem still there with same cause value=47, please see attachement for debug output of this case.

Thanks in advance.

[Ayodeji Okanlawon]

Tian,

Sorry for the late reply..

Can you try and enable early offer on the sip trunk in CUCM. You will need to have an MTP for this..do this and test again..send the logs

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Yan Tian]

Hey aokanlawon,

Thanks for your reply. I have enable early offer on SIP Trunk and end up with below SIP message on CUBE.

HQ-VG#

Mar  1 00:19:50.519: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:900861062286001@142.1.64.254:5060 SIP/2.0

Date: Fri, 01 Mar 2002 00:19:50 GMT

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

From: "HQ Phone 1" <>;tag=0140a88e-20ea-4ea4-98ef-fc4a3f05c677-33234526

Allow-Events: presence, kpml

P-Asserted-Identity: "HQ Phone 1" <>

Supported: timer,resource-priority,replaces

Min-SE:  1800

Remote-Party-ID: "HQ Phone 1" <>;party=calling;screen=yes;privacy=off

Content-Length: 214

User-Agent: Cisco-CUCM7.0

To: <900861062286001>

Contact: <>

Expires: 180

Content-Type: application/sdp

Call-ID: a1a1c80-c7e1c926-1-b40648e@142.100.64.11

Via: SIP/2.0/TCP 142.100.64.11:5060;branch=z9hG4bK039fd18a2

CSeq: 101 INVITE

Session-Expires:  1800

Max-Forwards: 70

v=0

o=CiscoSystemsCCM-SIP 2000 1 IN IP4 142.100.64.11

s=SIP Call

c=IN IP4 142.100.64.11

t=0 0

m=audio 24576 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

Mar  1 00:19:50.615: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 488 Not Acceptable Media

Via: SIP/2.0/TCP 142.100.64.11:5060;branch=z9hG4bK039fd18a2

From: "HQ Phone 1" <>;tag=0140a88e-20ea-4ea4-98ef-fc4a3f05c677-33234526

To: <900861062286001>;tag=122AA4-AC4

Date: Fri, 01 Mar 2002 00:19:50 GMT

Call-ID: a1a1c80-c7e1c926-1-b40648e@142.100.64.11

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 101 INVITE

Warning: 304 142.100.64.254 "Media Type(s) Unavailable"

Allow-Events: telephone-event

Content-Length: 0

Mar  1 00:19:50.651: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:900861062286001@142.1.64.254:5060 SIP/2.0

Date: Fri, 01 Mar 2002 00:19:50 GMT

From: "HQ Phone 1" <>;tag=0140a88e-20ea-4ea4-98ef-fc4a3f05c677-33234526

Allow-Events: presence, kpml

Content-Length: 0

To: <900861062286001>;tag=122AA4-AC4

Call-ID: a1a1c80-c7e1c926-1-b40648e@142.100.64.11

Via: SIP/2.0/TCP 142.100.64.11:5060;branch=z9hG4bK039fd18a2

CSeq: 101 ACK

Max-Forwards: 70

By the way, I am just curious about why you think enable early offer on SIP Trunk could be the solution of this problem?

Many Thanks

[Ayodeji Okanlawon]

First of all, you have enabled early offfer with G71ula codec and the inbound dial-peer 1 is set to use G720. You need to change the config on the dial-peer 1 to use G711, then ensure that the outbound dial-peer to ccme is also set t use G711...on your ccme gateway also set the inbound dial-peer to G711...

I am not sure enabling early offer will work, I just want to see if the issue has to do with media capabilites...So lets try this and see..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Yan Tian]

Hey aokanlawon,

my apologize, I did the test in a hurry, and forgot those basic configurations.

I have enabled codec g711ulaw on all related dial-peers, and the called party rings, but when Called Party pickup the phone, Calling party hears busy tone and the call gets disconnected.

From the SIP message, CUCM proactively sends SIP CANCEL with Reason: Q.850;cause=47.

From the debug voice ccapi inout, the call disconnected with cause value=16, which means normal call clear.

Apart from how to slove this problem, please also advice on below queries,

1. I have 2 dial-peers configured on CUBE as below,

dial-peer voice 1 voip

description Inbound Dial Peer Matching for H323

incoming called-number .T

codec g711ulaw

dial-peer voice 2 voip

description Inbound Dial Peer Matching for SIP

session protocol sipv2

incoming called-number .T

From output of "debug voice ccapi inout", I found dial-peer 1 was matched for this testing call, why this SIP call is matching h323 dial-peer for incoming direction, not dial-peer 2 which is a SIP dial-peer?

2. In the SDP offer, you can see c= IN IP4 10.11.11.2  / c=IN IP4 10.11.11.1 / c=IN 142.100.64.254

    I know why c=IN IP4 142.100.64.11 is used, because we are using MTP on CUCM, but I am curious why RTP connection are using those IP addresses as showned above? Why IP phone's IP address is not used here? How can those media streames destined for different IP address be bridged with each other?

Thanks in advance.

[Ayodeji Okanlawon]

Lets start with your questions..This is happening because CUBE doesnt select dial-peers based on protocols, dial-peers are selected based on matching called or calling numbers. In this scenario you have two matching dial-peers with incoming called number .T, CUBE will always use the dial-peer with the highest tag in this case. In this case that is dial-peer 1.

If you want to have two dial-peers for h323 and sip, you will need to define more specific patterns to match on your incoming called number..

eg

dial-peer voice 2 voip

incoming called number 900T

session protocl sipv2

dtmf-relay rtp-nte

no vad

On the next question...

From your call flow, this is what your rtp connections should looke like

IPphone-----rtp--MTP(cucm)---rtp---CUBE-------rtp---ipphone(on ccme)

Your CUBE has two ip addresses...one is 142.1.64.254 and the other is 10.11.11.2

The interface defined for your sip trunk is 142.1.64.254 on cucm and the interface closes to ccme is 10.11.11.2. This is why you are seeing both  addresses. I dont see a problem with this..

For the CCME, the reason why you dont see the ip address of the ip phone is down to DTMF megotiation and thats why the call is failing...

Lets look at the traces..

1.When CUCM sent invite to sip it advertised rtp-nte (rtpmap:101)

Received:
INVITE sip:900861062286001@142.1.64.254:5060 SIP/2.0
Date: Fri, 01 Mar 2002 01:16:28 GMT
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: "HQ Phone 1" <>;tag=0140a88e-20ea-4ea4-98ef-fc4a3f05c677-33234280
Allow-Events: presence, kpml
P-Asserted-Identity: "HQ Phone 1" <>
Supported: timer,resource-priority,replaces
Min-SE:  1800
Remote-Party-ID: "HQ Phone 1" <>;party=calling;screen=yes;privacy=off
Content-Length: 214
User-Agent: Cisco-CUCM7.0
To: <900861062286001>
Contact: <>
Expires: 180
Content-Type: application/sdp
Call-ID: f377c380-c7e1d66c-e-b40648e@142.100.64.11
Via: SIP/2.0/TCP 142.100.64.11:5060;branch=z9hG4bK1735b534a6
CSeq: 101 INVITE
Session-Expires:  1800
Max-Forwards: 70

v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 142.100.64.11
s=SIP Call
c=IN IP4 142.100.64.11
t=0 0
m=audio 24602 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

2. When CUBE sent out its INVITE to CCME, it also advertised rtp-nte

v=0

o=CiscoSystemsSIP-GW-UserAgent 5553 8018 IN IP4 10.11.11.2

s=SIP Call

c=IN IP4 10.11.11.2

t=0 0

m=audio 18168 RTP/AVP 0 101 19

c=IN IP4 10.11.11.2

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

3. However when we received 200 OK from CCME, we didnt get any dtmf advertised..Hence the reason why connection parameter C=10.11.11.1, points to the ip address of ccme not the phone, because it was attempting to invoke an MTP to address dtmf mismtach issue..

Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP  10.11.11.2:5060;branch=z9hG4bK142581
From: "HQ Phone 1" <>;tag=460334-7A8
To: <861062286001>;tag=45FB48-26F8
Date: Fri, 01 Mar 2002 01:16:28 GMT
Call-ID: CA7760AE-2BE811D6-8026EFAB-405440B5@10.11.11.2
Timestamp: 1014945388
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
Supported: replaces
Allow-Events: telephone-event
Contact: <861062286001>
Content-Type: application/sdp
Content-Length: 208

v=0
o=CiscoSystemsSIP-GW-UserAgent 9854 850 IN IP4 10.11.11.1
s=SIP Call
c=IN IP4 10.11.11.1
t=0 0
m=audio 16462 RTP/AVP 0 19
c=IN IP4 10.11.11.1
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20

To resolve this issue..please do the ff:

1. Ensure you define your inbound dial-peer correctly as suggested above. Then makse sure that dtmf-relay rtp-nte is advertised. You may remove dial-peer 1 for the sake of testing or use specific incoming called number I suggested

2. Your phones on CCME are SCCP phones and they dont support rtp-nte hence you will need to configure an MTP registered with your CCME or alternatively add the ff config to your ccme inbound dial-peer

dial-peer voice x voip

session protcol sipv2

dtmf-relay rtp-nte digit-drop sip-kpml

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Yan Tian]

Hey aokanlawon,

Many thanks for your valuable sharing. Really learn a lot from you.

After enable rtp-nte on all related dial-peers, rtp-nte does exist in all SDP offers from output of debug ccsip message.

However, call still disconnects when called party pick up the call, because CUCM proactively send SIP BYE with Reason: Q850; Cause=47.

Mar  1 03:45:03.287: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

BYE sip:900861062286001@142.100.64.254:5060;transport=tcp SIP/2.0

Reason: Q.850;cause=47

Date: Fri, 01 Mar 2002 03:44:56 GMT

From: "HQ Phone 1" <>;tag=0140a88e-20ea-4ea4-98ef-fc4a3f05c677-33234300

P-Asserted-Identity: "HQ Phone 1" <>

Content-Length: 0

User-Agent: Cisco-CUCM7.0

To: <900861062286001>;tag=CDF158-FB8

Call-ID: b10cb180-c7e1f938-12-b40648e@142.100.64.11

Via: SIP/2.0/TCP 142.100.64.11:5060;branch=z9hG4bK2316efbd

CSeq: 102 BYE

Max-Forwards: 70

Any advices please ?

[Ayodeji Okanlawon]

Okay, I need to check  the region setting between the IP phone on CUCM and the MTP device you are using...Ensure its set to G711..

If it still doesnt work..please use RTMT to collect CUCM logs and send them over. Ensure that the trace level is set to detailed..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Yan Tian]

Hey aokanlawon,

I confirm that Region setting is OK, and I collect the SDI trace just a few seconds after my testing call.

When collecting the trace, I select "relative range--- file generated in last 5 minutes",

Sorry to bring you a large amnout of SDI trace.

By the way, I have been looking for some docs showing how to understand the SDI, and any tools to make them more understandable, Could you please share some info on this ??

Thanks

[Ayodeji Okanlawon]

The CUCM trace you sent shows that your trace configuration is  not set to detailed..Please look at the link below to learn how to configure trace settings on cucm

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094e89.shtml

Having said that, I can see the ff entry which shows that CUCM attempts to invoke a MTP media resource for a call to the sip trunk and you can see the error highlighted..

I will need to see s detailed log before I know why cucm wants to use an MTP..What is the DTMF configuration on your sip trunk set to? Is it set to No preference?

<:STANDALONECLUSTER><:142.100.64.11><:1><:142.1.64.254><:><:ERROR><:0020>

03/01/2002 04:01:21.660 CCM|RouteListControl::idle_CcSetupReq - RouteList(RL-LRG), numberSetup=0 numberMember=0 vmEnabled=0|<:STANDALONECLUSTER><:142.100.64.11><:1><:142.100.64.12><:SEP020000006401><:ERROR><:0800>

03/01/2002 04:01:21.660 CCM|RouteListControl::idle_CcSetupReq -  RouteList(RL-LRG), RouteListCdrc::create  CI = 33234310  BRANCH = 0|<:STANDALONECLUSTER><:142.100.64.11><:1><:142.100.64.12><:SEP020000006401><:ERROR><:0800>

03/01/2002 04:01:21.665 CCM|MediaTerminationPointControl(1)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed -- Ci=33234311, errBitset=0x24|<:STANDALONECLUSTER><:142.100.64.11><:1><:142.100.64.12><:SEP020000006401><:ERROR><:0080>

03/01/2002 04:01:21.665 CCM|MtpNoMoreResourcesAvailable - No more MTP resources available. App ID:Cisco CallManager Cluster ID:StandAloneCluster Node ID:CUCM701-Pub|<:STANDALONECLUSTER><:142.100.64.11><:ALARM><:ALL><:FFFF>

03/01/2002 04:01:21.665 CCM|MRM::waiting_AllocateMtpResourceErr - ERROR - no resources are available -- ci = 33234311|

<:STANDALONECLUSTER><:142.100.64.11><:1><:142.1.64.254><:><:ERROR><:0020>

03/01/2002 04:01:21.660 CCM|RouteListControl::idle_CcSetupReq - RouteList(RL-LRG), numberSetup=0 numberMember=0 vmEnabled=0|<:STANDALONECLUSTER><:142.100.64.11><:1><:142.100.64.12><:SEP020000006401><:ERROR><:0800>

03/01/2002 04:01:21.660 CCM|RouteListControl::idle_CcSetupReq -  RouteList(RL-LRG), RouteListCdrc::create  CI = 33234310  BRANCH = 0|<:STANDALONECLUSTER><:142.100.64.11><:1><:142.100.64.12><:SEP020000006401><:ERROR><:0800>

03/01/2002 04:01:21.665 CCM|MediaTerminationPointControl(1)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed -- Ci=33234311, errBitset=0x24|<:STANDALONECLUSTER><:142.100.64.11><:1><:142.100.64.12><:SEP020000006401><:ERROR><:0080>

03/01/2002 04:01:21.665 CCM|MtpNoMoreResourcesAvailable - No more MTP resources available. App ID:Cisco CallManager Cluster ID:StandAloneCluster Node ID:CUCM701-Pub|<:STANDALONECLUSTER><:142.100.64.11><:ALARM><:ALL><:FFFF>

03/01/2002 04:01:21.665 CCM|MRM::waiting_AllocateMtpResourceErr - ERROR - no resources are available -- ci = 33234311|

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"