RE: [XCON] CPCP Requirement: Repeat times

["Drage, Keith (Keith)" <drage at lucent.com>]

I support Brian on this one.

If we have a requirement that means a car needs windows, and a second requirement that means a car needs doors, we don't try and rewrite the requirement such that the car only needs windows, because people can climb out of the windows.

Lets write the requirements so we know what we are trying to solve.

regards

Keith

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: 06 February 2004 14:09
> To: 'petri.koskelainen@nokia.com'; fluffy@cisco.com; drage@lucent.com;
> klantz@cisco.com
> Cc: xcon@ietf.org; dbieseli@cisco.com
> Subject: RE: [XCON] CPCP Requirement: Repeat times 
> 
> 
> This seems way too twisted to me.   
> 
> Yes, you can force fit start/stop the way you propose, but it doesn't
> match most people's view of how things ought to work.
> 
> I'd prefer an enumeration on what stop means.
> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: petri.koskelainen@nokia.com 
> [mailto:petri.koskelainen@nokia.com]
> > Sent: Friday, February 06, 2004 8:56 AM
> > To: Brian.Rosen@marconi.com; fluffy@cisco.com; drage@lucent.com;
> > klantz@cisco.com
> > Cc: xcon@ietf.org; dbieseli@cisco.com
> > Subject: RE: [XCON] CPCP Requirement: Repeat times 
> > 
> > 
> > 
> > > 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.  
> > 
> > You can implement this feature via CPCP by setting the start time
> > just before you join.
> > 
> > > If he arrives, and then leaves, the conference is over.
> > 
> > So it is impossible for a convener to hang up and re-join as 
> > the conference
> > has been ended already ? 
> > 
> > With start/stop times you can implement this kind of service 
> > (I mean if you really want this)
> > or you may create similar service with more features.
> > Convener can use CPCP and modify start/stop times as needed 
> > (thus creating 
> > the service you described).
> >  
> > > 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.
> > 
> > Hmm..If bridge does not have to obey CPCP it can do 
> whatever it likes.
> > The purpose of CPCP is to give the convener the power to 
> > define the 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?
> > 
> > It ends when stop time is reached or when convener ends it via CPCP.
> > 
> > > How does any participant know?
> > 
> > Conference policy describes stop time. This also allows 
> > people hanging up for a while
> > and rejoining (e.g. via different terminal). This would not 
> > be possible
> > otherwise.
> > 
> > > Also, Petri, you can't implement a "Meet Me" with start/stop. 
> > 
> > Yes I can. Convener can use CPCP and set start_time=NOW and 
> > join the conference.
> > When convener leaves the conference he can set stop_time=NOW. 
> > 
> > 
> > > 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.
> > 
> > Yes, but this can be achieved via CPCP.
> > 
> > 
> > Petri
> > 
> > > 
> > > 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