SIP Provider Drops My DTMF

Our SIP provider, via:talk, likes to do a server dance where they switch us from one server to the next, some times several times a say. Every time this happens the incoming DTMF to our Asterisk server stops getting through. This makes our voice menu system worthless. To get the DTMF to pass again I have to restart Asterisk or do “sip reloadâ€

This problem could be a couple things… so lets take a look. I am kind of taking a wild stab at this one.

Try adding:

rfc2833compensate=yes

to your sip.conf under trunk_1.
This compensates for version problems.

If that does nothing, try setting your codecs to ulaw only.
This might help if your provider is sending you “inband” when they switch servers.

Perhaps the servers that is jumps around are different versions.
In addition you might want to try dtmfmode=rfc2833 I mean, it could be that when the remote server switches, they don’t see that you are broadcasting your rfc2833 abilities and then drop their side to “inband”. Then when a call comes in on that trunk as gsm, the DTMF is too garbled to work.

Oh, and you may want to paste in what a call looks like going through, or rather, failing.

Hope that all makes sense…

Mark thank you for your suggestions. I will give them a try. See below for more info about your suggestions.

Here is the log for a call WITHOUT DTMF working

--------- start log DMTF not working --------

-- Executing [s@DID_trunk_1:1] NoOp("SIP/4.68.251.11-08274ee8", "[DID_trunk_1]| exten=s") in new stack
-- Executing [s@DID_trunk_1:2] ExecIf("SIP/4.68.251.11-08274ee8", "0|SetCallerPres|unavailable") in new stack
-- Executing [s@DID_trunk_1:3] ExecIf("SIP/4.68.251.11-08274ee8", "0|Set|CALLERID(all)=unknown <0000000>") in new stack
-- Executing [s@DID_trunk_1:4] Goto("SIP/4.68.251.11-08274ee8", "voicemenu-custom-1|s|1") in new stack
-- Goto (voicemenu-custom-1,s,1)
-- Executing [s@voicemenu-custom-1:1] NoOp("SIP/4.68.251.11-08274ee8", "--------incoming call start---------") in new stack
-- Executing [s@voicemenu-custom-1:2] Progress("SIP/4.68.251.11-08274ee8", "") in new stack
-- Executing [s@voicemenu-custom-1:3] Answer("SIP/4.68.251.11-08274ee8", "") in new stack
-- Executing [s@voicemenu-custom-1:4] Wait("SIP/4.68.251.11-08274ee8", "1") in new stack
-- Executing [s@voicemenu-custom-1:5] BackGround("SIP/4.68.251.11-08274ee8", "record/cim_main_menu") in new stack
-- <SIP/4.68.251.11-08274ee8> Playing 'record/cim_main_menu' (language 'en')

== Spawn extension (voicemenu-custom-1, s, 5) exited non-zero on ‘SIP/4.68.251.11-08274ee8’

------ end log file entry for DTMF not working

When calling in on my cell the DTMF did not pass so I hung up, that is what the last entry shows.

I then did “sip reload” and got this calling in on my cell.

------- start log DTMF working ------------

-- Executing [s@DID_trunk_1:1] NoOp("SIP/<phone number>-0827c5c0", "[DID_trunk_1]| exten=s") in new stack
-- Executing [s@DID_trunk_1:2] ExecIf("SIP/<phone number>-0827c5c0", "0|SetCallerPres|unavailable") in new stack
-- Executing [s@DID_trunk_1:3] ExecIf("SIP/<phone number>-0827c5c0", "0|Set|CALLERID(all)=unknown <0000000>") in new stack
-- Executing [s@DID_trunk_1:4] Goto("SIP/<phone number>-0827c5c0", "voicemenu-custom-1|s|1") in new stack
-- Goto (voicemenu-custom-1,s,1)
-- Executing [s@voicemenu-custom-1:1] NoOp("SIP/<phone number>-0827c5c0", "--------incoming call start---------") in new stack
-- Executing [s@voicemenu-custom-1:2] Progress("SIP/<phone number>-0827c5c0", "") in new stack
-- Executing [s@voicemenu-custom-1:3] Answer("SIP/<phone number>-0827c5c0", "") in new stack
-- Executing [s@voicemenu-custom-1:4] Wait("SIP/<phone number>-0827c5c0", "1") in new stack
-- Executing [s@voicemenu-custom-1:5] BackGround("SIP/<phone number>-0827c5c0", "record/cim_main_menu") in new stack
-- <SIP/<phone number>-0827c5c0> Playing 'record/cim_main_menu' (language 'en')

== CDR updated on SIP/-0827c5c0
– Executing [205@voicemenu-custom-1:1] Macro(“SIP/-0827c5c0”, “stdexten|205|SIP/205”) in new stack
– Executing [s@macro-stdexten:1] NoOp(“SIP/-0827c5c0”, “--------In Macro stdexten ------------”) in new stack
– Executing [s@macro-stdexten:2] SIPAddHeader(“SIP/-0827c5c0”, “Alert-Info: http://127.0.0.1;info=default”) in new stack
– Executing [s@macro-stdexten:3] Dial(“SIP/-0827c5c0”, “SIP/205|20|t”) in new stack
– Called 205
– SIP/205-082aa970 is ringing
== Spawn extension (macro-stdexten, s, 3) exited non-zero on ‘SIP/-0827c5c0’ in macro ‘stdexten’
== Spawn extension (macro-stdexten, s, 3) exited non-zero on ‘SIP/-0827c5c0’

-------- end log entry DTMF working ---------

As you can see from the “–Called 205” entry the DTMF went through thus forwarding the call to extension 205 using the stdexten macro.

Again the system will work fine until the provider changes us to another server(redirects) and then DTMF will no longer pass.

I did some playing around with our provider settings after my first posting and when the provider server changed it was not a DTMF problem but a connection problem. I changed the settings some how so that at a server change we could not receive incoming calls. I do not recall if outgoing were working. I reloaded the .conf files from a backup and we ended up with the DTMF problem again at server changes which is better than no connection/incoming calls. This leads me to believe there are some settings for the provider connection that are in need of tweaking. As there are so many and I do not totally understand what they are all for yet some trial and error will be in my future. And as I have to wait for the server change every time to test it this could take days.

As far as the DTMF setting with the provider we have switched them around several times from inband to rfc2833 to auto. Inband has never worked properly but is their default DTMF setting, rfc2833 worked fine for a while and then it wasn’t so we changed to “autoâ€

One change to my last post

In sip.conf I had the following line under [general]

context = DID_trunk_1

but for my first post it was set to

context = default

I have put it back to default to see what happens.

Thanks again