RE: [XCON] CPCP Requirement: Repeat times

["Rosen, Brian" <Brian.Rosen at marconi.com>]

I don't understand what you are talking about.

End when last person leaves is the way many bridges work.  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.

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

We have to be explicit.

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 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.  They start whenever the convener arrives, end
when he leaves (usually), but restart when he arrives again with out regard
to start and stop.

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