[Home]

Summary:ASTERISK-14589: [patch] Fix for Sonus DTMF issues
Reporter:Jason Shugart (jasonshugart)Labels:
Date Opened:2009-08-03 12:28:27Date Closed:2011-03-16 12:29:23
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) call2-dtmf.pcap
( 1) dash-den-gotomeeting.pcap
( 2) dash-DEN-gotomeeting2.pcap
( 3) dtmf_test_r308722M.pcap
( 4) fix_sonus_dtmf.patch.txt
( 5) issue_15652_dtmf_ast-1.4.patch.txt
( 6) issue_15652_dtmf_ast-1.6.2.patch.txt
( 7) issue_15652_dtmf_ast-1.8.patch.txt
( 8) rtp.c.diff
( 9) rtp.c.diff.fix
(10) rtp.conf.sample.diff
(11) rtp.conf.sample.diff.fix
Description:In some cases when Asterisk sends DTMF to Sonus platforms as RFC2833, Sonus will not recognize the DTMF.  Several articles have identified the problem as being the gap in the audio prior to the DTMF packets being sent.  This patch sends a single G.711 ulaw packet prior to the rfc2833 packets.  In our testing across with two carriers (Level3 and 360 Networks) this patch fixed our DTMF issues.  The rtp.c file seems very similar for the 1.4 branch, so minor changes could also be applied there.  I added an option to the rtp.conf file to enable this fix, called rtpfixdtmf.  Attached are both the rtp.c fix, and the rtp.conf change.
Comments:By: Ronald Chan (loloski) 2009-08-03 13:24:47

i'm not a C programmer, but the attach patch was generated in reverse, i might be wrong here... please check
By: Jason Shugart (jasonshugart) 2009-08-03 13:29:27

Sorry about that.  I have not uploaded a patch in a long time.  This should be better.
By: Ronald Chan (loloski) 2009-08-03 13:33:15

no, worries :) let's hope a developer will pick this up
By: Jason Shugart (jasonshugart) 2009-10-27 08:30:22

I have tested the patch and it appears to work.  I will get feedback from the people I have sent this patch to, but I would appreciate anyone else adding their comments if they have tested this.
By: Jamuel Starkey (jamuel) 2009-10-27 15:15:13

Tested this against 1.4.26.2 where we were seeing complete DTMF misses with our carrier.  Now we are getting intermittent detection issues.  Uploading the latest packet capture.
By: Jamuel Starkey (jamuel) 2009-10-27 15:18:36

I uploaded before (dash-den-gotomeeting.pcap) and after (dash-DEN-gotomeeting2.pcap) captures (tcpdump -s0) both calls were SIP to GotoMeeting where we were seeing this issue.
By: Russell Bryant (russell) 2009-11-20 15:51:18.000-0600

jasonshugart, Can you provide a packet capture before and after this change that demonstrates the problem and why this fixes it?
By: Russell Bryant (russell) 2009-11-20 15:52:38.000-0600

Also, if this has to be configurable, I would prefer that the option go into sip.conf, instead.  It should be both a global option in the general section as well as a per-peer option.  However, the option name will have to be a bit more descriptive.
By: Jamuel Starkey (jamuel) 2009-11-23 14:38:57.000-0600

Just tested this patch against asterisk 1.6.1.8.  Patch applied cleanly (hunk offset warnings notwithstanding).  Still have missed DTMF when dialing GotoMeeting destinations.
By: Terry Wilson (twilson) 2009-12-10 18:09:29.000-0600

Is there a way that someone with a connection to a sonus switch could somehow direct some traffic to one of my test boxes?  I would like to get this issue fixed, but I am having trouble recreating the "audio gap" with normal sip phones.  I would really like to come up with a good solution to this issue, but can't in good conscience modify and commit a patch for an issue that I don't entirely understand.
By: Jamuel Starkey (jamuel) 2009-12-10 18:14:07.000-0600

Send me an email and I can get you access to a test box that is peered with a Sonus -- jamuel@hcvoip.com or call me 925-250-2457
By: Terry Wilson (twilson) 2010-01-08 11:04:52.000-0600

Jamuel: If you set constantssrc=true in sip.conf [general] does it fix the dtmf issue for you?
By: Jamuel Starkey (jamuel) 2010-01-08 16:55:46.000-0600

Terry: shall I set constantssrc=TRUE as opposed to YES (which is indicated in sip.conf.sample)?

I didn't have it explicitly set either way in sip.conf -- what is the default value?
By: Terry Wilson (twilson) 2010-01-08 16:56:34.000-0600

either yes or true will work.  The default is no.
By: Jamuel Starkey (jamuel) 2010-01-08 17:52:20.000-0600

Enabling this option had no perceivable effect.
By: Sean Bright (seanbright) 2010-01-11 21:52:16.000-0600

We are also having this issue in production (1.6.1 SVN).  Please let me know what information I can provide.  I am able to test after 7pm eastern M-F and all day saturday and sunday.
By: S Harvanek (sharvanek) 2010-01-18 09:31:22.000-0600

This works for us with Dash, however if IAX2 is in the middle we still get intermittent issues.

If it's SIP all the way then there are no problems and this works perfectly.

-SH
By: Terry Wilson (twilson) 2010-02-23 16:19:04.000-0600

I am attaching another patch (for 1.4--1.6.x should apply with one easy modification--add 'struct ast_silence_generator *gen;' to the end of the sip_pvt struct definition) that interleaves audio with the dtmf events if the 'transmit_silence' option in asterisk.conf is enabled (be sure to uncomment '[options]' as well).  Other things that I have found that fixed things on various peoples machines were:
1) setting constantssrc=yes in sip.conf
2) setting rfc2833compensate=no in sip.conf

If I could get people to test out 1 and 2 (by themselves) to see if that fixes the problem, and if they don't then to test out the fix_sonus_dtmf.patch.txt patch, I would greatly appreciate it.
By: moshe Teitelbaum (moshe) 2010-03-05 00:02:43.000-0600

could you build a rtp.c patch for you that will compile in 1.4.26.1 as well
By: Terry Wilson (twilson) 2010-03-05 00:07:58.000-0600

The patch was against the 1.4 branch in the first place. Does it not apply to 1.4.26.1?
By: moshe Teitelbaum (moshe) 2010-03-05 00:29:46.000-0600

The patch does not compile against 1.4 looks like it is for 1.6.1 its calling non existent functions and needs to go into non-existent lines of code
By: Terry Wilson (twilson) 2010-03-05 00:40:34.000-0600

I just tested fix_sonus_dtmf_patch.txt against the 1.4 branch and it applied cleanly. If it doesn't apply against 1.4.26.1, then look at the chan_sip.c.rej file to see what is missing. most likely you will just need to add the definition to the end of the sip_pvt structure as mentioned above. 1.4.29.1 is out, so I would recommend doing that. We don't generally port patches back to older releases.
By: Terry Wilson (twilson) 2010-03-24 21:45:53

Anybody?
By: Jamuel Starkey (jamuel) 2010-03-25 00:08:04

Terry:

I tried patching against a clean 1.6.1.18 and got the following error (after adding your addition to struct sip_pvt:

patching file channels/chan_sip.c
Hunk #1 FAILED at 1064.
Hunk #2 succeeded at 5965 (offset 1934 lines).
Hunk #3 succeeded at 4060 (offset 1 line).
1 out of 3 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
patching file main/rtp.c
Hunk #1 succeeded at 3579 (offset 872 lines).

Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c (revision 248348)
+++ channels/chan_sip.c (working copy)
@@ -1064,6 +1064,7 @@
        * The large-scale changes would be a good idea for implementing during an SDP rewrite.
        */
       struct offered_media offered_media[3];
+       struct ast_silence_generator *gen;
} *iflist = NULL;


chan_sip.c in 1.6.1.18 already looks like this starting at line 1402:
        * The large-scale changes would be a good idea for implementing during an SDP rewrite.
        */
       struct offered_media offered_media[4];
       struct ast_silence_generator *gen;
};

Safe to assume I'm good to go by ignoring that failed hunk?

chan_sip.c and rtp.c both compile cleanly.

Please advise.
By: Terry Wilson (twilson) 2010-03-25 08:56:12

That's weird, because that line definitely isn't in a fresh download of 1.6.1.18. But, if that was all that failed...eh, try it. Make sure to set transmit_silence in asterisk.conf (and make sure that [options] is uncommented too).
By: Jamuel Starkey (jamuel) 2010-03-25 17:36:31

If you care 1.6.1.18 was downloaded directly from http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-1.6.1.18.tar.gz

# cat asterisk-1.6.1.18.tar.gz.sha1
99871bc2257185437c22b7f0e44a09c356ffe027  asterisk-1.6.1.18.tar.gz
# sha1sum asterisk-1.6.1.18.tar.gz
99871bc2257185437c22b7f0e44a09c356ffe027  asterisk-1.6.1.18.tar.gz

In any case testing now . . . will report back asap.
By: Terry Wilson (twilson) 2010-06-01 16:14:22

Jamuel: Did you get to try anything?
By: Jamuel Starkey (jamuel) 2010-06-11 01:08:12

Hi Terry,

Since 1.6.1.x was effectively mothballed we elected to get a baseline from an unmodified 1.6.2 release.

We have extensively tested with an unmodified asterisk 1.6.2.9-rc1 with a Polycom 550 (f/w v 3.2.1) calling thru asterisk via a SIP trunk to DashCS.  We repeatedly dialed known Sonus terminated destinations via Dash's Denver SBC.  In ALL tests we had 100% DMTF detection success compared to testing in 1.6.1 where we saw 100% failures.

That said we believe this issue to be resolved in 1.6.2.9-rc1 with no specific patch required--umodified asterisk 1.6.2.9-rc1 works as-is.  

Do you have any ideas as to what fixes or changes are in 1.6.2.9-rc1 that should be credited for the fix?

Thanks again for all of your help!

JPS
By: Terry Wilson (twilson) 2010-06-11 10:01:33

All of my constantssrc fixes should be in. Other than that, I'm not sure.
By: Erik Smith (eeman) 2010-07-09 10:44:57

just tested 1.6.2.9 and 1.6.2.10-rc1 with a Sonus switch with broadvox and it failed. Attached is a capture file while doing an interop test. the scenario is I am calling another TN where an asterisk box has a READ application that captures the DTMF digits and spits them back:


handset -> [Asterisk 1.6.2.9] -> [Asterisk 1.6.2.9] -> Broadvox Sonus -> PSTN

the testing diagnostic side:
[PSTN via PRI] -> [Asterisk 1.4.26.3] -> READ & SayDigits macro


then I tried:

handset -> [Asterisk 1.6.2.9] -> [Asterisk 1.6.2.10-rc1] -> Broadvox Sonus -> PSTN

after another failure I decided to upgrade everything to 1.6.2.10-rc1

handset -> [Asterisk 1.6.2.10-rc1] -> [Asterisk 1.6.2.10-rc1] -> Broadvox Sonus -> PSTN


In my test I dialed 1 through 9 followed by # twice in the test. If you listen to the media stream with wireshark you will hear the playback and how various digits are just missing.
By: Erik Smith (eeman) 2010-07-09 11:39:04

I have some more updated information which really seems to confuse things more.

my original test handset was an analog phone connected to a TDM800 fxs port .. with this device (where asterisk creates the rfc2833) I experience 100% failure to detect all 9 digits correctly. In almost every test multiple digits are missing. The same device on the same pbx calling out to the asterisk 1.6.26.3 gateway works without issue to both the test macro and the PSTN.

I then conducted the same test from a polycom 501 running firmware 3.1.2, upstairs and had less than 5% failure. Basically out of 20 tests only 1 failure and that was losing a single digit.

I repeated the test once more with a linksys ATA 2102 with firmware 5.2.5 and had more failures, but still only missing 1 digit per 9 digit sequence.

so when the original source is an FXS port on dahdi hardware the failure rate is very very high. When the source is an older model polycom the failure rate is considerably lower (but still not acceptable)

I just ran the test using a Polycom 550 firmware 3.2.2 and out of 10 tests I experienced zero errors. In that scenario it went

polycom550 -> [asterisk 1.4.26.3] -> [asterisk 1.6.2.10-rc1] -> BroadVox SONUS -> PSTN
By: Jamuel Starkey (jamuel) 2010-07-09 13:12:59

Out of curiosity how does your test perform with just a single asterisk box and a Polycom phone:

Polycom550 -> [* 1.6.2.9/1.6.2.10-rc1] -> BroadVox SONUS -> PSTN

If you need a test TN, try:  312-878-0201 it is a GotoMeeting number.  When prompted, dial any digit sequence and then press pound.  The AA will read back the digits.

LMK if you need more GotoMeeting numbers to test.
By: Erik Smith (eeman) 2010-07-09 14:07:41

when I had the polycom550 register to the 1.6.2.10-rc1 gateway server it had 0/10 failures.. ie 100% success.

interestingly enough the linksys ATA always fails on exactly the 7th digit. If I dial 1 through 0 its always 7 that gets dropped. If I dial 0 through 1 its always 4 that gets dropped.
By: Erik Smith (eeman) 2010-07-09 15:54:59

Interestingly enough when we change the Broadvox connection dtmfmode to sip info (forcing my gateway and their sonus gear to transcode) the problem vanishes. I am beginning to think that since all the asterisk boxes engage in Packet2Packet transfers; the RFC2833 packet 'moodiness' is coming from the devices sources more than anything. Of course this puts a new light on the asterisk box with the dahdi channel since dahdi isnt making 2833, that blame falls squarely on asterisk. More curious am I about why the polycom's never have a problem.
By: Terry Wilson (twilson) 2010-10-08 10:41:57

eeman: Do you have rfc2833compensate=no in sip.conf? If not, try it. rfc2833compensate=yes tends to break dtmf for some devices.
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2010-11-29 12:18:34.000-0600

twilson: I've got a customer suffering from the same issues with a Sonus Softswitch. rfc2833compensate doesn't seem to do the trick here. Anyone picking up on this issue? it's been around since 1.6.1.0
By: Terry Wilson (twilson) 2010-11-29 12:40:38.000-0600

greenfieldtech: are you saying you enabled rfc2833compensate? That is what usually causes breakage. Also, there was a recent bug where dtmf was re-broken after the constantssrc fixes went in. I'm not sure of the number right now, but Jeff Peeler was working on it.
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2010-11-29 13:58:40.000-0600

issue can still be observed with compensate enabled or disabled.
By: Bryant Zimmerman (zktech) 2010-12-07 14:07:20.000-0600

I too am having this issue. G729 with features.conf and applicaitons or tT in the Dial command increases the delays. the rfc2833compensate=false did nothing for me. The only way I can work arround this right now is to disable all of the DTMF features.conf I have the issue on both 1.6.2 and 1.8.svn I posted on this bug as well https://issues.asterisk.org/view.php?id=18189 both seem to be related. Any further ideas would be apperciated.
By: Terry Wilson (twilson) 2010-12-07 15:50:13.000-0600

The reason this happens when asterisk is in the middle of the dtmf (tT, features.conf, etc.) is because while rfc2833 DTMF is being received from one side, Asterisk does not send RTP to the other side until we get the end of the dtmf event. Then Sonus sees the gap of > 100ms and freaks out. I attached a patch long ago that generates silence in this case so we don't have the gap, but never got much feedback on it. I'll try to update it (fix_sonus_dtmf.patch.txt on this issue) and re-post if someone promises to give me feedback. ;-)
By: Bryant Zimmerman (zktech) 2010-12-07 16:55:28.000-0600

What kind of feed back do you need?  If it is reliable what will it take to get it into the release versions?  I would like to test it on both 1.6.2 and 1.8 if possible.

Thanks
By: Bryant Zimmerman (zktech) 2010-12-07 17:18:24.000-0600

Is there any easy way to notify cmbaker82 and others that were watching bug 18189 and 18352 so we can pull them in for testing of this to see if it resolves their issues as well. This is big for us and I have been trying to come up with a resoltion for a year now I wish I had found this post sooner.

Also why does the timing issue seem to be worse when using the g729 coder. Is there an issue when transcoding that would compound the issue. This is what I am seeing in my packet captures.

Thanks
By: Terry Wilson (twilson) 2010-12-07 17:41:11.000-0600

The patch isn't quite working, yet. After I post another one, I'll need feedback as to whether it solves the issue. I have no idea why it would be worse with g729 unless that is something on the sonus side of things. The issue will normally be worse the longer someone presses the keys for DTMF, though.
By: Bryant Zimmerman (zktech) 2010-12-08 08:23:23.000-0600

twilson--Ok I will look forward to seeing the patch. I have both a 1.8.SVN server and 1.6.2.14 server I can test on if the patch will work with both. Thanks for your work on this.

Also as I read the info from the summary it says that the patch will send a single g711 packet between dtmf tones. How will this work if the call is up g722, g729 or some other codec? Will the packet be sent in the format of the current audio rtp stream?

As for enabling the dtmfaudiopacketinsert=yes (or what ever it was called) did this get switched to the sip.conf so it could be enabled globaly or per peer?


By: Scott Johnson (globalnetinc) 2010-12-08 12:52:20.000-0600

Gladly do this on Asterisk SVN-branch-1.8-r297909.

I am also on 360Networks Sonus system.
By: Bryant Zimmerman (zktech) 2010-12-10 07:39:21.000-0600

What kind of time frame for the patch to test. I am trying to schedule out through the end of the year and I want to put some time in for testing as this issue is critiacl for me.  Thanks
Bryant
By: Bryant Zimmerman (zktech) 2010-12-23 10:13:56.000-0600

twilson - Just checking in on the status of this. Have a great Holiday.
By: Chris Baker (cmbaker82) 2011-01-06 16:31:06.000-0600

On the client I have that was experiencing the delays I have asterisk 1.6.2.2.  We had even more problems with 1.8.  The problems with 1.8 that we had appear to be resolved in 1.8.2-rc1 so once that is out of RC stage i will be able to upgrade them and test this if you all feel this patch will help with the delays.
By: Bryant Zimmerman (zktech) 2011-01-06 16:44:14.000-0600

cmbaker82 I do not belive there is a new patch for this issue as of yet? Based on the current status listed there does not appear to be anything in the 1.8.2-rc1 for this.
By: Bryant Zimmerman (zktech) 2011-02-07 13:04:43.000-0600

Is there a working patch for this for the 1.8.x builds yet? I need to get this resolved for our clients if possible.
By: Douglas Jensen (djensen99) 2011-02-09 15:31:19.000-0600

Tested existing patch against 1.6.2.16.1 using Broadvox - no luck.  Can help test future versions against 1.6.2 trunk if that would help development, as this is a big issue in our call center environment.
By: Olle Johansson (oej) 2011-02-14 07:05:25.000-0600

I've done a lot of work with DTMF in issue ASTERISK-17329  - please check.
By: Terry Wilson (twilson) 2011-02-23 18:03:54.000-0600

I've uploaded a patch that is a combination of Olle's and my work that should fix this (issue_15652_dtmf_ast-1.4.patch.txt). Currently, I only have the 1.4 version ready. I'll try to get the 1.6.2 version ready for tomorrow.

You will need to enable the transmit_silence option in asterisk.conf.


By: Terry Wilson (twilson) 2011-02-23 19:41:31.000-0600

I have uploaded a version of the patch for 1.6.2 as well. Make sure to enable transmit_silence in asterisk.conf. Also, there was a missing bugfix in 1.6.2, so this patch will only work from branches/1.6.2 r 308677 or above. You should probably be able to apply the patch from r308677 manually for testing as well.
By: Scott Johnson (globalnetinc) 2011-02-23 19:41:42.000-0600

Is there any fix for 1.8?
By: Terry Wilson (twilson) 2011-02-23 20:42:51.000-0600

globalnetinc: now attached. I'm going to stop working for the night, now. :-)  Be sure to test it out for me and let me know if it works as I don't have the equipment to test if this fixes the issue. Looking at capture files, it seems like it should. In case I didn't mention it enough before, set transmit_silence=yes in asterisk.conf. :-)
By: Scott Johnson (globalnetinc) 2011-02-24 09:42:33.000-0600

I have applied the patch to 1.8 SVN-r308679.  It was successful and I have seen on negative side effects.  I will be testing over the next few days.
By: Terry Wilson (twilson) 2011-02-24 09:52:16.000-0600

Was that "no negative side effects" or "one negative side effect"? :-)
By: Ronald Chan (loloski) 2011-02-24 13:03:15.000-0600

Between the two i think it's the former :D
By: Scott Johnson (globalnetinc) 2011-02-24 14:18:24.000-0600

Sorry "NO" negative side effects
By: Douglas Jensen (djensen99) 2011-02-24 14:44:35.000-0600

Have deployed 1.6.2 current SVN and applied the patch to one branch office.  No apparent side effects, but no relief to DTMF issues.  Will deploy locally tomorrow and test further.
By: Terry Wilson (twilson) 2011-02-24 14:52:46.000-0600

djensen99: just checking to make sure that you set transmit_silence=yes in asterisk.conf. Also, if you have issues while running the patch, a pcap file would be appreciated with a single failing call.
By: Terry Wilson (twilson) 2011-02-24 14:55:52.000-0600

Also, the majority of the people experiencing this problem have been those who use DTMF features (use things like the "t" or "T" flags to dial). The issue, as I understand it, has been that while Asterisk is receiving DTMF from the phone, it transmits no RTP at all to the bridged SIP call and some of them freak out if more than 100ms passes without any RTP.
By: Douglas Jensen (djensen99) 2011-02-24 14:57:36.000-0600

r308722M is being used, transmit_silence=yes is set.  However, there are some possible latency conditions with this branch office at present.  Will test tomorrow locally to rule out latency, and provide pcap if problems persist.

Note that we have legacy PBX -> DAHDI/PRI -> SIP (g729) in both configurations.

Also, our provider is Broadvox with the affected Sonus switches.


By: Douglas Jensen (djensen99) 2011-02-28 17:19:43.000-0600

Sorry for the slow response.

Installed r308722M with patch at my local location on Friday, response to DTMF events seems slightly better but does not appear to be fixed.  I captured a call to my bank while keying this CC# (1234567890123456#) and will upload the associated pcap.  First time with packet captures, let me know if it looks good or if more info is needed.

(edit : pcap uploaded)


By: Terry Wilson (twilson) 2011-03-01 16:20:33.000-0600

djensen99: Well, the patch seems to be doing what it is supposed to--there are no gaps in the RTP. The only thing that I can see that isn't perfect would be that after the DTMF is sent it seems like there is one extra packet sent with no delay at all, and the marker bit is properly set, so I wouldn't expect there to be any problem.

From decoding the audio, it sounds like just about every other digit was dropped. I am seeing about 300ms of skew after each DTMF event. If we have a 240ms long DTMF event, the timestamp jumps from 133440 to 137750 which would indicate 540ms in this case (I think). I'll look and see what I can find out about that and will also see if I can get a Broadvox account to test with.
By: Terry Wilson (twilson) 2011-03-02 14:55:48.000-0600

djensen99: I've been testing with a SIP phone registered to an Asterisk box with a broadvox account registered. Without the patch, I get about 50%. With it, it has been 100%. I tested with a couple of numbers one of which is 804-222-1111. Instructions: http://www.testcall.com/222-1111.html.  Basically as soon as it is done reading your 7 digit callerid back, press keys and it reads them back to you (make sure you start before the "testcall.com" announcement which signals that it is hanging up.

I suppose it could be a DAHDI<->SIP-specific issue...

globalnetinc: things still good with your tests?
By: Douglas Jensen (djensen99) 2011-03-02 15:38:28.000-0600

I get the same results as you using a SIP and DAHDI phone with that test number : 100% DTMF recognition.  However, when dialing that original number on my pcap (800-432-1000), the same digit recognition problems happen - looks like it drops every third digit consistently via DAHDI (read back 12457801346 to me 3 calls in a row), and random digits via SIP.


By: Erik Smith (eeman) 2011-03-02 15:46:13.000-0600

my experience with broadvox seemed to always happen on or around the 7th digit. If I were to call up a number that was directly connected to the PSTN (like an asterisk box with a pri) that went to a macro that would collect and read back DTMF, I would use a sequence like 1234567890, usually around 7 or 8 the digit would get skipped entirely. Make sure when you testing you use 10 or more digits. When testing shorter numbers its harder to get failures.

BTW for those on broadvox experiencing pain; we switched to sip info method of DTMF 6mos ago until this issue gets resolved and havent regretted it. The only downside is no Packet2Packet transfers but that has not yet created a problem as we are only 150 - 200 concurrent calls.
By: Terry Wilson (twilson) 2011-03-02 15:48:47.000-0600

Odd. When I call 8004321000, I get 100% on dtmf as well. Something odd is going on anyway. Would you mind either posting or emailing (my username @digium.com) some sanitized config files? I'd be most interested in the [general] and broadvox-related SIP entries, and the Dial command that is being executed to dial out to broadvox.
By: Terry Wilson (twilson) 2011-03-02 15:50:57.000-0600

(for reference, I've been using 16 digits or so to test)
By: Douglas Jensen (djensen99) 2011-03-02 16:12:28.000-0600

Sent you an email to try and keep the comments on-topic here, as our issue might be something separate.

SIP Info completely broke DTMF for us previously with Broadvox, will give it a shot again when I can get some downtime on this system.
By: Erik Smith (eeman) 2011-03-02 16:17:52.000-0600

sip info has to be turned on by broadvox on their switch. Once they convert you to sip info its as simple as editing your sip.conf entry and reloading.
By: Douglas Jensen (djensen99) 2011-03-02 16:29:19.000-0600

That's the piece I was missing!  Thank you!

If twilson can't find anything amiss, will get that change started with them.
By: Scott Johnson (globalnetinc) 2011-03-02 16:47:59.000-0600

The two places I have tested both work now.  I have not found a phone number that does not work yet I have 2 more to try.  i will get those numbers and report back.  We are on a Sonus switch using 360 Networks.
By: JD Erickson (jde) 2011-03-07 18:55:05.000-0600

This patch is working with a reported 100% success rate for all client systems I have rolled it out to, on 1.4 and 1.8 (I don't have any clients running 1.6). Our upstream is 360 Networks.


By: Digium Subversion (svnbot) 2011-03-16 11:58:44

Repository: asterisk
Revision: 310888

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r310888 | twilson | 2011-03-16 11:58:43 -0500 (Wed, 16 Mar 2011) | 29 lines

Don't delay DTMF in core bridge while listening for DTMF features

This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.

When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.

With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.

(closes issue ASTERISK-14589)
Reported by: jasonshugart
Patches:
     issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde

(closes issue ASTERISK-15449)
Reported by: sharvanek

Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=310888
By: Digium Subversion (svnbot) 2011-03-16 12:03:29

Repository: asterisk
Revision: 310889

_U  branches/1.6.2/
U   branches/1.6.2/main/features.c

------------------------------------------------------------------------
r310889 | twilson | 2011-03-16 12:03:29 -0500 (Wed, 16 Mar 2011) | 36 lines

Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
 
 Don't delay DTMF in core bridge while listening for DTMF features
 
 This patch is mostly the work of Olle Johansson. I did some cleanup and
 added the silence generating code if transmit_silence is set.
 
 When a channel listens for DTMF in the core bridge, the outbound DTMF is not
 sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
 send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
 Some products see this delay and the time skew on RTP packets that results and
 start ignoring the audio that is sent afterward.
 
 With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
 a feature code, we wait for DTMF_END and activate the feature as before. If
 transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
 multi-digit feature. If it doesn't match a feature, the frame is forwarded
 along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
 
 (closes issue ASTERISK-14589)
 Reported by: jasonshugart
 Patches:
       issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
 Tested by: globalnetinc, jde
 
 (closes issue ASTERISK-15449)
 Reported by: sharvanek
 
 Review: https://reviewboard.asterisk.org/r/1092/
 Review: https://reviewboard.asterisk.org/r/1125/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=310889
By: Digium Subversion (svnbot) 2011-03-16 12:19:58

Repository: asterisk
Revision: 310902

_U  branches/1.8/
U   branches/1.8/main/features.c

------------------------------------------------------------------------
r310902 | twilson | 2011-03-16 12:19:58 -0500 (Wed, 16 Mar 2011) | 43 lines

Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
 
 Merged revisions 310888 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
   
   Don't delay DTMF in core bridge while listening for DTMF features
   
   This patch is mostly the work of Olle Johansson. I did some cleanup and
   added the silence generating code if transmit_silence is set.
   
   When a channel listens for DTMF in the core bridge, the outbound DTMF is not
   sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
   send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
   Some products see this delay and the time skew on RTP packets that results and
   start ignoring the audio that is sent afterward.
   
   With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
   a feature code, we wait for DTMF_END and activate the feature as before. If
   transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
   multi-digit feature. If it doesn't match a feature, the frame is forwarded
   along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
   
   (closes issue ASTERISK-14589)
   Reported by: jasonshugart
   Patches:
         issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
   Tested by: globalnetinc, jde
   
   (closes issue ASTERISK-15449)
   Reported by: sharvanek
   
   Review: https://reviewboard.asterisk.org/r/1092/
   Review: https://reviewboard.asterisk.org/r/1125/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=310902
By: Digium Subversion (svnbot) 2011-03-16 12:29:17

Repository: asterisk
Revision: 310941

_U  trunk/
U   trunk/main/features.c

------------------------------------------------------------------------
r310941 | twilson | 2011-03-16 12:29:17 -0500 (Wed, 16 Mar 2011) | 50 lines

Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
 
 Merged revisions 310889 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
   
   Merged revisions 310888 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
     
     Don't delay DTMF in core bridge while listening for DTMF features
     
     This patch is mostly the work of Olle Johansson. I did some cleanup and
     added the silence generating code if transmit_silence is set.
     
     When a channel listens for DTMF in the core bridge, the outbound DTMF is not
     sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
     send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
     Some products see this delay and the time skew on RTP packets that results and
     start ignoring the audio that is sent afterward.
     
     With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
     a feature code, we wait for DTMF_END and activate the feature as before. If
     transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
     multi-digit feature. If it doesn't match a feature, the frame is forwarded
     along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
     
     (closes issue ASTERISK-14589)
     Reported by: jasonshugart
     Patches:
           issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
     Tested by: globalnetinc, jde
     
     (closes issue ASTERISK-15449)
     Reported by: sharvanek
     
     Review: https://reviewboard.asterisk.org/r/1092/
     Review: https://reviewboard.asterisk.org/r/1125/
   ........
 ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=310941