| Summary: | ASTERISK-02852: [patch] Asterisk sends repeated rtp seq number with rfc2833 dtmf | ||
| Reporter: | Terry Wilson (twilson) | Labels: | |
| Date Opened: | 2004-11-18 14:17:15.000-0600 | Date Closed: | 2008-01-15 15:14:21.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) rtp.c.patch.txt | |
| Description: | When asterisk retransmits the End of Event packets for a rfc2833 digit, it does so without incrementing the rtp sequence number. This patch increments the sequence number so that we avoid rtp sequence errors. ****** ADDITIONAL INFORMATION ****** RFC 2833 states: If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly. (The RTP sequence number is incremented by one for each packet.) If there has been no new event in the last interval, the event SHOULD be retransmitted three times or until the next event is recognized. This ensures that the duration of the event can be recognized correctly even if the last packet for an event is lost. When they say that the event should be retransmitted, I think (though I could be wrong) that they are not saying to retransmit the packet (including sequence number), but to retransmit the event portion (rtpheader[3]) while incrementing the rtp sequence number. Tests with several UAs that send rfc2833 show that this is how the manufacturers of these devices interpreted the rfc. I only bring it up because I was having some g729/rfc2833 issues doing some interoperability testing with a rather large nationwide CLEC that terminates traffic via SIP... | ||
| Comments: | By: Mark Spencer (markster) 2004-11-18 16:29:36.000-0600 Why the else if (x < 3) ? doesn't that make the same seqno get repeated the third time? By: Terry Wilson (twilson) 2004-11-18 16:58:52.000-0600 My first try left out the (x<3), but in testing it skipped a sequence number when switching back to to the codec. With the (x<3) the seq numbers seem to increment correctly. By: Terry Wilson (twilson) 2004-11-18 17:04:03.000-0600 oh, and I do have a disclaimer on file as well... By: Mark Spencer (markster) 2004-11-19 00:24:57.000-0600 You're right, it makes sense now, looking at the loop. Fixed in CVS head. By: Russell Bryant (russell) 2004-11-25 02:04:47.000-0600 fixed in 1.0 - will be in 1.0.3 By: Digium Subversion (svnbot) 2008-01-15 15:14:21.000-0600 Repository: asterisk Revision: 4293 U trunk/rtp.c ------------------------------------------------------------------------ r4293 | markster | 2008-01-15 15:14:21 -0600 (Tue, 15 Jan 2008) | 2 lines Increment seqno in RTP in RFC2833 (bug ASTERISK-2852) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4293 | ||