[asterisk-dev] [Code Review] SIP 484 handling fix and new Incomplete app control frame

Pavel Troller patrol at sinus.cz
Fri Sep 23 22:53:08 CDT 2011 

Hi!
  This change broke chan_sip for me. I've found it today, after updating my 1.8
SVN branch.
  The problem is, that my dialplans are commonly using the "incomplete" status,
waiting for more digits.
  The extension logic sends Progress() as soon as possible, which transforms to
183 Session Progress SIP message with SDP, thus establishing early media. Since
then, most SIP devices are able to dial using either RFC2833 or SIP INFO 
method, even the channel was not yet answered. This was successfully used to
complete the dialled number in something like "pseudo-overlap mode" (from the
SIP point of view, from the dialplan point of view it is a real overlap mode).
  Since this latest change, SIP definitely behaves better (according to the
spec), when allowoverlap=yes is set. However, when it is NOT set, it currently
immediately sends back 404 Not Found, which is fatal for me. There are no other
channels, which drop the connection upon receipt of the INCOMPLETE frame; I
don't see any explicit reason why SIP should do it, especially when there is a
possibility of receiving the next digits as described above.
  Also, think about the scenario, when there is a "t" extension, connecting the
caller to somebody like an operator or similar service. Even if the caller will
not be able to continue dialling (if he uses one of the very few devices, which
will not pass RFC2833 or INFO before real answer), he would be connected to
this service due to timeout. With your change, it's also impossible.
  I've patched the code, that it keeps your change with sending 484 back, but
discards the 404 case unconditionally. Maybe, the better way would be to have a
"three-way" allowoverlap option, like:
  allowoverlap=yes  ; use standard 484 Number Incomplete handling
  allowoverlap=dtmf ; ignore the Incomplete status and continue
  allowoverlap=no   ; send back 404 Not found response and terminate the call.
  If you are willing to accept this change, I will prepare the patch
accordingly and create a JIRA case for it.
  With regards,
    Pavel Troller
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1416/#review4275
> -----------------------------------------------------------
> 
> Ship it!
> 
> 
> I don't see anything else to really point out.
> 
> - rmudgett
> 
> 
> On Sept. 8, 2011, 2:12 p.m., mjordan wrote:
> > 
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviewboard.asterisk.org/r/1416/
> > -----------------------------------------------------------
> > 
> > (Updated Sept. 8, 2011, 2:12 p.m.)
> > 
> > 
> > Review request for Asterisk Developers, David Vossel and rmudgett.
> > 
> > 
> > Summary
> > -------
> > 
> > ASTERISK-17288 was filed against chan_sip.  When a response code of "484 Address Incomplete" was received by the dialplan, the channel was being hung up with a hangup cause of 111, as opposed to the RFC recommended 28.  Upon resolving this, the previously implemented logic for Incomplete extension dialing was triggered (implemented under ASTERISK-11768).  For SIP phones, this had a somewhat unexpected result: upon receiving the 484 response back from the dialed device, the dialplan would send no information back to the device that dialed the numbers, and, after a period of time, would timeout (transferring to either the 't' or 'i' extension, depending on the dialplan).
> > 
> > While this was the intended effect of the pbx Incomplete logic, it was not desired by the issue reporter.  What's more, for SIP phones, since no information was being forwarded back to the dialing device that the number that they dialed was incomplete, the device did not know to dial more numbers.
> > 
> > After discussion on asterisk-dev with Kevin and the issue reporter, the following decisions were made:
> > 1. app_dial by default should not attempt to place a call into Incomplete - functionality should be triggered by explicit dialplan usage
> > 2. Incomplete application should notify channels that they are in Incomplete status using a control frame. That allows channel tech to automatically hangup if no more digits are possible.
> > 
> > A new control frame AST_CONTROL_INCOMPLETE was added and is sent to the channel in the Incomplete application.  Otherwise, the Incomplete application logic was left unchanged.
> > 
> > Handling the control frame differs on the channel technology.  With respect to SIP, an Incomplete implies immediately sending the 484 Address Incomplete response to the dialing device and performing a soft hangup, as a new INVITE sequence is required.  If the device wants to retry, then the device will resend the URI with whatever appended digits it determines is needed to try for the next extension.
> > 
> > For other channel technologies, it depends on their implementation and their support for overlapped dialing.  DAHDI (and sig_pri) and mISDN have support for overlapped dialing - for those cases, receiving an AST_CONTROL_INCOMPLETE means either doing nothing if overlapped dialing is supported (and if the channel is in a state that it can receive additional digits), or hanging up if overlapped dialing is not supported.  In the case of a hangup, the approach was taken to emulate AST_CONTROL_CONGESTION.
> > 
> > For channels that do not support overlapped dialing, they treat a control frame of AST_CONTROL_INCOMPLETE as if it were AST_CONTROL_CONGESTION.
> > 
> > 
> > This addresses bug ASTERISK-17288.
> >     https://issues.asterisk.org/jira/browse/ASTERISK-17288
> > 
> > 
> > Diffs
> > -----
> > 
> >   /branches/1.8/addons/chan_ooh323.c 334951 
> >   /branches/1.8/apps/app_dial.c 334951 
> >   /branches/1.8/channels/chan_alsa.c 334951 
> >   /branches/1.8/channels/chan_console.c 334951 
> >   /branches/1.8/channels/chan_dahdi.c 334951 
> >   /branches/1.8/channels/chan_h323.c 334951 
> >   /branches/1.8/channels/chan_mgcp.c 334951 
> >   /branches/1.8/channels/chan_misdn.c 334951 
> >   /branches/1.8/channels/chan_oss.c 334951 
> >   /branches/1.8/channels/chan_sip.c 334951 
> >   /branches/1.8/channels/chan_skinny.c 334951 
> >   /branches/1.8/channels/chan_unistim.c 334951 
> >   /branches/1.8/channels/chan_usbradio.c 334951 
> >   /branches/1.8/channels/sig_pri.c 334951 
> >   /branches/1.8/channels/sig_ss7.c 334951 
> >   /branches/1.8/funcs/func_frame_trace.c 334951 
> >   /branches/1.8/include/asterisk/frame.h 334951 
> >   /branches/1.8/main/channel.c 334951 
> >   /branches/1.8/main/dial.c 334951 
> >   /branches/1.8/main/features.c 334951 
> >   /branches/1.8/main/pbx.c 334951 
> > 
> > Diff: https://reviewboard.asterisk.org/r/1416/diff
> > 
> > 
> > Testing
> > -------
> > 
> > Two new Asterisk test suites were written to test the behavior for SIP (review on https://reviewboard.asterisk.org/r/1417/ ).  These two tests check that Asterisk handles the SIP 484 Address Incomplete both when the response is returned and the Incomplete application is not used, and when the Incomplete application is used.
> > 
> > Additional testing will be needed for other channel types.  DAHDI will be tested in conjunction with this review; other channels whose support are extended will require testing by the Asterisk community.
> > 
> > 
> > Thanks,
> > 
> > mjordan
> > 
> >
> 

> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

More information about the asterisk-dev mailing list