[asterisk-dev] Asterisk and out-of-order RFC2833 DTMF Processing

[Phillip Heller]

Hi there,

   Some months ago, I posted of a problem I'm experiencing when  
distant IP phones connect to Asterisk and attempt to login to the  
MeetMe application.

I've finally liberated a bit of my time to get back to troubleshooting  
it.  What I've found is that between the distant IP Phone and the  
Asterisk machine, some packets are getting re-ordered.

As seen in asterisk RTP debug

Got  RTP RFC2833 from   10.100.200.199:16486 (type 101, seq 020204, ts  
88520688, len 000004, mark 1, event 0000000b, end 0, duration 00000)
Got  RTP packet from    10.100.200.199:16486 (type 101, seq 020203, ts  
88520688, len 000004)
Got  RTP RFC2833 from   10.100.200.199:16486 (type 101, seq 020203, ts  
88520688, len 000004, mark 1, event 0000000b, end 0, duration 00000)
Got  RTP packet from    10.100.200.199:16486 (type 101, seq 020205, ts  
88520688, len 000004)
Got  RTP RFC2833 from   10.100.200.199:16486 (type 101, seq 020205, ts  
88520688, len 000004, mark 1, event 0000000b, end 0, duration 00000)
Got  RTP packet from    10.100.200.199:16486 (type 101, seq 020208, ts  
88520688, len 000004)
Got  RTP RFC2833 from   10.100.200.199:16486 (type 101, seq 020208, ts  
88520688, len 000004, mark 0, event 0000000b, end 1, duration 00800)
Sent RTP packet to      10.100.200.199:16486 (type 00, seq 049667, ts  
049448, len 000160)
Got  RTP packet from    10.100.200.199:16486 (type 101, seq 020207, ts  
88520688, len 000004)
Got  RTP RFC2833 from   10.100.200.199:16486 (type 101, seq 020207, ts  
88520688, len 000004, mark 0, event 0000000b, end 1, duration 00800)
Got  RTP packet from    10.100.200.199:16486 (type 101, seq 020206, ts  
88520688, len 000004)
Got  RTP RFC2833 from   10.100.200.199:16486 (type 101, seq 020206, ts  
88520688, len 000004, mark 0, event 0000000b, end 0, duration 00400)
Got  RTP packet from    10.100.200.199:16486 (type 101, seq 020209, ts  
88520688, len 000004)
Got  RTP RFC2833 from   10.100.200.199:16486 (type 101, seq 020209, ts  
88520688, len 000004, mark 0, event 0000000b, end 1, duration 00800)

As it seems the packet re-ordering is happening outside my realm of  
control, I've fixed the problem within main/rtp.c as follows:

Prior to rtp->lastseqno being set to seqno:

         int dtmflastseqno = (int) rtp->lastrxseqno;
         int dtmfseqno = (int) seqno;

And process the rfc2833 frame within a conditional check for re- 
ordered packets:

                         if (dtmflastseqno > dtmfseqno) {
                                 ast_verbose("RTP RFC2833 seqno %d  
received out of order\n",dtmfseqno);
                         } else {
                                 f = process_rfc2833(rtp, rtp->rawdata  
+ AST_FRIENDLY_OFFSET + hdrlen, res - hdrlen, seqno, timestamp);
                         }

In searching for a solution to this, I did see that there is a  
jitterbuffer implemented, though it seems to only apply to the audio  
stream.  Perhaps it could be extended to buffer rfc8233 data as well?


Regards,

--phil