Summary:	ASTERISK-03750: In IAX, Dial's D() modifier sends only the first tone
Reporter:	edgreenberg (edgreenberg)	Labels:
Date Opened:	2005-03-23 08:50:51.000-0600	Date Closed:	2011-06-07 14:10:17
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) iaxlostdigits.txt ( 1) iaxlostdigits2.txt ( 2) failed_sample.cap ( 3) good_sample_101.cap
Description:	Dialing string such as "IAX2/9999@voipjet/13115552368|60|D(w123456)" sends only the first tone. The call is supposed to open the talk path only after all the digits are sent. Instead, it sends one digit and cuts. ****** ADDITIONAL INFORMATION ****** I put a bunch of logging into my test system and discovered that when we get to ast_write, the code loops through all the digits, but only the first digit is heard (see attached). I tried this with a SIP based provider and it seems (on very first test) to work fine.
Comments:	By: Mark Spencer (markster) 2005-03-23 23:23:31.000-0600 I hate to state the obvious but did you not try an IAX debug to see if the digits were going out? By: edgreenberg (edgreenberg) 2005-03-24 00:23:44.000-0600 I am not good at reading that the IAX debug output but I've attached it. See iaxlistditits2.txt. It seems that the digits (51668154320123456 in this case) are being processed. Could you please read the trace and see if there is anything to fix, or if I should complain to voipjet? Thanks. By: edgreenberg (edgreenberg) 2005-03-24 16:01:27.000-0600 In response to Kris2k, I have it working fine with LiveVoip (SIP) By: Mark Spencer (markster) 2005-03-24 16:05:43.000-0600 This does appear to be a voipjet issue.  From the debug, we are sending the digits out, clearly. By: edgreenberg (edgreenberg) 2005-06-22 15:26:34 I'm reopening this since there's more information. This time, I was trying to make it work with SIP. In tracing the RTP, I've discovered that the timing on the RFC2833 packets is not correct. When the digits are sent, all the packets are sent within the same 100ms. Take a look at packets 91-96, for example. Duration does not increase and timestamp is not in sync with the packets around it. On the "good" capture, which I got from our Level 3 engineer, please take a look at 407-423.  There is an rfc2833 packet every 20 seconds, until the tone ends. The timestamp properly tracks real time, and the event duration clocks up in step with real time as well. Level 3 discards all the tones after the first one, since they are out of time spec. By: Kevin P. Fleming (kpfleming) 2005-06-22 16:18:36 There have been multiple changes in the RFC2833 DTMF code in CVS HEAD, but those changes have not been backported to the v1-0 branch since they are a significant behavior change. If possible, please try to reproduce this problem with CVS HEAD, so we can determine whether our new DTMF generation logic is enough to solve the problem. If so, we can decide whether to backport it to v1-0 or not. Note: the RFCs are very ambiguous on this topic, and if the peer you are sending DTMF to is being that strict, it's going to be hard to interoperate with them with many types of devices that don't generate DTMF in that exact pattern (Cisco phones, for example). By: Michael Jerris (mikej) 2005-06-23 04:23:42 Notes indicate you are running on 1.0.5 (which is somwhat old), have you tried current stable cvs (I know we are waiting for test on current cvs head). By: Michael Jerris (mikej) 2005-07-20 20:27:53 unfortunately we are unable to address this issue furthur without additonal input from you.  I have to suspend this bug as there is nothing else we can do without testing on current head and/or current 1.0.x branch.  Feel free to reopen this bug when you have the results of those tests. By: Digium Subversion (svnbot) 2008-01-15 15:17:20.000-0600 Repository: asterisk Revision: 4497 U   branches/v1-0/res/res_features.c ------------------------------------------------------------------------ r4497 | russell | 2008-01-15 15:17:19 -0600 (Tue, 15 Jan 2008) | 2 lines fix parking issue (bug ASTERISK-3750) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4497