From exim@www1.ietf.org Mon Feb 2 15:57:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08786 for ; Mon, 2 Feb 2004 15:57:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl7q-0006tH-AL for xcon-archive@odin.ietf.org; Mon, 02 Feb 2004 15:56:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Kuwmq026483 for xcon-archive@odin.ietf.org; Mon, 2 Feb 2004 15:56:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl7p-0006rN-UN for xcon-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:56:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08722 for ; Mon, 2 Feb 2004 15:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anl7o-0000GR-00 for xcon-web-archive@ietf.org; Mon, 02 Feb 2004 15:56:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anl6r-00009w-00 for xcon-web-archive@ietf.org; Mon, 02 Feb 2004 15:55:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anl62-00003l-00 for xcon-web-archive@ietf.org; Mon, 02 Feb 2004 15:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl60-0006OZ-R7; Mon, 02 Feb 2004 15:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl5m-0006My-NB for xcon@optimus.ietf.org; Mon, 02 Feb 2004 15:54:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08407; Mon, 2 Feb 2004 15:54:47 -0500 (EST) Message-Id: <200402022054.PAA08407@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: xcon@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 02 Feb 2004 15:54:47 -0500 Subject: [XCON] I-D ACTION:draft-ietf-xcon-cpcp-reqs-02.txt Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Requirements for Conference Policy Control Protocol Author(s) : P. Koskelainen Filename : draft-ietf-xcon-cpcp-reqs-02.txt Pages : 19 Date : 2004-2-2 The conference policy server allows clients to manipulate and interact with the conference policy. One mechanism to manipulate the policy is to use conference policy control protocol (CPCP). This document gives the requirements for CPCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-cpcp-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-cpcp-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-2150041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-cpcp-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-cpcp-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150041.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 3 12:13:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19164 for ; Tue, 3 Feb 2004 12:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao46i-0001aL-E7 for xcon-archive@odin.ietf.org; Tue, 03 Feb 2004 12:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13HD4Ge006089 for xcon-archive@odin.ietf.org; Tue, 3 Feb 2004 12:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao46i-0001a8-8J for xcon-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19114 for ; Tue, 3 Feb 2004 12:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao46g-0001pz-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:13:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao45v-0001fo-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:12:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao44r-0001Ui-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:11:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao44l-0001Ms-2l; Tue, 03 Feb 2004 12:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao44F-0001Ja-4B for xcon@optimus.ietf.org; Tue, 03 Feb 2004 12:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18893 for ; Tue, 3 Feb 2004 12:10:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao44D-0001OT-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao43K-0001FT-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:09:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ao42O-00010S-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:08:36 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2004 09:08:24 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i13H8G08020144; Tue, 3 Feb 2004 09:08:16 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMA29779; Tue, 3 Feb 2004 09:08:13 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 03 Feb 2004 09:08:12 -0800 Subject: Re: [XCON] CPCP Requirement: Hidden Participants From: Cullen Jennings To: Eric Burger , XCON-IETF Message-ID: In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A05C@zoe.office.snowshore.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't care if we support hidden participants but I feel that the requirements for Legal Intercept should definitely be out. There are way too many land minds over yonder and it is not the point of this WG to solve those. Cullen On 1/20/04 8:00 AM, "Eric Burger" wrote: > Would Legal Intercept be in or out? E.g., hidden participants that CANNOT be > known. > >> -----Original Message----- >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >> Sent: Friday, December 19, 2003 6:14 AM >> To: hisham.khartabil@nokia.com; mhammer@cisco.com >> Cc: xcon@ietf.org >> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >> >> >> I believe hidden users are appropriate. >> >> I do not believe that this adds complexity to the >> specifications (particularly to the specification of CPCP), >> so I see no need to make it a DEFER as far as the >> specifications are concerned. It may add complexity to the >> implementation, so I am quite happy to see it a MAY in the >> requirements, so that it is optional to implement. >> >> As regards the legal implications of hidden users, then yes, >> there may be priveleged users that are able to request the >> identity of hidden users (along with an indication that they >> are hidden). This of course requires the enabling of such a >> privileged user in the first place. >> >> Secondly, it may not be necessary to identify hidden users, >> but merely that there are hidden users in the conference (in >> addition to any that may have made themselves visible). Some >> countries require some form of tone or announcement on voice >> conferences when someone else is listening in. They also >> require an announcement or other indication in the call is >> being recorded. >> >> regards >> >> Keith >> >> Keith Drage >> Lucent Technologies >> drage@lucent.com >> tel: +44 1793 776249 >> >> >>> -----Original Message----- >>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>> Sent: 15 December 2003 16:29 >>> To: mhammer@cisco.com >>> Cc: xcon@ietf.org >>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Michael Hammer [mailto:mhammer@cisco.com] >>>> Sent: 15.December.2003 18:17 >>>> To: Khartabil Hisham (NMP-MSW/Helsinki) >>>> Cc: xcon@ietf.org >>>> Subject: Re: [XCON] CPCP Requirement: Hidden Participants >>>> >>>> >>>> Related to this is there a requirement that, while not >>> revealing the >>>> identity of a hidden user, the conference policy contains >>>> state indication >>>> about either the presence of hidden users, or the >>>> possibility/preclusion >>>> that such hidden users may be present? >>>> >>>> I am anticipating that: >>>> 1) Laws may exist that require notification of such. >>> >>> That's a good point. This might require changes to the >>> conference event package to indicate if there are hidden >>> participants or not, and if so, how many. >>> >>> The question remain: is there a need for such a feature (to >>> hide users?)? >>> >>> Regards, >>> Hisham >>> >>>> 2) In some conferences, participants may want technical >>>> assurance that >>>> hidden users are not possible before they speak. >>>> >>>> Mike >>>> >>>> >>>> At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: >>>>> This is in reference to requirements REQ-A7 and REQ-E10 in >>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt >>>> >>>> REQ-A7: It SHOULD be possible to participate in a >> conference as a >>>> hidden user. Hidden user is present in a conference, but >>> his presence >>>> is not revealed. >>>> >>>> REQ-E10: It MUST be possible to allow and disallow >>> hidden membership >>>> in a conference. >>>> >>>> Should a conference policy, using CPCP, specify if a user >>> can be hidden? >>>> This means that the conference state package does not report the >>>> participation on the hidden user. CPCP is used to identify >>> which users are >>>> hidden. The list of hidden users is only manipulated by a >>> privileged user >>>> such as the moderator. >>>> >>>> Regards, >>>> Hisham >>>> >>>> _______________________________________________ >>>> 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 From exim@www1.ietf.org Tue Feb 3 12:13:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19185 for ; Tue, 3 Feb 2004 12:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao46j-0001al-Nh for xcon-archive@odin.ietf.org; Tue, 03 Feb 2004 12:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13HD5s5006113 for xcon-archive@odin.ietf.org; Tue, 3 Feb 2004 12:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao46j-0001aW-I5 for xcon-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19121 for ; Tue, 3 Feb 2004 12:13:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao46i-0001qA-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:13:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao45w-0001g4-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:12:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao44u-0001Uo-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao44k-0001MK-8P; Tue, 03 Feb 2004 12:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao44E-0001JV-EX for xcon@optimus.ietf.org; Tue, 03 Feb 2004 12:10:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18890 for ; Tue, 3 Feb 2004 12:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao44D-0001OO-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao43I-0001FB-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:09:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ao42N-00010S-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:08:35 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2004 09:08:10 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i13H8308019763 for ; Tue, 3 Feb 2004 09:08:03 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMA29763; Tue, 3 Feb 2004 09:08:02 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 03 Feb 2004 09:08:01 -0800 Subject: Re: [XCON] CPCP Requirement: Repeat times From: Cullen Jennings To: XCON-IETF Message-ID: In-Reply-To: <4.3.1.2.20040130110024.02047000@VTG-UM-E2K1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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" 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:eburger@snowshore.com] >>> Sent: Thursday, January 29, 2004 10:42 AM >>> To: hisham.khartabil@nokia.com; xcon@ietf.org >>> 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:dgboyer@avaya.com] >>>> Sent: Wednesday, January 28, 2004 9:39 AM >>>> To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org >>>> Cc: roni.even@polycom.co.il >>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of >>>> hisham.khartabil@nokia.com >>>> Sent: Wednesday, January 28, 2004 6:50 AM >>>> To: eburger@snowshore.com; xcon@ietf.org >>>> Cc: roni.even@polycom.co.il >>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On >>>> Behalf Of ext >>>>> hisham.khartabil@nokia.com >>>>> Sent: 28.January.2004 09:30 >>>>> To: eburger@snowshore.com; xcon@ietf.org >>>>> Cc: roni.even@polycom.co.il >>>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On >>>>> Behalf Of ext >>>>>> Eric Burger >>>>>> Sent: 26.January.2004 21:23 >>>>>> To: xcon@ietf.org >>>>>> 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:roni.even@polycom.co.il] >>>>>>> Sent: Sunday, January 25, 2004 8:44 AM >>>>>>> To: 'petri.koskelainen@nokia.com'; xcon@ietf.org >>>>>>> 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:roni.even@polycom.co.il >>>>>>> ******************************************* >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: petri.koskelainen@nokia.com >>>>>> [mailto:petri.koskelainen@nokia.com] >>>>>>> Sent: Sunday, January 25, 2004 3:31 PM >>>>>>> To: xcon@ietf.org >>>>>>> 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:Brian.Rosen@marconi.com] >>>>>>>>> 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: hisham.khartabil@nokia.com >>>>>>>> [mailto:hisham.khartabil@nokia.com] >>>>>>>>>> Sent: Wednesday, January 21, 2004 8:10 AM >>>>>>>>>> To: eburger@snowshore.com; roni.even@polycom.co.il; >>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org >>>>>>>>>> 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:eburger@snowshore.com] >>>>>>>>>>> Sent: 20.January.2004 18:01 >>>>>>>>>>> To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); >>>>>>>>>>> Koskelainen Petri >>>>>>>>>>> (Nokia-NRC/Tampere); xcon@ietf.org >>>>>>>>>>> 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:roni.even@polycom.co.il] >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 4:56 AM >>>>>>>>>>>> To: 'hisham.khartabil@nokia.com'; Even, Roni; >>>>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org >>>>>>>>>>>> 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:roni.even@polycom.co.il >>>>>>>>>>>> ******************************************* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: hisham.khartabil@nokia.com >>>>>>>>>> [mailto:hisham.khartabil@nokia.com] >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 11:22 AM >>>>>>>>>>>> To: roni.even@polycom.co.il; >>>>> petri.koskelainen@nokia.com; >>>>>>>>>>>> xcon@ietf.org >>>>>>>>>>>> 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:roni.even@polycom.co.il] >>>>>>>>>>>> Sent: 06.January.2004 19:06 >>>>>>>>>>>> To: Koskelainen Petri (Nokia-NRC/Tampere); >>>>> Even, Roni; >>>>>>>>>>>> Khartabil Hisham >>>>>>>>>>>> (Nokia-TP/Helsinki); 'xcon@ietf.org ' >>>>>>>>>>>> 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: petri.koskelainen@nokia.com >>>>>>>>>>>> To: roni.even@polycom.co.il; >>>>>> hisham.khartabil@nokia.com; >>>>>>>>>>>> xcon@ietf.org >>>>>>>>>>>> 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: hisham.khartabil@nokia.com >>>>>>>>>>> [mailto:hisham.khartabil@nokia.com] >>>>>>>>>>>> Sent: Monday, December 15, 2003 4:57 PM >>>>>>>>>>>> To: xcon@ietf.org >>>>>>>>>>>> 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 >>>>>>> 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 >>> >> >> _______________________________________________ >> 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 From exim@www1.ietf.org Tue Feb 3 12:39:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20466 for ; Tue, 3 Feb 2004 12:39:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4VM-0003Qo-W4 for xcon-archive@odin.ietf.org; Tue, 03 Feb 2004 12:38:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13HcWvX013183 for xcon-archive@odin.ietf.org; Tue, 3 Feb 2004 12:38:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4VM-0003QY-Pg for xcon-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20451 for ; Tue, 3 Feb 2004 12:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4VL-0004u1-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:38:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4UV-0004on-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:37:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4Tu-0004jo-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 12:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4Tt-00033y-M5; Tue, 03 Feb 2004 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4TQ-00032r-Gn for xcon@optimus.ietf.org; Tue, 03 Feb 2004 12:36:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20387 for ; Tue, 3 Feb 2004 12:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4TO-0004iP-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:36:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4SV-0004dR-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:35:36 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly04a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao4S2-0004X6-00 for xcon@ietf.org; Tue, 03 Feb 2004 12:35:07 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly04a.srv.mailcontrol.com (MailControl) with SMTP id i13HYT59030611; Tue, 3 Feb 2004 17:34:30 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Tue, 3 Feb 2004 17:34:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Tue, 3 Feb 2004 17:34:29 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF15D@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPqeMCxzpW4voPCR5iPmazUqtLS7wAAww1Q From: "Chris Boulton" To: "Cullen Jennings" , "Eric Burger" , "XCON-IETF" X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Cullen. I don't have a problem with Hidden participants BUT 'is legal intercept really in the scope of CPCP?'? Chris. >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: 03 February 2004 17:08 >To: Eric Burger; XCON-IETF >Subject: Re: [XCON] CPCP Requirement: Hidden Participants > > >I don't care if we support hidden participants but I feel that the >requirements for Legal Intercept should definitely be out. There are way >too >many land minds over yonder and it is not the point of this WG to solve >those. > >Cullen > > > >On 1/20/04 8:00 AM, "Eric Burger" wrote: > >> Would Legal Intercept be in or out? E.g., hidden participants that >CANNOT be >> known. >> >>> -----Original Message----- >>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>> Sent: Friday, December 19, 2003 6:14 AM >>> To: hisham.khartabil@nokia.com; mhammer@cisco.com >>> Cc: xcon@ietf.org >>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>> >>> >>> I believe hidden users are appropriate. >>> >>> I do not believe that this adds complexity to the >>> specifications (particularly to the specification of CPCP), >>> so I see no need to make it a DEFER as far as the >>> specifications are concerned. It may add complexity to the >>> implementation, so I am quite happy to see it a MAY in the >>> requirements, so that it is optional to implement. >>> >>> As regards the legal implications of hidden users, then yes, >>> there may be priveleged users that are able to request the >>> identity of hidden users (along with an indication that they >>> are hidden). This of course requires the enabling of such a >>> privileged user in the first place. >>> >>> Secondly, it may not be necessary to identify hidden users, >>> but merely that there are hidden users in the conference (in >>> addition to any that may have made themselves visible). Some >>> countries require some form of tone or announcement on voice >>> conferences when someone else is listening in. They also >>> require an announcement or other indication in the call is >>> being recorded. >>> >>> regards >>> >>> Keith >>> >>> Keith Drage >>> Lucent Technologies >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >>> >>>> -----Original Message----- >>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>> Sent: 15 December 2003 16:29 >>>> To: mhammer@cisco.com >>>> Cc: xcon@ietf.org >>>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Michael Hammer [mailto:mhammer@cisco.com] >>>>> Sent: 15.December.2003 18:17 >>>>> To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>> Cc: xcon@ietf.org >>>>> Subject: Re: [XCON] CPCP Requirement: Hidden Participants >>>>> >>>>> >>>>> Related to this is there a requirement that, while not >>>> revealing the >>>>> identity of a hidden user, the conference policy contains >>>>> state indication >>>>> about either the presence of hidden users, or the >>>>> possibility/preclusion >>>>> that such hidden users may be present? >>>>> >>>>> I am anticipating that: >>>>> 1) Laws may exist that require notification of such. >>>> >>>> That's a good point. This might require changes to the >>>> conference event package to indicate if there are hidden >>>> participants or not, and if so, how many. >>>> >>>> The question remain: is there a need for such a feature (to >>>> hide users?)? >>>> >>>> Regards, >>>> Hisham >>>> >>>>> 2) In some conferences, participants may want technical >>>>> assurance that >>>>> hidden users are not possible before they speak. >>>>> >>>>> Mike >>>>> >>>>> >>>>> At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: >>>>>> This is in reference to requirements REQ-A7 and REQ-E10 in >>>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt >>>>> >>>>> REQ-A7: It SHOULD be possible to participate in a >>> conference as a >>>>> hidden user. Hidden user is present in a conference, but >>>> his presence >>>>> is not revealed. >>>>> >>>>> REQ-E10: It MUST be possible to allow and disallow >>>> hidden membership >>>>> in a conference. >>>>> >>>>> Should a conference policy, using CPCP, specify if a user >>>> can be hidden? >>>>> This means that the conference state package does not report the >>>>> participation on the hidden user. CPCP is used to identify >>>> which users are >>>>> hidden. The list of hidden users is only manipulated by a >>>> privileged user >>>>> such as the moderator. >>>>> >>>>> Regards, >>>>> Hisham >>>>> >>>>> _______________________________________________ >>>>> 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 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 3 13:41:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23762 for ; Tue, 3 Feb 2004 13:41:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5TO-0003Uk-N0 for xcon-archive@odin.ietf.org; Tue, 03 Feb 2004 13:40:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13IeYiU013428 for xcon-archive@odin.ietf.org; Tue, 3 Feb 2004 13:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5TO-0003UV-Gi for xcon-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 13:40:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23736 for ; Tue, 3 Feb 2004 13:40:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5TM-0004Nk-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 13:40:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5ST-0004IL-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 13:39:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5Rr-0004Cy-00 for xcon-web-archive@ietf.org; Tue, 03 Feb 2004 13:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5Rs-0003Q1-Ta; Tue, 03 Feb 2004 13:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5RX-0003PM-SP for xcon@optimus.ietf.org; Tue, 03 Feb 2004 13:38:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23688 for ; Tue, 3 Feb 2004 13:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5RV-0004Bn-00 for xcon@ietf.org; Tue, 03 Feb 2004 13:38:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5Qf-00045o-00 for xcon@ietf.org; Tue, 03 Feb 2004 13:37:47 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao5Q3-0003y6-00 for xcon@ietf.org; Tue, 03 Feb 2004 13:37:07 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 13:36:37 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6387@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , XCON-IETF Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Tue, 3 Feb 2004 13:36:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, February 03, 2004 12:08 PM > To: XCON-IETF > Subject: Re: [XCON] CPCP Requirement: Repeat times > > > > 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" 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:eburger@snowshore.com] > >>> Sent: Thursday, January 29, 2004 10:42 AM > >>> To: hisham.khartabil@nokia.com; xcon@ietf.org > >>> 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:dgboyer@avaya.com] > >>>> Sent: Wednesday, January 28, 2004 9:39 AM > >>>> To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org > >>>> Cc: roni.even@polycom.co.il > >>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of > >>>> hisham.khartabil@nokia.com > >>>> Sent: Wednesday, January 28, 2004 6:50 AM > >>>> To: eburger@snowshore.com; xcon@ietf.org > >>>> Cc: roni.even@polycom.co.il > >>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > >>>> Behalf Of ext > >>>>> hisham.khartabil@nokia.com > >>>>> Sent: 28.January.2004 09:30 > >>>>> To: eburger@snowshore.com; xcon@ietf.org > >>>>> Cc: roni.even@polycom.co.il > >>>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > >>>>> Behalf Of ext > >>>>>> Eric Burger > >>>>>> Sent: 26.January.2004 21:23 > >>>>>> To: xcon@ietf.org > >>>>>> 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:roni.even@polycom.co.il] > >>>>>>> Sent: Sunday, January 25, 2004 8:44 AM > >>>>>>> To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > >>>>>>> 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:roni.even@polycom.co.il > >>>>>>> ******************************************* > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: petri.koskelainen@nokia.com > >>>>>> [mailto:petri.koskelainen@nokia.com] > >>>>>>> Sent: Sunday, January 25, 2004 3:31 PM > >>>>>>> To: xcon@ietf.org > >>>>>>> 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:Brian.Rosen@marconi.com] > >>>>>>>>> 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: hisham.khartabil@nokia.com > >>>>>>>> [mailto:hisham.khartabil@nokia.com] > >>>>>>>>>> Sent: Wednesday, January 21, 2004 8:10 AM > >>>>>>>>>> To: eburger@snowshore.com; roni.even@polycom.co.il; > >>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org > >>>>>>>>>> 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:eburger@snowshore.com] > >>>>>>>>>>> Sent: 20.January.2004 18:01 > >>>>>>>>>>> To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > >>>>>>>>>>> Koskelainen Petri > >>>>>>>>>>> (Nokia-NRC/Tampere); xcon@ietf.org > >>>>>>>>>>> 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:roni.even@polycom.co.il] > >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 4:56 AM > >>>>>>>>>>>> To: 'hisham.khartabil@nokia.com'; Even, Roni; > >>>>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org > >>>>>>>>>>>> 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:roni.even@polycom.co.il > >>>>>>>>>>>> ******************************************* > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: hisham.khartabil@nokia.com > >>>>>>>>>> [mailto:hisham.khartabil@nokia.com] > >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 11:22 AM > >>>>>>>>>>>> To: roni.even@polycom.co.il; > >>>>> petri.koskelainen@nokia.com; > >>>>>>>>>>>> xcon@ietf.org > >>>>>>>>>>>> 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:roni.even@polycom.co.il] > >>>>>>>>>>>> Sent: 06.January.2004 19:06 > >>>>>>>>>>>> To: Koskelainen Petri (Nokia-NRC/Tampere); > >>>>> Even, Roni; > >>>>>>>>>>>> Khartabil Hisham > >>>>>>>>>>>> (Nokia-TP/Helsinki); 'xcon@ietf.org ' > >>>>>>>>>>>> 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: petri.koskelainen@nokia.com > >>>>>>>>>>>> To: roni.even@polycom.co.il; > >>>>>> hisham.khartabil@nokia.com; > >>>>>>>>>>>> xcon@ietf.org > >>>>>>>>>>>> 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: hisham.khartabil@nokia.com > >>>>>>>>>>> [mailto:hisham.khartabil@nokia.com] > >>>>>>>>>>>> Sent: Monday, December 15, 2003 4:57 PM > >>>>>>>>>>>> To: xcon@ietf.org > >>>>>>>>>>>> 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 > >>>>>>> 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 > >>> > >> > >> _______________________________________________ > >> 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 From exim@www1.ietf.org Wed Feb 4 01:03:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24044 for ; Wed, 4 Feb 2004 01:03:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoG7m-0007zO-Kd for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 01:02:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1462wPu030704 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 01:02:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoG7m-0007z9-Dn for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 01:02:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24023 for ; Wed, 4 Feb 2004 01:02:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoG7j-0006Z6-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 01:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoG6m-0006Ty-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 01:01:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoG5s-0006OY-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 01:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoG5u-0007tJ-CT; Wed, 04 Feb 2004 01:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoG55-0007jR-Bz for xcon@optimus.ietf.org; Wed, 04 Feb 2004 01:00:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23946 for ; Wed, 4 Feb 2004 01:00:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoG52-0006I0-00 for xcon@ietf.org; Wed, 04 Feb 2004 01:00:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoG46-0006C0-00 for xcon@ietf.org; Wed, 04 Feb 2004 00:59:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AoG3Y-000656-00 for xcon@ietf.org; Wed, 04 Feb 2004 00:58:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2004 21:58:08 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i145w55j012511; Tue, 3 Feb 2004 21:58:05 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-1155.cisco.com [10.21.116.131]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMB04193; Tue, 3 Feb 2004 21:58:03 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 03 Feb 2004 20:47:12 -0800 Subject: Re: [XCON] CPCP Requirement: Repeat times From: Cullen Jennings To: Brian Rosen , XCON-IETF Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B6387@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sounds good to me. On 2/3/04 10:36 AM, "Rosen, Brian" wrote: > 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 > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Tuesday, February 03, 2004 12:08 PM >> To: XCON-IETF >> Subject: Re: [XCON] CPCP Requirement: Repeat times >> >> >> >> 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" 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:eburger@snowshore.com] >>>>> Sent: Thursday, January 29, 2004 10:42 AM >>>>> To: hisham.khartabil@nokia.com; xcon@ietf.org >>>>> 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:dgboyer@avaya.com] >>>>>> Sent: Wednesday, January 28, 2004 9:39 AM >>>>>> To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org >>>>>> Cc: roni.even@polycom.co.il >>>>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On >> Behalf Of >>>>>> hisham.khartabil@nokia.com >>>>>> Sent: Wednesday, January 28, 2004 6:50 AM >>>>>> To: eburger@snowshore.com; xcon@ietf.org >>>>>> Cc: roni.even@polycom.co.il >>>>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On >>>>>> Behalf Of ext >>>>>>> hisham.khartabil@nokia.com >>>>>>> Sent: 28.January.2004 09:30 >>>>>>> To: eburger@snowshore.com; xcon@ietf.org >>>>>>> Cc: roni.even@polycom.co.il >>>>>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On >>>>>>> Behalf Of ext >>>>>>>> Eric Burger >>>>>>>> Sent: 26.January.2004 21:23 >>>>>>>> To: xcon@ietf.org >>>>>>>> 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:roni.even@polycom.co.il] >>>>>>>>> Sent: Sunday, January 25, 2004 8:44 AM >>>>>>>>> To: 'petri.koskelainen@nokia.com'; xcon@ietf.org >>>>>>>>> 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:roni.even@polycom.co.il >>>>>>>>> ******************************************* >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: petri.koskelainen@nokia.com >>>>>>>> [mailto:petri.koskelainen@nokia.com] >>>>>>>>> Sent: Sunday, January 25, 2004 3:31 PM >>>>>>>>> To: xcon@ietf.org >>>>>>>>> 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:Brian.Rosen@marconi.com] >>>>>>>>>>> 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: hisham.khartabil@nokia.com >>>>>>>>>> [mailto:hisham.khartabil@nokia.com] >>>>>>>>>>>> Sent: Wednesday, January 21, 2004 8:10 AM >>>>>>>>>>>> To: eburger@snowshore.com; roni.even@polycom.co.il; >>>>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org >>>>>>>>>>>> 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:eburger@snowshore.com] >>>>>>>>>>>> Sent: 20.January.2004 18:01 >>>>>>>>>>>> To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); >>>>>>>>>>>> Koskelainen Petri >>>>>>>>>>>> (Nokia-NRC/Tampere); xcon@ietf.org >>>>>>>>>>>> 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:roni.even@polycom.co.il] >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 4:56 AM >>>>>>>>>>>> To: 'hisham.khartabil@nokia.com'; Even, Roni; >>>>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org >>>>>>>>>>>> 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:roni.even@polycom.co.il >>>>>>>>>>>> ******************************************* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: hisham.khartabil@nokia.com >>>>>>>>>>>> [mailto:hisham.khartabil@nokia.com] >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 11:22 AM >>>>>>>>>>>> To: roni.even@polycom.co.il; >>>>>>> petri.koskelainen@nokia.com; >>>>>>>>>>>> xcon@ietf.org >>>>>>>>>>>> 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:roni.even@polycom.co.il] >>>>>>>>>>>> Sent: 06.January.2004 19:06 >>>>>>>>>>>> To: Koskelainen Petri (Nokia-NRC/Tampere); >>>>>>> Even, Roni; >>>>>>>>>>>> Khartabil Hisham >>>>>>>>>>>> (Nokia-TP/Helsinki); 'xcon@ietf.org ' >>>>>>>>>>>> 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: petri.koskelainen@nokia.com >>>>>>>>>>>> To: roni.even@polycom.co.il; >>>>>>>> hisham.khartabil@nokia.com; >>>>>>>>>>>> xcon@ietf.org >>>>>>>>>>>> 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: hisham.khartabil@nokia.com >>>>>>>>>>>> [mailto:hisham.khartabil@nokia.com] >>>>>>>>>>>> Sent: Monday, December 15, 2003 4:57 PM >>>>>>>>>>>> To: xcon@ietf.org >>>>>>>>>>>> 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 >>>>>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 From exim@www1.ietf.org Wed Feb 4 02:27:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19280 for ; Wed, 4 Feb 2004 02:27:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHR5-0002Rk-Er for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 02:26:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147Qx2M009401 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 02:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHR4-0002RM-V2 for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:26:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19139 for ; Wed, 4 Feb 2004 02:26:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHR1-0005yz-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 02:26:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHQ8-0005tj-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 02:26:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoHPC-0005o0-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 02:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHPE-000252-8V; Wed, 04 Feb 2004 02:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHOK-0001rl-MD for xcon@optimus.ietf.org; Wed, 04 Feb 2004 02:24:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16180 for ; Wed, 4 Feb 2004 02:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHOG-0005i2-00 for xcon@ietf.org; Wed, 04 Feb 2004 02:24:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHNP-0005cA-00 for xcon@ietf.org; Wed, 04 Feb 2004 02:23:13 -0500 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AoHMz-0005Vc-00 for xcon@ietf.org; Wed, 04 Feb 2004 02:22:45 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <1GTXFW07>; Wed, 4 Feb 2004 09:22:09 +0200 Message-ID: From: "Even, Roni" To: "'Rosen, Brian'" , "'Cullen Jennings'" , XCON-IETF Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 09:22:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 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 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, February 03, 2004 12:08 PM > To: XCON-IETF > Subject: Re: [XCON] CPCP Requirement: Repeat times > > > > 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" 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:eburger@snowshore.com] > >>> Sent: Thursday, January 29, 2004 10:42 AM > >>> To: hisham.khartabil@nokia.com; xcon@ietf.org > >>> 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:dgboyer@avaya.com] > >>>> Sent: Wednesday, January 28, 2004 9:39 AM > >>>> To: hisham.khartabil@nokia.com; Eric Burger; xcon@ietf.org > >>>> Cc: roni.even@polycom.co.il > >>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of > >>>> hisham.khartabil@nokia.com > >>>> Sent: Wednesday, January 28, 2004 6:50 AM > >>>> To: eburger@snowshore.com; xcon@ietf.org > >>>> Cc: roni.even@polycom.co.il > >>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > >>>> Behalf Of ext > >>>>> hisham.khartabil@nokia.com > >>>>> Sent: 28.January.2004 09:30 > >>>>> To: eburger@snowshore.com; xcon@ietf.org > >>>>> Cc: roni.even@polycom.co.il > >>>>> 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: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > >>>>> Behalf Of ext > >>>>>> Eric Burger > >>>>>> Sent: 26.January.2004 21:23 > >>>>>> To: xcon@ietf.org > >>>>>> 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:roni.even@polycom.co.il] > >>>>>>> Sent: Sunday, January 25, 2004 8:44 AM > >>>>>>> To: 'petri.koskelainen@nokia.com'; xcon@ietf.org > >>>>>>> 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:roni.even@polycom.co.il > >>>>>>> ******************************************* > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: petri.koskelainen@nokia.com > >>>>>> [mailto:petri.koskelainen@nokia.com] > >>>>>>> Sent: Sunday, January 25, 2004 3:31 PM > >>>>>>> To: xcon@ietf.org > >>>>>>> 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:Brian.Rosen@marconi.com] > >>>>>>>>> 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: hisham.khartabil@nokia.com > >>>>>>>> [mailto:hisham.khartabil@nokia.com] > >>>>>>>>>> Sent: Wednesday, January 21, 2004 8:10 AM > >>>>>>>>>> To: eburger@snowshore.com; roni.even@polycom.co.il; > >>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org > >>>>>>>>>> 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:eburger@snowshore.com] > >>>>>>>>>>> Sent: 20.January.2004 18:01 > >>>>>>>>>>> To: Even, Roni; Khartabil Hisham (Nokia-TP/Helsinki); > >>>>>>>>>>> Koskelainen Petri > >>>>>>>>>>> (Nokia-NRC/Tampere); xcon@ietf.org > >>>>>>>>>>> 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:roni.even@polycom.co.il] > >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 4:56 AM > >>>>>>>>>>>> To: 'hisham.khartabil@nokia.com'; Even, Roni; > >>>>>>>>>>>> petri.koskelainen@nokia.com; xcon@ietf.org > >>>>>>>>>>>> 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:roni.even@polycom.co.il > >>>>>>>>>>>> ******************************************* > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: hisham.khartabil@nokia.com > >>>>>>>>>> [mailto:hisham.khartabil@nokia.com] > >>>>>>>>>>>> Sent: Wednesday, January 07, 2004 11:22 AM > >>>>>>>>>>>> To: roni.even@polycom.co.il; > >>>>> petri.koskelainen@nokia.com; > >>>>>>>>>>>> xcon@ietf.org > >>>>>>>>>>>> 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:roni.even@polycom.co.il] > >>>>>>>>>>>> Sent: 06.January.2004 19:06 > >>>>>>>>>>>> To: Koskelainen Petri (Nokia-NRC/Tampere); > >>>>> Even, Roni; > >>>>>>>>>>>> Khartabil Hisham > >>>>>>>>>>>> (Nokia-TP/Helsinki); 'xcon@ietf.org ' > >>>>>>>>>>>> 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: petri.koskelainen@nokia.com > >>>>>>>>>>>> To: roni.even@polycom.co.il; > >>>>>> hisham.khartabil@nokia.com; > >>>>>>>>>>>> xcon@ietf.org > >>>>>>>>>>>> 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: hisham.khartabil@nokia.com > >>>>>>>>>>> [mailto:hisham.khartabil@nokia.com] > >>>>>>>>>>>> Sent: Monday, December 15, 2003 4:57 PM > >>>>>>>>>>>> To: xcon@ietf.org > >>>>>>>>>>>> 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 > >>>>>>> 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 > >>> > >> > >> _______________________________________________ > >> 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 From exim@www1.ietf.org Wed Feb 4 04:00:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26576 for ; Wed, 4 Feb 2004 04:00:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoItB-0003WD-Hk for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 04:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149031D013492 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 04:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIt7-0003V5-GY for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:00:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26546 for ; Wed, 4 Feb 2004 03:59:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIt3-0000Z5-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 03:59:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIs5-0000Tp-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 03:58:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoIrB-0000P5-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 03:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIrC-0003QW-Cg; Wed, 04 Feb 2004 03:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIqN-0003Gs-8O for xcon@optimus.ietf.org; Wed, 04 Feb 2004 03:57:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26507 for ; Wed, 4 Feb 2004 03:57:09 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIqK-0000JZ-00 for xcon@ietf.org; Wed, 04 Feb 2004 03:57:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIpG-0000EW-00 for xcon@ietf.org; Wed, 04 Feb 2004 03:56:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AoIoy-00009c-00 for xcon@ietf.org; Wed, 04 Feb 2004 03:55:44 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i148tj228666 for ; Wed, 4 Feb 2004 10:55:45 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 10:55:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 10:55:43 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 10:55:43 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 10:55:42 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976D4@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPqhQmxiNc4hvPITfOuxxx28id+4AAd1QnQ To: , , X-OriginalArrivalTime: 04 Feb 2004 08:55:43.0310 (UTC) FILETIME=[ABE55EE0:01C3EAFC] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----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=20 >=20 >=20 > 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). >=20 > I think we can live with that definition. >=20 > Stop time, like it or not for most bridges I know is expected stop > time of the person scheduling the conference. =20 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=20 > a public bridge that actually tore down the connection, although I=20 > know of at least one enterprise class bridge that does this=20 > (and we HATED it). >=20 > I know I was assuming GMT. >=20 > Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 04:31:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27600 for ; Wed, 4 Feb 2004 04:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJN7-0006SL-Mw for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 04:31:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149V1F0024806 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 04:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJN6-0006Rp-GG for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:31:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27564 for ; Wed, 4 Feb 2004 04:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJN3-0003Ow-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:30:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJM5-0003JC-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:29:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoJLA-0003E9-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJLC-0006BF-K4; Wed, 04 Feb 2004 04:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJKF-00069X-G8 for xcon@optimus.ietf.org; Wed, 04 Feb 2004 04:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27443 for ; Wed, 4 Feb 2004 04:28:00 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJKC-00037h-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:28:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJJH-00031q-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:27:03 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AoJIQ-0002wa-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:26:11 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i149QBM03047 for ; Wed, 4 Feb 2004 11:26:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 11:15:36 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 11:15:35 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 11:15:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 11:15:34 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001E9BCFF@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPqhQmxiNc4hvPITfOuxxx28id+4AAd1QnQAABXuDA= To: , , , X-OriginalArrivalTime: 04 Feb 2004 09:15:34.0793 (UTC) FILETIME=[72133F90:01C3EAFF] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > So what you're saying here is that a conference will only=20 > 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=20 if I create (and pay) the conference (start time 2pm, and stop time = 3pm),=20 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..")=20 or if you have credit left it may be automatically extended for some = reasonable time if=20 there are resources and people hanging on (especially the creator).=20 No guarantees though, it is just best effort as Roni said.=20 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=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Rosen, Brian > > Sent: 03.February.2004 20:37 > > To: 'Cullen Jennings'; XCON-IETF > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > 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). > >=20 > > I think we can live with that definition. > >=20 > > Stop time, like it or not for most bridges I know is expected stop > > time of the person scheduling the conference. =20 >=20 > So what you're saying here is that a conference will only=20 > terminate when the last participant leaves? I think I'm ok with that. >=20 > /Hisham >=20 > > I've never encountered=20 > > a public bridge that actually tore down the connection, although I=20 > > know of at least one enterprise class bridge that does this=20 > > (and we HATED it). > >=20 > > I know I was assuming GMT. > >=20 > > Brian >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 04:36:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27778 for ; Wed, 4 Feb 2004 04:36:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJRy-0006go-Uz for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 04:36:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149a2XF025710 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 04:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJRy-0006ga-Kr for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:36:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27772 for ; Wed, 4 Feb 2004 04:36:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJRv-0003sf-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:35:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJQx-0003n8-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:35:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoJQ0-0003ha-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJQ2-0006bE-NA; Wed, 04 Feb 2004 04:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJP9-0006Zv-7S for xcon@optimus.ietf.org; Wed, 04 Feb 2004 04:33:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27698 for ; Wed, 4 Feb 2004 04:33:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJP6-0003c0-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:33:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJOB-0003WJ-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:32:07 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AoJNd-0003Qh-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:31:33 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i149VX220687 for ; Wed, 4 Feb 2004 11:31:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 11:31:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 11:31:32 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 11:31:31 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976D8@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPqhQmxiNc4hvPITfOuxxx28id+4AAd1QnQAABXuDAAAOLvwA== To: , , , X-OriginalArrivalTime: 04 Feb 2004 09:31:32.0162 (UTC) FILETIME=[ACB62A20:01C3EB01] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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)=20 > 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=20 >=20 >=20 > > So what you're saying here is that a conference will only=20 > > terminate when the last participant leaves? I think I'm ok=20 > with that. >=20 > Actually, I don't think that was the idea. Besides, I'd not be happy=20 > if I create (and pay) the conference (start time 2pm, and=20 > stop time 3pm),=20 > and other people stay there for days. >=20 > I think it is better to stop the conference as defined by the=20 > stop time.=20 > Some vendors may add polite warning 10 min before the stop=20 > time ("this conference will end soon..")=20 > or if you have credit left it may be automatically extended=20 > for some reasonable time if=20 > there are resources and people hanging on (especially the creator).=20 > No guarantees though, it is just best effort as Roni said.=20 >=20 > Anyway, we are now talking about solutions, not requirements. >=20 > -- > Petri >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > 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=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Rosen, Brian > > > Sent: 03.February.2004 20:37 > > > To: 'Cullen Jennings'; XCON-IETF > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > >=20 > > >=20 > > > 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). > > >=20 > > > I think we can live with that definition. > > >=20 > > > Stop time, like it or not for most bridges I know is expected stop > > > time of the person scheduling the conference. =20 > >=20 > > So what you're saying here is that a conference will only=20 > > terminate when the last participant leaves? I think I'm ok=20 > with that. > >=20 > > /Hisham > >=20 > > > I've never encountered=20 > > > a public bridge that actually tore down the connection,=20 > although I=20 > > > know of at least one enterprise class bridge that does this=20 > > > (and we HATED it). > > >=20 > > > I know I was assuming GMT. > > >=20 > > > Brian > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 04:52:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28095 for ; Wed, 4 Feb 2004 04:52:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJhT-0007bU-My for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 04:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149q3qS029226 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 04:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJhS-0007bJ-Mg for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28089 for ; Wed, 4 Feb 2004 04:51:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJhP-0005IA-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJgR-0005DP-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:50:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoJfV-00058l-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 04:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJfU-0007VC-K0; Wed, 04 Feb 2004 04:50:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJea-0007Tl-AU for xcon@optimus.ietf.org; Wed, 04 Feb 2004 04:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28044 for ; Wed, 4 Feb 2004 04:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJeX-00053E-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJdY-0004xt-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:48:01 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AoJd8-0004tO-00 for xcon@ietf.org; Wed, 04 Feb 2004 04:47:34 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i149kx719548 for ; Wed, 4 Feb 2004 03:47:00 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 09:46:58 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B1B13B0@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Cullen Jennings , Eric Burger , XCON-IETF Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Wed, 4 Feb 2004 09:46:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In the current mechanisms I know of for supporting legal intercept (in 3GPP), the interceptor would not even be a participant, therefore I am not convinced that this is relevant to the issue of hidden participants anyway. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 03 February 2004 17:08 > To: Eric Burger; XCON-IETF > Subject: Re: [XCON] CPCP Requirement: Hidden Participants > > > > I don't care if we support hidden participants but I feel that the > requirements for Legal Intercept should definitely be out. > There are way too > many land minds over yonder and it is not the point of this > WG to solve > those. > > Cullen > > > > On 1/20/04 8:00 AM, "Eric Burger" wrote: > > > Would Legal Intercept be in or out? E.g., hidden > participants that CANNOT be > > known. > > > >> -----Original Message----- > >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >> Sent: Friday, December 19, 2003 6:14 AM > >> To: hisham.khartabil@nokia.com; mhammer@cisco.com > >> Cc: xcon@ietf.org > >> Subject: RE: [XCON] CPCP Requirement: Hidden Participants > >> > >> > >> I believe hidden users are appropriate. > >> > >> I do not believe that this adds complexity to the > >> specifications (particularly to the specification of CPCP), > >> so I see no need to make it a DEFER as far as the > >> specifications are concerned. It may add complexity to the > >> implementation, so I am quite happy to see it a MAY in the > >> requirements, so that it is optional to implement. > >> > >> As regards the legal implications of hidden users, then yes, > >> there may be priveleged users that are able to request the > >> identity of hidden users (along with an indication that they > >> are hidden). This of course requires the enabling of such a > >> privileged user in the first place. > >> > >> Secondly, it may not be necessary to identify hidden users, > >> but merely that there are hidden users in the conference (in > >> addition to any that may have made themselves visible). Some > >> countries require some form of tone or announcement on voice > >> conferences when someone else is listening in. They also > >> require an announcement or other indication in the call is > >> being recorded. > >> > >> regards > >> > >> Keith > >> > >> Keith Drage > >> Lucent Technologies > >> drage@lucent.com > >> tel: +44 1793 776249 > >> > >> > >>> -----Original Message----- > >>> From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > >>> Sent: 15 December 2003 16:29 > >>> To: mhammer@cisco.com > >>> Cc: xcon@ietf.org > >>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: ext Michael Hammer [mailto:mhammer@cisco.com] > >>>> Sent: 15.December.2003 18:17 > >>>> To: Khartabil Hisham (NMP-MSW/Helsinki) > >>>> Cc: xcon@ietf.org > >>>> Subject: Re: [XCON] CPCP Requirement: Hidden Participants > >>>> > >>>> > >>>> Related to this is there a requirement that, while not > >>> revealing the > >>>> identity of a hidden user, the conference policy contains > >>>> state indication > >>>> about either the presence of hidden users, or the > >>>> possibility/preclusion > >>>> that such hidden users may be present? > >>>> > >>>> I am anticipating that: > >>>> 1) Laws may exist that require notification of such. > >>> > >>> That's a good point. This might require changes to the > >>> conference event package to indicate if there are hidden > >>> participants or not, and if so, how many. > >>> > >>> The question remain: is there a need for such a feature (to > >>> hide users?)? > >>> > >>> Regards, > >>> Hisham > >>> > >>>> 2) In some conferences, participants may want technical > >>>> assurance that > >>>> hidden users are not possible before they speak. > >>>> > >>>> Mike > >>>> > >>>> > >>>> At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > >>>>> This is in reference to requirements REQ-A7 and REQ-E10 in > >>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt >>>> >>>> REQ-A7: It SHOULD be possible to participate in a >> conference as a >>>> hidden user. Hidden user is present in a conference, but >>> his presence >>>> is not revealed. >>>> >>>> REQ-E10: It MUST be possible to allow and disallow >>> hidden membership >>>> in a conference. >>>> >>>> Should a conference policy, using CPCP, specify if a user >>> can be hidden? >>>> This means that the conference state package does not report the >>>> participation on the hidden user. CPCP is used to identify >>> which users are >>>> hidden. The list of hidden users is only manipulated by a >>> privileged user >>>> such as the moderator. >>>> >>>> Regards, >>>> Hisham >>>> >>>> _______________________________________________ >>>> 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 From exim@www1.ietf.org Wed Feb 4 05:46:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29888 for ; Wed, 4 Feb 2004 05:46:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKXV-0002Z7-II for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 05:45:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14AjnOJ009857 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 05:45:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKXV-0002Yu-Bo for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 05:45:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29782 for ; Wed, 4 Feb 2004 05:45:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoKXR-00039X-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 05:45:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoKWK-0002wr-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 05:44:37 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AoKVW-0002m2-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 05:43:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AoKN5-0005dt-EU for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 05:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKN4-0001F6-50; Wed, 04 Feb 2004 05:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKM8-0001Co-Dt for xcon@optimus.ietf.org; Wed, 04 Feb 2004 05:34:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29452 for ; Wed, 4 Feb 2004 05:34:00 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoKM4-0001xm-00 for xcon@ietf.org; Wed, 04 Feb 2004 05:34:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoKL7-0001t9-00 for xcon@ietf.org; Wed, 04 Feb 2004 05:33:02 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AoKL1-0001ou-00 for xcon@ietf.org; Wed, 04 Feb 2004 05:32:55 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14AWt228610 for ; Wed, 4 Feb 2004 12:32:55 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 12:32:53 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 12:32:53 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Wed, 4 Feb 2004 12:32:51 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976DC@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPrBFI1bMtYRdwGSGeFqyDCB4WGiQABbbfQ To: , , , X-OriginalArrivalTime: 04 Feb 2004 10:32:53.0639 (UTC) FILETIME=[3F0AF970:01C3EB0A] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Keith. That's why we removed hidden participants and are = content with anonymous. Legal interception can be local implementation = and policy. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Drage, Keith (Keith) > Sent: 04.February.2004 11:47 > To: Cullen Jennings; Eric Burger; XCON-IETF > Subject: RE: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > In the current mechanisms I know of for supporting legal=20 > intercept (in 3GPP), the interceptor would not even be a=20 > participant, therefore I am not convinced that this is=20 > relevant to the issue of hidden participants anyway. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 03 February 2004 17:08 > > To: Eric Burger; XCON-IETF > > Subject: Re: [XCON] CPCP Requirement: Hidden Participants > >=20 > >=20 > >=20 > > I don't care if we support hidden participants but I feel that the > > requirements for Legal Intercept should definitely be out.=20 > > There are way too > > many land minds over yonder and it is not the point of this=20 > > WG to solve > > those.=20 > >=20 > > Cullen > >=20 > >=20 > >=20 > > On 1/20/04 8:00 AM, "Eric Burger" wrote: > >=20 > > > Would Legal Intercept be in or out? E.g., hidden=20 > > participants that CANNOT be > > > known. > > >=20 > > >> -----Original Message----- > > >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > >> Sent: Friday, December 19, 2003 6:14 AM > > >> To: hisham.khartabil@nokia.com; mhammer@cisco.com > > >> Cc: xcon@ietf.org > > >> Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > >>=20 > > >>=20 > > >> I believe hidden users are appropriate. > > >>=20 > > >> I do not believe that this adds complexity to the > > >> specifications (particularly to the specification of CPCP), > > >> so I see no need to make it a DEFER as far as the > > >> specifications are concerned. It may add complexity to the > > >> implementation, so I am quite happy to see it a MAY in the > > >> requirements, so that it is optional to implement. > > >>=20 > > >> As regards the legal implications of hidden users, then yes, > > >> there may be priveleged users that are able to request the > > >> identity of hidden users (along with an indication that they > > >> are hidden). This of course requires the enabling of such a > > >> privileged user in the first place. > > >>=20 > > >> Secondly, it may not be necessary to identify hidden users, > > >> but merely that there are hidden users in the conference (in > > >> addition to any that may have made themselves visible). Some > > >> countries require some form of tone or announcement on voice > > >> conferences when someone else is listening in. They also > > >> require an announcement or other indication in the call is > > >> being recorded. > > >>=20 > > >> regards > > >>=20 > > >> Keith > > >>=20 > > >> Keith Drage > > >> Lucent Technologies > > >> drage@lucent.com > > >> tel: +44 1793 776249 > > >>=20 > > >>=20 > > >>> -----Original Message----- > > >>> From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > >>> Sent: 15 December 2003 16:29 > > >>> To: mhammer@cisco.com > > >>> Cc: xcon@ietf.org > > >>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > >>>=20 > > >>>=20 > > >>>=20 > > >>>=20 > > >>>> -----Original Message----- > > >>>> From: ext Michael Hammer [mailto:mhammer@cisco.com] > > >>>> Sent: 15.December.2003 18:17 > > >>>> To: Khartabil Hisham (NMP-MSW/Helsinki) > > >>>> Cc: xcon@ietf.org > > >>>> Subject: Re: [XCON] CPCP Requirement: Hidden Participants > > >>>>=20 > > >>>>=20 > > >>>> Related to this is there a requirement that, while not > > >>> revealing the=20 > > >>>> identity of a hidden user, the conference policy contains > > >>>> state indication > > >>>> about either the presence of hidden users, or the > > >>>> possibility/preclusion > > >>>> that such hidden users may be present? > > >>>>=20 > > >>>> I am anticipating that: > > >>>> 1) Laws may exist that require notification of such. > > >>>=20 > > >>> That's a good point. This might require changes to the > > >>> conference event package to indicate if there are hidden > > >>> participants or not, and if so, how many. > > >>>=20 > > >>> The question remain: is there a need for such a feature (to > > >>> hide users?)? > > >>>=20 > > >>> Regards, > > >>> Hisham > > >>>=20 > > >>>> 2) In some conferences, participants may want technical > > >>>> assurance that > > >>>> hidden users are not possible before they speak. > > >>>>=20 > > >>>> Mike > > >>>>=20 > > >>>>=20 > > >>>> At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > >>>>> This is in reference to requirements REQ-A7 and REQ-E10 in > > >>>>=20 > > >>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > >>>>=20 > >>>> REQ-A7: It SHOULD be possible to participate in a > >> conference as a > >>>> hidden user. Hidden user is present in a conference, but > >>> his presence > >>>> is not revealed. > >>>>=20 > >>>> REQ-E10: It MUST be possible to allow and disallow > >>> hidden membership > >>>> in a conference. > >>>>=20 > >>>> Should a conference policy, using CPCP, specify if a user > >>> can be hidden?=20 > >>>> This means that the conference state package does not report the > >>>> participation on the hidden user. CPCP is used to identify > >>> which users are > >>>> hidden. The list of hidden users is only manipulated by a > >>> privileged user > >>>> such as the moderator. > >>>>=20 > >>>> Regards, > >>>> Hisham > >>>>=20 > >>>> _______________________________________________ > >>>> XCON mailing list > >>>> XCON@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> XCON mailing list > >> XCON@ietf.org > >> https://www1.ietf.org/mailman/listinfo/xcon > >>=20 > >> _______________________________________________ > >> XCON mailing list > >> XCON@ietf.org > >> https://www1.ietf.org/mailman/listinfo/xcon > >>=20 > >>=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 06:27:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01014 for ; Wed, 4 Feb 2004 06:27:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLBW-0004Rq-Rm for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 06:27:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14BRAva017092 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 06:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLBW-0004Rb-Ks for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 06:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01009 for ; Wed, 4 Feb 2004 06:27:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLBS-0007EN-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 06:27:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLAa-00079b-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 06:26:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLAL-000742-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 06:25:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLAO-0004N8-UP; Wed, 04 Feb 2004 06:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoL9W-0004MW-E0 for xcon@optimus.ietf.org; Wed, 04 Feb 2004 06:25:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00927 for ; Wed, 4 Feb 2004 06:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoL9S-00071w-00 for xcon@ietf.org; Wed, 04 Feb 2004 06:25:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoL8T-0006vL-00 for xcon@ietf.org; Wed, 04 Feb 2004 06:24:02 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AoL7S-0006kI-00 for xcon@ietf.org; Wed, 04 Feb 2004 06:22:58 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14BMQo23981 for ; Wed, 4 Feb 2004 05:22:27 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 11:22:25 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFCB@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 11:22:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 From exim@www1.ietf.org Wed Feb 4 06:37:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01323 for ; Wed, 4 Feb 2004 06:37:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLL8-0004xu-Nn for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 06:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Bb6eT019080 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 06:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLL8-0004xf-0Y for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 06:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01317 for ; Wed, 4 Feb 2004 06:37:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLL4-0000FD-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 06:37:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLK5-0000Ab-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 06:36:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLJ7-00005d-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 06:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLJ8-0004so-Sq; Wed, 04 Feb 2004 06:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLIK-0004nD-1I for xcon@optimus.ietf.org; Wed, 04 Feb 2004 06:34:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01249 for ; Wed, 4 Feb 2004 06:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLIG-00000O-00 for xcon@ietf.org; Wed, 04 Feb 2004 06:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLHL-0007jH-00 for xcon@ietf.org; Wed, 04 Feb 2004 06:33:12 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly10a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AoLGz-0007dr-00 for xcon@ietf.org; Wed, 04 Feb 2004 06:32:49 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly10a.srv.mailcontrol.com (MailControl) with SMTP id i14BWIYF002264; Wed, 4 Feb 2004 11:32:18 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Wed, 4 Feb 2004 11:32:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 11:32:18 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B184@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPrEa85EQIXKcXkRXeD6RL/FAsrWAAAE0NA From: "Chris Boulton" To: "Drage, Keith (Keith)" , X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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. >-----Original Message----- >From: Drage, Keith (Keith) [mailto:drage@lucent.com] >Sent: 04 February 2004 11:22 >To: xcon@ietf.org >Subject: RE: [XCON] CPCP Requirement: Repeat times > >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 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 07:07:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02776 for ; Wed, 4 Feb 2004 07:07:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLoW-000734-FQ for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 07:07:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14C7Sk7027093 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 07:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLoW-00072m-06 for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02769 for ; Wed, 4 Feb 2004 07:07:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLoR-0003dS-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLnd-0003Wi-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:06:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLn5-0003OA-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLn7-0006p2-FJ; Wed, 04 Feb 2004 07:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLmL-0006nK-T9 for xcon@optimus.ietf.org; Wed, 04 Feb 2004 07:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02611 for ; Wed, 4 Feb 2004 07:05:09 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLmH-0003KX-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:05:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLlO-0003Aa-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:04:15 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AoLkA-0002r3-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:02:58 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14C2wM11740 for ; Wed, 4 Feb 2004 14:02:58 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 14:02:43 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 14:02:44 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 14:02:43 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 14:02:42 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976E1@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPrEem0kP6zT5l+QoWC9GuDQ60MjgABIIjw To: , X-OriginalArrivalTime: 04 Feb 2004 12:02:43.0514 (UTC) FILETIME=[CBA8A1A0:01C3EB16] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Drage, Keith (Keith) > Sent: 04.February.2004 13:22 > To: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > This distinction of what happens when the conference creator=20 > leaves is the current distinction between existing enterprise=20 > network and public network usage of add-on conference service=20 > outside of SIP. >=20 > In enterprise networks, the conference continues after the=20 > creator leaves, possibly effecting a transfer if down to two parties. >=20 > In the public network, the conference creator is generally=20 > the conference owner and paying for the conference bridge,=20 > and some or all of the connection resources to that bridge.=20 > As the conference owner would have no control of the cost=20 > after he leaves the conference the conference would terminate=20 > when the conference owner leaves. >=20 > If the conference owner/creator has a means of transferring=20 > the ownership, and therefore the charges, or if the=20 > conference owner can still supervise the charges after he=20 > ceases to be a participant, then there is not necessarily a=20 > need to clear such a conference when the creator leaves. >=20 > regards >=20 > Keith >=20 > > -----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=20 > >=20 > >=20 > > Brian is suggesting that stop-time means that the conference=20 > > creator will leave the conference at that time. At least this=20 > > is how I understood it. > >=20 > > This leaves the rest of the participants hanging around still=20 > > in the conference. I also ok with stop-time meaning all=20 > > participants will get a BYE. > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: Koskelainen Petri (Nokia-NRC/Tampere)=20 > > > 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=20 > > >=20 > > >=20 > > > > So what you're saying here is that a conference will only=20 > > > > terminate when the last participant leaves? I think I'm ok=20 > > > with that. > > >=20 > > > Actually, I don't think that was the idea. Besides, I'd not=20 > > be happy=20 > > > if I create (and pay) the conference (start time 2pm, and=20 > > > stop time 3pm),=20 > > > and other people stay there for days. > > >=20 > > > I think it is better to stop the conference as defined by the=20 > > > stop time.=20 > > > Some vendors may add polite warning 10 min before the stop=20 > > > time ("this conference will end soon..")=20 > > > or if you have credit left it may be automatically extended=20 > > > for some reasonable time if=20 > > > there are resources and people hanging on (especially the=20 > creator).=20 > > > No guarantees though, it is just best effort as Roni said.=20 > > >=20 > > > Anyway, we are now talking about solutions, not requirements. > > >=20 > > > -- > > > Petri > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > 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=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > Behalf Of ext > > > > > Rosen, Brian > > > > > Sent: 03.February.2004 20:37 > > > > > To: 'Cullen Jennings'; XCON-IETF > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > >=20 > > > > >=20 > > > > > Conventional conference bridges use a start time. =20 > Its the time > > > > > that the mixing starts. Most will let you connect=20 > > shortly before > > > > > start time, but would give you "music on hold" or some=20 > > equivalent. > > > > > Dial out would often be related to this (dial out=20 > > shortly before). > > > > >=20 > > > > > I think we can live with that definition. > > > > >=20 > > > > > Stop time, like it or not for most bridges I know is=20 > > expected stop > > > > > time of the person scheduling the conference. =20 > > > >=20 > > > > So what you're saying here is that a conference will only=20 > > > > terminate when the last participant leaves? I think I'm ok=20 > > > with that. > > > >=20 > > > > /Hisham > > > >=20 > > > > > I've never encountered=20 > > > > > a public bridge that actually tore down the connection,=20 > > > although I=20 > > > > > know of at least one enterprise class bridge that does this=20 > > > > > (and we HATED it). > > > > >=20 > > > > > I know I was assuming GMT. > > > > >=20 > > > > > Brian > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 07:17:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03087 for ; Wed, 4 Feb 2004 07:17:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLxv-0007rp-19 for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 07:17:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14CHAl8030235 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 07:17:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLxu-0007ra-L9 for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03081 for ; Wed, 4 Feb 2004 07:17:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLxu-0004cE-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:17:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLx0-0004XJ-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:16:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLwo-0004Ru-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLwn-0007ng-VT; Wed, 04 Feb 2004 07:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLw5-0007kv-QI for xcon@optimus.ietf.org; Wed, 04 Feb 2004 07:15:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03016 for ; Wed, 4 Feb 2004 07:15:14 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLw5-0004QH-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLv9-0004K9-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:14:20 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AoLuI-0004DX-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:13:26 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14CDP208871 for ; Wed, 4 Feb 2004 14:13:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 14:13:24 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 14:13:23 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 14:13:22 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 14:13:22 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976E3@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPrEem0kP6zT5l+QoWC9GuDQ60MjgABIIjwAABRlVA= To: , , X-OriginalArrivalTime: 04 Feb 2004 12:13:22.0563 (UTC) FILETIME=[488FC530:01C3EB18] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable crucial spelling mistake corrected :) Sorry about that. > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 04.February.2004 14:03 > To: drage@lucent.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > I'm contradicting myself here, but thinking about it more, I=20 > think it is better that a conference terminates with=20 ^^^^ > stop-time. The creator is free to set the stop-time to be the=20 > time he leaves (and therefore the conference terminates when=20 > he leaves), terminate the conference as he leaves, or leave=20 > before the stop-time and therefore the conference continues. >=20 > /Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Drage, Keith (Keith) > > Sent: 04.February.2004 13:22 > > To: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > This distinction of what happens when the conference creator=20 > > leaves is the current distinction between existing enterprise=20 > > network and public network usage of add-on conference service=20 > > outside of SIP. > >=20 > > In enterprise networks, the conference continues after the=20 > > creator leaves, possibly effecting a transfer if down to=20 > two parties. > >=20 > > In the public network, the conference creator is generally=20 > > the conference owner and paying for the conference bridge,=20 > > and some or all of the connection resources to that bridge.=20 > > As the conference owner would have no control of the cost=20 > > after he leaves the conference the conference would terminate=20 > > when the conference owner leaves. > >=20 > > If the conference owner/creator has a means of transferring=20 > > the ownership, and therefore the charges, or if the=20 > > conference owner can still supervise the charges after he=20 > > ceases to be a participant, then there is not necessarily a=20 > > need to clear such a conference when the creator leaves. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [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=20 > > >=20 > > >=20 > > > Brian is suggesting that stop-time means that the conference=20 > > > creator will leave the conference at that time. At least this=20 > > > is how I understood it. > > >=20 > > > This leaves the rest of the participants hanging around still=20 > > > in the conference. I also ok with stop-time meaning all=20 > > > participants will get a BYE. > > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: Koskelainen Petri (Nokia-NRC/Tampere)=20 > > > > Sent: 04.February.2004 11:16 > > > > To: Khartabil Hisham (Nokia-TP/Helsinki);=20 > Brian.Rosen@marconi.com; > > > > fluffy@cisco.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > > So what you're saying here is that a conference will only=20 > > > > > terminate when the last participant leaves? I think I'm ok=20 > > > > with that. > > > >=20 > > > > Actually, I don't think that was the idea. Besides, I'd not=20 > > > be happy=20 > > > > if I create (and pay) the conference (start time 2pm, and=20 > > > > stop time 3pm),=20 > > > > and other people stay there for days. > > > >=20 > > > > I think it is better to stop the conference as defined by the=20 > > > > stop time.=20 > > > > Some vendors may add polite warning 10 min before the stop=20 > > > > time ("this conference will end soon..")=20 > > > > or if you have credit left it may be automatically extended=20 > > > > for some reasonable time if=20 > > > > there are resources and people hanging on (especially the=20 > > creator).=20 > > > > No guarantees though, it is just best effort as Roni said.=20 > > > >=20 > > > > Anyway, we are now talking about solutions, not requirements. > > > >=20 > > > > -- > > > > Petri > > > >=20 > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > 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=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > > Behalf Of ext > > > > > > Rosen, Brian > > > > > > Sent: 03.February.2004 20:37 > > > > > > To: 'Cullen Jennings'; XCON-IETF > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Conventional conference bridges use a start time. =20 > > Its the time > > > > > > that the mixing starts. Most will let you connect=20 > > > shortly before > > > > > > start time, but would give you "music on hold" or some=20 > > > equivalent. > > > > > > Dial out would often be related to this (dial out=20 > > > shortly before). > > > > > >=20 > > > > > > I think we can live with that definition. > > > > > >=20 > > > > > > Stop time, like it or not for most bridges I know is=20 > > > expected stop > > > > > > time of the person scheduling the conference. =20 > > > > >=20 > > > > > So what you're saying here is that a conference will only=20 > > > > > terminate when the last participant leaves? I think I'm ok=20 > > > > with that. > > > > >=20 > > > > > /Hisham > > > > >=20 > > > > > > I've never encountered=20 > > > > > > a public bridge that actually tore down the connection,=20 > > > > although I=20 > > > > > > know of at least one enterprise class bridge that does this=20 > > > > > > (and we HATED it). > > > > > >=20 > > > > > > I know I was assuming GMT. > > > > > >=20 > > > > > > Brian > > > > >=20 > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 07:42:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03997 for ; Wed, 4 Feb 2004 07:42:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMM2-0001cA-G6 for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 07:42:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Cg6bJ006205 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 07:42:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMM2-0001c0-9F for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:42:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03985 for ; Wed, 4 Feb 2004 07:42:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMM1-000715-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:42:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoML3-0006tk-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:41:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMK3-0006lx-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMK1-0000yn-GK; Wed, 04 Feb 2004 07:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMJL-0000tA-P8 for xcon@optimus.ietf.org; Wed, 04 Feb 2004 07:39:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03644 for ; Wed, 4 Feb 2004 07:39:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMJK-0006js-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:39:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMIL-0006dz-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:38:18 -0500 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AoMHo-0006XH-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:37:45 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <12XFP7VD>; Wed, 4 Feb 2004 14:37:11 +0200 Message-ID: From: "Even, Roni" To: "'hisham.khartabil@nokia.com'" , drage@lucent.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 14:37:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Wednesday, February 04, 2004 2:03 PM To: drage@lucent.com; xcon@ietf.org 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 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Drage, Keith (Keith) > Sent: 04.February.2004 13:22 > To: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > 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 > _______________________________________________ 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 From exim@www1.ietf.org Wed Feb 4 07:44:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04047 for ; Wed, 4 Feb 2004 07:44:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMOE-0001jr-BY for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 07:44:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14CiMlp006677 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 07:44:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMOE-0001jb-5x for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:44:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04041 for ; Wed, 4 Feb 2004 07:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMOD-0007Ha-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:44:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMNP-0007Ba-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:43:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMMv-00073r-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMMv-0001fo-Bj; Wed, 04 Feb 2004 07:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMM3-0001cI-L4 for xcon@optimus.ietf.org; Wed, 04 Feb 2004 07:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03989 for ; Wed, 4 Feb 2004 07:42:06 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMM2-00071I-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:42:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoML4-0006ty-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:41:07 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AoMK8-0006pI-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:40:08 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14Ce6222350 for ; Wed, 4 Feb 2004 14:40:06 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Feb 2004 14:40:06 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 14:40:06 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 14:40:05 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976E6@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPrG6ApXiSmo95LRYWsTcxVLgI8egAAFQEg To: , , X-OriginalArrivalTime: 04 Feb 2004 12:40:06.0163 (UTC) FILETIME=[0461B630:01C3EB1C] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes. > -----Original Message----- > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > Sent: 04.February.2004 14:37 > To: Khartabil Hisham (Nokia-TP/Helsinki); drage@lucent.com; > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hisham, > I assume that you also want to allow the stop time to be=20 > changed by the > conference creator, during the conference, to allow extension of the > conference based on best effort > Roni >=20 > ************************************* > Roni Even > VP Product Planning > Polycom Israel >=20 > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* >=20 >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, February 04, 2004 2:03 PM > To: drage@lucent.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > I'm contradicting myself here, but thinking about it more, I=20 > think it is > better than a conference terminates with stop-time. The=20 > creator is free to > set the stop-time to be the time he leaves (and therefore the=20 > conference > terminates when he leaves), terminate the conference as he=20 > leaves, or leave > before the stop-time and therefore the conference continues. >=20 > /Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Drage, Keith (Keith) > > Sent: 04.February.2004 13:22 > > To: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > >=20 > >=20 > > This distinction of what happens when the conference creator=20 > > leaves is the current distinction between existing enterprise=20 > > network and public network usage of add-on conference service=20 > > outside of SIP. > >=20 > > In enterprise networks, the conference continues after the=20 > > creator leaves, possibly effecting a transfer if down to=20 > two parties. > >=20 > > In the public network, the conference creator is generally=20 > > the conference owner and paying for the conference bridge,=20 > > and some or all of the connection resources to that bridge.=20 > > As the conference owner would have no control of the cost=20 > > after he leaves the conference the conference would terminate=20 > > when the conference owner leaves. > >=20 > > If the conference owner/creator has a means of transferring=20 > > the ownership, and therefore the charges, or if the=20 > > conference owner can still supervise the charges after he=20 > > ceases to be a participant, then there is not necessarily a=20 > > need to clear such a conference when the creator leaves. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [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=20 > > >=20 > > >=20 > > > Brian is suggesting that stop-time means that the conference=20 > > > creator will leave the conference at that time. At least this=20 > > > is how I understood it. > > >=20 > > > This leaves the rest of the participants hanging around still=20 > > > in the conference. I also ok with stop-time meaning all=20 > > > participants will get a BYE. > > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: Koskelainen Petri (Nokia-NRC/Tampere)=20 > > > > Sent: 04.February.2004 11:16 > > > > To: Khartabil Hisham (Nokia-TP/Helsinki);=20 > Brian.Rosen@marconi.com; > > > > fluffy@cisco.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > >=20 > > > >=20 > > > > > So what you're saying here is that a conference will only=20 > > > > > terminate when the last participant leaves? I think I'm ok=20 > > > > with that. > > > >=20 > > > > Actually, I don't think that was the idea. Besides, I'd not=20 > > > be happy=20 > > > > if I create (and pay) the conference (start time 2pm, and=20 > > > > stop time 3pm),=20 > > > > and other people stay there for days. > > > >=20 > > > > I think it is better to stop the conference as defined by the=20 > > > > stop time.=20 > > > > Some vendors may add polite warning 10 min before the stop=20 > > > > time ("this conference will end soon..")=20 > > > > or if you have credit left it may be automatically extended=20 > > > > for some reasonable time if=20 > > > > there are resources and people hanging on (especially the=20 > > creator).=20 > > > > No guarantees though, it is just best effort as Roni said.=20 > > > >=20 > > > > Anyway, we are now talking about solutions, not requirements. > > > >=20 > > > > -- > > > > Petri > > > >=20 > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > 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=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > > Behalf Of ext > > > > > > Rosen, Brian > > > > > > Sent: 03.February.2004 20:37 > > > > > > To: 'Cullen Jennings'; XCON-IETF > > > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 > > > > > >=20 > > > > > >=20 > > > > > > Conventional conference bridges use a start time. =20 > > Its the time > > > > > > that the mixing starts. Most will let you connect=20 > > > shortly before > > > > > > start time, but would give you "music on hold" or some=20 > > > equivalent. > > > > > > Dial out would often be related to this (dial out=20 > > > shortly before). > > > > > >=20 > > > > > > I think we can live with that definition. > > > > > >=20 > > > > > > Stop time, like it or not for most bridges I know is=20 > > > expected stop > > > > > > time of the person scheduling the conference. =20 > > > > >=20 > > > > > So what you're saying here is that a conference will only=20 > > > > > terminate when the last participant leaves? I think I'm ok=20 > > > > with that. > > > > >=20 > > > > > /Hisham > > > > >=20 > > > > > > I've never encountered=20 > > > > > > a public bridge that actually tore down the connection,=20 > > > > although I=20 > > > > > > know of at least one enterprise class bridge that does this=20 > > > > > > (and we HATED it). > > > > > >=20 > > > > > > I know I was assuming GMT. > > > > > >=20 > > > > > > Brian > > > > >=20 > > > > > _______________________________________________ > > > > > XCON mailing list > > > > > XCON@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 07:53:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04155 for ; Wed, 4 Feb 2004 07:53:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMWh-00029A-Ty for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 07:53:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Cr7qZ008246 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 07:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMWh-00028v-Nm for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:53:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04152 for ; Wed, 4 Feb 2004 07:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMWh-0000Dp-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:53:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMVk-00009e-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:52:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMVb-00005G-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 07:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMVc-00026W-2u; Wed, 04 Feb 2004 07:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMUm-00025W-Ux for xcon@optimus.ietf.org; Wed, 04 Feb 2004 07:51:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04134 for ; Wed, 4 Feb 2004 07:51:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMUm-00004k-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:51:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMTr-000005-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:50:12 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AoMSu-0007dz-00 for xcon@ietf.org; Wed, 04 Feb 2004 07:49:12 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 07:48:42 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B638E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , roni.even@polycom.co.il, drage@lucent.com, xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Wed, 4 Feb 2004 07:48:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, February 04, 2004 7:40 AM > To: roni.even@polycom.co.il; drage@lucent.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > Yes. > > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 04.February.2004 14:37 > > To: Khartabil Hisham (Nokia-TP/Helsinki); drage@lucent.com; > > xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > 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 > > > > ************************************* > > Roni Even > > VP Product Planning > > Polycom Israel > > > > Tel: +972-3-9251200 > > Cell: +972-55-481099 > > email:roni.even@polycom.co.il > > ******************************************* > > > > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, February 04, 2004 2:03 PM > > To: drage@lucent.com; xcon@ietf.org > > 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 > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > Behalf Of ext > > > Drage, Keith (Keith) > > > Sent: 04.February.2004 13:22 > > > To: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > 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 > > > > > > > _______________________________________________ > > 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 From exim@www1.ietf.org Wed Feb 4 08:37:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05172 for ; Wed, 4 Feb 2004 08:37:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNDY-00051D-Q2 for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 08:37:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14DbOHJ019280 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 08:37:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNDX-00050q-LH for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 08:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05168 for ; Wed, 4 Feb 2004 08:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNDW-0004Ek-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 08:37:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNCk-00048a-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 08:36:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoNCD-00040h-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 08:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNCD-0004mM-3Z; Wed, 04 Feb 2004 08:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNBP-0004g1-9v for xcon@optimus.ietf.org; Wed, 04 Feb 2004 08:35:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05128 for ; Wed, 4 Feb 2004 08:35:09 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNBO-0003xT-00 for xcon@ietf.org; Wed, 04 Feb 2004 08:35:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNAT-0003sN-00 for xcon@ietf.org; Wed, 04 Feb 2004 08:34:13 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AoN9t-0003nE-00 for xcon@ietf.org; Wed, 04 Feb 2004 08:33:37 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14DXa217188 for ; Wed, 4 Feb 2004 15:33:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 4 Feb 2004 15:33:36 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 15:33:36 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 15:33:35 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2004 15:33:35 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976ED@esebe019.ntc.nokia.com> Thread-Topic: New version submission: draft-koskelainen-xcon-xcap-cpcp-usage-02.txt Thread-Index: AcPrI30w9+iwK8y1TsmX6P0umWMMAA== To: X-OriginalArrivalTime: 04 Feb 2004 13:33:35.0943 (UTC) FILETIME=[7D8F4570:01C3EB23] Content-Transfer-Encoding: quoted-printable Subject: [XCON] New version submission: draft-koskelainen-xcon-xcap-cpcp-usage-02.txt Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable A new version of the XCAP usage for CPCP has been submitted. Until is = appears in the IETF archive, you can fetch it from the following = location: http://sip.research.nokia.com/sipster/drafts/draft-koskelainen-xcon-cpcp-= usage-02.txt There is still one open issue. It has something to do with how a server = behaves when the conference URI suggested by the client is already = taken. This is an XCAP specific issue and is still being debated on the = SIMPLE list. The following changes were made: - Added Conference-floor-policy schema - Added simple Conference-media-policy schema - Fixed errors in schema - Added more elaborate text to every section - Created new sections describing conference entities' behaviour and how = focus communicates with XCAP server. - Multiple URIs are now allowed per conference to accommodate for = different signalling protocols - Described XML elements in more detail - Described Conference-time in different scenarios and how start-time = and stop-time can be used. - Removed Repeat-time from conference-time - Removed hidden user capability - Removed Dial-out list feature that allowed the focus to re-dial a user = if not reached - Aligned the draft with the new XCAP version (use of PUT) - Added language attribute into the conference-info - Updated references - Updated examples Thanks, Hisham _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 08:48:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05593 for ; Wed, 4 Feb 2004 08:48:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNO0-0005wB-1F for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 08:48:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14DmBrY022817 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 08:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNNz-0005vw-S0 for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 08:48:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05585 for ; Wed, 4 Feb 2004 08:48:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNNy-0005RJ-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 08:48:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNN5-0005Mc-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 08:47:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoNMq-0005Hd-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 08:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNMq-0005ri-Ht; Wed, 04 Feb 2004 08:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNMD-0005kP-DT for xcon@optimus.ietf.org; Wed, 04 Feb 2004 08:46:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05547 for ; Wed, 4 Feb 2004 08:46:19 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNMC-0005H2-00 for xcon@ietf.org; Wed, 04 Feb 2004 08:46:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNLB-0005BC-00 for xcon@ietf.org; Wed, 04 Feb 2004 08:45:18 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AoNKw-00055L-00 for xcon@ietf.org; Wed, 04 Feb 2004 08:45:02 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14Dj1M17325 for ; Wed, 4 Feb 2004 15:45:01 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 4 Feb 2004 15:45:00 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 15:44:59 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] New version submission: draft-koskelainen-xcon-xcap-cpcp-usage-02.txt Date: Wed, 4 Feb 2004 15:44:59 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017976EF@esebe019.ntc.nokia.com> Thread-Topic: New version submission: draft-koskelainen-xcon-xcap-cpcp-usage-02.txt Thread-Index: AcPrI30w9+iwK8y1TsmX6P0umWMMAAAAYGOA To: , X-OriginalArrivalTime: 04 Feb 2004 13:44:59.0722 (UTC) FILETIME=[151FAAA0:01C3EB25] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Apologies, I gave you the wrong link. Here is the correct one: http://www.cs.tut.fi/~petkos/draft-koskelainen-xcon-xcap-cpcp-usage-02.tx= t /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 04.February.2004 15:34 > To: xcon@ietf.org > Subject: [XCON] New version submission: > draft-koskelainen-xcon-xcap-cpcp-usage-02.txt >=20 >=20 > A new version of the XCAP usage for CPCP has been submitted.=20 > Until is appears in the IETF archive, you can fetch it from=20 > the following location: >=20 > http://sip.research.nokia.com/sipster/drafts/draft-koskelainen > -xcon-cpcp-usage-02.txt >=20 > There is still one open issue. It has something to do with=20 > how a server behaves when the conference URI suggested by the=20 > client is already taken. This is an XCAP specific issue and=20 > is still being debated on the SIMPLE list. >=20 > The following changes were made: >=20 > - Added Conference-floor-policy schema > - Added simple Conference-media-policy schema > - Fixed errors in schema > - Added more elaborate text to every section > - Created new sections describing conference entities'=20 > behaviour and how focus communicates with XCAP server. > - Multiple URIs are now allowed per conference to accommodate=20 > for different signalling protocols > - Described XML elements in more detail > - Described Conference-time in different scenarios and how=20 > start-time and stop-time can be used. > - Removed Repeat-time from conference-time > - Removed hidden user capability > - Removed Dial-out list feature that allowed the focus to=20 > re-dial a user if not reached > - Aligned the draft with the new XCAP version (use of PUT) > - Added language attribute into the conference-info > - Updated references > - Updated examples >=20 > Thanks, > Hisham >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 4 13:11:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18645 for ; Wed, 4 Feb 2004 13:11:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRUm-0000f6-BD for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 13:11:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14IBSW4002538 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 13:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRUm-0000er-5n for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 13:11:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18640 for ; Wed, 4 Feb 2004 13:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRUk-0002uG-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 13:11:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRTq-0002oT-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 13:10:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoRTO-0002iA-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 13:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRTO-0000Vt-AB; Wed, 04 Feb 2004 13:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRT3-0000TH-30 for xcon@optimus.ietf.org; Wed, 04 Feb 2004 13:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18499 for ; Wed, 4 Feb 2004 13:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRT1-0002gI-00 for xcon@ietf.org; Wed, 04 Feb 2004 13:09:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRRz-0002Z4-00 for xcon@ietf.org; Wed, 04 Feb 2004 13:08:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AoRRH-0002N3-00 for xcon@ietf.org; Wed, 04 Feb 2004 13:07:51 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Feb 2004 10:14:14 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i14I7LDI022221; Wed, 4 Feb 2004 10:07:21 -0800 (PST) Received: from klantz-w2k02.cisco.com (rtp-vpn2-137.cisco.com [10.82.240.137]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APY97084; Wed, 4 Feb 2004 10:07:17 -0800 (PST) Message-Id: <5.2.1.1.2.20040204094515.025175b8@vtg-um-e2k1.cisco.com> X-Sender: klantz@vtg-um-e2k1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 04 Feb 2004 10:01:19 -0800 To: "Drage, Keith (Keith)" From: Keith Lantz Subject: RE: [XCON] CPCP Requirement: Repeat times Cc: xcon@ietf.org, Dave Bieselin In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EFCB@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 From exim@www1.ietf.org Wed Feb 4 15:09:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23335 for ; Wed, 4 Feb 2004 15:09:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTL1-0007dN-T1 for xcon-archive@odin.ietf.org; Wed, 04 Feb 2004 15:09:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14K9V8S029339 for xcon-archive@odin.ietf.org; Wed, 4 Feb 2004 15:09:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTL1-0007d7-Mq for xcon-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:09:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23280 for ; Wed, 4 Feb 2004 15:09:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTKy-0006Rl-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 15:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTJy-0006ML-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 15:08:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTJY-0006HH-00 for xcon-web-archive@ietf.org; Wed, 04 Feb 2004 15:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTJZ-0006vJ-Ry; Wed, 04 Feb 2004 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTIz-0006X5-K3 for xcon@optimus.ietf.org; Wed, 04 Feb 2004 15:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23123 for ; Wed, 4 Feb 2004 15:07:22 -0500 (EST) From: Ext-Max.Yang@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTIw-0006G6-00 for xcon@ietf.org; Wed, 04 Feb 2004 15:07:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTI1-0006BT-00 for xcon@ietf.org; Wed, 04 Feb 2004 15:06:25 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AoTHS-00066q-00 for xcon@ietf.org; Wed, 04 Feb 2004 15:05:50 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14K5nM11291 for ; Wed, 4 Feb 2004 22:05:49 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 4 Feb 2004 22:05:25 +0200 Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 4 Feb 2004 14:05:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2004 14:05:17 -0600 Message-ID: <807CA26FA73D1648A05242561635786101874A0E@daebe005.americas.nokia.com> Thread-Topic: CPCP Requirement-02: ACL Thread-Index: AcPrWjU1z7c1hNl0Rdq49iTjHYkXUA== To: X-OriginalArrivalTime: 04 Feb 2004 20:05:17.0344 (UTC) FILETIME=[357C7A00:01C3EB5A] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirement-02: ACL Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Is ACL should contain the user privilege or other information, or simple = should there be a requirement for ACL itself together with REQ-Ex's? Max=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 5 05:49:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10666 for ; Thu, 5 Feb 2004 05:49:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoh3z-0001tX-0j for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 05:48:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Amoo1007280 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 05:48:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoh3y-0001tK-OS for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 05:48:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10663 for ; Thu, 5 Feb 2004 05:48:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoh3v-0007Ob-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 05:48:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoh32-0007K7-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 05:47:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoh2B-0007FX-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 05:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoh2D-0001pR-Ai; Thu, 05 Feb 2004 05:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoh22-0001pF-5U for xcon@optimus.ietf.org; Thu, 05 Feb 2004 05:46:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10639 for ; Thu, 5 Feb 2004 05:46:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoh1y-0007Dx-00 for xcon@ietf.org; Thu, 05 Feb 2004 05:46:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoh10-00079m-00 for xcon@ietf.org; Thu, 05 Feb 2004 05:45:47 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoh0W-00075O-00 for xcon@ietf.org; Thu, 05 Feb 2004 05:45:16 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i15Aiin04817 for ; Thu, 5 Feb 2004 04:44:45 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Feb 2004 10:44:43 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B1B15A8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Keith Lantz , "Drage, Keith (Keith)" Cc: xcon@ietf.org, Dave Bieselin Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 10:44:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 From exim@www1.ietf.org Thu Feb 5 06:50:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12349 for ; Thu, 5 Feb 2004 06:50:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoi16-0004y9-7Q for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 06:49:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15BnuAu019095 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 06:49:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoi16-0004xu-1Y for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 06:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12331 for ; Thu, 5 Feb 2004 06:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoi11-0005Fb-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 06:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoi04-00059z-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 06:48:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AohzB-00054I-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 06:47:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AohzE-0004rP-Qx; Thu, 05 Feb 2004 06:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aohz7-0004r9-QF for xcon@optimus.ietf.org; Thu, 05 Feb 2004 06:47:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12274 for ; Thu, 5 Feb 2004 06:47:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aohz3-00053D-00 for xcon@ietf.org; Thu, 05 Feb 2004 06:47:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aohy7-0004vq-00 for xcon@ietf.org; Thu, 05 Feb 2004 06:46:51 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AohxB-0004pS-00 for xcon@ietf.org; Thu, 05 Feb 2004 06:45:53 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i15BjrZ17507 for ; Thu, 5 Feb 2004 12:45:53 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i15Bjqw10710 for ; Thu, 5 Feb 2004 12:45:52 +0100 (MET) Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA03316 for ; Thu, 5 Feb 2004 12:45:52 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Feb 2004 12:45:51 +0100 Message-ID: From: Leis Peter To: xcon@ietf.org Subject: [XCON] comments on draft-ietf-xcon-cpcp-reqs-02.txt Date: Thu, 5 Feb 2004 12:45:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi, I have some some comments on draft-ietf-xcon-cpcp-reqs-02.txt: REQ-F4: the requirement does not sound like a requirement for the policy control protocol better It MUST be possible to define whether to have one floor per media type or one floor for all media types REQ-F5: the requirement does not sound like a requirement for the policy control protocol better It must be possible to define the number of floors in a conference regards, peter _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 5 09:07:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15644 for ; Thu, 5 Feb 2004 09:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok9h-0004tn-6d for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 09:06:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15E6v27018830 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 09:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok9g-0004td-W7 for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15630 for ; Thu, 5 Feb 2004 09:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aok9f-0002Bm-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:06:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aok8j-00021Z-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:05:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aok7r-0001qA-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok7q-0004hK-IX; Thu, 05 Feb 2004 09:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aok6y-0004eB-O8 for xcon@optimus.ietf.org; Thu, 05 Feb 2004 09:04:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15495 for ; Thu, 5 Feb 2004 09:04:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aok6x-0001id-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:04:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aok5w-0001c9-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:03:05 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1Aok56-0001R6-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:02:12 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ80C1F>; Thu, 5 Feb 2004 09:01:42 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63A1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Drage, Keith (Keith)'" , Keith Lantz Cc: xcon@ietf.org, Dave Bieselin Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 09:01:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 From exim@www1.ietf.org Thu Feb 5 09:14:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15918 for ; Thu, 5 Feb 2004 09:14:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokGT-0007mw-DU for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 09:13:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15EDvdP029935 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 09:13:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokGT-0007mj-6p for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:13:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15899 for ; Thu, 5 Feb 2004 09:13:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokGR-0003AN-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:13:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokFU-00035S-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:12:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AokEZ-00030O-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokEa-0007jL-NA; Thu, 05 Feb 2004 09:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokEZ-0007jA-GR for xcon@optimus.ietf.org; Thu, 05 Feb 2004 09:11:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15866 for ; Thu, 5 Feb 2004 09:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokEX-000300-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:11:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokDd-0002v8-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:11:03 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly06a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AokD1-0002hs-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:10:24 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly06a.srv.mailcontrol.com (MailControl) with SMTP id i15E9iVR025606; Thu, 5 Feb 2004 14:09:44 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 5 Feb 2004 14:09:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 14:09:43 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF173@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPr8RSZ8QU8l0bvT3+DS5YXbdMtbwAADcDg From: "Chris Boulton" To: "Rosen, Brian" , "Drage, Keith (Keith)" , "Keith Lantz" Cc: , "Dave Bieselin" X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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. >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: 05 February 2004 14:02 >To: 'Drage, Keith (Keith)'; Keith Lantz >Cc: xcon@ietf.org; Dave Bieselin >Subject: RE: [XCON] CPCP Requirement: Repeat times > >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 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 5 09:22:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16147 for ; Thu, 5 Feb 2004 09:22:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokOF-000842-7G for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 09:21:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15ELxdt030992 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 09:21:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokOF-00083n-1H for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:21:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16134 for ; Thu, 5 Feb 2004 09:21:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokOD-0003tg-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:21:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokNK-0003oR-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:21:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AokMN-0003iY-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokMN-0007z8-Gw; Thu, 05 Feb 2004 09:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokLN-0007xO-DP for xcon@optimus.ietf.org; Thu, 05 Feb 2004 09:19:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16055 for ; Thu, 5 Feb 2004 09:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokLL-0003by-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:18:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokKP-0003WE-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:18:02 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AokJW-0003LL-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:17:06 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ80C4L>; Thu, 5 Feb 2004 09:16:34 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63A2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Chris Boulton'" , "Drage, Keith (Keith)" , Keith Lantz Cc: xcon@ietf.org, Dave Bieselin Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 09:16:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Thursday, February 05, 2004 9:10 AM > To: Rosen, Brian; Drage, Keith (Keith); Keith Lantz > Cc: xcon@ietf.org; Dave Bieselin > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > 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. > > > >-----Original Message----- > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: 05 February 2004 14:02 > >To: 'Drage, Keith (Keith)'; Keith Lantz > >Cc: xcon@ietf.org; Dave Bieselin > >Subject: RE: [XCON] CPCP Requirement: Repeat times > > > >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 > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ 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 From exim@www1.ietf.org Thu Feb 5 09:24:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16215 for ; Thu, 5 Feb 2004 09:24:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokQB-0008B2-38 for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 09:23:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15ENx0b031426 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 09:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokQA-0008An-Ue for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:23:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16209 for ; Thu, 5 Feb 2004 09:23:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokQ9-00044F-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:23:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokPC-0003zI-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:22:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AokOF-0003tx-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokOG-00084L-7u; Thu, 05 Feb 2004 09:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokNR-00082D-JG for xcon@optimus.ietf.org; Thu, 05 Feb 2004 09:21:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16112 for ; Thu, 5 Feb 2004 09:21:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokNP-0003p1-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:21:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokMR-0003jJ-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:20:08 -0500 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AokM8-0003dA-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:19:48 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <12XFQVZP>; Thu, 5 Feb 2004 16:19:16 +0200 Message-ID: From: "Even, Roni" To: "'Rosen, Brian'" , "'Drage, Keith (Keith)'" Cc: xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 16:19:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, February 05, 2004 4:02 PM To: 'Drage, Keith (Keith)'; Keith Lantz Cc: xcon@ietf.org; Dave Bieselin Subject: RE: [XCON] CPCP Requirement: Repeat times 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 From exim@www1.ietf.org Thu Feb 5 09:30:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16284 for ; Thu, 5 Feb 2004 09:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokVz-000066-4M for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 09:29:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15ETxlr000368 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 09:29:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokVy-00005r-UQ for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 09:29:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16281 for ; Thu, 5 Feb 2004 09:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokVx-0004Wy-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:29:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokUy-0004SH-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:28:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AokU3-0004Ns-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 09:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokU4-0008Lf-Rs; Thu, 05 Feb 2004 09:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AokT7-0008KI-IY for xcon@optimus.ietf.org; Thu, 05 Feb 2004 09:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16262 for ; Thu, 5 Feb 2004 09:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AokT5-0004Ih-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:26:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AokSB-0004Dm-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:26:05 -0500 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AokRc-00048r-00 for xcon@ietf.org; Thu, 05 Feb 2004 09:25:29 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <12XFQV7R>; Thu, 5 Feb 2004 16:24:57 +0200 Message-ID: From: "Even, Roni" To: "'Rosen, Brian'" , "'Chris Boulton'" , "Drage, Keith (Keith)" , Keith Lantz Cc: xcon@ietf.org, Dave Bieselin Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 16:24:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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:Brian.Rosen@marconi.com] Sent: Thursday, February 05, 2004 4:16 PM To: 'Chris Boulton'; Drage, Keith (Keith); Keith Lantz Cc: xcon@ietf.org; Dave Bieselin Subject: RE: [XCON] CPCP Requirement: Repeat times 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 > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Thursday, February 05, 2004 9:10 AM > To: Rosen, Brian; Drage, Keith (Keith); Keith Lantz > Cc: xcon@ietf.org; Dave Bieselin > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > 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. > > > >-----Original Message----- > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: 05 February 2004 14:02 > >To: 'Drage, Keith (Keith)'; Keith Lantz > >Cc: xcon@ietf.org; Dave Bieselin > >Subject: RE: [XCON] CPCP Requirement: Repeat times > > > >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 > > > This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ 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 From exim@www1.ietf.org Thu Feb 5 10:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19786 for ; Thu, 5 Feb 2004 10:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolT4-00035Y-Eg for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 10:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15FV2Ah011863 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolT2-00034k-D0 for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:31:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19754 for ; Thu, 5 Feb 2004 10:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolT0-0002us-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:30:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolS1-0002pm-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:29:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AolR5-0002l1-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolR6-0002xY-OP; Thu, 05 Feb 2004 10:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolQB-0002tV-Hr for xcon@optimus.ietf.org; Thu, 05 Feb 2004 10:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19661 for ; Thu, 5 Feb 2004 10:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolQ9-0002fx-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:28:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolPB-0002bG-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:27:02 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AolOo-0002Wc-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:26:38 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ80FD6>; Thu, 5 Feb 2004 10:26:08 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63A5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Even, Roni'" , "'Drage, Keith (Keith)'" Cc: xcon@ietf.org Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 10:26:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, February 05, 2004 9:19 AM > To: 'Rosen, Brian'; 'Drage, Keith (Keith)' > Cc: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > 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 > > > > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, February 05, 2004 4:02 PM > To: 'Drage, Keith (Keith)'; Keith Lantz > Cc: xcon@ietf.org; Dave Bieselin > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > 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 From exim@www1.ietf.org Thu Feb 5 10:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19908 for ; Thu, 5 Feb 2004 10:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolVy-0003Xc-Ch for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 10:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15FY27A013606 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 10:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolVy-0003XN-74 for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:34:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19896 for ; Thu, 5 Feb 2004 10:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolVw-0003BC-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:34:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolUx-00035e-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:33:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AolTz-00030Q-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolU1-0003L0-Hq; Thu, 05 Feb 2004 10:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolTz-0003Kk-TB for xcon@optimus.ietf.org; Thu, 05 Feb 2004 10:32:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19825 for ; Thu, 5 Feb 2004 10:31:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolTx-0002zx-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:31:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolT1-0002v2-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:31:00 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AolS4-0002lh-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:30:00 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ80FJN>; Thu, 5 Feb 2004 10:29:29 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63A6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Even, Roni'" , "'Chris Boulton'" , "Drage, Keith (Keith)" , Keith Lantz Cc: xcon@ietf.org, Dave Bieselin Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 10:29:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, February 05, 2004 9:25 AM > To: 'Rosen, Brian'; 'Chris Boulton'; Drage, Keith (Keith); Keith Lantz > Cc: xcon@ietf.org; Dave Bieselin > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > 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:Brian.Rosen@marconi.com] > Sent: Thursday, February 05, 2004 4:16 PM > To: 'Chris Boulton'; Drage, Keith (Keith); Keith Lantz > Cc: xcon@ietf.org; Dave Bieselin > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > 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 > > > -----Original Message----- > > From: Chris Boulton [mailto:cboulton@ubiquity.net] > > Sent: Thursday, February 05, 2004 9:10 AM > > To: Rosen, Brian; Drage, Keith (Keith); Keith Lantz > > Cc: xcon@ietf.org; Dave Bieselin > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > 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. > > > > > > >-----Original Message----- > > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > >Sent: 05 February 2004 14:02 > > >To: 'Drage, Keith (Keith)'; Keith Lantz > > >Cc: xcon@ietf.org; Dave Bieselin > > >Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > >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 > > > > > > This message has been scanned for viruses by MailControl - > www.mailcontrol.com > > _______________________________________________ > 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 From exim@www1.ietf.org Thu Feb 5 10:44:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20159 for ; Thu, 5 Feb 2004 10:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aolfd-0004FQ-Sa for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 10:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Fi1nP016322 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aolfd-0004FA-Ln for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:44:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20156 for ; Thu, 5 Feb 2004 10:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aolfb-00048o-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:43:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aolee-000446-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:43:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoldg-0003z0-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 10:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoldi-00048U-3k; Thu, 05 Feb 2004 10:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aolco-000462-1A for xcon@optimus.ietf.org; Thu, 05 Feb 2004 10:41:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20114 for ; Thu, 5 Feb 2004 10:41:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aolcl-0003tM-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:41:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aolbs-0003o2-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:40:09 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly05a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AolbH-0003h8-00 for xcon@ietf.org; Thu, 05 Feb 2004 10:39:31 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05a.srv.mailcontrol.com (MailControl) with SMTP id i15FcuSY027484; Thu, 5 Feb 2004 15:38:57 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 5 Feb 2004 15:38:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 15:38:56 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDF178@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPr/NZTJ1h7P8gmS+CeYFM6+gXwYAAAUM2g From: "Chris Boulton" To: "Rosen, Brian" , "Even, Roni" , "Drage, Keith (Keith)" Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Agreed. >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: 05 February 2004 15:26 >To: 'Even, Roni'; 'Drage, Keith (Keith)' >Cc: xcon@ietf.org >Subject: RE: [XCON] CPCP Requirement: Repeat times > >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 > >> -----Original Message----- >> From: Even, Roni [mailto:roni.even@polycom.co.il] >> Sent: Thursday, February 05, 2004 9:19 AM >> To: 'Rosen, Brian'; 'Drage, Keith (Keith)' >> Cc: xcon@ietf.org >> Subject: RE: [XCON] CPCP Requirement: Repeat times >> >> >> 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 >> >> >> >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Sent: Thursday, February 05, 2004 4:02 PM >> To: 'Drage, Keith (Keith)'; Keith Lantz >> Cc: xcon@ietf.org; Dave Bieselin >> Subject: RE: [XCON] CPCP Requirement: Repeat times >> >> >> 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 This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 5 12:04:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24258 for ; Thu, 5 Feb 2004 12:04:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomvR-0006Wz-Au for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 12:04:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15H4PRV025099 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 12:04:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomvR-0006Wk-14 for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 12:04:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24083 for ; Thu, 5 Feb 2004 12:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomvP-00051Z-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 12:04:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aomtx-0004gp-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 12:02:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aomsi-0004TZ-01 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 12:01:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aomek-0003t8-8i for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 11:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aomee-0004Gx-OI; Thu, 05 Feb 2004 11:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aomdw-00043b-Me for xcon@optimus.ietf.org; Thu, 05 Feb 2004 11:46:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23222 for ; Thu, 5 Feb 2004 11:46:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aomdv-0002sL-00 for xcon@ietf.org; Thu, 05 Feb 2004 11:46:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aomck-0002a5-00 for xcon@ietf.org; Thu, 05 Feb 2004 11:45:08 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoman-00029y-00 for xcon@ietf.org; Thu, 05 Feb 2004 11:43:05 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 05 Feb 2004 08:48:59 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i15GgW08003043; Thu, 5 Feb 2004 08:42:32 -0800 (PST) Received: from klantz-w2k02.cisco.com (dhcp-171-69-218-146.cisco.com [171.69.218.146]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APZ94047; Thu, 5 Feb 2004 08:42:30 -0800 (PST) Message-Id: <5.2.1.1.2.20040205084137.02247f38@vtg-um-e2k1.cisco.com> X-Sender: klantz@vtg-um-e2k1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 05 Feb 2004 08:42:01 -0800 To: "Rosen, Brian" From: Keith Lantz Subject: RE: [XCON] CPCP Requirement: Repeat times Cc: "'Even, Roni'" , "'Drage, Keith (Keith)'" , xcon@ietf.org, Dave Bieselin In-Reply-To: <313680C9A886D511A06000204840E1CF070B63A5@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I agree. At 07:26 AM 2/5/2004, Rosen, Brian wrote: >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 > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Thursday, February 05, 2004 9:19 AM > > To: 'Rosen, Brian'; 'Drage, Keith (Keith)' > > Cc: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > 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 > > > > > > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, February 05, 2004 4:02 PM > > To: 'Drage, Keith (Keith)'; Keith Lantz > > Cc: xcon@ietf.org; Dave Bieselin > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > 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 From exim@www1.ietf.org Thu Feb 5 13:47:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28305 for ; Thu, 5 Feb 2004 13:47:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooWn-0006J4-Tq for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 13:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Il5Ug024236 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 13:47:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooWn-0006Ip-O0 for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 13:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28250 for ; Thu, 5 Feb 2004 13:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AooWl-0007nC-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 13:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AooVn-0007gU-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 13:46:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AooUo-0007YK-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 13:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooUp-0006En-7y; Thu, 05 Feb 2004 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aojy8-0003zn-MO for xcon@optimus.ietf.org; Thu, 05 Feb 2004 08:55:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15243 for ; Thu, 5 Feb 2004 08:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aojy7-0000s2-00 for xcon@ietf.org; Thu, 05 Feb 2004 08:54:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AojxA-0000mx-00 for xcon@ietf.org; Thu, 05 Feb 2004 08:54:01 -0500 Received: from vtg-um-e2k4.cisco.com ([171.70.93.57] helo=vtg-um-e2k4.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aojwo-0000hg-00 for xcon@ietf.org; Thu, 05 Feb 2004 08:53:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 05:53:03 -0800 Message-ID: Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPr1LfNy8Z0pa7tSc63qnoPPXI/VwAGZegw From: "Bieselin, David" To: "Drage, Keith \(Keith\)" , "Lantz, Keith" Cc: Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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:drage@lucent.com]=20 Sent: Thursday, February 05, 2004 2:45 AM To: Lantz, Keith; Drage, Keith (Keith) Cc: xcon@ietf.org; Bieselin, David Subject: RE: [XCON] CPCP Requirement: Repeat times=20 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 >=20 >=20 > Indeed, what happens when the conference creator/owner leaves a=20 > conference and whether or not to tear down the conference at a=20 > particular stop time are independent issues. For example, the typical=20 > use of MeetingPlace at Cisco is not to care in the least when the=20 > creator/owner leaves, and the conference will end when the designated=20 > stop time is reached (or everyone has left). And some users here=20 > definitely would not be happy if they were cross-charged for a=20 > conference call that continued, say, with "random chatter" long past=20 > the stop time they had designated. >=20 > Separately, the distinction drawn below between enterprise and service > provider usage seems to be based on the assumption that enterprises=20 > don't allocate charges for conferences so don't care if a conference=20 > continues after the stop time. You may not, in fact, being saying=20 > that. > But in case > others are making that assumption: Don't; it simply isn't true. >=20 > Regards, (A different) Keith >=20 > 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=20 > >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=20 > >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;=20 > > > fluffy@cisco.com; xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > Brian is suggesting that stop-time means that the conference=20 > > > creator will leave the conference at that time. At least this is=20 > > > how I understood it. > > > > > > This leaves the rest of the participants hanging around still in=20 > > > the conference. I also ok with stop-time meaning all participants=20 > > > 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=20 > > > > > 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=20 > > > > time 3pm), and other people stay there for days. > > > > > > > > I think it is better to stop the conference as defined by the=20 > > > > stop time. > > > > Some vendors may add polite warning 10 min before the stop time=20 > > > > ("this conference will end soon..") or if you have credit left=20 > > > > it may be automatically extended for some reasonable time if=20 > > > > 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. =20 > 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=20 > > > > > 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=20 > > > > > > (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 >=20 > ---------------- > 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. >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 5 14:09:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29413 for ; Thu, 5 Feb 2004 14:09:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoos9-0007n1-MA for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 14:09:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15J99Wg029942 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 14:09:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoos9-0007mm-8D for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 14:09:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29406 for ; Thu, 5 Feb 2004 14:09:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoos6-0002Es-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 14:09:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoor6-00029s-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 14:08:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aooq6-00021W-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 14:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aooq5-0007QS-6H; Thu, 05 Feb 2004 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoopc-0007PX-JF for xcon@optimus.ietf.org; Thu, 05 Feb 2004 14:06:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29358 for ; Thu, 5 Feb 2004 14:06:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoopZ-000210-00 for xcon@ietf.org; Thu, 05 Feb 2004 14:06:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoooN-0001wN-00 for xcon@ietf.org; Thu, 05 Feb 2004 14:05:18 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aoonc-0001sA-00 for xcon@ietf.org; Thu, 05 Feb 2004 14:04:28 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i15J4Rv06559 for ; Thu, 5 Feb 2004 21:04:27 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Feb 2004 21:04:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 21:04:27 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 21:04:26 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797701@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPr1LfNy8Z0pa7tSc63qnoPPXI/VwAGZegwAAsMmWA= To: , , Cc: X-OriginalArrivalTime: 05 Feb 2004 19:04:27.0495 (UTC) FILETIME=[E06B7770:01C3EC1A] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Bieselin, David > Sent: 05.February.2004 15:53 > To: Drage, Keith (Keith); Lantz, Keith > Cc: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > 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=20 > 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=20 > conference > policy, perhaps by scheduler to say, whether or not they can have more > time, and if so how much. >=20 > 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=20 > policy. On a > system by system basis, even down to the scheduler, some meetings are > allowed to continue and some not. >=20 > A variant on this is when you instruct the conference to call out to > auto answering devices. We have seen requirements similar=20 > to the above > on when to tear down this call leg. >=20 > Dave >=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: Thursday, February 05, 2004 2:45 AM > To: Lantz, Keith; Drage, Keith (Keith) > Cc: xcon@ietf.org; Bieselin, David > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 > 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. >=20 > 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. >=20 > regards >=20 > Keith >=20 > > -----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 > >=20 > >=20 > > Indeed, what happens when the conference creator/owner leaves a=20 > > conference and whether or not to tear down the conference at a=20 > > particular stop time are independent issues. For example,=20 > the typical=20 > > use of MeetingPlace at Cisco is not to care in the least when the=20 > > creator/owner leaves, and the conference will end when the=20 > designated=20 > > stop time is reached (or everyone has left). And some users here=20 > > definitely would not be happy if they were cross-charged for a=20 > > conference call that continued, say, with "random chatter"=20 > long past=20 > > the stop time they had designated. > >=20 > > Separately, the distinction drawn below between enterprise=20 > and service >=20 > > provider usage seems to be based on the assumption that enterprises=20 > > don't allocate charges for conferences so don't care if a=20 > conference=20 > > continues after the stop time. You may not, in fact, being saying=20 > > that. > > But in case > > others are making that assumption: Don't; it simply isn't true. > >=20 > > Regards, (A different) Keith > >=20 > > 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=20 > > >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=20 > > >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;=20 > > > > fluffy@cisco.com; xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Brian is suggesting that stop-time means that the conference=20 > > > > creator will leave the conference at that time. At=20 > least this is=20 > > > > how I understood it. > > > > > > > > This leaves the rest of the participants hanging around=20 > still in=20 > > > > the conference. I also ok with stop-time meaning all=20 > participants=20 > > > > 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=20 > > > > > > 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,=20 > and stop=20 > > > > > time 3pm), and other people stay there for days. > > > > > > > > > > I think it is better to stop the conference as defined by the=20 > > > > > stop time. > > > > > Some vendors may add polite warning 10 min before the=20 > stop time=20 > > > > > ("this conference will end soon..") or if you have=20 > credit left=20 > > > > > it may be automatically extended for some reasonable time if=20 > > > > > 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. =20 > > 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=20 > > > > > > 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=20 > does this=20 > > > > > > > (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 > >=20 > > ---------------- > > 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. > >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 5 15:36:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04657 for ; Thu, 5 Feb 2004 15:36:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqEN-0005gl-Rf for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 15:36:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KaBof021865 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 15:36:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqEN-0005ga-M1 for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:36:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04651 for ; Thu, 5 Feb 2004 15:36:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqEM-0003TP-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 15:36:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqDY-0003Ok-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 15:35:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoqDG-0003JL-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 15:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqDH-0005cR-Br; Thu, 05 Feb 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopzs-0004ZC-Uf for xcon@optimus.ietf.org; Thu, 05 Feb 2004 15:21:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03949 for ; Thu, 5 Feb 2004 15:21:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopzr-00022R-00 for xcon@ietf.org; Thu, 05 Feb 2004 15:21:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopyu-0001vu-00 for xcon@ietf.org; Thu, 05 Feb 2004 15:20:13 -0500 Received: from vtg-um-e2k4.cisco.com ([171.70.93.57] helo=vtg-um-e2k4.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AopyH-0001lZ-00 for xcon@ietf.org; Thu, 05 Feb 2004 15:19:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 12:19:00 -0800 Message-ID: Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPsBqn6WVYiuiLsTemijUww9woJegAHb+2g From: "Bieselin, David" To: "Lantz, Keith" , "Rosen, Brian" Cc: "Even, Roni" , "Drage, Keith \(Keith\)" , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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. =20 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=20 Sent: Thursday, February 05, 2004 8:42 AM To: Rosen, Brian Cc: 'Even, Roni'; 'Drage, Keith (Keith)'; xcon@ietf.org; Bieselin, David Subject: RE: [XCON] CPCP Requirement: Repeat times=20 I agree. At 07:26 AM 2/5/2004, Rosen, Brian wrote: >I think the protocol should let you change it at any time. >I think a particular implementation might have policy issues (for=20 >example, it may not be able to reserve the resources), so the attempt=20 >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=20 >stop time (policy permitting). > >Brian > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Thursday, February 05, 2004 9:19 AM > > To: 'Rosen, Brian'; 'Drage, Keith (Keith)' > > Cc: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > 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=20 > > stop time after conference started" may also be needed. > > > > About your choices I assume that logical operators between them are=20 > > allowed. > > e.g "end when convener leaves" OR "end when stop time is reached" > > > > Roni Even > > > > > > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, February 05, 2004 4:02 PM > > To: 'Drage, Keith (Keith)'; Keith Lantz > > Cc: xcon@ietf.org; Dave Bieselin > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > I formally propose a requirement that states > > > > There shall be a method for specifying when the conference ends,=20 > > with choices for at least: "end when last person leaves", "end when=20 > > convener leaves" > > and "end when stop time is reached". It is not be a requirement=20 > > 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=20 > > > their being enterprise or public network in the current day - I=20 > > > was highlighting a historical divergence and pointing out that=20 > > > both requirements will still exist. > > > > > > One further reason for a system that closes down the bridge when=20 > > > the conference originator/owner leaves, some companies require=20 > > > this as a security measure for their internal audio conference=20 > > > 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=20 > > > > conference and whether or not to tear down the conference at a=20 > > > > particular stop time are independent issues. For example, the=20 > > > > typical use of MeetingPlace at Cisco is not to care in the least > > > > when the creator/owner leaves, and the conference will end when=20 > > > > the designated stop time is reached (or everyone has left). And=20 > > > > some users here definitely would not be happy if they were=20 > > > > 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=20 > > > > service provider usage seems to be based on the assumption that=20 > > > > enterprises don't allocate charges for conferences so don't care > > > > if a conference continues after the stop time. You may not, in=20 > > > > 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;=20 > > > > > > 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=20 > > > > > > this is how I understood it. > > > > > > > > > > > > This leaves the rest of the participants hanging around=20 > > > > > > still in the conference. I also ok with stop-time meaning=20 > > > > > > 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=20 > > > > > > > > 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=20 > > > > > > > not > > > > > > be happy > > > > > > > if I create (and pay) the conference (start time 2pm, and=20 > > > > > > > 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=20 > > > > > > > credit left it may be automatically extended for some=20 > > > > > > > reasonable time if there are resources and people hanging=20 > > > > > > > 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=20 > > > > > > > > > [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=20 > > > > > > > > only terminate when the last participant leaves? I think > > > > > > > > I'm ok > > > > > > > with that. > > > > > > > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > I've never encountered a public bridge that actually=20 > > > > > > > > > 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 From exim@www1.ietf.org Thu Feb 5 15:38:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04709 for ; Thu, 5 Feb 2004 15:38:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqGJ-00066Y-HM for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 15:38:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KcB0R023460 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 15:38:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqGJ-00066J-Bt for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04705 for ; Thu, 5 Feb 2004 15:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqGH-0003fU-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 15:38:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqFS-0003am-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 15:37:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoqFA-0003VO-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 15:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqFB-0005lD-F2; Thu, 05 Feb 2004 15:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqEM-0005gV-Jk for xcon@optimus.ietf.org; Thu, 05 Feb 2004 15:36:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04648 for ; Thu, 5 Feb 2004 15:36:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqEL-0003TH-00 for xcon@ietf.org; Thu, 05 Feb 2004 15:36:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqDV-0003OT-00 for xcon@ietf.org; Thu, 05 Feb 2004 15:35:18 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AoqCj-0003Cz-00 for xcon@ietf.org; Thu, 05 Feb 2004 15:34:29 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i15KXuTs029248; Thu, 5 Feb 2004 12:33:56 -0800 (PST) Received: from klantz-w2k02.cisco.com (dhcp-128-107-142-226.cisco.com [128.107.142.226]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQA21747; Thu, 5 Feb 2004 12:33:54 -0800 (PST) Message-Id: <5.2.1.1.2.20040205122931.0221be88@vtg-um-e2k1.cisco.com> X-Sender: klantz@vtg-um-e2k1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 05 Feb 2004 12:33:52 -0800 To: "Bieselin, David" From: Keith Lantz Subject: RE: [XCON] CPCP Requirement: Repeat times Cc: "Lantz, Keith" , "Rosen, Brian" , "Even, Roni" , "Drage, Keith (Keith)" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: >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)'; xcon@ietf.org; Bieselin, David >Subject: RE: [XCON] CPCP Requirement: Repeat times > >I agree. > >At 07:26 AM 2/5/2004, Rosen, Brian wrote: > >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 > > > > > -----Original Message----- > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: Thursday, February 05, 2004 9:19 AM > > > To: 'Rosen, Brian'; 'Drage, Keith (Keith)' > > > Cc: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Thursday, February 05, 2004 4:02 PM > > > To: 'Drage, Keith (Keith)'; Keith Lantz > > > Cc: xcon@ietf.org; Dave Bieselin > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > 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 From exim@www1.ietf.org Thu Feb 5 16:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13218 for ; Thu, 5 Feb 2004 16:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorJy-0003us-4c for xcon-archive@odin.ietf.org; Thu, 05 Feb 2004 16:46:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Lk1gx015039 for xcon-archive@odin.ietf.org; Thu, 5 Feb 2004 16:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorJx-0003uF-Bk for xcon-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 16:46:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13115 for ; Thu, 5 Feb 2004 16:45:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorJv-0006vR-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 16:45:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorHS-0006Qv-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 16:43:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AorF7-00062z-00 for xcon-web-archive@ietf.org; Thu, 05 Feb 2004 16:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorF8-0003FN-50; Thu, 05 Feb 2004 16:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorEX-0003DY-CM for xcon@optimus.ietf.org; Thu, 05 Feb 2004 16:40:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12414 for ; Thu, 5 Feb 2004 16:40:22 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorEV-00061a-00 for xcon@ietf.org; Thu, 05 Feb 2004 16:40:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorDa-0005yp-00 for xcon@ietf.org; Thu, 05 Feb 2004 16:39:27 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AorDG-0005wB-00 for xcon@ietf.org; Thu, 05 Feb 2004 16:39:06 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i15Ld5v08968 for ; Thu, 5 Feb 2004 23:39:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Feb 2004 23:39:05 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 23:39:05 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 23:39:04 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 23:39:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Thu, 5 Feb 2004 23:39:03 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0CD5@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPsJ9ZkydZQHLd/SBOJUePZxOwSXgABetow To: , Cc: , , , X-OriginalArrivalTime: 05 Feb 2004 21:39:04.0753 (UTC) FILETIME=[7A18B210:01C3EC30] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think the current requirements (as written in -02 draft)=20 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 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Keith Lantz > Sent: 05 February, 2004 22:34 > To: Bieselin, David > Cc: Lantz, Keith; Rosen, Brian; Even, Roni; Drage, Keith (Keith); > xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Good point. OK then, I agree with MOST of what Brian was=20 > saying, and agree=20 > with you that an additional "allow to extend if resources are=20 > available"=20 > option is desirable (as an optimization for the user). >=20 > Cheers, Keith >=20 > At 12:19 PM 2/5/2004, Bieselin, David wrote: > >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=20 > 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=20 > 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=20 > you wanted > >to guarantee it, you can certainly do it manually before.=20 > 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)'; xcon@ietf.org;=20 > Bieselin, David > >Subject: RE: [XCON] CPCP Requirement: Repeat times > > > >I agree. > > > >At 07:26 AM 2/5/2004, Rosen, Brian wrote: > > >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=20 > 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=20 > can change > > >stop time (policy permitting). > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: Thursday, February 05, 2004 9:19 AM > > > > To: 'Rosen, Brian'; 'Drage, Keith (Keith)' > > > > Cc: xcon@ietf.org > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > Brian, > > > > > > > > When is the stop time get set, before the conference?=20 > can you change > > > > > > it once the conference has started or after an event=20 > announcing that > > > > > > the conference will end soon. > > > > > > > > Since this is a way to extend then a choice of "allowed=20 > to change > > > > stop time after conference started" may also be needed. > > > > > > > > About your choices I assume that logical operators=20 > between them are > > > > allowed. > > > > e.g "end when convener leaves" OR "end when stop time=20 > is reached" > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Thursday, February 05, 2004 4:02 PM > > > > To: 'Drage, Keith (Keith)'; Keith Lantz > > > > Cc: xcon@ietf.org; Dave Bieselin > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > 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=20 > 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----- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Feb 6 02:57:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15748 for ; Fri, 6 Feb 2004 02:57:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0qy-0006Ru-0h for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 02:56:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i167uhp4024789 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 02:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0qx-0006Rk-KE for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 02:56:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15733 for ; Fri, 6 Feb 2004 02:56:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0qt-0002sf-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 02:56:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0q2-0002pT-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 02:55:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0pG-0002lb-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 02:54:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0pJ-0006IT-Ju; Fri, 06 Feb 2004 02:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0ou-0006C7-Gd for xcon@optimus.ietf.org; Fri, 06 Feb 2004 02:54:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15624 for ; Fri, 6 Feb 2004 02:54:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0oq-0002il-00 for xcon@ietf.org; Fri, 06 Feb 2004 02:54:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0ny-0002fU-00 for xcon@ietf.org; Fri, 06 Feb 2004 02:53:39 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap0n6-0002ZS-00 for xcon@ietf.org; Fri, 06 Feb 2004 02:52:44 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i167q2T5024128; Thu, 5 Feb 2004 23:52:07 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-302.cisco.com [10.21.65.46]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMD11662; Thu, 5 Feb 2004 23:51:59 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 05 Feb 2004 23:51:56 -0800 Subject: Re: [XCON] CPCP Requirement: Repeat times From: Cullen Jennings To: Keith A Lantz , "Bieselin, David" CC: Brian Rosen , Roni Even , "Drage, Keith (Keith)" , XCON-IETF Message-ID: In-Reply-To: <5.2.1.1.2.20040205122931.0221be88@vtg-um-e2k1.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The definition of start time as when the mixing starts and dialout happens seems far more useful to me that dragging reservation of resources into the problem. The actual times these operations happen may even be admin defined deltas off of the start time. If you take this approach, stop time is not needed or is at best the time some human expects that the conference might end. I agree that systems will need to reserve resources and estimate the time the reservation is need for, and that some of these reservations will be repetitive. I just don't see what resource reservation has to do with CPCP. Cullen On 2/5/04 12:33 PM, "Keith Lantz" wrote: > 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: >> 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)'; xcon@ietf.org; Bieselin, David >> Subject: RE: [XCON] CPCP Requirement: Repeat times >> >> I agree. >> >> At 07:26 AM 2/5/2004, Rosen, Brian wrote: >>> 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 >>> >>>> -----Original Message----- >>>> From: Even, Roni [mailto:roni.even@polycom.co.il] >>>> Sent: Thursday, February 05, 2004 9:19 AM >>>> To: 'Rosen, Brian'; 'Drage, Keith (Keith)' >>>> Cc: xcon@ietf.org >>>> Subject: RE: [XCON] CPCP Requirement: Repeat times >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>> Sent: Thursday, February 05, 2004 4:02 PM >>>> To: 'Drage, Keith (Keith)'; Keith Lantz >>>> Cc: xcon@ietf.org; Dave Bieselin >>>> Subject: RE: [XCON] CPCP Requirement: Repeat times >>>> >>>> >>>> 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 From exim@www1.ietf.org Fri Feb 6 03:03:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15946 for ; Fri, 6 Feb 2004 03:03:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0wb-0006vT-EY for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 03:02:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1682XOZ026622 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 03:02:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0wa-0006vJ-Jg for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 03:02:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15937 for ; Fri, 6 Feb 2004 03:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0wW-000378-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 03:02:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0vZ-00035L-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 03:01:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0v5-00033n-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 03:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0v8-0006o2-7i; Fri, 06 Feb 2004 03:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0ui-0006me-OX for xcon@optimus.ietf.org; Fri, 06 Feb 2004 03:00:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15885 for ; Fri, 6 Feb 2004 03:00:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0ue-00033B-00 for xcon@ietf.org; Fri, 06 Feb 2004 03:00:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0tj-00030Y-00 for xcon@ietf.org; Fri, 06 Feb 2004 02:59:37 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap0t9-0002xk-00 for xcon@ietf.org; Fri, 06 Feb 2004 02:58:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Feb 2004 00:05:42 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i167wI9T029806; Thu, 5 Feb 2004 23:58:18 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-302.cisco.com [10.21.65.46]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMD11836; Thu, 5 Feb 2004 23:58:17 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 05 Feb 2004 23:58:17 -0800 Subject: Re: [XCON] CPCP Requirement: Repeat times From: Cullen Jennings To: Brian Rosen , "'Drage, Keith (Keith)'" , Keith A Lantz CC: XCON-IETF , Dave Bieselin Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B63A1@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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" 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 From exim@www1.ietf.org Fri Feb 6 03:12:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16125 for ; Fri, 6 Feb 2004 03:12:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap15P-0007pI-2H for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 03:11:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i168Bcvg030076 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 03:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap15M-0007oz-TH for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 03:11:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16105 for ; Fri, 6 Feb 2004 03:11:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap15I-0003RJ-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 03:11:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap14a-0003PH-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 03:10:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap13o-0003N6-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 03:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap13q-0007gs-Fg; Fri, 06 Feb 2004 03:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap13M-0007cm-ME for xcon@optimus.ietf.org; Fri, 06 Feb 2004 03:09:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16066 for ; Fri, 6 Feb 2004 03:09:28 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap13I-0003MI-00 for xcon@ietf.org; Fri, 06 Feb 2004 03:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap12N-0003Kl-00 for xcon@ietf.org; Fri, 06 Feb 2004 03:08:32 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ap11e-0003J4-00 for xcon@ietf.org; Fri, 06 Feb 2004 03:07:46 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1687kq23177 for ; Fri, 6 Feb 2004 10:07:46 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Feb 2004 10:07:46 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 10:07:45 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 10:07:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Fri, 6 Feb 2004 10:07:44 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0CD6@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPsh2Y1Jj6X2AnHRdKNccORiLxERAAABDqQ To: , , , Cc: , X-OriginalArrivalTime: 06 Feb 2004 08:07:44.0794 (UTC) FILETIME=[4CFE2FA0:01C3EC88] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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)=20 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=20 >=20 >=20 >=20 > I want something more complex that these. - I don't like=20 > 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=20 > and now the > conference has ended and no one else can join. >=20 >=20 > On 2/5/04 6:01 AM, "Rosen, Brian" wrote: >=20 > > I formally propose a requirement that states > >=20 > > There shall be a method for specifying when the conference=20 > ends, with > > choices for at least: "end when last person leaves", "end=20 > when convener > > leaves" > > and "end when stop time is reached". It is not be a=20 > requirement that > > all CPCP servers implement all such options. > >=20 > >=20 > >=20 > >> -----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 > >>=20 > >>=20 > >> 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. > >>=20 > >> 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. > >>=20 > >> regards > >>=20 > >> Keith > >>=20 > >>> -----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 > >>>=20 > >>>=20 > >>> Indeed, what happens when the conference creator/owner leaves > >>> a conference=20 > >>> 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=20 > >>> has left). And some users here definitely would not be happy > >>> if they were=20 > >>> cross-charged for a conference call that continued, say, > >> with "random=20 > >>> chatter" long past the stop time they had designated. > >>>=20 > >>> Separately, the distinction drawn below between enterprise > >>> and service=20 > >>> 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=20 > >>> others are making that assumption: Don't; it simply isn't true. > >>>=20 > >>> Regards, (A different) Keith > >>>=20 > >>> At 03:22 AM 2/4/2004, Drage, Keith (Keith) wrote: > >>>> This distinction of what happens when the conference creator > >>> leaves is the=20 > >>>> current distinction between existing enterprise network and > >>> public network=20 > >>>> usage of add-on conference service outside of SIP. > >>>>=20 > >>>> In enterprise networks, the conference continues after the > >>> creator leaves, > >>>> possibly effecting a transfer if down to two parties. > >>>>=20 > >>>> In the public network, the conference creator is generally > >>> the conference=20 > >>>> owner and paying for the conference bridge, and some or=20 > all of the > >>>> connection resources to that bridge. As the conference owner > >>> would have no=20 > >>>> control of the cost after he leaves the conference the > >>> conference would > >>>> terminate when the conference owner leaves. > >>>>=20 > >>>> If the conference owner/creator has a means of transferring > >>> the ownership,=20 > >>>> and therefore the charges, or if the conference owner can > >>> still supervise > >>>> the charges after he ceases to be a participant, then=20 > there is not > >>>> necessarily a need to clear such a conference when the > >>> creator leaves. > >>>>=20 > >>>> regards > >>>>=20 > >>>> Keith > >>>>=20 > >>>>> -----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 > >>>>>=20 > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> /Hisham > >>>>>=20 > >>>>>> -----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 > >>>>>>=20 > >>>>>>=20 > >>>>>>> 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. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> Anyway, we are now talking about solutions, not requirements. > >>>>>>=20 > >>>>>> -- > >>>>>> Petri > >>>>>>=20 > >>>>>>> -----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 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>> -----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 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> 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). > >>>>>>>>=20 > >>>>>>>> I think we can live with that definition. > >>>>>>>>=20 > >>>>>>>> Stop time, like it or not for most bridges I know is > >>>>> expected stop > >>>>>>>> time of the person scheduling the conference. > >>>>>>>=20 > >>>>>>> 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. > >>>>>>>=20 > >>>>>>> /Hisham > >>>>>>>=20 > >>>>>>>> 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). > >>>>>>>>=20 > >>>>>>>> I know I was assuming GMT. > >>>>>>>>=20 > >>>>>>>> Brian > >>>>>>>=20 > >>>>>>> _______________________________________________ > >>>>>>> XCON mailing list > >>>>>>> XCON@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>=20 > >>>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> XCON mailing list > >>>>> XCON@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> XCON mailing list > >>>> XCON@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>=20 > >>> ---------------- > >>> 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. > >>>=20 > >>=20 > >> _______________________________________________ > >> XCON mailing list > >> XCON@ietf.org > >> https://www1.ietf.org/mailman/listinfo/xcon > >>=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Feb 6 04:33:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17790 for ; Fri, 6 Feb 2004 04:33:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2Lk-00041b-6H for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 04:32:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i169WaP0015469 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 04:32:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2Lj-00041Q-RN for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 04:32:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17780 for ; Fri, 6 Feb 2004 04:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2Lh-0006le-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 04:32:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2Kk-0006je-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 04:31:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2KD-0006he-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 04:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2KE-0003xd-Rb; Fri, 06 Feb 2004 04:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2Jo-0003wB-3g for xcon@optimus.ietf.org; Fri, 06 Feb 2004 04:30:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17765 for ; Fri, 6 Feb 2004 04:30:32 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2Jl-0006hM-00 for xcon@ietf.org; Fri, 06 Feb 2004 04:30:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2Io-0006fa-00 for xcon@ietf.org; Fri, 06 Feb 2004 04:29:35 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2Ia-0006dX-00 for xcon@ietf.org; Fri, 06 Feb 2004 04:29:20 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i169TLv16947 for ; Fri, 6 Feb 2004 11:29:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Feb 2004 11:29:21 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 11:29:21 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 11:29:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] comments on draft-ietf-xcon-cpcp-reqs-02.txt Date: Fri, 6 Feb 2004 11:29:20 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001E9BD06@trebe004.europe.nokia.com> Thread-Topic: [XCON] comments on draft-ietf-xcon-cpcp-reqs-02.txt Thread-Index: AcPr3e2H4n0xA2i8RCS271uNolX2rgAtTs2g To: , X-OriginalArrivalTime: 06 Feb 2004 09:29:20.0693 (UTC) FILETIME=[B32D1650:01C3EC93] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > REQ-F4: the requirement does not sound like a requirement for=20 > the policy control protocol > better > It MUST be possible to define whether to have one floor per=20 > media type or one floor for all media types Actually, this has slightly different meaning (one or all). > REQ-F5: the requirement does not sound like a requirement for=20 > the policy control protocol > better > It must be possible to define the number of floors in a conference We'll change "have" to "define" in next version so they will be: REQ-F4: It MUST be possible to define one floor for one or more media = types. REQ-F5: It MUST be possible to define multiple floors in a conference. Thanks, Petri _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Feb 6 08:27:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25277 for ; Fri, 6 Feb 2004 08:27:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap60J-0004ib-Tq for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 08:26:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16DQhTn018133 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 08:26:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap60J-0004iO-Md for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 08:26:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25265 for ; Fri, 6 Feb 2004 08:26:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap60I-0004XY-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 08:26:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap5zP-0004V7-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 08:25:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5yh-0004SS-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 08:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5yh-0004fN-GQ; Fri, 06 Feb 2004 08:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap5yN-0004dj-7K for xcon@optimus.ietf.org; Fri, 06 Feb 2004 08:24:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25163 for ; Fri, 6 Feb 2004 08:24:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap5yJ-0004Qr-00 for xcon@ietf.org; Fri, 06 Feb 2004 08:24:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap5xN-0004Oj-00 for xcon@ietf.org; Fri, 06 Feb 2004 08:23:42 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap5wT-0004KO-00 for xcon@ietf.org; Fri, 06 Feb 2004 08:22:45 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ9AK2K>; Fri, 6 Feb 2004 08:22:04 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63AB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'petri.koskelainen@nokia.com'" , fluffy@cisco.com, "Rosen, Brian" , drage@lucent.com, klantz@cisco.com Cc: xcon@ietf.org, dbieseli@cisco.com Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Fri, 6 Feb 2004 08:21:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I don't understand what you are talking about. End when last person leaves is the way many bridges work. You might not like it, but that's the way they work. Most bridges don't start if the convener is not there. If he arrives, and then leaves, the conference is over. It also doesn't work to manipulate stop time to end the conference because its the bridge that wants to enforce its policy and not the convener. If the policy is that the conference ends when stop time is reached, and the convener leaves with stop time set long, how does the conference end? How does any participant know? We have to be explicit. As to Cullen's objection, what you are worried about is start time, and not stop time. By your definition, the conference never started. If it did start, then it ends when whoever showed up leaves (if that's what the conference policy was set to), or when the convener leaves, which is surely the right thing. I don't know how to fix your problem actually. Maybe some kind of action that resets start. The problem is, that would have to be a convener action; you wouldn't want a participant to invoke it. Also, Petri, you can't implement a "Meet Me" with start/stop. MeetMes don't have start and stop times. They start whenever the convener arrives, end when he leaves (usually), but restart when he arrives again with out regard to start and stop. Brian > -----Original Message----- > From: petri.koskelainen@nokia.com [mailto:petri.koskelainen@nokia.com] > Sent: Friday, February 06, 2004 3:08 AM > To: fluffy@cisco.com; Brian.Rosen@marconi.com; drage@lucent.com; > klantz@cisco.com > Cc: xcon@ietf.org; dbieseli@cisco.com > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > what is wrong with start and stop times? > They should cover all use cases. The use case you are referring to > is easy since we already have start/stop times. > > I don't like "stop when last person leaves" either since (in > the end of conference) > you could hang up, get coffee and join again. This scenario > can be achieved with stop time, though. > > All uses cases I have seen can be solved with simple start/stop times. > (note: stop time can be modified anytime, and ACLs are in use). > > Petri > > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of ext > > Cullen Jennings > > Sent: 06 February, 2004 09:58 > > To: Brian Rosen; 'Drage, Keith (Keith)'; Keith A Lantz > > Cc: XCON-IETF; Dave Bieselin > > Subject: Re: [XCON] CPCP Requirement: Repeat times > > > > > > > > I want something more complex that these. - I don't like > > systems where the > > first person dials in, realizes they are the only person > there because > > everyone else is 5 minutes late, hangs up to go get a coffee > > and now the > > conference has ended and no one else can join. > > > > > > On 2/5/04 6:01 AM, "Rosen, Brian" 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 From exim@www1.ietf.org Fri Feb 6 09:00:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25960 for ; Fri, 6 Feb 2004 09:00:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6WK-00071q-1V for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 08:59:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Dxmff027017 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 08:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6WJ-00071g-Rc for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 08:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25938 for ; Fri, 6 Feb 2004 08:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6WI-0006C9-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 08:59:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap6VW-00069T-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 08:59:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6Ua-00066a-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 08:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6Ua-0006wq-UE; Fri, 06 Feb 2004 08:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6UL-0006ue-6w for xcon@optimus.ietf.org; Fri, 06 Feb 2004 08:57:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25918 for ; Fri, 6 Feb 2004 08:57:42 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6UJ-00065G-00 for xcon@ietf.org; Fri, 06 Feb 2004 08:57:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap6TN-00062w-00 for xcon@ietf.org; Fri, 06 Feb 2004 08:56:46 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6Sg-00060V-00 for xcon@ietf.org; Fri, 06 Feb 2004 08:56:02 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i16Du0v05707 for ; Fri, 6 Feb 2004 15:56:00 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Feb 2004 15:55:59 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 15:55:59 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 6 Feb 2004 15:55:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Fri, 6 Feb 2004 15:55:57 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001E9BD08@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPstD2rZ1qe4QvNR+OCiobk7QVv+wAAv7dw To: , , , Cc: , X-OriginalArrivalTime: 06 Feb 2004 13:55:58.0312 (UTC) FILETIME=[F2800680:01C3ECB8] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > 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. =20 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 ?=20 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=20 the service you described). =20 > It also doesn't work to manipulate stop time to end the conference=20 > 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=20 > 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.=20 Yes I can. Convener can use CPCP and set start_time=3DNOW and join the = conference. When convener leaves the conference he can set stop_time=3DNOW.=20 > MeetMes don't have start and stop times. They start whenever the = convener=20 > arrives, end when he leaves (usually), but restart when he arrives = again=20 > with out regard to start and stop. Yes, but this can be achieved via CPCP. Petri >=20 > Brian >=20 > > -----Original Message----- > > From: petri.koskelainen@nokia.com=20 > [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=20 > >=20 > >=20 > > 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. > >=20 > > I don't like "stop when last person leaves" either since (in=20 > > the end of conference)=20 > > you could hang up, get coffee and join again. This scenario=20 > > can be achieved with stop time, though. > >=20 > > All uses cases I have seen can be solved with simple=20 > start/stop times. > > (note: stop time can be modified anytime, and ACLs are in use). > >=20 > > Petri > >=20 > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > 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=20 > > >=20 > > >=20 > > >=20 > > > I want something more complex that these. - I don't like=20 > > > systems where the > > > first person dials in, realizes they are the only person=20 > > there because > > > everyone else is 5 minutes late, hangs up to go get a coffee=20 > > > and now the > > > conference has ended and no one else can join. > > >=20 > > >=20 > > > On 2/5/04 6:01 AM, "Rosen, Brian" wrote: > > >=20 > > > > I formally propose a requirement that states > > > >=20 > > > > There shall be a method for specifying when the conference=20 > > > ends, with > > > > choices for at least: "end when last person leaves", "end=20 > > > when convener > > > > leaves" > > > > and "end when stop time is reached". It is not be a=20 > > > requirement that > > > > all CPCP servers implement all such options. > > > >=20 > > > >=20 > > > >=20 > > > >> -----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 > > > >>=20 > > > >>=20 > > > >> 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. > > > >>=20 > > > >> 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. > > > >>=20 > > > >> regards > > > >>=20 > > > >> Keith > > > >>=20 > > > >>> -----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 > > > >>>=20 > > > >>>=20 > > > >>> Indeed, what happens when the conference creator/owner leaves > > > >>> a conference=20 > > > >>> 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=20 > > > >>> has left). And some users here definitely would not be happy > > > >>> if they were=20 > > > >>> cross-charged for a conference call that continued, say, > > > >> with "random=20 > > > >>> chatter" long past the stop time they had designated. > > > >>>=20 > > > >>> Separately, the distinction drawn below between enterprise > > > >>> and service=20 > > > >>> 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=20 > > > >>> others are making that assumption: Don't; it simply=20 > isn't true. > > > >>>=20 > > > >>> Regards, (A different) Keith > > > >>>=20 > > > >>> At 03:22 AM 2/4/2004, Drage, Keith (Keith) wrote: > > > >>>> This distinction of what happens when the conference creator > > > >>> leaves is the=20 > > > >>>> current distinction between existing enterprise network and > > > >>> public network=20 > > > >>>> usage of add-on conference service outside of SIP. > > > >>>>=20 > > > >>>> In enterprise networks, the conference continues after the > > > >>> creator leaves, > > > >>>> possibly effecting a transfer if down to two parties. > > > >>>>=20 > > > >>>> In the public network, the conference creator is generally > > > >>> the conference=20 > > > >>>> owner and paying for the conference bridge, and some or=20 > > > all of the > > > >>>> connection resources to that bridge. As the conference owner > > > >>> would have no=20 > > > >>>> control of the cost after he leaves the conference the > > > >>> conference would > > > >>>> terminate when the conference owner leaves. > > > >>>>=20 > > > >>>> If the conference owner/creator has a means of transferring > > > >>> the ownership,=20 > > > >>>> and therefore the charges, or if the conference owner can > > > >>> still supervise > > > >>>> the charges after he ceases to be a participant, then=20 > > > there is not > > > >>>> necessarily a need to clear such a conference when the > > > >>> creator leaves. > > > >>>>=20 > > > >>>> regards > > > >>>>=20 > > > >>>> Keith > > > >>>>=20 > > > >>>>> -----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 > > > >>>>>=20 > > > >>>>>=20 > > > >>>>> Brian is suggesting that stop-time means that the conference > > > >>>>> creator will leave the conference at that time. At=20 > least this > > > >>>>> is how I understood it. > > > >>>>>=20 > > > >>>>> This leaves the rest of the participants hanging=20 > around still > > > >>>>> in the conference. I also ok with stop-time meaning all > > > >>>>> participants will get a BYE. > > > >>>>>=20 > > > >>>>> /Hisham > > > >>>>>=20 > > > >>>>>> -----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 > > > >>>>>>=20 > > > >>>>>>=20 > > > >>>>>>> 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. > > > >>>>>>=20 > > > >>>>>> 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. > > > >>>>>>=20 > > > >>>>>> I think it is better to stop the conference as=20 > 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. > > > >>>>>>=20 > > > >>>>>> Anyway, we are now talking about solutions, not=20 > requirements. > > > >>>>>>=20 > > > >>>>>> -- > > > >>>>>> Petri > > > >>>>>>=20 > > > >>>>>>> -----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;=20 > xcon@ietf.org > > > >>>>>>> Subject: RE: [XCON] CPCP Requirement: Repeat times > > > >>>>>>>=20 > > > >>>>>>>=20 > > > >>>>>>>=20 > > > >>>>>>>=20 > > > >>>>>>>> -----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 > > > >>>>>>>>=20 > > > >>>>>>>>=20 > > > >>>>>>>> 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). > > > >>>>>>>>=20 > > > >>>>>>>> I think we can live with that definition. > > > >>>>>>>>=20 > > > >>>>>>>> Stop time, like it or not for most bridges I know is > > > >>>>> expected stop > > > >>>>>>>> time of the person scheduling the conference. > > > >>>>>>>=20 > > > >>>>>>> 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. > > > >>>>>>>=20 > > > >>>>>>> /Hisham > > > >>>>>>>=20 > > > >>>>>>>> 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). > > > >>>>>>>>=20 > > > >>>>>>>> I know I was assuming GMT. > > > >>>>>>>>=20 > > > >>>>>>>> Brian > > > >>>>>>>=20 > > > >>>>>>> _______________________________________________ > > > >>>>>>> XCON mailing list > > > >>>>>>> XCON@ietf.org > > > >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > > > >>>>>>>=20 > > > >>>>>>=20 > > > >>>>>=20 > > > >>>>> _______________________________________________ > > > >>>>> XCON mailing list > > > >>>>> XCON@ietf.org > > > >>>>> https://www1.ietf.org/mailman/listinfo/xcon > > > >>>>>=20 > > > >>>>=20 > > > >>>> _______________________________________________ > > > >>>> XCON mailing list > > > >>>> XCON@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/xcon > > > >>>=20 > > > >>> ---------------- > > > >>> Keith Lantz, Ph.D. Voice:=20 > (408) 902-3302 > > > >>> Cisco Distinguished Engineer FAX: =20 > (408) 902-3518 > > > >>> Voice & Video Systems Architecture Email:=20 > > klantz@cisco.com > > > >>> Voice (& Video) Technology Group > > > >>> Cisco Systems, Inc. > > > >>>=20 > > > >>=20 > > > >> _______________________________________________ > > > >> XCON mailing list > > > >> XCON@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/xcon > > > >>=20 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Feb 6 09:13:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26239 for ; Fri, 6 Feb 2004 09:13:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6ip-0007jP-6s for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 09:12:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16EChHw029713 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 09:12:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6io-0007jA-Us for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 09:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26230 for ; Fri, 6 Feb 2004 09:12:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6in-0006nv-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 09:12:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap6hq-0006kq-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 09:11:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6hB-0006io-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 09:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6hC-0007ga-Cv; Fri, 06 Feb 2004 09:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6gx-0007fv-61 for xcon@optimus.ietf.org; Fri, 06 Feb 2004 09:10:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26187 for ; Fri, 6 Feb 2004 09:10:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6gv-0006iZ-00 for xcon@ietf.org; Fri, 06 Feb 2004 09:10:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap6g1-0006g6-00 for xcon@ietf.org; Fri, 06 Feb 2004 09:09:50 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap6fS-0006cz-00 for xcon@ietf.org; Fri, 06 Feb 2004 09:09:14 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ9ALR5>; Fri, 6 Feb 2004 09:08:44 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63AF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'petri.koskelainen@nokia.com'" , fluffy@cisco.com, drage@lucent.com, klantz@cisco.com Cc: xcon@ietf.org, dbieseli@cisco.com Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Fri, 6 Feb 2004 09:08:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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" > 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 From exim@www1.ietf.org Fri Feb 6 10:48:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02009 for ; Fri, 6 Feb 2004 10:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8Cw-0004Ng-J9 for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 10:47:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Flsj5016836 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 10:47:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8Cw-0004NT-5I for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 10:47:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02005 for ; Fri, 6 Feb 2004 10:47:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8Ct-00064J-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 10:47:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8C0-0005zZ-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 10:46:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8B5-0005rp-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 10:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8B6-00047n-V5; Fri, 06 Feb 2004 10:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8A9-00041J-T8 for xcon@optimus.ietf.org; Fri, 06 Feb 2004 10:45:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01800 for ; Fri, 6 Feb 2004 10:44:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8A7-0005jv-00 for xcon@ietf.org; Fri, 06 Feb 2004 10:44:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap899-0005cB-00 for xcon@ietf.org; Fri, 06 Feb 2004 10:44:01 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Ap88C-0005Sa-00 for xcon@ietf.org; Fri, 06 Feb 2004 10:43:00 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Feb 2004 07:42:21 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i16FgRYO005826; Fri, 6 Feb 2004 10:42:28 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWU80462; Fri, 6 Feb 2004 07:42:27 -0800 (PST) Message-Id: <4.3.2.7.2.20040206102325.00b2fee0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 10:42:26 -0500 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [XCON] CPCP Requirement: Repeat times Cc: "'petri.koskelainen@nokia.com'" , fluffy@cisco.com, "Rosen, Brian" , drage@lucent.com, klantz@cisco.com, xcon@ietf.org, dbieseli@cisco.com In-Reply-To: <313680C9A886D511A06000204840E1CF070B63AB@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 08:21 AM 2/6/2004 -0500, Rosen, Brian wrote: >I don't understand what you are talking about. > >End when last person leaves is the way many bridges work. Is that a technical justification? >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. 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. >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. Who is the authority here? Isnt' the bridge-providing service supposed to obey 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? >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. >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 bridge may need to be released and re-captured, but that does not mean the conference is re-started. > 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. 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 >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" 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 From exim@www1.ietf.org Fri Feb 6 10:49:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02069 for ; Fri, 6 Feb 2004 10:49:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8Do-0004ZG-Fr for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 10:48:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Fmmvd017552 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 10:48:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8Do-0004Z1-AI for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 10:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02066 for ; Fri, 6 Feb 2004 10:48:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8Dl-00066c-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 10:48:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8Ct-00064N-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 10:47:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8C2-0005zo-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 10:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8C4-0004Fh-Kt; Fri, 06 Feb 2004 10:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8BL-0004Ar-TU for xcon@optimus.ietf.org; Fri, 06 Feb 2004 10:46:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01866 for ; Fri, 6 Feb 2004 10:46:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8BJ-0005u2-00 for xcon@ietf.org; Fri, 06 Feb 2004 10:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8AN-0005mu-00 for xcon@ietf.org; Fri, 06 Feb 2004 10:45:17 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap89V-0005a6-00 for xcon@ietf.org; Fri, 06 Feb 2004 10:44:21 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i16Fhir02777 for ; Fri, 6 Feb 2004 09:43:45 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Feb 2004 15:43:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EFD5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rosen, Brian'" , "'petri.koskelainen@nokia.com'" , fluffy@cisco.com, "Drage, Keith (Keith)" , klantz@cisco.com Cc: xcon@ietf.org, dbieseli@cisco.com Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Fri, 6 Feb 2004 15:43:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I support Brian on this one. If we have a requirement that means a car needs windows, and a second requirement that means a car needs doors, we don't try and rewrite the requirement such that the car only needs windows, because people can climb out of the windows. Lets write the requirements so we know what we are trying to solve. regards Keith > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 06 February 2004 14:09 > To: 'petri.koskelainen@nokia.com'; fluffy@cisco.com; drage@lucent.com; > klantz@cisco.com > Cc: xcon@ietf.org; dbieseli@cisco.com > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > This seems way too twisted to me. > > Yes, you can force fit start/stop the way you propose, but it doesn't > match most people's view of how things ought to work. > > I'd prefer an enumeration on what stop means. > > Brian > > > > > -----Original Message----- > > From: petri.koskelainen@nokia.com > [mailto:petri.koskelainen@nokia.com] > > Sent: Friday, February 06, 2004 8:56 AM > > To: Brian.Rosen@marconi.com; fluffy@cisco.com; drage@lucent.com; > > klantz@cisco.com > > Cc: xcon@ietf.org; dbieseli@cisco.com > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > End when last person leaves is the way many bridges work. > You might > > > not like it, but that's the way they work. Most bridges don't > > > start if the convener is not there. > > > > You can implement this feature via CPCP by setting the start time > > just before you join. > > > > > If he arrives, and then leaves, the conference is over. > > > > So it is impossible for a convener to hang up and re-join as > > the conference > > has been ended already ? > > > > With start/stop times you can implement this kind of service > > (I mean if you really want this) > > or you may create similar service with more features. > > Convener can use CPCP and modify start/stop times as needed > > (thus creating > > the service you described). > > > > > It also doesn't work to manipulate stop time to end the > conference > > > because its the bridge that wants to enforce its policy and > > not the convener. > > > > Hmm..If bridge does not have to obey CPCP it can do > whatever it likes. > > The purpose of CPCP is to give the convener the power to > > define the policy. > > > > > If the policy is that the conference ends when stop time is > > > reached, and the convener leaves with stop time set long, > > how does the > > > conference end? > > > > It ends when stop time is reached or when convener ends it via CPCP. > > > > > How does any participant know? > > > > Conference policy describes stop time. This also allows > > people hanging up for a while > > and rejoining (e.g. via different terminal). This would not > > be possible > > otherwise. > > > > > Also, Petri, you can't implement a "Meet Me" with start/stop. > > > > Yes I can. Convener can use CPCP and set start_time=NOW and > > join the conference. > > When convener leaves the conference he can set stop_time=NOW. > > > > > > > MeetMes don't have start and stop times. They start > > whenever the convener > > > arrives, end when he leaves (usually), but restart when he > > arrives again > > > with out regard to start and stop. > > > > Yes, but this can be achieved via CPCP. > > > > > > Petri > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: petri.koskelainen@nokia.com > > > [mailto:petri.koskelainen@nokia.com] > > > > Sent: Friday, February 06, 2004 3:08 AM > > > > To: fluffy@cisco.com; Brian.Rosen@marconi.com; drage@lucent.com; > > > > klantz@cisco.com > > > > Cc: xcon@ietf.org; dbieseli@cisco.com > > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > what is wrong with start and stop times? > > > > They should cover all use cases. The use case you are > referring to > > > > is easy since we already have start/stop times. > > > > > > > > I don't like "stop when last person leaves" either since (in > > > > the end of conference) > > > > you could hang up, get coffee and join again. This scenario > > > > can be achieved with stop time, though. > > > > > > > > All uses cases I have seen can be solved with simple > > > start/stop times. > > > > (note: stop time can be modified anytime, and ACLs are in use). > > > > > > > > Petri > > > > > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > Cullen Jennings > > > > > Sent: 06 February, 2004 09:58 > > > > > To: Brian Rosen; 'Drage, Keith (Keith)'; Keith A Lantz > > > > > Cc: XCON-IETF; Dave Bieselin > > > > > Subject: Re: [XCON] CPCP Requirement: Repeat times > > > > > > > > > > > > > > > > > > > > I want something more complex that these. - I don't like > > > > > systems where the > > > > > first person dials in, realizes they are the only person > > > > there because > > > > > everyone else is 5 minutes late, hangs up to go get a coffee > > > > > and now the > > > > > conference has ended and no one else can join. > > > > > > > > > > > > > > > On 2/5/04 6:01 AM, "Rosen, Brian" > > 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 From exim@www1.ietf.org Fri Feb 6 13:29:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08415 for ; Fri, 6 Feb 2004 13:29:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApAij-00011n-FC for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 13:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16ISrTV003947 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 13:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApAij-00011a-A6 for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 13:28:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08398 for ; Fri, 6 Feb 2004 13:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApAih-0001KT-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 13:28:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAhk-0001HO-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 13:27:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApAgu-0001Eq-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 13:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApAgu-0000uU-St; Fri, 06 Feb 2004 13:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApAgt-0000uG-GY for xcon@optimus.ietf.org; Fri, 06 Feb 2004 13:26:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08355 for ; Fri, 6 Feb 2004 13:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApAgr-0001Ed-00 for xcon@ietf.org; Fri, 06 Feb 2004 13:26:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAfv-0001Bj-00 for xcon@ietf.org; Fri, 06 Feb 2004 13:26:00 -0500 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1ApAfi-00017y-00 for xcon@ietf.org; Fri, 06 Feb 2004 13:25:47 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <12XFRLPW>; Fri, 6 Feb 2004 20:25:15 +0200 Message-ID: From: "Even, Roni" To: "'Cullen Jennings '" , "'Brian Rosen '" , "''Drage, Keith (Keith)' '" , "'Keith A Lantz '" Cc: "'XCON-IETF '" , "'Dave Bieselin '" Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Fri, 6 Feb 2004 20:25:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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" 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 From exim@www1.ietf.org Fri Feb 6 13:38:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08741 for ; Fri, 6 Feb 2004 13:38:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApArV-00023D-Bm for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 13:37:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Ibvsg007861 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 13:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApArU-00022a-1A for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 13:37:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08727 for ; Fri, 6 Feb 2004 13:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApArR-0001tz-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 13:37:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAqX-0001rB-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 13:36:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApApc-0001o7-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 13:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApApd-0001hU-DD; Fri, 06 Feb 2004 13:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApAoi-0001af-5H for xcon@optimus.ietf.org; Fri, 06 Feb 2004 13:35:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08609 for ; Fri, 6 Feb 2004 13:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApAog-0001kP-00 for xcon@ietf.org; Fri, 06 Feb 2004 13:35:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAno-0001gr-00 for xcon@ietf.org; Fri, 06 Feb 2004 13:34:09 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1ApAnS-0001c3-00 for xcon@ietf.org; Fri, 06 Feb 2004 13:33:46 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ9A4NL>; Fri, 6 Feb 2004 13:33:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63B2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Michael Hammer'" Cc: "'petri.koskelainen@nokia.com'" , fluffy@cisco.com, "Rosen, Brian" , drage@lucent.com, klantz@cisco.com, xcon@ietf.org, dbieseli@cisco.com Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Fri, 6 Feb 2004 13:33:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > >End when last person leaves is the way many bridges work. > > Is that a technical justification? Actually, I think it means there is a requirement for that to be possible. > > >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. > > 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. 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. > > >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. > > Who is the authority here? Isnt' the bridge-providing > service supposed to > obey policy? As above, local policy must override. ....snip... > 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. 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. > > >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. 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. > > >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 bridge may need to be released and re-captured, but that > does not mean > 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"? > > > 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. > > 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. > > > 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. 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. > > >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. 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. > > >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. 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. > > 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. 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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Feb 6 14:54:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12007 for ; Fri, 6 Feb 2004 14:54:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC32-00089v-GN for xcon-archive@odin.ietf.org; Fri, 06 Feb 2004 14:53:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Jrua1031360 for xcon-archive@odin.ietf.org; Fri, 6 Feb 2004 14:53:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC32-00089j-8j for xcon-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 14:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11977 for ; Fri, 6 Feb 2004 14:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApC2z-00076I-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 14:53:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApC22-000722-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 14:52:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApC19-0006z6-00 for xcon-web-archive@ietf.org; Fri, 06 Feb 2004 14:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC1A-0007dc-ST; Fri, 06 Feb 2004 14:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC14-0007dD-Ns for xcon@optimus.ietf.org; Fri, 06 Feb 2004 14:51:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11926 for ; Fri, 6 Feb 2004 14:51:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApC11-0006y3-00 for xcon@ietf.org; Fri, 06 Feb 2004 14:51:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApC05-0006um-00 for xcon@ietf.org; Fri, 06 Feb 2004 14:50:54 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1ApBzD-0006pR-00 for xcon@ietf.org; Fri, 06 Feb 2004 14:49:59 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Feb 2004 11:48:58 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i16JnRYO029404; Fri, 6 Feb 2004 14:49:27 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWV03750; Fri, 6 Feb 2004 11:49:25 -0800 (PST) Message-Id: <4.3.2.7.2.20040206134127.035334a8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 14:49:25 -0500 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [XCON] CPCP Requirement: Repeat times Cc: "'petri.koskelainen@nokia.com'" , fluffy@cisco.com, "Rosen, Brian" , drage@lucent.com, klantz@cisco.com, xcon@ietf.org, dbieseli@cisco.com In-Reply-To: <313680C9A886D511A06000204840E1CF070B63B2@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 At 01:33 PM 2/6/2004 -0500, Rosen, Brian wrote: > > >End when last person leaves is the way many bridges work. > > > > Is that a technical justification? >Actually, I think it means there is a requirement for that to be possible. Agree. Don't see that as not possible. > > > > >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. > > > > 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. >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. 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 >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. > > > > > >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. > > > > Who is the authority here? Isnt' the bridge-providing > > service supposed to > > obey policy? >As above, local policy must override. I agree, in the sense that local policy drives convener policy that drives bridge resource provided/withheld. >....snip... > > 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. >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. 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. > > > > >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. >I've proposed that start time is the earliest time at which >mixing starts. 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.) >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. 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)? > > > > >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 bridge may need to be released and re-captured, but that > > does not mean > > the conference is re-started. >Possibly a minor semantic argument. I think we both agree that >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 >difference between "release and recapture" and "reset start"? One appears to be a new conference instance, while the other appears to be a modification of an existing conference. > > > > > 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. > > > > 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. > > > > > > 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. >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. >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 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. >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. > > > > >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. >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. OK > > > > >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. >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. 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 >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. 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? >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. > > > > > 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. >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? That sounds like a service description which may be implementation dependent. >You got >there with the conference URI, you can probably manipulate some resources _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Feb 9 05:50:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11506 for ; Mon, 9 Feb 2004 05:50:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8zF-0000Qz-5L for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 05:49:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Anv7P001665 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 05:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8zE-0000Qm-RI for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 05:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11487 for ; Mon, 9 Feb 2004 05:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8zB-0005LC-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 05:49:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq8yC-0005Gm-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 05:48:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8xK-0005CC-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 05:47:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8xN-0000LY-3g; Mon, 09 Feb 2004 05:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq8wT-0000Jo-7B for xcon@optimus.ietf.org; Mon, 09 Feb 2004 05:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11438 for ; Mon, 9 Feb 2004 05:47:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8wP-00056h-00 for xcon@ietf.org; Mon, 09 Feb 2004 05:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq8vS-00051a-00 for xcon@ietf.org; Mon, 09 Feb 2004 05:46:04 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aq8uv-0004wW-00 for xcon@ietf.org; Mon, 09 Feb 2004 05:45:29 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19AjUq08109 for ; Mon, 9 Feb 2004 12:45:30 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 12:45:29 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 12:45:29 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Mon, 9 Feb 2004 12:45:24 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179771C@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPs6rf1AQTG0aQkTcejjf208dMIDACDHVEw To: , Cc: , , , , , , X-OriginalArrivalTime: 09 Feb 2004 10:45:29.0133 (UTC) FILETIME=[D56AF5D0:01C3EEF9] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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-usag= e-02.txt Regards, Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Michael Hammer > Sent: 06.February.2004 21:49 > To: Rosen, Brian > Cc: Koskelainen Petri (Nokia-NRC/Tampere); fluffy@cisco.com; Rosen, > Brian; drage@lucent.com; klantz@cisco.com; xcon@ietf.org; > dbieseli@cisco.com > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Brian, >=20 > I may be a little confused by what is meant by policy and policy=20 > manipulation with respect to how that translates into resources being=20 > invoked and released. My vision (delusion) as to how that=20 > might work might=20 > have to wait to see the actual protocol develop. But, I=20 > suspect that your=20 > answers to my comments below will help clear this up for me. >=20 > Mike >=20 >=20 > At 01:33 PM 2/6/2004 -0500, Rosen, Brian wrote: > > > >End when last person leaves is the way many bridges work. > > > > > > Is that a technical justification? > >Actually, I think it means there is a requirement for that=20 > to be possible. >=20 > Agree. Don't see that as not possible. >=20 >=20 > > > > > > >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=20 > then leaves, > > > >the conference is over. > > > > > > 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=20 > it stops. > >CPCP has two elements, and they each have a role in policy. > >A particular implementation, or more properly, a particular=20 > administrative > >action, may restrict the range of possible policy requests=20 > the convener > >may ask for. The bridge may not respond the way the=20 > convener would like > >it to. It must be possible for the bridge to have local=20 > policy, and yet > >allow the convener to manipulate whatever freedoms the local policy > >permits. >=20 > I agree with this part. The local "uber-policy" determines if the=20 > convener's policy request is accepted or rejected. >=20 >=20 > >You could have the bridge change the start/stop time itself >=20 > I don't follow this part. It seems to confuse the role of=20 > the bridge in=20 > committing to the use of resources and the role of the convener in=20 > committing to pay for what he has asked for. If it is the=20 > intent of the=20 > requester to terminate the conference upon his leaving, then=20 > that should=20 > be an option of the request he makes to the bridge. >=20 > If he is requesting that the bridge terminate upon his=20 > departure, shouldn't=20 > that be an update to his policy? Same for other options. =20 > The bridge of=20 > course may have resource limitations, and thus there may be=20 > conditional=20 > authorizations to what is requested. Where I think I have=20 > some confusion=20 > is that some of these options/authorizations are implicit not=20 > explicit. >=20 > >to implement > >its local policy, but that makes the function even more twisted. > >Better to have explicit mechanisms, and let the bridge=20 > implement, or permit > >a subset of them if it wishes. > > > > > > > > >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=20 > the convener. > > > > > > Who is the authority here? Isnt' the bridge-providing > > > service supposed to > > > obey policy? > >As above, local policy must override. >=20 > I agree, in the sense that local policy drives convener=20 > policy that drives=20 > bridge resource provided/withheld. >=20 >=20 > >....snip... > > > 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. > >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=20 > policy permits, > >and the participants have to have some way to understand what is > >going to happen. >=20 > But, isn't the time at which the local policy interacts with=20 > the convener=20 > request independent of when a particular bridge resource gets=20 > assigned? A=20 > convener request could be accepted so long as there are=20 > enough resources=20 > available/reserved in the pool, whether or not a resource is=20 > actually put=20 > to use. >=20 >=20 > > > > > > >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. > >I've proposed that start time is the earliest time at which > >mixing starts. >=20 > I thought this was a policy? This would mean that the start=20 > time would be=20 > the earliest time at which mixing is permitted to start. Isn't this=20 > independent of whether a resource was invoked? Note, it may=20 > be reserved=20 > un-occupied and billed for, but that may not be the most=20 > efficient use of=20 > resources. (No statistical over-booking allowed.) >=20 >=20 > >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. >=20 > Could this not be defined as the latest time at which mixing=20 > is permitted=20 > to be used, i.e. that the enumeration option is whether the=20 > stop time may=20 > get updated explicitly by the convener or another party or=20 > implicitly by a=20 > convener agent (could be the bridge)? >=20 >=20 > > > > > > >As to Cullen's objection, what you are worried about is=20 > start time, > > > >and not stop time. By your definition, the conference=20 > 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=20 > 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 bridge may need to be released and re-captured, but that > > > does not mean > > > the conference is re-started. > >Possibly a minor semantic argument. I think we both agree that > >the scheduled conference did not take place. >=20 > Are we talking when a convener was authorized to invoke a conference=20 > resource or accounting for when resources were actually used? > I believe that some conference services still charge as the=20 > resources where=20 > reserved and represent an opportunity cost. >=20 > >What is the > >difference between "release and recapture" and "reset start"? >=20 > One appears to be a new conference instance, while the other=20 > appears to be=20 > a modification of an existing conference. >=20 >=20 > > > > > > > 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. > > > > > > 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=20 > implement it > >by twisting start/stop? I guess, but I don't think its a good idea. > > > > > > > > > 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. > >That's the way Meet Me (notice the word "Me") services are defined. >=20 > I should note that the term "meet me" has been used in a more=20 > broad way to=20 > mean any pre-scheduled conference for which a number=20 > (address) has be setup=20 > and to which users are asked to call into at some future=20 > time. You seem to=20 > have something more specific in mind. I have no problem with=20 > a specific,=20 > maybe trademarked, service to be more narrowly defined, but=20 > see no reason=20 > to limit other possibilities. >=20 > >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. >=20 > I have not problem with this being possible, just don't think=20 > CPCP should=20 > be restricted for being used in other ways. Protocol should=20 > be generally=20 > usable for many types of services. >=20 > >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. > > > > > > >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. > >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=20 > ability to say that. >=20 > OK >=20 >=20 > > > > > > >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. > >Well, a new start/stop MAY be a new conference, or it could=20 > be a reschedule > >of an existing one. Take a scenario where a couple of=20 > participants show, > >the convener doesn't, and the participants leave. >=20 > Hopefully, the convener could show up late and the conference=20 > is still=20 > active and resources get invoked for him and whoever else=20 > shows up late. >=20 > >The convener pushes > >start and stop an hour. If its a new conference, there is a=20 > new conference > >URI. > >If its a reschedule, then its the same conference, and the=20 > same URI. I > >think > >that is preferable. >=20 > So long as the convener shows up within the hour it was originally=20 > scheduled, could it be neither a new conference nor a=20 > reschedule? Suppose=20 > he shows 20 minutes late, but only needs 40 minutes to get=20 > the work done,=20 > why should any policy change take place? >=20 >=20 > >Local policy, as I advocate, is indeed a controlling factor.=20 > However, to be > >successful, the convener and the participants have to know=20 > what the local > >policy is, so that their expectations are met. That means=20 > 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=20 > it. It's not > >just 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. > >Confused about "what a conference is". I think we are all=20 > working on the > >"how it is to be supported". I don't even want to think=20 > about a definition > >of what it is. For example, if I play music on hold to you=20 > while you are > >waiting for a conference to start, is that part of the conference? >=20 > That sounds like a service description which may be=20 > implementation dependent. >=20 > >You got > >there with the conference URI, you can probably manipulate=20 > some resources >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Feb 9 09:39:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21201 for ; Mon, 9 Feb 2004 09:39:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCYy-00065i-Lj for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 09:39:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Ed45H023408 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 09:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCYy-00065S-D2 for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 09:39:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21186 for ; Mon, 9 Feb 2004 09:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCYw-0004IL-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 09:39:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCXx-0004Dc-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 09:38:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCWy-00047Y-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 09:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCWz-0005iW-GQ; Mon, 09 Feb 2004 09:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCW6-0005hd-81 for xcon@optimus.ietf.org; Mon, 09 Feb 2004 09:36:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21142 for ; Mon, 9 Feb 2004 09:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCW4-00045D-00 for xcon@ietf.org; Mon, 09 Feb 2004 09:36:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCVE-000412-00 for xcon@ietf.org; Mon, 09 Feb 2004 09:35:13 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqCUj-0003va-00 for xcon@ietf.org; Mon, 09 Feb 2004 09:34:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2004 06:41:21 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i19EY89T000257; Mon, 9 Feb 2004 06:34:08 -0800 (PST) Received: from [212.157.205.40] (sjc-vpn1-181.cisco.com [10.21.96.181]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AME61922; Mon, 9 Feb 2004 06:34:02 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 09 Feb 2004 06:34:00 -0800 Subject: Re: [XCON] CPCP Requirement: Repeat times From: Cullen Jennings To: , Michael P Hammer , Brian Rosen CC: , , Keith A Lantz , XCON-IETF , Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179771C@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, "hisham.khartabil@nokia.com" 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 > >> -----Original Message----- >> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext >> Michael Hammer >> Sent: 06.February.2004 21:49 >> To: Rosen, Brian >> Cc: Koskelainen Petri (Nokia-NRC/Tampere); fluffy@cisco.com; Rosen, >> Brian; drage@lucent.com; klantz@cisco.com; xcon@ietf.org; >> dbieseli@cisco.com >> Subject: RE: [XCON] CPCP Requirement: Repeat times >> >> >> 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 >> >> >> At 01:33 PM 2/6/2004 -0500, Rosen, Brian wrote: >>>>> End when last person leaves is the way many bridges work. >>>> >>>> Is that a technical justification? >>> Actually, I think it means there is a requirement for that >> to be possible. >> >> Agree. Don't see that as not possible. >> >> >>>> >>>>> 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. >>>> >>>> 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. >>> 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. >> >> 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 >>> 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. >>> >>>> >>>>> 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. >>>> >>>> Who is the authority here? Isnt' the bridge-providing >>>> service supposed to >>>> obey policy? >>> As above, local policy must override. >> >> I agree, in the sense that local policy drives convener >> policy that drives >> bridge resource provided/withheld. >> >> >>> ....snip... >>>> 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. >>> 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. >> >> 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. >> >> >>>> >>>>> 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. >>> I've proposed that start time is the earliest time at which >>> mixing starts. >> >> 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.) >> >> >>> 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. >> >> 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)? >> >> >>>> >>>>> 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 bridge may need to be released and re-captured, but that >>>> does not mean >>>> the conference is re-started. >>> Possibly a minor semantic argument. I think we both agree that >>> 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 >>> difference between "release and recapture" and "reset start"? >> >> One appears to be a new conference instance, while the other >> appears to be >> a modification of an existing conference. >> >> >>>> >>>>> 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. >>>> >>>> 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. >>> >>>> >>>>> 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. >>> 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. >> >>> 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 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. >> >>> 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. >>>> >>>>> 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. >>> 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. >> >> OK >> >> >>>> >>>>> 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. >>> 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. >> >> 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 >>> 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. >> >> 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? >> >> >>> 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. >>> >>>> >>>> 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. >>> 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? >> >> That sounds like a service description which may be >> implementation dependent. >> >>> You got >>> there with the conference URI, you can probably manipulate >> some resources >> >> >> _______________________________________________ >> 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 From exim@www1.ietf.org Mon Feb 9 10:00:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22035 for ; Mon, 9 Feb 2004 10:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCtJ-0007Lx-J9 for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 10:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19F05Gu028258 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 10:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCtJ-0007LZ-9k for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:00:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22006 for ; Mon, 9 Feb 2004 10:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCtG-0005yW-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 10:00:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCsI-0005tZ-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 09:59:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCrI-0005mD-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 09:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCrJ-0007Db-ES; Mon, 09 Feb 2004 09:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCqQ-0007Cb-88 for xcon@optimus.ietf.org; Mon, 09 Feb 2004 09:57:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21951 for ; Mon, 9 Feb 2004 09:57:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCqO-0005l9-00 for xcon@ietf.org; Mon, 09 Feb 2004 09:57:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCpT-0005hJ-00 for xcon@ietf.org; Mon, 09 Feb 2004 09:56:08 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AqCpD-0005dI-00 for xcon@ietf.org; Mon, 09 Feb 2004 09:55:51 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1JJ9CFDS>; Mon, 9 Feb 2004 09:55:15 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63C5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , hisham.khartabil@nokia.com, Michael P Hammer Cc: petri.koskelainen@nokia.com, drage@lucent.com, Keith A Lantz , XCON-IETF , dbieseli@cisco.com Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Mon, 9 Feb 2004 09:55:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, February 09, 2004 9:34 AM > To: hisham.khartabil@nokia.com; Michael P Hammer; Brian Rosen > Cc: petri.koskelainen@nokia.com; drage@lucent.com; Keith A Lantz; > XCON-IETF; dbieseli@cisco.com > Subject: Re: [XCON] CPCP Requirement: Repeat times > > > > 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, "hisham.khartabil@nokia.com" > > 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 > > > >> -----Original Message----- > >> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of ext > >> Michael Hammer > >> Sent: 06.February.2004 21:49 > >> To: Rosen, Brian > >> Cc: Koskelainen Petri (Nokia-NRC/Tampere); fluffy@cisco.com; Rosen, > >> Brian; drage@lucent.com; klantz@cisco.com; xcon@ietf.org; > >> dbieseli@cisco.com > >> Subject: RE: [XCON] CPCP Requirement: Repeat times > >> > >> > >> 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 > >> > >> > >> At 01:33 PM 2/6/2004 -0500, Rosen, Brian wrote: > >>>>> End when last person leaves is the way many bridges work. > >>>> > >>>> Is that a technical justification? > >>> Actually, I think it means there is a requirement for that > >> to be possible. > >> > >> Agree. Don't see that as not possible. > >> > >> > >>>> > >>>>> 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. > >>>> > >>>> 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. > >>> 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. > >> > >> 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 > >>> 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. > >>> > >>>> > >>>>> 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. > >>>> > >>>> Who is the authority here? Isnt' the bridge-providing > >>>> service supposed to > >>>> obey policy? > >>> As above, local policy must override. > >> > >> I agree, in the sense that local policy drives convener > >> policy that drives > >> bridge resource provided/withheld. > >> > >> > >>> ....snip... > >>>> 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. > >>> 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. > >> > >> 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. > >> > >> > >>>> > >>>>> 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. > >>> I've proposed that start time is the earliest time at which > >>> mixing starts. > >> > >> 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.) > >> > >> > >>> 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. > >> > >> 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)? > >> > >> > >>>> > >>>>> 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 bridge may need to be released and re-captured, but that > >>>> does not mean > >>>> the conference is re-started. > >>> Possibly a minor semantic argument. I think we both agree that > >>> 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 > >>> difference between "release and recapture" and "reset start"? > >> > >> One appears to be a new conference instance, while the other > >> appears to be > >> a modification of an existing conference. > >> > >> > >>>> > >>>>> 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. > >>>> > >>>> 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. > >>> > >>>> > >>>>> 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. > >>> 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. > >> > >>> 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 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. > >> > >>> 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. > >>>> > >>>>> 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. > >>> 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. > >> > >> OK > >> > >> > >>>> > >>>>> 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. > >>> 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. > >> > >> 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 > >>> 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. > >> > >> 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? > >> > >> > >>> 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. > >>> > >>>> > >>>> 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. > >>> 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? > >> > >> That sounds like a service description which may be > >> implementation dependent. > >> > >>> You got > >>> there with the conference URI, you can probably manipulate > >> some resources > >> > >> > >> _______________________________________________ > >> 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 From exim@www1.ietf.org Mon Feb 9 11:29:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26109 for ; Mon, 9 Feb 2004 11:29:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEHf-0002va-0e for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 11:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19GTIM7011250 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 11:29:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEHe-0002vN-R6 for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 11:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26102 for ; Mon, 9 Feb 2004 11:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEHd-0005ZV-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 11:29:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEGo-0005UL-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 11:28:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqEGO-0005OK-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 11:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEGO-0002qt-CL; Mon, 09 Feb 2004 11:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEFZ-0002kM-O7 for xcon@optimus.ietf.org; Mon, 09 Feb 2004 11:27:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25986 for ; Mon, 9 Feb 2004 11:27:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEFY-0005Lk-00 for xcon@ietf.org; Mon, 09 Feb 2004 11:27:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEEh-0005H7-00 for xcon@ietf.org; Mon, 09 Feb 2004 11:26:17 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AqEDt-00056q-00 for xcon@ietf.org; Mon, 09 Feb 2004 11:25:25 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2004 08:24:54 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i19GOqxH001592; Mon, 9 Feb 2004 11:24:52 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWV99741; Mon, 9 Feb 2004 08:24:51 -0800 (PST) Message-Id: <4.3.2.7.2.20040209111920.00b624c8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 11:24:50 -0500 To: From: Michael Hammer Subject: RE: [XCON] CPCP Requirement: Repeat times Cc: , , , , , , , In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179771C@esebe019.ntc.noki a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, hisham.khartabil@nokia.com 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 > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > > Michael Hammer > > Sent: 06.February.2004 21:49 > > To: Rosen, Brian > > Cc: Koskelainen Petri (Nokia-NRC/Tampere); fluffy@cisco.com; Rosen, > > Brian; drage@lucent.com; klantz@cisco.com; xcon@ietf.org; > > dbieseli@cisco.com > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > 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 > > > > > > At 01:33 PM 2/6/2004 -0500, Rosen, Brian wrote: > > > > >End when last person leaves is the way many bridges work. > > > > > > > > Is that a technical justification? > > >Actually, I think it means there is a requirement for that > > to be possible. > > > > Agree. Don't see that as not possible. > > > > > > > > > > > > >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. > > > > > > > > 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. > > >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. > > > > 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 > > >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. > > > > > > > > > > > >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. > > > > > > > > Who is the authority here? Isnt' the bridge-providing > > > > service supposed to > > > > obey policy? > > >As above, local policy must override. > > > > I agree, in the sense that local policy drives convener > > policy that drives > > bridge resource provided/withheld. > > > > > > >....snip... > > > > 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. > > >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. > > > > 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. > > > > > > > > > > > > >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. > > >I've proposed that start time is the earliest time at which > > >mixing starts. > > > > 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.) > > > > > > >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. > > > > 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)? > > > > > > > > > > > > >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 bridge may need to be released and re-captured, but that > > > > does not mean > > > > the conference is re-started. > > >Possibly a minor semantic argument. I think we both agree that > > >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 > > >difference between "release and recapture" and "reset start"? > > > > One appears to be a new conference instance, while the other > > appears to be > > a modification of an existing conference. > > > > > > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > > > > > 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. > > >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. > > > > >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 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. > > > > >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. > > > > > > > > >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. > > >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. > > > > OK > > > > > > > > > > > > >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. > > >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. > > > > 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 > > >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. > > > > 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? > > > > > > >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. > > > > > > > > > > > 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. > > >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? > > > > That sounds like a service description which may be > > implementation dependent. > > > > >You got > > >there with the conference URI, you can probably manipulate > > some resources > > > > > > _______________________________________________ > > 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 From exim@www1.ietf.org Mon Feb 9 11:45:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27692 for ; Mon, 9 Feb 2004 11:45:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEWR-0004r3-6T for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 11:44:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19GiZUS018654 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 11:44:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEWQ-0004qn-Nj for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 11:44:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27671 for ; Mon, 9 Feb 2004 11:44:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEWP-0000Ck-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 11:44:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEVf-00005X-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 11:43:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqEUv-0007kf-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 11:43:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqEUw-0005nv-HV for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 11:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEUu-0004dC-HL; Mon, 09 Feb 2004 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEU3-0004XG-Cv for xcon@optimus.ietf.org; Mon, 09 Feb 2004 11:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27455 for ; Mon, 9 Feb 2004 11:42:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEU2-0007gp-00 for xcon@ietf.org; Mon, 09 Feb 2004 11:42:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqET9-0007cD-00 for xcon@ietf.org; Mon, 09 Feb 2004 11:41:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqESk-0007Y9-00 for xcon@ietf.org; Mon, 09 Feb 2004 11:40:46 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19Gejq29387 for ; Mon, 9 Feb 2004 18:40:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 18:40:45 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 18:40:44 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 18:40:44 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Repeat times Date: Mon, 9 Feb 2004 18:40:44 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179771E@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPvKUJKTlJkMT5URAKrj7TlJBkTSQAAhqNw To: Cc: , , , , , , , X-OriginalArrivalTime: 09 Feb 2004 16:40:44.0677 (UTC) FILETIME=[7678DB50:01C3EF2B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Michael Hammer [mailto:mhammer@cisco.com] > Sent: 09.February.2004 18:25 > To: Khartabil Hisham (Nokia-TP/Helsinki) > Cc: Brian.Rosen@marconi.com; Koskelainen Petri (Nokia-NRC/Tampere); > fluffy@cisco.com; Brian.Rosen@marconi.com; drage@lucent.com; > klantz@cisco.com; xcon@ietf.org; dbieseli@cisco.com > Subject: RE: [XCON] CPCP Requirement: Repeat times=20 >=20 >=20 > Hisham, >=20 > Thanks. This fits my view of what is expected. One quick=20 > comment however=20 > (very minor nit) in 18.3: >=20 > "When saying that a conference starts, or becomes active=20 > (start-time), it=20 > means that the mixing starts." [... as soon as one or more=20 > inputs are=20 > available?] >=20 > Is it not possible that the start time has passed, yet no one=20 > has called in=20 > yet? So could it not be possible that no bridge resource (although=20 > assigned or reserved) is in use? How do you mix 0 inputs and outputs? Ok, I get your point. I'll fix the text. Thanks. Hisham >=20 > Mike >=20 >=20 >=20 > At 12:45 PM 2/9/2004 +0200, hisham.khartabil@nokia.com wrote: > >Admittedly, the current solution specifies that a convener=20 > needs to change=20 > >the stop time in order to terminate the conference, if he wants the=20 > >conference to end as he leaves. I sense that people want the=20 > convener to=20 > >explicitly indicate that instead of just modifying the=20 > stop-time. Am I=20 > >correct? I know Brian wants it so. > > > >I also would like to encourage people to read sections 12=20 > and 18.3 of the=20 > >solution draft. Those sections discuss exactly what this=20 > thread is all about. > > > >http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xc > ap-cpcp-usage-02.txt > > > >Regards, > >Hisham > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > > Michael Hammer > > > Sent: 06.February.2004 21:49 > > > To: Rosen, Brian > > > Cc: Koskelainen Petri (Nokia-NRC/Tampere);=20 > fluffy@cisco.com; Rosen, > > > Brian; drage@lucent.com; klantz@cisco.com; xcon@ietf.org; > > > dbieseli@cisco.com > > > Subject: RE: [XCON] CPCP Requirement: Repeat times > > > > > > > > > Brian, > > > > > > I may be a little confused by what is meant by policy and policy > > > manipulation with respect to how that translates into=20 > 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 > > > > > > > > > At 01:33 PM 2/6/2004 -0500, Rosen, Brian wrote: > > > > > >End when last person leaves is the way many bridges work. > > > > > > > > > > Is that a technical justification? > > > >Actually, I think it means there is a requirement for that > > > to be possible. > > > > > > Agree. Don't see that as not possible. > > > > > > > > > > > > > > > > >You might > > > > > >not like it, but that's the way they work. Most=20 > bridges don't > > > > > >start if the convener is not there. If he arrives, and > > > then leaves, > > > > > >the conference is over. > > > > > > > > > > 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. > > > >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=20 > local policy > > > >permits. > > > > > > 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 > > > >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. > > > > > > > > > > > > > > >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. > > > > > > > > > > Who is the authority here? Isnt' the bridge-providing > > > > > service supposed to > > > > > obey policy? > > > >As above, local policy must override. > > > > > > I agree, in the sense that local policy drives convener > > > policy that drives > > > bridge resource provided/withheld. > > > > > > > > > >....snip... > > > > > 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. > > > >I don't see it that way. I see it as the bridge has=20 > 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. > > > > > > 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. > > > > > > > > > > > > > > > > >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. > > > >I've proposed that start time is the earliest time at which > > > >mixing starts. > > > > > > 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. =20 > 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.) > > > > > > > > > >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. > > > > > > 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)? > > > > > > > > > > > > > > > > >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 bridge may need to be released and re-captured, but that > > > > > does not mean > > > > > the conference is re-started. > > > >Possibly a minor semantic argument. I think we both agree that > > > >the scheduled conference did not take place. > > > > > > Are we talking when a convener was authorized to invoke a=20 > 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 > > > >difference between "release and recapture" and "reset start"? > > > > > > One appears to be a new conference instance, while the other > > > appears to be > > > a modification of an existing conference. > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > You are asserting what the group is attempting to define. > > > >Well, we can twist start and stop, but to any person, a=20 > 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=20 > a good idea. > > > > > > > > > > > > > > > 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. > > > >That's the way Meet Me (notice the word "Me") services=20 > 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. > > > > > > >I happen to think its an excellent service. I would not=20 > 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,=20 > they can decide > > > >to have a conference (on my nickle) any time they want=20 > if there is > > > >not a restriction that convener starts. That is=20 > precisely why MeetMe > > > >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. > > > > > > >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=20 > a three way, > > > >or by the first person connecting to the conference, and=20 > it ends when > > > >the last person leaves (or for some, when the number of=20 > participants > > > >drops below 3). Ad-hoc is also a useful service, but=20 > usually we use > > > >ad-hoc internally where charging issues are simpler. > > > > > > > > > > >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=20 > says it can. > > > >Agree, but I want you to explicitly say that, and I want=20 > local policy > > > >to be able to permit you to say that, or deny you the > > > ability to say that. > > > > > > OK > > > > > > > > > > > > > > > > >but restart when he arrives again with out regard > > > > > >to start and stop. > > > > > > > > > > A new start and stop time is a new conference,=20 > 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. > > > >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. > > > > > > 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 > > > >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. > > > > > > 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? > > > > > > > > > >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=20 > learning the local > > > >policy, > > > >which means the language has to have the ability to express > > > it. It's not > > > >just 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. > > > >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=20 > conference? > > > > > > That sounds like a service description which may be > > > implementation dependent. > > > > > > >You got > > > >there with the conference URI, you can probably manipulate > > > some resources > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Feb 9 16:39:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16823 for ; Mon, 9 Feb 2004 16:39:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ6y-0006MS-C0 for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 16:38:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LcaEM024451 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 16:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ6x-0006MG-4E for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:38:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16734 for ; Mon, 9 Feb 2004 16:38:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJ6v-0006xn-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 16:38:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJ64-0006r3-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 16:37:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJ5Y-0006jt-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 16:37:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqJ5Z-00016o-7M for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 16:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ5W-0005xu-Ur; Mon, 09 Feb 2004 16:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJ4i-0005ei-SI for xcon@optimus.ietf.org; Mon, 09 Feb 2004 16:36:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16341 for ; Mon, 9 Feb 2004 16:36:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJ4g-0006Z7-00 for xcon@ietf.org; Mon, 09 Feb 2004 16:36:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJ36-0006E6-00 for xcon@ietf.org; Mon, 09 Feb 2004 16:34:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJ1d-0005sp-00 for xcon@ietf.org; Mon, 09 Feb 2004 16:33:05 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by mx2.foretec.com with smtp (Exim 4.24) id 1AqIx6-0000q7-He for xcon@ietf.org; Mon, 09 Feb 2004 16:28:24 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 28262; Mon, 09 Feb 2004 16:29:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Mon, 9 Feb 2004 16:27:43 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A11F@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPrBFI1bMtYRdwGSGeFqyDCB4WGiQABbbfQAQjokOA= From: "Eric Burger" To: Cc: Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm happy. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, February 04, 2004 5:33 AM > To: drage@lucent.com; fluffy@cisco.com; Eric Burger; xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > I agree with Keith. That's why we removed hidden participants=20 > and are content with anonymous. Legal interception can be=20 > local implementation and policy. >=20 > /Hisham >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Drage, Keith (Keith) > > Sent: 04.February.2004 11:47 > > To: Cullen Jennings; Eric Burger; XCON-IETF > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > >=20 > >=20 > > In the current mechanisms I know of for supporting legal=20 > > intercept (in 3GPP), the interceptor would not even be a=20 > > participant, therefore I am not convinced that this is=20 > > relevant to the issue of hidden participants anyway. [snip] _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Feb 9 19:24:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04308 for ; Mon, 9 Feb 2004 19:24:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLhR-0006Vi-CO for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 19:24:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0OPc3025020 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 19:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLhR-0006VT-6k for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 19:24:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04280 for ; Mon, 9 Feb 2004 19:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLhP-0007WA-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 19:24:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLgT-0007Qc-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 19:23:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqLg4-0007MR-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 19:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLg4-0006ST-Np; Mon, 09 Feb 2004 19:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLfS-0006S4-Tm for xcon@optimus.ietf.org; Mon, 09 Feb 2004 19:22:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04195 for ; Mon, 9 Feb 2004 19:22:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLfR-0007L8-00 for xcon@ietf.org; Mon, 09 Feb 2004 19:22:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLeS-0007Fd-00 for xcon@ietf.org; Mon, 09 Feb 2004 19:21:21 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqLdX-000744-00 for xcon@ietf.org; Mon, 09 Feb 2004 19:20:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2004 16:27:08 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1A0JpuA011686; Mon, 9 Feb 2004 16:19:51 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQD10999; Mon, 9 Feb 2004 16:19:47 -0800 (PST) Date: Tue, 10 Feb 2004 01:19:57 +0100 Subject: Re: [XCON] CPCP Requirement: Hidden Participants Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: , To: "Eric Burger" From: Rohan Mahy In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A11F@zoe.office.snowshore.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I believe there are plenty of uses for hidden participants. A robot that announces folks when they enter or whispers things to you in a sidebar via IM should be hidden. They detract from my view of who is there. This is very different from anonymous. thx, -rohan >> -----Original Message----- >> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >> Sent: Wednesday, February 04, 2004 5:33 AM >> To: drage@lucent.com; fluffy@cisco.com; Eric Burger; xcon@ietf.org >> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >> >> I agree with Keith. That's why we removed hidden participants >> and are content with anonymous. Legal interception can be >> local implementation and policy. >> >> /Hisham >> >>> -----Original Message----- >>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On >> Behalf Of ext >>> Drage, Keith (Keith) >>> Sent: 04.February.2004 11:47 >>> To: Cullen Jennings; Eric Burger; XCON-IETF >>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>> >>> >>> In the current mechanisms I know of for supporting legal >>> intercept (in 3GPP), the interceptor would not even be a >>> participant, therefore I am not convinced that this is >>> relevant to the issue of hidden participants anyway. > [snip] > > > _______________________________________________ > 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 From exim@www1.ietf.org Mon Feb 9 20:30:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09210 for ; Mon, 9 Feb 2004 20:30:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMic-0001Ad-J0 for xcon-archive@odin.ietf.org; Mon, 09 Feb 2004 20:29:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A1TgxY004493 for xcon-archive@odin.ietf.org; Mon, 9 Feb 2004 20:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMic-0001AO-Bo for xcon-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 20:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09092 for ; Mon, 9 Feb 2004 20:29:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMia-00001M-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 20:29:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqMhc-0007dc-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 20:28:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqMgX-0007Rq-00 for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 20:27:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqMWM-0004Jm-Cf for xcon-web-archive@ietf.org; Mon, 09 Feb 2004 20:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMWL-0000on-6b; Mon, 09 Feb 2004 20:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMVn-0000oJ-Vs for xcon@optimus.ietf.org; Mon, 09 Feb 2004 20:16:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08806 for ; Mon, 9 Feb 2004 20:16:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMVl-0006oE-00 for xcon@ietf.org; Mon, 09 Feb 2004 20:16:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqMUp-0006kD-00 for xcon@ietf.org; Mon, 09 Feb 2004 20:15:28 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AqMUQ-0006fr-00 for xcon@ietf.org; Mon, 09 Feb 2004 20:15:02 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 17:15:20 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Feb 2004 17:14:30 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 17:16:43 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2004 17:14:33 -0800 Message-ID: Thread-Topic: "Many users in a single operation" Requirements thread-index: AcPvcz3Jb4YIVoLBQDSBV/8FJxrYog== From: "Orit Levin" To: X-OriginalArrivalTime: 10 Feb 2004 01:16:44.0065 (UTC) FILETIME=[8BB49110:01C3EF73] Content-Transfer-Encoding: quoted-printable Subject: [XCON] "Many users in a single operation" Requirements Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi guys! =20 There are many places throughout the CPCP-req document that identify operations on a "subset of list" as MUST be performed in a single operation (e.g. G4, G6, H2, and H4). How do you plan to meet these requirements with "XCAP CPCP"? =20 The same question for REQ-CP-3: It MAY be possible for the client to batch multiple operations (such as add a user to ACL blocked list, or remove a user from ACL allowed list) into a single request that is processed atomically. =20 Thanks, Orit. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 01:34:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19199 for ; Tue, 10 Feb 2004 01:34:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqRSo-0008Ab-D7 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 01:33:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A6XgMY031399 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 01:33:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqRSo-0008AM-8K for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 01:33:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19190 for ; Tue, 10 Feb 2004 01:33:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqRSl-0005sA-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 01:33:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqRRn-0005nM-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 01:32:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqRR8-0005iR-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 01:31:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqRRA-00087l-Lj; Tue, 10 Feb 2004 01:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqRQm-000873-0L for xcon@optimus.ietf.org; Tue, 10 Feb 2004 01:31:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19128 for ; Tue, 10 Feb 2004 01:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqRQi-0005h4-00 for xcon@ietf.org; Tue, 10 Feb 2004 01:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqRPl-0005bG-00 for xcon@ietf.org; Tue, 10 Feb 2004 01:30:33 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AqROp-0005Rx-00 for xcon@ietf.org; Tue, 10 Feb 2004 01:29:35 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 28251; Tue, 10 Feb 2004 01:30:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2004 01:29:01 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A13B@zoe.office.snowshore.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TA== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Start/stop Proposal Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Since I started the thread "CPCP Requirement: Repeat times", which has = generated over 200 pages of responses (yes, I print stuff out to read on = airplanes), I thought I would give a concrete proposal that I _hope_ = will satisfy most of the excellent comments generated. First, two definitions: The CPCP Conference Start Time is the earliest mixing opportunity for a = conference. If you want to advertise a user-level start time, like when = you can call into a bridge and talk to an IVR system or listen to a = wonderful selection of music-on-hold, advertise the user-level start = time with SAP. The CPCP End Time is the time mixing ceases for a conference. If you = want to advertise a user-level stop time, like when everyone is supposed = to go out for lunch, but might not be the stop time, if things are going = peachy, advertise the user-level stop time with SAP. A Named Participant is a "special" participant. Usually this is the = conference owner. I would be happy to replace Named Participant with = Conference Owner, but I was thinking about delegating authority, e.g., = "Start this conference when I or my secretary join the bridge." Also, = if one examines CPCP End Time condition 2c, one can envision a policy = that states, "Keep the bridge up until both the CEO and the COO leave = the bridge." With those definitions, here is the proposal: The CPCP Start Time is the latter of: 1. A specified Earliest Mixing Time (which can be NOW or a time = delta/GMT) - AND ONE OF - 2a. The time the first participant arrives - OR - 2b. The time a Named Participant arrives The CPCP End Time is the earlier of: 1. A specified End of Mixing Time (which can be NOW, NEVER, or a time = delta/GMT) - AND ONE OF - 2a. The time the last participant leaves - OR - 2b. The time a Named Participant leaves - OR - 2c. The time the last Named Participant leaves - OR - 2d. Persistent (e.g., only the time (condition 1) matters) _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 03:05:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04942 for ; Tue, 10 Feb 2004 03:05:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSsx-0004u2-O3 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 03:04:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A84lqk018842 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 03:04:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSsv-0004tp-Oq for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 03:04:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04938 for ; Tue, 10 Feb 2004 03:04:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSsr-0005qo-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 03:04:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSru-0005lW-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 03:03:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqSrD-0005gX-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 03:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSrF-0004gl-29; Tue, 10 Feb 2004 03:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSqv-0004g9-3s for xcon@optimus.ietf.org; Tue, 10 Feb 2004 03:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04768 for ; Tue, 10 Feb 2004 03:02:37 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSqr-0005fI-00 for xcon@ietf.org; Tue, 10 Feb 2004 03:02:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSpv-0005ag-00 for xcon@ietf.org; Tue, 10 Feb 2004 03:01:40 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqSpD-0005WN-00 for xcon@ietf.org; Tue, 10 Feb 2004 03:00:56 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A80tv14137 for ; Tue, 10 Feb 2004 10:00:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Feb 2004 10:00:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 10:00:54 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Tue, 10 Feb 2004 10:00:54 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797721@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcPva5wItnjdNt9RQ9K4/o1xIIxm+wAQAqvg To: , Cc: X-OriginalArrivalTime: 10 Feb 2004 08:00:54.0963 (UTC) FILETIME=[025DF030:01C3EFAC] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We are all creative here and can come up with many use cases and = features, but there is a line that we have to draw in order to get = something finished. We're aiming at basic conferencing first. /Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 10.February.2004 02:20 > To: Eric Burger > Cc: Khartabil Hisham (Nokia-TP/Helsinki); xcon@ietf.org > Subject: Re: [XCON] CPCP Requirement: Hidden Participants >=20 >=20 > Hi, >=20 > I believe there are plenty of uses for hidden participants. A robot=20 > that announces folks when they enter or whispers things to you in a=20 > sidebar via IM should be hidden. They detract from my view of who is=20 > there. This is very different from anonymous. >=20 > thx, > -rohan >=20 >=20 > >> -----Original Message----- > >> From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > >> Sent: Wednesday, February 04, 2004 5:33 AM > >> To: drage@lucent.com; fluffy@cisco.com; Eric Burger; xcon@ietf.org > >> Subject: RE: [XCON] CPCP Requirement: Hidden Participants > >> > >> I agree with Keith. That's why we removed hidden participants > >> and are content with anonymous. Legal interception can be > >> local implementation and policy. > >> > >> /Hisham > >> > >>> -----Original Message----- > >>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > >> Behalf Of ext > >>> Drage, Keith (Keith) > >>> Sent: 04.February.2004 11:47 > >>> To: Cullen Jennings; Eric Burger; XCON-IETF > >>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants > >>> > >>> > >>> In the current mechanisms I know of for supporting legal > >>> intercept (in 3GPP), the interceptor would not even be a > >>> participant, therefore I am not convinced that this is > >>> relevant to the issue of hidden participants anyway. > > [snip] > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 03:23:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05616 for ; Tue, 10 Feb 2004 03:23:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqTAH-0006Gt-F0 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 03:22:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A8MfIc024101 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 03:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqTAH-0006Ge-3w for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 03:22:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05609 for ; Tue, 10 Feb 2004 03:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqTAE-0007Ud-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 03:22:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqT9K-0007QD-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 03:21:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqT8e-0007LX-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 03:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT8f-0006Bc-RI; Tue, 10 Feb 2004 03:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqT8K-0006Ac-JV for xcon@optimus.ietf.org; Tue, 10 Feb 2004 03:20:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05553 for ; Tue, 10 Feb 2004 03:20:39 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqT8I-0007Kl-00 for xcon@ietf.org; Tue, 10 Feb 2004 03:20:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqT7O-0007GA-00 for xcon@ietf.org; Tue, 10 Feb 2004 03:19:42 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqT6l-0007B1-00 for xcon@ietf.org; Tue, 10 Feb 2004 03:19:03 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A8J1v13848 for ; Tue, 10 Feb 2004 10:19:02 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Feb 2004 10:17:39 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 10:17:40 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] "Many users in a single operation" Requirements Date: Tue, 10 Feb 2004 10:17:39 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797722@esebe019.ntc.nokia.com> Thread-Topic: "Many users in a single operation" Requirements Thread-Index: AcPvcz3Jb4YIVoLBQDSBV/8FJxrYogAONw5w To: , X-OriginalArrivalTime: 10 Feb 2004 08:17:40.0005 (UTC) FILETIME=[596B2D50:01C3EFAE] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is an example of how to add multiple users to an ACL list in a = single operation: PUT = http://xcap.example.com/services/conferences/users/Alice/conference.xml? Conference/ACL/ACL-target-URI HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com The rest are done in a similar fashion. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Orit Levin > Sent: 10.February.2004 03:15 > To: xcon@ietf.org > Subject: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Hi guys! > =20 > There are many places throughout the CPCP-req document that identify > operations on a "subset of list" as MUST be performed in a single > operation (e.g. G4, G6, H2, and H4). > How do you plan to meet these requirements with "XCAP CPCP"? > =20 > The same question for REQ-CP-3: It MAY be possible for the client to > batch multiple operations (such as add a user to ACL blocked list, or > remove a user from ACL allowed list) into a single request that is > processed atomically. > =20 > Thanks, > Orit. >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:09:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21424 for ; Tue, 10 Feb 2004 10:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZVW-00043V-0g for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:09:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AF91Ej015583 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZVV-00043G-RY for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:09:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21353 for ; Tue, 10 Feb 2004 10:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZVT-00010l-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:08:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZUS-0000vF-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:07:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZTZ-0000qB-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZTY-0003MB-VK; Tue, 10 Feb 2004 10:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZTV-0003Kf-2t for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21162 for ; Tue, 10 Feb 2004 10:06:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZTT-0000pI-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:06:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZSa-0000kN-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:06:01 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AqZRc-0000Zr-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:05:00 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 10994; Tue, 10 Feb 2004 10:05:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 10:04:30 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A147@zoe.office.snowshore.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TAAglaCQAAzobPA= From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable nonononononono! It is NOT your choice: it is MY choice!!! These rules let me do ALL of the things that people want to do. Isn't = that the idea of policy: here are a few, simple rules that let one = construct whatever service (meet-me, hard-stop scheduled, end when last = leaves, end when time runs out, etc.) one wants? > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 10, 2004 3:34 AM > To: Eric Burger; xcon@softarmor.com > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Eric Burger > > Sent: 10.February.2004 08:29 > > To: IETF XCON Discussion List (E-mail) > > Subject: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > > Since I started the thread "CPCP Requirement: Repeat times",=20 >=20 > You really think so? Check again ;) >=20 > > which has generated over 200 pages of responses (yes, I print=20 > > stuff out to read on airplanes), I thought I would give a=20 > > concrete proposal that I _hope_ will satisfy most of the=20 > > excellent comments generated. > >=20 > >=20 > > First, two definitions: > >=20 > > The CPCP Conference Start Time is the earliest mixing=20 > > opportunity for a conference. If you want to advertise a=20 > > user-level start time, like when you can call into a bridge=20 > > and talk to an IVR system or listen to a wonderful selection=20 > > of music-on-hold, advertise the user-level start time with SAP. > >=20 > > The CPCP End Time is the time mixing ceases for a conference.=20 > > If you want to advertise a user-level stop time, like when=20 > > everyone is supposed to go out for lunch, but might not be=20 > > the stop time, if things are going peachy, advertise the=20 > > user-level stop time with SAP. > >=20 > > A Named Participant is a "special" participant. Usually this=20 > > is the conference owner. I would be happy to replace Named=20 > > Participant with Conference Owner, but I was thinking about=20 > > delegating authority, e.g., "Start this conference when I or=20 > > my secretary join the bridge." Also, if one examines CPCP=20 > > End Time condition 2c, one can envision a policy that states,=20 > > "Keep the bridge up until both the CEO and the COO leave=20 > the bridge." > >=20 > >=20 > > With those definitions, here is the proposal: > >=20 > > The CPCP Start Time is the latter of: > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > time delta/GMT) > > - AND ONE OF - > > 2a. The time the first participant arrives > > - OR - > > 2b. The time a Named Participant arrives >=20 > 2a is my choice >=20 > >=20 > >=20 > >=20 > > The CPCP End Time is the earlier of: > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > or a time delta/GMT) > > - AND ONE OF - > > 2a. The time the last participant leaves > > - OR - > > 2b. The time a Named Participant leaves > > - OR - > > 2c. The time the last Named Participant leaves > > - OR - > > 2d. Persistent (e.g., only the time (condition 1) matters) > >=20 >=20 > 2d is my choice here as well. Some conferences might still=20 > run eventhough there are no current participants. >=20 > Here is what our solution says: >=20 > If the element is not present, it > indicates that the conference starts immediately. If the=20 > > is set to zero, then conference occurrence is not bounded, i.e. > permanent, though it will not become active until the . > If the element is not present, it indicates that the > conference terminates as soon as the last participant leaves the > conference. >=20 > /Hisham >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:16:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22171 for ; Tue, 10 Feb 2004 10:16:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZcH-00065p-2R for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:16:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFG0UC023364 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZcG-00064O-Hb for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22118 for ; Tue, 10 Feb 2004 10:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZcE-0001eP-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:15:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZbG-0001YB-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:14:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZaJ-0001SH-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZaL-0005WV-8j; Tue, 10 Feb 2004 10:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZaJ-0005VM-7j for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:13:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21916 for ; Tue, 10 Feb 2004 10:13:55 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZaH-0001Rs-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:13:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZZL-0001MY-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:12:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqZYX-0001HJ-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:12:09 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFC8q05246 for ; Tue, 10 Feb 2004 17:12:08 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 17:12:07 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:12:06 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 17:12:06 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179772A@esebe019.ntc.nokia.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TAAupf2w To: X-OriginalArrivalTime: 10 Feb 2004 15:12:06.0766 (UTC) FILETIME=[3F29C8E0:01C3EFE8] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Eric, you should be using xcon@ietf.org. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Eric Burger > Sent: 10.February.2004 08:29 > To: IETF XCON Discussion List (E-mail) > Subject: [XCON] CPCP Start/stop Proposal >=20 >=20 > Since I started the thread "CPCP Requirement: Repeat times",=20 > which has generated over 200 pages of responses (yes, I print=20 > stuff out to read on airplanes), I thought I would give a=20 > concrete proposal that I _hope_ will satisfy most of the=20 > excellent comments generated. >=20 >=20 > First, two definitions: >=20 > The CPCP Conference Start Time is the earliest mixing=20 > opportunity for a conference. If you want to advertise a=20 > user-level start time, like when you can call into a bridge=20 > and talk to an IVR system or listen to a wonderful selection=20 > of music-on-hold, advertise the user-level start time with SAP. >=20 > The CPCP End Time is the time mixing ceases for a conference.=20 > If you want to advertise a user-level stop time, like when=20 > everyone is supposed to go out for lunch, but might not be=20 > the stop time, if things are going peachy, advertise the=20 > user-level stop time with SAP. >=20 > A Named Participant is a "special" participant. Usually this=20 > is the conference owner. I would be happy to replace Named=20 > Participant with Conference Owner, but I was thinking about=20 > delegating authority, e.g., "Start this conference when I or=20 > my secretary join the bridge." Also, if one examines CPCP=20 > End Time condition 2c, one can envision a policy that states,=20 > "Keep the bridge up until both the CEO and the COO leave the bridge." >=20 >=20 > With those definitions, here is the proposal: >=20 > The CPCP Start Time is the latter of: > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > time delta/GMT) > - AND ONE OF - > 2a. The time the first participant arrives > - OR - > 2b. The time a Named Participant arrives >=20 >=20 >=20 > The CPCP End Time is the earlier of: > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > or a time delta/GMT) > - AND ONE OF - > 2a. The time the last participant leaves > - OR - > 2b. The time a Named Participant leaves > - OR - > 2c. The time the last Named Participant leaves > - OR - > 2d. Persistent (e.g., only the time (condition 1) matters) >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:17:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22336 for ; Tue, 10 Feb 2004 10:17:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZdD-0006Ks-NR for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:16:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFGxUD024348 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZdD-0006KX-EH for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:16:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22280 for ; Tue, 10 Feb 2004 10:16:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZdB-0001lY-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:16:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZcG-0001ep-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:16:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZbJ-0001Yh-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZbK-0005os-Ns; Tue, 10 Feb 2004 10:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZbI-0005nb-2H for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:15:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22007 for ; Tue, 10 Feb 2004 10:14:56 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZbF-0001Y6-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:14:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZaJ-0001SB-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:14:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqZZR-0001Ml-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:13:05 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFD3q06288 for ; Tue, 10 Feb 2004 17:13:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 17:13:01 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:13:02 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:13:01 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 17:13:01 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179772B@esebe019.ntc.nokia.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TAAglaCQAA4eDyA= To: X-OriginalArrivalTime: 10 Feb 2004 15:13:01.0472 (UTC) FILETIME=[5FC54200:01C3EFE8] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Khartabil Hisham (Nokia-TP/Helsinki)=20 > Sent: 10.February.2004 10:34 > To: 'ext Eric Burger'; IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Eric Burger > > Sent: 10.February.2004 08:29 > > To: IETF XCON Discussion List (E-mail) > > Subject: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > > Since I started the thread "CPCP Requirement: Repeat times",=20 >=20 > You really think so? Check again ;) >=20 > > which has generated over 200 pages of responses (yes, I print=20 > > stuff out to read on airplanes), I thought I would give a=20 > > concrete proposal that I _hope_ will satisfy most of the=20 > > excellent comments generated. > >=20 > >=20 > > First, two definitions: > >=20 > > The CPCP Conference Start Time is the earliest mixing=20 > > opportunity for a conference. If you want to advertise a=20 > > user-level start time, like when you can call into a bridge=20 > > and talk to an IVR system or listen to a wonderful selection=20 > > of music-on-hold, advertise the user-level start time with SAP. > >=20 > > The CPCP End Time is the time mixing ceases for a conference.=20 > > If you want to advertise a user-level stop time, like when=20 > > everyone is supposed to go out for lunch, but might not be=20 > > the stop time, if things are going peachy, advertise the=20 > > user-level stop time with SAP. > >=20 > > A Named Participant is a "special" participant. Usually this=20 > > is the conference owner. I would be happy to replace Named=20 > > Participant with Conference Owner, but I was thinking about=20 > > delegating authority, e.g., "Start this conference when I or=20 > > my secretary join the bridge." Also, if one examines CPCP=20 > > End Time condition 2c, one can envision a policy that states,=20 > > "Keep the bridge up until both the CEO and the COO leave=20 > the bridge." > >=20 > >=20 > > With those definitions, here is the proposal: > >=20 > > The CPCP Start Time is the latter of: > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > time delta/GMT) > > - AND ONE OF - > > 2a. The time the first participant arrives > > - OR - > > 2b. The time a Named Participant arrives >=20 > 2a is my choice >=20 > >=20 > >=20 > >=20 > > The CPCP End Time is the earlier of: > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > or a time delta/GMT) > > - AND ONE OF - > > 2a. The time the last participant leaves > > - OR - > > 2b. The time a Named Participant leaves > > - OR - > > 2c. The time the last Named Participant leaves > > - OR - > > 2d. Persistent (e.g., only the time (condition 1) matters) > >=20 >=20 > 2d is my choice here as well. Some conferences might still=20 > run eventhough there are no current participants. >=20 > Here is what our solution says: >=20 > If the element is not present, it > indicates that the conference starts immediately. If the=20 > > is set to zero, then conference occurrence is not bounded, i.e. > permanent, though it will not become active until the . > If the element is not present, it indicates that the > conference terminates as soon as the last participant leaves the > conference. >=20 > /Hisham >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:18:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22467 for ; Tue, 10 Feb 2004 10:18:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZe6-0006aN-TH for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:17:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFHs14025307 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZe6-0006a5-Jp for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:17:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22414 for ; Tue, 10 Feb 2004 10:17:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZe4-0001rV-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:17:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZd8-0001l6-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:16:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZcF-0001ea-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZcG-00064s-QT; Tue, 10 Feb 2004 10:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZbP-0005r9-ML for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:15:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22019 for ; Tue, 10 Feb 2004 10:15:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZbN-0001Ym-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:15:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZaM-0001Sf-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:14:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqZZt-0001N2-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:13:33 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFDWv08934 for ; Tue, 10 Feb 2004 17:13:32 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 17:13:32 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:13:32 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 17:13:31 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179772C@esebe019.ntc.nokia.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TAAglaCQAAzobPAAATkoAA== To: X-OriginalArrivalTime: 10 Feb 2004 15:13:32.0512 (UTC) FILETIME=[72459600:01C3EFE8] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: 10.February.2004 16:57 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@softarmor.com > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 > nonononononono! >=20 > It is NOT your choice: it is MY choice!!! >=20 > These rules let me do ALL of the things that people want to=20 > do. Isn't that the idea of policy: here are a few, simple=20 > rules that let one construct whatever service (meet-me,=20 > hard-stop scheduled, end when last leaves, end when time runs=20 > out, etc.) one wants? >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, February 10, 2004 3:34 AM > > To: Eric Burger; xcon@softarmor.com > > Subject: RE: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > Behalf Of ext > > > Eric Burger > > > Sent: 10.February.2004 08:29 > > > To: IETF XCON Discussion List (E-mail) > > > Subject: [XCON] CPCP Start/stop Proposal > > >=20 > > >=20 > > > Since I started the thread "CPCP Requirement: Repeat times",=20 > >=20 > > You really think so? Check again ;) > >=20 > > > which has generated over 200 pages of responses (yes, I print=20 > > > stuff out to read on airplanes), I thought I would give a=20 > > > concrete proposal that I _hope_ will satisfy most of the=20 > > > excellent comments generated. > > >=20 > > >=20 > > > First, two definitions: > > >=20 > > > The CPCP Conference Start Time is the earliest mixing=20 > > > opportunity for a conference. If you want to advertise a=20 > > > user-level start time, like when you can call into a bridge=20 > > > and talk to an IVR system or listen to a wonderful selection=20 > > > of music-on-hold, advertise the user-level start time with SAP. > > >=20 > > > The CPCP End Time is the time mixing ceases for a conference.=20 > > > If you want to advertise a user-level stop time, like when=20 > > > everyone is supposed to go out for lunch, but might not be=20 > > > the stop time, if things are going peachy, advertise the=20 > > > user-level stop time with SAP. > > >=20 > > > A Named Participant is a "special" participant. Usually this=20 > > > is the conference owner. I would be happy to replace Named=20 > > > Participant with Conference Owner, but I was thinking about=20 > > > delegating authority, e.g., "Start this conference when I or=20 > > > my secretary join the bridge." Also, if one examines CPCP=20 > > > End Time condition 2c, one can envision a policy that states,=20 > > > "Keep the bridge up until both the CEO and the COO leave=20 > > the bridge." > > >=20 > > >=20 > > > With those definitions, here is the proposal: > > >=20 > > > The CPCP Start Time is the latter of: > > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > > time delta/GMT) > > > - AND ONE OF - > > > 2a. The time the first participant arrives > > > - OR - > > > 2b. The time a Named Participant arrives > >=20 > > 2a is my choice > >=20 > > >=20 > > >=20 > > >=20 > > > The CPCP End Time is the earlier of: > > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > > or a time delta/GMT) > > > - AND ONE OF - > > > 2a. The time the last participant leaves > > > - OR - > > > 2b. The time a Named Participant leaves > > > - OR - > > > 2c. The time the last Named Participant leaves > > > - OR - > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > >=20 > >=20 > > 2d is my choice here as well. Some conferences might still=20 > > run eventhough there are no current participants. > >=20 > > Here is what our solution says: > >=20 > > If the element is not present, it > > indicates that the conference starts immediately. If the=20 > > > > is set to zero, then conference occurrence is not bounded, i.e. > > permanent, though it will not become active until the=20 > . > > If the element is not present, it indicates that the > > conference terminates as soon as the last participant leaves the > > conference. > >=20 > > /Hisham > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:19:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22553 for ; Tue, 10 Feb 2004 10:19:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZf5-0006nz-NO for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:18:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFItVR026153 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:18:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZf5-0006nk-JA for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:18:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22518 for ; Tue, 10 Feb 2004 10:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZf3-0001xy-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:18:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZe8-0001s5-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:17:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZdD-0001lr-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZdE-0006LC-Gn; Tue, 10 Feb 2004 10:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZcI-00067a-MK for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:16:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22130 for ; Tue, 10 Feb 2004 10:15:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZcG-0001eg-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:16:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZbI-0001Yc-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:15:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqZaM-0001Sa-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:14:02 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFE0v09684 for ; Tue, 10 Feb 2004 17:14:00 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 17:13:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:13:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:13:57 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 17:13:57 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179772D@esebe019.ntc.nokia.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TAAglaCQAAzobPAAANCnwAAAbS0g To: X-OriginalArrivalTime: 10 Feb 2004 15:13:57.0446 (UTC) FILETIME=[81223660:01C3EFE8] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 10.February.2004 17:10 > To: 'ext Eric Burger'; xcon@softarmor.com > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 > Ok, I misunderstood what you meant earlier: You are saying=20 > that the creator of the conference needs to have those=20 > choices and the policy needs to enable creators to set that choice. >=20 > In this case, I would like to add the start-time a 2c:=20 > Persistent (e.g., only the time (condition 1) matters). I=20 > would also remove 2c for stop-time. >=20 > /Hisham >=20 > > -----Original Message----- > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > Sent: 10.February.2004 16:57 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@softarmor.com > > Subject: RE: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > > nonononononono! > >=20 > > It is NOT your choice: it is MY choice!!! > >=20 > > These rules let me do ALL of the things that people want to=20 > > do. Isn't that the idea of policy: here are a few, simple=20 > > rules that let one construct whatever service (meet-me,=20 > > hard-stop scheduled, end when last leaves, end when time runs=20 > > out, etc.) one wants? > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, February 10, 2004 3:34 AM > > > To: Eric Burger; xcon@softarmor.com > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > Eric Burger > > > > Sent: 10.February.2004 08:29 > > > > To: IETF XCON Discussion List (E-mail) > > > > Subject: [XCON] CPCP Start/stop Proposal > > > >=20 > > > >=20 > > > > Since I started the thread "CPCP Requirement: Repeat times",=20 > > >=20 > > > You really think so? Check again ;) > > >=20 > > > > which has generated over 200 pages of responses (yes, I print=20 > > > > stuff out to read on airplanes), I thought I would give a=20 > > > > concrete proposal that I _hope_ will satisfy most of the=20 > > > > excellent comments generated. > > > >=20 > > > >=20 > > > > First, two definitions: > > > >=20 > > > > The CPCP Conference Start Time is the earliest mixing=20 > > > > opportunity for a conference. If you want to advertise a=20 > > > > user-level start time, like when you can call into a bridge=20 > > > > and talk to an IVR system or listen to a wonderful selection=20 > > > > of music-on-hold, advertise the user-level start time with SAP. > > > >=20 > > > > The CPCP End Time is the time mixing ceases for a conference.=20 > > > > If you want to advertise a user-level stop time, like when=20 > > > > everyone is supposed to go out for lunch, but might not be=20 > > > > the stop time, if things are going peachy, advertise the=20 > > > > user-level stop time with SAP. > > > >=20 > > > > A Named Participant is a "special" participant. Usually this=20 > > > > is the conference owner. I would be happy to replace Named=20 > > > > Participant with Conference Owner, but I was thinking about=20 > > > > delegating authority, e.g., "Start this conference when I or=20 > > > > my secretary join the bridge." Also, if one examines CPCP=20 > > > > End Time condition 2c, one can envision a policy that states,=20 > > > > "Keep the bridge up until both the CEO and the COO leave=20 > > > the bridge." > > > >=20 > > > >=20 > > > > With those definitions, here is the proposal: > > > >=20 > > > > The CPCP Start Time is the latter of: > > > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > > > time delta/GMT) > > > > - AND ONE OF - > > > > 2a. The time the first participant arrives > > > > - OR - > > > > 2b. The time a Named Participant arrives > > >=20 > > > 2a is my choice > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > The CPCP End Time is the earlier of: > > > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > > > or a time delta/GMT) > > > > - AND ONE OF - > > > > 2a. The time the last participant leaves > > > > - OR - > > > > 2b. The time a Named Participant leaves > > > > - OR - > > > > 2c. The time the last Named Participant leaves > > > > - OR - > > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > > >=20 > > >=20 > > > 2d is my choice here as well. Some conferences might still=20 > > > run eventhough there are no current participants. > > >=20 > > > Here is what our solution says: > > >=20 > > > If the element is not present, it > > > indicates that the conference starts immediately. If the=20 > > > > > > is set to zero, then conference occurrence is not bounded, i.e. > > > permanent, though it will not become active until the=20 > > . > > > If the element is not present, it=20 > indicates that the > > > conference terminates as soon as the last participant=20 > leaves the > > > conference. > > >=20 > > > /Hisham > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22932 for ; Tue, 10 Feb 2004 10:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZos-0007jL-4H for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFT2gl029714 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZor-0007jB-Ej for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22926 for ; Tue, 10 Feb 2004 10:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZop-0002y7-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:28:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZnr-0002t9-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:28:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZmx-0002nk-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZmx-0007f7-0M; Tue, 10 Feb 2004 10:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZmt-0007e6-6h for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:26:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22852 for ; Tue, 10 Feb 2004 10:26:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZmq-0002mt-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:26:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZm2-0002he-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:26:06 -0500 Received: from uspitsmsgrtr01.pit.comms.marconi.com ([169.144.2.221]) by ietf-mx with esmtp (Exim 4.12) id 1AqZlB-0002V6-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:25:13 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCH6JX>; Tue, 10 Feb 2004 10:24:42 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B63D2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , xcon@ietf.org Subject: RE: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 10:24:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Will I beat Eric to the reply. Stay tuned. Nope, there is no point in saying start of mixing occurs when there are no participants. Remember this isn't a resource reservation mechanism (although it might trigger one in the mixer). 2c is the one that counts, I think. If my admin and I are named, and she leaves, I don't want the conference to stop. 2b is the one you could do without. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 10, 2004 10:14 AM > To: xcon@ietf.org > Subject: FW: [XCON] CPCP Start/stop Proposal > > > > > > -----Original Message----- > > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > Sent: 10.February.2004 17:10 > > To: 'ext Eric Burger'; xcon@softarmor.com > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > Ok, I misunderstood what you meant earlier: You are saying > > that the creator of the conference needs to have those > > choices and the policy needs to enable creators to set that choice. > > > > In this case, I would like to add the start-time a 2c: > > Persistent (e.g., only the time (condition 1) matters). I > > would also remove 2c for stop-time. > > > > /Hisham > > > > > -----Original Message----- > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > Sent: 10.February.2004 16:57 > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@softarmor.com > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > > > > nonononononono! > > > > > > It is NOT your choice: it is MY choice!!! > > > > > > These rules let me do ALL of the things that people want to > > > do. Isn't that the idea of policy: here are a few, simple > > > rules that let one construct whatever service (meet-me, > > > hard-stop scheduled, end when last leaves, end when time runs > > > out, etc.) one wants? > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Tuesday, February 10, 2004 3:34 AM > > > > To: Eric Burger; xcon@softarmor.com > > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > Eric Burger > > > > > Sent: 10.February.2004 08:29 > > > > > To: IETF XCON Discussion List (E-mail) > > > > > Subject: [XCON] CPCP Start/stop Proposal > > > > > > > > > > > > > > > Since I started the thread "CPCP Requirement: Repeat times", > > > > > > > > You really think so? Check again ;) > > > > > > > > > which has generated over 200 pages of responses (yes, I print > > > > > stuff out to read on airplanes), I thought I would give a > > > > > concrete proposal that I _hope_ will satisfy most of the > > > > > excellent comments generated. > > > > > > > > > > > > > > > First, two definitions: > > > > > > > > > > The CPCP Conference Start Time is the earliest mixing > > > > > opportunity for a conference. If you want to advertise a > > > > > user-level start time, like when you can call into a bridge > > > > > and talk to an IVR system or listen to a wonderful selection > > > > > of music-on-hold, advertise the user-level start time > with SAP. > > > > > > > > > > The CPCP End Time is the time mixing ceases for a conference. > > > > > If you want to advertise a user-level stop time, like when > > > > > everyone is supposed to go out for lunch, but might not be > > > > > the stop time, if things are going peachy, advertise the > > > > > user-level stop time with SAP. > > > > > > > > > > A Named Participant is a "special" participant. Usually this > > > > > is the conference owner. I would be happy to replace Named > > > > > Participant with Conference Owner, but I was thinking about > > > > > delegating authority, e.g., "Start this conference when I or > > > > > my secretary join the bridge." Also, if one examines CPCP > > > > > End Time condition 2c, one can envision a policy that states, > > > > > "Keep the bridge up until both the CEO and the COO leave > > > > the bridge." > > > > > > > > > > > > > > > With those definitions, here is the proposal: > > > > > > > > > > The CPCP Start Time is the latter of: > > > > > 1. A specified Earliest Mixing Time (which can be NOW or a > > > > > time delta/GMT) > > > > > - AND ONE OF - > > > > > 2a. The time the first participant arrives > > > > > - OR - > > > > > 2b. The time a Named Participant arrives > > > > > > > > 2a is my choice > > > > > > > > > > > > > > > > > > > > > > > > The CPCP End Time is the earlier of: > > > > > 1. A specified End of Mixing Time (which can be NOW, NEVER, > > > > > or a time delta/GMT) > > > > > - AND ONE OF - > > > > > 2a. The time the last participant leaves > > > > > - OR - > > > > > 2b. The time a Named Participant leaves > > > > > - OR - > > > > > 2c. The time the last Named Participant leaves > > > > > - OR - > > > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > > > > > > > > > > > > 2d is my choice here as well. Some conferences might still > > > > run eventhough there are no current participants. > > > > > > > > Here is what our solution says: > > > > > > > > If the element is not present, it > > > > indicates that the conference starts immediately. If the > > > > > > > > is set to zero, then conference occurrence is not > bounded, i.e. > > > > permanent, though it will not become active until the > > > . > > > > If the element is not present, it > > indicates that the > > > > conference terminates as soon as the last participant > > leaves the > > > > conference. > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 From exim@www1.ietf.org Tue Feb 10 10:49:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23814 for ; Tue, 10 Feb 2004 10:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqa87-0000iU-Kj for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:48:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFmtV4002747 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:48:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqa87-0000iD-Dk for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23803 for ; Tue, 10 Feb 2004 10:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqa85-0004th-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqa78-0004om-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:47:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqa6G-0004k4-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqa6G-0000eI-Pg; Tue, 10 Feb 2004 10:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqa6F-0000e3-Qy for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:46:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23738 for ; Tue, 10 Feb 2004 10:46:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqa6D-0004jY-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:46:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqa5J-0004eT-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:46:02 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1Aqa4w-0004ZS-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:45:39 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 10994; Tue, 10 Feb 2004 10:46:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 10:45:07 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A14A@zoe.office.snowshore.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TAAglaCQAAzobPAAANCnwAABPt3A From: "Eric Burger" To: , "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Considering the user's perspective, is there a difference between CPCP Start Time =3D n/a and Persistent and CPCP Start Time =3D NOW and Time First Participant Arrives ??? I would offer that from the user's perspective, there is no difference. = However, there may be differences from a resource allocation = perspective. The CPCP Stop Time (2c) parameter is for the distributed stock analyst = briefing, where the CxO's are calling in from different locations. We = want the conference to end when the CxO's all leave. That's easy if = they are in the same phone in the same room. In the old terminology, = they are the conference creator and the conference ends when they leave. = However, consider the case where the CFO is traveling and dials in. = The CEO calls in, creating the conference. The CFO joins in. The = analysts join in. The CEO needs to drop out for a while. However, = since the CFO is still on the call, the desired behavior is to keep the = conference active -- the CFO is still talking. For this scenario, the = CEO and CFO are the Named Participants. The conference is active so = long as one or more Named Participants are still in conference. I know I have wanted that behavior in the past. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 10, 2004 10:10 AM > To: Eric Burger; xcon@softarmor.com > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 > Ok, I misunderstood what you meant earlier: You are saying=20 > that the creator of the conference needs to have those=20 > choices and the policy needs to enable creators to set that choice. >=20 > In this case, I would like to add the start-time a 2c:=20 > Persistent (e.g., only the time (condition 1) matters). I=20 > would also remove 2c for stop-time. >=20 > /Hisham >=20 > > -----Original Message----- > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > Sent: 10.February.2004 16:57 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@softarmor.com > > Subject: RE: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > > nonononononono! > >=20 > > It is NOT your choice: it is MY choice!!! > >=20 > > These rules let me do ALL of the things that people want to=20 > > do. Isn't that the idea of policy: here are a few, simple=20 > > rules that let one construct whatever service (meet-me,=20 > > hard-stop scheduled, end when last leaves, end when time runs=20 > > out, etc.) one wants? > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, February 10, 2004 3:34 AM > > > To: Eric Burger; xcon@softarmor.com > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > Behalf Of ext > > > > Eric Burger > > > > Sent: 10.February.2004 08:29 > > > > To: IETF XCON Discussion List (E-mail) > > > > Subject: [XCON] CPCP Start/stop Proposal > > > >=20 > > > >=20 > > > > Since I started the thread "CPCP Requirement: Repeat times",=20 > > >=20 > > > You really think so? Check again ;) > > >=20 > > > > which has generated over 200 pages of responses (yes, I print=20 > > > > stuff out to read on airplanes), I thought I would give a=20 > > > > concrete proposal that I _hope_ will satisfy most of the=20 > > > > excellent comments generated. > > > >=20 > > > >=20 > > > > First, two definitions: > > > >=20 > > > > The CPCP Conference Start Time is the earliest mixing=20 > > > > opportunity for a conference. If you want to advertise a=20 > > > > user-level start time, like when you can call into a bridge=20 > > > > and talk to an IVR system or listen to a wonderful selection=20 > > > > of music-on-hold, advertise the user-level start time with SAP. > > > >=20 > > > > The CPCP End Time is the time mixing ceases for a conference.=20 > > > > If you want to advertise a user-level stop time, like when=20 > > > > everyone is supposed to go out for lunch, but might not be=20 > > > > the stop time, if things are going peachy, advertise the=20 > > > > user-level stop time with SAP. > > > >=20 > > > > A Named Participant is a "special" participant. Usually this=20 > > > > is the conference owner. I would be happy to replace Named=20 > > > > Participant with Conference Owner, but I was thinking about=20 > > > > delegating authority, e.g., "Start this conference when I or=20 > > > > my secretary join the bridge." Also, if one examines CPCP=20 > > > > End Time condition 2c, one can envision a policy that states,=20 > > > > "Keep the bridge up until both the CEO and the COO leave=20 > > > the bridge." > > > >=20 > > > >=20 > > > > With those definitions, here is the proposal: > > > >=20 > > > > The CPCP Start Time is the latter of: > > > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > > > time delta/GMT) > > > > - AND ONE OF - > > > > 2a. The time the first participant arrives > > > > - OR - > > > > 2b. The time a Named Participant arrives > > >=20 > > > 2a is my choice > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > The CPCP End Time is the earlier of: > > > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > > > or a time delta/GMT) > > > > - AND ONE OF - > > > > 2a. The time the last participant leaves > > > > - OR - > > > > 2b. The time a Named Participant leaves > > > > - OR - > > > > 2c. The time the last Named Participant leaves > > > > - OR - > > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > > >=20 > > >=20 > > > 2d is my choice here as well. Some conferences might still=20 > > > run eventhough there are no current participants. > > >=20 > > > Here is what our solution says: > > >=20 > > > If the element is not present, it > > > indicates that the conference starts immediately. If the=20 > > > > > > is set to zero, then conference occurrence is not bounded, i.e. > > > permanent, though it will not become active until the=20 > > . > > > If the element is not present, it=20 > indicates that the > > > conference terminates as soon as the last participant=20 > leaves the > > > conference. > > >=20 > > > /Hisham > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:58:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21432 for ; Tue, 10 Feb 2004 10:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZVW-000442-LZ for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:09:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AF92xK015614 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZVW-00043g-Gx for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21356 for ; Tue, 10 Feb 2004 10:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZVU-00010q-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:09:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZUT-0000vN-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:07:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZTZ-0000qC-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZTZ-0003MS-AZ; Tue, 10 Feb 2004 10:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZTW-0003L9-Bj for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:06:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21168 for ; Tue, 10 Feb 2004 10:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZTU-0000pW-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZSb-0000kX-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:06:02 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AqZRd-0000Zr-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:05:01 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 10994; Tue, 10 Feb 2004 10:05:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 10:04:30 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A148@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Start/stop Proposal Thread-Index: AcPv0yhtuO8qNrxCS1yoV+wi+1GnbAAEKTbA From: "Eric Burger" To: "Rosen, Brian" , "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Inline. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, February 10, 2004 7:41 AM > To: Eric Burger; IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 > Several issues, but getting there. >=20 > 1. You don't have a way to specify a traditional MeetMe, which is > not dependent on Start Time. So, I would add a 3a)Any participant > arrives (independent of start time) and 3b) Named participant arrives > (independent of stop time). MeetMe: CPCP Start Time =3D NOW (1) and Time First Participant Arrives (2a) CPCP End Time =3D NEVER (1) and Time Last Participant Leaves (2a) >=20 > 2. Forcing you to back up the stop time just because you=20 > ended early is=20 > silly. There is no point in saying end time is later than=20 > all participant > leaving in most cases. I can come up with a case (you want people to > come and go, even to the point where there are no people on=20 > the bridge, > but the conference stays up until the stop time is reached. =20 > So, I would > redefine Conference Stop Time to be > 2a) All participants leave > 2b) All named participants leave > 2c) Stop time exceeded > 2d) Stop time exceeded and all participants leave > 2e) Stop time exceeded and all named participants leave You don't have to backup the stop time. If your policy is "when last = participant leaves", that is often EARLIER than the CPCP End Time. >=20 >=20 > Brian >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, February 10, 2004 1:29 AM > > To: IETF XCON Discussion List (E-mail) > > Subject: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > > Since I started the thread "CPCP Requirement: Repeat times",=20 > > which has generated over 200 pages of responses (yes, I print=20 > > stuff out to read on airplanes), I thought I would give a=20 > > concrete proposal that I _hope_ will satisfy most of the=20 > > excellent comments generated. > >=20 > >=20 > > First, two definitions: > >=20 > > The CPCP Conference Start Time is the earliest mixing=20 > > opportunity for a conference. If you want to advertise a=20 > > user-level start time, like when you can call into a bridge=20 > > and talk to an IVR system or listen to a wonderful selection=20 > > of music-on-hold, advertise the user-level start time with SAP. > >=20 > > The CPCP End Time is the time mixing ceases for a conference.=20 > > If you want to advertise a user-level stop time, like when=20 > > everyone is supposed to go out for lunch, but might not be=20 > > the stop time, if things are going peachy, advertise the=20 > > user-level stop time with SAP. > >=20 > > A Named Participant is a "special" participant. Usually this=20 > > is the conference owner. I would be happy to replace Named=20 > > Participant with Conference Owner, but I was thinking about=20 > > delegating authority, e.g., "Start this conference when I or=20 > > my secretary join the bridge." Also, if one examines CPCP=20 > > End Time condition 2c, one can envision a policy that states,=20 > > "Keep the bridge up until both the CEO and the COO leave=20 > the bridge." > >=20 > >=20 > > With those definitions, here is the proposal: > >=20 > > The CPCP Start Time is the latter of: > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > time delta/GMT) > > - AND ONE OF - > > 2a. The time the first participant arrives > > - OR - > > 2b. The time a Named Participant arrives > >=20 > >=20 > >=20 > > The CPCP End Time is the earlier of: > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > or a time delta/GMT) > > - AND ONE OF - > > 2a. The time the last participant leaves > > - OR - > > 2b. The time a Named Participant leaves > > - OR - > > 2c. The time the last Named Participant leaves > > - OR - > > 2d. Persistent (e.g., only the time (condition 1) matters) > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 10:59:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24237 for ; Tue, 10 Feb 2004 10:59:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaHq-0001EH-FA for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:58:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFww8u004721 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 10:58:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaHq-0001E4-7D for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:58:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24222 for ; Tue, 10 Feb 2004 10:58:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaHn-0005vr-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:58:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaGp-0005ob-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:57:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaFv-0005iQ-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 10:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaFx-00019K-Ti; Tue, 10 Feb 2004 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaFu-00018o-PJ for xcon@optimus.ietf.org; Tue, 10 Feb 2004 10:56:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24135 for ; Tue, 10 Feb 2004 10:56:54 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaFs-0005he-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:56:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaEx-0005bO-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:56:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqaE2-0005VD-00 for xcon@ietf.org; Tue, 10 Feb 2004 10:55:02 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AFt1v07393 for ; Tue, 10 Feb 2004 17:55:01 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Feb 2004 17:55:01 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 17:55:01 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 17:55:00 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179772F@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Start/stop Proposal Thread-Index: AcPv6gYuJ0fplZToRTiDBr3BS5SWvgAA+MBQ To: , X-OriginalArrivalTime: 10 Feb 2004 15:55:01.0691 (UTC) FILETIME=[3DF028B0:01C3EFEE] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 10.February.2004 17:25 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 > Will I beat Eric to the reply. Stay tuned. >=20 > Nope, there is no point in saying start of mixing occurs when=20 > there are no > participants. > Remember this isn't a resource reservation mechanism=20 > (although it might > trigger > one in the mixer). We need to assume here that participant joining also means that the = focused has dialed out to them. Can I make the assumption that the = start-time will also trigger those dial outs? >=20 > 2c is the one that counts, I think. If my admin and I are=20 > named, and she > leaves, > I don't want the conference to stop. 2b is the one you could=20 > do without. Ok. Hisham >=20 > Brian >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, February 10, 2004 10:14 AM > > To: xcon@ietf.org > > Subject: FW: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > > > Sent: 10.February.2004 17:10 > > > To: 'ext Eric Burger'; xcon@softarmor.com > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > >=20 > > >=20 > > > Ok, I misunderstood what you meant earlier: You are saying=20 > > > that the creator of the conference needs to have those=20 > > > choices and the policy needs to enable creators to set=20 > that choice. > > >=20 > > > In this case, I would like to add the start-time a 2c:=20 > > > Persistent (e.g., only the time (condition 1) matters). I=20 > > > would also remove 2c for stop-time. > > >=20 > > > /Hisham > > >=20 > > > > -----Original Message----- > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > Sent: 10.February.2004 16:57 > > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@softarmor.com > > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > >=20 > > > >=20 > > > > nonononononono! > > > >=20 > > > > It is NOT your choice: it is MY choice!!! > > > >=20 > > > > These rules let me do ALL of the things that people want to=20 > > > > do. Isn't that the idea of policy: here are a few, simple=20 > > > > rules that let one construct whatever service (meet-me,=20 > > > > hard-stop scheduled, end when last leaves, end when time runs=20 > > > > out, etc.) one wants? > > > >=20 > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com=20 > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Tuesday, February 10, 2004 3:34 AM > > > > > To: Eric Burger; xcon@softarmor.com > > > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > > > > > Behalf Of ext > > > > > > Eric Burger > > > > > > Sent: 10.February.2004 08:29 > > > > > > To: IETF XCON Discussion List (E-mail) > > > > > > Subject: [XCON] CPCP Start/stop Proposal > > > > > >=20 > > > > > >=20 > > > > > > Since I started the thread "CPCP Requirement:=20 > Repeat times",=20 > > > > >=20 > > > > > You really think so? Check again ;) > > > > >=20 > > > > > > which has generated over 200 pages of responses=20 > (yes, I print=20 > > > > > > stuff out to read on airplanes), I thought I would give a=20 > > > > > > concrete proposal that I _hope_ will satisfy most of the=20 > > > > > > excellent comments generated. > > > > > >=20 > > > > > >=20 > > > > > > First, two definitions: > > > > > >=20 > > > > > > The CPCP Conference Start Time is the earliest mixing=20 > > > > > > opportunity for a conference. If you want to advertise a=20 > > > > > > user-level start time, like when you can call into a bridge=20 > > > > > > and talk to an IVR system or listen to a wonderful=20 > selection=20 > > > > > > of music-on-hold, advertise the user-level start time=20 > > with SAP. > > > > > >=20 > > > > > > The CPCP End Time is the time mixing ceases for a=20 > conference.=20 > > > > > > If you want to advertise a user-level stop time, like when=20 > > > > > > everyone is supposed to go out for lunch, but might not be=20 > > > > > > the stop time, if things are going peachy, advertise the=20 > > > > > > user-level stop time with SAP. > > > > > >=20 > > > > > > A Named Participant is a "special" participant. =20 > Usually this=20 > > > > > > is the conference owner. I would be happy to replace Named=20 > > > > > > Participant with Conference Owner, but I was thinking about=20 > > > > > > delegating authority, e.g., "Start this conference=20 > when I or=20 > > > > > > my secretary join the bridge." Also, if one examines CPCP=20 > > > > > > End Time condition 2c, one can envision a policy=20 > that states,=20 > > > > > > "Keep the bridge up until both the CEO and the COO leave=20 > > > > > the bridge." > > > > > >=20 > > > > > >=20 > > > > > > With those definitions, here is the proposal: > > > > > >=20 > > > > > > The CPCP Start Time is the latter of: > > > > > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > > > > > time delta/GMT) > > > > > > - AND ONE OF - > > > > > > 2a. The time the first participant arrives > > > > > > - OR - > > > > > > 2b. The time a Named Participant arrives > > > > >=20 > > > > > 2a is my choice > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > The CPCP End Time is the earlier of: > > > > > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > > > > > or a time delta/GMT) > > > > > > - AND ONE OF - > > > > > > 2a. The time the last participant leaves > > > > > > - OR - > > > > > > 2b. The time a Named Participant leaves > > > > > > - OR - > > > > > > 2c. The time the last Named Participant leaves > > > > > > - OR - > > > > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > > > > >=20 > > > > >=20 > > > > > 2d is my choice here as well. Some conferences might still=20 > > > > > run eventhough there are no current participants. > > > > >=20 > > > > > Here is what our solution says: > > > > >=20 > > > > > If the element is not present, it > > > > > indicates that the conference starts immediately. If the=20 > > > > > > > > > > is set to zero, then conference occurrence is not=20 > > bounded, i.e. > > > > > permanent, though it will not become active until the=20 > > > > . > > > > > If the element is not present, it=20 > > > indicates that the > > > > > conference terminates as soon as the last participant=20 > > > leaves the > > > > > conference. > > > > >=20 > > > > > /Hisham > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > XCON mailing list > > > > > > XCON@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 11:06:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25143 for ; Tue, 10 Feb 2004 11:06:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaPA-00029t-JS for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 11:06:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AG6WVj008291 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 11:06:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaPA-00029e-CQ for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:06:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25125 for ; Tue, 10 Feb 2004 11:06:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaP7-0007Jb-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 11:06:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaOF-00077m-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 11:05:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaMt-0006nf-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 11:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaMk-0001YD-MH; Tue, 10 Feb 2004 11:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaMD-0001V1-GI for xcon@optimus.ietf.org; Tue, 10 Feb 2004 11:03:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24705 for ; Tue, 10 Feb 2004 11:03:25 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaMA-0006iZ-00 for xcon@ietf.org; Tue, 10 Feb 2004 11:03:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaKq-0006Ts-00 for xcon@ietf.org; Tue, 10 Feb 2004 11:02:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqaJm-0006I2-00 for xcon@ietf.org; Tue, 10 Feb 2004 11:00:58 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AG0tq10433 for ; Tue, 10 Feb 2004 18:00:56 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Feb 2004 18:00:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 18:00:55 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Start/stop Proposal Date: Tue, 10 Feb 2004 18:00:53 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797730@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Start/stop Proposal Thread-Index: AcPv0yhtuO8qNrxCS1yoV+wi+1GnbAAEKTbAAAKu6CA= To: , , X-OriginalArrivalTime: 10 Feb 2004 16:00:55.0194 (UTC) FILETIME=[10A46FA0:01C3EFEF] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Eric Burger > Sent: 10.February.2004 17:04 > To: Rosen, Brian; IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 > Inline. >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, February 10, 2004 7:41 AM > > To: Eric Burger; IETF XCON Discussion List (E-mail)=09 > > Subject: RE: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > > Several issues, but getting there. > >=20 > > 1. You don't have a way to specify a traditional MeetMe, which is > > not dependent on Start Time. So, I would add a 3a)Any participant > > arrives (independent of start time) and 3b) Named=20 > participant arrives > > (independent of stop time). >=20 > MeetMe: > CPCP Start Time =3D NOW (1) and Time First Participant Arrives (2a) > CPCP End Time =3D NEVER (1) and Time Last Participant Leaves (2a) Well, I guess this depends on the way the solution is specified. For = example, the solution can specify a mandatory element with = a marco value NOW, or it can specify an optional element = that when not present, means now. /Hisham >=20 > >=20 > > 2. Forcing you to back up the stop time just because you=20 > > ended early is=20 > > silly. There is no point in saying end time is later than=20 > > all participant > > leaving in most cases. I can come up with a case (you want=20 > people to > > come and go, even to the point where there are no people on=20 > > the bridge, > > but the conference stays up until the stop time is reached. =20 > > So, I would > > redefine Conference Stop Time to be > > 2a) All participants leave > > 2b) All named participants leave > > 2c) Stop time exceeded > > 2d) Stop time exceeded and all participants leave > > 2e) Stop time exceeded and all named participants leave >=20 > You don't have to backup the stop time. If your policy is=20 > "when last participant leaves", that is often EARLIER than=20 > the CPCP End Time. >=20 > >=20 > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: Tuesday, February 10, 2004 1:29 AM > > > To: IETF XCON Discussion List (E-mail) > > > Subject: [XCON] CPCP Start/stop Proposal > > >=20 > > >=20 > > > Since I started the thread "CPCP Requirement: Repeat times",=20 > > > which has generated over 200 pages of responses (yes, I print=20 > > > stuff out to read on airplanes), I thought I would give a=20 > > > concrete proposal that I _hope_ will satisfy most of the=20 > > > excellent comments generated. > > >=20 > > >=20 > > > First, two definitions: > > >=20 > > > The CPCP Conference Start Time is the earliest mixing=20 > > > opportunity for a conference. If you want to advertise a=20 > > > user-level start time, like when you can call into a bridge=20 > > > and talk to an IVR system or listen to a wonderful selection=20 > > > of music-on-hold, advertise the user-level start time with SAP. > > >=20 > > > The CPCP End Time is the time mixing ceases for a conference.=20 > > > If you want to advertise a user-level stop time, like when=20 > > > everyone is supposed to go out for lunch, but might not be=20 > > > the stop time, if things are going peachy, advertise the=20 > > > user-level stop time with SAP. > > >=20 > > > A Named Participant is a "special" participant. Usually this=20 > > > is the conference owner. I would be happy to replace Named=20 > > > Participant with Conference Owner, but I was thinking about=20 > > > delegating authority, e.g., "Start this conference when I or=20 > > > my secretary join the bridge." Also, if one examines CPCP=20 > > > End Time condition 2c, one can envision a policy that states,=20 > > > "Keep the bridge up until both the CEO and the COO leave=20 > > the bridge." > > >=20 > > >=20 > > > With those definitions, here is the proposal: > > >=20 > > > The CPCP Start Time is the latter of: > > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > > time delta/GMT) > > > - AND ONE OF - > > > 2a. The time the first participant arrives > > > - OR - > > > 2b. The time a Named Participant arrives > > >=20 > > >=20 > > >=20 > > > The CPCP End Time is the earlier of: > > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > > or a time delta/GMT) > > > - AND ONE OF - > > > 2a. The time the last participant leaves > > > - OR - > > > 2b. The time a Named Participant leaves > > > - OR - > > > 2c. The time the last Named Participant leaves > > > - OR - > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 10 11:43:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26565 for ; Tue, 10 Feb 2004 11:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqayS-0005Ut-Uh for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 11:43:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AGh0qb021125 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqayS-0005Ue-MP for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:43:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26552 for ; Tue, 10 Feb 2004 11:42:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqayR-0003Bj-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 11:42:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaxT-00036d-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 11:42:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqawZ-00031c-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 11:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqawY-0005OS-CI; Tue, 10 Feb 2004 11:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqawU-0005Nd-Ms for xcon@optimus.ietf.org; Tue, 10 Feb 2004 11:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26478 for ; Tue, 10 Feb 2004 11:40:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqawT-00030w-00 for xcon@ietf.org; Tue, 10 Feb 2004 11:40:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqavc-0002w8-00 for xcon@ietf.org; Tue, 10 Feb 2004 11:40:05 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Aqav7-0002qU-00 for xcon@ietf.org; Tue, 10 Feb 2004 11:39:34 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2004 08:39:12 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1AGd0hu022279; Tue, 10 Feb 2004 11:39:01 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-118.cisco.com [64.100.229.118]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWW83346; Tue, 10 Feb 2004 08:38:59 -0800 (PST) Message-Id: <4.3.2.7.2.20040210113726.02d2ee70@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 11:38:59 -0500 To: "Eric Burger" From: Michael Hammer Subject: RE: [XCON] CPCP Start/stop Proposal Cc: , "IETF XCON Discussion List (E-mail)" In-Reply-To: <4A3384433CE2AB46A63468CB207E209DB1A14A@zoe.office.snowshor e.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Eric, "Named Participant" is somewhat vague as to intent. Could you instead say "Key Participant" and stop when said list=0? Mike At 10:45 AM 2/10/2004 -0500, Eric Burger wrote: >Considering the user's perspective, is there a difference between > > CPCP Start Time = n/a and Persistent > >and > > CPCP Start Time = NOW and Time First Participant Arrives > >??? > >I would offer that from the user's perspective, there is no >difference. However, there may be differences from a resource allocation >perspective. > > >The CPCP Stop Time (2c) parameter is for the distributed stock analyst >briefing, where the CxO's are calling in from different locations. We >want the conference to end when the CxO's all leave. That's easy if they >are in the same phone in the same room. In the old terminology, they are >the conference creator and the conference ends when they leave. However, >consider the case where the CFO is traveling and dials in. The CEO calls >in, creating the conference. The CFO joins in. The analysts join >in. The CEO needs to drop out for a while. However, since the CFO is >still on the call, the desired behavior is to keep the conference active >-- the CFO is still talking. For this scenario, the CEO and CFO are the >Named Participants. The conference is active so long as one or more Named >Participants are still in conference. > >I know I have wanted that behavior in the past. > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Tuesday, February 10, 2004 10:10 AM > > To: Eric Burger; xcon@softarmor.com > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > Ok, I misunderstood what you meant earlier: You are saying > > that the creator of the conference needs to have those > > choices and the policy needs to enable creators to set that choice. > > > > In this case, I would like to add the start-time a 2c: > > Persistent (e.g., only the time (condition 1) matters). I > > would also remove 2c for stop-time. > > > > /Hisham > > > > > -----Original Message----- > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > Sent: 10.February.2004 16:57 > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@softarmor.com > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > > > > nonononononono! > > > > > > It is NOT your choice: it is MY choice!!! > > > > > > These rules let me do ALL of the things that people want to > > > do. Isn't that the idea of policy: here are a few, simple > > > rules that let one construct whatever service (meet-me, > > > hard-stop scheduled, end when last leaves, end when time runs > > > out, etc.) one wants? > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Tuesday, February 10, 2004 3:34 AM > > > > To: Eric Burger; xcon@softarmor.com > > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > Behalf Of ext > > > > > Eric Burger > > > > > Sent: 10.February.2004 08:29 > > > > > To: IETF XCON Discussion List (E-mail) > > > > > Subject: [XCON] CPCP Start/stop Proposal > > > > > > > > > > > > > > > Since I started the thread "CPCP Requirement: Repeat times", > > > > > > > > You really think so? Check again ;) > > > > > > > > > which has generated over 200 pages of responses (yes, I print > > > > > stuff out to read on airplanes), I thought I would give a > > > > > concrete proposal that I _hope_ will satisfy most of the > > > > > excellent comments generated. > > > > > > > > > > > > > > > First, two definitions: > > > > > > > > > > The CPCP Conference Start Time is the earliest mixing > > > > > opportunity for a conference. If you want to advertise a > > > > > user-level start time, like when you can call into a bridge > > > > > and talk to an IVR system or listen to a wonderful selection > > > > > of music-on-hold, advertise the user-level start time with SAP. > > > > > > > > > > The CPCP End Time is the time mixing ceases for a conference. > > > > > If you want to advertise a user-level stop time, like when > > > > > everyone is supposed to go out for lunch, but might not be > > > > > the stop time, if things are going peachy, advertise the > > > > > user-level stop time with SAP. > > > > > > > > > > A Named Participant is a "special" participant. Usually this > > > > > is the conference owner. I would be happy to replace Named > > > > > Participant with Conference Owner, but I was thinking about > > > > > delegating authority, e.g., "Start this conference when I or > > > > > my secretary join the bridge." Also, if one examines CPCP > > > > > End Time condition 2c, one can envision a policy that states, > > > > > "Keep the bridge up until both the CEO and the COO leave > > > > the bridge." > > > > > > > > > > > > > > > With those definitions, here is the proposal: > > > > > > > > > > The CPCP Start Time is the latter of: > > > > > 1. A specified Earliest Mixing Time (which can be NOW or a > > > > > time delta/GMT) > > > > > - AND ONE OF - > > > > > 2a. The time the first participant arrives > > > > > - OR - > > > > > 2b. The time a Named Participant arrives > > > > > > > > 2a is my choice > > > > > > > > > > > > > > > > > > > > > > > > The CPCP End Time is the earlier of: > > > > > 1. A specified End of Mixing Time (which can be NOW, NEVER, > > > > > or a time delta/GMT) > > > > > - AND ONE OF - > > > > > 2a. The time the last participant leaves > > > > > - OR - > > > > > 2b. The time a Named Participant leaves > > > > > - OR - > > > > > 2c. The time the last Named Participant leaves > > > > > - OR - > > > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > > > > > > > > > > > > 2d is my choice here as well. Some conferences might still > > > > run eventhough there are no current participants. > > > > > > > > Here is what our solution says: > > > > > > > > If the element is not present, it > > > > indicates that the conference starts immediately. If the > > > > > > > > is set to zero, then conference occurrence is not bounded, i.e. > > > > permanent, though it will not become active until the > > > . > > > > If the element is not present, it > > indicates that the > > > > conference terminates as soon as the last participant > > leaves the > > > > conference. > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 From exim@www1.ietf.org Wed Feb 11 08:41:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00654 for ; Wed, 11 Feb 2004 08:41:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqubb-0002KV-08 for xcon-archive@odin.ietf.org; Wed, 11 Feb 2004 08:40:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BDegTs008952 for xcon-archive@odin.ietf.org; Wed, 11 Feb 2004 08:40:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aquba-0002KJ-Kh for xcon-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 08:40:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00633 for ; Wed, 11 Feb 2004 08:40:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqubZ-0004aC-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 08:40:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aquaf-0004Ur-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 08:39:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AquZw-0004PH-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 08:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquZw-0002EV-OY; Wed, 11 Feb 2004 08:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AquZc-0002Ba-IN for xcon@optimus.ietf.org; Wed, 11 Feb 2004 08:38:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00586 for ; Wed, 11 Feb 2004 08:38:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AquZb-0004OF-00 for xcon@ietf.org; Wed, 11 Feb 2004 08:38:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AquYh-0004JU-00 for xcon@ietf.org; Wed, 11 Feb 2004 08:37:44 -0500 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx with esmtp (Exim 4.12) id 1AquYW-0004EB-00 for xcon@ietf.org; Wed, 11 Feb 2004 08:37:32 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HSX002BE9692T@firewall.mci.com> for xcon@ietf.org; Wed, 11 Feb 2004 13:22:57 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HSX00B01968I4@pmismtp01.mcilink.com>; Wed, 11 Feb 2004 13:22:57 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.46.2.215]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HSX00B339686A@pmismtp01.mcilink.com>; Wed, 11 Feb 2004 13:22:56 +0000 (GMT) Date: Wed, 11 Feb 2004 07:22:35 -0600 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: xcon@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20040210150612.025ab410@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] XCON Agenda Requests Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Please submit your agenda requests for IETF-59. Currently, XCON is scheduled for a 2 hour slot on Monday, March 1 at 1530-1730, although this may change as the schedule is finalized Send your requests directly to me at alan.johnston@mci.com. I will acknowledge them and compile them. We will accept requests for a week until February 19. Next week we will post the requests and finalize the agenda on February 24. For each request, indicate your name, the topic, draft, and length of time requested. Thanks, Alan Johnston co-chair XCON WG _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 11 11:05:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06766 for ; Wed, 11 Feb 2004 11:05:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwr0-0002kA-Fp for xcon-archive@odin.ietf.org; Wed, 11 Feb 2004 11:04:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BG4kdi010545 for xcon-archive@odin.ietf.org; Wed, 11 Feb 2004 11:04:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwr0-0002k0-9t for xcon-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:04:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06742 for ; Wed, 11 Feb 2004 11:04:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqwqx-0003kE-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 11:04:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqwq3-0003e1-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 11:03:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqwpI-0003Y7-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 11:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwpK-0002YJ-0Q; Wed, 11 Feb 2004 11:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwp9-0002Xa-1H for xcon@optimus.ietf.org; Wed, 11 Feb 2004 11:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06663 for ; Wed, 11 Feb 2004 11:02:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqwp6-0003WT-00 for xcon@ietf.org; Wed, 11 Feb 2004 11:02:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqwo8-0003PY-00 for xcon@ietf.org; Wed, 11 Feb 2004 11:01:49 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AqwnJ-0003Cv-01 for xcon@ietf.org; Wed, 11 Feb 2004 11:00:57 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15987; Wed, 11 Feb 2004 11:01:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Start/stop Proposal Date: Wed, 11 Feb 2004 11:00:27 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A15A@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Start/stop Proposal Thread-Index: AcPv9GUNhfbj1JHzTMCQJWanTiZJKwAvojIg From: "Eric Burger" To: "Michael Hammer" Cc: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Call it fruit juice if you want :-) Key Participant is a better term. Go for it. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, February 10, 2004 11:39 AM > To: Eric Burger > Cc: hisham.khartabil@nokia.com; IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 > Eric, >=20 > "Named Participant" is somewhat vague as to intent. > Could you instead say "Key Participant" and stop when said list=3D0? >=20 > Mike >=20 > At 10:45 AM 2/10/2004 -0500, Eric Burger wrote: > >Considering the user's perspective, is there a difference between > > > > CPCP Start Time =3D n/a and Persistent > > > >and > > > > CPCP Start Time =3D NOW and Time First Participant Arrives > > > >??? > > > >I would offer that from the user's perspective, there is no=20 > >difference. However, there may be differences from a=20 > resource allocation=20 > >perspective. > > > > > >The CPCP Stop Time (2c) parameter is for the distributed=20 > stock analyst=20 > >briefing, where the CxO's are calling in from different=20 > locations. We=20 > >want the conference to end when the CxO's all leave. That's=20 > easy if they=20 > >are in the same phone in the same room. In the old=20 > terminology, they are=20 > >the conference creator and the conference ends when they=20 > leave. However,=20 > >consider the case where the CFO is traveling and dials in. =20 > The CEO calls=20 > >in, creating the conference. The CFO joins in. The analysts join=20 > >in. The CEO needs to drop out for a while. However, since=20 > the CFO is=20 > >still on the call, the desired behavior is to keep the=20 > conference active=20 > >-- the CFO is still talking. For this scenario, the CEO and=20 > CFO are the=20 > >Named Participants. The conference is active so long as one=20 > or more Named=20 > >Participants are still in conference. > > > >I know I have wanted that behavior in the past. > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > > > Sent: Tuesday, February 10, 2004 10:10 AM > > > To: Eric Burger; xcon@softarmor.com > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > > > > Ok, I misunderstood what you meant earlier: You are saying > > > that the creator of the conference needs to have those > > > choices and the policy needs to enable creators to set=20 > that choice. > > > > > > In this case, I would like to add the start-time a 2c: > > > Persistent (e.g., only the time (condition 1) matters). I > > > would also remove 2c for stop-time. > > > > > > /Hisham > > > > > > > -----Original Message----- > > > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > > > Sent: 10.February.2004 16:57 > > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@softarmor.com > > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > > > > > > > nonononononono! > > > > > > > > It is NOT your choice: it is MY choice!!! > > > > > > > > These rules let me do ALL of the things that people want to > > > > do. Isn't that the idea of policy: here are a few, simple > > > > rules that let one construct whatever service (meet-me, > > > > hard-stop scheduled, end when last leaves, end when time runs > > > > out, etc.) one wants? > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com > > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Tuesday, February 10, 2004 3:34 AM > > > > > To: Eric Burger; xcon@softarmor.com > > > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > > > > > Behalf Of ext > > > > > > Eric Burger > > > > > > Sent: 10.February.2004 08:29 > > > > > > To: IETF XCON Discussion List (E-mail) > > > > > > Subject: [XCON] CPCP Start/stop Proposal > > > > > > > > > > > > > > > > > > Since I started the thread "CPCP Requirement: Repeat times", > > > > > > > > > > You really think so? Check again ;) > > > > > > > > > > > which has generated over 200 pages of responses=20 > (yes, I print > > > > > > stuff out to read on airplanes), I thought I would give a > > > > > > concrete proposal that I _hope_ will satisfy most of the > > > > > > excellent comments generated. > > > > > > > > > > > > > > > > > > First, two definitions: > > > > > > > > > > > > The CPCP Conference Start Time is the earliest mixing > > > > > > opportunity for a conference. If you want to advertise a > > > > > > user-level start time, like when you can call into a bridge > > > > > > and talk to an IVR system or listen to a wonderful selection > > > > > > of music-on-hold, advertise the user-level start=20 > time with SAP. > > > > > > > > > > > > The CPCP End Time is the time mixing ceases for a=20 > conference. > > > > > > If you want to advertise a user-level stop time, like when > > > > > > everyone is supposed to go out for lunch, but might not be > > > > > > the stop time, if things are going peachy, advertise the > > > > > > user-level stop time with SAP. > > > > > > > > > > > > A Named Participant is a "special" participant. =20 > Usually this > > > > > > is the conference owner. I would be happy to replace Named > > > > > > Participant with Conference Owner, but I was thinking about > > > > > > delegating authority, e.g., "Start this conference when I or > > > > > > my secretary join the bridge." Also, if one examines CPCP > > > > > > End Time condition 2c, one can envision a policy=20 > that states, > > > > > > "Keep the bridge up until both the CEO and the COO leave > > > > > the bridge." > > > > > > > > > > > > > > > > > > With those definitions, here is the proposal: > > > > > > > > > > > > The CPCP Start Time is the latter of: > > > > > > 1. A specified Earliest Mixing Time (which can be NOW or a > > > > > > time delta/GMT) > > > > > > - AND ONE OF - > > > > > > 2a. The time the first participant arrives > > > > > > - OR - > > > > > > 2b. The time a Named Participant arrives > > > > > > > > > > 2a is my choice > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The CPCP End Time is the earlier of: > > > > > > 1. A specified End of Mixing Time (which can be NOW, NEVER, > > > > > > or a time delta/GMT) > > > > > > - AND ONE OF - > > > > > > 2a. The time the last participant leaves > > > > > > - OR - > > > > > > 2b. The time a Named Participant leaves > > > > > > - OR - > > > > > > 2c. The time the last Named Participant leaves > > > > > > - OR - > > > > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > > > > > > > > > > > > > > > 2d is my choice here as well. Some conferences might still > > > > > run eventhough there are no current participants. > > > > > > > > > > Here is what our solution says: > > > > > > > > > > If the element is not present, it > > > > > indicates that the conference starts immediately. If the > > > > > > > > > > is set to zero, then conference occurrence is not=20 > bounded, i.e. > > > > > permanent, though it will not become active until the > > > > . > > > > > If the element is not present, it > > > indicates that the > > > > > conference terminates as soon as the last participant > > > leaves the > > > > > conference. > > > > > > > > > > /Hisham > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 11 11:05:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06783 for ; Wed, 11 Feb 2004 11:05:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwr1-0002kX-7I for xcon-archive@odin.ietf.org; Wed, 11 Feb 2004 11:04:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BG4lYf010563 for xcon-archive@odin.ietf.org; Wed, 11 Feb 2004 11:04:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwr1-0002kI-1V for xcon-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:04:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06746 for ; Wed, 11 Feb 2004 11:04:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqwqy-0003kJ-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 11:04:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqwq5-0003e9-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 11:03:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqwpI-0003Y9-00 for xcon-web-archive@ietf.org; Wed, 11 Feb 2004 11:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwpK-0002YR-8s; Wed, 11 Feb 2004 11:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqwp9-0002Xf-MA for xcon@optimus.ietf.org; Wed, 11 Feb 2004 11:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06666 for ; Wed, 11 Feb 2004 11:02:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqwp7-0003WY-00 for xcon@ietf.org; Wed, 11 Feb 2004 11:02:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwoA-0003Pr-00 for xcon@ietf.org; Wed, 11 Feb 2004 11:01:51 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AqwnK-0003Cv-00 for xcon@ietf.org; Wed, 11 Feb 2004 11:00:58 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 15987; Wed, 11 Feb 2004 11:01:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] CPCP Start/stop Proposal Date: Wed, 11 Feb 2004 11:00:27 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A15B@zoe.office.snowshore.com> Thread-Topic: [XCON] CPCP Start/stop Proposal Thread-Index: AcPv0yhtuO8qNrxCS1yoV+wi+1GnbAAEKTbAAAKu6CAAMlNn8A== From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable That's a syntax issue. Fine w/ me. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 10, 2004 11:01 AM > To: Eric Burger; Brian.Rosen@marconi.com; xcon@ietf.org > Subject: RE: [XCON] CPCP Start/stop Proposal >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Eric Burger > > Sent: 10.February.2004 17:04 > > To: Rosen, Brian; IETF XCON Discussion List (E-mail) > > Subject: RE: [XCON] CPCP Start/stop Proposal > >=20 > >=20 > > Inline. > >=20 > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, February 10, 2004 7:41 AM > > > To: Eric Burger; IETF XCON Discussion List (E-mail)=09 > > > Subject: RE: [XCON] CPCP Start/stop Proposal > > >=20 > > >=20 > > > Several issues, but getting there. > > >=20 > > > 1. You don't have a way to specify a traditional MeetMe, which is > > > not dependent on Start Time. So, I would add a 3a)Any participant > > > arrives (independent of start time) and 3b) Named=20 > > participant arrives > > > (independent of stop time). > >=20 > > MeetMe: > > CPCP Start Time =3D NOW (1) and Time First Participant Arrives (2a) > > CPCP End Time =3D NEVER (1) and Time Last Participant Leaves (2a) >=20 > Well, I guess this depends on the way the solution is=20 > specified. For example, the solution can specify a mandatory=20 > element with a marco value NOW, or it can=20 > specify an optional element that when not=20 > present, means now. >=20 > /Hisham >=20 > >=20 > > >=20 > > > 2. Forcing you to back up the stop time just because you=20 > > > ended early is=20 > > > silly. There is no point in saying end time is later than=20 > > > all participant > > > leaving in most cases. I can come up with a case (you want=20 > > people to > > > come and go, even to the point where there are no people on=20 > > > the bridge, > > > but the conference stays up until the stop time is reached. =20 > > > So, I would > > > redefine Conference Stop Time to be > > > 2a) All participants leave > > > 2b) All named participants leave > > > 2c) Stop time exceeded > > > 2d) Stop time exceeded and all participants leave > > > 2e) Stop time exceeded and all named participants leave > >=20 > > You don't have to backup the stop time. If your policy is=20 > > "when last participant leaves", that is often EARLIER than=20 > > the CPCP End Time. > >=20 > > >=20 > > >=20 > > > Brian > > >=20 > > > > -----Original Message----- > > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > > Sent: Tuesday, February 10, 2004 1:29 AM > > > > To: IETF XCON Discussion List (E-mail) > > > > Subject: [XCON] CPCP Start/stop Proposal > > > >=20 > > > >=20 > > > > Since I started the thread "CPCP Requirement: Repeat times",=20 > > > > which has generated over 200 pages of responses (yes, I print=20 > > > > stuff out to read on airplanes), I thought I would give a=20 > > > > concrete proposal that I _hope_ will satisfy most of the=20 > > > > excellent comments generated. > > > >=20 > > > >=20 > > > > First, two definitions: > > > >=20 > > > > The CPCP Conference Start Time is the earliest mixing=20 > > > > opportunity for a conference. If you want to advertise a=20 > > > > user-level start time, like when you can call into a bridge=20 > > > > and talk to an IVR system or listen to a wonderful selection=20 > > > > of music-on-hold, advertise the user-level start time with SAP. > > > >=20 > > > > The CPCP End Time is the time mixing ceases for a conference.=20 > > > > If you want to advertise a user-level stop time, like when=20 > > > > everyone is supposed to go out for lunch, but might not be=20 > > > > the stop time, if things are going peachy, advertise the=20 > > > > user-level stop time with SAP. > > > >=20 > > > > A Named Participant is a "special" participant. Usually this=20 > > > > is the conference owner. I would be happy to replace Named=20 > > > > Participant with Conference Owner, but I was thinking about=20 > > > > delegating authority, e.g., "Start this conference when I or=20 > > > > my secretary join the bridge." Also, if one examines CPCP=20 > > > > End Time condition 2c, one can envision a policy that states,=20 > > > > "Keep the bridge up until both the CEO and the COO leave=20 > > > the bridge." > > > >=20 > > > >=20 > > > > With those definitions, here is the proposal: > > > >=20 > > > > The CPCP Start Time is the latter of: > > > > 1. A specified Earliest Mixing Time (which can be NOW or a=20 > > > > time delta/GMT) > > > > - AND ONE OF - > > > > 2a. The time the first participant arrives > > > > - OR - > > > > 2b. The time a Named Participant arrives > > > >=20 > > > >=20 > > > >=20 > > > > The CPCP End Time is the earlier of: > > > > 1. A specified End of Mixing Time (which can be NOW, NEVER,=20 > > > > or a time delta/GMT) > > > > - AND ONE OF - > > > > 2a. The time the last participant leaves > > > > - OR - > > > > 2b. The time a Named Participant leaves > > > > - OR - > > > > 2c. The time the last Named Participant leaves > > > > - OR - > > > > 2d. Persistent (e.g., only the time (condition 1) matters) > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > >=20 > > >=20 > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 12 11:17:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00661 for ; Thu, 12 Feb 2004 11:17:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJWf-00075P-VK for xcon-archive@odin.ietf.org; Thu, 12 Feb 2004 11:17:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CGHHpk027235 for xcon-archive@odin.ietf.org; Thu, 12 Feb 2004 11:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJWf-00075C-Q3 for xcon-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:17:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00580 for ; Thu, 12 Feb 2004 11:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJWd-0004u8-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 11:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJVd-0004mw-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 11:16:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJUd-0004bj-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 11:15:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJUU-0006wv-Lq; Thu, 12 Feb 2004 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJTx-0006t0-6X for xcon@optimus.ietf.org; Thu, 12 Feb 2004 11:14:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00422 for ; Thu, 12 Feb 2004 11:14:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJTu-0004ZH-00 for xcon@ietf.org; Thu, 12 Feb 2004 11:14:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJSy-0004S4-00 for xcon@ietf.org; Thu, 12 Feb 2004 11:13:29 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1ArJS3-0004Gz-00 for xcon@ietf.org; Thu, 12 Feb 2004 11:12:31 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 08:11:39 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Feb 2004 08:12:01 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 12 Feb 2004 08:11:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] "Many users in a single operation" Requirements Date: Thu, 12 Feb 2004 08:12:07 -0800 Message-ID: Thread-Topic: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPvcz3Jb4YIVoLBQDSBV/8FJxrYogAONw5wAHVB4CA= From: "Orit Levin" To: , Cc: "Jonathan Rosenberg" X-OriginalArrivalTime: 12 Feb 2004 16:11:58.0689 (UTC) FILETIME=[F0F13D10:01C3F182] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Where is this "XCAP extension" defined in the XCAP documents?! Besides, you can't do in the same way REQ-CP-3: It MAY be possible for the client to batch multiple operations (such as add a user to ACL blocked list, or remove a user from ACL allowed list) into a single request that is processed atomically. Thanks, Orit. -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Sent: Tuesday, February 10, 2004 12:18 AM To: Orit Levin; xcon@ietf.org Subject: RE: [XCON] "Many users in a single operation" Requirements Here is an example of how to add multiple users to an ACL list in a single operation: PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml? Conference/ACL/ACL-target-URI HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com The rest are done in a similar fashion. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Orit Levin > Sent: 10.February.2004 03:15 > To: xcon@ietf.org > Subject: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Hi guys! > =20 > There are many places throughout the CPCP-req document that identify > operations on a "subset of list" as MUST be performed in a single > operation (e.g. G4, G6, H2, and H4). > How do you plan to meet these requirements with "XCAP CPCP"? > =20 > The same question for REQ-CP-3: It MAY be possible for the client to > batch multiple operations (such as add a user to ACL blocked list, or > remove a user from ACL allowed list) into a single request that is > processed atomically. > =20 > Thanks, > Orit. >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 12 11:37:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01621 for ; Thu, 12 Feb 2004 11:37:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJq8-0000KV-2M for xcon-archive@odin.ietf.org; Thu, 12 Feb 2004 11:37:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CGbNX4001261 for xcon-archive@odin.ietf.org; Thu, 12 Feb 2004 11:37:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJq7-0000KF-Mp for xcon-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01574 for ; Thu, 12 Feb 2004 11:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJq4-0007KO-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 11:37:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJpG-0007Ek-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 11:36:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJok-00078v-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 11:35:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJon-00007n-1C; Thu, 12 Feb 2004 11:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJo4-0008Sy-Kx for xcon@optimus.ietf.org; Thu, 12 Feb 2004 11:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01473 for ; Thu, 12 Feb 2004 11:35:14 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJo1-00076X-00 for xcon@ietf.org; Thu, 12 Feb 2004 11:35:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJn4-00070G-00 for xcon@ietf.org; Thu, 12 Feb 2004 11:34:14 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ArJm9-0006rG-00 for xcon@ietf.org; Thu, 12 Feb 2004 11:33:17 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CGXI306168 for ; Thu, 12 Feb 2004 18:33:18 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Feb 2004 18:33:18 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 12 Feb 2004 18:33:18 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] "Many users in a single operation" Requirements Date: Thu, 12 Feb 2004 18:33:17 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797749@esebe019.ntc.nokia.com> Thread-Topic: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPvcz3Jb4YIVoLBQDSBV/8FJxrYogAONw5wAHVB4CAAARNFMA== To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 16:33:18.0062 (UTC) FILETIME=[EB8210E0:01C3F185] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Orit Levin [mailto:oritl@microsoft.com] > Sent: 12.February.2004 18:12 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org > Cc: Jonathan Rosenberg > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Where is this "XCAP extension" defined in the XCAP documents?! >=20 > Besides, you can't do in the same way REQ-CP-3: It MAY be possible for > the client to batch multiple operations (such as add a user to ACL > blocked list, or remove a user from ACL allowed list) into a single > request that is processed atomically. Removing someone from the ACL allowed list here I believe means adding = them to the blocked list as follows (Perhaps the comment between the = brackets needs clarification): PUT = http://xcap.example.com/services/conferences/users/Alice/conference.xml?C= onference HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Tuesday, February 10, 2004 12:18 AM > To: Orit Levin; xcon@ietf.org > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 > Here is an example of how to add multiple users to an ACL list in a > single operation: >=20 > PUT > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >=20 >=20 > The rest are done in a similar fashion. >=20 > /Hisham > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On=20 > Behalf Of ext > > Orit Levin > > Sent: 10.February.2004 03:15 > > To: xcon@ietf.org > > Subject: [XCON] "Many users in a single operation" Requirements > >=20 > >=20 > > Hi guys! > > =20 > > There are many places throughout the CPCP-req document that identify > > operations on a "subset of list" as MUST be performed in a single > > operation (e.g. G4, G6, H2, and H4). > > How do you plan to meet these requirements with "XCAP CPCP"? > > =20 > > The same question for REQ-CP-3: It MAY be possible for the client to > > batch multiple operations (such as add a user to ACL=20 > blocked list, or > > remove a user from ACL allowed list) into a single request that is > > processed atomically. > > =20 > > Thanks, > > Orit. > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Feb 12 18:17:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22905 for ; Thu, 12 Feb 2004 18:17:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQ4P-0006En-Jj for xcon-archive@odin.ietf.org; Thu, 12 Feb 2004 18:16:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CNGXfY023973 for xcon-archive@odin.ietf.org; Thu, 12 Feb 2004 18:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQ4P-0006Ea-EI for xcon-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 18:16:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22863 for ; Thu, 12 Feb 2004 18:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQ4K-0001Y2-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 18:16:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQ3L-0001Tv-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 18:15:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArQ2s-0001Pp-00 for xcon-web-archive@ietf.org; Thu, 12 Feb 2004 18:14:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQ2w-0005xY-9z; Thu, 12 Feb 2004 18:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQ2V-0005rN-IZ for xcon@optimus.ietf.org; Thu, 12 Feb 2004 18:14:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22724 for ; Thu, 12 Feb 2004 18:14:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQ2Q-0001PP-00 for xcon@ietf.org; Thu, 12 Feb 2004 18:14:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQ1U-0001KL-00 for xcon@ietf.org; Thu, 12 Feb 2004 18:13:33 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1ArQ0j-00019f-00 for xcon@ietf.org; Thu, 12 Feb 2004 18:12:46 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 15:12:20 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Feb 2004 15:12:26 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 15:11:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] "Many users in a single operation" Requirements Date: Thu, 12 Feb 2004 15:12:19 -0800 Message-ID: Thread-Topic: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPvcz3Jb4YIVoLBQDSBV/8FJxrYogAONw5wAHVB4CAAARNFMAAN3S8g From: "Orit Levin" To: , Cc: X-OriginalArrivalTime: 12 Feb 2004 23:11:52.0545 (UTC) FILETIME=[99A69510:01C3F1BD] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I didn't understand the answers. It seems to me that it is easier to remove the requirements rather than trying to implement them with XCAP. :-) Orit. -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Sent: Thursday, February 12, 2004 8:33 AM To: Orit Levin; xcon@ietf.org Cc: jdrosen@dynamicsoft.com Subject: RE: [XCON] "Many users in a single operation" Requirements > -----Original Message----- > From: ext Orit Levin [mailto:oritl@microsoft.com] > Sent: 12.February.2004 18:12 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon@ietf.org > Cc: Jonathan Rosenberg > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 >=20 > Where is this "XCAP extension" defined in the XCAP documents?! >=20 > Besides, you can't do in the same way REQ-CP-3: It MAY be possible for > the client to batch multiple operations (such as add a user to ACL=20 > blocked list, or remove a user from ACL allowed list) into a single=20 > request that is processed atomically. Removing someone from the ACL allowed list here I believe means adding them to the blocked list as follows (Perhaps the comment between the brackets needs clarification): PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml? Conference HTTP/1.1 Content-Type:text/plain sip:bob@example.com sip:alice@example.com sip:bob@domain.com >=20 > Thanks, > Orit. >=20 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Tuesday, February 10, 2004 12:18 AM > To: Orit Levin; xcon@ietf.org > Subject: RE: [XCON] "Many users in a single operation" Requirements >=20 > Here is an example of how to add multiple users to an ACL list in a=20 > single operation: >=20 > PUT > http://xcap.example.com/services/conferences/users/Alice/confe > rence.xml? > Conference/ACL/ACL-target-URI HTTP/1.1 > Content-Type:text/plain >=20 > Access-type=3D"Allowed">sip:bob@example.com > Access-type=3D"Allowed">sip:alice@example.com > Access-type=3D"Allowed">sip:bob@domain.com >=20 >=20 > The rest are done in a similar fashion. >=20 > /Hisham > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On > Behalf Of ext > > Orit Levin > > Sent: 10.February.2004 03:15 > > To: xcon@ietf.org > > Subject: [XCON] "Many users in a single operation" Requirements > >=20 > >=20 > > Hi guys! > > =20 > > There are many places throughout the CPCP-req document that identify > > operations on a "subset of list" as MUST be performed in a single=20 > > operation (e.g. G4, G6, H2, and H4). > > How do you plan to meet these requirements with "XCAP CPCP"? > > =20 > > The same question for REQ-CP-3: It MAY be possible for the client to > > batch multiple operations (such as add a user to ACL > blocked list, or > > remove a user from ACL allowed list) into a single request that is=20 > > processed atomically. > > =20 > > Thanks, > > Orit. > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sat Feb 14 14:33:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27815 for ; Sat, 14 Feb 2004 14:33:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5X4-0004kN-IY for xcon-archive@odin.ietf.org; Sat, 14 Feb 2004 14:32:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EJWsoq018241 for xcon-archive@odin.ietf.org; Sat, 14 Feb 2004 14:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5X4-0004k8-Bl for xcon-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 14:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27766 for ; Sat, 14 Feb 2004 14:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As5X1-0004VW-00 for xcon-web-archive@ietf.org; Sat, 14 Feb 2004 14:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As5W3-0004S8-00 for xcon-web-archive@ietf.org; Sat, 14 Feb 2004 14:31:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As5VD-0004Pf-00 for xcon-web-archive@ietf.org; Sat, 14 Feb 2004 14:30:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5VF-0004cq-4K; Sat, 14 Feb 2004 14:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As5VC-0004c8-Mb for xcon@optimus.ietf.org; Sat, 14 Feb 2004 14:30:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27715 for ; Sat, 14 Feb 2004 14:30:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As5VA-0004PP-00 for xcon@ietf.org; Sat, 14 Feb 2004 14:30:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As5UT-0004Ml-00 for xcon@ietf.org; Sat, 14 Feb 2004 14:30:13 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1As5Ti-0004Hf-00; Sat, 14 Feb 2004 14:29:26 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 11:30:10 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sat, 14 Feb 2004 11:28:38 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 14 Feb 2004 11:28:38 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 14 Feb 2004 11:28:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: [XCON] "Many users in a single operation" Requirements Date: Sat, 14 Feb 2004 11:29:01 -0800 Message-ID: Thread-Topic: [Simple] Re: [XCON] "Many users in a single operation" Requirements Thread-Index: AcPyVOSxtK2GWGngQoCejDN7cjsSpwAzRlQg From: "Orit Levin" To: "Jonathan Rosenberg" , , Cc: , X-OriginalArrivalTime: 14 Feb 2004 19:28:41.0536 (UTC) FILETIME=[C0D04400:01C3F330] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable XCAP was introduced and designed (as its name says: "XML Configuration Access Protocol") as a LIGHT way CONFIGURATION protocol. As a result, by design it doesn't address close-to-real-time dynamic data manipulations. You can perform any rich atomic operation you need, but in order to do so, you will need to be (preferably) the only owner of the data, to upload the whole data sub-tree, change it locally, and then PUT it back. I think it is a mistake to stretch XCAP functionality beyond this. I think it is a mistake to position XCAP as the (only) protocol for all kinds of dynamic operations neither for presence nor for conferencing. Instead, I liked Jonathan's approach to his "XCAP drafts":=20 "The documents are much less xcap-centric. They talk about document formats, and have a small section at the end which defines the usage for xcap. The title and filenames have also changed to reflect this. This clarifies that these documents can be used outside of xcap." I suggest that XCON group does the same for CPCP. Thanks, Orit. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Friday, February 13, 2004 9:14 AM To: Markus.Isomaki@nokia.com Cc: hisham.khartabil@nokia.com; Orit Levin; simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements Markus.Isomaki@nokia.com wrote: > Hi, >=20 > Jonathan Rosenberg wrote: >=20 >> We had discussed this particular limitation quite a bit during the >> design of xcap, and it was deemed an acceptable limitation. If it >> is no longer the case, then we can discuss fixes. >=20 >=20 > I think this all depends on what kind of usages we envision for XCAP. > The requirement for doing multiple operations atomically was also > originally included in the data manipulation reqs that were used as > motivation for XCAP. However, it seemed that doing the actual > applications that were in SIMPLE charter (mainly presence related) > did not really need this capability. Right. Though I fear that, in the future there will be more. >=20 > My opinion is that it should be added to XCAP if and only if: 1. It > is mandatory for conference control (CPCP) according to the concensus > in XCON WG 2. XCON WG chooses XCAP for CPCP's baseline given that > XCAP can meet this requirement 3. XCAP would not be complicated or > delayed considerably because of this >=20 > So far I haven't seen clarification on either 1. or 2. in XCON, but I > think it would be a good target for the Korea meeting. I would propose that I make a first stab at what such a feature might=20 look like in the revision I will submit (probably at 8:58am est=20 Monday...), and then we can discuss it with something concrete in hand. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sat Feb 14 23:40:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12607 for ; Sat, 14 Feb 2004 23:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE4j-0000Bl-LS for xcon-archive@odin.ietf.org; Sat, 14 Feb 2004 23:40:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F4eDOA000725 for xcon-archive@odin.ietf.org; Sat, 14 Feb 2004 23:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE4j-0000Bc-9r for xcon-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 23:40:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12604 for ; Sat, 14 Feb 2004 23:40:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE4h-000585-00 for xcon-web-archive@ietf.org; Sat, 14 Feb 2004 23:40:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE3j-00055R-00 for xcon-web-archive@ietf.org; Sat, 14 Feb 2004 23:39:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsE3Y-000537-00 for xcon-web-archive@ietf.org; Sat, 14 Feb 2004 23:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE3Z-0008Pi-3U; Sat, 14 Feb 2004 23:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsE2l-0008Nl-0V for xcon@optimus.ietf.org; Sat, 14 Feb 2004 23:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12577 for ; Sat, 14 Feb 2004 23:38:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsE2i-00052M-00 for xcon@ietf.org; Sat, 14 Feb 2004 23:38:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsE1o-000509-00 for xcon@ietf.org; Sat, 14 Feb 2004 23:37:13 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsE1F-0004ul-00; Sat, 14 Feb 2004 23:36:37 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F4aDNr004552; Sat, 14 Feb 2004 23:36:13 -0500 (EST) Message-ID: <402EF735.9040302@dynamicsoft.com> Date: Sat, 14 Feb 2004 23:36:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Markus.Isomaki@nokia.com, xcon@ietf.org, hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: [XCON] "Many users in a single operation" Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit Levin wrote: > XCAP was introduced and designed (as its name says: "XML Configuration > Access Protocol") as a LIGHT way CONFIGURATION protocol. As a result, by > design it doesn't address close-to-real-time dynamic data manipulations. I'm not sure what you mean by that. If I add a buddy to my buddy list with xcap, that change happens in real time. > You can perform any rich atomic operation you need, but in order to do > so, you will need to be (preferably) the only owner of the data, to > upload the whole data sub-tree, change it locally, and then PUT it back. XCAP most certainly allows multiple users to manipulate the data. It is not optimized for this case, no doubt, as the etag is over the entire document, so that two users manipulating separate parts will require each to syncrhonize on the changes made by the other before making their own change. > > I think it is a mistake to stretch XCAP functionality beyond this. > I think it is a mistake to position XCAP as the (only) protocol for all > kinds of dynamic operations neither for presence nor for conferencing. dynamic operations? Can you clarify what you mean? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 17 12:06:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17797 for ; Tue, 17 Feb 2004 12:06:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8ft-00052A-2c for xcon-archive@odin.ietf.org; Tue, 17 Feb 2004 12:06:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HH6LJC019344 for xcon-archive@odin.ietf.org; Tue, 17 Feb 2004 12:06:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8fs-00051v-TS for xcon-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 12:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17674 for ; Tue, 17 Feb 2004 12:06:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8fr-0006hG-00 for xcon-web-archive@ietf.org; Tue, 17 Feb 2004 12:06:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8eC-0006NX-00 for xcon-web-archive@ietf.org; Tue, 17 Feb 2004 12:04:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At8ck-00063Q-00 for xcon-web-archive@ietf.org; Tue, 17 Feb 2004 12:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8cf-0003qN-8f; Tue, 17 Feb 2004 12:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8cT-0003nd-9s for xcon@optimus.ietf.org; Tue, 17 Feb 2004 12:02:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17175 for ; Tue, 17 Feb 2004 12:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8cS-0005ze-00 for xcon@ietf.org; Tue, 17 Feb 2004 12:02:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8aO-0005ab-00 for xcon@ietf.org; Tue, 17 Feb 2004 12:00:41 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1At8ZU-0005MG-00 for xcon@ietf.org; Tue, 17 Feb 2004 11:59:44 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 5800; Tue, 17 Feb 2004 12:00:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2004 11:59:13 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB242D6@zoe.office.snowshore.com> Thread-Topic: draft-burger-xcon-mmodels-00 Thread-Index: AcP1d1rmcijDzlS0SOqFOkCJYTPiIw== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [XCON] draft-burger-xcon-mmodels-00 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I posted a rough outline of the different approaches for modeling media = policy in XCON. It is at = http://www.ietf.org/internet-drafts/draft-burger-xcon-mmodels-00.txt Discussion welcome. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Feb 24 15:20:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08931 for ; Tue, 24 Feb 2004 15:20:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avj2Q-0006Zy-OK for xcon-archive@odin.ietf.org; Tue, 24 Feb 2004 15:20:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OKKIo9025283 for xcon-archive@odin.ietf.org; Tue, 24 Feb 2004 15:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avj2Q-0006Zb-Fr for xcon-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 15:20:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08870 for ; Tue, 24 Feb 2004 15:20:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avj2P-0005vO-00 for xcon-web-archive@ietf.org; Tue, 24 Feb 2004 15:20:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avj1S-0005qi-00 for xcon-web-archive@ietf.org; Tue, 24 Feb 2004 15:19:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avj1A-0005m9-00 for xcon-web-archive@ietf.org; Tue, 24 Feb 2004 15:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avj1B-000679-02; Tue, 24 Feb 2004 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avj0S-0005ry-3e for xcon@optimus.ietf.org; Tue, 24 Feb 2004 15:18:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08695 for ; Tue, 24 Feb 2004 15:18:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avj0Q-0005l7-00 for xcon@ietf.org; Tue, 24 Feb 2004 15:18:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvizY-0005gx-00 for xcon@ietf.org; Tue, 24 Feb 2004 15:17:20 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1AvizJ-0005cB-00 for xcon@ietf.org; Tue, 24 Feb 2004 15:17:05 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTL000KVUZND9@firewall.mci.com> for xcon@ietf.org; Tue, 24 Feb 2004 20:16:35 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTL00G01UZE4Y@pmismtp01.mcilink.com>; Tue, 24 Feb 2004 20:16:35 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.153.19]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTL00EM6UZLO3@pmismtp01.mcilink.com>; Tue, 24 Feb 2004 20:16:35 +0000 (GMT) Date: Tue, 24 Feb 2004 14:16:33 -0600 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: xcon@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20040224141343.0285dda8@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] Draft XCON Agenda Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 All, Here's the XCON WG Agenda so far... Thanks, Alan Johnston co-chair sip:alan@sipstation.com THURSDAY, March 4, 2004 0900-1130 Morning Sessions Emerald TSV xcon Centralized Conferencing WG - Agenda bash (5 minutes) - Milestone review/discussion (10 minutes) (includes status of draft-ietf-xcon-conference-scenarios-00.txt) - Floor Control (15 minutes) 15 minutes: Joerg Ott draft-ietf-xcon-floor-control-req-00.txt - Conference Policy Control Protocol (CPCP) (30 minutes) 15 minutes: Hisham Khartabil/CPCP Requirements draft-ietf-xcon-cpcp-reqs-02.txt 15 minutes: Hisham Khartabil/CPCP XCAP Usage draft-koskelainen-xcon-xcap-cpcp-usage-02.txt - Media Policy Control Protocol (MPCP) Requirements/Protocol (30 minutes) 15 minutes: Cullen Jennings/Parametric Media Templates draft-jennings-xcon-media-control-00.txt 15 minutes Eric Burger/Media Control Models draft-burger-xcon-mmodels-00.txt - Open Media Policy Discussion (30 minutes) _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Feb 25 22:50:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02798 for ; Wed, 25 Feb 2004 22:50:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCXa-0002XC-Mc for xcon-archive@odin.ietf.org; Wed, 25 Feb 2004 22:50:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q3oQBt009738 for xcon-archive@odin.ietf.org; Wed, 25 Feb 2004 22:50:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCXa-0002Wz-H7 for xcon-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 22:50:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02792 for ; Wed, 25 Feb 2004 22:50:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwCXX-00051D-00 for xcon-web-archive@ietf.org; Wed, 25 Feb 2004 22:50:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwCWZ-0004vm-00 for xcon-web-archive@ietf.org; Wed, 25 Feb 2004 22:49:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwCWA-0004qR-00 for xcon-web-archive@ietf.org; Wed, 25 Feb 2004 22:48:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCWD-0002Rj-Ds; Wed, 25 Feb 2004 22:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCVR-0002PZ-KU for xcon@optimus.ietf.org; Wed, 25 Feb 2004 22:48:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02735 for ; Wed, 25 Feb 2004 22:48:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwCVO-0004on-00 for xcon@ietf.org; Wed, 25 Feb 2004 22:48:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwCUR-0004kS-00 for xcon@ietf.org; Wed, 25 Feb 2004 22:47:12 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AwCTq-0004cw-00 for xcon@ietf.org; Wed, 25 Feb 2004 22:46:34 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i1Q3joUY029941; Wed, 25 Feb 2004 21:45:58 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQNRZ>; Wed, 25 Feb 2004 21:45:50 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A326@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Eric Burger , "'xcon@ietf.org'" Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Wed, 25 Feb 2004 21:45:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I know this issue has been settled, but just as a general announcement for any work in any working group: the IAB and IESG have stated positions on the topic of legal intercept that are (to my understanding) binding on all IETF protocols. These positions are detailed in RFC 2804, and are summarized as follows: "The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards." /a > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, January 20, 2004 10:01 > To: xcon@ietf.org > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > Would Legal Intercept be in or out? E.g., hidden > participants that CANNOT be known. > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Friday, December 19, 2003 6:14 AM > > To: hisham.khartabil@nokia.com; mhammer@cisco.com > > Cc: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > I believe hidden users are appropriate. > > > > I do not believe that this adds complexity to the > > specifications (particularly to the specification of CPCP), > > so I see no need to make it a DEFER as far as the > > specifications are concerned. It may add complexity to the > > implementation, so I am quite happy to see it a MAY in the > > requirements, so that it is optional to implement. > > > > As regards the legal implications of hidden users, then yes, > > there may be priveleged users that are able to request the > > identity of hidden users (along with an indication that they > > are hidden). This of course requires the enabling of such a > > privileged user in the first place. > > > > Secondly, it may not be necessary to identify hidden users, > > but merely that there are hidden users in the conference (in > > addition to any that may have made themselves visible). Some > > countries require some form of tone or announcement on voice > > conferences when someone else is listening in. They also > > require an announcement or other indication in the call is > > being recorded. > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: 15 December 2003 16:29 > > > To: mhammer@cisco.com > > > Cc: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ext Michael Hammer [mailto:mhammer@cisco.com] > > > > Sent: 15.December.2003 18:17 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > > > Cc: xcon@ietf.org > > > > Subject: Re: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > > > > Related to this is there a requirement that, while not > > > revealing the > > > > identity of a hidden user, the conference policy contains > > > > state indication > > > > about either the presence of hidden users, or the > > > > possibility/preclusion > > > > that such hidden users may be present? > > > > > > > > I am anticipating that: > > > > 1) Laws may exist that require notification of such. > > > > > > That's a good point. This might require changes to the > > > conference event package to indicate if there are hidden > > > participants or not, and if so, how many. > > > > > > The question remain: is there a need for such a feature (to > > > hide users?)? > > > > > > Regards, > > > Hisham > > > > > > > 2) In some conferences, participants may want technical > > > > assurance that > > > > hidden users are not possible before they speak. > > > > > > > > Mike > > > > > > > > > > > > At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: > > > > >This is in reference to requirements REQ-A7 and REQ-E10 in > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > REQ-A7: It SHOULD be possible to participate in a > conference as a > > > hidden user. Hidden user is present in a conference, but > > his presence > > > is not revealed. > > > > > > REQ-E10: It MUST be possible to allow and disallow > > hidden membership > > > in a conference. > > > > > >Should a conference policy, using CPCP, specify if a user > > can be hidden? > > >This means that the conference state package does not report the > > >participation on the hidden user. CPCP is used to identify > > which users are > > >hidden. The list of hidden users is only manipulated by a > > privileged user > > >such as the moderator. > > > > > >Regards, > > >Hisham > > > > > >_______________________________________________ > > >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 From exim@www1.ietf.org Thu Feb 26 01:07:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08050 for ; Thu, 26 Feb 2004 01:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEgA-0003MH-K5 for xcon-archive@odin.ietf.org; Thu, 26 Feb 2004 01:07:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q67QeR012901 for xcon-archive@odin.ietf.org; Thu, 26 Feb 2004 01:07:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEgA-0003Ls-4N for xcon-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 01:07:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08041 for ; Thu, 26 Feb 2004 01:07:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwEg7-0002O6-00 for xcon-web-archive@ietf.org; Thu, 26 Feb 2004 01:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwEfL-0002J3-00 for xcon-web-archive@ietf.org; Thu, 26 Feb 2004 01:06:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwEem-0002DH-00 for xcon-web-archive@ietf.org; Thu, 26 Feb 2004 01:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEen-0002xG-FA; Thu, 26 Feb 2004 01:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEeD-0002wE-9Y for xcon@optimus.ietf.org; Thu, 26 Feb 2004 01:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07914 for ; Thu, 26 Feb 2004 01:05:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwEeA-0002C6-00 for xcon@ietf.org; Thu, 26 Feb 2004 01:05:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwEdJ-00027R-00 for xcon@ietf.org; Thu, 26 Feb 2004 01:04:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AwEcx-00021t-00 for xcon@ietf.org; Thu, 26 Feb 2004 01:04:07 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1Q63K4U011110; Wed, 25 Feb 2004 22:03:20 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQQ73539; Wed, 25 Feb 2004 22:03:19 -0800 (PST) In-Reply-To: <9ACE0CEE075B494096C86C23878BF85906A326@dyn-tx-exch-001.dynamicsoft.com> References: <9ACE0CEE075B494096C86C23878BF85906A326@dyn-tx-exch-001.dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <91D82640-6821-11D8-B826-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: "'xcon@ietf.org'" , Rohan Mahy , Eric Burger From: Rohan Mahy Subject: Re: [XCON] CPCP Requirement: Hidden Participants Date: Wed, 25 Feb 2004 22:03:59 -0800 To: Adam Roach X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In any case. Wiretaps are not hidden users. They are just there. The thing that announces that Eric has joined the conference is hidden. Not because the identity of the announcer is private, but because displaying the identity of the announcer would be annoying. thx, -rohan On Feb 25, 2004, at 7:45 PM, Adam Roach wrote: > I know this issue has been settled, but just as a general > announcement for any work in any working group: the IAB > and IESG have stated positions on the topic of legal > intercept that are (to my understanding) binding on all > IETF protocols. > > These positions are detailed in RFC 2804, and are > summarized as follows: "The IETF has decided not to consider > requirements for wiretapping as part of the process for > creating and maintaining IETF standards." > > /a > >> -----Original Message----- >> From: Eric Burger [mailto:eburger@snowshore.com] >> Sent: Tuesday, January 20, 2004 10:01 >> To: xcon@ietf.org >> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >> >> >> Would Legal Intercept be in or out? E.g., hidden >> participants that CANNOT be known. >> >>> -----Original Message----- >>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>> Sent: Friday, December 19, 2003 6:14 AM >>> To: hisham.khartabil@nokia.com; mhammer@cisco.com >>> Cc: xcon@ietf.org >>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>> >>> >>> I believe hidden users are appropriate. >>> >>> I do not believe that this adds complexity to the >>> specifications (particularly to the specification of CPCP), >>> so I see no need to make it a DEFER as far as the >>> specifications are concerned. It may add complexity to the >>> implementation, so I am quite happy to see it a MAY in the >>> requirements, so that it is optional to implement. >>> >>> As regards the legal implications of hidden users, then yes, >>> there may be priveleged users that are able to request the >>> identity of hidden users (along with an indication that they >>> are hidden). This of course requires the enabling of such a >>> privileged user in the first place. >>> >>> Secondly, it may not be necessary to identify hidden users, >>> but merely that there are hidden users in the conference (in >>> addition to any that may have made themselves visible). Some >>> countries require some form of tone or announcement on voice >>> conferences when someone else is listening in. They also >>> require an announcement or other indication in the call is >>> being recorded. >>> >>> regards >>> >>> Keith >>> >>> Keith Drage >>> Lucent Technologies >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >>> >>>> -----Original Message----- >>>> From: hisham.khartabil@nokia.com >> [mailto:hisham.khartabil@nokia.com] >>>> Sent: 15 December 2003 16:29 >>>> To: mhammer@cisco.com >>>> Cc: xcon@ietf.org >>>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Michael Hammer [mailto:mhammer@cisco.com] >>>>> Sent: 15.December.2003 18:17 >>>>> To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>> Cc: xcon@ietf.org >>>>> Subject: Re: [XCON] CPCP Requirement: Hidden Participants >>>>> >>>>> >>>>> Related to this is there a requirement that, while not >>>> revealing the >>>>> identity of a hidden user, the conference policy contains >>>>> state indication >>>>> about either the presence of hidden users, or the >>>>> possibility/preclusion >>>>> that such hidden users may be present? >>>>> >>>>> I am anticipating that: >>>>> 1) Laws may exist that require notification of such. >>>> >>>> That's a good point. This might require changes to the >>>> conference event package to indicate if there are hidden >>>> participants or not, and if so, how many. >>>> >>>> The question remain: is there a need for such a feature (to >>>> hide users?)? >>>> >>>> Regards, >>>> Hisham >>>> >>>>> 2) In some conferences, participants may want technical >>>>> assurance that >>>>> hidden users are not possible before they speak. >>>>> >>>>> Mike >>>>> >>>>> >>>>> At 02:55 PM 12/15/2003 +0200, hisham.khartabil@nokia.com wrote: >>>>>> This is in reference to requirements REQ-A7 and REQ-E10 in >>>>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt >>>> >>>> REQ-A7: It SHOULD be possible to participate in a >> conference as a >>>> hidden user. Hidden user is present in a conference, but >>> his presence >>>> is not revealed. >>>> >>>> REQ-E10: It MUST be possible to allow and disallow >>> hidden membership >>>> in a conference. >>>> >>>> Should a conference policy, using CPCP, specify if a user >>> can be hidden? >>>> This means that the conference state package does not report the >>>> participation on the hidden user. CPCP is used to identify >>> which users are >>>> hidden. The list of hidden users is only manipulated by a >>> privileged user >>>> such as the moderator. >>>> >>>> Regards, >>>> Hisham >>>> >>>> _______________________________________________ >>>> 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 From exim@www1.ietf.org Thu Feb 26 18:08:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15718 for ; Thu, 26 Feb 2004 18:08:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUbj-0000ba-Aj for xcon-archive@odin.ietf.org; Thu, 26 Feb 2004 18:07:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QN7toa002318 for xcon-archive@odin.ietf.org; Thu, 26 Feb 2004 18:07:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUbj-0000bJ-1V for xcon-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 18:07:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15665 for ; Thu, 26 Feb 2004 18:07:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUbg-0003LY-00 for xcon-web-archive@ietf.org; Thu, 26 Feb 2004 18:07:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUan-0003Fs-00 for xcon-web-archive@ietf.org; Thu, 26 Feb 2004 18:06:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwUZr-0003An-00 for xcon-web-archive@ietf.org; Thu, 26 Feb 2004 18:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUZt-0008NB-Ir; Thu, 26 Feb 2004 18:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUZn-0008KK-H2 for xcon@optimus.ietf.org; Thu, 26 Feb 2004 18:05:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15470 for ; Thu, 26 Feb 2004 18:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUZk-00039z-00 for xcon@ietf.org; Thu, 26 Feb 2004 18:05:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUYr-00035C-00 for xcon@ietf.org; Thu, 26 Feb 2004 18:04:58 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AwUYe-0002zx-00 for xcon@ietf.org; Thu, 26 Feb 2004 18:04:44 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i1QN4EUY023443 for ; Thu, 26 Feb 2004 17:04:14 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQ3A8>; Thu, 26 Feb 2004 17:04:14 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A32F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Thu, 26 Feb 2004 17:04:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Minute Taker Volunteer? Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Since it worked so well last time (thanks, Paul), I am once again soliciting volunteers to take minutes during the XCON meeting on Thursday. Please respond if you plan to attend and are willing to help out. Thanks. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Received: from localhost.localdomain (proofpoint-01.dynamicsoft.com [63.113.45.180]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1Q8KYQ0F; Tue, 10 Feb 2004 01:32:17 -0500 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i1A6WF1C029097; Tue, 10 Feb 2004 01:32:15 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i1A6WCAO010987; Tue, 10 Feb 2004 01:32:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqRRA-00087j-Kj; Tue, 10 Feb 2004 01:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqRQm-000873-0L for xcon@optimus.ietf.org; Tue, 10 Feb 2004 01:31:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19128 for ; Tue, 10 Feb 2004 01:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqRQi-0005h4-00 for xcon@ietf.org; Tue, 10 Feb 2004 01:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqRPl-0005bG-00 for xcon@ietf.org; Tue, 10 Feb 2004 01:30:33 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AqROp-0005Rx-00 for xcon@ietf.org; Tue, 10 Feb 2004 01:29:35 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 28251; Tue, 10 Feb 2004 01:30:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 10 Feb 2004 01:29:01 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A13B@zoe.office.snowshore.com> Thread-Topic: CPCP Start/stop Proposal Thread-Index: AcPvLYlOaJ9ZthXMTtuSPDo/72U5TA== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [XCON] CPCP Start/stop Proposal Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Proofpoint-Spam-Score: 0 Since I started the thread "CPCP Requirement: Repeat times", which has generated over 200 pages of responses (yes, I print stuff out to read on airplanes), I thought I would give a concrete proposal that I _hope_ will satisfy most of the excellent comments generated. First, two definitions: The CPCP Conference Start Time is the earliest mixing opportunity for a conference. If you want to advertise a user-level start time, like when you can call into a bridge and talk to an IVR system or listen to a wonderful selection of music-on-hold, advertise the user-level start time with SAP. The CPCP End Time is the time mixing ceases for a conference. If you want to advertise a user-level stop time, like when everyone is supposed to go out for lunch, but might not be the stop time, if things are going peachy, advertise the user-level stop time with SAP. A Named Participant is a "special" participant. Usually this is the conference owner. I would be happy to replace Named Participant with Conference Owner, but I was thinking about delegating authority, e.g., "Start this conference when I or my secretary join the bridge." Also, if one examines CPCP End Time condition 2c, one can envision a policy that states, "Keep the bridge up until both the CEO and the COO leave the bridge." With those definitions, here is the proposal: The CPCP Start Time is the latter of: 1. A specified Earliest Mixing Time (which can be NOW or a time delta/GMT) - AND ONE OF - 2a. The time the first participant arrives - OR - 2b. The time a Named Participant arrives The CPCP End Time is the earlier of: 1. A specified End of Mixing Time (which can be NOW, NEVER, or a time delta/GMT) - AND ONE OF - 2a. The time the last participant leaves - OR - 2b. The time a Named Participant leaves - OR - 2c. The time the last Named Participant leaves - OR - 2d. Persistent (e.g., only the time (condition 1) matters) _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon