Re: [on-asterisk] DTMF RFC283
On Tue, Mar 25, 2008 at 1:13 PM, John Lange [EMAIL PROTECTED] wrote: BTW, if I remember correctly; the problem with Asterisk is that it doesn't set the tone length (or it leaves it at zero or something). Some systems consider this to be invalid so they ignore it but most systems default to the bare minimum DTMF length. Either way this causes problems since even the minimum length is very hard to detect reliably. Ya, in Asterisk 1.2.x, there was no 'length' indicating how long the DTMF was held for (hence the 'variable length' in VLDTMF). Instead it would burst out 3 start DTMF frames, and 3 end DTMF frames (the reason for 3 of them on each was in case one of the frames was dropped since the frames are stateless, and thus do not get an ACK that they were delivered). This was the cause for some people getting duplicate and triplicate DTMF at the far end because each set of start/end DTMF frames were interpreted as individual key presses. VLDTMF largely eliminates this problem. More recent versions of 1.4 have dramatically improved DTMF. Oh the struggles and joys I had debugging Asterisk DTMF until it improved to a usable fashion! -- Leif Madsen. http://www.leifmadsen.com http://www.oreilly.com/catalog/asterisk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[on-asterisk] DTMF RFC283
I have an issue with a carrier and hoping for some feedback. My carrier has been amazing and responsive, but as in any business, there are minor things that arise from time to time The issue I am facing is that RFC2833 does not work on certain numbers, specially government IVRs. This is on Asterisk 1.2.9.1 I then tested the exact same thing RFC2833 on the government numbers in question from my Asterisk 1.4.18It works perfectly. HOWEVER!!! 1. When I use other CDN trunks from 1.2.9.1 Asterisk with RFC2833 it works FINE. 2. When I use Unlimitel it is fine. 3. When I use a dozen other carriers (American), its ALL fine. 4. Regardless of 1.2.9.1 or 1.4.18 RFC2833 works from ALL other carriers. SO. IF ALL other carriers are passing DTMF perfectly from my 1.2.9.1 except for the one in question, then would it be fair to say the problem is the specific carrier which is consistent in failure to transmit DTMF to those government numbers? Or are there other possible scenarios that I may be missing out? The quick fix here is to divert outgoing calls from 1.2.9.1 to the trunks that are 100% on DTMF via RFC2833. Any suggestions is welcome! Best, Reza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [on-asterisk] DTMF RFC283
You may be just running into an issue where your carrier has multiple providers and routes and is shuffling toll free and gov numbers over a trunk with no or poor dtmf. Reza M. Reza wrote: I have an issue with a carrier and hoping for some feedback. My carrier has been amazing and responsive, but as in any business, there are minor things that arise from time to time The issue I am facing is that RFC2833 does not work on certain numbers, specially government IVRs. This is on Asterisk 1.2.9.1 I then tested the exact same thing RFC2833 on the government numbers in question from my Asterisk 1.4.18It works perfectly. HOWEVER!!! 1. When I use other CDN trunks from 1.2.9.1 Asterisk with RFC2833 it works FINE. 2. When I use Unlimitel it is fine. 3. When I use a dozen other carriers (American), its ALL fine. 4. Regardless of 1.2.9.1 or 1.4.18 RFC2833 works from ALL other carriers. SO. IF ALL other carriers are passing DTMF perfectly from my 1.2.9.1 except for the one in question, then would it be fair to say the problem is the specific carrier which is consistent in failure to transmit DTMF to those government numbers? Or are there other possible scenarios that I may be missing out? The quick fix here is to divert outgoing calls from 1.2.9.1 to the trunks that are 100% on DTMF via RFC2833. Any suggestions is welcome! Best, Reza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [on-asterisk] DTMF RFC283
There is also another possible scenario, that is your provider may have multiple asterisk boxs and may be running in a mixed environment of 1.2 and 1.4. Adding on the 1.4 box rfc2833compensate=yes (to the customer/user profile), fixes many dtmf issues when talking to a 1.2 platform. Reza M. Reza wrote: I have an issue with a carrier and hoping for some feedback. My carrier has been amazing and responsive, but as in any business, there are minor things that arise from time to time The issue I am facing is that RFC2833 does not work on certain numbers, specially government IVRs. This is on Asterisk 1.2.9.1 I then tested the exact same thing RFC2833 on the government numbers in question from my Asterisk 1.4.18It works perfectly. HOWEVER!!! 1. When I use other CDN trunks from 1.2.9.1 Asterisk with RFC2833 it works FINE. 2. When I use Unlimitel it is fine. 3. When I use a dozen other carriers (American), its ALL fine. 4. Regardless of 1.2.9.1 or 1.4.18 RFC2833 works from ALL other carriers. SO. IF ALL other carriers are passing DTMF perfectly from my 1.2.9.1 except for the one in question, then would it be fair to say the problem is the specific carrier which is consistent in failure to transmit DTMF to those government numbers? Or are there other possible scenarios that I may be missing out? The quick fix here is to divert outgoing calls from 1.2.9.1 to the trunks that are 100% on DTMF via RFC2833. Any suggestions is welcome! Best, Reza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [on-asterisk] DTMF RFC283
Is the carrier capable of doing a packet capture on their end to make sure they are getting the DTMF from you correctly?. It would be interesting to find out where the DTMF is breaking? Are you able to do one from your box (or a mirrored switchport if you don't like running packet traces on a production box) to make sure you are transmitting it correctly to that carrier? - Original Message - From: Reza M. Reza [EMAIL PROTECTED] To: asterisk@uc.org Sent: Tuesday, March 25, 2008 12:36 PM Subject: [on-asterisk] DTMF RFC283 I have an issue with a carrier and hoping for some feedback. My carrier has been amazing and responsive, but as in any business, there are minor things that arise from time to time The issue I am facing is that RFC2833 does not work on certain numbers, specially government IVRs. This is on Asterisk 1.2.9.1 I then tested the exact same thing RFC2833 on the government numbers in question from my Asterisk 1.4.18It works perfectly. HOWEVER!!! 1. When I use other CDN trunks from 1.2.9.1 Asterisk with RFC2833 it works FINE. 2. When I use Unlimitel it is fine. 3. When I use a dozen other carriers (American), its ALL fine. 4. Regardless of 1.2.9.1 or 1.4.18 RFC2833 works from ALL other carriers. SO. IF ALL other carriers are passing DTMF perfectly from my 1.2.9.1 except for the one in question, then would it be fair to say the problem is the specific carrier which is consistent in failure to transmit DTMF to those government numbers? Or are there other possible scenarios that I may be missing out? The quick fix here is to divert outgoing calls from 1.2.9.1 to the trunks that are 100% on DTMF via RFC2833. Any suggestions is welcome! Best, Reza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [on-asterisk] DTMF RFC283
Thanks Phil for the valuable input! Hopefully others can also provide some input as to their experience, after which I will decide my alternatives. Thanks! Reza. There is also another possible scenario, that is your provider may have multiple asterisk boxs and may be running in a mixed environment of 1.2 and 1.4. Adding on the 1.4 box rfc2833compensate=yes (to the customer/user profile), fixes many dtmf issues when talking to a 1.2 platform. Reza M. Reza wrote: I have an issue with a carrier and hoping for some feedback. My carrier has been amazing and responsive, but as in any business, there are minor things that arise from time to time The issue I am facing is that RFC2833 does not work on certain numbers, specially government IVRs. This is on Asterisk 1.2.9.1 I then tested the exact same thing RFC2833 on the government numbers in question from my Asterisk 1.4.18It works perfectly. HOWEVER!!! 1. When I use other CDN trunks from 1.2.9.1 Asterisk with RFC2833 it works FINE. 2. When I use Unlimitel it is fine. 3. When I use a dozen other carriers (American), its ALL fine. 4. Regardless of 1.2.9.1 or 1.4.18 RFC2833 works from ALL other carriers. SO. IF ALL other carriers are passing DTMF perfectly from my 1.2.9.1 except for the one in question, then would it be fair to say the problem is the specific carrier which is consistent in failure to transmit DTMF to those government numbers? Or are there other possible scenarios that I may be missing out? The quick fix here is to divert outgoing calls from 1.2.9.1 to the trunks that are 100% on DTMF via RFC2833. Any suggestions is welcome! Best, Reza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [on-asterisk] DTMF RFC283
In a normal troubleshooting scenario, when you have proved it works in all situations except one, then it would be the one that is at fault. That would be the normal case. However, we are talking about Asterisk ;) DTMF has been very problematic in Asterisk for a long time and there are various interpretations and implementations of RFC2833. What I suspect you have encountered is your carrier has a particular SIP switch which is not compatible with the RFC2833 implementation as implemented in Asterisk 1.2.x. Actually, I'm surprised that it works with Unlimitel. Their switches used to require a manual patch to Asterisk 1.2.X in order to work properly but perhaps they have recently implemented a work around so that Asterisk 1.2.X works? And I suspect the other carriers have done the same which is why it works with most of them. So the short answer is, Asterisk 1.2.9.1 is probably at fault but since so many people use Asterisk most carriers have implemented a work-around. BTW, if I remember correctly; the problem with Asterisk is that it doesn't set the tone length (or it leaves it at zero or something). Some systems consider this to be invalid so they ignore it but most systems default to the bare minimum DTMF length. Either way this causes problems since even the minimum length is very hard to detect reliably. More recent versions of 1.4 have dramatically improved DTMF. John On Tue, 2008-03-25 at 12:36 -0400, Reza M. Reza wrote: I have an issue with a carrier and hoping for some feedback. My carrier has been amazing and responsive, but as in any business, there are minor things that arise from time to time The issue I am facing is that RFC2833 does not work on certain numbers, specially government IVRs. This is on Asterisk 1.2.9.1 I then tested the exact same thing RFC2833 on the government numbers in question from my Asterisk 1.4.18It works perfectly. HOWEVER!!! 1. When I use other CDN trunks from 1.2.9.1 Asterisk with RFC2833 it works FINE. 2. When I use Unlimitel it is fine. 3. When I use a dozen other carriers (American), its ALL fine. 4. Regardless of 1.2.9.1 or 1.4.18 RFC2833 works from ALL other carriers. SO. IF ALL other carriers are passing DTMF perfectly from my 1.2.9.1 except for the one in question, then would it be fair to say the problem is the specific carrier which is consistent in failure to transmit DTMF to those government numbers? Or are there other possible scenarios that I may be missing out? The quick fix here is to divert outgoing calls from 1.2.9.1 to the trunks that are 100% on DTMF via RFC2833. Any suggestions is welcome! Best, Reza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
