From nobody Thu May 1 15:11: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 E40EB1A0958 for ; Thu, 1 May 2014 15:11:39 -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_HELO_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 jDmxKaHWi1bE for ; Thu, 1 May 2014 15:11:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8391A066A for ; Thu, 1 May 2014 15:11:31 -0700 (PDT) Received: from BY2PR02MB364.namprd02.prod.outlook.com (10.141.140.152) by BY2PR02MB362.namprd02.prod.outlook.com (10.141.140.143) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 22:11:28 +0000 Received: from BY2PR02MB364.namprd02.prod.outlook.com ([10.141.140.152]) by BY2PR02MB364.namprd02.prod.outlook.com ([10.141.140.152]) with mapi id 15.00.0934.000; Thu, 1 May 2014 22:11:28 +0000 From: Michael Thornburgh To: "mmusic@ietf.org" Thread-Topic: draft-thornburgh-rtmfp-flash notice and feedback request Thread-Index: Ac9lh+8qRMgfmQImQsqCwGt4lVPrxA== Date: Thu, 1 May 2014 22:11:27 +0000 Message-ID: <62cb796a473c4972bcdf8a0e1da7d283@BY2PR02MB364.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.19.4] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(377424004)(77096999)(54356999)(50986999)(83072002)(85852003)(81342001)(20776003)(92566001)(86362001)(80022001)(81542001)(4396001)(76482001)(74502001)(74662001)(15975445006)(33646001)(74316001)(31966008)(83322001)(19580395003)(80976001)(79102001)(76576001)(99396002)(101416001)(15202345003)(66066001)(99286001)(77982001)(87936001)(2656002)(46102001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB362; H:BY2PR02MB364.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=mthornbu@adobe.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yQbowLr1j-l0gBOlA7ze5AuPVN8 Subject: [MMUSIC] draft-thornburgh-rtmfp-flash notice and feedback request 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, 01 May 2014 22:11:40 -0000 hi MMUSIC folks. just over a year ago, i notified this working group of the existence of an = I-D describing Adobe's RTMFP, a general purpose endpoint-to-endpoint transp= ort protocol designed for real-time and P2P communication. it is deployed = widely in the Internet as part of Flash and other software. in particular,= it is used to transport live, low-latency audio, video, and data P2P in Fl= ash. it has since been published as RFC 7016. recently i submitted a new companion I-D, "Adobe's RTMFP Profile for Flash = Communication", that describes how RTMFP (the generic protocol) is used to = transport the video, audio, and data messages of real-time and P2P communic= ations in Flash, including the concrete RFC 7016 "Cryptography Profile" for= Flash. this new specification illustrates a practical application of RTMF= P, which can also help folks understand how to apply RTMFP's capabilities t= o use cases other than Flash communication. i realize this material isn't in MMUSIC's charter. however, this material = pertains directly to live multimedia communication practiced in the Interne= t today, and therefore may be relevant, or of interest, to some participant= s of this working group. we will eventually be submitting this specification to the Independent Subm= ission Editorial Board for publication as an Informational RFC. to that en= d i am soliciting feedback, comments, and reviews of this I-D to help us im= prove its quality, readability, implementability, etc. --- Name: draft-thornburgh-rtmfp-flash Revision: 00 Title: Adobe's RTMFP Profile for Flash Communication Document date: 2014-04-14 Group: Individual Submission Pages: 45 URL: http://www.ietf.org/internet-drafts/draft-thornburgh-rtmfp-= flash-00.txt Status: https://datatracker.ietf.org/doc/draft-thornburgh-rtmfp-fla= sh/ Htmlized: http://tools.ietf.org/html/draft-thornburgh-rtmfp-flash-00 IPR: https://datatracker.ietf.org/ipr/2345/ Abstract: This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication. --- thank you. -michael thornburgh From nobody Sat May 3 06:35: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 755871A00BF for ; Sat, 3 May 2014 06:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.609 X-Spam-Level: X-Spam-Status: No, score=-13.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 reN0_sxuV4j7 for ; Sat, 3 May 2014 06:35:24 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1187F1A00B6 for ; Sat, 3 May 2014 06:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2018; q=dns/txt; s=iport; t=1399124121; x=1400333721; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=gT7mdm8RUKjSi2gUz19q2JYXwvzzslJ91UszBs6BKCc=; b=fHgIW6HL0ifuA0CG3TYJwM52NWHNoJJsgVi4i+tFNmYQeoykdGWms9Hs aFwuAuMxRCS/W9bVHkZUTa8Ke84j1MPae7XznMoGC8KGVW71/56ZUXC4Z 832N4bnwZY4Hin+mNNngBKVHAmHCBoV01XFS09TWyqKxhjPmPVri2w7iI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYMANXvZFOrRDoJ/2dsb2JhbABZKIJeT6sYAQEDAQUBklGGaFGBDxZ0giUBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGAQwGAgEBiDwOyW4TBIVWiCRfhD8BA5k0knSDUCGBMA X-IronPort-AV: E=Sophos;i="4.97,977,1389744000"; d="scan'208";a="108522923" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 03 May 2014 13:35:21 +0000 Received: from FANDREAS-M-201A.CISCO.COM (bxb-fandreas-8816.cisco.com [10.98.149.199]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s43DZKSY005924; Sat, 3 May 2014 13:35:20 GMT Message-ID: <5364566D.5010601@cisco.com> Date: Fri, 02 May 2014 22:37:33 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , mmusic References: <531875E3.9000605@alvestrand.no> <53187758.1080403@cisco.com> In-Reply-To: <53187758.1080403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/i6O4XyCWFC2NwYD_nSxDbUKoBCM Subject: Re: [MMUSIC] Updated MSID draft 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, 03 May 2014 13:35:25 -0000 Hi Harald I have taken a closer look at msid-05 and have a number of comments. I will list the major ones and/or what might require list discussion here and send you a bunch of more detailed ones in an annotated version off-line: 1) There are some grammar inconsistencies between the way you use token and (some) of the text you have. In general, it seems the length should be limited and the set of characters you want to allow are less than what token allows for. 2) Offer/Answer procedures are lacking. We need to have an O/A section with subsections as per RFC 3264 (for unicast) to better specify the overall behavior here (Generating the Initial Offer, Generating the Answer, Offerer Processing of the Answer, Modifying the Session) 3) There is some ambiguity as to what constitues an msid value and more specifically when it includes both the MediaStream identifier and the MediaStreamTrack and when (if ?) it doesn't. 4) Unified-plan is being referenced in a normative manner (but is listed as an informative reference). Since unified-plan is not expected to go to RFC, having a normative reference to it is problematic. Thanks -- Flemming On 3/6/14, 8:25 AM, Flemming Andreasen wrote: > I think the draft needs a bit more work in a few places (largely > editorial and more text on some of the procedures). I'll sign up to do > a pre-WGLC individual review to get you some more tangible and > constructive feedback on that. > > Thanks > > -- Flemming > > > On 3/6/14, 8:19 AM, Harald Alvestrand wrote: >> I have uploaded an updated msid draft, without the msid-control: >> section. >> >> As I said in the WG meeting, I think this is now uncontroversial, and >> should be ready for WG Last Call. >> >> I request that the WG chairs consider whether they agree with this >> opinion. >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sun May 4 12:26: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 9DA891A01BE for ; Sun, 4 May 2014 12:26:52 -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 EuFz5nki-Ycm for ; Sun, 4 May 2014 12:26:49 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D81DA1A01A0 for ; Sun, 4 May 2014 12:26:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9D31E7C5245; Sun, 4 May 2014 21:26:31 +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 1CzjDbf2AWx1; Sun, 4 May 2014 21:26:30 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4895C7C519B; Sun, 4 May 2014 21:26:30 +0200 (CEST) Message-ID: <53669466.4020309@alvestrand.no> Date: Sun, 04 May 2014 21:26:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Flemming Andreasen , mmusic References: <531875E3.9000605@alvestrand.no> <53187758.1080403@cisco.com> <5364566D.5010601@cisco.com> In-Reply-To: <5364566D.5010601@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/qRWjmjfU-rN6W3hRAoVtGXFWltQ Subject: Re: [MMUSIC] Updated MSID draft 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, 04 May 2014 19:26:53 -0000 On 05/03/2014 04:37 AM, Flemming Andreasen wrote: > Hi Harald > > I have taken a closer look at msid-05 and have a number of comments. I > will list the major ones and/or what might require list discussion > here and send you a bunch of more detailed ones in an annotated > version off-line: > > 1) There are some grammar inconsistencies between the way you use > token and (some) of the text you have. In general, it seems the length > should be limited and the set of characters you want to allow are less > than what token allows for. > > 2) Offer/Answer procedures are lacking. We need to have an O/A section > with subsections as per RFC 3264 (for unicast) to better specify the > overall behavior here (Generating the Initial Offer, Generating the > Answer, Offerer Processing of the Answer, Modifying the Session) Hm. But MSID isn't an offer/answer field. It's an unilateral declaration, and refers to no information coming from the other side. Does it make sense to follow the offer/answer section format when the answer doesn't depend on the offer? > > 3) There is some ambiguity as to what constitues an msid value and > more specifically when it includes both the MediaStream identifier and > the MediaStreamTrack and when (if ?) it doesn't. Hm. Must make this clearer. The generic format has MST-identifier optional, and the WMF usage has MST-identifier mandatory. > > 4) Unified-plan is being referenced in a normative manner (but is > listed as an informative reference). Since unified-plan is not > expected to go to RFC, having a normative reference to it is problematic. Have to move this pointer to JSEP. I think JSEP has the necessary targets now. > > Thanks > > -- Flemming > > > > On 3/6/14, 8:25 AM, Flemming Andreasen wrote: >> I think the draft needs a bit more work in a few places (largely >> editorial and more text on some of the procedures). I'll sign up to >> do a pre-WGLC individual review to get you some more tangible and >> constructive feedback on that. >> >> Thanks >> >> -- Flemming >> >> >> On 3/6/14, 8:19 AM, Harald Alvestrand wrote: >>> I have uploaded an updated msid draft, without the msid-control: >>> section. >>> >>> As I said in the WG meeting, I think this is now uncontroversial, and >>> should be ready for WG Last Call. >>> >>> I request that the WG chairs consider whether they agree with this >>> opinion. >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > -- Surveillance is pervasive. Go Dark. From nobody Mon May 5 10:33:36 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 5F1FC1A03EC; Mon, 5 May 2014 10:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 vVpeD_olnfeP; Mon, 5 May 2014 10:33:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 89EF91A0400; Mon, 5 May 2014 10:33:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8FC2F18000D; Mon, 5 May 2014 10:32:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140505173259.8FC2F18000D@rfc-editor.org> Date: Mon, 5 May 2014 10:32:59 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MdBDE-JZ6eykBkuYv0lSPxYTJxY Cc: drafts-update-ref@iana.org, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 7195 on Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) 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, 05 May 2014 17:33:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7195 Title: Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) Author: M. Garcia-Martin, S. Veikkolainen Status: Standards Track Stream: IETF Date: May 2014 Mailbox: miguel.a.garcia@ericsson.com, simo.veikkolainen@nokia.com Pages: 39 Characters: 92699 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-sdp-cs-23.txt URL: http://www.rfc-editor.org/rfc/rfc7195.txt This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). This document is a product of the Multiparty Multimedia Session Control Working 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 suggestions 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 From nobody Tue May 6 08:15:18 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 4A3BA1A0835 for ; Tue, 6 May 2014 08:15:16 -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 Q0tsBZ4OkTuJ for ; Tue, 6 May 2014 08:15:15 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EE6921A0357 for ; Tue, 6 May 2014 08:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3007; q=dns/txt; s=iport; t=1399389311; x=1400598911; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0wecm7h+R7NRpZPGuNaz5T811V+x/rett9a+4diIzvU=; b=B8aTFH9A6peiNjGCCtAedbpuJOKhVWILJ65TqcgR8QjCGIuc2PCEjMuA iT1AucgiXdenMW2p7h2lC0WS8H3lRdTFh9P5ueXeBmee66fi7nyml9X8u php1ZMkUijtVIgD6uWhXIlLe3K5VUYYd1siW1u+1zWIW/1fXoZ7RFYEGt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQJABb7aFOrRDoJ/2dsb2JhbABZgwZPqx0BAQEBAQEFAZJShmhRgR8WdIIlAQEBAwEBAQE1NgoRCxgJFg8JAwIBAgEVMAYBDAYCAQGINQcOzgITBIVWiCRfhD8BA5k3knuDUCGBMA X-IronPort-AV: E=Sophos;i="4.97,997,1389744000"; d="scan'208";a="112006253" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 06 May 2014 15:15:10 +0000 Received: from FANDREAS-M-201A.CISCO.COM (bxb-fandreas-8816.cisco.com [10.98.149.199]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s46FF99L009430; Tue, 6 May 2014 15:15:09 GMT Message-ID: <5368FC80.6050403@cisco.com> Date: Tue, 06 May 2014 11:15:12 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , mmusic References: <531875E3.9000605@alvestrand.no> <53187758.1080403@cisco.com> <5364566D.5010601@cisco.com> <53669466.4020309@alvestrand.no> In-Reply-To: <53669466.4020309@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/Pdn_9c3-PuOI9c4ehgUSXpM_zxA Subject: Re: [MMUSIC] Updated MSID draft 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, 06 May 2014 15:15:16 -0000 On 5/4/14, 3:26 PM, Harald Alvestrand wrote: > On 05/03/2014 04:37 AM, Flemming Andreasen wrote: >> Hi Harald >> >> I have taken a closer look at msid-05 and have a number of comments. I >> will list the major ones and/or what might require list discussion >> here and send you a bunch of more detailed ones in an annotated >> version off-line: >> >> 1) There are some grammar inconsistencies between the way you use >> token and (some) of the text you have. In general, it seems the length >> should be limited and the set of characters you want to allow are less >> than what token allows for. >> >> 2) Offer/Answer procedures are lacking. We need to have an O/A section >> with subsections as per RFC 3264 (for unicast) to better specify the >> overall behavior here (Generating the Initial Offer, Generating the >> Answer, Offerer Processing of the Answer, Modifying the Session) > Hm. But MSID isn't an offer/answer field. It's an unilateral > declaration, and refers to no information coming from the other side. > > Does it make sense to follow the offer/answer section format when the > answer doesn't depend on the offer? It does. Even declarative SDP parameters have procedures that must be followed by the offerer and the answerer and we want those called out clearly. > >> 3) There is some ambiguity as to what constitues an msid value and >> more specifically when it includes both the MediaStream identifier and >> the MediaStreamTrack and when (if ?) it doesn't. > Hm. Must make this clearer. The generic format has MST-identifier > optional, and the WMF usage has MST-identifier mandatory. > The confusion is more around some of the text in the document which is not always clear on this (to me at least). >> 4) Unified-plan is being referenced in a normative manner (but is >> listed as an informative reference). Since unified-plan is not >> expected to go to RFC, having a normative reference to it is problematic. > Have to move this pointer to JSEP. I think JSEP has the necessary > targets now. Ok. Thanks -- Flemming >> Thanks >> >> -- Flemming >> >> >> >> On 3/6/14, 8:25 AM, Flemming Andreasen wrote: >>> I think the draft needs a bit more work in a few places (largely >>> editorial and more text on some of the procedures). I'll sign up to >>> do a pre-WGLC individual review to get you some more tangible and >>> constructive feedback on that. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> On 3/6/14, 8:19 AM, Harald Alvestrand wrote: >>>> I have uploaded an updated msid draft, without the msid-control: >>>> section. >>>> >>>> As I said in the WG meeting, I think this is now uncontroversial, and >>>> should be ready for WG Last Call. >>>> >>>> I request that the WG chairs consider whether they agree with this >>>> opinion. >>>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> > From nobody Tue May 6 09:34: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 700951A0252; Tue, 6 May 2014 09:34:04 -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 0benX7ol68JO; Tue, 6 May 2014 09:34:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A91511A019C; Tue, 6 May 2014 09:33:58 -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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140506163358.30964.71772.idtracker@ietfa.amsl.com> Date: Tue, 06 May 2014 09:33:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IkyQKRTGXkNklnQeyv3c_pBqqZs Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-05.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, 06 May 2014 16:34:04 -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-05.txt Pages : 15 Date : 2014-05-06 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 this 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-05 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 May 6 09:36: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 9A9F81A018F for ; Tue, 6 May 2014 09:36:30 -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 ZgZsf0yNdeBl for ; Tue, 6 May 2014 09:36:28 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id C22961A017E for ; Tue, 6 May 2014 09:36:27 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so3197112wib.2 for ; Tue, 06 May 2014 09:36:23 -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=qIrra98oBVvWvGQIa0uSIVW2Joc65v7pDen8jOEPpM0=; b=MzBkUJ0RlwBPjLFJ/YtVe02sm4fBuTdEhwjLDykKHD2/ZBFkPdAIwoudDx4pjlJ/U3 SOPQyQt7qwoRhXXQI3/CanUUpv/bZ6PbyEHlDfQN9dgbW0vgeeRDQqoju4Oq1Zk+mBJ8 hZZ9jYYVvP9y9yxm9pmK6ID6O/Iaw1ulAPE+kG2FeM0KpayhAtrJCRCszN6QUBnI52O6 4dqehV8aNXEyRCIns1yjrWfyxNStq2aS3d3DGMaMnPy10yPjH9O1xRW3T0RqcIY3GtYf CB0ygtg9inAcUb2YogHzautVVY89h/HQ15vW08oJd7JcGKdNZr5ss6zKXX+FBQ0Gq0gP 4iNg== X-Gm-Message-State: ALoCoQkV4aatQ/t1H73ZDhkqv7DrGlsrjvh8nAia0x8ss54h2zCXG2kzXCZgVe+oPz8tDQp3miS6 X-Received: by 10.194.171.198 with SMTP id aw6mr34045500wjc.23.1399394183346; Tue, 06 May 2014 09:36:23 -0700 (PDT) Received: from camionet.local (neu67-4-88-160-65-79.fbx.proxad.net. [88.160.65.79]) by mx.google.com with ESMTPSA id ej7sm25704482wib.9.2014.05.06.09.36.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 09:36:21 -0700 (PDT) Message-ID: <53690F83.1080007@jitsi.org> Date: Tue, 06 May 2014 18:36:19 +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: Alissa Cooper , Kevin Gross References: <7CB15B3C-4A35-4397-8029-1396722EB2CC@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f3Z7Hsx53NLdHcGU6SgrKyUOgwo Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic , Dan Wing Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 06 May 2014 16:36:30 -0000 Hey Alissa, On 18.04.14, 23:06, Alissa Cooper wrote: > On 4/15/14, 4:29 PM, "Kevin Gross" > wrote: > > As fresh eyes on this, I'm having trouble understanding what NEW is > trying to say. Seems like the union of Internet and controlled > environments is everything. How about just saying: > > Due to the security issues presented in Section 5, the latching > mechanism > is not recommended unless all security considerations are taken into > account and solved. > > This is basically the same as what the text currently says, so I think > it’s better to just leave the text as-is and close out this discussion. OK. > Also, if you're going to change this in section 1, you'll also want > to change the treatment of the same subject in the last paragraph of > the abstract. Done. > Also, although there's a brief definition of "latching" in the > abstract, there's no mention of "latching" in section 1 until the > paragraph under discussion. It would be helpful to add better > context for "latching" in section 1. Done. > Seems like a reasonable suggestion. Could the authors make a run at that > and publish a rev that includes the other edits from my AD review? Done: http://tools.ietf.org/html/draft-ietf-mmusic-latching-05 Thanks for all the feedback! Emil > Thanks, > Alissa > > > Kevin Gross - AVA Networks > > > On Tue, Apr 15, 2014 at 5:03 PM, Alissa Cooper > wrote: > > I’d like to close out this thread. Are folks on board with this > proposed > change to Section 1? > > OLD: > Due to the security issues presented in Section 5, the latching > mechanism > is considered inappropriate for general use on the Internet > unless all > security considerations are taken into account and solved. > > NEW: > Due to the security issues presented in Section 5, the latching > mechanism > is considered inappropriate for general use on the Internet, and in > controlled environments unless all security considerations are > taken into > account and solved. > > > Thanks, > Alissa > > On 4/3/14, 11:19 AM, "Alissa Cooper" > wrote: > > >On 4/3/14 10:39 AM, "Dan Wing" > wrote: > > > >> > >>On Apr 3, 2014, at 10:28 AM, Alissa Cooper > wrote: > >> > >>> Hi Dan, > >>> > >>> On 4/1/14 11:42 AM, "Dan Wing" > wrote: > >>>> > >>>>>> The draft suggests use of SRTP for authenticating media which does > >>>>>> resolve the security issues (from a privacy/confidentiality > >>>>>> perspective). > >>>>>> > >>>>> > >>>>> I was more concerned with the DoS aspect. > > > >In response to Emil's note above about the SRTP text resolving the > >security issues "from a privacy/confidentiality perspective," all I was > >saying was that my initial question was prompted not because I was > >concerned about a breach of confidentiality, but about the ability to > >perform a DoS attack even when SRTP is in use. I think the text in Section > >5 that describes this is ok though. > > > >>>> > >>>> The DoS aspect of authenticating incoming SRTP packets to the SBC? > >>> > >>> The DoS aspect that is described in the paragraph Emil quoted below. > >>> > >>>> > >>>> > >>>>> > >>>>>> That's part of section 5: > >>>>>> > >>>>>> Naturally, SRTP [RFC3711] would help mitigate such threats and > >>>>>>should > >>>>>> be used independently of HNT. 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. > >>>>>> > >> > >>Sorry, I read it again and I'm still not clear on the concern. Could you > >>restate or rephrase. > >> > >> > >>> > >>>>> I think something like the following might capture the > >>>>> situation better: > >>>>> > >>>>> OLD: > >>>>> Due to the security issues presented in Section 5, the latching > >>>>> mechanism > >>>>> is considered inappropriate for general use on the Internet unless > >>>>>all > >>>>> security considerations are taken into account and solved. > >>>>> > >>>>> > >>>>> NEW: > >>>>> Due to the security issues presented in Section 5, the latching > >>>>> mechanism > >>>>> is considered inappropriate for general use on the Internet, and in > >>>>> controlled environments unless all security considerations are taken > >>>>> into > >>>>> account and solved. > >>>> > >>>> "General use on the Internet" and "in controlled environments" are > >>>>100% > >>>> of all networks, so perhaps simplifying to: > >>>> > >>>> NEW: > >>>> Due to the security issues presented in Section 5, the latching > >>>> mechanism > >>>> is considered appropriate only when all security considerations are > >>>> taken into > >>>> account and solved. > >>> > >>> I think the text in the -04 is preferable to this, as it is more > >>>specific. > >>> > >>> I would be interested in others' thoughts on the text I proposed above. > >> > >>Could we at least eliminate the double negatives ("inappropriate ... > >>unless")? > > > >In principle, yes, but it seems much easier to enumerate the situations > >where it's inappropriate than where it's appropriate -- I'm finding it > >difficult to think of better phrasing. > > > >Alissa > > > >> > >>-d > >> > >> > >>> > >>> Thanks, > >>> Alissa > >>> > >>> > >> > > > > > >_______________________________________________ > >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 > -- https://jitsi.org From nobody Tue May 6 10:26: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 ADEE81A0196 for ; Tue, 6 May 2014 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zbXqeuU2Mj-9 for ; Tue, 6 May 2014 10:26:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E22B11A0206 for ; Tue, 6 May 2014 10:26:31 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-f0-53691b43bec4 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2F.43.04714.34B19635; Tue, 6 May 2014 19:26:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Tue, 6 May 2014 19:26:26 +0200 From: Christer Holmberg To: Flemming Andreasen , Harald Alvestrand , mmusic Thread-Topic: [MMUSIC] Updated MSID draft Thread-Index: AQHPZtSMXeHvnDUVykKBkDYCcopqk5swrk8AgALedACAAEU6gA== Date: Tue, 6 May 2014 17:26:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EED4E@ESESSMB209.ericsson.se> References: <531875E3.9000605@alvestrand.no> <53187758.1080403@cisco.com> <5364566D.5010601@cisco.com> <53669466.4020309@alvestrand.no> <5368FC80.6050403@cisco.com> In-Reply-To: <5368FC80.6050403@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvja6zdGawQd8xSYv3F3QtjvV1sVlM Xf6YxYHZ48qEK6weU35vZPVYsuQnUwBzFJdNSmpOZllqkb5dAlfGx+OHWQvOc1YsXHKNuYHx CnsXIyeHhICJxOltc5ghbDGJC/fWs3UxcnEICRxllFi8fiErhLOYUeLqpftADgcHm4CFRPc/ bZAGEYFCiYu3VzOB2MICGhJ733YxQcQ1Je6s3MICYTtJ3Nh6ixGklUVARWLaqySQMK+Ar0T3 l16wvUICKxglllwCa+UEal259S2YzQh0z/dTa8BsZgFxiVtP5jNB3CkgsWTPeaibRSVePv7H CmErSSy6/RmqXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY RYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAuPm4JbfujsYV792PMQowMGoxMP74FVGsBBrYllx Ze4hRmkOFiVx3ra73sFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGJMmyPhfy/JjvOC3WuNP BvNVY9ZuPnvxCWnt6+w2zYm44i34kq2bKf3hlgZe78YEI3b1W9IaXLJL+5+qXltnsLGxOs6Y r6+jzOz2rvrP7/YsSP8bM/Op05sZXT/C2pQX3TNLfWXsfFeFMaZTQIJn41+128f0DyrI3bj4 deKNPVEBlaZpj3RuKbEUZyQaajEXFScCAJ0bCTh8AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/P7Q00aTr-RZzv6fNkSX2XmkgCd0 Subject: Re: [MMUSIC] Updated MSID draft 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, 06 May 2014 17:26:33 -0000 Hi, >>> 2) Offer/Answer procedures are lacking. We need to have an O/A=20 >>> section with subsections as per RFC 3264 (for unicast) to better=20 >>> specify the overall behavior here (Generating the Initial Offer,=20 >>> Generating the Answer, Offerer Processing of the Answer, Modifying=20 >>> the Session) >> Hm. But MSID isn't an offer/answer field. It's an unilateral=20 >> declaration, and refers to no information coming from the other side. >> >> Does it make sense to follow the offer/answer section format when the=20 >> answer doesn't depend on the offer? > It does. Even declarative SDP parameters have procedures that must be=20 > followed by the offerer and the answerer and we want those called out cle= arly. I agree. I have to admit that I was sceptical when Flemming asked me to do a similar= change for the UDPTL-DTLS draft, but afterward I think it was a good thing= to do. Especially when it comes to subsequent offer/answer exchanges, it's good to= have explicit text on what is allowed, and what is not. I also did the same change for BUNDLE (which was a much bigger exercise tha= n I initially thought :), so let me know if you need some help :) Regards, Christer From nobody Fri May 9 03:55:15 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 C45191A024B for ; Fri, 9 May 2014 03:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, 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 wFhmwCINBzFw for ; Fri, 9 May 2014 03:55:11 -0700 (PDT) Received: from mailout1.thls.bbc.co.uk (mailout1.thls.bbc.co.uk [132.185.240.36]) by ietfa.amsl.com (Postfix) with ESMTP id 52A821A0243 for ; Fri, 9 May 2014 03:55:11 -0700 (PDT) Received: from BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) by mailout1.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id s49AsqrJ001407 for ; Fri, 9 May 2014 11:55:04 +0100 (BST) Received: from BGB01XUD1002.national.core.bbc.co.uk ([169.254.11.5]) by BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) with mapi id 14.02.0342.004; Fri, 9 May 2014 11:55:04 +0100 From: Peter Stevens To: "mmusic@ietf.org" Thread-Topic: Resend: RFC 4317, RFC 4566: SDP asymmetry and port numbers? Thread-Index: Ac9rdIBPMSqWok8PQtq4FdAuwqSBQw== Date: Fri, 9 May 2014 10:55:03 +0000 Message-ID: <2F938AAE444ADB47AFEE6307955A30CE2DFD40A6@BGB01XUD1002.national.core.bbc.co.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.113.201] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: multipart/alternative; boundary="_000_2F938AAE444ADB47AFEE6307955A30CE2DFD40A6BGB01XUD1002nat_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UyBLJcFNrLjnRFG_Hm_JQ8UaZVc Subject: [MMUSIC] Resend: RFC 4317, RFC 4566: SDP asymmetry and port numbers? 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, 09 May 2014 10:55:13 -0000 --_000_2F938AAE444ADB47AFEE6307955A30CE2DFD40A6BGB01XUD1002nat_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3YXMgb3JpZ2luYWxseSBzZW50IHRvIHRoZSBsaXN0IGluIE1hcmNoLCBidXQgc28gZmFy IG5vIHJlc3BvbnNlLCBzbyByZXNlbmRpbmcgaW4gY2FzZSBzb21lb25lIHdobyBjb3VsZCBhbnN3 ZXIgbWlzc2VkIGl0IGF0IHRoZSB0aW1lLg0KDQoNCg0KSGksIEkgaGF2ZSB0aHJlZSBxdWVzdGlv bnMgYWJvdXQgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIFNEUC4NCg0KVGhlIGZpcnN0IGlzIGFi b3V0IFJGQyA0MzE3IC0gU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBPZmZlci9B bnN3ZXIgRXhhbXBsZXMuIEluIHNlY3Rpb25zIDIuOSBhbmQgMi4xMCBvZiB2ZXJzaW9uIDAxIG9m IHRoZSBkcmFmdCB0aGVyZSBhcmUgZXhhbXBsZXMgb2YgdXNpbmcgYT1zZW5kb25seSBhbmQgYT1y ZWN2b25seSB0byBkZWZpbmUgYXN5bW1ldHJpY2FsIGNvbm5lY3Rpb25zLCBpLmUuIGRpZmZlcmVu dCBjb2Rpbmcgb3IgYml0IHJhdGVzIGluIGRpZmZlcmVudCBkaXJlY3Rpb25zLiBJbiB0aGUgbmV4 dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCwgdGhlc2UgZXhhbXBsZXMgYXJlIGdvbmUuDQoNCk15IHF1 ZXN0aW9uIGlzOiBXaHkgd2VyZSB0aGV5IHJlbW92ZWQ/DQoNClRoZSBzZWNvbmQgcXVlc3Rpb24g aXMgYWJvdXQgUkZDIDQ1NjYgLSBTRFAgaXRzZWxmIGFuZCBtaWdodCBjb250YWluIHRoZSBhbnN3 ZXIgdG8gdGhlIHF1ZXN0aW9uIGFib3ZlLiBJbiBzZWN0aW9uIDUuMTQsIHdoZXJlIG1lZGlhIGRl c2NyaXB0aW9ucyBhcmUgZGVmaW5lZCwgSSBjYW4gcmVhZCB0aGUgZm9sbG93aW5nIHBhcmFncmFw aDoNCg0KICAgICAgVGhlIHNlbWFudGljcyBvZiBtdWx0aXBsZSAibT0iIGxpbmVzIHVzaW5nIHRo ZSBzYW1lIHRyYW5zcG9ydA0KICAgICAgYWRkcmVzcyBhcmUgdW5kZWZpbmVkLiAgVGhpcyBpbXBs aWVzIHRoYXQsIHVubGlrZSBsaW1pdGVkIHBhc3QNCiAgICAgIHByYWN0aWNlLCB0aGVyZSBpcyBu byBpbXBsaWNpdCBncm91cGluZyBkZWZpbmVkIGJ5IHN1Y2ggbWVhbnMgYW5kDQogICAgICBhbiBl eHBsaWNpdCBncm91cGluZyBmcmFtZXdvcmsgKGZvciBleGFtcGxlLCBbMThdKSBzaG91bGQgaW5z dGVhZA0KICAgICAgYmUgdXNlZCB0byBleHByZXNzIHRoZSBpbnRlbmRlZCBzZW1hbnRpY3MuDQoN CkRvZXMgdGhpcyBhbHNvIGFwcGx5IHdoZW4gdGhlIHVzZSBvZiBhPXNlbmRvbmx5IGFuZCBhPXJl Y3Zvbmx5IG1ha2UgdGhlIHNlbWFudGljcyBjbGVhcj8NCg0KSWYgdGhlIGFib3ZlIHBhcmFncmFw aCBkb2VzIGRpc2FsbG93IHVzYWdlIGxpa2UgdGhlIGRlbGV0ZWQgZXhhbXBsZXMgb2YgUkZDIDQz MTcsIGhvdyBzaG91bGQgc29tZXRoaW5nIGxpa2UgdGhhdCBiZSBzaWduYWxsZWQgc28gdGhhdCB0 aGUgaW50ZW50IGlzIHdlbGwgZGVmaW5lZCBhbmQgMTAwJSBjb21wbGlhbnQgd2l0aCBleGlzdGlu ZyBzdGFuZGFyZHM/DQoNCkJlc3QgcmVnYXJkcywNCg0KUGV0ZXIgU3RldmVucw0KDQpCQkMgUiZE DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpodHRwOi8vd3d3LmJi Yy5jby51aw0KVGhpcyBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVudGlh bCBhbmQgbWF5IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmlld3Mg b2YgdGhlIEJCQyB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC4NCklmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQpEbyBu b3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgd2F5IG5vciBh Y3QgaW4gcmVsaWFuY2Ugb24gaXQgYW5kIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5Lg0K UGxlYXNlIG5vdGUgdGhhdCB0aGUgQkJDIG1vbml0b3JzIGUtbWFpbHMgc2VudCBvciByZWNlaXZl ZC4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25pZnkgeW91ciBjb25zZW50IHRvIHRo aXMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_2F938AAE444ADB47AFEE6307955A30CE2DFD40A6BGB01XUD1002nat_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8IS0tIFRlbXBsYXRlIGdlbmVyYXRlZCBieSBFeGNs YWltZXIgTWFpbCBEaXNjbGFpbWVycyBvbiAxMTo1NTowNCBGcmlkYXksIDkgTWF5IDIwMTQgLS0+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlAuNWVlM2FhZjYtNjI2NC00NDQx LWIxODgtNjE2MDIzOWY4NDMyIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpMSS41ZWUzYWFm Ni02MjY0LTQ0NDEtYjE4OC02MTYwMjM5Zjg0MzIgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0N CkRJVi41ZWUzYWFmNi02MjY0LTQ0NDEtYjE4OC02MTYwMjM5Zjg0MzIgew0KCU1BUkdJTjogMGNt IDBjbSAwcHQNCn0NClRBQkxFLjVlZTNhYWY2LTYyNjQtNDQ0MS1iMTg4LTYxNjAyMzlmODQzMlRh YmxlIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNl Y3Rpb24xDQp9DQo8L3N0eWxlPjxzdHlsZSBpZD0ib3dhUGFyYVN0eWxlIj5QIHsNCglNQVJHSU4t Qk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweA0KfQ0KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGZQU3R5bGU9IjEiIG9jc2k9IjAiPg0KPHAgY2xhc3M9IjVlZTNhYWY2LTYyNjQtNDQ0MS1iMTg4 LTYxNjAyMzlmODQzMiI+PC9wPg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Zm9udC1mYW1p bHk6IEFyaWFsO2NvbG9yOiAjMDAwMDAwO2ZvbnQtc2l6ZTogMTBwdDsiPg0KPHA+VGhpcyB3YXMg b3JpZ2luYWxseSBzZW50IHRvIHRoZSBsaXN0IGluIE1hcmNoLCBidXQgc28gZmFyIG5vIHJlc3Bv bnNlLCBzbyByZXNlbmRpbmcgaW4gY2FzZSBzb21lb25lIHdobyBjb3VsZCBhbnN3ZXIgbWlzc2Vk IGl0IGF0IHRoZSB0aW1lLjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPkhpLCBJIGhhdmUgdGhyZWUg cXVlc3Rpb25zIGFib3V0IGV4aXN0aW5nIFJGQ3MgcmVsYXRlZCB0byBTRFAuPGJyPg0KPGJyPg0K VGhlIGZpcnN0IGlzIGFib3V0IFJGQyA0MzE3IC0gU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2Nv bCAoU0RQKSBPZmZlci9BbnN3ZXIgRXhhbXBsZXMuIEluIHNlY3Rpb25zIDIuOSBhbmQgMi4xMCBv ZiB2ZXJzaW9uIDAxIG9mIHRoZSBkcmFmdCB0aGVyZSBhcmUgZXhhbXBsZXMgb2YgdXNpbmcgYT1z ZW5kb25seSBhbmQgYT1yZWN2b25seSB0byBkZWZpbmUgYXN5bW1ldHJpY2FsIGNvbm5lY3Rpb25z LCBpLmUuIGRpZmZlcmVudCBjb2Rpbmcgb3IgYml0DQogcmF0ZXMgaW4gZGlmZmVyZW50IGRpcmVj dGlvbnMuIEluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0LCB0aGVzZSBleGFtcGxlcyBh cmUgZ29uZS48YnI+DQo8YnI+DQpNeSBxdWVzdGlvbiBpczogV2h5IHdlcmUgdGhleSByZW1vdmVk Pzxicj4NCjxicj4NClRoZSBzZWNvbmQgcXVlc3Rpb24gaXMgYWJvdXQgUkZDIDQ1NjYgLSBTRFAg aXRzZWxmIGFuZCBtaWdodCBjb250YWluIHRoZSBhbnN3ZXIgdG8gdGhlIHF1ZXN0aW9uIGFib3Zl LiBJbiBzZWN0aW9uIDUuMTQsIHdoZXJlIG1lZGlhIGRlc2NyaXB0aW9ucyBhcmUgZGVmaW5lZCwg SSBjYW4gcmVhZCB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDo8YnI+DQo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHNlbWFudGljcyBvZiBtdWx0aXBsZSAmcXVvdDttPSZx dW90OyBsaW5lcyB1c2luZyB0aGUgc2FtZSB0cmFuc3BvcnQ8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYWRkcmVzcyBhcmUgdW5kZWZpbmVkLiZuYnNwOyBUaGlzIGltcGxpZXMg dGhhdCwgdW5saWtlIGxpbWl0ZWQgcGFzdDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBwcmFjdGljZSwgdGhlcmUgaXMgbm8gaW1wbGljaXQgZ3JvdXBpbmcgZGVmaW5lZCBieSBz dWNoIG1lYW5zIGFuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbiBleHBs aWNpdCBncm91cGluZyBmcmFtZXdvcmsgKGZvciBleGFtcGxlLCBbMThdKSBzaG91bGQgaW5zdGVh ZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSB1c2VkIHRvIGV4cHJlc3Mg dGhlIGludGVuZGVkIHNlbWFudGljcy48YnI+DQo8YnI+DQpEb2VzIHRoaXMgYWxzbyBhcHBseSB3 aGVuIHRoZSB1c2Ugb2YgYT1zZW5kb25seSBhbmQgYT1yZWN2b25seSBtYWtlIHRoZSBzZW1hbnRp Y3MgY2xlYXI/PGJyPg0KPGJyPg0KSWYgdGhlIGFib3ZlIHBhcmFncmFwaCBkb2VzIGRpc2FsbG93 IHVzYWdlIGxpa2UgdGhlIGRlbGV0ZWQgZXhhbXBsZXMgb2YgUkZDIDQzMTcsIGhvdyBzaG91bGQg c29tZXRoaW5nIGxpa2UgdGhhdCBiZSBzaWduYWxsZWQgc28gdGhhdCB0aGUgaW50ZW50IGlzIHdl bGwgZGVmaW5lZCBhbmQgMTAwJSBjb21wbGlhbnQgd2l0aCBleGlzdGluZyBzdGFuZGFyZHM/PGJy Pg0KPC9wPg0KPHA+QmVzdCByZWdhcmRzLDwvcD4NCjxwPlBldGVyIFN0ZXZlbnM8L3A+DQo8cD5C QkMgUiZhbXA7RDwvcD4NCjxwPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPHA+PC9wPg0KPHAgY2xhc3M9 IjVlZTNhYWY2LTYyNjQtNDQ0MS1iMTg4LTYxNjAyMzlmODQzMiI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9IjVlZTNhYWY2LTYyNjQtNDQ0MS1iMTg4LTYxNjAyMzlmODQzMiI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PGEgaHJlZj0iaHR0cDovL3d3dy5iYmMuY28udWsiIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vd3d3LjxzcGFuIGNsYXNzPSJpbCI+YmJjPC9zcGFuPi48c3BhbiBjbGFzcz0iaWwiPmNvPC9z cGFuPi48c3BhbiBjbGFzcz0iaWwiPnVrPC9zcGFuPjwvYT48YnI+DQpUaGlzIGUtbWFpbCAoYW5k IGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwZXJzb25h bCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUNCjxzcGFuIGNsYXNzPSJpbCI+ QkJDPC9zcGFuPiB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC48YnI+DQpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjxi cj4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGluIGFueSB3 YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkuPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgPHNwYW4gY2xhc3M9ImlsIj5CQkM8L3Nw YW4+IG1vbml0b3JzIGUtbWFpbHMgc2VudCBvciByZWNlaXZlZC48YnI+DQpGdXJ0aGVyIGNvbW11 bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLjwvZm9udD48L2ZvbnQ+ PC9mb250PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iNWVlM2FhZjYtNjI2NC00NDQxLWIxODgtNjE2 MDIzOWY4NDMyIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2F938AAE444ADB47AFEE6307955A30CE2DFD40A6BGB01XUD1002nat_-- From nobody Fri May 9 07:57: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 231881A0021 for ; Fri, 9 May 2014 07:57:27 -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_18=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 yDfLlo_mC0SX for ; Fri, 9 May 2014 07:57:26 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2904D1A0008 for ; Fri, 9 May 2014 07:57:26 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id zoQt1n0010vyq2s57qxMqR; Fri, 09 May 2014 14:57:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id zqxL1n00m3ZTu2S3RqxM2z; Fri, 09 May 2014 14:57:21 +0000 Message-ID: <536CECD0.4070104@alum.mit.edu> Date: Fri, 09 May 2014 10:57:20 -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: <2F938AAE444ADB47AFEE6307955A30CE2DFD40A6@BGB01XUD1002.national.core.bbc.co.uk> In-Reply-To: <2F938AAE444ADB47AFEE6307955A30CE2DFD40A6@BGB01XUD1002.national.core.bbc.co.uk> 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=1399647441; bh=BIt+3EPSC1466JASvqdJNvlNBMmQP+jNiM1pU1/udp4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EM8QfOX6te0hPcsR00hDo3gzkZRWj3bp9ae56USHQJ6os/ruqQm2ZppjAjiEYJFIf gQC9Pd9wDkjkKOjbrqH505fYE5sUB0ynHZ0RSuhYQ1pnFEPkltiW0RBXzEJGTtWA0W CZzGOL8BR3oqyIGgUUfxYFyhfyXgbIIO7FZOojwYjMvWJWeXEvv3QGpLhcqZ5ontV3 LYLQbW+UFR45zWHhSQy7NNy+truGRwUTrtRUQbnaDawBGM6S+Ye1ZVnmvEwaDWfiMA HbvXBRvy9s98PtLegzHnnql2NhYPPncB3xT9YJLWSPJ1F8CMzzwLqRzVt+s8RKlsdA mA7LC7K7EZTNQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/V7JDCMVLOUwBOtdsh1pHa0Cfy3M Subject: Re: [MMUSIC] Resend: RFC 4317, RFC 4566: SDP asymmetry and port numbers? 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, 09 May 2014 14:57:27 -0000 On 5/9/14 6:55 AM, Peter Stevens wrote: > This was originally sent to the list in March, but so far no response, > so resending in case someone who could answer missed it at the time. > > Hi, I have three questions about existing RFCs related to SDP. > > The first is about RFC 4317 - Session Description Protocol (SDP) > Offer/Answer Examples. In sections 2.9 and 2.10 of version 01 of the > draft there are examples of using a=sendonly and a=recvonly to define > asymmetrical connections, i.e. different coding or bit rates in > different directions. In the next version of the draft, these examples > are gone. > > My question is: Why were they removed? I don't recall, but the answer you have given below is a good guess. > The second question is about RFC 4566 - SDP itself and might contain the > answer to the question above. In section 5.14, where media descriptions > are defined, I can read the following paragraph: > > The semantics of multiple "m=" lines using the same transport > address are undefined. This implies that, unlike limited past > practice, there is no implicit grouping defined by such means and > an explicit grouping framework (for example, [18]) should instead > be used to express the intended semantics. > > Does this also apply when the use of a=sendonly and a=recvonly make the > semantics clear? Yes it does. > If the above paragraph does disallow usage like the deleted examples of > RFC 4317, how should something like that be signalled so that the intent > is well defined and 100% compliant with existing standards? The work on m-line bundling (draft-ietf-mmusic-sdp-bundle-negotiation-07) provides a way to achieve this. Thanks, Paul From nobody Sun May 11 21:51: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 546FC1A03ED for ; Sun, 11 May 2014 21:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=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 Hz7pfLXafQ3v for ; Sun, 11 May 2014 21:51:05 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id D36D01A03EC for ; Sun, 11 May 2014 21:51:04 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so6185577wgh.31 for ; Sun, 11 May 2014 21:50:58 -0700 (PDT) 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=lLjL5zC3DzT2YUifJ4RDLDZKou0YzJrKzYQCqKFdERo=; b=Z5zePDLY1yFKi1o19iZwc/YqFVjCGJJ0HNyG0+abuI7X9Vy0WhKNvM+kWSe6yePUK4 3GWTBLkY66kSftv+z+bzrO5e80a1W6iG5KXfzBEUonhXK59ssgeIsycHnizjvW/xpCmB gIG05K74zBkKR8jfcd4roQo+M7B0dlA7iJnElSykUccMJK/D/Un3kK0Fasw7u+4ouGH8 ef+yXmg55Y9Q7uzjdEFR2b4g3hraj0uyMV/mFn/QA13iaAgjGQZ8j7zNbrH8uZucEPOv 2Y775ll+B4CifidPXWuxfuFMewATi/o+uk/95ZOvl884/eSV+E/bQe3zzm60W0nYS95U pkYQ== X-Gm-Message-State: ALoCoQmYsTM167mR4HbwIoddbQSef7OFsA70/8Sr/RU3qKsijLbGm3RcIDQraFYlktewMvFj87RO X-Received: by 10.180.94.226 with SMTP id df2mr13451213wib.1.1399870258447; Sun, 11 May 2014 21:50:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 11 May 2014 21:50:18 -0700 (PDT) X-Originating-IP: [74.95.2.168] From: Eric Rescorla Date: Sun, 11 May 2014 21:50:18 -0700 Message-ID: To: mmusic WG , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d04447e617cf71a04f92cb156 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/crq3AkM2fPcxxbCipzHyBARAqzk Subject: [MMUSIC] m-line recycling 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, 12 May 2014 04:51:06 -0000 --f46d04447e617cf71a04f92cb156 Content-Type: text/plain; charset=UTF-8 The JSEP spec specifies m-line recycling: o If any MediaStreamTracks have been added, and there exist m= sections of the appropriate media type with no associated MediaStreamTracks (i.e. as described in the preceding paragraph), those m= sections MUST be recycled by adding the new MediaStreamTrack to the m= section. This is done by adding the necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the recycled m= section, and removing the "a=recvonly" attribute. Based on the minutes from IETF 89, we were going to take this to mmusic. http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-rtcweb?useMonospaceFont=true Thoughts? -Ekr https://github.com/rtcweb-wg/jsep/issues/21 --f46d04447e617cf71a04f92cb156 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The JSEP spec = specifies m-line recycling:


 o  If any MediaStreamTracks ha=
ve been added, and there exist m=3D
      sections of the appropriate media type with no associated
      MediaStreamTracks (i.e. as described in the preceding paragraph),
      those m=3D sections MUST be recycled by adding the new
      MediaStreamTrack to the m=3D section.  This is done by adding the
      necessary "a=3Dmsid", "a=3Dssrc", and "a=3Ds=
src-group" lines to the
      recycled m=3D section, and removing the "a=3Drecvonly" attr=
ibute.
Based=C2=A0o=
n the minutes from IETF 89, we were going to take this to mmusic.


h=
ttp://etherpad.tools.ietf.org:9000/p/notes-ietf-89-rtcweb?useMonospaceFont=
=3Dtrue



Thoughts?
-Ekr

--f46d04447e617cf71a04f92cb156-- From nobody Sun May 11 23:54: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 A41B81A040B; Sun, 11 May 2014 23:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=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 etzAUjTBjBwN; Sun, 11 May 2014 23:54:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8761A040A; Sun, 11 May 2014 23:54:33 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-30-53707023bf6c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.0F.04329.32070735; Mon, 12 May 2014 08:54:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Mon, 12 May 2014 08:54:26 +0200 From: Christer Holmberg To: Eric Rescorla , mmusic WG , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] m-line recycling Thread-Index: AQHPbZ3IZCFNfz/Rxkqqe6/mM5wW2Js8gTuQ Date: Mon, 12 May 2014 06:54:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F672A@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2F672AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja5yQUGwwZsnKhYrXp9jt5i6/DGL xdp/7ewOzB5Llvxk8pj8uI05gCmKyyYlNSezLLVI3y6BK6N51w72gjWxFTf71jI3MD6J6mLk 5JAQMJHou/efBcIWk7hwbz1bFyMXh5DAUUaJyyenMkM4Sxglrr+cD+RwcLAJWEh0/9MGaRAR SJHoOXaSEcQWFlCTmP98BxNEXF3i77l7jBC2kcTBDxPYQGwWAVWJq8f+soPYvAK+EjdfLmcG sYUEAiSOHT3IBDKeUyBQovVRNUiYEeie76fWgI1kFhCXuPVkPhPEnQISS/acZ4awRSVePv7H CtIqIaAosbxfDsRkFsiXaFwgBrFIUOLkzCcsExhFZiEZNAuhahaSKoiwpsT6XfoQ1YoSU7of skPYGhKtc+ayI4svYGRfxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYVwe3/LbawXjwueMh RgEORiUeXgXtgmAh1sSy4srcQ4zSHCxK4ryTFrkHCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amBk73ANCtvg9ffV/j85Hx/nzftf0uBlo/VIMGFJjO5atbcq67LPZHD9f2xgbxgi6XxwwfEn +r/X/poZaTPvRqnpi2SbSM2ZfPL7Np5qen0+tf7KIeflbz9tffE5r/6pZFzg9tkR2s7PFpwW nW6cHd/ScGmzAN/RqdZ3EpZHaFj4rkxjnNT2+FmREktxRqKhFnNRcSIAj5C8OYwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uwnljJJl5HyOoegCFHwxi1PhQJo Subject: Re: [MMUSIC] m-line recycling 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, 12 May 2014 06:54:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2F672AESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG9u4oCZdCB0aGluayBpdCBzaG91bGQgYmUgYSBNVVNUIOKAkyBhdCBsZWFzdCBu b3Qgb25seSBiYXNlZCBvbiB0aGUgbWVkaWEgdHlwZS4gQmVjYXVzZSwgdGhlcmUgbWF5IGJlIG90 aGVyIHByb3BlcnRpZXMgdGhhbiB0aGUgbWVkaWEgdHlwZSBhc3NvY2lhdGVkIHdpdGggdGhlIOKA nG094oCdIGxpbmUsIHdoeSBvbmUgZG9lcyBub3Qgd2FudCB0byB1c2UgaXQgZm9yIHRoZSBzcGVj aWZpYyBNU1QuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBtbXVzaWMgW21h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGEN ClNlbnQ6IDEyLiB0b3Vrb2t1dXRhIDIwMTQgNzo1MA0KVG86IG1tdXNpYyBXRzsgcnRjd2ViQGll dGYub3JnDQpTdWJqZWN0OiBbTU1VU0lDXSBtLWxpbmUgcmVjeWNsaW5nDQoNClRoZSBKU0VQIHNw ZWMgc3BlY2lmaWVzIG0tbGluZSByZWN5Y2xpbmc6DQoNCg0KDQoNCg0KDQogbyAgSWYgYW55IE1l ZGlhU3RyZWFtVHJhY2tzIGhhdmUgYmVlbiBhZGRlZCwgYW5kIHRoZXJlIGV4aXN0IG09DQoNCiAg ICAgIHNlY3Rpb25zIG9mIHRoZSBhcHByb3ByaWF0ZSBtZWRpYSB0eXBlIHdpdGggbm8gYXNzb2Np YXRlZA0KDQogICAgICBNZWRpYVN0cmVhbVRyYWNrcyAoaS5lLiBhcyBkZXNjcmliZWQgaW4gdGhl IHByZWNlZGluZyBwYXJhZ3JhcGgpLA0KDQogICAgICB0aG9zZSBtPSBzZWN0aW9ucyBNVVNUIGJl IHJlY3ljbGVkIGJ5IGFkZGluZyB0aGUgbmV3DQoNCiAgICAgIE1lZGlhU3RyZWFtVHJhY2sgdG8g dGhlIG09IHNlY3Rpb24uICBUaGlzIGlzIGRvbmUgYnkgYWRkaW5nIHRoZQ0KDQogICAgICBuZWNl c3NhcnkgImE9bXNpZCIsICJhPXNzcmMiLCBhbmQgImE9c3NyYy1ncm91cCIgbGluZXMgdG8gdGhl DQoNCiAgICAgIHJlY3ljbGVkIG09IHNlY3Rpb24sIGFuZCByZW1vdmluZyB0aGUgImE9cmVjdm9u bHkiIGF0dHJpYnV0ZS4NCg0KQmFzZWQgb24gdGhlIG1pbnV0ZXMgZnJvbSBJRVRGIDg5LCB3ZSB3 ZXJlIGdvaW5nIHRvIHRha2UgdGhpcyB0byBtbXVzaWMuDQoNCmh0dHA6Ly9ldGhlcnBhZC50b29s cy5pZXRmLm9yZzo5MDAwL3Avbm90ZXMtaWV0Zi04OS1ydGN3ZWI/dXNlTW9ub3NwYWNlRm9udD10 cnVlDQoNCg0KDQoNClRob3VnaHRzPw0KDQotRWtyDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3 ZWItd2cvanNlcC9pc3N1ZXMvMjENCg== --_000_7594FB04B1934943A5C02806D1A2204B1D2F672AESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBpdCBzaG91bGQgYmUgYSBNVVNUIOKAkyBhdCBsZWFz dCBub3Qgb25seSBiYXNlZCBvbiB0aGUgbWVkaWEgdHlwZS4gQmVjYXVzZSwgdGhlcmUgbWF5IGJl IG90aGVyIHByb3BlcnRpZXMgdGhhbiB0aGUgbWVkaWEgdHlwZSBhc3NvY2lhdGVkIHdpdGggdGhl DQog4oCcbT3igJ0gbGluZSwgd2h5IG9uZSBkb2VzIG5vdCB3YW50IHRvIHVzZSBpdCBmb3IgdGhl IHNwZWNpZmljIE1TVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBt bXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiAxMi4gdG91a29rdXV0YSAyMDE0IDc6 NTA8YnI+DQo8Yj5Ubzo8L2I+IG1tdXNpYyBXRzsgcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtNTVVTSUNdIG0tbGluZSByZWN5Y2xpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIEpTRVAgc3BlYyBzcGVjaWZpZXMgbS1saW5l IHJlY3ljbGluZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3 b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiBvJm5ic3A7IElmIGFueSBNZWRpYVN0cmVhbVRyYWNrcyBoYXZl IGJlZW4gYWRkZWQsIGFuZCB0aGVyZSBleGlzdCBtPTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHNlY3Rpb25zIG9mIHRoZSBhcHByb3ByaWF0ZSBtZWRpYSB0eXBlIHdpdGggbm8gYXNzb2NpYXRl ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1lZGlhU3RyZWFtVHJhY2tzIChpLmUuIGFzIGRl c2NyaWJlZCBpbiB0aGUgcHJlY2VkaW5nIHBhcmFncmFwaCksPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhvc2UgbT0gc2VjdGlvbnMgTVVTVCBiZSByZWN5Y2xlZCBieSBhZGRpbmcgdGhlIG5l dzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1lZGlhU3RyZWFtVHJhY2sgdG8gdGhlIG09IHNl Y3Rpb24uJm5ic3A7IFRoaXMgaXMgZG9uZSBieSBhZGRpbmcgdGhlPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbmVjZXNzYXJ5ICZxdW90O2E9bXNpZCZxdW90OywgJnF1b3Q7YT1zc3JjJnF1b3Q7 LCBhbmQgJnF1b3Q7YT1zc3JjLWdyb3VwJnF1b3Q7IGxpbmVzIHRvIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJlY3ljbGVkIG09IHNlY3Rpb24sIGFuZCByZW1vdmluZyB0aGUgJnF1b3Q7 YT1yZWN2b25seSZxdW90OyBhdHRyaWJ1dGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWst d29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJhc2VkJm5i c3A7b24gdGhlIG1pbnV0ZXMgZnJvbSBJRVRGIDg5LCB3ZSB3ZXJlIGdvaW5nIHRvIHRha2UgdGhp cyB0byBtbXVzaWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxhIGhyZWY9Imh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3Avbm90ZXMtaWV0 Zi04OS1ydGN3ZWI/dXNlTW9ub3NwYWNlRm9udD10cnVlIj5odHRwOi8vZXRoZXJwYWQudG9vbHMu aWV0Zi5vcmc6OTAwMC9wL25vdGVzLWlldGYtODktcnRjd2ViP3VzZU1vbm9zcGFjZUZvbnQ9dHJ1 ZTwvYT48L3NwYW4+PGJyPjxicj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6 cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaG91Z2h0cz88L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+LUVrcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pz ZXAvaXNzdWVzLzIxIj5odHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzIx PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D2F672AESESSMB209erics_-- From nobody Mon May 12 07:43:43 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 E730C1A0721; Mon, 12 May 2014 07:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, WEIRD_PORT=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 4PhRm6imbUna; Mon, 12 May 2014 07:43:37 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 45FDF1A0711; Mon, 12 May 2014 07:43:37 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so7020985wes.15 for ; Mon, 12 May 2014 07:43:30 -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=yFVApFbnItYiNxn6IBgavR7NEx3eG42LAKjyLJJj26o=; b=TaIyV8RzxF9sDHA6xraI/DSqP8oVzVocSGOtoncgJOv6CbyqUg9rhXHUj2BrOZJkzG N4t6TLZDTNj4hFhmJQa6eQ41ai3Hy0O12U+WxNw/ewWptgDnuYtcU1KWzxCJ0RZbLQWM HP7slI3qNVIFD6v5F3eo7E9DrS2oEdrSUrb+K2BUNZGOZQmaVgIw/8nNfjm4MAKa0y9i jlY9mLZ2vAhNojcYGmaePxBN283nONLIolVEcaYWJDYPtCQgK+6IhT8+Mhja4Mv5/a5T b39K5eLMWW509gRtKKKnt332zqFSavkaw3fSgD96hwsYL1tAi4Hu0Li6M7Pe4KVhNm9a ymog== MIME-Version: 1.0 X-Received: by 10.180.77.165 with SMTP id t5mr16314207wiw.38.1399905810816; Mon, 12 May 2014 07:43:30 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Mon, 12 May 2014 07:43:30 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Mon, 12 May 2014 07:43:30 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2F672A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2F672A@ESESSMB209.ericsson.se> Date: Mon, 12 May 2014 07:43:30 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043c085a92a62a04f934f818 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/bqjLhu632mbKTFHDJHFljQ1uk-E Cc: rtcweb@ietf.org, mmusic WG Subject: Re: [MMUSIC] [rtcweb] m-line recycling 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, 12 May 2014 14:43:40 -0000 --f46d043c085a92a62a04f934f818 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, some words about being compatible and all that entails are required if we intend to stipulate it being reused. Either that or we can say MAY. The need for a strong definition diminishes then. On May 11, 2014 11:54 PM, "Christer Holmberg" < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I don=E2=80=99t think it should be a MUST =E2=80=93 at least not only bas= ed on the media > type. Because, there may be other properties than the media type associat= ed > with the =E2=80=9Cm=3D=E2=80=9D line, why one does not want to use it for= the specific MST. > > > > Regards, > > > > Christer > > > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* 12. toukokuuta 2014 7:50 > *To:* mmusic WG; rtcweb@ietf.org > *Subject:* [MMUSIC] m-line recycling > > > > The JSEP spec specifies m-line recycling: > > > > > > > > o If any MediaStreamTracks have been added, and there exist m=3D > > sections of the appropriate media type with no associated > > MediaStreamTracks (i.e. as described in the preceding paragraph), > > those m=3D sections MUST be recycled by adding the new > > MediaStreamTrack to the m=3D section. This is done by adding the > > necessary "a=3Dmsid", "a=3Dssrc", and "a=3Dssrc-group" lines to the > > recycled m=3D section, and removing the "a=3Drecvonly" attribute. > > Based on the minutes from IETF 89, we were going to take this to mmusic. > > http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-rtcweb?useMonospaceFo= nt=3Dtrue > > > > Thoughts? > > -Ekr > > > > https://github.com/rtcweb-wg/jsep/issues/21 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043c085a92a62a04f934f818 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, some words about being compatible and all that entails = are required if we intend to stipulate it being reused. Either that or we c= an say MAY. The need for a strong definition diminishes then.

On May 11, 2014 11:54 PM, "Christer Holmber= g" <christer.holm= berg@ericsson.com> wrote:

Hi,<= /p>

=C2=A0

I don=E2=80=99t think it = should be a MUST =E2=80=93 at least not only based on the media type. Becau= se, there may be other properties than the media type associated with the =E2=80=9Cm=3D=E2=80=9D line, why one does not want to use it for the speci= fic MST.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

From: mmusic [= mailto:mmusic-= bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 12. toukokuuta 2014 7:50
To: mmusic WG; = rtcweb@ietf.org
Subject: [MMUSIC] m-line recycling

=C2=A0

The JSEP spec specifies m-line recycling:=

=C2=A0

=C2=A0
=C2=A0
 o=C2=A0 If any MediaStreamTracks have been added, and there exi=
st m=3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sections of the appropriate media=
 type with no associated
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTracks (i.e. as descri=
bed in the preceding paragraph),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 those m=3D sections MUST be recyc=
led by adding the new
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTrack to the m=3D sect=
ion.=C2=A0 This is done by adding the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary "a=3Dmsid", &=
quot;a=3Dssrc", and "a=3Dssrc-group" lines to the<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 recycled m=3D section, and removi=
ng the "a=3Drecvonly" attribute.
Based=C2=A0o=
n the minutes from IETF 89, we were going to take this to mmusic.=

http://etherpad.tools.ietf.org:9000/p/notes-ietf=
-89-rtcweb?useMonospaceFont=3Dtrue


=C2=A0
Thoughts?<=
u>
-Ekr

=C2=A0


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

--f46d043c085a92a62a04f934f818-- From nobody Wed May 14 12:29:32 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 74E7C1A0152; Wed, 14 May 2014 12:29: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 Cjb3cms1C4tx; Wed, 14 May 2014 12:29:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8DD1A00DD; Wed, 14 May 2014 12:29:27 -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.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140514192927.4367.5819.idtracker@ietfa.amsl.com> Date: Wed, 14 May 2014 12:29:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/HjQK09K7uqOJFE6VPAE7T2YDR-M Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: (Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication) to Informational RFC 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: Wed, 14 May 2014 19:29:28 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication' as Informational RFC 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-05-28. 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 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 this mechanism over the Internet and recommends other solutions such as the Interactive Connectivity Establishment (ICE) protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu May 15 14:31: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 C16CB1A0158 for ; Thu, 15 May 2014 14:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 oEkJPMCYGTx7 for ; Thu, 15 May 2014 14:31:28 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52411A0152 for ; Thu, 15 May 2014 14:31:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ABE1F2123F for ; Thu, 15 May 2014 17:31:19 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 15 May 2014 17:31:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=FMicjTaJ4k7LIya4hLdyriB NX0Y=; b=vHyQl9CVFU2dZhY2cu1h74bDF2q+veG2sfKG5BcGe0IPazyHJLMWuDF O4MJosa94W6UqyFI46aT+LraGdzh67qjRumvsPTEilr/qAcuotHlRdXlyzDSjiJm 6JB2t0DOIRaOklJqgzjJUdOSbCJYud7NqyGmzbCf0hqvtUpCVlhc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=FMicjTaJ4k7LIya4hLdyriBNX0Y=; b=fg9nBN2oGq7MEftfqOziksCvk2qw X0ncoizcDNTG4IotQq7fMQNLeRxHQmeSx9RkHB6suNkjTkhpWBxVGg7bjazEQ5nl Cz8PZ+VzGekHS1HYb4ANhXtZqP9Mk/ycdxrGmskNJ8vd0USuI1LRlPWqzzmb9n/3 kl0rVRyikQ1Ch9I= X-Sasl-enc: z048UxXx5EG5Er/sfk6aFA/LBEu/0UWtKfcKv8Pz/7TL 1400189479 Received: from [171.68.20.90] (unknown [171.68.20.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 7CA1868015E for ; Thu, 15 May 2014 17:31:17 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 15 May 2014 14:31:19 -0700 From: Alissa Cooper To: Message-ID: Thread-Topic: AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Faxmd7SId_yCPbuRJEPUPhnJJPU Subject: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 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, 15 May 2014 21:31:31 -0000 I have reviewed draft-ietf-mmusic-rtsp-nat-evaluation-13 and I have a number of comments and questions below that I=E2=80=99d like to see resolved before sending this document to IETF LC. I=E2=80=99ve also included a long list o= f nits below to be resolved along with any LC comments. Overall, although the content of this document is good, I wish the clarity would have been better =E2=80=94 it was quite difficult to review. Comments and questions: General: It might be good in the introduction to characterize the extent to which this document is focused on single-NAT environments versus CGN/multiple NAT. The applicability of the various solutions in CGN environments is touched on here and there, but it would be good to set out the scope at the beginning. There are a number of references to an RSTP server being =E2=80=9Cin the public=E2=80= =9D or =E2=80=9Cpublic.=E2=80=9D I think it would be better in those cases to say that the server is not behind a NAT, as opposed to =E2=80=9Cpublic." Sec 2: "If a client does not receive data within a few seconds after having received the "200 OK" response to a PLAY request, there are likely some middleboxes blocking the traffic.=E2=80=9D This seems like a fairly sweeping statement. Surely the lack of response could be caused by congestion somewhere along the path? I would suggest: "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.=E2=80=9D Sec 3: "In terms of requirements, the first requirement should be to solve the RTSP NAT traversal problem for RTSP servers deployed in a public network, i.e. no NAT at the server side.=E2=80=9D What does =E2=80=9Cthe first requirement=E2=80=9D mean? It seems to me that the analysi= s in Section 4 covers cases where the server is behind a NAT and where it is not. "Should have minimal impact on clients in the open and not dual-hosted." I don=E2=80=99t understand this. What does it mean for a client to be =E2=80=9Cin the open=E2=80=9D? And are you recommending minimal impact only in the case of single-hosted RTSP? Sec 4.1.4: "Using STUN does not require RTSP server modifications=E2=80=9D This is only true for servers that already implement RTSP 2.0. This should be made explicit. Sec 4.2.5: "The removal of STUN capability in the client implementations will have to wait until there is absolutely no need to use STUN.=E2=80=9D I don=E2=80=99t quite get why this text is here. Of course if NAT ever disappears entirely, then none of the mechanisms described in this document will be necessary, but that seems unlikely any time soon. In general, I=E2=80=99m not sure I understand the purpose of the =E2=80=9CTransition=E2=80=9D sections in this document, nor do I understand why they appear for some of the mechanisms but not others. Could the authors provide a justification for that? Sec 4.2.6: The previous section said "See next section for an in-depth security discussion=E2=80=9D and this section just points back to 4.1.5. Was that intentional? Sec 4.3.2: =E2=80=9CHigh performance rather than always successful is recommended, as it is most likely to be a server in the public.=E2=80=9D Not quite sure what this means. I assume the =E2=80=9Cit=E2=80=9D refers to the server = to which the client is connecting? Even so, I don=E2=80=99t understand the claim. Is it that in general RTSP servers are more likely to be directly addressable than they are to be behind a NAT? Sec 4.3.5: For a section that is meant to explain the security properties of this solution choice, this seems a little thin. In particular, it=E2=80=99s not clear what it means to use ICE =E2=80=9Ccorrectly.=E2=80=9D There are some attacks that are o= nly mitigated if RTSP signaling is confidentiality protected =E2=80=94 that=E2=80=99s not really a matter of =E2=80=9Ccorrectness,=E2=80=9D but an implementation choice that deserves mention here. Sec. 4.4.3: "The format of the RTP packet for "connection setup" (a.k.a Latching packet) is yet to be defined. One possibility is to use RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].=E2=80=9D I=E2=80=99m assuming there isn=E2=80=99t actually any plan to define this. If that=E2=80=99s = the case, it would be better to just say so, rather than implying otherwise. The text in 4.5.1 gets this right. Sec 4.5.1: "Latching as described above requires the usage of a valid RTP format as the Latching packet, i.e. the first packet that the client sends to the server to set up virtual RTP connection. Need different phrasing for =E2=80=9Cvirtual RTP connection=E2=80=9D =E2=80=94 it=E2=80=99s not act= ually virtual. Sec 4.7.4: "An ALG will not work with deployment of end-to-end RTSP signaling security. Therefore deployment of ALG will likely result in clients located behind NATs not using end-to-end security.=E2=80=9D Not sure that=E2=80=99s the only conclusion to be drawn here, particularly if the client can traverse the NAT using some other mechanism. Sec 4.9.1: "This means that TURN could only be used if the server knows and accepts that the IP belongs to a TURN server and the TURN server can't be targeted at an unknown address or also the RTSP connection is relayed through the same TURN server.=E2=80=9D Not sure what is meant by the clause that begins =E2=80=9Cor also.=E2=80=9D Sec 5: Is it worth noting here the implications for firewalls when RTSP uses confidentiality protection? Sec 6: Why are C1 and C2 not discussed in Section 3? Sec 8: Conspicuously missing from this section is a discussion of the security properties of ICE. Given that it is the chosen mechanism, those need to be discussed here, at least at the same cursory level as the security considerations for all of the other mechanisms. --- Nits to be resolved with any IETF last call comments received: General: =E2=80=9CFirewall" should not be capitalized unless it appears at the beginning o= f a sentence or in the title of referenced document. Sec 1: s/This document is capturing/This document captures/ Sec 2: s/techniques in the next chapter/techniques discussed in the next section/ s/A RTP session/An RTP session/ s/no RTP packets has arrived/no RTP packets have arrived/ s/client can not get through/client cannot get through/ Section 3: s/for RTSP NAT solutions/for RTSP NAT traversal solutions/ s/connection till arrival/connection until arrival/ Sec 4.1.2: s/See [RFC4787] for full definition of these terms.// (terms are also defined in this document s/A RTSP client/An RTSP client/ s/a NAT(s)/a NAT/ s/a RTSP PLAY request/an RTSP PLAY request/ Sec 4.1.4: s/a RTSP-aware ALG /an RTSP-aware ALG / Sec 4.2.2: s/one of the can/one of them can/ s/establishing TCP connection/establishing a TCP connection/ Sec 4.2.5: s/a IETF standard/an IETF standard/ Sec 4.4: s/Latching/latching/ (throughout the document) Sec 4.4.3: s/an public IP address./a public IP address./ Sec. 4.4.4: s/the possible address a latching packet can come from to the same as the RTSP TCP connection are from/the source address of a latching packet to be the same as the source address of the RTSP TCP connection/ s/it is difficult to determine the address usage for the network the client connects from./it cannot be assumed that addresses within the range all belong to the same client./ s/the server will send from and also the SSRC the client will use./that the server will send from and that the SSRC client will use./ s/Having this information/Having this information,/ s/legit/legitimate/ (two occurrences) s/which results in that the media server sends the RTP/RTCP traffic to ports the client isn=E2=80=99t listening for RTP/RTCP on./which results in the media server sending the RTP/RTCP traffic to ports on which the client is not listening for RTP/RTCP./ s/client to server network path/client-to-server network path/ s/To improve the security against attackers/To improve the security against attackers,/ Sec. 4.5.1: s/[I-D.ietf-avt-rtp-no-op], however, that work was abandoned./[I-D.ietf-avt-rtp-no-op]. However, that work was abandoned./ OLD: There exists a RFC that discusses the implication of different type of packets as keep-alives for RTP [RFC6263] and its findings are very relevant to the format of the Latching packet. NEW: The findings of [RFC6263] concerning the implications of different types of packets as keep-alives for RTP are very relevant to the format of the Latching packet. s/there has been/there have been/ Sec. 4.5.2: s/so called/so-called/ s/as Latching packet/as a Latching packet/ Sec 4.5.3: s/(Requirement 4 in Section 3), instead a Latching protocol must be defined./(Requirement 4 in Section 3). Instead a Latching protocol must be defined./ Sec 4.5.4: s/more unlikely/less likely/ s/works and when it didn=E2=80=99t/worked and when it did not/ s/security issue remain/security issue remains/ s/a RTSP client/an RTSP client/ s/likes to/intends to/ s/an DoS target/a DoS target/ Sec 4.6: s/three way Latching/three-way latching/ (throughout) Sec 4.6.2: s/Uses the same RTSP extensions/Three-way latching uses the same RTSP extensions/ s/client to server latching packet/client-to-server latching packet/ s/an UDP packet/a UDP packet/ s/nonce. Thus confirming/nonce, thus confirming/ s/a RTSP client/an RTSP client/ Sec 4.6.3: s/have the following/has the following/ Sec 4.7.4: s/an UDP mapping/a UDP mapping/ s/with RTSP ALG/with an RTSP ALG/ Sec 4.8.3: s/where the RTSP server in not NATed or at least reachable like it was not./where the RTSP server is not NATed or is reachable as if it were not NATed./ Sec 4.9.1: s/a RTSP client/an RTSP client/ s/the IP belongs/the IP address belongs/ Sec 4.9.2: s/addresses also the TCP connection must be done through the same TURN server as the one in the next step./addresses, the TCP connection must be made through the same TURN server to be used for NAT traversal./ s/that it desires/where it desires/ Sec 4.9.3: s/has public/has a public/ Sec 4.9.4: s/a RTSP session/an RTSP session/ s/Which would/This would/ Sec 5: s/a RTSP session/an RTSP session/ s/what type of transport and from where, the media stream packets will be sent./what type of transport will be used and from where the media stream packets will be sent./ Sec 6: s/R1: Work/R1: Must work/ s/use, Implement and administer/use, implement and administer/ OLD: C1: Will solution support both Clients and Servers behind NAT C2: Is the solution robust to changing NAT behaviors NEW: C1: Supports both clients and servers behind NAT C2: Is robust to changing NAT behaviors s/using TCP Tunneling or Three-Way Latching is the solutions that best fulfill/TCP Tunneling or Three-Way Latching is the solution that best fulfills/ s/is acceptable/are acceptable/ s/When it comes to Three-Way Latching it is a very competitive technique given that you don't need support for RTSP servers behind NATs./Three-Way Latching is a comparable technique in situations where support for RTSP servers behind NATs is not required./ s/were some discussion/were some discussions/ s/In the end the authors believe that reuse of ICE, the greater flexibility and anyway need to deploy a new solution was the decisive factors./In the end, the WG concluded that reuse of ICE, its greater flexibility, and the need to deploy a new solution in either case were the decisive factors in favor of ICE./ Sec 8: s/IP-address/IP address/ s/those variants/of those variants/ Sec 9: s/has commented/have commented/ s/protocol/document/ From nobody Fri May 16 04:05: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 D0B2A1A021A for ; Fri, 16 May 2014 04:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QPSFmRRpac2n for ; Fri, 16 May 2014 04:05:04 -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 257DE1A021C for ; Fri, 16 May 2014 04:05:02 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-86-5375f0d5e52a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7B.6F.04199.5D0F5735; Fri, 16 May 2014 13:04:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.174.1; Fri, 16 May 2014 13:04:53 +0200 Message-ID: <5375F0D5.9060302@ericsson.com> Date: Fri, 16 May 2014 13:04:53 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alissa Cooper , References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje61D6XBBg+aBS2mn/nLaDF1+WMW ByaPL09eMnksWfKTKYApissmJTUnsyy1SN8ugSvj5M6igl2ZFXfPn2FsYDwa1MXIySEhYCJx +EwPO4QtJnHh3no2EFtI4CijxMaPXl2MXED2ckaJ9pZ1YEW8AtoSp3fvYOxi5OBgEVCVuLZQ AyTMJmAhcfNHI1ivqECwxIaHf6HKBSVOznzCAmKLANWc//uJFcQWFvCVuP9wESvIGCEBXYnz q91AwpwCehL7/sxnAglLCIhL9DSCXcksoCnRuv03O4QtL9G8dTYzxJXaEg1NHawTGAVnIVk2 C0nLLCQtCxiZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIEhunBLb8NdjC+fO54iFGAg1GJ h/eBRWmwEGtiWXFl7iFGaQ4WJXHe27uAQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhLSgrl Ajsv+O+84yxS/eCz6s3FUWubFncalJxemJ7tVe/6q+/BtafRR1m0NXKPXFyzNn9F9ryuq28r YqZGxT9ljss43hMguklS4M8Whbdv9+ZrBn499FnTv11w//OpLSeS3138883op84Ev6vJcYWW LbkFfA/SWtZ/uC3/lNtz5gQT2YhQPzYlluKMREMt5qLiRABvK+tpNAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4AjOXtrfFfvb5myPtlM2lKOv3aA Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 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, 16 May 2014 11:05:08 -0000 Alissa, WG, Thanks for the review. I will attempt to address these before my parental leave that starts at the end of the month, but I am uncertain if I will be able. So in worst case this might be left hanging for the rest of the year for your knowledge. My co-author is also not any longer an active participant in the IETF. Cheers Magnus On 2014-05-15 23:31, Alissa Cooper wrote: > I have reviewed draft-ietf-mmusic-rtsp-nat-evaluation-13 and I have a > number of comments and questions below that I’d like to see resolved > before sending this document to IETF LC. I’ve also included a long list of > nits below to be resolved along with any LC comments. Overall, although > the content of this document is good, I wish the clarity would have been > better — it was quite difficult to review. > > Comments and questions: > > General: > It might be good in the introduction to characterize the extent to which > this document is focused on single-NAT environments versus CGN/multiple > NAT. The applicability of the various solutions in CGN environments is > touched on here and there, but it would be good to set out the scope at > the beginning. > > There are a number of references to an RSTP server being “in the public†> or “public.†I think it would be better in those cases to say that the > server is not behind a NAT, as opposed to “public." > > Sec 2: > "If a client does not receive data within a few seconds after > having received the "200 OK" response to a PLAY request, there are > likely some middleboxes blocking the traffic.†> > This seems like a fairly sweeping statement. Surely the lack of response > could be caused by congestion somewhere along the path? I would suggest: > > "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.†> > > Sec 3: > "In terms of requirements, the > first requirement should be to solve the RTSP NAT traversal problem > for RTSP servers deployed in a public network, i.e. no NAT at the > server side.†> > What does “the first requirement†mean? It seems to me that the analysis > in Section 4 covers cases where the server is behind a NAT and where it is > not. > > "Should have minimal impact on clients in the open and not dual-hosted." > > I don’t understand this. What does it mean for a client to be “in the > open� And are you recommending minimal impact only in the case of > single-hosted RTSP? > > Sec 4.1.4: > "Using STUN does not require RTSP server modifications†> > This is only true for servers that already implement RTSP 2.0. This should > be made explicit. > > Sec 4.2.5: > "The removal of STUN capability in > the client implementations will have to wait until there is > absolutely no need to use STUN.†> > I don’t quite get why this text is here. Of course if NAT ever disappears > entirely, then none of the mechanisms described in this document will be > necessary, but that seems unlikely any time soon. > > In general, I’m not sure I understand the purpose of the “Transition†> sections in this document, nor do I understand why they appear for some of > the mechanisms but not others. Could the authors provide a justification > for that? > > Sec 4.2.6: > The previous section said "See next section for an in-depth security > discussion†and this section just points back to 4.1.5. Was that > intentional? > > Sec 4.3.2: > “High performance rather than always successful is recommended, as it > is most likely to be a server in the public.†> > Not quite sure what this means. I assume the “it†refers to the server to > which the client is connecting? Even so, I don’t understand the claim. Is > it that in general RTSP servers are more likely to be directly addressable > than they are to be behind a NAT? > > Sec 4.3.5: > For a section that is meant to explain the security properties of this > solution choice, this seems a little thin. In particular, it’s not clear > what it means to use ICE “correctly.†There are some attacks that are only > mitigated if RTSP signaling is confidentiality protected — that’s not > really a matter of “correctness,†but an implementation choice that > deserves mention here. > > Sec. 4.4.3: > "The format of the RTP packet for "connection setup" (a.k.a > Latching packet) is yet to be defined. One possibility is to use > RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].†> > I’m assuming there isn’t actually any plan to define this. If that’s the > case, it would be better to just say so, rather than implying otherwise. > The text in 4.5.1 gets this right. > > Sec 4.5.1: > "Latching as described above requires the usage of a valid RTP format > as the Latching packet, i.e. the first packet that the client sends > to the server to set up virtual RTP connection. > > Need different phrasing for “virtual RTP connection†— it’s not actually > virtual. > > Sec 4.7.4: > "An ALG will not work with deployment of end-to-end RTSP signaling > security. Therefore deployment of ALG will likely result in clients > located behind NATs not using end-to-end security.†> > Not sure that’s the only conclusion to be drawn here, particularly if the > client can traverse the NAT using some other mechanism. > > Sec 4.9.1: > "This means that TURN could only be used if the server knows and > accepts that the IP belongs to a TURN server and the TURN server > can't be targeted at an unknown address or also the RTSP connection > is relayed through the same TURN server.†> > Not sure what is meant by the clause that begins “or also.†> > Sec 5: > Is it worth noting here the implications for firewalls when RTSP uses > confidentiality protection? > > Sec 6: > Why are C1 and C2 not discussed in Section 3? > > Sec 8: > Conspicuously missing from this section is a discussion of the security > properties of ICE. Given that it is the chosen mechanism, those need to be > discussed here, at least at the same cursory level as the security > considerations for all of the other mechanisms. > > --- > > Nits to be resolved with any IETF last call comments received: > > General: > “Firewall" should not be capitalized unless it appears at the beginning of > a sentence or in the title of referenced document. > > Sec 1: > s/This document is capturing/This document captures/ > > Sec 2: > s/techniques in the next chapter/techniques discussed in the next section/ > > s/A RTP session/An RTP session/ > > s/no RTP packets has arrived/no RTP packets have arrived/ > > s/client can not get through/client cannot get through/ > > Section 3: > s/for RTSP NAT solutions/for RTSP NAT traversal solutions/ > > s/connection till arrival/connection until arrival/ > > Sec 4.1.2: > s/See [RFC4787] for full definition of these terms.// > (terms are also defined in this document > > s/A RTSP client/An RTSP client/ > > s/a NAT(s)/a NAT/ > > s/a RTSP PLAY request/an RTSP PLAY request/ > > Sec 4.1.4: > s/a RTSP-aware ALG /an RTSP-aware ALG / > > Sec 4.2.2: > s/one of the can/one of them can/ > > s/establishing TCP connection/establishing a TCP connection/ > > Sec 4.2.5: > s/a IETF standard/an IETF standard/ > > Sec 4.4: > s/Latching/latching/ (throughout the document) > > Sec 4.4.3: > s/an public IP address./a public IP address./ > > Sec. 4.4.4: > s/the possible address a latching packet can come from to the same as the > RTSP TCP connection are from/the source address of a latching packet to be > the same as the source address of the RTSP TCP connection/ > > s/it is difficult to determine the address usage for the network the > client connects from./it cannot be assumed that addresses within the range > all belong to the same client./ > > s/the server will send from and also the SSRC the client will use./that > the server will send from and that the SSRC client will use./ > > s/Having this information/Having this information,/ > > s/legit/legitimate/ > (two occurrences) > > s/which results in that the media server sends the RTP/RTCP traffic to > ports the client isn’t listening for RTP/RTCP on./which results in the > media server sending the RTP/RTCP traffic to ports on which the client is > not listening for RTP/RTCP./ > > s/client to server network path/client-to-server network path/ > > s/To improve the security against attackers/To improve the security > against attackers,/ > > Sec. 4.5.1: > s/[I-D.ietf-avt-rtp-no-op], however, that work was > abandoned./[I-D.ietf-avt-rtp-no-op]. However, that work was abandoned./ > > OLD: > There exists a RFC that discusses the implication of different type of > packets as keep-alives for RTP [RFC6263] and its findings are very > relevant to the format of the Latching packet. > > NEW: > The findings of [RFC6263] concerning the implications of different types > of packets as keep-alives for RTP are very relevant to the format of the > Latching packet. > > s/there has been/there have been/ > > Sec. 4.5.2: > s/so called/so-called/ > > s/as Latching packet/as a Latching packet/ > > Sec 4.5.3: > s/(Requirement 4 in Section 3), instead a Latching protocol must be > defined./(Requirement 4 in Section 3). Instead a Latching protocol must be > defined./ > > Sec 4.5.4: > s/more unlikely/less likely/ > > s/works and when it didn’t/worked and when it did not/ > > s/security issue remain/security issue remains/ > > s/a RTSP client/an RTSP client/ > > s/likes to/intends to/ > > s/an DoS target/a DoS target/ > > Sec 4.6: > s/three way Latching/three-way latching/ (throughout) > > Sec 4.6.2: > s/Uses the same RTSP extensions/Three-way latching uses the same RTSP > extensions/ > > s/client to server latching packet/client-to-server latching packet/ > > s/an UDP packet/a UDP packet/ > > s/nonce. Thus confirming/nonce, thus confirming/ > > s/a RTSP client/an RTSP client/ > > Sec 4.6.3: > s/have the following/has the following/ > > Sec 4.7.4: > s/an UDP mapping/a UDP mapping/ > > s/with RTSP ALG/with an RTSP ALG/ > > Sec 4.8.3: > s/where the RTSP server in not NATed or at least reachable like it was > not./where the RTSP server is not NATed or is reachable as if it were not > NATed./ > > Sec 4.9.1: > s/a RTSP client/an RTSP client/ > > s/the IP belongs/the IP address belongs/ > > Sec 4.9.2: > s/addresses also the TCP connection must be done through the same TURN > server as the one in the next step./addresses, the TCP connection must be > made through the same TURN server to be used for NAT traversal./ > > s/that it desires/where it desires/ > > Sec 4.9.3: > s/has public/has a public/ > > Sec 4.9.4: > s/a RTSP session/an RTSP session/ > > s/Which would/This would/ > > Sec 5: > s/a RTSP session/an RTSP session/ > > > s/what type of transport and from where, the media stream packets will be > sent./what type of transport will be used and from where the media stream > packets will be sent./ > > Sec 6: > s/R1: Work/R1: Must work/ > > s/use, Implement and administer/use, implement and administer/ > > OLD: > C1: Will solution support both Clients and Servers behind NAT > > C2: Is the solution robust to changing NAT behaviors > NEW: > > C1: Supports both clients and servers behind NAT > > C2: Is robust to changing NAT behaviors > > s/using TCP Tunneling or Three-Way Latching is the solutions that best > fulfill/TCP Tunneling or Three-Way Latching is the solution that best > fulfills/ > > s/is acceptable/are acceptable/ > > s/When it comes to Three-Way Latching it is a very competitive technique > given that you don't need support for RTSP servers behind NATs./Three-Way > Latching is a comparable technique in situations where support for RTSP > servers behind NATs is not required./ > > s/were some discussion/were some discussions/ > > s/In the end the authors believe that reuse of ICE, the greater > flexibility and anyway need to deploy a new solution was the decisive > factors./In the end, the WG concluded that reuse of ICE, its greater > flexibility, and the need to deploy a new solution in either case were the > decisive factors in favor of ICE./ > > Sec 8: > s/IP-address/IP address/ > > s/those variants/of those variants/ > > Sec 9: > s/has commented/have commented/ > > s/protocol/document/ > > > > > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri May 16 06:36:15 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 756BB1A021A for ; Fri, 16 May 2014 06:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4SpsMSkwQkHS for ; Fri, 16 May 2014 06:36:10 -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 4931D1A019E for ; Fri, 16 May 2014 06:36:10 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-e3-5376144151d3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 58.63.05409.14416735; Fri, 16 May 2014 15:36:01 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Fri, 16 May 2014 15:36:00 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BE44B1101FF; Fri, 16 May 2014 16:36:00 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6833C4E8F9; Fri, 16 May 2014 16:35:58 +0300 (EEST) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1358F4E857; Fri, 16 May 2014 16:35:58 +0300 (EEST) Message-ID: <53761440.2000605@ericsson.com> Date: Fri, 16 May 2014 16:36:00 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.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+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja6jSFmwwYltUhbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyrjY+p+t4A5zxb+zd1kaGH8xdTFyckgImEj8 nXuGDcIWk7hwbz2QzcUhJHCUUWLdwX4mCGcDo0Tzs13MIFVCAnsZJVbNNYBIrGOUWHHiCFTL CkaJ9S9esIJU8QpoS9xa8QVsB4uAqsShlnlgcTYBe4mbE66zg9iiAskStzd+ZYKoF5Q4OfMJ C4gtIiAjsXfTZrBtzEBzZt+ZBVYjLGAr8Xz/bXaIuK3EhTnXWSBseYntb+cwQ/ygJnH13Cao S1Ulrv57xTiBUXgWkhWzkLTPQtK+gJF5FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgiB/c 8lt1B+PlN46HGAU4GJV4eB9YlAYLsSaWFVfmHmKU5mBREue9vQsoJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgTHxx4E3rd6VHDWGYuu/zYst5mF9Vb/1pMa13L6HR+ebf3tRWfa2PkXl4upf NwXWrkt9+UG1J+So7eVaza6y7I28jxKYn2g8EdiY7p6lt6qP5z9HSF60s5zTyoPOobO9ensX JF6Mmqf64mDBsicr9LhFzraVFYokmjrs4tcSUFww8f5Vc6XYy0osxRmJhlrMRcWJAJwtRrNS AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fJSN9E3K1va0x_IkNrZo6vUY-2g Cc: Flemming Andreasen Subject: [MMUSIC] Liason statement from IMTC SIP Parity Activity Group 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, 16 May 2014 13:36:13 -0000 Hi all, The IETF has received a liaison statement from the IMTC SIP Parity Activity Group: https://datatracker.ietf.org/liaison/1323/ The AVTCORE and MMUSIC chairs are considering a reply to the liaison. If you want to provide feedback on the specification that you consider suitable to come from the WG, please provide such suggestions no later than end of next week (25th of May). The deadline for any reply is the 30th of May. Thanks, Ari & Flemming From nobody Sun May 18 20:38: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 E5C3C1A027D for ; Sun, 18 May 2014 20:38:07 -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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_PORT=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 2n7OTHUDFvpk for ; Sun, 18 May 2014 20:38:05 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DA61A0019 for ; Sun, 18 May 2014 20:38:05 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jx11so5916479veb.0 for ; Sun, 18 May 2014 20:38:05 -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=dkzV6EV0rsj4a1dOWvvFGfUGwl/QFrc8Ge8YQ+Am3UY=; b=kmzAqmEZB79XYFVZleOJyLo4eK2Fd2Ubv3DAH5Yuasyi4Yb1WtxhbSkwNqwCwkDx+W zbQGEYShb6l0V1il5MI8MboeVnlnENj1LLlv1rn5u81QEQiPGMS2yqaLmM8yxEAuEDL3 2JSYVFOyv63TVDzwcNQ1MSK9iceHqSYhBsgZnCoMN1ivkqyYwQo/+LbLEwN6OJ9DBnbs Kcgw2qBoYYrNeN4XgXg68B3gDeFGGiTCoWm66dODIsuRVYjNTJLyUR4zPEMAFCS37jeF a1xtrRkUg75dkckRzkaT5waCTJ+9HczW70RZpXbfpjNDofLP02jRpIfS/QLtuE/bj99i OPyQ== 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=dkzV6EV0rsj4a1dOWvvFGfUGwl/QFrc8Ge8YQ+Am3UY=; b=haeqjC0KYh/3sKkWx4Sucpj5e0TpwIdD/AhDD1CWqmGCiMRldmlTevczcKA9fSFW7N 2QXduvJGx04GFauh8lJKjNQPDLu0tDWlDCB1PgSrdsp8Elrtxw8bcwZZ2TN8R/Ik+2Sf uHvx2du0jyoyPqpowgS0d5dgfBt1wyJm9sCIyBoykygP9e5pW3ae7Opch1Oad8acNr2J 8jE1PBYxWCgONSAA1qmgvL7iDvKJkp4cjHV9f8w0a36E/aBasT/Fmbi+dlO/0w8Ke11a Il3/7zFa4cyXnzheDSJiFJEH2Gqks1B78h27mfDjqdF2pv+ucIILCNIPlwDUkxTuuxQZ DXmg== X-Gm-Message-State: ALoCoQlWU7bsdCvyD3S6I3aAamtIhJyEI8H11tErnB1gUPbgynmJjvLEEiVw0i+L0b+OFk9H88LO X-Received: by 10.220.163.3 with SMTP id y3mr12031652vcx.7.1400470684864; Sun, 18 May 2014 20:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.145.105 with HTTP; Sun, 18 May 2014 20:37:44 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D2F672A@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 18 May 2014 20:37:44 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1133da66b0b0b004f9b87d20 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MztaeJpnr6doJQUNWln6FvaaVY4 Cc: "rtcweb@ietf.org" , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] [rtcweb] m-line recycling 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, 19 May 2014 03:38:08 -0000 --001a1133da66b0b0b004f9b87d20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One option could be to only reuse m=3D lines that both sides have stopped using (i.e. port=3D0, as opposed to a=3Dsendonly/recvonly). This provides m= ost of the benefits of recycling without having to deal with the notion of 'compatible'. On Mon, May 12, 2014 at 7:43 AM, Martin Thomson w= rote: > Yes, some words about being compatible and all that entails are required > if we intend to stipulate it being reused. Either that or we can say MAY. > The need for a strong definition diminishes then. > On May 11, 2014 11:54 PM, "Christer Holmberg" < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> I don=E2=80=99t think it should be a MUST =E2=80=93 at least not only ba= sed on the media >> type. Because, there may be other properties than the media type associa= ted >> with the =E2=80=9Cm=3D=E2=80=9D line, why one does not want to use it fo= r the specific MST. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Eric >> Rescorla >> *Sent:* 12. toukokuuta 2014 7:50 >> *To:* mmusic WG; rtcweb@ietf.org >> *Subject:* [MMUSIC] m-line recycling >> >> >> >> The JSEP spec specifies m-line recycling: >> >> >> >> >> >> >> >> o If any MediaStreamTracks have been added, and there exist m=3D >> >> sections of the appropriate media type with no associated >> >> MediaStreamTracks (i.e. as described in the preceding paragraph), >> >> those m=3D sections MUST be recycled by adding the new >> >> MediaStreamTrack to the m=3D section. This is done by adding the >> >> necessary "a=3Dmsid", "a=3Dssrc", and "a=3Dssrc-group" lines to th= e >> >> recycled m=3D section, and removing the "a=3Drecvonly" attribute. >> >> Based on the minutes from IETF 89, we were going to take this to mmusic. >> >> http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-rtcweb?useMonospaceF= ont=3Dtrue >> >> >> >> >> Thoughts? >> >> -Ekr >> >> >> >> https://github.com/rtcweb-wg/jsep/issues/21 >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1133da66b0b0b004f9b87d20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One option could be to only reuse m=3D lines that both sid= es have stopped using (i.e. port=3D0, as opposed to a=3Dsendonly/recvonly).= This provides most of the benefits of recycling without having to deal wit= h the notion of 'compatible'.


On Mon, May 1= 2, 2014 at 7:43 AM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:

Yes, some words about being c= ompatible and all that entails are required if we intend to stipulate it be= ing reused. Either that or we can say MAY. The need for a strong definition= diminishes then.

On May 11, 2014 11:54 PM,= "Christer Holmberg" <christer.holmberg@ericsson.com> wrote:

Hi,<= /p>

=C2=A0

I don=E2=80=99t think it = should be a MUST =E2=80=93 at least not only based on the media type. Becau= se, there may be other properties than the media type associated with the =E2=80=9Cm=3D=E2=80=9D line, why one does not want to use it for the speci= fic MST.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

From: mmusic [= mailto:mmusic-= bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 12. toukokuuta 2014 7:50
To: mmusic WG; = rtcweb@ietf.org
Subject: [MMUSIC] m-line recycling

=C2=A0

The JSEP spec specifies m-line recycling:=

=C2=A0

=C2=A0
=C2=A0
 o=C2=A0 If any MediaStreamTracks have been added, and there exi=
st m=3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sections of the appropriate media=
 type with no associated
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTracks (i.e. as descri=
bed in the preceding paragraph),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 those m=3D sections MUST be recyc=
led by adding the new
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTrack to the m=3D sect=
ion.=C2=A0 This is done by adding the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary "a=3Dmsid", &=
quot;a=3Dssrc", and "a=3Dssrc-group" lines to the<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 recycled m=3D section, and removi=
ng the "a=3Drecvonly" attribute.
Based=C2=A0o=
n the minutes from IETF 89, we were going to take this to mmusic.=

http://etherpad.tools.ietf.org:9000/p/notes-ietf=
-89-rtcweb?useMonospaceFont=3Dtrue




=C2=A0
Thoughts?<=
u>
-Ekr

=C2=A0


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


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


--001a1133da66b0b0b004f9b87d20-- From nobody Sun May 18 21:50: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 4A3831A025C; Sun, 18 May 2014 21:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, WEIRD_PORT=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 r5Zte6XzMyyf; Sun, 18 May 2014 21:49:54 -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 2AD531A024F; Sun, 18 May 2014 21:49:52 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-79-53798d6e041b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.09.04199.E6D89735; Mon, 19 May 2014 06:49:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Mon, 19 May 2014 06:49:50 +0200 From: Christer Holmberg To: Justin Uberti , Martin Thomson Thread-Topic: [MMUSIC] [rtcweb] m-line recycling Thread-Index: AQHPcxO/Dvl2zS/bFU6AGA4jR2LlDZtHVMJw Date: Mon, 19 May 2014 04:49:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D321F5B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2F672A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D321F5BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM+JvjW5+b2Wwwctf7BZbpwpZXDvzj9Fi 6vLHLBZr/7WzO7B47Jx1l91jwaZSjyVLfjIFMEdx2aSk5mSWpRbp2yVwZfStmcBWcGM1Y0Xb pAdsDYwTljN2MXJySAiYSBx9vwTKFpO4cG89WxcjF4eQwFFGiV9vjzNCOIsZJTbe7mPuYuTg YBOwkOj+pw1iiggES3w5pALSyyzgInFh6mMmEFtYQF9i7d7HLCC2iICBxJ3OGYwQtpHErom3 wGwWAVWJozv3sYPYvAK+EtMPNkKtWsQk0b7tK9gqToFAiZ/rFUBqGIFu+35qDRPELnGJW0/m M0HcLCCxZM95ZghbVOLl43+sELaSROOSJ6wQ9fkSr3fvZYTYJShxcuYTlgmMorOQjJqFpGwW krJZQFcwC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxUm56UZGeqlFmcnFxfl5 enmpJZsYgZF4cMtvgx2ML587HmIU4GBU4uFdkFoZLMSaWFZcmXuIUZqDRUmc9/au0mAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjEYnrO6GXLr3Z456nnTEevNDVmLR9UfrpkZ8F92595vk bwa5Qpf1XUzWmTtZF3BuW7nEQin54pHbj7zmZ2/rlPLxKL5RaK8fy65i9NfJYu7c4t+trOu6 zlU/96zZ0XFBcJPgnnuKIT/ZLt5513nsYFVvxH7TgBlfQx1NZ3JkHNZaddE46EJgixJLcUai oRZzUXEiAJ+tcp+lAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ktC5gJKtwNMHFPdlQJDyAKfK4Qo Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] m-line recycling 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, 19 May 2014 04:49:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D321F5BESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KPk9uZSBvcHRpb24gY291bGQgYmUgdG8gb25seSByZXVzZSBtPSBsaW5lcyB0aGF0 IGJvdGggc2lkZXMgaGF2ZSBzdG9wcGVkIHVzaW5nIChpLmUuIHBvcnQ9MCwgYXMgPm9wcG9zZWQg dG8gYT1zZW5kb25seS9yZWN2b25seSkuIFRoaXMgcHJvdmlkZXMgbW9zdCBvZiB0aGUgYmVuZWZp dHMgb2YgcmVjeWNsaW5nIHdpdGhvdXQgPmhhdmluZyB0byBkZWFsIHdpdGggdGhlIG5vdGlvbiBv ZiAnY29tcGF0aWJsZScuDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyBhIE1VU1QgcmV1c2Ugc3VjaCBt PSBsaW5lLCBpZiBhdmFpbGFibGU/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCk9uIE1vbiwg TWF5IDEyLCAyMDE0IGF0IDc6NDMgQU0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpZZXMs IHNvbWUgd29yZHMgYWJvdXQgYmVpbmcgY29tcGF0aWJsZSBhbmQgYWxsIHRoYXQgZW50YWlscyBh cmUgcmVxdWlyZWQgaWYgd2UgaW50ZW5kIHRvIHN0aXB1bGF0ZSBpdCBiZWluZyByZXVzZWQuIEVp dGhlciB0aGF0IG9yIHdlIGNhbiBzYXkgTUFZLiBUaGUgbmVlZCBmb3IgYSBzdHJvbmcgZGVmaW5p dGlvbiBkaW1pbmlzaGVzIHRoZW4uDQpPbiBNYXkgMTEsIDIwMTQgMTE6NTQgUE0sICJDaHJpc3Rl ciBIb2xtYmVyZyIgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSSBkb27igJl0IHRoaW5r IGl0IHNob3VsZCBiZSBhIE1VU1Qg4oCTIGF0IGxlYXN0IG5vdCBvbmx5IGJhc2VkIG9uIHRoZSBt ZWRpYSB0eXBlLiBCZWNhdXNlLCB0aGVyZSBtYXkgYmUgb3RoZXIgcHJvcGVydGllcyB0aGFuIHRo ZSBtZWRpYSB0eXBlIGFzc29jaWF0ZWQgd2l0aCB0aGUg4oCcbT3igJ0gbGluZSwgd2h5IG9uZSBk b2VzIG5vdCB3YW50IHRvIHVzZSBpdCBmb3IgdGhlIHNwZWNpZmljIE1TVC4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBFcmlj IFJlc2NvcmxhDQpTZW50OiAxMi4gdG91a29rdXV0YSAyMDE0IDc6NTANClRvOiBtbXVzaWMgV0c7 IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogW01NVVNJ Q10gbS1saW5lIHJlY3ljbGluZw0KDQpUaGUgSlNFUCBzcGVjIHNwZWNpZmllcyBtLWxpbmUgcmVj eWNsaW5nOg0KDQoNCg0KDQoNCg0KIG8gIElmIGFueSBNZWRpYVN0cmVhbVRyYWNrcyBoYXZlIGJl ZW4gYWRkZWQsIGFuZCB0aGVyZSBleGlzdCBtPQ0KDQogICAgICBzZWN0aW9ucyBvZiB0aGUgYXBw cm9wcmlhdGUgbWVkaWEgdHlwZSB3aXRoIG5vIGFzc29jaWF0ZWQNCg0KICAgICAgTWVkaWFTdHJl YW1UcmFja3MgKGkuZS4gYXMgZGVzY3JpYmVkIGluIHRoZSBwcmVjZWRpbmcgcGFyYWdyYXBoKSwN Cg0KICAgICAgdGhvc2UgbT0gc2VjdGlvbnMgTVVTVCBiZSByZWN5Y2xlZCBieSBhZGRpbmcgdGhl IG5ldw0KDQogICAgICBNZWRpYVN0cmVhbVRyYWNrIHRvIHRoZSBtPSBzZWN0aW9uLiAgVGhpcyBp cyBkb25lIGJ5IGFkZGluZyB0aGUNCg0KICAgICAgbmVjZXNzYXJ5ICJhPW1zaWQiLCAiYT1zc3Jj IiwgYW5kICJhPXNzcmMtZ3JvdXAiIGxpbmVzIHRvIHRoZQ0KDQogICAgICByZWN5Y2xlZCBtPSBz ZWN0aW9uLCBhbmQgcmVtb3ZpbmcgdGhlICJhPXJlY3Zvbmx5IiBhdHRyaWJ1dGUuDQoNCkJhc2Vk IG9uIHRoZSBtaW51dGVzIGZyb20gSUVURiA4OSwgd2Ugd2VyZSBnb2luZyB0byB0YWtlIHRoaXMg dG8gbW11c2ljLg0KDQpodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL25vdGVz LWlldGYtODktcnRjd2ViP3VzZU1vbm9zcGFjZUZvbnQ9dHJ1ZQ0KDQoNCg0KDQoNCg0KDQoNCg0K DQpUaG91Z2h0cz8NCg0KLUVrcg0KDQpodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAv aXNzdWVzLzIxDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMg bWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D321F5BESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+T25lIG9wdGlvbiBj b3VsZCBiZSB0byBvbmx5IHJldXNlIG09IGxpbmVzIHRoYXQgYm90aCBzaWRlcyBoYXZlIHN0b3Bw ZWQgdXNpbmcgKGkuZS4gcG9ydD0wLCBhcw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZn dDs8L3NwYW4+b3Bwb3NlZCB0byBhPXNlbmRvbmx5L3JlY3Zvbmx5KS4gVGhpcyBwcm92aWRlcyBt b3N0IG9mIHRoZSBiZW5lZml0cyBvZiByZWN5Y2xpbmcgd2l0aG91dA0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+aGF2aW5nIHRvIGRlYWwgd2l0aCB0aGUgbm90aW9uIG9m ICdjb21wYXRpYmxlJy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJlIHlvdSBzdWdnZXN0aW5n IGEgTVVTVCByZXVzZSBzdWNoIG09IGxpbmUsIGlmIGF2YWlsYWJsZT88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTW9uLCBNYXkgMTIsIDIwMTQgYXQgNzo0MyBBTSwgTWFydGluIFRob21z b24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHA+WWVzLCBzb21lIHdvcmRzIGFib3V0IGJlaW5nIGNvbXBhdGlibGUgYW5kIGFsbCB0aGF0IGVu dGFpbHMgYXJlIHJlcXVpcmVkIGlmIHdlIGludGVuZCB0byBzdGlwdWxhdGUgaXQgYmVpbmcgcmV1 c2VkLiBFaXRoZXIgdGhhdCBvciB3ZSBjYW4gc2F5IE1BWS4gVGhlIG5lZWQgZm9yIGEgc3Ryb25n IGRlZmluaXRpb24gZGltaW5pc2hlcyB0aGVuLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkgMTEsIDIwMTQgMTE6NTQgUE0s ICZxdW90O0NocmlzdGVyIEhvbG1iZXJnJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBpdCBzaG91bGQg YmUgYSBNVVNUIOKAkyBhdCBsZWFzdCBub3Qgb25seSBiYXNlZCBvbiB0aGUgbWVkaWEgdHlwZS4g QmVjYXVzZSwNCiB0aGVyZSBtYXkgYmUgb3RoZXIgcHJvcGVydGllcyB0aGFuIHRoZSBtZWRpYSB0 eXBlIGFzc29jaWF0ZWQgd2l0aCB0aGUg4oCcbT3igJ0gbGluZSwgd2h5IG9uZSBkb2VzIG5vdCB3 YW50IHRvIHVzZSBpdCBmb3IgdGhlIHNwZWNpZmljIE1TVC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNocmlzdGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYw0KIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IDEyLiB0b3Vrb2t1dXRh IDIwMTQgNzo1MDxicj4NCjxiPlRvOjwvYj4gbW11c2ljIFdHOyA8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTU1V U0lDXSBtLWxpbmUgcmVjeWNsaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBKU0VQIHNwZWMgc3BlY2lmaWVzIG0tbGluZSBy ZWN5Y2xpbmc6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IG8mbmJzcDsg SWYgYW55IE1lZGlhU3RyZWFtVHJhY2tzIGhhdmUgYmVlbiBhZGRlZCwgYW5kIHRoZXJlIGV4aXN0 IG09PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc2VjdGlvbnMgb2YgdGhlIGFwcHJvcHJpYXRlIG1lZGlhIHR5cGUgd2l0aCBu byBhc3NvY2lhdGVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTWVkaWFTdHJlYW1UcmFja3MgKGkuZS4gYXMgZGVzY3JpYmVk IGluIHRoZSBwcmVjZWRpbmcgcGFyYWdyYXBoKSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aG9zZSBtPSBzZWN0aW9ucyBN VVNUIGJlIHJlY3ljbGVkIGJ5IGFkZGluZyB0aGUgbmV3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWVkaWFTdHJlYW1UcmFj ayB0byB0aGUgbT0gc2VjdGlvbi4mbmJzcDsgVGhpcyBpcyBkb25lIGJ5IGFkZGluZyB0aGU8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBuZWNlc3NhcnkgJnF1b3Q7YT1tc2lkJnF1b3Q7LCAmcXVvdDthPXNzcmMmcXVvdDssIGFu ZCAmcXVvdDthPXNzcmMtZ3JvdXAmcXVvdDsgbGluZXMgdG8gdGhlPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVjeWNsZWQg bT0gc2VjdGlvbiwgYW5kIHJlbW92aW5nIHRoZSAmcXVvdDthPXJlY3Zvbmx5JnF1b3Q7IGF0dHJp YnV0ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QmFzZWQmbmJzcDtvbiB0aGUgbWludXRl cyBmcm9tIElFVEYgODksIHdlIHdlcmUgZ29pbmcgdG8gdGFrZSB0aGlzIHRvIG1tdXNpYy48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxhIGhyZWY9Imh0 dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3Avbm90ZXMtaWV0Zi04OS1ydGN3ZWI/ dXNlTW9ub3NwYWNlRm9udD10cnVlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5odHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL25vdGVzLWlldGYtODkt cnRjd2ViP3VzZU1vbm9zcGFjZUZvbnQ9dHJ1ZTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRob3Vn aHRzPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4tRWtyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy8yMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVO LVVTIj5odHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzIxPC9zcGFuPjwv YT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3 ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D321F5BESESSMB209erics_-- From nobody Mon May 19 05:38:10 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 53E8D1A0359 for ; Mon, 19 May 2014 05:38:07 -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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_PORT=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 z3ns8XsF7L9R for ; Mon, 19 May 2014 05:38:06 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5AE1A0361 for ; Mon, 19 May 2014 05:37:57 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jx11so6420017veb.0 for ; Mon, 19 May 2014 05:37:56 -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=JIyWzILa9eSCkAL6ISlYX8mz1AGbcm/MAwkNXfcCIZk=; b=g/yHS5FQx4sU4HNICjFTv9jcfv5DrMi9eYAKmZt5nDaXTAExRf4ypDxAv2Uv1NU3eq 6NpE3U7gTGK2KBGIQC1/lhQFTFFvMFKQALOKD0Mrv3hvDgppyEqjTJGrCuj9hRHVs4U2 /mXNgSJsK4dfsMmSKHeIJvPjvpRsSmx+XkqgG6W2irGqMD6/oDRPeeJBSDMFOhMko29G 2crexrPRoCW10JkmwxuqvwjYPyqVb3vBAWGrOC9xJtW3WsyDKg2fYcvpZ3gLm58Z79Bu 23H8djEQNd8y/2TuJoBAjqZwCt8H1BZlDBc0qhu4ObuC9moklICR3d1+6D6LsipgjQYA /sWA== 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=JIyWzILa9eSCkAL6ISlYX8mz1AGbcm/MAwkNXfcCIZk=; b=fP/ReEF0aoAg5EoHeW7YFG8CtJbj0eZe0z6PFaX9LgDxgDP+3KJD+FOW/LitzfhdUG ST/dl2zx+lCVTDO+cpB85Pu3zrTyhulnpH4ftlAx/ZFJ472MxC9J/24iO2Zkl9Bdz1CR RVigSUgf+CeXn1bLulmyvaIfVAzSK2FvO9V+a0qAYuHCytXyu6uxq/ZtrtX2oCSNL0J2 DqLbPT5Q+7wkNnQBwfcFvzza6HzS+4WnB81cJ34Htu6I6Xt7hrWavByGyjvr/Sae8Vdz 1Q8w10bDvp9LFtmKs5Ro2fQn4OY509zxJ9hgjLEcJ9RH1vjgVM7pEQTktoVMv12mxu1v mRYw== X-Gm-Message-State: ALoCoQlGjqaqEfzkuOwKnghmoKubm7NZmtR/8Lt9l/Fj+kmw9XznuAXYxX9kV+LRVj2rsix8UwGd X-Received: by 10.220.59.65 with SMTP id k1mr14455457vch.22.1400503076655; Mon, 19 May 2014 05:37:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.145.105 with HTTP; Mon, 19 May 2014 05:37:36 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D321F5B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2F672A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D321F5B@ESESSMB209.ericsson.se> From: Justin Uberti Date: Mon, 19 May 2014 05:37:36 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2950264369d04f9c008d4 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IuDMpFVRVxwdpIu96VgRb5_eOes Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] [rtcweb] m-line recycling 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, 19 May 2014 12:38:07 -0000 --001a11c2950264369d04f9c008d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes On Sun, May 18, 2014 at 9:49 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > >One option could be to only reuse m=3D lines that both sides have stoppe= d > using (i.e. port=3D0, as >opposed to a=3Dsendonly/recvonly). This provide= s > most of the benefits of recycling without >having to deal with the notion > of 'compatible'. > > > > Are you suggesting a MUST reuse such m=3D line, if available? > > > > Regards, > > > > Christer > > > > On Mon, May 12, 2014 at 7:43 AM, Martin Thomson > wrote: > > Yes, some words about being compatible and all that entails are required > if we intend to stipulate it being reused. Either that or we can say MAY. > The need for a strong definition diminishes then. > > On May 11, 2014 11:54 PM, "Christer Holmberg" < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > I don=E2=80=99t think it should be a MUST =E2=80=93 at least not only bas= ed on the media > type. Because, there may be other properties than the media type associat= ed > with the =E2=80=9Cm=3D=E2=80=9D line, why one does not want to use it for= the specific MST. > > > > Regards, > > > > Christer > > > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* 12. toukokuuta 2014 7:50 > *To:* mmusic WG; rtcweb@ietf.org > *Subject:* [MMUSIC] m-line recycling > > > > The JSEP spec specifies m-line recycling: > > > > > > > > o If any MediaStreamTracks have been added, and there exist m=3D > > sections of the appropriate media type with no associated > > MediaStreamTracks (i.e. as described in the preceding paragraph), > > those m=3D sections MUST be recycled by adding the new > > MediaStreamTrack to the m=3D section. This is done by adding the > > necessary "a=3Dmsid", "a=3Dssrc", and "a=3Dssrc-group" lines to the > > recycled m=3D section, and removing the "a=3Drecvonly" attribute. > > Based on the minutes from IETF 89, we were going to take this to mmusic. > > http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-rtcweb?useMonospaceFo= nt=3Dtrue > > > > > > > > > > Thoughts? > > -Ekr > > > > https://github.com/rtcweb-wg/jsep/issues/21 > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --001a11c2950264369d04f9c008d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes


On Sun, May 18, 2014 at 9:49 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

=C2=A0

Hi,<= /p>

=C2=A0

>One option = could be to only reuse m=3D lines that both sides have stopped using (i.e. = port=3D0, as >opposed to a=3Dsendonly/recvonly).= This provides most of the benefits of recycling without >having to deal with the notion of = 'compatible'.

=C2=A0

Are you suggesting a MUST reuse such m=3D line= , if available?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0<= /p>

On Mon, May 12, 2014 at 7:43 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

Yes, some words about being compatible and all that entails are required= if we intend to stipulate it being reused. Either that or we can say MAY. = The need for a strong definition diminishes then.

On May 11, 2014 11:54 PM, "Christer Holmberg&qu= ot; <christer.holmberg@ericsson.com> wrote:

Hi,=

=C2=A0

I don=E2= =80=99t think it should be a MUST =E2=80=93 at least not only based on the = media type. Because, there may be other properties than the media type associated with the =E2= =80=9Cm=3D=E2=80=9D line, why one does not want to use it for the specific = MST.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 12. toukokuuta 2014 7:50
To: mmusic WG; rtcweb@ietf.org
Subject: [MMUSIC] m-line recycling

=C2=A0

The JSEP spec specifies m-line recycling:

=C2=A0

=C2=A0
=C2=A0
 o=C2=A0 If any MediaStreamTracks have been added=
, and there exist m=3D

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sections of the ap=
propriate media type with no associated<=
u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTracks =
(i.e. as described in the preceding paragraph),=





=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 those m=3D section=
s MUST be recycled by adding the new<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTrack t=
o the m=3D section.=C2=A0 This is done by adding the


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary "a=
=3Dmsid", "a=3Dssrc", and "a=3Dssrc-group" lines t=
o the




=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 recycled m=3D sect=
ion, and removing the "a=3Drecvonly" attribute.




Based=C2=A0on the minutes from IETF 89, we were going to take this to mm=
usic.




http://etherpad.tools.ietf.org:9000/p/notes-ie=
tf-89-rtcweb?useMonospaceFont=3Dtrue





=C2=A0


=C2=A0


=C2=A0


=C2=A0


Thoughts?=



-Ekr

=C2=A0

=C2=A0

_____________________= __________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


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

=C2=A0


--001a11c2950264369d04f9c008d4-- From nobody Mon May 19 19:41: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 882AC1A0488 for ; Mon, 19 May 2014 19:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 RPy_fX8FCJnZ for ; Mon, 19 May 2014 19:41:32 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 32E131A0481 for ; Mon, 19 May 2014 19:41:32 -0700 (PDT) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 42dJ1o0021eYJf8A12hYD8; Tue, 20 May 2014 02:41:32 +0000 Received: from mail-yh0-f49.google.com ([209.85.213.49]) by omta19.emeryville.ca.mail.comcast.net with comcast id 42fX1o00M14WgC1012fYCm; Tue, 20 May 2014 02:39:32 +0000 Received: by mail-yh0-f49.google.com with SMTP id c41so7580870yho.22 for ; Mon, 19 May 2014 19:39:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.32.65 with SMTP id n41mr17903193yha.117.1400553571644; Mon, 19 May 2014 19:39:31 -0700 (PDT) Received: by 10.170.208.216 with HTTP; Mon, 19 May 2014 19:39:31 -0700 (PDT) In-Reply-To: <05442941-FAB9-4A9A-B2D8-0B8A70F623CB@cisco.com> References: <20140317194900.4227.77172.idtracker@ietfa.amsl.com> <05442941-FAB9-4A9A-B2D8-0B8A70F623CB@cisco.com> Date: Mon, 19 May 2014 20:39:31 -0600 Message-ID: From: Kevin Gross To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=089e01537be22084b904f9cbca76 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400553692; bh=VBndlvrhn4DUFZFP8TUs0tPkPw3bIfH9PsgsvaaZb0g=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=vf44xofd1zzQ7NyhiFmBaO7H+WsQX35gOjNmBx/rfJR0/xjA87JYrMFgvw4j4DBsR sdtjrWTdTvYCrRkrxWBC2hqx2lfPDsgDMTWmDWGtlkRawValUUUephm0pFdnB+bBnu 9wbQFjECMIR33xbVtd4IMRct/LkfMO/gb8m7VFNx9vfY/++4RBzJhNWYt5UP7GNaGs qFynbhcdY1oeXUgGM1Sgpan/CfFM4WR9IrXJswg1BNgb4kbtLXSsOG7GVI6drVwbuz 9XYLTwld8g6b2lclzlIXipECNSm1rlLRHqUFDD/a5xfEX2L4FkKmF/+J2/dH/6qFA+ QH4Jt1A2vhJjg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5QRIWRYkdgkOOHlYnCg-ClcWO_0 Cc: "" Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-10.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, 20 May 2014 02:41:35 -0000 --089e01537be22084b904f9cbca76 Content-Type: text/plain; charset=UTF-8 I have reviewed this and have one minor comment: I would suggest adding a reference to BCP23/RFC2365 in the second bullet point of section 5.7. Kevin Gross - AVA Networks On Mon, Mar 17, 2014 at 1:51 PM, Ali C. Begen (abegen) wrote: > This is a keep-alive update. > > We had some discussions about "fixing" some of the IANA > registrations/ABNFs that were done in 4566 but whether this will be done or > not is TBD. > > -acbegen > > Begin forwarded message: > > > From: > > Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-10.txt > > Date: March 18, 2014 at 6:49:00 AM GMT+11 > > To: Van Jacobson , "Mark J. Handley" < > m.handley@cs.ucl.ac.uk>, "Ali C. Begen" , "Dr. Colin > Perkins" , Colin Perkins , Van > Jacobson , Ali Begen , Mark Handley < > m.handley@cs.ucl.ac.uk> > > > > > > A new version of I-D, draft-ietf-mmusic-rfc4566bis-10.txt > > has been successfully submitted by Ali Begen and posted to the > > IETF repository. > > > > Name: draft-ietf-mmusic-rfc4566bis > > Revision: 10 > > Title: SDP: Session Description Protocol > > Document date: 2014-03-17 > > Group: mmusic > > Pages: 51 > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-10.txt > > Status: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ > > Htmlized: > http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-10 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-10 > > > > Abstract: > > This memo defines the Session Description Protocol (SDP). SDP is > > intended for describing multimedia sessions for the purposes of > > session announcement, session invitation, and other forms of > > multimedia session initiation. This document obsoletes RFC 4566. > > > > > > > > > > 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 > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --089e01537be22084b904f9cbca76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed=C2=A0this and have one minor comment: I wo= uld suggest adding a reference to BCP23/RFC2365 in the second bullet point = of section 5.7.

Kevin Gross - AVA Networks


On Mon, Mar 17, 2014 at 1:51 PM, Ali C. = Begen (abegen) <abegen@cisco.com> wrote:
This is a keep-alive update.

We had some discussions about "fixing" some of the IANA registrat= ions/ABNFs that were done in 4566 but whether this will be done or not is T= BD.

-acbegen

Begin forwarded message:

> From: <internet-drafts@= ietf.org>
> Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-10.= txt
> Date: March 18, 2014 at 6:49:00 AM GMT+11
> To: Van Jacobson <van@parc.com&= gt;, "Mark J. Handley" <m.handley@cs.ucl.ac.uk>, "Ali C. Begen" <abegen@cisco.com>, "Dr. Colin Perkins= " <csp@csperkins.org>, = Colin Perkins <csp@csperkins.org>, Van Jacobson <van@parc.com>= ;, Ali Begen <abegen@cisco.com&g= t;, Mark Handley <m.handley@cs= .ucl.ac.uk>
>
>
> A new version of I-D, draft-ietf-mmusic-rfc4566bis-10.txt
> has been successfully submitted by Ali Begen and posted to the
> IETF repository.
>
> Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-mmusic-rfc4566bis
> Revision: =C2=A0 =C2=A0 10
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SDP: Ses= sion Description Protocol
> Document date: =C2=A0 =C2=A0 =C2=A0 =C2=A02014-03-17
> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mmusic > Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A051
> URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-10.txt<= /a>
> Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatrac= ker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/
> Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/htm= l/draft-ietf-mmusic-rfc4566bis-10
> Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://= www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-10
>
> Abstract:
> =C2=A0 This memo defines the Session Description Protocol (SDP). =C2= =A0SDP is
> =C2=A0 intended for describing multimedia sessions for the purposes of=
> =C2=A0 session announcement, session invitation, and other forms of > =C2=A0 multimedia session initiation. =C2=A0This document obsoletes RF= C 4566.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

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

--089e01537be22084b904f9cbca76-- From nobody Wed May 21 11:20:56 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 EB8CF1A0116 for ; Wed, 21 May 2014 11:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.152 X-Spam-Level: X-Spam-Status: No, score=-17.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, 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 fIeQA12OgLkx for ; Wed, 21 May 2014 11:20:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DD71A037D for ; Wed, 21 May 2014 11:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2536; q=dns/txt; s=iport; t=1400696442; x=1401906042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1oADQky0pJPU/BndYPWMpGAG8SfvRPxhlM+bTDHv4ZA=; b=VNHspKkkzVoX5681KvscQh3EjmHmcLBsrD+yaheie9b37t+GLB9ABhdW ZyCHeiLl110Fo+KtZTqagjwNSKO5Sd78J2uIkpiBUgxlF8qArLmmZI0/U qDsWKQCh7NsID3iXr3yc+QXZE6KJ2AsCvE9J4r38XI/QHogqSzYGV/pyK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkIAHDtfFOtJV2T/2dsb2JhbABZgmUkUlEHvGCGalEBgQwWdIIlAQEBAwEBAQE3NAkCBQsCAQgRAwECAR4QJwsdCAIEDgUJiDAIAQcF1kIXjhszBwaDJYEVBJlugT2RZ4M4bYFD X-IronPort-AV: E=Sophos;i="4.98,881,1392163200"; d="scan'208";a="323728186" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP; 21 May 2014 18:20:40 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4LIKe17023367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 18:20:40 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 21 May 2014 13:20:40 -0500 From: "Ali C. Begen (abegen)" To: Kevin Gross Thread-Topic: [MMUSIC] New Version Notification for draft-ietf-mmusic-rfc4566bis-10.txt Thread-Index: AQHPdSFemQz+3exu60+Qv6ulQLQODg== Date: Wed, 21 May 2014 18:20:39 +0000 Message-ID: References: <20140317194900.4227.77172.idtracker@ietfa.amsl.com> <05442941-FAB9-4A9A-B2D8-0B8A70F623CB@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <965AE7C932E94444AB87066E6148F57D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SPFYBTmH82zD51sPmmrgIUrGGUQ Cc: "" Subject: Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-rfc4566bis-10.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, 21 May 2014 18:20:50 -0000 Sounds good, I will add that. On May 19, 2014, at 7:39 PM, Kevin Gross wrote: > I have reviewed this and have one minor comment: I would suggest adding a= reference to BCP23/RFC2365 in the second bullet point of section 5.7. >=20 > Kevin Gross - AVA Networks >=20 >=20 > On Mon, Mar 17, 2014 at 1:51 PM, Ali C. Begen (abegen) = wrote: > This is a keep-alive update. >=20 > We had some discussions about "fixing" some of the IANA registrations/ABN= Fs that were done in 4566 but whether this will be done or not is TBD. >=20 > -acbegen >=20 > Begin forwarded message: >=20 > > From: > > Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-10.t= xt > > Date: March 18, 2014 at 6:49:00 AM GMT+11 > > To: Van Jacobson , "Mark J. Handley" , "Ali C. Begen" , "Dr. Colin Perkins" , Colin Perkins , Van Jacobson , Ali = Begen , Mark Handley > > > > > > A new version of I-D, draft-ietf-mmusic-rfc4566bis-10.txt > > has been successfully submitted by Ali Begen and posted to the > > IETF repository. > > > > Name: draft-ietf-mmusic-rfc4566bis > > Revision: 10 > > Title: SDP: Session Description Protocol > > Document date: 2014-03-17 > > Group: mmusic > > Pages: 51 > > URL: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-r= fc4566bis-10.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4= 566bis/ > > Htmlized: http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis= -10 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rf= c4566bis-10 > > > > Abstract: > > This memo defines the Session Description Protocol (SDP). SDP is > > intended for describing multimedia sessions for the purposes of > > session announcement, session invitation, and other forms of > > multimedia session initiation. This document obsoletes RFC 4566. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 From nobody Thu May 22 12:42: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 3143B1A0357 for ; Thu, 22 May 2014 12:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] 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 4QYpbEhuq1pO for ; Thu, 22 May 2014 12:42:43 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF801A035C for ; Thu, 22 May 2014 12:42:36 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B168820AC9 for ; Thu, 22 May 2014 15:42:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 22 May 2014 15:42:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=AFCGpweaJBSEFwfOKvWAPJB zGkw=; b=vrk+ImD6EsS6eRZVO0Ru7ffDLmaSf4/m/9rl/6pn35EpFJIeY+GfPJE BSX5H9QMlsGKLJmmIt7yqfwrws8CGayo55+Qascq1TPUcksYmGHVPgoFYJ6Y4ghX gnTkcP7BslV7IJpccDcPNjvfsXJf/BgIBpZblb7JBWFkapCbSvDE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=AFCGpweaJBSEFwfOKvWAPJBzGkw=; b=gTcDQolNERguX1j91WlIEyyZmThd eRIQUNqhwmGoK899RNx4e/1sYdN2XPU14U4t1uZOEOkR/BA0JCrEajlm+inaMoTE pV3rF8YIAMwvw2kI59RAkdpV+qSjVA1y8kZ9lG99JaMX4omoHlXHiMMCGNt4xQXD JFR6yi+ipryN44o= X-Sasl-enc: exzw5xopnW78qnLTG/+FlXK/U1iBIuYw/ieP4x5izEfu 1400787749 Received: from [10.150.9.165] (unknown [64.102.254.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 84F2068013A for ; Thu, 22 May 2014 15:42:27 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 22 May 2014 15:42:23 -0400 From: Alissa Cooper To: Message-ID: Thread-Topic: AD evaluation: draft-ietf-mmusic-rtsp-nat-20 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1aI6PvIobrhBT81cYTrPH8lpJJk Subject: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20 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, 22 May 2014 19:42:46 -0000 I have reviewed draft-ietf-mmusic-rtsp-nat-20 in preparation for IETF LC. The document is in good shape. I have a few questions and comments below that need to be resolved before issuing the last call. I=E2=80=99ve also included a list of nits that should be resolved in the next rev. Comments and questions: Sec 4.2: "The connection address SHOULD use the same format (explicit IP or FQDN) as in the dest_addr parameter used to express fallbacks.=E2=80=9D Per 4.1, I thought the dest_addr MUST NOT be included, so this requirement seems contradictory. ": conveys the candidates connection type (active, passive, or S-O) for TCP based candidates. This MUST be included for candidates that have set to TCP and MUST NOT be included for other transport types, including UDP, unless explicitly specified for that transport protocol." I=E2=80=99m assuming the last phrase means =E2=80=9Cunless gets specified i= n the future for that transport protocol.=E2=80=9D But I=E2=80=99m not clear on what the is. Sec 4.4: "The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the "Supported" header in all SETUP requests that contain the "D-ICE" lower layer transport.=E2=80=9D What are the situations where the SETUP request contains =E2=80=9CD-ICE=E2=80=9D but wh= ere the feature tag should not be included? Is it for SETUP requests issued after media is already playing (as described in Sec 6.13)? Sec 6.5: "The server determines if the SETUP request is successful from the other perspectives=E2=80=9D It=E2=80=99s not clear what is meant by =E2=80=9Cfrom the other perspectives.=E2=80=9D Sec 6.10: "If the 480 response is received or sent in response to a PLAY request, the server MUST NOT free its gathered candidates." The =E2=80=9Creceived or sent=E2=80=9D part doesn=E2=80=99t quite make sense, since we=E2=80=99re t= alking about the server, right? Shouldn=E2=80=99t this just say =E2=80=9Csent=E2=80=9D? Sec 6.13: See comments on Sec 4.4 above =E2=80=94 why is the Supported header not included in the SETUP requests in this example? Sec 7.1 and 7.2: Again with reference to Sec 4.4 =E2=80=94 why is the "setup.ice-d-m=E2=80=9D feature ta= g mandatory for media proxies but recommended for clients and signaling proxies? Sec 7.3: "Unfortunately, the usage of the "setup.ice-d-m" feature tag in the Proxy-Require will have contradicting results.=E2=80=9D This sentence and the paragraph that follows are confusing because there is no prior mention of putting the feature tag in the Proxy-Require header (although I guess it was implicitly assumed). I think what you meant is this: "The usage of the =E2=80=9Csetup.ice-d-m=E2=80=9D feature tag in the Proxy-Require head= er is NOT RECOMMENDED because it can have contradictory results.=E2=80=9D Sec 8: "This multiplexing SHALL be combined with ICE=E2=80=9D I think s/ICE/ICE-RTSP/ makes sense here. "Due to the above mentioned benefits, RTSP servers and clients that support "D-ICE" lower layer transport in combination with RTP SHALL also implement RTP and RTCP multiplexing as specified in this section and [RFC5761].=E2=80=9D Multiplexing is not specified in this section. Did you mean as specified in Appendix C of draft-ietf-mmusic-rfc2326bis and RFC5761? Nits: There are a couple of idnits that should be fixed. Sec 1: s/when PLAY request are/when PLAY requests are/ Sec 4.2: OLD: : is an identifier that is equivalent for two candidates that are of the same type, share the same base, and come from the same STUN server, and is composed of one to thirty two . NEW: : is an identifier that is equivalent for two candidates that are of the same type, share the same base IP address, and come from the same STUN server. It is composed of 1 to 32 s. s/is used when the second component/is used, in which case the second component/ s/the Allocate Response/the TURN Allocate Response/ s/: conveys the candidates connection type/: conveys the candidate=E2=80=99s connection type/ Sec 4.4: s/RTSP agents; clients, servers and proxies./RTSP agents: clients, servers and proxies./ Sec 6.12: s/First, if it can attempt/First, it can attempt/ s/or change the transport parameters./or changing the transport parameters./ s/SHALL use Regular nomination./SHALL use regular nomination./ Sec 6.13: s/A Server/A server/ s/gather new ICE candidates, and send/gather new ICE candidates and send/ s/If not the client will/If not, the client will/ Sec 7.3: s/non ICE/non-ICE/ OLD: A non-media handling proxy is expected to ignore and simply forward all unknown transport specifications, however, this can only be guaranteed for proxies following the RTSP 2.0 specification [I-D.ietf-mmusic-rfc2326bis]. NEW: A non-media handling proxy is expected to ignore and simply forward all unknown transport specifications. However, this can only be guaranteed for proxies following the RTSP 2.0 specification [I-D.ietf-mmusic-rfc2326bis]. s/if you want to provide other fallbacks/if it is desirable to provide other fallbacks/ s/For non-supporting non-media handling proxies the result will also result in aborting the setup, however,/For non-ICE supporting non-media handling proxies the result will be aborting the setup. However,/ s/the proxy chain support/the proxy chain supports/ s/to try perform an SETUP/to try to perform a SETUP/ Sec 9: OLD: However, for RTSP clients lacking a relay server, like a TURN server, or where usage of such a server has significant cost associated with it the usage of a STUN derived server reflexive address NEW: However, for RTSP clients lacking a relay server, such as a TURN server, or where usage of such a server has significant cost associated with it, the usage of a STUN-derived server reflexive address s/the selected protocol, e.g. UDP needs/the selected protocol, e.g. UDP, needs/ s/Secondly the selected/Secondly, the selected/ Sec 10.1: s/This document request that/This document requests that/ s/ICE based/ICE-based/ Sec. 10.2: s/Transport Protocol Specifications/Transport Protocol Identifiers/ Sec 12: s/Bill Atwood have provided/Bill Atwood has provided/ From nobody Fri May 23 06:49: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 A07011A04B8; Fri, 23 May 2014 06:48:20 -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 1sGHuDuu0PaU; Fri, 23 May 2014 06:48:15 -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 5580A1A04B7; Fri, 23 May 2014 06:48:12 -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 s4NDlvLJ011180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 May 2014 08:47:58 -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 s4NDlvBk020367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 May 2014 08:47:57 -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 s4NDlv79013281; Fri, 23 May 2014 08:47:57 -0500 (CDT) Message-ID: <537F520E.3060501@bell-labs.com> Date: Fri, 23 May 2014 08:50:06 -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: "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-OshYijb1tCnxPE_LwJKWsUGgJg X-Mailman-Approved-At: Fri, 23 May 2014 06:49:54 -0700 Cc: IESG IESG , mmusic Subject: [MMUSIC] 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: Fri, 23 May 2014 13:48:20 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mmusic-latching-05 Title: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Reviewer: Vijay K. Gurbani Review Date: May 23-2014 IETF Last Call Date: May-28-2014 IESG Telechat Date: May-29-2014 Summary: This draft is almost ready for publication as an Informational RFC but has a few issues that should be fixed before publication. The draft captures excellent discussions on latching and provides a great overview on what it is, how it works, and despite its simplicity, why not to use it. However, the tone of the draft should change from colloquial to something more objective (various examples of this in the Nits section). Major: 0 Minor: numerous (see below) Nits: numerous (see below) Minor: - S1, second to last paragraph: Not sure I understand what you mean by The SIP signaling-layer component of HNT is typically more implementation-specific and deployment-specific than the SDP and media components. 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? - S3, second paragraph: "newly introduced media relay" --- newly introduced to who? Perhaps you mean "a media relay incorporated into session establishment"? Is this paragraph saying that the SBC and media relay may be co-located on the same host? - 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". - 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. - 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)"? - 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/ - S5, first paragraph, line 12: s/onto packets/onto media packets/ - 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. - 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? - S5, second paragraph: s/In all/All/ - S5, second paragraph: s/disturb media/impact media/ - S5, third paragraph: s/since the SBC will not latch onto the attacker's packets./since the SBC will not latch onto the attacker's media packets, not having seen the corresponding signaling packets first./ - 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? Teasing this case further, if the legitimate user hangs up the call because it is not getting any media packets, then a BYE should go through the SBC causing it to discard latched states, thereby preventing any more media packets from going to the attacker. Assuming that the attacker had inserted itself as a man-in-the-middle and was relaying packets to the UA, then sure, the legitimate user will not hang up and continue conversing. The case of a non-human user (answering machine) is redundant since the behaviour of the user (non-human or otherwise) is essentially the same. - 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?) Nits: - Abstract, 3rd paragraph: s/components of the HNT components/components of HNT/ 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. - S1, second paragraph: s/They use IP/These protocols use IP/ - S1, second paragraph: s/as, in the/as, and in the/ - S1, fourth paragraph: s/some manufacturers sometimes/a number of manufacturers sometimes/ - S1, fifth paragraph: s/creation time/publication/ - S1, fifth paragraph: s/in the foreseeable/for the foreseeable/ - S1, sixth paragraph: s/are not novel to experts/are well known in the community/ - S1, seventh paragraph: s/In no way does this document/This document does not/ - S4, first paragraph: s/couple/tuple/ - S4, Figure 3: why not use the principals Alice and Bob here as well instead of "XMPP Client 1" and "XMPP Client 2"? - S5, last sentence of second-to-last paragraph: s/However it is sometimes argued that, neither S/MIME nor [RFC4474] are widely deployed and that this may not be a real concern./However, neither S/MIME or [RFC4474] are widely deployed, thus not being able to sign/verify requests appear not to be a concern at this time./ Thanks, - 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 Tue May 27 02:59: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 910421A0049 for ; Tue, 27 May 2014 02:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jd-TqoHCzrxC for ; Tue, 27 May 2014 02:59:24 -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 010101A0078 for ; Tue, 27 May 2014 02:59:23 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-8d-538461f72cea Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.36.25910.7F164835; Tue, 27 May 2014 11:59:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.174.1; Tue, 27 May 2014 11:59:18 +0200 Message-ID: <538461ED.50008@ericsson.com> Date: Tue, 27 May 2014 11:59:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alissa Cooper , , "Jeff Goldberg (jgoldber)" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvje73xJZgg0kvVSymn/nLaPHzyQs2 i6nLH7M4MHtM+b2R1ePLk5dMHkuW/GQKYI7isklJzcksSy3St0vgylj76CdrQZNxxZOLN9kb GLdodDFyckgImEjs6trEDmGLSVy4t54NxBYSOMooMfOLSxcjF5C9nFFifeMHVpAEr4CmxJ9V T8CKWARUJZqe/mMGsdkELCRu/mgEi4sKBEtsePiXHaJeUOLkzCcsILaIQLbEho0rweqFBZwk Dk7pYYFYpifxZM5ksPmcAvoSDTd2MHYxcgAdJC7R0xgEEmYGWtu6/Tc7hC0v0bx1NjNEq7ZE Q1MH6wRGwVlIts1C0jILScsCRuZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIEBfHDLb4Md jC+fOx5iFOBgVOLhVWhsDhZiTSwrrsw9xCjNwaIkzntRozpYSCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA6NrmZKse5fqumUnLz+bHfrN4XGNneTqLavSV1pEHOj/eGt+u8CSsDlzRLb93LTw 5O3ync8+egbp71iyrvX9oxdqVjkz/E+47E1jYLov9nay3NObr6dJnzvyRv7gn4Iojz7ea3/8 FhdmfU/Z//3r8d/KcYcaDNRDXDKZb675Yq8r5Pvr9qGi7kAbJZbijERDLeai4kQAe1iwZEEC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vUvtoIXnPAN-MGzrRt-H52Qjjgs Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20 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, 27 May 2014 09:59:26 -0000 Hi, Thanks for the review. Please see below for answers and comments on your questions and comments. On 2014-05-22 21:42, Alissa Cooper wrote: > I have reviewed draft-ietf-mmusic-rtsp-nat-20 in preparation for IETF LC. > The document is in good shape. I have a few questions and comments below > that need to be resolved before issuing the last call. I’ve also included > a list of nits that should be resolved in the next rev. > > Comments and questions: > > Sec 4.2: > "The connection address SHOULD use the same format > (explicit IP or FQDN) as in the dest_addr parameter used to > express fallbacks.†> > Per 4.1, I thought the dest_addr MUST NOT be included, so this requirement > seems contradictory. So, this is a reference to another transport specification used as fallback if ICE isn't supported. The format of the D-ICE transport spec's connection-address SHOULD be the same format (explicit IP or FQDN) as used in that fallback transport specification's dest_addr parameter. Will see what we can do to clarify that it is referencing another transport spec. > > ": conveys the candidates connection type (active, > passive, or S-O) for TCP based candidates. This MUST be included > for candidates that have set to TCP and MUST NOT be > included for other transport types, including UDP, unless > explicitly specified for that transport protocol." > > I’m assuming the last phrase means “unless gets specified in > the future for that transport protocol.†But I’m not clear on what the > is. So, if anyone defines a new transport protocol and you like to add this here. Then that protocol may chose to re-use this header. That is when that unless occurs. As one can define a new parameter as easily, I guess this "unless ..." is quite unnecessary and can be removed. > > Sec 4.4: > "The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the > "Supported" header in all SETUP requests that contain the "D-ICE" > lower layer transport.†> > What are the situations where the SETUP request contains “D-ICE†but where > the feature tag should not be included? Is it for SETUP requests issued > after media is already playing (as described in Sec 6.13)? I would classify this SHOULD as: we have no good reason why you would not include the feature tag. But if you have one, we don't see a reason for making the implementation violate a MUST. > > Sec 6.5: > "The server determines if the SETUP request is successful from the > other perspectives†> > It’s not clear what is meant by “from the other perspectives.†As a SETUP for a media resource also the preparation and availability of the media resource, not only the transport needs to be fulfilled. It might be clear to simply use "is successful" > > Sec 6.10: > "If the 480 response is received or sent in response to a PLAY > request, the server MUST NOT free its gathered candidates." > > The “received or sent†part doesn’t quite make sense, since we’re talking > about the server, right? Shouldn’t this just say “sent� Correct, as currently specified the 480 is only sent in Server -> Client direction, thus the "received or" is to be removed. > > Sec 6.13: > See comments on Sec 4.4 above — why is the Supported header not included > in the SETUP requests in this example? I don't think there exist a reason, just a missed inclusion. will address. > > Sec 7.1 and 7.2: > Again with reference to Sec 4.4 — why is the "setup.ice-d-m†feature tag > mandatory for media proxies but recommended for clients and signaling > proxies? Because a client really needs to know if a proxy supports the ICE-D transport. If it doesn't you end up in all the issues discussed in Section 7.3. If there is one change I think should be done here is to make 7.2 a SHALL indicate its capability. I also clarified that this relates to SETUP request and responses. If a client skips including a Supported header but anyway tries using ICE-D as transport, it will work if the nodes support it. Including the Supported header will only make it clear on the feature negotiation level that the feature is supported and also prompt the proxies to include their Proxy-Supported header. > > Sec 7.3: > "Unfortunately, the usage of the "setup.ice-d-m" feature tag in the > Proxy-Require will have contradicting results.†> > This sentence and the paragraph that follows are confusing because there > is no prior mention of putting the feature tag in the Proxy-Require header > (although I guess it was implicitly assumed). I think what you meant is > this: > > "The usage of the “setup.ice-d-m†feature tag in the Proxy-Require header > is NOT RECOMMENDED because it can have contradictory results.†> Yes, the sentence you propose is better, will include. The text is written with the assumption that one knows RTSP 2.0 and its feature negotiation mechanisms. Thus, clearly one can include the feature tag in any headers that uses feature tags when relevant. > Sec 8: > "This multiplexing SHALL be combined with ICE†> > I think s/ICE/ICE-RTSP/ makes sense here. I actually removed the SHALL, it was duplicate with the SHALL in the last sentence. So I change this to "This multiplexing is very benefical when be combined with ICE for RTSP as it makes RTP and RTCP need only a single component ..." > > "Due to the above mentioned benefits, RTSP servers and clients that > support "D-ICE" lower layer transport in combination with RTP SHALL > also implement RTP and RTCP multiplexing as specified in this section > and [RFC5761].†> > Multiplexing is not specified in this section. Did you mean as specified > in Appendix C of draft-ietf-mmusic-rfc2326bis and RFC5761? > Yes, will address. We will take care of the nits. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue May 27 16:24: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 C37081A07AB for ; Tue, 27 May 2014 16:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 i3eHu3KwFvGe for ; Tue, 27 May 2014 16:24:34 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92BDD1A0671 for ; Tue, 27 May 2014 16:24:34 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DE17F230B6 for ; Tue, 27 May 2014 19:24:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 27 May 2014 19:24:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=NHY7cmSwRQ e6GUDtNhee5LvA2RE=; b=OhSQ5+4GL6jiohMrYe5p1qNDOIhB5ubUvxe3D6xYBL 3er1e2IfdZANBDdMUR0wYvTL4JZUIj/yS4ePpx0tszZZ5XMDFnhRwapu8hV62unQ 00G4H6PQOD/sfEpo6bh48biDY5xKjwRNT0xKo7WPWAIJflPBsPWcJgVaDD6FtZDD 0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=NHY7cmSwRQe6GUDtNhee5L vA2RE=; b=RwxcjcEqyo+y79GGwvJezmOdkBjdjHQyzdVcmmQrDF4V6W5vvo3Tlo kmx9uWjrlUQzdXI0M6goLePKIb+2k2kbXNY+AhIgoRVWD7AmQhJ1HFfQ1tObekkz DWeiNY1NMcbrYtOmzNtjyKVe88/Y2e81J/bLgVKKhguAB8pZ/Z4ds= X-Sasl-enc: L43ASnUDYNwqpRllHikeQ+yPZKDo3VMEQsCxaZyZ5piH 1401233070 Received: from [171.68.18.44] (unknown [171.68.18.44]) by mail.messagingengine.com (Postfix) with ESMTPA id C1A2DC00003; Tue, 27 May 2014 19:24:29 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Tue, 27 May 2014 16:24:23 -0700 From: Alissa Cooper To: Magnus Westerlund , , "Jeff Goldberg (jgoldber)" Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20 References: <538461ED.50008@ericsson.com> In-Reply-To: <538461ED.50008@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lwCGMd6qa5HRz84ILmGxAcQjdvQ Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20 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, 27 May 2014 23:24:36 -0000 Hi Magnus, Thanks. Comments inline. On 5/27/14, 2:59 AM, "Magnus Westerlund" wrote: >Hi, > >Thanks for the review. Please see below for answers and comments on your >questions and comments. > >On 2014-05-22 21:42, Alissa Cooper wrote: >> I have reviewed draft-ietf-mmusic-rtsp-nat-20 in preparation for IETF >>LC. >> The document is in good shape. I have a few questions and comments below >> that need to be resolved before issuing the last call. I=E2=80=99ve also >>included >> a list of nits that should be resolved in the next rev. >>=20 >> Comments and questions: >>=20 >> Sec 4.2: >> "The connection address SHOULD use the same format >> (explicit IP or FQDN) as in the dest_addr parameter used to >> express fallbacks.=E2=80=9D >>=20 >> Per 4.1, I thought the dest_addr MUST NOT be included, so this >>requirement >> seems contradictory. > >So, this is a reference to another transport specification used as >fallback if ICE isn't supported. The format of the D-ICE transport >spec's connection-address SHOULD be the same format (explicit IP or >FQDN) as used in that fallback transport specification's dest_addr >parameter. > >Will see what we can do to clarify that it is referencing another >transport spec. Thanks. > >>=20 >> ": conveys the candidates connection type (active, >> passive, or S-O) for TCP based candidates. This MUST be included >> for candidates that have set to TCP and MUST NOT be >> included for other transport types, including UDP, unless >> explicitly specified for that transport protocol." >>=20 >> I=E2=80=99m assuming the last phrase means =E2=80=9Cunless gets specifie= d in >> the future for that transport protocol.=E2=80=9D But I=E2=80=99m not clear on what t= he >> is. > >So, if anyone defines a new transport protocol and you like to add this >here. Then that protocol may chose to re-use this header. That is when >that unless occurs. As one can define a new parameter as easily, I guess >this "unless ..." is quite unnecessary and can be removed. Sounds good. > >>=20 >> Sec 4.4: >> "The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the >> "Supported" header in all SETUP requests that contain the "D-ICE" >> lower layer transport.=E2=80=9D >>=20 >> What are the situations where the SETUP request contains =E2=80=9CD-ICE=E2=80=9D but >>where >> the feature tag should not be included? Is it for SETUP requests issued >> after media is already playing (as described in Sec 6.13)? > >I would classify this SHOULD as: we have no good reason why you would >not include the feature tag. But if you have one, we don't see a reason >for making the implementation violate a MUST. Would help to explain that rationale in the document. > >>=20 >> Sec 6.5: >> "The server determines if the SETUP request is successful from the >> other perspectives=E2=80=9D >>=20 >> It=E2=80=99s not clear what is meant by =E2=80=9Cfrom the other perspectives.=E2=80=9D > >As a SETUP for a media resource also the preparation and availability of >the media resource, not only the transport needs to be fulfilled. It >might be clear to simply use "is successful" Agreed. > >>=20 >> Sec 6.10: >> "If the 480 response is received or sent in response to a PLAY >> request, the server MUST NOT free its gathered candidates." >>=20 >> The =E2=80=9Creceived or sent=E2=80=9D part doesn=E2=80=99t quite make sense, since we=E2=80=99r= e >>talking >> about the server, right? Shouldn=E2=80=99t this just say =E2=80=9Csent=E2=80=9D? > >Correct, as currently specified the 480 is only sent in Server -> Client >direction, thus the "received or" is to be removed. Ok. > >>=20 >> Sec 6.13: >> See comments on Sec 4.4 above =E2=80=94 why is the Supported header not includ= ed >> in the SETUP requests in this example? > >I don't think there exist a reason, just a missed inclusion. will address. Ok. > > >>=20 >> Sec 7.1 and 7.2: >> Again with reference to Sec 4.4 =E2=80=94 why is the "setup.ice-d-m=E2=80=9D feature= tag >> mandatory for media proxies but recommended for clients and signaling >> proxies? > >Because a client really needs to know if a proxy supports the ICE-D >transport. If it doesn't you end up in all the issues discussed in >Section 7.3. If there is one change I think should be done here is to >make 7.2 a SHALL indicate its capability. I also clarified that this >relates to SETUP request and responses. Good, this makes sense to me. > >If a client skips including a Supported header but anyway tries using >ICE-D as transport, it will work if the nodes support it. Including the >Supported header will only make it clear on the feature negotiation >level that the feature is supported and also prompt the proxies to >include their Proxy-Supported header. > >>=20 >> Sec 7.3: >> "Unfortunately, the usage of the "setup.ice-d-m" feature tag in the >> Proxy-Require will have contradicting results.=E2=80=9D >>=20 >> This sentence and the paragraph that follows are confusing because there >> is no prior mention of putting the feature tag in the Proxy-Require >>header >> (although I guess it was implicitly assumed). I think what you meant is >> this: >>=20 >> "The usage of the =E2=80=9Csetup.ice-d-m=E2=80=9D feature tag in the Proxy-Require >>header >> is NOT RECOMMENDED because it can have contradictory results.=E2=80=9D >>=20 > >Yes, the sentence you propose is better, will include. The text is >written with the assumption that one knows RTSP 2.0 and its feature >negotiation mechanisms. Thus, clearly one can include the feature tag in >any headers that uses feature tags when relevant. Ok. > >> Sec 8: >> "This multiplexing SHALL be combined with ICE=E2=80=9D >>=20 >> I think s/ICE/ICE-RTSP/ makes sense here. > >I actually removed the SHALL, it was duplicate with the SHALL in the >last sentence. So I change this to "This multiplexing is very benefical >when be combined with ICE for RTSP as it makes RTP and RTCP need only a >single component ..." Ok.=20 > > > >>=20 >> "Due to the above mentioned benefits, RTSP servers and clients that >> support "D-ICE" lower layer transport in combination with RTP SHALL >> also implement RTP and RTCP multiplexing as specified in this section >> and [RFC5761].=E2=80=9D >>=20 >> Multiplexing is not specified in this section. Did you mean as specified >> in Appendix C of draft-ietf-mmusic-rfc2326bis and RFC5761? >>=20 > >Yes, will address. Ok. > > >We will take care of the nits. Great, thanks. Alissa > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Tue May 27 17:11:39 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 430D11A081D for ; Tue, 27 May 2014 17:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 p8s6YWufMYd4 for ; Tue, 27 May 2014 17:11:23 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434EF1A081E for ; Tue, 27 May 2014 17:11:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 98BC020A08 for ; Tue, 27 May 2014 20:11:19 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 27 May 2014 20:11:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=lmYkMLZlMncadn3aAQdWaBH Rshg=; b=ZaHJ6ri/wkqQ8lX2HbGadSyaR3UEFbDC1Sq4/Wq2S0yM5HgZtzBYGf7 7QEVwwxmt6tz2sKwjau3yWoSLwu1Jy6bXj/v0h/yH2YY/LKAepUmRlmM/16BQxD8 gK3s4dJBu6DyU93yfIZrlT5Leuo8CoG1R+fccUcZLP7Kf6pqdfl8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=lmYkMLZlMncadn3aAQdWaBHRshg=; b=rVufNnmpsZKRSMgQ4fMX1Qng4ZrF Mb1/2HNn2qk3IJ30RJSDT07R6FUCC/tnOU90edivq50ZgzwYN9JME7I3VapAWq6p 1psTuTaM41u3H6ETJSBcg0gKeafkIa47bQlIjh5zUQuc8D1wWVRIMdjevL6/QWgy iKdRMiQjNtaGh68= X-Sasl-enc: N/aWJnGkB4QniqHWI7He0+PiRCUJMLIMBxcg8Oa2Y6PQ 1401235878 Received: from [171.68.18.44] (unknown [171.68.18.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 6AE2FC00003 for ; Tue, 27 May 2014 20:11:18 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Tue, 27 May 2014 17:11:13 -0700 From: Alissa Cooper To: Message-ID: Thread-Topic: AD evaluation: draft-ietf-mmusic-udptl-dtls-07 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jaQaGN8K1bnrVhRhT-jZ36VPwLk Subject: [MMUSIC] AD evaluation: draft-ietf-mmusic-udptl-dtls-07 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, 28 May 2014 00:11:37 -0000 I have reviewed this document in preparation for IETF last call. It=E2=80=99s in good shape. I will issue the last call. Couple of nits to be resolved with any last call comments: Section 1: s/clearly defined, well understood and implementations are widely available./clearly defined and well understood and implementations are widely available./ Section 4.5: s/same rules of for/same rules for/ From nobody Tue May 27 17:23: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 6CFC11A0831; Tue, 27 May 2014 17:22:58 -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 psUGTryvNE6w; Tue, 27 May 2014 17:22:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 412CB1A07DD; Tue, 27 May 2014 17:22:57 -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.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140528002257.19014.25701.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 17:22:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mu4BbQbSClnDtYcRoGjwA39KZyA Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: (UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)) 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: Wed, 28 May 2014 00:22:58 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)' 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-10. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed May 28 01:07: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 C20FD1A0873 for ; Wed, 28 May 2014 01:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ePR8O1wuCQoN for ; Wed, 28 May 2014 01:07:55 -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 6AA0E1A03D7 for ; Wed, 28 May 2014 01:07:55 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-5f-538599552314 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 40.81.16420.55995835; Wed, 28 May 2014 10:07:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Wed, 28 May 2014 10:07:49 +0200 From: Christer Holmberg To: Alissa Cooper , "mmusic@ietf.org" Thread-Topic: AD evaluation: draft-ietf-mmusic-udptl-dtls-07 Thread-Index: AQHPeglmopg+utwmsUCj+eNbSa1y65tVo0Wg Date: Wed, 28 May 2014 08:07:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3418D1@ESESSMB209.ericsson.se> References: In-Reply-To: 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvjW7YzNZggzfP2Symn/nLaDF1+WMW ByaPL09eMnksWfKTKYApissmJTUnsyy1SN8ugSvjwrqcghdsFVNWbWZpYLzA1sXIySEhYCJx 4GEHE4QtJnHh3nqgOBeHkMBRRolfp84yQjiLGSXuTHvP3sXIwcEmYCHR/U8bpEFEwEui+dhu RhBbWMBa4su/w8wgJSICNhJrt6lBlBhJ7Do8AyzMIqAq8X+NOkiYV8BXYv7v92CdQgJ6Ep+P NYDZnAL6Ehf/vmEHsRmBzvl+ag3YacwC4hK3nsyHOlNAYsme88wQtqjEy8f/WCFsRYmdZ9vB VjELaEqs36UP0aooMaX7ITvEWkGJkzOfsExgFJ2FZOoshI5ZSDpmIelYwMiyilG0OLU4KTfd yFgvtSgzubg4P08vL7VkEyMwOg5u+a26g/HyG8dDjAIcjEo8vAsutQQLsSaWFVfmHmKU5mBR Eue9qFEdLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGReSYXc9kN9rOcV0S/RM67/+5cAWP1 T7vrdQlTDRrXRUV+0WlPkTIKKm3j/KNcyTFncl3zPekFX/qP+jctmhLv+zP31paVUb73JKbN d8wOXcGaFND64bCR7nP7oBZVlVJxA9kywZWv1Va9qW0091z2NGfzQ4Mal6STEjOLL/699ua5 5iufVyuVWIozEg21mIuKEwGCbaR7bwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eoSB_bVgGixNQQU_WZ1MWxCx55I Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-udptl-dtls-07 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, 28 May 2014 08:07:57 -0000 SGkgQWxpc3NhLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cyEgUmVwbHkg aW5saW5lLg0KDQo+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgaW4gcHJlcGFyYXRpb24g Zm9yIElFVEYgbGFzdCBjYWxsLiBJdOKAmXMgaW4gZ29vZCBzaGFwZS4gSSB3aWxsIGlzc3VlIHRo ZSBsYXN0IGNhbGwuIENvdXBsZSBvZiBuaXRzIHRvIGJlIHJlc29sdmVkIHdpdGggYW55IGxhc3Qg Y2FsbCBjb21tZW50czoNCj4NCj5TZWN0aW9uIDE6DQo+cy9jbGVhcmx5IGRlZmluZWQsIHdlbGwg dW5kZXJzdG9vZCBhbmQgaW1wbGVtZW50YXRpb25zIGFyZSB3aWRlbHkgYXZhaWxhYmxlLi9jbGVh cmx5IGRlZmluZWQgYW5kIHdlbGwgdW5kZXJzdG9vZCBhbmQgaW1wbGVtZW50YXRpb25zIGFyZSB3 aWRlbHkgYXZhaWxhYmxlLi8NCj4NCj5TZWN0aW9uIDQuNToNCj5zL3NhbWUgcnVsZXMgb2YgZm9y L3NhbWUgcnVsZXMgZm9yLw0KDQpXZSdsbCBkbyB0aGUgY2hhbmdlcyBhcyBzdWdnZXN0ZWQuDQoN CkRvIHlvdSB3YW50IHVzIHRvIGRvIHRoZW0gbm93LCBiZWZvcmUgdGhlIElFU0cgcmV2aWV3LCBh bmQgc3VibWl0IGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Pw0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQo= From nobody Wed May 28 06:47:54 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 7B79C1A0331 for ; Wed, 28 May 2014 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5QQ9tA_p4l5t for ; Wed, 28 May 2014 06:47:50 -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 16E711A014D for ; Wed, 28 May 2014 06:47:49 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-75-5385e900521e Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.02.25910.009E5835; Wed, 28 May 2014 15:47:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.174.1; Wed, 28 May 2014 15:47:44 +0200 Message-ID: <5385E8F7.1040306@ericsson.com> Date: Wed, 28 May 2014 15:47:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alissa Cooper , , "Jeff Goldberg (jgoldber)" References: <538461ED.50008@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+JvjS7jy9Zgg2W/+Symn/nLaPHzyQs2 i6nLH7M4MHtM+b2R1ePLk5dMHkuW/GQKYI7isklJzcksSy3St0vgypj2ezNLwR3eilnn57I3 MH7n6mLk5JAQMJG4/G4fM4QtJnHh3nq2LkYuDiGBo4wSN95tgHKWM0r8vXaBBaSKV0BbYvHc U2wgNouAqsSaO5PAutkELCRu/mgEi4sKBEtsePiXHaJeUOLkzCdgvSIC2RIbNq4EqxcWcJI4 OKUHLC4kkC8x98EZsHpOAX2JC0/XMHUxcgBdJC7R0xgEEmYW0JRo3f6bHcKWl2jeOpsZolVb oqGpg3UCo+AsJNtmIWmZhaRlASPzKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAED645bfB DsaXzx0PMQpwMCrx8C641BIsxJpYVlyZe4hRmoNFSZz3okZ1sJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQbGde4bzzxKcdVeLPfW1J25gmXug2qeqkPWDye/6ZFMWfSP1+RT09FCnnNPzyyo TVJ8WSk53+RZJ0vfJPcW6+m7ub+qaN+sk92b9JPn+6/1Ua0+W+v3LC6Xqf+zM3Cj/w3ulUsT 1YMlXJZ8LPp50NDIgOuiQ5L3rYbaZt0bwbMfGm98IBfapXdRiaU4I9FQi7moOBEAyJ6U0UIC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/pv92Boj0Evq0iSGczJNTcngVUUc Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20 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, 28 May 2014 13:47:52 -0000 On 2014-05-28 01:24, Alissa Cooper wrote: >>> >>> Sec 4.4: >>> "The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the >>> "Supported" header in all SETUP requests that contain the "D-ICE" >>> lower layer transport.†>>> >>> What are the situations where the SETUP request contains “D-ICE†but >>> where >>> the feature tag should not be included? Is it for SETUP requests issued >>> after media is already playing (as described in Sec 6.13)? >> >> I would classify this SHOULD as: we have no good reason why you would >> not include the feature tag. But if you have one, we don't see a reason >> for making the implementation violate a MUST. > > Would help to explain that rationale in the document. > I propose the following: The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the "Supported" header in all SETUP requests that contain the "D-ICE" lower layer transport. Note, this is not a "MUST" due to that an RTSP client always can attempt to perform an SETUP using ICE to see if it functions or fails. But including the feature tag in the "Supported" header do ensure that proxies supporting this specification do explicitly indicate such support, see Section 7. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed May 28 09:04:54 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 2B54E1A0452 for ; Wed, 28 May 2014 09:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 kAlS4TwxeGBk for ; Wed, 28 May 2014 09:04:40 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AAF1A04D2 for ; Wed, 28 May 2014 09:04:40 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3A53C21516 for ; Wed, 28 May 2014 12:04:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 28 May 2014 12:04:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=HJjAsPi+xF 5GeNmHSMH1e2nv6gA=; b=jgxHLHgVfnFVtgXhMbiYMwEQShk3VFqSgjpoLRnHeV gBzlHybfk7WCScP8VJoMXMDnIuNWEnktoaVfUlimcCCmcUzhanZsUevFALhLbIPR o/iEN9e5JsWu/eLq6G+9aGaGJ1zKwN5IBwgZIGDqVLF+jgM04UGO7l5KgqsKt2+q M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=HJjAsPi+xF5GeNmHSMH1e2 nv6gA=; b=o25IeDq8MFiMB/E8SZdjTeFrtxiwmFvkQL04g8Vpbgy1NgcLiMR3PH 0pJetEgAH8XfU2wRdosL2sFKt/VsXqnV+sVKj+4wVDWyD85omnmcwKjcRz32mZC3 LzA/MsocJCoUPj58M/v+dfp8N2tsbOIZs/2PEH2cJ5pxNup0pjjp8= X-Sasl-enc: v4/2xp6iJ5DeK6cLeR6AF/hgoTW+vm2y4WBCJk3ES1MF 1401293060 Received: from [10.21.70.163] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 6BDD3C007AD; Wed, 28 May 2014 12:04:19 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 28 May 2014 09:04:13 -0700 From: Alissa Cooper To: Magnus Westerlund , , "Jeff Goldberg (jgoldber)" Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20 References: <538461ED.50008@ericsson.com> <5385E8F7.1040306@ericsson.com> In-Reply-To: <5385E8F7.1040306@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/t38ttMHCELtYEiuOuYrkHkabD40 Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20 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, 28 May 2014 16:04:45 -0000 On 5/28/14, 6:47 AM, "Magnus Westerlund" wrote: >On 2014-05-28 01:24, Alissa Cooper wrote: >>>> >>>> Sec 4.4: >>>> "The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the >>>> "Supported" header in all SETUP requests that contain the "D-ICE" >>>> lower layer transport.=E2=80=9D >>>> >>>> What are the situations where the SETUP request contains =E2=80=9CD-ICE=E2=80=9D b= ut >>>> where >>>> the feature tag should not be included? Is it for SETUP requests >>>>issued >>>> after media is already playing (as described in Sec 6.13)? >>> >>> I would classify this SHOULD as: we have no good reason why you would >>> not include the feature tag. But if you have one, we don't see a reason >>> for making the implementation violate a MUST. >>=20 >> Would help to explain that rationale in the document. >>=20 > >I propose the following: > > The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the > "Supported" header in all SETUP requests that contain the "D-ICE" > lower layer transport. Note, this is not a "MUST" due to that an > RTSP client always can attempt to perform an SETUP using ICE to see > if it functions or fails. But including the feature tag in the > "Supported" header do ensure that proxies supporting this > specification do explicitly indicate such support, see Section 7. Looks good. Thanks, Alissa > > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Wed May 28 09:23: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 7A5CA1A0A17 for ; Wed, 28 May 2014 09:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jgOb3blubn1b for ; Wed, 28 May 2014 09:23:31 -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 E362D1A04C5 for ; Wed, 28 May 2014 09:23:30 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-75-53860d7d11c3 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.92.28642.D7D06835; Wed, 28 May 2014 18:23:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.174.1; Wed, 28 May 2014 18:23:25 +0200 Message-ID: <53860D75.2010400@ericsson.com> Date: Wed, 28 May 2014 18:23:17 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alissa Cooper , References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+JvjW4tb1uwwYdJNhbTz/xltJi6/DGL A5PHlycvmTyWLPnJFMAUxWWTkpqTWZZapG+XwJUxr/MFY8HVdsaKHVOXsjUwrs3qYuTkkBAw kfjU84oVwhaTuHBvPVsXIxeHkMBRRok5Tw+yQzjLGSWePfrNDFLFK6At8ePFRJYuRg4OFgFV id7J7iBhNgELiZs/GtlAbFGBYIkND/+yQ5QLSpyc+YQFxBYBqjn/9xPYMmEBX4n7DxexgowR EtCVOL/aDSTMKaAnse/PfCaQsISAuERPYxBImFlAU6J1+292CFteonnrbLBjhICOaWjqYJ3A KDgLybJZSFpmIWlZwMi8ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwWA9u+W21g/Hgc8dD jAIcjEo8vAsutQQLsSaWFVfmHmKU5mBREue9qFEdLCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoFR8Ll2ejFbG+sW9vsJjROSUh1SvXO1K4sW/Hn2ZQrzrfczGFq5v1/O+f/g7sKZjoIFFus7 fvzdkjjnfaLAlQXGy7e/4DxVbm7w8yJXBOsBb+enEavslojorv17/3T8vjO7VgdFb/4boJHn czousqjju5Kwb+7ci0r/mZ7IK+T2qn41aPwk16CsxFKckWioxVxUnAgAH4+gKDcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/X3ONSQsOJHL2hzmNPX-PC1Bq8vw Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 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, 28 May 2014 16:23:34 -0000 Hi, Once more thanks for the review. Please response to the comments here. I have not yet addressed the nits, these will have to be addressed in a later stage. On 2014-05-15 23:31, Alissa Cooper wrote: > I have reviewed draft-ietf-mmusic-rtsp-nat-evaluation-13 and I have a > number of comments and questions below that I’d like to see resolved > before sending this document to IETF LC. I’ve also included a long list of > nits below to be resolved along with any LC comments. Overall, although > the content of this document is good, I wish the clarity would have been > better — it was quite difficult to review. > > Comments and questions: > > General: > It might be good in the introduction to characterize the extent to which > this document is focused on single-NAT environments versus CGN/multiple > NAT. The applicability of the various solutions in CGN environments is > touched on here and there, but it would be good to set out the scope at > the beginning. Ok, will add a paragraph on that. > > There are a number of references to an RSTP server being “in the public†> or “public.†I think it would be better in those cases to say that the > server is not behind a NAT, as opposed to “public." Ok, I have reworded a number of cases where it is not specific to discuss public IP addresses. > > Sec 2: > "If a client does not receive data within a few seconds after > having received the "200 OK" response to a PLAY request, there are > likely some middleboxes blocking the traffic.†> > This seems like a fairly sweeping statement. Surely the lack of response > could be caused by congestion somewhere along the path? I would suggest: > > "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.†Sure, this is more correct. > > > Sec 3: > "In terms of requirements, the > first requirement should be to solve the RTSP NAT traversal problem > for RTSP servers deployed in a public network, i.e. no NAT at the > server side.†> > What does “the first requirement†mean? It seems to me that the analysis > in Section 4 covers cases where the server is behind a NAT and where it is > not. I have replaced first with primary. It being the most important case to resolve. > > "Should have minimal impact on clients in the open and not dual-hosted." > > I don’t understand this. What does it mean for a client to be “in the > open� And are you recommending minimal impact only in the case of > single-hosted RTSP? I changed this to: "Should have minimal impact on clients not behind NATs and which are not dual-hosted." So open is the client not behind NATs or Firewalls. The requirement was written so that we should keep in mind that the impact on the clients that worked without a NAT traversal solution should not be significantly impaired by the solution. > > Sec 4.1.4: > "Using STUN does not require RTSP server modifications†> > This is only true for servers that already implement RTSP 2.0. This should > be made explicit. Ok > > Sec 4.2.5: > "The removal of STUN capability in > the client implementations will have to wait until there is > absolutely no need to use STUN.†> > I don’t quite get why this text is here. Of course if NAT ever disappears > entirely, then none of the mechanisms described in this document will be > necessary, but that seems unlikely any time soon. I made a minor tweak to be even clear on how absurd they are. Please see below. > > In general, I’m not sure I understand the purpose of the “Transition†> sections in this document, nor do I understand why they appear for some of > the mechanisms but not others. Could the authors provide a justification > for that? Short Answer: Because IAB made us do it ;-). The long answer is that these are the UNSAF "transition" sections that RFC 3424 requires when discussing UNSAF mechanisms. Thus, all sections containing UNSAF solutions have them, not the others. > > Sec 4.2.6: > The previous section said "See next section for an in-depth security > discussion†and this section just points back to 4.1.5. Was that > intentional? Yes, to not break the template. > > Sec 4.3.2: > “High performance rather than always successful is recommended, as it > is most likely to be a server in the public.†> > Not quite sure what this means. I assume the “it†refers to the server to > which the client is connecting? Even so, I don’t understand the claim. Is > it that in general RTSP servers are more likely to be directly addressable > than they are to be behind a NAT? I think this is clearer: High performance candidates is recommended rather than candidates with the highest likely hood of success, as it is more likely that a server is not behind a NAT compared to a SIP user-agent. > > Sec 4.3.5: > For a section that is meant to explain the security properties of this > solution choice, this seems a little thin. In particular, it’s not clear > what it means to use ICE “correctly.†There are some attacks that are only > mitigated if RTSP signaling is confidentiality protected — that’s not > really a matter of “correctness,†but an implementation choice that > deserves mention here. Yes, added. "An important factor is to secure the signalling, i.e. use TLS between RTSP client and server." > > Sec. 4.4.3: > "The format of the RTP packet for "connection setup" (a.k.a > Latching packet) is yet to be defined. One possibility is to use > RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].†> > I’m assuming there isn’t actually any plan to define this. If that’s the > case, it would be better to just say so, rather than implying otherwise. > The text in 4.5.1 gets this right. I have reformulated this bullet to: o The format of the RTP packet for "connection setup" (a.k.a Latching packet) is not defined. One possibility considered was to use RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op], a proposal which has been abandoned. > > Sec 4.5.1: > "Latching as described above requires the usage of a valid RTP format > as the Latching packet, i.e. the first packet that the client sends > to the server to set up virtual RTP connection. > > Need different phrasing for “virtual RTP connection†— it’s not actually > virtual. Sure, what about: the first packet that the client sends to the server to establish a bi-directional transport flow for RTP streams. > > Sec 4.7.4: > "An ALG will not work with deployment of end-to-end RTSP signaling > security. Therefore deployment of ALG will likely result in clients > located behind NATs not using end-to-end security.†> > Not sure that’s the only conclusion to be drawn here, particularly if the > client can traverse the NAT using some other mechanism. Are you fishing for something like this? An ALG will not work with deployment of end-to-end RTSP signaling security. Therefore deployment of ALG will likely result in clients located behind NATs not using end-to-end security, or more likely select a NAT traversal solution that allow for security. > > Sec 4.9.1: > "This means that TURN could only be used if the server knows and > accepts that the IP belongs to a TURN server and the TURN server > can't be targeted at an unknown address or also the RTSP connection > is relayed through the same TURN server.†> > Not sure what is meant by the clause that begins “or also.†Is this clearer (instead of the "or also ...") Alternatively, both the RTSP TCP connection as well as the RTP media is relayed through the same TURN server. > > Sec 5: > Is it worth noting here the implications for firewalls when RTSP uses > confidentiality protection? Something like this? The above possibilities for firewalls to inspect and respond to the signalling are prevented if confidentiality protection is used for the RTSP signalling, e.g. using the specified RTSP over TLS. This results in that firewalls can't be actively opening pinholes for the media streams based on the signalling. Instead other methods have to be used to enable the transport flows for the media. > > Sec 6: > Why are C1 and C2 not discussed in Section 3? The case for C1 is discussed in the second paragraph of the section. C2 I think you are correct are not discussed in that section, but it is discussed in Section 2. Yes the linkage could be greater, but the information is present from my perspective, just maybe not as clear or where you may have expected it to be. > > Sec 8: > Conspicuously missing from this section is a discussion of the security > properties of ICE. Given that it is the chosen mechanism, those need to be > discussed here, at least at the same cursory level as the security > considerations for all of the other mechanisms. I propose to add the following: ICE resolves the binding vulnerability of latching by using signed STUN messages, as well as requiring that both sides perform connectivity checks to verify that the target IP address in the candidate pair is both reachable and willing to respond. ICE can however create a significant amount of traffic if the number of candidate pairs are large. Thus pacing is required and implementations should attempt to limit their number of candidates to reduce the number of packets. If the signalling between the ICE peers (RTSP client and Server) is not confidentiality and integrity protected ICE is vulnerable to attacks where the candidate list is manipulated. Lack of signalling security will also simplify spoofing of STUN binding messages by revealing the secret used in signing. Will address the below nits in a later revision. I intended to submit a version now, to enable this document to take at least some more step towards publication while I am away. Cheers Magnus > > --- > > Nits to be resolved with any IETF last call comments received: > > General: > “Firewall" should not be capitalized unless it appears at the beginning of > a sentence or in the title of referenced document. > > Sec 1: > s/This document is capturing/This document captures/ > > Sec 2: > s/techniques in the next chapter/techniques discussed in the next section/ > > s/A RTP session/An RTP session/ > > s/no RTP packets has arrived/no RTP packets have arrived/ > > s/client can not get through/client cannot get through/ > > Section 3: > s/for RTSP NAT solutions/for RTSP NAT traversal solutions/ > > s/connection till arrival/connection until arrival/ > > Sec 4.1.2: > s/See [RFC4787] for full definition of these terms.// > (terms are also defined in this document > > s/A RTSP client/An RTSP client/ > > s/a NAT(s)/a NAT/ > > s/a RTSP PLAY request/an RTSP PLAY request/ > > Sec 4.1.4: > s/a RTSP-aware ALG /an RTSP-aware ALG / > > Sec 4.2.2: > s/one of the can/one of them can/ > > s/establishing TCP connection/establishing a TCP connection/ > > Sec 4.2.5: > s/a IETF standard/an IETF standard/ > > Sec 4.4: > s/Latching/latching/ (throughout the document) > > Sec 4.4.3: > s/an public IP address./a public IP address./ > > Sec. 4.4.4: > s/the possible address a latching packet can come from to the same as the > RTSP TCP connection are from/the source address of a latching packet to be > the same as the source address of the RTSP TCP connection/ > > s/it is difficult to determine the address usage for the network the > client connects from./it cannot be assumed that addresses within the range > all belong to the same client./ > > s/the server will send from and also the SSRC the client will use./that > the server will send from and that the SSRC client will use./ > > s/Having this information/Having this information,/ > > s/legit/legitimate/ > (two occurrences) > > s/which results in that the media server sends the RTP/RTCP traffic to > ports the client isn’t listening for RTP/RTCP on./which results in the > media server sending the RTP/RTCP traffic to ports on which the client is > not listening for RTP/RTCP./ > > s/client to server network path/client-to-server network path/ > > s/To improve the security against attackers/To improve the security > against attackers,/ > > Sec. 4.5.1: > s/[I-D.ietf-avt-rtp-no-op], however, that work was > abandoned./[I-D.ietf-avt-rtp-no-op]. However, that work was abandoned./ > > OLD: > There exists a RFC that discusses the implication of different type of > packets as keep-alives for RTP [RFC6263] and its findings are very > relevant to the format of the Latching packet. > > NEW: > The findings of [RFC6263] concerning the implications of different types > of packets as keep-alives for RTP are very relevant to the format of the > Latching packet. > > s/there has been/there have been/ > > Sec. 4.5.2: > s/so called/so-called/ > > s/as Latching packet/as a Latching packet/ > > Sec 4.5.3: > s/(Requirement 4 in Section 3), instead a Latching protocol must be > defined./(Requirement 4 in Section 3). Instead a Latching protocol must be > defined./ > > Sec 4.5.4: > s/more unlikely/less likely/ > > s/works and when it didn’t/worked and when it did not/ > > s/security issue remain/security issue remains/ > > s/a RTSP client/an RTSP client/ > > s/likes to/intends to/ > > s/an DoS target/a DoS target/ > > Sec 4.6: > s/three way Latching/three-way latching/ (throughout) > > Sec 4.6.2: > s/Uses the same RTSP extensions/Three-way latching uses the same RTSP > extensions/ > > s/client to server latching packet/client-to-server latching packet/ > > s/an UDP packet/a UDP packet/ > > s/nonce. Thus confirming/nonce, thus confirming/ > > s/a RTSP client/an RTSP client/ > > Sec 4.6.3: > s/have the following/has the following/ > > Sec 4.7.4: > s/an UDP mapping/a UDP mapping/ > > s/with RTSP ALG/with an RTSP ALG/ > > Sec 4.8.3: > s/where the RTSP server in not NATed or at least reachable like it was > not./where the RTSP server is not NATed or is reachable as if it were not > NATed./ > > Sec 4.9.1: > s/a RTSP client/an RTSP client/ > > s/the IP belongs/the IP address belongs/ > > Sec 4.9.2: > s/addresses also the TCP connection must be done through the same TURN > server as the one in the next step./addresses, the TCP connection must be > made through the same TURN server to be used for NAT traversal./ > > s/that it desires/where it desires/ > > Sec 4.9.3: > s/has public/has a public/ > > Sec 4.9.4: > s/a RTSP session/an RTSP session/ > > s/Which would/This would/ > > Sec 5: > s/a RTSP session/an RTSP session/ > > > s/what type of transport and from where, the media stream packets will be > sent./what type of transport will be used and from where the media stream > packets will be sent./ > > Sec 6: > s/R1: Work/R1: Must work/ > > s/use, Implement and administer/use, implement and administer/ > > OLD: > C1: Will solution support both Clients and Servers behind NAT > > C2: Is the solution robust to changing NAT behaviors > NEW: > > C1: Supports both clients and servers behind NAT > > C2: Is robust to changing NAT behaviors > > s/using TCP Tunneling or Three-Way Latching is the solutions that best > fulfill/TCP Tunneling or Three-Way Latching is the solution that best > fulfills/ > > s/is acceptable/are acceptable/ > > s/When it comes to Three-Way Latching it is a very competitive technique > given that you don't need support for RTSP servers behind NATs./Three-Way > Latching is a comparable technique in situations where support for RTSP > servers behind NATs is not required./ > > s/were some discussion/were some discussions/ > > s/In the end the authors believe that reuse of ICE, the greater > flexibility and anyway need to deploy a new solution was the decisive > factors./In the end, the WG concluded that reuse of ICE, its greater > flexibility, and the need to deploy a new solution in either case were the > decisive factors in favor of ICE./ > > Sec 8: > s/IP-address/IP address/ > > s/those variants/of those variants/ > > Sec 9: > s/has commented/have commented/ > > s/protocol/document/ > > > > > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed May 28 09:25:19 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 913811A0A28; Wed, 28 May 2014 09:25:18 -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 VOjss3L-cMnr; Wed, 28 May 2014 09:25:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D48511A04C5; Wed, 28 May 2014 09:25:16 -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: <20140528162516.26601.64898.idtracker@ietfa.amsl.com> Date: Wed, 28 May 2014 09:25:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Zv46U3Zd2-1s0SwQ2B1XCPrzuaw Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-14.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: Wed, 28 May 2014 16:25:18 -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 : The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) Authors : Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-evaluation-14.txt Pages : 41 Date : 2014-05-28 Abstract: This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-14 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 Wed May 28 10:44: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 A7C581A01CC for ; Wed, 28 May 2014 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 iLHOU1CO6dj3 for ; Wed, 28 May 2014 10:44:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BDB1A046B for ; Wed, 28 May 2014 10:44:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 274BA21486; Wed, 28 May 2014 13:44:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 28 May 2014 13:44:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=VJV4uFlvmy 5FW0BX4YjRstsLnuY=; b=UMD3tnGzYr2S1S+CXRrggDn73qRcrPhAWFlVIDIxz5 NnsiMuMnzy2VJopiZHlUMZ8It1zVl6Xlh4aBaceu1M1LGFEvUTe0nxxhQPRmfbK/ bEKyGyFniuomXRjrLMBBhPdGHysuzs1xSWg0ibajCAwuXeviKiijOOMsYXFRu9XY w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=VJV4uFlvmy5FW0BX4YjRst sLnuY=; b=PrI+04GzsYFYC//ifXWRLmMWEoWktsQp7GIm1IzzKhOp/Rc1kvhHRs QCKLQKUoAp7dYE9sr0AXuVF9vqlOTZOwFxncvHMPPlpSi1iKR0pwXn2fDqXqbOec WPdMcJXnppTiMOqAdftVvsI70ClPOm4OW7WFcgojwtoMs8Qm7y1ys= X-Sasl-enc: wQjfy2tDMawAtwt2Bk1bx8ZDZXQsMHLq4rO3GkMoHNUY 1401299066 Received: from [171.68.18.44] (unknown [171.68.18.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EA0F680190; Wed, 28 May 2014 13:44:25 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 28 May 2014 10:44:20 -0700 From: Alissa Cooper To: Magnus Westerlund , Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 References: <53860D75.2010400@ericsson.com> In-Reply-To: <53860D75.2010400@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ye9sb66nkrcMSsENOy49DU3dxTQ Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 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, 28 May 2014 17:44:39 -0000 Thanks. These mostly look good. I will send detailed responses in a separate mail so that together with the nits there will be a record of what further changes need to be made after IETF LC, and after that I=E2=80=99ll issue the LC. Alissa On 5/28/14, 9:23 AM, "Magnus Westerlund" wrote: >Hi, > >Once more thanks for the review. Please response to the comments here. I >have not yet addressed the nits, these will have to be addressed in a >later stage. > >On 2014-05-15 23:31, Alissa Cooper wrote: >> I have reviewed draft-ietf-mmusic-rtsp-nat-evaluation-13 and I have a >> number of comments and questions below that I=E2=80=99d like to see resolved >> before sending this document to IETF LC. I=E2=80=99ve also included a long lis= t >>of >> nits below to be resolved along with any LC comments. Overall, although >> the content of this document is good, I wish the clarity would have been >> better =E2=80=94 it was quite difficult to review. >>=20 >> Comments and questions: >>=20 >> General: >> It might be good in the introduction to characterize the extent to which >> this document is focused on single-NAT environments versus CGN/multiple >> NAT. The applicability of the various solutions in CGN environments is >> touched on here and there, but it would be good to set out the scope at >> the beginning. > >Ok, will add a paragraph on that. > >>=20 >> There are a number of references to an RSTP server being =E2=80=9Cin the publi= c=E2=80=9D >> or =E2=80=9Cpublic.=E2=80=9D I think it would be better in those cases to say that t= he >> server is not behind a NAT, as opposed to =E2=80=9Cpublic." > >Ok, I have reworded a number of cases where it is not specific to >discuss public IP addresses. > >>=20 >> Sec 2: >> "If a client does not receive data within a few seconds after >> having received the "200 OK" response to a PLAY request, there are >> likely some middleboxes blocking the traffic.=E2=80=9D >>=20 >> This seems like a fairly sweeping statement. Surely the lack of response >> could be caused by congestion somewhere along the path? I would suggest: >>=20 >> "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.=E2=80=9D > >Sure, this is more correct. > >>=20 >>=20 >> Sec 3: >> "In terms of requirements, the >> first requirement should be to solve the RTSP NAT traversal problem >> for RTSP servers deployed in a public network, i.e. no NAT at the >> server side.=E2=80=9D >>=20 >> What does =E2=80=9Cthe first requirement=E2=80=9D mean? It seems to me that the anal= ysis >> in Section 4 covers cases where the server is behind a NAT and where it >>is >> not. > >I have replaced first with primary. It being the most important case to >resolve. > >>=20 >> "Should have minimal impact on clients in the open and not dual-hosted." >>=20 >> I don=E2=80=99t understand this. What does it mean for a client to be =E2=80=9Cin th= e >> open=E2=80=9D? And are you recommending minimal impact only in the case of >> single-hosted RTSP? > >I changed this to: > >"Should have minimal impact on clients not behind NATs and which are not >dual-hosted." > >So open is the client not behind NATs or Firewalls. > >The requirement was written so that we should keep in mind that the >impact on the clients that worked without a NAT traversal solution >should not be significantly impaired by the solution. > >>=20 >> Sec 4.1.4: >> "Using STUN does not require RTSP server modifications=E2=80=9D >>=20 >> This is only true for servers that already implement RTSP 2.0. This >>should >> be made explicit. > >Ok > > >>=20 >> Sec 4.2.5: >> "The removal of STUN capability in >> the client implementations will have to wait until there is >> absolutely no need to use STUN.=E2=80=9D >>=20 >> I don=E2=80=99t quite get why this text is here. Of course if NAT ever >>disappears >> entirely, then none of the mechanisms described in this document will be >> necessary, but that seems unlikely any time soon. > >I made a minor tweak to be even clear on how absurd they are. Please see >below. > >>=20 >> In general, I=E2=80=99m not sure I understand the purpose of the =E2=80=9CTransition= =E2=80=9D >> sections in this document, nor do I understand why they appear for some >>of >> the mechanisms but not others. Could the authors provide a justification >> for that? > > >Short Answer: Because IAB made us do it ;-). The long answer is that >these are the UNSAF "transition" sections that RFC 3424 requires when >discussing UNSAF mechanisms. Thus, all sections containing UNSAF >solutions have them, not the others. > >>=20 >> Sec 4.2.6: >> The previous section said "See next section for an in-depth security >> discussion=E2=80=9D and this section just points back to 4.1.5. Was that >> intentional? > >Yes, to not break the template. > >>=20 >> Sec 4.3.2: >> =E2=80=9CHigh performance rather than always successful is recommended, as it >> is most likely to be a server in the public.=E2=80=9D >>=20 >> Not quite sure what this means. I assume the =E2=80=9Cit=E2=80=9D refers to the serv= er >>to >> which the client is connecting? Even so, I don=E2=80=99t understand the claim. >>Is >> it that in general RTSP servers are more likely to be directly >>addressable >> than they are to be behind a NAT? > >I think this is clearer: > >High performance candidates is recommended rather than candidates with >the highest likely hood of success, as it is more likely that a server >is not behind a NAT compared to a SIP user-agent. > > >>=20 >> Sec 4.3.5: >> For a section that is meant to explain the security properties of this >> solution choice, this seems a little thin. In particular, it=E2=80=99s not cle= ar >> what it means to use ICE =E2=80=9Ccorrectly.=E2=80=9D There are some attacks that ar= e >>only >> mitigated if RTSP signaling is confidentiality protected =E2=80=94 that=E2=80=99s no= t >> really a matter of =E2=80=9Ccorrectness,=E2=80=9D but an implementation choice that >> deserves mention here. > >Yes, added. > >"An important factor is to secure the signalling, i.e. use TLS between >RTSP client and server." > > >>=20 >> Sec. 4.4.3: >> "The format of the RTP packet for "connection setup" (a.k.a >> Latching packet) is yet to be defined. One possibility is to use >> RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].=E2=80=9D >>=20 >> I=E2=80=99m assuming there isn=E2=80=99t actually any plan to define this. If that=E2=80= =99s the >> case, it would be better to just say so, rather than implying otherwise. >> The text in 4.5.1 gets this right. > >I have reformulated this bullet to: > > o The format of the RTP packet for "connection setup" (a.k.a > Latching packet) is not defined. One possibility considered was > to use RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op], a > proposal which has been abandoned. > >>=20 >> Sec 4.5.1: >> "Latching as described above requires the usage of a valid RTP format >> as the Latching packet, i.e. the first packet that the client sends >> to the server to set up virtual RTP connection. >>=20 >> Need different phrasing for =E2=80=9Cvirtual RTP connection=E2=80=9D =E2=80=94 it=E2=80=99s not = actually >> virtual. > >Sure, what about: > > the first packet that the client sends to the server to establish a >bi-directional transport flow for RTP streams. > >>=20 >> Sec 4.7.4: >> "An ALG will not work with deployment of end-to-end RTSP signaling >> security. Therefore deployment of ALG will likely result in clients >> located behind NATs not using end-to-end security.=E2=80=9D >>=20 >> Not sure that=E2=80=99s the only conclusion to be drawn here, particularly if >>the >> client can traverse the NAT using some other mechanism. > >Are you fishing for something like this? > >An ALG will not work with deployment of end-to-end RTSP signaling >security. Therefore deployment of ALG will likely result in clients >located behind NATs not using end-to-end security, or more likely select >a NAT traversal solution that allow for security. > >>=20 >> Sec 4.9.1: >> "This means that TURN could only be used if the server knows and >> accepts that the IP belongs to a TURN server and the TURN server >> can't be targeted at an unknown address or also the RTSP connection >> is relayed through the same TURN server.=E2=80=9D >>=20 >> Not sure what is meant by the clause that begins =E2=80=9Cor also.=E2=80=9D > >Is this clearer (instead of the "or also ...") > >Alternatively, both the RTSP TCP connection as well as the RTP media is >relayed through the same TURN server. > >>=20 >> Sec 5: >> Is it worth noting here the implications for firewalls when RTSP uses >> confidentiality protection? > >Something like this? > >The above possibilities for firewalls to inspect and respond to the >signalling are prevented if confidentiality protection is used for the >RTSP signalling, e.g. using the specified RTSP over TLS. This results in >that firewalls can't be actively opening pinholes for the media streams >based on the signalling. Instead other methods have to be used to enable >the transport flows for the media. > >>=20 >> Sec 6: >> Why are C1 and C2 not discussed in Section 3? > >The case for C1 is discussed in the second paragraph of the section. C2 >I think you are correct are not discussed in that section, but it is >discussed in Section 2. > >Yes the linkage could be greater, but the information is present from my >perspective, just maybe not as clear or where you may have expected it >to be. > >>=20 >> Sec 8: >> Conspicuously missing from this section is a discussion of the security >> properties of ICE. Given that it is the chosen mechanism, those need to >>be >> discussed here, at least at the same cursory level as the security >> considerations for all of the other mechanisms. > >I propose to add the following: > >ICE resolves the binding vulnerability of latching by using signed STUN >messages, as well as requiring that both sides perform connectivity >checks to verify that the target IP address in the candidate pair is >both reachable and willing to respond. ICE can however create a >significant amount of traffic if the number of candidate pairs are >large. Thus pacing is required and implementations should attempt to >limit their number of candidates to reduce the number of packets. If the >signalling between the ICE peers (RTSP client and Server) is not >confidentiality and integrity protected ICE is vulnerable to attacks >where the candidate list is manipulated. Lack of signalling security >will also simplify spoofing of STUN binding messages by revealing the >secret used in signing. > > > > >Will address the below nits in a later revision. I intended to submit a >version now, to enable this document to take at least some more step >towards publication while I am away. > >Cheers > >Magnus > >>=20 >> --- >>=20 >> Nits to be resolved with any IETF last call comments received: >>=20 >> General: >> =E2=80=9CFirewall" should not be capitalized unless it appears at the beginnin= g >>of >> a sentence or in the title of referenced document. >>=20 >> Sec 1: >> s/This document is capturing/This document captures/ >>=20 >> Sec 2: >> s/techniques in the next chapter/techniques discussed in the next >>section/ >>=20 >> s/A RTP session/An RTP session/ >>=20 >> s/no RTP packets has arrived/no RTP packets have arrived/ >>=20 >> s/client can not get through/client cannot get through/ >>=20 >> Section 3: >> s/for RTSP NAT solutions/for RTSP NAT traversal solutions/ >>=20 >> s/connection till arrival/connection until arrival/ >>=20 >> Sec 4.1.2: >> s/See [RFC4787] for full definition of these terms.// >> (terms are also defined in this document >>=20 >> s/A RTSP client/An RTSP client/ >>=20 >> s/a NAT(s)/a NAT/ >>=20 >> s/a RTSP PLAY request/an RTSP PLAY request/ >>=20 >> Sec 4.1.4: >> s/a RTSP-aware ALG /an RTSP-aware ALG / >>=20 >> Sec 4.2.2: >> s/one of the can/one of them can/ >>=20 >> s/establishing TCP connection/establishing a TCP connection/ >>=20 >> Sec 4.2.5: >> s/a IETF standard/an IETF standard/ >>=20 >> Sec 4.4: >> s/Latching/latching/ (throughout the document) >>=20 >> Sec 4.4.3: >> s/an public IP address./a public IP address./ >>=20 >> Sec. 4.4.4: >> s/the possible address a latching packet can come from to the same as >>the >> RTSP TCP connection are from/the source address of a latching packet to >>be >> the same as the source address of the RTSP TCP connection/ >>=20 >> s/it is difficult to determine the address usage for the network the >> client connects from./it cannot be assumed that addresses within the >>range >> all belong to the same client./ >>=20 >> s/the server will send from and also the SSRC the client will use./that >> the server will send from and that the SSRC client will use./ >>=20 >> s/Having this information/Having this information,/ >>=20 >> s/legit/legitimate/ >> (two occurrences) >>=20 >> s/which results in that the media server sends the RTP/RTCP traffic to >> ports the client isn=E2=80=99t listening for RTP/RTCP on./which results in the >> media server sending the RTP/RTCP traffic to ports on which the client >>is >> not listening for RTP/RTCP./ >>=20 >> s/client to server network path/client-to-server network path/ >>=20 >> s/To improve the security against attackers/To improve the security >> against attackers,/ >>=20 >> Sec. 4.5.1: >> s/[I-D.ietf-avt-rtp-no-op], however, that work was >> abandoned./[I-D.ietf-avt-rtp-no-op]. However, that work was abandoned./ >>=20 >> OLD: >> There exists a RFC that discusses the implication of different type of >> packets as keep-alives for RTP [RFC6263] and its findings are very >> relevant to the format of the Latching packet. >>=20 >> NEW: >> The findings of [RFC6263] concerning the implications of different types >> of packets as keep-alives for RTP are very relevant to the format of the >> Latching packet. >>=20 >> s/there has been/there have been/ >>=20 >> Sec. 4.5.2: >> s/so called/so-called/ >>=20 >> s/as Latching packet/as a Latching packet/ >>=20 >> Sec 4.5.3: >> s/(Requirement 4 in Section 3), instead a Latching protocol must be >> defined./(Requirement 4 in Section 3). Instead a Latching protocol must >>be >> defined./ >>=20 >> Sec 4.5.4: >> s/more unlikely/less likely/ >>=20 >> s/works and when it didn=E2=80=99t/worked and when it did not/ >>=20 >> s/security issue remain/security issue remains/ >>=20 >> s/a RTSP client/an RTSP client/ >>=20 >> s/likes to/intends to/ >>=20 >> s/an DoS target/a DoS target/ >>=20 >> Sec 4.6: >> s/three way Latching/three-way latching/ (throughout) >>=20 >> Sec 4.6.2: >> s/Uses the same RTSP extensions/Three-way latching uses the same RTSP >> extensions/ >>=20 >> s/client to server latching packet/client-to-server latching packet/ >>=20 >> s/an UDP packet/a UDP packet/ >>=20 >> s/nonce. Thus confirming/nonce, thus confirming/ >>=20 >> s/a RTSP client/an RTSP client/ >>=20 >> Sec 4.6.3: >> s/have the following/has the following/ >>=20 >> Sec 4.7.4: >> s/an UDP mapping/a UDP mapping/ >>=20 >> s/with RTSP ALG/with an RTSP ALG/ >>=20 >> Sec 4.8.3: >> s/where the RTSP server in not NATed or at least reachable like it was >> not./where the RTSP server is not NATed or is reachable as if it were >>not >> NATed./ >>=20 >> Sec 4.9.1: >> s/a RTSP client/an RTSP client/ >>=20 >> s/the IP belongs/the IP address belongs/ >>=20 >> Sec 4.9.2: >> s/addresses also the TCP connection must be done through the same TURN >> server as the one in the next step./addresses, the TCP connection must >>be >> made through the same TURN server to be used for NAT traversal./ >>=20 >> s/that it desires/where it desires/ >>=20 >> Sec 4.9.3: >> s/has public/has a public/ >>=20 >> Sec 4.9.4: >> s/a RTSP session/an RTSP session/ >>=20 >> s/Which would/This would/ >>=20 >> Sec 5: >> s/a RTSP session/an RTSP session/ >>=20 >>=20 >> s/what type of transport and from where, the media stream packets will >>be >> sent./what type of transport will be used and from where the media >>stream >> packets will be sent./ >>=20 >> Sec 6: >> s/R1: Work/R1: Must work/ >>=20 >> s/use, Implement and administer/use, implement and administer/ >>=20 >> OLD: >> C1: Will solution support both Clients and Servers behind NAT >>=20 >> C2: Is the solution robust to changing NAT behaviors >> NEW: >>=20 >> C1: Supports both clients and servers behind NAT >>=20 >> C2: Is robust to changing NAT behaviors >>=20 >> s/using TCP Tunneling or Three-Way Latching is the solutions that best >> fulfill/TCP Tunneling or Three-Way Latching is the solution that best >> fulfills/ >>=20 >> s/is acceptable/are acceptable/ >>=20 >> s/When it comes to Three-Way Latching it is a very competitive technique >> given that you don't need support for RTSP servers behind >>NATs./Three-Way >> Latching is a comparable technique in situations where support for RTSP >> servers behind NATs is not required./ >>=20 >> s/were some discussion/were some discussions/ >>=20 >> s/In the end the authors believe that reuse of ICE, the greater >> flexibility and anyway need to deploy a new solution was the decisive >> factors./In the end, the WG concluded that reuse of ICE, its greater >> flexibility, and the need to deploy a new solution in either case were >>the >> decisive factors in favor of ICE./ >>=20 >> Sec 8: >> s/IP-address/IP address/ >>=20 >> s/those variants/of those variants/ >>=20 >> Sec 9: >> s/has commented/have commented/ >>=20 >> s/protocol/document/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Wed May 28 12:05:32 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 D435B1A6F5A for ; Wed, 28 May 2014 12:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 rdLeyC-oAd7H for ; Wed, 28 May 2014 12:05:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0061A6F3B for ; Wed, 28 May 2014 12:05:29 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 44C0921A86 for ; Wed, 28 May 2014 15:05:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 28 May 2014 15:05:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=6EWfvxlS+h DnwiOO7EsCHUhypEI=; b=TQgml54j0UQcvceiPrly7NLAnw+U1I1FjEYf3r6a6R wmJy5MAPBk4V3hLid0LWaA536lP/9Nxf4wwCVpZAJ7kOm3rfa3u2SA2fXgLgftQ1 Qn4ubsvtUZkCCXcPSmDJl9pQxayVA5huxja9Eu1IfNYZQgTJ3+EDbv4JbmBrLQnJ M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=6EWfvxlS+hDnwiOO7EsCHU hypEI=; b=adV+cfEcuYAM+NBrZ8vOiqlyx0KqiujUuvgC4/0G01CxQM6aq+VROR TlFsAgy+Yj0CpVgEoBbUWeKyJgoy4nyR2OVNHlcv4zSluf80nK8agkKHpLkbGmjR B8YhropI5ManC7c/Vn4sGTVsLEzkqNNdNKtxw2hMvFXGi1XbGdEGI= X-Sasl-enc: zWkNmqQW2oguiafgvJuuNNv9lfY37FwZH5D4HHDjTU/1 1401303923 Received: from [171.68.18.44] (unknown [171.68.18.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B46EC00003; Wed, 28 May 2014 15:05:21 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 28 May 2014 12:05:13 -0700 From: Alissa Cooper To: Christer Holmberg , "mmusic@ietf.org" Message-ID: Thread-Topic: AD evaluation: draft-ietf-mmusic-udptl-dtls-07 References: <7594FB04B1934943A5C02806D1A2204B1D3418D1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3418D1@ESESSMB209.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/iUm7SCsZK6NwYB9VvTAXMnpm5zA Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-udptl-dtls-07 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, 28 May 2014 19:05:31 -0000 On 5/28/14, 1:07 AM, "Christer Holmberg" wrote: >Hi Alissa, > >Thanks for your review and comments! Reply inline. > >>I have reviewed this document in preparation for IETF last call. It=E2=80=99s i= n >>good shape. I will issue the last call. Couple of nits to be resolved >>with any last call comments: >> >>Section 1: >>s/clearly defined, well understood and implementations are widely >>available./clearly defined and well understood and implementations are >>widely available./ >> >>Section 4.5: >>s/same rules of for/same rules for/ > >We'll do the changes as suggested. > >Do you want us to do them now, before the IESG review, and submit a new >version of the draft? No, you can wait until LC ends. Thanks, Alissa > >Regards, > >Christer > From nobody Wed May 28 15:32: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 B59E11A0702 for ; Wed, 28 May 2014 15:32: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 XD9IyoJEX4f1 for ; Wed, 28 May 2014 15:32:33 -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 DDB1B1A06F0 for ; Wed, 28 May 2014 15:32:32 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so11728378wes.21 for ; Wed, 28 May 2014 15:32:28 -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=FcDNB5PgNRYvp0iPILjEDvA5irMUW+SrUdKTEzjfaWw=; b=g/Jj9mkqG/B13K9LHRznN1T54myaB3DVaXYAiuKU698mUhNr/su9hhfhSk6MEnI2ft EukZQN4KnNbUn1wvBzE3aq9t/BvrmOvVKhdadl8sz5Owobcyt/3RYzpADEofoHgHp5Kv Iw9bSQX9eAQMhJbKBTU7F2e6GhCvTE9lUjmP/5nHnjCH3ZyFtJ5N04iZ9tl0CuhGzr24 ZuTDqgjAEunHhb52r5uu9KAnUqsrAk7mK4ee5RZNGGea1LyoY8uEf18YSVuYu6eoX04a /7b8qWZwDTAX6IzNtYSOwK6StEAJ8YiQMa0L2qElgZYoF3jbtbFDxVscnj7jHga92C62 y+rw== X-Gm-Message-State: ALoCoQldd7mVoYiERMA4R8c81nSQ09WPyHieYgWD4SpmHkE5D0Rf4oV1LJ5PH5vLW5rzzSeHpwBF X-Received: by 10.194.63.46 with SMTP id d14mr4137913wjs.24.1401316348205; Wed, 28 May 2014 15:32:28 -0700 (PDT) Received: from camionet.local (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id b1sm46591918wjb.37.2014.05.28.15.32.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 15:32:25 -0700 (PDT) Message-ID: <538663F1.4080709@jitsi.org> Date: Thu, 29 May 2014 00:32:17 +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: "Vijay K. Gurbani" , "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org References: <537F520E.3060501@bell-labs.com> In-Reply-To: <537F520E.3060501@bell-labs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BwXIvHUZp54mgph1v006lGhmJqU Cc: IESG IESG , mmusic Subject: Re: [MMUSIC] 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, 28 May 2014 22:32:36 -0000 Hey Vijay, Thanks for your review! Comments inline. On 23.05.14, 15:50, Vijay K. Gurbani wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see ​ > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-mmusic-latching-05 > Title: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time > Communication > Reviewer: Vijay K. Gurbani > Review Date: May 23-2014 > IETF Last Call Date: May-28-2014 > IESG Telechat Date: May-29-2014 > > Summary: This draft is almost ready for publication as an Informational > RFC but has a few issues that should be fixed before publication. > > The draft captures excellent discussions on latching and provides a > great overview on what it is, how it works, and despite its simplicity, > why not to use it. However, the tone of the draft should change from > colloquial to something more objective (various examples of this in > the Nits section). > > Major: 0 > Minor: numerous (see below) > Nits: numerous (see below) > > Minor: > > - S1, second to last paragraph: Not sure I understand what you mean by > > The SIP signaling-layer component of HNT is typically more > implementation-specific and deployment-specific than the SDP and > media components. > > 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. SIP's routing features provide for several ways of doing NAT traversal for signalling. Some can be entirely transparent to a UA (basically terminating the session at the SBC) others could do it in a more opaque and SIP-y way like for example the one described in: http://tools.ietf.org/html/rfc3665#section-3.5 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? > - S3, second paragraph: "newly introduced media relay" --- newly > introduced to who? That was meant from a general perspective. So "newly introduced" to the reader. > Perhaps you mean "a media relay incorporated into > session establishment"? Right. > Is this paragraph saying that the SBC and > media relay may be co-located on the same host? It is saying that it is most often the same, that it can also be a different one in some cases and that it would almost always be of the same address family. In other words: if we confirmed that a UA has IPv4 access to an SBC it is unlikely that we will risk introducing an IPv6 relay. 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? > - 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". > - 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! > - 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 :) > - 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? > - 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 > - 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? > - S5, second paragraph: s/In all/All/ Oh right! Much better! > - S5, second paragraph: s/disturb media/impact media/ Thanks! > - S5, third paragraph: > s/since the SBC will not latch onto the attacker's packets./since the > SBC will not latch onto the attacker's media packets, not having > seen the corresponding signaling packets first./ OK > - 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? Case 2 is about the attacker being behind the same NAT as the UA, so traffic from the attacked would appear legit to the SBC. > Teasing this case further, if the legitimate user hangs up the call > because it is not getting any media packets, then a BYE should go > through the SBC causing it to discard latched states, thereby > preventing any more media packets from going to the attacker. Right, but that's already mentioned in the text: the legitimate SIP UA will end the call anyway, because a human user would not hear anything and will hang up. > Assuming that the attacker had inserted itself as a man-in-the-middle > and was relaying packets to the UA, then sure, the legitimate user > will not hang up and continue conversing. > > The case of a non-human user (answering machine) is redundant since > the behaviour of the user (non-human or otherwise) is essentially > the same. 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. > - 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? > Nits: > > - 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. > - S1, second paragraph: s/They use IP/These protocols use IP/ OK > - S1, second paragraph: s/as, in the/as, and in the/ OK > - S1, fourth paragraph: > s/some manufacturers sometimes/a number of manufacturers sometimes/ Thanks > - S1, fifth paragraph: s/creation time/publication/ OK > - S1, fifth paragraph: s/in the foreseeable/for the foreseeable/ OK > - S1, sixth paragraph: > s/are not novel to experts/are well known in the community/ OK > - S1, seventh paragraph: > s/In no way does this document/This document does not/ OK > - 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?) > - 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 ;) ). > - S5, last sentence of second-to-last paragraph: > s/However it is sometimes argued that, neither S/MIME nor > [RFC4474] are widely deployed and that this may not be > a real concern./However, neither S/MIME or [RFC4474] are widely > deployed, thus not being able to sign/verify requests appear not > to be a concern at this time./ OK. Thanks again for the review! Emil -- https://jitsi.org From nobody Thu May 29 09:40: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 CDF1E1A042A; Thu, 29 May 2014 09:40:32 -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 a9EXQLB4qI3g; Thu, 29 May 2014 09:40:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 383E81A0177; Thu, 29 May 2014 09:40:31 -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: <20140529164031.26486.54207.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 09:40:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-S5Box4TkAyHlLQdEHITSfpnwfo Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-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: Thu, 29 May 2014 16:40:33 -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-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/ From nobody Fri May 30 12: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 E22711A8028 for ; Fri, 30 May 2014 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 KlnOltaWEMxo for ; Fri, 30 May 2014 12:12:17 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDAB1A7029 for ; Fri, 30 May 2014 12:12:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 57C3220A44 for ; Fri, 30 May 2014 15:12:12 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 30 May 2014 15:12:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=DEd+4UUDFN 3l1BBZrlWUd91ou+A=; b=Iyi6FWUfws38IVDvUPDDbf6uQ3Zjp5BZLyWn48dmjJ qJwbEgsE734kq145Zx6/DLRdt3z5ECeuUOWn9R6dn5jTh2Tkg5WOhcjcWWxvHpR+ LhuWkOZ7Yl62LSISUiSW4ZwIR7WgB4tynfiUPOp7PBEWfDSAo9VRgdGSdBWV0mH+ E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=DEd+4UUDFN3l1BBZrlWUd9 1ou+A=; b=nhvUwuq1Y2zdB3DNCK7L/YKwcGXTBuChRyXudd0/LLVTOcZjQhIehN aRuKkUGQuX9vLYckZP+76z9kjQCZV2rZUqys+9MZtFfAYDuPheNAYN6+UUY1shAO TfZBG5d+w/9VXlMFamJWZlF68+NuBMLZeUkuOEadVEZoudQ4CqyOg= X-Sasl-enc: 402SQEYWO2ec2i8a04jjPHMhAw2sB0Zv2a8KRqopIetg 1401477131 Received: from [171.68.18.44] (unknown [171.68.18.44]) by mail.messagingengine.com (Postfix) with ESMTPA id E6C09C00003; Fri, 30 May 2014 15:12:09 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 30 May 2014 12:12:07 -0700 From: Alissa Cooper To: Magnus Westerlund , Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 References: <53860D75.2010400@ericsson.com> In-Reply-To: <53860D75.2010400@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/z37e6yRYaRCOTXiY21zHvUC85_I Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13 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, 30 May 2014 19:12:21 -0000 Comments inline. On 5/28/14, 9:23 AM, "Magnus Westerlund" wrote: > >>=20 >> Sec 4.3.2: >> =E2=80=9CHigh performance rather than always successful is recommended, as it >> is most likely to be a server in the public.=E2=80=9D >>=20 >> Not quite sure what this means. I assume the =E2=80=9Cit=E2=80=9D refers to the serv= er >>to >> which the client is connecting? Even so, I don=E2=80=99t understand the claim. >>Is >> it that in general RTSP servers are more likely to be directly >>addressable >> than they are to be behind a NAT? > >I think this is clearer: > >High performance candidates is recommended rather than candidates with >the highest likely hood of success, as it is more likely that a server >is not behind a NAT compared to a SIP user-agent. s/is recommended/are recommended/ s/likely hood/likelihood/ > > >>=20 >> Sec 4.3.5: >> For a section that is meant to explain the security properties of this >> solution choice, this seems a little thin. In particular, it=E2=80=99s not cle= ar >> what it means to use ICE =E2=80=9Ccorrectly.=E2=80=9D There are some attacks that ar= e >>only >> mitigated if RTSP signaling is confidentiality protected =E2=80=94 that=E2=80=99s no= t >> really a matter of =E2=80=9Ccorrectness,=E2=80=9D but an implementation choice that >> deserves mention here. > >Yes, added. > >"An important factor is to secure the signalling, i.e. use TLS between >RTSP client and server." > > >>=20 >> Sec. 4.4.3: >> "The format of the RTP packet for "connection setup" (a.k.a >> Latching packet) is yet to be defined. One possibility is to use >> RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].=E2=80=9D >>=20 >> I=E2=80=99m assuming there isn=E2=80=99t actually any plan to define this. If that=E2=80= =99s the >> case, it would be better to just say so, rather than implying otherwise. >> The text in 4.5.1 gets this right. > >I have reformulated this bullet to: > > o The format of the RTP packet for "connection setup" (a.k.a > Latching packet) is not defined. One possibility considered was > to use RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op], a > proposal which has been abandoned. > >>=20 >> Sec 4.5.1: >> "Latching as described above requires the usage of a valid RTP format >> as the Latching packet, i.e. the first packet that the client sends >> to the server to set up virtual RTP connection. >>=20 >> Need different phrasing for =E2=80=9Cvirtual RTP connection=E2=80=9D =E2=80=94 it=E2=80=99s not = actually >> virtual. > >Sure, what about: > > the first packet that the client sends to the server to establish a >bi-directional transport flow for RTP streams. > >>=20 >> Sec 4.7.4: >> "An ALG will not work with deployment of end-to-end RTSP signaling >> security. Therefore deployment of ALG will likely result in clients >> located behind NATs not using end-to-end security.=E2=80=9D >>=20 >> Not sure that=E2=80=99s the only conclusion to be drawn here, particularly if >>the >> client can traverse the NAT using some other mechanism. > >Are you fishing for something like this? > >An ALG will not work with deployment of end-to-end RTSP signaling >security. Therefore deployment of ALG will likely result in clients >located behind NATs not using end-to-end security, or more likely select >a NAT traversal solution that allow for security. Yes, good. > >>=20 >> Sec 4.9.1: >> "This means that TURN could only be used if the server knows and >> accepts that the IP belongs to a TURN server and the TURN server >> can't be targeted at an unknown address or also the RTSP connection >> is relayed through the same TURN server.=E2=80=9D >>=20 >> Not sure what is meant by the clause that begins =E2=80=9Cor also.=E2=80=9D > >Is this clearer (instead of the "or also ...") > >Alternatively, both the RTSP TCP connection as well as the RTP media is >relayed through the same TURN server. How about: Alternatively, TURN can be used if both the RTSP TCP connection and the RTP media are relayed through the same TURN server. > >>=20 >> Sec 5: >> Is it worth noting here the implications for firewalls when RTSP uses >> confidentiality protection? > >Something like this? > >The above possibilities for firewalls to inspect and respond to the >signalling are prevented if confidentiality protection is used for the >RTSP signalling, e.g. using the specified RTSP over TLS. This results in >that firewalls can't be actively opening pinholes for the media streams >based on the signalling. Instead other methods have to be used to enable >the transport flows for the media. Looks good. > >>=20 >> Sec 6: >> Why are C1 and C2 not discussed in Section 3? > >The case for C1 is discussed in the second paragraph of the section. C2 >I think you are correct are not discussed in that section, but it is >discussed in Section 2. > >Yes the linkage could be greater, but the information is present from my >perspective, just maybe not as clear or where you may have expected it >to be. This doesn=E2=80=99t make much sense to me =E2=80=94 if you=E2=80=99re going to make a number= ed list of requirements, why not include them all in the list? > >>=20 >> Sec 8: >> Conspicuously missing from this section is a discussion of the security >> properties of ICE. Given that it is the chosen mechanism, those need to >>be >> discussed here, at least at the same cursory level as the security >> considerations for all of the other mechanisms. > >I propose to add the following: > >ICE resolves the binding vulnerability of latching by using signed STUN >messages, as well as requiring that both sides perform connectivity >checks to verify that the target IP address in the candidate pair is >both reachable and willing to respond. ICE can however create a >significant amount of traffic if the number of candidate pairs are >large. Thus pacing is required and implementations should attempt to >limit their number of candidates to reduce the number of packets. If the >signalling between the ICE peers (RTSP client and Server) is not >confidentiality and integrity protected ICE is vulnerable to attacks >where the candidate list is manipulated. Lack of signalling security >will also simplify spoofing of STUN binding messages by revealing the >secret used in signing. The above looks good. It might help to work in a reference to RFC 5245 section 18. Thanks, Alissa > > > > >Will address the below nits in a later revision. I intended to submit a >version now, to enable this document to take at least some more step >towards publication while I am away. > >Cheers > >Magnus > >>=20 >> --- >>=20 >> Nits to be resolved with any IETF last call comments received: >>=20 >> General: >> =E2=80=9CFirewall" should not be capitalized unless it appears at the beginnin= g >>of >> a sentence or in the title of referenced document. >>=20 >> Sec 1: >> s/This document is capturing/This document captures/ >>=20 >> Sec 2: >> s/techniques in the next chapter/techniques discussed in the next >>section/ >>=20 >> s/A RTP session/An RTP session/ >>=20 >> s/no RTP packets has arrived/no RTP packets have arrived/ >>=20 >> s/client can not get through/client cannot get through/ >>=20 >> Section 3: >> s/for RTSP NAT solutions/for RTSP NAT traversal solutions/ >>=20 >> s/connection till arrival/connection until arrival/ >>=20 >> Sec 4.1.2: >> s/See [RFC4787] for full definition of these terms.// >> (terms are also defined in this document >>=20 >> s/A RTSP client/An RTSP client/ >>=20 >> s/a NAT(s)/a NAT/ >>=20 >> s/a RTSP PLAY request/an RTSP PLAY request/ >>=20 >> Sec 4.1.4: >> s/a RTSP-aware ALG /an RTSP-aware ALG / >>=20 >> Sec 4.2.2: >> s/one of the can/one of them can/ >>=20 >> s/establishing TCP connection/establishing a TCP connection/ >>=20 >> Sec 4.2.5: >> s/a IETF standard/an IETF standard/ >>=20 >> Sec 4.4: >> s/Latching/latching/ (throughout the document) >>=20 >> Sec 4.4.3: >> s/an public IP address./a public IP address./ >>=20 >> Sec. 4.4.4: >> s/the possible address a latching packet can come from to the same as >>the >> RTSP TCP connection are from/the source address of a latching packet to >>be >> the same as the source address of the RTSP TCP connection/ >>=20 >> s/it is difficult to determine the address usage for the network the >> client connects from./it cannot be assumed that addresses within the >>range >> all belong to the same client./ >>=20 >> s/the server will send from and also the SSRC the client will use./that >> the server will send from and that the SSRC client will use./ >>=20 >> s/Having this information/Having this information,/ >>=20 >> s/legit/legitimate/ >> (two occurrences) >>=20 >> s/which results in that the media server sends the RTP/RTCP traffic to >> ports the client isn=E2=80=99t listening for RTP/RTCP on./which results in the >> media server sending the RTP/RTCP traffic to ports on which the client >>is >> not listening for RTP/RTCP./ >>=20 >> s/client to server network path/client-to-server network path/ >>=20 >> s/To improve the security against attackers/To improve the security >> against attackers,/ >>=20 >> Sec. 4.5.1: >> s/[I-D.ietf-avt-rtp-no-op], however, that work was >> abandoned./[I-D.ietf-avt-rtp-no-op]. However, that work was abandoned./ >>=20 >> OLD: >> There exists a RFC that discusses the implication of different type of >> packets as keep-alives for RTP [RFC6263] and its findings are very >> relevant to the format of the Latching packet. >>=20 >> NEW: >> The findings of [RFC6263] concerning the implications of different types >> of packets as keep-alives for RTP are very relevant to the format of the >> Latching packet. >>=20 >> s/there has been/there have been/ >>=20 >> Sec. 4.5.2: >> s/so called/so-called/ >>=20 >> s/as Latching packet/as a Latching packet/ >>=20 >> Sec 4.5.3: >> s/(Requirement 4 in Section 3), instead a Latching protocol must be >> defined./(Requirement 4 in Section 3). Instead a Latching protocol must >>be >> defined./ >>=20 >> Sec 4.5.4: >> s/more unlikely/less likely/ >>=20 >> s/works and when it didn=E2=80=99t/worked and when it did not/ >>=20 >> s/security issue remain/security issue remains/ >>=20 >> s/a RTSP client/an RTSP client/ >>=20 >> s/likes to/intends to/ >>=20 >> s/an DoS target/a DoS target/ >>=20 >> Sec 4.6: >> s/three way Latching/three-way latching/ (throughout) >>=20 >> Sec 4.6.2: >> s/Uses the same RTSP extensions/Three-way latching uses the same RTSP >> extensions/ >>=20 >> s/client to server latching packet/client-to-server latching packet/ >>=20 >> s/an UDP packet/a UDP packet/ >>=20 >> s/nonce. Thus confirming/nonce, thus confirming/ >>=20 >> s/a RTSP client/an RTSP client/ >>=20 >> Sec 4.6.3: >> s/have the following/has the following/ >>=20 >> Sec 4.7.4: >> s/an UDP mapping/a UDP mapping/ >>=20 >> s/with RTSP ALG/with an RTSP ALG/ >>=20 >> Sec 4.8.3: >> s/where the RTSP server in not NATed or at least reachable like it was >> not./where the RTSP server is not NATed or is reachable as if it were >>not >> NATed./ >>=20 >> Sec 4.9.1: >> s/a RTSP client/an RTSP client/ >>=20 >> s/the IP belongs/the IP address belongs/ >>=20 >> Sec 4.9.2: >> s/addresses also the TCP connection must be done through the same TURN >> server as the one in the next step./addresses, the TCP connection must >>be >> made through the same TURN server to be used for NAT traversal./ >>=20 >> s/that it desires/where it desires/ >>=20 >> Sec 4.9.3: >> s/has public/has a public/ >>=20 >> Sec 4.9.4: >> s/a RTSP session/an RTSP session/ >>=20 >> s/Which would/This would/ >>=20 >> Sec 5: >> s/a RTSP session/an RTSP session/ >>=20 >>=20 >> s/what type of transport and from where, the media stream packets will >>be >> sent./what type of transport will be used and from where the media >>stream >> packets will be sent./ >>=20 >> Sec 6: >> s/R1: Work/R1: Must work/ >>=20 >> s/use, Implement and administer/use, implement and administer/ >>=20 >> OLD: >> C1: Will solution support both Clients and Servers behind NAT >>=20 >> C2: Is the solution robust to changing NAT behaviors >> NEW: >>=20 >> C1: Supports both clients and servers behind NAT >>=20 >> C2: Is robust to changing NAT behaviors >>=20 >> s/using TCP Tunneling or Three-Way Latching is the solutions that best >> fulfill/TCP Tunneling or Three-Way Latching is the solution that best >> fulfills/ >>=20 >> s/is acceptable/are acceptable/ >>=20 >> s/When it comes to Three-Way Latching it is a very competitive technique >> given that you don't need support for RTSP servers behind >>NATs./Three-Way >> Latching is a comparable technique in situations where support for RTSP >> servers behind NATs is not required./ >>=20 >> s/were some discussion/were some discussions/ >>=20 >> s/In the end the authors believe that reuse of ICE, the greater >> flexibility and anyway need to deploy a new solution was the decisive >> factors./In the end, the WG concluded that reuse of ICE, its greater >> flexibility, and the need to deploy a new solution in either case were >>the >> decisive factors in favor of ICE./ >>=20 >> Sec 8: >> s/IP-address/IP address/ >>=20 >> s/those variants/of those variants/ >>=20 >> Sec 9: >> s/has commented/have commented/ >>=20 >> s/protocol/document/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- From nobody Fri May 30 12:41:32 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 A3DCF1A0A30; Fri, 30 May 2014 12:41:29 -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 PTAws6ZHhS12; Fri, 30 May 2014 12:41:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 313D51A09B5; Fri, 30 May 2014 12:41:27 -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.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140530194127.27325.82831.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 12:41:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_cP0mjcNcQFZdGKyYunPHLjvyGo Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: (The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)) to Informational RFC 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: Fri, 30 May 2014 19:41:29 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)' as Informational RFC 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-13. 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. Some helpful state about this draft is available here: http://www.ietf.org/mail-archive/web/mmusic/current/msg13385.html. Abstract This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri May 30 14:47: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 E44621A886F; Fri, 30 May 2014 14:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FxeEHjfQxYXO; Fri, 30 May 2014 14:47:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 149941A8876; Fri, 30 May 2014 14:47:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CB31518000F; Fri, 30 May 2014 14:46:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140530214636.CB31518000F@rfc-editor.org> Date: Fri, 30 May 2014 14:46:36 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lwtR45Lkn169tprSvjuRT_-aGDE 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 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, 30 May 2014 21:47:26 -0000 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 Working 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 suggestions 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 From nobody Sat May 31 16:42: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 E79191A013B for ; Sat, 31 May 2014 16:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 uH88wn6IOU3q for ; Sat, 31 May 2014 16:41:58 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAB11A0135 for ; Sat, 31 May 2014 16:41:57 -0700 (PDT) Received: from userPC (unknown [122.166.171.109]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id B7DA6869325; Sat, 31 May 2014 23:41:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1401579713; bh=cc48t5nlBOR+YF/YCTZ8GDug9yxrJLfK8JblVjk0sKM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FOOF8mVXj40EgvR1foLuRRl3TwPiv+4x9JbkCn6zJEp9AalnDohqiOzo496Cfmykh VmgWYhm7wuRpZP9Tv++D/Z8Vivo3ly5dXyWjWfzBlo8lX3/I+KtCwOdRFfXkdGvJg4 ZoriqfqTR3BVU6FVYbT5s6zWDS+dDHYdYcuQScWY= From: "Parthasarathi R" To: "'Emil Ivov'" , "'Hadriel Kaplan'" , "'Dan Wing \(dwing\)'" References: <20140529164031.26486.54207.idtracker@ietfa.amsl.com> In-Reply-To: <20140529164031.26486.54207.idtracker@ietfa.amsl.com> Date: Sun, 1 Jun 2014 05:11:45 +0530 Message-ID: <001101cf7d29$e5e75d30$b1b61790$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac97XNi1ryscqsS2TvWslbkfoEaetQByyBqw Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.538A68C0.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xt6a5VYo77tvwm7Uzt2uz4g9zLY 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: Sat, 31 May 2014 23:42:01 -0000 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