[asterisk-dev] [Code Review] Overlap dialling improvement for chan_sip.

[Pavel Troller]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1517/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

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. The patch implementing my proposal is subject to the review.


This addresses bug ASTERISK-18702.
    https://issues.asterisk.org/jira/browse/ASTERISK-18702


Diffs
-----

  /trunk/channels/chan_sip.c 340278 
  /trunk/channels/sip/include/sip.h 340278 

Diff: https://reviewboard.asterisk.org/r/1517/diff


Testing
-------

Tested on 1.8 and trunk testbeds, routinely used on three 1.8 installations, which require the modification, because they use the DTMF mode of SIP overlap dialling extensively since 1.4.


Thanks,

Pavel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111011/a816eccd/attachment.htm>