> On March 27, 2015, 10:39 a.m., Joshua Colp wrote: > > /branches/13/res/res_pjsip.c, lines 3325-3328 > > <https://reviewboard.asterisk.org/r/4532/diff/1/?file=72952#file72952line3325> > > > > 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?
If you have two messages in flight, and Asterisk handles them simultaneously in different threads, it should work out okay. At some point the threads will hit a critical section in the PJSIP transaction code where they will create a transaction key and search if that transaction already exists. The first to hit the section will succeed, and Asterisk will send a response. The second to hit that section will fail and return PJ_EEXISTS, and Asterisk will not send a response. However, since we sent a response to the other request, all works out. - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4532/#review14886 ----------------------------------------------------------- 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
