Issue with DTMF and SIP trunk

Hi,

I have an issue with my asterisk 1.8(which is an IVR) and a trunk sip (mydivert.com). In order to get calls from that provider I need to register the trunk sip.
In this case everything works perfect and the DTMF are ok.

This provider can also send me the calls without being registered which is what I need but in this case I get the calls but asterisk doesn’t recognize the DTMF.

When I register the trunk sip, apart from using the register… I also have the below code.

[mydivert]
fromuser= xxxxxx
fromdomain=xx.xx.xx.xx
insecure=port,invite
dtmf=rfc2833
disallow=all
allow=ulaw
allow=alaw
allow=gsm
type=friend
host=sip.mydivert.com
nat=never
context=incoming_calls

Can anyone help me with this please to make the DTMF working without being registered with the provider? Is there any difference between being registered or not?

Thanks,
Gabriel

Valentin, you have a mistake in the configuration.

You have this:

[mydivert]
fromuser= xxxxxx
fromdomain=xx.xx.xx.xx
insecure=port,invite
dtmf=rfc2833
disallow=all
allow=ulaw
allow=alaw
allow=gsm
type=friend
host=sip.mydivert.com
nat=never
context=incoming_calls

Replace the line dtmf=rfc2833 by dtmfmode=rfc2833 or dtmfmode=info
You will see that in this way you will be working fine :wink:

Hi,

Thank you for you reply. The sip trunk that I posted is the one that is working if I use
register => xxxxxxx:xxxxxxx@sip.mydivert.com/xxxxxxx

This provider has the option to send the calls without being registered and for it I set the below code in my sip.conf

[109.68.162.234]
host=109.68.162.234
dtmfmode=rfc2833
type=peer
context=incoming_calls
insecure=invite,port
nat=yes
disallow=all
allow=ulaw
allow=alaw
allow=gsm

With the code above I got the call and my IVR system plays the audio files perfect but it doesn’t recognize the DTMF. They say that they support DTMF rfc2833 but it’s not working.

Can it be a firewall issue, a nat issue or should I add something more?

Thanks for your response.

You need to get the SDP sent from both sides (eg. by using “sip set debug on” and confirm that it enables telephony events. If it does, you will need to capture the RTP stream and see whether those events are actually arriving.

The dtmf log may also help.

If telephony events are not being negotiated on the m line, one or both sides have not actually enabled RFC 2833 properly.

telelphony events are typically codec 101.

Please note that Asterisk General is a discussion forum, not a support one.

hi!
if this was NAT/firewall problem, then you would have one-way audio problem additionaly.
if you don’t have audio problems, then this is most likely wrong dtmfmode or wrongly recognized dtmf.
so you can try to set dtmfmode=auto. i noticed this works on most systems.

if it still won’t work, then you should enable dtmf logging in logger.conf and see what is there.

Hi david55,

I think it’s a provider issue because here is some debug info:

[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 0 [ 43]: INVITE sip:35314880058@54.72.84.108 SIP/2.0
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 1 [ 65]: Via: SIP/2.0/UDP 109.68.162.234:5060;branch=z9hG4bK2a32bc6d;rport
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 2 [ 16]: Max-Forwards: 70
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 3 [ 65]: From: “0831545682” sip:0831545682@109.68.162.234;tag=as5b140e60
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 4 [ 34]: To: sip:35314880058@54.72.84.108
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 5 [ 45]: Contact: sip:0831545682@109.68.162.234:5060
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 6 [ 61]: Call-ID: 6ca9d6764825c9f21ca5fbd41c564b33@109.68.162.234:5060
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 7 [ 16]: CSeq: 102 INVITE
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 8 [ 20]: User-Agent: Asterisk
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 9 [ 35]: Date: Mon, 24 Mar 2014 10:42:57 GMT
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 10 [ 81]: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 11 [ 26]: Supported: replaces, timer
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 12 [ 97]: Remote-Party-ID: “0831545682” sip:0831545682@109.68.162.234;party=calling;privacy=off;screen=no
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 13 [ 29]: Content-Type: application/sdp
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 14 [ 19]: Content-Length: 310
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Header 15 [ 0]:
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 0 [ 3]: v=0
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 1 [ 48]: o=root 579570140 579570140 IN IP4 109.68.162.234
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 2 [ 23]: s=Asterisk PBX 1.8.15.0
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 3 [ 23]: c=IN IP4 109.68.162.234
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 4 [ 5]: t=0 0
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 5 [ 32]: m=audio 19352 RTP/AVP 8 0 18 101
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 6 [ 20]: a=rtpmap:8 PCMA/8000
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 7 [ 20]: a=rtpmap:0 PCMU/8000
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 8 [ 21]: a=rtpmap:18 G729/8000
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 9 [ 19]: a=fmtp:18 annexb=no
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 10 [ 33]: a=rtpmap:101 telephone-event/8000
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 11 [ 15]: a=fmtp:101 0-16
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 12 [ 10]: a=ptime:20
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9649 parse_request: Body 13 [ 10]: a=sendrecv

I assume that the below line is what you say:
[Mar 24 10:42:57] DEBUG[1360]: chan_sip.c:9612 parse_request: Body 10 [ 33]: a=rtpmap:101 telephone-event/8000

I tested it with another provider and the dtmf works but the hangup is not detected. My server is with amazon and is in Ireland, does it make any difference?

Can anyone recommend a good ddi provider that you know that works well?

Thanks,
Gabriel

It’s a combination of that line and this:

They claim to be using RFC 2833. One would need to look at the response to make sure that Asterisk was.