[asterisk-dev] [Code Review] 4532: PJSIP: Create transactions for out-of-dialog responses

[Joshua Colp]

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



/branches/13/main/threadpool.c
<https://reviewboard.asterisk.org/r/4532/#comment25511>

    This should be removed.



/branches/13/res/res_pjsip.c
<https://reviewboard.asterisk.org/r/4532/#comment25512>

    Just a question - if I somehow have two messages in-flight in processing what will happen here? I assume pjsip_tsx_create_uas will return non-PJ_SUCCESS and since we presumably will have already sent a message, or shortly will, it'll all be fine?
    
    If that happens do the callers cope fine with it?


- Joshua Colp


On March 26, 2015, 10:54 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4532/
> -----------------------------------------------------------
> 
> (Updated March 26, 2015, 10:54 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24920
>     https://issues.asterisk.org/jira/browse/ASTERISK-24920
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> A problem was found where a device was sending a MESSAGE request to a heavily loaded Asterisk system. Since Asterisk wasn't able to respond to the message within 500 ms, the device retransmitted the MESSAGE. Asterisk got around to handling the first MESSAGE, sent a 202 response and then sent the incoming MESSAGE into the dialplan to be handled. Asterisk then took the retransmission, sent a 202 response to it, and sent it into the dialplan to be handled as well.
> 
> This patch aims to fix the problem where retransmissions are being treated as new requests. This adds an API call to respond to an out of dialog request by creating a transaction and sending the response on that transaction. This way, when a retransmission arrives, the PJSIP transaction layer matches it to the transaction we created, re-sends the response, and Asterisk does not ever see the retransmission.
> 
> 
> Diffs
> -----
> 
>   /branches/13/res/res_pjsip_registrar.c 433494 
>   /branches/13/res/res_pjsip_messaging.c 433494 
>   /branches/13/res/res_pjsip/pjsip_options.c 433494 
>   /branches/13/res/res_pjsip.c 433494 
>   /branches/13/main/threadpool.c 433494 
>   /branches/13/include/asterisk/res_pjsip.h 433494 
> 
> Diff: https://reviewboard.asterisk.org/r/4532/diff/
> 
> 
> Testing
> -------
> 
> The test scenario where Asterisk was mishandling the retransmitted MESSAGE request has been confirmed to work correctly now. I also have started Asterisk and ensured that Asterisk has no errors responding to incoming REGISTER or OPTIONS requests, which are altered by this patch.
> 
> There is a testsuite review up at https://gerrit.asterisk.org/#/c/14/
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150327/7b966496/attachment-0001.html>