On Mon, Feb 27, 2012 at 2:32 PM, Gang Liu <gangban.lau at gmail.com> wrote: > Hi, > I saw this scenario before. The B sip device was VOS which it is a > popular but not good implemented > soft switch. > I found that call was disconnected at side B when it sent back > CANCEL 200 OK response. And if > A sent out BYE to clear the dialog, the response from B was 481. > I don't think B is following RFC 3261 well. > It looks like B is following RFC 2543 instead. > For better implementation, B should response 4xx rather than 200 > because related dialog already > connected before CANCLE arrived. > Actually RFC 3261 says that CANCEL should be responded with 200. And for A, normally we need a timer to wait for DISCONNECTED event > call back from pjsip-ua > to make sure related dialog resource is released. Then we could easy > detect this race condition at there > when that timer timeout. > > We already have the timer to wait for disconnection, but I think we're discussing different case here, i.e. when the call actually gets connected instead. cheers, Benny > regards, > Gang > > On Fri, Feb 24, 2012 at 6:28 AM, Steve King <sking at zetron.com> wrote: > > Hi Alan, > > > > Thanks for the email. > > > > In this instance, PJSIP is acting as UAC, not UAS so Rule 9.2 does not > apply to it. > > At B, 9.2 rule is followed correctly. > > The standard does not seem to mention this particular scenario. > > > > Logically, as the app, I have requested PJSIP end that session, however > PJ does not do that and allows the session to be established. > > > > In effect, *all* PJSIP based applications are then forced to perform a > check if the session is being ended when the session is reported as > established/confirmed. Does pjsua handle this scenario? > > > > Imho, I think its sensible for PJSIP to take about this. > > > > Steve > > > >> -----Original Message----- > >> From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip- > >> bounces at lists.pjsip.org] On Behalf Of Alain Totouom > >> Sent: Thursday, 23 February 2012 07:51 PM > >> To: pjsip list > >> Subject: Re: CANCEL and final INVITE response glare ("crosses > >> the wire") > >> > >> Hi Steve, > >> > >> On 02/23/2012 08:36 AM, Steve King wrote: > >> > Hi Benny, > >> > > >> > > >> > > >> > The scenario is: > >> > > >> > > >> > > >> > A B > >> > > >> > 1. =====> INVITE > >> > > >> > 2. <==== 100 Trying > >> > > >> > 3. =====> CANCEL > >> > > >> > 4. <===== 200 OK (INVITE w SDP) > >> > > >> > 5. =====> ACK > >> > > >> > 6. <===== 200 OK (CANCEL) > >> > > >> > > >> > > >> > In this case, B sends final INVITE response(4) before receiving > >> > CANCEL(3), PJSIP receives the response, ACKs it and indicates up to > >> > the application that the call is connected and its media available > >> > (not good). The 200 response to the CANCEL is according to spec and > >> > terminates the tsx for the CANCEL. > >> > > >> > > >> > > >> > This has been touched on before in a previous thread: > >> > http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009- > >> September/ > >> > 00 > >> > 8945.html > >> > > >> > But no real conclusion was reached. > >> > > >> > > >> > > >> > I think this case can/should be handled in the SIP stack, rather than > >> > at the application layer. > >> > > >> > >> We are definitively missing one part of the conversation here: what > >> does the calleR do, when it ends up with an established dialog, despite > >> the succeful completion of the CANCEL-Transaction it has previously > >> issued?!? > >> At application level is easier to catch and resolve that conflict by > >> sending a BYE/UAC... > >> > >> Here is what the standard says about this hop-by-hop request as far as > >> the UAS is concerned... > >> > >> 9.2 Server Behavior > >> "If the transaction for the original request still exists, the behavior > >> of the UAS on receiving a CANCEL request depends on whether it has > >> already sent a final response for the original request. If it has, the > >> CANCEL request has no effect on the processing of the original request, > >> no effect on any session state, and no effect on the responses > >> generated for the original request." > >> > >> IMHO PJSIP is strictly following the 9.2 rule... > >> > >> The best place to solve this race condition and be fully #3261 ?9 > >> compliant should/would definitively be at the application level. > >> > >> Best regards, > >> Alain > >> > >> > >> > > >> > > >> > I propose a change to sip_inv.c, in inv_send_ack(). See below: > >> > > >> > > >> > > >> > /* Send ACK */ > >> > > >> > status = pjsip_dlg_send_request(inv->dlg, inv->last_ack, -1, > >> > NULL); > >> > > >> > if (status != PJ_SUCCESS) { > >> > > >> > /* Better luck next time */ > >> > > >> > pj_assert(!"Unable to send ACK!"); > >> > > >> > return status; > >> > > >> > } > >> > > >> > > >> > > >> > > >> > > >> > /* Set state to CONFIRMED (if we're not in CONFIRMED yet). > >> > > >> > * But don't set it to CONFIRMED if we're already DISCONNECTED > >> > > >> > * (this may have been a late 200/OK response. > >> > > >> > */ > >> > > >> > if (inv->state < PJSIP_INV_STATE_CONFIRMED) { > >> > > >> > > >> > > >> > /* Bug: PJSIP does not handle a glare of rx final INVITE > >> > > >> > * response and tx CANCEL (when in early state) > >> > > >> > * > >> > > >> > * The ACK may be set in response to final INVITE > >> > > >> > * response, but CANCEL may have been sent prior. > >> > > >> > * We check here for cancelling inv session, if set, > >> > > >> > * we end the session and suppress state notification > >> > > >> > * for confirmed state. > >> > > >> > */ > >> > > >> > if(inv->cancelling) { > >> > > >> > PJ_LOG(5,(inv->obj_name, "Suppressing %s notification, > >> > because cancellation in progress", > >> > > >> > inv_state_names[PJSIP_INV_STATE_CONFIRMED])); > >> > > >> > > >> > > >> > notify = inv->notify; > >> > > >> > inv->notify = PJ_FALSE; > >> > > >> > inv_set_state(inv, PJSIP_INV_STATE_CONFIRMED, e); > >> > > >> > inv->notify = notify; > >> > > >> > > >> > > >> > status = pjsip_inv_end_session(inv, PJSIP_SC_GONE, NULL, > >> > &tdata); > >> > > >> > if( status == PJ_SUCCESS) { > >> > > >> > status = pjsip_dlg_send_request(inv->dlg, tdata, -1, > >> > NULL); > >> > > >> > if (status != PJ_SUCCESS) { > >> > > >> > /* Better luck next time */ > >> > > >> > pj_assert(!"Unable to send BYE!"); > >> > > >> > return status; > >> > > >> > } > >> > > >> > } > >> > > >> > } > >> > > >> > else { > >> > > >> > inv_set_state(inv, PJSIP_INV_STATE_CONFIRMED, e); > >> > > >> > } > >> > > >> > } > >> > > >> > > >> > > >> > return PJ_SUCCESS; > >> > > >> > > >> > > >> > Is this a bad idea? What are your thoughts? > >> > > >> > > >> > > >> > Steve > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Visit our blog: http://blog.pjsip.org > >> > > >> > pjsip mailing list > >> > pjsip at lists.pjsip.org > >> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >> > >> -- > >> "" > >> (o)(o) > >> _____o00o__(__)__o00o_____ > >> 3072D/146D10DE 2011-09-29 Alain Totouom <totouom at gmx.de> > >> PGP Fingerprint 39A4F092 FFA7C746 CC305CB0 69091911 146D10DE > >> > >> _______________________________________________ > >> Visit our blog: http://blog.pjsip.org > >> > >> pjsip mailing list > >> pjsip at lists.pjsip.org > >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > _______________________________________________ > > Visit our blog: http://blog.pjsip.org > > > > pjsip mailing list > > pjsip at lists.pjsip.org > > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120227/e00ce122/attachment-0001.html>
