Summary:ASTERISK-06491: [branch] Asterisk trunk [pre-1.4] and rfc2833 compliance
Reporter:Arsen Chaloyan (arsen)Labels:
Date Opened:2006-03-06 23:51:33.000-0600Date Closed:2006-09-27 16:30:51
Versions:Frequency of
Environment:Attachments:( 0) rtp.diff
Description:Scenario to reproduce:

SIPPhone -> asterisk -> SPA-3000 -> PSTN
Asterisk stays in media path (canreinvite=no, dtmfmode=rfc2833)

PSTN side is failed to receive DTMFs pressed on SIPPhone.

Actually this issue can be considered as an issue of SPA-3000, as another IP->PSTN gateway (Quadro 4x), which is substituted SPA-3000 in mentioned scenario, successfully receives rfc2833 DTMFs from asterisk and put inband DTMFs to PSTN side.

From the other side, problem is disappeared as well, if I exclude asterisk from media path (canreinvite=yes). In this case SPA-3000 receives rfc2833 DTMFs directly from SIPPhone and successfully sends them to PSTN side.

So I assume that rfc2833 implementation of SPA-3000 is not robust enough, but asterisk itself surely is not fully compliant with rfc2833.

Find below my patch against 1.2.4, which makes asterisk more compliant with rfc2833 and reliable enough for SPA-3000


I'm VoIP developer (mainly RTP guy) for more than 5 years now. During last 3 years I found too many broken rfc2833 implementations in the field. I reported rfc2833 compliance issues to xten, snom. Now these issues are fixed for a while.

Rfc2833 contains some weak (not clarified) areas, which seems to be the reason for broken implementations.
Drafts on rfc2833 are backward compatible with original document and contains mainly clarifications on it.
The last one is: draft-ietf-avt-rfc2833bis-12

I can go into details if accepted and needed.
Comments:By: Olle Johansson (oej) 2006-03-07 01:06:19.000-0600

Your competence in this area is certainly needed, since we have a few open bugs. However, before we look at your patch, we need you to send a disclaimer to Digium. Please read the bug guidelines for more information (you where referred to them when opening this report. A pointer is on the home page of this site).

Thank you for contributing to Asterisk!

By: Arsen Chaloyan (arsen) 2006-03-08 23:32:21.000-0600

Do you receive the disclaimer? I've sent it on 03-08-06.

By: Olle Johansson (oej) 2006-03-09 00:34:51.000-0600

I don't work for Digium, so I can't check, but I believe you. Will look at your code soon. Thanks!

By: damin (damin) 2006-03-09 12:40:56.000-0600

Asterisk's RFC2833 implementation has no concept of Variable Length DTMF and machine guns everything out RTP in the same loop. While technically, this is not in violation of the RFC, it causes issues such as clipped DTMF, duplicate DTMF and occasionally no DTMF on the receiving end. Many gateway vendors do not implement jitter buffers on RTP events, and will handle them in the order they receive, so it is possible for DTMF events to arrive out of sequence and cause all sorts of havoc. As your patch demonstrates, there are also some issues w/ timestamps and sequence numbers. You can check more detailed information on the RFC2833 issues in the following bugnotes:


Kevin Fleming from Digium has been working on a SVN branch that supports true Variable Length DTMF that should resolve virtually all of the RFC2833 DTMF issues that I personally have encountered, and should make Asterisk much more interoperable with a wider variety of equipment.

If your patch can truly be considered a fix and helps correct these behaviours then it should definitely be included in the 1.2 train as a bug-fix. If not, you might want to work with Kevin on this VLDTMF branch. We need all the RFC2833 expertise we can get!

By: Tilghman Lesher (tilghman) 2006-03-10 22:37:13.000-0600

I think we can safely put this into 1.2, with the much more involved and complex patch for trunk.

arsen:  I think we'd all appreciate your looking at the other bugs already open on this issue, and let us know the strengths and weaknesses of those proposed patches, so we can get this issue completely solved going forward.

By: Arsen Chaloyan (arsen) 2006-03-13 08:37:16.000-0600

This patch can be truly considered as fix for rfc2833 sending procedure. It shouldn't break anything, but makes asterisk more reliable for 3-rd party gateways.
Analyzing rtp.c, I guess that there are a lot of issues left to fix both for receiver and sender routines.

Supporting Variable Length DTMF is good idea, but seems it'll take some effort to implement.
I believe that asterisk can be reliable enough even with Fixed Length DTMF

Hopefully I'll have some time during the week to analyze and comment on other issues as well.

By: damin (damin) 2006-03-13 09:25:05.000-0600

I am running this patch on a development system and doing some interop testing with a couple of different vendor's stacks. Nothing really exciting, but they did complain about the timestamp and sequence number issues, so we'll see if this helps them out.

I would urge that we have Russell add this to the 1.2 SVN tree so the patch makes it into mainline 1.2 for 1.2.6.

By: Tilghman Lesher (tilghman) 2006-03-13 09:30:44.000-0600

Committed to 1.2, merged to trunk.

By: Tilghman Lesher (tilghman) 2006-03-15 12:38:50.000-0600

Patch reverted due to breakage.

By: damin (damin) 2006-03-15 13:02:58.000-0600

Hmm.. I hadn't noticed anything broken with it. Any idea what is horked?

By: alric (alric) 2006-03-15 13:18:47.000-0600

Didn't help with my issue (shown in bug 5970, with Metaswitch interop).

By: Neal Horman (knhor) 2006-03-15 23:57:53.000-0600

spa3000 #1 - line1 <- sip -> *1 <- sip -> spa3000 #1 - pstn
spa3000 #1 - line1 <- sip -> *1 <- sip -> spa3000 #2 - pstn
spa3000 #1 - line1 <- sip -> *1 <- iax -> *2 <- sip -> broadvoice
spa841 <- sip -> *1 <- sip -> spa3000 #1 - pstn
spa841 <- sip -> *1 <- sip -> spa3000 #2 - pstn
spa841 <- sip -> *1 <- iax -> *2 <- sip -> broadvoice

I can report that this patch against 1.2.5 helps to the point where dtmf generation at least produces about 100-200ms bursts whereas previously i would get approx. 20-50ms bursts.
Another note, dtmf is only generated after i release the key, not while i press the key.
Both *1 and *2 are 1.2.5 patched.

By: Arsen Chaloyan (arsen) 2006-03-16 00:30:31.000-0600

Some additional notes regarding comments made by 'amyl 02-17-06 10:37 (ASTERISK-5815)' and patch on ASTERISK-6491

I fully agree with mentioned comments and just copy & past recommendation to clarify against patch on ASTERISK-6491

> 1. All the packets that make up the digit should have a timestamp that indicates when the digit > starts. This timestamp should be against the same timebase as the media packets. The first >packet must be sent in a timely manner - i.e. it is no good telling MetaSwitch to start playing a >digit a significant time in the past or the future. Best to send the packet at the next point a normal >packet would have been sent (i.e. on the packetization interval) after the digit is >detected/requested
patch on 6667 contains no changes concerning timing intervals in which dtmf packets are sent

>2. The first packet should not be repeated.

>3. Best to send a digit packet at subsequent packetization intervals. Timestamp should remain >the same, but duration and sequence number should increase. Duration should increase by the >packetization interval for each packet.
duration value is fixed, timestamp was already there, all digits are sent at once (no changes here, but should be fixed in the further patches)

>4. The final packet should be sent 3 times with "end" set. No need to space the repeats out. >Duration should not increase in the repeats.
exactly, with another minor fix,
sequence number must be increased even on repeated packets.

Just analyzing source code of astreisk regarding dtmf issues, I see that it needs to be completely revised, but it will take too much effort and time from me.
Patch on ASTERISK-6491 is just maybe small, but robust enough step to compliance with rfc2833.

By: Arsen Chaloyan (arsen) 2006-03-16 00:36:06.000-0600

I'm sure that this patch can only break some already broken implementations.
I'm waiting for comments on this. Just reporting breakage doesn't help match.

By: damin (damin) 2006-03-16 05:18:32.000-0600

Arsen.. I agree that the current DTMF implementation in Asterisk is kludgy and will require a re-write to solve many of it's problems. Kevin Flemming from Digium has already begun that work by implementing Variable Length DTMF in an SVN branch.

You can view his progress at; http://svn.digium.com/view/asterisk/team/kpfleming/vldtmf/

Most likely this is not going to be fully baked fot the 1.4 release this Summer unless we all make a concerted effort to help Kevin test this branch and comment on his implementation.

As for your patches, the best thing that we can do for the 1.2 train right now is to try and make Asterisk as compatible as possible w/ it's current implementation. This should help interop with a wider variety of equipment and solve some issues.

Corydon, can you please comment on the specific issues that caused you to revert the patch from 1.2 and trunk? I've been running them and I don't see any major difference, except that my DTMF output looks "more correct".

By: Joshua C. Colp (jcolp) 2006-03-16 09:47:42.000-0600

Here at VON we had a group of people who were using latest 1.2 branch, with the new fix. They had nothing but DTMF issues, while reverting to before this was applied returned DTMF to a working and normal state. Rather then have RFC2833 potentially totally broken, I thought it would be safer to revert to something that is known to work in most situations until we can look at this further without being distracted by VON.

By: Tilghman Lesher (tilghman) 2006-03-16 11:18:48.000-0600

There was a specific issue here on the VON show floor that reverting the patch solved.  I was told in no uncertain terms to revert the patch.  If you want more details, please talk to joshnet (file on IRC).

By: BJ Weschke (bweschke) 2006-03-16 11:53:33.000-0600

Ya, so umm.... That person that "had the issue on the VON floor"... .That would be me. We had PSTN <-------> Telica SIP <-----> SIP * <------> SIP * and we had DTMF getting dupped all over the place. Plus, when we had reinvites enabled eliminating the SIP * in the middle, we had issues with DTMF not getting recognized at all - but that's not immediately clear if it was a NAT issue or something else. The DUPE issue however was clearly a "night and day" difference between 1.2 with this patch and 1.2 without it. 1.2 w/o it doesn't experience the problem at all. I'm certainly open and available to testing these kinds of scenarios again to get more info, but as someone already stated with this bug, we were trying to demo something on the VON floor and dupe DTMF was kinda counter-productive for that and the decision was made to revert it on the 1.2 branch and /trunk which shouldn't have these kinds of issues in the first place. Like others have said, I very much appreciate the contributions and will try and work with you however possible for testing so we can get this resolved.

By: damin (damin) 2006-03-16 12:05:54.000-0600

Alright.. that makes a lot of sense and I understand why it was reverted. I would also like to suggest that we get some clueful individuals together, either on IRC or via MeetMe to create a specific Asterisk DTMF Task Force with the very specific purpose of clearly defining the issues at hand w/ DTMF support in Asterisk, what options are available given the current 1.2 branch and defining a roadmap for the future.

I will setup a public IAX2 and SIP Meet-Me room if neccessary, and we can carve out an IRC channel #asterisk-dtmf. I'll propose some times to the asterisk-dev mailing list and those that can participate should.

There are a lot of irons in the fire, and many people of varying skills, but to me, DTMF support in Asterisk is causing me the largest number of interop issues. I think that I speak for a large number of people from the User and Developer community when I state that DTMF support is a critical issue and that we have a heck of a lot of talent at our disposal to throw at it. Surely, with the incredible knowledge of the Developer community we can set a course and knock this one off the to-do list given Kevin's estensive work on VLDTMF already.

By: Arsen Chaloyan (arsen) 2006-03-17 01:33:44.000-0600

Ok, I agree,  reverting back in this stage is right choice. I don't want my patches to make any disadvantage to you guys, but I do want to find the reason of breakage.

You can consider yourself as lucky man, if you didn't experience dtmf duplication problem in asterisk before. See ASTERISK-5868 for more info. By the way, recently I've uploaded patch there which should solve dtmf duplication issue in general. In any case I realize, that patch on ASTERISK-6491 issue should be at least backward compatible with poor asterisk itself, I can't enforce (and don't need it at all) whole asterisk community to use patch on ASTERISK-5868, even if it'll be the most perfect one.
So I'm trying to reproduce your issue in my back-to-back asterisk installation with no luck yet.
Can you attach network capture (tcpdump or ethereal), which will contain rtp stream from ast1 -> ast2.
Maybe I'll come up with "nicer" solution, if I manage to reproduce it.
"Nicer" doesn't mean more compliant with rfc2833, but backward compatible with asterisk itself.

By: Joshua C. Colp (jcolp) 2006-03-17 09:36:33.000-0600

I personally have never had any issues with RFC2833, across everything I've used. It's always just worked. If I asked for people to post all the times it's worked, and for those who have not had any issues with it to post... I think we'd get a lot. You may think there's tons of issues, but in reality there's really not that many. It's just some unique cases that it's a problem.

By: damin (damin) 2006-03-17 11:07:05.000-0600

I would disagree with your statement Josh. Asterisk's RFC-2833 DTMF works most of the time for me, but I don't think that we can settle for "good enough". There are very clear issues with the way that RFC-2833 is handled that will continue to cause problems with various vendor's implementations. I do not believe that it is acceptable to be "good enough". When you are looking for a surgeon, you don't settle for "good enough".

There are two issues on the table that are, in my humble opinion, critical to address. The first are minor changes that can be made to ensure a wider level of compatibility with a wider array of vendor implementations given the current RTP stack and DTMF implementation. By fixing these quirks, we are opening up Asterisk to a much larger potential audience. More people == more testing == more users == more potential developers == better code. My personal goal for Asterisk is to get it into everywhere that I possibly can, and to truly exploit its potential to be a disruptive technology. The more interoperable it is, the better. We used a catch phrase of "Yeah, Linux runs on that" during the really heavy years of arhcitecture porting that was going on between 1997 to 2000. I'd like to rephrase that now and make it "Yea, Asterisk works with that".

The second issue is the fact that we cannot get the Industry and Vendors to change the way THEIR stacks are written. Not easily anyway. If you would like to call Cisco and tell them they need to implement RTP Event jitter buffering to reduce the likelyhood of Asterisk causing duplicate digits on high latency connections, please feel free. I do not believe that Cisco, given their position in the market, and their current forray into the low end SIP market, has any interest in making Asterisk more compatible with their hardware. Phones? Yes.. they can sell lots of them. AS5300s? Probably not likely. Their answer is going to be "You need to implement Variable Length DTMF correctly, per the RFC standard. We do this in an industry standard way that has passed very stringent interop testing and in our situations, latency is not an issue like it is with Asterisk because we can't recieve packets that far out of order." (Well, at least that was what the Cisco VoIP Engineer told me on the way back from E-tel).

So, we are left with one option. It's not likely that all the other vendor stacks are going to be changed to make them more compatible with Asterisk. I would say that is highly unlikely. We can complain and moan about it all we want, but we have the power to alter Asterisk's RFC-2833 implementation and completely remove that from the table. In my opinion, it is far easier for us to fix what we know is less than optimal and address the issue.

In the end, that is one of the main strengths of Open Source development. We have the power to change the world with code. It might sound a bit idealogic, but I've seen it happen. I was there when Linus released the first Linux kernel. I know what can be done. I see the same potential with Asterisk.

Now.. on to more commercial issues and why this is important. I am currently under a Non Disclosure agreement with a "Legacy PBX Vendor" that is very interested in making sure their products are fully compatible with Asterisk. They realize that Asterisk, as a platform, enables their customers to take advantage of features and applications that they are not capable of providing. Their interest is in having Asterisk co-exist in some form or fashion with their SIP handoff cards to provide features for their PBX. They have done extensive interop testing at many of the SIPIT events, and they are having problems with Asterisk DTMF interoperability. I have obtained permission to post the following into this bug report, but I had to scrub the information and get approval first.

From: xxx@xxx

We checked the RFC 2833, it dose not work, because your DTMF event and voice event has the same time stamp. In this case, we are going to drop the "duplicate" packets. I have several email exchanges with our engineers. They think logically, DMTF events and voice packets should not have the same time stamps. We have been in SIPIT events and test with 10+ vendors, we don't have problems to recieve DTMF through RFC 2833. I don't know if it's easy to change some implementation in your side. Attatched are some email exchanges among our engineers.

From: xxx@xxx

I think the RFC 1889 define the timestamp clearly.

Timestamp: 32 bits The timestamp reflects the sampling instant of the first octet in the RTP data packet.

And RFC 2833 also has similar explain:
4.3 Use of RTP Header Fields
Timestamp: The RTP timestamp reflects the measurement point for  the current packet.

Since the DTMF tone and voice can not happen at the same time, so they will be sampled/measured at different time. So different timestamp for voice and DTMF tone is logical and reasonable.  They send 6 DTMF ones RTP packets with same timestamp, this is OK for the redundancy and reliability.  But they need use different timestamp for the voice and tone.

How many devices have we test with on RFC 2833?  Is Asterisk the only one behaving like this?

From: xxx@xxx

Asterisk RFC 2833 implementation have duplicated time stamp between DTMF packet and voice packet. If this is not specified in RFC clearly, I think we should support it. I may be able to ask Asterisk to change their implementation, but what if other SIP implementations have similar issues?

From: xxx@xxx

Yes it only talks about how to handle the inband tone and outband named event.  We suppress the tone and replace it with outband Event which the second cases in the first paragraph.  However it does not talk about anything about timestamp of the RTP. My understanding is since the DTMF tone and voice can not exist at the same time, logically it is more natural to use sequential timestamp for voice and DTMF RTP.

From: xxx@xxx

We did not use the same timestamp for both audio and DTMF packet. Seems the RFC is not clear about this.

3.2 Simultaneous Generation of Audio and Events

  A source MAY send events and coded audio packets for the same time
  instants, using events as the redundant encoding for the audio
  stream, or it MAY block outgoing audio while event tones are active
  and only send named events as both the primary and redundant

  Note that a period covered by an encoded tone may overlap in time
  with a period of audio encoded by other means. This is likely to
  occur at the onset of a tone and is necessary to avoid possible
  errors in the interpretation of the reproduced tone at the remote
  end.  Implementations supporting this payload format must be prepared
  to handle the overlap. It is RECOMMENDED that gateways only render
  the encoded tone since the audio may contain spurious tones
  introduced by the audio compression algorithm. However, it is
  anticipated that these extra tones in general should not interfere
  with recognition at the far end.

From: xxx@xxx
Henry, Do we use the same timestamp or not?  Does the RFC 2833 say anything about this?  Thanks, William

From: xxx@xxx
Since the DTMF RTP packets have the same timestamp with the previous audio RTP packet. The jitter buffer ignored the packet with duplicated timestamp.

From: xxx@xxx

For voice and video, when you split the large chunk of voice/audio data, it is recommended to update the timestamp in each packet as well because they do represent the different time for the media it carry.  

In our case the most important thing is that should the DTMF RTP packet use the same timestamp as the previous audio RTP packet?

If the answer is yes, we need change our code to differentiate the different type of the RTP.  Otherwise they need change their implementation.

Henry, how do you implement the timestamp for voice and dtmf?  

From: xxx@xxx
What are the roles of the RTP timestamp and sequence numbers? The timestamp is used to place the incoming audio and video packets in the correct timing order (playout delay compensation). The sequence number is mainly used to detect losses. Sequence numbers increase by one for each RTP packet transmitted, timestamps increase by the time "covered" by a packet. For video formats where a video frame is split across several RTP packets, several packets may have the same timestamp. In some cases such as carrying DTMF (touch tone) data (RFC 2833), RTP timestamps may not be monotonic.

Now.. in summation, we can point fingers at RFC-2833 all we want and bitch about the ambiguities and uncertanties in it. However, the fact remains that most vendors have opted to work around the ambiguity by incrementing timestamps between Voice and RTP events. Asterisk does not. This causes a lot of problems. We can fix it. It would be a small thing to do. In fact, I probably have a patch from our series of Etel experiments that does it.

Why NOT implement it? Why NOT make Asterisk more compatible?

By: Joshua C. Colp (jcolp) 2006-03-17 11:13:56.000-0600

I didn't say Asterisk's RFC2833 support was "good enough". I was simply stating that for most people it does work, and that arsen shouldn't think that everyone should have issues with it. Yes I do admit we need to improve the implementation. I simply don't want people to read this and think, "oh the RFC2833 implementation sucks, doesn't work, is crap!" when yes it could use improvement but it works in most situations. Giving credit where credit is due.

By: damin (damin) 2006-03-17 15:27:37.000-0600

Josh.. Cool!

arsen.. I just patched my development box w/ your patch for 6667 and 6027. I'm reading through the patches and WOW! COMMENTS! THANKS! It'll make life easier for those of us that don't normally look at code to get a better understanding of how and what you are attempting to solve!

By: Arsen Chaloyan (arsen) 2006-03-19 05:44:56.000-0600

I'm testing asterisk as user for more than 2 years. I find asterisk very strong and powerfull project, may be even the most powerfull open source project I follow up.
Recently I read the post on asterisk mailing list, in which user complians against asterisk and rfc2833.
I just decided to dig into the problem for the first time from developer perspective, as RTP and rfc2833 is my close specialisation.
I'm really happy that for most of the users current implemantation does work, but asterisk "may" have interoperate problems using devices from different vendors.
It depend's on vendors and scenarios used, so for "some" of the cases it defenitely "should" have problems. This is my poor thoughts only.

Is it possible to reproduce the issue and attach net capture?
May be it's not suitable to you to revert sources back, in this case I need at least the following capture Telica Sip ----> SIP *. I'll try to reproduce it myself.


By: BJ Weschke (bweschke) 2006-03-20 12:01:52.000-0600

arsen: The one machine that was at the end of that chain is in transit back from VON to our offices now so I won't be able to reproduce it completely. I will however try with a different machine and try to get you a capture.

By: Arsen Chaloyan (arsen) 2006-03-23 00:24:12.000-0600

bweschke: My patch on this issue changes only dtmf sending routine, so in your scenario it should be no difference which machine to run at terminating side. I believe, in some circumstances, patched asterisk, which is between Telica and terminating asterisk, sends dtmfs in the way which makes terminating asterisk to duplicate them. I have some assumption, but I definitely need your input in any case, even if it's not reproducible to you any more. Sorry for bothering you too much.

By: Arsen Chaloyan (arsen) 2006-03-29 22:52:17.000-0600

any updates...

By: damin (damin) 2006-03-29 23:33:43.000-0600

Kevin has stated on the asterisk-dev mailing list that he will be merging in his VLDTMF code to trunk very soon, which should give us a good 2-3 months to flesh out any bugs with it. I believe that the new DTMF code should solve just about all of the existing DTMf issues that we have.

As for your patches, I am running this patch on a production gateway w/ 1.2 SVN built this week. It's handling 300+ concurrent calls  (SIP to SIP) and seems to be working without a problem. We've had no reported DTMF issues yet. I also applied the patch from 6027 as well.

By: Arsen Chaloyan (arsen) 2006-03-30 23:54:24.000-0600

I was waiting for bweschke's input on this issue, but seems he is unreachable to me, so I'm going to share my assumption regarding the reason of breakage at VON.

"Sequence number must be incremented even on final packet (retransmit)".
This is one of the issues, which my patch is intended to fix. As I stated before, rfc2833 isn't well formed, and has no detailed clarification how to send retransmitted packets, but the draft-ietf-avt-rfc2833bis-12 clearly states:  RTP Sequence Number
  The RTP sequence number MUST be incremented by one in each successive
  RTP packet sent.  Incrementing applies to retransmitted as well as
  initial instances of event reports, to permit the receiver to detect
  lost packets for RTCP receiver reports.

In any case, it's not a major issue not to increment sequence number for final packet, but expecting this behavior from other devices is too wrong.
See process_rfc2833

} else if(event_end & 0x80) {
 if (rtp->resp) {
  if(rtp->lasteventendseqn != seqno) {
   f = send_dtmf(rtp);
   rtp->lasteventendseqn = seqno;
  rtp->resp = 0;
Issue ASTERISK-5868 clearly states that asterisk has problems by duplicating dtmfs, when some packets are lost (missed) or reordered.
So I assume that bweschke had some network issues at VON with lost or reordered packets, when patched asterisk behaved itself as alien device for terminating asterisk and made it to duplicate dtmfs. This is the only reason why reverting back can help.
Hopefully I'm on right track and my thoughts is clear to you as well.

joshnet: please share your consideration regarding this.

By: BJ Weschke (bweschke) 2006-03-31 08:53:52.000-0600

arsen: We've all got bills to pay. I get to stuff that isn't revenue affecting when I can. I'm sure you understand. What kind of trace is it that you need?

By: Arsen Chaloyan (arsen) 2006-04-01 01:17:50.000-0600

bweschke: See my notes on 03-17-06 01:33 and 03-19-06 05:44 regarding capture I asked.

"issue holder(s)": Please note, I don't use and I'm not going to use asterisk in any production environment (no interest in this). I'm just developer and asterisk still seems to be an interesting project to participate, from other side I'm getting tired with the way this issue is processed. I'll continue my activity if you need it, else just forget this patch and original reported issue as well.

damin: Hopefully I'll find time to look at vldtmf branch or just wait it to be merged to trunk and maybe then I'll give some comments on dev mailing list.

By: damin (damin) 2006-08-18 23:54:42

Alright.. I know this is a little late but.. As luck would have it, I was informed on IRC tonight that the last couple of obstacles in the new VLDTMF code have been cleaned up and we are now at the stage where we can begin testing and getting feedback on the new implementation. We would love to see if this solves your problem. The following instructions for checking out the new VLDTMF code was sent to me by Russell Bryant a few minutes ago

From russell@digium.com Sat Aug 19 00:46:36 2006
Date: Sat, 19 Aug 2006 00:34:03 -0400
From: Russell Bryant <russell@digium.com>
To: Greg Boehnlein <damin@nacs.net>
Cc: jcolp@digium.com
Subject: Testing VLDTMF

$ svn co http://svn.digium.com/svn/zaptel/team/group/vldtmf [^] zaptel-vldtmf
$ svn co http://svn.digium.com/svn/asterisk/team/group/vldtmf [^] asterisk-vldtmf
$ cd zaptel-vldtmf ; ./configure ; make ; sudo make install
$ cd ../asterisk-vldtmf ; ./configure ; make ; sudo make install

That should be all there is to it. If you have any more questions,
please let us know!

By: Joshua C. Colp (jcolp) 2006-09-27 16:30:33

Okay folks here is the scoop - DTMF in 1.4 is vastly different to what it is in 1.2, and it can't be backported without A LOT of trouble... so I'm closing this bug. Please do give 1.4 a try as a beta, or wait for a release and open a new bug if you have issues with the implementation there. That is all and thanks all for holding on!