hi, any planning for RFC 5407? regards, Gang On Fri, Feb 24, 2012 at 3:01 PM, Benny Prijono <bennylp at teluu.com> wrote: > 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 > > > > _______________________________________________ > 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 >
