VoIP Mailing List Archives :: View topic - [asterisk-biz] Solving DTMF issue

Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community

[asterisk-biz] Solving DTMF issue

VoIP Mailing List Archives Forum Index -> Asterisk Business

View previous topic :: View next topic

Author

Message

cyriaz at gmail.com
Guest

Posted: Tue Apr 01, 2008 2:08 am Post subject: [asterisk-biz] Solving DTMF issue

I would like to hire an expert who can absolutely fix the following issue: I have SIP providers who sends several DTMF mode to my asterisk at different times. We have changed "dtmfmode=auto" and still sometimes it recognized dtmf and sometimes not. I need someone to identify the issue and detect all DTMF mode sent by the SIP provider no matter what it is and pass it to asterisk without any problem. Thanks _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz

john at vanoppen.com
Guest

Posted: Wed Apr 02, 2008 2:20 pm Post subject: [asterisk-biz] Solving DTMF issue

The simplest solution is to just use a provider that implements this properly. I know our providers (big international networks) all support this with no problem, if you are seeing many different types of DTMF you likely have a very broken reseller in the path... John -----Original Message----- From: asterisk-biz-bounces@lists.digium.com [mailto:asterisk-biz-bounces@lists.digium.com] On Behalf Of Cyriaz@Gmail.com Sent: Tuesday, April 01, 2008 12:00 AM To: asterisk-biz@lists.digium.com Subject: [asterisk-biz] Solving DTMF issue I would like to hire an expert who can absolutely fix the following issue: I have SIP providers who sends several DTMF mode to my asterisk at different times. We have changed "dtmfmode=auto" and still sometimes it recognized dtmf and sometimes not. I need someone to identify the issue and detect all DTMF mode sent by the SIP provider no matter what it is and pass it to asterisk without any problem. Thanks _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Wed Apr 02, 2008 3:38 pm Post subject: [asterisk-biz] Solving DTMF issue

dtmf in asterisk (rfc2833) violates the rfc. There are many switches
that usually are only "big carrier types" that do not properly deal with
what asterisk sends. I gave oej specifics as he was doing something
relating to a filed bug on this issue. I even wrote a patch, but until
asterisk is no longer released gpl I cant contribute it (personal thing
just as some wont contribute unless its gpl I wont contribute if it is).

So what you should have said is the simpliest solution is to use a
provider that does not require rfc compliant dtmf, or uses a gateway
that will redo the RTP flow to make it compliant.

As for the original poster, there are 3 main methods for dtmf, auto
tries to select the best one. There is sip-info which dtmf is sent as
sip messages - you cant guarantee they are arrived in order unless you
have a tcp connection which asterisk violates the sip rfc by not having
tcp support (its not optional, its required).

There is inband which is what the pstn uses, and it only works well with
some codecs, with voip when there is low jitter and loss, and requires
more cpu to process (each frame it has to look and see if there is
dtmf).

There is also rfc2833 (now "deprecated" by rfc4733, yeah adding 1900
fixed y2k why wont it fix a poorly worded rfc?!). This is sent in the
RTP stream and with SIP negotiated via the SDP.

You said that the provider sends "several dtmf mode" to your server,
what does that mean? In the SDP there are multiple entries for rfc2833
(required if you support more thna one sample rate, and likely to break
most devices, sigh) or what?

On Wed, 2008-04-02 at 11:14 -0800, John van Oppen wrote:

Quote:

The simplest solution is to just use a provider that implements this
properly. I know our providers (big international networks) all
support this with no problem, if you are seeing many different types of
DTMF you likely have a very broken reseller in the path...

Quote:

On Behalf Of Cyriaz@Gmail.com

Quote:

I would like to hire an expert who can absolutely fix the following
issue:

I have SIP providers who sends several DTMF mode to my asterisk at
different times. We have changed "dtmfmode=auto" and still sometimes
it recognized dtmf and sometimes not. I need someone to identify the
issue and detect all DTMF mode sent by the SIP provider no matter what
it is and pass it to asterisk without any problem.

Thanks

--
Trixter http://www.0xdecafbad.com Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

kpfleming at digium.com
Guest

Posted: Wed Apr 02, 2008 4:50 pm Post subject: [asterisk-biz] Solving DTMF issue

Trixter aka Bret McDanel wrote:

Quote:

This was only true with Asterisk up to and including 1.2; 1.4 and beyond
send proper RFC2833 (now RFC4833) DTMF telephone-events and
interoperability has been dramatically improved.

--
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Wed Apr 02, 2008 5:16 pm Post subject: [asterisk-biz] Solving DTMF issue

On Wed, 2008-04-02 at 16:45 -0500, Kevin P. Fleming wrote:

Quote:

Trixter aka Bret McDanel wrote:

Quote:

This was only true with Asterisk up to and including 1.2; 1.4 and beyond
send proper RFC2833 (now RFC4833) DTMF telephone-events and
interoperability has been dramatically improved.

my patch was for 1.4 so that is not true.

--
Trixter http://www.0xdecafbad.com Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Wed Apr 02, 2008 5:41 pm Post subject: [asterisk-biz] Solving DTMF issue

On Wed, 2008-04-02 at 16:45 -0500, Kevin P. Fleming wrote:

Quote:

Trixter aka Bret McDanel wrote:

Quote:

This was only true with Asterisk up to and including 1.2; 1.4 and beyond
send proper RFC2833 (now RFC4833) DTMF telephone-events and
interoperability has been dramatically improved.

I just noticed that you said rfc4833, I assume you meant 4733, however
that is not backwards compatible with 2833. The marker bit changed
meanings, as did a couple of other things. Its 90% the same or so, and
they even cut and pasted some of the poorly written paragraphs from
2833, but there are differences that will break 2833 in other ways. The
differences from the spec I mentioned are all afaik broken for both.

So my question is is asterisk only 4733 now? Or is it dual mode?

--
Trixter http://www.0xdecafbad.com Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

damin at nacs.net
Guest

Posted: Wed Apr 02, 2008 7:19 pm Post subject: [asterisk-biz] Solving DTMF issue

Quote:

This was only true with Asterisk up to and including 1.2; 1.4 and

beyond

Quote:

send proper RFC2833 (now RFC4833) DTMF telephone-events and
interoperability has been dramatically improved.

my patch was for 1.4 so that is not true.

What specifically does the 1.4 DTMF implementation break in terms of the
RFC? RFC-2833 is pretty vague about a lot of things, and most vendors
implementations (Cisco, Avaya, Sonus etc..) can be deemed to be "in
violation" of the RFC. For example Cisco doesn't respect DTMF duration
events, and clips DTMF upon receipt of a DTMF "end of event" marker.
Technically this violates the RFC.

In a lot of ways, the Asterisk RFC-2833 implementation is more compatible
(in 1.4) than most other stacks out there.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Wed Apr 02, 2008 7:57 pm Post subject: [asterisk-biz] Solving DTMF issue

On Wed, 2008-04-02 at 20:15 -0400, Gregory Boehnlein wrote:

Quote:

This was only true with Asterisk up to and including 1.2; 1.4 and

beyond

Quote:

send proper RFC2833 (now RFC4833) DTMF telephone-events and
interoperability has been dramatically improved.

my patch was for 1.4 so that is not true.

duration per the rfc is optional, recommended for pstn gateways, but
optional.

But aside from that there are issues, some of them such as the one I
will say here (only becuase its been a couple months and I dont recall
everything that I did, although it was all very obvious stuff if you
look at it with a packet sniffer such as wireshark). RTP timestamps
dont match, they are just plain wrong infact (1.4.15 was what I did this
in, yes rtp is rfc1889 but this is in the 2833 generation code and only
happens when it generates a 2833 packet, so its clumped together with
the other things I fixed).

At the time I gave oej a full list via irc, he made some comment on the
bug issue and I kinda left it alone. I think there were 3-4 things
fixed, this is either 25% or 33% of it, I just dont recall right now.

Quote:

In a lot of ways, the Asterisk RFC-2833 implementation is more compatible
(in 1.4) than most other stacks out there.

That may be, however it doesnt mean that its compliant Smile

beckman at angryox.com
Guest

Posted: Wed Apr 02, 2008 11:03 pm Post subject: [asterisk-biz] Solving DTMF issue

On Wed, 2 Apr 2008, Trixter aka Bret McDanel wrote:

Quote:

Why don't you release your patch under a different license, so I can patch
it separately from Asterisk? I can make modifications to Asterisk, I
don't have to make them public.

---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Thu Apr 03, 2008 10:15 am Post subject: [asterisk-biz] Solving DTMF issue

On Wed, 2008-04-02 at 23:54 -0400, Peter Beckman wrote:

Quote:

Why don't you release your patch under a different license, so I can patch
it separately from Asterisk? I can make modifications to Asterisk, I
don't have to make them public.

it really isnt that hard for anyone to replicate it, you just get the
rfc, get a packet sniffer, look at the traffic and it was all fairly
obvious stuff. At one time I gave exact details which were to be put
into the comments of a bug that was then already filed and open and just
idling on bugs.digium.com (I really dont recall which number though, I
*think* it ended in 088 for some reason but cant say why).

My patch did a couple other things as well that were unrelated to fixing
problems, such as making the code far easier to read and understand. I
created proper structures for the rtp headers and 2833 info, that way
you dont have to access it as an array and do some logical operators to
deal with less than even 8 bit multiple sizes (there are some oddly
sized items, not dissimilar to IP header length and version where they
are each one nybble). It was just painful to work with "out of the box"
so the cleanup was to make it easier to fix.

This of course was all months ago, I want to say that it was last year
even, but I just dont recall when exactly.

But take heart, freeswitch has the same problem, and they are also
unwilling to fix the same issue because "it goes the wrong direction",
although my thoughts at the time that was said was they didnt understand
nor care to understand what the problem was. Why if you look at the
freeswitch rtp stack, you will see a high number of similarities to the
asterisk one, and its odd that the same bugs were replicated across,
almost as if someone just copied the code, did some clean up, changed
some names of variables and such and called it their own work. I am not
saying that is what happened, but it sure seems like it - why would a
"from scratch" work have the same errors in it?

So you arent alone in this issue. And there are still incompatibilities
with really strict gateways, to the point that it does not work at all
with those gateways. It could be worse right? Could be metaswitch
where you can DoS it (hose the DSPs, cause resets, destabilize the
switch) with bad 2833 data Smile

mike at jerris.com
Guest

Posted: Thu Apr 03, 2008 11:15 am Post subject: [asterisk-biz] Solving DTMF issue

On Apr 3, 2008, at 11:09 AM, Trixter aka Bret McDanel wrote:

Quote:

<snip>
But take heart, freeswitch has the same problem, and they are also
unwilling to fix the same issue because "it goes the wrong direction",
although my thoughts at the time that was said was they didnt
understand
nor care to understand what the problem was. Why if you look at the
freeswitch rtp stack, you will see a high number of similarities to
the
asterisk one, and its odd that the same bugs were replicated across,
almost as if someone just copied the code, did some clean up, changed
some names of variables and such and called it their own work. I am
not
saying that is what happened, but it sure seems like it - why would a
"from scratch" work have the same errors in it?

Just to note, I personally witnessed the creation of the freeswitch
rtp code and can say for sure that none of it was taken from
asterisk. Anyone looking to confirm this for themselves can feel free
to look at the code history and make their own decision.

Freeswitch: http://fisheye.freeswitch.org/browse/FreeSWITCH/src/switch_rtp.c
Asterisk: http://svn.digium.com/view/asterisk/trunk/main/rtp.c?view=log

As far as I know, freeswitch has all its outstanding rfc 2833
compliance issues resolved as of our 1.0.rc2 release. Most notably,
there are some strange cases related to time-stamps that need very
careful attention, especially when handling things like the 8 second
rollover in dtmf duration. Also, the rules relating to SSRC and never
starting timestamp offset at 0 are good ones to go over. On the
detection side the issue is often worse, with many broken devices out
there, making it very tricky to follow the old adage, "be liberal in
what you accept, strict in what you send".

Mike

Quote:

So you arent alone in this issue. And there are still
incompatibilities
with really strict gateways, to the point that it does not work at all
with those gateways. It could be worse right? Could be metaswitch
where you can DoS it (hose the DSPs, cause resets, destabilize the
switch) with bad 2833 data Smile

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Thu Apr 03, 2008 11:32 am Post subject: [asterisk-biz] Solving DTMF issue

On Thu, 2008-04-03 at 12:07 -0400, Michael Jerris wrote:

Quote:

On Apr 3, 2008, at 11:09 AM, Trixter aka Bret McDanel wrote:

Quote:

That is what I made my comments based on, the same bugs exist in both,
the structure is highly similar. Bugs dont just invent themselves in
the same way in 2 totally independant stacks, now if they were different
bugs, or if the structure of the code was highly different I wouldnt
have thought that, but upon reading both it sure looks like it was
copied and cleaned a bit.

Why even some of the unused functions at one point in the FS rtp stack
coresponded to functions in the asterisk rtp stack, those are now
removed from the code, but they were there at one point.

Quote:

As far as I know, freeswitch has all its outstanding rfc 2833
compliance issues resolved as of our 1.0.rc2 release.

no it doesnt, you personally commented that compliance is "going in the
wrong direction" when you spent that month trying to break my patch to
make it more compliant.

Quote:

Most notably,
there are some strange cases related to time-stamps that need very
careful attention, especially when handling things like the 8 second
rollover in dtmf duration.

which you arent compliant with, but this isnt the forum to discuss
freeswitch now is it?

Quote:

Also, the rules relating to SSRC and never
starting timestamp offset at 0 are good ones to go over.

it doesnt say to not start it at 0 it suggests it more so for SRTP but
that is a different issue.

Quote:

On the
detection side the issue is often worse, with many broken devices out
there, making it very tricky to follow the old adage, "be liberal in
what you accept, strict in what you send".

Yes, by quoting that it makes me wonder why "strict in what you send"
was specifically rejected by you personally for "going in the wrong
direction". But this isnt the place.

--
Trixter http://www.0xdecafbad.com Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Thu Apr 03, 2008 7:48 pm Post subject: [asterisk-biz] Solving DTMF issue

On Wed, 2008-04-02 at 23:54 -0400, Peter Beckman wrote:

Quote:

On Wed, 2 Apr 2008, Trixter aka Bret McDanel wrote:

Quote:

Why don't you release your patch under a different license, so I can patch
it separately from Asterisk? I can make modifications to Asterisk, I
don't have to make them public.

I went looking earlier today for the bug report, its 10058 iirc, and it
seems that the bug itself was more related to 1.2, there were some
questions about 1.4 in there, and I really didnt pay that much attention
after finding it and it was marked closed.

The version specifically I modified was 1.4.15 but I believe that 1.4.17
had the same issues. Unless there has been work since then on some of
these things then its still the same way.

I also noticed that the note by oej only included one of the 3-4 things
that I noticed werent right. Anyone can look at this easily with a
packet sniffer and that is how I did it, largely by comparing a working
(cisco) stream to the non-working asterisk one and seeing just what was
different was I able to locate 1 or 2 of the things because it seemed
right (the rfc indicates that it should be the way the cisco was on
those particular things).

--
Trixter http://www.0xdecafbad.com Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
The GPL is a software license not a religion

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

damin at nacs.net
Guest

Posted: Thu Apr 03, 2008 9:20 pm Post subject: [asterisk-biz] Solving DTMF issue

Quote:

The version specifically I modified was 1.4.15 but I believe that
1.4.17 had the same issues. Unless there has been work since then on some

Quote:

these things then its still the same way.

I also noticed that the note by oej only included one of the 3-4 things
that I noticed werent right. Anyone can look at this easily with a
packet sniffer and that is how I did it, largely by comparing a working
(cisco) stream to the non-working asterisk one and seeing just what was
different was I able to locate 1 or 2 of the things because it seemed
right (the rfc indicates that it should be the way the cisco was on
those particular things).

http://bugs.digium.com/view.php?id=6667 has lots of discussion regarding the
issues w/ the Asterisk 1.2 DTMF stack. All of the issues that I raised in
that bug report have been fixed in 1.4. Specifically, I was having issues w/
Sonus, Cisco and Altigen at the time.

While 1.4 VLDTMF may not be perfect, it is a huge step in the right
direction. I can now confidently plug Asterisk 1.4 into just about anything
that speaks RFC-2833 and expect it to work. At least, I've not found
anything that breaks like it did w/ 1.2.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

trixter at 0xdecafbad.com
Guest

Posted: Thu Apr 03, 2008 10:28 pm Post subject: [asterisk-biz] Solving DTMF issue

On Thu, 2008-04-03 at 22:15 -0400, Gregory Boehnlein wrote:

Quote:

That may be, however I have found stuff that it did not work with
properly, and that is what I was commenting on. I do not know if there
was a bug report filed specifically for the items I found, I told oej
only because I knew he worked on sip, and that he would either have
worked on or knew who did work on the rtp stack. He is the one that
suggested that 10058 may address that since on the surface at least it
did.

As stated by Jason earlier, a packet trace would fairly quickly identify
what was wrong with the original posters comments, as well as the stuff
I found, since that is exactly how I found it. It may even be that the
original poster was talking about other issues, there is less than
enough info to say if anything I have talked about is the same as what
other people talked about, for all I know there are multiple issues.

What I do know is that a specific cisco device worked with a specific
gateway (it wasnt mine the packet captures were provided by someone
else, and the most that could be derived is they use a proxy that is
known to not modify rtp, so useragent stuff was not available) yet
asterisk did not work with that same gateway, and the differences all
revolved around malformed rfc2833 packets. I dont even know which cisco
device it was that worked (depending on revision and other things it may
be different output ...) I do know it wouldnt be hard to make the list
for anyone who is reasonably competent at looking at packet traces, all
of the anomolies that I discovered had to do with basically "numbers"
not being incremented properly (such as the timestamp) and this was
either 1.4.15 or 1.4.17 at that time.
--
Trixter http://www.0xdecafbad.com Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
The GPL is a software license not a religion

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz

Display posts from previous:

	VoIP Mailing List Archives Forum Index -> Asterisk Business	All times are GMT - 5 Hours
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum