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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Dec 2003 12:10:49 -0500

Well, now you might see why I think the Conference Factory URI
does not instantiate a conference; it just returns a conference ID.
That way, you could, if you wanted to, change the default policy
before you "started" it.

If you go to a scheduler and create a conference, you may or may
not have to enter any more questions other than start time.  You
may not even be asked that; it's implementation dependent.  When
the service gives you a conference uri, you have what you need
to modify the conference policy with CPCP.  You can do it immediately
after you get the uri, just before the conference starts, immediately
after it starts, or just before it ends.  Doesn't matter.  The
protocol mechanism is the same.

That's why I don't think CPCP has to create conference uris.
It's duplicative of the conference factory uri.  We can get rid of
one of these mechanisms and not lose anything.  I think we should.

Brian

> -----Original Message-----
> From: Heil Franca Marcelo [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2003 11:58 AM
> To: 'Rosen, Brian'; 'Alan Johnston'; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> 
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Rosen, Brian [mailto:[email-masked]] 
> > Gesendet: Dienstag, 2. Dezember 2003 17:28
> > An: 'Alan Johnston'; [email-masked]; 
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Betreff: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> > 
> > 
> > Agree with one nit.
> > 
> > Every conference starts with a default policy.  You then use CPCP to
> > modify it.  The conference service defines the default 
> policy.  It may
> > also enforce limits on what kinds of changes could be made to policy
> > with CPCP, but that is beyond the scope of our work.  The 
> > default policy
> > for an ad-hoc conference may or may not be different from 
> the default
> > policy for a pre-scheduled conference; that's an 
> implementation issue.
> > 
> I see one point here: pre-scheduled conferences may start 
> with a policy which is different from the default one, as the 
> policy could have been changed at conference creation 
> (scheduling) time. (This is of course application dependent.)
> 
> 
> > If you create a conference ID, connect to the conference 
> policy server
> > and request it's current conference policy, you should get 
> a coherent
> > answer.
> > 
> I think that the conference server is the entity that creates 
> the conference ID (on request), not "me"...
> 
> Marcelo
> 
> > > -----Original Message-----
> > > From: Alan Johnston [mailto:[email-masked]]
> > > Sent: Tuesday, December 02, 2003 10:52 AM
> > > To: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> > > 
> > > 
> > > At 05:26 PM 12/2/2003 +0200, [email-masked] wrote:
> > > 
> > > 
> > > > > -----Original Message-----
> > > > > From: ext Rosen, Brian [mailto:[email-masked]]
> > > > > Sent: 02.December.2003 16:52
> > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> > > > > [email-masked]
> > > > > Cc: [email-masked]; Mayer Georg (NMP-MSW/Helsinki);
> > > > > [email-masked]; [email-masked]
> > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a 
> > conference
> > > > >
> > > > >
> > > > > So, two fundamental differences:
> > > > > 1. You think CPCP has some separate namespace 
> > independent of a URI
> > > > > (of which a SIP uri is a good, but not exclusive example).
> > > > > I am opposed to that.  A conferenceID is a uri.  I 
> can imagine a
> > > > > specific instance of a conference service that could 
> > have multiple
> > > > > IDs for the same conference, for example, an H.323 URI 
> > > and a SIP URI
> > > > > that resolves to the same conference.  That's fine, and it's
> > > > > not subject
> > > > > to standardization.  However, I think that the ID you 
> > use with the
> > > > > focus is always the ID you use with CPCP for the same 
> > conference.
> > > >
> > > >I don't understand why the ID for the conference needs to be 
> > > the same as 
> > > >the ID for the conference policy.
> > > 
> > > I agree with Brian here.  The conference identifier is the 
> > > URI.  It is the 
> > > means by which a participant joins the conference and 
> > depends on the 
> > > signaling protocol (SIP, H.323, PSTN, etc.).  It can't just 
> > > be some random 
> > > string.  This is a fundamental idea in the framework.
> > > 
> > > >If you look at XCAP list usage for example, you will see 
> > > that the list-URI 
> > > >used when sending SIP SUBSCRIBE requests to the list is not 
> > > the same as 
> > > >the URI used to manipulate the list using XCAP. They 
> > > certainly need to be 
> > > >linked, but not necessarily the same.
> > > 
> > > I don't understand what you are saying.  The policy URI and 
> > > the conference 
> > > URI can not be the same since they are different protocols, right?
> > > 
> > > 
> > > >Depending on the protocol we chose, a SIP URI can or cannot 
> > > be used to 
> > > >identify a conference policy.
> > > 
> > > Knowing only the conference URI, it must be possible to 
> > determine the 
> > > conference policy URI.
> > > 
> > > 
> > > > >
> > > > > 2. You think ad-hoc conferences don't have policy.  I am
> > > > > fundamentally
> > > > > opposed to that.  Ad-hoc conferences should have all of the
> > > > > functionality of a pre-established conference and I can't 
> > > imagine any
> > > > > reason why we can't provide that.
> > > >
> > > >If we replicate everything that a scheduled conference can 
> > > have to ad-hoc 
> > > >conferences, then we don't need scheduled conferences at 
> > > all. Perhaps we 
> > > >need to define the scope of an ad-hoc conference. To me an 
> > > ad-hoc is just 
> > > >that; a conference created instantaneously for discussing an 
> > > urgent matter 
> > > >or whatever. You REFER other participants and it terminated 
> > > as soon as the 
> > > >last participant leaves. There are no start and stop times, 
> > > there are no 
> > > >dial-out and dial-in lists configured, there is no general 
> > > conference 
> > > >info, and there are no media policies.
> > > 
> > > I agree 100% with Brian.  An ad-hoc conference does have 
> > > policy, but it is 
> > > a default (non-unique) policy.  The creator of the conference 
> > > factory URI 
> > > sets that policy.  It is possible for this policy to be 
> > > manipulated once 
> > > the conference has begun, but again this is up to the application.
> > > 
> > > There is no such thing as an "ad-hoc conference" or a "scheduled 
> > > conference" - however,there are "ad-hoc methods" of joining 
> > > or being added 
> > > to a conference, and scheduled means.
> > > 
> > > When joining a pre-established, the conference URI is 
> > typically sent 
> > > out-of-band, often in advance, to participants using say 
> > > email or IM.  When 
> > > a participant is added using ad-hoc means, they often will 
> > > not know (see) 
> > > the conference URI - they will just be added in via a REFER or 
> > > transfer.  Trying to come up with a strict definition for one 
> > > vs. the other 
> > > is very difficult and probably not all that productive.
> > > 
> > > I would encourage everyone to carefully read the SIPPING 
> Conference 
> > > Framework document - it details many of these issues.
> > > 
> > > Thanks,
> > > Alan Johnston
> > > MCI
> > > sip:[email-masked]
> > > 
> > > > >
> > > > > We also have a nit, at least I think it's a nit, about 
> > > Instantiation.
> > > > > I'm not sure there is any real difference between a re-usable
> > > > > conference ID and an instantiated conference that has no
> > > > > participants.
> > > > > Since I define instantiated as allocated mixer resources, 
> > > if I'm not
> > > > > using resources I don't have the conference instantiated.
> > > >
> > > >I agree about the definition of "instantiated". But if 
> > there are no 
> > > >current participants in a conference, and a server releases 
> > > resources and 
> > > >keeps the conference ID, it needs to guarantee what 
> > > resources will be 
> > > >available as soon as a participant enters. This might be not 
> > > releasing the 
> > > >resources. Perhaps all this is an implementation issue.
> > > >
> > > > > If you define instantiation differently, then you could.
> > > > > It would be good, I think, to have a common agreement on what
> > > > > instantiation means, because we use it in the 
> documents, but I'm
> > > > > not sure we disagree on what can happen.  We both 
> agree you can
> > > > > manipulate policy, and we both agree participants can 
> > come and go.
> > > > > I guess I would ask you if you have some notion of a re-usable
> > > > > conference ID that is somehow different from an instantiated
> > > > > conference with no participants.
> > > >
> > > >A conference ID can exist even if a conference is not 
> > > instantiated. But 
> > > >what I was trying to say is that a conference can be 
> > > instantiated without 
> > > >any participants, unless as I said, the resources can be 
> > > guaranteed to be 
> > > >reallocated.
> > > >
> > > >Regards,
> > > >Hisham
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] 
> > > [mailto:[email-masked]]
> > > > > > Sent: Tuesday, December 02, 2003 9:26 AM
> > > > > > To: [email-masked]; [email-masked]; 
> > [email-masked]
> > > > > > Cc: [email-masked]; [email-masked];
> > > > > [email-masked];
> > > > > > [email-masked]
> > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a 
> > > conference
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----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
> > > > > > >
> > > > >
> > > > > >
> > > > >
> > > 
> > 
> > _______________________________________________
> > 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 14:22:16 -0500

> That way, you could, if you wanted to, change the default policy

It is my understanding that the Conference Factory URI is used by 
sending an INVITE to it. So how is it supposed to return a conference ID 
without also "starting" the conference? Typically the result of the 
INVITE will be a dialog with the focus, with the address of the focus 
being returned as the Contact. Or are you assuming that Conference 
Factory URI will *always* return a 3xx rather than establishing the dialog?

I would hate to write an application for creating/configuring a 
conference that sends and INVITE but depends on it not succeeding - so 
that if it is surprised by having the INVITE succeed it barfs.

I think sending an invite to a Conference Factory URI should only be 
used when the UAC wants to participate in a new conference that starts 
*now*.

If you want to establish a name and policy for a conference to take 
place later, then I think you must use other means.

	Paul