From espeberg@cisco.com Mon Jun 3 11:57:47 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F22021E804B for ; Mon, 3 Jun 2013 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvLt-Jx3lxOW for ; Mon, 3 Jun 2013 11:57:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 21C4611E80DF for ; Mon, 3 Jun 2013 11:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2955; q=dns/txt; s=iport; t=1370285609; x=1371495209; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=W8OdA/br3cEvDCgyJB0nTRZVZvMHdBgBWjoPoT4aw4E=; b=bsfe7SVTuSIFit1L/2Ak5h8yAPz715TFPjNi8k4st5dPqFh627wSjokf DIlJJV9WPxi/rhFDmGjHBOy3XDJnLacvKqUKU9C7ZiGhMFZxXKwcdAFkf WKjDoLXruHIVn+2HMGAb6sCE4p41UsVrlfeUKHcBNCBolNhobLKsoKSOl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJTjrFGtJV2c/2dsb2JhbABZgwkwvweBBhZ0giMBAQEDAQEBATc0EAcEAgEIEQMBAQELFAkHJwsUCQgCBAESCId/Bgy8PI52OAaCcWEDmGeQF4MPgic X-IronPort-AV: E=Sophos;i="4.87,794,1363132800"; d="scan'208";a="218175057" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 03 Jun 2013 18:53:28 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53IrSqG024930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 18:53:28 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.81]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 13:53:28 -0500 From: "Espen Berger (espeberg)" To: Christer Holmberg , Mary Barnes , CLUE Thread-Topic: [clue] Fwd: [rtcweb] No Plan Thread-Index: AQHOXJ6uFw5HAhykjkOYpdoEAXMeLpkc276AgADLv4CABrS2gA== Date: Mon, 3 Jun 2013 18:53:27 +0000 Message-ID: References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D10F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37D10F@ESESSMB209.ericsson.se> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.202.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Fwd: [rtcweb] No Plan X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:57:47 -0000 >> That goes against the CLUE signaling proposals we've been discussing. I think we should revisit the existing CLUE proposals to be more in line wi= th the latest discussions in MMUSIC. At the time when we discussed this, it= was not obvious which direction the MMUSIC group will take and we have lea= rned a lot internally in the CLUE team as well.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: 30. mai 2013 09:23 To: Mary Barnes; CLUE Subject: Re: [clue] Fwd: [rtcweb] No Plan Hi Mary, > As chair, I strongly encourage folks to review this proposal and=20 > comment on the RTCWEB mailing list (while I personally think the discussi= on should be on the MMUSIC mailing list, it seems impossible to get RTCWEB = folks to do that consistently). I've managed to move the BUNDLE discussions to the MMUSIC list ;) > Individually, I really like this approach of minimizing dependency and in= teractions with SDP O/A and leaving the more complex signaling to the appli= cations (e.g., CLUE). I have nothing against trying to minimize SDP O/A transactions. But, from a= CLUE perspective please note the following statement in the draft: "For the sake of interoperability this specification strongly advises against the use of multiple m=3D lines for a single media type." That goes against the CLUE signaling proposals we've been discussing. Regards, Christer ---------- Forwarded message ---------- From: Emil Ivov Date: Wed, May 29, 2013 at 1:59 PM Subject: [rtcweb] No Plan To: rtcweb@ietf.org Hey all, Based on many of the discussions that we've had here, as well as many other= s that we've had offlist, it seemed like a good idea to investigate a negot= iation alternative that relies on SDP and Offer/Answer just a little bit le= ss. The following "no plan" draft attempts to present one such approach: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan The draft relies on conventional use of SDP O/A but leaves the intricacies = of multi-source scenarios to application-specific signalling, with potentia= lly a little help from RTP. Hopefully, proponents of Plans A and B would find that the interoperability= requirements that concerned them can still be met with "no plan". Of cours= e they would have to be addressed by application-specific signalling and/or= signalling gateways. Comments are welcome! Cheers, Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Mon Jun 3 14:16:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7873821E809D for ; Mon, 3 Jun 2013 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 506UDCiMqdgE for ; Mon, 3 Jun 2013 14:16:49 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60321F86D3 for ; Mon, 3 Jun 2013 14:11:38 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j11so2131357qag.16 for ; Mon, 03 Jun 2013 14:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=3a53dL2ulJReRrXO8429nUFrr6FvpDiBjACHJ2MVbUo=; b=j+/QMAiozaVduD8pX/izWLDWmF772nCXPwlDWeliBTDPWu07dpTuxa3kHUBlhP33Tu RIpRbuX5V6ju/KBOqkymmT4mdExf5je6d4H6O70ngllFmjwEfBD3cNAXWbywE9RTjEM7 KrwIbDqWP59jeZ9dtEa+t/sV0uNjkUgGSp0g8jNSsVJ3qfk7XQHxtmkzSTkrKftLAwji ZVRvOOIovYn1ngLKxfJDDSV5VlzYhRCwPP/Wy0KzLEG6R+VRdbHc2UIKOekmNJB0jumt qhtaALt53WdYY4BgxwbfDoXkDbPUuz7KdBk3Tk6lXwesHLjElh8AP9WvzS8r6AiHf6WV 1+cw== MIME-Version: 1.0 X-Received: by 10.224.38.133 with SMTP id b5mr20722203qae.78.1370293897806; Mon, 03 Jun 2013 14:11:37 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Mon, 3 Jun 2013 14:11:37 -0700 (PDT) Date: Mon, 3 Jun 2013 16:11:37 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Meeting invitation: CLUE Virtual Interim Meeting - June 25, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:16:59 -0000 Hi all, Based on the doodle poll, the CLUE WG Virtual Interim has been scheduled for Tuesday, June 25th starting at 8am Central with the Webex info and iCal link below. Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Mon, Jun 3, 2013 at 4:03 PM Subject: Meeting invitation: CLUE Virtual Interim Meeting To: mary.ietf.barnes@gmail.com Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE Virtual Interim Meeting Date: Tuesday, June 25, 2013 Time: 8:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 640 347 515 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=225537567&UID=1567027807&PW=NZjZjYTI2N2Fi&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=225537567&UID=1567027807&PW=NZjZjYTI2N2Fi&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 347 515 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=225537567&UID=1567027807&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAuF4nP-ZL7/VJefrr32WvlL0YXVPRXzr8cnlsh9KJHWV&RT=MiM3 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640347515# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation From iesg-secretary@ietf.org Tue Jun 4 11:20:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F4421F9B83; Tue, 4 Jun 2013 11:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk2jx3FFAA+S; Tue, 4 Jun 2013 11:20:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5A21E80F3; Tue, 4 Jun 2013 10:40:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130604174020.29459.31000.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 10:40:20 -0700 Cc: clue@ietf.org Subject: [clue] CLUE WG Virtual Interim Meeting, June 25, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:20:27 -0000 The CLUE WG will hold an Interim meeting on: June 25, 2013, 13.00-15.00 GMT (starting at 6.00 Pacific, 8.00 Central, 9.00 Eastern) Webex details and the preliminary agenda are available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki From pkyzivat@alum.mit.edu Wed Jun 5 08:44:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC4D21F9AF8 for ; Wed, 5 Jun 2013 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB65Nfu12BPP for ; Wed, 5 Jun 2013 08:44:31 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDA121F9B1A for ; Wed, 5 Jun 2013 08:44:23 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta12.westchester.pa.mail.comcast.net with comcast id kaEs1l0031GhbT85CfkPLU; Wed, 05 Jun 2013 15:44:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id kfkN1l01g3ZTu2S3TfkPH6; Wed, 05 Jun 2013 15:44:23 +0000 Message-ID: <51AF5CD6.9040800@alum.mit.edu> Date: Wed, 05 Jun 2013 11:44:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D10F@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370447063; bh=6wyvnuUTRzIrpApbf7Wh9yU2MUUivNByGtGImHuW/eY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QCSohTRVcXLpryxA9scHlwgDToWxHvdByVzlt05JQVLUFGRoa9j4ZIS45zml/l5mB PxbQCLXDpw3oq89tJ0JXiiTG2W+kSc8CXtHOWJEL36QGcT2GArbTjlM0ss/vCS937D QTTNMFsLc9RodsLa2Bx405IhTyMPs3csFbOKdmgI+2fk3dddl4EQi6uC1rcijmtgHy 7T2ie+TiYUSfBPCG9l5OKnu5Z286j7Q+9Je4swJLdTuoWEWK2N5ls4NTG/3QkX10is 5b9YihaCCcE0mjOmAjVqMRs07HqxFaGPPAgpJpVfAwKeISxInsJSJxadEkmnxYPx4L +qipWZIxZlqkg== Subject: Re: [clue] Fwd: [rtcweb] No Plan X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:44:35 -0000 On 6/3/13 2:53 PM, Espen Berger (espeberg) wrote: >>> That goes against the CLUE signaling proposals we've been discussing. > > I think we should revisit the existing CLUE proposals to be more in line with the latest discussions in MMUSIC. At the time when we discussed this, it was not obvious which direction the MMUSIC group will take and we have learned a lot internally in the CLUE team as well. We definitely will need to revisit to align with bundle. But we still don't know where that will end up, so IMO its premature to do so. I'm certainly following that discussion closely. In the meantime I think our decision to assume no bundling and a single encoding per m-line can allow us to proceed. IMO the main impact on what we are doing is the proposal to put the entire description of encodings into SDP rather than in the advertisement. Depending on the outcome of the bundle discussions we may need to change that. But doing so shouldn't be that big a deal. Thanks, Paul > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 30. mai 2013 09:23 > To: Mary Barnes; CLUE > Subject: Re: [clue] Fwd: [rtcweb] No Plan > > Hi Mary, > >> As chair, I strongly encourage folks to review this proposal and >> comment on the RTCWEB mailing list (while I personally think the discussion should be on the MMUSIC mailing list, it seems impossible to get RTCWEB folks to do that consistently). > > I've managed to move the BUNDLE discussions to the MMUSIC list ;) > >> Individually, I really like this approach of minimizing dependency and interactions with SDP O/A and leaving the more complex signaling to the applications (e.g., CLUE). > > I have nothing against trying to minimize SDP O/A transactions. But, from a CLUE perspective please note the following statement in the draft: > > "For the sake of interoperability this specification strongly advises > against the use of multiple m= lines for a single media type." > > That goes against the CLUE signaling proposals we've been discussing. > > Regards, > > Christer > > > > ---------- Forwarded message ---------- > From: Emil Ivov > Date: Wed, May 29, 2013 at 1:59 PM > Subject: [rtcweb] No Plan > To: rtcweb@ietf.org > > > Hey all, > > Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways. > > Comments are welcome! > > Cheers, > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Jun 5 09:20:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC60821F9B5F for ; Wed, 5 Jun 2013 09:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhkgQ1VzEPF1 for ; Wed, 5 Jun 2013 09:20:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC2B921F9B40 for ; Wed, 5 Jun 2013 09:20:23 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-1e-51af65454b49 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B3.D9.15700.5456FA15; Wed, 5 Jun 2013 18:20:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 18:20:21 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Fwd: [rtcweb] No Plan Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkcZmaAgADrufCABupfgIAC79YAgAAqn6A= Date: Wed, 5 Jun 2013 16:20:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3836D3@ESESSMB209.ericsson.se> References: <51A65017.4090502@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C37D10F@ESESSMB209.ericsson.se> <51AF5CD6.9040800@alum.mit.edu> In-Reply-To: <51AF5CD6.9040800@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvra5r6vpAg98rtS32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj2t+NTAUfFCuOLV3F1sC4R7qLkZNDQsBE 4tHWGewQtpjEhXvr2boYuTiEBA4zSsx4uZwdwlnMKLHn3R2mLkYODjYBC4nuf9ogDSICnhI7 Pk5hBrGFBTQl1l6+zAoR15JYfPEbE4TtJ9HUdoARxGYRUJH4++MNWD2vgK/EmePLWSDmz2CS +Hd1JlgRp4COxPMte8AuYgS66PupNWCDmAXEJT4cvM4McamAxJI956FsUYmXj/+xQthKEo1L nrBC1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25iZk56 ueEmRmA0HNzyW3cH46lzIocYpTlYlMR59XgXBwoJpCeWpGanphakFsUXleakFh9iZOLglGpg 1L4yjdvn205nnQnyBtmtG2b9OrbsrmTzXrH82J6Xsc/ZU52/s6pZaNs92l88ucdoNfMDUduH pzNcNm9gLm7/K1eSwufg5Kbv5L8nr8iXcdY7ZYnbzOkzMtn6jm4zsm5z+372moXOFTOmQ/dt 3pc2cTpdnb7urhhTU5xQpePeuJiTDGyaiTeUWIozEg21mIuKEwGqzzAAVAIAAA== Subject: Re: [clue] Fwd: [rtcweb] No Plan X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:20:35 -0000 Hi, >>>> That goes against the CLUE signaling proposals we've been discussing. >> >> I think we should revisit the existing CLUE proposals to be more in line= with the latest discussions in MMUSIC. At the time when we discussed this,= it was not obvious which direction the MMUSIC group will take and we have = learned a lot internally in the CLUE team as well. > > We definitely will need to revisit to align with bundle. > But we still don't know where that will end up, so IMO its premature to d= o so. I'm certainly following that discussion closely. > > In the meantime I think our decision to assume no bundling and a single e= ncoding per m-line can allow us to proceed. I agree. In addition, I haven't seen anything in our current assumptions that would = prevent usage of BUNDLE, if someone wants to. > IMO the main impact on what we are doing is the proposal to put the entir= e description of encodings into SDP rather than in the advertisement. Depen= ding on the outcome of the bundle discussions we may need to change that. B= ut doing so shouldn't be that big a deal. Let's also keep in mind that RTCWEB is NOT defining what is sent on the wir= e. WHATEVER CLUE defines, it can be sent to a JS APP. The question is when = whether the JS APP can "map" that into proper API language towards the brow= ser. Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Christer Holmberg > Sent: 30. mai 2013 09:23 > To: Mary Barnes; CLUE > Subject: Re: [clue] Fwd: [rtcweb] No Plan > > Hi Mary, > >> As chair, I strongly encourage folks to review this proposal and=20 >> comment on the RTCWEB mailing list (while I personally think the discuss= ion should be on the MMUSIC mailing list, it seems impossible to get RTCWEB= folks to do that consistently). > > I've managed to move the BUNDLE discussions to the MMUSIC list ;) > >> Individually, I really like this approach of minimizing dependency and i= nteractions with SDP O/A and leaving the more complex signaling to the appl= ications (e.g., CLUE). > > I have nothing against trying to minimize SDP O/A transactions. But, from= a CLUE perspective please note the following statement in the draft: > > "For the sake of interoperability this specification strongly advises > against the use of multiple m=3D lines for a single media type." > > That goes against the CLUE signaling proposals we've been discussing. > > Regards, > > Christer > > > > ---------- Forwarded message ---------- > From: Emil Ivov > Date: Wed, May 29, 2013 at 1:59 PM > Subject: [rtcweb] No Plan > To: rtcweb@ietf.org > > > Hey all, > > Based on many of the discussions that we've had here, as well as many oth= ers that we've had offlist, it seemed like a good idea to investigate a neg= otiation alternative that relies on SDP and Offer/Answer just a little bit = less. > > The following "no plan" draft attempts to present one such approach: > > http://tools.ietf.org/html/draft-ivov-rtcweb-noplan > > The draft relies on conventional use of SDP O/A but leaves the intricacie= s of multi-source scenarios to application-specific signalling, with potent= ially a little help from RTP. > > Hopefully, proponents of Plans A and B would find that the interoperabili= ty requirements that concerned them can still be met with "no plan". Of cou= rse they would have to be addressed by application-specific signalling and/= or signalling gateways. > > Comments are welcome! > > Cheers, > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Jun 6 04:17:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F821F994F for ; Thu, 6 Jun 2013 04:17: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtjNqgMWXc+d for ; Thu, 6 Jun 2013 04:17:53 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 5261A21F9951 for ; Thu, 6 Jun 2013 04:17:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAOFusFF20fMs/2dsb2JhbAANTIM5v0OBDYMXAQEBAwEBAQEkERsbChELGAkMCg8JAwIBAgEVMBMGAgEBiAMSqSuSLQSPMgqDUQOsIA Received: from ppp118-209-243-44.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.243.44]) by ipmail04.adl6.internode.on.net with ESMTP; 06 Jun 2013 20:47:51 +0930 Message-ID: <51B06FD7.6000804@nteczone.com> Date: Thu, 06 Jun 2013 21:17:43 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <519C3316.7020707@nteczone.com> <519CDB89.5020104@alum.mit.edu> In-Reply-To: <519CDB89.5020104@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Label attribute for CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:17:54 -0000 Hello Paul, I'm not saying the use of label is not possible, I just don't think it's ideal. Please see my replies below. Regards, Christian On 23/05/2013 12:51 AM, Paul Kyzivat wrote: > On 5/21/13 10:53 PM, Christian Groves wrote: >> Hello >> >> We discussed in yesterday's virtual interim meeting about the use of the >> a=label: in the signalling flows. >> >> My concern is with regards to the scope of the label attribute. Section >> 4/RFC4574 says "The new attribute can be attached to 'm' lines in >> multiple SDP documents allowing the application to logically group the >> media streams across SDP sessions when necessary." >> >> Considering an MCU case my understanding is that any identities used in >> CLUE only have scope to a particular advertisement. i.e. the MCU can use >> the same Scene and capture ids in Advertisements to different endpoints. >> >> If label has the scope over multiple SDP sessions does this mean that >> the CLUE strings used with label would have to be unique across all SDP >> sessions in a MCU or gateway? > > I think you are reaching to far! > > I don't know why that statement is in the RFC. It appears to be an > example of how it might be used. But I see nothing normative about > that statement regarding the scope of the label value. [CNG] I don't know its there either but its there so it must have a purpose. > > My interpretation is that an application that participates in multiple > SDP sessions could use the same label values in the SDP it generates > for those sessions. The uniqueness of the values across multiple SDP > documents, whether describing one or several sessions, is determined > by the application. [CNG] The "application"... what if there are multiple applications? ie. you happily implemented BFCP which allocates it own labels without care. Then you add CLUE which uses the same label space... your BFCP stack needs to be updated to account for CLUE labels etc... > >> Also RFC4796 section 3 on the Content Attribute indicates that a new >> attribute was required because of a problem of backward compatibility. >> Would this apply to a clue attribute also? For example if the endpoint >> uses BFCP which uses label it would have to make sure labels for CLUE >> didn't overlap. Also existing BFCP processing would just see a label >> string. It wouldn't know that a=label:CLUE1 is not to be considered. > > As I read 4796, the backward compatibility issue would have arisen if > some *dedicated* label values were identified for the purpose. > > The same would be true if clue tried to specify dedicated label > values. That is why I was objecting to rob's proposal that the label > prefix of "clue." be used to signal that the m-line is "clue > controlled". Jonathan agreed with me on that. I think we agreed that > if we need to signal that m-lines are clue controlled we will need > something new in SDP. But that doesn't affect using labels as the > means for referencing m-lines from the clue signaling. (Those labels > will be assigned by the application.) > > Thanks, > Paul > >> For CLUE I think we need to look at defining a specific SDP attribute >> for this m-line -> encoding mapping. >> >> Regards, Christian >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Jun 13 14:27:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6B221F881F for ; Thu, 13 Jun 2013 14:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XFMAveFH3QI for ; Thu, 13 Jun 2013 14:27:01 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id A15BE21F99B4 for ; Thu, 13 Jun 2013 14:27:00 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id nnXq1l0020SCNGk59xSzZm; Thu, 13 Jun 2013 21:26:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id nxSz1l00i3ZTu2S3VxSz98; Thu, 13 Jun 2013 21:26:59 +0000 Message-ID: <51BA3922.9040506@alum.mit.edu> Date: Thu, 13 Jun 2013 17:26:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: CLUE References: <20130613212245.8835.79830.idtracker@ietfa.amsl.com> In-Reply-To: <20130613212245.8835.79830.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130613212245.8835.79830.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371158819; bh=G0k99s6Xy6EO4dpg6J45oPVQ44hiGRiMFApwi30F6g0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=itljDb7e2QKXRjanichyMRKDPCaN7rggmJyhBwa6k7Lde1sRw+3aGPxGvqin4Lg26 a+xumKwEMKBizgINpxES2dmgDXeMgWvKifhHlZUO3f8pXUA9svbXyxhOcNxBn8zcak DEqLjxWBrU4hHOYaHgvsqpvA6t3GF96odcWin1hPNyvZvrSeWp+a+I0Kz9/O6vHYCE TYwXkoN9EFO1bG6XukCVUPV9j+s2shuxBwmVuUYbmc3VBCjvKWeKkMzjBCAdgxFYCg uSGspIy3KyAJyRSNuJPIkxba3Szb++xn5JuRLwm7sk0F1MGNxOcqVuD00SVwgIAQRa OdcfBByr5oJEA== Subject: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:27:06 -0000 I just posted a new version of the signaling draft. Here are changes (from the change log): * Added a syntax section with an XML schema for CLUE messages. This is a strawhorse, and is very incomplete, but it establishes a template for doing this based on elements defined in the data model. (Thanks to Roberta for help with this!) * Did some rewording to fit the syntax section in and reference it. * Did some relatively minor restructuring of the document to make it flow better in a logical way. The prior versions have received little comment. PLEASE, PLEASE review this and comment!!! There are many open issues in this looking for comments or preferably proposed text. Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-clue-signaling-03.txt Date: Thu, 13 Jun 2013 14:22:45 -0700 From: internet-drafts@ietf.org To: Christian Groves , Lennard Xiao , Paul Kyzivat , Christian Groves A new version of I-D, draft-kyzivat-clue-signaling-03.txt has been successfully submitted by Paul Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-clue-signaling Revision: 03 Title: CLUE Signaling Creation date: 2013-06-13 Group: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-03.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-03 Abstract: This document specifies how signaling is conducted in the course of CLUE sessions. This includes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol that complements SIP/SDP and supports negotiation of CLUE application level data. The IETF Secretariat From Mark.Duckworth@polycom.com Fri Jun 14 07:35:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A2021F9A85 for ; Fri, 14 Jun 2013 07:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGfkqrE9VYZd for ; Fri, 14 Jun 2013 07:35:28 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88821F9CB7 for ; Fri, 14 Jun 2013 07:35:28 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 14 Jun 2013 07:35:27 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 14 Jun 2013 07:35:25 -0700 Thread-Topic: comments on description of RTP topologies Thread-Index: Ac5pBpyrxLMMPtycTZe47c4dFhAReQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60146DF92@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D60146DF92CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] comments on description of RTP topologies X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:35:33 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60146DF92CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is regarding section 3. RTP topologies for CLUE, in draft-ietf-clue-rt= p-mapping-00. I'm having difficulty relating the topologies described here to the termino= logy described in draft-ietf-avtcore-rtp-topologies-update-00. There doesn= 't seem to be a clean mapping, so I'd like to clarify this and make it clea= ner, using the same terminology. >From the beginning of section 3: "For telepresence, the relevant topologies include point-to-point, as well = as media mixers, media- switching mixers, and source-projection mixers." So for these four categories, I would like to understand how they map to th= e topologies described in draft-ietf-avtcore-rtp-topologies-update. The fo= llowing list describes how I think the two documents relate. Do I understa= nd this correctly? Can we make this more explicit in the CLUE document, to= list the CLUE topologies directly using terminology from the rtp-topologie= s-update document, so we don't have to map it to a new set of CLUE terminol= ogy? 1. point-to-point. This includes: a. Topo-Point-to-Point b. Topo-PtP-Translator - not sure if this is meant to be included or n= ot? c. Back to back RTP sessions - not sure if this is meant to be includ= ed or not? 2. media mixers. This includes: a. Topo-RTCP-terminating-MCU b. Topo-Mixer, Media Mixing variety (3.6.1 of rtp-topologies-update) 3. media switching mixers. This includes: a. Topo-Mixer, Media Switching variety (3.6.2 of rtp-topologies-updat= e) 4. source projection mixers. This includes: a. Source Projecting Middlebox (3.7 of rtp-topologies-update) We should also add De-composite Endpoint (3.10 of rtp-topologies-update), a= s we agreed in the June 2012 interim meeting. I believe we also agreed CLUE is not attempting to support Topo-Video-switc= h-MCU, so I suggest we remove reference to this one. The document refers t= o this as if CLUE supports it, which I think is not the case. I have a related question in avtcore, asking if source projection is intend= ed to be a variety of Topo-Mixer. Mark Duckworth --_000_49E45C59CA48264997FEBFB29B6BC2D60146DF92CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is regardin= g section 3. RTP topologies for CLUE, in draft-ietf-clue-rtp-mapping-00.

 

= I’m having difficulty relating the topologies described here to the t= erminology described in draft-ietf-avtcore-rtp-topologies-update-00.  = There doesn’t seem to be a clean mapping, so I’d like to clarif= y this and make it cleaner, using the same terminology.

 

From the beginnin= g of section 3:

“For telepresence, the relevant topologies include point-to-point,= as well as media mixers, media- switching mixers, and source-projection mi= xers.”

 

So for these four categories, I would like to understand how= they map to the topologies described in draft-ietf-avtcore-rtp-topologies-= update.  The following list describes how I think the two documents re= late.  Do I understand this correctly?  Can we make this more exp= licit in the CLUE document, to list the CLUE topologies directly using term= inology from the rtp-topologies-update document, so we don’t have to = map it to a new set of CLUE terminology?

 

1.   &nbs= p;   point-to-point.  This includes:=

a.  = ;     Topo-Point-to-Point<= /o:p>

b.   = ;   Topo-PtP-Translator – not sure = if this is meant to be included or not?

c.       Back to back RTP sessions – not sure if this is meant t= o be included or not?

2. &= nbsp;     media mixers.  T= his includes:

a.b.3.       media switching mixers.  This includes:

a.       <= /span>Topo-Mixer, Media Switching variety (3.6.2 of rtp-to= pologies-update)

4.  &= nbsp;    source projection mixers. T= his includes:

a.

FYI,=

 

Christer

 

Ps. If = you have comments on the draft, please present them on the MMUSIC list.

&n= bsp;

L=E4hett=E4j= =E4: mmusic-bounces@ietf.org= [mailto:mmusic-bounces@ietf.org] Puolesta Christer Holmberg
L=E4hetetty: 15. kes=E4kuuta 2013 0:19
Vastaanottaja: mmusic@ietf.org
Aihe: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negot= iation-04

 

Dear Bundle Fans,

 

I’ve submitted a new vers= ion (-04) of BUNDLE.

 

Compared with the previous vers= ion, there are some rather big editorial changes, especially in the SDP Off= er/Answer sections, mostly based on the mail discussions.=

 

I have not touched the “I= CE Usage” section at all. That is one of the next things we need to d= eal with.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_-- --_004_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Fri, 14 Jun 2013 21:18:52 GMT"; modification-date="Fri, 14 Jun 2013 21:18:52 GMT" Content-ID: <5A5801A961235E42B1408D42B6472534@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7594FB04B1934943A5C02806D1A2204B1C38B30CESESSMB209erics_-- From Mark.Duckworth@polycom.com Fri Jun 14 16:04:44 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9993921F8F9E for ; Fri, 14 Jun 2013 16:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC7nF+dHMArB for ; Fri, 14 Jun 2013 16:04:40 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5453821F8F15 for ; Fri, 14 Jun 2013 16:04:40 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 14 Jun 2013 16:04:39 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 14 Jun 2013 16:04:38 -0700 Thread-Topic: New Version Notification for draft-duckworth-clue-switching-example-00.txt Thread-Index: Ac5pU0Lo8Dunj9FiRWOT2edb6CZAQg== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60146E2B3@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [clue] FW: New Version Notification for draft-duckworth-clue-switching-example-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 23:04:45 -0000 SSBzdGFydGVkIHRoaXMgZHJhZnQgYWJvdXQgdXNpbmcgQ0xVRSB3aXRoIHRoZSBtZWRpYSBzd2l0 Y2hpbmcgdG9wb2xvZ3kuICBUaGUgaW50ZW50IG9mIHRoaXMgZmlyc3QgZHJhZnQgaXMgdG8gcHJv dmlkZSBhIGJhc2lzIGZvciBkaXNjdXNzaW9uIGFib3V0IGhvdyBDTFVFIHdvcmtzIGluIHRoaXMg dG9wb2xvZ3ksIGFuZCB3aGF0IG1pZ2h0IGJlIG1pc3NpbmcgZnJvbSBDTFVFIHRoYXQgbmVlZHMg dG8gYmUgYWRkZWQgdG8gbWFrZSBpdCB3b3JrLg0KDQpNYXJrIER1Y2t3b3J0aA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgSnVuZSAxNCwgMjAx MyA2OjU3IFBNDQpUbzogRHVja3dvcnRoLCBNYXJrDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWR1Y2t3b3J0aC1jbHVlLXN3aXRjaGluZy1leGFtcGxlLTAwLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kdWNrd29ydGgtY2x1ZS1zd2l0Y2hp bmctZXhhbXBsZS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFy ayBEdWNrd29ydGggYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFt ZToJIGRyYWZ0LWR1Y2t3b3J0aC1jbHVlLXN3aXRjaGluZy1leGFtcGxlDQpSZXZpc2lvbjoJIDAw DQpUaXRsZToJCSBDTFVFIFN3aXRjaGluZyBNaXhlciBFeGFtcGxlDQpDcmVhdGlvbiBkYXRlOgkg MjAxMy0wNi0xNA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFn ZXM6IDgNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtZHVja3dvcnRoLWNsdWUtc3dpdGNoaW5nLWV4YW1wbGUtMDAudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVja3dvcnRo LWNsdWUtc3dpdGNoaW5nLWV4YW1wbGUNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZHVja3dvcnRoLWNsdWUtc3dpdGNoaW5nLWV4YW1wbGUtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYW4gZXhhbXBsZSBtdWx0aXBv aW50IHVzZSBjYXNlIHNjZW5hcmlvIGZvcg0KICAgQ0xVRS4gIFRoaXMgZXhhbXBsZSB1c2VzIHRo ZSBtZWRpYSBzd2l0Y2hpbmcgdmFyaWV0eSBvZiB0aGUgVG9wby0NCiAgIE1peGVyIFJUUCB0b3Bv bG9neS4gIFRoaXMgZXhhbXBsZSBpcyBpbnRlbmRlZCB0byBwcm9tb3RlIGRpc2N1c3Npb24NCiAg IGFib3V0IGhvdyB0byBpbXBsZW1lbnQgaXQgdXNpbmcgdGhlIENMVUUgRnJhbWV3b3JrLCBhbmQg d2hldGhlciBvcg0KICAgbm90IHRoZSBmcmFtZXdvcmsgYXMgY3VycmVudGx5IGRlZmluZWQgaXMg c3VmZmljaWVudCB0byBlbmFibGUgdGhpcw0KICAgdXNlIGNhc2UuDQoNCiAgIFRoaXMgZmlyc3Qg dmVyc2lvbiBpcyBpbmNvbXBsZXRlLCBhbmQgaXMgaW50ZW5kZWQgdG8gcmFpc2UgcXVlc3Rpb25z DQogICBhbmQgcHJvbXB0IGRpc2N1c3Npb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From mary.ietf.barnes@gmail.com Thu Jun 20 10:44:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39221F9F4E; Thu, 20 Jun 2013 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgZkMQfH59G3; Thu, 20 Jun 2013 10:44:25 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 270AE21F9F5D; Thu, 20 Jun 2013 10:44:25 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so465976qae.20 for ; Thu, 20 Jun 2013 10:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=P7IX4sX1uAhu2G+vBCZNEjrkyxVGl+ZDH1k2KGmIeJw=; b=GcK71ekH2PYbS/1A7+vBcaGimudvirG3kfna3rVnasiNbEaPvYMn+6ElxlgOtkSc13 4eTYArwFpihyCdSU5VanHRDxu4ZybBo7weFx7BusD1dVV/KZCYcaqjeD3N2H0dgzuFlu EwOXkDa0lE/kzZfG5+2B6jq33xzNgDM8nd2OkHTV9Bg9v/WngmwiKmZ/fxKConmlbCeW zqr1XLgwqieoLkCQQ6c4/5FVX8BLvxlZck+QcRncWCJ5NaRktaPudTzuuRgf8CeEE+15 eSdYM8vAm3zI74U90McVJrG24wx5bBms70v/XBzCIj0KxNuyJYVsLFNWKN8T0THyKjqN +cNA== MIME-Version: 1.0 X-Received: by 10.224.72.203 with SMTP id n11mr10212822qaj.13.1371750264650; Thu, 20 Jun 2013 10:44:24 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Thu, 20 Jun 2013 10:44:24 -0700 (PDT) In-Reply-To: <20130619221422.22392.12062.idtracker@ietfa.amsl.com> References: <20130619221422.22392.12062.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2013 12:44:24 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH , CLUE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: NOMCOM 2013 - UPDATE of validated volunteers list so far X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:44:26 -0000 Thanks to the RAI folks who have volunteered! This is a great way to serve the community. [Note: I really would volunteer but I can't due to my IAB role]. The time commitment is most intense towards year end, but the role of a voting member can be fairly well managed, in particular since you have a great Nomcom chair this year! Thanks, Mary. ---------- Forwarded message ---------- From: NomCom Chair 2013 Date: Wed, Jun 19, 2013 at 5:14 PM Subject: NOMCOM 2013 - UPDATE of validated volunteers list so far To: IETF Announcement List Cc: ietf@ietf.org Below is the current validated list of volunteers for Nomcom 2013. If your name has a *, I'm waiting for a message back from you. Big thanks to everyone who has volunteered! Now what are the rest of you waiting for? We still need quite a few to get up to 200 volunteers. Please reply and volunteer - include in the email: your First Name, Last Name, email addresses you've used in the last few years in registering for IETF meetings, preferred email address, primary affiliation, and a contact phone number for use if you're selected. Thanks, Allison Mankin Nomcom 2013 Chair 1 John Scudder 2 Stephen Hanna 3 Wassim Haddad 4 Russ White 5 Stephan Wenger 6 ZHAO Yi 7 Eric Gray 8 Steve Kent 9 Toerless Eckert 10 Alia Atlas 11 Victor Kuarsingh 12 Yizhou LI 13 Gonzalo Salgueiro 14 Gang CHEN 15 Ning KONG 16 Marcelo Bagnulo 17 SHEN Shuo =E6=B2=88=E7=83=81 (Sean) 18 Fernando Gont 19 Glen Zorn 20 Reinaldo Penno 21 Klaas Wierenga 22 Pascal Thubert 23 Mehmet Ersue 24 Ole Troan 25 Jouni Korhonen 26 Giles Heron 27 Gunter Van de Velde 28 Arturo Servin 29 Eric Vyncke 30 Cullen Jennings 31 Tina Tsou 32 Dhruv Dhody 33 Hongyu LI (Julio) 34 Scott Mansfield 35 John Drake 36 Andrew McLachlan 37 Derek Atkins 38 Suhas Nandakumar 39 Eric Rescorla 40 Karen Seo 41 Stig Venaas 42 Stan Ratliff 43 Ignas Bagdonas 44 Peter Yee 45 Donald Eastlake 46 ZHOU Qian (Cathy) 47 Sam Hartman 48 Lixia Zhang 49 Teemu Savolainen 50 Alvaro Retana 51 Terry Manderson 52 Bill VerSteeg 53 Melinda Shore 54 IJsbrand Wijnands 55 Karen O'Donoghue 56 Benson Schliesser 57 Ari Ker=C3=A4nen 58 Fangwei HU 59 Mach CHEN 60 Hui Deng 61 LIU Dapeng 62 Jaap Akkerhuis 63 Magnus Westerlund 64 Zehn CAO 65 Zaheduzzaman Sarker 66 Bhumip Khasnabish 67 Andrew Chi 68 Thomas Nadeau 69 Steven C (Craig) Whilte 70 Orit Levin 71 Sam Aldrin 72 Paul Ebersman 73 Christopher Liljenstolpe 74 Uma Chunduri 75 Suresh Krishnan 76 Varun Singh 77 Ron Bonica 78 Bill (William) Manning 79 Radia Perlman 80 Daniele Ceccarelli 81 Deborah Brungard 82 Kostas Pentikousis 83 Gregory Mirsky 84 Dave Sinicrope 85 Thomas Walsh 86 Zhaohui (Jeffrey) ZHANG 87 Xian ZHANG 88 Mark Townsley 89 Hannes Gredler 90 Brian Trammell 91 Carlos Martinez 92 Peter Koch 93 Daniel Migault 94 Yi (Aaron) Ding 95 Michael Richardson 96 Sohel Khan 97 John Bradley 98 Huaimo Chen 99 Matthew Campagna 100 Keith Drage 101 Chris Bowers 102 Jakob Heitz 103 Tomofumi Okubo 104 Emil Ivov 105 Timothy B. Terriberry 106 JIANG Yuanlong 107 Luigi Iannone 108 Damien Saucez 109 Lou Berger 110 Yana Stamcheva 111 Ond=C5=99ej Sur=C3=BD 112 Marcin Pilarski 113 Michael StJohns 114 Wes George 115 Christian O'Flaherty 116 Uwe Rauschenbach 117 Olafur Gudmundsson 118 Shwetha Subray Bhandari* 119 Tobias Gondrom 120 Christer Holmberg 121 Susan Hares 122 Kiran Kumar Chittimaneni 123 Donald Fedyk 124 Stephen Botzko* 125 Li Xue* 126 John Sauer* From Christian.Groves@nteczone.com Fri Jun 21 01:25:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C383721F8956 for ; Fri, 21 Jun 2013 01:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFA+ivTh39K4 for ; Fri, 21 Jun 2013 01:25:39 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 83A8621F866E for ; Fri, 21 Jun 2013 01:25:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcBAPUMxFGQ/iyc/2dsb2JhbAANRQkOgyxDgwm8MoEVgxcBAQEEAQEBIA8BBRsbCQEBDAQLDQEDAwECAQICBRYLAgIJAwIBAgEVKAgGDQEFAgEBBYgMBaoac5E4gSaMaIE7BwaCR4EUA5hshRuNUVA Received: from unknown (HELO [127.0.0.1]) ([144.254.44.156]) by ipmail07.adl2.internode.on.net with ESMTP; 21 Jun 2013 17:55:32 +0930 Message-ID: <51C40DF2.6050604@nteczone.com> Date: Fri, 21 Jun 2013 18:25:22 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <20130613212245.8835.79830.idtracker@ietfa.amsl.com> <51BA3922.9040506@alum.mit.edu> In-Reply-To: <51BA3922.9040506@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: CLUE Subject: Re: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:25:41 -0000 Hello Paul, all, A few comments: 3.5.1 Clue Channel Lifetime --------------------------- Should we say something about heartbeat mechanisms in the case the CLUE channel stays established. Is a transport level heartbeat sufficient (probably so), or would someone like an application level heartbeat? 4.1. Encodings represented in SDP ---------------------------------- 2nd paragraph: We should probably be clear what we mean. There is the individual encoding attributes that are already defined in CLUE. Then there is the “actual media encoding” i.e. codecs et.al. Do we mean both? Or the later? From the above syntax I guess you propose only the latter which would mean having to introducing equivalent SDP to the CLUE individual encoding attributes. 3rd paragraph - 1st sentence: The encoding infromation is available for use at least by CLUE (in the next sentence it says that a consumer may use it). I guess what you’re trying to say is that media isn’t available until the ID is associated with SDP associated with media or similar? 3rd paragraph - 2st sentence: Doesn’t the label need to be defined for the consumer to configure it? It probably should say “The media associated with a capture encoding will only become active if/when a CLUE encoding identity (label) is associated which the SDP defining the encoding and the Advertiser has received a Configure message confirming the capture encoding.” 3rd paragraph - last sentence: I’m confused? Its says the consumer has insufficient information to select it? But two sentence above it says a consumer may configure an encoding that is not defined? 5.1. Independence of SDP and CLUE negotiation ---------------------------------------------- First sentence: CLUE exceeding I don’t think is a problem. How about if the CLUE Max bandwidth is less the SDP bandwidth? I’m not sure how the encodingGroup attributes apply? "make reference to SDP contents" - This is very general should we narrow this only to refer to the group/label that ties the two together? General ------- There seems to be overlap between the included text from I-D.hansen-clue-sdp-interaction and other sections in the signalling document. I'm not sure of the procedure but I think it would be good if the draft editor can make changes to the text rather than cutting and pasting. Regards, Christian PS: I might be slow with my responses as I'm travelling. On 14/06/2013 7:26 AM, Paul Kyzivat wrote: > I just posted a new version of the signaling draft. Here are changes > (from the change log): > > * Added a syntax section with an XML schema for CLUE messages. > This is a strawhorse, and is very incomplete, but it > establishes a template for doing this based on elements defined > in the data model. (Thanks to Roberta for help with this!) > > * Did some rewording to fit the syntax section in and reference > it. > > * Did some relatively minor restructuring of the document to make > it flow better in a logical way. > > The prior versions have received little comment. > PLEASE, PLEASE review this and comment!!! > There are many open issues in this looking for comments > or preferably proposed text. > > Thanks, > Paul > > > -------- Original Message -------- > Subject: New Version Notification for draft-kyzivat-clue-signaling-03.txt > Date: Thu, 13 Jun 2013 14:22:45 -0700 > From: internet-drafts@ietf.org > To: Christian Groves , Lennard Xiao > , Paul Kyzivat , > Christian Groves > > > A new version of I-D, draft-kyzivat-clue-signaling-03.txt > has been successfully submitted by Paul Kyzivat and posted to the > IETF repository. > > Filename: draft-kyzivat-clue-signaling > Revision: 03 > Title: CLUE Signaling > Creation date: 2013-06-13 > Group: Individual Submission > Number of pages: 27 > URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-03.txt > Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling > Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-03 > > Abstract: > This document specifies how signaling is conducted in the course of > CLUE sessions. This includes how SIP/SDP signaling is applied to > CLUE sessions as well as defining a CLUE-specific signaling protocol > that complements SIP/SDP and supports negotiation of CLUE application > level data. > > > > > > The IETF Secretariat > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Jun 21 10:23:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85921E811B for ; Fri, 21 Jun 2013 10:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpIH3OWTcmPH for ; Fri, 21 Jun 2013 10:23:36 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 4851521E8125 for ; Fri, 21 Jun 2013 10:23:32 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id r1Sx1l0090SCNGk565PYZE; Fri, 21 Jun 2013 17:23:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id r5PX1l0113ZTu2S3V5PXB9; Fri, 21 Jun 2013 17:23:32 +0000 Message-ID: <51C48C13.2040402@alum.mit.edu> Date: Fri, 21 Jun 2013 13:23:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christian Groves References: <20130613212245.8835.79830.idtracker@ietfa.amsl.com> <51BA3922.9040506@alum.mit.edu> <51C40DF2.6050604@nteczone.com> In-Reply-To: <51C40DF2.6050604@nteczone.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371835412; bh=WsTT0HAa5Y3jZ7nX5vyMad6DMoFlN0liaRrnjlTQZMc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lwagXSIksRS4ifNdYS2gM633CjiV+qKwVkyYpEqJH+RATyzo8YVWlHJkMu9x06m12 ppq3JrRzalWuoxPrTKLs/+ZPa3h4ENxSAqWt+PhZ0m6vY7o9e98vC8UrmQRfJCHac2 FIvsIFw+0EkvJVbLHIqZ5krwnoLXSBdIbmlTw8DFSS752vL5i9Pw4wUi3Puagy5lfu Hbq0OaTyccCkKQMAaeTP9k4Pz0eBjzSVadd/chJUgzbPLI/0BtWxi+yG2cTp1+tyGs S7PbvZxN1RuD6TKmkbMA/hkjfuJBeqHNcF1A/Qi4xwIeKn6aSdnuZ8oA061fR/gTYD gmAx16l3IpZEg== Cc: CLUE Subject: Re: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:23:41 -0000 Hi Christian, Thanks for being the first to comment! I'm hoping others will now follow your lead. (HINT) I ESPECIALLY NEED ROB TO RESPOND TO THIS. On 6/21/13 4:25 AM, Christian Groves wrote: > Hello Paul, all, > > A few comments: > 3.5.1 Clue Channel Lifetime > --------------------------- > Should we say something about heartbeat mechanisms in the case the CLUE > channel stays established. Is a transport level heartbeat sufficient > (probably so), or would someone like an application level heartbeat? I was thinking that the transport level heartbeat would be sufficient. Also, one of the reasons for choosing this transport stack is that it will work well for NAT/FW traversal, especially in conjunction with ICE. In that case I believe there is an expectation that STUN keepalives will be sent to keep the NATs happy. Perhaps there should be a section on that. What do you think? It would be nice to keep the application level free of such things. > 4.1. Encodings represented in SDP > ---------------------------------- > 2nd paragraph: > We should probably be clear what we mean. There is the individual > encoding attributes that are already defined in CLUE. Then there is the > “actual media encoding” i.e. codecs et.al. Do we mean both? Or the > later? From the above syntax I guess you propose only the latter which > would mean having to introducing equivalent SDP to the CLUE individual > encoding attributes. Note that this approach was first proposed by Rob. There seemed to be some interest in that, though perhaps not consensus. I adopted that approach here as a straw horse, looking to get consensus or some pushback. What I intend here is that there is *no* representation of individual encodings in the Advertisement message. The one and only representation is what is present in the SDP. But the Encoding Groups are still represented in the Advertisement - consisting of a set of IDs or labels that each reference an individual encoding in the SDP. So to answer your question, the m-line contains both. > 3rd paragraph - 1st sentence: > The encoding infromation is available for use at least by CLUE (in the > next sentence it says that a consumer may use it). I guess what you’re > trying to say is that media isn’t available until the ID is associated > with SDP associated with media or similar? > > 3rd paragraph - 2st sentence: > Doesn’t the label need to be defined for the consumer to configure it? > It probably should say “The media associated with a capture encoding > will only become active if/when a CLUE encoding identity (label) is > associated which the SDP defining the encoding and the Advertiser has > received a Configure message confirming the capture encoding.” I'm trying to address the reality of the asynchrony of Advertisements and SDP O/A, while not trying to over constrain. When an advertisement is sent, it will include some encoding groups, that contain IDs of some encodings. At the time the advertisement is received, an SDP that contains the definitions of the encodings may or may not been received. If the most recently received SDP doesn't have a definition of the encoding, then the receiver won't be able to understand it. So it would be stupid, but possible, to send a Configure that references such an encoding. All I'm doing is explaining what will happen in that situation: you will end up with a capture encoding that cannot be transmitted. But transmission can then begin if/when another O/A occurs that identifies that encoding / m-line, *and* that m-line is accepted by both ends during that O/A. This does illustrate a limitation with this approach: Suppose an advertiser wants to advertise a new encoding. It needs to send an offer that includes the encoding, and it needs to send an advertisement that references it in an encoding group, making it available for configuration. It has to decide which to send first. If an offer containing the SDP with the encoding is sent first, then the answer will need to be constructed without knowing if there will be any desire to use that encoding. If the answer accepts the encoding and then the answerer, after receiving the subsequent Advertisement, decides it doesn't need that encoding, then resources have been wasted. It will then take another O/A to shed those resources. If an Advertisement that references the new encoding is sent first, then as above, the receiver has no basis to send a configure selecting it. This may be ok if it can just wait for the SDP before sending a Configure. But there is no *guarantee* that such an SDP offer will be coming soon. So how long should one wait before sending a Configure? I think this means that this approach requires a bit more specification of the sequencing between advertisements and SDP. Perhaps we could say that if you send an advertisement that references an encoding, then you are obligated to send an offer asap that defines that encoding. This was Rob's idea. Maybe he will comment. ROB - ARE YOU THERE??? Personally, I find this fairly discomforting. I think I would prefer to keep encodings in the advertisement. But I thought it worthwhile to explore this approach. > 3rd paragraph - last sentence: > I’m confused? Its says the consumer has insufficient information to > select it? But two sentence above it says a consumer may configure an > encoding that is not defined? I think I already covered this above. The consumer has insufficient information to make an informed choice. But he has sufficient information to make an uninformed choice. (I would like this capture, but the only encoding for it is currently unavailable to me. I'll just ask for it and see if I get an offer that defines it and that I can support.) > 5.1. Independence of SDP and CLUE negotiation > ---------------------------------------------- > First sentence: > CLUE exceeding I don’t think is a problem. How about if the CLUE Max > bandwidth is less the SDP bandwidth? I’m not sure how the encodingGroup > attributes apply? "make reference to SDP contents" - This is very > general should we narrow this only to refer to the group/label that ties > the two together? As noted, I just copied this material from Rob's document. While I have my own interpretation of it, rather than trying to channel Rob, I think it would be better to let him respond to this! ROB - CAN YOU RESPOND HERE? > General > ------- > There seems to be overlap between the included text from > I-D.hansen-clue-sdp-interaction and other sections in the signalling > document. I'm not sure of the procedure but I think it would be good if > the draft editor can make changes to the text rather than cutting and > pasting. I agree. I just consider this a transient stage. My adoption of Rob's proposal is tentative, to see how it flies. If we actually agree to go this way then we need to do a lot of cleanup. I just don't think its worthwhile until we get some agreement. Thanks, Paul > Regards, Christian > > PS: I might be slow with my responses as I'm travelling. > > On 14/06/2013 7:26 AM, Paul Kyzivat wrote: >> I just posted a new version of the signaling draft. Here are changes >> (from the change log): >> >> * Added a syntax section with an XML schema for CLUE messages. >> This is a strawhorse, and is very incomplete, but it >> establishes a template for doing this based on elements defined >> in the data model. (Thanks to Roberta for help with this!) >> >> * Did some rewording to fit the syntax section in and reference >> it. >> >> * Did some relatively minor restructuring of the document to make >> it flow better in a logical way. >> >> The prior versions have received little comment. >> PLEASE, PLEASE review this and comment!!! >> There are many open issues in this looking for comments >> or preferably proposed text. >> >> Thanks, >> Paul >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-kyzivat-clue-signaling-03.txt >> Date: Thu, 13 Jun 2013 14:22:45 -0700 >> From: internet-drafts@ietf.org >> To: Christian Groves , Lennard Xiao >> , Paul Kyzivat , >> Christian Groves >> >> >> A new version of I-D, draft-kyzivat-clue-signaling-03.txt >> has been successfully submitted by Paul Kyzivat and posted to the >> IETF repository. >> >> Filename: draft-kyzivat-clue-signaling >> Revision: 03 >> Title: CLUE Signaling >> Creation date: 2013-06-13 >> Group: Individual Submission >> Number of pages: 27 >> URL: >> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-03.txt >> Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling >> Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-03 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-03 >> >> Abstract: >> This document specifies how signaling is conducted in the course of >> CLUE sessions. This includes how SIP/SDP signaling is applied to >> CLUE sessions as well as defining a CLUE-specific signaling protocol >> that complements SIP/SDP and supports negotiation of CLUE application >> level data. >> >> >> >> >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From trac+clue@trac.tools.ietf.org Mon Jun 24 09:11:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43EC21E80F8 for ; Mon, 24 Jun 2013 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9IrCp+C3fyM for ; Mon, 24 Jun 2013 09:11:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2569521F9C34 for ; Mon, 24 Jun 2013 09:11:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:39724 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ur9MQ-0002Gw-Fc; Mon, 24 Jun 2013 18:11:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 24 Jun 2013 16:11:22 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/22#comment:1 Message-ID: <083.4ddf3c5dcd9c15ecf084090bb20fe10e@trac.tools.ietf.org> References: <068.fb5e79bb27ae7c1fb4b12d1afbef9e96@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <068.fb5e79bb27ae7c1fb4b12d1afbef9e96@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, keith.drage@alcatel-lucent.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #22: Action item (ix): Out-of-date Advertisements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:11:29 -0000 #22: Action item (ix): Out-of-date Advertisements Changes (by mary.ietf.barnes@gmail.com): * component: framework => charter Comment: This issue should be resolved as part of the signaling solution. However, since we don't currently have a signaling WG document. The component has been changed to the charter. -- ----------------------------------------+-------------------------- Reporter: mary.ietf.barnes@gmail.com | Owner: Keith Drage Type: task | Status: new Priority: minor | Milestone: milestone1 Component: charter | Version: 1.0 Severity: - | Resolution: Keywords: | ----------------------------------------+-------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Mon Jun 24 09:49:24 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9121E813E for ; Mon, 24 Jun 2013 09:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu0QL9yDNJ-L for ; Mon, 24 Jun 2013 09:49:24 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBE121E811E for ; Mon, 24 Jun 2013 09:49:24 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so6507335qcq.33 for ; Mon, 24 Jun 2013 09:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cm521bLB39u9iRVw1/bezNN+sbTuyTzNsw6BtDd+ZS0=; b=pZA+UKNw78tBYC2wgGAF4XOcsqLRyQIfSICWrhjT3FyrrkZ6vj6Cwk7kM+7k0vUzeg jb21QypEUSF3En7s7sXUU3Ok6+CxRrrVOQA0DRsKXbX213+cw3d+oF5DGvG37jzro/ir zgXhQPJWNXd99JhWm505UWnE+zi4ziCgjGjJIiUbZmTbtHY+l3r8gR1czSiGw+Q29wH2 ke9H9w6AwW7LwDXLRrlDN8q/3Ec/pLujzXHeFiTJidFDpl6nqK1L9XERhdiKFXVtrxOd SVTXW1gj6nIYuqEwc6Na+ZWs4zan0dR7hg97JF/u5YmHW7RcUdNTW2OWWSmyVZntq4Z+ 09ow== MIME-Version: 1.0 X-Received: by 10.224.149.199 with SMTP id u7mr27955485qav.37.1372092562561; Mon, 24 Jun 2013 09:49:22 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Mon, 24 Jun 2013 09:49:22 -0700 (PDT) Date: Mon, 24 Jun 2013 11:49:22 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Reminder: Virtual Interim tomorrow - 6/25 @ 8am Central US time X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:49:24 -0000 As a reminder, we have a virtual interim scheduled for tomorrow: http://tools.ietf.org/wg/clue/trac/wiki The chairs need charts by 3pm Pacific today to ensure we can get them uploaded in time for the meeting for folks that may not have Webex. The materials will be available here: http://www.ietf.org/proceedings/interim/2013/06/25/clue/proceedings.html Note that the agenda in the proceedings has presenters identified, if you are not planning to present, please let the chairs know ASAP, so we can have a revised agenda out before the meeting. Thanks, Mary. From roberta.presta@unina.it Mon Jun 24 10:18:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C254A21E8123 for ; Mon, 24 Jun 2013 10:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dO5wTRxN0QY for ; Mon, 24 Jun 2013 10:18:09 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id A880A21E8119 for ; Mon, 24 Jun 2013 10:18:08 -0700 (PDT) Received: from [127.0.0.1] ([100.71.7.51]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r5OHI1Mt023030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 19:18:02 +0200 Message-ID: <51C87F49.1040607@unina.it> Date: Mon, 24 Jun 2013 19:18:01 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130624-1, 24/06/2013), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] Reminder: Virtual Interim tomorrow - 6/25 @ 8am Central US time X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 17:18:21 -0000 Dear Mary, we'll be participating in the virtual meeting. Though, we think there is no need to allocate a dedicated slot to the data model, since there is no significant update to be discussed. Most of the discussions on the list have actually concerned CLUE signaling and this does not impact that much the data model. See you tomorrow online, Roberta Il 24/06/2013 18:49, Mary Barnes ha scritto: > As a reminder, we have a virtual interim scheduled for tomorrow: > http://tools.ietf.org/wg/clue/trac/wiki > > The chairs need charts by 3pm Pacific today to ensure we can get them > uploaded in time for the meeting for folks that may not have Webex. > The materials will be available here: > http://www.ietf.org/proceedings/interim/2013/06/25/clue/proceedings.html > > Note that the agenda in the proceedings has presenters identified, if > you are not planning to present, please let the chairs know ASAP, so > we can have a revised agenda out before the meeting. > > Thanks, > Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > -- Roberta Presta, Ph.D. Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione (DIETI) Universita' degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 From rohanse2@cisco.com Mon Jun 24 12:15:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253DC21E816F for ; Mon, 24 Jun 2013 12:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtDegIVJoZec for ; Mon, 24 Jun 2013 12:14:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC70B21E816E for ; Mon, 24 Jun 2013 12:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14089; q=dns/txt; s=iport; t=1372101296; x=1373310896; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=KZqqMM2MuR8qC0cQFGtBGd8tg4R1w6f83xi1ghVcjOk=; b=lXLGbaz090J+GUCtrsS1kBszSGhtG8GeuuHdPHtNL1wGhNlMqxXhHJR/ R+1Hy5kp3cL0F+ptMTyWICQ3ftar6YlgPDHVWuPW7UvhcqryEoaRPY4V+ 2ULtaqXGLN4tShY3k+mt2sOy3dLvYGD1mwnJW8P9EfoHd5Cja27mODzTw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoIABWayFGQ/khM/2dsb2JhbABRCYMJMUODC6g0lAqBBxZ0giMBAQEDAQEBASAPAQU2BgMBDQQLEQMBAgECAgUWCwICCQMCAQIBFSgIEwYCAQEFh38GBwWpN5E7gSaMbgSBPgaCSYEUA5dDgSmEeIsjgxE7gSwBBhk X-IronPort-AV: E=Sophos;i="4.87,930,1363132800"; d="scan'208";a="83608203" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 24 Jun 2013 19:14:53 +0000 Received: from [10.47.196.239] ([10.47.196.239]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5OJEpKO025166 for ; Mon, 24 Jun 2013 19:14:51 GMT Message-ID: <51C89ABE.4070806@cisco.com> Date: Mon, 24 Jun 2013 20:15:10 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <20130613212245.8835.79830.idtracker@ietfa.amsl.com> <51BA3922.9040506@alum.mit.edu> <51C40DF2.6050604@nteczone.com> <51C48C13.2040402@alum.mit.edu> In-Reply-To: <51C48C13.2040402@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:15:02 -0000 Apologies for not having responded - I've been trying to find the time to write a proper set of updates I could run past Paul for integration into the draft but haven't managed it yet. I clearly need to do so, because without concrete proposals it's hard to weigh the pros and cons of things. Some comment in-line. On 21/06/2013 18:23, Paul Kyzivat wrote: > Hi Christian, > > Thanks for being the first to comment! > I'm hoping others will now follow your lead. (HINT) > > I ESPECIALLY NEED ROB TO RESPOND TO THIS. > > On 6/21/13 4:25 AM, Christian Groves wrote: >> Hello Paul, all, >> >> A few comments: >> 3.5.1 Clue Channel Lifetime >> --------------------------- >> Should we say something about heartbeat mechanisms in the case the CLUE >> channel stays established. Is a transport level heartbeat sufficient >> (probably so), or would someone like an application level heartbeat? > > I was thinking that the transport level heartbeat would be sufficient. > > Also, one of the reasons for choosing this transport stack is that it > will work well for NAT/FW traversal, especially in conjunction with ICE. > In that case I believe there is an expectation that STUN keepalives will > be sent to keep the NATs happy. Perhaps there should be a section on > that. What do you think? > > It would be nice to keep the application level free of such things. > >> 4.1. Encodings represented in SDP >> ---------------------------------- >> 2nd paragraph: >> We should probably be clear what we mean. There is the individual >> encoding attributes that are already defined in CLUE. Then there is the >> “actual media encoding” i.e. codecs et.al. Do we mean both? Or the >> later? From the above syntax I guess you propose only the latter which >> would mean having to introducing equivalent SDP to the CLUE individual >> encoding attributes. > > Note that this approach was first proposed by Rob. There seemed to be > some interest in that, though perhaps not consensus. I adopted that > approach here as a straw horse, looking to get consensus or some pushback. > > What I intend here is that there is *no* representation of individual > encodings in the Advertisement message. The one and only representation > is what is present in the SDP. But the Encoding Groups are still > represented in the Advertisement - consisting of a set of IDs or labels > that each reference an individual encoding in the SDP. > > So to answer your question, the m-line contains both. In a perfect world I think there's a good argument for the encoding groups to also be in the SDP, but that would require new syntax and is a lot less important than having the encodings there. > >> 3rd paragraph - 1st sentence: >> The encoding infromation is available for use at least by CLUE (in the >> next sentence it says that a consumer may use it). I guess what you’re >> trying to say is that media isn’t available until the ID is associated >> with SDP associated with media or similar? >> >> 3rd paragraph - 2st sentence: >> Doesn’t the label need to be defined for the consumer to configure it? >> It probably should say “The media associated with a capture encoding >> will only become active if/when a CLUE encoding identity (label) is >> associated which the SDP defining the encoding and the Advertiser has >> received a Configure message confirming the capture encoding.” > > I'm trying to address the reality of the asynchrony of Advertisements > and SDP O/A, while not trying to over constrain. > > When an advertisement is sent, it will include some encoding groups, > that contain IDs of some encodings. At the time the advertisement is > received, an SDP that contains the definitions of the encodings may or > may not been received. If the most recently received SDP doesn't have a > definition of the encoding, then the receiver won't be able to > understand it. So it would be stupid, but possible, to send a Configure > that references such an encoding. All I'm doing is explaining what will > happen in that situation: you will end up with a capture encoding that > cannot be transmitted. But transmission can then begin if/when another > O/A occurs that identifies that encoding / m-line, *and* that m-line is > accepted by both ends during that O/A. > > This does illustrate a limitation with this approach: Suppose an > advertiser wants to advertise a new encoding. It needs to send an offer > that includes the encoding, and it needs to send an advertisement that > references it in an encoding group, making it available for > configuration. It has to decide which to send first. > > If an offer containing the SDP with the encoding is sent first, then the > answer will need to be constructed without knowing if there will be any > desire to use that encoding. If the answer accepts the encoding and then > the answerer, after receiving the subsequent Advertisement, decides it > doesn't need that encoding, then resources have been wasted. It will > then take another O/A to shed those resources. > > If an Advertisement that references the new encoding is sent first, then > as above, the receiver has no basis to send a configure selecting it. > This may be ok if it can just wait for the SDP before sending a > Configure. But there is no *guarantee* that such an SDP offer will be > coming soon. So how long should one wait before sending a Configure? > > I think this means that this approach requires a bit more specification > of the sequencing between advertisements and SDP. Perhaps we could say > that if you send an advertisement that references an encoding, then you > are obligated to send an offer asap that defines that encoding. > > This was Rob's idea. Maybe he will comment. ROB - ARE YOU THERE??? > > Personally, I find this fairly discomforting. I think I would prefer to > keep encodings in the advertisement. But I thought it worthwhile to > explore this approach. I believe that this problem exists irrespective of where the encoding information goes - even if all the encoding information were in the clue advertisment the essential issue would still exist. So long as we have the premise that stream multiplexing is negotiated at the SDP level but that some information about that stream is outside SDP (in the clue advertisment) then accepting a new stream isn't atomic and we have this issue: if an SDP offer is received with three streams but the advertisment hasn't yet been received then the receiver will be unable to make a sensible decision about whether it wants to accept those streams, whether the encoding information about those streams is in the SDP or in the CLUE message. When I've thought about this in the past I've generally felt it was best to leave it up to individual implementations how they deal with how best to deal with the fact they need information from two independant sources to make sensible decisions. However, as you point out some behaviour (such as accepting streams from an SDP on-spec before you see the associated advertisment when there's no guarentee when, if ever, that advertisment will arrive) is obviously sub-optimal. Rather than mandate the timings of inter-related SDP and CLUE messages, though, I'd prefer to mandate the way the receiver deals with the messages it received (or at least highly recommend it). Adding the rule that a receiver should ignore any CLUE advertised element for which it does not have the corresponding SDP, and similarly must reject any SDP streams for which it does not have corresponding CLUE advertisment information, is straightforward and ensures that resources are never unnecessarily committed. The downside, that an additional O/A or clue message may be required, is a fixed cost rather than an open-ended one. For instance, A advertises an additional stream to B by sending a new SDP offer and a new CLUE advertisment. In the first example, B receives the advertisment first: * A sends an advertisment with stream X. (B must not send a configure for stream X, because it has not received the corresponding SDP). * A sends an SDP offer with stream X. * B sends an SDP answer accepting stream X. * B sends a configure message requesting stream X. In the second example, B receives the SDP first: * A sends an SDP offer with stream X. (B cannot send an answer in response with an active stream X, because it has not received the corresponding advertisment). * B send an SDP answer with stream X zeroed. * B receives A's advertisment with stream X in. * B sends a new SDP offer with stream X active. * B sends a configure message requesting stream X. * A sends an SDP answer with stream X active. >> 3rd paragraph - last sentence: >> I’m confused? Its says the consumer has insufficient information to >> select it? But two sentence above it says a consumer may configure an >> encoding that is not defined? > > I think I already covered this above. The consumer has insufficient > information to make an informed choice. But he has sufficient > information to make an uninformed choice. (I would like this capture, > but the only encoding for it is currently unavailable to me. I'll just > ask for it and see if I get an offer that defines it and that I can > support.) Indeed, and the proposal above would be to disallow such 'uninformed' choices. >> 5.1. Independence of SDP and CLUE negotiation >> ---------------------------------------------- >> First sentence: >> CLUE exceeding I don’t think is a problem. How about if the CLUE Max >> bandwidth is less the SDP bandwidth? I’m not sure how the encodingGroup >> attributes apply? "make reference to SDP contents" - This is very >> general should we narrow this only to refer to the group/label that ties >> the two together? > > As noted, I just copied this material from Rob's document. > While I have my own interpretation of it, rather than trying to channel > Rob, I think it would be better to let him respond to this! > > ROB - CAN YOU RESPOND HERE? Ultimately I'd like to move any bandwidth and other encoding-related constraints out of clue and into the SDP, removing this specific issue. But that will probably depend on the final SDP syntax we end up using for multiplexing. Generally, though, the rule is that the constraints of both SDP and CLUE are applied. If 4M has been negotiated in SDP and 2M in CLUE, the limit is 2M. If five streams have been asked for in a CLUE configure message but only three streams have been negotiated in SDP, only those three streams should be sent. > >> General >> ------- >> There seems to be overlap between the included text from >> I-D.hansen-clue-sdp-interaction and other sections in the signalling >> document. I'm not sure of the procedure but I think it would be good if >> the draft editor can make changes to the text rather than cutting and >> pasting. > > I agree. I just consider this a transient stage. My adoption of Rob's > proposal is tentative, to see how it flies. If we actually agree to go > this way then we need to do a lot of cleanup. I just don't think its > worthwhile until we get some agreement. > > Thanks, > Paul > >> Regards, Christian >> >> PS: I might be slow with my responses as I'm travelling. >> >> On 14/06/2013 7:26 AM, Paul Kyzivat wrote: >>> I just posted a new version of the signaling draft. Here are changes >>> (from the change log): >>> >>> * Added a syntax section with an XML schema for CLUE messages. >>> This is a strawhorse, and is very incomplete, but it >>> establishes a template for doing this based on elements defined >>> in the data model. (Thanks to Roberta for help with this!) >>> >>> * Did some rewording to fit the syntax section in and reference >>> it. >>> >>> * Did some relatively minor restructuring of the document to make >>> it flow better in a logical way. >>> >>> The prior versions have received little comment. >>> PLEASE, PLEASE review this and comment!!! >>> There are many open issues in this looking for comments >>> or preferably proposed text. >>> >>> Thanks, >>> Paul >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-kyzivat-clue-signaling-03.txt >>> Date: Thu, 13 Jun 2013 14:22:45 -0700 >>> From: internet-drafts@ietf.org >>> To: Christian Groves , Lennard Xiao >>> , Paul Kyzivat , >>> Christian Groves >>> >>> >>> A new version of I-D, draft-kyzivat-clue-signaling-03.txt >>> has been successfully submitted by Paul Kyzivat and posted to the >>> IETF repository. >>> >>> Filename: draft-kyzivat-clue-signaling >>> Revision: 03 >>> Title: CLUE Signaling >>> Creation date: 2013-06-13 >>> Group: Individual Submission >>> Number of pages: 27 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-03.txt >>> Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling >>> Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-03 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-03 >>> >>> Abstract: >>> This document specifies how signaling is conducted in the course of >>> CLUE sessions. This includes how SIP/SDP signaling is applied to >>> CLUE sessions as well as defining a CLUE-specific signaling protocol >>> that complements SIP/SDP and supports negotiation of CLUE application >>> level data. >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Jun 24 13:40:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE3F21E80EC for ; Mon, 24 Jun 2013 13:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.024 X-Spam-Level: X-Spam-Status: No, score=-0.024 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmdzU7714Xol for ; Mon, 24 Jun 2013 13:39:58 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id EF13E21E8108 for ; Mon, 24 Jun 2013 13:39:57 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta07.westchester.pa.mail.comcast.net with comcast id sDa51l0050EZKEL57LfxE8; Mon, 24 Jun 2013 20:39:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id sLfx1l00D3ZTu2S3MLfxGR; Mon, 24 Jun 2013 20:39:57 +0000 Message-ID: <51C8AE9C.3050206@alum.mit.edu> Date: Mon, 24 Jun 2013 16:39:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <20130613212245.8835.79830.idtracker@ietfa.amsl.com> <51BA3922.9040506@alum.mit.edu> <51C40DF2.6050604@nteczone.com> <51C48C13.2040402@alum.mit.edu> <51C89ABE.4070806@cisco.com> In-Reply-To: <51C89ABE.4070806@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372106397; bh=0cDOs1sWyiXHgi4adxVrQXQ7THA9akGT2llNcvN6/74=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JSFJnXBY3Mj6boeIBcvU1rGPKXSo7skOrzHGQPig3DdC4EpeR7MHAm56qW/3KdcLP yJPbTqlO/kcSmtK3JYV7fnFA2OLkzwDoZXeFrWbrbOn0r8XLf+WjU3PFvMQxZ6voF3 tbyjO1XvmR1L1qREJxAevMTHCk4KaRpB2bnaD+G/flr4uhq5cMvyAUb0mO/QjnZ+bb weHKyOcxKSq39oSvOJPu2urVuGassyg2do85XdZmbMeVRbKu6bWJWpDlA0B7ewOSgj shxSLtP2nVFY0EI+1C/Pv1GHFdDWaEzK5o7LvaQWVhlTmYE/RlR506BEmC2RmeH4qx CSTAH6LLyDFFA== Subject: Re: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:40:03 -0000 Rob, I'm in general agreement with what you say. The one exception is about "must ignore" parts of an advertisement where required SDP info is lacking. I do think a sensible device will probably take this approach. But I can see no reason to mandate that. Doing so still leaves open the possibility that it will be violated. And in general it will be impossible for the advertiser to know if the configurer has behaved legally or not. (Because messages may arrive in a different order than they were sent.) I can see no harm to anyone from allowing this seemingly stupid behavior. So why be more restrictive than necessary? Thanks, Paul On 6/24/13 3:15 PM, Robert Hansen wrote: > Apologies for not having responded - I've been trying to find the time > to write a proper set of updates I could run past Paul for integration > into the draft but haven't managed it yet. I clearly need to do so, > because without concrete proposals it's hard to weigh the pros and cons > of things. > > Some comment in-line. > > On 21/06/2013 18:23, Paul Kyzivat wrote: >> Hi Christian, >> >> Thanks for being the first to comment! >> I'm hoping others will now follow your lead. (HINT) >> >> I ESPECIALLY NEED ROB TO RESPOND TO THIS. >> >> On 6/21/13 4:25 AM, Christian Groves wrote: >>> Hello Paul, all, >>> >>> A few comments: >>> 3.5.1 Clue Channel Lifetime >>> --------------------------- >>> Should we say something about heartbeat mechanisms in the case the CLUE >>> channel stays established. Is a transport level heartbeat sufficient >>> (probably so), or would someone like an application level heartbeat? >> >> I was thinking that the transport level heartbeat would be sufficient. >> >> Also, one of the reasons for choosing this transport stack is that it >> will work well for NAT/FW traversal, especially in conjunction with ICE. >> In that case I believe there is an expectation that STUN keepalives will >> be sent to keep the NATs happy. Perhaps there should be a section on >> that. What do you think? >> >> It would be nice to keep the application level free of such things. >> >>> 4.1. Encodings represented in SDP >>> ---------------------------------- >>> 2nd paragraph: >>> We should probably be clear what we mean. There is the individual >>> encoding attributes that are already defined in CLUE. Then there is the >>> “actual media encoding” i.e. codecs et.al. Do we mean both? Or the >>> later? From the above syntax I guess you propose only the latter which >>> would mean having to introducing equivalent SDP to the CLUE individual >>> encoding attributes. >> >> Note that this approach was first proposed by Rob. There seemed to be >> some interest in that, though perhaps not consensus. I adopted that >> approach here as a straw horse, looking to get consensus or some >> pushback. >> >> What I intend here is that there is *no* representation of individual >> encodings in the Advertisement message. The one and only representation >> is what is present in the SDP. But the Encoding Groups are still >> represented in the Advertisement - consisting of a set of IDs or labels >> that each reference an individual encoding in the SDP. >> >> So to answer your question, the m-line contains both. > > In a perfect world I think there's a good argument for the encoding > groups to also be in the SDP, but that would require new syntax and is a > lot less important than having the encodings there. > >> >>> 3rd paragraph - 1st sentence: >>> The encoding infromation is available for use at least by CLUE (in the >>> next sentence it says that a consumer may use it). I guess what you’re >>> trying to say is that media isn’t available until the ID is associated >>> with SDP associated with media or similar? >>> >>> 3rd paragraph - 2st sentence: >>> Doesn’t the label need to be defined for the consumer to configure it? >>> It probably should say “The media associated with a capture encoding >>> will only become active if/when a CLUE encoding identity (label) is >>> associated which the SDP defining the encoding and the Advertiser has >>> received a Configure message confirming the capture encoding.” >> >> I'm trying to address the reality of the asynchrony of Advertisements >> and SDP O/A, while not trying to over constrain. >> >> When an advertisement is sent, it will include some encoding groups, >> that contain IDs of some encodings. At the time the advertisement is >> received, an SDP that contains the definitions of the encodings may or >> may not been received. If the most recently received SDP doesn't have a >> definition of the encoding, then the receiver won't be able to >> understand it. So it would be stupid, but possible, to send a Configure >> that references such an encoding. All I'm doing is explaining what will >> happen in that situation: you will end up with a capture encoding that >> cannot be transmitted. But transmission can then begin if/when another >> O/A occurs that identifies that encoding / m-line, *and* that m-line is >> accepted by both ends during that O/A. >> >> This does illustrate a limitation with this approach: Suppose an >> advertiser wants to advertise a new encoding. It needs to send an offer >> that includes the encoding, and it needs to send an advertisement that >> references it in an encoding group, making it available for >> configuration. It has to decide which to send first. >> >> If an offer containing the SDP with the encoding is sent first, then the >> answer will need to be constructed without knowing if there will be any >> desire to use that encoding. If the answer accepts the encoding and then >> the answerer, after receiving the subsequent Advertisement, decides it >> doesn't need that encoding, then resources have been wasted. It will >> then take another O/A to shed those resources. >> >> If an Advertisement that references the new encoding is sent first, then >> as above, the receiver has no basis to send a configure selecting it. >> This may be ok if it can just wait for the SDP before sending a >> Configure. But there is no *guarantee* that such an SDP offer will be >> coming soon. So how long should one wait before sending a Configure? >> >> I think this means that this approach requires a bit more specification >> of the sequencing between advertisements and SDP. Perhaps we could say >> that if you send an advertisement that references an encoding, then you >> are obligated to send an offer asap that defines that encoding. >> >> This was Rob's idea. Maybe he will comment. ROB - ARE YOU THERE??? >> >> Personally, I find this fairly discomforting. I think I would prefer to >> keep encodings in the advertisement. But I thought it worthwhile to >> explore this approach. > > I believe that this problem exists irrespective of where the encoding > information goes - even if all the encoding information were in the clue > advertisment the essential issue would still exist. So long as we have > the premise that stream multiplexing is negotiated at the SDP level but > that some information about that stream is outside SDP (in the clue > advertisment) then accepting a new stream isn't atomic and we have this > issue: if an SDP offer is received with three streams but the > advertisment hasn't yet been received then the receiver will be unable > to make a sensible decision about whether it wants to accept those > streams, whether the encoding information about those streams is in the > SDP or in the CLUE message. > > When I've thought about this in the past I've generally felt it was best > to leave it up to individual implementations how they deal with how best > to deal with the fact they need information from two independant sources > to make sensible decisions. However, as you point out some behaviour > (such as accepting streams from an SDP on-spec before you see the > associated advertisment when there's no guarentee when, if ever, that > advertisment will arrive) is obviously sub-optimal. > > Rather than mandate the timings of inter-related SDP and CLUE messages, > though, I'd prefer to mandate the way the receiver deals with the > messages it received (or at least highly recommend it). Adding the rule > that a receiver should ignore any CLUE advertised element for which it > does not have the corresponding SDP, and similarly must reject any SDP > streams for which it does not have corresponding CLUE advertisment > information, is straightforward and ensures that resources are never > unnecessarily committed. The downside, that an additional O/A or clue > message may be required, is a fixed cost rather than an open-ended one. > > For instance, A advertises an additional stream to B by sending a new > SDP offer and a new CLUE advertisment. In the first example, B receives > the advertisment first: > > * A sends an advertisment with stream X. > (B must not send a configure for stream X, because it has not > received the corresponding SDP). > > * A sends an SDP offer with stream X. > > * B sends an SDP answer accepting stream X. > > * B sends a configure message requesting stream X. > > In the second example, B receives the SDP first: > > * A sends an SDP offer with stream X. > (B cannot send an answer in response with an active stream X, > because it has not received the corresponding advertisment). > > * B send an SDP answer with stream X zeroed. > > * B receives A's advertisment with stream X in. > > * B sends a new SDP offer with stream X active. > > * B sends a configure message requesting stream X. > > * A sends an SDP answer with stream X active. > > >>> 3rd paragraph - last sentence: >>> I’m confused? Its says the consumer has insufficient information to >>> select it? But two sentence above it says a consumer may configure an >>> encoding that is not defined? >> >> I think I already covered this above. The consumer has insufficient >> information to make an informed choice. But he has sufficient >> information to make an uninformed choice. (I would like this capture, >> but the only encoding for it is currently unavailable to me. I'll just >> ask for it and see if I get an offer that defines it and that I can >> support.) > > Indeed, and the proposal above would be to disallow such 'uninformed' > choices. > >>> 5.1. Independence of SDP and CLUE negotiation >>> ---------------------------------------------- >>> First sentence: >>> CLUE exceeding I don’t think is a problem. How about if the CLUE Max >>> bandwidth is less the SDP bandwidth? I’m not sure how the encodingGroup >>> attributes apply? "make reference to SDP contents" - This is very >>> general should we narrow this only to refer to the group/label that ties >>> the two together? >> >> As noted, I just copied this material from Rob's document. >> While I have my own interpretation of it, rather than trying to channel >> Rob, I think it would be better to let him respond to this! >> >> ROB - CAN YOU RESPOND HERE? > > Ultimately I'd like to move any bandwidth and other encoding-related > constraints out of clue and into the SDP, removing this specific issue. > But that will probably depend on the final SDP syntax we end up using > for multiplexing. > > Generally, though, the rule is that the constraints of both SDP and CLUE > are applied. If 4M has been negotiated in SDP and 2M in CLUE, the limit > is 2M. If five streams have been asked for in a CLUE configure message > but only three streams have been negotiated in SDP, only those three > streams should be sent. > >> >>> General >>> ------- >>> There seems to be overlap between the included text from >>> I-D.hansen-clue-sdp-interaction and other sections in the signalling >>> document. I'm not sure of the procedure but I think it would be good if >>> the draft editor can make changes to the text rather than cutting and >>> pasting. >> >> I agree. I just consider this a transient stage. My adoption of Rob's >> proposal is tentative, to see how it flies. If we actually agree to go >> this way then we need to do a lot of cleanup. I just don't think its >> worthwhile until we get some agreement. >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> PS: I might be slow with my responses as I'm travelling. >>> >>> On 14/06/2013 7:26 AM, Paul Kyzivat wrote: >>>> I just posted a new version of the signaling draft. Here are changes >>>> (from the change log): >>>> >>>> * Added a syntax section with an XML schema for CLUE messages. >>>> This is a strawhorse, and is very incomplete, but it >>>> establishes a template for doing this based on elements defined >>>> in the data model. (Thanks to Roberta for help with this!) >>>> >>>> * Did some rewording to fit the syntax section in and reference >>>> it. >>>> >>>> * Did some relatively minor restructuring of the document to make >>>> it flow better in a logical way. >>>> >>>> The prior versions have received little comment. >>>> PLEASE, PLEASE review this and comment!!! >>>> There are many open issues in this looking for comments >>>> or preferably proposed text. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for >>>> draft-kyzivat-clue-signaling-03.txt >>>> Date: Thu, 13 Jun 2013 14:22:45 -0700 >>>> From: internet-drafts@ietf.org >>>> To: Christian Groves , Lennard Xiao >>>> , Paul Kyzivat , >>>> Christian Groves >>>> >>>> >>>> A new version of I-D, draft-kyzivat-clue-signaling-03.txt >>>> has been successfully submitted by Paul Kyzivat and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-kyzivat-clue-signaling >>>> Revision: 03 >>>> Title: CLUE Signaling >>>> Creation date: 2013-06-13 >>>> Group: Individual Submission >>>> Number of pages: 27 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-03.txt >>>> Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling >>>> Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-03 >>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-03 >>>> >>>> Abstract: >>>> This document specifies how signaling is conducted in the course of >>>> CLUE sessions. This includes how SIP/SDP signaling is applied to >>>> CLUE sessions as well as defining a CLUE-specific signaling protocol >>>> that complements SIP/SDP and supports negotiation of CLUE application >>>> level data. >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Tue Jun 25 07:52:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ADE21E80BC for ; Tue, 25 Jun 2013 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyjIZnzl4FG9 for ; Tue, 25 Jun 2013 07:52:25 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6F21121E8091 for ; Tue, 25 Jun 2013 07:52:25 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so7336034qcz.14 for ; Tue, 25 Jun 2013 07:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Uo7W+jwpjc9Shr36UkZ/wUp7Ayhldn+A5J1ssDAiB/E=; b=yX+/MeKkrQ7Y2UMXXzgB5PhOB7pbpiq6VFnbkc0ZES7IvdPL8TL1nlKvX3N632aRAg yaWFiEc1esEkf1VXGGp/spfKz+YEsJzirq1CDAtbvrkAgl2PeYW1fUYA39mMGgCFPB+S wPwnH3lhtBnR6G6qRJkcz/pwVwtRYYC8NJaNedRY614Do1V8g3r+DyKGOHAyi/LKlcJW OpbgC33DesTPzbpv8jIjBpsiWW9lKDtQem78Jtzm77thhpi22LYfbt99e1yqdGeqsR6r dSsRCX1pnA5EJj7oiTarlqPJuljVE2jNvi0qxvpkEooB2qmjrw7hSMt00PD/TM8ArKti Q2Zg== MIME-Version: 1.0 X-Received: by 10.224.149.199 with SMTP id u7mr264647qav.37.1372171944885; Tue, 25 Jun 2013 07:52:24 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 25 Jun 2013 07:52:24 -0700 (PDT) Date: Tue, 25 Jun 2013 09:52:24 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Open Source SIP Telepresence X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:52:26 -0000 For folks that might have missed this link that Simon posted in the chat window, there is an open source (Google) Telepresence implementation: http://code.google.com/p/telepresence/ Thanks for the link Simon! Mary. From fluffy@iii.ca Tue Jun 25 07:54:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAA421E80F0 for ; Tue, 25 Jun 2013 07:54:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcJ8VrMdCIbo for ; Tue, 25 Jun 2013 07:54:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id CA8DD21E80BC for ; Tue, 25 Jun 2013 07:54:47 -0700 (PDT) Received: from [10.71.1.4] (unknown [209.155.233.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8383850A89 for ; Tue, 25 Jun 2013 10:54:33 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 25 Jun 2013 10:54:32 -0400 To: clue@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [clue] Comments on draft-kyzivat-clue-signaling-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:54:53 -0000 I think this draft is going in the wrong direction. It is punting on the = what is done in SDP, what is done in clue and basically says all of clue = data model goes in the clue protocol and some might also be in SDP. That = will result in miserable conflicts resolutions and nasty = interoperability failure as well as reducing the odds of folks = implementing this widely.=20 I'd rather see it split up the data model and put some of it in SDP and = some of it CLUE with a very clean distinction between the two. I'm fine = with the concept that SDP forms an envelope of which other things are = negotiated to be inside the limits set by the envelope.=20 From spromano@unina.it Tue Jun 25 08:05:24 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D7521E80D4 for ; Tue, 25 Jun 2013 08:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.718 X-Spam-Level: X-Spam-Status: No, score=-97.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, SARE_RECV_SPAM_DOMN0b=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh-ZvTrEJXMc for ; Tue, 25 Jun 2013 08:05:18 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 67BFD21E80B7 for ; Tue, 25 Jun 2013 08:05:18 -0700 (PDT) Received: from 1-160-184-173.dynamic.hinet.net ([91.252.220.173]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r5PF5CQ1005605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Jun 2013 17:05:14 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----L6E4H9V7EZ39BCLTICOJUEBYIU2P5J" From: Simon Pietro Romano Date: Tue, 25 Jun 2013 17:05:07 +0200 To: Mary Barnes Message-ID: Cc: clue@ietf.org Subject: Re: [clue] Open Source SIP Telepresence X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:05:24 -0000 ------L6E4H9V7EZ39BCLTICOJUEBYIU2P5J Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ...thus is the stuff from Mamadou Diop (Doubango Telecom) and is definitely worth a look. Simon Mary Barnes ha scritto: >For folks that might have missed this link that Simon posted in the >chat window, there is an open source (Google) Telepresence >implementation: >http://code.google.com/p/telepresence/ > >Thanks for the link Simon! > >Mary. ------L6E4H9V7EZ39BCLTICOJUEBYIU2P5J Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit ...thus is the stuff from Mamadou Diop (Doubango Telecom) and is definitely worth a look.

Simon

Mary Barnes <mary.ietf.barnes@gmail.com> ha scritto:
For folks that might have missed this link that Simon posted in the
chat window,  there is an open source (Google) Telepresence
implementation:
http://code.google.com/p/telepresence/

Thanks for the link Simon!

Mary.

------L6E4H9V7EZ39BCLTICOJUEBYIU2P5J-- From pkyzivat@alum.mit.edu Tue Jun 25 08:23:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD9411E80EF for ; Tue, 25 Jun 2013 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.326 X-Spam-Level: X-Spam-Status: No, score=-0.326 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0vYoyaBbyoq for ; Tue, 25 Jun 2013 08:23:04 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 5741F21F9BC2 for ; Tue, 25 Jun 2013 08:23:02 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id sazT1l00117dt5G53fP2Yv; Tue, 25 Jun 2013 15:23:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id sfP11l01B3ZTu2S3ZfP2kC; Tue, 25 Jun 2013 15:23:02 +0000 Message-ID: <51C9B5D4.9000307@alum.mit.edu> Date: Tue, 25 Jun 2013 11:23:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372173782; bh=tlK3NkgE8xRF80bfipn3bSAeuumK3uyA0brHtwKwKno=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=On0lTyKqfU8XveXX0h1M338/eDA3wY5tq4NznX1jgRCfocYW81cTxRN3v35e+ti02 dvOinJNdPxUmK7rxLxMcVJhysFkpK/4RzMhEbFr02pf4W4EIq4wDo/yyBS3XP5b+s3 Ip/6KAu+soXP2+liVrUQo8hy6illfn4m32YptNnLYiYnt/GpwqR+MXuoy2hQtn/6cV qRu34Fa39QN2G4rcJ0fFGoQlacybXvLSPq0bIpbbEcQlrqPQGUrScguqXMfef+zNDN 7iouIq7FWrgW+kQsSSEgHAXVk08ILG6K4JG6eoP5Sur6i9vRDgy1iM7wT5meJrHl0v LDNxJRwsN9sGg== Subject: Re: [clue] Comments on draft-kyzivat-clue-signaling-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:23:23 -0000 Cullen. On 6/25/13 10:54 AM, Cullen Jennings wrote: > > I think this draft is going in the wrong direction. It is punting on the what is done in SDP, what is done in clue and basically says all of clue data model goes in the clue protocol and some might also be in SDP. That will result in miserable conflicts resolutions and nasty interoperability failure as well as reducing the odds of folks implementing this widely. > > I'd rather see it split up the data model and put some of it in SDP and some of it CLUE with a very clean distinction between the two. I'm fine with the concept that SDP forms an envelope of which other things are negotiated to be inside the limits set by the envelope. I just want to check how carefully you looked. Currently it explicitly says that the description of Encodings is done only in SDP, while Encoding Groups (referencing the encodings in SDP) and all the rest of the advertisement stuff is done in clue messages. To fully realize this the data model should probably change. Currently the data model has an XML representation of Encoding and Encodings, but the signaling draft doesn't reference that part. I'm not convinced this is the best way, but I wanted to explore it. It has some unpleasant consequences, that would be removed if encodings were described in the advertisement. But that is one of the discussions we need to have. If you already understood the above, then what would you like to see different. Thanks, Paul From mary.ietf.barnes@gmail.com Thu Jun 27 13:10:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBD111E80F5 for ; Thu, 27 Jun 2013 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtprKBLu8bLg for ; Thu, 27 Jun 2013 13:10:08 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 77BC811E80F2 for ; Thu, 27 Jun 2013 13:10:05 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id d13so76194qak.9 for ; Thu, 27 Jun 2013 13:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nqGUDkaTKNjHpiK/3Kehxlnt8ELVnynpq12Xn2YYc0M=; b=WjrPd6argY41GAsMgeAkEPM40yj99wcUe6y8WyEIcYXp+TWioSn4Dn3pOvQz3kp0ve BN4jViOJ1x0k5176GmEGrhVh8LrtwMAR4k/vMaURx2wbVkehCchSicoYU2fNbJMdWHJY E5u3h2hHHVD9zxcHZ9mNE9prz07C51E5PnLXEy0imMDoovfOzMuvsvrpvCSKf4Rq3gWW FpKVQ7/agJjyznIdYhvnxlYmWTYqM2yXraKGB2XMLX4gnoq8sHxKQ9Ds8GS9gE+YX0Yo 6Q/GMArT4oKZd0kcDcZ2FD+tYKZcGEovHAu8rrQfiVOA+6dNeLOKXxp4zYx1zcjrpfT7 b5rA== MIME-Version: 1.0 X-Received: by 10.224.22.143 with SMTP id n15mr13838666qab.93.1372363804936; Thu, 27 Jun 2013 13:10:04 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Thu, 27 Jun 2013 13:10:04 -0700 (PDT) In-Reply-To: <20130627195153.20898.65956.idtracker@ietfa.amsl.com> References: <20130627195153.20898.65956.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2013 15:10:04 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: clue - Requested sessions have been scheduled for IETF 87 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:10:09 -0000 FYI, So, folks need to plan to be there the entire week. Mary. ---------- Forwarded message ---------- From: "IETF Secretariat" Date: Thu, Jun 27, 2013 at 2:51 PM Subject: clue - Requested sessions have been scheduled for IETF 87 To: mary.ietf.barnes@gmail.com Cc: clue-ads@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, smccammon@amsl.com Dear Mary Barnes, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. clue Session 1 (2:30:00) Monday, Morning Session I 0900-1130 Room Name: Tiergarten 1/2 --------------------------------------------- clue Session 2 (1:00:00) Friday, Morning Session I 0900-1100 Room Name: Potsdam 2 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 2 Length of Session(s): 2.5 Hours, 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: dispatch xrblock xmpp vipr siprec sipcore straw rtcweb payload mmusic insipid geopriv ecrit cuss codec bfcpbis avtext avtcore rmcat jose Second Priority: drinks soc p2psip Special Requests: Please schedule the sessions with at least two days in between (e.g., Mon & Wed/Thurs/Friday. We would also like Meetecho support for both sessions --------------------------------------------------------- From mary.ietf.barnes@gmail.com Fri Jun 28 09:31:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3621F9A6A for ; Fri, 28 Jun 2013 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC0TwealfZZN for ; Fri, 28 Jun 2013 09:31:20 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 658E921F841B for ; Fri, 28 Jun 2013 09:31:20 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so1499690qcw.15 for ; Fri, 28 Jun 2013 09:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N4UfEo5u+oxmoqku+7WDRhJ65Z5IfqsrqF+IYMoWraQ=; b=qhZDc0lWhZN4fzJdPPFSo3reG4TvZBVkipjx46MIBjsU5LctHOObpqa/eNcFSJI93f n8a8JsMYTF3dYf3bPODQXZnQYhORtejxR4pqgITEyLdAw+JA+abArGLKEOzVxCaZXQrQ XUzL/SGcR/SuV5P8eOZ5W1Y0u99jn6T922CZRzmUH4ABEtgmhwxIVjDt4w/YAnzjsS62 7OlGwlmjUA+emjaNJiZMkDQ8HJaQ4DsTrfjibcXcaj7/O3ftidCJcmJCQVqc9PcH+7Ma HNcwrpKodm3NuzsnrIOyPuYGFgNt6PW96sfOw8L/3Dl+4+4epHve6dE5q0vo3bKkGafB Wmvw== MIME-Version: 1.0 X-Received: by 10.49.98.196 with SMTP id ek4mr18319203qeb.8.1372437078789; Fri, 28 Jun 2013 09:31:18 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Fri, 28 Jun 2013 09:31:18 -0700 (PDT) In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> References: <20130628152721.7537.5884.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C2299A10BE@szxpml504-mbs.exmail.huawei.com> Date: Fri, 28 Jun 2013 11:31:18 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:31:21 -0000 ---------- Forwarded message ---------- From: Roni Even Date: Fri, Jun 28, 2013 at 10:54 AM Subject: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt To: "mmusic@ietf.org" Hi, We have submitted this document that defines a mechanism to provide the mapping between the SSRCs of RTP streams and the application semantics by defining extensions to RTP and RTCP messages. It defines a new SDP attribute, RTCP SDES message and RTP header extension for this puropose. The document explains how it can be used with the different multiplexing proposal (Plan A, Plan B and no plan). It can be used also in CLUE to map SSRCs to Clue media capture. Please review and send comments Thanks Roni Even ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, June 28, 2013 6:27 PM To: Jonathan Lennox; Qin Wu; Roni Even Subject: New Version Notification for draft-even-mmusic-application-token-00.txt A new version of I-D, draft-even-mmusic-application-token-00.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-mmusic-application-token Revision: 00 Title: The Session Description Protocol (SDP) Application Token Attribute Creation date: 2013-06-28 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-application-token-00.txt Status: http://datatracker.ietf.org/doc/draft-even-mmusic-application-token Htmlized: http://tools.ietf.org/html/draft-even-mmusic-application-token-00 Abstract: The RTP fixed header includes the payload type number and the SSRC values of the RTP stream. RTP defines how you de-multiplex streams within an RTP session, but in some use cases applications need further identifiers in order to identify the application semantics associated with particular streams within the session. This document defines a mechanism to provide the mapping between the SSRCs of RTP streams and the application semantics by defining extensions to RTP and RTCP messages. The IETF Secretariat _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic