cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1954
Views
5
Helpful
13
Replies

Intermittent DTMF issue with SIP-SIP CUBE

Hello,

We are facing intermittent DTMF issue with our CUBE. Call Flow: ITSP---SIP---CUBE----SIP-----CUCM---SIP---Lync Conference

Users dial-in to Lync conference from pstn and are prompted for conference id. when they the enter the dtmf, it seems the dtmf digits are not reaching lync intermittently.

I captured the packets from CUBE on both WAN & LAN interfaces and found that the digits are coming into WAN interface but they are not passed to LAN interface towards CUCM.

We have configured only rfc2833 on both the inbound & outbound dial-peers.

Attached are the captures. btside2.pcap on interface connected to ITSP and ccmside2.pcap on the interface connected towards CUCM.

any help would be really appreciated.

Thanks

Suresh

//Suresh Please rate all the useful posts.
1 Accepted Solution

Accepted Solutions

Hi Suresh,

If you see in the second packet capture towards cucm you just uploaded, the first two call has two way RTP stream.

10.224.1.252 <----->153.112.49.23

But in the last call its only one way from cucm to cube.

10.224.1.252 <-----153.112.49.23

If we think there is problem with SDP media IP or ports on the third call then atleast CUBE had generated packet to wrong (media or port) but here its doing nothing.

That's a very odd behavior.

Thanks

Manish

View solution in original post

13 Replies 13

Nishant Savalia
Level 4
Level 4

Hi Suresh,

It would be great if you can share required debug from CUBE and trace from CUCM.

debug voip ccapi inout

debug ccsip all

Also please do share your full running configuration

Regards,
Nishant Savalia

Regards, Nishant Savalia

Thanks Nishant & Manish for looking into this.

I captured the packets from CUBE interfaces both ITSP & CUCM side and also 'debug voip rtp sess name & debug ccsip mess'. collected the ccm traces also.

calling: 918066914754, called 48222022000. there were 3 calls captures in the logs.

first 2 were successful & last one failed. I've attached the snippets of cube config.

with debug voip rtp sess name, I could see the dtmf digits for the first two calls but not for the faulty third call.

with the cube packet captures, i could see the digits are received at provider side interface & passed on to cucm side interface for the successful calls.

for the faulty one, the digits are successfully received from provider but the same are not passed to ccm side. with that, we could say, the issue lies on cube config.

please have a look and let me know if any further info required.

//Suresh

Please rate all the useful posts.

//Suresh Please rate all the useful posts.

Manish Prasad
Level 5
Level 5

Hi Suresh,

What I can see on ccmside2 packet capture , there is no two way RTP stream.

Its only from 153.112.49.23 --->10.224.1.253.

Thanks

Manish

Hi Suresh,

If you see in the second packet capture towards cucm you just uploaded, the first two call has two way RTP stream.

10.224.1.252 <----->153.112.49.23

But in the last call its only one way from cucm to cube.

10.224.1.252 <-----153.112.49.23

If we think there is problem with SDP media IP or ports on the third call then atleast CUBE had generated packet to wrong (media or port) but here its doing nothing.

That's a very odd behavior.

Thanks

Manish

Hello Manish,

>> Below is the 200 OK message CUBE sent to ITSP.

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.251.253.20:5060;branch=z9hG4bK3ff38758;rport

From: "918066914754" <918066914754>;tag=as54c2f72e

To: <48222022000>;tag=3D150DC4-4EE

Date: Wed, 05 Mar 2014 12:29:31 GMT

Call-ID: 4913b5763cd35fa554ab44cf0f5446e1@10.251.253.1

CSeq: 102 INVITE

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

Allow-Events: telephone-event

Remote-Party-ID: <>;party=called;screen=yes;privacy=off

Contact: <>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Session-Expires:  1800;refresher=uas

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 247

v=0

o=CiscoSystemsSIP-GW-UserAgent 6418 5347 IN IP4 10.251.253.1

s=SIP Call

c=IN IP4 10.251.253.1

t=0 0

m=audio 30340 RTP/AVP 8 101 ---> RTP port:30340

c=IN IP4 10.251.253.1

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

we have configured the access list to allow the rtp port range between 10000-29999.

permit udp 10.251.253.0 0.0.0.31 host 10.251.253.1 range 10000 29999.

so the dtmf was failing as the CUBE negotiates the rtp port out of configured range in which the dtmf digits are coming in.

below is the log for the denied packets with 30340 port.

032148: Mar  5 12:34:48.530 UTC: %SEC-6-IPACCESSLOGP: list Provider denied udp 10.251.253.20(11024) -> 10.251.253.1(30340), 571 packets 

Now, instead of allowing complete RTP port range in the access list, how can we force CUBE to include one of the configrued RTP port range in SDP? using SIP normalization profile?

//Suresh

Please rate all the useful posts.

Message was edited by: Suresh Subramanian

//Suresh Please rate all the useful posts.

Hi Suresh,

As you know that by default gateway would select rtp ports from range of 16384 - 32767. But you can configure RTP port range for an interface.

Please refer below link and see it helps you in meeting your criteria.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_proto/configuration/xe-3s/cube-proto-xe-3s-book/voi-ip6-voip.html#task_39847922DDE9413BAFE73A80EE44EA5D

Regards,
Nishant Savalia

Regards, Nishant Savalia

Suresh,

Why dont you want to use the standard RTP port range 16384 - 32767. These are the standard ports. This is much easier for you than tweaking things..If you change this on the CUBE, you will not be able to change this on the IP Phones. When IP phones send open channel ACK, they send the ports to use for RTP to CUCM, these ports are taken from the standard RTP port range and I dont think you can change that.

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts

Hello Deji, our provider is sending the RTP packets in the port range 10000-29999. So we were thinking whether we can use the same range in CUBE, but now we allowed the standard range in the access-list.

Just wondering, is that possible to restrict the rtp range in IOS?

//Suresh

Please rate all the useful posts.

//Suresh Please rate all the useful posts.

Suresh,

I am not sure you can change this on the CUBE(enterprise model). I have had a look and I cant find a way to do this..

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts

Nishant, this seems for Service Provider CUBE, tried these commands though, but not available in our IOS.

Sent from Cisco Technical Support Android App

//Suresh Please rate all the useful posts.

What is your current version?

Regards,
Nishant Savalia

Regards, Nishant Savalia

it is Cisco 2921 with !5.1.4M3

//Suresh

Please rate all the useful posts.

//Suresh Please rate all the useful posts.

Hi Suresh,

Just for a knowledge , till now you didn't face any issue regarding calls other than DTMF issue in CUBE whenever RTP port is selected outside the range of 29999.

And if you want to use that range then as mentioned that feature is available from CUBE 9.1 version.

CUBE.png

Regards,
Nishant Savalia

Regards, Nishant Savalia
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: