[asterisk-users] double DTMF digits
Hi, I've been getting complaints lately that callers to my IVR are pressing a digit once but the system is responding as if they pressed it twice (once for each of two consecutive menus). I'm using an AGI script and logging all DTMF entries - and to the script, at least, it looks like the digit is being pressed twice. The TN being called is a VOIP number (provided by Flowroute) and being forwarded via SIP to my asterisk 1.6.2.4 server. The dtmfmode is set to rfc28333 in sip.conf. The first time this happened, I figured the caller pressed the number twice without realizing it. It's happening to too many people for that to be plausible anymore. I also experienced it once myself, months ago, when I entered my tn as 1234567890 and had it read back to me as 1122334455. Can anyone give me some pointers where to start troubleshooting? Can overloading a system cause such an error? Thanks, Mira -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] double DTMF digits
On 8/26/2010 2:55 PM, M S wrote: Hi, I've been getting complaints lately that callers to my IVR are pressing a digit once but the system is responding as if they pressed it twice (once for each of two consecutive menus). I'm using an AGI script and logging all DTMF entries - and to the script, at least, it looks like the digit is being pressed twice. The TN being called is a VOIP number (provided by Flowroute) and being forwarded via SIP to my asterisk 1.6.2.4 server. The dtmfmode is set to rfc28333 in sip.conf. The first time this happened, I figured the caller pressed the number twice without realizing it. It's happening to too many people for that to be plausible anymore. I also experienced it once myself, months ago, when I entered my tn as 1234567890 and had it read back to me as 1122334455. Can anyone give me some pointers where to start troubleshooting? Can overloading a system cause such an error? Thanks, I have seen this before. Upon careful analisys we saw that the far end was sending the digits in RFC2833 plus SIP INFO (or Inband, I can't remember). Thus Asterisk detected double digits. The solution was to ask the remote end to only send RFC2833. Andres http://www.telesip.net -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] double DTMF digits
We've actually had issues with Flowroute in the past where DTMF was a constant issue. My best suggestion for course of action is find another provider. NexVortex is pretty solid all around. They also had the quickest recourse for when GNAPS went bottoms up last month and sent pretty much all VoIP traffic in New England into a tailspin. --Matt On Thu, Aug 26, 2010 at 3:23 PM, Andres and...@telesip.net wrote: On 8/26/2010 2:55 PM, M S wrote: Hi, I've been getting complaints lately that callers to my IVR are pressing a digit once but the system is responding as if they pressed it twice (once for each of two consecutive menus). I'm using an AGI script and logging all DTMF entries - and to the script, at least, it looks like the digit is being pressed twice. The TN being called is a VOIP number (provided by Flowroute) and being forwarded via SIP to my asterisk 1.6.2.4 server. The dtmfmode is set to rfc28333 in sip.conf. The first time this happened, I figured the caller pressed the number twice without realizing it. It's happening to too many people for that to be plausible anymore. I also experienced it once myself, months ago, when I entered my tn as 1234567890 and had it read back to me as 1122334455. Can anyone give me some pointers where to start troubleshooting? Can overloading a system cause such an error? Thanks, I have seen this before. Upon careful analisys we saw that the far end was sending the digits in RFC2833 plus SIP INFO (or Inband, I can't remember). Thus Asterisk detected double digits. The solution was to ask the remote end to only send RFC2833. Andres http://www.telesip.net -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] double DTMF digits
How were you able to determine that the far end was sending the digits in RFC2833 plus SIP INFO? On Thu, Aug 26, 2010 at 3:23 PM, Andres and...@telesip.net wrote: I have seen this before. Upon careful analisys we saw that the far end was sending the digits in RFC2833 plus SIP INFO (or Inband, I can't remember). Thus Asterisk detected double digits. The solution was to ask the remote end to only send RFC2833. Andres http://www.telesip.net -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits
On Sun, 2007-05-13 at 20:54 +0300, Dovid B wrote: I am actually getting DTMF over SIP when people call in to a clients system that is running a2billing. They are using RFC2833. If you are using a Cisco router anywhere in the loop, there is a known bug that causes rfc2833 and inband signalling to cause double DTMF. It is fixed in IOS 12.4.11T ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits
I am actually getting DTMF over SIP when people call in to a clients system that is running a2billing. They are using RFC2833. - Original Message - From: Remi Quezada [EMAIL PROTECTED] To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Wednesday, May 09, 2007 6:15 PM Subject: Re: [asterisk-users] Double DTMF digits I wonder if your hardware is doing the actual DTMF detecting. What hardware are you using? I'm using the TE205P and I believe that the DTMF detection is being done in the software in my case. Remi Steve Davies wrote: On 5/3/07, Ken Leland III [EMAIL PROTECTED] wrote: When dtmfmode is set to inband for SIP, and i originate a call from sip out to the PSTN, I can hear the DTMF digit twice in the audio stream. Once very briefly and once for normal duration. Our Theory: While Asterisk is parsing the DTMF, for a fraction of a second, while the end user generated DTMF is being detected, the DTMF is passed inband. Once the DTMF is detected Asterisk silences it and regenerates it. Sensitive machines like auto attendants pick up both the brief end user generated tone as well as the full length asterisk generated tone and ultimately perceive each digit twice. Is anyone else experiencing this? I have reproduced this in an environment * with one asterisk server that is both the feature server and the media gateway, and is timing off of network T1s * with two servers, one feature server (timing off of ztdummy) and one media gateway (timing off of network T1s) using IAX as the inter asterisk protocol It is pretty easy to reproduce: -Dial a PSTN number(like your cell) from a sip phone using inband DTMF, and configured in asterisk sip.conf with dtmfmode=inband. -Answer the PSTN end. -Press and hold a digit on the sip phone. On the PSTN phone you will hear a very brief, end user generated, tone. -Let go of the digit on the sip phone. On the PSTN phone you will hear the asterisk generated tone. Can anyone else hear the brief initial tone? Any help is greatly appreciated! Yes, we have a similar issue, but do not normally use inband DTMF because SIP phones very cleanly generate rfc2833 RTP packets directly and remove this issue. On the other hand, asterisk is not alone dealing with this issue in SIP. The Linksys ATAs have exactly the same issue. Strangely, I do not have a problem receiving inband DTMF through Zaptel, which I believe uses the same DSP code for DTMF detection... Or does it? Steve ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits
I wonder if the your hardware is doing the actual DTMF detecting. What hardware are you using? I'm using the TE205P and I believe that the DTMF detection is being done in the software. Remi Steve Davies wrote: On 5/3/07, Ken Leland III [EMAIL PROTECTED] wrote: When dtmfmode is set to inband for SIP, and i originate a call from sip out to the PSTN, I can hear the DTMF digit twice in the audio stream. Once very briefly and once for normal duration. Our Theory: While Asterisk is parsing the DTMF, for a fraction of a second, while the end user generated DTMF is being detected, the DTMF is passed inband. Once the DTMF is detected Asterisk silences it and regenerates it. Sensitive machines like auto attendants pick up both the brief end user generated tone as well as the full length asterisk generated tone and ultimately perceive each digit twice. Is anyone else experiencing this? I have reproduced this in an environment * with one asterisk server that is both the feature server and the media gateway, and is timing off of network T1s * with two servers, one feature server (timing off of ztdummy) and one media gateway (timing off of network T1s) using IAX as the inter asterisk protocol It is pretty easy to reproduce: -Dial a PSTN number(like your cell) from a sip phone using inband DTMF, and configured in asterisk sip.conf with dtmfmode=inband. -Answer the PSTN end. -Press and hold a digit on the sip phone. On the PSTN phone you will hear a very brief, end user generated, tone. -Let go of the digit on the sip phone. On the PSTN phone you will hear the asterisk generated tone. Can anyone else hear the brief initial tone? Any help is greatly appreciated! Yes, we have a similar issue, but do not normally use inband DTMF because SIP phones very cleanly generate rfc2833 RTP packets directly and remove this issue. On the other hand, asterisk is not alone dealing with this issue in SIP. The Linksys ATAs have exactly the same issue. Strangely, I do not have a problem receiving inband DTMF through Zaptel, which I believe uses the same DSP code for DTMF detection... Or does it? Steve ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits
I wonder if your hardware is doing the actual DTMF detecting. What hardware are you using? I'm using the TE205P and I believe that the DTMF detection is being done in the software in my case. Remi Steve Davies wrote: On 5/3/07, Ken Leland III [EMAIL PROTECTED] wrote: When dtmfmode is set to inband for SIP, and i originate a call from sip out to the PSTN, I can hear the DTMF digit twice in the audio stream. Once very briefly and once for normal duration. Our Theory: While Asterisk is parsing the DTMF, for a fraction of a second, while the end user generated DTMF is being detected, the DTMF is passed inband. Once the DTMF is detected Asterisk silences it and regenerates it. Sensitive machines like auto attendants pick up both the brief end user generated tone as well as the full length asterisk generated tone and ultimately perceive each digit twice. Is anyone else experiencing this? I have reproduced this in an environment * with one asterisk server that is both the feature server and the media gateway, and is timing off of network T1s * with two servers, one feature server (timing off of ztdummy) and one media gateway (timing off of network T1s) using IAX as the inter asterisk protocol It is pretty easy to reproduce: -Dial a PSTN number(like your cell) from a sip phone using inband DTMF, and configured in asterisk sip.conf with dtmfmode=inband. -Answer the PSTN end. -Press and hold a digit on the sip phone. On the PSTN phone you will hear a very brief, end user generated, tone. -Let go of the digit on the sip phone. On the PSTN phone you will hear the asterisk generated tone. Can anyone else hear the brief initial tone? Any help is greatly appreciated! Yes, we have a similar issue, but do not normally use inband DTMF because SIP phones very cleanly generate rfc2833 RTP packets directly and remove this issue. On the other hand, asterisk is not alone dealing with this issue in SIP. The Linksys ATAs have exactly the same issue. Strangely, I do not have a problem receiving inband DTMF through Zaptel, which I believe uses the same DSP code for DTMF detection... Or does it? Steve ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits
On 5/3/07, Ken Leland III [EMAIL PROTECTED] wrote: When dtmfmode is set to inband for SIP, and i originate a call from sip out to the PSTN, I can hear the DTMF digit twice in the audio stream. Once very briefly and once for normal duration. Our Theory: While Asterisk is parsing the DTMF, for a fraction of a second, while the end user generated DTMF is being detected, the DTMF is passed inband. Once the DTMF is detected Asterisk silences it and regenerates it. Sensitive machines like auto attendants pick up both the brief end user generated tone as well as the full length asterisk generated tone and ultimately perceive each digit twice. Is anyone else experiencing this? I have reproduced this in an environment * with one asterisk server that is both the feature server and the media gateway, and is timing off of network T1s * with two servers, one feature server (timing off of ztdummy) and one media gateway (timing off of network T1s) using IAX as the inter asterisk protocol It is pretty easy to reproduce: -Dial a PSTN number(like your cell) from a sip phone using inband DTMF, and configured in asterisk sip.conf with dtmfmode=inband. -Answer the PSTN end. -Press and hold a digit on the sip phone. On the PSTN phone you will hear a very brief, end user generated, tone. -Let go of the digit on the sip phone. On the PSTN phone you will hear the asterisk generated tone. Can anyone else hear the brief initial tone? Any help is greatly appreciated! Yes, we have a similar issue, but do not normally use inband DTMF because SIP phones very cleanly generate rfc2833 RTP packets directly and remove this issue. On the other hand, asterisk is not alone dealing with this issue in SIP. The Linksys ATAs have exactly the same issue. Strangely, I do not have a problem receiving inband DTMF through Zaptel, which I believe uses the same DSP code for DTMF detection... Or does it? Steve ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits sent on IAX native bridge
This is very interesting. I am now getting this double-digit behaviour occasionally, and only on IAX channels (so far). Did anyone come up with a solution or a way to improve matters? The scenario where I get this is: PSTN - Provider - IAX - Gateway - IAX - Customer So I will go and do some debugging to see where the extra packets are generated. Perhaps a simple change to prevent DTMF audio-tone detection on a channel that supports RFC or out-of-band DTMF transmission? Or perhaps some sort of DTMF debounce mechanism? Thanks, Steve On 3/6/07, Remi Quezada [EMAIL PROTECTED] wrote: Any ideas as to how I can fix this issue? Thanks Remi Remi Quezada wrote: Ok that makes sense, but I'm still getting double digits. It seems to me that the DTMF digit is getting detected too late. When the digit is pressed it seems like asterisk is passing the DTMF digit for a fraction of a second through the audio path and then sends the digit for however long your toneduration is set for. I can hear this happening when I dial the digits myself, I hear some kind sound being cut off for a fraction of a second and then hear the DTMF tone pass. So I guess this is why sometimes some answer machines are detecting double digits. Russell Bryant wrote: Remi Quezada wrote: I have two asterisk servers one is connected to the PSTN and the other one is connected to SIP users. The two servers connect with each other using IAX. When I have an incoming call from PSTN to the asterisk servers and have a forward to go back out to the PSTN the two IAX channel bridge together. Now every time I dial a DTMF digit, the asterisk is sending two DTMF digits. I enable debugging for iax and I do see it sending the DTMF digits two times. Here is what I see: The IAX debug that you show below only shows one of each digit. For each one, it shows Receiving the digit from one leg of the call, and then transmitting it out the other. I have spaced out your debug to separate each digit. Each one shows ... - digit - ACK - - digit --- ACK -- which is exactly what is supposed to happen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits sent on IAX native bridge
Replying to my own post... Even more interesting is that the issue seems to be caused by the Linksys ATAs that I am using to test with. If I use a mobile phone, a landline, or a digital phone to originate the call, all seems happy. If I use an ATA, it leaves just enough of the original DTMF in the audio stream to be detectable by Asterisk, but it ALSO sends an rfc2833 packet and both are detected and sent onwards! I would still be interested in any ways to improve this! Thanks, Steve On 5/3/07, Steve Davies [EMAIL PROTECTED] wrote: This is very interesting. I am now getting this double-digit behaviour occasionally, and only on IAX channels (so far). Did anyone come up with a solution or a way to improve matters? The scenario where I get this is: PSTN - Provider - IAX - Gateway - IAX - Customer So I will go and do some debugging to see where the extra packets are generated. Perhaps a simple change to prevent DTMF audio-tone detection on a channel that supports RFC or out-of-band DTMF transmission? Or perhaps some sort of DTMF debounce mechanism? Thanks, Steve On 3/6/07, Remi Quezada [EMAIL PROTECTED] wrote: Any ideas as to how I can fix this issue? Thanks Remi Remi Quezada wrote: Ok that makes sense, but I'm still getting double digits. It seems to me that the DTMF digit is getting detected too late. When the digit is pressed it seems like asterisk is passing the DTMF digit for a fraction of a second through the audio path and then sends the digit for however long your toneduration is set for. I can hear this happening when I dial the digits myself, I hear some kind sound being cut off for a fraction of a second and then hear the DTMF tone pass. So I guess this is why sometimes some answer machines are detecting double digits. Russell Bryant wrote: Remi Quezada wrote: I have two asterisk servers one is connected to the PSTN and the other one is connected to SIP users. The two servers connect with each other using IAX. When I have an incoming call from PSTN to the asterisk servers and have a forward to go back out to the PSTN the two IAX channel bridge together. Now every time I dial a DTMF digit, the asterisk is sending two DTMF digits. I enable debugging for iax and I do see it sending the DTMF digits two times. Here is what I see: The IAX debug that you show below only shows one of each digit. For each one, it shows Receiving the digit from one leg of the call, and then transmitting it out the other. I have spaced out your debug to separate each digit. Each one shows ... - digit - ACK - - digit --- ACK -- which is exactly what is supposed to happen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Double DTMF digits
When dtmfmode is set to inband for SIP, and i originate a call from sip out to the PSTN, I can hear the DTMF digit twice in the audio stream. Once very briefly and once for normal duration. Our Theory: While Asterisk is parsing the DTMF, for a fraction of a second, while the end user generated DTMF is being detected, the DTMF is passed inband. Once the DTMF is detected Asterisk silences it and regenerates it. Sensitive machines like auto attendants pick up both the brief end user generated tone as well as the full length asterisk generated tone and ultimately perceive each digit twice. Is anyone else experiencing this? I have reproduced this in an environment * with one asterisk server that is both the feature server and the media gateway, and is timing off of network T1s * with two servers, one feature server (timing off of ztdummy) and one media gateway (timing off of network T1s) using IAX as the inter asterisk protocol It is pretty easy to reproduce: -Dial a PSTN number(like your cell) from a sip phone using inband DTMF, and configured in asterisk sip.conf with dtmfmode=inband. -Answer the PSTN end. -Press and hold a digit on the sip phone. On the PSTN phone you will hear a very brief, end user generated, tone. -Let go of the digit on the sip phone. On the PSTN phone you will hear the asterisk generated tone. Can anyone else hear the brief initial tone? Any help is greatly appreciated! There is a good wiki article on DTMF: http://www.voip-info.org/wiki/view/Asterisk+DTMF and there has been a thread about it on this mailing list: http://lists.digium.com/pipermail/asterisk-users/2007-March/181461.html We have opened a bug report: http://bugs.digium.com/view.php?id=9382 Some System Specifications: Asterisk 1.2.14 Digium Wildcard TE405P/TE410P CentOS release 4.4 (Final) -- Ken W. Leland III Engineering [EMAIL PROTECTED] Monmouth Telecom 10 Drs. James Parker Blvd., Suite 110 Red Bank, NJ 07701 732-704-1000 X283 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits sent on IAX native bridge
Any ideas as to how I can fix this issue? Thanks Remi Remi Quezada wrote: Ok that makes sense, but I'm still getting double digits. It seems to me that the DTMF digit is getting detected too late. When the digit is pressed it seems like asterisk is passing the DTMF digit for a fraction of a second through the audio path and then sends the digit for however long your toneduration is set for. I can hear this happening when I dial the digits myself, I hear some kind sound being cut off for a fraction of a second and then hear the DTMF tone pass. So I guess this is why sometimes some answer machines are detecting double digits. Russell Bryant wrote: Remi Quezada wrote: I have two asterisk servers one is connected to the PSTN and the other one is connected to SIP users. The two servers connect with each other using IAX. When I have an incoming call from PSTN to the asterisk servers and have a forward to go back out to the PSTN the two IAX channel bridge together. Now every time I dial a DTMF digit, the asterisk is sending two DTMF digits. I enable debugging for iax and I do see it sending the DTMF digits two times. Here is what I see: The IAX debug that you show below only shows one of each digit. For each one, it shows Receiving the digit from one leg of the call, and then transmitting it out the other. I have spaced out your debug to separate each digit. Each one shows ... - digit - ACK - - digit --- ACK -- which is exactly what is supposed to happen. Rx-Frame Retry[ No] -- OSeqno: 018 ISeqno: 021 Type: DTMFSubclass: 1 Timestamp: 51523ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 019 Type: IAX Subclass: ACK Timestamp: 51523ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 019 ISeqno: 022 Type: DTMFSubclass: 1 Timestamp: 51543ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 51543ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 019 ISeqno: 021 Type: DTMFSubclass: 2 Timestamp: 52083ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 52083ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 020 ISeqno: 022 Type: DTMFSubclass: 2 Timestamp: 52103ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52103ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 020 ISeqno: 021 Type: DTMFSubclass: 3 Timestamp: 52663ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52663ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 021 ISeqno: 022 Type: DTMFSubclass: 3 Timestamp: 52683ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 52683ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 021 ISeqno: 021 Type: DTMFSubclass: 4 Timestamp: 53223ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 53223ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 022 ISeqno: 022 Type: DTMFSubclass: 4 Timestamp: 53243ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53243ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: DTMFSubclass: 5 Timestamp: 53703ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53703ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 023 ISeqno: 022 Type: DTMFSubclass: 5 Timestamp: 53723ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 53723ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 023 ISeqno: 021 Type: DTMFSubclass: 6 Timestamp: 54163ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 54163ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 024 ISeqno: 022
Re: [asterisk-users] Double DTMF digits sent on IAX native bridge
Ok that makes sense, but I'm still getting double digits. It seems to me that the DTMF digit is getting detected too late. When the digit is pressed it seems like asterisk is passing the DTMF digit for a fraction of a second through the audio path and then sends the digit for however long your toneduration is set for. I can hear this happening when I dial the digits myself, I hear some kind sound being cut off for a fraction of a second and then hear the DTMF tone pass. So I guess this is why sometimes some answer machines are detecting double digits. Russell Bryant wrote: Remi Quezada wrote: I have two asterisk servers one is connected to the PSTN and the other one is connected to SIP users. The two servers connect with each other using IAX. When I have an incoming call from PSTN to the asterisk servers and have a forward to go back out to the PSTN the two IAX channel bridge together. Now every time I dial a DTMF digit, the asterisk is sending two DTMF digits. I enable debugging for iax and I do see it sending the DTMF digits two times. Here is what I see: The IAX debug that you show below only shows one of each digit. For each one, it shows Receiving the digit from one leg of the call, and then transmitting it out the other. I have spaced out your debug to separate each digit. Each one shows ... - digit - ACK - - digit --- ACK -- which is exactly what is supposed to happen. Rx-Frame Retry[ No] -- OSeqno: 018 ISeqno: 021 Type: DTMFSubclass: 1 Timestamp: 51523ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 019 Type: IAX Subclass: ACK Timestamp: 51523ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 019 ISeqno: 022 Type: DTMFSubclass: 1 Timestamp: 51543ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 51543ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 019 ISeqno: 021 Type: DTMFSubclass: 2 Timestamp: 52083ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 52083ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 020 ISeqno: 022 Type: DTMFSubclass: 2 Timestamp: 52103ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52103ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 020 ISeqno: 021 Type: DTMFSubclass: 3 Timestamp: 52663ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52663ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 021 ISeqno: 022 Type: DTMFSubclass: 3 Timestamp: 52683ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 52683ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 021 ISeqno: 021 Type: DTMFSubclass: 4 Timestamp: 53223ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 53223ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 022 ISeqno: 022 Type: DTMFSubclass: 4 Timestamp: 53243ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53243ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: DTMFSubclass: 5 Timestamp: 53703ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53703ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 023 ISeqno: 022 Type: DTMFSubclass: 5 Timestamp: 53723ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 53723ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 023 ISeqno: 021 Type: DTMFSubclass: 6 Timestamp: 54163ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 54163ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 024 ISeqno: 022 Type: DTMFSubclass: 6 Timestamp: 54183ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 025 Type: IAX
[asterisk-users] Double DTMF digits sent on IAX native bridge
Hi, I have two asterisk servers one is connected to the PSTN and the other one is connected to SIP users. The two servers connect with each other using IAX. When I have an incoming call from PSTN to the asterisk servers and have a forward to go back out to the PSTN the two IAX channel bridge together. Now every time I dial a DTMF digit, the asterisk is sending two DTMF digits. I enable debugging for iax and I do see it sending the DTMF digits two times. Here is what I see: Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 019 Type: IAX Subclass: ACK Timestamp: 50018ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 018 ISeqno: 021 Type: DTMFSubclass: 1 Timestamp: 51523ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 019 Type: IAX Subclass: ACK Timestamp: 51523ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 019 ISeqno: 022 Type: DTMFSubclass: 1 Timestamp: 51543ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 51543ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 019 ISeqno: 021 Type: DTMFSubclass: 2 Timestamp: 52083ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 52083ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 020 ISeqno: 022 Type: DTMFSubclass: 2 Timestamp: 52103ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52103ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 020 ISeqno: 021 Type: DTMFSubclass: 3 Timestamp: 52663ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52663ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 021 ISeqno: 022 Type: DTMFSubclass: 3 Timestamp: 52683ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 52683ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 021 ISeqno: 021 Type: DTMFSubclass: 4 Timestamp: 53223ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 53223ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 022 ISeqno: 022 Type: DTMFSubclass: 4 Timestamp: 53243ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53243ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: DTMFSubclass: 5 Timestamp: 53703ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53703ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 023 ISeqno: 022 Type: DTMFSubclass: 5 Timestamp: 53723ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 53723ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 023 ISeqno: 021 Type: DTMFSubclass: 6 Timestamp: 54163ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 54163ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 024 ISeqno: 022 Type: DTMFSubclass: 6 Timestamp: 54183ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 025 Type: IAX Subclass: ACK Timestamp: 54183ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Any ideas on how I can fix this so it only detects one? I've tried relaxing the DTMF detect, but that didn't seem to work. This is only happening when the two IAX channel bridge together. If I have a call terminating to a SIP user or the PSTN and dial any digit it detects it only once. I verified this by turning on iax debugging also. Thanks Remi ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Double DTMF digits sent on IAX native bridge
Remi Quezada wrote: I have two asterisk servers one is connected to the PSTN and the other one is connected to SIP users. The two servers connect with each other using IAX. When I have an incoming call from PSTN to the asterisk servers and have a forward to go back out to the PSTN the two IAX channel bridge together. Now every time I dial a DTMF digit, the asterisk is sending two DTMF digits. I enable debugging for iax and I do see it sending the DTMF digits two times. Here is what I see: The IAX debug that you show below only shows one of each digit. For each one, it shows Receiving the digit from one leg of the call, and then transmitting it out the other. I have spaced out your debug to separate each digit. Each one shows ... - digit - ACK - - digit --- ACK -- which is exactly what is supposed to happen. Rx-Frame Retry[ No] -- OSeqno: 018 ISeqno: 021 Type: DTMFSubclass: 1 Timestamp: 51523ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 019 Type: IAX Subclass: ACK Timestamp: 51523ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 019 ISeqno: 022 Type: DTMFSubclass: 1 Timestamp: 51543ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 51543ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 019 ISeqno: 021 Type: DTMFSubclass: 2 Timestamp: 52083ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 020 Type: IAX Subclass: ACK Timestamp: 52083ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 020 ISeqno: 022 Type: DTMFSubclass: 2 Timestamp: 52103ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52103ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 020 ISeqno: 021 Type: DTMFSubclass: 3 Timestamp: 52663ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 021 Type: IAX Subclass: ACK Timestamp: 52663ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 021 ISeqno: 022 Type: DTMFSubclass: 3 Timestamp: 52683ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 52683ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 021 ISeqno: 021 Type: DTMFSubclass: 4 Timestamp: 53223ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 022 Type: IAX Subclass: ACK Timestamp: 53223ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 022 ISeqno: 022 Type: DTMFSubclass: 4 Timestamp: 53243ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53243ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 021 Type: DTMFSubclass: 5 Timestamp: 53703ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 023 Type: IAX Subclass: ACK Timestamp: 53703ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 023 ISeqno: 022 Type: DTMFSubclass: 5 Timestamp: 53723ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 53723ms SCall: 4 DCall: 16385 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 023 ISeqno: 021 Type: DTMFSubclass: 6 Timestamp: 54163ms SCall: 3 DCall: 2 [192.168.15.201:4569] Tx-Frame Retry[-01] -- OSeqno: 021 ISeqno: 024 Type: IAX Subclass: ACK Timestamp: 54163ms SCall: 2 DCall: 3 [192.168.15.201:4569] Tx-Frame Retry[000] -- OSeqno: 024 ISeqno: 022 Type: DTMFSubclass: 6 Timestamp: 54183ms SCall: 16385 DCall: 4 [192.168.15.201:4569] Rx-Frame Retry[ No] -- OSeqno: 022 ISeqno: 025 Type: IAX Subclass: ACK Timestamp: 54183ms SCall: 4 DCall: 16385 [192.168.15.201:4569] -- Russell Bryant Software Engineer Digium, Inc. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Double DTMF digits.
I am forwarding my calls from my packet8 phone number to my Free World Dialup account using the Packet8 FWD interconnect codes. I have asterisk registered with my FWD account via IAX2 and have also tried with SIP. When a call comes in Asterisk interprets any DTMF tones twice. IE: someone types 1 asterisk thinks they pressed 11. I have tried the echo test and do not hear any keybounce or echo. I can forward the call to FWD's coffeehouse at 514 via IAX2 and DTMF works fine and there is no echo. I hope I have provided enough information and maybe someone will have a solution. I thought maybe I could tweak the DTMF recognition but that doesn't look possible without recompiling dsp.c every time I make a change to test it. - Jason Garland FWD# 273307 ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Double DTMF digits
I am forwarding my calls from my packet8 phone number to my Free World Dialup account using the Packet8 FWD interconnect codes. I have asterisk registered with my FWD account via IAX2 and have also tried with SIP. When a call comes in Asterisk interprets any DTMF tones twice. IE: someone types 1 asterisk thinks they pressed 11. I have tried the echo test and do not hear any keybounce or echo. I can forward the call to FWD's coffeehouse at 514 via IAX2 and DTMF works fine and there is no echo. I hope I have provided enough information and maybe someone will have a solution. I thought maybe I could tweak the DTMF recognition but that doesn't look possible without recompiling dsp.c every time I make a change to test it. - Jason Garland FWD# 273307 ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
