Subject: [SIP] CANCEL related questions

From: Shail Bhatnagar <[email-masked]>
Date: Mon, 24 Apr 2000 20:22:11 -0400 (EDT)

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 ??

2) Stateful forking proxy server returns a 200 response to INVITE upstream
and receives another 200 OK from downstream. Should it return this second
200 OK upstream or it is a configuration issue ??

3) Stateful forking proxy server is waiting for a final response on forked
"branches" and meanwhile receives a CANCEL. It returns a 200 OK upstream
and generates locally generated CANCEL requests for pending branches. Now it
receives a 200 response to original request. Should it just drop this
response ??        

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

---

From: Igor Slepchin <[email-masked]>
Date: Mon, 24 Apr 2000 20:46:28 -0400

> 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.
 
> 200 OK upstream or it is a configuration issue ??

It should proxy the second 200 OK upstream.
 
> receives a 200 response to original request. Should it just drop this

No way. It should proxy the 200 OK upstream (see sec 4.2.5 of
RFC2543bis).

Thank you,
Igor Slepchin

---

From: Igor Slepchin <[email-masked]>
Date: Mon, 24 Apr 2000 20:53:34 -0400

> It may return a 481. However, it should still try to proxy the CANCEL

Oops, I meant downstream...

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Apr 2000 01:31:27 -0400

> It may return a 481. However, it should still try to proxy the CANCEL

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. 

As for proxying it upstream, if the proxy returned a final response
already, there should either be no pending branches, or a CANCEL was
already sent to cancel pending branches. In that case, there is no need
to proxy the CANCEL.

> It should proxy the second 200 OK upstream.

Yes. In general, a proxy should never absorb 200 OK.

> No way. It should proxy the 200 OK upstream (see sec 4.2.5 of

Igor is correct. Remember, CANCEL is meant to "speed up" completion of
the original request. So, after sending a CANCEL, you should still be
prepared for any set of responses you might get, just as if you had
never sent the CANCEL in the first place.

-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: Shail Bhatnagar <[email-masked]>
Date: Tue, 25 Apr 2000 17:27:00 -0400

Thanks for responses. One more related question. Let us consider the following
scenario :

1) INVITE from UA to proxy 
2) 100 from proxy to UA and INVITE from proxy to next hop server
3) CANCEL from UA to proxy and CANCEL from proxy to next hop server
4) Proxy gets a duplicate copy of INVITE and returns 487 response
5) Proxy gets a 200 response to INVITE and forwards it upstream. This
creates a messy state at the UA. Is this acceptable ??

Thanks,
Shail

---

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

> 4) Proxy gets a duplicate copy of INVITE and returns 487 response

Why would it do this? The proxy should not generate the response to the
INVITE, it should wait for a response. Remember - the point of the
CANCEL is to speed up the return of a response from the UAS. The reason
you really don't want to generate one yourself like this is exactly the
case in step 5 below.

> creates a messy state at the UA. Is this acceptable ??

No.

-Jonathan R.

---

From: Shail Bhatnagar <[email-masked]>
Date: Tue, 25 Apr 2000 17:40:11 -0400

> you really don't want to generate one yourself like this is exactly the

Okay, so what should the proxy do with this duplicate INVITE - simply drop it
(since transaction is cancelled) or return 100 trying ??

Thanks,
Shail

---

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

> (since transaction is cancelled) or return 100 trying ??

Do the same thing you would do if a CANCEL was never received.
Retransmit the last provisional response sent for a stateful proxy, and
proxy the INVITE for a stateless proxy.

Remember - CANCELs only act to speed up a response to the transaction.
The original transaction itself, its state is not directly affected by
CANCEL in a proxy.

-Jonathan R.

---

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

> > creates a messy state at the UA. Is this acceptable ??

I guess this "No" is only valid in the context of item 4 above - the
proxy erred when sending the 487 instead of waiting for one from the UAS
and created this mess. Nevertheless, the protocol still requires UAC be
prepared to receive that 200 OK.

---
Igor Slepchin

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 26 Apr 2000 20:41:11 +0100

> already sent to cancel pending branches. In that case, there is no need

Actually, just for the record, I believe CANCEL'ing outstanding branches
upon receiving a 2xx is optional for a proxy (12.4 in 2543bis), so in
this case proxying CANCEL would be appropriate.

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK