I am having some problems getting asterisk to work with my carrier (Bandwidth.com). They clearly state in their setup docs that you need to use RFC-2833 for all DTMF processing. I have confirmed that they are properly delivering DTMF to my * system in RFC2833 format. The problem is that I cannot originate an outbound call and dial digits after an answer is received.
I have tried something like:
Dial(5555551212@bandwidth_server,30,D(123))
As well as just issuing a SendDTMF(123) after getting an answer. Neither work . In the first example I hear a single tone, in the second example I hear nothing.
I am running asterisk 1.4.19.1. I have done wireshark captures on the network interface and can clearly see that three distinct RTP events are being dispatched (multiple packets for each event). Everything looks but I have one question for anyone familiar with RFC-2833 and RTP.
As the call is progressing the timestamp value on all the RTP packets increases as it should. The ‘issue’ I see is that the timestamp of the first DTMF event resets back to 0 and each subseqent DTMF event timestamp increments relative to the first DTMF event and NOT the beginning of the RTP stream. After reading the RFC documentation, it isn’t entirely clear what it should be.
Could what I am seeing here possibly be causing the issue I am experiencing?
Perhaps this is the wrong forum for this particular type of question. Can anyone more familiar with the asterisk community point me in the right direction for the appropriate location for something like this?
I am having the same problems w/ bandwidth.com on two circuits sending outbound dtmf. Where the receiving end does not recognize any of the dtmf digits.
I added rfc2833compensate=yes to one of my sites and it has helped with the problem. However, I still have a second site that has the problem repeatedly.
I have talked w/ Bandwidth.com and they have told me that it is a problem with my data carrier. I have done packet captures with my data carrier on my end, their gateway and the peering gateway and see all the packets being sent and in sequence.
Just know there are others having this same problem. If you have a support number w/ bandwidth.com, please let me know what it is.
[quote=“g2010”]I am having some problems getting asterisk to work with my carrier (Bandwidth.com). They clearly state in their setup docs that you need to use RFC-2833 for all DTMF processing. I have confirmed that they are properly delivering DTMF to my * system in RFC2833 format. The problem is that I cannot originate an outbound call and dial digits after an answer is received.
I have tried something like:
Dial(5555551212@bandwidth_server,30,D(123))
As well as just issuing a SendDTMF(123) after getting an answer. Neither work . In the first example I hear a single tone, in the second example I hear nothing.
I am running asterisk 1.4.19.1. I have done wireshark captures on the network interface and can clearly see that three distinct RTP events are being dispatched (multiple packets for each event). Everything looks but I have one question for anyone familiar with RFC-2833 and RTP.
As the call is progressing the timestamp value on all the RTP packets increases as it should. The ‘issue’ I see is that the timestamp of the first DTMF event resets back to 0 and each subseqent DTMF event timestamp increments relative to the first DTMF event and NOT the beginning of the RTP stream. After reading the RFC documentation, it isn’t entirely clear what it should be.
Could what I am seeing here possibly be causing the issue I am experiencing?
I spoke with a Tier 3 engineer at bandwidth.com at length today. We did multiple tests and packet captures while we were on the phone. It was determined that asterisk was fully RFC-2833 compliant.
Their engineer re-provisioned my account to utilize a different upstream carrier on their side. As soon as they did that my DTMF started working just fine. They concluded that one of their carriers was not in compliance with 2833 and they were going to pursue getting it fixed internally.
I don’t have the number of someone at bandwidth… but hopefully with a little determination you can get them to switch you too.