Subject: [Sip] Open Issue #72: CANCEL for multicast

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

Rohan Mahy wrote:
> #72  "CANCEL for multicast"
>  >Spec says that servers send no response to a multicast CANCEL
>  >How does client know when to stop retransmitting?  No way!
>  >Proposals:
>  >1) Never send CANCEL over multicast
>  >2) Never send SIP over multicast
>  >3) Just continue retransmitting until timeout
>  >4) Send CANCEL responses over multicast (May need to limit scope)
> 
> rohan>  I propose the first option: (never cancel over 
> multicast), although 
> the second (deprecate SIP over Multicast) is also acceptable to me.

It is to me as well. I think sip multicast is really quite broken; this is
just one example of the problem. Another, for example, is this. A proxy
sends a multicast INVITE. It gets a single 5xx response. It has no way of
knowing whether any furhter responses (such as a 2xx) will arrive. If can't
send the 5xx, since a 2xx might show up, proxy rules prohibit a proxy from
sending a 2xx after a 5xx. THus, it can't send the 5xx upstream until the
transaction times out. THis means that all multicast transactions take the
full 16s (or whatever it is)to complete for non-2xx responses. Thats bad.

The main motivation we had for multicast sip was register, but I think the
dhcp draft is a far better way to bootstrap to your registrar. Plus, there
were issues (its actually another open issue) of transitioning from a
multicast registration to unicast once you've discovered your registrar.
That problem would go away too.

Another motivation was call center types of applications, where you reach
the first user at a given address. Realistically, you don't need (and don't
want in all likelihood) multicast for this. 

So, in the interests of greater simplicity, and following the philosophy
that the protocol is done NOT when you have no more to add, but no more to
take away, I'd like to remove multicast sip entirely.

Shout now if you have a problem with this. In 2 weeks, its a goner if no one
says anything.

-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: Gonzalo Camarillo <[email-masked]>
Date: Sat, 22 Sep 2001 04:03:52 +0300

Hi,

I support this. Let's get rid of SIP over multicast.

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: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 21 Sep 2001 21:06:04 -0400

> I support this. Let's get rid of SIP over multicast.

I'm opposed. REGISTER using multicast works nicely. Given the choices of
the DHCP working group, the DHCP option will be effectively unusable
with any existing DHCP server that is not specifically written to
support the option, so I wouldn't count on it any time soon.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

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

Hello,

Shall we disallow using multicast for requests different than REGISTER?
It seems that SIP over multicast is broken for INVITEs and CANCELs. As
you point out, sending REGISTERs to the well-known multicast address
seems useful.

Regards,

Gonzalo

---

From: Howard Hart <[email-masked]>
Date: Fri, 21 Sep 2001 18:25:21 -0700

Make that two opposed, though not vehemently in our case. Multicast
registration has worked fine for us for a while--I'd hate to lose it.
Anyone for deprecate Multicast with the exception of REGISTERs, or should I
say, is anyone using Multicast with any SIP method other than REGISTER?

Howard Hart
ipDialog, Inc.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 21 Sep 2001 21:41:36 -0400

> say, is anyone using Multicast with any SIP method other than REGISTER?

Plus, multicast is nice to have for updating several registrars at once,
scalably.

Another reason for keeping this is that multicast REGISTER can be
programmed to avoid the "reboot building" problem of 20,000 phones all
registering more or less at the same time when the power comes back on.
We haven't pursued this, but it would be easy (as an implementation
choice) to implement a form of RTCP reconsideration that causes phones
to back off when they see lots of other registrations, rather than
causing the poor registrar to drop almost all registrations. I wouldn't
be surprised if, just like RTCP, somebody eventually calls us on this
problem. (Not that other protocols, such as DHCP, don't have the same
problem...)

For non-REGISTER: I wonder if there is a need/use for 'non-confirmed'
requests, e.g., notifications that are meant for a large group, but with
no need for reliability. This would address some of the concerns in
terms of response implosion. Beyond unreliable notifications, once we
have a reliable multicast infrastructure in place, there may well be
other applications where the current concerns don't apply. It should be
noted that many other event systems have this mode, as it is much more
scalable than individual event notification. I would hate to have this
ruled impermissible. Since SIP, being transport-neutral, should be able
to make use of reliable multicast transport, it would seem short-sighted
to rule this out of scope completely.

Whether this has to be in the main draft or not is a separate question.
For non-REGISTER, it might be best to define this more specifically for
particular methods and transport infrastructures. We already have
slightly different retransmit behavior, for example, for UDP and TCP, so
this is not completely new.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henry Chen <[email-masked]>
Date: Mon, 24 Sep 2001 16:55:52 -0500

> to rule this out of scope completely.

Totally agree. I would like to add one more general case for the reason to
leverage multicast by SIP:
Whenever there is only one possible and relevant UAS who will response the
multicast request in the multicast group.
The pattern is:

Multicast request to a multicast group and
Only one possible UAS sends unicast response back.

Henry