Hi Peili, > There may have different APIs to provide different level of shiled. > The stack may expose the un-compilant 1xx through lower-layer API on which > upper layer API may shield it and do more function like sending BYE. > Also, to fulfill this fuction, the application layer should be able to > indicate the stack how to process in different situations.
Thank you again for the response. Do you know of any particular APIs that you believe provide a nice shielded versus an unshielded view of the underlying protocol? - Rhys __________________________________ Rhys Ulerich IMS & SIP SOA Software Development Email: [EMAIL PROTECTED] Office: 512-838-1428 IBM Software Group - Austin, TX Peili Xu <[EMAIL PROTECTED]> wrote on 10/26/2005 09:20:26 PM: > Hi Rhys, > > Please see Inline. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rhys D > Ulerich > Sent: Thursday, October 27, 2005 12:54 AM > To: Peili Xu > Cc: [email protected] > Subject: Re: [Sip-implementors] PRACK: How to handle UAS that fails to > respondwith 420 > > > Hi Peili, > > I appreciate the response. I guess I'm getting at a different angle of > the issue... > > > Firstly, Although it is OK to send INVITE with Require:100rel, it > > may not be necessary, > > because it is the UAS`s responsibility and capability to decide if > > the 1xx should be reliable or not. > > ... > > I personally perfer to expose the reception of non-compilant 1xx and > > let the upperlayer to decide. > > On a strict reading of the specifications, the UAS can only decide to > provide/not provide PRACK support if the UAC had indicated that it > Supported the 100rel extension. The UAC Require-ing the 100rel extension > indicates that it needs PRACK-support for meaningful flow completion. I > feel that the UAC has already performed the upper level decision you > described by choosing the Require header. > > It is the UAS' responsibility to reject the request with a 420 Bad > Extension if it is not willing or not able to send reliable responses. RFC > 3261 Section 8.2.2.3 describes this as MUST behavior. So the UAS has made > a protocol-level error if it send a non-reliable response to an INVITE > that Require-s the 100rel extension. > > If an implementation wanted to shield an application-level UAC from this > SIP protocol-level error, are there approaches other than the > implementation autogenerating the BYE/CANCEL? Has anyone attempted to do > this, and if so did any best practices come from the effort? Are their > any tradeoffs that aren't obvious? > > <xpl> > Yes, the indication to require 100rel is an application layer decision by > UAC, > and the un-reliable 1xx is a protocol level error caused by UAS. > > The more function to be put into the stack, the more complicate the stack > will be and the less flexibility the upper layer will have. > > There may have different APIs to provide different level of shiled. > The stack may expose the un-compilant 1xx through lower-layer API on which > upper layer API may shield it and do more function like sending BYE. > Also, to fulfill this fuction, the application layer should be able to > indicate the stack how to process in different situations. > </xpl> > > - Rhys > __________________________________ > Rhys Ulerich > IMS & SIP SOA Software Development > Email: [EMAIL PROTECTED] Office: 512-838-1428 > IBM Software Group - Austin, TX > > > Peili Xu <[EMAIL PROTECTED]> wrote on 10/26/2005 11:12:19 AM: > > > Hi Rhys, > > > > Firstly, Although it is OK to send INVITE with Require:100rel, it > > may not be necessary, > > because it is the UAS`s responsibility and capability to decide if > > the 1xx should be reliable or not. > > > > Secondly, If the UAC receive an unreliable 1xx in this situation, > > and consider it a hindrance to > > further process the flow, it may send CANCEL or BYE(if early dialog > > is established) to end the request. > > Whether to convert non-compilant 1xx to 420 and automatically send > > BYE in the stack layer is an implementation choice. > > It depends on the design of the functional seperation between stack > > and upper layer and the capability of the API. > > > > I personally perfer to expose the reception of non-compilant 1xx and > > let the upperlayer to decide. > > > > regards > > Peili > > > > > > ----- Original Message ----- > > From: "Rhys D Ulerich" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Wednesday, October 26, 2005 11:09 PM > > Subject: [Sip-implementors] PRACK: How to handle UAS that fails to > > respond with 420 > > > > > > > Hi all, > > > > > > I've got a question about defensive programming with the PRACK > > > extension... > > > > > > Say my UAC supports PRACK, and generates an INVITE with a Require: > 100rel > > > header. Say I send it to a UAS that doesn't support PRACK, and that > is > > > poorly written when it comes to handling Require headers. Instead > > > of > > > rejecting the INVITE with a 420 Bad Extension like RFC 3261 mandates, > the > > > UAS goes ahead a sends a provisional response back to my UAC. How > should > > > my stack and UAC handle the situation? > > > > > > So the scenario looks like-- > > > > > > UAC UAS > > > ---INVITE---> Contains Requre: 100rel > > > <--180-------- Lacks RSeq, the client obviously should have > responded > > > with a 420. > > > (now what?) > > > > > > The PRACK-savvy stack could "fake" sending a 420 request back to the > UAC. > > > That leaves the UAS with a stale INVITE transaction that the stack > could > > > cleanup by sending a BYE. Having a stack implemented this way is > > > very > > > > heavyweight, but it prevents the application-level UAC code from > > > ever > > > having to deal with a non-compliant UAS. > > > > > > This may look like > > > > > > UAC stack UAS > > > ----INVITE--> Contains Require: 100rel > > > ---INVITE--> Contains Require: 100rel > > > <--180------ Lacks RSeq, and the client > > > obviously should have responded with a 420 > > > <--420------- Protect the UAC from the > > > noncompliant UAS > > > ---BYE-----> Terminate the UAS' early dialog > per > > > RFC 3261 Section 15 > > > <--200/481- This response is a don't care, > and > > > the stack can discard it > > > ----ACK-----> which the stack can deliver if > > > ----ACK-----> it > > > > likes.... I guess... Not sure here... > > > > > > Any other ideas/options/recommendations? > > > > > > - Rhys > > > __________________________________ > > > Rhys Ulerich > > > IMS & SIP SOA Software Development > > > Email: [EMAIL PROTECTED] Office: 512-838-1428 > > > IBM Software Group - Austin, TX > > > _______________________________________________ > > > Sip-implementors mailing list [email protected] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
