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

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

> > 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. 
> 
> 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.
> 
> Depending on the protocol we chose, a SIP URI can or cannot 
> be used to identify a conference policy.
I think we CAN always have the same ID.
I think there is a lot of value in one ID
I don't think there is any problem in having one ID

So, I think there should be one.

If there is a good reason, we can burden the conference policy server
with keeping the relationship, but unless there is a good reason, history
suggests that one namespace is better than two with linkage.

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

Well, basically, I agree; we don't need to distinguish between
an ad-hoc conference and a pre-established one.  I think we definitely
need policy for ad-hoc conferences (as you define them), and
don't see any reason we need to differentiate.

Why can't someone ask the conference policy server to dial out to
add someone to an ad-hoc conference?  It's crystal clear that you
need media policy, otherwise, you can't control mixing at all, and we
already do that (for something that clearly meets you definition
of an ad-hoc conference).  Shouldn't I be able, as the conference
creator, to control who is in my conference, or can any participant
add any other participant?  That's up to me, isn't it?

So, I think there is very much a requirement for conference policy
for ad-hoc, and there is no need, nor reason to have anything special
for ad-hoc, or for pre-established conferences.
> 
> > 
> > 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 schedule a conference for a week from now, you need
to "guarantee" that resources will be available in a week
for that conference.  That is resource reservation.  A
re-usable conference which has no time schedule would have to
have resources reserved, just like a "meet-me" number.
Of course, like a "meet-me", a given implementation may use
some statistics to guide what kind of actual reservation mechanism
it employs.
> 
> > 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.

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

---

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

> suggests that one namespace is better than two with linkage.

[The chicken and the egg are different things. If I want to talk to the 
egg I need the address of the egg - having the address of the chicken 
isn't sufficient. Its probably a bad idea to crack the egg in order to 
ask the chicken for the address of the egg.]

Getting away from metaphors, this seems to be coming down to the 
distinction between URIs and URLs.

A sip address is a URL in that it is sufficient for me to locate a 
corresponding (sip) resource.

But it isn't sufficient for me to locate a CPCP resource. If I knew how 
to contact the appropriate CPCP server, perhaps a sip uri could serve to 
identify the policy. But that would require me to know the address of 
the server a-priori.

If all I have is the sip conference id, then to derive the URI for the 
policy from it I must invoke sip operations on it.

	Paul