Summary:ASTERISK-01027: SIP DTMF INFO mode does not work reliably
Reporter:Ricardo Villa (ricvil)Labels:
Date Opened:2004-02-11 21:07:42.000-0600Date Closed:2011-06-07 14:04:48
Versions:Frequency of
Description:When a SIP client makes a call through * and connects to an IVR, DTMF does not work reliably if there is any retransmission of SIP INFO Messages from the client to *.


SIP INFO packets are sent from the client to *, and * sends a Status 200 OK back to the client.  These packets contain a CSeq number which helps to identify the proper sequence of SIP INFO packets sent.  It the client sends a SIP INFO packet to * and it does not receive a STATUS 200 OK soon, then it sends another identical packet (with same CSeq #), but * treats it as another DTMF input and thus breaks the entire input.  * should look at that CSeq # to determine the correct order of the DTMF input as well as duplicates.  

This problem is easily reproducible by cranking up the bandwidth usage at a remote location thus forcing delays and retransmissions of SIP packets.
Comments:By: Brian West (bkw918) 2004-02-11 23:16:56.000-0600

What phones?

By: Brian West (bkw918) 2004-02-11 23:17:34.000-0600

Also what does the RFC say on this?

By: Ricardo Villa (ricvil) 2004-02-12 00:04:24.000-0600

Phones tested so far: Sipura and Grandstream.

And in regards to the RFC I just looked at it and read this lame statement:

  In addition, the INFO method does not define additional mechanisms
  for ensuring in-order delivery.  While the CSeq header will be
  incremented upon the transmission of new INFO messages, this should
  not be used to determine the sequence of INFO information.  This is
  due to the fact that there could be gaps in the INFO message CSeq
  count caused by a user agent sending re-INVITES or other SIP

So in conclusion SIP INFO is not as reliable as I thought.  I will stick with RFC2833.  

This BUG can be closed...sorry for wasting time here.