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
