Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference

From: [email-masked]
Date: Tue, 2 Dec 2003 16:26:08 +0200

> -----Original Message-----
> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: 02.December.2003 15:16
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]; 
> 'Paul Kyzivat'
> Cc: [email-masked]; Mayer Georg (NMP-MSW/Helsinki);
> [email-masked]; [email-masked]
> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> 
> Well it's clear that my view is different from you-all.
> Not an unfamiliar situation :(
> Let me keep trying a while, but I'll cave if I'm out here
> by myself for too long.
> 
> Several points to make.  In my view:
> 1. "Instantiating" a conference is a concept that is getting 
> confusing.
> It's all in what you mean.  I think it's when the mixer resources
> are actually allocated (as opposed to reserved).  That starts when
> the first participant creates a dialog with the focus, and ends
> when the last dialog terminates.  Getting a conference ID doesn't
> instantiate a conference, creating a dialog with it does.

Some chat type conferences can exist without any participants. Participants come and go as they please. Why is there a requirement that at least one participant is needed for the conference to ever exist?

> 
> You can have a policy on whether the conference ID expires when 
> the last dialog terminates.  If it does, once the conference
> instantiation terminates, it cannot be re-instantiated.  
> If it doesn't, then it can be re-instantiated.  An example of the 
> latter is a weekly sales meeting or a "meet-me" number.  
> An example of the latter could be a 4-way call created by a CONF 
> button.
> 
> 2. You can manipulate policy before you instantiate a conference.
> As soon as a conference ID is created, policy is available to be
> manipulated on it.  

Agreed on the part, but I don't think you need the conferece ID (that is the SIP URI for the conference) in order to manipulate the policy. CPCP can provide its own conference policy ID that is somehow mapped to a conference ID. This depends on the protocol chosen for CPCP.

> 
> 3. There is almost no difference between a pre-established 
> conference and an ad-hoc conference.  Try and think of something 
> that matters:
> 	Time between creation of conference ID and instantiation?
> 		Nope; you can pre-establish a conference and use it 
> 		immediately, and there can be an arbitrary 
> delay between 
> 		requesting an ad-hoc conference and the first dialog 
> 		with it.  And even if there was, who cares?

You are asking to redefine the whole concept of ah-hoc conferencing using SIP. The INVITE creates a conference, and creates a dialog.

> 	DialIn/DialOut 
> 		Nope - both can do both, or a mixture of either

How can you limit the dail-in list in an ad-hoc conference. Let me remind you that an ad-hoc conference does not have a policy.

For dial-out list, it is true that you can send REFER requests for the focus, but again, you cannot predefine that list. Also, you have to send a REFER to the focus for each potential participant, creating x number of dialogs, one for each REFER request.

> 	"Long running conference/chat"  Nope; length of time of a
> 		conference/chat is not relevant, you could start one 
> 		ad-hoc and leave it run for years.

again, with ad-hoc conferences, there is no policy to dictate this. I think I will stop commenting now until someone agrues that I am wrong and an ah-hoc conference also needs a policy (where my reply would be: why is it called ah-hoc then?).

Regards,
Hisham

> Therefore, I think you can't use CPCP for pre-established 
> conferences and SIP for ad-hoc conferences.  Pick one.  There is no 
> justification for two mechanisms to do the same thing.  I have a 
> problem with policy creating a conference, and I think SIP 
> signalling is a more appropriate way to create a conference, but 
> I care more about having one and only one way to do it.
> 
> 4. My view of the conference factory was that you didn't get a 
> conference instantiation from it, you only got a conference ID.  
> Either end would immediately terminate the conference factory dialog, 
> either by an actual BYE or a REFER.  If you wanted to immediately 
> instantiate the conference after getting the conferenceID, fine, 
> but you don't have to; you can just get the conference ID and
> instantiate later.  Later could be milliseconds or, if policy 
> allowed, years.
> 
> 5. I agree that non-SIP signalling mechanisms could be standardized 
> to create conferences (H.323, iCal) if there is a SIP way to do it.  
> There wouldn't be any interoperability issues with that like there 
> would if both CPCP and SIP can do it. Even a single device that had, 
> say, both SIP and iCAL mechanisms would have no interoperability 
> issues with devices that were, say, SIP-only.  On the other hand, 
> if you standardize on CPCP to do it, then you would not expect to 
> see any other standardized mechanism.
> 
> Brian
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, December 02, 2003 5:07 AM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> > 
> > 
> > Yes. After the conference server creates the focus on the 
> > scheduled time that was set using CPCP, the focus can use SIP 
> > INVTE or whatever protocol it desires to invite participants 
> > into the conference, or accpet participants to join a conference.
> > 
> > /Hisham
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On 
> > Behalf Of ext
> > > Rohan Mahy
> > > Sent: 02.December.2003 00:58
> > > To: Rosen, Brian
> > > Cc: 'Alan Johnston'; 'Orit Levin'; [email-masked]
> > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference
> > > 
> > > 
> > > 
> > > On Monday, December 1, 2003, at 02:06 PM, Rosen, Brian wrote:
> > > 
> > > > Guilty of not reading documents carefully enough.
> > > > Most of the "duplicate" mechanisms were, on my reading, merely
> > > > reflecting the observation that the focus is one end of the
> > > > dialog each participant has, and in SIP, either end can
> > > > initiate most operations, thus there is really no possibility
> > > > of incompatible implementations.  Re-reading, I think we may
> > > > want to beef up the wording to make sure of it.
> > > >
> > > > The only case where I think CPCP actually "creates" a conference
> > > > is where there is a dial out with no-one dialing in before the
> > > > dial out occurs.  It should not be possible, I think, 
> to "create"
> > > > a conference before someone dials in or the focus dials out.
> > > 
> > > I can think of several reasons to create a conference before 
> > > there are 
> > > any participants/legs/users:
> > > 
> > > - A scheduled conference which has policies set by the 
> > creator before 
> > > the creator joins
> > > - A long running conference/group chat
> > > - A dial out conference
> > > 
> > > So clearly having a mechanism to create conferences using 
> > CPCP makes 
> > > sense.
> > > 
> > > Now if someone wants to create (possibly standardized) 
> > mechanisms in 
> > > other protocols to create an XCON  conference, I see no 
> > > reason why this 
> > > is a problem.  The SIP conferencing framework describes a role (a 
> > > conference factory) that has a URI you can INVITE that will 
> > create an 
> > > XCON conference.  You could define a similar function for 
> > HTTP, XMPP, 
> > > iCal via SMTP, or H.323.
> > > 
> > > thanks,
> > > -rohan
> > > 
> > > > Similarly, a conference is destroyed when the last dialog is
> > > > terminated with a BYE, which may very well be by the focus,
> > > > but it is not terminated explicitly by CPCP.
> > > >
> > > > Looking at the other mechanisms:
> > > >   Adding participants
> > > > 	Similar to creating conferences, you can dial 
> out or dial in.
> > > > 	I think we might want to observe in the text that focus
> > > > 	implementations MUST accept INVITES and REFERS, 
> as well as
> > > > 	CPCP requests to send INVITES.  A UA could 
> implement either or
> > > > 	both mechanisms.  I would observe that if a UA 
> wishes to promote
> > > > 	a two way to a conference, then it would have to use a 
> > > REFER, and
> > > > 	no other mechanism.  I'd prefer that the SIP way be the 
> > > only way,
> > > > 	but the carriers seem to want to control who does the 
> > > dialing, so
> > > > 	there is no way the community would support REFER only.
> > > >   Removing Participants
> > > > 	Again, mostly a "both ends of the dialog" 
> issue.  BYE from focus
> > > > 	really is an acceptable way to boot someone.  
> 3rd party REFER
> > > > 	really is a duplicate, but prohibiting it seems 
> unlikely.  In
> > > > 	most systems it wouldn't work from, say, a 
> moderator, because
> > > > 	of security issues (a random user can't 
> REFER/BYE you I hope).
> > > > 	Probably need to expand that wording to say 
> "third person
> > > > 	(another participant) departures..."  I don't 
> want to imply
> > > > 	that the focus would use REFER.  It would use BYE.
> > > >
> > > > 	I note that the text in this section about the focus 
> > > manipulating
> > > > 	other dialogs is misplaced, because it would do 
> the same thing
> > > > 	if the participant was removed by SIP or any 
> other means.
> > > >   Obtaining Membership
> > > > 	I don't see why we need two mechanisms.  If we keep 
> > > both, then we
> > > > 	should explicitly require a focus to implement 
> both.  I really
> > > > 	don't care which one we keep.
> > > >
> > > >   Adding and Removing Media
> > > > 	"Both ends of the dialog" issues.  Again, a 
> focus probably can't
> > > > 	help but implement both, but it might be good 
> to say that
> > > > 	explicitly somewhere.
> > > >
> > > > Brian
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Alan Johnston [mailto:[email-masked]]
> > > >> Sent: Monday, December 01, 2003 4:12 PM
> > > >> To: Rosen, Brian; 'Orit Levin'; [email-masked]
> > > >> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a 
> > conference
> > > >>
> > > >>
> > > >> At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote:
> > > >>> Orit
> > > >>>
> > > >>> Keeping XCON separate from SIP is useful so long as it doesn't
> > > >>> get in the way of common sense.  To me, that would mean, 
> > > for example,
> > > >>> having a different name space for a conference ID, 
> requiring one
> > > >>> for CPCP and another for SIP.  If a conference ID in 
> > CPCP is not a
> > > >>> uri, for which a SIP uri is an excellent, but not 
> > > limiting example,
> > > >>> I have a very large problem.
> > > >>>
> > > >>> I don't care if some day, someone invents a way to use 
> > > CPCP without
> > > >>> SIP, and I don't have any interest in making that difficult
> > > >> in any way.
> > > >>> However, it's not a driving function, and I don't 
> think there is
> > > >>> any reason to have more than one standardized way to create
> > > >> a conference.
> > > >>> An INVITE to a conference URI does it.  A specific 
> > > implementation may
> > > >>> have some other, non standardized way.  I want ONE 
> > > standardized way,
> > > >>> unless someone has a compelling reason why we need to 
> have two.
> > > >>> It's a broken record; when you have multiple ways to do the
> > > >> same thing,
> > > >>> you facilitate incompatible implementations.  If there 
> > > are a million
> > > >>> ways, you will have a lot of incompatible systems.  I have
> > > >> no interest
> > > >>> in fostering that kind of design.
> > > >>
> > > >> Brian,
> > > >>
> > > >> Please re-read the SIP Conferencing Framework document -
> > > >> practically every
> > > >> conference-related operation has both a SIP and a non-SIP
> > > >> mechanism to do so.
> > > >>
> > > >> Thanks,
> > > >> Alan
> > > >> sip:[email-masked]
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> Brian
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Orit Levin [mailto:[email-masked]]
> > > >>>> Sent: Monday, December 01, 2003 3:02 PM
> > > >>>> To: Rosen, Brian; [email-masked]
> > > >>>> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a 
> > > conference
> > > >>>>
> > > >>>>
> > > >>>> Brian!
> > > >>>> I am actually surprised by this thread.
> > > >>>>
> > > >>>> In reality, a single conference instance can be
> > > >> potentially defined /
> > > >>>> requested by million ways. Moreover, the same conference
> > > >> instance can
> > > >>>> host participants joining by very different means and
> > > >> media. Moreover,
> > > >>>> the same conference can have more than a single unique
> > > >> identifier...
> > > >>>>
> > > >>>> SIP conferencing and XCON conferencing must be able to
> > > >> coexist in the
> > > >>>> system and share same conference instances but apart from
> > > >>>> that - each is
> > > >>>> a "complete system" on its own. (SIP point-to-point CC is
> > > >> a different
> > > >>>> issue - it is one of the tools available for XCON.)
> > > >>>>
> > > >>>> As a result, the discussion of the addressing scheme should
> > > >>>> first apply
> > > >>>> to the SIPPING conferencing work. (In XCON we still need to
> > > >>>> agree on the
> > > >>>> higher level architectural decomposition of the pieces
> > > >> that we managed
> > > >>>> to introduce.)
> > > >>>>
> > > >>>> In particular, draft-ietf-sipping-cc-conferencing-02.txt
> > > >> has different
> > > >>>> assumptions or, I should say, is less restrictive that 
> > > you propose
> > > >>>> below. BTW, it does define that "calling a Factory" 
> results in
> > > >>>> establishing a conference with its focus (either through the
> > > >>>> same dialog
> > > >>>> or by redirection to a focus - both are valid cases). If we
> > > >>>> disagree on
> > > >>>> this, let's start this discussion in SIPPING ASAP.
> > > >>>>
> > > >>>> Orit.
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> From: [email-masked] [mailto:[email-masked]] On
> > > >> Behalf Of
> > > >>>> Rosen, Brian
> > > >>>> Sent: Monday, December 01, 2003 10:26 AM
> > > >>>> To: [email-masked]'
> > > >>>> Subject: [XCON] Chicken and Egg - Can CPCP create a 
> conference
> > > >>>>
> > > >>>> I'd like to re-open the requirement to create a
> > > >> conference with CPCP.
> > > >>>> Somehow, I missed that one.
> > > >>>>
> > > >>>> Generally, I think it's a bad idea to have two ways to do
> > > >>>> something, and
> > > >>>> we
> > > >>>> have another way to create a conference (conference
> > > >> factory uri).  I'd
> > > >>>> like to eliminate one of them if possible.
> > > >>>>
> > > >>>> Beyond that, it seems to me that there is a chicken and egg
> > > >>>> problem with
> > > >>>> CPCP.  That is, how do you "start" sending CPCP "commands",
> > > >>>> and to whom
> > > >>>> do you address them?  This is an issue that 
> > intertwines with the
> > > >>>> signalling
> > > >>>> protocol (sip).  In my mind, the conference uri gave you an
> > > >>>> address (the
> > > >>>> host of the focus) and an identifier (the userpart of the
> > > >> uri).  Now,
> > > >>>> in at least the first version of all of this, do we need
> > > >> to have some
> > > >>>> kind
> > > >>>> of discovery mechanism for the conference policy server?
> > > >> I think not,
> > > >>>> or at least I think you get it from the focus.  I'd
> > > >> propose that it is
> > > >>>> precisely the host of the focus, but I'd be okay with a
> > > >> query to the
> > > >>>> focus
> > > >>>> that returned the address of the conference policy server.
> > > >>>>
> > > >>>> So, if I were choosing, I would not permit CPCP to create
> > > >> conferences.
> > > >>>> I would rely on the conference factory URI (as well as 
> > > out of band
> > > >>>> means).
> > > >>>> I would make the conference policy server the same 
> host as the
> > > >>>> conference
> > > >>>> uri, or at least make the focus return the address of
> > > >>>> conference policy
> > > >>>> server.
> > > >>>> If you need a conference uri to get the conference 
> > policy server
> > > >>>> address,
> > > >>>> then you can't use CPCP without a conference URI, and thus
> > > >>>> using CPCP to
> > > >>>> create/discover a conference URI wouldn't work.
> > > >>>>
> > > >>>> Brian
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> XCON mailing list
> > > >>>> [email-masked]
> > > >>>> https://www1.ietf.org/mailman/listinfo/xcon
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> XCON mailing list
> > > >>>> [email-masked]
> > > >>>> https://www1.ietf.org/mailman/listinfo/xcon
> > > >>>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> XCON mailing list
> > > >>> [email-masked]
> > > >>> https://www1.ietf.org/mailman/listinfo/xcon
> > > >>
> > > >
> > > > _______________________________________________
> > > > XCON mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > 
> > > 
> > > _______________________________________________
> > > XCON mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > > 
> > 
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2003 11:14:45 -0500

[email-masked] wrote:
> Some chat type conferences can exist without any participants.
 > Participants come and go as they please. Why is there a requirement
 > that at least one participant is needed for the conference to ever exist?

I agree. Defining the conference by the allocation of mixer resources 
seems wrong to me. That is very implementation specific - I might choose 
to allocate mixer resources differently than Brian does. In case of chat 
conferences where mixing is trivial, there may not be any explicitly 
allocated mixing resources at all.

IMO a conference is defined by a valid address. So as long as the sip 
address constituting the conference ID, which names a unique focus, is 
valid, it *is* a conference. The only real question is what state that 
conference is in. If the conference isn't scheduled to start yet, then I 
would hope that a request directed to it would yield some meaningful 
error - perhaps 480 Temporarily Unavailable, giving the time until it 
will be available. If a request is directed to it after policy says it 
should have expired, then a 404 Not Found error would be appropriate.

> You are asking to redefine the whole concept of ah-hoc conferencing
 > using SIP. The INVITE creates a conference, and creates a dialog.
...
 > again, with ad-hoc conferences, there is no policy to dictate this.
 > I think I will stop commenting now until someone agrues that I am
 > wrong and an ah-hoc conference also needs a policy (where my reply
 > would be: why is it called ah-hoc then?).

I have to disagree with you and agree with Brian here.
I don't think it makes sense to say a conference has no policy.
It may be that you can neither query nor manipulate the policy, but 
conceptually it still has a policy. Fancier conferencing products would 
hopefully provide the ability to query and manipulate policy on ad hoc 
conferences.

I think the only real difference is that if you create an ad hoc 
conference by sending an invitation to a conference factory, you get a 
conference with some *default* policy determined by the factory in its 
infinite wisdom.

	Paul