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.
> Also a transaction is defined as the messages between the initial
> request to the final response,
Right; but a transaction is also identified by the CSeq number. The
CANCEL that arrives to the Registrar above will have the same CSeq number
as the request it is canceling (the REGISTER).
> since the transaction of the Invite request is terminated by replying with
> a 200 ok, the transaction does not exsist, so the response to the Cancel
> request should be a 481 response."transaction does not exsist".
As I pointed out above, while the INVITE transaction may have been term-
inated by a final response, the Registrar may cache the final response for
some time. If the CANCEL comes in after the cache has been dropped, then
a 481 makes sense. If the CANCEL comes in before the cache has been
dropped and the Registrar could match the CANCEL to a valid transaction,
a 200 makes sense (change the reason phrase if you want).
BTW, ACK and CANCEL are 2 methods in SIP that do not exist in isolation.
Both of them depend on a previous method; that is why they use the same
CSeq numbers. On arrival at a server, they have to be matched to an
existing transaction.
Regards,
- vijay
--
Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
