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

From: [email-masked]
Date: Wed, 3 Dec 2003 10:57:04 +0200

> -----Original Message-----
> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: 02.December.2003 18:28
> To: 'Alan Johnston'; Khartabil Hisham (NMP-MSW/Helsinki);
> [email-masked]; [email-masked]
> Cc: Mayer Georg (NMP-MSW/Helsinki); [email-masked]; [email-masked]
> Subject: 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.
> 
> 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 see it as you connect to conference policy server, create a conference policy and a conference ID (or get a conference ID assigned to you). There is no need for a default policy to exist for non ad-hoc conferences.

/Hisham

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Dec 2003 15:36:53 -0500

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

> From: Orit Levin [mailto:[email-masked]]
> Sent: Monday, December 01, 2003 3:02 PM
> To: Rosen, Brian; [email-masked]
> 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.
> 
> 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
>