RE: [XCON] CPCP Requirement: Repeat times

["Even, Roni" <roni.even at polycom.co.il>]

 Hi,
I think we need to define what is the basic functionality and what we leave
to an application server that offers conference services. I do not think
that CPCP should address it but should supply the right tools. My claim as
that ad-hoc was enough but since some people want more then a decision needs
to be taken here. One of the issue of having a simple CPCP is to enable n
application server or a user client to be able to work consistently with a
conference server from any vendor.
Roni Even

-----Original Message-----
From: Cullen Jennings
To: Brian Rosen; 'Drage, Keith (Keith)'; Keith A Lantz
Cc: XCON-IETF; Dave Bieselin
Sent: 06/02/2004 09:58
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