Subject: RE: [SIP] CANCEL related questions

From: "Donovan, Steven R." <[email-masked]>
Date: Tue, 25 Apr 2000 21:11:22 +0000

Jonathan Rosenberg wrote:
> 
> Igor Slepchin wrote:
> > 
> > Shail Bhatnagar wrote:
> > >
> > > Can someone please clarify the behavior in the following 
> scenarios :
> > >
> > > 1) Stateful proxy server returns a final response upstream.
> > > Now it receives a CANCEL request. Should it return a 481 
> response ??
> > 
> > It may return a 481. However, it should still try to proxy 
> the CANCEL
> > upstream, I believe.
> 
> Actually, I think the proxy will generate a 200 OK to to the CANCEL.
> There was no error; the CANCEL was received for a valid transaction. 
> 

It depends on whether the proxy still has state for the transaction.  
If the proxy has "forgotten" about the transaction, then a 481 is
the appropriate response.  

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Apr 2000 17:26:28 -0400

> the appropriate response.

I don't think thats the right behavior. In this case, I think the proxy
should actually proxy the CANCEL, as any other request. Consider this
scenario. A UAC sends an INVITE, goes through a proxy, goes to UAS, 100
comes back. The UAC lets the phone ring for a long time. At some point,
the proxy gives up and destroys transaction state (note that it may have
been stateless to begin with). Now, the UAC finally decides to CANCEL.
So, it sends a CANCEL, and this arrives to the proxy. There is
definitely a value in proxying this CANCEL so that it can cause the
request to be cancelled at the UAS. 

Since the correct behavior of a stateless proxy is to forward all
CANCELs, it makes sense that the default behavior of a stateful proxy
which forgot its state should be the same - proxy the CANCEL.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Igor Slepchin <[email-masked]>
Date: Tue, 25 Apr 2000 17:18:36 -0400

> the appropriate response.

Actually, I still think that it might be appropriate for the proxy to
return a 4xx response when it receives a CANCEL for the transaction in a
state where it shouldn't receive any save for a race condition. Not that
this makes any difference...

Also note that if the proxy has forgotten about the transaction, it
needs to forward the CANCEL after returning the 481 (and yes, I was
wrong on this in my first reply).

---
Igor Slepchin

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 26 Apr 2000 14:06:36 +0100

Bleh,

Apologies for any confusion of message attribution, or whatever, I
seem to be missing half of this thread...

> request to be cancelled at the UAS. 

So, should a stateful proxy always return 200 for a CANCEL?  I'm
struggling to envisage a case where it would not.  It seems to me
that returning 481 implies confusing semantics, since the ultimate
UAS could "successfully" CANCEL the offending transaction.

> which forgot its state should be the same - proxy the CANCEL.

Is this stated explicitly anywhere, or is it implied by section
12.3.4 in rfc2543bis?  Therefore, should a stateless proxy initially
return a 100 for a CANCEL, as specified by section 12.4?  (Seems
pointless if we're always going to return 200...but obviously I
may be way off with the 200.)  Actually, thinking about it, isn't
the opening text of Section 12.4 --
    "The server MUST respond to the request immediately with a
     100 (Trying) response."
-- (potentially also) wrong when considering ACKs?  (Section 10.6)

To finish, can the Ten Commandments of a Stateful Proxy Behaviour,
when dealing with Requests, be summed up as:
 0) Thou shalt always attempt[0] to proxy any Request, unless it
    is a REGISTER for the local domain (or similar);
 1) Thou shalt return 100 (Trying) whilst thou proxies, unless
    the Request is an ACK;  
 2) Thou shalt obey the mighty C code in Section 12.4 of RFC 2543
    when proxying INVITEs, OPTIONSs, BYEs;
 3) Thou shalt return 200 (OK) uponst(?) seeing a CANCEL;
 4) Thou shalt not generate any Responses to ACKs;
 5) See 0;
 6) See 1;
 7) See 2;
 8) See 3;
 9) See 4.

Of course, I made it Ten just to look clever.

Am I being too simplistic?

 - Jo.

[0] Admittedly, I'm blatantly ignoring the case of an INVITE or
    REGISTER that requires authorisaction; or any semantics implied
    by, for example, a Request with a Max-Forwards value of 0.
-- 
  Jo Hornsby; IT Professional         --       mailto:[email-masked]
 Ubiquity Software Corporation        --         http://www.ubiquity.net/

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 26 Apr 2000 14:06:07 -0400

> UAS could "successfully" CANCEL the offending transaction.

It should return 481 if it doesn't know what transaction that CANCEL is
for (i.e., it has already forgotten about that transaction or received a
stray CANCEL). I thought it might also return a 481 if it received a
CANCEL for a transaction in the state where CANCEL doesn't make sense
but the spec is quite specific on this (4.2.5 in 2543bis):

A redirect or user agent server (a proxy server as well, I guess)
receiving a CANCEL request responds with a status code 200 (OK) if the
transaction exists and a status 481 (Transaction Does Not Exist) if not.

Note that the class of CANCEL response has no impact on protocol
operation.
 
> 12.3.4 in rfc2543bis?  

No special case is made for CANCEL and all other requests are to be
proxied, hence CANCEL is to be proxied as well. I don't think this
specific situation is described anywhere in the spec.

> Therefore, should a stateless proxy initially
> return a 100 for a CANCEL, as specified by section 12.4?  

No. From section 7.1 in 2543bis: "A server SHOULD send a 1xx response if
it expects to take more than 200 ms to obtain a final response." A
response to CANCEL is sent immediately, so there is no point in sending
a 1xx.

>     is a REGISTER for the local domain (or similar);

"Any" is probably too generic. You might want to send final responses
sometime as well:)

>  1) Thou shalt return 100 (Trying) whilst thou proxies, unless
See 7.1

>  3) Thou shalt return 200 (OK) uponst(?) seeing a CANCEL;
See above

>  4) Thou shalt not generate any Responses to ACKs;
Universally true.

---
Igor Slepchin

---

From: Neil Deason <[email-masked]>
Date: Wed, 26 Apr 2000 20:00:39 +0100

At the risk of adding more confusion ...

> transaction exists and a status 481 (Transaction Does Not Exist) if not.

Just to be clear are you saying that you should send back 481 and proxy
the CANCEL? I thought that a stateful proxy should always forward on
the CANCEL as while it may have lost state a UAS may not have and
find the CANCEL useful.  (See Jonathon's posting earlier on this thread).

> response to CANCEL is sent immediately, so there is no point in sending

I agree that sending a 100 is not very sensible for CANCELS.
However 12.4 states a forking proxy MUST send back 100 immediately.
This contradicts what we think is the right thing to do here and the
case with ACKs where the draft also says you shouldn't generate any
responses. If we are right maybe the bis draft needs clarifying here.

Cheers,
Neil
--
Ubiquity Software Corporation           http://www.ubiquity.net

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 26 Apr 2000 15:19:26 -0400

Neil Deason wrote:
> the CANCEL? 

Yes. BTW, 481 means a 481 response to CANCEL, _not_ a 481 to the
original request.

> I thought that a stateful proxy should always forward on

I don't really see a contradiction here. How sending a 481 is different
from sending a 200?
 
> responses. If we are right maybe the bis draft needs clarifying here.
 
I agree that this needs some clarification. Probably the 200 ms rule
from 7.1 should be repeated in 12.4 as well.

Regards,
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Apr 2000 01:40:47 -0400

> I don't really see a contradiction here. How sending a 481 is different

There are three possibilities about what a proxy might do (as far as
responses to the CANCEL) when it receives one for which no transaction
exists:

1. not respond at all, but rather forward the response from the next hop
upstream (this is what a stateless proxy will do)
2. respond with 200 OK immediately
3. respond with 481 immediately

All three will work just fine. Igor has pointed out correctly that the
client behavior remains unchanged if it gets a 200 as opposed to 481. I
can think of unsubstantial reasons for one over the other. Note that the
spec does not say that a PROXY should return 481 if the call leg is
unknown, only UA and redirects:

> A redirect or user agent server receiving a CANCEL request responds
>    with a status of 200 (OK) if the transaction exists and a status of
>    481 (Transaction Does Not Exist) if not, but takes no further action.
>    In particular, any existing call is unaffected.

I could not find anything in the spec which recommends 481 or 200 for
proxies in this case. 

> from 7.1 should be repeated in 12.4 as well.

100 is definitely useless for CANCEL. We'll clarify that.

-Jonathan R.