From nobody Sun Jun 1 00:50:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAEA1A01AA; Sun, 1 Jun 2014 00:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uwopTe_XAwD; Sun, 1 Jun 2014 00:50:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E8E1A0189; Sun, 1 Jun 2014 00:50:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140601075026.29663.52898.idtracker@ietfa.amsl.com> Date: Sun, 01 Jun 2014 00:50:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZPo2ayfODMx_Pf8wu-_IQBKy8fg Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 07:50:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Authors : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-07.txt Pages : 16 Date : 2014-06-01 Abstract: This document describes behavior of signaling intermediaries in Real- Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. Latching, which is one of the components of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of latching mechanism over the Internet and recommends other solutions such as the Interactive Connectivity Establishment (ICE) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-latching-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 1 00:51:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7611A018C for ; Sun, 1 Jun 2014 00:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8K-G-BWCCnL for ; Sun, 1 Jun 2014 00:50:57 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AE01A01B1 for ; Sun, 1 Jun 2014 00:50:54 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so3668553wes.21 for ; Sun, 01 Jun 2014 00:50:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NmCjh7AWgdADcf+cXhbltMPY08TbP6oaLVqmkQMGgNg=; b=jM0oX/OC/bxa1srepM7ZMaHS7msyN+wYSVru/5TcMIrTWFcLRgAFqTClCLBSCux58U XVf+9nNf0fu1dKe6zYc0Gwad1xrwj2WWn0jkB7mx3Xmp9w0vUeOiEFnsQHCilixnIDxH F/goFL4XsZlTlyzuM0rsB1efQ22o7kcWQK4ZUfPaU0PoqoqZPz1VpwlHZJaoKB+AfC6e oMysiAVZu94fAoOCPAON1aHI4jl6rRWb7MCnJKH6lgz8+GJL0BPmSRfjDFCUtqhJ2vIQ Y1iq8XkdtDY2hEaC2jGOihlmEMAMWotxUXcu3MSfFS5klMGCkI8kckG24+gVMvw2sPbZ cwOQ== X-Gm-Message-State: ALoCoQmjMElR9l8iKEn88RhpnYRVYtVI0G9vPqGUVA5LjymEcCWF0d6rnehvKv2+R7ZNbYk7wl2j X-Received: by 10.194.62.140 with SMTP id y12mr39357878wjr.27.1401609047950; Sun, 01 Jun 2014 00:50:47 -0700 (PDT) Received: from camionet.local (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id b1sm24832355wjb.37.2014.06.01.00.50.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 00:50:46 -0700 (PDT) Message-ID: <538ADB54.1060109@jitsi.org> Date: Sun, 01 Jun 2014 09:50:44 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Parthasarathi R , 'Hadriel Kaplan' , "'Dan Wing (dwing)'" References: <20140529164031.26486.54207.idtracker@ietfa.amsl.com> <001101cf7d29$e5e75d30$b1b61790$@co.in> In-Reply-To: <001101cf7d29$e5e75d30$b1b61790$@co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hEj5_hNFKFevGRkxxsqJmW5JykQ Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 07:51:01 -0000 Sure. Fixed. On 01.06.14, 01:41, Parthasarathi R wrote: > Hi all, > > The minor text comment in the introduction for the below text: > > "It is however worth pointing out that the current > deployment levels of HNT and NATs themselves make an exclusive > adoption of ICE highly unlikely in the foreseeable future." > > I agree with you that the above text is correct when the initial draft is > written on June 2012 > (http://tools.ietf.org/html/draft-ivov-mmusic-latching-00). Because WebRTC > mandated ICE, the above scenario is changed drastically now and lot of > SBC/intermediates supports ICE as one of the NAT traversal mechanism today. > In case you revise this draft once more, Please consider for updating the > text or remove this line to reflect the current status. > > Thanks > Partha > >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Thursday, May 29, 2014 10:11 PM >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-06.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Multiparty Multimedia Session Control >> Working Group of the IETF. >> >> Title : Latching: Hosted NAT Traversal (HNT) for >> Media in Real-Time Communication >> Authors : Emil Ivov >> Hadriel Kaplan >> Dan Wing >> Filename : draft-ietf-mmusic-latching-06.txt >> Pages : 16 >> Date : 2014-05-29 >> >> Abstract: >> This document describes behavior of signalling intermediaries in >> Real-Time Communication (RTC) deployments, sometimes referred to as >> Session Border Controllers (SBCs), when performing Hosted NAT >> Traversal (HNT). HNT is a set of mechanisms, such as media relaying >> and latching, that such intermediaries use to enable other RTC >> devices behind NATs to communicate with each other. >> >> This document is non-normative, and is only written to explain HNT >> in >> order to provide a reference to the IETF community, as well as an >> informative description to manufacturers, and users. >> >> Latching, which is one of the components of the HNT components, has >> a >> number of security issues covered here. Because of those, and >> unless >> all security considerations explained here are taken into account >> and >> solved, the IETF advises against use of latching mechanism over the >> Internet and recommends other solutions such as the Interactive >> Connectivity Establishment (ICE) protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-mmusic-latching-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-06 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > -- https://jitsi.org From nobody Sun Jun 1 22:09:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1811A028D for ; Sun, 1 Jun 2014 22:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOOkGQUAwu_I for ; Sun, 1 Jun 2014 22:09:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BB61A0289 for ; Sun, 1 Jun 2014 22:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2792; q=dns/txt; s=iport; t=1401685772; x=1402895372; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rfscdtJYraXjpD+fAOi79iyMieLOifZWMceubrrXAJQ=; b=i2HYrxcr2FUipijE79Tk0GigKx8lUEMOh7DTiTRX9RxuwAMuJOXJtWv9 gODhRHdGRV3UbFfXaVBXoM74jkOfD4sxPSOQFD8SwcnjD5mwiKEeUBy/e Y9kEWOfiqPK5/3j9XRgOR6FRWuhwA2J5ODPmA/h8k4+P0M4itk15rQZPU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugLAMIGjFOtJA2G/2dsb2JhbABZgwdSVQOqLAEBAQEBB5BihmhRAYEOFnSCJQEBAQQBAQE3FCAGEQQCAQgRAwEBAQsCEgkHJwoBFAkIAgQTCAELBwIEiCEN1AYXhVWFboI8IjMFBoMlgRUEmz6Lf4VwgXiBQGyBCjk X-IronPort-AV: E=Sophos;i="4.98,955,1392163200"; d="scan'208";a="329733378" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 02 Jun 2014 05:09:20 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5259KOv021251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Jun 2014 05:09:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.220]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 00:09:20 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 7261 on Offer/Answer Considerations for G723 Annex A and G729 Annex B Thread-Index: AQHPfFDCrRiLqt8Dl0aInTkkhPMLuJtdRbQQ Date: Mon, 2 Jun 2014 05:09:19 +0000 Message-ID: References: <20140530214636.CB31518000F@rfc-editor.org> In-Reply-To: <20140530214636.CB31518000F@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.104.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-GFCK2XDV1xvEjSFCobVMKpeydM Subject: Re: [MMUSIC] RFC 7261 on Offer/Answer Considerations for G723 Annex A and G729 Annex B X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 05:09:39 -0000 Thanks to the WG for all the reviews and thanks to the chairs for promptly = following up on all issues till the final stage. -Authors |-----Original Message----- |From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of rfc-editor@rfc-= editor.org |Sent: Saturday, May 31, 2014 3:17 AM |To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org |Cc: drafts-update-ref@iana.org; mmusic@ietf.org; rfc-editor@rfc-editor.org |Subject: [MMUSIC] RFC 7261 on Offer/Answer Considerations for G723 Annex A= and G729 Annex B | |A new Request for Comments is now available in online RFC libraries. | | | RFC 7261 | | Title: Offer/Answer Considerations for G723 Annex | A and G729 Annex B | Author: M. Perumal, P. Ravindran | Status: Standards Track | Stream: IETF | Date: May 2014 | Mailbox: mperumal@cisco.com, | partha@parthasarathi.co.in | Pages: 8 | Characters: 14097 | Updates/Obsoletes/SeeAlso: None | | I-D Tag: draft-ietf-mmusic-sdp-g723-g729-06.txt | | URL: http://www.rfc-editor.org/rfc/rfc7261.txt | |This document provides the offer/answer considerations for the annexa |parameter of G723 and the annexb parameter of G729, G729D, and G729E |when the value of the annexa or annexb parameter does not match in |the Session Description Protocol (SDP) offer and answer. | |This document is a product of the Multiparty Multimedia Session Control Wo= rking Group of the IETF. | |This is now a Proposed Standard. | |STANDARDS TRACK: This document specifies an Internet standards track |protocol for the Internet community,and requests discussion and suggestion= s |for improvements. Please refer to the current edition of the Internet |Official Protocol Standards (STD 1) for the standardization state and |status of this protocol. Distribution of this memo is unlimited. | |This announcement is sent to the IETF-Announce and rfc-dist lists. |To subscribe or unsubscribe, see | http://www.ietf.org/mailman/listinfo/ietf-announce | http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist | |For searching the RFC series, see http://www.rfc-editor.org/search |For downloading RFCs, see http://www.rfc-editor.org/rfc.html | |Requests for special distribution should be addressed to either the |author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless |specifically noted otherwise on the RFC itself, all RFCs are for |unlimited distribution. | | |The RFC Editor Team |Association Management Solutions, LLC | | |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Jun 2 05:31:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01111A0313 for ; Mon, 2 Jun 2014 05:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaNENWFuED6R for ; Mon, 2 Jun 2014 05:31:09 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879E61A01EB for ; Mon, 2 Jun 2014 05:31:08 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-09-538c6e85ae16 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 43.5D.16420.58E6C835; Mon, 2 Jun 2014 14:31:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 14:31:00 +0200 From: Christer Holmberg To: Roni Even , 'Bernard Aboba' , "mmusic@ietf.org" Thread-Topic: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt Thread-Index: AQHPVaN5WvGalTaPX0i13vmV4oIK3ZsMn3HrgAgEirCAABDMgIAAwXYAgAAylrCAACznAIBIO6jw Date: Mon, 2 Jun 2014 12:31:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34C62B@ESESSMB209.ericsson.se> References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com>, <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com>, <7594FB04B1934943A5C02806D1A2204B1D2CC7BB@ESESSMB209.ericsson.se> <011201cf5a21$8767a150$9636e3f0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D2CD51D@ESESSMB209.ericsson.se> <014301cf5a51$45d2afc0$d1780f40$@gmail.com> In-Reply-To: <014301cf5a51$45d2afc0$d1780f40$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D34C62BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+JvjW5rXk+wwZaHhhb7l1xmtti/+Dyz xdTlj1ks/rYzO7B47Jx1l93jcc8ZNo8lS34yebQ9u8MewBLFZZOSmpNZllqkb5fAlbHqQANb wdyCinVT37E1MJ5O6WLk4JAQMJG4fEKxi5ETyBSTuHBvPVsXIxeHkMBRRom7B5ewgCSEBBYx Smx5bAdSzyZgIdH9TxskLCJQJbH2QQ8biM0soCXxf+4VdhBbWCBeYtnNSYwQNQkSF5fPYYew oyTenF4NFmcRUJG42rOfCcTmFfCVOHDpKyvE3sXMEjMaVoAVcQLtOtT1DqyZEei476fWMEEs E5e49WQ+E8TRAhJL9pxnhrBFJV4+/scKYStK7DzbzgxRny8xddY9RohlghInZz5hmcAoOgvJ qFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uTctONjPVSizKTi4vz 8/TyUks2MQJj8uCW36o7GC+/cTzEKMDBqMTDq+DdEyzEmlhWXJl7iFGag0VJnPeiRnWwkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYirc9lLwzN9SeWOH4VM2Tyk5iR0Kbj/0V3bu8c/4Xp 33psrB/dLQ7Q3DQts1hi35HkE2suFG+8e/NVzczS+PYtiew9c7vTVlxtcTn0Nvb4D+HzT8Rj TlnkVUv8MT9hcnZizGSem6vexXS885oaOlVa8SZ36L4FdTG2T5wYI3pufs1a2Z+d0qXEUpyR aKjFXFScCACfqqvnqgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4_kA25XNI_XADE0pSHroAAZY45o Cc: 'Jonathan Lennox' Subject: Re: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 12:31:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D34C62BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, What is the way forward regarding the draft? Especially regarding the parts that BUNDLE need, i.e. the offerer being abl= e to map received RTP packets from the answerer, we need to get done. Regards, Christer From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 17. huhtikuuta 2014 18:26 To: Christer Holmberg; 'Bernard Aboba'; mmusic@ietf.org Cc: 'Jonathan Lennox' Subject: RE: [MMUSIC] New Version Notification for draft-even-mmusic-applic= ation-token-03.txt Hi, Inline Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 17 April, 2014 1:50 PM To: Roni Even; 'Bernard Aboba'; mmusic@ietf.org Cc: 'Jonathan Lennox' Subject: RE: [MMUSIC] New Version Notification for draft-even-mmusic-applic= ation-token-03.txt Hi, >By no semantics we meant that it is just a token with no parameters that m= aps the RTP stream >(packet stream) to a description in the SDP m-line. Well, then that IS the semantics :) > (we agreed to take out the SSRC like functionality and have it at the end= of the document as issues > that we may want to address for simulcast for = example) > It addressed the cases described by Christer where the RTP arrives before= the SDP answer but also > on the send direction for cases where the offere= r does not know the SSRC that will be used (see for > example of the three = camera case bellow) Is there a reason why you don't call the 'appId' attribute 'send-appId' ins= tead? [Roni Even] No reason and we may have a different name for appId, was discu= ssed on the list. We assume appId is sent-appId Also, assuming the previous answerer in a subsequent O/A exchange becomes t= he offerer, which attribute (if any) does it include in the Offer? You need= to describe how a change of the Offerer/Answerer roles affect affects the = usage. [Roni Even] The current text talks about having the answer use the recv-app= Id as the appId. We need to add text about subsequent offer/answer, do we mandate keeping cu= rrent appId. Other issue we have is if we need to send appId (send-appId) or can only se= nd the recv-appId Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D34C62BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 <= /p>

What is the way forward r= egarding the draft?

 <= /p>

Especially regarding the = parts that BUNDLE need, i.e. the offerer being able to map received RTP pac= kets from the answerer, we need to get done.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Roni Eve= n [mailto:ron.even.tlv@gmail.com]
Sent: 17. huhtikuuta 2014 18:26
To: Christer Holmberg; 'Bernard Aboba'; mmusic@ietf.org
Cc: 'Jonathan Lennox'
Subject: RE: [MMUSIC] New Version Notification for draft-even-mmusic= -application-token-03.txt

 

Hi,

Inline<= /p>

Roni

 <= /p>

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: 17 April, 2014 1:50 PM
To: Roni Even; 'Bernard Aboba'; m= music@ietf.org
Cc: 'Jonathan Lennox'
Subject: RE: [MMUSIC] New Version Notification for draft-even-mmusic= -application-token-03.txt

 

Hi,

 = ;

>By no semantics we me= ant that it is just a token with no parameters that maps the RTP stream >= ;(packet stream) to a description in the SDP m-line.

 <= /p>

Well, then that IS the se= mantics :)

 <= /p>

> (we agreed to take o= ut the SSRC like functionality and have it at the end of the document as is= sues > that we may want to address for simulcast for example)=

> It addressed the cas= es described by Christer where the RTP arrives before the SDP answer but al= so > on the send direction for cases where the offerer does not know the SSRC that will be used (see for > example of the three cam= era case bellow)

 <= /p>

Is there a reason why you= don’t call the ‘appId’ attribute ‘send-appId’= ; instead?

[Roni Even] No reas= on and we may have a different name for appId, was discussed on the list. W= e assume appId is sent-appId=

 <= /p>

Also, assuming the previo= us answerer in a subsequent O/A exchange becomes the offerer, which attribu= te (if any) does it include in the Offer? You need to describe how a change of the Offerer/Answerer roles affect affects the usage.<= /o:p>

 <= /p>

[Roni Even] The cur= rent text talks about having the answer use the recv-appId as the appId.

We need to add text= about subsequent offer/answer, do we mandate keeping current appId.

 

Other issue we have= is if we need to send appId (send-appId) or can only send the recv-appId

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

--_000_7594FB04B1934943A5C02806D1A2204B1D34C62BESESSMB209erics_-- From nobody Mon Jun 2 06:32:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7BD1A0204 for ; Mon, 2 Jun 2014 06:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1uegbucS9Hh for ; Mon, 2 Jun 2014 06:32:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014D11A020B for ; Mon, 2 Jun 2014 06:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1814; q=dns/txt; s=iport; t=1401715923; x=1402925523; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=vnudm2px71Lmeueq+TQLUt/7mmDHHQRj+YOPO7cUFpI=; b=OzD+vSKOu2tQTMY5vaqDOt77TQLQEU/3QmjCNt/pznQ6WQcQWqO9B82r iE7i1gTAWWwDf6xvYr1TbDmy8BWdAu+jQm8IuGIykbdscF37nRv3ST3eL L9/eI0np/d4Z5WQNw41tSqDA6BLr8ERNLDeKclCe1iM0Jmf5jpl6lCumP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAH97jFOtJA2I/2dsb2JhbABZgmUiUljCVAGBERZ0gicBBDo/EgEqFEImAQQODQGIOQEM1F4XjiExAoMwgRUErS2DOGyBQw X-IronPort-AV: E=Sophos;i="4.98,957,1392163200"; d="scan'208";a="329887133" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jun 2014 13:32:02 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s52DW2MW008385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 13:32:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 08:32:01 -0500 From: "Ali C. Begen (abegen)" To: "mmusic@ietf.org" Thread-Topic: SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03 Thread-Index: Ac9+Y66Ocav9Dh7wS1ebifdoOraAxg== Date: Mon, 2 Jun 2014 13:32:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.222.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/pwxohAGhVW_x0tQihMXeYQ7zBes Cc: "draft-ietf-xrblock-rtcp-xr-post-repair-loss-count@tools.ietf.org" Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 13:32:10 -0000 I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at=0A= =0A= http://www.ietf.org/iesg/directorate/sdp.html=0A= =0A= Please wait for direction from your document shepherd or AD before posting = a new version of the draft.=0A= =0A= Summary:=0A= - There are some statements that need to be modified slightly. See below.= =0A= - There are quite a few grammatical/capitalization/spelling errors. I liste= d the ones I caught. Please proofread the document.=0A= - The registry and SDP usage seem correct.=0A= =0A= Comments:=0A= =0A= - Intro: s/RTCP SR/RR/RTCP sender and receiver reports (SR and RR)=0A= =0A= - Intro: s/cumulative number of packet lost/cumulative number of packets lo= st =0A= =0A= - Rather than referring to RFC 5109, I prefer you to refer to FEC Framework= (RFC 6363). =0A= =0A= - Intro, end of 1st parag: "at the cost of higher overhead": For someone wh= o does now know 5725, this statement is confusing. Higher compared to what?= =0A= =0A= - Intro, 2nd parag: =0A= s/range of RTP application/range of RTP applications=0A= s/sequence number range inconsistent/sequence number range inconsistency=0A= =0A= - Intro, 2nd parag: "lost after applying one or more loss repair mechanisms= ": Actually, this should say something like "lost after applying all availa= ble loss repair mechanisms as a lost packet should not be reported in your = report if it can still be recovered.=0A= =0A= - Use of 2119 keywords in the intro is not allowed AFAIK. Refrain from usin= g them. =0A= =0A= - Similarly, the use of lower case 2119 keywords after introduction is not = encouraged. So, refrain from such use as well.=0A= =0A= - RFCs 4588 and 5109 (or 6363) should be informative not normative.=0A= From nobody Mon Jun 2 07:47:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3011A0358; Mon, 2 Jun 2014 07:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFN0q7d96nAn; Mon, 2 Jun 2014 07:18:18 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80B41A0340; Mon, 2 Jun 2014 07:18:09 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s52EI1ba000986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Jun 2014 09:18:01 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s52EI0am028166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2014 09:18:00 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s52EHwZk024804; Mon, 2 Jun 2014 09:17:59 -0500 (CDT) Message-ID: <538C8820.1090900@bell-labs.com> Date: Mon, 02 Jun 2014 09:20:16 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Emil Ivov , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> In-Reply-To: <538663F1.4080709@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cUy4DeSaSB8prvNfsFopK8QQvT4 X-Mailman-Approved-At: Mon, 02 Jun 2014 07:47:50 -0700 Cc: IESG IESG , mmusic Subject: Re: [MMUSIC] [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 14:18:27 -0000 On 05/28/2014 05:32 PM, Emil Ivov wrote: > Hey Vijay, > > Thanks for your review! Comments inline. Emil: Thank you for indulging me. More inline (please see to end). I have taken out items of agreement and only list those where more discussion is required. For reference, my original review is at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12014.html). >> SDP is as much of a standard as SIP is, no? Maybe you mean to say that >> because of the complexity of representing SIP messages, the SIP portion >> of a RTC component's stack may vary between implementations and deploy- >> ments. SDP, being a simpler protocol (at least syntactically), is not >> exposed to such vagaries. Yes? > > Yes, exactly. [...] > On the other hand there only so many ways you can change an IP address > in SDP. So, how about the following wording? > > SIP's many features in terms of controlling message routing provide > for various ways of addressing NAT traversal. As a result, the HNT > component for SIP is typically more implementation-specific and > deployment-specific than the SDP and media components. > > Would this be better? Yes, much improved. One minor modification to the suggested text: s/SIP's many features in terms of controlling message routing provide for various ways of addressing NAT traversal./ SIP uses numerous expressive primitives for message routing and, consequently, NAT traversal./ >> - S3, second paragraph: "newly introduced media relay" --- newly >> introduced to who? [...] > So how about this? > > While this is not necessary for HNT to work, quite often, the IP > address of that media relay may be the same as that of the signaling > intermediary (i.e. the SIP SBC and media relay are co-located on the > same host). Also, in almost all cases, the address of the media > relay would belong to the same IP address family as the one used for > signaling, as it is known to work for that UA. > > Is this better or do you prefer the original? The problem with qualifying phrases like "In almost all cases" is that one wonders what happens in other cases? What do you think about the following text: In typical deployments, the media relay and signaling intermediary (the SBC) are co-located, thereby sharing the same IP address family. This works well because the UA also shares the same IP address family. In deployments where the media relay belongs to a different address family, the signaling intermediary would rewrite it to correspond to the address family of the UA. Feel free to push back and modify if this does not convey the right semantics (especially the "In deployments..." part). >> - S4, the descriptional steps below the text "The latching mechanism >> works as follows:" will be improved if you used "UAC" or "UAS" instead >> of "UA" (I recognize that in SIP it is not necessary that the UAC >> make the first offer, but these steps are for illustrative purposes >> and it helps to be as clear as we can for neophyte readers). Even >> much better if you could cast the actors in terms of the principals >> Alice and Bob that appear in Figures 2. So, something like "After >> receving an offer from Alice (UAC) who is behind a NAT" is preferable >> (I think) to "After receiving an offer from a NATed UA". > > I agree this can be said better. What would you say about: > > This way, while a session is still being setup, the signalling > intermediary is not yet aware what addresses and ports the caller > and the callee would end up using for media traffic: it has only > seen them advertise the private addresses they use behind their > respective NATs. Therefore media relays used in HNT would often use > a mechanism called "latching". Umm ... I think there is a bit of a disconnect here. I am referring to all steps 1 - 6 above. See next comment; it is related. >> - S4, the numbered steps in Figure 2: change UAC to Alice in all of >> the steps, and change UAS to Bob in all of the steps. Easier for >> neophyte readers to follow. Alternatively, you may put "(UAC)" >> above Alice and "(UAS)" above Bob to impart the same semantics. > > Agreed! Would be much better! > >> - S4, Figure 2: the text between step 12 and step 13 ("(SBC latches >> to source IP address and port seen in (10))" --- what is this >> referring to? Is it referring to the latching created by Alice? >> or Bob? It is not clear, specially since I am not sure if the >> "(10)" in the text I quote is a typo or not. Maybe you meant >> "(7)" or maybe "(2)"? > > Latching happens as soon as the first media packet arrives so this meant > (11). Thanks for the catch and sorry about the confusion! No worries. >> - S4, Figure 2, step 13: Much as you do in step 11, you should >> spell out the "dest" field here as well. So, >> s/RTP/RTP, dest=198.51.100.2:22007/ > > OK, that's going to require some ASCII art magic because we are out of > place there already but I do agree it would be useful :) Sure; will be helpful if put in. >> - S5, first paragraph, line 12: s/onto packets/onto media packets/ > > Well they don't need to be media. They would be ignored even if they > weren't. WDYT? Yes, you are right. Disregard that comment. >> - S5, first paragraph, line 14: "... a range of IP addresses belonging >> to the same network..." Here, "same" as which one? I suspect you >> mean the attacker's network. But being explicit is better here. > > It means the same as the one that the source address of the signalling > packets belongs to. How about this: > > In some cases the > limitation may be loosened to allow media from a predefined range of > IP addresses in order to allow for use cases such as decomposed UAs Yes, much better. >> - S5, first paragraph, towards the end: "widen the gap for potential >> attackers..." Here, I suspect you mean that it provides the attackers >> more IP address from which to mount attacks, i.e., advantage: >> attackers. Yes? > > Yes. Is this a clarifying question or do you think it would be better if > changed that way? I think it is better to say that "it provides the attackers a larger attack surface" (or something similar). Using the phrase "widen the gap" is ambiguous. One can read that as widening the gap between attacker and defender (i.e., advantage defenders). >> - S5, third paragraph: I am not sure I understand case (2). Why would >> an SBC latch on to an attacker if it is using restricted latching? [...] > Well, automated UAs are often less picky than humans about the kind of > media they get (if at all) and the intention was to warn aout that > option. Happy to remove it if you find it unnecessary. No leave all that in. As I re-read my comment on case (2), it seems that I may have been in error. If the attacker is behind the same NAT as the legitimate SIP UA, then what you describe is good. >> - S5, fourth paragraph: "For example, in cases where end-to-end >> encryption is used it would still be possible for an attacker to >> hijack a session despite the use of SRTP and perform a denial of >> service attack. However, media integrity would not be compromised." >> >> Can you explain more broadly how the above would work? If we assume >> that the endpoints exchange keys end-to-end and create secure channels >> end-to-end, how would the attacker hijack a session? (Heartbleed and >> all such mechanisms aside, of course. If we assume keys are derived >> end-to-end and don't follow the hop-by-hop model, how would the >> attacker prevail?) > > End-to-end was probably not the best choice of words here. Imagine > something like ZRTP though. Given that such mechanisms rely exclusively > on the media path for key negotiation, there would be no way for the SBC > to authenticate the UA so it would still latch onto the wrong endpoint. > Obviously ZRTP's authentication would prevent from an actual MitM attack > but given that it's already on the media path, the attacker can simply > stop relaying media and effectively perform a DoS. Does this make sense? Yes, more now. But, I think you will have to describe this attack using ZRTP as an example in some more detail since there are various issues at work here (the SBC not being able to authenticate the endpoint using ZRTP, etc.). I suspect that the security ADs may ask you to do this anyway during IESG review. Of course, if they don't you are free to proceed, but as a matter of principle, it is best to explain the security threat in enough detail that someone building these things can appreciate the reasoning. (In the current form, at least I had questions on the scenario you had in mind, hence the comment.) >> - Abstract, 3rd paragraph: >> s/components of the HNT components/components of HNT/ > > thanks > >> In fact, the entire 3rd paragraph could be written more succinctly as >> follows: >> >> Latching, one of the components of HNT, has a number of security >> issues detailed in this document. Based on the known threats, the >> IETF advises against use of this mechanism on the Internet and >> recommends other solutions, such as the Interactive Connectivity >> Establishment (ICE) protocol. > > That paragraph was the result of literally tens of back and forths so, > unless you think this is paramount, I think it would be better to keep > it as is. Specifically, the above version is missing on the fact that a) > using SRTP allows for the security concerns to be addresses and the > mechanism becomes acceptable b) sometimes the security concerns simply > don't come into play (e.g. public conferences) c) there are controlled > environments where security is taken care of in another way. Hmmm ... I don't see that the original version attends to (a), (b) and (c) any more explicitly than the above version, but I will defer to your judgment here. Since the paragraph is crafted through a hard-won battle, please feel free to retain it. >> - S4, first paragraph: s/couple/tuple/ > > well, in this case the text does refer to the address:port couple but I > am ok with changing that to the "addres:port/transport" tuple (or triplet?) Stevens used "tuple" in his seminal TCP books. I personally think "tuple" is better (and it is devoid of ordinal value, i.e., there can be a 2-tuple, a quintuple, sextuple, etc.). If, however, you'd like to leave it as "couple", no problem. >> - S4, Figure 3: why not use the principals Alice and Bob here as >> well instead of "XMPP Client 1" and "XMPP Client 2"? > > Frankly the main reason was because it otherwise looks exactly like SIP > and it becomes confusing. But I don't mind switching to Romeo and Juliet > (which are XSF's protagonists of choice ;) ). Sure. Out of curiosity, who is XSF's Eve? Thanks for your time on this, Emil. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Thu Jun 5 18:09:14 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6BF1A0371 for ; Thu, 5 Jun 2014 18:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCMAxWNdk_XQ for ; Thu, 5 Jun 2014 18:09:08 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B400A1A0369 for ; Thu, 5 Jun 2014 18:09:08 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id db12so2239482veb.39 for ; Thu, 05 Jun 2014 18:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=RFF1TfkN1NCWQ0vfW5sNxt+W04RH2fClGsdCSPHYXaw=; b=MwgxlhDMWSC1lUsWr7xV0HTWAFyfde/qz7oIBJPEnn8BNr9SaJyC24iu1QsOzc5K+P qQfj1w0jcqU7az8eYeUZYcWsinZ3fFJgre6YgJBiRX7dZwMwxVloyHZ8vq1UmXUaZHiI RIZBRYk2mApS91cT/tSlkfMRWd/Lsrq8lSmY7htV7OmVPo+nzh5c52cRuGIdCUjEbMAD L2WIFcbSRllB3nQsSbdox9BwcKioavQS1E9QjJA4Ez8jN5lZBO+tyhA7Dqxwy1c7T+yK zamAiNRkF+M3RP8DThObSoo8Dv0TXz8uhFz2MCWwbnqPXoMjh9rg/F71jk96cwE+jaUc u9zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=RFF1TfkN1NCWQ0vfW5sNxt+W04RH2fClGsdCSPHYXaw=; b=RgnxpHcaHOWEvHaEKqB7j/cUfrNNxcz1T0GsniCSj/YEP6nLC5JYK75riSQyf3vtbF mpIR3H1nZv6Xqn4jnJYOE9P2bVNTl9TKyaNwfths8KqsZpA/Gd9Qw0Guzn1Wv1sk35Lc 9Wb2JOtGL5voFRQa+GtUnQnHHyTOv2ytGddeFpoV2agVWsqeqFCjZ6J1RzRW6KlcLBrv vm5RyqOYj+Qo+PbW3ndEJqqaFGFPILXAM7421bCXtM27TQDDdkuX8xSzL8BGmMq/tzHA erqClgeaDmwOc89BRfNmwDqhAvlHKrXkZe8iXA5kea96eQbGsv+YaSGqpcB4SuHo0u/p ucRg== X-Gm-Message-State: ALoCoQkldaGl6FRMc6hVYr0L9TYT3Tih3n3xp/OzMm3uCczDEwG1m6+nmgChmrtVA/i8OBFv86IV X-Received: by 10.58.216.34 with SMTP id on2mr1562491vec.22.1402016940699; Thu, 05 Jun 2014 18:09:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Thu, 5 Jun 2014 18:08:40 -0700 (PDT) From: Justin Uberti Date: Thu, 5 Jun 2014 18:08:40 -0700 Message-ID: To: "mmusic@ietf.org" , Mallinath Bareddy , Jiayang Liu , Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b6d8574b853e304fb2081e4 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/isyEwdluHuTl5mMnVUDrmawBnIU Subject: [MMUSIC] ICE PRIORITY with multiple TURN servers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 01:09:10 -0000 --047d7b6d8574b853e304fb2081e4 Content-Type: text/plain; charset=UTF-8 Consider the case where a single endpoint has 2 TURN servers, and allocates a relay candidate from both, from the same local IP. What should their PRIORITY values be? Quoth 5245, S 4.1.2: Each candidate for a media stream MUST have a unique priority that MUST be a positive integer between 1 and (2**31 - 1). OK, so they have to have different priorities, i.e. either their type preference or local preference must be different. But then, looking at S 4.1.2.1: The type preference MUST be identical for all candidates of the same type and MUST be different for candidates of different types. Hmm, this means their local_preference must be different. But later in S 4.1.2.1: The local preference MUST be an integer from 0 to 65535 inclusive. It represents a preference for the particular IP address from which the candidate was obtained, in cases where an agent is multihomed. Obviously, if they come from the same local IP, this cannot be satisfied. What to do? It seems like the easiest solution would be to use some of the local preference to represent the ordering, so that both IP preference and server preference and represented, and therefore relay candidates from IPs 1 and 2 and Turn Servers A and B would stack rank as A1 B1 A2 B2 --047d7b6d8574b853e304fb2081e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Consider the case where a single endpoint has 2 TURN serve= rs, and allocates a relay candidate from both, from the same local IP. What= should their PRIORITY values be?

Quoth 5245, S 4.1.2:
=C2=A0 =C2=A0Each candidate for a media stream MUST have a unique=
=C2=A0 =C2=A0priority that MUST be a positive integer between 1 = and (2**31 - 1).

OK, so they have to have di= fferent priorities, i.e. either their type preference or local preference m= ust be different. But then, looking at S 4.1.2.1= :
=C2=A0 =C2=A0The type preference MUST be identical for all
<= div>=C2=A0 =C2=A0candidates of the same type and MUST be different for cand= idates of
=C2=A0 =C2=A0different types.

= Hmm, this means their local_preference must be different. But later in S 4.1.2.1:
=C2=A0 =C2=A0The local preference MUST be an integer from 0 to 65535 i= nclusive.
=C2=A0 =C2=A0It represents a preference for the par= ticular IP address from which
=C2=A0 =C2=A0the candidate was obta= ined, in cases where an agent is multihomed.

Obviously, if they come from the same local IP, t= his cannot be satisfied. What to do?

It seems like= the easiest solution would be to use some of the local preference to repre= sent the ordering, so that both IP preference and server preference and rep= resented, and therefore relay candidates from IPs 1 and 2 and Turn Servers = A and B would stack rank as
A1
B1
A2
B2
--047d7b6d8574b853e304fb2081e4-- From nobody Fri Jun 6 00:12:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2342A1A010A for ; Fri, 6 Jun 2014 00:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiNgmwgvfJQq for ; Fri, 6 Jun 2014 00:12:06 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 31B521A00C5 for ; Fri, 6 Jun 2014 00:12:06 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 2A59A23F0574; Fri, 6 Jun 2014 09:11:59 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 09:11:58 +0200 From: "Stach, Thomas" To: Justin Uberti , "mmusic@ietf.org" , Mallinath Bareddy , Jiayang Liu , Eric Rescorla Thread-Topic: [MMUSIC] ICE PRIORITY with multiple TURN servers Thread-Index: AQHPgSPtCa0N0iwsfU2FCZjPJ+UUq5tjqW9A Date: Fri, 6 Jun 2014 07:11:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE1217AAEB31MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2U6kKBuEvGnj1KKPI_qYFl3kZ2c Subject: Re: [MMUSIC] ICE PRIORITY with multiple TURN servers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:12:08 -0000 --_000_F81CEE99482EFE438DAE2A652361EE1217AAEB31MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluLA0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IEZyZWl0YWcsIDYuIEp1bmkgMjAxNCAw MzowOQ0KVG86IG1tdXNpY0BpZXRmLm9yZzsgTWFsbGluYXRoIEJhcmVkZHk7IEppYXlhbmcgTGl1 OyBFcmljIFJlc2NvcmxhDQpTdWJqZWN0OiBbTU1VU0lDXSBJQ0UgUFJJT1JJVFkgd2l0aCBtdWx0 aXBsZSBUVVJOIHNlcnZlcnMNCg0KQ29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgZW5k cG9pbnQgaGFzIDIgVFVSTiBzZXJ2ZXJzLCBhbmQgYWxsb2NhdGVzIGEgcmVsYXkgY2FuZGlkYXRl IGZyb20gYm90aCwgZnJvbSB0aGUgc2FtZSBsb2NhbCBJUC4gV2hhdCBzaG91bGQgdGhlaXIgUFJJ T1JJVFkgdmFsdWVzIGJlPw0KDQpRdW90aCA1MjQ1LCBTIDQuMS4yOg0KICAgRWFjaCBjYW5kaWRh dGUgZm9yIGEgbWVkaWEgc3RyZWFtIE1VU1QgaGF2ZSBhIHVuaXF1ZQ0KICAgcHJpb3JpdHkgdGhh dCBNVVNUIGJlIGEgcG9zaXRpdmUgaW50ZWdlciBiZXR3ZWVuIDEgYW5kICgyKiozMSAtIDEpLg0K DQpPSywgc28gdGhleSBoYXZlIHRvIGhhdmUgZGlmZmVyZW50IHByaW9yaXRpZXMsIGkuZS4gZWl0 aGVyIHRoZWlyIHR5cGUgcHJlZmVyZW5jZSBvciBsb2NhbCBwcmVmZXJlbmNlIG11c3QgYmUgZGlm ZmVyZW50LiBCdXQgdGhlbiwgbG9va2luZyBhdCBTIDQuMS4yLjE8aHR0cDovLzQuMS4yLjE+Og0K ICAgVGhlIHR5cGUgcHJlZmVyZW5jZSBNVVNUIGJlIGlkZW50aWNhbCBmb3IgYWxsDQogICBjYW5k aWRhdGVzIG9mIHRoZSBzYW1lIHR5cGUgYW5kIE1VU1QgYmUgZGlmZmVyZW50IGZvciBjYW5kaWRh dGVzIG9mDQogICBkaWZmZXJlbnQgdHlwZXMuDQoNCkhtbSwgdGhpcyBtZWFucyB0aGVpciBsb2Nh bF9wcmVmZXJlbmNlIG11c3QgYmUgZGlmZmVyZW50LiBCdXQgbGF0ZXIgaW4gUyA0LjEuMi4xPGh0 dHA6Ly80LjEuMi4xPjoNCiAgIFRoZSBsb2NhbCBwcmVmZXJlbmNlIE1VU1QgYmUgYW4gaW50ZWdl ciBmcm9tIDAgdG8gNjU1MzUgaW5jbHVzaXZlLg0KICAgSXQgcmVwcmVzZW50cyBhIHByZWZlcmVu Y2UgZm9yIHRoZSBwYXJ0aWN1bGFyIElQIGFkZHJlc3MgZnJvbSB3aGljaA0KICAgdGhlIGNhbmRp ZGF0ZSB3YXMgb2J0YWluZWQsIGluIGNhc2VzIHdoZXJlIGFuIGFnZW50IGlzIG11bHRpaG9tZWQu DQoNCk9idmlvdXNseSwgaWYgdGhleSBjb21lIGZyb20gdGhlIHNhbWUgbG9jYWwgSVAsIHRoaXMg Y2Fubm90IGJlIHNhdGlzZmllZC4gV2hhdCB0byBkbz8NCltUU10gV2VsbCwgdGhhdCBwYXJhZ3Jh cGggY29udGludWVzOg0KDQogIFdoZW4gdGhlcmUgaXMgb25seSBhIHNpbmdsZSBJUCBhZGRyZXNz LCB0aGlzIHZhbHVlIFNIT1VMRCBiZSBzZXQgdG8NCiAgIDY1NTM1LiAgTW9yZSBnZW5lcmFsbHks IGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBjYW5kaWRhdGVzIGZvciBhDQogICBwYXJ0aWN1bGFyIGNv bXBvbmVudCBmb3IgYSBwYXJ0aWN1bGFyIG1lZGlhIHN0cmVhbSB0aGF0IGhhdmUgdGhlIHNhbWUN CiAgIHR5cGUsIHRoZSBsb2NhbCBwcmVmZXJlbmNlIE1VU1QgYmUgdW5pcXVlIGZvciBlYWNoIG9u ZS4NCg0KU28gdGhlIGNhc2Ugb2YgdHdvIFRVUk4gc2VydmVycyBpcyBjb3ZlcmVkLg0KV2hhdCB5 b3UgcHJvcG9zZSBiZWxvdyBpcyBPSywgYnV0IGlmIGRlc2lyZWQgeW91IGNvdWxkICBhbHNvIHJh bmsgQTEsIEEyLCBCMSwgQjIuIEl04oCZcyB5b3VyIGZyZWVkb20gb2YgY2hvaWNlLg0KUmVnYXJk cw0KVGhvbWFzDQoNCkl0IHNlZW1zIGxpa2UgdGhlIGVhc2llc3Qgc29sdXRpb24gd291bGQgYmUg dG8gdXNlIHNvbWUgb2YgdGhlIGxvY2FsIHByZWZlcmVuY2UgdG8gcmVwcmVzZW50IHRoZSBvcmRl cmluZywgc28gdGhhdCBib3RoIElQIHByZWZlcmVuY2UgYW5kIHNlcnZlciBwcmVmZXJlbmNlIGFu ZCByZXByZXNlbnRlZCwgYW5kIHRoZXJlZm9yZSByZWxheSBjYW5kaWRhdGVzIGZyb20gSVBzIDEg YW5kIDIgYW5kIFR1cm4gU2VydmVycyBBIGFuZCBCIHdvdWxkIHN0YWNrIHJhbmsgYXMNCkExDQpC MQ0KQTINCkIyDQo= --_000_F81CEE99482EFE438DAE2A652361EE1217AAEB31MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5KdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IEZyZWl0YWcsIDYuIEp1bmkg MjAxNCAwMzowOTxicj4NCjxiPlRvOjwvYj4gbW11c2ljQGlldGYub3JnOyBNYWxsaW5hdGggQmFy ZWRkeTsgSmlheWFuZyBMaXU7IEVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW01N VVNJQ10gSUNFIFBSSU9SSVRZIHdpdGggbXVsdGlwbGUgVFVSTiBzZXJ2ZXJzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbnNpZGVyIHRoZSBj YXNlIHdoZXJlIGEgc2luZ2xlIGVuZHBvaW50IGhhcyAyIFRVUk4gc2VydmVycywgYW5kIGFsbG9j YXRlcyBhIHJlbGF5IGNhbmRpZGF0ZSBmcm9tIGJvdGgsIGZyb20gdGhlIHNhbWUgbG9jYWwgSVAu IFdoYXQgc2hvdWxkIHRoZWlyIFBSSU9SSVRZIHZhbHVlcyBiZT88bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1b3RoIDUyNDUsIFMgNC4xLjI6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO0VhY2ggY2FuZGlkYXRlIGZvciBhIG1lZGlhIHN0cmVhbSBNVVNUIGhhdmUgYSB1bmlx dWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtwcmlvcml0eSB0aGF0IE1VU1QgYmUgYSBwb3NpdGl2ZSBpbnRlZ2VyIGJldHdl ZW4gMSBhbmQgKDIqKjMxIC0gMSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0ssIHNvIHRoZXkgaGF2ZSB0byBoYXZlIGRpZmZl cmVudCBwcmlvcml0aWVzLCBpLmUuIGVpdGhlciB0aGVpciB0eXBlIHByZWZlcmVuY2Ugb3IgbG9j YWwgcHJlZmVyZW5jZSBtdXN0IGJlIGRpZmZlcmVudC4gQnV0IHRoZW4sIGxvb2tpbmcgYXQgUw0K PGEgaHJlZj0iaHR0cDovLzQuMS4yLjEiPjQuMS4yLjE8L2E+OjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtUaGUg dHlwZSBwcmVmZXJlbmNlIE1VU1QgYmUgaWRlbnRpY2FsIGZvciBhbGw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjYW5kaWRh dGVzIG9mIHRoZSBzYW1lIHR5cGUgYW5kIE1VU1QgYmUgZGlmZmVyZW50IGZvciBjYW5kaWRhdGVz IG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ZGlmZmVyZW50IHR5cGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IbW0sIHRoaXMgbWVhbnMgdGhlaXIgbG9jYWxfcHJl ZmVyZW5jZSBtdXN0IGJlIGRpZmZlcmVudC4gQnV0IGxhdGVyIGluIFMNCjxhIGhyZWY9Imh0dHA6 Ly80LjEuMi4xIj40LjEuMi4xPC9hPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtUaGUgbG9jYWwgcHJlZmVyZW5jZSBNVVNU IGJlIGFuIGludGVnZXIgZnJvbSAwIHRvIDY1NTM1IGluY2x1c2l2ZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtJdCByZXBy ZXNlbnRzIGEgcHJlZmVyZW5jZSBmb3IgdGhlIHBhcnRpY3VsYXIgSVAgYWRkcmVzcyBmcm9tIHdo aWNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7dGhlIGNhbmRpZGF0ZSB3YXMgb2J0YWluZWQsIGluIGNhc2VzIHdoZXJlIGFu IGFnZW50IGlzIG11bHRpaG9tZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2J2aW91c2x5LCBpZiB0aGV5IGNvbWUgZnJvbSB0 aGUgc2FtZSBsb2NhbCBJUCwgdGhpcyBjYW5ub3QgYmUgc2F0aXNmaWVkLiBXaGF0IHRvIGRvPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUU10gV2VsbCwgdGhhdCBwYXJhZ3JhcGggY29u dGludWVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyBXaGVuIHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgSVAgYWRkcmVzcywgdGhp cyB2YWx1ZSBTSE9VTEQgYmUgc2V0IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyA2NTUzNS4mbmJzcDsgTW9yZSBnZW5l cmFsbHksIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBjYW5kaWRhdGVzIGZvciBhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBw YXJ0aWN1bGFyIGNvbXBvbmVudCBmb3IgYSBwYXJ0aWN1bGFyIG1lZGlhIHN0cmVhbSB0aGF0IGhh dmUgdGhlIHNhbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHR5cGUsIHRoZSBsb2NhbCBwcmVmZXJlbmNlIE1VU1QgYmUg dW5pcXVlIGZvciBlYWNoIG9uZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gdGhlIGNhc2Ugb2YgdHdv IFRVUk4gc2VydmVycyBpcyBjb3ZlcmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PldoYXQgeW91IHByb3Bvc2UgYmVsb3cgaXMgT0ssIGJ1dCBpZiBkZXNpcmVkIHlvdSBjb3VsZCZu YnNwOyBhbHNvIHJhbmsgQTEsIEEyLCBCMSwgQjIuIEl04oCZcyB5b3VyIGZyZWVkb20gb2YgY2hv aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRob21hczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgbGlrZSB0aGUgZWFzaWVzdCBzb2x1 dGlvbiB3b3VsZCBiZSB0byB1c2Ugc29tZSBvZiB0aGUgbG9jYWwgcHJlZmVyZW5jZSB0byByZXBy ZXNlbnQgdGhlIG9yZGVyaW5nLCBzbyB0aGF0IGJvdGggSVAgcHJlZmVyZW5jZSBhbmQgc2VydmVy IHByZWZlcmVuY2UgYW5kIHJlcHJlc2VudGVkLCBhbmQgdGhlcmVmb3JlIHJlbGF5IGNhbmRpZGF0 ZXMgZnJvbSBJUHMgMSBhbmQgMiBhbmQgVHVybiBTZXJ2ZXJzDQogQSBhbmQgQiB3b3VsZCBzdGFj ayByYW5rIGFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QjE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkEyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C MjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_F81CEE99482EFE438DAE2A652361EE1217AAEB31MCHP04MSXglobal_-- From nobody Fri Jun 6 03:52:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E641A045F; Fri, 6 Jun 2014 03:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvXzKYRA2IDK; Fri, 6 Jun 2014 03:52:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E05A1A0151; Fri, 6 Jun 2014 03:52:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606105200.32743.48558.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 03:52:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/wL0Q__S_PD6vkPO6St5IjtOaV24 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 10:52:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP) Authors : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-21.txt Pages : 32 Date : 2014-06-06 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams set up and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary RTSP extensions and procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 6 14:19:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ABF1A02A6 for ; Fri, 6 Jun 2014 14:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kClz9qcn_vn for ; Fri, 6 Jun 2014 14:19:25 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9871A0274 for ; Fri, 6 Jun 2014 14:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2388; q=dns/txt; s=iport; t=1402089558; x=1403299158; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=i0JRmWvwq+zEpoyzNTFYftCWTP+BIb95V1lGxO8A3cc=; b=Y6ul0/qonvup8aF4R5Tg5A0qG8fT3laDzQ5bU6q7MBRiaOyLztjRKVaa L7fHLRH6fTAyzdwXcutKLNOaAZpMAoXl+h6aoydsP0Ee55pVE8DlfFsD9 W88urgL8vpNqxJmrEOPi/AGyq4ltdycVM0PpWyity3h+7BvB/uujrCC5l E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGovklOtJA2L/2dsb2JhbABPCoJpJIErxAkBgQcWdYQFAQQ6UQEqFEImAQQbE4gnAZ8BrlIXjXwLBggCAgEeg2OBFgStYYM8gi8 X-IronPort-AV: E=Sophos;i="4.98,991,1392163200"; d="scan'208";a="50953305" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 06 Jun 2014 21:19:18 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s56LJIYY013730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Jun 2014 21:19:18 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 16:19:17 -0500 From: "Ali C. Begen (abegen)" To: "mmusic@ietf.org" Thread-Topic: 4566bis outstanding issues Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWg== Date: Fri, 6 Jun 2014 21:19:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.222.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/J4HjwVsC6EL85gTj4bD7fob--DI Subject: [MMUSIC] 4566bis outstanding issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 21:19:27 -0000 Hi everyone=0A= =0A= I went thru the mail archives since 01/2012 and tried to list the issues th= at seem to be unresolved at this point. I can put them in the tracker but I= wanna provide a summary first.=0A= =0A= For some of the issues below, no solution has been proposed. For the rest, = there was no agreement on what to do. Here it goes:=0A= =0A= 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defi= ned. =0A= =0A= Comments: This was discussed again in a side meeting in London and there wa= s not a consensus whether we actually needed this. =0A= =0A= 2) 4566bis should update the format of the IANA registries to reflect the d= ependency between addrtype and net type.=0A= =0A= Comments: There does not seem an agreement on this but it looks to be an ea= sy fix.=0A= =0A= 3) Section 8.2.4 defines the IANA registry and populates it with the attrib= utes defined in 4566, however, Section 8.2.4 does not specify the name or f= ormat of the table.=0A= =0A= Comments: No text has been proposed or agreed but seems to be an easy fix i= f we wanna do this.=0A= =0A= 4) 4566bis does not make the registration of new network or address types m= andatory. Section 8.2.6 and 8.2.7.=0A= =0A= Comments: If we agree that this should be mandatory, we can change the text= .=0A= =0A= 5) Source-level attributes defined in 5576. Should these attributes be incl= uded in the same table structure in the IANA registry? =0A= =0A= Comments: This seems to be an organizational issue rather than a technical = issue. If we agree we need this, we can take on this as well.=0A= =0A= 6) Should we add a new column called "registered network type" in the addrt= ype table in the IANA registry as not all address types are applicable for = all network types? =0A= =0A= Comments: This is also an IANA fix that we can do in this bis document or i= n a separate document (with all the other IANA registry changes).=0A= =0A= =0A= These are the issues I was able to identify. There is one more thing relate= d to ICE and I sent an email about this to Marc Petit-Huguenin. As soon as = he responds and depending on his answer, I might add one more issue.=0A= =0A= If there are things I missed, please let me know. The chairs and editors wo= uld like to close these issues and finalize 4566bis soon.=0A= =0A= Thanks.=0A= -acbegen= From nobody Fri Jun 6 15:03:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AF21A02AF for ; Fri, 6 Jun 2014 15:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px17NcTIHJh5 for ; Fri, 6 Jun 2014 15:03:15 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE011A0273 for ; Fri, 6 Jun 2014 15:03:15 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db11so4062064veb.36 for ; Fri, 06 Jun 2014 15:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WaKC01/jd1XS5EzHV4BpUOk3WrDeMdudw0uKVi8i65A=; b=CzcRAq1lWvDSBeACkd54iWQ969Dzj8m+H+Rwm6AbyQKgT89GEcfx1CRouBVgKGlZR7 Z/le7x/CvZmydhjbJJyfMkxg7ErnfertYRP//tI38YxQxMW/Kv2kePvAThdD4aXdXRfJ 9vZqsBA9eR2A/zWq0/IwUbmQgtvm5IhNm8SS3AjUoLePEGrKxDgDzpy8/fDX1/BL1wBe WJZp4IMp4jiIpB22heceftgWGmBx2i7U+E+o6dYL6gWU7Y8glXOyldto3AFzoNsNVcgU knTz/Tzhr6MYuzRyIULzAHm1Wq66Yx/NRKkhvwbxN/ImTtRHWroiF2+Tl/8mA112/cWr AjiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WaKC01/jd1XS5EzHV4BpUOk3WrDeMdudw0uKVi8i65A=; b=VonEtIKsgCMNU9tEDFGcfciqVwM/tDMS96/dlDukP3kaTvdK4kn4ioCECU88NkUn8G WEsVJvhcDOh71bZy8r3ijI7BSXcPcBUVCVO0N4BbubLrAR71Q9qhnvkKewC8wfL67Uch 9S9zJi8bES4P6sY1sz1Mejvv9j1Y9mPFs3yD3IfVFW08LWfsO4ytNZVbLh91rLByCwz5 iiWMLvGxtGIc9IvYAtJkkUDzL7H3okCI8q6iAuHlsstjDzRDYad1+0QzTRilG09alw0+ tFBVyywU+7SyHyL1J8g1Gc4ftS9MbBr3H9VZql3IyEZyGg82wIRXRV1MejKF78UEdCVl h2oQ== X-Gm-Message-State: ALoCoQlGuOtdyZGDhPDULZM+RnbDikMfAzbrGB5pfNIu78U4IoYAmjx+hu5sBzU0sDnO4uCfJqxf X-Received: by 10.58.152.137 with SMTP id uy9mr7255072veb.54.1402092187942; Fri, 06 Jun 2014 15:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.139 with HTTP; Fri, 6 Jun 2014 15:02:47 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 6 Jun 2014 15:02:47 -0700 Message-ID: To: "Stach, Thomas" Content-Type: multipart/alternative; boundary=089e013a25d6ce1d6104fb3206da Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4Au9FmMMdRXHY_kygciQIT4kO14 Cc: "mmusic@ietf.org" , Jiayang Liu Subject: Re: [MMUSIC] ICE PRIORITY with multiple TURN servers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 22:03:24 -0000 --089e013a25d6ce1d6104fb3206da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks. I think this could be made clearer in 5245 S 4.1.2.2, and address the multiple relay server case specifically; right now, it is all about assigning a local preference based on the network interface. Something to think about for -bis. On Fri, Jun 6, 2014 at 12:11 AM, Stach, Thomas wrote: > Justin, > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Justin > Uberti > *Sent:* Freitag, 6. Juni 2014 03:09 > *To:* mmusic@ietf.org; Mallinath Bareddy; Jiayang Liu; Eric Rescorla > *Subject:* [MMUSIC] ICE PRIORITY with multiple TURN servers > > > > Consider the case where a single endpoint has 2 TURN servers, and > allocates a relay candidate from both, from the same local IP. What shoul= d > their PRIORITY values be? > > > > Quoth 5245, S 4.1.2: > > Each candidate for a media stream MUST have a unique > > priority that MUST be a positive integer between 1 and (2**31 - 1). > > > > OK, so they have to have different priorities, i.e. either their type > preference or local preference must be different. But then, looking at S > 4.1.2.1: > > The type preference MUST be identical for all > > candidates of the same type and MUST be different for candidates of > > different types. > > > > Hmm, this means their local_preference must be different. But later in S > 4.1.2.1: > > The local preference MUST be an integer from 0 to 65535 inclusive. > > It represents a preference for the particular IP address from which > > the candidate was obtained, in cases where an agent is multihomed. > > > > Obviously, if they come from the same local IP, this cannot be satisfied. > What to do? > > *[TS] Well, that paragraph continues:* > > > > When there is only a single IP address, this value SHOULD be set to > > 65535. More generally, if there are multiple candidates for a > > particular component for a particular media stream that have the same > > type, the local preference MUST be unique for each one. > > > > So the case of two TURN servers is covered. > > What you propose below is OK, but if desired you could also rank A1, A2, > B1, B2. It=E2=80=99s your freedom of choice. > > Regards > > Thomas > > > > It seems like the easiest solution would be to use some of the local > preference to represent the ordering, so that both IP preference and serv= er > preference and represented, and therefore relay candidates from IPs 1 and= 2 > and Turn Servers A and B would stack rank as > > A1 > > B1 > > A2 > > B2 > --089e013a25d6ce1d6104fb3206da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. I think this could be made clearer in 5245 S 4.1.2= .2, and address the multiple relay server case specifically; right now, it = is all about assigning a local preference based on the network interface.
Something to think about for -bis.


On Fri, Jun 6, 2014 at 12:1= 1 AM, Stach, Thomas <thomas.stach@unify.com> wrote:

Justin,

=C2=A0

From: mmusic [= mailto:mmusic-= bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Freitag, 6. Juni 2014 03:09
To: mmusic@ietf= .org; Mallinath Bareddy; Jiayang Liu; Eric Rescorla
Subject: [MMUSIC] ICE PRIORITY with multiple TURN servers<= /u>

=C2=A0

Consider the case where a single endpoint has 2 TURN= servers, and allocates a relay candidate from both, from the same local IP= . What should their PRIORITY values be?

=C2=A0

Quoth 5245, S 4.1.2:

=C2=A0 =C2=A0Each candidate for a media stream MUST = have a unique

=C2=A0 =C2=A0priority that MUST be a positive intege= r between 1 and (2**31 - 1).

=C2=A0

OK, so they have to have different priorities, i.e. = either their type preference or local preference must be different. But the= n, looking at S 4.1.2.1:

=C2=A0 =C2=A0The type preference MUST be identical f= or all

=C2=A0 =C2=A0candidates of the same type and MUST be= different for candidates of

=C2=A0 =C2=A0different types.

=C2=A0

Hmm, this means their local_preference must be diffe= rent. But later in S 4.1.2.1:

=C2=A0 =C2=A0The local preference MUST be an integer= from 0 to 65535 inclusive.

=C2=A0 =C2=A0It represents a preference for the part= icular IP address from which

=C2=A0 =C2=A0the candidate was obtained, in cases wh= ere an agent is multihomed.

=C2=A0

Obviously, if they come from the same local IP, this= cannot be satisfied. What to do?

[TS] Well, th= at paragraph continues:

=C2=A0

=C2=A0 When there is only a single IP address, this value = SHOULD be set to

=C2=A0=C2=A0 65535.=C2=A0 More generally, if there are mul= tiple candidates for a

=C2=A0=C2=A0 particular component for a particular media s= tream that have the same

=C2=A0=C2=A0 type, the local preference MUST be unique for= each one.=C2=A0

=C2=A0

So the case of two TURN s= ervers is covered.

What you propose below is= OK, but if desired you could=C2=A0 also rank A1, A2, B1, B2. It=E2=80=99s = your freedom of choice.

Regards

Thomas

=C2=A0

It seems like the easiest solution would be to use s= ome of the local preference to represent the ordering, so that both IP pref= erence and server preference and represented, and therefore relay candidate= s from IPs 1 and 2 and Turn Servers A and B would stack rank as

A1

B1

A2

B2


--089e013a25d6ce1d6104fb3206da-- From nobody Fri Jun 6 17:28:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D8B1A0247; Fri, 6 Jun 2014 17:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9FdB7q3iEpF; Fri, 6 Jun 2014 17:28:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 495341A0201; Fri, 6 Jun 2014 17:28:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140607002820.15821.10834.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 17:28:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5XrrbHmc7hWePL09O70CbJ9cunk Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: (A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 00:28:21 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams set up and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary RTSP extensions and procedures. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jun 6 17:59:24 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9FF1A0268 for ; Fri, 6 Jun 2014 17:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z4MZwD49pep for ; Fri, 6 Jun 2014 17:59:21 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id B458C1A0264 for ; Fri, 6 Jun 2014 17:59:21 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id BCyA1o0031ei1Bg58CzEkt; Sat, 07 Jun 2014 00:59:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id BCzE1o0083ZTu2S3kCzEdZ; Sat, 07 Jun 2014 00:59:14 +0000 Message-ID: <539263E2.8010802@alum.mit.edu> Date: Fri, 06 Jun 2014 20:59:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mmusic@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=q20140121; t=1402102754; bh=qCufaHJemPhMM2Iyd/QtZctqPPNJnRItC7qU3to8sA4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vA9Ox2j8M9B8kdmW/KuKhG3k64md8C0hqU338Yy2312L6vBMZboAHK0mi5aXCMTdB 5ANj7aMqKCUsPxszPH6ifT+RJI+nBo+dgXJLmrlA7rJ2ttYVlHd8hwEWDuRxY/4Rd9 wAVl5L5KS82pepqvrJjC3p1q2FJLm+3J7hz4tdenIOQWzJZi5kxiFr2OFR8oBHVwft 0Bow6uM0MylblTFkAlLh9aEpVPmc/c3kRlGimbq0iccJDNYF0lDtOVAxSrpIhmsi2Y Hj+NBbOw0XIS3bCd3bH1aU9noizuvmP7VJiFyIJT+3EpXWCKbSE1mDdS4LwHCF3d7g qp+Cg7xvO/3Og== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f6Jug6fGR6lg52aZisJhLCbI-0E Subject: Re: [MMUSIC] 4566bis outstanding issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 00:59:22 -0000 Hi Ali, It is great that you are working on this!!! On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote: > Hi everyone > > I went thru the mail archives since 01/2012 and tried to list the issues that seem to be unresolved at this point. I can put them in the tracker but I wanna provide a summary first. > > For some of the issues below, no solution has been proposed. For the rest, there was no agreement on what to do. Here it goes: > > 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined. > > Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this. IIRC the argument against doing this is that we might get it wrong. But IMO we should do it because if we can't get it right how can we expect readers to get it right? > 2) 4566bis should update the format of the IANA registries to reflect the dependency between addrtype and net type. > > Comments: There does not seem an agreement on this but it looks to be an easy fix. > > 3) Section 8.2.4 defines the IANA registry and populates it with the attributes defined in 4566, however, Section 8.2.4 does not specify the name or format of the table. > > Comments: No text has been proposed or agreed but seems to be an easy fix if we wanna do this. > > 4) 4566bis does not make the registration of new network or address types mandatory. Section 8.2.6 and 8.2.7. > > Comments: If we agree that this should be mandatory, we can change the text. IMO we should make this change > 5) Source-level attributes defined in 5576. Should these attributes be included in the same table structure in the IANA registry? > > Comments: This seems to be an organizational issue rather than a technical issue. If we agree we need this, we can take on this as well. Yes, but IMO an important one. The current registries are hard to read, and easy to get wrong when adding new attributes. Also, we ought to have templates for what goes into the IANA consideration section when defining new attributes, and that template would be best in this document. > 6) Should we add a new column called "registered network type" in the addrtype table in the IANA registry as not all address types are applicable for all network types? > > Comments: This is also an IANA fix that we can do in this bis document or in a separate document (with all the other IANA registry changes). Similar comment to the one just above. > These are the issues I was able to identify. There is one more thing related to ICE and I sent an email about this to Marc Petit-Huguenin. As soon as he responds and depending on his answer, I might add one more issue. > > If there are things I missed, please let me know. The chairs and editors would like to close these issues and finalize 4566bis soon. There is an ongoing problem when SDP extensions are defined - lack of a consistent format for defining new attributes. Many people look to 4566 for examples of how to do this, but it provides bad examples. IMO 4566bis should show the definition of all attributes in a style that complies with a recommended format for defining attributes. (Of course that implies that we could agree on such a format.) Thanks, Paul From nobody Fri Jun 6 19:05:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96431A02E8 for ; Fri, 6 Jun 2014 19:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX7lcDTQDzkY for ; Fri, 6 Jun 2014 19:05:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C131A02F3 for ; Fri, 6 Jun 2014 19:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=807; q=dns/txt; s=iport; t=1402106749; x=1403316349; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=OW1UWq5U5OqOWH7Sb4CfVQI8dj6/eCPWxqht4lvbWeo=; b=TdIvhoMjy1SIe5Hb4CaG1tI+OsVa2/BeF0q7PDGYYheXGCOc+ztLhzJD Skb3KKAHTvz1/lwRpi29QiUn4kgSuUl1Jjn4lR5Y5kNDrACiXiFKtbJTk CxhkZ4qju3OqArinq8+i0DVqKH7YBYyXwB8C96rhlVdXqDcRKPLT1ebzF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAN5yklOtJA2I/2dsb2JhbABYgw1SWcQMAYEEFnWEAwEBAQMBOj8FDQEIIhRCJgEEDg0TiB8IDc07F444MYMygRYEm1+SAoM8bAGBQg X-IronPort-AV: E=Sophos;i="4.98,992,1392163200"; d="scan'208";a="331064670" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP; 07 Jun 2014 02:05:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5725la5021413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Jun 2014 02:05:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 21:05:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Justin Uberti (juberti@google.com)" Thread-Topic: [MMUSIC] ICE PRIORITY with multiple TURN servers Thread-Index: Ac+B9PryQ/VWVcmnR76OeN1zKc7dPQ== Date: Sat, 7 Jun 2014 02:05:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C9B39@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.61.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/17hrQIVDNqhBiCsYZyy90WNQTiE Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE PRIORITY with multiple TURN servers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 02:05:57 -0000 > It seems like the easiest solution would be to use some of the local pref= erence to represent the ordering, so that both IP preference and server pre= ference and represented, and therefore relay candidates from IPs 1 and 2 an= d Turn Servers A and B would > stack rank as=20 > A1 > B1 >A2 >B2 Yup, TURN servers could be provided by local network, access network, an ap= plication service provider or a third party provider. The ICE agent also ne= eds to use server preference to prioritize the relayed candidates learnt fr= om different administrative domains. For the enterprise use case discussed = in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-= 14#section-3.3.5 TURN server provided by the local network should have the = highest priority. =20 -Tiru From nobody Sun Jun 8 21:26:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF971B27D6; Sun, 8 Jun 2014 21:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXZ_Z-bAxqaW; Sun, 8 Jun 2014 21:26:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBB91A04AE; Sun, 8 Jun 2014 21:26:06 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s594Q3u2096521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jun 2014 23:26:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell Date: Sun, 8 Jun 2014 23:26:02 -0500 X-Mao-Original-Outgoing-Id: 423980762.897201-b2645a7bb05615547ccbc722548e50af Content-Transfer-Encoding: quoted-printable Message-Id: <26D7D69F-FFA0-442A-B151-1ADCCC972717@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> To: rtcweb@ietf.org, clue@ietf.org, mmusic@ietf.org, avtcore@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Slc7BhL3Dfp6D4_XFnr83ATiUXs Cc: dart@ietf.org Subject: [MMUSIC] Fwd: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 04:26:08 -0000 Hi, The referenced draft is a start for discussion on the implicat ions of = using different DiffServ treatments for packets in the same IP flow = (that is, share the same IP 5-tuple.) This will likely be of interest to = RTCWEB, MMUSIC, AVTCORE, CLUE and possibly other groups that contemplate = the bundling of multiple media streams on a single IP flow.=20 Please take discussion to the DART working group list (copied.) Thanks! Ben. Begin forwarded message: > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Differentiated Services (DiffServ) and = Real-time Communication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based = on > the Real-time Transport Protocol (RTP). DiffServ is based on = network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As = a > result, use of different DSCPs within a single traffic flow may = cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the = traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, = including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 From nobody Sun Jun 8 21:27:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DDF1A0658; Sun, 8 Jun 2014 21:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS4M6j7O9I2U; Sun, 8 Jun 2014 21:27:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788ED1B27D8; Sun, 8 Jun 2014 21:27:52 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s594RnHa096677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jun 2014 23:27:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell Date: Sun, 8 Jun 2014 23:27:49 -0500 X-Mao-Original-Outgoing-Id: 423980869.043394-a908008ed14f8b0ffbca2ad324f4c0c2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> To: rtcweb@ietf.org, clue@ietf.org, mmusic@ietf.org, avt@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/frHWzo5n-djA_mPX_prDweHpZQM Cc: dart@ietf.org Subject: [MMUSIC] Fwd: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 04:27:54 -0000 [Resending with the correct address for avtcore. Apologies for the = repeat] Hi, The referenced draft is a start for discussion on the implicat ions of = using different DiffServ treatments for packets in the same IP flow = (that is, share the same IP 5-tuple.) This will likely be of interest to = RTCWEB, MMUSIC, AVTCORE, CLUE and possibly other groups that contemplate = the bundling of multiple media streams on a single IP flow.=20 Please take discussion to the DART working group list (copied.) Thanks! Ben. Begin forwarded message: > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Friday, June 06, 2014 8:49 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Differentiated Services (DiffServ) and = Real-time Communication > Authors : Dan York > David Black > Cullen Jennings > Paul Jones > Filename : draft-york-dart-dscp-rtp-00.txt > Pages : 13 > Date : 2014-06-06 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based on > the Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As a > result, use of different DSCPs within a single traffic flow may cause > transport protocol interactions (e.g., due to reordering). In > addition, DSCP markings may be changed or removed between the traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00 >=20 From nobody Mon Jun 9 03:22:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E51A006C; Mon, 9 Jun 2014 03:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDTHwwOCsrBw; Mon, 9 Jun 2014 03:22:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD491A0062; Mon, 9 Jun 2014 03:22:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140609102247.27617.8665.idtracker@ietfa.amsl.com> Date: Mon, 09 Jun 2014 03:22:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/R-RzAltb-4pMOHhyAfRvd56r4Po Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 10:22:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-06.txt Pages : 17 Date : 2014-06-09 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "m-line" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-msid-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 13 07:32:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0341B2936 for ; Fri, 13 Jun 2014 07:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXHkiMnA4pbL for ; Fri, 13 Jun 2014 07:32:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE821B2935 for ; Fri, 13 Jun 2014 07:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3934; q=dns/txt; s=iport; t=1402669954; x=1403879554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MgQv5ciSjeAsJjVL6wZ9V0TOrqO7wzCTxHzilL+cle0=; b=Jj194v51taTZKToapLep+YXTuTNWgPRCLkETCOPe/JRUJUJV4IVAlid1 7IPYHnTz0KfYa8tU8c2jNe31scWXuGfqlOMIODWNZ9MVCYC3w+EzJZt/B /ekrHXO54md3u2CiQ+tYJJC0YcUqQOErLno+JGoijCxR+Vc8ykYaCh6PY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAEgKm1OtJV2U/2dsb2JhbABQCg6CWyRSWbtJhmtRAYEDFnWEAwEBAQMBAQEBNzQLBQsCAQgOCh4QJwslAQEEDgUbiB8IAQzSHxMEiS6EQQsGCAICARwzB4MrgRYEmjaTVIJ8QIIv X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="333000870" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 13 Jun 2014 14:32:34 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5DEWWrh030340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 14:32:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 09:32:32 -0500 From: "Ali C. Begen (abegen)" To: Paul Kyzivat Thread-Topic: [MMUSIC] 4566bis outstanding issues Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgASkPUAAUom8IA= Date: Fri, 13 Jun 2014 14:32:31 +0000 Message-ID: <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com> References: <539263E2.8010802@alum.mit.edu> In-Reply-To: <539263E2.8010802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.109] Content-Type: text/plain; charset="us-ascii" Content-ID: <3CE6FEA12083994ABAEA01D6A83B40B6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QFPpqJ49TU05Q6gR9x1LfjAgHb8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4566bis outstanding issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:32:39 -0000 Thanks Paul for the comments. Before I comment on your email, I would like = other participants to say their comments, too. If you have comments on the following issues, please speak up. On Jun 7, 2014, at 3:59 AM, Paul Kyzivat wrote: > Hi Ali, >=20 > It is great that you are working on this!!! >=20 > On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote: >> Hi everyone >>=20 >> I went thru the mail archives since 01/2012 and tried to list the issues= that seem to be unresolved at this point. I can put them in the tracker bu= t I wanna provide a summary first. >>=20 >> For some of the issues below, no solution has been proposed. For the res= t, there was no agreement on what to do. Here it goes: >>=20 >> 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 d= efined. >>=20 >> Comments: This was discussed again in a side meeting in London and there= was not a consensus whether we actually needed this. >=20 > IIRC the argument against doing this is that we might get it wrong. >=20 > But IMO we should do it because if we can't get it right how can we expec= t readers to get it right? >=20 >> 2) 4566bis should update the format of the IANA registries to reflect th= e dependency between addrtype and net type. >>=20 >> Comments: There does not seem an agreement on this but it looks to be an= easy fix. >>=20 >> 3) Section 8.2.4 defines the IANA registry and populates it with the att= ributes defined in 4566, however, Section 8.2.4 does not specify the name o= r format of the table. >>=20 >> Comments: No text has been proposed or agreed but seems to be an easy fi= x if we wanna do this. >>=20 >> 4) 4566bis does not make the registration of new network or address type= s mandatory. Section 8.2.6 and 8.2.7. >>=20 >> Comments: If we agree that this should be mandatory, we can change the t= ext. >=20 > IMO we should make this change >=20 >> 5) Source-level attributes defined in 5576. Should these attributes be i= ncluded in the same table structure in the IANA registry? >>=20 >> Comments: This seems to be an organizational issue rather than a technic= al issue. If we agree we need this, we can take on this as well. >=20 > Yes, but IMO an important one. The current registries are hard to read, a= nd easy to get wrong when adding new attributes. >=20 > Also, we ought to have templates for what goes into the IANA consideratio= n section when defining new attributes, and that template would be best in = this document. >=20 >> 6) Should we add a new column called "registered network type" in the ad= drtype table in the IANA registry as not all address types are applicable f= or all network types? >>=20 >> Comments: This is also an IANA fix that we can do in this bis document o= r in a separate document (with all the other IANA registry changes). >=20 > Similar comment to the one just above. >=20 >> These are the issues I was able to identify. There is one more thing rel= ated to ICE and I sent an email about this to Marc Petit-Huguenin. As soon = as he responds and depending on his answer, I might add one more issue. >>=20 >> If there are things I missed, please let me know. The chairs and editors= would like to close these issues and finalize 4566bis soon. >=20 > There is an ongoing problem when SDP extensions are defined - lack of a c= onsistent format for defining new attributes. Many people look to 4566 for = examples of how to do this, but it provides bad examples. >=20 > IMO 4566bis should show the definition of all attributes in a style that = complies with a recommended format for defining attributes. >=20 > (Of course that implies that we could agree on such a format.) >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Sat Jun 14 01:25:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DFC1B2BE2; Sat, 14 Jun 2014 01:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAitzrqTDMw0; Sat, 14 Jun 2014 01:25:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 533861B2BE5; Sat, 14 Jun 2014 01:25:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140614082523.25078.15634.idtracker@ietfa.amsl.com> Date: Sat, 14 Jun 2014 01:25:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/KwnNCPqC9GjK7XAtFjLeTzSwxOs Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:25:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) Authors : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-08.txt Pages : 24 Date : 2014-06-14 Abstract: This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-udptl-dtls-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 15 14:11:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8A1B27FE for ; Sun, 15 Jun 2014 14:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL5Mm5cHgQPm for ; Sun, 15 Jun 2014 14:11:14 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6D87C1A009A for ; Sun, 15 Jun 2014 14:11:13 -0700 (PDT) Received: from [IPv6:2001:470:40b8:0:c8cb:a2ef:177e:8079] (unknown [IPv6:2001:470:40b8:0:c8cb:a2ef:177e:8079]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1B01220F60; Sun, 15 Jun 2014 23:11:12 +0200 (CEST) Message-ID: <539E0BEE.4010004@acm.org> Date: Sun, 15 Jun 2014 15:11:10 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" , "mmusic@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BC94E8CRWss2A6jMI_-wrGRQyeE Subject: [MMUSIC] SDP attribute level for disaggregated media [was Re: 4566bis outstanding issues] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 21:11:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/06/2014 03:19 PM, Ali C. Begen (abegen) wrote: > Hi everyone > [...] > > > These are the issues I was able to identify. There is one more thing > related to ICE and I sent an email about this to Marc Petit-Huguenin. As > soon as he responds and depending on his answer, I might add one more > issue. > Let me first explain the problem as I perceive it: The SDP was designed so that different endpoints can be part of an RTP session, i.e. each m= section can used a different IP address. For example one can imagine that during an IETF meeting each microphone has its own IP address and stream audio directly to some destination (in that example the IP address in the SDP is only use for RTCP). If this use case was not possible, then it would be only possible to use c= at the session level. draft-loreto-splices-disaggregated-media was, I think, the first document to call this "media disaggregation". Now if we expand this to ICE, it means that each ICE agent declared in a SDP has to be independent of each other, i.e. each microphone in our example has it's own ICE agent, and they do not even to be from the same vendor. That means that all SDP attributes needs to be at least media-level attributes, and eventually both media- and session- level attributes. IANA fixed the problem for ice-mismatch, but the problem still exists for ice-options, and fixing it is part of rfc5245bis. Now my suggestion was that for future SDP attributes, people should really think about the disaggregated case when they choose between a session-level only attribute or an attribute that works at both session- and media-level, because using a session-level only attribute prevents media disaggregation. I could not find this problem in any existing attribute at the time I did the analysis but in ICE attributes, but note that this is not a problem specific to ICE. So I would suggest adding some text after this paragraph in section 8.2.4: 'Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability.' Something like this: 'Submitters of registrations should also carefully choose the type of attribute. They should not choose a session-level only type when the attribute can have different values when media is disaggregated, i.e. when each m= section has its own IP address on a different endpoint. In that case the attribute type chosen should be "both".' Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTngvsAAoJECnERZXWan7EkoEP+QH/FamXyYcisXxR8vtRBUAV D0MrwvRzzjQfAEW2aRSYPC12de0UeC7uYCOx9l7Cv1NKcFccdD/3NsDUNYy5C++Q siL0YAcTIhuCiBYkYPUEq3Ix3CrXGnspBV2kbJdcBPgGuIw7jXNHQh5l5bvoAtJs isHGev6rn6wGR2WheiYtlQ1AInFmjD5MqOyu9xtAAbdIJBWrqFzDsSq4vAevSyzL EYPgW6Op6UoP6zGIB45PRXiGP//5Gj8jri9wXjp3M8cyvgpK6CoHoNe6m1rGuWqS pMOh6vZRjRbkRpcufJ29tuV8SJ513m5x0pDSiCZAyNi47q3zgN+W++i4eX1ujnbN D/UjmQmacSFO3N/QWvuAlZH9VRSVHdUbyw/NXUFFhCjexSokn/nBh7eFFvwMJyp6 ZuxpKjcg+wrOxjkocSq8bNXcQLR1yohADKN1ePyHHvZ84+gkinlIpKMuegEBBFi5 OVe0O4QiRjKd3h1ewO98tzPUKVhaD9nSkLT7eOjHU3Xfz5Ol5tlA50+5P7tcN43h OO10nUijN4lxBsTi0WNC2sFpE3WXQ8gAkWHKyedfeMx9Uvl2SF18QFujAeD1oYIN jS+SuZOlO7S6t2naMzyJj10yOxzgSnNYBGBQQ2yP1oE1qtiZjCDhTTaJIMjTgCYu V/fj5tQ5v43FLPpKlD+8 =qu35 -----END PGP SIGNATURE----- From nobody Mon Jun 16 02:16:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1641B2A85; Sat, 14 Jun 2014 19:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTp_c70Hgjtj; Sat, 14 Jun 2014 19:57:08 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1C21B2886; Sat, 14 Jun 2014 19:57:06 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5F2v0YE028756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jun 2014 22:57:00 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5F2v0YE028756 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1402801020; bh=z2zGtkehDOoPF3PQcQ/NDTatVTI=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UpmfkpTneu2+WBMGDevEWaaR+875ANNrKPTRqn//cNubptGwSupmsJorLlFKKNWMO vFxWkaim0xCyIjjrItqxTXXJBJ8utIS4Z24EsJaRJE8cHqkq6qLGYAQIdNloFozPqb RSuHt9ksbN0FMN2gdwGdiGhkWx7Yq3n3MRSv4vzY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s5F2v0YE028756 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Sat, 14 Jun 2014 22:56:45 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5F2uj0R022962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Jun 2014 22:56:45 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Sat, 14 Jun 2014 22:56:45 -0400 From: "Black, David" To: "Magnus Westerlund (magnus.westerlund@ericsson.com)" , "thomas.zeng@gmail.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Date: Sat, 14 Jun 2014 22:56:43 -0400 Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-14 Thread-Index: Ac+IRWFz4ahMkmbER52S8zyZHBzAJg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FF268CF@MX15A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PaJ4fRVvzFs5R5uGvoKkn2Dgcmg X-Mailman-Approved-At: Mon, 16 Jun 2014 02:16:13 -0700 Cc: "Black, David" , "mmusic@ietf.org" , "ietf@ietf.org" Subject: [MMUSIC] Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-14 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 02:57:11 -0000 This is a combined Gen-ART and OPS-DIR review. Boilerplate for both follows ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Document: draft-ietf-mmusic-rtsp-nat-evaluation-14 Reviewer: David L. Black Review Date: June 14, 2014 IETF LC End Date: June 13, 2014 Summary: This draft is on the right track, but has open issues described in the review. This draft describes and evaluates a number of proposed NAT traversal mechanisms for RTSP. The draft covers a lot of detailed material about the proposed mechanisms, and necessarily assumes that the reader has some reasonable familiarity with NAT and RTP concepts. Major issues: [1] The abstract characterizes this draft as the evaluation that lead to the mmusic WG's choice of the NAT traversal technique for RTSP, but the evaluation in this draft did not drive that choice, as indicated in Section 6: Looking at Figure 1 one would draw the conclusion that using TCP Tunneling or Three-Way Latching is the solutions that best fulfill the requirements. The different techniques were discussed in the MMUSIC WG. It was established that the WG would pursue an ICE based solution due to its generality and capability of handling also servers delivering media from behind NATs. OTOH, there appears to be a lot of useful material in this draft that should be published in an informational RFC, not only the comparison, of NAT traversal techniques, but also documentation of some of those techniques, as indicated in Section 4: This section includes NAT traversal techniques that have not been formally specified anywhere else. The overview section of this document may be the only publicly available specification of some of the NAT traversal techniques. This may be fairly simple to address, as the last sentence in the abstract and the Section 6 text quoted above are the primary sources of this issue. It may also help to change the title of this draft from "The Evaluation of ..." to "Comparison of ..." and do something analogous to other occurrences of the word "evaluation" in this draft. Also in the text quoted from section 4 above "overview section" is misleading, as the documentation is in Section 4 - I suggest deleting "The overview section of". [Editorial] [2] Section 4 says: Some other techniques have been recommended against or are no longer possible due to standardization works' outcome or their failure to progress within IETF after the initial evaluation in this document, e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op]. That's too vague, an explicit list should be provided of techniques in Section 4 that should not or cannot currently be used, starting with RTP No-Op including an explanation of why that is the case for each technique. There's also an important editorial clarification needed - these "other techniques" are not NAT traversal techniques; they are possible elements of some NAT traversal techniques. This text is 4.1.1 is part of this issue: The first version of STUN [RFC3489] included categorization and parameterization of NATs. This was abandoned in the updated version [RFC5389] due to it being unreliable and brittle. Some of the below discussed methods are based on RFC3489 functionality which will be called out and the downside of that will be part of the characterization. Minor issues: [A] Firewall paragraph in Introduction confuses ALG implementation with firewall configuration (presumably UDP pinholes). It needs to clearly separate those two concepts, as the current text implies that punching a UDP (pin)hole is part of the firewall implementation, whereas it's actually part of the operational configuration of the firewall. [B] Still in the Introduction (Section 1): At the time when the bulk of work on this document was done, a single level of NAT was the dominant deployment for NATs, and multiple level of NATs, including Carrier Grade NATs (CGNs) has been only partially considered. That's vague - please provide a clear statement of what is out of scope for this draft. It looks like everything other than Basic NAT techniques is out of scope. -- Section 1.2 [C] Many organizations use firewalls to prevent privacy intrusions and malicious attacks to corporate computing resources in the private intranet [RFC2588]. Please remove the word "privacy" - I don't believe it's correct in this context, as many of the intrusions are intended to compromise far more than privacy. I would also change "to prevent" -> "to counter" as many current attacks are not prevented by firewalls. This needs more explanation: 2. NAT does not in itself provide security, although some access control policies can be implemented using address translation schemes. The inherent filtering behaviours are commonly mistaken for real security policies. At a minimum, explain what sort of "security" is not provided. In addition= , I suggest noting that a NAT can provide some privacy by concealing address/= port usage on the private side of the NAT. [D] Still in Section 1.2: In the rest of this memo we use the phrase "NAT traversal" interchangeably with "firewall traversal", and "NAT/firewall traversal". No, don't do that, please. This is a NAT traversal document that considers the effects of NAT traversal techniques on firewalls, so the term "NAT traversal" should be the primary term. -- Section 2, last paragraph. [E] Note that if neither RTCP packets nor RTSP messages are received by the RTSP server for a while, the RTSP server has the option to delete the corresponding RTP session, SSRC and RTSP session ID, because either the client can not get through a middle box NAT/firewall, or the client is mal-functioning. Is there any delay recommended before RTSP server reuse of that set of identifying information (RTP session, SSRC and RTSP session ID)? -- Section 3 [F] 3. Should have minimal impact on clients not behind NATs and which are not dual-hosted. RTSP dual-hosting means that the RTSP signalling protocol and the media protocol (e.g. RTP) are implemented on different computers with different IP addresses. * For instance, no extra delay from RTSP connection till arrival of media By comparison to requirement R3 in Section 6, the above text is too broad. The R3 requirement considered in this draft is specifically about additiona= l protocol round trips; "extra delay" could be introduced for other reasons. [G] Still in Section 3 4. Should be simple to use/implement/administer so people actually turn them on * Otherwise people will resort to TCP tunneling through NATs Not so fast ... TCP tunneling is one of the evaluated techniques (see Section 4.8), so that text isn't right. Deletion of the "* Otherwise ..." sub-bullet should suffice to deal with this. [H] Still in Section 3 5. Should authenticate dual-hosted client transport handler to prevent DDoS attacks. What's a "dual-hosted client transport handler" ??? I suggest adding this term and dual-hosting/dual-hosted to the Glossary in Section 1.3. [I] Still in Section 3 Note a simple preventative measure commonly deployed is for the RTSP server to disallow the cases where the client's RTP receiver has a different IP address than that of the RTSP client. With the increased deployment of NAT middleboxes by operators, i.e. carrier grade NAT (CGN), the reuse of an IP address on the NAT's external side by many customers reduces the protection provided. Also in some applications (e.g., centralized conferencing), dual-hosted RTSP/RTP clients have valid use cases. The key is how to authenticate the messages exchanged during the NAT traversal process. Is that "measure commonly deployed" recommended? The above text chunk feels like Security Considerations text, and this text could usefully be moved to Section 8. [J] Section 4.1.1 relies on STUN's abandoned NAT type classification functionality to determine where to send the hole-punching UDP packets. What's wrong with always sending those packets to the "server's source address/port"? That should work for both types of NATs, thereby removing the dependency on STUN classification of NAT types. [K] Why are ALG considerations only applicable to STUN-based techniques? -- Section 4.3.4 Disadvantages list [L] o Assumes that it is possible to de-multiplex between the packets of the media protocol and STUN packets. That is actually possible, although the demux technique is not exactly elegant Add a pointer to Section 5.1.2 of RFC 5764 for information on how this can be done. -- Section 4.4.1 [M] Latching [I-D.ietf-mmusic-latching] is a NAT traversal solution that is based on requiring RTSP clients to send UDP packets to the server's media output ports. Well, draft-ietf-mmusic-latching is about to be approved for publication as an RFC, but it does not apply to RTSP. Additional RTSP extension work would be required, as specified in section 4.4.2. Please make that clear at the start of this section, and include a forward pointer to section 4.4.= 2. [N] Section 4.6 - Where are the security considerations for 3-way Latching? -- Section 4.8.4 [O] It is not possible to get any amplification effect for denial of service attacks due to TCP's flow control. That's not correct or at least not a complete discussion of denial of servi= ce possibilities - if an attacker can cause a lot of TCP SYNs to be sent to a target/victim, the result can be a DDoS attack. The text quoted above need= s to be rewritten to address this possibility. Nits/editorial comments: There are additional editorial cleanups that I'll leave to the RFC Editor, but I noted a few things that seem to deserve mention here: - Section 1, 1st paragraph Today there is a proliferate deployment of different flavors of "proliferate" -> "proliferating", "flavors" -> "types" -- Section 1.1: "This document uses the term "address and port mapping" as the translation between an external address and port and an internal address and port. Note that this is not the same as an "address binding" as defined in RFC 2663." Note: In the above it would be more correct to use external instead of public in the above text. The external IP address is commonly a public one, but might be of other type if the NAT's external side is in a private address domain. That's confusing - I think this can be improved by using more precise terms in the first sentence (including adding quotes): external instead of public -> "external IP address" instead of "public IP address" -- Section 2 The loss of a RTP mapping can only be detected when expected traffic does not arrive. If a client does not receive data within a few seconds after having received the "200 OK" response to a PLAY request, it may be the result of a middlebox blocking the traffic. Are "200 OK" and "PLAY request" sent via RTP? I don't think so ... please clarify. -- Section 4 Add an explanation of what the "Transition:" text discusses for each mechanism are about - transition from what to what? I believe that these chunks of text concern transitioning to a (hypothetical, IMHO) world in which NATs don't exist. -- Section 4.3.4 Disadvantages list o Assumes that it is possible to de-multiplex between the packets of the media protocol and STUN packets. It is possible, although not elegant. Add a pointer to Section 5.1.2 of RFC 5764 for this. -- Section 5 DDoS attacks occur if the attacker fakes the messages in the NAT traversal mechanism to trick the RTSP server into believing that the client's RTP receiver is located on a separate host. "a separate host" -> "the host to be attacked". -- Section 8 The second paragraph in this section summarizes the security considerations from Section 4. It ought to be followed by a paragraph that compares/ contrasts the degree of security risks of the various NAT traversal mechani= sms to draw some conclusions - e.g., are some of the proposed mechanisms simply infeasible/implausible because the security risks are too high? idnits 2.13.01 found a few minor concerns with the references: =3D=3D Outdated reference: A later version (-07) exists of draft-ietf-mmusic-latching-05 =3D=3D Outdated reference: A later version (-21) exists of draft-ietf-mmusic-rtsp-nat-20 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) The final concern deserves attention - it would be a good thing if the need to reference to RFC 3489 could be eliminated. See [J] above for one suggested step towards that end. --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- In general, there is a lot of operational considerations material (applicable to A.1 questions) in this draft. Beyond that, management considerations (A.2 questions) are generally inapplicable. A.1.1. Has deployment been discussed? Yes, there is significant good material on deployment consideration= s. A.1.3. Has the migration path been discussed? Not much, but discussion of migration is mostly deferrable to the documentation of the selected NAT traversal mechanism and its components. Ease/difficulty of adding the NAT traversal support could have been an evaluation consideration, but was not used. On balance, this seems ok. A.1.4. Have the Requirements on other protocols and functional components been discussed? Yes, the discussion of each NAT traversal mechanism indicates what, if any changes would be needed to protocols used by that mechanism. But ... see major issue [2] above on the need for clarification of the discussion of obsolete/unusable protocol changes/features. A.1.9 Is configuration discussed? Yes, as part of the deployment considerations discussion, and the desire to avoid complexity of configuration is one of the evaluation criteria (R4). Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Mon Jun 16 06:56:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0741A0039; Mon, 16 Jun 2014 06:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTyCxijxJTgg; Mon, 16 Jun 2014 06:56:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B29B1A0029; Mon, 16 Jun 2014 06:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140616135638.29429.84842.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 06:56:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RXO_n5FhveqoXaQiQLniy698m5U Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 13:56:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) Authors : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-09.txt Pages : 24 Date : 2014-06-16 Abstract: This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-udptl-dtls-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 17 14:51:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100C01A01AE; Tue, 17 Jun 2014 14:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDHOf26YMzYK; Tue, 17 Jun 2014 14:51:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BAD1A0188; Tue, 17 Jun 2014 14:51:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140617215103.13000.57545.idtracker@ietfa.amsl.com> Date: Tue, 17 Jun 2014 14:51:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/WcKzQNzfepEOC_Fg8r0XjJBHotc Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:51:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Authors : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-08.txt Pages : 16 Date : 2014-06-17 Abstract: This document describes behavior of signaling intermediaries in Real- Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. Latching, which is one of the components of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of latching mechanism over the Internet and recommends other solutions such as the Interactive Connectivity Establishment (ICE) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 17 14:53:24 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9836C1A01B5 for ; Tue, 17 Jun 2014 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkK4w23ECMld for ; Tue, 17 Jun 2014 14:53:19 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924331A017C for ; Tue, 17 Jun 2014 14:53:18 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so8052198wes.0 for ; Tue, 17 Jun 2014 14:53:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mO4yEGVCh13p8bxdrnfkKLDclrI1/LEQjbeo/hNPfeE=; b=JG01q5WWH7z1kFAQtMhsoyG7JreVVZGb5if0UC0F7+vjhotNNq9zkMXQH1pNfwGW5k pcIjuMsnV7P/OoHKBf1NbXzQaMABBsVEe4V4WwFj71Zg+wE14F1ayMxPATq+WWumkyzs 9lJIedEYBs5yvDIwDzmCJCCKDW644ebkwD+TzdekAhTUwZTY+zFZjOTrOe38j37TW+0E kJdeDPxNSyglT4pDSb6GOBBbQxTCBQKM4OAOVhsMPgHcYOjZUIhgyxDSRzQ8iuJnLfGF Nm59f/ouMHk3ceJDfr61QqvgwOV7bDTHpr7Jwm7aLHUgYZmhrN4jZOhThQQ5epKO9kYr N/Lw== X-Gm-Message-State: ALoCoQn9PQG+YFdpCL/+yPruvPKRAmHJui0rDvuDegs3bazyE0mRybNOzuYGPnu6lft0tcfYRWuQ X-Received: by 10.194.85.225 with SMTP id k1mr41993983wjz.49.1403041997109; Tue, 17 Jun 2014 14:53:17 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id ub8sm465739wib.0.2014.06.17.14.53.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 14:53:16 -0700 (PDT) Message-ID: <53A0B8CA.3080107@jitsi.org> Date: Wed, 18 Jun 2014 00:53:14 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Vijay K. Gurbani" , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> In-Reply-To: <538C8820.1090900@bell-labs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/w2zAtEldJ1V6ZdZwNEkDPO1A-wU Cc: IESG IESG , mmusic Subject: Re: [MMUSIC] [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:53:22 -0000 Hey Vijay, Apologies for the delay! I believe we have addressed all comments and a new version is available here: Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 Please see inline for the rest of my responses (points of accord removed): On 02.06.14, 17:20, Vijay K. Gurbani wrote: > On 05/28/2014 05:32 PM, Emil Ivov wrote: >> Hey Vijay, >> >> Thanks for your review! Comments inline. > > Emil: Thank you for indulging me. Any time ;) > More inline (please see to end). I > have taken out items of agreement and only list those where more > discussion is required. For reference, my original review is at > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12014.html). > >>> SDP is as much of a standard as SIP is, no? Maybe you mean to say >>> that >>> because of the complexity of representing SIP messages, the SIP >>> portion >>> of a RTC component's stack may vary between implementations and >>> deploy- >>> ments. SDP, being a simpler protocol (at least syntactically), is not >>> exposed to such vagaries. Yes? >> >> Yes, exactly. [...] >> On the other hand there only so many ways you can change an IP address >> in SDP. So, how about the following wording? >> >> SIP's many features in terms of controlling message routing provide >> for various ways of addressing NAT traversal. As a result, the HNT >> component for SIP is typically more implementation-specific and >> deployment-specific than the SDP and media components. >> >> Would this be better? > > Yes, much improved. One minor modification to the suggested text: > > s/SIP's many features in terms of controlling message routing provide > for various ways of addressing NAT traversal./ > SIP uses numerous expressive primitives for message routing and, > consequently, NAT traversal./ I like that! Although with your wording the first part of the sentence is enough so if we remove the second we get: SIP uses numerous expressive primitives for message routing. As a result, the HNT component for SIP is typically more implementation-specific and deployment-specific than the SDP and media components. I think this matches exactly what we intended to say so if you are happy with it I think it's perfect. >>> - S3, second paragraph: "newly introduced media relay" --- newly >>> introduced to who? [...] >> So how about this? >> >> While this is not necessary for HNT to work, quite often, the IP >> address of that media relay may be the same as that of the signaling >> intermediary (i.e. the SIP SBC and media relay are co-located on the >> same host). Also, in almost all cases, the address of the media >> relay would belong to the same IP address family as the one used for >> signaling, as it is known to work for that UA. >> >> Is this better or do you prefer the original? > > The problem with qualifying phrases like "In almost all cases" is that > one wonders what happens in other cases? Well ... we have media and signalling going over different IP versions ... but I see what you mean. > What do you think about the > following text: > > In typical deployments, the media relay and signaling intermediary > (the SBC) are co-located, thereby sharing the same IP address > family. This works well because the UA also shares the same IP > address family. In deployments where the media relay belongs to > a different address family, the signaling intermediary would > rewrite it to correspond to the address family of the UA. > > Feel free to push back and modify if this does not convey the right > semantics (especially the "In deployments..." part). Yes, I think there might have been a misunderstanding here. I used some of your wording and arrived at: In typical deployments, the media relay and signaling intermediary (i.e., the SBC) are co-located, thereby sharing the same IP address. Also, the address of the media relay would typically belong to the same IP address family as the one used for signaling, as it is known to work for that UA. In other words, signalling and media would either both travel over IPv4 or IPv6. Is this better? >>> - S4, the descriptional steps below the text "The latching mechanism >>> works as follows:" will be improved if you used "UAC" or "UAS" instead >>> of "UA" (I recognize that in SIP it is not necessary that the UAC >>> make the first offer, but these steps are for illustrative purposes >>> and it helps to be as clear as we can for neophyte readers). Even >>> much better if you could cast the actors in terms of the principals >>> Alice and Bob that appear in Figures 2. So, something like "After >>> receving an offer from Alice (UAC) who is behind a NAT" is preferable >>> (I think) to "After receiving an offer from a NATed UA". >> >> I agree this can be said better. What would you say about: >> >> This way, while a session is still being setup, the signalling >> intermediary is not yet aware what addresses and ports the caller >> and the callee would end up using for media traffic: it has only >> seen them advertise the private addresses they use behind their >> respective NATs. Therefore media relays used in HNT would often use >> a mechanism called "latching". > > Umm ... I think there is a bit of a disconnect here. I am referring to > all steps 1 - 6 above. See next comment; it is related. Ah! Gotcha! Better now? >>> - S4, Figure 2, step 13: Much as you do in step 11, you should >>> spell out the "dest" field here as well. So, >>> s/RTP/RTP, dest=198.51.100.2:22007/ >> >> OK, that's going to require some ASCII art magic because we are out of >> place there already but I do agree it would be useful :) > > Sure; will be helpful if put in. Done. >>> - S5, first paragraph, towards the end: "widen the gap for potential >>> attackers..." Here, I suspect you mean that it provides the attackers >>> more IP address from which to mount attacks, i.e., advantage: >>> attackers. Yes? >> >> Yes. Is this a clarifying question or do you think it would be better if >> changed that way? > > I think it is better to say that "it provides the attackers a larger > attack surface" (or something similar). Using the phrase "widen the > gap" is ambiguous. One can read that as widening the gap between > attacker and defender (i.e., advantage defenders). Got it. Changed. >>> - S5, fourth paragraph: "For example, in cases where end-to-end >>> encryption is used it would still be possible for an attacker to >>> hijack a session despite the use of SRTP and perform a denial of >>> service attack. However, media integrity would not be compromised." >>> >>> Can you explain more broadly how the above would work? If we assume >>> that the endpoints exchange keys end-to-end and create secure channels >>> end-to-end, how would the attacker hijack a session? (Heartbleed and >>> all such mechanisms aside, of course. If we assume keys are derived >>> end-to-end and don't follow the hop-by-hop model, how would the >>> attacker prevail?) >> >> End-to-end was probably not the best choice of words here. Imagine >> something like ZRTP though. Given that such mechanisms rely exclusively >> on the media path for key negotiation, there would be no way for the SBC >> to authenticate the UA so it would still latch onto the wrong endpoint. >> Obviously ZRTP's authentication would prevent from an actual MitM attack >> but given that it's already on the media path, the attacker can simply >> stop relaying media and effectively perform a DoS. Does this make sense? > > Yes, more now. But, I think you will have to describe this attack using > ZRTP as an example in some more detail since there are various issues at > work here (the SBC not being able to authenticate the endpoint using > ZRTP, etc.). I suspect that the security ADs may ask you to do this > anyway during IESG review. Of course, if they don't you are free to > proceed, but as a matter of principle, it is best to explain the > security threat in enough detail that someone building these things can > appreciate the reasoning. (In the current form, at least I had > questions on the scenario you had in mind, hence the comment.) This section got completely reworded during IESG review and the above text is no longer there so ... >>> - Abstract, 3rd paragraph: >>> s/components of the HNT components/components of HNT/ >> >> thanks >> >>> In fact, the entire 3rd paragraph could be written more succinctly as >>> follows: >>> >>> Latching, one of the components of HNT, has a number of security >>> issues detailed in this document. Based on the known threats, the >>> IETF advises against use of this mechanism on the Internet and >>> recommends other solutions, such as the Interactive Connectivity >>> Establishment (ICE) protocol. >> >> That paragraph was the result of literally tens of back and forths so, >> unless you think this is paramount, I think it would be better to keep >> it as is. Specifically, the above version is missing on the fact that a) >> using SRTP allows for the security concerns to be addresses and the >> mechanism becomes acceptable b) sometimes the security concerns simply >> don't come into play (e.g. public conferences) c) there are controlled >> environments where security is taken care of in another way. > > Hmmm ... I don't see that the original version attends to (a), (b) and > (c) any more explicitly than the above version, but I will defer to your > judgment here. Since the paragraph is crafted through a hard-won > battle, please feel free to retain it. Also rewritten during IESG review. >>> - S4, first paragraph: s/couple/tuple/ >> >> well, in this case the text does refer to the address:port couple but I >> am ok with changing that to the "addres:port/transport" tuple (or >> triplet?) > > Stevens used "tuple" in his seminal TCP books. I personally think > "tuple" is better (and it is devoid of ordinal value, i.e., there can > be a 2-tuple, a quintuple, sextuple, etc.). If, however, you'd like > to leave it as "couple", no problem. OK. Changed for tuple everywhere. >>> - S4, Figure 3: why not use the principals Alice and Bob here as >>> well instead of "XMPP Client 1" and "XMPP Client 2"? >> >> Frankly the main reason was because it otherwise looks exactly like SIP >> and it becomes confusing. But I don't mind switching to Romeo and Juliet >> (which are XSF's protagonists of choice ;) ). > > Sure. Out of curiosity, who is XSF's Eve? I assume if an "Eve" is necessary it is easier to just pick a couple of other common protagonists: hamlet@denmark.lit and ophelia@denmark.lit, and then just go for claudius@denmark.lit > Thanks for your time on this, Emil. Thank you for yours Vijay! Emil -- https://jitsi.org From nobody Tue Jun 17 14:57:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9991A0188 for ; Tue, 17 Jun 2014 14:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I7SFI34DTpZ for ; Tue, 17 Jun 2014 14:57:35 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0601A004D for ; Tue, 17 Jun 2014 14:57:34 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so7739302wes.24 for ; Tue, 17 Jun 2014 14:57:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lJbv3BF58IzwtYx+/3Bz1Vh/AFYbz4IUClbCEyfNYvU=; b=A7gb7chTiddSwAZNnuXiQYaDjSelmu1TS/gxGS9+tma0D5ekqNvBWa1wz/0VwBNh+5 I89er571Zh5+yeCz4tlyhoeT593Ec+VeOD/QXljruO8S3UCR4bhx17Kt3uwkv9Se6+sv TpfoB/LkGsMXAA9CxXD4c+M0EvjvWbfogGTlxhJjq3SYw1sKgdYWnaTmfyYbwrfV5J/5 tzgHFeyDB8lA/Abb+RC1ySrERLvSDL28CDfTyiNXuWe6xKfM6BSYrNNaLK39z2a3Fa3G tJdsJy9l4iJ4RJTDBaz25M8cOxTwvdz85ecwsgY1NYg09hKwkwTxYjOiBx3k7ztw0RQc WOhA== X-Gm-Message-State: ALoCoQmjUshzduLVnVOXLClNQhYNHcJ35Y5iwYYrsg9NaBydeA7NGO/jpgp3yampHoEUB/BoxG0K X-Received: by 10.194.23.135 with SMTP id m7mr41452083wjf.2.1403042253080; Tue, 17 Jun 2014 14:57:33 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id em7sm25108853wjd.34.2014.06.17.14.57.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 14:57:32 -0700 (PDT) Message-ID: <53A0B9CB.3050909@jitsi.org> Date: Wed, 18 Jun 2014 00:57:31 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: MMUSIC References: <20140617215119.31326.31295.idtracker@ietfa.amsl.com> In-Reply-To: <20140617215119.31326.31295.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140617215119.31326.31295.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EWwKgd8DZyU3Wp0kVDp9Bep1Q6E Subject: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-trickle-ice-sip-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:57:37 -0000 Hey all, We have just updated the trickle ICE for SIP specification [0] and thought we'd send a quick summary of its most important characteristics. 1. Using INFO messages. Candidates are trickled with INFO messages and a trickle specific Info Package. This eliminates risk of glare during trickling and it allows both sides to do it in parallel with no concern for potential collisions. 2. Candidates are sent incrementally. In addition to the newly discovered candidates, every INFO message contains all local candidates an agent has previously sent. This allows misordered/lost INFOs to not be a problem. 3. INFO requests carry a (currently underspecified) sdpfrag content-type. Help is very welcome! 4. sdpfrag bodies start with session level attributes and are then followed by media level sections that are identified and delimited by "a=mid" lines. These media level sections exactly refer to the ones in the corresponding offer or answer. 5. INFO requests must always carry the a=ice-ufrag and a=ice-pwd attributes (as either session or media-level attributes) so that the requests can be matched to a specific ICE generation (i.e., or an offer/answer negotiation). 6. Trickle ICE for SIP does NOT require support for PRACK (although it can use it if available). In cases where PRACK is not supported an offerer must send a trickle INFO as soon as it gets a provisional response. Such an INFO message can contain new candidates or just be entirely the same as the previous one. (This is a change from the previous non-incremental version where an "end-of-candidates" was required for such cases). 7. SIP User Agents may be configured to force use of full trickle where maintainers expect all endpoints to support it. This would likely be the case for WebRTC environments. 8. Support for trickle ICE may also be dynamically discover with RFC 3840 but *only if* GRUU is also supported (otherwise there is no way to guarantee that the endpoint responding to caps query will be the same as the one that will get a subsequent INVITE 9. For those with an aversion to the above discovery hacks, trickle ICE for SIP can also be used in half trickle mode where the offerer starts with a regular ICE offer and, if the answerer can trickle, it just does. Comments and questions are welcome! Trickle ICE for SIP: [0] html: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02 [1] diff: http://www.ietf.org/rfcdiff?url2=draft-ivov-mmusic-trickle-ice-sip-02 -------- Original Message -------- Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-sip-02.txt Date: Tue, 17 Jun 2014 14:51:19 -0700 A new version of I-D, draft-ivov-mmusic-trickle-ice-sip-02.txt has been successfully submitted by Emil Ivov and posted to the IETF repository. Name: draft-ivov-mmusic-trickle-ice-sip Revision: 02 Title: A Session Initiation Protocol (SIP) usage for Trickle ICE Document date: 2014-06-17 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-sip-02.txt Status: https://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice-sip/ Htmlized: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ivov-mmusic-trickle-ice-sip-02 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the offer/answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jun 17 20:30:41 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB38C1A014C for ; Tue, 17 Jun 2014 20:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlpwxJEdYwwG for ; Tue, 17 Jun 2014 20:30:36 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594431A0140 for ; Tue, 17 Jun 2014 20:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2340; q=dns/txt; s=iport; t=1403062237; x=1404271837; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=NztUmYx1EeIVZGaKiR9a2NglMztONndleCnoHwUu13U=; b=GuOHj7J6lPTbF0OfsDpSEygL1GCLy1o5Y8UFaFf5/+ao5W1stCGyOsQq B2YcBGNSWYA1SdhYpVc0nCMRctE9oTmrmKpzSO7NijYXj89TD9uppe/BY bR+SwhjaJy4w95bacexurmX3NMm0B5ZJrA2Yzz/UUvgJsHbBOSemoa3+w o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIRANIGoVOtJV2T/2dsb2JhbABagw1SUweCbKcSDAEBAQEBAQUBApkmARl0FnWEAwEBAQQjEUMOBgEIEQQBAQMCBh0DAgQwFAEGAQEFBAEEEwgBiDkIBZw6jyOfCReBKoQ4iGIWKIJxNoEWBJwGkhWDQmyBRA X-IronPort-AV: E=Sophos;i="5.01,498,1400025600"; d="scan'208";a="53887758" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 18 Jun 2014 03:30:36 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5I3UZD2032726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Jun 2014 03:30:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 22:30:35 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-07.txt Thread-Index: Ac+KpaWjason1HIWSVSefO3zUvhPoA== Date: Wed, 18 Jun 2014 03:30:34 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282E0FE5@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/16auh-hZkqmPixCkfEyq_phSTOg Subject: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 03:30:38 -0000 V2UndmUgc2VwYXJhdGVkIG91dCBzZWN0aW9ucyB0aGF0IGRlYWwgd2l0aCBUVVJOIG1vYmlsaXR5 IHRvIGEgbmV3IGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmctdHJh bS10dXJuLW1vYmlsaXR5LTAwDQpUaGlzIG1ha2VzIE1JQ0UgYW5kIFRVUk4gTW9iaWxpdHkgZHJh ZnRzIHF1aXRlIGluZGVwZW5kZW50Lg0KDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdl bGNvbWUgb24gTUlDRS4NCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KLUF1dGhvcnMNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBKdW5lIDE3LCAy MDE0IDEwOjE0IFBNDQpUbzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSk7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBEYW4gV2luZyAo ZHdpbmcpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBQYWwgTWFydGluc2VuIChwYWxt YXJ0aSk7IERhbiBXaW5nIChkd2luZyk7IFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKQ0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9i aWxpdHktMDcudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdpbmctbW11c2lj LWljZS1tb2JpbGl0eS0wNy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg UHJhc2hhbnRoIFBhdGlsIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5h bWU6CQlkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHkNClJldmlzaW9uOgkwNw0KVGl0bGU6 CQlNb2JpbGl0eSB3aXRoIElDRSAoTUlDRSkNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMTcNCkdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE2DQpVUkw6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2luZy1tbXVzaWMtaWNl LW1vYmlsaXR5LTA3LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eS8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxp dHktMDcNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDcNCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNw ZWNpZmljYXRpb24gZGVzY3JpYmVzIGhvdyBlbmRwb2ludCBtb2JpbGl0eSBjYW4gYmUgYWNoaWV2 ZWQNCiAgIHVzaW5nIElDRS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jun 18 15:08:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0601A01A8; Wed, 18 Jun 2014 15:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez-xZC5vpzmI; Wed, 18 Jun 2014 15:08:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68061A019D; Wed, 18 Jun 2014 15:08:24 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5IM8NCf018021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jun 2014 17:08:23 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5IM8Md5030284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jun 2014 17:08:23 -0500 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.3.195]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5IM87Hd014615; Wed, 18 Jun 2014 17:08:08 -0500 (CDT) Message-ID: <53A20E5B.1000209@bell-labs.com> Date: Wed, 18 Jun 2014 17:10:35 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Emil Ivov , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> <53A0B8CA.3080107@jitsi.org> In-Reply-To: <53A0B8CA.3080107@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cf6kfVRrmj_swC5zdJm9fEOYf3g Cc: IESG IESG , mmusic Subject: Re: [MMUSIC] [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 22:08:28 -0000 On 06/17/2014 04:53 PM, Emil Ivov wrote: > Hey Vijay, > > Apologies for the delay! I believe we have addressed all comments and a > new version is available here: > > Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 > > Please see inline for the rest of my responses (points of accord removed): Emil: I am fine with the changes you suggested in the email text. I will go through the diffs next week, but I suspect all is good. Thanks for attending to my comments. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri Jun 20 01:16:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27B91B27A2; Fri, 20 Jun 2014 01:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sbpyWYld8HU; Fri, 20 Jun 2014 01:16:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 807B31B279A; Fri, 20 Jun 2014 01:16:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620081625.1025.43789.idtracker@ietfa.amsl.com> Date: Fri, 20 Jun 2014 01:16:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aJ2P7wLJRxybbYZp8VtATFxzK_0 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 08:16:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) Authors : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-10.txt Pages : 24 Date : 2014-06-20 Abstract: This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-udptl-dtls-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 22 20:36:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64711A03F2 for ; Sun, 22 Jun 2014 20:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.701 X-Spam-Level: *** X-Spam-Status: No, score=3.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoEh1CqIVgFf for ; Sun, 22 Jun 2014 20:36:49 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3771A0316 for ; Sun, 22 Jun 2014 20:36:48 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so5986085wes.8 for ; Sun, 22 Jun 2014 20:36:47 -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:content-type; bh=VTE6wRQQFVcAc/9ZF65+Zh5MtWrnSgUr89mw3eH0bqM=; b=KvPt9tAe71xYrWXFTnLMsP4Ldms5/PT3v5F3mTOWy6qdbT+E7lLBsGqq49Lo69EzB3 P2ItUkz9T84EdHmXzrdZU8sARuBjTB9FAM39G0B7IDCcP0QgsdWqiB3nYOqfHJTtGXcu abxwuHSqFPfYpIq6VKd7+62OrEvptviP0+GeE8mwGZipCFbvAwojyX3uImLuyOfZDZQV iCr5y2u6V8x5T4JkvcOybVKIx6ahToWCvXKUnXkAeEcxav5McEwwfsAiOy3pmy72Iviw 0RGl7mGzuZ2gVvQ9+BKCjF3qsjTQXvws6PP7hotg8e/Ig+5+yNKWql7AK+IIwDlBKVt2 NyAw== MIME-Version: 1.0 X-Received: by 10.194.186.178 with SMTP id fl18mr23239858wjc.83.1403494607288; Sun, 22 Jun 2014 20:36:47 -0700 (PDT) Received: by 10.194.71.97 with HTTP; Sun, 22 Jun 2014 20:36:47 -0700 (PDT) Date: Sun, 22 Jun 2014 20:36:47 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=047d7bb04dd282fe0f04fc788d9f Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RQsZlJ8E7fbXGJPJ90J0PrSNoPA Subject: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 03:36:50 -0000 --047d7bb04dd282fe0f04fc788d9f Content-Type: text/plain; charset=UTF-8 Hello All Continuing the discussions from London on analyzing multiplexing behavior for SDP attributes that are defined per Payload Type, I was thinking on making following changes to the draft-ietf-mmusic-sdp-mux-attributes-01. 1. Add new category called IDENTICAL-PER-PT to the SDP Attribute analysis framework in Section 4 which is defined as IDENTICAL-PER-PT: Attributes that define the RTP payload configuration on per Payload Type basis and MUST have identical values across all the media descriptions for a given RTP Payload Type when repeated. 2. Similarly add another category IDENTICAL-PER-SSRC to accommodate source level SDP attributes. IDENTICAL-PER-SSRC: Attributes that correspond to the individual RTP Packet Streams in a given RTP Session and MUST have identical values when repeated across multiple media description for a given SSRC. 3. For all the attributes that directly/indirectly impact codec configuration and packetization of the media, I have attempted to assign a SDP MUX category and provide some insights on how such a decision was made (wherever applicable) *Attribute: a=ptime, a=maxptime* Mux Category: IDENTICAL-PER-PT Notes: For a given codec the audio packetization time must be same if the PT is repeated. This will ensure that the RTP receiver can unambiguously decode the incoming audio packets. *Attribute: a=framerate* Mux Category: IDENTICAL-PER-PT *Attribute: a=rtpmap* Mux Category: IDENTICAL-PER-PT *Attribute: a=fmtp* Mux Category: IDENTICAL-PER-PT Notes: *Attribute: a=rtcp-fb* Mux Category: NORMAL Notes: Since the feedback messages are reported per SSRC, the category of NORMAL suffices. *Attribute: a=depend (RFC5583)* Mux Category: IDENTICAL-PER-PT Notes: Since each dependency identifies a unique RTP packetization and thus MUST be identified via unique Payload Type. Similarly if the Payload Type is repeated across media descriptions, they MUST represent the Identical codec configuration. *Attribute: a=ssrc:xyz fmtp: ... * Mux Category: IDENTICAL-PER-PT Notes: RFC5576 says this : " Within a media stream, "ssrc" attributes with the same value of describe different attributes of the same media sources. Across media streams, values are not correlated (unless correlation is indicated by media-stream grouping or some other mechanism) and MAY be repeated. " Thus if the RTP Payload Type used to specify fmtp parameters is repeated, it MUST represent the same codec configuration. example: m=video ... a=rtpmap:98 VP8/90000 a=ssrc:12345 fmtp:98max-fr=15; max-fs-1200 m=video ... a=rtpmap:98 VP8/90000 a=ssrc:56789 fmtp:98 max-fr=15; max-fs-1200 *Attribute: a=ssrc:xyz cname: ....* Mux Category: IDENTICAL-PER-SSRC Notes: RFC5576 defines the identical requirement as it is. *Attribute: a=imageattr* Mux Category: IDENTICAL-PER-PT *Attribute: a=framesize* Mux Category: IDENTICAL-PER-PT *Attributes: a=fec-source-flow, a=fec-repair-flow, a=repair-window* Mux Category: NORMAL I believe these cover all PT scoped SDP attributes. Please let me know your thoughts and comments. Cheers Suhas Nandakumar --047d7bb04dd282fe0f04fc788d9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0=C2=A0
=C2=A0 =C2=A0Continuing the discussions from London on analyzing multi= plexing behavior for SDP attributes that are defined per =C2=A0Payload Type= , I was thinking on making following changes to the draft-ietf-mmusic-sdp-m= ux-attributes-01.=C2=A0

1. Add new category = called IDENTICAL-PER-PT to the SDP Attribute analysis framework in Section = 4 which is defined as
<= br>
IDENTICAL-PER-PT: Attr= ibutes that define the RTP payload configuration on per Payload Type basis = and MUST have identical values across=C2=A0all the media descriptions for a given RTP Payload Ty= pe when repeated.

=
2. Similarly add anothe= r category IDENTICAL-PER-SSRC to accommodate source level SDP attributes.

IDENTICAL-PER-SSRC: Attributes that correspond t= o the individual RTP Packet Streams in a given RTP Session and MUST have id= entical values when repeated across multiple media description for a given = SSRC.

3. For all the= attributes that directly/indirectly impact codec configuration and packeti= zation of the media, I have attempted to assign a SDP MUX category and prov= ide some insights on how such a decision was made (wherever applicable)

Attribute: a=3Dptime, a=3Dmaxptime
Mux Category: IDENTICAL-PER-PT
Notes: For a given codec the audio = packetization time must be same if the PT is repeated. This will ensure tha= t the RTP receiver can=C2=A0unambiguously=C2=A0decode the incoming audio pa= ckets.


Attribute: a=3Dframerate
= Mux Category: IDENTICAL-PER-PT


Attribute: a=3Dfmtp
Mux Category: IDENTICA= L-PER-PT
Notes:=C2=A0

Attribute: a=3Drtcp-fb
Mux= Category: NORMAL
Notes: Since the feedback messages are re= ported per SSRC, the category of NORMAL suffices.

Attribute: a=3Ddepend (RFC5583)
Mux Categ= ory: IDENTICAL-PER-PT
Notes:
Since each dependency identifies a unique RTP packetiza= tion =C2=A0and thus MUST be identified via unique Payload Type.=C2=A0
Similarly if the Payload Type is repeated across media descriptions, t= hey MUST represent the Identical codec configuration.=C2=A0

<= /div>
Attribute: a=3Dssrc:xyz =C2=A0fmtp:<fmt> ...=C2=A0
Mux Category: IDENTICAL-PER-PT
Notes:
RFC5576 says this :
" =C2=A0
Within a media stream, &quo= t;ssrc" attributes with the same value of
<ssrc-id> describe different attri=
butes of the same media sources.
Across media streams, <ssrc-id> values are not correlated (unless
correlation is indicated by media-stream grouping or some other
mechanism) and MAY be re=
peated.


"
Thus if the RTP Payload Type used to spe=
cify fmtp parameters  is repeated, it MUST represent the same codec configuration.=



example:
m=3Dvideo ...<=
/span>
a=3Drtpmap:98 VP8/90000


a=3Dssrc:12345 fmtp:98max-fr=3D15; max-fs-1200



m=3Dvideo ...<=
/span>
a=3D=
rtpmap:98 VP8/90000


a=3Dssrc:56789 f=
mtp:98 max-fr=3D15; max-fs-1200




Attribute: a=3Dssrc:xyz=
 =C2=A0cname: ....


Mux Category: IDENTICAL-PER-SSRC
Notes: RFC5576 defines the =
identical requirement as it is.

Attribute: a=3Dimageattr
Mux Categor=
y: IDENTICAL-PER-PT




Attribute: a=3Dframesize
Mux Category: IDENTICAL-PER-PT


<=
div>
Attributes: a=3D=
fec-source-flow, a=3D=
fec-repair-flow, a=3Drepair-window


Mux Category: NORMAL


I b=
elieve these cover all PT scoped SDP attributes. Please let me know your th=
oughts and comments.

Cheers
Suhas Nandak=
umar
--047d7bb04dd282fe0f04fc788d9f-- From nobody Mon Jun 23 06:55:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466E11B2AF0; Mon, 23 Jun 2014 06:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyo1OfBrvnUF; Mon, 23 Jun 2014 06:55:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 248B41B2AFE; Mon, 23 Jun 2014 06:55:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623135530.11634.51054.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 06:55:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QNCGsZ7l17PjeKOrBKQn8DMIGU8 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-mmusic-udptl-dtls-10.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 13:55:34 -0000 The IESG has approved the following document: - 'UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)' (draft-ietf-mmusic-udptl-dtls-10.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Alissa Cooper and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ Technical Summary The document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). Working Group Summary There has been no controversy on the document. On the contrary in fact with both quick WG interest and adoption as well as review and finalization. Document Quality There are no known implementations of the protocol, however it has been adopted by 3GPP. There are no new Media Types, MIBs, etc. and hence no special reviews. Personnel Flemming Andreasen is the document shepherd. Alissa Cooper is the responsible area director. From nobody Tue Jun 24 08:22:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA79B1B2D72 for ; Tue, 24 Jun 2014 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEQ7fKpw8SJQ for ; Tue, 24 Jun 2014 08:22:42 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782F21B2D9F for ; Tue, 24 Jun 2014 08:20:04 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so540527wgh.9 for ; Tue, 24 Jun 2014 08:20:02 -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:content-type; bh=cyGEn8GljRb/rw+0Kyo7/ReqfaMz6J9zIrxlPwq5IPI=; b=Sdx64XangBOFEDXoGtJhDolDrpC2fTZKBLKXaM0NULX89G5zT/VsLM9REI6i9q6ktt czNAWbuCBU8ccsB3W4I6BhoXzY3NM0ys01Ed4ot9DdVgpAFTWt3cLkO4K6JzL+4WGHFU dbcqwf1NIFwfYG/4clVvVygiZo5+/UunUPshZm+kE9qTYCj+s0crmzuqBCR52AAPqz6w HXnofjHklOAZ3h2RAJhcUqmPPHoe09fZrMha+MgrNWyoNibBVGw9yHcgsqoUjzfFGwFW dOxAYkhn2SuF4bN5GaW0rSWzUy5TosBYR70Kjsi5c9CdtyJfexPccoBCi3ouAy/SO7Dd TWxA== MIME-Version: 1.0 X-Received: by 10.194.134.70 with SMTP id pi6mr2252807wjb.1.1403623200803; Tue, 24 Jun 2014 08:20:00 -0700 (PDT) Received: by 10.194.71.97 with HTTP; Tue, 24 Jun 2014 08:20:00 -0700 (PDT) Date: Tue, 24 Jun 2014 08:20:00 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=089e01175d9d48527504fc967ef8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/frixL8vtz0tBc3Wa_iC9EnfNbDw Subject: [MMUSIC] ISSUE2: SDP Attribute Multiplexing - CapNeg Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 15:22:45 -0000 --089e01175d9d48527504fc967ef8 Content-Type: text/plain; charset=UTF-8 Hello All One of the action items from the IETF89 was to complete the analysis for describing multiplexing behavior of CapNeg attributes. Based on some offline discussions with Flemming back in London, I am planning to propose following semantic changes to the upcoming version of SDP Attributes Mux draft. { the english text usage might change in the final version though } *CHANGE 1. Define a new category called INHERIT as below* INHERIT*:* Attributes that encapsulate other SDP attributes and their multiplexing characteristics are INHERITED from the attributes they encapsulate. Such attributes as of today, are defined in [RFC3407], [RFC5939] and [RFC6781] as part of a generic framework for indicating and negotiating transport, media and media format related capabilities in the SDP. Example : m=video 3456 RTP/AVP 100 a=rtpmap:100 VP8/90000 a=fmtp:100 max-fr=30;max-fs=8040 a=sqn: 0 a=cdsc: 1 video RTP/AVP 100 a=cpar: a=rtcp-mux m=video 3456 RTP/AVP 101 a=rtpmap:101 VP8/90000 a=fmtp:100 max-fr=15;max-fs=1200 a=cdsc: 2 video RTP/AVP 101 a=cpar: a=rtcp-mux In the above example , the category IDENTICAL is inherited for the cpar encapsulated rtcp-mux attribute *CHANGE 2: Update Section 15 to reflect the discussions from IETF 89 * *Section 15. Multiplexing considerations for Encapsulating Attributes* This sections deals with recommendations for defining the multiplexing characteristics of the SDP attributes that encapsulate other SDP attributes. Such attributes as of today, for example, are defined in [RFC3407], [RFC5939] and [RFC6781] as part of a generic framework for indicating and negotiating transport, media and media format related capabilities in the SDP. The behavior of such attributes under multiplexing is in turn defined by the multiplexing behavior of the attributes they encapsulate which are made known once the negotiation process is completed. *RFC3407 Attribute Analysis* sqn : NORMAL cdsc: NORMAL cpar: INHERIT cpar encapsulates b= (bandwidth) or an a= attribute. For bandwidth attribute encapsulation, the category SUM is inherited. For the case of a= attribute, the category corresponding to the SDP attribute being referenced is inherited. cparmin: SPECIAL cparmax: SPECIAL Since these attributes defines minimum and maximum numerical values associated with the attributed described in a=cpar, it is recommended to consult the document defining the attribute. *RFC5939 Attribute Analysis* RFC5939 defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. The attribute a=pcfg encapsulates various capabilities related to transport and media properties via the a=tcap and a=acap attributes respectively, that the Offerer is capable of supporting. Thus the attribute a=pcfg provides a list of potential configurations from the Offerer. In response, the Answerer picks its supported transport and/or media capabilities from the Offered list as part of a=acfg attribute representing the actual configuration selected. Thus a complete Offer/Answer exchange needs to be completed for the Offerer to ensure the right set of configuration parameters based on the actual configuration selected by the Answerer. Within the context of multiplexing several media descriptions with RFC5939 Capability negotiation attributes, following recommendations should be considered: 1. The negotiated transport capability attribute (a=tcap) MUST be IDENTICAL across all the multiplexed m=lines. [ Refer to section XXXXX in BUNDLE]. 2. For attributes encapsulated via a=acap capability attribute, the negotiation MUST ensure the multiplexing behavior of the same inherits the attribute being encapsulated. *RFC6871 Attribute Analysis* RFC6871 extends capability negotiation framework described in RFC5939 by defining media capabilities that can be used to indicate and negotiate media types and their associated format parameters. Building upon the analysis from the previous sections, following recommendations should be considered for dealing with the attributes defined in RFC6871 when multiplexing several SDP media descriptions 1. On negotiation, the category IDENTICAL-PER-PT applies to the attributes that define media capabilities (a=rmcap) and media format capabilities ( a=mfcap), if same Payload Type is being used to define these capabilities. 2. The Media specific capability attribute (a=mscap) , the non RTP media based capability attribute (a=omcap) MUST inherit the multiplexing behavior of the attribute being encapsulated. 3.The behavior for the latent configuration attribute (a=lcfg) follows the reasoning defined for the a=acfg and a=pcfg attributes, since a given latent configuration is provided as a recommendation and is not applied to the on-going Offer/Answer exchange. Example 1: Below SDP example captures the following aspects. - The Offerer offers audio and video streams with several different RTP profiles (AVP, SAVP, SAVPF) as potential configurations. - corresponds to the SDP answer where the Answerer accepts RTP/SAVPF as the default profile for both the media streams. In this scenario both the media streams can be successfully multiplexed. - , the Answerer accepts the profile RTP/SAVPF for the audio stream and RTP/AVPF for the video stream. This scenario results in the failure of the multiplexing as defined in the section 7.2 of the BUNDLE specification [I-D.ietf-mmusic-sdp-bundle-negotiation]. v=0 o=- 25678 753849 IN IP4 192.0.2.1 s= t=0 0 c=IN IP4 192.0.2.1 m=audio 3456 RTP/AVP 98 a=tcap:1 RTP/SAVPF a=rtpmap:98 OPUS/48000/2 a=pcfg:1 t=1 m=video 51372 RTP/AVP 101 a=rtpmap:101 H264/90000 a=tcap:2 RTP/SAVPF RTP/AVPF a=pcfg:2 t=2|3 v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= m=audio 3456 RTP/SAVPF 98 a=rtpmap:98 OPUS/48000/2 a=acfg:1 t=1 m=video 51372 RTP/SAVPF 101 a=rtpmap:101 H264/90000 a=acfg:2 t=2 v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= m=audio 3456 RTP/SAVPF 98 a=rtpmap:98 OPUS/48000/2 a=acfg:1 t=1 m=video 51372 RTP/AVPF 101 a=rtpmap:101 H264/90000 a=acfg:2 t=3 Please let me know your thoughts Cheers Suhas --089e01175d9d48527504fc967ef8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All
=C2=A0One of the action items from the IETF89 was to complete the analysis = for describing multiplexing behavior of CapNeg attributes. Based on some of= fline discussions with Flemming back in London, I am planning to propose fo= llowing semantic changes to the upcoming version of SDP Attributes Mux draf= t. { the english text usage might change in the final version though }

CHANGE 1. Define a new category called INHERIT as below
INHERIT:
Attributes that encapsulate other SDP attributes=C2=A0and their multiplexing cha= racteristics are INHERITED from the attributes they encapsulate. Such attri= butes as of today, are defined in [RFC3407], [RFC5939] and [RFC6781] as par= t of a generic framework for indicating and negotiating transport, media an= d media format related capabilities in the SDP.
Example :
m=3Dvideo 3456 RTP/AVP 1= 00
a=3Drtpmap:100 VP8/90000
a=3Dfmtp:100 max-fr=3D30;max-fs=3D8040
a=3Dsqn: 0
<= div style=3D"font-size:13px;padding-right:1px;color:rgb(0,0,0);font-family:= Arial,sans-serif;line-height:17px">a=3Dcdsc: 1 video RTP/AVP 100
a=3Dcpar: a=3Drtcp-mux
m=3Dvideo 3456 RTP/AVP 1= 01
a=3Drtpmap:101 VP8/90000
a=3Dfmtp:100 max-fr=3D15;max-fs=3D1200
a=3Dcdsc: 2 video RTP/AV= P 101
a=3Dcpar: a=3Drtcp-mux

In the above example , t= he category IDENTICAL is inherited for the cpar encapsulated rtcp-mux attri= bute

CHANGE 2: Update Section 15 to reflect the discuss= ions from IETF 89=C2=A0
Section 15. Multiplexing considerations for Encapsulating= Attributes
This sections deals with recommendations for defining the multi= plexing characteristics of the SDP attributes that encapsulate other SDP at= tributes. Such attributes as of today, for example, are defined in [RFC3407= ], [RFC5939] and [RFC6781] as part of a generic framework for indicating an= d negotiating transport, media and media format related capabilities in the= SDP.
The behavior of such attributes under multiplexing is in turn d= efined by the multiplexing behavior of the attributes they encapsulate whic= h are made known once the negotiation process is completed.=C2=A0

RFC3407 Attribute Ana= lysis
sqn :=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 NORMAL
cdsc:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NORMAL
cpar:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INHERIT=C2=A0
cpar encapsulates b=3D (bandwidth) or an a=3D attribute. For bandwidth at= tribute encapsulation, the category SUM is inherited. For the case of=C2=A0= a=3D attribute, the category corresponding to the SDP attribute being refe= renced is inherited.
cparmin:=C2=A0=C2=A0=C2=A0=C2=A0 SPECIAL
cparmax:=C2=A0=C2=A0=C2= =A0 SPECIAL
Since these attributes defines minimum = and maximum numerical values associated with the attributed described in a= =3Dcpar, it is recommended to consult the document defining the attribute.<= /span>

RFC5939 Attribute Ana= lysis
RFC5939 defines a general SDP Capability = Negotiation framework. It also specifies how to provide attributes and tran= sport protocols as capabilities and negotiate them using the framework.
=C2=A0
The attribute a=3Dpcfg e= ncapsulates various capabilities related to transport and media properties = via the a=3Dtcap and a=3Dacap attributes respectively, that the Offerer is = capable of supporting. Thus the attribute a=3Dpcfg provides a list of poten= tial configurations from the Offerer.=C2=A0In response, the Answerer= picks its supported transport and/or media capabilities from the Offered l= ist as part of a=3Dacfg attribute representing the actual configuration sel= ected.

Thus a complete Offer/An= swer exchange needs to be completed for the Offerer to ensure the right set= of configuration parameters based on the actual configuration selected by = the Answerer.

Within the context of mu= ltiplexing several media descriptions with RFC5939 Capability negotiation a= ttributes, following recommendations should be considered:
1. The negotiated transp= ort capability attribute (a=3Dtcap) MUST be IDENTICAL across all the multip= lexed m=3Dlines. [ Refer to section XXXXX in BUNDLE].
2. For attributes encaps= ulated via a=3Dacap capability attribute, the negotiation MUST ensure the m= ultiplexing behavior of the same inherits the attribute being encapsulated.=

RFC6871 Attribute Ana= lysis
RFC6871 extends capability negotiation fr= amework described in RFC5939 by defining media
capabilities that can be used to indicate and negotiate media t= ypes and their associated format parameters.

Building upon the analys= is from the previous sections, following recommendations should be consider= ed for dealing with the attributes defined in RFC6871 when multiplexing sev= eral SDP media descriptions
1. On negotiation, the category IDENTICAL-PER-PT applies to the= attributes that define=C2=A0 media capabilities (a=3Drmcap) and media form= at capabilities ( a=3Dmfcap),=C2=A0 if same Payload Type is being used to d= efine these capabilities.=C2=A0
2. The Media specific capability attribute (a=3Dmscap) ,=C2=A0 = the non RTP media based capability attribute (a=3Domcap) MUST inherit the m= ultiplexing behavior of the attribute being encapsulated.
3.The behavior for the latent configuration attribute (a=3Dlcfg= ) follows the reasoning defined for the a=3Dacfg and a=3Dpcfg attributes, s= ince a given latent configuration is provided as a recommendation and is no= t applied to the on-going Offer/Answer exchange.

Example 1: Below SDP example captures the following aspects.
- The Offerer offers audio and video streams with several different RTP = profiles (AVP,=C2=A0=C2=A0=C2=A0
=C2=A0 SAVP, SAVPF) as potential configurations.
- <Valid Answer > = corresponds to the SDP answer where the Answerer accepts RTP/SAVPF as the d= efault profile for both the media streams. In this scenario both the media = streams can be successfully multiplexed.
- <Invalid Answer> , the Answerer accepts the profile RTP= /SAVPF for the audio stream and RTP/AVPF for the video stream. This scenari= o results in the failure of the multiplexing as defined in the section 7.2 = of the BUNDLE specification [I-D.ietf-mmusic-sdp-bundle-negotiation].
<Offer-SDP>
v=3D0
o=3D- 25678 753849 IN IP4 192.0.2.1
s=3D
t=3D0 0
c=3DIN IP4 192.0.2.1
m=3Daudio 3456 RTP/AVP 98
a=3Dtcap:1 RTP/SAVPF
a=3Drtpmap:98 OPUS/48000/2
a=3Dpcfg:1 t=3D1
m=3Dvideo 51372 RTP/AVP = 101
a=3Drtpmap:101 H264/90000
a=3Dtcap:2 RTP/SAVPF RTP/AVPF
a=3Dpcfg:2 t=3D2|3

<Valid Answer>
v=3D0
o=3D- 24351 621814 IN IP4 192.0.2.2
=
s=3D
m=3Daudio 3456 RTP/SAVPF 98
a=3Drtpmap:98 OPUS/48000/2
a=3Dacfg:1 t=3D1<= /div>

m=3Dvideo 51372 RTP/SAVP= F 101
a=3Drtpmap:101 H264/90000
a=3Dacfg:2 t=3D2
<Invalid Answer>
v=3D0
o=3D- 24351 621814 IN IP4 192.0.2.2
=
s=3D
m=3Daudio 3456 RTP/SAVPF 98
a=3Drtpmap:98 OPUS/48000/2
a=3Dacfg:1 t=3D1<= /div>

m=3Dvideo 51372 RTP/AVPF= 101
a=3Drtpmap:101 H264/90000
a=3Dacfg:2 t=3D3

Please= let me know your thoughts

Cheers
Suhas
<= /div> --089e01175d9d48527504fc967ef8-- From nobody Wed Jun 25 11:08:33 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275E01B2DC9; Wed, 25 Jun 2014 11:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7QXICXezeEz; Wed, 25 Jun 2014 11:08:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709F51B2DD0; Wed, 25 Jun 2014 11:07:17 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id s5PI7DQ9024256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jun 2014 13:07:14 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5PI7DRj006692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jun 2014 13:07:13 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5PI77tf025602; Wed, 25 Jun 2014 13:07:13 -0500 (CDT) Message-ID: <53AB1065.6030905@bell-labs.com> Date: Wed, 25 Jun 2014 13:09:41 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Emil Ivov , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> <53A0B8CA.3080107@jitsi.org> In-Reply-To: <53A0B8CA.3080107@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uAGcrwq6mwqBKOmZqaD73iXxe2U Cc: IESG IESG , mmusic Subject: Re: [MMUSIC] [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 18:08:26 -0000 On 06/17/2014 04:53 PM, Emil Ivov wrote: > Hey Vijay, > > Apologies for the delay! I believe we have addressed all comments and a > new version is available here: > > Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 > > Please see inline for the rest of my responses (points of accord removed): [...] Emil: Closing the loop on this one since I was pressed for time last week (traveling). I am fine with your proposed changes and the diffs look good. I have no further comments. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Wed Jun 25 14:57:45 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88A1A854B for ; Wed, 25 Jun 2014 14:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-S_VJOvmf90 for ; Wed, 25 Jun 2014 14:57:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F7D1B27A1 for ; Wed, 25 Jun 2014 14:57:41 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-d3-53ab45d35569 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EC.C7.28642.3D54BA35; Wed, 25 Jun 2014 23:57:39 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.174.1; Wed, 25 Jun 2014 23:57:38 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 037D0110293; Thu, 26 Jun 2014 00:57:39 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 88F915818B; Thu, 26 Jun 2014 00:58:07 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0758457DB8; Thu, 26 Jun 2014 00:58:06 +0300 (EEST) Message-ID: <53AB45CF.8030208@ericsson.com> Date: Wed, 25 Jun 2014 23:57:35 +0200 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Justin Uberti , "Stach, Thomas" References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje5l19XBBnPOqlis+ryJxWLrVCGL qcsfs1ic3LmN2YHFY8GmUo8lS34yeWzvecwSwBzFZZOSmpNZllqkb5fAldH2eCJbwUWtijOz 29gaGE/JdzFyckgImEhMmPmJDcIWk7hwbz2QzcUhJHCUUeLk+sPMEM4GRomDB6azQzh7GSWe nHvGAuGsY5T4vXc5I4SzglFi/dRFrCDDeAW0JV4/fsoIYrMIqEpMaznFDmKzCThK3H74EqxG VCBZYum6VWwQ9YISJ2c+YQGxRQSCJD4cWAJWwyzgLvFt/2dmEFtYwFZi4pJGsHohgRuMEmc3 WYPYnAKBEt/3bAeKcwDV20s82FoG0Sov0bx1NjPEb2oSV89tYoZoVZW4+u8V4wRG0VlINs9C 6J6FpHsBI/MqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMBoObjlt9UOxoPPHQ8xCnAwKvHw KvCtDhZiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwGcxjf bRf2Nw95fGbptMf3NmXwJSxRTGMosT7heDxP5LJ9l+SSNzoPp736stzvy66ZnaaXr22ue8q8 4MVm5+J/Hx+aRPeoGe+o2+zOErdExmTPHIufpZ913tgxV8qsXhw41/3MgZO5kqfmy4Z9bpLb 1/4hYal2q9/l3viMvc8r9RIF+q7OTWtXYinOSDTUYi4qTgQAMJWV2HcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vg-y1XKrIew8POuLGlN0-Ib8HKA Cc: "mmusic@ietf.org" , Jiayang Liu Subject: Re: [MMUSIC] ICE PRIORITY with multiple TURN servers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:57:44 -0000 Hi, This sounds like a good and simple thing to fix in 5245bis. I would suggest the following: For section 4.1.2.1 (http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-01#section-4.1.2.1): OLD: The local preference MUST be an integer from 0 to 65535 inclusive. It represents a preference for the particular IP address from which the candidate was obtained, in cases where an agent is multihomed. 65535 represents the highest preference, and a zero, the lowest. When there is only a single IP address, this value SHOULD be set to 65535. More generally, if there are multiple candidates for a particular component for a particular media stream that have the same type, the local preference MUST be unique for each one. In this specification, this only happens for multihomed hosts. [...] NEW: The local preference MUST be an integer from 0 to 65535 inclusive. It represents a preference for the particular IP address from which the candidate was obtained. 65535 represents the highest preference, and a zero, the lowest. When there is only a single IP address, this value SHOULD be set to 65535. More generally, if there are multiple candidates for a particular component for a particular media stream that have the same type, the local preference MUST be unique for each one. In this specification, this only happens for multihomed hosts or if an agent is using multiple TURN servers. [...] That is, removing first "(only) multihomed" comment and adding "multiple TURN servers" comment to the end. For the following section (4.1.2.2.) we could add after the first paragraph: If multiple TURN servers are used, local priorities for the candidates obtained from the TURN servers are chosen in a similar fashion as for multihomed local candidates: the local preference value is used to indicate preference among different servers but the preference MUST be unique for each one. Would that be OK? Cheers, Ari On 6/7/14 12:02 AM, Justin Uberti wrote: > Thanks. I think this could be made clearer in 5245 S 4.1.2.2, and > address the multiple relay server case specifically; right now, it is > all about assigning a local preference based on the network interface. > > Something to think about for -bis. > > > On Fri, Jun 6, 2014 at 12:11 AM, Stach, Thomas > wrote: > > Justin,____ > > __ __ > > *From:*mmusic [mailto:mmusic-bounces@ietf.org > ] *On Behalf Of *Justin Uberti > *Sent:* Freitag, 6. Juni 2014 03:09 > *To:* mmusic@ietf.org ; Mallinath Bareddy; > Jiayang Liu; Eric Rescorla > *Subject:* [MMUSIC] ICE PRIORITY with multiple TURN servers____ > > __ __ > > Consider the case where a single endpoint has 2 TURN servers, and > allocates a relay candidate from both, from the same local IP. What > should their PRIORITY values be?____ > > __ __ > > Quoth 5245, S 4.1.2:____ > > Each candidate for a media stream MUST have a unique____ > > priority that MUST be a positive integer between 1 and (2**31 - > 1).____ > > __ __ > > OK, so they have to have different priorities, i.e. either their > type preference or local preference must be different. But then, > looking at S 4.1.2.1 :____ > > The type preference MUST be identical for all____ > > candidates of the same type and MUST be different for candidates > of____ > > different types.____ > > __ __ > > Hmm, this means their local_preference must be different. But later > in S 4.1.2.1 :____ > > The local preference MUST be an integer from 0 to 65535 > inclusive.____ > > It represents a preference for the particular IP address from > which____ > > the candidate was obtained, in cases where an agent is > multihomed.____ > > __ __ > > Obviously, if they come from the same local IP, this cannot be > satisfied. What to do?____ > > */[TS] Well, that paragraph continues:____/* > > */__ __/* > > When there is only a single IP address, this value SHOULD be set > to____ > > 65535. More generally, if there are multiple candidates for a____ > > particular component for a particular media stream that have the > same____ > > type, the local preference MUST be unique for each one. ____ > > __ __ > > So the case of two TURN servers is covered. ____ > > What you propose below is OK, but if desired you could also rank > A1, A2, B1, B2. It’s your freedom of choice.____ > > Regards____ > > Thomas____ > > __ __ > > It seems like the easiest solution would be to use some of the local > preference to represent the ordering, so that both IP preference and > server preference and represented, and therefore relay candidates > from IPs 1 and 2 and Turn Servers A and B would stack rank as____ > > A1____ > > B1____ > > A2____ > > B2____ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Jun 26 04:19:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816CE1B2B12 for ; Thu, 26 Jun 2014 04:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi27mbFsvcIS for ; Thu, 26 Jun 2014 04:19:49 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B671B2A61 for ; Thu, 26 Jun 2014 04:19:48 -0700 (PDT) X-AuditID: c1b4fb30-f79da6d000006b80-02-53ac01d2f42d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.34.27520.2D10CA35; Thu, 26 Jun 2014 13:19:47 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Thu, 26 Jun 2014 13:17:06 +0200 From: Bo Burman To: Suhas Nandakumar , mmusic WG Thread-Topic: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis Thread-Index: AQHPjpRiotv8Y7tMYkKUeIpMo0+P8ZuDCknw Date: Thu, 26 Jun 2014 11:17:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E24FD39ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje5lxjXBBpsvMFlMXf6YxWLn3A5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj5ZMDrAVzbjNVPN9yjaWBccolpi5GDg4J AROJpm/xXYycQKaYxIV769m6GLk4hASOMkrM6JvCBOEsYZSYfvAtG0gVm4CGxPwddxlBbBEB d4l91z+zgtjCAsESizY/YIaIh0jMbF/DBGEbSTy+1QtmswioSry8txPM5hXwldhydzYLiC0k ECDxbdUbVpCDOAUCJe4eVwUJMwrIStz/fg+shFlAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuE rSjx8dU+Roj6fImFV96wQawSlDg58wnLBEaRWUhGzUJSNgtJ2SygK5gFNCXW79KHKFGUmNL9 kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAuDq45bfBDsaXzx0P MQpwMCrx8CrwrQ4WYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MPFUrVt97MDc8SJs1/xLH8RNbPTa//bpOaG6T4YSYrwXfGoN90y2DpaJZlJPWi1r6SF99 PudjnIqesMulZclTpqxZtn3hka1vFO8f8dJNWBQtX+wyW/am5sxnMXX3+/5k7npm1zlB/e6G Zql5jpmXE2PX1UR4L5HdLsdrbZz2ZMmjnka5U4falViKMxINtZiLihMBl0MkJ4wCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/I7u7NBO7SXwaHYBJsvAsNCj8a0w Subject: Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 11:19:52 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E24FD39ESESSMB105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VoYXMsIGFsbCwgcGxlYXNlIGZpbmQgY29tbWVudHMgaW5saW5lIGJlbG93IC9Cbw0KDQpGcm9t OiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1 aGFzIE5hbmRha3VtYXINClNlbnQ6IGRlbiAyMyBqdW5pIDIwMTQgMDU6MzcNClRvOiBtbXVzaWMg V0cNClN1YmplY3Q6IFtNTVVTSUNdIElTU1VFMTogU0RQIEF0dHJpYnV0ZXMgTXVsdGlwbGV4aW5n IC0gUGF5bG9hZCBUeXBlIEFuYWx5c2lzDQoNCkhlbGxvIEFsbA0KDQoNCiAgIENvbnRpbnVpbmcg dGhlIGRpc2N1c3Npb25zIGZyb20gTG9uZG9uIG9uIGFuYWx5emluZyBtdWx0aXBsZXhpbmcgYmVo YXZpb3IgZm9yIFNEUCBhdHRyaWJ1dGVzIHRoYXQgYXJlIGRlZmluZWQgcGVyICBQYXlsb2FkIFR5 cGUsIEkgd2FzIHRoaW5raW5nIG9uIG1ha2luZyBmb2xsb3dpbmcgY2hhbmdlcyB0byB0aGUgZHJh ZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTAxLg0KDQoxLiBBZGQgbmV3IGNhdGVn b3J5IGNhbGxlZCBJREVOVElDQUwtUEVSLVBUIHRvIHRoZSBTRFAgQXR0cmlidXRlIGFuYWx5c2lz IGZyYW1ld29yayBpbiBTZWN0aW9uIDQgd2hpY2ggaXMgZGVmaW5lZCBhcw0KDQpJREVOVElDQUwt UEVSLVBUOiBBdHRyaWJ1dGVzIHRoYXQgZGVmaW5lIHRoZSBSVFAgcGF5bG9hZCBjb25maWd1cmF0 aW9uIG9uIHBlciBQYXlsb2FkIFR5cGUgYmFzaXMgYW5kIE1VU1QgaGF2ZSBpZGVudGljYWwgdmFs dWVzIGFjcm9zcyBhbGwgdGhlIG1lZGlhIGRlc2NyaXB0aW9ucyBmb3IgYSBnaXZlbiBSVFAgUGF5 bG9hZCBUeXBlIHdoZW4gcmVwZWF0ZWQuDQpbQm9CXSBJIGJlbGlldmUgdGhpcyByZXF1aXJlbWVu dCBmb3IgY29uc2lzdGVuY3kgaXMgZ29vZCwgc3RyYWlnaHRmb3J3YXJkIGFuZCBzaW1wbGUuIE5v dGUgdGhhdCBhcyBhIGNvbnNlcXVlbmNlLCBpZiBhbnkgc2luZ2xlIG9uZSBvZiB0aGUgYnVuZGxl ZCBtZWRpYSBkZXNjcmlwdGlvbnMgaGFzIGEgcGF5bG9hZC1zcGVjaWZpYyBhdHRyaWJ1dGUgbGlz dGVkIGFzIElERU5USUNBTC1QRVItUFQgdXNpbmcg4oCYKuKAmSwgdGhhdCBhdHRyaWJ1dGUgaGFz IHRvIGJlIGlkZW50aWNhbCBmb3IgYWxsIFBUIGFjcm9zcyBhbGwgYnVuZGxlZCBtZWRpYSBkZXNj cmlwdGlvbnMuDQoNCkFwb2xvZ2llcyBpZiB5b3UgYWxyZWFkeSBkaXNjdXNzZWQgYW5kIHNldHRs ZWQgdGhpcywgYnV0IGl0IGRvZXMgbm90IHNlZW0gdG8gYmUgc3RyaWN0bHkgdGVjaG5pY2FsbHkg bmVjZXNzYXJ5IElGIGEgcmVjZWl2ZXIgY2FuIHJlbGF0ZSBhIHN0cmVhbSB0byBhIGNlcnRhaW4g bWVkaWEgZGVzY3JpcHRpb24sIHdoaWNoIGlzIHBvc3NpYmxlIGZvciBleGFtcGxlIGluIHRoZSBw cmVzZW5jZSBvZiBhPXNzcmMgKEFORCBJRiB0aGF0IFNTUkMgaXMgdW5pcXVlIGFjcm9zcyB0aGUg U0RQKSwgb3IgaW4gdGhlIHByZXNlbmNlIG9mIGE9YXBwSWQgKHdoaWNoIGhhcyB0byBiZSB1bmlx dWUgYWNyb3NzIHRoZSBTRFApLiBXZSBtYXkgaG93ZXZlciBjaG9vc2UgdG8gaWdub3JlIHRoYXQg ZmFjdCBpbiBmYXZvciBvZiBrZWVwaW5nIHRoZSBydWxlIHNpbXBsZS4NCg0KMi4gU2ltaWxhcmx5 IGFkZCBhbm90aGVyIGNhdGVnb3J5IElERU5USUNBTC1QRVItU1NSQyB0byBhY2NvbW1vZGF0ZSBz b3VyY2UgbGV2ZWwgU0RQIGF0dHJpYnV0ZXMuDQoNCklERU5USUNBTC1QRVItU1NSQzogQXR0cmli dXRlcyB0aGF0IGNvcnJlc3BvbmQgdG8gdGhlIGluZGl2aWR1YWwgUlRQIFBhY2tldCBTdHJlYW1z IGluIGEgZ2l2ZW4gUlRQIFNlc3Npb24gYW5kIE1VU1QgaGF2ZSBpZGVudGljYWwgdmFsdWVzIHdo ZW4gcmVwZWF0ZWQgYWNyb3NzIG11bHRpcGxlIG1lZGlhIGRlc2NyaXB0aW9uIGZvciBhIGdpdmVu IFNTUkMuDQpbQm9CXSBUaGlzIHJ1bGUgd291bGQgb25seSBiZSB1c2VkIHdoZW5ldmVyIHRoZSBz YW1lIFNTUkMgdmFsdWUgd2FzIGV4cGxpY2l0bHkgbGlzdGVkIHVuZGVyIG11bHRpcGxlIG1lZGlh IGRlc2NyaXB0aW9ucywgcmlnaHQ/IFNpbmNlIHRoZSBtZWRpYSBkZXNjcmlwdGlvbnMgYXJlIGJ1 bmRsZWQsIHRob3NlIHN0cmVhbXMgd2lsbCBiZSBpbiB0aGUgc2FtZSBSVFAgc2Vzc2lvbiBhbmQg d2lsbCBlZmZlY3RpdmVseSBiZWNvbWUgcGFydCBvZiBvbmUgYW5kIHRoZSBzYW1lIHN0cmVhbSwg c2hhcmluZyB0aGUgc2FtZSBSVFAgdGltZXN0YW1wIGFuZCBzZXF1ZW5jZSBudW1iZXIgc3BhY2Uu IElzIHRoaXMgcmVhbGx5IGEgdXNlZnVsIGNhc2UgdG8gZGVzY3JpYmUsIG9yIGlzIGl0IG5vdCBy YXRoZXIgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIGF2b2lkZWQ/IFdoYXQgeW91IGVmZmVjdGl2 ZWx5IGRlc2NyaWJlIGlzIGEgc2luZ2xlIHN0cmVhbSB0aGF0IGhhcyBpdHMgY29uZmlndXJhdGlv biBzcHJlYWQgb3V0IGFjcm9zcyBtdWx0aXBsZSBtZWRpYSBkZXNjcmlwdGlvbnMuDQoNCjMuIEZv ciBhbGwgdGhlIGF0dHJpYnV0ZXMgdGhhdCBkaXJlY3RseS9pbmRpcmVjdGx5IGltcGFjdCBjb2Rl YyBjb25maWd1cmF0aW9uIGFuZCBwYWNrZXRpemF0aW9uIG9mIHRoZSBtZWRpYSwgSSBoYXZlIGF0 dGVtcHRlZCB0byBhc3NpZ24gYSBTRFAgTVVYIGNhdGVnb3J5IGFuZCBwcm92aWRlIHNvbWUgaW5z aWdodHMgb24gaG93IHN1Y2ggYSBkZWNpc2lvbiB3YXMgbWFkZSAod2hlcmV2ZXIgYXBwbGljYWJs ZSkNCg0KQXR0cmlidXRlOiBhPXB0aW1lLCBhPW1heHB0aW1lDQpNdXggQ2F0ZWdvcnk6IElERU5U SUNBTC1QRVItUFQNCk5vdGVzOiBGb3IgYSBnaXZlbiBjb2RlYyB0aGUgYXVkaW8gcGFja2V0aXph dGlvbiB0aW1lIG11c3QgYmUgc2FtZSBpZiB0aGUgUFQgaXMgcmVwZWF0ZWQuIFRoaXMgd2lsbCBl bnN1cmUgdGhhdCB0aGUgUlRQIHJlY2VpdmVyIGNhbiB1bmFtYmlndW91c2x5IGRlY29kZSB0aGUg aW5jb21pbmcgYXVkaW8gcGFja2V0cy4NCltCb0JdIE1ha2VzIHNlbnNlLiBTaW5jZSB0aG9zZSBh dHRyaWJ1dGVzIGFyZSBub3QgcGF5bG9hZCBzcGVjaWZpYywgdGhleSBvZiBjb3Vyc2UgYXBwbHkg YW5kIHB1dHMgcmVzdHJpY3Rpb25zIG9uIGFueSBQVCBwcmVzZW50IGluIHRoYXQgbWVkaWEgZGVz Y3JpcHRpb24uDQoNCg0KQXR0cmlidXRlOiBhPWZyYW1lcmF0ZQ0KTXV4IENhdGVnb3J5OiBJREVO VElDQUwtUEVSLVBUDQpbQm9CXSBNYWtlcyBzZW5zZS4gQXMgYWJvdmUsIGFwcGxpZXMgdG8gYWxs IFBUIHByZXNlbnQgaW4gdGhhdCBtZWRpYSBkZXNjcmlwdGlvbi4NCg0KQXR0cmlidXRlOiBhPXJ0 cG1hcA0KTXV4IENhdGVnb3J5OiBJREVOVElDQUwtUEVSLVBUDQpbQm9CXSBNYWtlcyBzZW5zZS4N Cg0KDQpBdHRyaWJ1dGU6IGE9Zm10cA0KTXV4IENhdGVnb3J5OiBJREVOVElDQUwtUEVSLVBUDQpO b3RlczoNCltCb0JdIE1ha2VzIHNlbnNlLg0KDQpBdHRyaWJ1dGU6IGE9cnRjcC1mYg0KTXV4IENh dGVnb3J5OiBOT1JNQUwNCk5vdGVzOiBTaW5jZSB0aGUgZmVlZGJhY2sgbWVzc2FnZXMgYXJlIHJl cG9ydGVkIHBlciBTU1JDLCB0aGUgY2F0ZWdvcnkgb2YgTk9STUFMIHN1ZmZpY2VzLg0KW0JvQl0g SSBiZWxpZXZlIElERU5USUNBTC1QRVItUFQgaXMgbW9yZSBhcHByb3ByaWF0ZSwgc2luY2UgcGVy IFJGQyA0NTg1IFJUQ1AgcmVjZWl2ZXJzIOKAmOKApk1VU1QgTk9UIHVzZSBvdGhlciBGQiBtZXNz YWdlcyB0aGFuIHRob3NlIGxpc3RlZCBpbiBvbmUgb2YgdGhlIOKAnHJ0Y3AtZmLigJ0gYXR0cmli dXRlIGxpbmVz4oCZLCB3aGljaCBJIHRoaW5rIHdvdWxkIGNhdXNlIGEgY29uZmxpY3QgZm9yIE5P Uk1BTC4NCg0KQXR0cmlidXRlOiBhPWRlcGVuZCAoUkZDNTU4MykNCk11eCBDYXRlZ29yeTogSURF TlRJQ0FMLVBFUi1QVA0KTm90ZXM6DQpTaW5jZSBlYWNoIGRlcGVuZGVuY3kgaWRlbnRpZmllcyBh IHVuaXF1ZSBSVFAgcGFja2V0aXphdGlvbiAgYW5kIHRodXMgTVVTVCBiZSBpZGVudGlmaWVkIHZp YSB1bmlxdWUgUGF5bG9hZCBUeXBlLg0KU2ltaWxhcmx5IGlmIHRoZSBQYXlsb2FkIFR5cGUgaXMg cmVwZWF0ZWQgYWNyb3NzIG1lZGlhIGRlc2NyaXB0aW9ucywgdGhleSBNVVNUIHJlcHJlc2VudCB0 aGUgSWRlbnRpY2FsIGNvZGVjIGNvbmZpZ3VyYXRpb24uDQpbQm9CXSBNYWtlcyBzZW5zZQ0KDQpB dHRyaWJ1dGU6IGE9c3NyYzp4eXogIGZtdHA6PGZtdD4gLi4uDQpNdXggQ2F0ZWdvcnk6IElERU5U SUNBTC1QRVItUFQNCk5vdGVzOg0KUkZDNTU3NiBzYXlzIHRoaXMgOg0KIg0KV2l0aGluIGEgbWVk aWEgc3RyZWFtLCAic3NyYyIgYXR0cmlidXRlcyB3aXRoIHRoZSBzYW1lIHZhbHVlIG9mDQoNCg0K DQo8c3NyYy1pZD4gZGVzY3JpYmUgZGlmZmVyZW50IGF0dHJpYnV0ZXMgb2YgdGhlIHNhbWUgbWVk aWEgc291cmNlcy4NCg0KQWNyb3NzIG1lZGlhIHN0cmVhbXMsIDxzc3JjLWlkPiB2YWx1ZXMgYXJl IG5vdCBjb3JyZWxhdGVkICh1bmxlc3MNCg0KY29ycmVsYXRpb24gaXMgaW5kaWNhdGVkIGJ5IG1l ZGlhLXN0cmVhbSBncm91cGluZyBvciBzb21lIG90aGVyDQoNCm1lY2hhbmlzbSkgYW5kIE1BWSBi ZSByZXBlYXRlZC4NCg0KIg0KDQoNCg0KVGh1cyBpZiB0aGUgUlRQIFBheWxvYWQgVHlwZSB1c2Vk IHRvIHNwZWNpZnkgZm10cCBwYXJhbWV0ZXJzICBpcyByZXBlYXRlZCwgaXQgTVVTVCByZXByZXNl bnQgdGhlIHNhbWUgY29kZWMgY29uZmlndXJhdGlvbi4NCg0KZXhhbXBsZToNCg0KDQoNCm09dmlk ZW8gLi4uDQoNCmE9cnRwbWFwOjk4IFZQOC85MDAwMA0KDQphPXNzcmM6MTIzNDUgZm10cDo5OG1h eC1mcj0xNTsgbWF4LWZzLTEyMDANCg0KDQoNCg0KDQptPXZpZGVvIC4uLg0KDQphPXJ0cG1hcDo5 OCBWUDgvOTAwMDANCg0KDQoNCmE9c3NyYzo1Njc4OSBmbXRwOjk4IG1heC1mcj0xNTsgbWF4LWZz LTEyMDANCg0KDQoNCltCb0JdIE9LLiBSZWxhdGVzIHRvIG15IGNvbW1lbnQgb24gSURFTlRJQ0FM LVBFUi1QVDsgdGhlIGFib3ZlIHByb3Bvc2FsIHByaW9yaXRpemVzIHRvIGtlZXAgdGhlIHNhbWUg ZGVmaW5pdGlvbiBhbmQgdGh1cyB0aGUgcnVsZSBzaW1wbGUuDQoNCg0KDQoNCkF0dHJpYnV0ZTog YT1zc3JjOnh5eiAgY25hbWU6IC4uLi4NCk11eCBDYXRlZ29yeTogSURFTlRJQ0FMLVBFUi1TU1JD DQpOb3RlczogUkZDNTU3NiBkZWZpbmVzIHRoZSBpZGVudGljYWwgcmVxdWlyZW1lbnQgYXMgaXQg aXMuDQpbQm9CXSBTbywgbWF5YmUgbm90IG5lZWRlZCBhbmQgdGh1cyBOT1JNQUw/IEFzIHNhaWQg YWJvdmUsIEkgcXVlc3Rpb24gdGhlIHVzZWZ1bG5lc3Mgb2YgSURFTlRJQ0FMLVBFUi1TU1JDIGNh dGVnb3J5Lg0KDQoNCkF0dHJpYnV0ZTogYT1pbWFnZWF0dHINCk11eCBDYXRlZ29yeTogSURFTlRJ Q0FMLVBFUi1QVA0KW0JvQl0gT0sNCg0KDQpBdHRyaWJ1dGU6IGE9ZnJhbWVzaXplDQpNdXggQ2F0 ZWdvcnk6IElERU5USUNBTC1QRVItUFQNCltCb0JdIE9LDQoNCg0KQXR0cmlidXRlczogYT1mZWMt c291cmNlLWZsb3csIGE9ZmVjLXJlcGFpci1mbG93LCBhPXJlcGFpci13aW5kb3cNCk11eCBDYXRl Z29yeTogTk9STUFMDQpbQm9CXSBJIHdvbmRlciBpZiB0aGlzIGlzIHN1ZmZpY2llbnQsIG9yIGlm IGl0IGhhcyB0byBiZSBTUEVDSUFMPyBJdCBzZWVtcyB0byBtZSB5b3UgbmVlZCBhIG5ldyBBRFUg aWRlbnRpZmljYXRpb24gbWVjaGFuaXNtLiBXaGVuIGJ1bmRsaW5nIG1lZGlhIGRlc2NyaXB0aW9u cywgdGhlIEFEVSBpZGVudGlmaWNhdGlvbiB1c2VkIGJ5IFJGQyA2MzYzIGFuZCA2MzY0IG1ha2Vz IGFsbCBBRFUgZmxvd3MsIHNvdXJjZSBhbmQgcmVwYWlyIGFsaWtlLCBlZmZlY3RpdmVseSBiZWNv bWUgb25lIGFuZCB0aGUgc2FtZSBBRFUgZmxvdy4gRnJvbSBzZWN0aW9uIDMgb2YgUkZDIDYzNjM6 DQogICBJbiB0aGlzIGFyY2hpdGVjdHVyZSwgd2UgYXNzdW1lIHRoYXQgdGhlIGludGVyZmFjZSB0 byB0aGUgdHJhbnNwb3J0DQogICBsYXllciBzdXBwb3J0cyB0aGUgY29uY2VwdHMgb2YgZGF0YSB1 bml0cyAocmVmZXJyZWQgdG8gaGVyZSBhcw0KICAgQXBwbGljYXRpb24gRGF0YSBVbml0cyAoQURV cykpIHRvIGJlIHRyYW5zcG9ydGVkIGFuZCBpZGVudGlmaWNhdGlvbg0KICAgb2YgQURVIGZsb3dz IG9uIHdoaWNoIHRob3NlIGRhdGEgdW5pdHMgYXJlIHRyYW5zcG9ydGVkLg0KDQoNCg0KDQpJIGJl bGlldmUgdGhlc2UgY292ZXIgYWxsIFBUIHNjb3BlZCBTRFAgYXR0cmlidXRlcy4gUGxlYXNlIGxl dCBtZSBrbm93IHlvdXIgdGhvdWdodHMgYW5kIGNvbW1lbnRzLg0KDQpDaGVlcnMNClN1aGFzIE5h bmRha3VtYXINCg== --_000_BBE9739C2C302046BD34B42713A1E2A22E24FD39ESESSMB105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5T dWhhcywgYWxsLCBwbGVhc2UgZmluZCBjb21tZW50cyBpbmxpbmUgYmVsb3cgL0JvPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYyBbbWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdWhhcyBOYW5kYWt1bWFy PGJyPg0KPGI+U2VudDo8L2I+IGRlbiAyMyBqdW5pIDIwMTQgMDU6Mzc8YnI+DQo8Yj5Ubzo8L2I+ IG1tdXNpYyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTU1VU0lDXSBJU1NVRTE6IFNEUCBBdHRy aWJ1dGVzIE11bHRpcGxleGluZyAtIFBheWxvYWQgVHlwZSBBbmFseXNpczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IZWxs byBBbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7Q29u dGludWluZyB0aGUgZGlzY3Vzc2lvbnMgZnJvbSBMb25kb24gb24gYW5hbHl6aW5nIG11bHRpcGxl eGluZyBiZWhhdmlvciBmb3IgU0RQIGF0dHJpYnV0ZXMgdGhhdCBhcmUgZGVmaW5lZCBwZXIgJm5i c3A7UGF5bG9hZCBUeXBlLCBJIHdhcyB0aGlua2luZyBvbiBtYWtpbmcgZm9sbG93aW5nIGNoYW5n ZXMgdG8gdGhlIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0wMS4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjEuIEFkZCBuZXcgY2F0ZWdvcnkgY2FsbGVkIElERU5USUNBTC1QRVIt UFQgdG8gdGhlIFNEUCBBdHRyaWJ1dGUgYW5hbHlzaXMgZnJhbWV3b3JrIGluIFNlY3Rpb24gNCB3 aGljaCBpcyBkZWZpbmVkIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JREVOVElDQUwtUEVSLVBUOiBBdHRy aWJ1dGVzIHRoYXQgZGVmaW5lIHRoZSBSVFAgcGF5bG9hZCBjb25maWd1cmF0aW9uIG9uIHBlciBQ YXlsb2FkIFR5cGUgYmFzaXMgYW5kIE1VU1QgaGF2ZSBpZGVudGljYWwgdmFsdWVzIGFjcm9zcyZu YnNwO2FsbCB0aGUgbWVkaWEgZGVzY3JpcHRpb25zIGZvciBhIGdpdmVuIFJUUCBQYXlsb2FkIFR5 cGUNCiB3aGVuIHJlcGVhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b Qm9CXSBJIGJlbGlldmUgdGhpcyByZXF1aXJlbWVudCBmb3IgY29uc2lzdGVuY3kgaXMgZ29vZCwg c3RyYWlnaHRmb3J3YXJkIGFuZCBzaW1wbGUuIE5vdGUgdGhhdCBhcyBhIGNvbnNlcXVlbmNlLCBp Zg0KPHU+YW55IHNpbmdsZSBvbmU8L3U+IG9mIHRoZSBidW5kbGVkIG1lZGlhIGRlc2NyaXB0aW9u cyBoYXMgYSBwYXlsb2FkLXNwZWNpZmljIGF0dHJpYnV0ZSBsaXN0ZWQgYXMgSURFTlRJQ0FMLVBF Ui1QVCB1c2luZyDigJgq4oCZLCB0aGF0IGF0dHJpYnV0ZSBoYXMgdG8gYmUgaWRlbnRpY2FsIGZv cg0KPHU+YWxsPC91PiBQVCBhY3Jvc3MgPHU+YWxsPC91PiBidW5kbGVkIG1lZGlhIGRlc2NyaXB0 aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcG9sb2dpZXMgaWYg eW91IGFscmVhZHkgZGlzY3Vzc2VkIGFuZCBzZXR0bGVkIHRoaXMsIGJ1dCBpdCBkb2VzIG5vdCBz ZWVtIHRvIGJlIHN0cmljdGx5IHRlY2huaWNhbGx5IG5lY2Vzc2FyeSBJRiBhIHJlY2VpdmVyIGNh biByZWxhdGUgYSBzdHJlYW0gdG8gYQ0KIGNlcnRhaW4gbWVkaWEgZGVzY3JpcHRpb24sIHdoaWNo IGlzIHBvc3NpYmxlIGZvciBleGFtcGxlIGluIHRoZSBwcmVzZW5jZSBvZiBhPXNzcmMgKEFORCBJ RiB0aGF0IFNTUkMgaXMgdW5pcXVlIGFjcm9zcyB0aGUgU0RQKSwgb3IgaW4gdGhlIHByZXNlbmNl IG9mIGE9YXBwSWQgKHdoaWNoIGhhcyB0byBiZSB1bmlxdWUgYWNyb3NzIHRoZSBTRFApLiBXZSBt YXkgaG93ZXZlciBjaG9vc2UgdG8gaWdub3JlIHRoYXQgZmFjdCBpbiBmYXZvciBvZiBrZWVwaW5n DQogdGhlIHJ1bGUgc2ltcGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yLiBTaW1pbGFybHkg YWRkIGFub3RoZXIgY2F0ZWdvcnkgSURFTlRJQ0FMLVBFUi1TU1JDIHRvIGFjY29tbW9kYXRlIHNv dXJjZSBsZXZlbCBTRFAgYXR0cmlidXRlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JREVOVElD QUwtUEVSLVNTUkM6IEF0dHJpYnV0ZXMgdGhhdCBjb3JyZXNwb25kIHRvIHRoZSBpbmRpdmlkdWFs IFJUUCBQYWNrZXQgU3RyZWFtcyBpbiBhIGdpdmVuIFJUUCBTZXNzaW9uIGFuZCBNVVNUIGhhdmUg aWRlbnRpY2FsIHZhbHVlcyB3aGVuIHJlcGVhdGVkIGFjcm9zcyBtdWx0aXBsZSBtZWRpYSBkZXNj cmlwdGlvbiBmb3INCiBhIGdpdmVuIFNTUkMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPltCb0JdIFRoaXMgcnVsZSB3b3VsZCBvbmx5IGJlIHVzZWQgd2hlbmV2ZXIgdGhlIHNh bWUgU1NSQyB2YWx1ZSB3YXMgZXhwbGljaXRseSBsaXN0ZWQgdW5kZXIgbXVsdGlwbGUgbWVkaWEg ZGVzY3JpcHRpb25zLCByaWdodD8gU2luY2UgdGhlIG1lZGlhIGRlc2NyaXB0aW9ucw0KIGFyZSBi dW5kbGVkLCB0aG9zZSBzdHJlYW1zIHdpbGwgYmUgaW4gdGhlIHNhbWUgUlRQIHNlc3Npb24gYW5k IHdpbGwgZWZmZWN0aXZlbHkgYmVjb21lIHBhcnQgb2Ygb25lIGFuZCB0aGUgc2FtZSBzdHJlYW0s IHNoYXJpbmcgdGhlIHNhbWUgUlRQIHRpbWVzdGFtcCBhbmQgc2VxdWVuY2UgbnVtYmVyIHNwYWNl LiBJcyB0aGlzIHJlYWxseSBhIHVzZWZ1bCBjYXNlIHRvIGRlc2NyaWJlLCBvciBpcyBpdCBub3Qg cmF0aGVyIHNvbWV0aGluZyB0aGF0IHNob3VsZA0KIGJlIGF2b2lkZWQ/IFdoYXQgeW91IGVmZmVj dGl2ZWx5IGRlc2NyaWJlIGlzIGEgc2luZ2xlIHN0cmVhbSB0aGF0IGhhcyBpdHMgY29uZmlndXJh dGlvbiBzcHJlYWQgb3V0IGFjcm9zcyBtdWx0aXBsZSBtZWRpYSBkZXNjcmlwdGlvbnMuPC9zcGFu PjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4zLiBGb3IgYWxsIHRoZSBhdHRyaWJ1dGVzIHRoYXQgZGlyZWN0 bHkvaW5kaXJlY3RseSBpbXBhY3QgY29kZWMgY29uZmlndXJhdGlvbiBhbmQgcGFja2V0aXphdGlv biBvZiB0aGUgbWVkaWEsIEkgaGF2ZSBhdHRlbXB0ZWQgdG8gYXNzaWduIGEgU0RQIE1VWCBjYXRl Z29yeSBhbmQgcHJvdmlkZSBzb21lIGluc2lnaHRzIG9uIGhvdw0KIHN1Y2ggYSBkZWNpc2lvbiB3 YXMgbWFkZSAod2hlcmV2ZXIgYXBwbGljYWJsZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0dHJpYnV0 ZTogYT1wdGltZSwgYT1tYXhwdGltZTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NdXggQ2F0ZWdvcnk6IElE RU5USUNBTC1QRVItUFQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ob3RlczogRm9yIGEgZ2l2ZW4gY29kZWMgdGhl IGF1ZGlvIHBhY2tldGl6YXRpb24gdGltZSBtdXN0IGJlIHNhbWUgaWYgdGhlIFBUIGlzIHJlcGVh dGVkLiBUaGlzIHdpbGwgZW5zdXJlIHRoYXQgdGhlIFJUUCByZWNlaXZlciBjYW4mbmJzcDt1bmFt YmlndW91c2x5Jm5ic3A7ZGVjb2RlIHRoZSBpbmNvbWluZyBhdWRpbyBwYWNrZXRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQm9CXSBNYWtlcyBzZW5zZS4gU2luY2UgdGhv c2UgYXR0cmlidXRlcyBhcmUgbm90IHBheWxvYWQgc3BlY2lmaWMsIHRoZXkgb2YgY291cnNlIGFw cGx5IGFuZCBwdXRzIHJlc3RyaWN0aW9ucyBvbiBhbnkgUFQgcHJlc2VudCBpbiB0aGF0IG1lZGlh IGRlc2NyaXB0aW9uLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0dHJpYnV0ZTogYT1m cmFtZXJhdGU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NdXgg Q2F0ZWdvcnk6IElERU5USUNBTC1QRVItUFQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+W0JvQl0gTWFrZXMgc2Vuc2UuIEFzIGFib3ZlLCBhcHBsaWVzIHRvIGFsbCBQVCBwcmVz ZW50IGluIHRoYXQgbWVkaWEgZGVzY3JpcHRpb24uPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0dHJpYnV0ZTogYT1ydHBtYXA8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NdXggQ2F0ZWdvcnk6IElERU5USUNB TC1QRVItUFQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JvQl0gTWFrZXMg c2Vuc2UuDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0dHJpYnV0ZTogYT1mbXRwPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TXV4IENhdGVnb3J5OiBJREVOVElDQUwt UEVSLVBUPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ob3RlczombmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JvQl0gTWFrZXMgc2Vuc2UuPC9zcGFuPjwv aT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0dHJpYnV0ZTogYT1ydGNwLWZiPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11eCBDYXRlZ29yeTogTk9S TUFMPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Tm90ZXM6IFNpbmNlIHRoZSBmZWVkYmFjayBtZXNzYWdlcyBhcmUg cmVwb3J0ZWQgcGVyIFNTUkMsIHRoZSBjYXRlZ29yeSBvZiBOT1JNQUwgc3VmZmljZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCb0JdIEkgYmVsaWV2ZSBJREVOVElDQUwt UEVSLVBUIGlzIG1vcmUgYXBwcm9wcmlhdGUsIHNpbmNlIHBlciBSRkMgNDU4NSBSVENQIHJlY2Vp dmVycyDigJjigKZNVVNUIE5PVCB1c2Ugb3RoZXIgRkIgbWVzc2FnZXMgdGhhbiB0aG9zZSBsaXN0 ZWQgaW4gb25lIG9mIHRoZQ0KIOKAnHJ0Y3AtZmLigJ0gYXR0cmlidXRlIGxpbmVz4oCZLCB3aGlj aCBJIHRoaW5rIHdvdWxkIGNhdXNlIGEgY29uZmxpY3QgZm9yIE5PUk1BTC48L3NwYW4+PC9pPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QXR0cmlidXRlOiBhPWRlcGVuZCAoUkZDNTU4Myk8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11eCBDYXRlZ29yeTogSURFTlRJ Q0FMLVBFUi1QVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk5vdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaW5j ZSBlYWNoIGRlcGVuZGVuY3kgaWRlbnRpZmllcyBhIHVuaXF1ZSBSVFAgcGFja2V0aXphdGlvbiAm bmJzcDthbmQgdGh1cyBNVVNUIGJlIGlkZW50aWZpZWQgdmlhIHVuaXF1ZSBQYXlsb2FkIFR5cGUu Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2ltaWxhcmx5IGlmIHRoZSBQYXlsb2FkIFR5cGUgaXMgcmVw ZWF0ZWQgYWNyb3NzIG1lZGlhIGRlc2NyaXB0aW9ucywgdGhleSBNVVNUIHJlcHJlc2VudCB0aGUg SWRlbnRpY2FsIGNvZGVjIGNvbmZpZ3VyYXRpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltCb0JdIE1ha2VzIHNlbnNlPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkF0dHJpYnV0ZTogYT1zc3JjOnh5eiAmbmJzcDtmbXRwOiZsdDtmbXQm Z3Q7IC4uLiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TXV4IENh dGVnb3J5OiBJREVOVElDQUwtUEVSLVBUPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Tm90ZXM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+UkZDNTU3NiBzYXlzIHRoaXMgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90OyAmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5XaXRoaW4gYSBtZWRpYSBzdHJlYW0sICZxdW90O3NzcmMmcXVv dDsgYXR0cmlidXRlcyB3aXRoIHRoZSBzYW1lIHZhbHVlIG9mPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmx0O3NzcmMtaWQmZ3Q7 IGRlc2NyaWJlIGRpZmZlcmVudCBhdHRyaWJ1dGVzIG9mIHRoZSBzYW1lIG1lZGlhIHNvdXJjZXMu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+QWNyb3NzIG1lZGlhIHN0cmVhbXMsICZsdDtzc3JjLWlkJmd0OyB2YWx1 ZXMgYXJlIG5vdCBjb3JyZWxhdGVkICh1bmxlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5jb3JyZWxhdGlvbiBp cyBpbmRpY2F0ZWQgYnkgbWVkaWEtc3RyZWFtIGdyb3VwaW5nIG9yIHNvbWUgb3RoZXI8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pm1lY2hhbmlzbSkgYW5kIE1BWSBiZSByZXBlYXRlZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZxdW90Ozwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaHVzIGlmIHRoZSBSVFAgUGF5bG9hZCBUeXBlIHVzZWQgdG8g c3BlY2lmeSBmbXRwIHBhcmFtZXRlcnMmbmJzcDsgaXMgcmVwZWF0ZWQsIGl0IE1VU1QgcmVwcmVz ZW50IHRoZSBzYW1lIGNvZGVjIGNvbmZpZ3VyYXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5leGFtcGxlOjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5tPXZpZGVvIC4uLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+YT1ydHBtYXA6OTggVlA4 LzkwMDAwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5hPXNzcmM6MTIzNDUgZm10cDo5OG1heC1mcj0xNTsgbWF4LWZzLTEyMDA8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5tPXZp ZGVvIC4uLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+YT1ydHBtYXA6OTggVlA4LzkwMDAwPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPmE9c3NyYzo1Njc4OSBmbXRwOjk4IG1heC1mcj0xNTsgbWF4LWZzLTEyMDA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JvQl0gT0suIFJlbGF0 ZXMgdG8gbXkgY29tbWVudCBvbiBJREVOVElDQUwtUEVSLVBUOyB0aGUgYWJvdmUgcHJvcG9zYWwg cHJpb3JpdGl6ZXMgdG8ga2VlcCB0aGUgc2FtZSBkZWZpbml0aW9uIGFuZCB0aHVzIHRoZSBydWxl IHNpbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj48YnI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdHRyaWJ1dGU6IGE9c3NyYzp4eXogJm5i c3A7Y25hbWU6IC4uLi48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11eCBD YXRlZ29yeTogSURFTlRJQ0FMLVBFUi1TU1JDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Tm90ZXM6IFJGQzU1NzYg ZGVmaW5lcyB0aGUgaWRlbnRpY2FsIHJlcXVpcmVtZW50IGFzIGl0IGlzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQm9CXSBTbywgbWF5YmUgbm90IG5lZWRlZCBhbmQgdGh1 cyBOT1JNQUw/IEFzIHNhaWQgYWJvdmUsIEkgcXVlc3Rpb24gdGhlIHVzZWZ1bG5lc3Mgb2YgSURF TlRJQ0FMLVBFUi1TU1JDIGNhdGVnb3J5Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdHRyaWJ1dGU6IGE9 aW1hZ2VhdHRyPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NdXggQ2F0ZWdv cnk6IElERU5USUNBTC1QRVItUFQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W0JvQl0gT0s8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdHRyaWJ1dGU6IGE9ZnJhbWVzaXplPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NdXggQ2F0ZWdvcnk6IElERU5USUNBTC1QRVItUFQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JvQl0gT0s8L3NwYW4+PC9pPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0dHJp YnV0ZXM6IGE9PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5mZWMtc291cmNlLWZsb3csIGE9ZmVj LXJlcGFpci1mbG93LCBhPXJlcGFpci13aW5kb3c8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5NdXggQ2F0ZWdvcnk6IE5PUk1BTDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bQm9CXSBJIHdvbmRlciBpZiB0aGlzIGlzIHN1ZmZpY2llbnQsIG9y IGlmIGl0IGhhcyB0byBiZSBTUEVDSUFMPyBJdCBzZWVtcyB0byBtZSB5b3UgbmVlZCBhIG5ldyBB RFUgaWRlbnRpZmljYXRpb24gbWVjaGFuaXNtLiBXaGVuIGJ1bmRsaW5nIG1lZGlhIGRlc2NyaXB0 aW9ucywNCiB0aGUgQURVIGlkZW50aWZpY2F0aW9uIHVzZWQgYnkgUkZDIDYzNjMgYW5kIDYzNjQg bWFrZXMgYWxsIEFEVSBmbG93cywgc291cmNlIGFuZCByZXBhaXIgYWxpa2UsIGVmZmVjdGl2ZWx5 IGJlY29tZSBvbmUgYW5kIHRoZSBzYW1lIEFEVSBmbG93LiBGcm9tIHNlY3Rpb24gMyBvZiBSRkMg NjM2Mzo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDo3LjVwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEluIHRoaXMgYXJjaGl0ZWN0dXJlLCB3ZSBhc3N1 bWUgdGhhdCB0aGUgaW50ZXJmYWNlIHRvIHRoZSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ny41cHQ7cGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBsYXll ciBzdXBwb3J0cyB0aGUgY29uY2VwdHMgb2YgZGF0YSB1bml0cyAocmVmZXJyZWQgdG8gaGVyZSBh czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDo3LjVwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9uIERhdGEgVW5pdHMgKEFEVXMpKSB0byBiZSB0cmFu c3BvcnRlZCBhbmQgaWRlbnRpZmljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ny41cHQ7cGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvZiBBRFUgZmxvd3Mgb24g d2hpY2ggdGhvc2UgZGF0YSB1bml0cyBhcmUgdHJhbnNwb3J0ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBiZWxpZXZlIHRoZXNlIGNvdmVyIGFsbCBQVCBzY29wZWQg U0RQIGF0dHJpYnV0ZXMuIFBsZWFzZSBsZXQgbWUga25vdyB5b3VyIHRob3VnaHRzIGFuZCBjb21t ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DaGVlcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5TdWhhcyBOYW5kYWt1bWFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BBE9739C2C302046BD34B42713A1E2A22E24FD39ESESSMB105erics_-- From nobody Thu Jun 26 08:37:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D895C1B3126 for ; Thu, 26 Jun 2014 08:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BOvIC6NCLuW for ; Thu, 26 Jun 2014 08:37:08 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4F31B3152 for ; Thu, 26 Jun 2014 07:43:29 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so3582579wgg.1 for ; Thu, 26 Jun 2014 07:43:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=muwJFxgoOirOMwAtbS6SeBeY2YiCB+Hg2XJiBEkjVtg=; b=gQcukl3hJb7lQgJi/OydCD+GPOq6C/ksz1jZDhY7rYmTqGK8BZ/RZ9HlIhUPLjsx97 7ibHyVpHB3roUdeoiChwACpwceA1gTYVLntEePERooLAMM1ViTCSOokd52kxA8J0MzPI G2Y61pWleAleMj/ysmszYXMjhSJ8x8z1MDb7NDGGg3Y8984MaUOY2Afy/YcM1TBQ30rx +JQ4elOpPt6KTToQSewMQjxXIhMRlOgbD4JqrMNd8OZyWBE2Fq0LzyNoWWjmNOk/WiiA Pvhd8BoiIBylVkqpmxX44VWruyAjSOP/ffljs9jOoyYjq6CJduKZ4RhuFKVf3QR0seF2 5++w== X-Gm-Message-State: ALoCoQlsVjx+OQ7Ab0iOK75zNaCCy248o6sfsUhk+gJB0tA7Gut9wF4AU3W5/3DATgE6cGpYTHbU X-Received: by 10.195.13.102 with SMTP id ex6mr17960304wjd.48.1403793802772; Thu, 26 Jun 2014 07:43:22 -0700 (PDT) Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id i4sm25186350wib.21.2014.06.26.07.43.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 07:43:21 -0700 (PDT) Message-ID: <53AC3179.1010900@jitsi.org> Date: Thu, 26 Jun 2014 17:43:05 +0300 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Vijay K. Gurbani" , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> <538663F1.4080709@jitsi.org> <538C8820.1090900@bell-labs.com> <53A0B8CA.3080107@jitsi.org> <53AB1065.6030905@bell-labs.com> In-Reply-To: <53AB1065.6030905@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8ZLLv172vVCja2sVCthcru1crEw Cc: IESG IESG , mmusic Subject: Re: [MMUSIC] [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:37:12 -0000 Great! Thanks very much Vijay! Emil On 25.06.14, 21:09, Vijay K. Gurbani wrote: > On 06/17/2014 04:53 PM, Emil Ivov wrote: >> Hey Vijay, >> >> Apologies for the delay! I believe we have addressed all comments and a >> new version is available here: >> >> Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08 >> >> Please see inline for the rest of my responses (points of accord >> removed): > [...] > > Emil: Closing the loop on this one since I was pressed for time last > week (traveling). > > I am fine with your proposed changes and the diffs look good. I have no > further comments. > > Cheers, > > - vijay -- https://jitsi.org From nobody Thu Jun 26 11:05:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810B21B308C for ; Thu, 26 Jun 2014 11:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuMddjpYEDCW for ; Thu, 26 Jun 2014 11:05:51 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A7D1B2C60 for ; Thu, 26 Jun 2014 10:50:54 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so1501685wiv.2 for ; Thu, 26 Jun 2014 10:50:51 -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 :cc:content-type; bh=za22Ni/H3Ozise12IEpo47cIRdHmLqkyJoH+JS5/db4=; b=uRPTD9rTRxo1OzptUcTSZzRXloGRCXXFJDgRe/t2ruknOCFm959h15xxoHN5gMS7Kx Tq8CPoQWIH5frMKSeG/U1af6Oh5tKxD+A1GXPmZEKxBpham/SMZ3PeSYuZilUpWo0HMq EGd5fO2hc9QlIC3afUq6gqYKBGwEg/A39hNzbzDL8Fv4v7IF7TmpvldZx2l99x1qUoDk qxGqummPax82a0LlXy5powi35jNZIjE38Q0dx7UDHM1ZMLm4ctN7qpfh9yrJ0UhEgIqs xxPpaMoEPIlY/2U3pgZ8CtbzO6/t4HbWn/tDCgzODPpcjbp1zA6cW2aPjVAdKJG/TKc0 wDFQ== MIME-Version: 1.0 X-Received: by 10.180.77.167 with SMTP id t7mr6023185wiw.77.1403805051548; Thu, 26 Jun 2014 10:50:51 -0700 (PDT) Received: by 10.194.71.97 with HTTP; Thu, 26 Jun 2014 10:50:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jun 2014 10:50:51 -0700 Message-ID: From: Suhas Nandakumar To: Bo Burman Content-Type: multipart/alternative; boundary=f46d043c08546e77ad04fcc0d5c8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/iAnlYsI44Pw8_09k6RBkXq7Ketg Cc: mmusic WG Subject: Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 18:05:55 -0000 --f46d043c08546e77ad04fcc0d5c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Many thanks Bo for the review. Please see comments inline Cheers Suhas On Thu, Jun 26, 2014 at 4:17 AM, Bo Burman wrote: > Suhas, all, please find comments inline below /Bo > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Suhas > Nandakumar > *Sent:* den 23 juni 2014 05:37 > *To:* mmusic WG > *Subject:* [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type > Analysis > > > > Hello All > > > > > > Continuing the discussions from London on analyzing multiplexing > behavior for SDP attributes that are defined per Payload Type, I was > thinking on making following changes to the > draft-ietf-mmusic-sdp-mux-attributes-01. > > > > 1. Add new category called IDENTICAL-PER-PT to the SDP Attribute analysis > framework in Section 4 which is defined as > > > > IDENTICAL-PER-PT: Attributes that define the RTP payload configuration on > per Payload Type basis and MUST have identical values across all the medi= a > descriptions for a given RTP Payload Type when repeated. > > *[BoB] I believe this requirement for consistency is good, straightforwar= d > and simple. Note that as a consequence, if any single one of the bundled > media descriptions has a payload-specific attribute listed as > IDENTICAL-PER-PT using =E2=80=98*=E2=80=99, that attribute has to be iden= tical for all PT > across all bundled media descriptions.* > > > [ Suhas ] Agreed. > *Apologies if you already discussed and settled this, but it does not > seem to be strictly technically necessary IF a receiver can relate a stre= am > to a certain media description, which is possible for example in the > presence of a=3Dssrc (AND IF that SSRC is unique across the SDP), or in t= he > presence of a=3DappId (which has to be unique across the SDP). We may how= ever > choose to ignore that fact in favor of keeping the rule simple.* > > > [Suhas] Totally make sense. If there are way to uniquely map the incoming RTP streams to a m=3Dline the implementation can use it. BUNDLE does specif= y this fact. > 2. Similarly add another category IDENTICAL-PER-SSRC to accommodate > source level SDP attributes. > > > > IDENTICAL-PER-SSRC: Attributes that correspond to the individual RTP > Packet Streams in a given RTP Session and MUST have identical values when > repeated across multiple media description for a given SSRC. > > *[BoB] This rule would only be used whenever the same SSRC value was > explicitly listed under multiple media descriptions, right? Since the med= ia > descriptions are bundled, those streams will be in the same RTP session a= nd > will effectively become part of one and the same stream, sharing the same > RTP timestamp and sequence number space. Is this really a useful case to > describe, or is it not rather something that should be avoided? What you > effectively describe is a single stream that has its configuration spread > out across multiple media descriptions.* > > > [Suhas ] Makes sense. We probably dont need a new one and we should assign the category NORMAL. Since if the SSRC is repeated it is describing the same source ( as you mentioned). > 3. For all the attributes that directly/indirectly impact codec > configuration and packetization of the media, I have attempted to assign = a > SDP MUX category and provide some insights on how such a decision was mad= e > (wherever applicable) > > > > *Attribute: a=3Dptime, a=3Dmaxptime* > > Mux Category: IDENTICAL-PER-PT > > Notes: For a given codec the audio packetization time must be same if the > PT is repeated. This will ensure that the RTP receiver > can unambiguously decode the incoming audio packets. > > *[BoB] Makes sense. Since those attributes are not payload specific, they > of course apply and puts restrictions on any PT present in that media > description.* > > > > > > *Attribute: a=3Dframerate* > > Mux Category: IDENTICAL-PER-PT > > *[BoB] Makes sense. As above, applies to all PT present in that media > description.* > > > > *Attribute: a=3Drtpmap* > > Mux Category: IDENTICAL-PER-PT > > *[BoB] Makes sense. * > > > > > > *Attribute: a=3Dfmtp* > > Mux Category: IDENTICAL-PER-PT > > Notes: > > *[BoB] Makes sense.* > > > > *Attribute: a=3Drtcp-fb* > > Mux Category: NORMAL > > Notes: Since the feedback messages are reported per SSRC, the category of > NORMAL suffices. > > *[BoB] I believe IDENTICAL-PER-PT is more appropriate, since per RFC 4585 > RTCP receivers =E2=80=98=E2=80=A6MUST NOT use other FB messages than thos= e listed in one of > the =E2=80=9Crtcp-fb=E2=80=9D attribute lines=E2=80=99, which I think wou= ld cause a conflict for > NORMAL.* > > > [Suhas] Good catch. I agree this should be IDENTICAL-PER-PT > *Attribute: a=3Ddepend (RFC5583)* > > Mux Category: IDENTICAL-PER-PT > > Notes: > > Since each dependency identifies a unique RTP packetization and thus MUS= T > be identified via unique Payload Type. > > Similarly if the Payload Type is repeated across media descriptions, they > MUST represent the Identical codec configuration. > > *[BoB] Makes sense* > > > > *Attribute: a=3Dssrc:xyz fmtp: ... * > > Mux Category: IDENTICAL-PER-PT > > Notes: > > RFC5576 says this : > > " > > Within a media stream, "ssrc" attributes with the same value of > > > > describe different attributes of the same media sources. > > Across media streams, values are not correlated (unless > > correlation is indicated by media-stream grouping or some other > > mechanism) and MAY be repeated. > > " > > > > Thus if the RTP Payload Type used to specify fmtp parameters is repeated= , it MUST represent the same codec configuration. > > example: > > > > m=3Dvideo ... > > a=3Drtpmap:98 VP8/90000 > > a=3Dssrc:12345 fmtp:98max-fr=3D15; max-fs-1200 > > > > > > m=3Dvideo ... > > a=3Drtpmap:98 VP8/90000 > > > > a=3Dssrc:56789 fmtp:98 max-fr=3D15; max-fs-1200 > > > > *[BoB] OK. Relates to my comment on IDENTICAL-PER-PT; the above proposal = prioritizes to keep the same definition and thus the rule simple.* > > > > > > *Attribute: a=3Dssrc:xyz cname: ....* > > Mux Category: IDENTICAL-PER-SSRC > > Notes: RFC5576 defines the identical requirement as it is. > > *[BoB] So, maybe not needed and thus NORMAL? As said above, I question th= e > usefulness of IDENTICAL-PER-SSRC category.* > > > > [Suhas] . Agreed > > *Attribute: a=3Dimageattr* > > Mux Category: IDENTICAL-PER-PT > > *[BoB] OK* > > > > > > *Attribute: a=3Dframesize* > > Mux Category: IDENTICAL-PER-PT > > *[BoB] OK* > > > > > > *Attributes: a=3Dfec-source-flow, a=3Dfec-repair-flow, a=3Drepair-window* > > Mux Category: NORMAL > > *[BoB] I wonder if this is sufficient, or if it has to be SPECIAL? It > seems to me you need a new ADU identification mechanism. When bundling > media descriptions, the ADU identification used by RFC 6363 and 6364 make= s > all ADU flows, source and repair alike, effectively become one and the sa= me > ADU flow. From section 3 of RFC 6363:* > > In this architecture, we assume that the interface to the transport > > layer supports the concepts of data units (referred to here as > > Application Data Units (ADUs)) to be transported and identification > > of ADU flows on which those data units are transported. > > > > [Suhas ] Thats true. Let me also think this through. Even if we define SPECIAL, I am not sure what is the expected behavior though .. > > > > I believe these cover all PT scoped SDP attributes. Please let me know > your thoughts and comments. > > > > Cheers > > Suhas Nandakumar > --f46d043c08546e77ad04fcc0d5c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Many thanks Bo for the review. Please see comments inline<= div>
Cheers
Suhas
<= br>
On Thu, Jun 26, 2014 at 4:17 AM, Bo Burma= n <bo.burman@ericsson.com> wrote:

Suhas, all, please find c= omments inline below /Bo

=C2=A0

From: mmusic [= mailto:mmusic-= bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: den 23 juni 2014 05:37
To: mmusic WG
Subject: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type= Analysis

=C2=A0

Hello All

=C2=A0

=C2=A0=C2=A0

=C2=A0 =C2=A0Continuing the discussions from London on a= nalyzing multiplexing behavior for SDP attributes that are defined per =C2= =A0Payload Type, I was thinking on making following changes to the draft-ie= tf-mmusic-sdp-mux-attributes-01.=C2=A0

=C2=A0

1. Add new category called IDENTICAL-PER-PT to the SDP A= ttribute analysis framework in Section 4 which is defined as<= u>

=C2=A0

IDENTICAL-PER-PT: Attributes that define the RTP payload= configuration on per Payload Type basis and MUST have identical values acr= oss=C2=A0all the media descriptions for a given RTP Payload Type when repeated.

[BoB] I belie= ve this requirement for consistency is good, straightforward and simple. No= te that as a consequence, if any single one of the bundled media descriptions has a payload-speci= fic attribute listed as IDENTICAL-PER-PT using =E2=80=98*=E2=80=99, that at= tribute has to be identical for all PT across all bundled media descriptions.

=C2=A0


[ Suhas ] Agreed.=C2=A0
=C2=A0

Apologies if you al= ready discussed and settled this, but it does not seem to be strictly techn= ically necessary IF a receiver can relate a stream to a certain media description, which is possible for example in the presence o= f a=3Dssrc (AND IF that SSRC is unique across the SDP), or in the presence = of a=3DappId (which has to be unique across the SDP). We may however choose= to ignore that fact in favor of keeping the rule simple.

=C2=A0

=C2=A0
[Suhas] Totally make sense. If there ar= e way to uniquely map the incoming RTP streams to a m=3Dline the implementa= tion can use it. BUNDLE does specify this fact.
=C2=A0

2. Similarly add another category IDENTICAL-PER-SSRC to = accommodate source level SDP attributes.

=C2=A0

IDENTICAL-PER-SSRC: Attributes that correspond to the in= dividual RTP Packet Streams in a given RTP Session and MUST have identical = values when repeated across multiple media description for a given SSRC.

[BoB] This ru= le would only be used whenever the same SSRC value was explicitly listed un= der multiple media descriptions, right? Since the media descriptions are bundled, those streams will be in the same RTP session and will effect= ively become part of one and the same stream, sharing the same RTP timestam= p and sequence number space. Is this really a useful case to describe, or i= s it not rather something that should be avoided? What you effectively describe is a single stream that has its = configuration spread out across multiple media descriptions.=

=C2=A0

[Suhas ] Makes sense. We probably dont need a new one an= d we should assign the category NORMAL. Since if the SSRC is repeated it is= describing the same source ( as you mentioned).=C2=A0
=C2=A0

3. For all the attributes that directly/indirectly impac= t codec configuration and packetization of the media, I have attempted to a= ssign a SDP MUX category and provide some insights on how such a decision was made (wherever applicable)

=C2=A0

Attribute: a=3Dptime, a=3Dmaxptime<= u>

Mux Category: IDENTICAL-PER-PT

Notes: For a given codec the audio packetization time mu= st be same if the PT is repeated. This will ensure that the RTP receiver ca= n=C2=A0unambiguously=C2=A0decode the incoming audio packets.<= /span>

[BoB] Makes s= ense. Since those attributes are not payload specific, they of course apply= and puts restrictions on any PT present in that media description.<= /i>

=C2=A0

=C2=A0

Attribute: a=3Dframerate<= /p>

Mux Category: IDENTICAL-PER-PT

[BoB] Makes sense. = As above, applies to all PT present in that media description.

=C2=A0

Attribute: a=3Drtpmap

Mux Category: IDENTICAL-PER-PT

[BoB] Makes sense.

=C2=A0

=C2=A0

Attribute: a=3Dfmtp

Mux Category: IDENTICAL-PER-PT

Notes:=C2=A0

[BoB] Makes sense.<= /span>

=C2=A0

Attribute: a=3Drtcp-fb

Mux Category: NORMAL

Notes: Since the feedback messages are reported per SSRC= , the category of NORMAL suffices.

[BoB] I belie= ve IDENTICAL-PER-PT is more appropriate, since per RFC 4585 RTCP receivers = =E2=80=98=E2=80=A6MUST NOT use other FB messages than those listed in one o= f the =E2=80=9Crtcp-fb=E2=80=9D attribute lines=E2=80=99, which I think would ca= use a conflict for NORMAL.=

=C2=A0

[Suhas] Good catch. I agree this should be IDEN= TICAL-PER-PT
=C2=A0

Attribute: a=3Ddepend (RFC5583)<= /span>

Mux Category: IDENTICAL-PER-PT

Notes:

Since each dependency identifies a unique RTP packetizat= ion =C2=A0and thus MUST be identified via unique Payload Type.=C2=A0=

Similarly if the Payload Type is repeated across media d= escriptions, they MUST represent the Identical codec configuration.=C2=A0

[BoB] Makes s= ense

=C2=A0

Attribute: a=3Dssrc:xyz =C2=A0fmtp:<fmt> ...=C2= =A0

Mux Category: IDENTICAL-PER-PT

Notes:

RFC5576 says this :

" =C2=A0

Within a media stream, "ssrc" attr= ibutes with the same value of

=C2=A0
<ssrc-id> describe different attributes=
 of the same media sources.
Across media streams, <ssrc-id> values =
are not correlated (unless
correlation is indicated by media-stream grou=
ping or some other
mechanism) and MAY be repeated.
"
=C2=A0
Thus if the RTP Payload Type used to specify =
fmtp parameters=C2=A0 is repeated, it MUST represent the same codec configu=
ration.
example:
=C2=A0
m=3Dvideo ...
a=3Drtpmap:98 VP8/90000
a=3Dssrc:12345 fmtp:98max-fr=3D15; max-fs-120=
0<=
/pre>


=C2=A0


=C2=A0


m=3Dvideo ...


a=3Drtpmap:98 VP8/90000


=C2=A0


a=3Dssrc:56789 fmtp:98 max-fr=3D15; max-fs-12=
00=




=C2=A0
[BoB] OK. Relates to my comment on ID=
ENTICAL-PER-PT; the above proposal prioritizes to keep the same definition =
and thus the rule simple.


=C2=A0

Attribute: a=3Dssrc:xyz =C2=A0cname: ....<= span style=3D"font-family:"Verdana","sans-serif"">

Mux Category: IDENTICAL-PER-SSRC

Notes: RFC5576 defines the identical requirement as it i= s.

[BoB] So, may= be not needed and thus NORMAL? As said above, I question the usefulness of = IDENTICAL-PER-SSRC category.

=C2=A0

[Suhas] . Agreed
=C2=A0

=C2=A0

Attribute: a=3Dimageattr<= /p>

Mux Category: IDENTICAL-PER-PT

[BoB] OK=

=C2=A0

=C2=A0

Attribute: a=3Dframesize<= /p>

Mux Category: IDENTICAL-PER-PT

[BoB] OK=

=C2=A0

=C2=A0

Attributes: a=3Dfec-sourc= e-flow, a=3Dfec-repair-flow, a=3Drepair-window<= /span>

Mux Category: NORMAL

[BoB] I wonder if t= his is sufficient, or if it has to be SPECIAL? It seems to me you need a ne= w ADU identification mechanism. When bundling media descriptions, the ADU identification used by RFC 6363 and 6364 makes all ADU flows, sour= ce and repair alike, effectively become one and the same ADU flow. From sec= tion 3 of RFC 6363:

=C2=A0=C2=A0 In t= his architecture, we assume that the interface to the transport

=C2=A0=C2=A0 laye= r supports the concepts of data units (referred to here as

=C2=A0=C2=A0 Appl= ication Data Units (ADUs)) to be transported and identification

=C2=A0=C2=A0 of A= DU flows on which those data units are transported.

=C2=A0

=
[Suhas ] =C2=A0Thats true. Let me also think this through= . Even if we define SPECIAL, I am not sure what is the expected behavior th= ough ..=C2=A0
=C2=A0

=C2=A0

=

<= /span>

=C2=A0

I believe these cover all PT scoped SDP attributes. Plea= se let me know your thoughts and comments.

=C2=A0

Cheers

Suhas Nandakumar


--f46d043c08546e77ad04fcc0d5c8-- From nobody Thu Jun 26 15:12:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AB61A050E for ; Thu, 26 Jun 2014 15:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONEOEPLh4fhZ for ; Thu, 26 Jun 2014 15:12:15 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7686B1B2EDD for ; Thu, 26 Jun 2014 15:12:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6B1667C3B4C for ; Fri, 27 Jun 2014 00:12:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIIrVuN-QTu7 for ; Fri, 27 Jun 2014 00:12:13 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:2969:536a:2d99:9231] (unknown [IPv6:2001:470:de0a:27:2969:536a:2d99:9231]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9CA9C7C3B44 for ; Fri, 27 Jun 2014 00:12:13 +0200 (CEST) Message-ID: <53AC9ABC.3030107@alvestrand.no> Date: Fri, 27 Jun 2014 00:12:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IYmOldJ_ckx7pkyfMAzTW8BUuOA Subject: [MMUSIC] Updated MSID draft - version -06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:12:19 -0000 Flemming kindly pointed out to me that I had not actively notified the list about my new version of the -msid draft that was published on June 6. Here's the changelog - the "detailed procedures" section has the "initial offer / initial answer" and so on format that was recommended by the chairs, so it may be of interest to this group. Harald C.12. Changes from -05 to -06 Addressed issues found in Fleming Andreassen's review Referenced JSEP rather than unified-plan for the M-line mapping model Relaxed MSID definition to allow "token-char" in values rather than a-z 0-9 hyphen; tightened ABNF by adding length description to it. Deleted discussion of abandoned alternatives, as part of preparing for publication. Added a "detailed procedures" section to the WMS semantics description. Added IANA registration of the "msid-semantic" attribute. From nobody Thu Jun 26 16:51:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEEB1B3015 for ; Thu, 26 Jun 2014 16:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGGv2ViUu1zh for ; Thu, 26 Jun 2014 16:51:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08891B2B37 for ; Thu, 26 Jun 2014 16:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1368; q=dns/txt; s=iport; t=1403826674; x=1405036274; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=l7V2nyCPGIT2tALkC+ZvqZwcZlaLAZ+a541SPL/szQo=; b=kdZGweGBDs+0+BAbH/PABT6v3JflvAZDk4mU8wF97WsSAOybEigZki/P uxctot/s6hWTOp+X7mCu9prIINdU4CTnjIf3anLIrRe12CFSxLY/OTqk8 TDT1v1Z6z8t3KZdJ6vhRY2/wouhx3hGNKYI5md506jypbDvASKJwIqTYr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMGALuwrFOtJA2B/2dsb2JhbABagw1SqwYBAQEBAQEFAW2RP4ZtUwGBChZ1hAMBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGAQwGAgEBiD4NwjQTBIVkiSOEQwEEmlmTdYNeIQ X-IronPort-AV: E=Sophos;i="5.01,556,1400025600"; d="scan'208";a="335989690" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2014 23:51:13 +0000 Received: from FANDREAS-M-201A.CISCO.COM (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5QNpChh029869; Thu, 26 Jun 2014 23:51:13 GMT Message-ID: <53ACB1F2.4030201@cisco.com> Date: Thu, 26 Jun 2014 19:51:14 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Harald Alvestrand , "mmusic@ietf.org" References: <53AC9ABC.3030107@alvestrand.no> In-Reply-To: <53AC9ABC.3030107@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RTHAdvjylmXuE8RBpz-ik279PQs Subject: Re: [MMUSIC] Updated MSID draft - version -06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:51:18 -0000 Thanks Harald It would be great if people could please take a look at the updated draft and see if they have any comments; we would like to get WGLC issued soon. Thanks -- Flemming (MMUSIC co-chair) On 6/26/14, 6:12 PM, Harald Alvestrand wrote: > Flemming kindly pointed out to me that I had not actively notified the > list about my new version of the -msid draft that was published on > June 6. > > Here's the changelog - the "detailed procedures" section has the > "initial offer / initial answer" and so on format that was recommended > by the chairs, so it may be of interest to this group. > > Harald > > C.12. Changes from -05 to -06 > > Addressed issues found in Fleming Andreassen's review > > Referenced JSEP rather than unified-plan for the M-line mapping model > > Relaxed MSID definition to allow "token-char" in values rather than > a-z 0-9 hyphen; tightened ABNF by adding length description to it. > > Deleted discussion of abandoned alternatives, as part of preparing > for publication. > > Added a "detailed procedures" section to the WMS semantics > description. > > Added IANA registration of the "msid-semantic" attribute. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Jun 27 00:57:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735551B2F2A for ; Fri, 27 Jun 2014 00:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6wGKNaD9TiD for ; Fri, 27 Jun 2014 00:56:56 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C0C1A02E3 for ; Fri, 27 Jun 2014 00:56:55 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so4774504wes.25 for ; Fri, 27 Jun 2014 00:56:54 -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 :cc:content-type; bh=3JoYbPw6tEdcgidjA6SyVrQoMoD63XvksKMrHMjy2lk=; b=BsQy4NkuDuwS7I+DDSdD9Qinvk+HA2gx0vXy6M7lqQxskmJI8bstELBVIhPuJiSAas nIUFVO0uILaXwvtKOefK3FJzYnEeK6SQY8+ZENIAexQBSMUx77IMMmbjuoWYFwgVxX8h UL7+2lvO32ZavJU7cqTBTeFpF/BjPkSs9IEq/fe7Sq5Y8tsnUntBVBPlwhaYeHeAkqDX dk0QptAkCvQPqYqPW8+4Pb1icr7VQK0riusehFtUVrzLONoyh/tr9yBVllBpHIxTFHZz /0QUGwMTdYckUrVGZOcTpzPJlxkkTYwmdpAHePPIDyle2CZHpsOk9fstgMhUP/ClqyhT u5kg== MIME-Version: 1.0 X-Received: by 10.181.13.5 with SMTP id eu5mr10022662wid.58.1403855814092; Fri, 27 Jun 2014 00:56:54 -0700 (PDT) Received: by 10.194.71.97 with HTTP; Fri, 27 Jun 2014 00:56:54 -0700 (PDT) In-Reply-To: <53ACB1F2.4030201@cisco.com> References: <53AC9ABC.3030107@alvestrand.no> <53ACB1F2.4030201@cisco.com> Date: Fri, 27 Jun 2014 00:56:54 -0700 Message-ID: From: Suhas Nandakumar To: Flemming Andreasen Content-Type: multipart/alternative; boundary=f46d043be04c1d6d8504fccca72d Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/39nPMTi3Vkuf6z8OnmEyftRLCIM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Updated MSID draft - version -06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 07:56:59 -0000 --f46d043be04c1d6d8504fccca72d Content-Type: text/plain; charset=UTF-8 Hello Harald Thanks for the work on this draft. Below are few thoughts inline * General Comment: + We might want to use RTP Taxonomy throughout + Replace MediaStream with "WebRTC MediaStream" for clarity + Replace MediaStreamTrack with "WebRTC MediaStreamTrack" clarity + m-line usage , can it be changed to m=line instead * Section 1.1 This document adds a new Session Description Protocol (SDP) Grouping [RFC5888] relation between SDP m-lines [RFC4566] that can associate application layer identifiers with the binding between media streams, attaching identifiers to the media streams and attaching identifiers to the groupings they form. [Suhas] I am assuming we are referring to RTP Stream here Section 1.2 SDP gives a description based on m-lines. According to the model used in [I-D.ietf-rtcweb-jsep] , each m-line describes exactly one media source, and if mulitple media sources are carried in an RTP session, this is signalled using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] ; if BUNDLE is not used, each media source is carried in its own RTP session. [Suhas] suggest updating the above para as " SDP gives a description based on m-lines. According to the model used in [I-D.ietf-rtcweb-jsep] , each m-line describes exactly one media source (WebRTC MediaStreamTrack), and if multiple media sources are carried in an RTP session, this is signaled using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] mechanism ; if BUNDLE is not used, each media source is carried in its own RTP session." Section 1.2 Para 4 [Suhas] Para 3 doesn't force the need for a new mechanism and it is probably a good idea to add more clarity in Para4 to clarify the need as below" "The SDP grouping framework [RFC5888] can be used to group m-lines. When an m-line describes one and only one RTP Packet stream, it is possible to associate RTP media streams across different m-lines. However, cases such as when a m-line has multiple RTP Packets streams or the need for an application to specify application-level information about the association between the m-line and the group, the SDP grouping framework cannot be used for this purpose" * Section 1.3 Para 3 WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep] ) where one SDP m-line is used to describe each MediaStreamTrack, and that the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group MediaStreamTracks into RTP sessions. [Suhas] we might want to say "MediaStreamTracks into a RTP Session" instead of "MediaStreamTracks into RTP Sessions" *Section 1.3 Para 3 Therefore, the need is to specify the ID of a MediaStreamTrack and its associated MediaStream for each m-line, which can be accomplished with a media-level SDP attribute. [Suhas] Can we change it to " Therefore, the need is to uniquely identify the MediaStreamTrack and its MediaStream for each m-line via a media-level SDP attribute. This would enable establishing the relationship between RTP Packet Streams that correspond to same WebRTC MediaStream across m= lines". " * Section 2 Title [Suhas] Msid is not defined. Also suggest common convention. (MSID vs Msid) throughout Section 3 The ABNF of msid-semantic is: attribute =/ msid-semantic-attr msid-semantic-attr = "msid-semantic:" semantic identifier-list semantic = token ; see RFC 4566 identifier-list = (" " identifier)* / " *" [Suhas] The identifier-list MUST be msid not generic identifier. Since this session level grouping applies only to msid or should it apply * Section 4 [Suhas] Shouldn't we make appData MUST for WMS semantics. Since having a MediaStream with no tracks into makes much sense. also the ABNF for appdata is optional in Section 2. * Section 4 [Suhas] When the m= section is updated to inactive, I am thinking we should signal the MedaStreamTrack as ended, is that a right assumption ? * Section 4 In addition to signaling that the track is closed when its msid attribute disappears from the SDP, the track will also be signaled as being closed when all associated SSRCs have disappeared by the rules of [Suhas] Probably a formatting glitch. The above sentence is incomplete * Section 4 The association between SSRCs and m-lines is specified in [I-D.ietf-rtcweb-jsep] . [Suhas] Why is this needed here ? * Section 4.1 Title [Suhas] Tracks undefined, suggest we change it to WebRTC MediaStreamTracks or something like that. * Section 4.1 Para 1 Non-WebRTC entities will not send msid [Suhas] Suggest changing will not to may not .. since msid itself is generic mechanism but WMS is webrtc specific mechanism * Section 4.1 It follows from the above that media stream tracks in the "default" media stream cannot be closed by removing the msid attribute; the application must instead signal these as closed when the SSRC disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 or by disabling the m-line by setting its port to zero. [ Suhas ] "default" media stream and tracks aren't defined and we need some context to explain this. * Section 4.2.1 How do we want to support adding a track that is not part of a Media Stream ? Should there be a msid line at all ? * Section 4.2.1 What should happen if the modified SDP has same msid but a different trackId in the appData. Should we trigger ended on the old track and created on the new track ? Is it worthwhile considering the possibility of sending the TrackId in the RTP Layer (as header extension) since it can identifies the Media Source end to end. *Section 4 - Offer/Answer Procedures We might want to add some text to explain the following - An Offer has WMS semantic include, Answerer doesn't include the semantic in response --> No WMS used for the session - Either Offer/Answer has a semantic which isn't understood by the end-points --> No MSID mechanism is used and m= lines are rejected Section 4.1 Says "If a WebRTC entity sends a description, it MUST include the msid-semantic:WMS attribute, even if no media streams are sent." and Section 3 says "This attribute MUST be present if "a=msid" is used." So if i add both, it is not clear in the cases of recvonly/inactive streams in the Offer, if we should include a=msid line If i wanted to include a empty WMS semantic. So basically what mandates which is not very clear here ? Section 4.2.2 - We need a line to parse the Semantics Please let me know If i can help with aligning the draft with Taxonomy and so on.. Thanks Suhas Nandakumar On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen wrote: > Thanks Harald > > It would be great if people could please take a look at the updated draft > and see if they have any comments; we would like to get WGLC issued soon. > > Thanks > > -- Flemming (MMUSIC co-chair) > > > > On 6/26/14, 6:12 PM, Harald Alvestrand wrote: > >> Flemming kindly pointed out to me that I had not actively notified the >> list about my new version of the -msid draft that was published on June 6. >> >> Here's the changelog - the "detailed procedures" section has the "initial >> offer / initial answer" and so on format that was recommended by the >> chairs, so it may be of interest to this group. >> >> Harald >> >> C.12. Changes from -05 to -06 >> >> Addressed issues found in Fleming Andreassen's review >> >> Referenced JSEP rather than unified-plan for the M-line mapping model >> >> Relaxed MSID definition to allow "token-char" in values rather than >> a-z 0-9 hyphen; tightened ABNF by adding length description to it. >> >> Deleted discussion of abandoned alternatives, as part of preparing >> for publication. >> >> Added a "detailed procedures" section to the WMS semantics >> description. >> >> Added IANA registration of the "msid-semantic" attribute. >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --f46d043be04c1d6d8504fccca72d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Harald

=C2=A0 Thanks for the work= on this draft. Below are few thoughts inline

* Ge= neral Comment:=C2=A0
=C2=A0 =C2=A0 =C2=A0+ We might want to use R= TP Taxonomy throughout
=C2=A0 =C2=A0 =C2=A0+ Replace MediaStream with "WebRTC MediaStrea= m" for clarity
=C2=A0 =C2=A0 =C2=A0+ Replace MediaStreamTrac= k with "WebRTC MediaStreamTrack" clarity
=C2=A0 =C2=A0 = =C2=A0+ m-line usage , can it be changed to m=3Dline instead
=C2=A0
=C2=A0

* Section 1.1
This document adds a new Session Description Protocol (SDP) G= rouping[RFC5888]=C2=A0rel= ation between SDP m-lines=C2=A0[RFC4566]=C2=A0that can associate application layer identifiers with = the binding between media streams, attaching identifiers to the media strea= ms and attaching identifiers to the groupings they form.

[Suhas] I am assuming we are referring= to RTP Stream here


Section 1.2
SDP gives a descrip= tion based on m-lines. According to the model used in=C2=A0[I-D.ietf-rtcweb-jsep], ea= ch m-line describes exactly one media source, and if mulitple media sources= are carried in an RTP session, this is signalled using BUNDLE=C2=A0= [I-D.ietf-mmusic-sdp-bund= le-negotiation]; if BUNDLE is not used, each media = source is carried in its own RTP session.
[Suhas] suggest updating the above para as

" SDP gives a description b= ased on m-lines. According to the model used in=C2=A0[I-D.ietf-rtcweb-jsep], each m-lin= e describes exactly one media source (WebRTC MediaStreamTrack), and if mult= iple media sources are carried in an RTP session, this is signaled using BU= NDLE=C2=A0[I-D.iet= f-mmusic-sdp-bundle-negotiation]=C2=A0mechanism=C2=A0
Section 1.2 Para 4
[Suhas] Para 3 doesn't force the need for a new mechanism and it is pr= obably a good idea to add more clarity in Para4 to clarify the need as belo= w"=C2=A0

"The SDP grouping framework= =C2=A0[RFC5888]=C2=A0can = be used to group m-lines. When an m-line describes one and only one RTP Pac= ket stream, it is possible to associate RTP media streams across different = m-lines. However, cases such as when a m-line has multiple RTP Packets stre= ams or=C2=A0the need for an application to speci= fy application-level information about the association between the m-line a= nd the group,=C2=A0the SDP grouping framework ca= nnot be used for this purpose"

* Section 1.3 Para 3
WebRTC defines a mapping (documented in=C2=A0= [I-D.ietf-rtcweb-jsep]) where one SDP m-line is used to describe each MediaStreamTrack, and th= at the BUNDLE mechanism=C2=A0[I-D.ietf-mmusic-sdp-bundle-negotiation]
[Suhas] we might want to say "Me= diaStreamTracks into a RTP Session" instead of "MediaStreamTracks into RTP Sessions"

*Section= 1.3 Para 3
Therefore, the need is to specify the ID of a Medi= aStreamTrack and its associated MediaStream for each m-line, which can be a= ccomplished with a media-level SDP attribute.
[Suhas] Can we change it to=C2=A0
=
"
=C2=A0Therefore, the need is to uniquely identify = the MediaStreamTrack and its MediaStream for each m-line via a media-level = SDP attribute. This would enable establishing the relationship between RTP = Packet Streams that correspond to same WebRTC MediaStream across m=3D lines= ".
"

* Section 2 Title
=C2=A0[Suhas] Msid is not defined. Also sug= gest common convention. (MSID vs Msid) throughout

Section 3

The ABNF of msid-semantic is:

  att=
ribute =3D/ msid-semantic-attr
  msid-semantic-attr =3D "msid-semantic:" semantic identifier-lis=
t
  semantic =3D token ; see RFC 4566
  identifier-list =3D (" " identifier)* / " *"
[Suhas] The identifier-list MUST be msid not generic ide= ntifier. Since this session level grouping applies only to msid or should i= t apply

* Section 4
[Suhas] Shouldn't we make appData MUST for WMS semantics. Since having= a MediaStream with no tracks into makes much sense. also the ABNF for appd= ata is optional in Section 2.

* Section 4
[Suhas] When the m=3D section i= s updated to inactive, I am thinking we should signal the MedaStreamTrack a= s ended, is that a right assumption ?


* Section 4
=C2=A0 =C2=A0In addition to signaling that the track is closed = when its msid attribute disappears from the SDP, the track will also be sig= naled as being closed when all associated SSRCs have disappeared by the rul= es of
[Suhas] Probably a formatting glitch. The above sentence is incomplete=

* Section 4
The ass= ociation between SSRCs and m-lines is specified in=C2=A0[I-D.ietf-rtcweb-jsep].<= br>
[Suhas] Why is this needed here ?
=

* Section 4.1 Title
= [Suhas] Tracks undefined, suggest we change it to WebRT= C MediaStreamTracks or something like that.

* Sectio= n 4.1 Para 1
Non-WebRTC entities will not send msid
[Suhas] Suggest changing will not to = may not .. since msid itself is generic mechanism but WMS is webrtc specifi= c mechanism

* Section 4.1
<= span style=3D"color:rgb(0,0,0);font-family:verdana,helvetica,arial,sans-ser= if;font-size:13px">It follows from the above that media stream tracks in th= e "default" media stream cannot be closed by removing the msid at= tribute; the application must instead signal these as closed when the SSRC = disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 or by= disabling the m-line by setting its port to zero.
[ Suhas ] "default" media s= tream and tracks aren't defined and we need some context to explain thi= s.

* Sectio= n 4.2.1
=C2=A0How do we want to support adding =C2=A0a track that is not part of a= Media Stream ? Should there be a msid line at all ?

* Section 4.2.1
=C2=A0What should happen if the = modified SDP has same msid but a different trackId in the appData. Should w= e trigger ended on the old track and created on the new track ?

Is it worthwhile considering the possibility of sending = the TrackId in the RTP Layer (as header extension) since it can identifies = the Media Source end to end.

*Section 4 - Offer/Answer Procedures
We mig= ht want to add some text to explain the following
=C2=A0- An Offer has WMS semantic include, Answerer doesn't include th= e semantic in response --> No WMS used for the session
= =C2= =A0- Either Offer/Answer has a semantic which isn't understood by the e= nd-points --> No MSID mechanism is used and m=3D lines are rejected=C2= =A0
=C2=A0
Section 4.1 Says
"If a WebRTC entity sends a description, it MUST include the msid-s= emantic:WMS attribute, even if no media streams are sent."
and Section 3 says
"This attr= ibute MUST be present if "a=3Dmsid" is used."

So if i = add both, it is not clear in the cases of recvonly/inactive streams in the = Offer, if we should include a=3Dmsid line If i wanted to include a empty WM= S semantic. So basically what mandates which is not very clear here ?

Section = 4.2.2
- We need a line to parse the Semantics

Please let me know If i can help with= aligning the draft with Taxonomy and so on..


Thanks
Suhas Nandak= umar

On Thu, Jun= 26, 2014 at 4:51 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
Thanks Harald

It would be great if people could please take a look at the updated draft a= nd see if they have any comments; we would like to get WGLC issued soon.
Thanks

-- Flemming (MMUSIC co-chair)



On 6/26/14, 6:12 PM, Harald Alvestrand wrote:
Flemming kindly pointed out to me that I had not actively notified the list= about my new version of the -msid draft that was published on June 6.

Here's the changelog - the "detailed procedures" section has = the "initial offer / initial answer" and so on format that was re= commended by the chairs, so it may be of interest to this group.

Harald

C.12. =C2=A0Changes from -05 to -06

=C2=A0 =C2=A0Addressed issues found in Fleming Andreassen's review

=C2=A0 =C2=A0Referenced JSEP rather than unified-plan for the M-line mappin= g model

=C2=A0 =C2=A0Relaxed MSID definition to allow "token-char" in val= ues rather than
=C2=A0 =C2=A0a-z 0-9 hyphen; tightened ABNF by adding length description to= it.

=C2=A0 =C2=A0Deleted discussion of abandoned alternatives, as part of prepa= ring
=C2=A0 =C2=A0for publication.

=C2=A0 =C2=A0Added a "detailed procedures" section to the WMS sem= antics
=C2=A0 =C2=A0description.

=C2=A0 =C2=A0Added IANA registration of the "msid-semantic" attri= bute.

_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

--f46d043be04c1d6d8504fccca72d-- From nobody Fri Jun 27 06:25:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE51B319B for ; Fri, 27 Jun 2014 06:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-FCqPnD9Mjn for ; Fri, 27 Jun 2014 06:25:26 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id F030B1B3194 for ; Fri, 27 Jun 2014 06:25:25 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id E498423F068E; Fri, 27 Jun 2014 15:25:24 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 27 Jun 2014 15:25:24 +0200 From: "Stach, Thomas" To: Emil Ivov Thread-Topic: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-trickle-ice-sip-02.txt Thread-Index: AQHPincqTKDCa7NKuk+ksabvqS+Aa5uE4yDg Date: Fri, 27 Jun 2014 13:25:23 +0000 Message-ID: References: <20140617215119.31326.31295.idtracker@ietfa.amsl.com> <53A0B9CB.3050909@jitsi.org> In-Reply-To: <53A0B9CB.3050909@jitsi.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/WtxUc44wI2ac9g2-x6CdwQ_S614 Cc: MMUSIC Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-trickle-ice-sip-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 13:25:29 -0000 Emil, this version improved quite a bit from the last one. Some comments/questions inline. > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: Dienstag, 17. Juni 2014 23:58 > To: MMUSIC > Subject: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-tri= ckle- > ice-sip-02.txt >=20 > Hey all, >=20 > We have just updated the trickle ICE for SIP specification [0] and > thought we'd send a quick summary of its most important characteristics. >=20 > 1. Using INFO messages. Candidates are trickled with INFO messages and a > trickle specific Info Package. This eliminates risk of glare during > trickling and it allows both sides to do it in parallel with no concern > for potential collisions. >=20 > 2. Candidates are sent incrementally. In addition to the newly > discovered candidates, every INFO message contains all local candidates > an agent has previously sent. This allows misordered/lost INFOs to not > be a problem. >=20 > 3. INFO requests carry a (currently underspecified) sdpfrag > content-type. Help is very welcome! >=20 > 4. sdpfrag bodies start with session level attributes and are then > followed by media level sections that are identified and delimited by > "a=3Dmid" lines. These media level sections exactly refer to the ones in > the corresponding offer or answer. [TS] You should update the reference from RFC3388 to RFC5588. The text doesn't mention the a=3Dgroup attribute.=20 I think it is OK to omit it, but some explicit text might be worthwhile. E.g. some like: This specification reuses the a=3Dmid: attribute from RFC55= 88,=20 but does not define any grouping semantics.=20 Consequently, using the a=3Dgroup: attribute as specified in RFC5588 is not= needed for Trickle-ICE. >=20 > 5. INFO requests must always carry the a=3Dice-ufrag and a=3Dice-pwd > attributes (as either session or media-level attributes) so that the > requests can be matched to a specific ICE generation (i.e., or an > offer/answer negotiation). [TS] So, the INFOs carry the complete information needed by the ICE agents. >=20 > 6. Trickle ICE for SIP does NOT require support for PRACK (although it > can use it if available). In cases where PRACK is not supported an > offerer must send a trickle INFO as soon as it gets a provisional > response. Such an INFO message can contain new candidates or just be > entirely the same as the previous one. (This is a change from the > previous non-incremental version where an "end-of-candidates" was > required for such cases). >=20 [TS] In Fig 2 you show the ICE agents as being separated from the Offer/Ans= wer Module.=20 I think this makes sense, since ICE's purpose of establishing connectivity = is independent from the other tasks of the Offer/Answer module.=20 Section 4.1 states the following two conditions needed to be fulfilled to s= tart trickling o ICE support in the peer agent MUST be confirmed. --> BTW: Shouldn't t= hat read Trickle-ICE? o The SIP dialog at both sides MUST be at least in the early state. The rest of section 4.1 additionally assumes that the answer is needed as w= ell. I think that you could start trickling even if the 183 did not contain an a= nswer, provided that the 183 indicated support for Trickle-ICE on SIP level= via Supported:trickle-ice and Recv-Info:trickle-ice. =20 The answer would just include a third indicator a=3Dice-options:trickle on = SDP-level. The INFOs would include all necessary information to start ICE and could al= so carry a=3Dice-options:trickle to verify trickle-ICE support also on SDP-= level. There might be some benefits for existing implementations if they could sta= rt trickling before they have sent an answer. Regards Thomas > 7. SIP User Agents may be configured to force use of full trickle where > maintainers expect all endpoints to support it. This would likely be the > case for WebRTC environments. >=20 > 8. Support for trickle ICE may also be dynamically discover with RFC > 3840 but *only if* GRUU is also supported (otherwise there is no way to > guarantee that the endpoint responding to caps query will be the same as > the one that will get a subsequent INVITE >=20 > 9. For those with an aversion to the above discovery hacks, trickle ICE > for SIP can also be used in half trickle mode where the offerer starts > with a regular ICE offer and, if the answerer can trickle, it just does. >=20 > Comments and questions are welcome! >=20 >=20 > Trickle ICE for SIP: > [0] html: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02 > [1] diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ivov-mmusic-trickle-ice-sip-02 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-ivov-mmusic-trickle-ice-sip-02.txt > Date: Tue, 17 Jun 2014 14:51:19 -0700 >=20 > A new version of I-D, draft-ivov-mmusic-trickle-ice-sip-02.txt > has been successfully submitted by Emil Ivov and posted to the > IETF repository. >=20 > Name: draft-ivov-mmusic-trickle-ice-sip > Revision: 02 > Title: A Session Initiation Protocol (SIP) usage for Trickle ICE > Document date: 2014-06-17 > Group: Individual Submission > Pages: 21 > URL: > http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-sip-02.= txt > Status: > https://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice-sip/ > Htmlized: > http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ivov-mmusic-trickle-ice-sip-02 >=20 > Abstract: > The Interactive Connectivity Establishment (ICE) protocol describes a > Network Address Translator (NAT) traversal mechanism for UDP-based > multimedia sessions established with the offer/answer model. The ICE > extension for Incremental Provisioning of Candidates (Trickle ICE) > defines a mechanism that allows ICE agents to shorten session > establishment delays by making the candidate gathering and > connectivity checking phases of ICE non-blocking and by executing > them in parallel. >=20 > This document defines usage semantics for Trickle ICE with the > Session Initiation Protocol (SIP). >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Jun 27 06:41:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92301B2F33 for ; Fri, 27 Jun 2014 01:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XYuS-40Useo for ; Fri, 27 Jun 2014 01:42:05 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCFF1B3129 for ; Fri, 27 Jun 2014 01:42:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4463A7C3AC4; Fri, 27 Jun 2014 10:42:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgNBVGtpZrXv; Fri, 27 Jun 2014 10:42:00 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:2969:536a:2d99:9231] (unknown [IPv6:2001:470:de0a:27:2969:536a:2d99:9231]) by mork.alvestrand.no (Postfix) with ESMTPSA id EE1397C3A92; Fri, 27 Jun 2014 10:41:59 +0200 (CEST) Message-ID: <53AD2E56.6090501@alvestrand.no> Date: Fri, 27 Jun 2014 10:41:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Suhas Nandakumar , Flemming Andreasen References: <53AC9ABC.3030107@alvestrand.no> <53ACB1F2.4030201@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040007070503060600080409" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/dUAaMnvRhTyjSxurgl3zVzQBkDc X-Mailman-Approved-At: Fri, 27 Jun 2014 06:41:00 -0700 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Updated MSID draft - version -06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:42:11 -0000 This is a multi-part message in MIME format. --------------040007070503060600080409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Just a quick reply to the general comments... On 06/27/2014 09:56 AM, Suhas Nandakumar wrote: > Hello Harald > > Thanks for the work on this draft. Below are few thoughts inline > > * General Comment: > + We might want to use RTP Taxonomy throughout Yes. When the concepts are the same, we should. (what's the timeline for the RTP taxonomy?) Can you help find terms that are not used identically with Taxonomy? > + Replace MediaStream with "WebRTC MediaStream" for clarity > + Replace MediaStreamTrack with "WebRTC MediaStreamTrack" clarity I would push back on that in any section where the section title or the same sentence includes "WebRTC". So far "MediaStreamTrack" is used in the intro (WebRTC in the same sentence), section 1.1 (ditto), section 1.3 (WebRTC in heading), section 4 (WebRTC in heading). So the only usage concerned would be in Appendix B. > + m-line usage , can it be changed to m=line instead I don't understand this comment - it is highly unusual to use the = sign to denote compound words. It is possible that most occurences should be replaced with "media section". Would that be more readable? > > * Section 1.1 > This document adds a new Session Description Protocol (SDP) > Grouping[RFC5888] > relation > between SDP m-lines [RFC4566] > that > can associate application layer identifiers with the binding between > media streams, attaching identifiers to the media streams and > attaching identifiers to the groupings they form. > > [Suhas] I am assuming we are referring to RTP Stream here Since "RTP Stream" is not a defined term in draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a packet stream, which RFC 3550 sometimes refers to as "media stream". > > > > Section 1.2 > SDP gives a description based on m-lines. According to the model used > in [I-D.ietf-rtcweb-jsep] > , > each m-line describes exactly one media source, and if mulitple media > sources are carried in an RTP session, this is signalled using BUNDLE > [I-D.ietf-mmusic-sdp-bundle-negotiation] > ; > if BUNDLE is not used, each media source is carried in its own RTP > session. > [Suhas] suggest updating the above para as > > " SDP gives a description based on m-lines. According to the model > used in [I-D.ietf-rtcweb-jsep] > , > each m-line describes exactly one media source (WebRTC > MediaStreamTrack), and if multiple media sources are carried in an RTP > session, this is signaled using BUNDLE > [I-D.ietf-mmusic-sdp-bundle-negotiation] > mechanism > ; if BUNDLE is not used, each media source is carried in its own RTP > session." Section 1.2 is not WebRTC specific, so should not use WebRTC terms. The model used in JSEP doesn't have an independent formulation, unfortunately, but the main thrust of the argument for adopting it is that this is the model used by a significant portion of existing applications, so adopting that model for JSEP enhances interoperability. "Media source" is a defined term in -taxonomy-. > > Section 1.2 Para 4 > [Suhas] Para 3 doesn't force the need for a new mechanism and it is > probably a good idea to add more clarity in Para4 to clarify the need > as below" > > "The SDP grouping framework [RFC5888] > can > be used to group m-lines. When an m-line describes one and only one > RTP Packet stream, it is possible to associate RTP media streams > across different m-lines. However, cases such as when a m-line has > multiple RTP Packets streams or the need for an application to specify > application-level information about the association between the m-line > and the group, the SDP grouping framework cannot be used for this purpose" This seems good. I'll adopt and/or adapt. > > * Section 1.3 Para 3 > WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep] > ) > where one SDP m-line is used to describe each MediaStreamTrack, and > that the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] > is > used to group MediaStreamTracks into RTP sessions. > [Suhas] we might want to say "MediaStreamTracks into a RTP Session" > instead of "MediaStreamTracks into RTP Sessions" No, because in the case of less than total Bundling, MediaStreamTracks will be grouped into multiple RTP sessions, not a single one. > > *Section 1.3 Para 3 > Therefore, the need is to specify the ID of a MediaStreamTrack and its > associated MediaStream for each m-line, which can be accomplished with > a media-level SDP attribute. > [Suhas] Can we change it to > " > Therefore, the need is to uniquely identify the MediaStreamTrack and > its MediaStream for each m-line via a media-level SDP attribute. This > would enable establishing the relationship between RTP Packet Streams > that correspond to same WebRTC MediaStream across m= lines". > " Modulo "would" -> "will" ("would" is the wishful-thinking tense of the word, which I like to avoid - can't remember the grammatical name of the construct at the moment). > > * Section 2 Title > [Suhas] Msid is not defined. Also suggest common convention. (MSID vs > Msid) throughout The section is the definition of MSID, I'm not sure how to define the term before defining it. I'd like to have the convention be "msid" (all lower case), but the RFC Editor likes capitals in section titles. I'll lowercase it and see if it survives. (I lowercased all occurences elsewhere in a previous pass) > > Section 3 > > The ABNF of msid-semantic is: > > attribute =/ msid-semantic-attr > msid-semantic-attr = "msid-semantic:" semantic identifier-list > semantic = token ; see RFC 4566 > identifier-list = (" " identifier)* / " *" > > [Suhas] The identifier-list MUST be msid not generic identifier. Since > this session level grouping applies only to msid or should it apply There is no "msid" ABNF construct. The "msid-attr" in section 2 is defined in terms of identifier. So I can't parse this request. > > * Section 4 > [Suhas] Shouldn't we make appData MUST for WMS semantics. Since having > a MediaStream with no tracks into makes much sense. also the ABNF for > appdata is optional in Section 2. It makes sense to say that it MUST be given. Will do. > > * Section 4 > [Suhas] When the m= section is updated to inactive, I am thinking we > should signal the MedaStreamTrack as ended, is that a right assumption ? No, because "inactive" can be resumed. "Ended" is a final state for a MediaStreamTrack. > > > * Section 4 > In addition to signaling that the track is closed when its msid > attribute disappears from the SDP, the track will also be signaled as > being closed when all associated SSRCs have disappeared by the rules of > [Suhas] Probably a formatting glitch. The above sentence is incomplete In my copy, it continues with "[RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), and when the corresponding media section is disabled by setting the port number to zero.". What does it say in your copy? > > * Section 4 > The association between SSRCs and m-lines is specified in > [I-D.ietf-rtcweb-jsep] > . > [Suhas] Why is this needed here ? It's not. Will remove. > > * Section 4.1 Title > [Suhas] Tracks undefined, suggest we change it to WebRTC > MediaStreamTracks or something like that. I think it would be correct to say "non-signalled packet streams". > > * Section 4.1 Para 1 > Non-WebRTC entities will not send msid > [Suhas] Suggest changing will not to may not .. since msid itself is > generic mechanism but WMS is webrtc specific mechanism I'll change to "will not send msid with the WMS semantic". This is a leftover from before msid-semantic was introduced. Good catch! > > * Section 4.1 > It follows from the above that media stream tracks in the "default" > media stream cannot be closed by removing the msid attribute; the > application must instead signal these as closed when the SSRC > disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 > or by disabling the m-line by setting its port to zero. > [ Suhas ] "default" media stream and tracks aren't defined and we need > some context to explain this. This should be "tracks constructed by the above rule when no msid-semantic:WMS is present". Good catch. > > * Section 4.2.1 > How do we want to support adding a track that is not part of a Media > Stream ? Should there be a msid line at all ? This is not supported. Should it be? > > * Section 4.2.1 > What should happen if the modified SDP has same msid but a different > trackId in the appData. Should we trigger ended on the old track and > created on the new track ? Yes. > > Is it worthwhile considering the possibility of sending the TrackId in > the RTP Layer (as header extension) since it can identifies the Media > Source end to end. This is being considered for BUNDLE (appid). I don't want to try to do the same thing here, for fear of having duelling specifications. > > *Section 4 - Offer/Answer Procedures > We might want to add some text to explain the following > - An Offer has WMS semantic include, Answerer doesn't include the > semantic in response --> No WMS used for the session > - Either Offer/Answer has a semantic which isn't understood by the > end-points --> No MSID mechanism is used and m= lines are rejected I don't see a reason for either of these things. Continuing to announce the data does no harm. I can add "MUST ignore a=msid lines where the identifier is listed in a msid-semantic: header that the implementation does not support". > Section 4.1 Says > "If a WebRTC entity sends a description, it MUST include the > msid-semantic:WMS attribute, even if no media streams are sent." > and Section 3 says > "This attribute MUST be present if "a=msid" is used." > > So if i add both, it is not clear in the cases of recvonly/inactive > streams in the Offer, if we should include a=msid line If i wanted to > include a empty WMS semantic. So basically what mandates which is not > very clear here ? 4.1 is about WebRTC implementations. These MUST send msid-semantic:WMS, whether or not they have any a=msid in the SDP. Non-WebRTC implementations that don't send a=msid don't have to send msid-semantic:. Non-WebRTC implementations that send a=msid MUST send msid-semantic: so that it's possible to figure out what they mean by their a=msid lines. Non-WebRTC implementations that use a different msid-semantic: must follow the rules for that semantic. I don't see what's not clear here, but would appreciate suggestions for more text to make it clearer. > > Section 4.2.2 > - We need a line to parse the Semantics Good catch. It needs to verify that the msid-semantic says WMS. (Since all of section 4.2 is about WMS, this is the only one we need to specify rules for. > > Please let me know If i can help with aligning the draft with Taxonomy > and so on.. Help appreciated! > > > Thanks > Suhas Nandakumar > > On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen > > wrote: > > Thanks Harald > > It would be great if people could please take a look at the > updated draft and see if they have any comments; we would like to > get WGLC issued soon. > > Thanks > > -- Flemming (MMUSIC co-chair) > > > > On 6/26/14, 6:12 PM, Harald Alvestrand wrote: > > Flemming kindly pointed out to me that I had not actively > notified the list about my new version of the -msid draft that > was published on June 6. > > Here's the changelog - the "detailed procedures" section has > the "initial offer / initial answer" and so on format that was > recommended by the chairs, so it may be of interest to this group. > > Harald > > C.12. Changes from -05 to -06 > > Addressed issues found in Fleming Andreassen's review > > Referenced JSEP rather than unified-plan for the M-line > mapping model > > Relaxed MSID definition to allow "token-char" in values > rather than > a-z 0-9 hyphen; tightened ABNF by adding length description > to it. > > Deleted discussion of abandoned alternatives, as part of > preparing > for publication. > > Added a "detailed procedures" section to the WMS semantics > description. > > Added IANA registration of the "msid-semantic" attribute. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --------------040007070503060600080409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Just a quick reply to the general comments...


On 06/27/2014 09:56 AM, Suhas Nandakumar wrote:
Hello Harald

  Thanks for the work on this draft. Below are few thoughts inline

* General Comment: 
     + We might want to use RTP Taxonomy throughout

Yes. When the concepts are the same, we should. (what's the timeline for the RTP taxonomy?)
Can you help find terms that are not used identically with Taxonomy?

     + Replace MediaStream with "WebRTC MediaStream" for clarity
     + Replace MediaStreamTrack with "WebRTC MediaStreamTrack" clarity

I would push back on that in any section where the section title or the same sentence includes "WebRTC".

So far "MediaStreamTrack" is used in the intro (WebRTC in the same sentence), section 1.1 (ditto), section 1.3 (WebRTC in heading), section 4 (WebRTC in heading).

So the only usage concerned would be in Appendix B.

     + m-line usage , can it be changed to m=line instead

I don't understand this comment - it is highly unusual to use the = sign to denote compound words.
It is possible that most occurences should be replaced with "media section". Would that be more readable?

 
 

* Section 1.1
This document adds a new Session Description Protocol (SDP) Grouping[RFC5888] relation between SDP m-lines [RFC4566] that can associate application layer identifiers with the binding between media streams, attaching identifiers to the media streams and attaching identifiers to the groupings they form.

[Suhas] I am assuming we are referring to RTP Stream here

Since "RTP Stream" is not a defined term in draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a packet stream, which RFC 3550 sometimes refers to as "media stream".


Section 1.2
SDP gives a description based on m-lines. According to the model used in [I-D.ietf-rtcweb-jsep], each m-line describes exactly one media source, and if mulitple media sources are carried in an RTP session, this is signalled using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each media source is carried in its own RTP session.
[Suhas] suggest updating the above para as

" SDP gives a description based on m-lines. According to the model used in [I-D.ietf-rtcweb-jsep], each m-line describes exactly one media source (WebRTC MediaStreamTrack), and if multiple media sources are carried in an RTP session, this is signaled using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] mechanism ; if BUNDLE is not used, each media source is carried in its own RTP session."

Section 1.2 is not WebRTC specific, so should not use WebRTC terms. The model used in JSEP doesn't have an independent formulation, unfortunately, but the main thrust of the argument for adopting it is that this is the model used by a significant portion of existing applications, so adopting that model for JSEP enhances interoperability.

"Media source" is a defined term in -taxonomy-.


Section 1.2 Para 4
[Suhas] Para 3 doesn't force the need for a new mechanism and it is probably a good idea to add more clarity in Para4 to clarify the need as below" 

"The SDP grouping framework [RFC5888] can be used to group m-lines. When an m-line describes one and only one RTP Packet stream, it is possible to associate RTP media streams across different m-lines. However, cases such as when a m-line has multiple RTP Packets streams or the need for an application to specify application-level information about the association between the m-line and the group, the SDP grouping framework cannot be used for this purpose"
This seems good. I'll adopt and/or adapt.


* Section 1.3 Para 3
WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where one SDP m-line is used to describe each MediaStreamTrack, and that the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group MediaStreamTracks into RTP sessions. 
[Suhas] we might want to say "MediaStreamTracks into a RTP Session" instead of "MediaStreamTracks into RTP Sessions"

No, because in the case of less than total Bundling, MediaStreamTracks will be grouped into multiple RTP sessions, not a single one.

*Section 1.3 Para 3
Therefore, the need is to specify the ID of a MediaStreamTrack and its associated MediaStream for each m-line, which can be accomplished with a media-level SDP attribute.
[Suhas] Can we change it to 
"
 Therefore, the need is to uniquely identify the MediaStreamTrack and its MediaStream for each m-line via a media-level SDP attribute. This would enable establishing the relationship between RTP Packet Streams that correspond to same WebRTC MediaStream across m= lines".
"

Modulo "would" -> "will" ("would" is the wishful-thinking tense of the word, which I like to avoid - can't remember the grammatical name of the construct at the moment).


* Section 2 Title
 [Suhas] Msid is not defined. Also suggest common convention. (MSID vs Msid) throughout

The section is the definition of MSID, I'm not sure how to define the term before defining it.

I'd like to have the convention be "msid" (all lower case), but the RFC Editor likes capitals in section titles. I'll lowercase it and see if it survives. (I lowercased all occurences elsewhere in a previous pass)

Section 3

The ABNF of msid-semantic is:

  attribute =/ msid-semantic-attr
  msid-semantic-attr = "msid-semantic:" semantic identifier-list
  semantic = token ; see RFC 4566
  identifier-list = (" " identifier)* / " *"
[Suhas] The identifier-list MUST be msid not generic identifier. Since this session level grouping applies only to msid or should it apply

There is no "msid" ABNF construct. The "msid-attr" in section 2 is defined in terms of identifier.
So I can't parse this request.


* Section 4
[Suhas] Shouldn't we make appData MUST for WMS semantics. Since having a MediaStream with no tracks into makes much sense. also the ABNF for appdata is optional in Section 2.

It makes sense to say that it MUST be given. Will do.


* Section 4
[Suhas] When the m= section is updated to inactive, I am thinking we should signal the MedaStreamTrack as ended, is that a right assumption ?

No, because "inactive" can be resumed.
"Ended" is a final state for a MediaStreamTrack.


* Section 4
   In addition to signaling that the track is closed when its msid attribute disappears from the SDP, the track will also be signaled as being closed when all associated SSRCs have disappeared by the rules of
[Suhas] Probably a formatting glitch. The above sentence is incomplete

In my copy, it continues with "[RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), and when the corresponding media section is disabled by setting the port number to zero.". What does it say in your copy?


* Section 4
The association between SSRCs and m-lines is specified in [I-D.ietf-rtcweb-jsep].
[Suhas] Why is this needed here ?

It's not. Will remove.


* Section 4.1 Title
[Suhas] Tracks undefined, suggest we change it to WebRTC MediaStreamTracks or something like that.

I think it would be correct to say "non-signalled packet streams".


* Section 4.1 Para 1
Non-WebRTC entities will not send msid
[Suhas] Suggest changing will not to may not .. since msid itself is generic mechanism but WMS is webrtc specific mechanism

I'll change to "will not send msid with the WMS semantic". This is a leftover from before msid-semantic was introduced. Good catch!



* Section 4.1
It follows from the above that media stream tracks in the "default" media stream cannot be closed by removing the msid attribute; the application must instead signal these as closed when the SSRC disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 or by disabling the m-line by setting its port to zero.
[ Suhas ] "default" media stream and tracks aren't defined and we need some context to explain this.

This should be "tracks constructed by the above rule when no msid-semantic:WMS is present".
Good catch.


* Section 4.2.1
 How do we want to support adding  a track that is not part of a Media Stream ? Should there be a msid line at all ?

This is not supported. Should it be?

* Section 4.2.1
 What should happen if the modified SDP has same msid but a different trackId in the appData. Should we trigger ended on the old track and created on the new track ?

Yes.

Is it worthwhile considering the possibility of sending the TrackId in the RTP Layer (as header extension) since it can identifies the Media Source end to end.

This is being considered for BUNDLE (appid). I don't want to try to do the same thing here, for fear of having duelling specifications.


*Section 4 - Offer/Answer Procedures
We might want to add some text to explain the following
 - An Offer has WMS semantic include, Answerer doesn't include the semantic in response --> No WMS used for the session
 - Either Offer/Answer has a semantic which isn't understood by the end-points --> No MSID mechanism is used and m= lines are rejected

I don't see a reason for either of these things. Continuing to announce the data does no harm.
I can add "MUST ignore a=msid lines where the identifier is listed in a msid-semantic: header that the implementation does not support".
 
Section 4.1 Says
"If a WebRTC entity sends a description, it MUST include the msid-semantic:WMS attribute, even if no media streams are sent."
and Section 3 says
"This attribute MUST be present if "a=msid" is used."

So if i add both, it is not clear in the cases of recvonly/inactive streams in the Offer, if we should include a=msid line If i wanted to include a empty WMS semantic. So basically what mandates which is not very clear here ?

4.1 is about WebRTC implementations. These MUST send msid-semantic:WMS, whether or not they have any a=msid in the SDP.

Non-WebRTC implementations that don't send a=msid don't have to send msid-semantic:.

Non-WebRTC implementations that send a=msid MUST send msid-semantic: so that it's possible to figure out what they mean by their a=msid lines.

Non-WebRTC implementations that use a different msid-semantic: must follow the rules for that semantic.

I don't see what's not clear here, but would appreciate suggestions for more text to make it clearer.


Section 4.2.2
- We need a line to parse the Semantics

Good catch. It needs to verify that the msid-semantic says WMS. (Since all of section 4.2 is about WMS, this is the only one we need to specify rules for.


Please let me know If i can help with aligning the draft with Taxonomy and so on..

Help appreciated!



Thanks
Suhas Nandakumar

On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
Thanks Harald

It would be great if people could please take a look at the updated draft and see if they have any comments; we would like to get WGLC issued soon.

Thanks

-- Flemming (MMUSIC co-chair)



On 6/26/14, 6:12 PM, Harald Alvestrand wrote:
Flemming kindly pointed out to me that I had not actively notified the list about my new version of the -msid draft that was published on June 6.

Here's the changelog - the "detailed procedures" section has the "initial offer / initial answer" and so on format that was recommended by the chairs, so it may be of interest to this group.

Harald

C.12.  Changes from -05 to -06

   Addressed issues found in Fleming Andreassen's review

   Referenced JSEP rather than unified-plan for the M-line mapping model

   Relaxed MSID definition to allow "token-char" in values rather than
   a-z 0-9 hyphen; tightened ABNF by adding length description to it.

   Deleted discussion of abandoned alternatives, as part of preparing
   for publication.

   Added a "detailed procedures" section to the WMS semantics
   description.

   Added IANA registration of the "msid-semantic" attribute.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--------------040007070503060600080409-- From nobody Fri Jun 27 06:46:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990BA1B2BD8 for ; Fri, 27 Jun 2014 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J2ecYlSvEbY for ; Fri, 27 Jun 2014 06:46:31 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA401B2C28 for ; Fri, 27 Jun 2014 06:46:30 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5RDkOP0007230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jun 2014 08:46:25 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5RDkNrJ020539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 15:46:23 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 27 Jun 2014 15:46:23 +0200 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , Suhas Nandakumar , Flemming Andreasen Thread-Topic: [MMUSIC] Updated MSID draft - version -06 Thread-Index: AQHPkg2RCXp5Ow0/L0GbCBaAgAc3YZuE97Ow Date: Fri, 27 Jun 2014 13:46:22 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1F7A84@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <53AC9ABC.3030107@alvestrand.no> <53ACB1F2.4030201@cisco.com> <53AD2E56.6090501@alvestrand.no> In-Reply-To: <53AD2E56.6090501@alvestrand.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/s-a1yBYO-riVxtvmU0G7dyCxYDg Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Updated MSID draft - version -06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 13:46:34 -0000 The timeline for the taxonomy draft is that it is essentially ready for WGL= C as soon as enough CLUE, RTCWEB and MMUSIC people have looked at it to say= it is consistent with the documentation in that WG. Is anyone reviewing (or indeed has reviewed it) from the MMUSIC perspective= , or in respect of specific documents in the MMUSIC working group. Keith=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Harald Alvestrand > Sent: 27 June 2014 09:42 > To: Suhas Nandakumar; Flemming Andreasen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Updated MSID draft - version -06 >=20 > Just a quick reply to the general comments... >=20 >=20 > On 06/27/2014 09:56 AM, Suhas Nandakumar wrote: >=20 >=20 > Hello Harald=20 >=20 > Thanks for the work on this draft. Below are few=20 > thoughts inline >=20 > * General Comment:=20 > + We might want to use RTP Taxonomy throughout >=20 >=20 > Yes. When the concepts are the same, we should. (what's the=20 > timeline for the RTP taxonomy?) Can you help find terms that=20 > are not used identically with Taxonomy? >=20 >=20 >=20 > + Replace MediaStream with "WebRTC MediaStream" for clarity > + Replace MediaStreamTrack with "WebRTC=20 > MediaStreamTrack" clarity >=20 >=20 > I would push back on that in any section where the section=20 > title or the same sentence includes "WebRTC". >=20 > So far "MediaStreamTrack" is used in the intro (WebRTC in the=20 > same sentence), section 1.1 (ditto), section 1.3 (WebRTC in=20 > heading), section 4 (WebRTC in heading). >=20 > So the only usage concerned would be in Appendix B. >=20 >=20 >=20 > + m-line usage , can it be changed to m=3Dline instead >=20 >=20 > I don't understand this comment - it is highly unusual to use=20 > the =3D sign to denote compound words. > It is possible that most occurences should be replaced with=20 > "media section". Would that be more readable? >=20 >=20 >=20 > =20 > =20 >=20 > * Section 1.1 > This document adds a new Session Description Protocol=20 > (SDP) Grouping[RFC5888]=20 > 88> relation between SDP m-lines [RFC4566]=20 > 66> that can associate application layer identifiers with=20 > the binding between media streams, attaching identifiers to=20 > the media streams and attaching identifiers to the groupings=20 > they form. > =09 > =09 > [Suhas] I am assuming we are referring to RTP Stream here >=20 >=20 > Since "RTP Stream" is not a defined term in=20 > draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a=20 > packet stream, which RFC 3550 sometimes refers to as "media stream". >=20 >=20 >=20 > =09 > =09 >=20 > Section 1.2 > SDP gives a description based on m-lines. According to=20 > the model used in [I-D.ietf-rtcweb-jsep]=20 > etf-rtcweb-jsep> , each m-line describes exactly one media=20 > source, and if mulitple media sources are carried in an RTP=20 > session, this is signalled using BUNDLE=20 > [I-D.ietf-mmusic-sdp-bundle-negotiation]=20 > etf-mmusic-sdp-bundle-negotiation> ; if BUNDLE is not used,=20 > each media source is carried in its own RTP session. > =09 > [Suhas] suggest updating the above para as > =09 > =09 > " SDP gives a description based on m-lines. According=20 > to the model used in [I-D.ietf-rtcweb-jsep]=20 > etf-rtcweb-jsep> , each m-line describes exactly one media=20 > source (WebRTC MediaStreamTrack), and if multiple media=20 > sources are carried in an RTP session, this is signaled using=20 > BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]=20 > etf-mmusic-sdp-bundle-negotiation> mechanism ; if BUNDLE is=20 > not used, each media source is carried in its own RTP session." > =09 >=20 >=20 > Section 1.2 is not WebRTC specific, so should not use WebRTC=20 > terms. The model used in JSEP doesn't have an independent=20 > formulation, unfortunately, but the main thrust of the=20 > argument for adopting it is that this is the model used by a=20 > significant portion of existing applications, so adopting=20 > that model for JSEP enhances interoperability. >=20 > "Media source" is a defined term in -taxonomy-. >=20 >=20 >=20 > =09 > =09 > Section 1.2 Para 4 > [Suhas] Para 3 doesn't force the need for a new=20 > mechanism and it is probably a good idea to add more clarity=20 > in Para4 to clarify the need as below"=20 > =09 > =09 > "The SDP grouping framework [RFC5888]=20 > 88> can be used to group m-lines. When an m-line describes=20 > one and only one RTP Packet stream, it is possible to=20 > associate RTP media streams across different m-lines.=20 > However, cases such as when a m-line has multiple RTP Packets=20 > streams or the need for an application to specify=20 > application-level information about the association between=20 > the m-line and the group, the SDP grouping framework cannot=20 > be used for this purpose" >=20 > This seems good. I'll adopt and/or adapt. >=20 >=20 >=20 >=20 > * Section 1.3 Para 3 > WebRTC defines a mapping (documented in=20 > [I-D.ietf-rtcweb-jsep]=20 > etf-rtcweb-jsep> ) where one SDP m-line is used to describe=20 > each MediaStreamTrack, and that the BUNDLE mechanism=20 > [I-D.ietf-mmusic-sdp-bundle-negotiation]=20 > etf-mmusic-sdp-bundle-negotiation> is used to group=20 > MediaStreamTracks into RTP sessions.=20 > =09 > [Suhas] we might want to say "MediaStreamTracks into a=20 > RTP Session" instead of "MediaStreamTracks into RTP Sessions" >=20 >=20 > No, because in the case of less than total Bundling,=20 > MediaStreamTracks will be grouped into multiple RTP sessions,=20 > not a single one. >=20 >=20 > =09 > =09 > *Section 1.3 Para 3 > Therefore, the need is to specify the ID of a=20 > MediaStreamTrack and its associated MediaStream for each=20 > m-line, which can be accomplished with a media-level SDP attribute. > [Suhas] Can we change it to=20 > =09 > " > Therefore, the need is to uniquely identify the=20 > MediaStreamTrack and its MediaStream for each m-line via a=20 > media-level SDP attribute. This would enable establishing the=20 > relationship between RTP Packet Streams that correspond to=20 > same WebRTC MediaStream across m=3D lines". > " >=20 >=20 > Modulo "would" -> "will" ("would" is the wishful-thinking=20 > tense of the word, which I like to avoid - can't remember the=20 > grammatical name of the construct at the moment). >=20 >=20 >=20 > =09 > =09 > * Section 2 Title > [Suhas] Msid is not defined. Also suggest common=20 > convention. (MSID vs Msid) throughout >=20 >=20 > The section is the definition of MSID, I'm not sure how to=20 > define the term before defining it. >=20 > I'd like to have the convention be "msid" (all lower case),=20 > but the RFC Editor likes capitals in section titles. I'll=20 > lowercase it and see if it survives. (I lowercased all=20 > occurences elsewhere in a previous pass) >=20 >=20 >=20 > =09 > =09 > Section 3 >=20 > The ABNF of msid-semantic is: >=20 > attribute =3D/ msid-semantic-attr > msid-semantic-attr =3D "msid-semantic:" semantic identifier-list > semantic =3D token ; see RFC 4566 > identifier-list =3D (" " identifier)* / " *" > =20 > [Suhas] The identifier-list MUST be msid not generic=20 > identifier. Since this session level grouping applies only to=20 > msid or should it apply >=20 >=20 > There is no "msid" ABNF construct. The "msid-attr" in section=20 > 2 is defined in terms of identifier. > So I can't parse this request. >=20 >=20 >=20 >=20 > * Section 4 > [Suhas] Shouldn't we make appData MUST for WMS=20 > semantics. Since having a MediaStream with no tracks into=20 > makes much sense. also the ABNF for appdata is optional in Section 2. >=20 >=20 > It makes sense to say that it MUST be given. Will do. >=20 >=20 >=20 > =09 > =09 > * Section 4 > [Suhas] When the m=3D section is updated to inactive, I=20 > am thinking we should signal the MedaStreamTrack as ended, is=20 > that a right assumption ? >=20 >=20 > No, because "inactive" can be resumed. > "Ended" is a final state for a MediaStreamTrack. >=20 >=20 >=20 > =09 > =09 >=20 > * Section 4 > In addition to signaling that the track is closed=20 > when its msid attribute disappears from the SDP, the track=20 > will also be signaled as being closed when all associated=20 > SSRCs have disappeared by the rules of > [Suhas] Probably a formatting glitch. The above=20 > sentence is incomplete >=20 >=20 > In my copy, it continues with "[RFC3550] section 6.3.4 (BYE=20 > packet received) and 6.3.5 (timeout), and when the=20 > corresponding media section is disabled by setting the port=20 > number to zero.". What does it say in your copy? >=20 >=20 >=20 >=20 > * Section 4 > The association between SSRCs and m-lines is specified=20 > in [I-D.ietf-rtcweb-jsep]=20 > etf-rtcweb-jsep> . > =09 > [Suhas] Why is this needed here ? > =09 >=20 >=20 > It's not. Will remove. >=20 >=20 >=20 > =09 > =09 > * Section 4.1 Title > [Suhas] Tracks undefined, suggest we change it to=20 > WebRTC MediaStreamTracks or something like that. >=20 >=20 > I think it would be correct to say "non-signalled packet streams". >=20 >=20 >=20 > =09 > =09 > * Section 4.1 Para 1 > Non-WebRTC entities will not send msid > =09 > [Suhas] Suggest changing will not to may not .. since=20 > msid itself is generic mechanism but WMS is webrtc specific mechanism >=20 >=20 > I'll change to "will not send msid with the WMS semantic".=20 > This is a leftover from before msid-semantic was introduced.=20 > Good catch! >=20 >=20 >=20 >=20 > =09 > =09 > * Section 4.1 > It follows from the above that media stream tracks in=20 > the "default" media stream cannot be closed by removing the=20 > msid attribute; the application must instead signal these as=20 > closed when the SSRC disappears according to the rules of RFC=20 > 3550 section 6.3.4 and 6.3.5 or by disabling the m-line by=20 > setting its port to zero. > =09 > [ Suhas ] "default" media stream and tracks aren't=20 > defined and we need some context to explain this. >=20 >=20 > This should be "tracks constructed by the above rule when no=20 > msid-semantic:WMS is present". > Good catch. >=20 >=20 >=20 > =09 > =09 > * Section 4.2.1 > How do we want to support adding a track that is not=20 > part of a Media Stream ? Should there be a msid line at all ? >=20 >=20 > This is not supported. Should it be? >=20 >=20 >=20 > =09 > =09 > * Section 4.2.1 > What should happen if the modified SDP has same msid=20 > but a different trackId in the appData. Should we trigger=20 > ended on the old track and created on the new track ? >=20 >=20 > Yes. >=20 >=20 >=20 > =09 > =09 > Is it worthwhile considering the possibility of sending=20 > the TrackId in the RTP Layer (as header extension) since it=20 > can identifies the Media Source end to end. >=20 >=20 > This is being considered for BUNDLE (appid). I don't want to=20 > try to do the same thing here, for fear of having duelling=20 > specifications. >=20 >=20 >=20 > =09 > =09 > *Section 4 - Offer/Answer Procedures > We might want to add some text to explain the following > - An Offer has WMS semantic include, Answerer doesn't=20 > include the semantic in response --> No WMS used for the session > - Either Offer/Answer has a semantic which isn't=20 > understood by the end-points --> No MSID mechanism is used=20 > and m=3D lines are rejected=20 > =09 >=20 >=20 > I don't see a reason for either of these things. Continuing=20 > to announce the data does no harm. > I can add "MUST ignore a=3Dmsid lines where the identifier is=20 > listed in a msid-semantic: header that the implementation=20 > does not support". >=20 >=20 >=20 > =20 > Section 4.1 Says > "If a WebRTC entity sends a description, it MUST=20 > include the msid-semantic:WMS attribute, even if no media=20 > streams are sent." > and Section 3 says > "This attribute MUST be present if "a=3Dmsid" is used." > =09 > =09 > So if i add both, it is not clear in the cases of=20 > recvonly/inactive streams in the Offer, if we should include=20 > a=3Dmsid line If i wanted to include a empty WMS semantic. So=20 > basically what mandates which is not very clear here ? >=20 >=20 > 4.1 is about WebRTC implementations. These MUST send=20 > msid-semantic:WMS, whether or not they have any a=3Dmsid in the SDP. >=20 > Non-WebRTC implementations that don't send a=3Dmsid don't have=20 > to send msid-semantic:. >=20 > Non-WebRTC implementations that send a=3Dmsid MUST send=20 > msid-semantic: so that it's possible to figure out what they=20 > mean by their a=3Dmsid lines. >=20 > Non-WebRTC implementations that use a different=20 > msid-semantic: must follow the rules for that semantic. >=20 > I don't see what's not clear here, but would appreciate=20 > suggestions for more text to make it clearer. >=20 >=20 >=20 > =09 > =09 > Section 4.2.2 > - We need a line to parse the Semantics >=20 >=20 > Good catch. It needs to verify that the msid-semantic says=20 > WMS. (Since all of section 4.2 is about WMS, this is the only=20 > one we need to specify rules for. >=20 >=20 >=20 > =09 > =09 > Please let me know If i can help with aligning the=20 > draft with Taxonomy and so on.. >=20 >=20 > Help appreciated! >=20 >=20 >=20 >=20 > =09 > =09 > Thanks > Suhas Nandakumar >=20 > On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen=20 > wrote: > =09 >=20 > Thanks Harald > =09 > It would be great if people could please take a=20 > look at the updated draft and see if they have any comments;=20 > we would like to get WGLC issued soon. > =09 > Thanks > =09 > -- Flemming (MMUSIC co-chair)=20 >=20 >=20 >=20 > On 6/26/14, 6:12 PM, Harald Alvestrand wrote: > =09 >=20 > Flemming kindly pointed out to me that=20 > I had not actively notified the list about my new version of=20 > the -msid draft that was published on June 6. > =09 > Here's the changelog - the "detailed=20 > procedures" section has the "initial offer / initial answer"=20 > and so on format that was recommended by the chairs, so it=20 > may be of interest to this group. > =09 > Harald > =09 > C.12. Changes from -05 to -06 > =09 > Addressed issues found in Fleming=20 > Andreassen's review > =09 > Referenced JSEP rather than=20 > unified-plan for the M-line mapping model > =09 > Relaxed MSID definition to allow=20 > "token-char" in values rather than > a-z 0-9 hyphen; tightened ABNF by=20 > adding length description to it. > =09 > Deleted discussion of abandoned=20 > alternatives, as part of preparing > for publication. > =09 > Added a "detailed procedures"=20 > section to the WMS semantics > description. > =09 > Added IANA registration of the=20 > "msid-semantic" attribute. > =09 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > =09 > =09 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > =09 >=20 >=20 >=20 > = From nobody Fri Jun 27 08:12:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047EA1B3230 for ; Fri, 27 Jun 2014 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.351 X-Spam-Level: X-Spam-Status: No, score=-13.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbAMWWxo1_Ig for ; Fri, 27 Jun 2014 08:12:15 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842541B2D2A for ; Fri, 27 Jun 2014 08:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42422; q=dns/txt; s=iport; t=1403881936; x=1405091536; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=0KQeVKXqNF2xd+rsLKnCaybXko5wSFE10guk+DjxgfE=; b=dqqVCM8fX4FZ9o8sp56qRaQnqsFp3zBZvUaAAGOxNYnL+yli60JOoVel 2UNg1FVjemtBy3D/969jyY48QpjNNKlmMp8Ej+kVTlByAgRCpe+duf37Y 5YeKOvNpKEJWyLTo1fEPgo20xaImwuOc7NGWXHKQug0Iy/40Abn++c3Vv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgFABeJrVOtJA2H/2dsb2JhbABagkZHUqsXAQEBAQEBBQFtAZFCAYZsUwGBCRZ1hAMBAQEDAQEBAWsKBgsLGAkWAQENCQMCAQIBFTAGAQwGAgEBiDYIDcNvEwSFZIhNW4RDBZpdk3uDXiE X-IronPort-AV: E=Sophos; i="5.01,560,1400025600"; d="scan'208,217"; a="56490646" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP; 27 Jun 2014 15:12:15 +0000 Received: from FANDREAS-M-201A.CISCO.COM (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5RFCDBk012733; Fri, 27 Jun 2014 15:12:13 GMT Message-ID: <53AD89CF.1080306@cisco.com> Date: Fri, 27 Jun 2014 11:12:15 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Suhas Nandakumar , mmusic WG References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090400000805090406060107" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/oJeAiB9hL5jvK11a3bIvcWdNJVg Subject: Re: [MMUSIC] ISSUE2: SDP Attribute Multiplexing - CapNeg Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:12:20 -0000 This is a multi-part message in MIME format. --------------090400000805090406060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/24/14, 11:20 AM, Suhas Nandakumar wrote: > Hello All > One of the action items from the IETF89 was to complete the analysis > for describing multiplexing behavior of CapNeg attributes. Based on > some offline discussions with Flemming back in London, I am planning > to propose following semantic changes to the upcoming version of SDP > Attributes Mux draft. { the english text usage might change in the > final version though } > > *CHANGE 1. Define a new category called INHERIT as below* > INHERIT*:* > Attributes that encapsulate other SDP attributes and their > multiplexing characteristics are INHERITED from the attributes they > encapsulate. Such attributes as of today, are defined in [RFC3407], > [RFC5939] and [RFC6781] as part of a generic framework for indicating > and negotiating transport, media and media format related capabilities > in the SDP. > Example : > m=video 3456 RTP/AVP 100 > a=rtpmap:100 VP8/90000 > a=fmtp:100 max-fr=30;max-fs=8040 > a=sqn: 0 > a=cdsc: 1 video RTP/AVP 100 > a=cpar: a=rtcp-mux > m=video 3456 RTP/AVP 101 > a=rtpmap:101 VP8/90000 > a=fmtp:100 max-fr=15;max-fs=1200 > a=cdsc: 2 video RTP/AVP 101 > a=cpar: a=rtcp-mux > > In the above example , the category IDENTICAL is inherited for the > cpar encapsulated rtcp-mux attribute > Looks good. > *CHANGE 2: Update Section 15 to reflect the discussions from IETF 89 * > *_Section 15. Multiplexing considerations for Encapsulating Attributes_* > This sections deals with recommendations for defining the multiplexing > characteristics of the SDP attributes that encapsulate other SDP > attributes. Such attributes as of today, for example, are defined in > [RFC3407], [RFC5939] and [RFC6781] as part of a generic framework for > indicating and negotiating transport, media and media format related > capabilities in the SDP. > The behavior of such attributes under multiplexing is in turn defined > by the multiplexing behavior of the attributes they encapsulate which > are made known once the negotiation process is completed. > > *RFC3407 Attribute Analysis* > sqn : NORMAL > cdsc: NORMAL > cpar: INHERIT > cpar encapsulates b= (bandwidth) or an a= attribute. For bandwidth > attribute encapsulation, the category SUM is inherited. For the case > of a= attribute, the category corresponding to the SDP attribute > being referenced is inherited. > cparmin: SPECIAL > cparmax: SPECIAL > Since these attributes defines minimum and maximum numerical values > associated with the attributed described in a=cpar, it is recommended > to consult the document defining the attribute. > Looks good. > *RFC5939 Attribute Analysis* > RFC5939 defines a general SDP Capability Negotiation framework. It > also specifies how to provide attributes and transport protocols as > capabilities and negotiate them using the framework. > The attribute a=pcfg encapsulates various capabilities related to > transport and media properties via the a=tcap and a=acap attributes > respectively, that the Offerer is capable of supporting. Thus the > attribute a=pcfg provides a list of potential configurations from the > Offerer. In response, the Answerer picks its supported transport > and/or media capabilities from the Offered list as part of a=acfg > attribute representing the actual configuration selected. > > Thus a complete Offer/Answer exchange needs to be completed for the > Offerer to ensure the right set of configuration parameters based on > the actual configuration selected by the Answerer. > > Within the context of multiplexing several media descriptions with > RFC5939 Capability negotiation attributes, following recommendations > should be considered: > 1. The negotiated transport capability attribute (a=tcap) MUST be > IDENTICAL across all the multiplexed m=lines. [ Refer to section XXXXX > in BUNDLE]. > 2. For attributes encapsulated via a=acap capability attribute, the > negotiation MUST ensure the multiplexing behavior of the same inherits > the attribute being encapsulated. > I think we need a bit more text and maybe an example for the second point as I'm not quite sure what it conveys (for example what does "same" mean). I also think we need some restrictions (or at least recommendations) on the Offerer to make sure he generates potential configurations between the multiplexed streams that can (easily) be negotiated to be consistent between those streams. For example, if we try to negotiate one or more attributes that must be IDENTICAL, then the offered potential configurations should be constructed in a way to make that possible. If we could furthermore come up with some rules for constructing those in a way that makes it easy to for the answerer to pick those compatible potential configurations betweem media streams, that would make it much easier to deal with in practice (one possible idea could be to require the configuration numbers to line up between the media descriptions as a way of easily finding something that is compatible between them) We should also say something about what to do with extensions (which may be difficult to do generically, in which case we can just state that and say to consult the extension, e.g. like RFC 6871 below). Section 5.28 also needs to be updated with new category information. > *RFC6871 Attribute Analysis* > RFC6871 extends capability negotiation framework described in RFC5939 > by defining media > capabilities that can be used to indicate and negotiate media types > and their associated format parameters. > > Building upon the analysis from the previous sections, following > recommendations should be considered for dealing with the attributes > defined in RFC6871 when multiplexing several SDP media descriptions > 1. On negotiation, the category IDENTICAL-PER-PT applies to the > attributes that define media capabilities (a=rmcap) and media format > capabilities ( a=mfcap), if same Payload Type is being used to define > these capabilities. To be clear, the requirement is really on the "pcfg" attribute, since it controls what gets negotiated (same comment applies to RFC 5939 above). Now that ends up placing some requirements on the capabilities (like "acap" above or "rmcap" here) that are used in those potential configurations, and we should make that clear(er). The reason it comes up more here is because payload types are defined by the "pcfg" attribute in RFC 6871, not the "rmcap" attribute. More text around how to construct these potential configurations and the attributes they leverage (similarly to RFC 5939) would be helpful. Btw, I'm not sure I've seen the definition of "IDENTICAL-PER-PT". > 2. The Media specific capability attribute (a=mscap) , the non RTP > media based capability attribute (a=omcap) MUST inherit the > multiplexing behavior of the attribute being encapsulated. mscap seems right. If "rmcap" needed some kind of payload type (or format type more likely) consistency, then "omcap" does too. More definition around which ones need to be identical is needed though (and it may be easier to drive this requirement though the potential configuration, but I'm not sure). > 3.The behavior for the latent configuration attribute (a=lcfg) follows > the reasoning defined for the a=acfg and a=pcfg attributes, since a > given latent configuration is provided as a recommendation and is not > applied to the on-going Offer/Answer exchange. > I don't think the "lcfg" attribute has any interaction with Bundle since it merely describes one or more potential future media streams. There is also the "sescap" attribute. Presumably you would want to make sure that any bundled media descriptions/configurations are also acceptable combinations of media streams/configurations as specified by "sescap" (it quickly becomes complicated otherwise, so we may want to add text to that effect). I don't think there is much more to this one. Also, section 5.29 needs to be updated with new category information. Thanks -- Flemming > Example 1: Below SDP example captures the following aspects. > - The Offerer offers audio and video streams with several different > RTP profiles (AVP, > SAVP, SAVPF) as potential configurations. > - corresponds to the SDP answer where the Answerer > accepts RTP/SAVPF as the default profile for both the media streams. > In this scenario both the media streams can be successfully multiplexed. > - , the Answerer accepts the profile RTP/SAVPF for > the audio stream and RTP/AVPF for the video stream. This scenario > results in the failure of the multiplexing as defined in the section > 7.2 of the BUNDLE specification [I-D.ietf-mmusic-sdp-bundle-negotiation]. > > v=0 > o=- 25678 753849 IN IP4 192.0.2.1 > s= > t=0 0 > c=IN IP4 192.0.2.1 > m=audio 3456 RTP/AVP 98 > a=tcap:1 RTP/SAVPF > a=rtpmap:98 OPUS/48000/2 > a=pcfg:1 t=1 > m=video 51372 RTP/AVP 101 > a=rtpmap:101 H264/90000 > a=tcap:2 RTP/SAVPF RTP/AVPF > a=pcfg:2 t=2|3 > > > v=0 > o=- 24351 621814 IN IP4 192.0.2.2 > s= > m=audio 3456 RTP/SAVPF 98 > a=rtpmap:98 OPUS/48000/2 > a=acfg:1 t=1 > > m=video 51372 RTP/SAVPF 101 > a=rtpmap:101 H264/90000 > a=acfg:2 t=2 > > > v=0 > o=- 24351 621814 IN IP4 192.0.2.2 > s= > m=audio 3456 RTP/SAVPF 98 > a=rtpmap:98 OPUS/48000/2 > a=acfg:1 t=1 > > m=video 51372 RTP/AVPF 101 > a=rtpmap:101 H264/90000 > a=acfg:2 t=3 > > Please let me know your thoughts > > Cheers > Suhas > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------090400000805090406060107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/24/14, 11:20 AM, Suhas Nandakumar wrote:
Hello All
 One of the action items from the IETF89 was to complete the analysis for describing multiplexing behavior of CapNeg attributes. Based on some offline discussions with Flemming back in London, I am planning to propose following semantic changes to the upcoming version of SDP Attributes Mux draft. { the english text usage might change in the final version though }

CHANGE 1. Define a new category called INHERIT as below
INHERIT:
Attributes that encapsulate other SDP attributes and their multiplexing characteristics are INHERITED from the attributes they encapsulate. Such attributes as of today, are defined in [RFC3407], [RFC5939] and [RFC6781] as part of a generic framework for indicating and negotiating transport, media and media format related capabilities in the SDP.
Example :
m=video 3456 RTP/AVP 100
a=rtpmap:100 VP8/90000
a=fmtp:100 max-fr=30;max-fs=8040
a=sqn: 0
a=cdsc: 1 video RTP/AVP 100
a=cpar: a=rtcp-mux
m=video 3456 RTP/AVP 101
a=rtpmap:101 VP8/90000
a=fmtp:100 max-fr=15;max-fs=1200
a=cdsc: 2 video RTP/AVP 101
a=cpar: a=rtcp-mux

In the above example , the category IDENTICAL is inherited for the cpar encapsulated rtcp-mux attribute

Looks good.


CHANGE 2: Update Section 15 to reflect the discussions from IETF 89 
Section 15. Multiplexing considerations for Encapsulating Attributes
This sections deals with recommendations for defining the multiplexing characteristics of the SDP attributes that encapsulate other SDP attributes. Such attributes as of today, for example, are defined in [RFC3407], [RFC5939] and [RFC6781] as part of a generic framework for indicating and negotiating transport, media and media format related capabilities in the SDP.
The behavior of such attributes under multiplexing is in turn defined by the multiplexing behavior of the attributes they encapsulate which are made known once the negotiation process is completed. 

RFC3407 Attribute Analysis
sqn :          NORMAL
cdsc:         NORMAL
cpar:          INHERIT 
cpar encapsulates b= (bandwidth) or an a= attribute. For bandwidth attribute encapsulation, the category SUM is inherited. For the case of  a= attribute, the category corresponding to the SDP attribute being referenced is inherited.
cparmin:     SPECIAL
cparmax:    SPECIAL
Since these attributes defines minimum and maximum numerical values associated with the attributed described in a=cpar, it is recommended to consult the document defining the attribute.

Looks good.
RFC5939 Attribute Analysis
RFC5939 defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework.
 
The attribute a=pcfg encapsulates various capabilities related to transport and media properties via the a=tcap and a=acap attributes respectively, that the Offerer is capable of supporting. Thus the attribute a=pcfg provides a list of potential configurations from the Offerer. In response, the Answerer picks its supported transport and/or media capabilities from the Offered list as part of a=acfg attribute representing the actual configuration selected.

Thus a complete Offer/Answer exchange needs to be completed for the Offerer to ensure the right set of configuration parameters based on the actual configuration selected by the Answerer.

Within the context of multiplexing several media descriptions with RFC5939 Capability negotiation attributes, following recommendations should be considered:
1. The negotiated transport capability attribute (a=tcap) MUST be IDENTICAL across all the multiplexed m=lines. [ Refer to section XXXXX in BUNDLE].
2. For attributes encapsulated via a=acap capability attribute, the negotiation MUST ensure the multiplexing behavior of the same inherits the attribute being encapsulated.

I think we need a bit more text and maybe an example for the second point as I'm not quite sure what it conveys (for example what does "same" mean). I also think we need some restrictions (or at least recommendations) on the Offerer to make sure he generates potential configurations between the multiplexed streams that can (easily) be negotiated to be consistent between those streams. For example, if we try to negotiate one or more attributes that must be IDENTICAL, then the offered potential configurations should be constructed in a way to make that possible. If we could furthermore come up with some rules for constructing those in a way that makes it easy to for the answerer to pick those compatible potential configurations betweem media streams, that would make it much easier to deal with in practice (one possible idea could be to require the configuration numbers to line up between the media descriptions as a way of easily finding something that is compatible between them)

We should also say something about what to do with extensions (which may be difficult to do generically, in which case we can just state that and say to consult the extension, e.g. like RFC 6871 below).

Section 5.28 also needs to be updated with new category information.

RFC6871 Attribute Analysis
RFC6871 extends capability negotiation framework described in RFC5939 by defining media
capabilities that can be used to indicate and negotiate media types and their associated format parameters.

Building upon the analysis from the previous sections, following recommendations should be considered for dealing with the attributes defined in RFC6871 when multiplexing several SDP media descriptions
1. On negotiation, the category IDENTICAL-PER-PT applies to the attributes that define  media capabilities (a=rmcap) and media format capabilities ( a=mfcap),  if same Payload Type is being used to define these capabilities.
To be clear, the requirement is really on the "pcfg" attribute, since it controls what gets negotiated (same comment applies to RFC 5939 above). Now that ends up placing some requirements on the capabilities (like "acap" above or "rmcap" here) that are used in those potential configurations, and we should make that clear(er). The reason it comes up more here is because payload types are defined by the "pcfg" attribute in RFC 6871, not the "rmcap" attribute. More text around how to construct these potential configurations and the attributes they leverage (similarly to RFC 5939) would be helpful.

Btw, I'm not sure I've seen the definition of "IDENTICAL-PER-PT".

2. The Media specific capability attribute (a=mscap) ,  the non RTP media based capability attribute (a=omcap) MUST inherit the multiplexing behavior of the attribute being encapsulated.
mscap seems right.

If "rmcap" needed some kind of payload type (or format type more likely) consistency, then "omcap" does too. More definition around which ones need to be identical is needed though (and it may be easier to drive this requirement though the potential configuration, but I'm not sure). 

3.The behavior for the latent configuration attribute (a=lcfg) follows the reasoning defined for the a=acfg and a=pcfg attributes, since a given latent configuration is provided as a recommendation and is not applied to the on-going Offer/Answer exchange.

I don't think the "lcfg" attribute has any interaction with Bundle since it merely describes one or more potential future media streams.

There is also the "sescap" attribute. Presumably you would want to make sure that any bundled media descriptions/configurations are also acceptable combinations of media streams/configurations as specified by "sescap" (it quickly becomes complicated otherwise, so we may want to add text to that effect). I don't think there is much more to this one.

Also, section 5.29 needs to be updated with new category information.

Thanks

-- Flemming
Example 1: Below SDP example captures the following aspects.
- The Offerer offers audio and video streams with several different RTP profiles (AVP,   
  SAVP, SAVPF) as potential configurations.
- <Valid Answer > corresponds to the SDP answer where the Answerer accepts RTP/SAVPF as the default profile for both the media streams. In this scenario both the media streams can be successfully multiplexed.
- <Invalid Answer> , the Answerer accepts the profile RTP/SAVPF for the audio stream and RTP/AVPF for the video stream. This scenario results in the failure of the multiplexing as defined in the section 7.2 of the BUNDLE specification [I-D.ietf-mmusic-sdp-bundle-negotiation].
<Offer-SDP>
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 3456 RTP/AVP 98
a=tcap:1 RTP/SAVPF
a=rtpmap:98 OPUS/48000/2
a=pcfg:1 t=1
m=video 51372 RTP/AVP 101
a=rtpmap:101 H264/90000
a=tcap:2 RTP/SAVPF RTP/AVPF
a=pcfg:2 t=2|3

<Valid Answer>
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
m=audio 3456 RTP/SAVPF 98
a=rtpmap:98 OPUS/48000/2
a=acfg:1 t=1

m=video 51372 RTP/SAVPF 101
a=rtpmap:101 H264/90000
a=acfg:2 t=2

<Invalid Answer>
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
m=audio 3456 RTP/SAVPF 98
a=rtpmap:98 OPUS/48000/2
a=acfg:1 t=1

m=video 51372 RTP/AVPF 101
a=rtpmap:101 H264/90000
a=acfg:2 t=3


Please let me know your thoughts

Cheers
Suhas


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------090400000805090406060107-- From nobody Fri Jun 27 08:18:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4381B3245 for ; Fri, 27 Jun 2014 08:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjxK1IfYqY8K for ; Fri, 27 Jun 2014 08:18:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C134F1B3244 for ; Fri, 27 Jun 2014 08:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15988; q=dns/txt; s=iport; t=1403882331; x=1405091931; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PHWt7XGYyOZ/YqLCyBRj63PeIkLPn982G9Gw0IElp/I=; b=X+EjFvGZxjwnclD7v3GRam9/F4qLLDT9EbdCvOpd20fKCogUNVyuxYzI /vDqS1HejEolk+6YJbmqehQeuQUiw0t8d2tVejmvAm03i94QhE6IvdxyW 6dzuSle8VgLjP1WLMBwfoz2N1IMa7LVf0EvKk+RGWZQdZoCkvhCMUBPPZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAPyKrVOtJA2N/2dsb2JhbABQBAaDDVKrFwEBAQEBAQUBbQGRQoZtUwGBCxZ1hAMBAQEEAQEBJBEvBwQGAQwEHAQBAQEJFggHCQMCAQIBFR8JCAYBDAEDAgIBAYg+DcNsF4VkiEUZPgUHBoQ9AQSaXYFGkjWDXiEEKwE X-IronPort-AV: E=Sophos;i="5.01,560,1400025600"; d="scan'208";a="335937862" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jun 2014 15:18:50 +0000 Received: from FANDREAS-M-201A.CISCO.COM (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5RFInPq020223; Fri, 27 Jun 2014 15:18:49 GMT Message-ID: <53AD8B5B.5040600@cisco.com> Date: Fri, 27 Jun 2014 11:18:51 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Harald Alvestrand , Suhas Nandakumar References: <53AC9ABC.3030107@alvestrand.no> <53ACB1F2.4030201@cisco.com> <53AD2E56.6090501@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1F7A84@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1F7A84@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5KpvOjKek9Xp-v_eSicqPZoSYgs Cc: "mmusic@ietf.org" Subject: [MMUSIC] RTP taxonomy draft review [Re: Updated MSID draft - version -06] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:18:55 -0000 [updated subject] Per Keith's question below, has anybody in the MMUSIC group reviewed the RTP taxonomy draft: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ If so, please let the group and chairs know. Thanks -- Flemming On 6/27/14, 9:46 AM, DRAGE, Keith (Keith) wrote: > The timeline for the taxonomy draft is that it is essentially ready for WGLC as soon as enough CLUE, RTCWEB and MMUSIC people have looked at it to say it is consistent with the documentation in that WG. > > Is anyone reviewing (or indeed has reviewed it) from the MMUSIC perspective, or in respect of specific documents in the MMUSIC working group. > > Keith > >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of >> Harald Alvestrand >> Sent: 27 June 2014 09:42 >> To: Suhas Nandakumar; Flemming Andreasen >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Updated MSID draft - version -06 >> >> Just a quick reply to the general comments... >> >> >> On 06/27/2014 09:56 AM, Suhas Nandakumar wrote: >> >> >> Hello Harald >> >> Thanks for the work on this draft. Below are few >> thoughts inline >> >> * General Comment: >> + We might want to use RTP Taxonomy throughout >> >> >> Yes. When the concepts are the same, we should. (what's the >> timeline for the RTP taxonomy?) Can you help find terms that >> are not used identically with Taxonomy? >> >> >> >> + Replace MediaStream with "WebRTC MediaStream" for clarity >> + Replace MediaStreamTrack with "WebRTC >> MediaStreamTrack" clarity >> >> >> I would push back on that in any section where the section >> title or the same sentence includes "WebRTC". >> >> So far "MediaStreamTrack" is used in the intro (WebRTC in the >> same sentence), section 1.1 (ditto), section 1.3 (WebRTC in >> heading), section 4 (WebRTC in heading). >> >> So the only usage concerned would be in Appendix B. >> >> >> >> + m-line usage , can it be changed to m=line instead >> >> >> I don't understand this comment - it is highly unusual to use >> the = sign to denote compound words. >> It is possible that most occurences should be replaced with >> "media section". Would that be more readable? >> >> >> >> >> >> >> * Section 1.1 >> This document adds a new Session Description Protocol >> (SDP) Grouping[RFC5888] >> > 88> relation between SDP m-lines [RFC4566] >> > 66> that can associate application layer identifiers with >> the binding between media streams, attaching identifiers to >> the media streams and attaching identifiers to the groupings >> they form. >> >> >> [Suhas] I am assuming we are referring to RTP Stream here >> >> >> Since "RTP Stream" is not a defined term in >> draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a >> packet stream, which RFC 3550 sometimes refers to as "media stream". >> >> >> >> >> >> >> Section 1.2 >> SDP gives a description based on m-lines. According to >> the model used in [I-D.ietf-rtcweb-jsep] >> > etf-rtcweb-jsep> , each m-line describes exactly one media >> source, and if mulitple media sources are carried in an RTP >> session, this is signalled using BUNDLE >> [I-D.ietf-mmusic-sdp-bundle-negotiation] >> > etf-mmusic-sdp-bundle-negotiation> ; if BUNDLE is not used, >> each media source is carried in its own RTP session. >> >> [Suhas] suggest updating the above para as >> >> >> " SDP gives a description based on m-lines. According >> to the model used in [I-D.ietf-rtcweb-jsep] >> > etf-rtcweb-jsep> , each m-line describes exactly one media >> source (WebRTC MediaStreamTrack), and if multiple media >> sources are carried in an RTP session, this is signaled using >> BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] >> > etf-mmusic-sdp-bundle-negotiation> mechanism ; if BUNDLE is >> not used, each media source is carried in its own RTP session." >> >> >> >> Section 1.2 is not WebRTC specific, so should not use WebRTC >> terms. The model used in JSEP doesn't have an independent >> formulation, unfortunately, but the main thrust of the >> argument for adopting it is that this is the model used by a >> significant portion of existing applications, so adopting >> that model for JSEP enhances interoperability. >> >> "Media source" is a defined term in -taxonomy-. >> >> >> >> >> >> Section 1.2 Para 4 >> [Suhas] Para 3 doesn't force the need for a new >> mechanism and it is probably a good idea to add more clarity >> in Para4 to clarify the need as below" >> >> >> "The SDP grouping framework [RFC5888] >> > 88> can be used to group m-lines. When an m-line describes >> one and only one RTP Packet stream, it is possible to >> associate RTP media streams across different m-lines. >> However, cases such as when a m-line has multiple RTP Packets >> streams or the need for an application to specify >> application-level information about the association between >> the m-line and the group, the SDP grouping framework cannot >> be used for this purpose" >> >> This seems good. I'll adopt and/or adapt. >> >> >> >> >> * Section 1.3 Para 3 >> WebRTC defines a mapping (documented in >> [I-D.ietf-rtcweb-jsep] >> > etf-rtcweb-jsep> ) where one SDP m-line is used to describe >> each MediaStreamTrack, and that the BUNDLE mechanism >> [I-D.ietf-mmusic-sdp-bundle-negotiation] >> > etf-mmusic-sdp-bundle-negotiation> is used to group >> MediaStreamTracks into RTP sessions. >> >> [Suhas] we might want to say "MediaStreamTracks into a >> RTP Session" instead of "MediaStreamTracks into RTP Sessions" >> >> >> No, because in the case of less than total Bundling, >> MediaStreamTracks will be grouped into multiple RTP sessions, >> not a single one. >> >> >> >> >> *Section 1.3 Para 3 >> Therefore, the need is to specify the ID of a >> MediaStreamTrack and its associated MediaStream for each >> m-line, which can be accomplished with a media-level SDP attribute. >> [Suhas] Can we change it to >> >> " >> Therefore, the need is to uniquely identify the >> MediaStreamTrack and its MediaStream for each m-line via a >> media-level SDP attribute. This would enable establishing the >> relationship between RTP Packet Streams that correspond to >> same WebRTC MediaStream across m= lines". >> " >> >> >> Modulo "would" -> "will" ("would" is the wishful-thinking >> tense of the word, which I like to avoid - can't remember the >> grammatical name of the construct at the moment). >> >> >> >> >> >> * Section 2 Title >> [Suhas] Msid is not defined. Also suggest common >> convention. (MSID vs Msid) throughout >> >> >> The section is the definition of MSID, I'm not sure how to >> define the term before defining it. >> >> I'd like to have the convention be "msid" (all lower case), >> but the RFC Editor likes capitals in section titles. I'll >> lowercase it and see if it survives. (I lowercased all >> occurences elsewhere in a previous pass) >> >> >> >> >> >> Section 3 >> >> The ABNF of msid-semantic is: >> >> attribute =/ msid-semantic-attr >> msid-semantic-attr = "msid-semantic:" semantic identifier-list >> semantic = token ; see RFC 4566 >> identifier-list = (" " identifier)* / " *" >> >> [Suhas] The identifier-list MUST be msid not generic >> identifier. Since this session level grouping applies only to >> msid or should it apply >> >> >> There is no "msid" ABNF construct. The "msid-attr" in section >> 2 is defined in terms of identifier. >> So I can't parse this request. >> >> >> >> >> * Section 4 >> [Suhas] Shouldn't we make appData MUST for WMS >> semantics. Since having a MediaStream with no tracks into >> makes much sense. also the ABNF for appdata is optional in Section 2. >> >> >> It makes sense to say that it MUST be given. Will do. >> >> >> >> >> >> * Section 4 >> [Suhas] When the m= section is updated to inactive, I >> am thinking we should signal the MedaStreamTrack as ended, is >> that a right assumption ? >> >> >> No, because "inactive" can be resumed. >> "Ended" is a final state for a MediaStreamTrack. >> >> >> >> >> >> >> * Section 4 >> In addition to signaling that the track is closed >> when its msid attribute disappears from the SDP, the track >> will also be signaled as being closed when all associated >> SSRCs have disappeared by the rules of >> [Suhas] Probably a formatting glitch. The above >> sentence is incomplete >> >> >> In my copy, it continues with "[RFC3550] section 6.3.4 (BYE >> packet received) and 6.3.5 (timeout), and when the >> corresponding media section is disabled by setting the port >> number to zero.". What does it say in your copy? >> >> >> >> >> * Section 4 >> The association between SSRCs and m-lines is specified >> in [I-D.ietf-rtcweb-jsep] >> > etf-rtcweb-jsep> . >> >> [Suhas] Why is this needed here ? >> >> >> >> It's not. Will remove. >> >> >> >> >> >> * Section 4.1 Title >> [Suhas] Tracks undefined, suggest we change it to >> WebRTC MediaStreamTracks or something like that. >> >> >> I think it would be correct to say "non-signalled packet streams". >> >> >> >> >> >> * Section 4.1 Para 1 >> Non-WebRTC entities will not send msid >> >> [Suhas] Suggest changing will not to may not .. since >> msid itself is generic mechanism but WMS is webrtc specific mechanism >> >> >> I'll change to "will not send msid with the WMS semantic". >> This is a leftover from before msid-semantic was introduced. >> Good catch! >> >> >> >> >> >> >> * Section 4.1 >> It follows from the above that media stream tracks in >> the "default" media stream cannot be closed by removing the >> msid attribute; the application must instead signal these as >> closed when the SSRC disappears according to the rules of RFC >> 3550 section 6.3.4 and 6.3.5 or by disabling the m-line by >> setting its port to zero. >> >> [ Suhas ] "default" media stream and tracks aren't >> defined and we need some context to explain this. >> >> >> This should be "tracks constructed by the above rule when no >> msid-semantic:WMS is present". >> Good catch. >> >> >> >> >> >> * Section 4.2.1 >> How do we want to support adding a track that is not >> part of a Media Stream ? Should there be a msid line at all ? >> >> >> This is not supported. Should it be? >> >> >> >> >> >> * Section 4.2.1 >> What should happen if the modified SDP has same msid >> but a different trackId in the appData. Should we trigger >> ended on the old track and created on the new track ? >> >> >> Yes. >> >> >> >> >> >> Is it worthwhile considering the possibility of sending >> the TrackId in the RTP Layer (as header extension) since it >> can identifies the Media Source end to end. >> >> >> This is being considered for BUNDLE (appid). I don't want to >> try to do the same thing here, for fear of having duelling >> specifications. >> >> >> >> >> >> *Section 4 - Offer/Answer Procedures >> We might want to add some text to explain the following >> - An Offer has WMS semantic include, Answerer doesn't >> include the semantic in response --> No WMS used for the session >> - Either Offer/Answer has a semantic which isn't >> understood by the end-points --> No MSID mechanism is used >> and m= lines are rejected >> >> >> >> I don't see a reason for either of these things. Continuing >> to announce the data does no harm. >> I can add "MUST ignore a=msid lines where the identifier is >> listed in a msid-semantic: header that the implementation >> does not support". >> >> >> >> >> Section 4.1 Says >> "If a WebRTC entity sends a description, it MUST >> include the msid-semantic:WMS attribute, even if no media >> streams are sent." >> and Section 3 says >> "This attribute MUST be present if "a=msid" is used." >> >> >> So if i add both, it is not clear in the cases of >> recvonly/inactive streams in the Offer, if we should include >> a=msid line If i wanted to include a empty WMS semantic. So >> basically what mandates which is not very clear here ? >> >> >> 4.1 is about WebRTC implementations. These MUST send >> msid-semantic:WMS, whether or not they have any a=msid in the SDP. >> >> Non-WebRTC implementations that don't send a=msid don't have >> to send msid-semantic:. >> >> Non-WebRTC implementations that send a=msid MUST send >> msid-semantic: so that it's possible to figure out what they >> mean by their a=msid lines. >> >> Non-WebRTC implementations that use a different >> msid-semantic: must follow the rules for that semantic. >> >> I don't see what's not clear here, but would appreciate >> suggestions for more text to make it clearer. >> >> >> >> >> >> Section 4.2.2 >> - We need a line to parse the Semantics >> >> >> Good catch. It needs to verify that the msid-semantic says >> WMS. (Since all of section 4.2 is about WMS, this is the only >> one we need to specify rules for. >> >> >> >> >> >> Please let me know If i can help with aligning the >> draft with Taxonomy and so on.. >> >> >> Help appreciated! >> >> >> >> >> >> >> Thanks >> Suhas Nandakumar >> >> On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen >> wrote: >> >> >> Thanks Harald >> >> It would be great if people could please take a >> look at the updated draft and see if they have any comments; >> we would like to get WGLC issued soon. >> >> Thanks >> >> -- Flemming (MMUSIC co-chair) >> >> >> >> On 6/26/14, 6:12 PM, Harald Alvestrand wrote: >> >> >> Flemming kindly pointed out to me that >> I had not actively notified the list about my new version of >> the -msid draft that was published on June 6. >> >> Here's the changelog - the "detailed >> procedures" section has the "initial offer / initial answer" >> and so on format that was recommended by the chairs, so it >> may be of interest to this group. >> >> Harald >> >> C.12. Changes from -05 to -06 >> >> Addressed issues found in Fleming >> Andreassen's review >> >> Referenced JSEP rather than >> unified-plan for the M-line mapping model >> >> Relaxed MSID definition to allow >> "token-char" in values rather than >> a-z 0-9 hyphen; tightened ABNF by >> adding length description to it. >> >> Deleted discussion of abandoned >> alternatives, as part of preparing >> for publication. >> >> Added a "detailed procedures" >> section to the WMS semantics >> description. >> >> Added IANA registration of the >> "msid-semantic" attribute. >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> . From nobody Fri Jun 27 10:02:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64011B2953 for ; Fri, 27 Jun 2014 10:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLpRqayDqWK4 for ; Fri, 27 Jun 2014 10:02:07 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5701B2964 for ; Fri, 27 Jun 2014 10:02:07 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id KV1v1o0011YDfWL5DV26jV; Fri, 27 Jun 2014 17:02:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id KV261o00l3ZTu2S3gV26PV; Fri, 27 Jun 2014 17:02:06 +0000 Message-ID: <53ADA38E.1040009@alum.mit.edu> Date: Fri, 27 Jun 2014 13:02:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <53AC9ABC.3030107@alvestrand.no> In-Reply-To: <53AC9ABC.3030107@alvestrand.no> 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=q20140121; t=1403888526; bh=DwTY8HWlLdA5uLOShELRdH1D/+XnzFsySlWiCtQzmU0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LYwUjwLEYLgDCdu+myzHfX6pShz/VhqNG1jdoffI5Jzm7hqhgB/bVDnpMliorKqoz afwl3HvBOtzxBGgHWg2KrglO04VxAbn4OJgXTWexi/4kbHZaORoJo+RfNhZCeieuN4 p+68m+W/Ws28xug/s5fUac/rmEmaHKstBl1LMEz1nQek3rYWjgsMsmTFayyCiYJotS MjSdqztfTNs+Zj4UpJKXM7XEoDe+2Oe4TWVgzWd+daIs09x48bSu/8ElcmGUoMXKAf kDrrWrwD/QAyf4KPjnfld9OQ+q38vWy4DWB9ae3S0mvKEw4A2xKAwGwCj1+nIYnTER 0h+QOIpTlV8/Q== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lt5jmPIZjzpm2-EFi3_z_xImUpM Subject: Re: [MMUSIC] Updated MSID draft - version -06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 17:02:09 -0000 The following are my comments on the -06 version: Sections 2 & 2 (ABNF): There is an error in the ABNF: identifier-list = (" " identifier)* / " *" should be identifier-list = *(" " identifier) / " *" Also, to formally check ABNF that extends 4566 it is necessary to merge the ABNFs. To facilitate this it would be good to ensure that all the new ABNF names introduced are unique across 4566. And since some implementers may need to merge many extensions, it would good to avoid defining new names that are overly generic and prone to collision. In particular, I suggest the following renamings would improve things: identifier -> msid appdata -> msid-data semantic -> msid-semantic identifier-list -> msid-list Note: I'm not saying that these currently cause any conflicts. I don't think they do with 4566 itself, and I have no idea if they conflict with other extensions to 4566. I'm suggesting this as a matter of prudence and readability. Section 3 says: This attribute MUST be present if "a=msid" is used. This is true, but stronger constraints ought to be applied: Every identifier mentioned in an msid-semantic line MUST also appear in at least one a=msid line. The identifier in every a=msid line MUST be mentioned in *at least* (or perhaps *exactly*) one a=msid-semantic line. Section 4.1: The section refers to "WebRTC entity", but AFAIK there is no definition of this. I presume you don't mean to restrict this to browsers. IIUC you probably mean any entity that supports msid-semantic:WMS. Could you clarify the text? Section 4.2: This section should probably be called "Detailed Offer/Answer procedures". The following: These procedures ... They are specifically applicable to the WMS semantic; other semantics will have their own consideration. Is this really true? ISTM that there are some basic O/A procedures that apply to all msid-semantics. Specifically, - If a particular msid-semantic is mentioned in an offer, and it is supported by the answerer, then a corresponding msid-semantic MUST be mentioned in the answer. (The absence indicates that it is not supported.) So I think there is need of a "generic" set of O/A procedures. And then there can be additional O/A procedures specific to WMS. The existing sections 4.2.1 - 4.2.5 are just the WMS-specific ones. Section 4.2.1: This section should say something about msid-semantic. Some of the text from section 4.1 might do the job: If a WebRTC entity sends a description, it MUST include the msid- semantic:WMS attribute, even if no media streams are sent. That covers everything I noticed. Thanks, Paul From nobody Sat Jun 28 00:26:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9841A01A6 for ; Sat, 28 Jun 2014 00:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s964bH-ap7dL for ; Sat, 28 Jun 2014 00:26:22 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC9D1A007C for ; Sat, 28 Jun 2014 00:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BAA987C3929 for ; Sat, 28 Jun 2014 09:26:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiNgib3SiKQc for ; Sat, 28 Jun 2014 09:26:18 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id AB2B17C3863 for ; Sat, 28 Jun 2014 09:26:18 +0200 (CEST) Message-ID: <53AE6E1A.3030204@alvestrand.no> Date: Sat, 28 Jun 2014 09:26:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <53AC9ABC.3030107@alvestrand.no> <53ADA38E.1040009@alum.mit.edu> In-Reply-To: <53ADA38E.1040009@alum.mit.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lNdoWi3V_IPxVGYa4hXg0snjhjs Subject: Re: [MMUSIC] Updated MSID draft - version -06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 07:26:27 -0000 On 06/27/2014 07:02 PM, Paul Kyzivat wrote: > The following are my comments on the -06 version: > > Sections 2 & 2 (ABNF): > > There is an error in the ABNF: > > identifier-list = (" " identifier)* / " *" > > should be > > identifier-list = *(" " identifier) / " *" > > Also, to formally check ABNF that extends 4566 it is necessary to > merge the ABNFs. To facilitate this it would be good to ensure that > all the new ABNF names introduced are unique across 4566. And since > some implementers may need to merge many extensions, it would good to > avoid defining new names that are overly generic and prone to > collision. In particular, I suggest the following renamings would > improve things: > > identifier -> msid > appdata -> msid-data > semantic -> msid-semantic > identifier-list -> msid-list > > Note: I'm not saying that these currently cause any conflicts. I don't > think they do with 4566 itself, and I have no idea if they conflict > with other extensions to 4566. I'm suggesting this as a matter of > prudence and readability. I think this actually reduces readability, but that's a matter of taste. One of our failiures with ABNF is that we never implemented a modularization facility with official syntax for "identifier = ". > > Section 3 says: > > This attribute MUST be present if "a=msid" is used. > > This is true, but stronger constraints ought to be applied: > > Every identifier mentioned in an msid-semantic line MUST also > appear in at least one a=msid line. > > The identifier in every a=msid line MUST be mentioned in > *at least* (or perhaps *exactly*) one a=msid-semantic line. Not a bad idea. The wildcard identifier (*) counts as > Section 4.1: > > The section refers to "WebRTC entity", but AFAIK there is no > definition of this. I presume you don't mean to restrict this to > browsers. IIUC you probably mean any entity that supports > msid-semantic:WMS. Could you clarify the text? With the split in -overview recently into "WebRTC browsers" and "WebRTC devices", this is actually limited to WebRTC browsers, since the SDP in question only appears on the Javscript API, and implementing the Javascript API is only a requirement for browsers.... > > Section 4.2: > > This section should probably be called "Detailed Offer/Answer > procedures". > > The following: > > These procedures ... > > They are specifically applicable to the WMS semantic; other semantics > will have their own consideration. > > Is this really true? ISTM that there are some basic O/A procedures > that apply to all msid-semantics. Specifically, > > - If a particular msid-semantic is mentioned in an offer, and it is > supported by the answerer, then a corresponding msid-semantic > MUST be mentioned in the answer. (The absence indicates that it > is not supported.) > > So I think there is need of a "generic" set of O/A procedures. And > then there can be additional O/A procedures specific to WMS. The > existing sections 4.2.1 - 4.2.5 are just the WMS-specific ones. My problem is that I don't want to write the generic ones, because I don't have any idea what they should say. This is a generic problem with the generic mechanism - we can't define rules for what doesn't exist yet, and it's not possible to see what parts of the rules are true for any use of msid and what parts of the rules are true for WMS only before we start seeing a second usage. At the moment we have zero value to the generic mechanism, because we have zero potential usages of it. Writing something that has zero value does not appeal greatly to me. I suggested earlier that we might instead rip out the whole generalized mechanism and go back to msid being WMS only. I got no responses on that suggestion (neither positive or negative - it was ignored). This suggestion of another set of for-now-useless sections in the document makes me reiterate that proposal. Can you comment on it? > > Section 4.2.1: > > This section should say something about msid-semantic. Some of the > text from section 4.1 might do the job: > > If a WebRTC entity sends a description, it MUST include the msid- > semantic:WMS attribute, even if no media streams are sent. Yes. > > That covers everything I noticed. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Surveillance is pervasive. Go Dark. From nobody Sat Jun 28 10:17:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4DE1A037C for ; Sat, 28 Jun 2014 10:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znndrFs-4_Y1 for ; Sat, 28 Jun 2014 10:17:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625591A037A for ; Sat, 28 Jun 2014 10:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4217; q=dns/txt; s=iport; t=1403975860; x=1405185460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pg+i6f6UvDcGj42vqhC9g0A49qnbweq590Xx1R0FGDE=; b=NcbqRZFRnBJPC+/Ze4tLTquzHGQrFG16t9bH9Mwe5JDlOFzNxQ90OaDC vhAwrenXoN6DvoemB95WDLRHcUVvSuBorGvVeqQJtQ935VIWWmDk7VKOp uJOjcJADzGUFMkOD4pQP2Vl3kiuJSCUDatas1PCNsZa9zK1L4O9iVA/KT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAF/4rlOtJV2Z/2dsb2JhbABQCoJpJFJaxH4BgQkWdYQDAQEBBDo/EAIBCBgeEDIlAgQOBYhCAQzFXheMToFVBgsBHTMHgy2BFgWaXYFGkjWCAIFCbIELOQ X-IronPort-AV: E=Sophos;i="5.01,567,1400025600"; d="scan'208";a="336304278" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2014 17:17:38 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5SHHbbu011642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Jun 2014 17:17:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sat, 28 Jun 2014 12:17:36 -0500 From: "Ali C. Begen (abegen)" To: Marc Petit-Huguenin Thread-Topic: SDP attribute level for disaggregated media [was Re: [MMUSIC] 4566bis outstanding issues] Thread-Index: AQHPiN5l1fZcJTn7tkK7wRFVZA33PZuHK8YA Date: Sat, 28 Jun 2014 17:17:35 +0000 Message-ID: <589E38A9-CF4F-492E-9E32-B51E2A037E56@cisco.com> References: <539E0BEE.4010004@acm.org> In-Reply-To: <539E0BEE.4010004@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SimGkLIyTtBdu2xyOSnuFI0RKlU Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP attribute level for disaggregated media [was Re: 4566bis outstanding issues] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 17:17:42 -0000 I have not seen any objections to this change request? So, I will include M= arc's text in the next revision. -acbegen On Jun 16, 2014, at 12:11 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 06/06/2014 03:19 PM, Ali C. Begen (abegen) wrote: >> Hi everyone >>=20 >=20 > [...] >=20 >>=20 >>=20 >> These are the issues I was able to identify. There is one more thing >> related to ICE and I sent an email about this to Marc Petit-Huguenin. As >> soon as he responds and depending on his answer, I might add one more >> issue. >>=20 >=20 > Let me first explain the problem as I perceive it: >=20 > The SDP was designed so that different endpoints can be part of an RTP > session, i.e. each m=3D section can used a different IP address. For exa= mple > one can imagine that during an IETF meeting each microphone has its own I= P > address and stream audio directly to some destination (in that example th= e IP > address in the SDP is only use for RTCP). If this use case was not possi= ble, > then it would be only possible to use c=3D at the session level. > draft-loreto-splices-disaggregated-media was, I think, the first document= to > call this "media disaggregation". >=20 > Now if we expand this to ICE, it means that each ICE agent declared in a = SDP > has to be independent of each other, i.e. each microphone in our example = has > it's own ICE agent, and they do not even to be from the same vendor. Tha= t > means that all SDP attributes needs to be at least media-level attributes= , and > eventually both media- and session- level attributes. IANA fixed the pro= blem > for ice-mismatch, but the problem still exists for ice-options, and fixin= g it > is part of rfc5245bis. >=20 > Now my suggestion was that for future SDP attributes, people should reall= y > think about the disaggregated case when they choose between a session-lev= el > only attribute or an attribute that works at both session- and media-leve= l, > because using a session-level only attribute prevents media disaggregatio= n. I > could not find this problem in any existing attribute at the time I did t= he > analysis but in ICE attributes, but note that this is not a problem speci= fic > to ICE. >=20 > So I would suggest adding some text after this paragraph in section 8.2.4= : >=20 > 'Submitters of registrations should ensure that the specification is > in the spirit of SDP attributes, most notably that the attribute is > platform independent in the sense that it makes no implicit > assumptions about operating systems and does not name specific pieces > of software in a manner that might inhibit interoperability.' >=20 > Something like this: >=20 > 'Submitters of registrations should also carefully choose the type of > attribute. They should not choose a session-level only type when the attr= ibute > can have different values when media is disaggregated, i.e. when each m= =3D > section has its own IP address on a different endpoint. In that case the > attribute type chosen should be "both".' >=20 > Thanks. >=20 > - --=20 > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQIcBAEBCAAGBQJTngvsAAoJECnERZXWan7EkoEP+QH/FamXyYcisXxR8vtRBUAV > D0MrwvRzzjQfAEW2aRSYPC12de0UeC7uYCOx9l7Cv1NKcFccdD/3NsDUNYy5C++Q > siL0YAcTIhuCiBYkYPUEq3Ix3CrXGnspBV2kbJdcBPgGuIw7jXNHQh5l5bvoAtJs > isHGev6rn6wGR2WheiYtlQ1AInFmjD5MqOyu9xtAAbdIJBWrqFzDsSq4vAevSyzL > EYPgW6Op6UoP6zGIB45PRXiGP//5Gj8jri9wXjp3M8cyvgpK6CoHoNe6m1rGuWqS > pMOh6vZRjRbkRpcufJ29tuV8SJ513m5x0pDSiCZAyNi47q3zgN+W++i4eX1ujnbN > D/UjmQmacSFO3N/QWvuAlZH9VRSVHdUbyw/NXUFFhCjexSokn/nBh7eFFvwMJyp6 > ZuxpKjcg+wrOxjkocSq8bNXcQLR1yohADKN1ePyHHvZ84+gkinlIpKMuegEBBFi5 > OVe0O4QiRjKd3h1ewO98tzPUKVhaD9nSkLT7eOjHU3Xfz5Ol5tlA50+5P7tcN43h > OO10nUijN4lxBsTi0WNC2sFpE3WXQ8gAkWHKyedfeMx9Uvl2SF18QFujAeD1oYIN > jS+SuZOlO7S6t2naMzyJj10yOxzgSnNYBGBQQ2yP1oE1qtiZjCDhTTaJIMjTgCYu > V/fj5tQ5v43FLPpKlD+8 > =3Dqu35 > -----END PGP SIGNATURE----- From nobody Sun Jun 29 14:08:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389271A0024 for ; Sun, 29 Jun 2014 14:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMZvHFmqMLXd for ; Sun, 29 Jun 2014 14:08:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8D91A000E for ; Sun, 29 Jun 2014 14:08:07 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-b3-53b080352f46 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F4.30.19155.53080B35; Sun, 29 Jun 2014 23:08:05 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.174.1; Sun, 29 Jun 2014 23:08:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B9BC6110294; Mon, 30 Jun 2014 00:08:04 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C74CC5820B; Mon, 30 Jun 2014 00:08:38 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7423657363; Mon, 30 Jun 2014 00:08:38 +0300 (EEST) Message-ID: <53B08036.103@ericsson.com> Date: Sun, 29 Jun 2014 23:08:06 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvja5pw4Zgg/4+MYv3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZTTums9UcIqjYt5RwQbGR2xdjJwcEgImEg/e ToGyxSQu3FsPZHNxCAkcZZT4+u4HE4SzgVHi3NpzzBDOXkaJP12NUM46Rok7x9ayg/QLCaxg lNhwuLKLkYODV0BdYtr+EJAwi4CqRN/rXmYQm03AXuLmhOtg5aICyRJrtk4Cs3kFBCVOznzC AmKLCMhI7N20GayeWUBbYvadWUwgI4WB7FmLZSHCthIX5lxngbDlJba/ncMM8YGaxNVzm5gh rlGVuPrvFeMERuFZSDbMQtI+C0n7AkbmVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBwX1w y2/VHYyX3zgeYhTgYFTi4X1gtT5YiDWxrLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwBh20KTg6o7HtzwXOYubpfzQP1xptU2PVnfysSWDCojlfXi11/T9vko6S cENkdj8DR5ldx1RB+19i82pkb1/1dFFMsvIwWxS0//TUqqksfeJFMkqP2Q9/nrPnj5Nd+Heh 5VEJv9R+rwt/vaIv3IYvi19m/cEpj7yLZB5uUDodOefh7/Zn6q92KbEUZyQaajEXFScCAERc MQ5PAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5mE6ltU1YMkr8eUWzA7_sFkgJhk Cc: Flemming Andreasen Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 90 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 21:08:09 -0000 Hi all, MMUSIC has two 2,5 hour sessions tentatively scheduled for the IETF 90 meeting at Toronto: http://tools.ietf.org/agenda/90/ If you want to request a time slot to discuss a draft, please send an e-mail to the chairs as soon as possible, but latest by the end of Thursday 3rd of July. As usual, we want to ensure we take advantage of our meeting time in a productive manner that leads to forward progress. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback already. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following: - name of the draft and the presenter - how much time would you need - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks, Ari & Flemming From nobody Mon Jun 30 04:26:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210381A020A for ; Mon, 30 Jun 2014 04:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.85 X-Spam-Level: * X-Spam-Status: No, score=1.85 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NyUuFk_oqrp for ; Mon, 30 Jun 2014 04:26:22 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id A2F401A020B for ; Mon, 30 Jun 2014 04:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7DCAE7C3949 for ; Mon, 30 Jun 2014 13:26:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH83iF8foVnu for ; Mon, 30 Jun 2014 13:26:19 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 268E27C38EA for ; Mon, 30 Jun 2014 13:26:19 +0200 (CEST) Message-ID: <53B14959.2090907@alvestrand.no> Date: Mon, 30 Jun 2014 13:26:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030409080108070500090106" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uu8G_SKNZhswoXgCrJxJNVWPL3U Subject: Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 11:26:26 -0000 This is a multi-part message in MIME format. --------------030409080108070500090106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with Bo's analysis concluding that IDENTICAL-PER-SSRC is likely not needed, and that situations where one has one SSRC in multiple media descriptions are probably a Bad Thing (I can't think of a case where it would represent anything but a bug). IDENTICAL-PER-PT seems like a sensible thing to add. On 06/23/2014 05:36 AM, Suhas Nandakumar wrote: > Hello All > > Continuing the discussions from London on analyzing multiplexing > behavior for SDP attributes that are defined per Payload Type, I was > thinking on making following changes to the > draft-ietf-mmusic-sdp-mux-attributes-01. > > 1. Add new category called IDENTICAL-PER-PT to the SDP Attribute > analysis framework in Section 4 which is defined as > > IDENTICAL-PER-PT: Attributes that define the RTP payload configuration > on per Payload Type basis and MUST have identical values across all > the media descriptions for a given RTP Payload Type when repeated. > > 2. Similarly add another category IDENTICAL-PER-SSRC to accommodate > source level SDP attributes. > > IDENTICAL-PER-SSRC: Attributes that correspond to the individual RTP > Packet Streams in a given RTP Session and MUST have identical values > when repeated across multiple media description for a given SSRC. > > 3. For all the attributes that directly/indirectly impact codec > configuration and packetization of the media, I have attempted to > assign a SDP MUX category and provide some insights on how such a > decision was made (wherever applicable) > > *Attribute: a=ptime, a=maxptime* > Mux Category: IDENTICAL-PER-PT > Notes: For a given codec the audio packetization time must be same if > the PT is repeated. This will ensure that the RTP receiver > can unambiguously decode the incoming audio packets. > > > *Attribute: a=framerate* > Mux Category: IDENTICAL-PER-PT > > *Attribute: a=rtpmap* > Mux Category: IDENTICAL-PER-PT > > > *Attribute: a=fmtp* > Mux Category: IDENTICAL-PER-PT > Notes: > > *Attribute: a=rtcp-fb* > Mux Category: NORMAL > Notes: Since the feedback messages are reported per SSRC, the category > of NORMAL suffices. > > *Attribute: a=depend (RFC5583)* > Mux Category: IDENTICAL-PER-PT > Notes: > Since each dependency identifies a unique RTP packetization and thus > MUST be identified via unique Payload Type. > Similarly if the Payload Type is repeated across media descriptions, > they MUST represent the Identical codec configuration. > > *Attribute: a=ssrc:xyz fmtp: ... * > Mux Category: IDENTICAL-PER-PT > Notes: > RFC5576 says this : > " > Within a media stream, "ssrc" attributes with the same value of > describe different attributes of the same media sources. > Across media streams, values are not correlated (unless > correlation is indicated by media-stream grouping or some other > mechanism) and MAY be repeated. > " > Thus if the RTP Payload Type used to specify fmtp parameters is repeated, it MUST representthe same codec configuration. > example: > m=video ... > a=rtpmap:98 VP8/90000 > a=ssrc:12345 fmtp:98max-fr=15; max-fs-1200 > m=video ... > a=rtpmap:98 VP8/90000 > > a=ssrc:56789 fmtp:98 max-fr=15; max-fs-1200 > *Attribute: a=ssrc:xyz cname: ....* > Mux Category: IDENTICAL-PER-SSRC > Notes: RFC5576 defines the identical requirement as it is. > > * > * > *Attribute: a=imageattr* > Mux Category: IDENTICAL-PER-PT > > > *Attribute: a=framesize* > Mux Category: IDENTICAL-PER-PT > > > *Attributes: a=fec-source-flow, a=fec-repair-flow, a=repair-window* > Mux Category: NORMAL > > > I believe these cover all PT scoped SDP attributes. Please let me know > your thoughts and comments. > > Cheers > Suhas Nandakumar > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------030409080108070500090106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I agree with Bo's analysis concluding that IDENTICAL-PER-SSRC is likely not needed, and that situations where one has one SSRC in multiple media descriptions are probably a Bad Thing (I can't think of a case where it would represent anything but a bug).

IDENTICAL-PER-PT seems like a sensible thing to add.

On 06/23/2014 05:36 AM, Suhas Nandakumar wrote:
Hello All

  
   Continuing the discussions from London on analyzing multiplexing behavior for SDP attributes that are defined per  Payload Type, I was thinking on making following changes to the draft-ietf-mmusic-sdp-mux-attributes-01. 

1. Add new category called IDENTICAL-PER-PT to the SDP Attribute analysis framework in Section 4 which is defined as

IDENTICAL-PER-PT: Attributes that define the RTP payload configuration on per Payload Type basis and MUST have identical values across all the media descriptions for a given RTP Payload Type when repeated.

2. Similarly add another category IDENTICAL-PER-SSRC to accommodate source level SDP attributes.

IDENTICAL-PER-SSRC: Attributes that correspond to the individual RTP Packet Streams in a given RTP Session and MUST have identical values when repeated across multiple media description for a given SSRC.

3. For all the attributes that directly/indirectly impact codec configuration and packetization of the media, I have attempted to assign a SDP MUX category and provide some insights on how such a decision was made (wherever applicable)

Attribute: a=ptime, a=maxptime
Mux Category: IDENTICAL-PER-PT
Notes: For a given codec the audio packetization time must be same if the PT is repeated. This will ensure that the RTP receiver can unambiguously decode the incoming audio packets.


Attribute: a=framerate
Mux Category: IDENTICAL-PER-PT

Attribute: a=rtpmap
Mux Category: IDENTICAL-PER-PT


Attribute: a=fmtp
Mux Category: IDENTICAL-PER-PT
Notes: 

Attribute: a=rtcp-fb
Mux Category: NORMAL
Notes: Since the feedback messages are reported per SSRC, the category of NORMAL suffices.

Attribute: a=depend (RFC5583)
Mux Category: IDENTICAL-PER-PT
Notes:
Since each dependency identifies a unique RTP packetization  and thus MUST be identified via unique Payload Type. 
Similarly if the Payload Type is repeated across media descriptions, they MUST represent the Identical codec configuration. 

Attribute: a=ssrc:xyz  fmtp:<fmt> ... 
Mux Category: IDENTICAL-PER-PT
Notes:
RFC5576 says this :
"  
Within a media stream, "ssrc" attributes with the same value of
 
<ssrc-id> describe different attributes of the same media sources.
Across media streams, <ssrc-id> values are not correlated (unless
correlation is indicated by media-stream grouping or some other
mechanism) and MAY be repeated.
"
Thus if the RTP Payload Type used to specify fmtp parameters  is repeated, it MUST represent the same codec configuration.
example:
m=video ...
a=rtpmap:98 VP8/90000
a=ssrc:12345 fmtp:98max-fr=15; max-fs-1200

              
m=video ...
a=rtpmap:98 VP8/90000


a=ssrc:56789 fmtp:98 max-fr=15; max-fs-1200




              

              
                

                    
Attribute: a=ssrc:xyz  cname: ....

                    
Mux Category: IDENTICAL-PER-SSRC

                    
Notes: RFC5576 defines the identical
                      requirement as it is.

                    


                    

                  

                


                  

                

                  
Attribute: a=imageattr

                  
Mux Category: IDENTICAL-PER-PT

                  


                  

                

                


                

                
Attribute: a=framesize

                
Mux Category: IDENTICAL-PER-PT

                


                

                


                

                

                  
Attributes: a=fec-source-flow,
                        a=fec-repair-flow,
                        a=repair-window

                  
Mux Category: NORMAL

                

                


                

                


                

                
I believe these cover all PT scoped SDP attributes.
                  Please let me know your thoughts and comments.

                


                

                
Cheers

                
Suhas Nandakumar

              

          

      

      

      

      

      
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


    

    

  


--------------030409080108070500090106--


From nobody Mon Jun 30 10:44:07 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722161A03D3 for ; Mon, 30 Jun 2014 10:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.552
X-Spam-Level: 
X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygWxyT2iobgJ for ; Mon, 30 Jun 2014 10:44:00 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB191A03B6 for ; Mon, 30 Jun 2014 10:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5371; q=dns/txt; s=iport; t=1404150239; x=1405359839; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=F0cZgf7vfxcu+l7dGCr1U85Ll3/bHK7uJ/m6XDm9M/Q=; b=duyJNjX/MR1pXhEqpY2BMJ1p/Gk6o5yv01y+4Z/tqQ4sIrzWJj8RAnBe ycsTacijj/ljSVjtCnD4QBJsI931Zk5n4Cp3JhhqchSNpeYogZcVAHTNS 0+9EAMQCY7fdNYKcqY3yPawTeZdAOUBV7GsH7vMflIZyohsTe34Ppp1rr Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsHAEehsVOtJA2F/2dsb2JhbABagw1Sq3QBAQEBAQEFAW4BkgaGbVMBgREWdYQDAQEBAwEBAQEkETYKBgsLGAkWDwkDAgECARUwBgEMBgIBAYg2CA3IHxMEhWSISwFehEMBBJpehwaMd4NeIYExAR8
X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="336773663"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jun 2014 17:43:58 +0000
Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5UHhwIW029920; Mon, 30 Jun 2014 17:43:58 GMT
Message-ID: <53B1A1DD.8080503@cisco.com>
Date: Mon, 30 Jun 2014 13:43:57 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Harald Alvestrand , mmusic@ietf.org
References: <53AC9ABC.3030107@alvestrand.no> <53ADA38E.1040009@alum.mit.edu> <53AE6E1A.3030204@alvestrand.no>
In-Reply-To: <53AE6E1A.3030204@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/du_Z0yWbZHNChFepWOBBPBk3zfU
Subject: Re: [MMUSIC] Updated MSID draft - version -06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 17:44:02 -0000

On 6/28/14, 3:26 AM, Harald Alvestrand wrote:
> On 06/27/2014 07:02 PM, Paul Kyzivat wrote:
>> The following are my comments on the -06 version:
>>
>> Sections 2 & 2 (ABNF):
>>
>> There is an error in the ABNF:
>>
>>       identifier-list = (" " identifier)* / " *"
>>
>> should be
>>
>>       identifier-list = *(" " identifier) / " *"
>>
>> Also, to formally check ABNF that extends 4566 it is necessary to
>> merge the ABNFs. To facilitate this it would be good to ensure that
>> all the new ABNF names introduced are unique across 4566. And since
>> some implementers may need to merge many extensions, it would good to
>> avoid defining new names that are overly generic and prone to
>> collision. In particular, I suggest the following renamings would
>> improve things:
>>
>> identifier -> msid
>> appdata -> msid-data
>> semantic -> msid-semantic
>> identifier-list -> msid-list
>>
>> Note: I'm not saying that these currently cause any conflicts. I don't
>> think they do with 4566 itself, and I have no idea if they conflict
>> with other extensions to 4566. I'm suggesting this as a matter of
>> prudence and readability.
> I think this actually reduces readability, but that's a matter of taste.
I'm with Paul on this one and would prefer something along the lines of 
what he suggested.

> One of our failiures with ABNF is that we never implemented a
> modularization facility with official syntax for "identifier =  in other document>".
>
>> Section 3 says:
>>
>>     This attribute MUST be present if "a=msid" is used.
>>
>> This is true, but stronger constraints ought to be applied:
>>
>>     Every identifier mentioned in an msid-semantic line MUST also
>>     appear in at least one a=msid line.
>>
>>     The identifier in every a=msid line MUST be mentioned in
>>     *at least* (or perhaps *exactly*) one a=msid-semantic line.
> Not a bad idea. The wildcard identifier (*) counts as
>> Section 4.1:
>>
>> The section refers to "WebRTC entity", but AFAIK there is no
>> definition of this. I presume you don't mean to restrict this to
>> browsers. IIUC you probably mean any entity that supports
>> msid-semantic:WMS. Could you clarify the text?
> With the split in -overview recently into "WebRTC browsers" and "WebRTC
> devices", this is actually limited to WebRTC browsers, since the SDP in
> question only appears on the Javscript API, and implementing the
> Javascript API is only a requirement for browsers....
Are you suggesting any changes here (seems to me we shouldn't limit the 
mechanism to just browsers, which I think was Paul's point as well) ?
>> Section 4.2:
>>
>> This section should probably be called "Detailed Offer/Answer
>> procedures".
>>
>> The following:
>>
>>     These procedures ...
>>
>>     They are specifically applicable to the WMS semantic; other semantics
>>     will have their own consideration.
>>
>> Is this really true? ISTM that there are some basic O/A procedures
>> that apply to all msid-semantics. Specifically,
>>
>> - If a particular msid-semantic is mentioned in an offer, and it is
>>    supported by the answerer, then a corresponding msid-semantic
>>    MUST be mentioned in the answer. (The absence indicates that it
>>    is not supported.)
>>
>> So I think there is need of a "generic" set of O/A procedures. And
>> then there can be additional O/A procedures specific to WMS. The
>> existing sections 4.2.1 - 4.2.5 are just the WMS-specific ones.
> My problem is that I don't want to write the generic ones, because I
> don't have any idea what they should say.
>
> This is a generic problem with the generic mechanism - we can't define
> rules for what doesn't exist yet, and it's not possible to see what
> parts of the rules are true for any use of msid and what parts of the
> rules are true for WMS only before we start seeing a second usage.
>
> At the moment we have zero value to the generic mechanism, because we
> have zero potential usages of it. Writing something that has zero value
> does not appeal greatly to me.
For an MMUSIC document extending SDP, we do need O/A sections following 
the structure of RFC 3264. If you need help writing those, the chairs 
can try and find somebody to assist.

> I suggested earlier that we might instead rip out the whole generalized
> mechanism and go back to msid being WMS only. I got no responses on that
> suggestion (neither positive or negative - it was ignored).
>
> This suggestion of another set of for-now-useless sections in the
> document makes me reiterate that proposal. Can you comment on it?
My initial reaction for an MMUSIC document would be against that, but 
can you provide a pointer or resend the proposal so we can take another 
look and discuss it.

Thanks

-- Flemming

>> Section 4.2.1:
>>
>> This section should say something about msid-semantic. Some of the
>> text from section 4.1 might do the job:
>>
>>     If a WebRTC entity sends a description, it MUST include the msid-
>>     semantic:WMS attribute, even if no media streams are sent.
> Yes.
>
>> That covers everything I noticed.
>>
>>      Thanks,
>>      Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Mon Jun 30 10:53:07 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF291A03D0 for ; Mon, 30 Jun 2014 10:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level: 
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCnjBDReep9p for ; Mon, 30 Jun 2014 10:53:02 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 771C71A03B6 for ; Mon, 30 Jun 2014 10:53:02 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id Lf8p1o0050vyq2s5Dht1wa; Mon, 30 Jun 2014 17:53:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Lht11o00h3ZTu2S3Rht1Sh; Mon, 30 Jun 2014 17:53:01 +0000
Message-ID: <53B1A3FD.3000507@alum.mit.edu>
Date: Mon, 30 Jun 2014 13:53:01 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <53AC9ABC.3030107@alvestrand.no>	<53ACB1F2.4030201@cisco.com>  <53AD2E56.6090501@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1F7A84@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53AD8B5B.5040600@cisco.com>
In-Reply-To: <53AD8B5B.5040600@cisco.com>
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=q20140121; t=1404150782; bh=xyxmvcOaN1bwItWI0nqNsouP/VOPWFdyuoLEbBeMErg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RAQ683MXBaP+wSK60usiXyLwXBRDtp44WEKPqdUfV5jkkjOoaVUJ7Z+xQB04bDdYI Kg27SJifKAybzA8w5LuyeKtgCJS7Aalpv+3hvXLQ8l78A/EaD/L6wZLmAIprzYXtr3 WzIXNFFT04HVCYoXBe7quwqhf20Il+sTCoLzcyGufLVfIrz7PijOw8A8wl28NCAhoR QYiujWAosU4BsuIzRI3ZupQ6tqPhcNbG6C4gQmbGNkKZ3QCswipwFBXbq+RNJD7US4 AUtYeeu+rup0doTUaLMWgdoYXvy1UJojhCWNcSIYCymteWGbcnhVM5l/sZih/qdkd/ LGdZYvHigZc1Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ug9pD5s7Nlu24W_uDoOZES5BHGU
Subject: Re: [MMUSIC] RTP taxonomy draft review [Re: Updated MSID draft - version -06]
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 17:53:05 -0000

I haven't fully reviewed it. But I've been checking alignment with clue 
usage. And one question I have is which way references should point.

Right now the taxonomy has a section called Mapping from Existing Terms. 
This has come CLUE terms in it, and effectively defines them relative to 
the terms defined in the concepts section. Some of these definitions are 
different in detail from those in the CLUE documents, though for the 
most part the same in spirit.

Obviously this can only be done for usages that are known before the 
taxonomy is finally published as an RFC. After that, documents that 
define their own terms relative to the taxonomy will have to publish the 
relationship in their own document.

What should we do in our effort to rationalize the clue terminology with 
the taxonomy?

- copy the description of the clue term from the taxonomy into the
   clue documents, and retain it in the taxonomy.

- remove the description of the clue term from the taxonomy and put
   an appropriate definition into the clue docs, relating to the
   terms defined in the concepts section of the taxonomy.

Note that we may want to delay the publication of the taxonomy until 
this can be completed.

Also, CLUE has been using the term MCU, which wasn't defined in the 
taxonomy, but has since been added. The taxonomy definition looks good, 
better than the one currently in clue. But the clue definition is 
specialized to clue, in that we assume the MCU is capable of supporting 
the CLUE features.

ISTM that for this one the "right" answer is for clue to define a new 
term (e.g., CLUE-MCU) that is a specialization of the taxonomy 
definition of MCU. That unfortunately means we will have to update all 
of our documents.

This seems to be something that will come up a lot in general - 
specializations of concepts that are generic in the taxonomy.  I wonder 
if the taxonomy should talk about this.

	Thanks,
	Paul

On 6/27/14 11:18 AM, Flemming Andreasen wrote:
> [updated subject]
>
> Per Keith's question below, has anybody in the MMUSIC group reviewed the
> RTP taxonomy draft:
>
> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/
>
> If so, please let the group and chairs know.
>
> Thanks
>
> -- Flemming
>
>
> On 6/27/14, 9:46 AM, DRAGE, Keith (Keith) wrote:
>> The timeline for the taxonomy draft is that it is essentially ready
>> for WGLC as soon as enough CLUE, RTCWEB and MMUSIC people have looked
>> at it to say it is consistent with the documentation in that WG.
>>
>> Is anyone reviewing (or indeed has reviewed it) from the MMUSIC
>> perspective, or in respect of specific documents in the MMUSIC working
>> group.
>>
>> Keith
>>
>>> -----Original Message-----
>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of
>>> Harald Alvestrand
>>> Sent: 27 June 2014 09:42
>>> To: Suhas Nandakumar; Flemming Andreasen
>>> Cc: mmusic@ietf.org
>>> Subject: Re: [MMUSIC] Updated MSID draft - version -06
>>>
>>> Just a quick reply to the general comments...
>>>
>>>
>>> On 06/27/2014 09:56 AM, Suhas Nandakumar wrote:
>>>
>>>
>>>     Hello Harald
>>>
>>>       Thanks for the work on this draft. Below are few
>>> thoughts inline
>>>
>>>     * General Comment:
>>>          + We might want to use RTP Taxonomy throughout
>>>
>>>
>>> Yes. When the concepts are the same, we should. (what's the
>>> timeline for the RTP taxonomy?) Can you help find terms that
>>> are not used identically with Taxonomy?
>>>
>>>
>>>
>>>          + Replace MediaStream with "WebRTC MediaStream" for clarity
>>>          + Replace MediaStreamTrack with "WebRTC
>>> MediaStreamTrack" clarity
>>>
>>>
>>> I would push back on that in any section where the section
>>> title or the same sentence includes "WebRTC".
>>>
>>> So far "MediaStreamTrack" is used in the intro (WebRTC in the
>>> same sentence), section 1.1 (ditto), section 1.3 (WebRTC in
>>> heading), section 4 (WebRTC in heading).
>>>
>>> So the only usage concerned would be in Appendix B.
>>>
>>>
>>>
>>>          + m-line usage , can it be changed to m=line instead
>>>
>>>
>>> I don't understand this comment - it is highly unusual to use
>>> the = sign to denote compound words.
>>> It is possible that most occurences should be replaced with
>>> "media section". Would that be more readable?
>>>
>>>
>>>
>>>
>>>
>>>
>>>     * Section 1.1
>>>     This document adds a new Session Description Protocol
>>> (SDP) Grouping[RFC5888]
>>> >> 88>  relation between SDP m-lines [RFC4566]
>>> >> 66>  that can associate application layer identifiers with
>>> the binding between media streams, attaching identifiers to
>>> the media streams and attaching identifiers to the groupings
>>> they form.
>>>
>>>
>>>     [Suhas] I am assuming we are referring to RTP Stream here
>>>
>>>
>>> Since "RTP Stream" is not a defined term in
>>> draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a
>>> packet stream, which RFC 3550 sometimes refers to as "media stream".
>>>
>>>
>>>
>>>
>>>
>>>
>>>     Section 1.2
>>>     SDP gives a description based on m-lines. According to
>>> the model used in [I-D.ietf-rtcweb-jsep]
>>> >> etf-rtcweb-jsep> , each m-line describes exactly one media
>>> source, and if mulitple media sources are carried in an RTP
>>> session, this is signalled using BUNDLE
>>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
>>> >> etf-mmusic-sdp-bundle-negotiation> ; if BUNDLE is not used,
>>> each media source is carried in its own RTP session.
>>>
>>>     [Suhas] suggest updating the above para as
>>>
>>>
>>>     " SDP gives a description based on m-lines. According
>>> to the model used in [I-D.ietf-rtcweb-jsep]
>>> >> etf-rtcweb-jsep> , each m-line describes exactly one media
>>> source (WebRTC MediaStreamTrack), and if multiple media
>>> sources are carried in an RTP session, this is signaled using
>>> BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]
>>> >> etf-mmusic-sdp-bundle-negotiation>  mechanism ; if BUNDLE is
>>> not used, each media source is carried in its own RTP session."
>>>
>>>
>>>
>>> Section 1.2 is not WebRTC specific, so should not use WebRTC
>>> terms. The model used in JSEP doesn't have an independent
>>> formulation, unfortunately, but the main thrust of the
>>> argument for adopting it is that this is the model used by a
>>> significant portion of existing applications, so adopting
>>> that model for JSEP enhances interoperability.
>>>
>>> "Media source" is a defined term in -taxonomy-.
>>>
>>>
>>>
>>>
>>>
>>>     Section 1.2 Para 4
>>>     [Suhas] Para 3 doesn't force the need for a new
>>> mechanism and it is probably a good idea to add more clarity
>>> in Para4 to clarify the need as below"
>>>
>>>
>>>     "The SDP grouping framework [RFC5888]
>>> >> 88>  can be used to group m-lines. When an m-line describes
>>> one and only one RTP Packet stream, it is possible to
>>> associate RTP media streams across different m-lines.
>>> However, cases such as when a m-line has multiple RTP Packets
>>> streams or the need for an application to specify
>>> application-level information about the association between
>>> the m-line and the group, the SDP grouping framework cannot
>>> be used for this purpose"
>>>
>>> This seems good. I'll adopt and/or adapt.
>>>
>>>
>>>
>>>
>>>     * Section 1.3 Para 3
>>>     WebRTC defines a mapping (documented in
>>> [I-D.ietf-rtcweb-jsep]
>>> >> etf-rtcweb-jsep> ) where one SDP m-line is used to describe
>>> each MediaStreamTrack, and that the BUNDLE mechanism
>>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
>>> >> etf-mmusic-sdp-bundle-negotiation>  is used to group
>>> MediaStreamTracks into RTP sessions.
>>>
>>>     [Suhas] we might want to say "MediaStreamTracks into a
>>> RTP Session" instead of "MediaStreamTracks into RTP Sessions"
>>>
>>>
>>> No, because in the case of less than total Bundling,
>>> MediaStreamTracks will be grouped into multiple RTP sessions,
>>> not a single one.
>>>
>>>
>>>
>>>
>>>     *Section 1.3 Para 3
>>>     Therefore, the need is to specify the ID of a
>>> MediaStreamTrack and its associated MediaStream for each
>>> m-line, which can be accomplished with a media-level SDP attribute.
>>>     [Suhas] Can we change it to
>>>
>>>     "
>>>      Therefore, the need is to uniquely identify the
>>> MediaStreamTrack and its MediaStream for each m-line via a
>>> media-level SDP attribute. This would enable establishing the
>>> relationship between RTP Packet Streams that correspond to
>>> same WebRTC MediaStream across m= lines".
>>>     "
>>>
>>>
>>> Modulo "would" -> "will" ("would" is the wishful-thinking
>>> tense of the word, which I like to avoid - can't remember the
>>> grammatical name of the construct at the moment).
>>>
>>>
>>>
>>>
>>>
>>>     * Section 2 Title
>>>      [Suhas] Msid is not defined. Also suggest common
>>> convention. (MSID vs Msid) throughout
>>>
>>>
>>> The section is the definition of MSID, I'm not sure how to
>>> define the term before defining it.
>>>
>>> I'd like to have the convention be "msid" (all lower case),
>>> but the RFC Editor likes capitals in section titles. I'll
>>> lowercase it and see if it survives. (I lowercased all
>>> occurences elsewhere in a previous pass)
>>>
>>>
>>>
>>>
>>>
>>>     Section 3
>>>
>>>     The ABNF of msid-semantic is:
>>>
>>>       attribute =/ msid-semantic-attr
>>>       msid-semantic-attr = "msid-semantic:" semantic identifier-list
>>>       semantic = token ; see RFC 4566
>>>       identifier-list = (" " identifier)* / " *"
>>>
>>>     [Suhas] The identifier-list MUST be msid not generic
>>> identifier. Since this session level grouping applies only to
>>> msid or should it apply
>>>
>>>
>>> There is no "msid" ABNF construct. The "msid-attr" in section
>>> 2 is defined in terms of identifier.
>>> So I can't parse this request.
>>>
>>>
>>>
>>>
>>>     * Section 4
>>>     [Suhas] Shouldn't we make appData MUST for WMS
>>> semantics. Since having a MediaStream with no tracks into
>>> makes much sense. also the ABNF for appdata is optional in Section 2.
>>>
>>>
>>> It makes sense to say that it MUST be given. Will do.
>>>
>>>
>>>
>>>
>>>
>>>     * Section 4
>>>     [Suhas] When the m= section is updated to inactive, I
>>> am thinking we should signal the MedaStreamTrack as ended, is
>>> that a right assumption ?
>>>
>>>
>>> No, because "inactive" can be resumed.
>>> "Ended" is a final state for a MediaStreamTrack.
>>>
>>>
>>>
>>>
>>>
>>>
>>>     * Section 4
>>>        In addition to signaling that the track is closed
>>> when its msid attribute disappears from the SDP, the track
>>> will also be signaled as being closed when all associated
>>> SSRCs have disappeared by the rules of
>>>     [Suhas] Probably a formatting glitch. The above
>>> sentence is incomplete
>>>
>>>
>>> In my copy, it continues with "[RFC3550] section 6.3.4 (BYE
>>> packet received) and 6.3.5 (timeout), and when the
>>> corresponding media section is disabled by setting the port
>>> number to zero.". What does it say in your copy?
>>>
>>>
>>>
>>>
>>>     * Section 4
>>>     The association between SSRCs and m-lines is specified
>>> in [I-D.ietf-rtcweb-jsep]
>>> >> etf-rtcweb-jsep> .
>>>
>>>     [Suhas] Why is this needed here ?
>>>
>>>
>>>
>>> It's not. Will remove.
>>>
>>>
>>>
>>>
>>>
>>>     * Section 4.1 Title
>>>     [Suhas] Tracks undefined, suggest we change it to
>>> WebRTC MediaStreamTracks or something like that.
>>>
>>>
>>> I think it would be correct to say "non-signalled packet streams".
>>>
>>>
>>>
>>>
>>>
>>>     * Section 4.1 Para 1
>>>     Non-WebRTC entities will not send msid
>>>
>>>     [Suhas] Suggest changing will not to may not .. since
>>> msid itself is generic mechanism but WMS is webrtc specific mechanism
>>>
>>>
>>> I'll change to "will not send msid with the WMS semantic".
>>> This is a leftover from before msid-semantic was introduced.
>>> Good catch!
>>>
>>>
>>>
>>>
>>>
>>>
>>>     * Section 4.1
>>>     It follows from the above that media stream tracks in
>>> the "default" media stream cannot be closed by removing the
>>> msid attribute; the application must instead signal these as
>>> closed when the SSRC disappears according to the rules of RFC
>>> 3550 section 6.3.4 and 6.3.5 or by disabling the m-line by
>>> setting its port to zero.
>>>
>>>     [ Suhas ] "default" media stream and tracks aren't
>>> defined and we need some context to explain this.
>>>
>>>
>>> This should be "tracks constructed by the above rule when no
>>> msid-semantic:WMS is present".
>>> Good catch.
>>>
>>>
>>>
>>>
>>>
>>>     * Section 4.2.1
>>>      How do we want to support adding  a track that is not
>>> part of a Media Stream ? Should there be a msid line at all ?
>>>
>>>
>>> This is not supported. Should it be?
>>>
>>>
>>>
>>>
>>>
>>>     * Section 4.2.1
>>>      What should happen if the modified SDP has same msid
>>> but a different trackId in the appData. Should we trigger
>>> ended on the old track and created on the new track ?
>>>
>>>
>>> Yes.
>>>
>>>
>>>
>>>
>>>
>>>     Is it worthwhile considering the possibility of sending
>>> the TrackId in the RTP Layer (as header extension) since it
>>> can identifies the Media Source end to end.
>>>
>>>
>>> This is being considered for BUNDLE (appid). I don't want to
>>> try to do the same thing here, for fear of having duelling
>>> specifications.
>>>
>>>
>>>
>>>
>>>
>>>     *Section 4 - Offer/Answer Procedures
>>>     We might want to add some text to explain the following
>>>      - An Offer has WMS semantic include, Answerer doesn't
>>> include the semantic in response --> No WMS used for the session
>>>      - Either Offer/Answer has a semantic which isn't
>>> understood by the end-points --> No MSID mechanism is used
>>> and m= lines are rejected
>>>
>>>
>>>
>>> I don't see a reason for either of these things. Continuing
>>> to announce the data does no harm.
>>> I can add "MUST ignore a=msid lines where the identifier is
>>> listed in a msid-semantic: header that the implementation
>>> does not support".
>>>
>>>
>>>
>>>
>>>     Section 4.1 Says
>>>     "If a WebRTC entity sends a description, it MUST
>>> include the msid-semantic:WMS attribute, even if no media
>>> streams are sent."
>>>     and Section 3 says
>>>     "This attribute MUST be present if "a=msid" is used."
>>>
>>>
>>>     So if i add both, it is not clear in the cases of
>>> recvonly/inactive streams in the Offer, if we should include
>>> a=msid line If i wanted to include a empty WMS semantic. So
>>> basically what mandates which is not very clear here ?
>>>
>>>
>>> 4.1 is about WebRTC implementations. These MUST send
>>> msid-semantic:WMS, whether or not they have any a=msid in the SDP.
>>>
>>> Non-WebRTC implementations that don't send a=msid don't have
>>> to send msid-semantic:.
>>>
>>> Non-WebRTC implementations that send a=msid MUST send
>>> msid-semantic: so that it's possible to figure out what they
>>> mean by their a=msid lines.
>>>
>>> Non-WebRTC implementations that use a different
>>> msid-semantic: must follow the rules for that semantic.
>>>
>>> I don't see what's not clear here, but would appreciate
>>> suggestions for more text to make it clearer.
>>>
>>>
>>>
>>>
>>>
>>>     Section 4.2.2
>>>     - We need a line to parse the Semantics
>>>
>>>
>>> Good catch. It needs to verify that the msid-semantic says
>>> WMS. (Since all of section 4.2 is about WMS, this is the only
>>> one we need to specify rules for.
>>>
>>>
>>>
>>>
>>>
>>>     Please let me know If i can help with aligning the
>>> draft with Taxonomy and so on..
>>>
>>>
>>> Help appreciated!
>>>
>>>
>>>
>>>
>>>
>>>
>>>     Thanks
>>>     Suhas Nandakumar
>>>
>>>     On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen
>>>  wrote:
>>>
>>>
>>>         Thanks Harald
>>>
>>>         It would be great if people could please take a
>>> look at the updated draft and see if they have any comments;
>>> we would like to get WGLC issued soon.
>>>
>>>         Thanks
>>>
>>>         -- Flemming (MMUSIC co-chair)
>>>
>>>
>>>
>>>         On 6/26/14, 6:12 PM, Harald Alvestrand wrote:
>>>
>>>
>>>             Flemming kindly pointed out to me that
>>> I had not actively notified the list about my new version of
>>> the -msid draft that was published on June 6.
>>>
>>>             Here's the changelog - the "detailed
>>> procedures" section has the "initial offer / initial answer"
>>> and so on format that was recommended by the chairs, so it
>>> may be of interest to this group.
>>>
>>>             Harald
>>>
>>>             C.12.  Changes from -05 to -06
>>>
>>>                Addressed issues found in Fleming
>>> Andreassen's review
>>>
>>>                Referenced JSEP rather than
>>> unified-plan for the M-line mapping model
>>>
>>>                Relaxed MSID definition to allow
>>> "token-char" in values rather than
>>>                a-z 0-9 hyphen; tightened ABNF by
>>> adding length description to it.
>>>
>>>                Deleted discussion of abandoned
>>> alternatives, as part of preparing
>>>                for publication.
>>>
>>>                Added a "detailed procedures"
>>> section to the WMS semantics
>>>                description.
>>>
>>>                Added IANA registration of the
>>> "msid-semantic" attribute.
>>>
>>>             _______________________________________________
>>>             mmusic mailing list
>>>             mmusic@ietf.org
>>>             https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         mmusic mailing list
>>>         mmusic@ietf.org
>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>> .
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Mon Jun 30 11:02:42 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132911A03A9 for ; Mon, 30 Jun 2014 11:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.951
X-Spam-Level: 
X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsiMIpVcAMzy for ; Mon, 30 Jun 2014 11:02:35 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFDA1A02DE for ; Mon, 30 Jun 2014 11:02:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7CA727C397B; Mon, 30 Jun 2014 20:02:33 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TPbHqcVJDkA; Mon, 30 Jun 2014 20:02:32 +0200 (CEST)
Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6E6D67C3942; Mon, 30 Jun 2014 20:02:32 +0200 (CEST)
Message-ID: <53B1A638.8000306@alvestrand.no>
Date: Mon, 30 Jun 2014 20:02:32 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Flemming Andreasen , mmusic@ietf.org
References: <53AC9ABC.3030107@alvestrand.no> <53ADA38E.1040009@alum.mit.edu> <53AE6E1A.3030204@alvestrand.no> <53B1A1DD.8080503@cisco.com>
In-Reply-To: <53B1A1DD.8080503@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9QiWqOxG8Y1bhUnhnKCBSSroiK8
Subject: Re: [MMUSIC] Updated MSID draft - version -06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 18:02:41 -0000

On 06/30/2014 07:43 PM, Flemming Andreasen wrote:
>
> On 6/28/14, 3:26 AM, Harald Alvestrand wrote:
>> On 06/27/2014 07:02 PM, Paul Kyzivat wrote:
>>> The following are my comments on the -06 version:
>>>
>>> Sections 2 & 2 (ABNF):
>>>
>>> There is an error in the ABNF:
>>>
>>>       identifier-list = (" " identifier)* / " *"
>>>
>>> should be
>>>
>>>       identifier-list = *(" " identifier) / " *"
>>>
>>> Also, to formally check ABNF that extends 4566 it is necessary to
>>> merge the ABNFs. To facilitate this it would be good to ensure that
>>> all the new ABNF names introduced are unique across 4566. And since
>>> some implementers may need to merge many extensions, it would good to
>>> avoid defining new names that are overly generic and prone to
>>> collision. In particular, I suggest the following renamings would
>>> improve things:
>>>
>>> identifier -> msid
>>> appdata -> msid-data
>>> semantic -> msid-semantic
>>> identifier-list -> msid-list
>>>
>>> Note: I'm not saying that these currently cause any conflicts. I don't
>>> think they do with 4566 itself, and I have no idea if they conflict
>>> with other extensions to 4566. I'm suggesting this as a matter of
>>> prudence and readability.
>> I think this actually reduces readability, but that's a matter of taste.
> I'm with Paul on this one and would prefer something along the lines
> of what he suggested.
>
>> One of our failiures with ABNF is that we never implemented a
>> modularization facility with official syntax for "identifier = > in other document>".
>>
>>> Section 3 says:
>>>
>>>     This attribute MUST be present if "a=msid" is used.
>>>
>>> This is true, but stronger constraints ought to be applied:
>>>
>>>     Every identifier mentioned in an msid-semantic line MUST also
>>>     appear in at least one a=msid line.
>>>
>>>     The identifier in every a=msid line MUST be mentioned in
>>>     *at least* (or perhaps *exactly*) one a=msid-semantic line.
>> Not a bad idea. The wildcard identifier (*) counts as
>>> Section 4.1:
>>>
>>> The section refers to "WebRTC entity", but AFAIK there is no
>>> definition of this. I presume you don't mean to restrict this to
>>> browsers. IIUC you probably mean any entity that supports
>>> msid-semantic:WMS. Could you clarify the text?
>> With the split in -overview recently into "WebRTC browsers" and "WebRTC
>> devices", this is actually limited to WebRTC browsers, since the SDP in
>> question only appears on the Javscript API, and implementing the
>> Javascript API is only a requirement for browsers....
> Are you suggesting any changes here (seems to me we shouldn't limit
> the mechanism to just browsers, which I think was Paul's point as well) ?

The requirement (the "MUST implement") is on WebRTC browsers, not WebRTC
devices.

>>> Section 4.2:
>>>
>>> This section should probably be called "Detailed Offer/Answer
>>> procedures".
>>>
>>> The following:
>>>
>>>     These procedures ...
>>>
>>>     They are specifically applicable to the WMS semantic; other
>>> semantics
>>>     will have their own consideration.
>>>
>>> Is this really true? ISTM that there are some basic O/A procedures
>>> that apply to all msid-semantics. Specifically,
>>>
>>> - If a particular msid-semantic is mentioned in an offer, and it is
>>>    supported by the answerer, then a corresponding msid-semantic
>>>    MUST be mentioned in the answer. (The absence indicates that it
>>>    is not supported.)
>>>
>>> So I think there is need of a "generic" set of O/A procedures. And
>>> then there can be additional O/A procedures specific to WMS. The
>>> existing sections 4.2.1 - 4.2.5 are just the WMS-specific ones.
>> My problem is that I don't want to write the generic ones, because I
>> don't have any idea what they should say.
>>
>> This is a generic problem with the generic mechanism - we can't define
>> rules for what doesn't exist yet, and it's not possible to see what
>> parts of the rules are true for any use of msid and what parts of the
>> rules are true for WMS only before we start seeing a second usage.
>>
>> At the moment we have zero value to the generic mechanism, because we
>> have zero potential usages of it. Writing something that has zero value
>> does not appeal greatly to me.
> For an MMUSIC document extending SDP, we do need O/A sections
> following the structure of RFC 3264. If you need help writing those,
> the chairs can try and find somebody to assist.

I have those. What I object to is writing two of them.

>
>> I suggested earlier that we might instead rip out the whole generalized
>> mechanism and go back to msid being WMS only. I got no responses on that
>> suggestion (neither positive or negative - it was ignored).
>>
>> This suggestion of another set of for-now-useless sections in the
>> document makes me reiterate that proposal. Can you comment on it?
> My initial reaction for an MMUSIC document would be against that, but
> can you provide a pointer or resend the proposal so we can take
> another look and discuss it.

What's the argument, based in an use case, for leaving the generic
mechanism in?



From nobody Mon Jun 30 11:12:48 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEA51A03A7 for ; Mon, 30 Jun 2014 11:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLrztVVqc9aP for ; Mon, 30 Jun 2014 11:12:46 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id D79321A040E for ; Mon, 30 Jun 2014 11:12:44 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta02.westchester.pa.mail.comcast.net with comcast id Lhfp1o0060SCNGk51iCkU3; Mon, 30 Jun 2014 18:12:44 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id LiCk1o00S3ZTu2S3ViCkzB; Mon, 30 Jun 2014 18:12:44 +0000
Message-ID: <53B1A89C.80801@alum.mit.edu>
Date: Mon, 30 Jun 2014 14:12:44 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <53AC9ABC.3030107@alvestrand.no> <53ADA38E.1040009@alum.mit.edu> <53AE6E1A.3030204@alvestrand.no> <53B1A1DD.8080503@cisco.com>
In-Reply-To: <53B1A1DD.8080503@cisco.com>
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=q20140121; t=1404151964; bh=kBdhe4zK3UGpgUbTTNqN323lg/xNPoXvvdxWowswdWo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qy3XbzTH1ijfvF0bdD9wzzi7gKZFf0glthKW8yS6HnNoiSfF3004P0ykblBTCyum7 tkY+DEmDRjmnHwUTUAgqFDhshDbo/6NJneg6NH1YsDvfNXOgZdBckV4IWPrv/taB7I l8HRfjSIImLBtkoyXS7xO1ijq6gSUQR2DptahocYv7ONdfJOy0jLs0wEiZ0iNz5DSu 0Pap9Kqf0M5beM+8+8hgagN8DggWUEbLJooFlMGCBhc2iqXZ7a+0Uzbc/bCk/J7xbm irzWm406grbS2fjZRxrhb5H/KvIirqu5Cpp3gS8U8J4CHM5W4rNhcJWM63P0/llfQU L8i9loGG62RoA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XY0yzxvaUuzkaotq0cMkRz52fP8
Subject: Re: [MMUSIC] Updated MSID draft - version -06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 18:12:47 -0000

On 6/30/14 1:43 PM, Flemming Andreasen wrote:

>>> Section 4.1:
>>>
>>> The section refers to "WebRTC entity", but AFAIK there is no
>>> definition of this. I presume you don't mean to restrict this to
>>> browsers. IIUC you probably mean any entity that supports
>>> msid-semantic:WMS. Could you clarify the text?
>> With the split in -overview recently into "WebRTC browsers" and "WebRTC
>> devices", this is actually limited to WebRTC browsers, since the SDP in
>> question only appears on the Javscript API, and implementing the
>> Javascript API is only a requirement for browsers....
> Are you suggesting any changes here (seems to me we shouldn't limit the
> mechanism to just browsers, which I think was Paul's point as well) ?

I'm not certain. I *think* that the two ends need to agree on how this 
works and is used. If one end is a browser, then the other end may need 
to understand about MediaStreams and MediaStreamTracks, and follow these 
rules. That's true whether the other end is also a browser or not.

And an endpoint that sometimes talks to browsers may want to use the 
same mechanisms even when no browser is present.

IOW, istm that this is really about rules for use of the WMS semantic, 
not rules for browsers.

But I'm not sure I understand it properly.

>>> Section 4.2:
>>>
>>> This section should probably be called "Detailed Offer/Answer
>>> procedures".
>>>
>>> The following:
>>>
>>>     These procedures ...
>>>
>>>     They are specifically applicable to the WMS semantic; other
>>> semantics
>>>     will have their own consideration.
>>>
>>> Is this really true? ISTM that there are some basic O/A procedures
>>> that apply to all msid-semantics. Specifically,
>>>
>>> - If a particular msid-semantic is mentioned in an offer, and it is
>>>    supported by the answerer, then a corresponding msid-semantic
>>>    MUST be mentioned in the answer. (The absence indicates that it
>>>    is not supported.)
>>>
>>> So I think there is need of a "generic" set of O/A procedures. And
>>> then there can be additional O/A procedures specific to WMS. The
>>> existing sections 4.2.1 - 4.2.5 are just the WMS-specific ones.
>> My problem is that I don't want to write the generic ones, because I
>> don't have any idea what they should say.

I don't think this is so hard. It is very similar to general O/A 
requirements for the grouping framework.

>> This is a generic problem with the generic mechanism - we can't define
>> rules for what doesn't exist yet, and it's not possible to see what
>> parts of the rules are true for any use of msid and what parts of the
>> rules are true for WMS only before we start seeing a second usage.
>>
>> At the moment we have zero value to the generic mechanism, because we
>> have zero potential usages of it. Writing something that has zero value
>> does not appeal greatly to me.
> For an MMUSIC document extending SDP, we do need O/A sections following
> the structure of RFC 3264. If you need help writing those, the chairs
> can try and find somebody to assist.

I've already started "helping". I am willing to continue doing so.

	Thanks,
	Paul


From nobody Mon Jun 30 11:18:42 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FA21A0413 for ; Mon, 30 Jun 2014 11:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRclYofUhW7K for ; Mon, 30 Jun 2014 11:18:38 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 084F31A0452 for ; Mon, 30 Jun 2014 11:18:36 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta02.westchester.pa.mail.comcast.net with comcast id LiH31o00727AodY51iJchR; Mon, 30 Jun 2014 18:18:36 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id LiJc1o00B3ZTu2S3fiJclg; Mon, 30 Jun 2014 18:18:36 +0000
Message-ID: <53B1A9FC.20402@alum.mit.edu>
Date: Mon, 30 Jun 2014 14:18:36 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <53AC9ABC.3030107@alvestrand.no> <53ADA38E.1040009@alum.mit.edu> <53AE6E1A.3030204@alvestrand.no> <53B1A1DD.8080503@cisco.com> <53B1A638.8000306@alvestrand.no>
In-Reply-To: <53B1A638.8000306@alvestrand.no>
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=q20140121; t=1404152316; bh=YoQiq30v9tne6OSBfkWmxkzln0vnR9mTyMZcWDTRINI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=asKTLBd4G2jft5gNDQThLA9bd8AoTawNIlWKTdWJlGdOb3zbtgFE1oip7fhYiE3pv RYzkZFsvriDTLHwtzAu7qyBcDB1oBlc16tLusGSfuMt7fAcJukz8VztENVOy7CbPJZ NQ77/NWYucW31gfEIF2C3gsfYg4xc1bysf6TMOVUEsT4dnZ03NmOK8PBQ8HiCVS8yL WmmgXdFIa+P7TPCnXKhXuZFzGSTBIwzqjlhahYb+ipzRRKCq9mwRHuyvsIAPScvTYO mfthKYRuvq8Hselu8QTG3irJM5P2RZS/CGtZuK9BccIDPyeVTPkRQlURzwKnYI+C5C w7QPYEfAusceA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/urXevh4OC6BUlMKwshi_9rO8n_c
Subject: Re: [MMUSIC] Updated MSID draft - version -06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 18:18:39 -0000

On 6/30/14 2:02 PM, Harald Alvestrand wrote:

>>>> The section refers to "WebRTC entity", but AFAIK there is no
>>>> definition of this. I presume you don't mean to restrict this to
>>>> browsers. IIUC you probably mean any entity that supports
>>>> msid-semantic:WMS. Could you clarify the text?
>>> With the split in -overview recently into "WebRTC browsers" and "WebRTC
>>> devices", this is actually limited to WebRTC browsers, since the SDP in
>>> question only appears on the Javscript API, and implementing the
>>> Javascript API is only a requirement for browsers....
>> Are you suggesting any changes here (seems to me we shouldn't limit
>> the mechanism to just browsers, which I think was Paul's point as well) ?
>
> The requirement (the "MUST implement") is on WebRTC browsers, not WebRTC
> devices.

I don't understand. Suppose I have a browser talking to a non-browser. 
And the non-browser end decides to add an m-line that represents another 
m-line. To be specific, suppose it decides to add video where previously 
there was only audio. And the video "goes with" the audio.

Doesn't it need to use this stuff to indicate the relationship?

	Thanks,
	Paul


From nobody Mon Jun 30 11:53:26 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807E51A04B9 for ; Mon, 30 Jun 2014 11:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVSEkKKtNtmQ for ; Mon, 30 Jun 2014 11:53:12 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB8E1A02E9 for ; Mon, 30 Jun 2014 11:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8692; q=dns/txt; s=iport; t=1404154391; x=1405363991; h=from:to:subject:date:message-id:references:mime-version; bh=QjQ5XasKxDKYsKBH4wFngXcE1tndLP8PrLOzqRF6noA=; b=gwg5VBQHGXjCvLFwm8e50pr+mkaySydarjFllWnhkPzqWKpby2EmgBrF ulXBbWpeHpt+wS+Y+PXfc+6+SpD+p4YqGGE4x2ZL3216cN0E9/WQTcV0c DrZSOxvnCEcciGZQKnEOo3lF40mJE370uk2DgDf5xRzVN+TNVFZG0O8kZ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkKAO+wsVOtJA2N/2dsb2JhbABagkZHHzNTB7xGgVUBhz8BgRIWdYQDAQEBBHcSAgEZAwECKAcyFAcCCAIEEwmIOQgFyDEXjnYNCgeCMFMkgRYFig2QUYFGkjeDQmyBRA
X-IronPort-AV: E=Sophos;i="5.01,576,1400025600";  d="scan'208,217";a="336739312"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jun 2014 18:53:09 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5UIr9kF009752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Jun 2014 18:53:09 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.80]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 13:53:09 -0500
From: "Pal Martinsen (palmarti)" 
To: "mmusic (E-mail)" 
Thread-Topic: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-07.txt
Thread-Index: AQHPlJOLh5EiAoumTEyKlcelylfgPw==
Date: Mon, 30 Jun 2014 18:53:08 +0000
Message-ID: <803DB627-3D5F-494D-9D25-E1000200A7A1@cisco.com>
References: <20140630184553.31625.21293.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.215.102]
Content-Type: multipart/alternative; boundary="_000_803DB6273D5F494D9D25E1000200A7A1ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0p55wqnmE-xEokfHy4pNU7M48a8
Subject: [MMUSIC] Fwd: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-07.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 18:53:16 -0000

--_000_803DB6273D5F494D9D25E1000200A7A1ciscocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,

We have just completed and submitted  our work on the 07 version of draft-r=
eddy-mmusic-ice-happy-eyeballs.

Summary of changes:
The algorithm proposal have been moved to the appendix. The text have been =
slightly modified to make it clear that this draft is all about recommendat=
ions and what values you can play with without breaking vanilla ICE compati=
bility.

This is the last version of the draft we publish as an ID. Its been fun, an=
d we have improved our own ICE implementation. So whatever the draft will b=
e accepted or not, it have proven to be useful for at least the authors.

.-.
P=E5l-Erik

Begin forwarded message:

From: >
Subject: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs=
-07.txt
Date: 30 Jun 2014 20:45:53 GMT+2
To: Prashanth Patil >, Tiruma=
leswar Reddy >, Tirumaleswar Re=
ddy >, "Paal-Erik Martinsen" >, Prashanth Patil >, Paal-Erik Martinsen >


A new version of I-D, draft-reddy-mmusic-ice-happy-eyeballs-07.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the
IETF repository.

Name: draft-reddy-mmusic-ice-happy-eyeballs
Revision: 07
Title: Happy Eyeballs Extension for ICE
Document date: 2014-06-30
Group: Individual Submission
Pages: 8
URL:            http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ice-=
happy-eyeballs-07.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-hap=
py-eyeballs/
Htmlized:       http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-eye=
balls-07
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-mmusic-ice-h=
appy-eyeballs-07

Abstract:
  This document provides guidelines on how to make Interactive
  Connectivity Establishment (ICE) conclude faster in IPv4/IPv6 dual-
  stack scenarios where broken paths exist.  The provided guidelines
  are backwards compatible with the original ICE specification.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--_000_803DB6273D5F494D9D25E1000200A7A1ciscocom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Hi all,






We have just completed and submitted =
 our work on the 07 version of draft-reddy-mmusic-ice-happy-eyeballs.&=
nbsp;



Summary of changes:

The algorithm proposal have been moved to =
the appendix. The text have been slightly modified to make it clear that th=
is draft is all about recommendations and what values you can play with wit=
hout breaking vanilla ICE compatibility. 



This is the last version of the draft we p=
ublish as an ID. Its been fun, and we have improved our own ICE implementat=
ion. So whatever the draft will be accepted or not, it have proven to be us=
eful for at least the authors. 









.-.


P=E5l-Erik





Begin forwarded message:








Subje=
ct: 
New Version Notification=
 for draft-reddy-mmusic-ice-happy-eyeballs-07.txt





Date:=
 30 Jun 2014 20:45:53 G=
MT+2





To: <=
/b>Prashanth Patil <praspati@cisco.com>, Tirumaleswar =
Reddy <tireddy@cisco.com>,
 Tirumaleswar Reddy <tireddy@cisco.=
com>, "Paal-Erik Martinsen" <palmarti@cisco.com>, Prashanth Patil <praspati@cisco.com>, Paal-Erik Martinsen
 <palmarti@cisco.com>








A new version of I-D, draft-reddy-mmusic-ice-happy-eyeballs-07.txt

has been successfully submitted by Paal-Erik Martinsen and posted to the
IETF repository.



Name: draft-reddy-mmus=
ic-ice-happy-eyeballs

Revision: 0=
7

Title: Happy Eyeballs =
Extension for ICE

Document date: 2014-06-30

Group: Individual Subm=
ission

Pages: 8

URL:            http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ice-ha=
ppy-eyeballs-07.txt

Status:         https://da=
tatracker.ietf.org/doc/draft-reddy-mmusic-ice-happy-eyeballs/

Htmlized:       http://tools.ietf.org/ht=
ml/draft-reddy-mmusic-ice-happy-eyeballs-07

Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-mmusic-ice-happy-eyeba=
lls-07



Abstract:

  This document provides guidelines on how to make Interactive
  Connectivity Establishment (ICE) conclude faster in IPv4/IPv6 d=
ual-

  stack scenarios where broken paths exist.  The provided gu=
idelines

  are backwards compatible with the original ICE specification.








Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



The IETF Secretariat
















--_000_803DB6273D5F494D9D25E1000200A7A1ciscocom_--


From nobody Mon Jun 30 12:02:35 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8298F1A03B8 for ; Mon, 30 Jun 2014 12:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level: 
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBDWqJqCCD8H for ; Mon, 30 Jun 2014 12:02:30 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC2E1A02E9 for ; Mon, 30 Jun 2014 12:02:30 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5UJ2QQw000195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jun 2014 14:02:27 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5UJ2PrT007344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 21:02:25 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 30 Jun 2014 21:02:25 +0200
From: "DRAGE, Keith (Keith)" 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] RTP taxonomy draft review [Re: Updated MSID draft - version -06]
Thread-Index: AQHPlIxB+ZnMB3up6Ey/6F7CTMwY6ZuJ89Sg
Date: Mon, 30 Jun 2014 19:02:24 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B1FA31D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <53AC9ABC.3030107@alvestrand.no>	<53ACB1F2.4030201@cisco.com>  <53AD2E56.6090501@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1F7A84@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53AD8B5B.5040600@cisco.com> <53B1A3FD.3000507@alum.mit.edu>
In-Reply-To: <53B1A3FD.3000507@alum.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/75Go3HPaYEIK-a9zmKrYbbZZojU
Subject: Re: [MMUSIC] RTP taxonomy draft review [Re: Updated MSID draft - version -06]
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 19:02:33 -0000

As an individual, I see the taxonomy document as the document other documen=
ts will reference for the definitions they use.

i.e. the CLUE, MMUSIC and RTCWEB documents might well have paragraphs in th=
eir near the start of their documents that says:

"xx	Definitions

: see draft-ietf-avtext-taxonomy
: see draft-ietf-avtext-taxonomy

Therefore it really needs to be published as soon as we want to publish the=
 first of those other documents. That first document may well not be a CLUE=
 document.

Some of the backward type references you identify could well be examples, s=
o these will be informative (as currently given), and therefore not necessa=
ry to hold in relation to publication.

Regards

Keith

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20
> Paul Kyzivat
> Sent: 30 June 2014 18:53
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] RTP taxonomy draft review [Re: Updated=20
> MSID draft - version -06]
>=20
> I haven't fully reviewed it. But I've been checking alignment=20
> with clue usage. And one question I have is which way=20
> references should point.
>=20
> Right now the taxonomy has a section called Mapping from=20
> Existing Terms.=20
> This has come CLUE terms in it, and effectively defines them=20
> relative to the terms defined in the concepts section. Some=20
> of these definitions are different in detail from those in=20
> the CLUE documents, though for the most part the same in spirit.
>=20
> Obviously this can only be done for usages that are known=20
> before the taxonomy is finally published as an RFC. After=20
> that, documents that define their own terms relative to the=20
> taxonomy will have to publish the relationship in their own document.
>=20
> What should we do in our effort to rationalize the clue=20
> terminology with the taxonomy?
>=20
> - copy the description of the clue term from the taxonomy into the
>    clue documents, and retain it in the taxonomy.
>=20
> - remove the description of the clue term from the taxonomy and put
>    an appropriate definition into the clue docs, relating to the
>    terms defined in the concepts section of the taxonomy.
>=20
> Note that we may want to delay the publication of the=20
> taxonomy until this can be completed.
>=20
> Also, CLUE has been using the term MCU, which wasn't defined=20
> in the taxonomy, but has since been added. The taxonomy=20
> definition looks good, better than the one currently in clue.=20
> But the clue definition is specialized to clue, in that we=20
> assume the MCU is capable of supporting the CLUE features.
>=20
> ISTM that for this one the "right" answer is for clue to=20
> define a new term (e.g., CLUE-MCU) that is a specialization=20
> of the taxonomy definition of MCU. That unfortunately means=20
> we will have to update all of our documents.
>=20
> This seems to be something that will come up a lot in general=20
> - specializations of concepts that are generic in the=20
> taxonomy.  I wonder if the taxonomy should talk about this.
>=20
> 	Thanks,
> 	Paul
>=20
> On 6/27/14 11:18 AM, Flemming Andreasen wrote:
> > [updated subject]
> >
> > Per Keith's question below, has anybody in the MMUSIC group=20
> reviewed=20
> > the RTP taxonomy draft:
> >
> >=20
> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxono
> > my/
> >
> > If so, please let the group and chairs know.
> >
> > Thanks
> >
> > -- Flemming
> >
> >
> > On 6/27/14, 9:46 AM, DRAGE, Keith (Keith) wrote:
> >> The timeline for the taxonomy draft is that it is=20
> essentially ready=20
> >> for WGLC as soon as enough CLUE, RTCWEB and MMUSIC people=20
> have looked=20
> >> at it to say it is consistent with the documentation in that WG.
> >>
> >> Is anyone reviewing (or indeed has reviewed it) from the MMUSIC=20
> >> perspective, or in respect of specific documents in the MMUSIC=20
> >> working group.
> >>
> >> Keith
> >>
> >>> -----Original Message-----
> >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald=20
> >>> Alvestrand
> >>> Sent: 27 June 2014 09:42
> >>> To: Suhas Nandakumar; Flemming Andreasen
> >>> Cc: mmusic@ietf.org
> >>> Subject: Re: [MMUSIC] Updated MSID draft - version -06
> >>>
> >>> Just a quick reply to the general comments...
> >>>
> >>>
> >>> On 06/27/2014 09:56 AM, Suhas Nandakumar wrote:
> >>>
> >>>
> >>>     Hello Harald
> >>>
> >>>       Thanks for the work on this draft. Below are few thoughts=20
> >>> inline
> >>>
> >>>     * General Comment:
> >>>          + We might want to use RTP Taxonomy throughout
> >>>
> >>>
> >>> Yes. When the concepts are the same, we should. (what's=20
> the timeline=20
> >>> for the RTP taxonomy?) Can you help find terms that are not used=20
> >>> identically with Taxonomy?
> >>>
> >>>
> >>>
> >>>          + Replace MediaStream with "WebRTC MediaStream"=20
> for clarity
> >>>          + Replace MediaStreamTrack with "WebRTC=20
> MediaStreamTrack"=20
> >>> clarity
> >>>
> >>>
> >>> I would push back on that in any section where the=20
> section title or=20
> >>> the same sentence includes "WebRTC".
> >>>
> >>> So far "MediaStreamTrack" is used in the intro (WebRTC in=20
> the same=20
> >>> sentence), section 1.1 (ditto), section 1.3 (WebRTC in heading),=20
> >>> section 4 (WebRTC in heading).
> >>>
> >>> So the only usage concerned would be in Appendix B.
> >>>
> >>>
> >>>
> >>>          + m-line usage , can it be changed to m=3Dline instead
> >>>
> >>>
> >>> I don't understand this comment - it is highly unusual to=20
> use the =3D=20
> >>> sign to denote compound words.
> >>> It is possible that most occurences should be replaced=20
> with "media=20
> >>> section". Would that be more readable?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 1.1
> >>>     This document adds a new Session Description Protocol
> >>> (SDP) Grouping[RFC5888]
> >>>  >>> 88>  relation between SDP m-lines [RFC4566]
> >>>  >>> 66>  that can associate application layer identifiers with
> >>> the binding between media streams, attaching identifiers to the=20
> >>> media streams and attaching identifiers to the groupings=20
> they form.
> >>>
> >>>
> >>>     [Suhas] I am assuming we are referring to RTP Stream here
> >>>
> >>>
> >>> Since "RTP Stream" is not a defined term in=20
> >>> draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a packet=20
> >>> stream, which RFC 3550 sometimes refers to as "media stream".
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 1.2
> >>>     SDP gives a description based on m-lines. According=20
> to the model=20
> >>> used in [I-D.ietf-rtcweb-jsep]=20
> >>>  >>> etf-rtcweb-jsep> , each m-line describes exactly one media
> >>> source, and if mulitple media sources are carried in an=20
> RTP session,=20
> >>> this is signalled using BUNDLE=20
> >>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
> >>>  >>> etf-mmusic-sdp-bundle-negotiation> ; if BUNDLE is not used,
> >>> each media source is carried in its own RTP session.
> >>>
> >>>     [Suhas] suggest updating the above para as
> >>>
> >>>
> >>>     " SDP gives a description based on m-lines. According to the=20
> >>> model used in [I-D.ietf-rtcweb-jsep]=20
> >>>  >>> etf-rtcweb-jsep> , each m-line describes exactly one media
> >>> source (WebRTC MediaStreamTrack), and if multiple media=20
> sources are=20
> >>> carried in an RTP session, this is signaled using BUNDLE=20
> >>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
> >>>  >>> etf-mmusic-sdp-bundle-negotiation>  mechanism ; if BUNDLE is
> >>> not used, each media source is carried in its own RTP session."
> >>>
> >>>
> >>>
> >>> Section 1.2 is not WebRTC specific, so should not use=20
> WebRTC terms.=20
> >>> The model used in JSEP doesn't have an independent formulation,=20
> >>> unfortunately, but the main thrust of the argument for=20
> adopting it=20
> >>> is that this is the model used by a significant portion=20
> of existing=20
> >>> applications, so adopting that model for JSEP enhances=20
> >>> interoperability.
> >>>
> >>> "Media source" is a defined term in -taxonomy-.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 1.2 Para 4
> >>>     [Suhas] Para 3 doesn't force the need for a new=20
> mechanism and it=20
> >>> is probably a good idea to add more clarity in Para4 to=20
> clarify the=20
> >>> need as below"
> >>>
> >>>
> >>>     "The SDP grouping framework [RFC5888]
> >>>  >>> 88>  can be used to group m-lines. When an m-line describes
> >>> one and only one RTP Packet stream, it is possible to=20
> associate RTP=20
> >>> media streams across different m-lines.
> >>> However, cases such as when a m-line has multiple RTP Packets=20
> >>> streams or the need for an application to specify=20
> application-level=20
> >>> information about the association between the m-line and=20
> the group,=20
> >>> the SDP grouping framework cannot be used for this purpose"
> >>>
> >>> This seems good. I'll adopt and/or adapt.
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 1.3 Para 3
> >>>     WebRTC defines a mapping (documented in=20
> [I-D.ietf-rtcweb-jsep]=20
> >>>  >>> etf-rtcweb-jsep> ) where one SDP m-line is used to describe
> >>> each MediaStreamTrack, and that the BUNDLE mechanism=20
> >>> [I-D.ietf-mmusic-sdp-bundle-negotiation]
> >>>  >>> etf-mmusic-sdp-bundle-negotiation>  is used to group
> >>> MediaStreamTracks into RTP sessions.
> >>>
> >>>     [Suhas] we might want to say "MediaStreamTracks into a RTP=20
> >>> Session" instead of "MediaStreamTracks into RTP Sessions"
> >>>
> >>>
> >>> No, because in the case of less than total Bundling,=20
> >>> MediaStreamTracks will be grouped into multiple RTP=20
> sessions, not a=20
> >>> single one.
> >>>
> >>>
> >>>
> >>>
> >>>     *Section 1.3 Para 3
> >>>     Therefore, the need is to specify the ID of a=20
> MediaStreamTrack=20
> >>> and its associated MediaStream for each m-line, which can be=20
> >>> accomplished with a media-level SDP attribute.
> >>>     [Suhas] Can we change it to
> >>>
> >>>     "
> >>>      Therefore, the need is to uniquely identify the=20
> >>> MediaStreamTrack and its MediaStream for each m-line via a=20
> >>> media-level SDP attribute. This would enable establishing the=20
> >>> relationship between RTP Packet Streams that correspond to same=20
> >>> WebRTC MediaStream across m=3D lines".
> >>>     "
> >>>
> >>>
> >>> Modulo "would" -> "will" ("would" is the wishful-thinking=20
> tense of=20
> >>> the word, which I like to avoid - can't remember the grammatical=20
> >>> name of the construct at the moment).
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 2 Title
> >>>      [Suhas] Msid is not defined. Also suggest common convention.=20
> >>> (MSID vs Msid) throughout
> >>>
> >>>
> >>> The section is the definition of MSID, I'm not sure how to define=20
> >>> the term before defining it.
> >>>
> >>> I'd like to have the convention be "msid" (all lower=20
> case), but the=20
> >>> RFC Editor likes capitals in section titles. I'll=20
> lowercase it and=20
> >>> see if it survives. (I lowercased all occurences elsewhere in a=20
> >>> previous pass)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 3
> >>>
> >>>     The ABNF of msid-semantic is:
> >>>
> >>>       attribute =3D/ msid-semantic-attr
> >>>       msid-semantic-attr =3D "msid-semantic:" semantic=20
> identifier-list
> >>>       semantic =3D token ; see RFC 4566
> >>>       identifier-list =3D (" " identifier)* / " *"
> >>>
> >>>     [Suhas] The identifier-list MUST be msid not generic=20
> identifier.=20
> >>> Since this session level grouping applies only to msid or=20
> should it=20
> >>> apply
> >>>
> >>>
> >>> There is no "msid" ABNF construct. The "msid-attr" in section
> >>> 2 is defined in terms of identifier.
> >>> So I can't parse this request.
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>     [Suhas] Shouldn't we make appData MUST for WMS=20
> semantics. Since=20
> >>> having a MediaStream with no tracks into makes much=20
> sense. also the=20
> >>> ABNF for appdata is optional in Section 2.
> >>>
> >>>
> >>> It makes sense to say that it MUST be given. Will do.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>     [Suhas] When the m=3D section is updated to inactive, I am=20
> >>> thinking we should signal the MedaStreamTrack as ended, is that a=20
> >>> right assumption ?
> >>>
> >>>
> >>> No, because "inactive" can be resumed.
> >>> "Ended" is a final state for a MediaStreamTrack.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>        In addition to signaling that the track is closed when its=20
> >>> msid attribute disappears from the SDP, the track will also be=20
> >>> signaled as being closed when all associated SSRCs have=20
> disappeared=20
> >>> by the rules of
> >>>     [Suhas] Probably a formatting glitch. The above sentence is=20
> >>> incomplete
> >>>
> >>>
> >>> In my copy, it continues with "[RFC3550] section 6.3.4=20
> (BYE packet=20
> >>> received) and 6.3.5 (timeout), and when the corresponding media=20
> >>> section is disabled by setting the port number to zero.".=20
> What does=20
> >>> it say in your copy?
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>     The association between SSRCs and m-lines is specified in=20
> >>> [I-D.ietf-rtcweb-jsep]=20
> >>>  >>> etf-rtcweb-jsep> .
> >>>
> >>>     [Suhas] Why is this needed here ?
> >>>
> >>>
> >>>
> >>> It's not. Will remove.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.1 Title
> >>>     [Suhas] Tracks undefined, suggest we change it to WebRTC=20
> >>> MediaStreamTracks or something like that.
> >>>
> >>>
> >>> I think it would be correct to say "non-signalled packet streams".
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.1 Para 1
> >>>     Non-WebRTC entities will not send msid
> >>>
> >>>     [Suhas] Suggest changing will not to may not .. since msid=20
> >>> itself is generic mechanism but WMS is webrtc specific mechanism
> >>>
> >>>
> >>> I'll change to "will not send msid with the WMS semantic".
> >>> This is a leftover from before msid-semantic was introduced.
> >>> Good catch!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.1
> >>>     It follows from the above that media stream tracks in the=20
> >>> "default" media stream cannot be closed by removing the msid=20
> >>> attribute; the application must instead signal these as=20
> closed when=20
> >>> the SSRC disappears according to the rules of RFC 3550=20
> section 6.3.4=20
> >>> and 6.3.5 or by disabling the m-line by setting its port to zero.
> >>>
> >>>     [ Suhas ] "default" media stream and tracks aren't=20
> defined and=20
> >>> we need some context to explain this.
> >>>
> >>>
> >>> This should be "tracks constructed by the above rule when no=20
> >>> msid-semantic:WMS is present".
> >>> Good catch.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.2.1
> >>>      How do we want to support adding  a track that is=20
> not part of a=20
> >>> Media Stream ? Should there be a msid line at all ?
> >>>
> >>>
> >>> This is not supported. Should it be?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4.2.1
> >>>      What should happen if the modified SDP has same msid but a=20
> >>> different trackId in the appData. Should we trigger ended=20
> on the old=20
> >>> track and created on the new track ?
> >>>
> >>>
> >>> Yes.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Is it worthwhile considering the possibility of sending the=20
> >>> TrackId in the RTP Layer (as header extension) since it can=20
> >>> identifies the Media Source end to end.
> >>>
> >>>
> >>> This is being considered for BUNDLE (appid). I don't want=20
> to try to=20
> >>> do the same thing here, for fear of having duelling=20
> specifications.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     *Section 4 - Offer/Answer Procedures
> >>>     We might want to add some text to explain the following
> >>>      - An Offer has WMS semantic include, Answerer=20
> doesn't include=20
> >>> the semantic in response --> No WMS used for the session
> >>>      - Either Offer/Answer has a semantic which isn't=20
> understood by=20
> >>> the end-points --> No MSID mechanism is used and m=3D lines are=20
> >>> rejected
> >>>
> >>>
> >>>
> >>> I don't see a reason for either of these things. Continuing to=20
> >>> announce the data does no harm.
> >>> I can add "MUST ignore a=3Dmsid lines where the identifier=20
> is listed=20
> >>> in a msid-semantic: header that the implementation does not=20
> >>> support".
> >>>
> >>>
> >>>
> >>>
> >>>     Section 4.1 Says
> >>>     "If a WebRTC entity sends a description, it MUST include the=20
> >>> msid-semantic:WMS attribute, even if no media streams are sent."
> >>>     and Section 3 says
> >>>     "This attribute MUST be present if "a=3Dmsid" is used."
> >>>
> >>>
> >>>     So if i add both, it is not clear in the cases of=20
> >>> recvonly/inactive streams in the Offer, if we should=20
> include a=3Dmsid=20
> >>> line If i wanted to include a empty WMS semantic. So=20
> basically what=20
> >>> mandates which is not very clear here ?
> >>>
> >>>
> >>> 4.1 is about WebRTC implementations. These MUST send=20
> >>> msid-semantic:WMS, whether or not they have any a=3Dmsid in the SDP.
> >>>
> >>> Non-WebRTC implementations that don't send a=3Dmsid don't=20
> have to send=20
> >>> msid-semantic:.
> >>>
> >>> Non-WebRTC implementations that send a=3Dmsid MUST send
> >>> msid-semantic: so that it's possible to figure out what=20
> they mean by=20
> >>> their a=3Dmsid lines.
> >>>
> >>> Non-WebRTC implementations that use a different
> >>> msid-semantic: must follow the rules for that semantic.
> >>>
> >>> I don't see what's not clear here, but would appreciate=20
> suggestions=20
> >>> for more text to make it clearer.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 4.2.2
> >>>     - We need a line to parse the Semantics
> >>>
> >>>
> >>> Good catch. It needs to verify that the msid-semantic says WMS.=20
> >>> (Since all of section 4.2 is about WMS, this is the only=20
> one we need=20
> >>> to specify rules for.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Please let me know If i can help with aligning the draft with=20
> >>> Taxonomy and so on..
> >>>
> >>>
> >>> Help appreciated!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Thanks
> >>>     Suhas Nandakumar
> >>>
> >>>     On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen=20
> >>>  wrote:
> >>>
> >>>
> >>>         Thanks Harald
> >>>
> >>>         It would be great if people could please take a=20
> look at the=20
> >>> updated draft and see if they have any comments; we would like to=20
> >>> get WGLC issued soon.
> >>>
> >>>         Thanks
> >>>
> >>>         -- Flemming (MMUSIC co-chair)
> >>>
> >>>
> >>>
> >>>         On 6/26/14, 6:12 PM, Harald Alvestrand wrote:
> >>>
> >>>
> >>>             Flemming kindly pointed out to me that I had not=20
> >>> actively notified the list about my new version of the=20
> -msid draft=20
> >>> that was published on June 6.
> >>>
> >>>             Here's the changelog - the "detailed=20
> procedures" section=20
> >>> has the "initial offer / initial answer"
> >>> and so on format that was recommended by the chairs, so=20
> it may be of=20
> >>> interest to this group.
> >>>
> >>>             Harald
> >>>
> >>>             C.12.  Changes from -05 to -06
> >>>
> >>>                Addressed issues found in Fleming=20
> Andreassen's review
> >>>
> >>>                Referenced JSEP rather than unified-plan for the=20
> >>> M-line mapping model
> >>>
> >>>                Relaxed MSID definition to allow "token-char" in=20
> >>> values rather than
> >>>                a-z 0-9 hyphen; tightened ABNF by adding length=20
> >>> description to it.
> >>>
> >>>                Deleted discussion of abandoned=20
> alternatives, as part=20
> >>> of preparing
> >>>                for publication.
> >>>
> >>>                Added a "detailed procedures"
> >>> section to the WMS semantics
> >>>                description.
> >>>
> >>>                Added IANA registration of the "msid-semantic"=20
> >>> attribute.
> >>>
> >>>             _______________________________________________
> >>>             mmusic mailing list
> >>>             mmusic@ietf.org
> >>>             https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >>>
> >>>
> >>>
> >>>         _______________________________________________
> >>>         mmusic mailing list
> >>>         mmusic@ietf.org
> >>>         https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >>>
> >>>
> >>>
> >>> .
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> =


From nobody Mon Jun 30 23:35:50 2014
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648E21A0AD3 for ; Mon, 30 Jun 2014 23:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1-7wojn4B2F for ; Mon, 30 Jun 2014 23:35:45 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3661A02E2 for ; Mon, 30 Jun 2014 23:35:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DE9127C39E9 for ; Tue,  1 Jul 2014 08:35:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr1YLQhikLKs for ; Tue,  1 Jul 2014 08:35:43 +0200 (CEST)
Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 30D4A7C39CB for ; Tue,  1 Jul 2014 08:35:43 +0200 (CEST)
Message-ID: <53B256BE.1060104@alvestrand.no>
Date: Tue, 01 Jul 2014 08:35:42 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <53AC9ABC.3030107@alvestrand.no> <53ADA38E.1040009@alum.mit.edu> <53AE6E1A.3030204@alvestrand.no> <53B1A1DD.8080503@cisco.com> <53B1A638.8000306@alvestrand.no> <53B1A9FC.20402@alum.mit.edu>
In-Reply-To: <53B1A9FC.20402@alum.mit.edu>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9hbLZrkW6HFYTHCuUiHe2sHzXVc
Subject: Re: [MMUSIC] Updated MSID draft - version -06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Jul 2014 06:35:49 -0000

On 06/30/2014 08:18 PM, Paul Kyzivat wrote:
> On 6/30/14 2:02 PM, Harald Alvestrand wrote:
>
>>>>> The section refers to "WebRTC entity", but AFAIK there is no
>>>>> definition of this. I presume you don't mean to restrict this to
>>>>> browsers. IIUC you probably mean any entity that supports
>>>>> msid-semantic:WMS. Could you clarify the text?
>>>> With the split in -overview recently into "WebRTC browsers" and
>>>> "WebRTC
>>>> devices", this is actually limited to WebRTC browsers, since the
>>>> SDP in
>>>> question only appears on the Javscript API, and implementing the
>>>> Javascript API is only a requirement for browsers....
>>> Are you suggesting any changes here (seems to me we shouldn't limit
>>> the mechanism to just browsers, which I think was Paul's point as
>>> well) ?
>>
>> The requirement (the "MUST implement") is on WebRTC browsers, not WebRTC
>> devices.
>
> I don't understand. Suppose I have a browser talking to a non-browser.
> And the non-browser end decides to add an m-line that represents
> another m-line. To be specific, suppose it decides to add video where
> previously there was only audio. And the video "goes with" the audio.
>
> Doesn't it need to use this stuff to indicate the relationship?

OK, I was off on the wrong tangent.

The actual text concerned is this one:

4.1.  Handling of non-signalled tracks

   Non-WebRTC entities will not send msid.  This means that there will
   be some incoming RTP packets that the recipient has no predefined
   MediaStream id value for.

This is a subsection of

4.  Applying Msid to WebRTC MediaStreams

What it SHOULD be saying is

  "Entities that do not implement the WMS semantic will not send
"msid-semantic:WMS".

It's kind of an oxymoron.

What WebRTC entities do and do not do is actually irrelevant to this
spec; it is the task of a completely different document (JSEP) to say
that WebRTC browsers MUST implemenet this spec.

I'll make the correction.