| Summary: | ASTERISK-01626: Outbound DTMF Fails with Telica - RFC2833 Sends DTMF Packets with Identical Timestamp and Sequence Numbers | ||
| Reporter: | Simon Rowland (funky) | Labels: | |
| Date Opened: | 2004-05-14 23:36:00 | Date Closed: | 2008-01-15 14:54:46.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Only the first digit is detected when using RFC2833 when communicating with a Telica VoIP Gateway. The Telica is like a MAXTNT, except much larger. We noticed that the Telica indicates in the SIP INVITE message that it supports DTMF tones from 0-15 (ie 0-9,*,#,A-D) while Asterisk indicates it supports 0-16. Changing the sources to indicate only 0-15 did not fix the issue. (16 is flash hook.) I was speaking with some senior support folks at Telica trying to work out the issue, and they played back the following packet captures into a Telica machine in their lab. I was attempting to use send_dtmf via an AGI, to send the digits 12345678901234567890. Only the '1' was received. The folks at Telica noticed that the Sequence Number and Timestamp doesn't change as the dtmf digits are sent through. - The Telica doesn't interpret the dtmf signals if the sequence number and timestamp overlaps. - Each packet should have a unique sequence number - The timestamps really shoudl be updated wiht each subsequent DTMF packet. ****** ADDITIONAL INFORMATION ****** The following packet captures wil be included as attachments until the bug is closed: http://207.112.117.194/captures/capture-195-ast1 http://207.112.117.194/captures/capture-196-ast1 | ||
| Comments: | By: Mark Spencer (markster) 2004-05-15 00:13:43 Are you using CVS head? By: Simon Rowland (funky) 2004-05-15 10:53:05 Yes, using the head branch from about a week ago. By: Mark Spencer (markster) 2004-05-15 12:16:07 First let me clarify a couple of things: 1) Each number is transmitted in a burst of 4 packets. 2) The sequence number *does* increment from the first to the second entry in each burst but does not increment in the remaining two. That's because the 2nd, 3rd, and 4th packets endicate the end of the condition, and as per section 3.6 of RFC2833, "... the [last] event SHOULD be retransmitted three times ..." Still, though, the timestamp issue is clearly a mistake and is occuring becuase the code was mistakingly written on the assumption that audio would be transmitted between digits (which in typicaly gateway applications it is, but not if you're using senddigit. Anyway the fix is in CVS head and should propagate itself through in about 30-45 minutes from this posting. Please test it and confirm that fixes the issue. Thanks. By: Simon Rowland (funky) 2004-05-16 10:41:46 I tested it, and it works! Asterisk is now compatible with a very large VoIP gatway. Thank you for getting right on this with such diligence, you've got a great achievement with asterisk. By: Mark Spencer (markster) 2004-05-16 12:51:02 Glad to be of service. By: Digium Subversion (svnbot) 2008-01-15 14:54:46.000-0600 Repository: asterisk Revision: 2969 U trunk/rtp.c ------------------------------------------------------------------------ r2969 | markster | 2008-01-15 14:54:46 -0600 (Tue, 15 Jan 2008) | 2 lines Fix typo in outgoing rfc2833 handling (bug ASTERISK-1626) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=2969 | ||