> -----Original Message-----
> From: Vijay Gurbani [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 12, 2001 10:41 AM
> To: Hrishikesh Saria
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] CANCEL the REGISTER
>
>
> Hrishikesh Saria wrote:
> >
> > I dont think that the response to the Cancel request if
> the registrar has
> > already replied to the register request should be 200 OK.
> 200 ok is used
> > to denote a success operation. In this case since the reply to the
> > registrar request has already been done before it got the
> cancel, the
> > registrar server should reply with a 4XX response to the
> cancel in this
> > case.
>
> I think you may be getting bogged down by semantics. Let's
> recap the scenario
> first:
>
> UAC REGISTRAR
> REGISTER------>
> 200 OK <--------
> CANCEL-------->
> 200 OK <--------
>
> The issue you appear to be raising is why does the REGISTRAR
> send a 200 OK
> to the CANCEL, it should send a 4xx message. There are 3
> cases to consider:
>
> Case 1: Unreliable transport was used for REGISTER/200 OK
> transaction.
> In this case, as per the RFC (and bis), the
> Registrar should
> cache the final response for at least 10*T2
> seconds (if T2 = 4
> (the default value), then the cache time is 40
> seconds). Now,
> within 40 seconds the Registrar gets a CANCEL, AND
> it matches
> the CANCEL to the request being canceled (which is
> REGISTER).
> The fact that the CANCEL matched a request to be canceled
> implies that the CANCEL transaction itself is not in error,
> thus a 4xx cannot be send. The CANCEL request
> itself succeeded,
> but the Registrar has already send a final response and it
> cannot rescind it. Hence the 200 OK (CANCEL). If
> you dislike
> the reason phrase "OK", you can always change it
> to something
> like "200 Registration NOT canceled" to
> distinguish it from the
> case where "200 OK" means that a registration was canceled.
> Case 2: Unreliable transport was used for REGISTER/200 OK
> transaction,
> AND the CANCEL arrived after 40 seconds. This is
> easy -- send
> a "481 Transaction/Call Leg does not exist" since after 40
> seconds, the Registrar may drop the final response from its
> cache.
> Case 3: Reliable transport was used for REGISTER/200 OK.
> Processing
> is same as Case 2 -- send a 481.
To add some clarity here, Vijay is correct that the response to the CANCEL
will be 200 OK if the transaction is still in existence, and any final
response was sent to that transaction. The semantics for CANCEL are really
"please speed up the transmission of a final response to this request by
sending a 487 if you haven't done responded already". Based on that, a 200
OK to CANCEL is appropriate.
In any case, the whole issue is academic since the CANCEL is hop by hop. If
a UAC sends a CANCEL, the first hop proxy sends the final response to the
CANCEL. SO, even if some downstream UAS responds to the CANCEL with 4xx,
this would not be propagated to the UAC.
-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
