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

From: Nermeen Ismail <[email-masked]>
Date: Tue, 09 Dec 2003 17:00:51 -0800

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: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, December 04, 2003 4:54 AM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > 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: [email-masked] [mailto:[email-masked]]On
> > Behalf Of ext
> > > Nermeen Ismail
> > > Sent: 04.December.2003 05:56
> > > To: Rosen, Brian
> > > Cc: [email-masked]
> > > 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
> > > >[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: [email-masked]
Date: Wed, 10 Dec 2003 13:00:22 +0200

I don't think anyone was suggesting that as soon as a conference policy is in place, the resources must be reserved. CPCP does not provide an interface for resource allocation, but it does provide the scheduled time for the conference. It is up to the conference host to read the start and stop times for a conference and allocate resources using some local intelligence.

In my definitions, conference host and conference server are the same thing.

More comment inline...

> From: ext Nermeen Ismail [mailto:[email-masked]]
> Sent: 10.December.2003 03:01
> To: Rosen, Brian
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]
> Subject: RE: [XCON] CPCP and resource allocation. (was: 
> Chicken and Egg
> - Can CPCP create a conference)
> 
> 
> Ok back to the hot seat.
> 

I don't quite understand what your saying here, but I'll comment anyway: Assigning a conference URI is not assigning resources. It is merely assigning an ID to that conference. It does not matter when that ID is assigned as long as it is done before the conference starts. But I would be done long enough to enable users to pass it around.

Regards,
Hisham

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 10 Dec 2003 10:16:46 -0500

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

> From: Nermeen Ismail [mailto:[email-masked]]
> Sent: Tuesday, December 09, 2003 8:01 PM
> To: Rosen, Brian
> Cc: [email-masked]'; [email-masked]

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 11 Dec 2003 23:23:37 -0500

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

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Wed, December 10, 2003 10:17 AM
> To: 'Nermeen Ismail'