Subject: Re: [XCON] CPCP Requirement: Repeat times

From: Cullen Jennings <[email-masked]>
Date: Tue, 03 Feb 2004 09:08:01 -0800

Start time I can understand but it is seems more complex that you are making
it sound. Is it the time the focus URL becomes valid? Is it the time that if
before this you tired to connect you would get rejected? Is it the time that
mixing of the media starts? is it the time that normal participants gets
dialed on a dial out? Is it the time the moderator get dialed?

Theses are all separate times and reducing them to a single "start time"
won't work. 

Stop time is even worse. Is it when the the human who set this up expects it
to end? Is the absolute max time after which all session will be torn down?
Is the time that resources are reserved for? (I hope not) I think someone
needs to say what stop time is before we decide if it is CPCP or not.

I'm assuming that people are thinking that all times will be in GMT or
relative offsets from some GMT time. If folks see a need for local times,
lets get that discussion going.

I have a long rant why I hate Repeat times but sounds like I don't need to
send that :-) 

On 1/30/04 11:02 AM, "Nermeen Ismail" <[email-masked]> wrote:

> At 10:48 AM 1/29/2004 -0500, Rosen, Brian wrote:
>> Do we all agree that the start time can be in the future, and that
>> constitutes a (simple) reservation?
>> 
>> I am also okay with no repeats.
>> 
>> Brian
> 
> If start time can not be in the future then there is no reason for it. I am
> OK with having a start time.
> 
> nermeen
> 
> 
> 
>>> -----Original Message-----
>>> From: Eric Burger [mailto:[email-masked]]
>>> Sent: Thursday, January 29, 2004 10:42 AM
>>> To: [email-masked]; [email-masked]
>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>> 
>>> 
>>> Exactly.  The idea "we'll start small and extend later" on
>>> the reservation / scheduling function is how we will end up
>>> re-inventing iCal, only this time with people with less
>>> expertise in the area...
>>> 
>>> I think all we need is start time & end time.  Period.
>>> 
>>>> -----Original Message-----
>>>> From: Boyer, David G (Dave) [mailto:[email-masked]]
>>>> Sent: Wednesday, January 28, 2004 9:39 AM
>>>> To: [email-masked]; Eric Burger; [email-masked]
>>>> Cc: [email-masked]
>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>> 
>>>> 
>>>> If a conference focus is created at conference start time by
>>>> a conference factory, the focus will only need to know it's
>>>> end time in order to prevent any users from joining.
>>>> Repeat times and more complex reservations can be handled by
>>>> an "external" reservation
>>>> application.
>>>> 
>>>> Dave Boyer
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>>> [email-masked]
>>>> Sent: Wednesday, January 28, 2004 6:50 AM
>>>> To: [email-masked]; [email-masked]
>>>> Cc: [email-masked]
>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>> 
>>>> 
>>>> Let me elaborate a little on this proposal.
>>>> 
>>>> I agree that eventually we need complex scheduling for
>>>> conferences. We can pick this up after we finalise a solution
>>>> for CPCP. In can be decided at that point if this scheduling
>>>> could be done inside CPCP as an extension (similar approach
>>>> to CPL) or is a separate protocol.
>>>> 
>>>> In the mean time, we can define a very simple start, stop and
>>>> repeat times that is OPTIONAL TO IMPLEMENT at the client
>>>> side. The purpose of those would not be to indicate the need
>>>> for resource reservation, although they can be used for that.
>>>> 
>>>> Start time indicates to the focus when it should start
>>>> allowing users to join or when it should invite users to join.
>>>> Stop time indicates to the focus when it should stop allowing
>>>> users to join. It also indicates that the focus should not
>>>> invite users that have been added to dial-out list.
>>>> Repeat times is obvious.
>>>> 
>>>> Again, this would be optional and can be deprecated by a more
>>>> complex scheduling solution.
>>>> 
>>>> Regards,
>>>> Hisham
>>>> 
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]]On
>>>> Behalf Of ext
>>>>> [email-masked]
>>>>> Sent: 28.January.2004 09:30
>>>>> To: [email-masked]; [email-masked]
>>>>> Cc: [email-masked]
>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>> 
>>>>> 
>>>>> I'm sorry, but I don't buy the argument that just because
>>>>> scheduling is complex it requires a separate protocol.
>>>>> Henning did mention how they approached the problem for CPL.
>>>>> We can adopt that here also.
>>>>> 
>>>>> If we don't want a full scheduling solution yet, then we
>>>>> start with something basic and design the protocol in a way
>>>>> that allows complex scheduling to be added later.
>>>>> 
>>>>> /Hisham
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]]On
>>>>> Behalf Of ext
>>>>>> Eric Burger
>>>>>> Sent: 26.January.2004 21:23
>>>>>> To: [email-masked]
>>>>>> Cc: Even, Roni
>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>> 
>>>>>> 
>>>>>> I started to say that it was totally out of scope.  Here are
>>>>>> both sides of the coin:
>>>>>> 
>>>>>> AGAINST *ANY* SCHEDULING IN CPCP:
>>>>>> Scheduling logic is arbitrarily complex.  Scheduling
>>>>>> semantics are arbitrarily complex, and have been tackled in
>>>>>> other venues much better than we every will (e.g., iCal).
>>>>>> What more does CPCP need other than "Create conference NOW"
>>>>>> and "Remove conference NOW"?
>>>>>> 
>>>>>> FOR *SOME* SCHEDULING IN CPCP:
>>>>>> Resource management should be at the focus, not at the
>>>>>> application.  This would lead to "Reserve resources for a
>>>>>> conference starting LATER" (could succeed or fail).
>>>>>> 
>>>>>> I *might* understand "Reserve resources for a conference that
>>>>>> repeats every {time unit}".
>>>>>> 
>>>>>> I would NOT approve "Reserve resources for a conference that
>>>>>> repeats every week except for the week after next."  Limit
>>>>>> ourselves to "Reserve resources for a conference this week
>>>>>> and next.  +  Reserve resources for a conference starting
>>>>>> three weeks from now."
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Even, Roni [mailto:[email-masked]]
>>>>>>> Sent: Sunday, January 25, 2004 8:44 AM
>>>>>>> To: [email-masked]'; [email-masked]
>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>> 
>>>>>>> 
>>>>>>> Hi,
>>>>>>> Repeating myself I would like to state my objection, and I
>>>>>>> would suggest to
>>>>>>> have conference reservation functionality not in the scope of
>>>>>>> conference
>>>>>>> policy but maybe as an application functionality that we may
>>>>>>> consider as a
>>>>>>> different working item.
>>>>>>> Roni
>>>>>>> 
>>>>>>> *************************************
>>>>>>> Roni Even
>>>>>>> 
>>>>>>> Polycom Israel
>>>>>>> 
>>>>>>> Tel: +972-3-9251200
>>>>>>> Cell: +972-55-481099
>>>>>>> email:[email-masked]
>>>>>>> *******************************************
>>>>>>> 
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked]
>>>>>> [mailto:[email-masked]]
>>>>>>> Sent: Sunday, January 25, 2004 3:31 PM
>>>>>>> To: [email-masked]
>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Back to the original question in this thread:
>>>>>>> 
>>>>>>>>>>>> Do we see a need for such capability using CPCP?
>>>>>>>>>>>> If so, then we need to add a requirement.
>>>>>>> 
>>>>>>> I guess we can close this open issue now as rough consensus
>>>>>> seems to
>>>>>>> be that such a requirement is needed (at least for the
>>>>>>> start/stop/repeat
>>>>>>> times).
>>>>>>> Note that we don't have to design the actual solution yet
>>>>>>> (e.g. using iCal vs defining own format).
>>>>>>> 
>>>>>>> --
>>>>>>> Petri
>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: ext Rosen, Brian [mailto:[email-masked]]
>>>>>>>>> Sent: 21.January.2004 16:09
>>>>>>>>> To: Khartabil Hisham (Nokia-TP/Helsinki)
>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I think we need to figure out where we are going on
>>>>> scheduling.
>>>>>>>>> 
>>>>>>>>> First, let me say that I think we SHOULD allow CPCP to at
>>>>>>>>> least specify start/stop times for conferences,
>>> and that if
>>>>>>>>> the start time is in the future, that is a reservation.
>>>>>>>> 
>>>>>>>> Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> What I want to discuss is, how far do we go, and what is
>>>>>>>> the end game?
>>>>>>>>> I think we can agree that generalized scheduling is
>>>> complex,
>>>>>>>>> and standards exist (iCal).  So, the issue I want to
>>>>> discuss is:
>>>>>>>>>   if we allow simple scheduling (start/stop) now,
>>>>>> do we EVENTUALLY
>>>>>>>>>           allow complex scheduling?  That implies
>>>>>> duplicating
>>>>>>> significant
>>>>>>>>>           parts of e.g. iCal.
>>>>>>>>> 
>>>>>>>>> We could consider an alternative - explicitly
>>>> support an iCal
>>>>>>>>> (actually iMIP) transaction now.
>>>>>>>>> 
>>>>>>>>> One could allow the iMIP Request/Reply only (ie subset of
>>>>>>>>> iMIP) now (or maybe as a minimum).
>>>>>>>>> 
>>>>>>>>> Or we could pull in some or all of calsch
>>>>>>>> 
>>>>>>>> If there is an XML schema already defined that we can use,
>>>>>>> then it is
>>>>>>>> possible to embed that in CPCP. If you look at the solution
>>>>>>>> we are proposing (using XCAP), each feature, like
>>>>>>> conference-time, has its
>>>>>>> own
>>>>>>>> XML namespace.
>>>>>>>> We can take the iCal XML namespace and just drop it
>>> in there.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Hisham
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Brian
>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked]
>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>> Sent: Wednesday, January 21, 2004 8:10 AM
>>>>>>>>>> To: [email-masked]; [email-masked];
>>>>>>>>>> [email-masked]; [email-masked]
>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Yes.
>>>>>>>>>> 
>>>>>>>>>> We all have weekly meetings with predefined start
>>>> and stop
>>>>>>>>>> times. I think it is a valid use case for a user to
>>>>> create a
>>>>>>>>>> conference policy to satisfy this once and once only.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Hisham
>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: ext Eric Burger [mailto:[email-masked]]
>>>>>>>>>>> Sent: 20.January.2004 18:01
>>>>>>>>>>> To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki);
>>>>>>>>>>> Koskelainen Petri
>>>>>>>>>>> (Nokia-NRC/Tampere); [email-masked]
>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> For that matter, is there a use case for end
>>>>> points (XCON)
>>>>>>>>>>> doing such complicated scheduling?  Why don't we
>>>>> just take
>>>>>>>>>>> the bridge out of service?
>>>>>>>>>>> 
>>>>>>>>>>> Wow!  Agreeing with Roni twice in one day!!!
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Even, Roni [mailto:[email-masked]]
>>>>>>>>>>>> Sent: Wednesday, January 07, 2004 4:56 AM
>>>>>>>>>>>> To: [email-masked]'; Even, Roni;
>>>>>>>>>>>> [email-masked]; [email-masked]
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Hisham,
>>>>>>>>>>>> 
>>>>>>>>>>>> The conference server is not mentioned in
>>>>>>>>>>>> draft-ietf-sipping-conferencing-framework-01. The
>>>>>> framework
>>>>>>>>>>>> mentioned the
>>>>>>>>>>>> conference policy server. As for reservation my
>>>>>>> view is that
>>>>>>>>>>>> reservation is
>>>>>>>>>>>> starting an ad-hoc conference when the schedule
>>>>> time has
>>>>>>>>>>>> arrived and it
>>>>>>>>>>>> should not be part of the conference policy.
>>>>>> Reservation is
>>>>>>>>>>> a separate
>>>>>>>>>>>> application from the conference policy. I
>>>>> suggest that if
>>>>>>>>>>> you want to
>>>>>>>>>>>> address it then we should have a separate
>>>>> element in the
>>>>>>>>>>>> frame work which
>>>>>>>>>>>> will be a reservation server.
>>>>>>>>>>>> 
>>>>>>>>>>>> Roni
>>>>>>>>>>>> 
>>>>>>>>>>>> *************************************
>>>>>>>>>>>> Roni Even
>>>>>>>>>>>> 
>>>>>>>>>>>> Polycom Israel
>>>>>>>>>>>> 
>>>>>>>>>>>> Tel: +972-3-9251200
>>>>>>>>>>>> Cell: +972-55-481099
>>>>>>>>>>>> email:[email-masked]
>>>>>>>>>>>> *******************************************
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: [email-masked]
>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>> Sent: Wednesday, January 07, 2004 11:22 AM
>>>>>>>>>>>> To: [email-masked];
>>>>> [email-masked];
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> No, the focus host (conference server) is the
>>>> one that
>>>>>>>>> handles the
>>>>>>>>>>>> reservations. The focus is only created and
>>>>>>> destroyed by the
>>>>>>>>>>>> conference
>>>>>>>>>>>> server according to the start and stop times.
>>>>>>>>>>>> 
>>>>>>>>>>>> /Hisham
>>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: ext Even, Roni
>>>> [mailto:[email-masked]]
>>>>>>>>>>>> Sent: 06.January.2004 19:06
>>>>>>>>>>>> To: Koskelainen Petri (Nokia-NRC/Tampere);
>>>>> Even, Roni;
>>>>>>>>>>>> Khartabil Hisham
>>>>>>>>>>>> (Nokia-TP/Helsinki); [email-masked] '
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement:
>>> Repeat times
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Petri,
>>>>>>>>>>>> The CPS is a data storage that is used by the
>>>>>>> focus, so the
>>>>>>>>>>>> focus will have
>>>>>>>>>>>> to handle the reservation
>>>>>>>>>>>> Roni
>>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: [email-masked]
>>>>>>>>>>>> To: [email-masked];
>>>>>> [email-masked];
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> Sent: 06/01/2004 18:50
>>>>>>>>>>>> Subject: RE: [XCON] CPCP Requirement:
>>> Repeat times
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Roni,
>>>>>>>>>>>> 
>>>>>>>>>>>> My opinion is that the conference policy
>>>>> needs only a
>>>>>>>>>>>> conference duration parameter if any.
>>>>>>>>>>>> I think that reservation is an external
>>>>>>>>>>>> application to the focus. According to the
>>>>> conference
>>>>>>>>>>>> framework the focus is using the
>>>> information in the
>>>>>>>>>>>> conference policy server and the focus is
>>>>>>>>>>>> not the right place for reservation.
>>>>>>>>>>>> 
>>>>>>>>>>>> The reservation is sent to CPS, not to focus.
>>>>>>>>>>>> I think it makes sense to have this (repeat time)
>>>>>>>> capability in protocol since we need the feature anyway in
>>>>>>> real-world
>>>>>>>> (either in CPCP or in some new mystery protocol between the
>>>>>>> user and the
>>>>>>>>>>> reservation application).
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Petri
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Roni Even
>>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: [email-masked]
>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>> Sent: Monday, December 15, 2003 4:57 PM
>>>>>>>>>>>> To: [email-masked]
>>>>>>>>>>>> Subject: [XCON] CPCP Requirement: Repeat times
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> A conference has start and stop times.
>>> Although the
>>>>>>>>>>> current proposed solution has repeat times (eg:
>>>>>>> meeting repeats
>>>>>>> weekly),
>>>>>>>>>>> there is no requirement for such.
>>>>>>>>>>>> 
>>>>>>>>>>>> Do we see a need for such capability
>>> using CPCP? If
>>>>>>>> so, then we need to add a requirement.
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> XCON mailing list
>>>>>>> [email-masked]
>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> XCON mailing list
>>>>>>> [email-masked]
>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> XCON mailing list
>>>>>> [email-masked]
>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> XCON mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> XCON mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> XCON mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/xcon
>>> 
>> 
>> _______________________________________________
>> XCON mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 4 Feb 2004 09:22:08 +0200

Brian,
About tearing down of conferences it is not that simple. If you reserved a
conference for two hours then the conference is for two hours. extension may
be bases on service type, left credit and resource availability due to
previous reservation. I would say that unlike the reservation time which is
supposed to be guaranteed, conference extension is based on best effort.
Again I will state that the policy is up to the service provider and not on
the bridge manufacturer that should allow all. This is another reason for
having conference times as application functionality
Roni 

Polycom Israel

Tel: +972-3-9251200
Cell: +972-55-481099

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, February 03, 2004 8:37 PM
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.  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

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2004 12:08 PM
> To: XCON-IETF
> Subject: Re: [XCON] CPCP Requirement: Repeat times 
> 
> 
> 
> Behalf Of

---

From: [email-masked]
Date: Wed, 4 Feb 2004 10:55:42 +0200

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Rosen, Brian
> Sent: 03.February.2004 20:37
> 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

---

From: [email-masked]
Date: Wed, 4 Feb 2004 11:15:34 +0200

> 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

> Sent: 04 February, 2004 10:56
> To: [email-masked]; [email-masked]; [email-masked]
> 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

---

From: [email-masked]
Date: Wed, 4 Feb 2004 11:31:31 +0200

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

> From: Koskelainen Petri (Nokia-NRC/Tampere) 
> Sent: 04.February.2004 11:16
> To: Khartabil Hisham (Nokia-TP/Helsinki); [email-masked];
> [email-masked]; [email-masked]

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Feb 2004 11:22:22 -0000

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: 04 February 2004 09:32
> To: [email-masked]; [email-masked];
> 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
>

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 4 Feb 2004 11:32:18 -0000

So is this a matter for local policy????  A conference might end when
the stop time is reached and may be linked to the owner of the
conference BUT specifying any further action is beyond scope.

Chris.

>From: Drage, Keith (Keith) [mailto:[email-masked]]
>Sent: 04 February 2004 11:22
>To: [email-masked]
>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
>

This message has been scanned for viruses by MailControl - www.mailcontrol.com

---

From: [email-masked]
Date: Wed, 4 Feb 2004 14:02:42 +0200

I'm contradicting myself here, but thinking about it more, I think it is better than a conference terminates with stop-time. The creator is free to set the stop-time to be the time he leaves (and therefore the conference terminates when he leaves), terminate the conference as he leaves, or leave before the stop-time and therefore the conference continues.

/Hisham

> Drage, Keith (Keith)
> Sent: 04.February.2004 13:22
> To: [email-masked]
> 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
>

---

From: [email-masked]
Date: Wed, 4 Feb 2004 14:13:22 +0200

crucial spelling mistake corrected :) Sorry about that.

> Sent: 04.February.2004 14:03
> To: [email-masked]; [email-masked]
> I'm contradicting myself here, but thinking about it more, I 
> think it is better that a conference terminates with 
                      ^^^^
> stop-time. The creator is free to set the stop-time to be the 
> time he leaves (and therefore the conference terminates when 
> he leaves), terminate the conference as he leaves, or leave 
> before the stop-time and therefore the conference continues.
> 
> /Hisham
>

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 4 Feb 2004 14:37:11 +0200

Hisham,
I assume that you also want to allow the stop time to be changed by the
conference creator, during the conference, to allow extension of the
conference based on best effort
Roni

VP Product Planning
Polycom Israel

Tel: +972-3-9251200
Cell: +972-55-481099

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 04, 2004 2:03 PM
To: [email-masked]; [email-masked]
Subject: RE: [XCON] CPCP Requirement: Repeat times 

I'm contradicting myself here, but thinking about it more, I think it is
better than a conference terminates with stop-time. The creator is free to
set the stop-time to be the time he leaves (and therefore the conference
terminates when he leaves), terminate the conference as he leaves, or leave
before the stop-time and therefore the conference continues.

/Hisham

---

From: [email-masked]
Date: Wed, 4 Feb 2004 14:40:05 +0200

Yes.

> From: ext Even, Roni [mailto:[email-masked]]
> Sent: 04.February.2004 14:37
> To: Khartabil Hisham (Nokia-TP/Helsinki); [email-masked];
> [email-masked]
> think it is

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 4 Feb 2004 07:48:41 -0500

Keith had it closest to current reality.  Maybe we need an enumeration on
how conferences end (last person leaves, creator leaves, stop time arrives).
I fear that picking one won't work for enough circumstances.

My definition for stop time was "expected end time, with no guarantee of
resource availability beyond it".

Brian

> Sent: Wednesday, February 04, 2004 7:40 AM
> To: [email-masked]; [email-masked]; [email-masked]

---

From: Keith Lantz <[email-masked]>
Date: Wed, 04 Feb 2004 10:01:19 -0800

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 
>In enterprise networks, the conference continues after the creator leaves, 
>In the public network, the conference creator is generally the conference 
>connection resources to that bridge. As the conference owner would have no 
>If the conference owner/creator has a means of transferring the ownership, 
>and therefore the charges, or if the conference owner can still supervise 

----------------
Keith Lantz, Ph.D.                        Voice: (408) 902-3302
Cisco Distinguished Engineer              FAX:   (408) 902-3518
Voice & Video Systems Architecture        Email: [email-masked]
Voice (& Video) Technology Group
Cisco Systems, Inc.

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Feb 2004 10:44:36 -0000

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

> From: Keith Lantz [mailto:[email-masked]]
> Sent: 04 February 2004 18:01
> To: Drage, Keith (Keith)
> Cc: [email-masked]; Dave Bieselin
> leaves is the 
> creator leaves, 
> the conference 
> the ownership,

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 5 Feb 2004 14:09:43 -0000

Sounds alright to me - or even something like:-

There shall be a method for specifying when the conference ends.  This
'end-time' merely acts as an indication to conf servers which should
then decide on conference termination based on local policy.

Chris.

>Sent: 05 February 2004 14:02
>To: 'Drage, Keith (Keith)'; Keith Lantz
>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.
>
>
>
>> Sent: Thursday, February 05, 2004 5:45 AM
>> To: Keith Lantz; Drage, Keith (Keith)
>> 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
>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 5 Feb 2004 09:16:25 -0500

I can live with it, but the problem with this kind of thing is that you
can't build a CPCP client that works with all CPCP servers if you don't
know what knobs you have.  When you say "local policy" you imply either
that there is no control, or the control is proprietary.

Brian

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Thursday, February 05, 2004 9:10 AM
> To: Rosen, Brian; Drage, Keith (Keith); Keith Lantz
> >> > > > > > terminate when the last participant leaves? I 
> think I'm ok
> >> > > > > with that.
> >> > > > >
> >> > > > > I think it is better to stop the conference as 
> defined by the
> >> > > > > stop time.
> >> > > > > > terminate when the last participant leaves? I 
> think I'm ok
> >> > > > > with that.
> >> > > > > >
> >> > > > > > /Hisham
> >> > > > > >
> >> > > > > > > I've never encountered

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 5 Feb 2004 16:19:15 +0200

Brian,

When is the stop time get set, before the conference? can you change it once
the conference has started or after an event announcing that the conference
will end soon.

Since this is a way to extend then a choice of "allowed to change stop time
after conference started" may also be needed. 

About your choices I assume that logical operators between them are allowed.
e.g "end when convener leaves" OR "end when stop time is reached"

Roni Even

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 5 Feb 2004 16:24:56 +0200

Will a service provider have one CPCP server. If not then there is problem
with a consistent service if policy for stop time can not be fully
provisioned, that is one of the reasons I saw conference time as an
application server issue and not a CPCP issue.
Roni

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, February 05, 2004 4:16 PM
To: 'Chris Boulton'; Drage, Keith (Keith); Keith Lantz
Cc: [email-masked]; Dave Bieselin
Subject: RE: [XCON] CPCP Requirement: Repeat times 

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 5 Feb 2004 10:26:01 -0500

I think the protocol should let you change it at any time.
I think a particular implementation might have policy issues
(for example, it may not be able to reserve the resources), so
the attempt may fail.

I don't see why you need an explicit choice or "allowed to extend".
The choice you would select is "end at stop time", and you can
change stop time (policy permitting).

Brian

> Sent: Thursday, February 05, 2004 9:19 AM
> To: 'Rosen, Brian'; 'Drage, Keith (Keith)'
> Cc: [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 5 Feb 2004 10:29:19 -0500

This is always an issue with things left to local policy,
and that is one reason why people often standardize on one vendor.
I'm very big on interoperability.  I tend to want to specify things,
and NOT leave them up to local policy, but that's primarily because
I want both end to interwork.  Having two servers look alike is
another benefit of more tight specification.

Brian

> Sent: Thursday, February 05, 2004 9:25 AM
> To: 'Rosen, Brian'; 'Chris Boulton'; Drage, Keith (Keith); Keith Lantz
> > >> > > > > Actually, I don't think that was the idea. 
> Besides, I'd not
> > >> > > > be happy
> > >> > > > > 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
> > >> > > > > > > start time, but would give you "music on 
> hold" or some
> > >> > > > equivalent.
> > >> > > > > > > a public bridge that actually tore down the 
> connection,
> > >> > > > > although I

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 5 Feb 2004 15:38:56 -0000

Agreed.

>Sent: 05 February 2004 15:26
>To: 'Even, Roni'; 'Drage, Keith (Keith)'
>Cc: [email-masked]
>> > > > > > > terminate when the last participant leaves? I think I'm
ok
>> > > > > > > terminate when the last participant leaves? I think I'm
ok

---

From: Keith Lantz <[email-masked]>
Date: Thu, 05 Feb 2004 08:42:01 -0800

I agree.

---

From: "Bieselin, David" <[email-masked]>
Date: Thu, 5 Feb 2004 05:53:03 -0800

On stopping of conferences:  I believe that the end time (or stop time
as it is referred to here) is the scheduler's best attempt of saying how
long a meeting will be.  If the meeting is still going and there are
people still in the meeting, there is no reason why the system cannot
grant the meeting more time.  This should be configurable by conference
policy, perhaps by scheduler to say, whether or not they can have more
time, and if so how much.

On reservationless meetings as Keith suggested, when the scheduler of
the meeting leaves, the question of whether or not to tear down the
conference is a 2nd issue and should also make it into the policy.  On a
system by system basis, even down to the scheduler, some meetings are
allowed to continue and some not.

A variant on this is when you instruct the conference to call out to
auto answering devices.   We have seen requirements similar to the above
on when to tear down this call leg.

Dave

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, February 05, 2004 2:45 AM
To: Lantz, Keith; Drage, Keith (Keith)
Cc: [email-masked]; Bieselin, David
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

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

> 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
> > > 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
> > >
> > > > if I create (and pay) the conference (start time 2pm, and stop 
> > > > time 3pm), and other people stay there for days.
> > > >
> > > > 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

---

From: [email-masked]
Date: Thu, 5 Feb 2004 21:04:26 +0200

If it is a scenario where the conference must terminate when the creator leaves, the creator can set the stop-time to be the time he is leaving. If he does not know when exactly he will leave, then he can simply remove the conference as he leaves (by removing policy, updating the stop-time to the current time, put the stop time in the past even).

/Hisham

> Bieselin, David
> Sent: 05.February.2004 15:53
> To: Drage, Keith (Keith); Lantz, Keith
> Cc: [email-masked]

---

From: "Bieselin, David" <[email-masked]>
Date: Thu, 5 Feb 2004 12:19:00 -0800

I have to disagree .. How many of you leave the conference room you
reserved just because the end time came?  Why would you?   If you are
having a useful meeting (do not laugh) then you should be allowed to
continue should there be no reservations behind you.  

If you forced people to manually do this you would have to stop the
meeting and say, "Hold it Jim, we need to extend this room for time is
running out!".  You want that to happen based on the policy of the
conference service.  Therefore one room can be set up for allow meeting
to continue for as long as the people are in there and productive and
the next for only the time allotted.  On the other hand, if you wanted
to guarantee it, you can certainly do it manually before. However, this
is also subject to policy constraints as Brian mentions below.

Dave

-----Original Message-----
From: Lantz, Keith 
Sent: Thursday, February 05, 2004 8:42 AM
To: Rosen, Brian
Cc: 'Even, Roni'; 'Drage, Keith (Keith)'; [email-masked]; Bieselin, David
Subject: RE: [XCON] CPCP Requirement: Repeat times 

I agree.

At 07:26 AM 2/5/2004, Rosen, Brian wrote:
>I think a particular implementation might have policy issues (for 
>example, it may not be able to reserve the resources), so the attempt 
>may fail.
>
>The choice you would select is "end at stop time", and you can change 
>stop time (policy permitting).
>
>Brian
>
> > When is the stop time get set, before the conference? can you change

> > it once the conference has started or after an event announcing that

> > the conference will end soon.
> >
> > Since this is a way to extend then a choice of "allowed to change 
> > stop time after conference started" may also be needed.
> >
> > 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.
> >
> >
> >
> > > 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
> > >
> > > > 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 
> > > > 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

> > > > > > 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
> > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > 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).
> > > > > > > > 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
> > > > Voice (& Video) Technology Group Cisco Systems, Inc.
> > > >
> > >

---

From: [email-masked]
Date: Thu, 5 Feb 2004 23:39:03 +0200

I think the current requirements (as written in -02 draft) 
fulfill all the issues raised here. For example, extending conference duration
is possible (just modify stop time anytime).

I'm not sure about the "keep this conference running as long as there are users,
then stop the conference" issue. You could easily set the stop time to be next year.
I guess this covers the use case.

--
Petri

> Keith Lantz
> Sent: 05 February, 2004 22:34
> To: Bieselin, David
> Cc: Lantz, Keith; Rosen, Brian; Even, Roni; Drage, Keith (Keith);
> [email-masked]
> Good point. OK then, I agree with MOST of what Brian was 
> saying, and agree 
> with you that an additional "allow to extend if resources are 
> available" 
> option is desirable (as an optimization for the user).
> 
> Cheers, Keith
> 
> At 12:19 PM 2/5/2004, Bieselin, David wrote:
> > > > About your choices I assume that logical operators 
> between them are
> > > > allowed.

---

From: [email-masked]
Date: Fri, 6 Feb 2004 10:07:44 +0200

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

> Cullen Jennings
> Sent: 06 February, 2004 09:58
> To: Brian Rosen; 'Drage, Keith (Keith)'; Keith A Lantz
> Cc: XCON-IETF; Dave Bieselin
> 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" <[email-masked]> wrote:
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 6 Feb 2004 08:21:58 -0500

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 06, 2004 3:08 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: [email-masked]
Date: Fri, 6 Feb 2004 15:55:57 +0200

> 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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 6 Feb 2004 09:08:40 -0500

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

> Sent: Friday, February 06, 2004 8:56 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > > > >>> Indeed, what happens when the conference 
> creator/owner leaves
> > > > >>> a conference 
> > > > >>> after the stop time. You may not, in fact, being 
> saying that.
> > > > >>> But in case 
> > > > >>>> connection resources to that bridge. As the 
> conference owner
> > > > >>> would have no

---

From: Michael Hammer <[email-masked]>
Date: Fri, 06 Feb 2004 10:42:26 -0500

At 08:21 AM 2/6/2004 -0500, Rosen, Brian wrote:
>End when last person leaves is the way many bridges work.

Is that a technical justification?

>You might

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.

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

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

>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,
>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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 6 Feb 2004 15:43:40 -0000

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

> Sent: 06 February 2004 14:09
> To: [email-masked]'; [email-masked]; [email-masked];
> [email-masked]
> > > > > >>> 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 
> > > > > >>>> current distinction between existing enterprise 
> network and
> > > > > >>> public network

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 6 Feb 2004 20:25:08 +0200

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.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 6 Feb 2004 13:33:08 -0500

> Is that a technical justification?
Actually, I think it means there is a requirement for that to be possible.

> stop, and the bridge resources are needed elsewhere, then it stops.
CPCP has two elements, and they each have a role in policy.
A particular implementation, or more properly, a particular administrative
action, may restrict the range of possible policy requests the convener
may ask for.   The bridge may not respond the way the convener would like
it to.  It must be possible for the bridge to have local policy, and yet
allow the convener to manipulate whatever freedoms the local policy
permits.

You could have the bridge change the start/stop time itself to implement
its local policy, but that makes the function even more twisted.
Better to have explicit mechanisms, and let the bridge implement, or permit
a subset of them if it wishes.

> Who is the authority here?  Isnt' the bridge-providing 
As above, local policy must override.

....snip...
> and should a bridge be reserved at the moment.
I don't see it that way.  I see it as the bridge has local policy,
the convener wants to exert whatever freedom the local policy permits,
and the participants have to have some way to understand what is
going to happen.

> with secondary and tertiary implementation implications.
I've proposed that start time is the earliest time at which
mixing starts.

I've proposed that stop time is interpreted by the stop time
enumeration.  It could be a hard stop of mixing resources, or it
could be only advisory.

> the conference is re-started.
Possibly a minor semantic argument.  I think we both agree that
the scheduled conference did not take place.  What is the
difference between "release and recapture" and "reset start"?

> You are asserting what the group is attempting to define.
Well, we can twist start and stop, but to any person, a meet me, by
definition, does not have start and stop times.  Could we implement it
by twisting start/stop?  I guess, but I don't think its a good idea.

> it never starts seems rather limiting in an unnecessary way.
That's the way Meet Me (notice the word "Me") services are defined.
I happen to think its an excellent service.  I would not want anyone
to be able to use my Meet Me conference if I was not there.
I am charged for it.  If 4 people know my MeetMe URI, they can decide
to have a conference (on my nickle) any time they want if there is
not a restriction that convener starts.  That is precisely why MeetMe
works the way it does.  Its not a current technology limitation.

I have no problem at all in allowing CPCP to facilitate an ad-hoc
conference, which is what I think you are looking for.  Ad-hoc is
a conference starts either by promoting a one on one to a three way,
or by the first person connecting to the conference, and it ends when
the last person leaves (or for some, when the number of participants
drops below 3).  Ad-hoc is also a useful service, but usually we use 
ad-hoc internally where charging issues are simpler.
> can not continue without that person, if the policy says it can.
Agree, but I want you to explicitly say that, and I want local policy
to be able to permit you to say that, or deny you the ability to say that.

> that over-rides the ability to do so.  But, that again is 
Well, a new start/stop MAY be a new conference, or it could be a reschedule
of an existing one.  Take a scenario where a couple of participants show,
the convener doesn't, and the participants leave.  The convener pushes
start and stop an hour.  If its a new conference, there is a new conference
URI.
If its a reschedule, then its the same conference, and the same URI.  I
think
that is preferable.

Local policy, as I advocate, is indeed a controlling factor.  However, to be
successful, the convener and the participants have to know what the local
policy is, so that their expectations are met.  That means CPCP has to have
ways of the participants including the convener to learning the local
policy,
which means the language has to have the ability to express it.  It's not
just implementation.

> definition of "how" it is to be supported.
Confused about "what a conference is".  I think we are all working on the
"how it is to be supported".  I don't even want to think about a definition
of what it is.  For example, if I play music on hold to you while you are
waiting for a conference to start, is that part of the conference?  You got
there with the conference URI, you can probably manipulate some resources

---

From: Michael Hammer <[email-masked]>
Date: Fri, 06 Feb 2004 14:49:25 -0500

Brian,

I may be a little confused by what is meant by policy and policy 
manipulation with respect to how that translates into resources being 
invoked and released.  My vision (delusion) as to how that might work might 
have to wait to see the actual protocol develop.  But, I suspect that your 
answers to my comments below will help clear this up for me.

Mike

>Actually, I think it means there is a requirement for that to be possible.

Agree.  Don't see that as not possible.

>allow the convener to manipulate whatever freedoms the local policy

I agree with this part.  The local "uber-policy" determines if the 
convener's policy request is accepted or rejected.

>You could have the bridge change the start/stop time itself

I don't follow this part.  It seems to confuse the role of the bridge in 
committing to the use of resources and the role of the convener in 
committing to pay for what he has asked for.  If it is the intent of the 
requester to terminate the conference upon his leaving, then that should 
be  an option of the request he makes to the bridge.

If he is requesting that the bridge terminate upon his departure, shouldn't 
that be an update to his policy?  Same for other options.  The bridge of 
course may have resource limitations, and thus there may be conditional 
authorizations to what is requested.  Where I think I have some confusion 
is that some of these options/authorizations are implicit not explicit.

>to implement

I agree, in the sense that local policy drives convener policy that drives 
bridge resource provided/withheld.

>and the participants have to have some way to understand what is

But, isn't the time at which the local policy interacts with the convener 
request independent of when a particular bridge resource gets assigned?  A 
convener request could be accepted so long as there are enough resources 
available/reserved in the pool, whether or not a resource is actually put 
to use.

>I've proposed that start time is the earliest time at which

I thought this was a policy?  This would mean that the start time would be 
the earliest time at which mixing is permitted to start.  Isn't this 
independent of whether a resource was invoked?  Note, it may be reserved 
un-occupied and billed for, but that may not be the most efficient use of 
resources.  (No statistical over-booking allowed.)

>enumeration.  It could be a hard stop of mixing resources, or it

Could this not be defined as the latest time at which mixing is permitted 
to be used, i.e. that the enumeration option is whether the stop time may 
get updated explicitly by the convener or another party or implicitly by a 
convener agent (could be the bridge)?

>the scheduled conference did not take place.

Are we talking when a convener was authorized to invoke a conference 
resource or accounting for when resources were actually used?
I believe that some conference services still charge as the resources where 
reserved and represent an opportunity cost.

>What is the

One appears to be a new conference instance, while the other appears to be 
a modification of an existing conference.

>That's the way Meet Me (notice the word "Me") services are defined.

I should note that the term "meet me" has been used in a more broad way to 
mean any pre-scheduled conference for which a number (address) has be setup 
and to which users are asked to call into at some future time.  You seem to 
have something more specific in mind.  I have no problem with a specific, 
maybe trademarked, service to be more narrowly defined, but see no reason 
to limit other possibilities.

>works the way it does.  Its not a current technology limitation.

I have not problem with this being possible, just don't think CPCP should 
be restricted for being used in other ways.  Protocol should be generally 
usable for many types of services.

>to be able to permit you to say that, or deny you the ability to say that.

OK

>the convener doesn't, and the participants leave.

Hopefully, the convener could show up late and the conference is still 
active and resources get invoked for him and whoever else shows up late.

>The convener pushes

So long as the convener shows up within the hour it was originally 
scheduled, could it be neither a new conference nor a reschedule?  Suppose 
he shows 20 minutes late, but only needs 40 minutes to get the work done, 
why should any policy change take place?

>waiting for a conference to start, is that part of the conference?

That sounds like a service description which may be implementation dependent.

>You got

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 9 Feb 2004 09:55:14 -0500

That's of course what I proposed, although I think stop time is pretty
useful
for most conferences even if it is only advisory.  I had additional options
(stop when convener leaves, for example).

Brian

> Sent: Monday, February 09, 2004 9:34 AM
> To: [email-masked]; Michael P Hammer; Brian Rosen
> Cc: [email-masked]; [email-masked]; Keith A Lantz;
> XCON-IETF; [email-masked]
> I think we would get further if we decided it was time to 
> stop calling it
> stop time and instead say there was an optional policy setting of
> 
> terminate conference at time X policy
> and/or
> terminate when all users leave yes/no policy
>  
> There are two disconnected things that are getting convolved 
> together in
> stop time. One is how long resource are reserved for 
> (whatever reservation
> means). The other is the policy around how the conference will end.
> 
> Cullen
> 
> On 2/9/04 2:45 AM, "[email-masked]" 
> <[email-masked]>
> wrote:
> 
> > Admittedly, the current solution specifies that a convener 
> needs to change the
> > stop time in order to terminate the conference, if he wants 
> the conference to
> > end as he leaves. I sense that people want the convener to 
> explicitly indicate
> > that instead of just modifying the stop-time. Am I correct? 
> I know Brian wants
> > it so.
> > 
> > I also would like to encourage people to read sections 12 
> and 18.3 of the
> > solution draft. Those sections discuss exactly what this 
> thread is all about.
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xca
> p-cpcp-usage-02.
> > txt
> > 
> > Regards,
> > Hisham
> > 
> >> Michael Hammer
> >> Sent: 06.February.2004 21:49
> >> To: Rosen, Brian
> >> Cc: Koskelainen Petri (Nokia-NRC/Tampere); [email-masked]; Rosen,
> >> Brian; [email-masked]; [email-masked]; [email-masked];
> >> [email-masked]

---

From: Michael Hammer <[email-masked]>
Date: Mon, 09 Feb 2004 11:24:50 -0500

Hisham,

Thanks.  This fits my view of what is expected.  One quick comment however 
(very minor nit) in 18.3:

"When saying that a conference starts, or becomes active (start-time), it 
means that the mixing starts."  [... as soon as one or more inputs are 
available?]

Is it not possible that the start time has passed, yet no one has called in 
yet?  So could it not be possible that no bridge resource (although 
assigned or reserved) is in use?  How do you mix 0 inputs and outputs?

Mike

At 12:45 PM 2/9/2004 +0200, [email-masked] wrote:
>Admittedly, the current solution specifies that a convener needs to change 
>the stop time in order to terminate the conference, if he wants the 
>conference to end as he leaves. I sense that people want the convener to 
>explicitly indicate that instead of just modifying the stop-time. Am I 
>correct? I know Brian wants it so.
>
>I also would like to encourage people to read sections 12 and 18.3 of the 
>solution draft. Those sections discuss exactly what this thread is all about.
>
>http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xcap-cpcp-usage-02.txt
>
>Regards,
>Hisham
>

---

From: [email-masked]
Date: Mon, 9 Feb 2004 18:40:44 +0200

> From: ext Michael Hammer [mailto:[email-masked]]
> Sent: 09.February.2004 18:25
> Cc: [email-masked]; Koskelainen Petri (Nokia-NRC/Tampere);
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]

Ok, I get your point. I'll fix the text. Thanks.

Hisham
> needs to change