From adam@nostrum.com Wed Aug 5 08:22:09 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F9C28C5B8 for ; Wed, 5 Aug 2009 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h52PMYFGu2r1 for ; Wed, 5 Aug 2009 08:22:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8839C28C5A5 for ; Wed, 5 Aug 2009 08:22:08 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n75FM8Fw063306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Aug 2009 10:22:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A79A3A0.1090203@nostrum.com> Date: Wed, 05 Aug 2009 10:22:08 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [XCON] Draft minutes posted X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 15:22:09 -0000 [as chair] The first draft of minutes from the XCON meeting have been posted: http://www.ietf.org/proceedings/75/minutes/xcon.html If you have any corrections or additions to make, please contact the working group chairs. /a From adam@nostrum.com Wed Aug 5 08:27:17 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FE628C5B3 for ; Wed, 5 Aug 2009 08:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1uG6MIcQyRG for ; Wed, 5 Aug 2009 08:27:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 400A928C2A6 for ; Wed, 5 Aug 2009 08:27:16 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n75FRGfx063681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Aug 2009 10:27:16 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A79A4D3.4060201@nostrum.com> Date: Wed, 05 Aug 2009 10:27:15 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [XCON] Consensus call: Blueprint Cloning X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 15:27:17 -0000 [as chair] At the face-to-face meeting in Stockholm, we had a discussion regarding whether a conference object that was created from a blueprint retains a link to blueprint from which it was cloned. The examples document currently assumes that no such link exists. There was consensus among those in attendance that this is the proper behavior; the rationale voiced was that the blueprint will often be controlled by a different authority than the conferences cloned from it, and it would therefore be undesirable to have changes to the blueprint propagate to active conferences. If you have an opinion on this topic -- either in support of the foregoing conclusion or against it -- please voice it on the list. /a From adam@nostrum.com Wed Aug 5 08:31:58 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B23528C5D9 for ; Wed, 5 Aug 2009 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9OCo3Xr1W09 for ; Wed, 5 Aug 2009 08:31:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0C33828C57D for ; Wed, 5 Aug 2009 08:31:56 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n75FVvl7064037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Aug 2009 10:31:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A79A5ED.1040803@nostrum.com> Date: Wed, 05 Aug 2009 10:31:57 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [XCON] Consensus Call: CCMP Muting interaction with BFCP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 15:31:58 -0000 [as chair] At the face-to-face meeting in Stockholm, we discussed the interaction between muting conditions created by CCMP and the muting conditions created by BFCP. The question was whether these manipulated a single muting state (which would imply that a CCMP unmute operation would override the muting imposed by not having the floor in BFCP), or whether these operations operated on independent muting states (both of which must be unmuted for media to be contributed to the conference). The consensus among those in attendance was that the protocols operated on independent muting states. If you have an opinion on this topic -- either in support of that consensus or in opposition to it -- please express it on the mailing list. /a From lennox@cs.columbia.edu Wed Aug 5 09:20:54 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB24B3A718B for ; Wed, 5 Aug 2009 09:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ8VoaatT5Td for ; Wed, 5 Aug 2009 09:20:51 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by core3.amsl.com (Postfix) with ESMTP id ACDB43A71D8 for ; Wed, 5 Aug 2009 09:20:51 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail1.panix.com (Postfix) with ESMTP id 2B5481F099 for ; Wed, 5 Aug 2009 12:20:54 -0400 (EDT) Received: from amman.clic.cs.columbia.edu (amman.clic.cs.columbia.edu [128.59.15.55]) by mailbackend.panix.com (Postfix) with ESMTP id 0E2DD3087B for ; Wed, 5 Aug 2009 12:20:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19065.45413.467879.47899@amman.clic.cs.columbia.edu> Date: Wed, 5 Aug 2009 12:20:53 -0400 To: XCON-IETF In-Reply-To: <4A79A5ED.1040803@nostrum.com> References: <4A79A5ED.1040803@nostrum.com> X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Subject: Re: [XCON] Consensus Call: CCMP Muting interaction with BFCP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 16:20:54 -0000 I agree that BFCP and CCMP should operate independently in this respect. A related question, though, is that CCMP (via the common data model) seems to have multiple ways of muting a user. Do the endpoint/media/status=recvonly and endpoint/media/controls/to-mixer/mute=true states operate independently? Are the authorization requirements for the two expected to be different? (I'm in general perplexed about the to-mixer and from-mixer controls in the common data model -- is the presence of "VideoIn" and "VideoOut" mixers inside a media/type=audio block in the example in common-data-model-13 an error? If not, what does it mean?) -- Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com On Wednesday, August 5 2009, "Adam Roach" wrote to "XCON-IETF" saying: > [as chair] > > At the face-to-face meeting in Stockholm, we discussed the interaction > between muting conditions created by CCMP and the muting conditions > created by BFCP. The question was whether these manipulated a single > muting state (which would imply that a CCMP unmute operation would > override the muting imposed by not having the floor in BFCP), or whether > these operations operated on independent muting states (both of which > must be unmuted for media to be contributed to the conference). > > The consensus among those in attendance was that the protocols operated > on independent muting states. > > If you have an opinion on this topic -- either in support of that > consensus or in opposition to it -- please express it on the mailing list. From lennox@cs.columbia.edu Wed Aug 5 10:02:01 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD56028C598 for ; Wed, 5 Aug 2009 10:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd9q10AM07q4 for ; Wed, 5 Aug 2009 10:02:01 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by core3.amsl.com (Postfix) with ESMTP id CF96328C5E3 for ; Wed, 5 Aug 2009 10:02:00 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail1.panix.com (Postfix) with ESMTP id CEF361F099 for ; Wed, 5 Aug 2009 13:01:30 -0400 (EDT) Received: from amman.clic.cs.columbia.edu (amman.clic.cs.columbia.edu [128.59.15.55]) by mailbackend.panix.com (Postfix) with ESMTP id 8305130D0A for ; Wed, 5 Aug 2009 13:01:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19065.47850.208863.440522@amman.clic.cs.columbia.edu> Date: Wed, 5 Aug 2009 13:01:30 -0400 To: XCON-IETF X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Subject: [XCON] Heads up: draft-lennox-mmusic-sdp-source-selection-00 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 17:02:01 -0000 Hello, all -- As I presented in Stockholm, I've published the Internet-Draft draft-lennox-mmusic-sdp-source-selection-00, which may be of interest to the XCON community. (Note: Vidyo has potential IPR on this draft; see .) The draft is based on a conference architecture where a conference server sends multiple (unmixed) streams to the conference participants, using RTP SSRC multiplexing. The draft defines an SDP-based mechanism to allow participants to explicitly request specific of these media streams, along with parameters for how they should be received (resolution, frame rate, priority). The XCON relevance is that, while it's possible to list all available sources in SDP, it's not very efficient, since SDP doesn't have partial notifications. Thus, the draft recommends that if a conference event package is running in parallel (whether it's the XCON or SIPPING packages), the event package, rather than SDP, should be used to notify particpants of the available sources. So my questions to the group are twofold. First, is this a reasonable use of the conference event packages' element? And more fundamentally, are there reasons to try to solve this problem CCMP rather than in SDP? -- Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com From lennox@cs.columbia.edu Wed Aug 5 10:10:06 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184A128C5DE for ; Wed, 5 Aug 2009 10:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFT2dlb6ob6O for ; Wed, 5 Aug 2009 10:10:05 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by core3.amsl.com (Postfix) with ESMTP id 1C64A28C5EE for ; Wed, 5 Aug 2009 10:08:54 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail2.panix.com (Postfix) with ESMTP id D772F38E49 for ; Wed, 5 Aug 2009 13:08:18 -0400 (EDT) Received: from amman.clic.cs.columbia.edu (amman.clic.cs.columbia.edu [128.59.15.55]) by mailbackend.panix.com (Postfix) with ESMTP id A778F2FC12 for ; Wed, 5 Aug 2009 13:08:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19065.48258.322258.349474@amman.clic.cs.columbia.edu> Date: Wed, 5 Aug 2009 13:08:18 -0400 To: XCON-IETF X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Subject: [XCON] Syntax of field in the conference event package X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 17:10:06 -0000 Hello, all -- The other, minor issue I raised at the XCON meeting in Stockholm is that the SIPPING conference event package (RFC 4575) doesn't actually define the syntax of the element when it's used to represent SSRC values. SSRCs in RTP are just four binary octets; I've seen systems that, for instance, interpret them in host byte order (to avoid a generally- unnecessary ntohl() call), and many systems print them in hexadecimal rather than decimal when debugging. It looks like the intention of the conference event package is to interpret the SSRC as an unsigned 32-bit network-byte-order value, and print it in decimal -- is there any dispute about this? And is there any easy (lightweight) way to define this anywhere without needing an update to 4575? (The common data model could define it, of course, but this is more in the spirit of a correction to 4575 than extensions to it.) -- Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com From oscar.novo@ericsson.com Thu Aug 6 00:02:14 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF893A683E for ; Thu, 6 Aug 2009 00:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=3.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVo47sdw2rPi for ; Thu, 6 Aug 2009 00:02:14 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 213FE3A686E for ; Thu, 6 Aug 2009 00:02:12 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-78-4a7a7ff59cd3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 06.84.15141.5FF7A7A4; Thu, 6 Aug 2009 09:02:13 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 09:00:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 09:00:51 +0200 Message-ID: <9520E66537CC4941994C518E3E21091C01811E43@esealmw105.eemea.ericsson.se> In-Reply-To: <19065.45413.467879.47899@amman.clic.cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Consensus Call: CCMP Muting interaction with BFCP thread-index: AcoV6LiW12a7Vt5ETLaIoJ1gGPhHEAAdo2BA References: <4A79A5ED.1040803@nostrum.com> <19065.45413.467879.47899@amman.clic.cs.columbia.edu> From: "Oscar Novo" To: , "XCON-IETF" X-OriginalArrivalTime: 06 Aug 2009 07:00:52.0996 (UTC) FILETIME=[A3406440:01CA1663] X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] Consensus Call: CCMP Muting interaction with BFCP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 07:02:15 -0000 Hello Jonathan, Note that the data model defines multiple elements of doing the same things. It's up to the conferencing system to correlate those elements in the proper way. And, Good catch! The VideoIn and VideoOut values in the example are an error indeed. I'll fix it in a next version of the data model. Thanks Jonathan! Oscar -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of lennox@cs.columbia.edu Sent: 5. elokuuta 2009 19:21 To: XCON-IETF Subject: Re: [XCON] Consensus Call: CCMP Muting interaction with BFCP I agree that BFCP and CCMP should operate independently in this respect. A related question, though, is that CCMP (via the common data model) seems to have multiple ways of muting a user. Do the endpoint/media/status=3Drecvonly and endpoint/media/controls/to-mixer/mute=3Dtrue states operate = independently? Are the authorization requirements for the two expected to be different? (I'm in general perplexed about the to-mixer and from-mixer controls in the common data model -- is the presence of "VideoIn" and "VideoOut" mixers inside a media/type=3Daudio block in the example in common-data-model-13 an error? If not, what does it mean?) -- Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com On Wednesday, August 5 2009, "Adam Roach" wrote to "XCON-IETF" saying: > [as chair] >=20 > At the face-to-face meeting in Stockholm, we discussed the interaction > between muting conditions created by CCMP and the muting conditions=20 > created by BFCP. The question was whether these manipulated a single=20 > muting state (which would imply that a CCMP unmute operation would=20 > override the muting imposed by not having the floor in BFCP), or=20 > whether these operations operated on independent muting states (both=20 > of which must be unmuted for media to be contributed to the conference). >=20 > The consensus among those in attendance was that the protocols=20 > operated on independent muting states. >=20 > If you have an opinion on this topic -- either in support of that=20 > consensus or in opposition to it -- please express it on the mailing list. _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From spromano@unina.it Thu Aug 6 01:32:54 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DFB3A6AB4 for ; Thu, 6 Aug 2009 01:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVo6z9azloLV for ; Thu, 6 Aug 2009 01:32:54 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id B93343A6C78 for ; Thu, 6 Aug 2009 01:32:53 -0700 (PDT) Received: from localhost (webmail.unina.it [192.132.34.212]) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id n768WJjI032549; Thu, 6 Aug 2009 10:32:26 +0200 Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Thu, 06 Aug 2009 10:32:19 +0200 Message-ID: <20090806103219.pc5vgo66soo8kk8o@webmail.unina.it> Date: Thu, 06 Aug 2009 10:32:19 +0200 From: spromano@unina.it To: lennox@cs.columbia.edu References: <19065.47850.208863.440522@amman.clic.cs.columbia.edu> In-Reply-To: <19065.47850.208863.440522@amman.clic.cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.1/9659/Thu Aug 6 08:07:46 2009 on smtp2.unina.it X-Virus-Status: Clean Cc: XCON-IETF Subject: Re: [XCON] Heads up: draft-lennox-mmusic-sdp-source-selection-00 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 08:32:54 -0000 Hi Jonathan, interesting work, indeed. As to the points you are raising: > So my questions to the group are twofold. First, is this a reasonable use > of the conference event packages' element? I think it is. > And more fundamentally, > are there reasons to try to solve this problem CCMP rather than in SDP? I don't see a use case for CCMP related to this. Cheers, Simon I think that the Quoting lennox@cs.columbia.edu: > Hello, all -- > > As I presented in Stockholm, I've published the Internet-Draft > draft-lennox-mmusic-sdp-source-selection-00, which may be of interest to t= he > XCON community. > > (Note: Vidyo has potential IPR on this draft; see > .) > > The draft is based on a conference architecture where a conference server > sends multiple (unmixed) streams to the conference participants, using RTP > SSRC multiplexing. The draft defines an SDP-based mechanism to allow > participants to explicitly request specific of these media streams, along > with parameters for how they should be received (resolution, frame rate, > priority). > > The XCON relevance is that, while it's possible to list all available > sources in SDP, it's not very efficient, since SDP doesn't have partial > notifications. Thus, the draft recommends that if a conference event > package is running in parallel (whether it's the XCON or SIPPING packages)= , > the event package, rather than SDP, should be used to notify particpants o= f > the available sources. > > So my questions to the group are twofold. First, is this a reasonable use > of the conference event packages' element? And more fundamentall= y, > are there reasons to try to solve this problem CCMP rather than in SDP? > > -- > Jonathan Lennox > lennox@cs.columbia.edu / jonathan@vidyo.com > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www.ietf.org/mailman/listinfo/xcon > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From adam@nostrum.com Wed Aug 12 13:47:32 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6011528C143 for ; Wed, 12 Aug 2009 13:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0VDbCwzmKnR for ; Wed, 12 Aug 2009 13:47:28 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 346DE3A6948 for ; Wed, 12 Aug 2009 13:47:28 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7CKlIeg048353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 15:47:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A832A56.7030100@nostrum.com> Date: Wed, 12 Aug 2009 15:47:18 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Alan Johnston Subject: [XCON] XCON Chair Replacement X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:47:32 -0000 [as chair] As I mentioned in Stockholm, I have been working with the RAI area directors to transition away from my role as XCON chair. The primary factor in this decision is a desire to focus on my new responsibilities co-chairing the SIPCORE working group. It has been a pleasure working with each of you, and I am confident that we have the right group of implementors and authors involved to bring this work to a successful conclusion. I look forward to reading the announcement that XCON has closed after meeting its final milestone. Please join me in welcoming Richard Barnes as the new co-chair of XCON. Or, to put it in more technical terms: xcon-userid:rbarnes@xcon.ietf.org xcon:8977878@xcon.ietf.org update chair xcon-userid:adam@xcon.ietf.org xcon:239858@xcon.ietf.org update participant Again, thanks for all your hard work over the past six years. I am quite proud that we have reached the point where my final email as chair can contain (mostly) valid protocol messages based on our ultimate milestone. /a From rbarnes@bbn.com Sun Aug 16 13:14:24 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4444728C13A for ; Sun, 16 Aug 2009 13:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzz0NI5RqaO8 for ; Sun, 16 Aug 2009 13:14:23 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C9B233A6D49 for ; Sun, 16 Aug 2009 13:14:14 -0700 (PDT) Received: from [128.89.255.41] (helo=col-rbarnes-l1.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Mcm7O-0003XL-CN for xcon@ietf.org; Sun, 16 Aug 2009 16:14:18 -0400 Message-ID: <4A88689A.2050006@bbn.com> Date: Sun, 16 Aug 2009 16:14:18 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [XCON] Review of draft-ietf-xcon-common-data-model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 20:14:24 -0000 Hi all, In my effort to get up to speed on XCON, I'm in the process of reviewing the active working group drafts (in addition to the other relevant background). My review of draft-ietf-xcon-common-data-model is below. --Richard ----- Draft: draft-ietf-xcon-common-data-model-13 Reviewer: Richard Barnes Review Date: 13 Mar 07 General Comments: 1. The major challenge I had with this document there doesn't seem to be a clear separation in some cases between what the document describes, and what actions are implied. I'll call out specific instances below, but in future revisions, I would encourage the authors to focus describing clearly what the state of the conference is that this object describes, and separately, what actions this state requires or allows. Specific Comments: Section 1, Paragraph 1 The phrase "... using an Extensible Markup Language (XML)-based." does not parse. Section 1, Paragraph 3 s/and specifies who/and specifies by whom/ Section 3.3.1, ABNF It seems like a lot of the ABNF for the SIP URI (RFC3261, page 222) could be re-usable here. E.g., you could just say XCON-URI = "xcon:" [ userinfo ] hostport This would align the sets of allowed characters in what is now the conf-object-id, which could make parsing easier. It would also add back in the "password" field (within userinfo), which could be useful when these URIs are used to access XCON conferences via CCMP (you would however, have to REQUIRE that the password be the same as the ). Section 4.2.1 It seems like there should be some structure to the element, e.g., using the language tags from RFC1766. Section 4.2.6 This section specifies the meaning of this element if it is present and set to true, but not what it means for it to be present and false, or absent. Is the default for sidebars to be disallowed, confirmed by a moderator, etc.? Section 4.2.9, bullet This section says that the element specifies when mixing starts "before" the conference starts. Should this be "relative to", or is it not allowed for mixing to start after the conference starts? Section 4.2.9, bullet It's a little bit confusing that this element ends in -offset but isn't an offset. Does this interact with the requiredParticipant attribute of the element? E.g., can this element indicate that a privileged participant should be denied an extension to the mixing time? Section 4.2.13, bullet This section specifies what the "Moderator-controlled" and "FCFS" policies mean (although it's not clear to me what "a first-come-first-served" algorithm is when comes to media), but doesn't define what the "Automatic" algorithm means. Section 4.2.13, bullet It's really unclear what this element means. Are the sub-elements of the "controls" element describing controls that are available to a user? Constraints on how the current media streams are handled? I.e., does true tell the conference server to stop sending audio, or does it tell a client to show a "mute" control to the user? Section 4.2.13, bullet Why are these controls necessary? Are there systems that are doing video layout on the server? If not, then isn't it just a client UI issue? Section 4.6.2 For clarity, it might be helpful here (and in the Security Considerations) to say that these elements specify only that the clients must authenticate to the server, using a mechanism of the server's choosing -- the specific mechanism(s) to be used are determined by individual servers for individual CSPs, and are beyond the scope of this document. Section 4.6.5 Why does the "entity" attribute have to be unique in the scope of the conferencing system, rather than within the scope of the conference? At first blush, it might seem like this is necessary for CCMP, but in that case, there is always a conference-ID present to disambiguate. Section 4.6.5.3 s/provides anonymity/specifies what level of anonymity the server should provide/ Section 4.6.5.7 s/boolean action/boolean value/ Section 4.6.5.* It seems like there's an element missing, something like . and correspond to the "dial-out", and "refer" values for "method" above; what about "dial-in"? Section 4.6.5.10, paragraph 3 Is this phrase correct? "... a floor that joins the participant in the conference"? Section 8.1 See above comment on Section 4.6.2 Section 8.2 This section should be rewritten to be a little less hand-wavy. The key points are (1) conference information can be sensitive, so (2) protocols that transmit conference object need to be able to confidentiality-protect them. Couple of sentences describing the risks, then one sentence saying the "Protocols that transmit conference objects (or fragments thereof) MUST be able to provide confidentiality protection to them." Section 8.3 Since we're mostly talking about an object as it resides on the conference server, most of the integrity are related to authentication and access control. So this section could probably be deleted in favor of changing the title of 8.1 to "Authentication, Access Control, & Integrity". The only addition that might be necessary is to ensure that protocols that carry these objects over the wire provide them with integrity protection in order to ensure the integrity of the management process; essentially the confidentiality sentence above, s/confidentiality/integrity/. From rbarnes@bbn.com Mon Aug 17 10:10:59 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52AC28C2C5 for ; Mon, 17 Aug 2009 10:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5EVfUw6AdB4 for ; Mon, 17 Aug 2009 10:10:58 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DDDD728C21F for ; Mon, 17 Aug 2009 10:10:57 -0700 (PDT) Received: from [128.89.255.115] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Md4nE-0000Bd-Fh for xcon@ietf.org; Mon, 17 Aug 2009 12:10:45 -0400 Message-ID: <4A898F16.2040303@bbn.com> Date: Mon, 17 Aug 2009 13:10:46 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [XCON] Review of draft-ietf-xcon-ccmp-03 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 17:10:59 -0000 Hi all, In my effort to get up to speed on XCON, I'm in the process of reviewing the active working group drafts (in addition to the other relevant background). My review of draft-ietf-xcon-ccmp-03 is below. --Richard ----- Draft: draft-ietf-xcon-common-data-model-13 Reviewer: Richard Barnes Review Date: 18 Aug 09 General comments: 1. The protocol seems pretty well thought out. Most of the below comments are focused on clarity, but there are also a couple of technical issues to be addressed. 2. It seems like this document and the data model should both use the same specification language, either XSD or RelaxNG, to facilitate parsing/validation. 3. The document uses a mixture of single (') and double (") quotes around things like element names. Might be nice to standardize on one or the other. Specific comments: Abstract The abstract says that CCMP is stateless, but that seems a little weird given that the whole point of the protocol is to modify the state of the conference server. I understand the intent (the protocol itself is stateless), but you might think about rewording. Section 4/5 These two sections could probably stand to be merged. I think it would be helpful to have the content of Section 5 (especially Figure 1) before most of Section 4, except maybe the first paragraph. Section 5 Make sure that the label for Figure 1 stays with the figure. Section 6 This section seems to be a little confused about what its purpose is. The stated purpose is to give an overview of the conference and user objects, but it has several tangential comments about how these objects are handled in certain cases. Think about tightening the scope (see below). Section 6.1, Paragraph 1 It might be helpful to provide a reference to Section 7.1 (Cloning Tree) of RFC 5239 here. Section 6.1, Paragraph 2, "A client MAY specify a parent element..." The phrase "parent element" is a little confusing here, since we're talking about XML objects, and the "parent" relationship is not in terms of XML elements, but rather objects in the cloning tree. Suggest changing this sentence to "A client MAY specify a parent object (a conference or blueprint) from which to inherit values." Section 6.1, Paragraph 2, "When creating conferences..." This sentence seems like it belongs in Section 7.2.3.4 instead of here. Section 6.2, Paragraph 1, "Users are inherited as well..." For clarity, suggest adding "When a conference is cloned from a parent object..." Section 6.2, Paragraph 3 This paragraph seems like it belongs elsewhere, e.g., in Section 7.2.3.4 or 7.2.3.6. Section 7.2 It took me a little while to figure out why all the messages in the example are doubled up: "..." It would be helpful here to explain the general design methodology being followed that leads to that. As I understand it, the idea is that you can carry multiple request and response messages within a single request or response. This idea would be helpful to note, as well as some idea of how request and response messages are correlated. Also, since you define elements for the detailed messages types, it would be clearer to use those types in the examples (in Section 8), rather than casting with xsi:type. Section 7.2.1, confUserId, "This attribute is required ..." Should there be RFC 2119 requirement here? "This attribute is REQUIRED..." Section 7.2.1, password I'm confused about how this parameter interacts with the element in the data model: In the data model, conference passwords are only scoped within a given , whereas a password for a CCMP request would presumably need to be scoped at the level of the conference. Or is the CCMP password an independent value not reflected in the conference object? Section 7.2.1, Figure 2 It was helpful to have this structure here. It would be even better if a brief example could be provided as well. Likewise for other sections below. Section 7.2.2.1 It's a little confusing to have the error messages introduced at this point in the document, since the actions themselves haven't been defined. Perhaps Table 2 (probably with the introductory text to Section 7.2.3) could be moved up to Section 7.2.1 to give a clearer idea of what the operations do. Section 7.2.3, Paragraph 3 (counting the bulleted list as 1 para) You need a different symbol than "N/A*" here, since * is also used with a different meaning in the table. Section 7.2.3.3, Paragraph 3 The first sentence seems odd -- it's not clear in general that it another blueprint would be useful to the conference client, so why would it be RECOMMENDED to try another? Suggest changing to the following: "If a response code fo "objectNotFound" is received in a 'blueprintResponse' message, a conference control client may attempt to retrieve another conference blueprint if more than one had been received in the "blueprintsResponse" message." Section 7.2.3.4, Paragraph 6 (counting 2 bullets as 1 para) The following phrase is confusing: " The 'confInfo' represents an object of type "conference-type" containing all the changes to be applied... " "Conference-type" object, i.e., conference objects, represent conference state, not changes. I see in the example (Section 8) that the intent is to allow clients to send only a fragment of the conference object, rather than the whole thing. There should be more discussion here about how the client constructs the right fragment to express his changes, and how the server interprets the fragment it gets. Section 7.2.3.5-10 Since users and sidebars are both sub-elements of the conferene object, what's the rationale for handling them via separate CCMP requests? Is the idea that it simplifies permissions management for the server (in the case where some users are only allowed to access users/sidebars), since the server doesn't have to look at what's in the changes to check permissions? Section 7.2.3.5-10 Also, it seems like these messages should follow the pattern of the blueprint[s] and conf[s] messages above: The plural messages should be retreive-only, while the singular messages should allow other operations. Section 7.2.3.5-6 How do these CCMP operations interact with the signaling protocols? Presumably when a user joins via a CSP, he is added to the conference object; is this equivalent to a userRequest/create operation? Section 7.2.3.5, Paragraph 2 s/userInfo/usersInfo/ Section 7.2.3.5, Bullet 1 (retreive) Change SHOULD NOT to MUST NOT, since it is ignored anyway. Section 7.2.3.5, Bullet 2 (update) Same concern here as with 7.2.3.4 above -- how do you represent changes with a users-type object? Section 7.2.3.6, Paragraph 1, "Note that a user..." This sentence seems like a non-sequitur: If a client is not XCON-aware, then it's not going to generate these messages. Recommend saying instead that some CSP operations might have the same effect as these operations, i.e., that when a user joins/leaves/etc, the conference server might perform an action that would otherwise be performed via a userRequest. Section 7.2.3.6, 'update' paragraph Same concern here as with 7.2.3.4 above -- how do you represent changes with a user-type object? Section 7.2.3.8, 'update' paragraph Same concern here as with 7.2.3.4 above -- how do you represent changes with a conference-type object? Section 7.2.3.10, 'update' paragraph Same concern here as with 7.2.3.4 above -- how do you represent changes with a conference-type object? Section 9 Is this the process for dereferencing an XCON-URI? If so, you should say so. Section 11, Paragraph 3 The second sentence here ("Because the conferencing client...") doesn't make sense. The reason you're not requiring HTTP authentication and cookies is that CCMP has its own authentication. Suggest replacing with " A conferencing client that conforms to this specification is not required to support HTTP authentication [RFC2617] or cookies [RFC2965]. These mechanisms are unnecessary because CCMP requests carry their own authentication information (in the 'confUserId' and 'password' fields; see Section 7.2.1). " Section 11, Paragraphs 4 and 7 Change first sentence to "CCMP requests MUST be carried in the body of an HTTP POST request. If a CCMP server receives an HTTP request using a method other than POST, it must respond with an error message, e.g., 404 (not found)." In light of this change, paragraph 7 could be deleted. On the other hand, it seems like it wouldn't be unreasonable for the server to respond to a HEAD request. In which case: "CCMP requests MUST be carried in the body of an HTTP POST request. A CCMP server MAY respond to HEAD requests. If a CCMP server receives an HTTP request using a method other than POST or HEAD, it must respond with an error message, e.g., 404 (not found)." Section 12 The security considerations here are relatively comprehensive, but a little scatter-shot. I will provide a more thorough review of this section later. Section 14.4.1-2 I'm guessing you mean to register "Conference Server" tags rather than "Location Server" tags, and for CCMP rather than HELD.