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
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.
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.
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.
07-30-2018 09:25 AM
07-31-2018 12:47 AM
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.
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.
07-31-2018 06:20 AM
Can you post a new debug of a working and not working call?
Regards.
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.
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.
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.
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
08-01-2018 05:50 AM
Excellent response Anthony. +5
Accurate and straight to the point.
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.
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