Subject: Re: [SIP] Solving the REFER retransmit issue

From: "James Undery" <[email-masked]>
Date: Fri, 15 Dec 2000 01:14:43 -0000

>From: William Marshall <[email-masked]>

>I think there is a definite simplification possible here,
>if the three-phase-procedure can be dissaciated with INVITE.
>That is, to allow the three-phase-procedure for all methods.
>
>SIP defined two mechanisms for retransmission/reliability.  One
>(currently used for INVITE) involves a three-way handshake
>(INVITE, 200-OK, ACK); and the other (currently used for all
>other methods) is a two-way handshake (INVITE, 200-OK).
>The major difference, in my opinion, is that the three-way
>handshake allows a provisional response, which is not allowed
>for such methods as BYE, INFO, SUBSCRIBE, REGISTER, etc (even
>though it might be useful).

You can and should send provisional responces to all requests that you can't 
process in a specific time (200ms IIRC).

>I think the changes are relatively simple.  All are currently
>implemented in the handling of INVITE, and just need to be
>made non-INVITE-specific.
>
>UAC/UAS behavior changes:
>
>(1) A UAC that receives a 1xx response to any method, MUST send
>an ACK when it receives a final response.
>
>(2) A UAS MUST send a response within some short time limit of
>receiving a request, either a final response or a provisional
>response.
>
>(3) If a UAS sends a provisional response, it MUST re-transmit any
>final response until receiving an ACK.
>
>Proxy behavior changes:
>
>(1) A Proxy MUST forward an ACK to the UAS, regardless of original
>request.
>
>(2) Proxy MUST forward a 100 provisional responses back to the UAC,
>except when the proxy generated its own 100 response for the same
>request.
>
>REFER, of course, is the first example of a method that could use
>the three-way-handshake other than INVITE.  The only reason the
>situation didn't arise before (with the Also/Replaces version of
>call control) because they were headers added to an INVITE method.
>
>The main issue is whether this is toooo incompatible with RFC2543.
>Proxy point (2) is the only point that is not backwards compatible
>with existing devices that conform to RFC2543 and that handle only
>existing methods.
>
>Would this involve significant implementation changes in UAs?
>Regardless, I think the contortions needed for REFER are more complex.
>

All this is very well for UAs, however, as a proxy implementor I and not 
going to be to happy about retaining state indefinitely and cancel your 
requests to prevent DOS attacks.

James Undery [email-masked]

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip