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

Reply via email to