----------------------------------------------------------- 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 > >
-- _____________________________________________________________________ -- 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