[Home]

Summary:ASTERISK-04591: [patch] RTP rfc2833 out of sequence problem
Reporter:Kevin P. Fleming (kpfleming)Labels:
Date Opened:2005-07-14 19:51:36Date Closed:2011-06-07 14:10:32
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If rtp rfc2833 packets arrive out of sequence for a single DTMF event, <br />
Asterisk may report double or triple digits received. This occurs<br />
when Asterisk HEAD/Stable is communicating with Asterisk HEAD/Stable.<br />
<br />
Six rtp packets are sent via ast_rtp_sendigit() - the first packet <br />
has the marker bit set and the last three have the end bit set. <br />
If one for the last three packets (with the end bit set) arrives <br />
before all of the first three packets arrive a duplicate send_dtmf()<br />
occurs for the event.<br />
<br />
For example, this is the debug channel output for a single DTMF event<br />
corresponding to receiving the digit '1' in the case where the forth <br />
rtp packet (the first packet with the end bit set) is received second. <br />
The result is Asterisk reads two DTMF events instead of one.<br />
<br />
local*CLI> debug channel SIP/john-5d4d<br />
Debugging enabled on channel SIP/john-5d4d<br />
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/john-5d4d]<br />
<< [ TYPE: DTMF (1) SUBCLASS: 1 (49) ] [SIP/john-5d4d]<br />
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/john-5d4d]<br />
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/john-5d4d]<br />
<< [ TYPE: DTMF (1) SUBCLASS: 1 (49) ] [SIP/john-5d4d]<br />
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/john-5d4d]<br />
<br />
The sequence numbers of the rtp packets in the following example are<br />
52924 52925 52926 52927 52928 52929. Asterisk sends them in this order,<br />
but by the time the receiving Asterisk gets them, they arrive in the order<br />
52924 52927 52925 52926 52929 52928. This is reasonable and not surprising.<br />
<br />
This is a tcpdump of the same event:<br />
<br />
#  tcpdump -T rtp -vvv host remote and less 100<br />
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes<br />
11:31:06.327425 IP (tos 0x0, ttl  49, id 565, offset 0, flags [DF], \<br />
proto 17, length: 44) remote.19392 > local.16224: \<br />
udp/rtp 4 c101 * 52924 90280 1440528472<br />
11:31:06.327930 IP (tos 0x0, ttl  49, id 568, offset 0, flags [DF], \<br />
proto 17, length: 44) remote.19392 > local.16224: \<br />
udp/rtp 4 c101  52927 90280 1440528472<br />
11:31:06.328451 IP (tos 0x0, ttl  49, id 566, offset 0, flags [DF], \<br />
proto 17, length: 44) remote.19392 > local.16224: \<br />
udp/rtp 4 c101  52925 90280 1440528472<br />
11:31:06.329064 IP (tos 0x0, ttl  49, id 567, offset 0, flags [DF], \<br />
proto 17, length: 44) remote.19392 > local.16224: \<br />
udp/rtp 4 c101  52926 90280 1440528472<br />
11:31:06.329582 IP (tos 0x0, ttl  49, id 570, offset 0, flags [DF], \<br />
proto 17, length: 44) remote.19392 > local.16224: \<br />
udp/rtp 4 c101  52929 90280 1440528472<br />
11:31:06.330529 IP (tos 0x0, ttl  49, id 569, offset 0, flags [DF], \<br />
proto 17, length: 44) remote.19392 > local.16224: \<br />
udp/rtp 4 c101  52928 90280 1440528472<br />
<br />
If, in this example, the packets happened to arrive in the order<br />
52924 52927 52925 52928 52926 52929, Asterisk would report receiving<br />
three DTMF digits. <br />
<br />
While I took the time last night to read rfc2833, I was unfortunately<br />
unable to figure out exactly what is supposed to be sent. So assuming<br />
the ast_rtp_senddigit() is doing something considered correct, it <br />
appears that receiving side needs to be modified to correctly handle<br />
the case where packets arrive out of sequence.<br />
<br />
One change that may fix the problem (at least in the cases<br />
I could think of) is to restrict the processing of rfc2833 packets<br />
to those whose sequence number is greater than or equal to the<br />
most recently processed rfc2833 packet. I think this can be done by <br />
modifying ast_rtp_read() line 480 (in HEAD) from:<br />
<br />
if (rtp->lasteventseqn <= seqno || rtp->resp == 0 || <br />
   (rtp->lasteventseqn >= 65530 && seqno <= 6)) {<br />
<br />
to:<br />
<br />
if (rtp->lasteventseqn <= seqno || <br />
   (rtp->lasteventseqn >= 65530 && seqno <= 6)) {<br />
<br />
<br />
Disclaimer:<br />
I read the Bug Guidelines and I understand that I may need to submit<br />
a disclaimer for suggesting the removal of approx 20 chars from an<br />
if statement and I would be happy to do so if it required in this case. <br />
If the above needs to be submitted in patch form, I would be happy to <br />
submit it in that form as well. I apologize in advance if I have violated<br />
the Guidelines with this posting.<br />
<br />
Comments:By: Matt O'Gorman (mogorman) 2005-11-08 13:38:05.000-0600

are we accepting this and should we just get the disclaimer.  or has it already been submitted?
By: John Riordan (john) 2005-11-08 14:33:33.000-0600

Disclaimer was submitted along with parent bug ASTERISK-4614659