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

[rmudgett]

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



/team/mjordan/AST_17288/1.8/channels/chan_dahdi.c
<https://reviewboard.asterisk.org/r/1416/#comment8293>

    Spaces after commas. :)



/team/mjordan/AST_17288/1.8/channels/chan_h323.c
<https://reviewboard.asterisk.org/r/1416/#comment8295>

    No break?



/team/mjordan/AST_17288/1.8/channels/chan_usbradio.c
<https://reviewboard.asterisk.org/r/1416/#comment8296>

    This probably should be an independent case:
    case AST_CONTROL_INCOMPLETE:
       res = AST_CONTROL_CONGESTION;
       break;



/team/mjordan/AST_17288/1.8/channels/sig_pri.c
<https://reviewboard.asterisk.org/r/1416/#comment8297>

    This should be:
    if (!(p->pri->overlapdial & DAHDI_OVERLAPDIAL_INCOMING)
        || p->call_level != SIG_PRI_CALL_LEVEL_OVERLAP) {



/team/mjordan/AST_17288/1.8/channels/sig_pri.c
<https://reviewboard.asterisk.org/r/1416/#comment8298>

    New code does not need to check the return value of pri_grab() since it always returns zero because it can never fail.



/team/mjordan/AST_17288/1.8/channels/sig_pri.c
<https://reviewboard.asterisk.org/r/1416/#comment8299>

    break missing.



/team/mjordan/AST_17288/1.8/main/channel.c
<https://reviewboard.asterisk.org/r/1416/#comment8300>

    This probably should be with AST_CONTROL_CONGESTION since you are going to hear this as a congestion tone.



/team/mjordan/AST_17288/1.8/main/channel.c
<https://reviewboard.asterisk.org/r/1416/#comment8301>

    This should be handled the same as a congestion since the driver did not handle it.



/team/mjordan/AST_17288/1.8/main/channel.c
<https://reviewboard.asterisk.org/r/1416/#comment8302>

    This should be like a congestion.



/team/mjordan/AST_17288/1.8/main/features.c
<https://reviewboard.asterisk.org/r/1416/#comment8303>

    I think this just needs to convert the frame to a congestion since you are inside of the bridge between party A and party B during an attended transfer.
    
    This scenario definitely needs to be tested.


- rmudgett


On Sept. 6, 2011, 12:32 p.m., mjordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1416/
> -----------------------------------------------------------
> 
> (Updated Sept. 6, 2011, 12:32 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
> -----
> 
>   /team/mjordan/AST_17288/1.8/apps/app_dial.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_alsa.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_console.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_dahdi.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_h323.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_mgcp.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_misdn.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_oss.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_sip.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_skinny.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_unistim.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/chan_usbradio.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/sig_pri.c 334565 
>   /team/mjordan/AST_17288/1.8/channels/sig_ss7.c 334565 
>   /team/mjordan/AST_17288/1.8/funcs/func_frame_trace.c 334565 
>   /team/mjordan/AST_17288/1.8/include/asterisk/frame.h 334565 
>   /team/mjordan/AST_17288/1.8/main/channel.c 334565 
>   /team/mjordan/AST_17288/1.8/main/dial.c 334565 
>   /team/mjordan/AST_17288/1.8/main/features.c 334565 
>   /team/mjordan/AST_17288/1.8/main/pbx.c 334565 
> 
> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110906/3ca95607/attachment-0001.htm>