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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Sep 2001 01:34:31 -0400

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 11:14 AM
> To: Neil Deason
> Cc: Jo Hornsby; Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip] Open Issue #122: CANCEL on 200/600 strength
> 
> 
> Hello,
> 
> > > No, but it removes the need for the UA to handle multiple
> > > non-2xx final
> > > responses.
> > 
> > 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.
> 
> 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.

I agree with Gonzalo. He's exactly right. If its a SHOULD, then the UA will
have to CANCEL everything or else keep the transactions around forever. If
its a MUST, its just 16s.

I am happy to make the text something like "...MUST cancel unless requested
not to by the client through some extension" so that we leave room for
caller prefs.

-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: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2001 14:39:53 +0300

Hi,

I also think it should be a MUST in the bis.

For example, the UAC may have reserved media resources for every 18x it
received, eg for early media. Then, when it receives 200 it knows that
the other branches have been terminated, so it can free those resources.
Of course it can do so even if the proxy didn't terminate the branch,
but then the servers sending early media won't start receiving ICMP for
an early session they still think is active...

I AM, however, looking forward for an SIP extension that allows one NOT
to assume that the other legs have been terminated :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 25 Sep 2001 09:27:01 -0400

> an early session they still think is active...

I'm fine with making it a MUST, but that does not absolve the UAC from
needing to be able to handle multiple 200s. If the proxy's CANCEL and the
second 200 cross on the wire, the proxy must still send the 200 upstream to
the UAC. The proxy is not allowed to BYE that call leg.

My apologies if this is too obvious.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2001 16:36:11 +0300

Hi,

>My apologies if this is too obvious.

I think it is a good point.

If the UAC receives a re-transmission of the ORIGINAL 200 OK, it will
resend the ACK. 

But, if it receives 200 OK for other legs I think they should be handled
like a 200 OK response to a non-existing transaction, and I guess it is
pretty much an implementation issue what to do. Some probably will
discard it, while others may ACK and BYE it.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 25 Sep 2001 08:53:34 -0500

[...]
> I agree with Gonzalo. He's exactly right. If its a SHOULD, then the UA 
> will have to CANCEL everything or else keep the transactions around 
> forever. If its a MUST, its just 16s.
> 
> I am happy to make the text something like "...MUST cancel unless 
> requested not to by the client through some extension" so that we leave 
> room for caller prefs.

Doesn't this have the unfortunate side effect that the next SIP RFC will 
be dependent on some extension?  In other words, someone implementing the
SIP RFC WILL have to also implement the said extension in order to be
compliant with the RFC.

I assumed that the whole idea was for the core RFC to stand alone; 
extensions of course can refer to it and depend on the behavior specified 
in it.

I would just as soon leave it as MUST cancel in the core RFC and let caller 
prefs document over-ride this behavior for proxies that support caller 
prefs.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 25 Sep 2001 09:52:44 -0400

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: "Bob Penfield" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "'Gonzalo Camarillo'"
<[email-masked]>; "Neil Deason" <[email-masked]>;
"Jo Hornsby" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 25, 2001 9:36 AM
Subject: Re: [Sip] Open Issue #122: CANCEL on 200/600 strength

> discard it, while others may ACK and BYE it.

Doesn't the UAC always have to ACK? If the UAC ignores it, the UAS will just
keep resending it. It seems to me that the right thing to do is ACK and then
BYE.

> > will
> > > > have to CANCEL everything or else keep the transactions around
forever.
> > If
> > requested

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 25 Sep 2001 17:50:34 +0300

Hello,

> discard it, while others may ACK and BYE it.

Well, this thread is being sidetracked...

Anyway, a second 2xx for an INVITE MUST NOT be considered "a
non-existing trasaction". It is part of the INVITE trasaction. About
discarding it, of course you MUST NOT discard it.

The UAC MUST store state for 16 seconds after the first 2xx arrives. If
during those 16 seconds another 2xx is received an ACK is sent. Then, if
the UAC wants to go on with the new call leg or if it wants to BYE it is
up to that particular UAC (and ultimately up to the user).

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: "Jo Hornsby" <[email-masked]>
Date: Tue, 25 Sep 2001 15:32:22 +0100

> requested not to by the client through some extension" so that we
> leave room for caller prefs.

Sits better with me.

[Perhaps, though, this exposes the need for an UNLESS. (:&]

 - Jo.

---

From: "James Undery" <[email-masked]>
Date: Tue, 25 Sep 2001 17:02:08 +0100

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jo
> Hornsby

I am not so happy with this, the MUST is required so the UA only need
store state for 15.5s and the unless seems to break the intent of RFC
2119

"1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
the
   definition is an absolute requirement of the specification."

I realise it's really too late for caller prefs to be changed having
gone to the IESG, however, in an ideal world it would have been to
remove the cancel-feature. (If it was really useful fake it with a
hack i.e. use a new INVITE using caller prefs to avoid the UA that
returned the 200).

That said I'd be glad to be told my interpretation of RFC2119 was
incorrect.

James Undery

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2001 22:41:15 +0300

Hi,

>during those 16 seconds another 2xx is received an ACK is sent.

I agree. However, it is important to see the difference between a
re-transmission of the first 200 OK, and possible 200 OK responses for
other legs that may come after, IF the UAC chooses to BYE the others.

>Then, if the UAC wants to go on with the new call leg or if it wants to BYE it is

This confuses me a little. Now it sounds to me like it really doesn't
matter if the proxy terminates the other legs or not, because if the UAC
receives multiple 200 OK it can choose to accept or reject them just
like it wishes... :) 

IF the bis will say that the proxy MUST NOT forward more than one 200
OK, should the UAC be allowed to accept those even if that happens? One
could argue that it doesn't matter because it is a UAC implementation
issue, and I can agree on that, but the fact is that a protocol error
has occured in the network.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 25 Sep 2001 23:03:07 +0300

Hello Christer,

> other legs that may come after, IF the UAC chooses to BYE the others.

That's why we have tags in the to field.

> receives multiple 200 OK it can choose to accept or reject them just

Christer, re-read this thread. We have been discussing exactly this
issue for a long time already. If proxies CANCEL pending branches, the
second 2xx will arrive at maximum 16 seconds after the first. If proxies
do not CANCEL branches, the second 2xx might arrive 3 hours later.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2001 22:55:49 +0300

Hi,

>That's why we have tags in the to field.

I KNOW that. I just said I though it was a good point to mention the
case :)

Regards,

Christer Holmberg
Ericsson Finland