|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-0600||Date Closed:||2011-06-07 14:04:48|
|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 *.|
****** ADDITIONAL INFORMATION ******
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|
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.