| 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 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| 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 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 messages. 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. | ||