RE: [XCON] CPCP Requirement: Repeat times

[Michael Hammer <mhammer at cisco.com>]

At 08:21 AM 2/6/2004 -0500, Rosen, Brian wrote:
> I don't understand what you are talking about.
>
> End when last person leaves is the way many bridges work.
Is that a technical justification?

> You might
> not like it, but that's the way they work.  Most bridges don't
> start if the convener is not there.  If he arrives, and then leaves,
> the conference is over.
What is the meaning of conference policy then?  I thought that it was an 
authorization for something to take place.  If the conference is authorized 
to start and someone shows up, then it starts.  If it is authorized to 
stop, and the bridge resources are needed elsewhere, then it stops.

> It also doesn't work to manipulate stop time to end the conference because
> its the bridge that wants to enforce its policy and not the convener.
Who is the authority here?  Isnt' the bridge-providing service supposed to 
obey policy?

> If the policy is that the conference ends when stop time is reached, and
> the convener leaves with stop time set long, how does the conference end?
> How does any participant know?
This is a different question.  Separate out the algorithm for the 
bridge-providing service to provide bridges, whether some bridge resources 
are available in a pool, and whether a bridge is assigned at the moment to 
a conference.  The stop time could mean that a bridge is authorized is 
someone is attempting to join the conference.  If no one is on, the bridges 
could be released, so long as some bridge resources are still available in 
the pool to meet demand.  But, that is more part of the resource allocation 
strategy, and an implementation detail.  It seems the confusion here stems 
from not separating:

Is a conference authorized at the moment,
Is a bridge needed at the moment,
and should a bridge be reserved at the moment.

> We have to be explicit.
Yes, particularly as to the semantics of policy.  What does start time 
mean?  What does stop time mean?  I keep seeing primary meanings tangled up 
with secondary and tertiary implementation implications.

> As to Cullen's objection, what you are worried about is start time,
> and not stop time.  By your definition, the conference never started.
> If it did start, then it ends when whoever showed up leaves (if that's
> what the conference policy was set to), or when the convener leaves,
> which is surely the right thing.  I don't know how to fix your problem
> actually.   Maybe some kind of action that resets start.
The bridge may need to be released and re-captured, but that does not mean 
the conference is re-started.

>   The problem is,
> that would have to be a convener action; you wouldn't want a participant
> to invoke it.
>
> Also, Petri, you can't implement a "Meet Me" with start/stop.  MeetMes don't
> have start and stop times.
You are asserting what the group is attempting to define.

>   They start whenever the convener arrives,
What if the convener never arrives, but the rest of the group does?  To say 
it never starts seems rather limiting in an unnecessary way.

> end
> when he leaves (usually),
This again is not necessary.  A convener (payer) may want to start the 
conference, but not stay for the full discussion.  No reason the conference 
can not continue without that person, if the policy says it can.

> but restart when he arrives again with out regard
> to start and stop.
A new start and stop time is a new conference, perhaps an ad hoc 
one.  There is no reason the conference policy would restrict the convener 
from scheduling multiple conferences, unless there is other local policy 
that over-rides the ability to do so.  But, that again is implementation.

I hope the tone of the above does not sound harsh.  I just think it would 
be useful to separate the definition of "what" the conference is from the 
definition of "how" it is to be supported.

Mike



> Brian
>
> > -----Original Message-----
> > From: petri.koskelainen@nokia.com [mailto:petri.koskelainen@nokia.com]
> > Sent: Friday, February 06, 2004 3:08 AM
> > To: fluffy@cisco.com; Brian.Rosen@marconi.com; drage@lucent.com;
> > klantz@cisco.com
> > Cc: xcon@ietf.org; dbieseli@cisco.com
> > Subject: RE: [XCON] CPCP Requirement: Repeat times
> >
> >
> > what is wrong with start and stop times?
> > They should cover all use cases. The use case you are referring to
> > is easy since we already have start/stop times.
> >
> > I don't like "stop when last person leaves" either since (in
> > the end of conference)
> > you could hang up, get coffee and join again. This scenario
> > can be achieved with stop time, though.
> >
> > All uses cases I have seen can be solved with simple start/stop times.
> > (note: stop time can be modified anytime, and ACLs are in use).
> >
> > Petri
> >
> >
> > > -----Original Message-----
> > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On
> > Behalf Of ext
> > > Cullen Jennings
> > > Sent: 06 February, 2004 09:58
> > > To: Brian Rosen; 'Drage, Keith (Keith)'; Keith A Lantz
> > > Cc: XCON-IETF; Dave Bieselin
> > > Subject: Re: [XCON] CPCP Requirement: Repeat times
> > >
> > >
> > >
> > > I want something more complex that these.  - I don't like
> > > systems where the
> > > first person dials in, realizes they are the only person
> > there because
> > > everyone else is 5 minutes late, hangs up to go get a coffee
> > > and now the
> > > conference has ended and no one else can join.
> > >
> > >
> > > On 2/5/04 6:01 AM, "Rosen, Brian" <Brian.Rosen@marconi.com> wrote:
> > >
> > > > I formally propose a requirement that states
> > > >
> > > > There shall be a method for specifying when the conference
> > > ends, with
> > > > choices for at least: "end when last person leaves", "end
> > > when convener
> > > > leaves"
> > > > and "end when stop time is reached".  It is not be a
> > > requirement that
> > > > all CPCP servers implement all such options.
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> > > >> Sent: Thursday, February 05, 2004 5:45 AM
> > > >> To: Keith Lantz; Drage, Keith (Keith)
> > > >> Cc: xcon@ietf.org; Dave Bieselin
> > > >> Subject: RE: [XCON] CPCP Requirement: Repeat times
> > > >>
> > > >>
> > > >> I would not like to tie behaviour of any particular systems
> > > >> to their being enterprise or public network in the current
> > > >> day - I was highlighting a historical divergence and pointing
> > > >> out that both requirements will still exist.
> > > >>
> > > >> One further reason for a system that closes down the bridge
> > > >> when the conference originator/owner leaves, some companies
> > > >> require this as a security measure for their internal audio
> > > >> conference services.
> > > >>
> > > >> regards
> > > >>
> > > >> Keith
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Keith Lantz [mailto:klantz@cisco.com]
> > > >>> Sent: 04 February 2004 18:01
> > > >>> To: Drage, Keith (Keith)
> > > >>> Cc: xcon@ietf.org; Dave Bieselin
> > > >>> Subject: RE: [XCON] CPCP Requirement: Repeat times
> > > >>>
> > > >>>
> > > >>> Indeed, what happens when the conference creator/owner leaves
> > > >>> a conference
> > > >>> and whether or not to tear down the conference at a
> > > >>> particular stop time
> > > >>> are independent issues. For example, the typical use of
> > > >>> MeetingPlace at
> > > >>> Cisco is not to care in the least when the creator/owner
> > > >>> leaves, and the
> > > >>> conference will end when the designated stop time is reached
> > > >>> (or everyone
> > > >>> has left). And some users here definitely would not be happy
> > > >>> if they were
> > > >>> cross-charged for a conference call that continued, say,
> > > >> with "random
> > > >>> chatter" long past the stop time they had designated.
> > > >>>
> > > >>> Separately, the distinction drawn below between enterprise
> > > >>> and service
> > > >>> provider usage seems to be based on the assumption that
> > > >>> enterprises don't
> > > >>> allocate charges for conferences so don't care if a
> > > >>> conference continues
> > > >>> after the stop time. You may not, in fact, being saying that.
> > > >>> But in case
> > > >>> others are making that assumption: Don't; it simply isn't true.
> > > >>>
> > > >>> Regards, (A different) Keith
> > > >>>
> > > >>> At 03:22 AM 2/4/2004, Drage, Keith (Keith) wrote:
> > > >>>> This distinction of what happens when the conference creator
> > > >>> leaves is the
> > > >>>> current distinction between existing enterprise network and
> > > >>> public network
> > > >>>> usage of add-on conference service outside of SIP.
> > > >>>>
> > > >>>> In enterprise networks, the conference continues after the
> > > >>> creator leaves,
> > > >>>> possibly effecting a transfer if down to two parties.
> > > >>>>
> > > >>>> In the public network, the conference creator is generally
> > > >>> the conference
> > > >>>> owner and paying for the conference bridge, and some or
> > > all of the
> > > >>>> connection resources to that bridge. As the conference owner
> > > >>> would have no
> > > >>>> control of the cost after he leaves the conference the
> > > >>> conference would
> > > >>>> terminate when the conference owner leaves.
> > > >>>>
> > > >>>> If the conference owner/creator has a means of transferring
> > > >>> the ownership,
> > > >>>> and therefore the charges, or if the conference owner can
> > > >>> still supervise
> > > >>>> the charges after he ceases to be a participant, then
> > > there is not
> > > >>>> necessarily a need to clear such a conference when the
> > > >>> creator leaves.
> > > >>>>
> > > >>>> regards
> > > >>>>
> > > >>>> Keith
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: hisham.khartabil@nokia.com
> > > >>> [mailto:hisham.khartabil@nokia.com]
> > > >>>>> Sent: 04 February 2004 09:32
> > > >>>>> To: petri.koskelainen@nokia.com; Brian.Rosen@marconi.com;
> > > >>>>> fluffy@cisco.com; xcon@ietf.org
> > > >>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
> > > >>>>>
> > > >>>>>
> > > >>>>> Brian is suggesting that stop-time means that the conference
> > > >>>>> creator will leave the conference at that time. At least this
> > > >>>>> is how I understood it.
> > > >>>>>
> > > >>>>> This leaves the rest of the participants hanging around still
> > > >>>>> in the conference. I also ok with stop-time meaning all
> > > >>>>> participants will get a BYE.
> > > >>>>>
> > > >>>>> /Hisham
> > > >>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: Koskelainen Petri (Nokia-NRC/Tampere)
> > > >>>>>> Sent: 04.February.2004 11:16
> > > >>>>>> To: Khartabil Hisham (Nokia-TP/Helsinki);
> > > >>> Brian.Rosen@marconi.com;
> > > >>>>>> fluffy@cisco.com; xcon@ietf.org
> > > >>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> So what you're saying here is that a conference will only
> > > >>>>>>> terminate when the last participant leaves? I think I'm ok
> > > >>>>>> with that.
> > > >>>>>>
> > > >>>>>> Actually, I don't think that was the idea. Besides, I'd not
> > > >>>>> be happy
> > > >>>>>> if I create (and pay) the conference (start time 2pm, and
> > > >>>>>> stop time 3pm),
> > > >>>>>> and other people stay there for days.
> > > >>>>>>
> > > >>>>>> I think it is better to stop the conference as defined by the
> > > >>>>>> stop time.
> > > >>>>>> Some vendors may add polite warning 10 min before the stop
> > > >>>>>> time ("this conference will end soon..")
> > > >>>>>> or if you have credit left it may be automatically extended
> > > >>>>>> for some reasonable time if
> > > >>>>>> there are resources and people hanging on (especially
> > > >>> the creator).
> > > >>>>>> No guarantees though, it is just best effort as Roni said.
> > > >>>>>>
> > > >>>>>> Anyway, we are now talking about solutions, not requirements.
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Petri
> > > >>>>>>
> > > >>>>>>> -----Original Message-----
> > > >>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On
> > > >>>>>> Behalf Of ext
> > > >>>>>>> hisham.khartabil@nokia.com
> > > >>>>>>> Sent: 04 February, 2004 10:56
> > > >>>>>>> To: Brian.Rosen@marconi.com; fluffy@cisco.com; xcon@ietf.org
> > > >>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> -----Original Message-----
> > > >>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On
> > > >>>>>>> Behalf Of ext
> > > >>>>>>>> Rosen, Brian
> > > >>>>>>>> Sent: 03.February.2004 20:37
> > > >>>>>>>> To: 'Cullen Jennings'; XCON-IETF
> > > >>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Conventional conference bridges use a start time.
> > > >>> Its the time
> > > >>>>>>>> that the mixing starts.  Most will let you connect
> > > >>>>> shortly before
> > > >>>>>>>> start time, but would give you "music on hold" or some
> > > >>>>> equivalent.
> > > >>>>>>>> Dial out would often be related to this (dial out
> > > >>>>> shortly before).
> > > >>>>>>>>
> > > >>>>>>>> I think we can live with that definition.
> > > >>>>>>>>
> > > >>>>>>>> Stop time, like it or not for most bridges I know is
> > > >>>>> expected stop
> > > >>>>>>>> time of the person scheduling the conference.
> > > >>>>>>>
> > > >>>>>>> So what you're saying here is that a conference will only
> > > >>>>>>> terminate when the last participant leaves? I think I'm ok
> > > >>>>>> with that.
> > > >>>>>>>
> > > >>>>>>> /Hisham
> > > >>>>>>>
> > > >>>>>>>> I've never encountered
> > > >>>>>>>> a public bridge that actually tore down the connection,
> > > >>>>>> although I
> > > >>>>>>>> know of at least one enterprise class bridge that
> > > >> does this
> > > >>>>>>>> (and we HATED it).
> > > >>>>>>>>
> > > >>>>>>>> I know I was assuming GMT.
> > > >>>>>>>>
> > > >>>>>>>> Brian
> > > >>>>>>>
> > > >>>>>>> _______________________________________________
> > > >>>>>>> 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
> > > >>>
> > > >>> ----------------
> > > >>> Keith Lantz, Ph.D.                        Voice: (408) 902-3302
> > > >>> Cisco Distinguished Engineer              FAX:   (408) 902-3518
> > > >>> Voice & Video Systems Architecture        Email:
> > klantz@cisco.com
> > > >>> Voice (& Video) Technology Group
> > > >>> Cisco Systems, Inc.
> > > >>>
> > > >>
> > > >> _______________________________________________
> > > >> 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
> >
>
> _______________________________________________
> 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