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? - 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 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
