05-20-2013 07:24 AM - edited 03-18-2019 11:16 AM
Hi,
I have two CUBEs in different regions. They both have the same SIP profile and are registered to the same CUCM cluster. We hit an AA in UCX through both CUBEs. On one CUBE the DTMF is working but not the other.
The DTMF is being received on the CUBE from the ITSP :-
May 20 14:04:20: <<<Rcv> Pt:101 Evt:0 Pkt:87 08 48
May 20 14:04:20: s=DSP d=VoIP payload 0x65 ssrc 0x68BE0FDF sequence 0xA3 timestamp 0x4C40
May 20 14:04:20: Pt:101 Evt:0 Pkt:87 08 48 <Snd>>>
May 20 14:04:20: s=VoIP d=DSP payload 0x65 ssrc 0x68BE0FDF sequence 0xA4 timestamp 0x4C40
May 20 14:04:20: <<<Rcv> Pt:101 Evt:0 Pkt:87 08 48
May 20 14:04:20: s=DSP d=VoIP payload 0x65 ssrc 0x68BE0FDF sequence 0xA4 timestamp 0x4C40
May 20 14:04:20: Pt:101 Evt:0 Pkt:87 08 48 <Snd>>>
May 20 14:04:20: s=VoIP d=DSP payload 0x65 ssrc 0x68BE0FDF sequence 0xA6 timestamp 0x4C40
May 20 14:04:20: <<<Rcv> Pt:101 Evt:0 Pkt:87 08 48
May 20 14:04:20: s=DSP d=VoIP payload 0x65 ssrc 0x68BE0FDF sequence 0xA6 timestamp 0x4C40
May 20 14:04:20: Pt:101 Evt:0 Pkt:87 08 48 <Snd>>>
The incoming ITSP dial-peer on the not working CUBE :-
dial-peer voice 103 voip
description INCOMING CALLS
translation-profile incoming SUBSCRIBERS_INBOUND
session protocol sipv2
incoming called-number xxxxx
voice-class codec 1
dtmf-relay rtp-nte
no vad
The outgoing CUCM dial-peer on the not working CUBE :-
dial-peer voice 105 voip
description CALLS TO PUBLISHER
translation-profile outgoing SUBSCRIBERS_OUTBOUND
preference 1
destination-pattern xxxxx
session protocol sipv2
session target ipv4:y.y.y.y
voice-class codec 1
dtmf-relay rtp-nte
Odd how one CUBE is working and the other isnt on the same CUCM/UCX cluster, any ideas ?
TIA
Paul.
05-20-2013 01:54 PM
Paul,
Can you send cucm SDI traces. What is this IP address: 199.27.81.200?
The only difference I see in the 2 calls is that the non working call use g711. To this device while the working uses g729. Codec shouldn't matter with rfc2833 since DTMF are transported in a different payload separate from the media payload which is our codec here.
Also what's the integration sip or sccp?
The logs showed that the gateway receives and sent the digits correctly, so the issue seem to be with the end point not receiving them, hence the need to look st cucm traces.
Sent from Cisco Technical Support Android App
05-21-2013 12:59 PM
Ok, so this is fixed.
What we did :-
This is a migration from an old 7.1 cluster on unsupported hardware to a new cluster on VMWare.
We are rebuilding 9.1 on the new hardware and have a SIP trunk between old & new clusters whiulst we migrate users over.
Looks like it was a routing or firewall issue.
Thanks to you guys for spending your valuable time assisting.
05-22-2013 12:40 AM
Paul,
Thats a very strange one. The interesting thing is that firewalls cant block dtmf digits especially one that uses rtp-nte as the transport method. This is because the digits are actually carried in the existing voice stream i.e using the same udp source and destination ports. The only thing that is different is that rather than using the media payload (i.e your voice codec) it uses a different payload (101)
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide