Inbound DTMF failing ITSP => CUBE => CUCM => UCX

[Paul Cobley]

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.

[Ayodeji Okanlawon]

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

[Paul Cobley]

Ok, so this is fixed.

What we did :-

• Reloaded the router - didn't fix
  
• Downgraded the IOS to match the wwokring CUBE - didn't fix
  
• Moved the not working CUBE from the old voice network to the new voice network - fixed. Not sure if there was a firewall blocking it or something else.
  

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.

[Ayodeji Okanlawon]

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"