in line. On Tue, Feb 28, 2012 at 11:46 AM, Steve King <sking at zetron.com> wrote: > Hi Gang, > > Inline below. > > Steve > >> -----Original Message----- >> From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip- >> bounces at lists.pjsip.org] On Behalf Of Gang Liu >> Sent: Tuesday, 28 February 2012 12:32 PM >> To: pjsip list >> Subject: Re: CANCEL and final INVITE response glare ("crosses >> thewire") >> >> in line. >> >> On Mon, Feb 27, 2012 at 7:30 PM, Benny Prijono <bennylp at teluu.com> >> wrote: >> > 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. >> > >> according to RFC 3261, an INVITE server transaction is supposed to be >> terminated by a 200 response. I think the UAS MAY send a 481 response >> to >> the CANCEL since there is no transaction that the CANCEL request >> matches. >> This 481 simply means that there is no matching INVITE server >> transaction >> and CANCEL is not sent to the next hop. Or I am missing something? >> > [SK] In the case I mentioned, the transaction does exist and is connected (CANCEL received after INVITE final response is sent). A CANCEL received by a UAS in the connected state should always be responded with 200 OK, but has no effect on the transaction state. > This behavior is defined in RFC3261 9.2: > > ? Regardless of the method of the original request, as long as the > ? CANCEL matched an existing transaction, the UAS answers the CANCEL > ? request itself with a 200 (OK) response. > [Gang] I guess you said is "dialog does exist and is connected". According to RFC 3261, The server transaction MUST then transition to the "Terminated" state. So CANCEL may not matched to INVITE transaction. It depends on UAS implementation. >> >> >> >> ? 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. >> > >> Yes, pjsip_inv APIs already do very well. I only add more timer to >> call pjsip_inv_terminate >> when necessary. >> >> > 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 >> > >> > >> > >> > _______________________________________________ >> > 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
