| Summary: | ASTERISK-18702: Improvement of overlap dialling handling in chan_sip | ||||
| Reporter: | Pavel Troller (patrol-cz) | Labels: | |||
| Date Opened: | 2011-10-10 15:27:18 | Date Closed: | 2011-11-14 15:44:15.000-0600 | ||
| Priority: | Major | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability | ||
| Versions: | 1.8.7.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) chan_sip.diff | |||
| Description: | In SIP, there is an "official" (RFC 3578 specified) way of supporting overlap dialling: Sending a 484 Address Incomplete response, which causes the calling UA to collect more digits and send a new INVITE when it gets them. This RFC has been created initially to support SS7/ISUP mapping of overlap dialling to SIP. The implementation reflects it: cancelling the incomplete session with 484 Address Incomplete response and awaiting, that the signalling gateway will send a new INVITE as soon a new digits arive to it (in the SAM message(s)). This RFC doesn't mention other possible scenarios of overlap dialling in SIP. However, it doesn't mean, that they don't generally exist. There are at least two alternate methods of overlap dialling in SIP: one is described in RFC 4730 - Keypad Stimulus protocol (KPML - currently unsupported by chan_sip) and the other, AFAIK not covered explicitly by any RFC, but also not prohibited by any, using standard DTMF delivery methods (inband, RFC2833 or SIP INFO) in the Early Media phase (i.e. after 183 Session Progress message has been sent and the media session established). The recent modification of chan_sip overlap handling implements the RFC 3578 overlap dialling method, but simultaneously disables the Early Media method, which was perfecly usable before. From this point of view, this improvement can be considered as a regression, because it can break perfectly running Asterisk environments, which were there since at least 1.4 days, and especially in my case it really breaks them. The problem is, that the current implementation knows only 2 states: allowoverlap=yes, which requires support of 484 message on the UA, or allowoverlap=no, which simply sends back 404 Not Found in the case of incomplete number entry, thus disallowing any possible alternate method of overlap dialling. I propose the following improvement for the allowoverlap SIP option: 1) allowoverlap=yes: The UA understands the 484 response and is able to fully support RFC 3578 recommended overlap dialling. Calling Incomplete() from the dialplan causes the 484 response to be sent. 2) allowoverlap=dtmf: The UA doesn't understand the 484 response, but it's capable to continue dialling with a DTMF delivery mechanism specified in the "dtmfmode" option. In this case, the dialplan must ensure that the Early Media state is properly established before the Incomplete() application is called. Calling Incomplete() from the dialplan is ignored by chan_sip in this case (as it was before the RFC 3578 implementation). 3) allowoverlap=no: The UA doesn't understand the 484 response and is not capable to send DTMF in the Early Media state, OR the system dial plan is not adopted for this kind of signalling. In this case, Incomplete() will send 404 immediately. I think that implementing this cannot make any harm to the Asterisk, and it will substantially improve the flexibility of the SIP channel regarding the overlap dialling possibilities. I've prepared a patch (against the 1.8 branch), which implements the improvement. It is attached to the case. | ||||
| Comments: | By: Pavel Troller (patrol-cz) 2011-10-10 15:31:00.527-0500 An experimental implementation of the improvemen. By: Richard Mudgett (rmudgett) 2011-11-11 18:40:13.834-0600 See reviewboard https://reviewboard.asterisk.org/r/1582/ for an updated version of the patch. | ||||