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.

[Suresh Subramanian]

can you please post the working configuration too?

[Paul Cobley]

Here you go but they're the same ?

Incoming from ITSP (working CUBE):-

dial-peer voice 103 voip

description INCOMING CALLS

translation-profile incoming SUBSCRIBERS_INBOUND

session protocol sipv2

incoming called-number +dsdsdds...

voice-class codec 1 

dtmf-relay rtp-nte

no vad

Outbound to CUCM :-

dial-peer voice 104 voip

description CALLS TO SUBSCRIBER

translation-profile outgoing SUBSCRIBERS_OUTBOUND

preference 1

destination-pattern XXXX...

session protocol sipv2

session target ipv4:y.y.y.y

voice-class codec 1 

dtmf-relay rtp-nte

fax-relay ecm disable

fax rate disable

fax protocol none

no vad

Thanks

[Suresh Subramanian]

Yes, the dial-peer configuration is same. but the nonworking call is really matching the dial-peers mentioned above?

Now lets try to find out where the difference is.

- IOS version of the two CUBEs

- CUCM version

- DTMF method in SIP trunk(s) ( if one trunk per CUBE is configured, check the dtmf method in both the trunks)

if everything looks same, then lets make one working and one non-working test calls and collect the below debugs for both the calls.

> debug ccsip all

> debug voip rtp session named-events

> debug voip ccapi inout

> show call active voice brief (3-4 times during the active call)

[Paul Cobley]

Hi,

So DTMF method on both trunks is set to No Preference

IOS is subtly different between the CUBEs :-

working - .151(4)M1

not working - Version 15.1(4)M4,

CUCM is 9.1.1.20000-5

Debugs attached (ccsip all broke my cube !) -

> debug voip rtp session named-events

> debug voip ccapi inout

Also a show call active voice fro each in teh same file.

[Suresh Subramanian]

can you try setting the DTMF to only RFC2833 instead of No Preference on the non-working SIP trunk and check if it makes any difference please?

[Ayodeji Okanlawon]

Suresh,

Why do you want to set the trunk to RFC2833..Just curious. The logs show that RFC2833 is negotiated by CUCM and the gateway...We can see NSE events for digits using pt=101..and in CUCM logs we can see CUCM negotiating RFC2833..

Please rate all useful posts

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

[Paul Cobley]

Hi both,

I did hardcode to RFC2833 and retsted - no improvement. In answer to a previous question, DTMF does work outbound.

So, I will change IOS on the not working CUBE and try that - i'll report back.

Really appreciate your assistance.

Paul.

[Ayodeji Okanlawon]

There is another variable to this equation. The integration method used between unity connection and cucm. Is it sccp or sip? Can you collect cucm logs..SDI traces..ensure your trace level is set to detailed. We will see what DTMF method cucm negotiates between all parties


Sent from Cisco Technical Support Android App

[Paul Cobley]

Hi,

So I made a test from my a mobile ending 093 to the CUBE that does not have working DTMF. Logs are attached.

UCX is a SCCP integration & it's the same UCX and the same CUCM on both the CUBEs.

Hope this includes what you require & many thanks for your assistance.

B/w

Paul.

[Ayodeji Okanlawon]

I have looked at the traces and there is no reason why this shoudlnt work. the sccp ports of the UCXN supports RFC2833..

00298126.001 |16:44:26.328 |AppInfo  |setEndpointsDtmfCaps: Detected inband DTMF support.

00298126.002 |16:44:26.328 |AppInfo  |SIP DTMF Info: mLocalDtmfCaps...UNSOL=1, KPML=0, Inband=0(0) mEndppointsDtmfCaps...UNSOL=0, KPML=0, Inband=1(101) mDefaultTelephonyEvent=101, mDtmfPreference=1, mMtpAllocated=0

00298126.003 |16:44:26.328 |AppInfo  |SIPCdpc(137) - getDefAe: SIPCdpc=137, nodeId=1, processNumber=74  ci=23268899, branch=0

We can see from the higlighted text that RFC2833 is negotiated...So this should just work because the gateway is ending DTMF using pt=101 directly to the endpoint.

The only thing I will suggest is that you upgrade the IOS on the CUBE to the same version as the one that is working and try again...otherwise you may need to open a TAC case.

The other thing that would be nice is to see if the digits arrive on the unity connection server itself...Not sure how we can check that

Please rate all useful posts

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

[Ayodeji Okanlawon]

You can also do a quick test in the non working cube by adding sip-kpml on the inbound and outbound dial-peer to cucm..

dtmf-relay sip-kpml rtp-nte


Sent from Cisco Technical Support Android App

[Paul Cobley]

Hi,

I added this to incoming (from itsp) & outgoing (to cucm) Dial-Peers and re-tested. No change.

[Ayodeji Okanlawon]

Does DTMF work for outbound calls..if you place a test call from an IP phone to an IVR enabled destination..does it work?

[m.vanheukelum]

For me this is the solution. Many thanks Ayo!