[asterisk-dev] [Code Review]: Tests for SIP handling of 484 Address Incomplete; Incomplete application

[mjordan]

> On Sept. 20, 2011, 9:39 a.m., Paul Belanger wrote:
> >

Cleaned up and submitted.


> On Sept. 20, 2011, 9:39 a.m., Paul Belanger wrote:
> > /asterisk/trunk/tests/channels/SIP/handle_response_address_incomplete/run-test, line 69
> > <https://reviewboard.asterisk.org/r/1417/diff/1/?file=20010#file20010line69>
> >
> >     Not sure why we are stopping the reactor here.  From the looks of the code asterisk dialplan it is possible for more then one user event to fire?

Actually no.  Any UserEvent but the pass UserEvent is a failure, so we stop the test execution.  If we see the pass UserEvent, we are (by the dialplan) about to hangup, so stopping the reactor is fine there as well.

Where it may appear as if there are two UserEvents is on line 8 of the dialplan and on line 16 - wherein, the extension 1234 would fail (with an invalid hangup cause) and the user would redial into 12345.  What this is actually testing for is auto-transitioning into Incomplete, which was the previous behavior of chan_sip with a 484 response.  In that case, neither UserEvent in extension 1234 would have been hit - after the Dial application, it would have gone back into the main pbx loop and waited for more digits.  So again, only a single UserEvent would be sent.


- mjordan


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


On Sept. 6, 2011, 12:45 p.m., mjordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1417/
> -----------------------------------------------------------
> 
> (Updated Sept. 6, 2011, 12:45 p.m.)
> 
> 
> Review request for Asterisk Developers, Paul Belanger and rmudgett.
> 
> 
> Summary
> -------
> 
> These tests are for the change under review for ASTERISK-17288 (https://reviewboard.asterisk.org/r/1416/ ).  They test SIP handling of 484 Address Incomplete and the Incomplete application's effect on chan_sip.
> 
> 
> This addresses bug ASTERISK-17288.
>     https://issues.asterisk.org/jira/browse/ASTERISK-17288
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/lib/python/asterisk/sipp.py 2057 
>   /asterisk/trunk/tests/apps/incomplete/sip_incomplete/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/apps/incomplete/sip_incomplete/configs/ast1/manager.general.conf.inc PRE-CREATION 
>   /asterisk/trunk/tests/apps/incomplete/sip_incomplete/configs/ast1/sip.conf PRE-CREATION 
>   /asterisk/trunk/tests/apps/incomplete/sip_incomplete/run-test PRE-CREATION 
>   /asterisk/trunk/tests/apps/incomplete/sip_incomplete/sipp/receiver1.xml PRE-CREATION 
>   /asterisk/trunk/tests/apps/incomplete/sip_incomplete/sipp/sender1.xml PRE-CREATION 
>   /asterisk/trunk/tests/apps/incomplete/sip_incomplete/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/apps/incomplete/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/apps/tests.yaml 2057 
>   /asterisk/trunk/tests/channels/SIP/handle_response_address_incomplete/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/handle_response_address_incomplete/configs/ast1/manager.general.conf.inc PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/handle_response_address_incomplete/configs/ast1/sip.conf PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/handle_response_address_incomplete/run-test PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/handle_response_address_incomplete/sipp/uas1.xml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/handle_response_address_incomplete/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/tests.yaml 2057 
> 
> Diff: https://reviewboard.asterisk.org/r/1417/diff
> 
> 
> Testing
> -------
> 
> Without the patch for ASTERISK-17288, both tests will fail.  The application Incomplete test will fail with a timeout to the t extension, as it received no additional information to dial (and the SIP test will fail as the 484 response will never be forwarded to the dialing party).  The SIP handle response test will fail with a hangup cause of 111.
> 
> 
> Thanks,
> 
> mjordan
> 
>

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