RE: [XCON] CPCP Requirement: Repeat times
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
