Subject: RE: [Sipping] update to conferencing models draft!

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 1 Aug 2001 02:46:24 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 11:57 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Sipping] update to conferencing models draft!
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 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
> 
> 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.)

I suppose that is possible, yes. I can add some text about that to the next
version. Of course, we are going to run into the problem that the refer
target needs to know that the incoming call legs need to join an existing
leg, as opposed to being a totally separate call.
draft-rosenberg-sip-call-package proposes a way to fix that.

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

That depends on whether the multicast group is created just for the purposes
of this call, or whether the INVITE is asking someone to join an existing,
separately allocating mbone conference. In the latter case, its not entirely
clear that BYE is needed to clean up the call state, so long as both sides
know that this is a call for a session where the session itself has its own
mechanisms for lifecycle management, and thus a BYE is not needed. There is
no way to signal that now, and this is listed as an open issue in the draft.

Way back when, I recall there was a proposed "Session" header which we had
thought about using for this purpose. However, that header disappeared,
being folded into the mime headers, I think.

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

Again, it depends on whether the media sessions are created for the purpose
of the call, or whether the call is to an existing, separately managed media
session (like an mbone conference). The draft really doesn't talk about the
former case, and its probably worth doing that.

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

One of the open issues I have written down is whether or not a unicast offer
can be answered with a multicast address (and vice a versa), and what that
might mean. If such a thing were possible, the re-invite might not be
needed.

-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: "Eric Burger" <[email-masked]>
Date: Mon, 6 Aug 2001 17:00:01 -0400

Section 4.1: conference URI service indicator (a'la announcement service
indicator of draft-burger-sipping-netann-00.txt) is coming after the IETF
blackout period.

Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping