Hi all, >From the SIP spec, I think the standard behavior is quite clear, i.e. UAC MUST treat the call as established. I forgot which particular section of the spec that says this, but this is the well known behavior. PJSIP complies with this, and one of the reason for doing so is to provide consistent report to the application, i.e. if the call has been established then we want to convey this state to application. This is particularly important say when the ITSP provider charges for connected call. Had we not reported the confirmed state, end users may complained why they get charged for a call that was not connected. But I do get your point, Steve, and that's why we have https://trac.pjsip.org/repos/ticket/1049. We will implement that at some point, but for now apps need to handle this themselves. -Benny On Fri, Feb 24, 2012 at 8:50 AM, Alain Totouom <alain.totouom at gmx.de> wrote: > Hi Steve > > On 02/23/2012 11:28 PM, Steve King 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. > > > > I fully agree with you on #3261 ? 9.1 is not clear on how to resolve > that race condition (BTW a CANCEL request is at worst a no-op). > In your current scenario a dialog IS established and it's the > responsibility of the UA to tear it down... > > > 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. > > > > If you say/suggest, upon detection of this scenario, PJSUA should > handle this and issue a BYE request, then I'm with you. > BTW PJSUA is a UA, thus application level ;o) > > > Best Regards, > Alain > > > > 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 > > > > -- > "" > (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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120224/7510c050/attachment-0001.html>
