Solved: No DTMF from certain CUCM subscriber

mmoulson1 · ‎08-15-2019

We have a CUCM 12 cluster with a few subscribers.

When phones are registered to a certain subscriber the DTMF on outbound calls does not work. If we update the CMG on their device pool so the phone registration moves to a different subscriber the DTMF works fine.

We are using SIP to CUBE and SIP to an ITSP.

Anthony Holloway · ‎08-15-2019

Here's a theory: Your CUBE is not matching the correct dial-peer for incoming calls from those Subs, and so it's using dial-peer 0, which does not support any dtmf-relay at all. Can you articulate how you're doing inbound dial-peer matching for calls from all CUCM nodes?

You can confirm my theory by nailing up a failing call on the CUBE and then issue the following command:

show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

The output will be in pairs of call legs. PeerAddr shows the phone numbers, while PeerId shows the dial-peers in use. Finally Dtmf will show what DTMF was negotiated.

Might as well do it again for a working call too, just to compare. Can you share the output?

View solution in original post

Anthony Holloway · ‎08-15-2019

Here's a theory: Your CUBE is not matching the correct dial-peer for incoming calls from those Subs, and so it's using dial-peer 0, which does not support any dtmf-relay at all. Can you articulate how you're doing inbound dial-peer matching for calls from all CUCM nodes?

You can confirm my theory by nailing up a failing call on the CUBE and then issue the following command:

show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

The output will be in pairs of call legs. PeerAddr shows the phone numbers, while PeerId shows the dial-peers in use. Finally Dtmf will show what DTMF was negotiated.

Might as well do it again for a working call too, just to compare. Can you share the output?

mmoulson1 · ‎08-16-2019

Many thanks Anthony, 100% correct with your theory!

My next thoughts were how?!! And a review of the CUBE config. My colleague had configured "incoming uri from 1001" on the inbound dial peer from CUCM but then not configured the subscriber IP addresses within the "voice class uri"!

Many thanks for your help

Anthony Holloway · ‎08-16-2019

I should have guessed you were doing inbound matching on URI, because it was peer specific. Which also means you have run on all nodes checked on the trunk to cube, causing the route local rule to come into play. Had you not had this checked, and your trunk's DP->CMG matched the subs in the voice class URI, then it would have worked no matter which sub you register your phone to.

Anyway, glad I could help!