Subject: [Sip] Open Issue #122: CANCEL on 200/600 strength

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Sep 2001 03:39:05 -0400

Rohan wrote:
> #122  "cancel on 200/600 strength"
>  >When a forking proxy gets a 2xx/6xx on a branch, is CANCEL 
> of other branches
>  >a: 1) MAY, 2) MUST, or 3) SHOULD
>  >Bis-03 and previous were MAY, -04 is SHOULD
>  >Why?  Without cancellation, burden moves to UA; UA doesn't 
> know if proxy
>  >forked!  Would always need to send CANCEL after 2xx
>  >Why not?  Useful apps for not cancelling
>  >Proposal:  change to MUST, MAY use caller-prefs to turn off
> 

Let me elaborate some more.

Here's the problem. Currently, bis-04 says that when a proxy forks, it
SHOULD generate a CANCEL to uncompleted branches when it receives a 2xx.
Because its a SHOULD, its possible that a proxy doesn't do it. So, consider
a UAC that sends an INVITE. It doesn't know whether the INVITE forked
downstream. So, when the UAC gets a 2xx, it has no way to know whether or
not to expect further 2xx anytime soon. Thats because it doesn't know
whether the potentially forking proxy downstream actually cancelled. So, the
UAC will need to generate a CANCEL on receipt of a 2xx. This would need to
happen for every INVITE. Bad, IMHO. THis is why I proposed making it a MUST.
That is, a forking proxy MUST send a cancel on receipt of a 2xx/6xx. This
way, the UAC doesn't need to send a CANCEL. After the first 2xx, it will
receive subsequent 2xx almost immediately (within the bounds of
retransmissions for packet loss recovery), or never.

If a proxy forks, it has to take responsibility for cleaning that up. I
believe Bob Penfield had objected to this, since he had a particular app
that took advantage of downstream proxies NOT cancelling. My argument was
that he couldn't count on the proxies not cancelling, so he'd have to use
caller preferences at the application server to request that the downstream
proxies not cancel. 

So, the concrete proposal is that normal behavior is that a proxy MUST
cancel any outstanding branches on 2xx/6xx, but caller prefs can modify
that. This way, the UAC would have to send cancel only if it asked the
downstream proxies not to do it.

Unless I hear otherwise in TWO WEEKS, this will be the final decision.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 19 Sep 2001 10:16:55 -0400

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 19, 2001 3:39 AM
Subject: [Sip] Open Issue #122: CANCEL on 200/600 strength

> Unless I hear otherwise in TWO WEEKS, this will be the final decision.

I'm OK with this as long as the text says that it can be overridden by an
extension that the UAC and the proxy both understand (e.g. caller prefs).

(-:bob

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 20 Sep 2001 17:35:11 +0100

> downstream proxies not to do it.

I don't like this, but it's purely for the reason that
it grates with me slightly that one day we're going to
end up with a spec that mandates X, but this mandate
is overridden by another spec (which is not obsoleting).

I'm relatively clueless in these matters, however, so
maybe this is deemed as perfectly acceptable IETF-wise....

 - Jo.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 22 Sep 2001 04:18:43 +0300

Hello,

Let's make it a {\MUST}.

Implementing a service that takes for granted that proxies will not
CANCEL the remaining branches will only work if all the proxies
understand caller preferences, regardless of whether we write SHOULD or
MUST in the spec. As soona s there is one proxy in the chain that does
not understand caller preferences the service will fail.

So, since the service implementor is sure that all his proxies
understand caller preferences, this MUST in the spec for "standard"
proxies is not confusing.

The only thing is that the caller preferences spec will have to say
that, when proxies doe not CANCEL branches, the UAC should not should
not consider the INVITE transaction terminated after 16 seconds after
the first 2xx.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Neil Deason" <[email-masked]>
Date: Mon, 24 Sep 2001 11:10:05 +0100

I would leave it as a SHOULD. While building services
on the strength of any feature not being a MUST is
no good, there is more to it than that.

Making it a MUST does not remove the need for a UA to
be able to deal with multiple 200s to an INVITE. A CANCEL
and 200 could still cross on the wire. I also don't think
that being able to do that is an unfair burden on an intelligent
end-point in a peer to peer protocol. Finally saying that caller
prefs can be a valid reason in particular circumstances to
ignore canceling any outstanding branches on 2xx/6xx makes
it a SHOULD according to RFC 2119 for me. But I would trade for
a finished spec ;)

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Gonzalo
> Camarillo
> Sent: 22 September 2001 02:19
> To: Jo Hornsby
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip] Open Issue #122: CANCEL on 200/600 strength
>
>
> Hello,
>
> Let's make it a {\MUST}.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Sep 2001 17:14:39 +0300

Hello,

Neil Deason wrote:
> no good,

That's my view as well.

> there is more to it than that.
> 
> be able to deal with multiple 200s to an INVITE. 

No, but it removes the need for the UA to handle multiple non-2xx final
responses.

Regards,

Gonzalo

A CANCEL

---

From: "Neil Deason" <[email-masked]>
Date: Mon, 24 Sep 2001 15:30:47 +0100

> No, but it removes the need for the UA to handle multiple

A working forking proxy will not send back >1 non-2xx for
an INVITE. Only the lowest number response code gets sent back
(anything lower, other than a 2xx, coming in late would be
dropped). 2xxs for INVITES being a special case that must be
sent back due to the INV/2xx/ACK reliability mech'n.

Cheers,
Neil.

> > > > > happen for every INVITE. Bad, IMHO. THis is why I
> proposed making
> > > > > it a MUST.
> > > > > caller preferences at the application server to
> request that the
> > > > > downstream
> > > > > proxies not cancel.
> > > > >

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Sep 2001 18:14:05 +0300

Hello,

> sent back due to the INV/2xx/ACK reliability mech'n.

Sorry, I thought I was answering another thread... what I wanted to say
is that having proxies cancel branches after the first 2xx let the UA
know when to terminate the INVITE trasaction. That is, the UA receives
the first 2xx and 16 secs later it can safely remove state for that
trasaction. If proxies do not CANCEL branches, a second 2xx might arrive
3 minutes later to the UA... this would imply that the UA would have to
store trasaction state "for ever", just in case another 2xx arrives.

Regards,

Gonzalo