RE: [XCON] CPCP and resource allocation. (was: Chicken and Egg - Can CPCP create a conference)

["Eric Burger" <eburger@snowshore.com>]

I, too, get to agree with Brian :-)

On the issue of creating the conference/policy/etc URI family: If we do not do that, what are we doing with CPCP, anyway?  What we would be saying is, "Use this protocol to schedule a conference.  When you do that, nothing happens.  Don't worry -- that is by design."  That does not make much sense!

I fully agree that media resource allocation is independent of a conference scheduling protocol.

Let me also propose that it is OUT OF SCOPE for what has been described as "media policy."  Media policy is about who gets to talk to whom NOW.  Resource allocation is about manipulating resources, in this case at the DSP or media server level.  That is another, yet solved, problem.

[A nit is that the conference server/media server interface is out of scope for XCON.]

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Wed, December 10, 2003 10:17 AM
> To: 'Nermeen Ismail'
> Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org
> Subject: RE: [XCON] CPCP and resource allocation. (was: 
> Chicken and Egg
> - Can CPCP create a conference)
> 
> 
> The kind of resources you are discussing are actually media resources,
> and thus really part of media policy, but there is no escaping the
> fact that a pre-established conference reserves some resources.
> So, scheduling a conference does some resource reservation.  The
> resource reservation is a byproduct of the scheduled nature of
> the conference and the specific media (and other) resources that
> reservation may need.  I don't see CPCP needing any specific
> capabilities for resource reservation, and an implementation may
> choose to not reserve any resources
> 
> Except one -- the URI(s).
> 
> When you schedule a conference, you get the conference URI (and,
> I guess, the conference policy URI and the media policy URI) right
> away.  You need the conference uri to pass to participants in some
> circumstances (consider, for example, the calendar automaton that
> schedules a conference as a result of a calendar operation, and
> places the conference URI in the calendar for later use to create
> the connection for the user to the conference.  There is no "later";
> you have to get the URI upon scheduling it.
> 
> You can also manipulate the conference policy and the media policy
> any time between creation and the end of the conference, so you
> need those also.  To extend the example; you might reserve "ports"
> for all the people you invite to a conference.  The calendar 
> mechanisms
> usually have invitation mechanisms with accept/decline.  The decline
> operation could result in decreasing the number of reserved "ports"
> in an intelligent implementation.  Such operations would occur 
> after scheduling and before the start of the conference.
> 
> Brian
> 
> > -----Original Message-----
> > From: Nermeen Ismail [mailto:nismail@cisco.com]
> > Sent: Tuesday, December 09, 2003 8:01 PM
> > To: Rosen, Brian
> > Cc: 'hisham.khartabil@nokia.com'; xcon@ietf.org
> > Subject: RE: [XCON] CPCP and resource allocation. (was: 
> > Chicken and Egg
> > - Can CPCP create a conference)
> > 
> > 
> > Ok back to the hot seat.
> > 
> > I agree that CPCP should allow conferences that have been 
> > scheduled in 
> > adavnce to be created. However that does not mean that CPCP
> > should provide the inetrafce for resource allocation.
> > 
> > I am not sure that resource allocation is a function of the 
> > conference 
> > server because:
> > - The same DSP resources can be scheduled for 
> > mixing(conferencing) or for 
> > other types of services (e.g. transcoding). So really 
> > resource allocation 
> > is not a conferencing-specific function
> > - I can not see the point of allocating a URI (be it SIP, 
> > SPIS, TEL, H.323) 
> > when really the conference is going to start in two weeks 
> > time. I prefer to
> > separate the problem of resource allocation which can happen way in 
> > adavance and can cater for more than just mixing resources  
> from the 
> > problem of allocating a conference URI and a conferenec 
> > policy that allows 
> > participants to join into the conference right now. I have 
> > understood CPCP 
> > to be targeting the latter and not the first.
> > 
> > nermeen
> > 
> > 
> > 
> > 
> > 
> > 
> > >Hurray, someone else on the hot seat.
> > >
> > >I agree with Hisham, and others, that schedule in advance is
> > >a clear requirement we must support (existing systems do it),
> > >it's not hard, and the resource allocation is local policy at the
> > >conference service.   The simplest way to get around time
> > >zone issues is to simply have the schedule always be in GMT,
> > >and leave it to the clients to deal with local conversion 
> for display
> > >purposes.
> > >
> > >Conference system vendors have coped with the scheduling 
> problem for
> > >years, and have sensible, albeit not foolproof heuristics to make
> > >scheduled conferences work pretty well.  The reality these days is
> > >that calculating conference resources is already an 
> inexact science,
> > >and you don't really know if your DSP will run out of 
> > horsepower until
> > >it does. Again, vendors often use heuristics and approximations to
> > >give you a "port count".
> > >
> > >Brian
> > >
> > > > -----Original Message-----
> > > > From: hisham.khartabil@nokia.com 
> > [mailto:hisham.khartabil@nokia.com]
> > > > Sent: Thursday, December 04, 2003 4:54 AM
> > > > To: nismail@cisco.com; Brian.Rosen@marconi.com
> > > > Cc: xcon@ietf.org
> > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a 
> conference
> > > >
> > > >
> > > > I can't believe people still think time zones are a problem.
> > > > There are many time zone standards that can be used. The only
> > > > requirement is that the client and the server need to
> > > > implement the same one. That is hardly a show stopper.
> > > >
> > > > /Hisham
> > > >
> > > > > -----Original Message-----
> > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On
> > > > Behalf Of ext
> > > > > Nermeen Ismail
> > > > > Sent: 04.December.2003 05:56
> > > > > To: Rosen, Brian
> > > > > Cc: xcon@ietf.org
> > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a 
> > conference
> > > > >
> > > > >
> > > > > I have just seen this thread so I might be repeating what is
> > > > > laredy been said.
> > > > >
> > > > > I agree that from the protocols point of view a conference is
> > > > > a conference.
> > > > > It does not matter if it is ad hoc or scheduled. It has a
> > > > > unique URI, its
> > > > > policy can be manipulated and authorized users can join/leave
> > > > > them either
> > > > > by dial-in or dial-out.
> > > > >
> > > > > My understanding for why there are two ways to create a
> > > > > conference is to
> > > > > support :
> > > > > 1- Creating a conference and joining it without having 
> > to implement
> > > > > anything other than SIP (cc-conferencing). In this case 
> > sending an
> > > > > INVITE to the URI factory is sufficient. Off course if the
> > > > > endpoint needs
> > > > > to do something more like modifying the conference policy then
> > > > > it needs to also implement CPCP/MPCP in which case it might
> > > > > have just used
> > > > > that to create the conference. However the point is 
> > still that an
> > > > > application can create, join a conference and get the
> > > > roster without
> > > > > needing anything other than a SIP stack.
> > > > >
> > > > > 2- Creating a conference and never joining it. This is like
> > > > > the case of a
> > > > > scheduling automata that at the time of conference scheduling
> > > > > it creates a
> > > > > conference and a focus. In this case and as the application
> > > > > will never send
> > > > > or receive media to the conference it was deemed
> > > > > inappropriate to demand
> > > > > the application to have a SIP stack and send a no-media
> > > > > INVITE to create
> > > > > the conference. Hence some non-SIP method will be used to
> > > > create the
> > > > > conference. A non-sip method will be used to create the
> > > > > conference (enters
> > > > > CPCP) and this create-conference will be sent to the
> > > > top-level policy
> > > > > server URI which in return will send the conference URI and
> > > > > the policy
> > > > > server URI for that conference. The only benefot that this
> > > > method has
> > > > > over number 1 is that the application does not have to 
> > support SIP.
> > > > >
> > > > > So a conference server needs to have a SIP stack, 
> > CPCP/MPCP and the
> > > > > conference package but a client might only have a SIP stack,
> > > > > a CPCP/MPCP
> > > > > implementation or both.
> > > > >
> > > > > On a separate topic, it was mentioned before that when a
> > > > > conference is
> > > > > created a future start time can be specified. I see lots of
> > > > > complications
> > > > > with that to do with time zones etc. Already the client that
> > > > > created the
> > > > > conference has to deal with that and I do not see any benefit
> > > > > in extending
> > > > > that to the conference server as well. So I see benefits in
> > > > > specifying a
> > > > > conference duration but no benefit in specifying conference
> > > > > start time.
> > > > > If the client creating the conference wishes the conference
> > > > to start
> > > > > accepting users in 5 minutes time then it needs to delay
> > > > > sending the create
> > > > > conference 5 minutes.
> > > > >
> > > > >
> > > > > nermeen
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > > >We must stop talking about "ad-hoc conferences" 
> > and "scheduled
> > > > > > > conferences"
> > > > > > > >- there is no such thing.  There are only ad-hoc 
> > mechanisms and
> > > > > > > scheduled
> > > > > > > >mechanisms to create/join a conference.
> > > > > >Which, I think, is completely useless.
> > > > > >And, to be specific:
> > > > > >         There is no difference in how you join a conference
> > > > > >                 You always send an INVITE, or get a REFER,
> > > > > >                         or receive an INVITE.  You 
> > can't join with
> > > > > >                         CPCP.
> > > > > >         There is no reason to have a difference to 
> create one
> > > > > >
> > > > > > >
> > > > > > > [Chris Boulton] I totally agree.  Whether 'ad-hoc' or
> > > > > > > 'scheduled' means
> > > > > > > are used to create a conference should have no effect - a
> > > > > conference
> > > > > > > should be created and a default policy applied.  Then,
> > > > if it is an
> > > > > > > 'ad-hoc' conference, a participant is free to join and
> > > > if it is a
> > > > > > > scheduled, the creator may manipulate the 
> conference policy.
> > > > > >Why is it different with ad-hoc that a participant is 
> > free to join?
> > > > > >Why is it different with scheduled that the creator 
> > may manipulate
> > > > > >the conference policy?
> > > > > >
> > > > > >I think there is no difference at all.  No matter how you
> > > > create it,
> > > > > >participants are free to join any time the policy says 
> > they pay.
> > > > > >No matter how you create it, the creator may manipulate the
> > > > > conference
> > > > > >policy (and participants may manipulate it also, subject to
> > > > > permissions).
> > > > > >
> > > > > >
> > > > > > > >So, if The Example Company already has their public web
> > > > > server home
> > > > > > > page at
> > > > > > > >example.com where everyone goes to download the latest
> > > > > examples, this
> > > > > > > web
> > > > > > > >server now needs to become the conference policy server?
> > > > > >No, unless the example.com is also the focus host.  If it
> > > > > is, then the
> > > > > >web server is there too. That is just not a limitation
> > > > worth worrying
> > > > > >about.
> > > > > >
> > > > > >
> > > > > > > >
> > > > > > > >There are significant disadvantages in limiting
> > > > ourselves to such
> > > > > > > >conventions - especially when there are other ways of
> > > > > discovering the
> > > > > > > >policy URI.  One way that has been discussed is 
> advertising
> > > > > > > the policy
> > > > > > > URI
> > > > > > > >in conference package notifications.  Is this not
> > > > > sufficient?  This
> > > > > > > >approach is flexible and extensible (different protocols
> > > > > for policy
> > > > > > > >manipulation can be defined with a new URI 
> scheme) and has
> > > > > > > none of the
> > > > > > > name
> > > > > > > >space limitations of this proposal.
> > > > > > >
> > > > > > > [Chris Boulton] This approach does seem to 'shoe-horn'
> > > > > the HTTP usage
> > > > > > > and IMHO is quite an ugly solution.  As Alan points out,
> > > > > policy URI
> > > > > > > contained in conference packages is a far more 
> > elegant solution.
> > > > > > >
> > > > > >My problem is that we seem to be heading to a solution 
> > where there
> > > > > >is no subset of capabilities.  To do anything, you need to
> > > > implement:
> > > > > >         cc conference
> > > > > >AND
> > > > > >         cpcp
> > > > > >AND
> > > > > >         mpcp
> > > > > >AND
> > > > > >         the conference package
> > > > > >
> > > > > >There are no simple implementations other than 
> > conference unaware.
> > > > > >Is that really what we want to do?  Intertwine all the
> > > > pieces so that
> > > > > >there is no clean functional separation that allows 
> > implementation
> > > > > >flexibility without creating incompatibility?  In 
> this specific
> > > > > >case, why do you have to implement the conference 
> > package in order
> > > > > >to discover the conference policy uri?
> > > > > >
> > > > > >A message or two ago, Alan talked about automata
> > > > > manipulating conference
> > > > > >policy, and you were aghast that I proposed using 
> SIP means to
> > > > > >create a conference ID.  You now want the automata to 
> > use SIP means
> > > > > >to find a conference policy URI given a conference URI; they
> > > > > even have
> > > > > >to join the conference to do so, unless the automata 
> > created the
> > > > > >conference in the first place, where it may get the
> > > > conference policy
> > > > > >uri returned to it).
> > > > > >
> > > > > >Can't we give up a slight amount of flexibility to get the
> > > > > possibility
> > > > > >of more widespread use of this facility by limiting 
> > implementation
> > > > > >complexity?  Maybe we need some use case stuff to see how
> > > > > subsets might
> > > > > >be useful.
> > > > > >
> > > > > >
> > > > > >_______________________________________________
> > > > > >XCON mailing list
> > > > > >XCON@ietf.org
> > > > > >https://www1.ietf.org/mailman/listinfo/xcon
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > XCON mailing list
> > > > > XCON@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > > >
> > > >
> > 
> 
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon