Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
3843
Views
15
Helpful
14
Replies

DTMF issue with sip trunk to ISP for some calls

Sebin
Level 1
Level 1

‎07-30-2018 02:09 AM - edited ‎03-17-2019 01:16 PM

Hi all,

I am facing issues with DTMF for some outbound calls. Some are working fine (mostly the toll free numbers) but calls to other numbers it is failing with dtmf. The calls are getting connected, users can hear the IVR options but none can be selected. Attaching the output of "show call active voice" for one successfull call and one unsuccessfull.  My setup is like CUCM<-->Gateway router (C4321)<--->ITSP. Both the links are SIP trunks. 10.128.2.10 is the CUCM and 192.168.1.6 is the ITSP sip gateway. 5068888 is the sample number with DTMF not working and 600532273 is the one DTMF is working well. Below is the dial-peer configuration from the gateway.

 

dial-peer voice 772 voip
 session protocol sipv2
 session target ipv4:10.128.2.10
 incoming called-number [0,1-9].
 no voice-class sip outbound-proxy   
 dtmf-relay rtp-nte sip-notify sip-kpml sip-info
 codec g711alaw
 no vad

 

dial-peer voice 6666 voip
 preference 2
 destination-pattern 408....
 session protocol sipv2
 session target ipv4:10.128.2.10
 no voice-class sip localhost
 no voice-class sip outbound-proxy   
 dtmf-relay rtp-nte sip-notify sip-kpml sip-info
 codec g711alaw
 ip qos dscp cs3 signaling
 no vad

 

dial-peer voice 7704 voip
 destination-pattern [2-8]......$
 session protocol sipv2
 session target ipv4:192.168.1.6
 voice-class sip localhost dns:44086666.etisalat
 voice-class sip profiles 101
 dtmf-relay rtp-nte sip-notify sip-kpml sip-info
 codec g711alaw
 no vad

dial-peer voice 77800 voip
 destination-pattern [678]00T
 session protocol sipv2
 session target ipv4:192.168.1.6
 voice-class sip localhost dns:44086666.etisalat
 voice-class sip profiles 101
 dtmf-relay rtp-nte
 codec g711alaw
 no vad

My voice gateway IOS is isr4300-universalk9.03.13.06a.S.154-3.S6a-ext.SPA.bin

Thanks in advance

 

1 person had this problem
Labels:
Preview file
14 KB
0 Helpful
14 Replies 14

Daniele Giordano
Level 8
Level 8

‎07-30-2018 02:37 AM

Hi, 

I see a call to PeerAddress=5068888 that uses tx_DtmfRelay=inband-voice

and a call to PeerAddress=600532273 that uses tx_DtmfRelay=rtp-nte.

 

Try to negotiate only rtp-nte in your dial-peers.

Replacethe config ' dtmf-relay rtp-nte sip-notify sip-kpml sip-info '

with '  dtmf-relay rtp-nte ' only.

 

Regards.

0 Helpful

Sebin
Level 1
Level 1
In response to Daniele Giordano

‎07-30-2018 04:22 AM - edited ‎07-30-2018 04:24 AM

Hi Daniele,

Thank you for the response, but that didn't work out. Basically it was the configuration before and i modified it for testing. Please find attached the "debug voice dialpeer all" along with the "show call active voice" output. Please check something you can find out from this.

Preview file
39 KB
0 Helpful

Daniele Giordano
Level 8
Level 8
In response to Sebin

‎07-30-2018 07:39 AM

Hi, try to remove completely 'dtmf-relay' from your outgoing dial-peers.

In this way the dtmf will be sent as voice inside the rtp flow.

 

Test the call using these debugs:

debug ccsip all

debug voip rtp sess name

 

Regards.

0 Helpful

Anthony Holloway
Cisco Employee
Cisco Employee
In response to Daniele Giordano

‎07-30-2018 09:25 AM

Why would there be any messages in debug voip rtp sess name, if they remove dtmf-relay, and thus rtp-nte?

I agree with the need to review the debug ccsip, however, messages should be plenty, not all. What's your reason for asking for all?
0 Helpful

Sebin
Level 1
Level 1
In response to Anthony Holloway

‎07-31-2018 12:47 AM

Hi please find attached the debug ccsip message for this failed call

Preview file
14 KB
0 Helpful

Daniele Giordano
Level 8
Level 8
In response to Sebin

‎07-31-2018 05:47 AM

Hi, this is your debug:

 

INVITE sent from your Cisco:

INVITE sip:5068888@192.168.1.6:5060 SIP/2.0
...
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
...
Allow-Events: telephone-event
...
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP-GW-UserAgent 1403 6924 IN IP4 192.168.1.25
s=SIP Call
c=IN IP4 192.168.1.25
t=0 0
m=audio 31932 RTP/AVP 8 101
c=IN IP4 192.168.1.25
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

 

 

and this is the response from a Huawei SoftSwitch:

SIP/2.0 200 OK
...

Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
...
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 61748586 61748586 IN IP4 192.168.1.6
s=Sip Call
c=IN IP4 192.168.1.6
t=0 0
m=audio 41270 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=ptime:20

 

 

Based on debug, the Huawei SoftSwitch doesn't negotiate DTMF RFC2833 method. Telephone-event header is missing in SDP response.

Probably the Huawei uses SIP INFO or SUBSCRIBE/NOTIFY method.

In this case my suggestion is to configure your cisco to use SIP INFO.

 

The output of debug must be similar to the following:

INFO ...

Content-Type: application/dfmf-relay

....

 

Signal=4

Duration=160

 

In this example the digit 4 has been pressed for 160 ms.

With SIP INFO I had problem of interoperability due to duration and volume.

Some IVR need a duration of e.g. 500 ms in order to detect digits.

 

Test DTMF SIP INFO and let us know.

 

Regards.

0 Helpful

Sebin
Level 1
Level 1
In response to Daniele Giordano

‎07-31-2018 06:07 AM

Dear Daniele,

 

thank you for ur detailed explanation, but still its not working

dial-peer voice 7704 voip
 destination-pattern [2-8]......$
 session protocol sipv2
 session target ipv4:192.168.1.6
 voice-class sip localhost dns:44086666.etisalat
 voice-class sip profiles 101
 dtmf-relay sip-info
 codec g711alaw
 no vad

 

but the same SIP trunk i can successfully dial most of the toll free numbers with working DTMF.

0 Helpful

Daniele Giordano
Level 8
Level 8
In response to Sebin

‎07-31-2018 06:20 AM

Can you post a new debug of a working and not working call?

Regards.

0 Helpful

Sebin
Level 1
Level 1
In response to Daniele Giordano

‎07-31-2018 07:45 AM

Hi Daniele

 

Please find attached the logs.

 

DTMF with calls to 600532273 is working fine. And calls to 5068888 is not

 

these are the dial-peers used to route the calls.

 

dial-peer voice 772 voip
 session protocol sipv2
 session target ipv4:10.128.2.10
 incoming called-number [0,1-9].
 no voice-class sip outbound-proxy   
 dtmf-relay rtp-nte sip-notify sip-kpml sip-info
 codec g711alaw
 no vad

 

in dial-peer  772  i tried dtmf relay to none and sip-info, but same.

 

 

dial-peer voice 7704 voip
 destination-pattern [2-8]......$
 session protocol sipv2
 session target ipv4:192.168.1.6
 voice-class sip localhost dns:44086666.etisalat
 voice-class sip profiles 101
 dtmf-relay sip-info
 codec g711alaw
 no vad

 

dial-peer voice 77800 voip
 destination-pattern [678]00T
 session protocol sipv2
 session target ipv4:192.168.1.6
 voice-class sip localhost dns:44086666.etisalat
 voice-class sip profiles 101
 dtmf-relay rtp-nte
 codec g711alaw
 no vad

The calls to [678]00T is working without any dtmf issues.

Preview file
26 KB
0 Helpful

Daniele Giordano
Level 8
Level 8
In response to Sebin

‎07-31-2018 08:19 AM

Ok, I've better analized your logs. Your cisco works as border element, received a SIP message and forward a new one:

 

Received:
INVITE sip:5068888@192.168.1.25:5060 SIP/2.0

...
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
...
Allow-Events: presence, kpml
...
Call-Info: <sip:10.128.2.10:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
...
Content-Type: application/sdp

v=0
o=CiscoSystemsCCM-SIP 133536354 1 IN IP4 10.128.2.10
s=SIP Call
c=IN IP4 10.128.2.10
t=0 0
m=audio 26062 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

 

and Sent:
INVITE sip:5068888@192.168.1.6:5060 SIP/2.0
...
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
...
Allow-Events: telephone-event
...
Content-Type: application/sdp
...

v=0
o=CiscoSystemsSIP-GW-UserAgent 4950 4701 IN IP4 192.168.1.25
s=SIP Call
c=IN IP4 192.168.1.25
t=0 0
m=audio 20642 RTP/AVP 8
c=IN IP4 192.168.1.25
a=rtpmap:8 PCMA/8000
a=ptime:20

 

So in A-Leg the cisco negotiate RFC2833 but in B-Leg no.

Probably in B-Leg the router uses the dial-peer 7704 but I cannot see SIP INFO messages in outgoing direction.

 

Do you have already tested 'dtmf-relay rtp-nte' in your dial-peer 7704?

 

Regards.

0 Helpful

Anthony Holloway
Cisco Employee
Cisco Employee
In response to Daniele Giordano

‎07-31-2018 10:31 AM

In an earlier reply, Sebin already tested dtmf-relay rtp-nte towards the ITSP.

 

You can see that in the following debug, rtp-nte is sent in the offer:

Jul 31 07:21:50.875: //3258888/62DC80800004/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:5068888@192.168.1.6:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.25:5060;branch=z9hG4bK1FB1FC6F2
Remote-Party-ID: "SEBIN" <sip:044086471@44086666.etisalat>;party=calling;screen=yes;privacy=off
From: "SEBIN" <sip:044086471@44086666.etisalat>;tag=797CD02B-4E0
To: <sip:5068888@192.168.1.6>
Date: Tue, 31 Jul 2018 07:21:50 GMT
Call-ID: 3A301595-93C911E8-B3EFAA70-C66C772A@44086666.etisalat
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 1658617984-0000065536-0000323275-0167936010
User-Agent: Cisco-SIPGateway/IOS-15.4.3.S6a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1533021710
Contact: <sip:044086471@192.168.1.25:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 1403 6924 IN IP4 192.168.1.25
s=SIP Call
c=IN IP4 192.168.1.25
t=0 0
m=audio 31932 RTP/AVP 8 101
c=IN IP4 192.168.1.25
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

However, the ITSP does not respond with rtp-nte in its answer:

Jul 31 07:21:51.436: //3258888/62DC80800004/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.25:5060;branch=z9hG4bK1FB1FC6F2
From: "SEBIN" <sip:044086471@44086666.etisalat>;tag=797CD02B-4E0
To: <sip:5068888@192.168.1.6>;tag=mc83h58c-CC-1018
Call-ID: 3A301595-93C911E8-B3EFAA70-C66C772A@44086666.etisalat
CSeq: 101 INVITE
Timestamp: 1533021710
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Contact: <sip:5068888@192.168.1.6:5060;transport=udp>
Content-Length: 161
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 61748586 61748586 IN IP4 192.168.1.6
s=Sip Call
c=IN IP4 192.168.1.6
t=0 0
m=audio 41270 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=ptime:20

In the example which works, the offer to the ITSP also contains rtp-nte:

Jul 31 14:14:21.242: //3263406/039B62000004/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:600532273@192.168.1.6:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.25:5060;branch=z9hG4bK1FC5D3B19
Remote-Party-ID: "SEBIN" <sip:044086471@44086666.etisalat>;party=calling;screen=yes;privacy=off
From: "SEBIN" <sip:044086471@44086666.etisalat>;tag=7AF6794B-2143
To: <sip:600532273@192.168.1.6>
Date: Tue, 31 Jul 2018 14:14:21 GMT
Call-ID: DA8E61F8-940211E8-9BE4AA70-C66C772A@44086666.etisalat
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0060514816-0000065536-0000324171-0167936010
User-Agent: Cisco-SIPGateway/IOS-15.4.3.S6a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1533046461
Contact: <sip:044086471@192.168.1.25:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 8016 5193 IN IP4 192.168.1.25
s=SIP Call
c=IN IP4 192.168.1.25
t=0 0
m=audio 21342 RTP/AVP 8 101
c=IN IP4 192.168.1.25
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

Only, the ITSP did respond with an answer containing rtp-nte, unlike in the failed call:

Jul 31 14:14:21.669: //3263406/039B62000004/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.25:5060;branch=z9hG4bK1FC5D3B19
From: "SEBIN" <sip:044086471@44086666.etisalat>;tag=7AF6794B-2143
To: <sip:600532273@192.168.1.6>;tag=5673c3x7-CC-1018
Call-ID: DA8E61F8-940211E8-9BE4AA70-C66C772A@44086666.etisalat
CSeq: 101 INVITE
Timestamp: 1533046461
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Contact: <sip:600532273@192.168.1.6:5060;transport=udp>
Content-Length: 217
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 62135205 62135205 IN IP4 192.168.1.6
s=Sip Call
c=IN IP4 192.168.1.6
t=0 0
m=audio 43618 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=fmtp:101 0-15

I suspect there is a problem on the ITSP side.  You can prove that this is not dial-peer configuration, by making both dial-peers: 7704 and 77800 identical.  A test Sebin already did earlier, by making the change to the DTMF relay to support only rtp-nte.

 

Sebin,  whenever you perform a test, always capture the running config, debug ccsip messages, debug voip ccapi inout, and the show call active voice.

 

A nice trick to filtering the data in the show call active voice command, is to do this instead:

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

 

I also note two other issues in this thread:

 

1) Do note that SIP INFO DTMF Relay is not supported by CUCM.  And since most ITSPs will only support rtp-nte, there is not reason to ever use it.

 

Reference: INFO is not supported by Unified CM.

 

2) The media IP coming from CUCM to the CUBE is that of CUCM itself.  This indicates that some media resource is being invoked for the call, and this may not be desireable.  Now, it's happening on both the working and non-working calls, so I don't think it contributes to the DTMF issue, however, it could be a source of other problems.  Be sure to not selected MTP Required on the SIP trunks, don't select Early Offer Forced (Use Best Effort) on your SIP Profiles, and use No Preference for your DTMF on the SIP Trunks.

Sebin
Level 1
Level 1
In response to Anthony Holloway

‎08-01-2018 12:57 AM

Hi Anthony,

 

Thank you very much for your guidelines. Im attaching the running config, and please have a look at the below output of the show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD command. The same pair of dialpeers negotiating it in different ways. The DTMF at 3103103 is working well but the 5068888 is not. I checked 5068888 from one another location where using the same ITSP SIP gateway (192.168.1.6) and its working there. but the solution is an asterisk based and the SIP trunk is directly connecting to the asterisk box.

 

PeerAddress=044086471
PeerId=772
RemoteSignallingIPAddress=10.128.2.10
RemoteSignallingPort=5060
RemoteMediaIPAddress=10.128.1.124
RemoteMediaPort=30540
tx_DtmfRelay=rtp-nte
VAD = disabled
CoderTypeRate=g711alaw

PeerAddress=5068888
PeerId=7704
RemoteSignallingIPAddress=192.168.1.6
RemoteSignallingPort=5060
RemoteMediaIPAddress=192.168.1.6
RemoteMediaPort=44192
tx_DtmfRelay=inband-voice
VAD = disabled
CoderTypeRate=g711alaw




PeerAddress=044086471
PeerId=772
RemoteSignallingIPAddress=10.128.2.10
RemoteSignallingPort=5060
RemoteMediaIPAddress=10.128.1.124
RemoteMediaPort=31522
tx_DtmfRelay=rtp-nte
VAD = disabled
CoderTypeRate=g711alaw

PeerAddress=3103103
PeerId=7704
RemoteSignallingIPAddress=192.168.1.6
RemoteSignallingPort=5060
RemoteMediaIPAddress=192.168.1.6
RemoteMediaPort=44208
tx_DtmfRelay=rtp-nte
VAD = disabled
CoderTypeRate=g711alaw

Preview file
13 KB
0 Helpful

Ayodeji Okanlawon
VIP Alumni
VIP Alumni
In response to Anthony Holloway

‎08-01-2018 05:50 AM

Excellent response Anthony. +5

Accurate and straight to the point.

Please rate all useful posts
0 Helpful

Amod Joshi
Level 1
Level 1

‎08-28-2018 12:58 AM

Hi Sebin,

 

Have you resolved this problem!

We are facing the same issue in our company. The DTMF is not working for DU (ITSP) numbers only, for etisalat its working fine. Same for incoming calls, we have IVR in our office, if anyone calls from DU mobile/landline,DTMF will not work. where if someone is calling from Estisalat (mobile/landline) DTMF is working fine.

 

 

0 Helpful
Customers Also Viewed These Support Documents