Subject: [Sipping] update to conferencing models draft!

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2001 03:53:09 -0400

Folks,

I've submitted an update to draft-rosenberg-sip-conferencing-models. The new
version has clarified some of the cases with additional call flow diagrams
and explanations. It also notes some open issues that need resolution. Until
it appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-conferencing-models-01.txt

Thanks,
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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Jul 2001 11:57:19 -0400

> http://www.jdrosen.net/papers/draft-rosenberg-sip-conferencing-models-01.txt

I wonder about a couple of things in this paper:

- End System Mixing (section 2.1) says:

   A serious problem with the more complex topologies is that the
   departure of a participant might cause a partition of the conference
   into several sub-conferences which cannot easily be healed.

Why? This need not be the case; it is only necessary for that UA to
splice together the parties it was mixing before leaving. This is
possible if there are only two of them. This is the same as a
consultative transfer. (It is harder with more parties because it is
necessary to find someone else who can mix.)

- Large Scale Multicast Conferences (section 3): this description covers
a bit more ground than seems appropriate for a SIP draft - conference
participation that isn't initiated with SIP ought to be out of scope. I
also think this should call for more discipline and control than it
does. For instance, it says that BYE is not needed. But from a SIP
signalling perspective, there is state in each call. That state needs to
be cleaned up, which requires BYE. Also, if the multicast address is
obtained dynamically, it should be yielded when there are no more
participants in the conference. 

So, if it is worth discussing multicast based conferences for SIP, then
I would think the techniques presented ought to assure that the
conference is controlled by sip signalling, including the lifetime of
the media sessions. (It is my understanding that normally media sessions
are assumed to end when all the calls that negotiated them end - why
should this be different for multicast media?) 

One way to achieve this would be to have another kind of dial-out
conference server, where the SDP contains a multicast address. This
could also work for dial-in if the caller knew not to offer any SDP in
the invite, but of course the caller wouldn't normally know to do this.
A server could work around that: if it receives an invitation with
media, it could accept on hold. Then it could immediately send a
reinvite offering the multicast media.

The point is that now the conference server knows who, and how many, are
in conference. The multicast address can be released when everyone has
departed. This perhaps doesn't scale well to millions of participants,
but then I think you have exceeded the limits where sip is applicable.

This doesn't prevent someone from obtaining the SDP and putting it into
a new invite, but that should perhaps be undefined behavior. The burden
is on the UA issuing the invite to end the call when the media become
invalid, and the prime way that UA would know that would be to have
received the SDP as part of some other call.

But it might not be worth the trouble to specify multicast conferencing
with SIP if nobody is doing it.

	Paul Kyzivat
	Cisco Systems

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 31 Jul 2001 12:23:12 -0400

Paul Kyzivat wrote:

> with SIP if nobody is doing it.

I suspect that it will be used. Multicast is humming along nicely in
Internet2 and works just fine in most internal networks. In addition,
anything we can do to encourage its use seems worth doing, from an
architectural perspective.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs