[asterisk-bugs] [JIRA] (ASTERISK-25363) PJSIP/rls and Testsuite: channels/pjsip/subscriptions/rls/lists/off_nominal/large_notify reports success after reactor times out and terminates the unfinished sipp scenario

[Jonathan Rose (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Rose updated ASTERISK-25363:
-------------------------------------

    Attachment: sipp_test_fail_on_timeout.patch

> PJSIP/rls and Testsuite: channels/pjsip/subscriptions/rls/lists/off_nominal/large_notify reports success after reactor times out and terminates the unfinished sipp scenario
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25363
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25363
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Tests/testsuite
>    Affects Versions: 13.5.0
>         Environment: Ubuntu 12.04 64 bit
>            Reporter: Jonathan Rose
>         Attachments: sipp_test_fail_on_timeout.patch
>
>
> The rls/lists/off_nominal/large_notify test is incorrectly written and the sipp scenario associated with it expects a NOTIFY that it will never receive. Because the notify being created is too large, a number of PJSIP_EUNSUPTRANSPORT warning are raised and the request is never actually sent back to sipp which just keeps on waiting until reactor times out and when reactor times out, it makes the sipp module pass because sipp's return value/error code is the same on successful completion as it is on forceful termination by an outside process.
> Suggested course of action for testsuite: SIPpTestCase should fail on timeout. I'm attaching a patch to deal with this and there might be some tests caused to fail by this that shouldn't (if they were also relying on this behavior for instance). It is my opinion that tests that rely on reactor timeouts should be the exception and not the rule though and that either those tests should have their approach reconsidered or else SIPpTestCase should have an option flag for either allowing pass on reactor timeout or specifying a custom on_reactor_timeout function.
> Suggested course of action for this specific test: Asterisk does not in any way inform SIPp of the errors taking place here, so there is no way to tell that a NOTIFY isn't sent and won't be sent. We could do what we are doing, that is to say verify that the sipp scenario fails, but that is somewhat inadequate since we won't know whether the early parts of the test passed. It may be necessary to add test events to determine that Asterisk attempted a notify but failed to issue it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)