From nobody Thu Nov 2 06:50:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A87E13F657 for ; Thu, 2 Nov 2017 06:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5No_6q8XlH_Y for ; Thu, 2 Nov 2017 06:50:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B3213A415 for ; Thu, 2 Nov 2017 06:50:55 -0700 (PDT) X-AuditID: c1b4fb25-1b7d19c000000c94-7f-59fb22bd929b Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.7E.03220.DB22BF95; Thu, 2 Nov 2017 14:50:53 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Thu, 2 Nov 2017 14:50:53 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: PR on s/"m=" line/"m=" section Thread-Index: AQHTU+GYsNnycPAzkkWLuMbBWvHbNw== Date: Thu, 2 Nov 2017 13:50:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D620F1172580Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7t+5epd+RBo8aTSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDW/T7IXTBWuOHPbuIFxqkAXIyeHhICJxNyjh5m7GLk4hAQO M0psnrOFCSQhJLCIUeLHj/wuRg4ONgELie5/2iBhEQF1ia97e5hBbGEBfYlL224wQ8RNJCbf P8cKYetJTFpwkA3EZhFQkVgxcxc7iM0rYC3x/MNxMJtRQEzi+6k1YKuYBcQlbj2ZzwRxj4DE kj3nmSFsUYmXj/+BzRQFmrnhxG12iLiixMdX+xghehMkVvfMZIGYLyhxcuYTlgmMQrOQjJ2F pGwWkjKIuIHE+3PzmSFsbYllC19D2foSG7+cZYSwrSWa131gR1azgJFjFaNocWpxUm66kbFe alFmcnFxfp5eXmrJJkZgnBzc8lt1B+PlN46HGAU4GJV4eD8K/44UYk0sK67MPcQowcGsJML7 XgooxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0xJLU7NTUgtQimCwTB6dUA6Ny/3++ z7s2FnHJOd9JuTaJIXVuh8LDraV3tk96q/TH7tERF+7O/366RzfuUnKsfmWqtv9pfmmA2PPj t52YFgg1Vm/LEc6IFGOcteajjlaEdJhDllDghvwcztNSnZdt7W41vZyRsCDIQX2D3+/K5a8X PZ079TlLjkpugCq3JvvKgsBsWQGLXUosxRmJhlrMRcWJAOMtnfKPAgAA Archived-At: Subject: [MMUSIC] BUNDLE: PR on s/"m=" line/"m=" section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 02 Nov 2017 13:50:57 -0000 --_000_D620F1172580Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Ok, folks, the final act for getting BUNDLE out of the WG has started. Based on previous discussions, I have created a BUNDLE PR which replaces = =93m=3D=93 line with =93m=3D=93 section, in order to be consistent with oth= er specs. I also replaced =93associated address=94 with =93assign address=94, and due= to the change above I also managed to get rid of a number of other =93asso= ciate=94 instances. The PR is based on Taylor=92s PR, but that also contains a number of other = changes. We may still do those too, but due to the size of the document (an= d the number of changes) I prefer each PR to focus on one thing. https://github.com/cdh4u/draft-sdp-bundle/pull/38 Regards, Christer --_000_D620F1172580Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Ok, folks, the final act for getting BUNDLE out of the WG has started.=

Based on previous discussions, I have created a BUNDLE PR which replac= es =93m=3D=93 line with =93m=3D=93 section, in order to be consistent with = other specs.

I also replaced =93associated address=94 with =93assign address=94, an= d due to the change above I also managed to get rid of a number of other = =93associate=94 instances.

The PR is based on Taylor=92s PR, but that also contains a number of o= ther changes. We may still do those too, but due to the size of the documen= t (and the number of changes) I prefer each PR to focus on one thing.


Regards,

Christer
--_000_D620F1172580Fchristerholmbergericssoncom_-- From nobody Thu Nov 2 14:04:21 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D69A613F969; Thu, 2 Nov 2017 14:04:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.64.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, ben@nostrum.com, mmusic@ietf.org, The IESG , fandreas@cisco.com, mmusic-chairs@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150965664285.24414.7543778000080502432.idtracker@ietfa.amsl.com> Date: Thu, 02 Nov 2017 14:04:02 -0700 Archived-At: Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-mmusic-dtls-sdp-32.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 21:04:03 -0000 The IESG has approved the following document: - 'Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)' (draft-ietf-mmusic-dtls-sdp-32.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ Technical Summary The document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. The document defines a new SDP media-level attribute, 'dtls-id'. Working Group Summary There was originally no controversy or anything else to note. Version 22 of this draft underwent IETF Last Call. Subsequently, the working group elected to add support for TLS, which was a material change. Therefore the IETF Last Call was repeated with version 26. Document Quality There are existing implementations of the protocol, and a number of vendors have indicated that they intend to implement it. Personnel Flemming Andreasen is the Document Shepherd. Ben Campbell is the Area Director From nobody Fri Nov 3 02:00:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A7F13FD04 for ; Fri, 3 Nov 2017 02:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RXNzI4qDDUVK for ; Fri, 3 Nov 2017 02:00:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B621513FD19 for ; Fri, 3 Nov 2017 02:00:25 -0700 (PDT) X-AuditID: c1b4fb3a-1c7889c000006897-fe-59fc3027ba9f Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.B0.26775.7203CF95; Fri, 3 Nov 2017 10:00:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Fri, 3 Nov 2017 10:00:23 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: ICE check list state Thread-Index: AQHTVIIu8TYbxgoL5k+3T6Yx192s7A== Date: Fri, 3 Nov 2017 09:00:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D621FE852589Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7lq66wZ9Igy+fLC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE8n+1gKOkUrFmwvbGC8JtjFyMkhIWAisevUU9YuRi4OIYHD jBJd3zcxQjiLGCV+f/kB5HBwsAlYSHT/0wZpEBFQl/i6t4cZxBYWkJVY/+0zE0RcSWJ283ZG CFtPonnafXYQm0VARWLnhQWsIDavgLXEgX0/wXoZBcQkvp9aA9bLLCAucevJfCaIgwQkluw5 zwxhi0q8fPwPrFcUaOaGE7fZIeKKEjvPtjND9CZIzJp1mQlivqDEyZlPWCYwCs1CMnYWkrJZ SMog4gYS78/NZ4awtSWWLXwNZetLbPxylhHCtpaY/Xs/K7KaBYwcqxhFi1OLi3PTjYz0Uosy k4uL8/P08lJLNjECI+Xglt9WOxgPPnc8xCjAwajEw7tX+0+kEGtiWXFl7iFGCQ5mJRHexzG/ I4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgXFl0b6/A 7i7Tw1quR6qi8ovntkx5cWraKgY99QMn3RYeDt9z7Wyg0Srm2W63cjK84oJKpxmuf1qXz3p8 rTvztC+9gS7/z4osbPql3bxf7NFt00BLO2nVKb8fLtjW2HXvgu4Zzn0n/Sz2bRGc9G6n/S3L i/1Bfqeq8o6xu/t8tDlm69Lk8TPghBJLcUaioRZzUXEiAAIX3tWQAgAA Archived-At: Subject: [MMUSIC] ICE check list state X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 09:00:42 -0000 --_000_D621FE852589Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Section 8.1 of draft-mmusic-trickle-ice talks about =93active=94 and =93fro= zen=94 check lists. Note that the concept of =93active" and =93frozen" check lists has been rem= oved from ICEbis. Only the check list states (Running, Completed and Failed= ) remain. So, IF the concept is needed for trickle, it has to be defined in the ICE t= rickle spec, and then reflected in the MMUSIC trickle spec. Commenting on the actual text in section 8.1., which says: "Given that with trickle ICE, other check lists may still be empty at th= at point, a trickle ICE agent SHOULD also maintain an explicit Active/Frozen state for every che= ck list,=85" In my opinion you should not call it an Active/Frozen state. Rather call it= flag, or something. Regards, Christer --_000_D621FE852589Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Section 8.1 of draft-mmusic-trickle-ice talks about =93active=94 and = =93frozen=94 check lists.

Note that the concept of =93active" and =93frozen" check lis= ts has been removed from ICEbis. Only the check list states (Running, Compl= eted and Failed) remain.

So, IF the concept is needed for trickle, it has to be defined in the = ICE trickle spec, and then reflected in the MMUSIC trickle spec.

Commenting on the actual text in section 8.1., which says:
   "Given that with trickle I=
CE, other check lists may still be empty at that point, a trickle ICE
   agent SHOULD also maintain an explicit Active/Frozen state for every che=
ck list,=85"
In my opinion you should not call it an Active/Frozen state. Rather ca= ll it flag, or something. 


Regards,

Christer
--_000_D621FE852589Dchristerholmbergericssoncom_-- From nobody Fri Nov 3 02:18:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B461C13FA91 for ; Fri, 3 Nov 2017 02:18:12 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tPhpw1fjWVys for ; Fri, 3 Nov 2017 02:18:10 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D8513FD22 for ; Fri, 3 Nov 2017 02:18:10 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b9so125115wmh.0 for ; Fri, 03 Nov 2017 02:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RfX98m6fLW0dekY1aspnHpakY7mMHPfiiYGVg7f08sE=; b=pufitLRn2+QxFxxG3Yc0A71Tid1z8F4COtpNLSZHCcym0X7kghZUcIQCI9+VFxHMrc awWNCArAlxYPi+ypejb8QluJCmmy0ckK4Q+miF7n/Tlnzs6DWLHz7xZIG4uzkFr7n3rK tveJoEpaDrLnqGv5h0J7W1UseC+ATMFG3DRqNRe6vLa5r/NBYHS3lF9YIMwkQwcEI0mW P2ofKhxEdIKHAejSl0XAs09S68bRM/mogOd3mEpzVF9G1HZnc0LgQ0BjWNT91/k9E2gv 0Be7R75rifORAJw5Vgk4BYPwip8xmSyM8gN7TqygSMAzjjGbuK2YneHaSs8g9tL/LFcP /Iew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RfX98m6fLW0dekY1aspnHpakY7mMHPfiiYGVg7f08sE=; b=FOa2O8u/E8UzIZwnmHToRLxRmSivqUIqePBFkCV37hbVPTVK1svj3LyzP/YFSLtM15 +Bj4IlaX6MhjolRVc5UE6q96Z3WKKi0Lo7OZcY65w03LFuP7iQsubaGZma9zHiE2O6QZ v1Xaql6z0mghx8G18cXrLQoZwAsshSMoqcAvgD2DbFsFRO38OkoyxzIlL2nTBGGmr0qP /4LAhOyWP3mWO2O+SmDDwwXKIXo9oR7iLIGT/Gon7qdmxfPkRNDECmplCpC9Ba50Odta qlTQSUBrwsnBEg8FHSZamBEy/VCGOQzlARCFTBXlN6tPQVriESaiBy18mg32Y3kJaPM2 HXEQ== X-Gm-Message-State: AMCzsaX8EczBv7ohlWhC+6yIVrRK+Tqx9DdDWxzVUrazojhf4B9gMCuy Ii9toUaiSiUWa9mQlU9gq5paIN8qPDtKHRcN1Oc= X-Google-Smtp-Source: ABhQp+QNYN2hkhggfj/d0hbUbTPjxP3dqYZnCZhFt4Kf0lghYk2wM/AS2/nhbiPB/TwX/0F6ADEM/5w+RjtDjnDUihk= X-Received: by 10.28.111.206 with SMTP id c75mr3912148wmi.123.1509700688597; Fri, 03 Nov 2017 02:18:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.136.154 with HTTP; Fri, 3 Nov 2017 02:18:07 -0700 (PDT) In-Reply-To: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> From: Andy Hutton Date: Fri, 3 Nov 2017 09:18:07 +0000 Message-ID: To: Christer Holmberg Cc: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 09:18:13 -0000 The comment from Christer below was the only WGLC comment I believe. Whilst I see some value in what Christer suggests I think this is a simple draft which already adequately describes the solution and to be honest I don't really want to go round the loop of making significant changes to the draft and going through more last calls etc. Please can the chairs let us know how we should proceed. Unfortunately I will not be in Singapore to discuss but lets find a way to get this done. Regards Andy On Thu, Sep 28, 2017 at 10:35 AM, Christer Holmberg wrote: > Hi, > >>I agree that ideally we should have all the associated procedures in >>one place and having two specs is not ideal however we have been going >>round this circle for a couple of years now and just need to get this >>done. >> >>Originally we wanted this work to be done in MMUSIC but it got >>dispatched to SIPBrandy but it was later discovered that an update to >>RFC 4568 was needed and that the SIPBrandy charter did not allow this >>so we were told an MMUSIC draft was needed after all to update the RFC >>before the SIPBrandy work could be completed. >> >>I do not want to start again and waste another couple of years lets >>just get it finished. > > I suggest that we: > > 1) Keep the SIPBRANDY draft as it is. Perhaps they could add a sente= nce > pointing out that that the normative procedures will be described > elsewhere. > 2) Keep the MMUSIC draft, but we add a proper 'SDP Offer/Answer > Considerations=E2=80=99 section, where we include the normal subsections = (create > initial offer, process offer, process answer etc). > > Regards, > > Christer > > > > >>On Wed, Sep 27, 2017 at 9:35 PM, Christer Holmberg >> wrote: >>> Hi, >>> >>> >>> >>> In the mail you referenced the following is said: >>> >>> >>> >>> =E2=80=9CI see your point but Currently SIPBRANDY is chartered to produ= ce >>> Opportunistic SRTP as a BCP. There is also a milestone to >>> >>> inform MMUSIC or other appropriate WGs of any changes needed to support >>> Opportunistic SRTP (Not expected to be published >>> >>> as an RFC). I think SIPBRANDY is just carrying out what they are >>>chartered >>> to do.=E2=80=9D >>> >>> >>> >>> But, draft-ietf-mmusic-opportunistic-negotiation doesn=E2=80=99t really= define >>>any >>> procedures =C2=AD it references the SIPBRANDY draft for everything. >>> >>> >>> >>> =E2=80=9C[I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time tran= sport >>> >>> protocol (SRTP) can be negotiated opportunistically.=E2= =80=9D >>> >>> >>> >>> But, as the SIPBRANDY is only Informational, where are the normative >>> procedures? >>> >>> >>> >>> =E2=80=9CThe exact negotiation mechanism is however outside the scope o= f this >>> document, >>> >>> an example mechanism can be found in >>> [I-D.ietf-sipbrandy-osrtp].=E2=80=9D >>> >>> >>> >>> How can negotiation be outside the scope of the document, when the >>>title of >>> the document contains =E2=80=9Cnegotiating=E2=80=9D? >>> >>> >>> >>> In addition, the text says that the sipbrandy only contains =E2=80=9Can= example >>> mechanism=E2=80=9D. >>> >>> >>> >>> If we are going to have this document, I think we shall include >>>normative >>> offer/answer procedures. The draft DOES contain some normative >>>procedures, >>> but I think we shall have it all in one place. One shall not have to >>>read >>> both documents just to figure out the offer/answer procedures. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com] >>> Sent: 27 September 2017 21:58 >>> To: Christer Holmberg >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] I-D Action: >>> draft-ietf-mmusic-opportunistic-negotiation-01.txt >>> >>> >>> >>> Hi Christer - >>> >>> >>> >>> See this: >>> https://mailarchive.ietf.org/arch/msg/mmusic/wov2yErrgtUZURyRyVuVZ6K-nL= I >>> >>> >>> >>> Cheers, >>> >>> >>> >>> -G >>> >>> >>> >>> On Sep 27, 2017, at 9:19 AM, Christer Holmberg >>> wrote: >>> >>> >>> >>> Hi, >>> >>> I am currently reviewing draft-ietf-sipbrandy-osrtp-03, and the >>>following >>> question comes to my mind: do we really need >>> draft-ietf-mmusic-opportunistic-negotiation? :) >>> >>> Section 3 of draft-ietf-sipbrandy-osrtp-03 already more or less contain= s >>> SDP Offer/Answer procedures for OSRTP. We can change the name of >>>section 3 >>> in that draft to =C2=B3SDP Offer/Answer Procedures=C2=B2, modify the st= ructure a >>> little, and add whatever might be missing. >>> >>> Or, am I missing something? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> On 14/09/17 19:03, "mmusic on behalf of internet-drafts@ietf.org" >>> wrote: >>> >>> >>> >>> 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 >>>WG >>> of the IETF. >>> >>> Title : Negotiating SRTP and RTCP Feedback using the >>> RTP/AVP Profile >>> Authors : Andrew Hutton >>> Roland Jesske >>> Alan Johnston >>> Gonzalo Salgueiro >>> Bernard Aboba >>> Filename : draft-ietf-mmusic-opportunistic-negotiation-01.txt >>> Pages : 7 >>> Date : 2017-09-14 >>> >>> Abstract: >>> This document describes how the use of the Secure Real-time transport >>> protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio >>> Video Profile) defined in [RFC3551]. Such a mechanism is used to >>> provide a means for encrypted media to be used in environments where >>> support for encryption is not known in advance, and not required. >>> The same mechanism is also applied to negotiation of the Extended RTP >>> Profile for Real-time Transport Control Protocol Based Feedback (RTP/ >>> AVPF) [RFC4585]. >>> >>> >>> The IETF datatracker status page for this draft is: >>> >>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotia= t >>>i >>> on/ >>> >>> There are also htmlized versions available at: >>> >>>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-= 0 >>>1 >>> >>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-ne= g >>>o >>> tiation-01 >>> >>> A diff from the previous version is available at: >>> >>>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-nego= tia >>>t >>> ion-01 >>> >>> >>> 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 >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> > From nobody Fri Nov 3 02:35:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7813FD30 for ; Fri, 3 Nov 2017 02:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cgYlonaH2X_z for ; Fri, 3 Nov 2017 02:35:25 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60B613FD1C for ; Fri, 3 Nov 2017 02:35:24 -0700 (PDT) X-AuditID: c1b4fb3a-1c7889c000006897-2d-59fc385a8f16 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.28.26775.A583CF95; Fri, 3 Nov 2017 10:35:22 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Fri, 3 Nov 2017 10:34:31 +0100 From: Christer Holmberg To: Andy Hutton CC: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUAgACwtID//7EEIIAAs6WAgAA+fYCAOGvZgIAAF2yA Date: Fri, 3 Nov 2017 09:34:30 +0000 Message-ID: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="euc-kr" Content-ID: <565238E1EBC932479CFC5EBB3CFBDB5C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7vW6UxZ9Ig0ezDCwurdvKZDF3ip/F 1OWPWRyYPab83sjqsXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBlTD/by17wJrLi24r17A2M R8K7GDk5JARMJFa3fGXqYuTiEBI4zCgxb/kZdghnEaPE9ounWLsYOTjYBCwkuv9pgzSICGhL vJuygxXEZhaIkzi8djI7iC0sECZxavMxJoiacInZ7w6yQthREjsurWEGsVkEVCQWf7nFBmLz ClhLzHp8mBli11pmiQ2X1rOAJDgFAiVmvt0ENpRRQEzi+6k1TBDLxCVuPZnPBHG1gMSSPeeZ IWxRiZeP/4EtExXQk9hw4jY7RFxRYufZdmaIXi2JLz/2sUHY1hJnd71mhLAVJaZ0P2SHOEhQ 4uTMJywTGMVnIVk3C0n7LCTts5C0z0LSvoCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZG YAwe3PLbagfjweeOhxgFOBiVeHj3av+JFGJNLCuuzD3EKMHBrCTC+zjmd6QQb0piZVVqUX58 UWlOavEhRmkOFiVxXod9FyKEBNITS1KzU1MLUotgskwcnFINjApTp040iQw6XpcxyyN77fdf 6/6Zv01Mvmmh5D9RSuXmqX+dX/e0s32Tvr6v9Jb5ifLudtPDG1nOrb/8Xaourel1KduSZw2m nSf11pzjuLBuVsjHHfe2dHBrKi7fs7y7Tj6/5cnq41x6PWe2pm7RiNusoH5Vu5ejqNJmUWVA 9u+LUUcfWOqcFFBiKc5INNRiLipOBABo40cKvQIAAA== Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 09:35:27 -0000 SGksDQoNCkp1c3QgYmVjYXVzZSB0aGUgZHJhZnQgaXMgobBzaW1wbGWhsSwgSSBzdGlsbCB0aGlu ayB3ZSBzaGFsbCBkbyBpdCBwcm9wZXJseSwNCmFzIHRoaXMgaXMgdGhlIHNwZWNpZmljYXRpb24g ZGVmaW5pbmcgdGhlIG5vcm1hdGl2ZSBPL0EgcHJvY2VkdXJlcy4NCg0KQWxzbywgYmFzZWQgb24g dGhlIGRpc2N1c3Npb25zIHJlZ2FyZGluZyBTRFAgcmVsYXRlZCB0ZXJtaW5vbG9neSwgSSB0aGlu aw0Kd2Ugc2hvdWxkIHRhbGsgYWJvdXQgobBtPaGwIHNlY3Rpb25zIGluc3RlYWQgb2YgobBtPaGw IGxpbmVzLg0KDQpTb21ldGltZXMgd2UgZG8gbmVlZCBhZGRpdGlvbmFsIFdHTENzIC0gSaGvdmUg bG9zdCBjb3VudCBvbiBob3cgbWFueSBXR0xDcw0Kd2Whr3ZlIGhhZCBmb3IgQlVORExFIGJ5IG5v dyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDAzLzExLzE3IDExOjE4LCAiQW5k eSBIdXR0b24iIDxhbmR5aHV0dG9uLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPlRoZSBjb21t ZW50IGZyb20gQ2hyaXN0ZXIgYmVsb3cgd2FzIHRoZSBvbmx5IFdHTEMgY29tbWVudCBJIGJlbGll dmUuDQo+DQo+V2hpbHN0IEkgc2VlIHNvbWUgdmFsdWUgaW4gd2hhdCBDaHJpc3RlciBzdWdnZXN0 cyBJIHRoaW5rIHRoaXMgaXMgYQ0KPnNpbXBsZSBkcmFmdCB3aGljaCBhbHJlYWR5IGFkZXF1YXRl bHkgZGVzY3JpYmVzIHRoZSBzb2x1dGlvbiBhbmQgdG8gYmUNCj5ob25lc3QgSSBkb24ndCByZWFs bHkgd2FudCB0byBnbyByb3VuZCB0aGUgbG9vcCBvZiBtYWtpbmcgc2lnbmlmaWNhbnQNCj5jaGFu Z2VzIHRvIHRoZSBkcmFmdCBhbmQgZ29pbmcgdGhyb3VnaCBtb3JlIGxhc3QgY2FsbHMgZXRjLg0K Pg0KPlBsZWFzZSBjYW4gdGhlIGNoYWlycyBsZXQgdXMga25vdyBob3cgd2Ugc2hvdWxkIHByb2Nl ZWQuDQo+DQo+VW5mb3J0dW5hdGVseSBJIHdpbGwgbm90IGJlIGluIFNpbmdhcG9yZSB0byBkaXNj dXNzIGJ1dCBsZXRzIGZpbmQgYQ0KPndheSB0byBnZXQgdGhpcyBkb25lLg0KPg0KPlJlZ2FyZHMN Cj5BbmR5DQo+DQo+DQo+DQo+DQo+T24gVGh1LCBTZXAgMjgsIDIwMTcgYXQgMTA6MzUgQU0sIENo cmlzdGVyIEhvbG1iZXJnDQo+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQo+PiBIaSwNCj4+DQo+Pj5JIGFncmVlIHRoYXQgaWRlYWxseSB3ZSBzaG91bGQgaGF2ZSBhbGwg dGhlIGFzc29jaWF0ZWQgcHJvY2VkdXJlcyBpbg0KPj4+b25lIHBsYWNlIGFuZCBoYXZpbmcgdHdv IHNwZWNzIGlzIG5vdCBpZGVhbCBob3dldmVyIHdlIGhhdmUgYmVlbiBnb2luZw0KPj4+cm91bmQg dGhpcyBjaXJjbGUgZm9yIGEgY291cGxlIG9mIHllYXJzIG5vdyBhbmQganVzdCBuZWVkIHRvIGdl dCB0aGlzDQo+Pj5kb25lLg0KPj4+DQo+Pj5PcmlnaW5hbGx5IHdlIHdhbnRlZCB0aGlzIHdvcmsg dG8gYmUgZG9uZSBpbiBNTVVTSUMgYnV0IGl0IGdvdA0KPj4+ZGlzcGF0Y2hlZCB0byBTSVBCcmFu ZHkgYnV0IGl0IHdhcyBsYXRlciBkaXNjb3ZlcmVkIHRoYXQgYW4gdXBkYXRlIHRvDQo+Pj5SRkMg NDU2OCB3YXMgbmVlZGVkIGFuZCB0aGF0IHRoZSBTSVBCcmFuZHkgY2hhcnRlciBkaWQgbm90IGFs bG93IHRoaXMNCj4+PnNvIHdlIHdlcmUgdG9sZCBhbiBNTVVTSUMgZHJhZnQgd2FzIG5lZWRlZCBh ZnRlciBhbGwgdG8gdXBkYXRlIHRoZSBSRkMNCj4+PmJlZm9yZSB0aGUgU0lQQnJhbmR5IHdvcmsg Y291bGQgYmUgY29tcGxldGVkLg0KPj4+DQo+Pj5JIGRvIG5vdCB3YW50IHRvIHN0YXJ0IGFnYWlu IGFuZCB3YXN0ZSBhbm90aGVyIGNvdXBsZSBvZiB5ZWFycyBsZXRzDQo+Pj5qdXN0IGdldCBpdCBm aW5pc2hlZC4NCj4+DQo+PiBJIHN1Z2dlc3QgdGhhdCB3ZToNCj4+DQo+PiAxKSAgICAgIEtlZXAg dGhlIFNJUEJSQU5EWSBkcmFmdCBhcyBpdCBpcy4gUGVyaGFwcyB0aGV5IGNvdWxkIGFkZCBhDQo+ PnNlbnRlbmNlDQo+PiBwb2ludGluZyBvdXQgdGhhdCB0aGF0IHRoZSBub3JtYXRpdmUgcHJvY2Vk dXJlcyB3aWxsIGJlIGRlc2NyaWJlZA0KPj4gZWxzZXdoZXJlLg0KPj4gMikgICAgICBLZWVwIHRo ZSBNTVVTSUMgZHJhZnQsIGJ1dCB3ZSBhZGQgYSBwcm9wZXIgJ1NEUCBPZmZlci9BbnN3ZXINCj4+ IENvbnNpZGVyYXRpb25zoa8gc2VjdGlvbiwgd2hlcmUgd2UgaW5jbHVkZSB0aGUgbm9ybWFsIHN1 YnNlY3Rpb25zIChjcmVhdGUNCj4+IGluaXRpYWwgb2ZmZXIsIHByb2Nlc3Mgb2ZmZXIsIHByb2Nl c3MgYW5zd2VyIGV0YykuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+ DQo+Pg0KPj4NCj4+Pk9uIFdlZCwgU2VwIDI3LCAyMDE3IGF0IDk6MzUgUE0sIENocmlzdGVyIEhv bG1iZXJnDQo+Pj48Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4g SGksDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEluIHRoZSBtYWlsIHlvdSByZWZlcmVuY2VkIHRo ZSBmb2xsb3dpbmcgaXMgc2FpZDoNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gobBJIHNlZSB5b3Vy IHBvaW50IGJ1dCBDdXJyZW50bHkgU0lQQlJBTkRZIGlzIGNoYXJ0ZXJlZCB0byBwcm9kdWNlDQo+ Pj4+IE9wcG9ydHVuaXN0aWMgU1JUUCBhcyBhIEJDUC4gVGhlcmUgaXMgYWxzbyBhIG1pbGVzdG9u ZSB0bw0KPj4+Pg0KPj4+PiBpbmZvcm0gTU1VU0lDIG9yIG90aGVyIGFwcHJvcHJpYXRlIFdHcyBv ZiBhbnkgY2hhbmdlcyBuZWVkZWQgdG8NCj4+Pj5zdXBwb3J0DQo+Pj4+IE9wcG9ydHVuaXN0aWMg U1JUUCAoTm90IGV4cGVjdGVkIHRvIGJlIHB1Ymxpc2hlZA0KPj4+Pg0KPj4+PiBhcyBhbiBSRkMp LiAgSSB0aGluayBTSVBCUkFORFkgaXMganVzdCBjYXJyeWluZyBvdXQgd2hhdCB0aGV5IGFyZQ0K Pj4+PmNoYXJ0ZXJlZA0KPj4+PiB0byBkby6hsQ0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBCdXQs IGRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24gZG9lc26hr3QgcmVh bGx5IGRlZmluZQ0KPj4+PmFueQ0KPj4+PiBwcm9jZWR1cmVzIKGpIGl0IHJlZmVyZW5jZXMgdGhl IFNJUEJSQU5EWSBkcmFmdCBmb3IgZXZlcnl0aGluZy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4g obBbSS1ELmlldGYtc2lwYnJhbmR5LW9zcnRwXSBkZXNjcmliZXMgaG93IFNlY3VyZSBSZWFsLXRp bWUgdHJhbnNwb3J0DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgcHJvdG9jb2wgKFNSVFApIGNh biBiZSBuZWdvdGlhdGVkIG9wcG9ydHVuaXN0aWNhbGx5LqGxDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+ Pj4+IEJ1dCwgYXMgdGhlIFNJUEJSQU5EWSBpcyBvbmx5IEluZm9ybWF0aW9uYWwsIHdoZXJlIGFy ZSB0aGUgbm9ybWF0aXZlDQo+Pj4+IHByb2NlZHVyZXM/DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ IKGwVGhlIGV4YWN0IG5lZ290aWF0aW9uIG1lY2hhbmlzbSBpcyBob3dldmVyIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMNCj4+Pj4gZG9jdW1lbnQsDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAg YW4gZXhhbXBsZSBtZWNoYW5pc20gY2FuIGJlIGZvdW5kIGluDQo+Pj4+IFtJLUQuaWV0Zi1zaXBi cmFuZHktb3NydHBdLqGxDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEhvdyBjYW4gbmVnb3RpYXRp b24gYmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50LCB3aGVuIHRoZQ0KPj4+PnRp dGxlIG9mDQo+Pj4+IHRoZSBkb2N1bWVudCBjb250YWlucyChsG5lZ290aWF0aW5nobE/DQo+Pj4+ DQo+Pj4+DQo+Pj4+DQo+Pj4+IEluIGFkZGl0aW9uLCB0aGUgdGV4dCBzYXlzIHRoYXQgdGhlIHNp cGJyYW5keSBvbmx5IGNvbnRhaW5zIKGwYW4NCj4+Pj5leGFtcGxlDQo+Pj4+IG1lY2hhbmlzbaGx Lg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBJZiB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSB0aGlzIGRv Y3VtZW50LCBJIHRoaW5rIHdlIHNoYWxsIGluY2x1ZGUNCj4+Pj5ub3JtYXRpdmUNCj4+Pj4gb2Zm ZXIvYW5zd2VyIHByb2NlZHVyZXMuIFRoZSBkcmFmdCBET0VTIGNvbnRhaW4gc29tZSBub3JtYXRp dmUNCj4+Pj5wcm9jZWR1cmVzLA0KPj4+PiBidXQgSSB0aGluayB3ZSBzaGFsbCBoYXZlIGl0IGFs bCBpbiBvbmUgcGxhY2UuIE9uZSBzaGFsbCBub3QgaGF2ZSB0bw0KPj4+PnJlYWQNCj4+Pj4gYm90 aCBkb2N1bWVudHMganVzdCB0byBmaWd1cmUgb3V0IHRoZSBvZmZlci9hbnN3ZXIgcHJvY2VkdXJl cy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4gQ2hyaXN0ZXINCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gRnJvbTogR29uemFsbyBTYWxn dWVpcm8gKGdzYWxndWVpKSBbbWFpbHRvOmdzYWxndWVpQGNpc2NvLmNvbV0NCj4+Pj4gU2VudDog MjcgU2VwdGVtYmVyIDIwMTcgMjE6NTgNCj4+Pj4gVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+IENjOiBtbXVzaWNAaWV0Zi5vcmcNCj4+ Pj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIEktRCBBY3Rpb246DQo+Pj4+IGRyYWZ0LWlldGYtbW11 c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24tMDEudHh0DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+ Pj4+IEhpIENocmlzdGVyIC0NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gU2VlIHRoaXM6DQo+Pj4+ IA0KPj4+Pmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbW11c2ljL3dvdjJ5 RXJyZ3RVWlVSeVJ5VnVWWjZLLW5MDQo+Pj4+SQ0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBDaGVl cnMsDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IC1HDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9u IFNlcCAyNywgMjAxNywgYXQgOToxOSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4+Pj4gPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ IEhpLA0KPj4+Pg0KPj4+PiBJIGFtIGN1cnJlbnRseSByZXZpZXdpbmcgZHJhZnQtaWV0Zi1zaXBi cmFuZHktb3NydHAtMDMsIGFuZCB0aGUNCj4+Pj5mb2xsb3dpbmcNCj4+Pj4gcXVlc3Rpb24gY29t ZXMgdG8gbXkgbWluZDogZG8gd2UgcmVhbGx5IG5lZWQNCj4+Pj4gZHJhZnQtaWV0Zi1tbXVzaWMt b3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbj8gOikNCj4+Pj4NCj4+Pj4gU2VjdGlvbiAzIG9mIGRy YWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwLTAzIGFscmVhZHkgbW9yZSBvciBsZXNzDQo+Pj4+Y29u dGFpbnMNCj4+Pj4gU0RQIE9mZmVyL0Fuc3dlciBwcm9jZWR1cmVzIGZvciBPU1JUUC4gV2UgY2Fu IGNoYW5nZSB0aGUgbmFtZSBvZg0KPj4+PnNlY3Rpb24gMw0KPj4+PiBpbiB0aGF0IGRyYWZ0IHRv IKn4U0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzqfcsIG1vZGlmeSB0aGUgc3RydWN0dXJlIGEN Cj4+Pj4gbGl0dGxlLCBhbmQgYWRkIHdoYXRldmVyIG1pZ2h0IGJlIG1pc3NpbmcuDQo+Pj4+DQo+ Pj4+IE9yLCBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+ Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAx NC8wOS8xNyAxOTowMywgIm1tdXNpYyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIg0KPj4+PiA8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cw0KPj4+PiBkaXJlY3Rvcmllcy4NCj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbA0KPj4+PldHDQo+Pj4+IG9m IHRoZSBJRVRGLg0KPj4+Pg0KPj4+PiAgICAgICBUaXRsZSAgICAgICAgICAgOiBOZWdvdGlhdGlu ZyBTUlRQIGFuZCBSVENQIEZlZWRiYWNrIHVzaW5nIHRoZQ0KPj4+PiBSVFAvQVZQIFByb2ZpbGUN Cj4+Pj4gICAgICAgQXV0aG9ycyAgICAgICAgIDogQW5kcmV3IEh1dHRvbg0KPj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICBSb2xhbmQgSmVzc2tlDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgIEFsYW4gSm9obnN0b24NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgR29uemFsbyBT YWxndWVpcm8NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgQmVybmFyZCBBYm9iYQ0KPj4+ PiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290 aWF0aW9uLTAxLnR4dA0KPj4+PiBQYWdlcyAgICAgICAgICAgOiA3DQo+Pj4+IERhdGUgICAgICAg ICAgICA6IDIwMTctMDktMTQNCj4+Pj4NCj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+ICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBob3cgdGhlIHVzZSBvZiB0aGUgU2VjdXJlIFJlYWwtdGltZSB0cmFuc3Bv cnQNCj4+Pj4gIHByb3RvY29sIChTUlRQKSBbUkZDMzcxMV0uIGNhbiBiZSBuZWdvdGlhdGVkIHVz aW5nIHRoZSBSVFAvQVZQIChBdWRpbw0KPj4+PiAgVmlkZW8gUHJvZmlsZSkgZGVmaW5lZCBpbiBb UkZDMzU1MV0uICBTdWNoIGEgbWVjaGFuaXNtIGlzIHVzZWQgdG8NCj4+Pj4gIHByb3ZpZGUgYSBt ZWFucyBmb3IgZW5jcnlwdGVkIG1lZGlhIHRvIGJlIHVzZWQgaW4gZW52aXJvbm1lbnRzIHdoZXJl DQo+Pj4+ICBzdXBwb3J0IGZvciBlbmNyeXB0aW9uIGlzIG5vdCBrbm93biBpbiBhZHZhbmNlLCBh bmQgbm90IHJlcXVpcmVkLg0KPj4+PiAgVGhlIHNhbWUgbWVjaGFuaXNtIGlzIGFsc28gYXBwbGll ZCB0byBuZWdvdGlhdGlvbiBvZiB0aGUgRXh0ZW5kZWQgUlRQDQo+Pj4+ICBQcm9maWxlIGZvciBS ZWFsLXRpbWUgVHJhbnNwb3J0IENvbnRyb2wgUHJvdG9jb2wgQmFzZWQgRmVlZGJhY2sgKFJUUC8N Cj4+Pj4gIEFWUEYpIFtSRkM0NTg1XS4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+DQo+Pj4+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1u ZWdvdGkNCj4+Pj5hdA0KPj4+PmkNCj4+Pj4gb24vDQo+Pj4+DQo+Pj4+IFRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+Pj4NCj4+Pj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlv bg0KPj4+Pi0wDQo+Pj4+MQ0KPj4+Pg0KPj4+Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uDQo+Pj4+ZWcNCj4+Pj5v DQo+Pj4+IHRpYXRpb24tMDENCj4+Pj4NCj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pg0KPj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290DQo+Pj4+aWEN Cj4+Pj50DQo+Pj4+IGlvbi0wMQ0KPj4+Pg0KPj4+Pg0KPj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+PiBzdWJt aXNzaW9uDQo+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+DQo+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPj4+PiBt bXVzaWNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWMNCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPj4+PiBtbXVzaWNA aWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPj4+PiBt bXVzaWNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWMNCj4+Pj4NCj4+DQoNCg== From nobody Fri Nov 3 03:16:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBD513FD53 for ; Fri, 3 Nov 2017 03:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 z_kyott1HB-x for ; Fri, 3 Nov 2017 03:16:21 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8812713FD51 for ; Fri, 3 Nov 2017 03:16:20 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 15so2053239wrb.5 for ; Fri, 03 Nov 2017 03:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EZWyzUnJdzyxwN4TK4nYTaH7qrCkTlAmLpCYZ/jRlcw=; b=Y9hDXXLErTp+D7OPqd5Popm0k8nPVc6C48/pY/34JwLokPIaFB4u3kAJB/zHWX1OJN 1icWqQLq1QZa/LCKXiziHayhVnFaevWlP8WtN1nCN34w735NQsW+nH0kl5cq6AMhZlhk Vwv3Sd/UL/4j9sM9xDbdVXMKcvPFC7WmoKhp7ukph9X4luqAJsTabK+Jsp9a99fN6BkY KVpn+/dyLFVuUdaCnBfzq0Oq86AfA6wA5TvDJRPUV6ssnsfbGngh57cUiCQdAqQkuvBp nUvUfOYAfBF4w+VL3rfnHvGB6UpxZVtoRfHemwWbPV+xP/P+7UiBxmgGI8jZ7qCTEsBM 0iUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EZWyzUnJdzyxwN4TK4nYTaH7qrCkTlAmLpCYZ/jRlcw=; b=njqtNADXdgbIphC8PepSDqrD/FRnhsGgBpuezQBnRc84ffx/PNDsCZGyPOZuUHVBTG ucFgzxgsUFRzEKs+1Utlz5YGuRs2F426vQbf5lu/kqfSwIf1E3RKU3K9gQPbA569rvQh js/qzurGaEQQYGouCvQ/XfQ5plAp+DqT41FCxdr8TkYdFtlVPuQ1hOThW+O6nFL9MjVL NN5HKDvLvvRAWLlMZnRUHc3bjB0uVAqjPcKPn1PzjRl/FSfFODGYrYiuI1GS6gb2g95Z fJ3h5Pj8QCddGXMhdeb1yQ8XHQ6Iq2TGa8TMGnkgm30SM02SBZUe8/DzLhyZtaAP1J/U 3tlQ== X-Gm-Message-State: AMCzsaUTeX4XtnCyMFcFgcvz/dJjzDGdzhjYRULu04FVBVm2RKK7N+6F gdZDE0pNaKOmBLrewHsnuzzU0QsMfsV4DyFwI2c= X-Google-Smtp-Source: ABhQp+S3cuhVQUs3lV3JB55HAUpwwNzb3CWMSQJpLpMbeDPw3Ses634tBk9eo8Ba/m+oY5chLUkTp/ogeD+1/o+7PBk= X-Received: by 10.223.199.15 with SMTP id k15mr5785850wrg.111.1509704179011; Fri, 03 Nov 2017 03:16:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.136.154 with HTTP; Fri, 3 Nov 2017 03:16:18 -0700 (PDT) In-Reply-To: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> From: Andy Hutton Date: Fri, 3 Nov 2017 10:16:18 +0000 Message-ID: To: Christer Holmberg Cc: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 10:16:23 -0000 Christer, I understand the desire to put others through the same pain as yourself that=E2=80=99s natural :-). But is it really necessary in this case? Andy On Fri, Nov 3, 2017 at 9:34 AM, Christer Holmberg wrote: > Hi, > > Just because the draft is =E2=80=9Csimple=E2=80=9D, I still think we shal= l do it properly, > as this is the specification defining the normative O/A procedures. > > Also, based on the discussions regarding SDP related terminology, I think > we should talk about =E2=80=9Cm=3D=E2=80=9C sections instead of =E2=80=9C= m=3D=E2=80=9C lines. > > Sometimes we do need additional WGLCs - I=E2=80=99ve lost count on how ma= ny WGLCs > we=E2=80=99ve had for BUNDLE by now :) > > Regards, > > Christer > > > On 03/11/17 11:18, "Andy Hutton" wrote: > >>The comment from Christer below was the only WGLC comment I believe. >> >>Whilst I see some value in what Christer suggests I think this is a >>simple draft which already adequately describes the solution and to be >>honest I don't really want to go round the loop of making significant >>changes to the draft and going through more last calls etc. >> >>Please can the chairs let us know how we should proceed. >> >>Unfortunately I will not be in Singapore to discuss but lets find a >>way to get this done. >> >>Regards >>Andy >> >> >> >> >>On Thu, Sep 28, 2017 at 10:35 AM, Christer Holmberg >> wrote: >>> Hi, >>> >>>>I agree that ideally we should have all the associated procedures in >>>>one place and having two specs is not ideal however we have been going >>>>round this circle for a couple of years now and just need to get this >>>>done. >>>> >>>>Originally we wanted this work to be done in MMUSIC but it got >>>>dispatched to SIPBrandy but it was later discovered that an update to >>>>RFC 4568 was needed and that the SIPBrandy charter did not allow this >>>>so we were told an MMUSIC draft was needed after all to update the RFC >>>>before the SIPBrandy work could be completed. >>>> >>>>I do not want to start again and waste another couple of years lets >>>>just get it finished. >>> >>> I suggest that we: >>> >>> 1) Keep the SIPBRANDY draft as it is. Perhaps they could add a >>>sentence >>> pointing out that that the normative procedures will be described >>> elsewhere. >>> 2) Keep the MMUSIC draft, but we add a proper 'SDP Offer/Answer >>> Considerations=E2=80=99 section, where we include the normal subsection= s (create >>> initial offer, process offer, process answer etc). >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>>>On Wed, Sep 27, 2017 at 9:35 PM, Christer Holmberg >>>> wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> In the mail you referenced the following is said: >>>>> >>>>> >>>>> >>>>> =E2=80=9CI see your point but Currently SIPBRANDY is chartered to pro= duce >>>>> Opportunistic SRTP as a BCP. There is also a milestone to >>>>> >>>>> inform MMUSIC or other appropriate WGs of any changes needed to >>>>>support >>>>> Opportunistic SRTP (Not expected to be published >>>>> >>>>> as an RFC). I think SIPBRANDY is just carrying out what they are >>>>>chartered >>>>> to do.=E2=80=9D >>>>> >>>>> >>>>> >>>>> But, draft-ietf-mmusic-opportunistic-negotiation doesn=E2=80=99t real= ly define >>>>>any >>>>> procedures =C2=AD it references the SIPBRANDY draft for everything. >>>>> >>>>> >>>>> >>>>> =E2=80=9C[I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time tr= ansport >>>>> >>>>> protocol (SRTP) can be negotiated opportunistically.=E2= =80=9D >>>>> >>>>> >>>>> >>>>> But, as the SIPBRANDY is only Informational, where are the normative >>>>> procedures? >>>>> >>>>> >>>>> >>>>> =E2=80=9CThe exact negotiation mechanism is however outside the scope= of this >>>>> document, >>>>> >>>>> an example mechanism can be found in >>>>> [I-D.ietf-sipbrandy-osrtp].=E2=80=9D >>>>> >>>>> >>>>> >>>>> How can negotiation be outside the scope of the document, when the >>>>>title of >>>>> the document contains =E2=80=9Cnegotiating=E2=80=9D? >>>>> >>>>> >>>>> >>>>> In addition, the text says that the sipbrandy only contains =E2=80=9C= an >>>>>example >>>>> mechanism=E2=80=9D. >>>>> >>>>> >>>>> >>>>> If we are going to have this document, I think we shall include >>>>>normative >>>>> offer/answer procedures. The draft DOES contain some normative >>>>>procedures, >>>>> but I think we shall have it all in one place. One shall not have to >>>>>read >>>>> both documents just to figure out the offer/answer procedures. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com] >>>>> Sent: 27 September 2017 21:58 >>>>> To: Christer Holmberg >>>>> Cc: mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] I-D Action: >>>>> draft-ietf-mmusic-opportunistic-negotiation-01.txt >>>>> >>>>> >>>>> >>>>> Hi Christer - >>>>> >>>>> >>>>> >>>>> See this: >>>>> >>>>>https://mailarchive.ietf.org/arch/msg/mmusic/wov2yErrgtUZURyRyVuVZ6K-n= L >>>>>I >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> -G >>>>> >>>>> >>>>> >>>>> On Sep 27, 2017, at 9:19 AM, Christer Holmberg >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I am currently reviewing draft-ietf-sipbrandy-osrtp-03, and the >>>>>following >>>>> question comes to my mind: do we really need >>>>> draft-ietf-mmusic-opportunistic-negotiation? :) >>>>> >>>>> Section 3 of draft-ietf-sipbrandy-osrtp-03 already more or less >>>>>contains >>>>> SDP Offer/Answer procedures for OSRTP. We can change the name of >>>>>section 3 >>>>> in that draft to =C2=B3SDP Offer/Answer Procedures=C2=B2, modify the = structure a >>>>> little, and add whatever might be missing. >>>>> >>>>> Or, am I missing something? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 14/09/17 19:03, "mmusic on behalf of internet-drafts@ietf.org" >>>>> wrote= : >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Multiparty Multimedia Session Contro= l >>>>>WG >>>>> of the IETF. >>>>> >>>>> Title : Negotiating SRTP and RTCP Feedback using the >>>>> RTP/AVP Profile >>>>> Authors : Andrew Hutton >>>>> Roland Jesske >>>>> Alan Johnston >>>>> Gonzalo Salgueiro >>>>> Bernard Aboba >>>>> Filename : draft-ietf-mmusic-opportunistic-negotiation-01.txt >>>>> Pages : 7 >>>>> Date : 2017-09-14 >>>>> >>>>> Abstract: >>>>> This document describes how the use of the Secure Real-time transpor= t >>>>> protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audi= o >>>>> Video Profile) defined in [RFC3551]. Such a mechanism is used to >>>>> provide a means for encrypted media to be used in environments where >>>>> support for encryption is not known in advance, and not required. >>>>> The same mechanism is also applied to negotiation of the Extended RT= P >>>>> Profile for Real-time Transport Control Protocol Based Feedback (RTP= / >>>>> AVPF) [RFC4585]. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >>>>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negot= i >>>>>at >>>>>i >>>>> on/ >>>>> >>>>> There are also htmlized versions available at: >>>>> >>>>>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiatio= n >>>>>-0 >>>>>1 >>>>> >>>>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-= n >>>>>eg >>>>>o >>>>> tiation-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-ne= got >>>>>ia >>>>>t >>>>> ion-01 >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>> > From nobody Fri Nov 3 04:06:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE5013FD87 for ; Fri, 3 Nov 2017 04:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xazj1ZsSkgAK for ; Fri, 3 Nov 2017 04:06:02 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D7913FD7C for ; Fri, 3 Nov 2017 04:06:01 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-76-59fc4d97b62e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.54.03220.79D4CF95; Fri, 3 Nov 2017 12:05:59 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 3 Nov 2017 12:05:58 +0100 From: Christer Holmberg To: Andy Hutton CC: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUAgACwtID//7EEIIAAs6WAgAA+fYCAOGvZgIAAF2yA///41QCAACC4AA== Date: Fri, 3 Nov 2017 11:05:58 +0000 Message-ID: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="euc-kr" Content-ID: <9C3237BB26A15A45A9AD2111460376A9@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7q+503z+RBr9eGFhcWreVyWLuFD+L qcsfszgwe0z5vZHVY+esu+weS5b8ZApgjuKySUnNySxLLdK3S+DK6HvcyVgwr7pixe2JbA2M HRVdjJwcEgImEs+PP2DrYuTiEBI4zCjR29HIBOEsYpSY/2gxYxcjBwebgIVE9z9tkAYRAW2J d1N2sILYzAJxEofXTmYHsYUFwiRObT7GBFETLjH73UFWkFYRgSyJO9sNQMIsAioSt1/sZQSx eQWsJQ72b2YDsYUElrFIfOrmB7E5BQIl5rXvZwaxGQXEJL6fWsMEsUpc4taT+UwQNwtILNlz nhnCFpV4+fgf2DmiAnoSG07cZoeIK0q0P21ghOjVkvjyYx8bhG0tce77d6jzFSWmdD9kh7hH UOLkzCcsExjFZyFZNwtJ+ywk7bOQtM9C0r6AkXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmD8HdzyW3UH4+U3jocYBTgYlXh4TbX/RAqxJpYVV+YeYpTgYFYS4Q21AgrxpiRWVqUW5ccX leakFh9ilOZgURLnddx3IUJIID2xJDU7NbUgtQgmy8TBKdXAqGK5MzTZ6ztH7KRTukbH7eLv rllw3YVzrW+Ga5m9R5pUmOisH9zpnMuyLX0VX2irhorKT7plN3vJfS8nKZ1ne/4utVjG57g3 vTJ5tYX3evlV+n6zq2XW+3/jCJzwq1hq8aT61w9azVfLb5fJ1jOqSg62YC4WPXp+yqJ2ldk3 puqErtxw+u5pJZbijERDLeai4kQAWb7PRrsCAAA= Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 11:06:05 -0000 SGksDQoNCj5DaHJpc3RlciwgSSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gcHV0IG90aGVycyB0 aHJvdWdoIHRoZSBzYW1lIHBhaW4NCj5hcyB5b3Vyc2VsZiB0aGF0oa9zIG5hdHVyYWwgOi0pLg0K DQpUaGVyZSBpcyBubyBwYWluIGxpa2UgQlVORExFIHBhaW4gLSBldmVuIHRob3VnaCBJQ0ViaXMg cGFpbiBjb21lcyB2ZXJ5DQpjbG9zZSA6KQ0KDQpBbnl3YXksIGl0oa9zIG5vdCB1cCB0byBtZSB0 byBkZWNpZGUgd2hldGhlciBhIG5ldyBXR0xDIHdvdWxkIGJlIG5lZWRlZC4NCkmhr2xsIGxlYXZl IHRoYXQgdG8gdGhlIGNoYWlycy4NCg0KPkJ1dCBpcyBpdCByZWFsbHkgbmVjZXNzYXJ5IGluIHRo aXMgY2FzZT8NCg0KU2VyaW91c2x5LCBJIHRoaW5rIGl0IGlzLiBUaGlzIGlzIHNvbWV0aGluZyB0 aGF0IGlzIGV4cGVjdGVkIHRvIGJlIHdpZGVseQ0KaW1wbGVtZW50ZWQgKGFzIHdlIGtub3csIHRo ZXJlIGFyZSBhbHJlYWR5IGltcGxlbWVudGF0aW9ucyBhbmQgU0lQDQpwcm9maWxlcyBkb2luZyBp dCksIHNvIEkgdGhpbmsgdGhlIHByb2NlZHVyZXMgbmVlZCB0byBiZSBjbGVhci4gSnVzdA0KYmVj YXVzZSB0aG9zZSBvZiB1c2UgZmFtaWxpYXIgd2l0aCBTRFAgbWlnaHQgdGhpbmsgaXShr3Mgc2lt cGxlLCBpdCBkb2VzbqGvdA0KbWVhbiBvdGhlcnMgd2lsbC4NCg0KTm93LCB0aGUgZHJhZnQgc2F5 czoNCg0KICAgIlRoZSBleGFjdCBuZWdvdGlhdGlvbiBtZWNoYW5pc20gaXMgaG93ZXZlciBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzDQogICAgZG9jdW1lbnQsIGFuIGV4YW1wbGUgbWVjaGFuaXNt IGNhbiBiZSBmb3VuZCBpbg0KW0ktRC5pZXRmLXNpcGJyYW5keS1vc3J0cF0uobENCg0KDQpIb3cg ZG8geW91IGltcGxlbWVudCBhbmQgdGVzdCBzb21ldGhpbmcgYmFzZWQgb24gYSBzdGF0ZW1lbnQg bGlrZSB0aGF0PyBJbg0KYWRkaXRpb24sIHRoZSChsGV4YW1wbGUgbWVjaGFuaXNtobEgZG9lcyBu b3QgY292ZXIgc3Vic2VxdWVudCBvZmZlcnMuDQoNCkFuZCwgaWV0Zi1zaXBicmFuZHktb3NydHAg c2F5czoNCg0KICAgIlRoZSB1c2Ugb2YgU0RQIFNlY3VyaXR5IERlc2NyaXB0aW9ucyB1c2luZyB0 aGUgUlRQL0FWUCBwcm9maWxlIGlzDQpkZWZpbmVkIGluDQogICAgW0ktRC5tbXVzaWMtb3Bwb3J0 dW5pc3RpYy1uZWdvdGlhdGlvbl0uobENCg0KDQpTbywgYm90aCBkcmFmdHMgc2VlbSB0byBzYXkg dGhhdCBvbmUgc2hhbGwgbG9vayBhdCB0aGUgb3RoZXIgZHJhZnQgZm9yDQpkZXRhaWxzIDopDQoN ClNvLCBJIHRoaW5rIHlvdSBzaG91bGQgYWRkIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnM6DQoNClgu ICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNClguMS4gIEdlbmVyYXRpbmcgdGhlIEluaXRp YWwgU0RQIE9mZmVyDQpYLjIuICBHZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyDQpYLjMuICBPZmZl cmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3ZXINClguNC4gIE1vZGlmeWluZyB0aGUgU2Vz c2lvbg0KDQoNCkluIGFkZGl0aW9uIHRvIGRlZmluaW5nIGhvdyB0aGUgb2ZmZXJzIGFuZCBhbnN3 ZXJzIGFyZSBjcmVhdGVkICh0aGF0IGlzDQp0aGUgc2ltcGxlIHBhcnQpLCBpdCBhbHNvIG5lZWRz IHRvIGJlIGNsZWFyIHdoZXRoZXIgdGhlcmUgYXJlIHJlc3RyaWN0aW9ucw0KaW4gc3Vic2VxdWVu dCBvZmZlcnMuDQoNCkZvciBleGFtcGxlLCB3aGF0IGRvZXMgaXQgbWVhbiB0byBzZW5kIGEgc3Vi c2VxdWVudCBvZmZlciB3aXRoIFJUUC9BVlAsDQpXSVRIT1VUIGE9ZmluZ2VycHJpbnQvY3J5cHRv L3pydHAtaGFzaD8gSXMgdGhlIHNlY3VyaXR5IGRpc2FibGVkPw0KDQpBbHNvLCBhcyB0aGlzIGRv Y3VtZW50IHVwZGF0ZXMgUkZDcyA0NTY4IGFuZCA0NTg1LCBJoa9kIHByZWZlciB0byBoYXZlIGEN CmRlZGljYXRlZCBzZWN0aW9uIG5hbWVkIKGwVXBkYXRlcyB0byBSRkMgNDU2OCBhbmQgUkZDIDQ1 ODWhsSwgYW5kIHRoZW4NCmluZGljYXRlIHdoYXQgaXMgdXBkYXRlZC4NCg0KQWxzbywgYXJlIHRo ZXJlIEJVTkRMRSBjb25zaWRlcmF0aW9ucz8gRm9yIGV4YW1wbGUsIGNhbiB5b3UgdXNlDQpvcHBv cnR1bmlzdGljIHNlY3VyaXR5IGluIG9uZSBidW5kbGVkIG0tIHNlY3Rpb24sIHdoaWxlIHlvdSB1 c2UgdmFuaWxsYQ0Kc2VjdXJpdHkgaW4gYW5vdGhlciBtLSBzZWN0aW9uPw0KDQpUaGVzZSBhcmUg cXVlc3Rpb25zIHRoYXQgbWF5IGNvbWUgdXAgc29vbmVyIG9yIGxhdGVyLCBzbyBsZXShr3MgdHJ5 IHRvDQphbnN3ZXIgdGhlbSBmcm9tIHRoZSBiZWdpbm5pbmcuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KPk9uIEZyaSwgTm92IDMsIDIwMTcgYXQgOTozNCBBTSwgQ2hyaXN0ZXIgSG9sbWJl cmcNCj48Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IEhpLA0KPj4N Cj4+IEp1c3QgYmVjYXVzZSB0aGUgZHJhZnQgaXMgobBzaW1wbGWhsSwgSSBzdGlsbCB0aGluayB3 ZSBzaGFsbCBkbyBpdA0KPj5wcm9wZXJseSwNCj4+IGFzIHRoaXMgaXMgdGhlIHNwZWNpZmljYXRp b24gZGVmaW5pbmcgdGhlIG5vcm1hdGl2ZSBPL0EgcHJvY2VkdXJlcy4NCj4+DQo+PiBBbHNvLCBi YXNlZCBvbiB0aGUgZGlzY3Vzc2lvbnMgcmVnYXJkaW5nIFNEUCByZWxhdGVkIHRlcm1pbm9sb2d5 LCBJDQo+PnRoaW5rDQo+PiB3ZSBzaG91bGQgdGFsayBhYm91dCChsG09obAgc2VjdGlvbnMgaW5z dGVhZCBvZiChsG09obAgbGluZXMuDQo+Pg0KPj4gU29tZXRpbWVzIHdlIGRvIG5lZWQgYWRkaXRp b25hbCBXR0xDcyAtIEmhr3ZlIGxvc3QgY291bnQgb24gaG93IG1hbnkNCj4+V0dMQ3MNCj4+IHdl oa92ZSBoYWQgZm9yIEJVTkRMRSBieSBub3cgOikNCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IENo cmlzdGVyDQo+Pg0KPj4NCj4+IE9uIDAzLzExLzE3IDExOjE4LCAiQW5keSBIdXR0b24iIDxhbmR5 aHV0dG9uLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4+DQo+Pj5UaGUgY29tbWVudCBmcm9tIENo cmlzdGVyIGJlbG93IHdhcyB0aGUgb25seSBXR0xDIGNvbW1lbnQgSSBiZWxpZXZlLg0KPj4+DQo+ Pj5XaGlsc3QgSSBzZWUgc29tZSB2YWx1ZSBpbiB3aGF0IENocmlzdGVyIHN1Z2dlc3RzIEkgdGhp bmsgdGhpcyBpcyBhDQo+Pj5zaW1wbGUgZHJhZnQgd2hpY2ggYWxyZWFkeSBhZGVxdWF0ZWx5IGRl c2NyaWJlcyB0aGUgc29sdXRpb24gYW5kIHRvIGJlDQo+Pj5ob25lc3QgSSBkb24ndCByZWFsbHkg d2FudCB0byBnbyByb3VuZCB0aGUgbG9vcCBvZiBtYWtpbmcgc2lnbmlmaWNhbnQNCj4+PmNoYW5n ZXMgdG8gdGhlIGRyYWZ0IGFuZCBnb2luZyB0aHJvdWdoIG1vcmUgbGFzdCBjYWxscyBldGMuDQo+ Pj4NCj4+PlBsZWFzZSBjYW4gdGhlIGNoYWlycyBsZXQgdXMga25vdyBob3cgd2Ugc2hvdWxkIHBy b2NlZWQuDQo+Pj4NCj4+PlVuZm9ydHVuYXRlbHkgSSB3aWxsIG5vdCBiZSBpbiBTaW5nYXBvcmUg dG8gZGlzY3VzcyBidXQgbGV0cyBmaW5kIGENCj4+PndheSB0byBnZXQgdGhpcyBkb25lLg0KPj4+ DQo+Pj5SZWdhcmRzDQo+Pj5BbmR5DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pk9uIFRodSwgU2Vw IDI4LCAyMDE3IGF0IDEwOjM1IEFNLCBDaHJpc3RlciBIb2xtYmVyZw0KPj4+PGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+IEhpLA0KPj4+Pg0KPj4+Pj5JIGFncmVl IHRoYXQgaWRlYWxseSB3ZSBzaG91bGQgaGF2ZSBhbGwgdGhlIGFzc29jaWF0ZWQgcHJvY2VkdXJl cyBpbg0KPj4+Pj5vbmUgcGxhY2UgYW5kIGhhdmluZyB0d28gc3BlY3MgaXMgbm90IGlkZWFsIGhv d2V2ZXIgd2UgaGF2ZSBiZWVuIGdvaW5nDQo+Pj4+PnJvdW5kIHRoaXMgY2lyY2xlIGZvciBhIGNv dXBsZSBvZiB5ZWFycyBub3cgYW5kIGp1c3QgbmVlZCB0byBnZXQgdGhpcw0KPj4+Pj5kb25lLg0K Pj4+Pj4NCj4+Pj4+T3JpZ2luYWxseSB3ZSB3YW50ZWQgdGhpcyB3b3JrIHRvIGJlIGRvbmUgaW4g TU1VU0lDIGJ1dCBpdCBnb3QNCj4+Pj4+ZGlzcGF0Y2hlZCB0byBTSVBCcmFuZHkgYnV0IGl0IHdh cyBsYXRlciBkaXNjb3ZlcmVkIHRoYXQgYW4gdXBkYXRlIHRvDQo+Pj4+PlJGQyA0NTY4IHdhcyBu ZWVkZWQgYW5kIHRoYXQgdGhlIFNJUEJyYW5keSBjaGFydGVyIGRpZCBub3QgYWxsb3cgdGhpcw0K Pj4+Pj5zbyB3ZSB3ZXJlIHRvbGQgYW4gTU1VU0lDIGRyYWZ0IHdhcyBuZWVkZWQgYWZ0ZXIgYWxs IHRvIHVwZGF0ZSB0aGUgUkZDDQo+Pj4+PmJlZm9yZSB0aGUgU0lQQnJhbmR5IHdvcmsgY291bGQg YmUgY29tcGxldGVkLg0KPj4+Pj4NCj4+Pj4+SSBkbyBub3Qgd2FudCB0byBzdGFydCBhZ2FpbiBh bmQgd2FzdGUgYW5vdGhlciBjb3VwbGUgb2YgeWVhcnMgbGV0cw0KPj4+Pj5qdXN0IGdldCBpdCBm aW5pc2hlZC4NCj4+Pj4NCj4+Pj4gSSBzdWdnZXN0IHRoYXQgd2U6DQo+Pj4+DQo+Pj4+IDEpICAg ICAgS2VlcCB0aGUgU0lQQlJBTkRZIGRyYWZ0IGFzIGl0IGlzLiBQZXJoYXBzIHRoZXkgY291bGQg YWRkIGENCj4+Pj5zZW50ZW5jZQ0KPj4+PiBwb2ludGluZyBvdXQgdGhhdCB0aGF0IHRoZSBub3Jt YXRpdmUgcHJvY2VkdXJlcyB3aWxsIGJlIGRlc2NyaWJlZA0KPj4+PiBlbHNld2hlcmUuDQo+Pj4+ IDIpICAgICAgS2VlcCB0aGUgTU1VU0lDIGRyYWZ0LCBidXQgd2UgYWRkIGEgcHJvcGVyICdTRFAg T2ZmZXIvQW5zd2VyDQo+Pj4+IENvbnNpZGVyYXRpb25zoa8gc2VjdGlvbiwgd2hlcmUgd2UgaW5j bHVkZSB0aGUgbm9ybWFsIHN1YnNlY3Rpb25zDQo+Pj4+KGNyZWF0ZQ0KPj4+PiBpbml0aWFsIG9m ZmVyLCBwcm9jZXNzIG9mZmVyLCBwcm9jZXNzIGFuc3dlciBldGMpLg0KPj4+Pg0KPj4+PiBSZWdh cmRzLA0KPj4+Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj5P biBXZWQsIFNlcCAyNywgMjAxNyBhdCA5OjM1IFBNLCBDaHJpc3RlciBIb2xtYmVyZw0KPj4+Pj48 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4+PiBIaSwNCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBJbiB0aGUgbWFpbCB5b3UgcmVmZXJlbmNlZCB0aGUg Zm9sbG93aW5nIGlzIHNhaWQ6DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gobBJIHNl ZSB5b3VyIHBvaW50IGJ1dCBDdXJyZW50bHkgU0lQQlJBTkRZIGlzIGNoYXJ0ZXJlZCB0byBwcm9k dWNlDQo+Pj4+Pj4gT3Bwb3J0dW5pc3RpYyBTUlRQIGFzIGEgQkNQLiBUaGVyZSBpcyBhbHNvIGEg bWlsZXN0b25lIHRvDQo+Pj4+Pj4NCj4+Pj4+PiBpbmZvcm0gTU1VU0lDIG9yIG90aGVyIGFwcHJv cHJpYXRlIFdHcyBvZiBhbnkgY2hhbmdlcyBuZWVkZWQgdG8NCj4+Pj4+PnN1cHBvcnQNCj4+Pj4+ PiBPcHBvcnR1bmlzdGljIFNSVFAgKE5vdCBleHBlY3RlZCB0byBiZSBwdWJsaXNoZWQNCj4+Pj4+ Pg0KPj4+Pj4+IGFzIGFuIFJGQykuICBJIHRoaW5rIFNJUEJSQU5EWSBpcyBqdXN0IGNhcnJ5aW5n IG91dCB3aGF0IHRoZXkgYXJlDQo+Pj4+Pj5jaGFydGVyZWQNCj4+Pj4+PiB0byBkby6hsQ0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEJ1dCwgZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0 dW5pc3RpYy1uZWdvdGlhdGlvbiBkb2VzbqGvdCByZWFsbHkNCj4+Pj4+PmRlZmluZQ0KPj4+Pj4+ YW55DQo+Pj4+Pj4gcHJvY2VkdXJlcyChqSBpdCByZWZlcmVuY2VzIHRoZSBTSVBCUkFORFkgZHJh ZnQgZm9yIGV2ZXJ5dGhpbmcuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gobBbSS1E LmlldGYtc2lwYnJhbmR5LW9zcnRwXSBkZXNjcmliZXMgaG93IFNlY3VyZSBSZWFsLXRpbWUgdHJh bnNwb3J0DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgICAgICAgIHByb3RvY29sIChTUlRQKSBjYW4g YmUgbmVnb3RpYXRlZCBvcHBvcnR1bmlzdGljYWxseS6hsQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4+IEJ1dCwgYXMgdGhlIFNJUEJSQU5EWSBpcyBvbmx5IEluZm9ybWF0aW9uYWwsIHdo ZXJlIGFyZSB0aGUgbm9ybWF0aXZlDQo+Pj4+Pj4gcHJvY2VkdXJlcz8NCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+PiChsFRoZSBleGFjdCBuZWdvdGlhdGlvbiBtZWNoYW5pc20gaXMgaG93 ZXZlciBvdXRzaWRlIHRoZSBzY29wZSBvZg0KPj4+Pj4+dGhpcw0KPj4+Pj4+IGRvY3VtZW50LA0K Pj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAgICAgICBhbiBleGFtcGxlIG1lY2hhbmlzbSBjYW4gYmUg Zm91bmQgaW4NCj4+Pj4+PiBbSS1ELmlldGYtc2lwYnJhbmR5LW9zcnRwXS6hsQ0KPj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEhvdyBjYW4gbmVnb3RpYXRpb24gYmUgb3V0c2lkZSB0aGUg c2NvcGUgb2YgdGhlIGRvY3VtZW50LCB3aGVuIHRoZQ0KPj4+Pj4+dGl0bGUgb2YNCj4+Pj4+PiB0 aGUgZG9jdW1lbnQgY29udGFpbnMgobBuZWdvdGlhdGluZ6GxPw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+IEluIGFkZGl0aW9uLCB0aGUgdGV4dCBzYXlzIHRoYXQgdGhlIHNpcGJyYW5k eSBvbmx5IGNvbnRhaW5zIKGwYW4NCj4+Pj4+PmV4YW1wbGUNCj4+Pj4+PiBtZWNoYW5pc22hsS4N Cj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBJZiB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSB0 aGlzIGRvY3VtZW50LCBJIHRoaW5rIHdlIHNoYWxsIGluY2x1ZGUNCj4+Pj4+Pm5vcm1hdGl2ZQ0K Pj4+Pj4+IG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVzLiBUaGUgZHJhZnQgRE9FUyBjb250YWluIHNv bWUgbm9ybWF0aXZlDQo+Pj4+Pj5wcm9jZWR1cmVzLA0KPj4+Pj4+IGJ1dCBJIHRoaW5rIHdlIHNo YWxsIGhhdmUgaXQgYWxsIGluIG9uZSBwbGFjZS4gT25lIHNoYWxsIG5vdCBoYXZlIHRvDQo+Pj4+ Pj5yZWFkDQo+Pj4+Pj4gYm90aCBkb2N1bWVudHMganVzdCB0byBmaWd1cmUgb3V0IHRoZSBvZmZl ci9hbnN3ZXIgcHJvY2VkdXJlcy4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBGcm9tOiBHb256YWxv IFNhbGd1ZWlybyAoZ3NhbGd1ZWkpIFttYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tXQ0KPj4+Pj4+ IFNlbnQ6IDI3IFNlcHRlbWJlciAyMDE3IDIxOjU4DQo+Pj4+Pj4gVG86IENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+Pj4gQ2M6IG1tdXNpY0Bp ZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOg0KPj4+Pj4+ IGRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24tMDEudHh0DQo+Pj4+ Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gSGkgQ2hyaXN0ZXIgLQ0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IFNlZSB0aGlzOg0KPj4+Pj4+DQo+Pj4+Pj5odHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL21tdXNpYy93b3YyeUVycmd0VVpVUnlSeVZ1Vlo2Sy0NCj4+ Pj4+Pm5MDQo+Pj4+Pj5JDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gQ2hlZXJzLA0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IC1HDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4gT24gU2VwIDI3LCAyMDE3LCBhdCA5OjE5IEFNLCBDaHJpc3RlciBIb2xtYmVyZw0K Pj4+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEhpLA0KPj4+Pj4+DQo+Pj4+Pj4gSSBhbSBjdXJyZW50bHkg cmV2aWV3aW5nIGRyYWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwLTAzLCBhbmQgdGhlDQo+Pj4+Pj5m b2xsb3dpbmcNCj4+Pj4+PiBxdWVzdGlvbiBjb21lcyB0byBteSBtaW5kOiBkbyB3ZSByZWFsbHkg bmVlZA0KPj4+Pj4+IGRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24/ IDopDQo+Pj4+Pj4NCj4+Pj4+PiBTZWN0aW9uIDMgb2YgZHJhZnQtaWV0Zi1zaXBicmFuZHktb3Ny dHAtMDMgYWxyZWFkeSBtb3JlIG9yIGxlc3MNCj4+Pj4+PmNvbnRhaW5zDQo+Pj4+Pj4gU0RQIE9m ZmVyL0Fuc3dlciBwcm9jZWR1cmVzIGZvciBPU1JUUC4gV2UgY2FuIGNoYW5nZSB0aGUgbmFtZSBv Zg0KPj4+Pj4+c2VjdGlvbiAzDQo+Pj4+Pj4gaW4gdGhhdCBkcmFmdCB0byCp+FNEUCBPZmZlci9B bnN3ZXIgUHJvY2VkdXJlc6n3LCBtb2RpZnkgdGhlDQo+Pj4+Pj5zdHJ1Y3R1cmUgYQ0KPj4+Pj4+ IGxpdHRsZSwgYW5kIGFkZCB3aGF0ZXZlciBtaWdodCBiZSBtaXNzaW5nLg0KPj4+Pj4+DQo+Pj4+ Pj4gT3IsIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0K Pj4+Pj4+DQo+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4gT24gMTQvMDkvMTcgMTk6MDMsICJtbXVzaWMgb24gYmVoYWxmIG9mIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyINCj4+Pj4+PiA8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4+Pj4+Pndyb3RlOg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+Pj4+IGRpcmVjdG9yaWVz Lg0KPj4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE11bHRpcGFydHkgTXVs dGltZWRpYSBTZXNzaW9uDQo+Pj4+Pj5Db250cm9sDQo+Pj4+Pj5XRw0KPj4+Pj4+IG9mIHRoZSBJ RVRGLg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgVGl0bGUgICAgICAgICAgIDogTmVnb3RpYXRpbmcg U1JUUCBhbmQgUlRDUCBGZWVkYmFjayB1c2luZyB0aGUNCj4+Pj4+PiBSVFAvQVZQIFByb2ZpbGUN Cj4+Pj4+PiAgICAgICBBdXRob3JzICAgICAgICAgOiBBbmRyZXcgSHV0dG9uDQo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgUm9sYW5kIEplc3NrZQ0KPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgIEFsYW4gSm9obnN0b24NCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBH b256YWxvIFNhbGd1ZWlybw0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIEJlcm5hcmQg QWJvYmENCj4+Pj4+PiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1 bmlzdGljLW5lZ290aWF0aW9uLTAxLnR4dA0KPj4+Pj4+IFBhZ2VzICAgICAgICAgICA6IDcNCj4+ Pj4+PiBEYXRlICAgICAgICAgICAgOiAyMDE3LTA5LTE0DQo+Pj4+Pj4NCj4+Pj4+PiBBYnN0cmFj dDoNCj4+Pj4+PiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRoZSB1c2Ugb2YgdGhlIFNl Y3VyZSBSZWFsLXRpbWUNCj4+Pj4+PnRyYW5zcG9ydA0KPj4+Pj4+ICBwcm90b2NvbCAoU1JUUCkg W1JGQzM3MTFdLiBjYW4gYmUgbmVnb3RpYXRlZCB1c2luZyB0aGUgUlRQL0FWUA0KPj4+Pj4+KEF1 ZGlvDQo+Pj4+Pj4gIFZpZGVvIFByb2ZpbGUpIGRlZmluZWQgaW4gW1JGQzM1NTFdLiAgU3VjaCBh IG1lY2hhbmlzbSBpcyB1c2VkIHRvDQo+Pj4+Pj4gIHByb3ZpZGUgYSBtZWFucyBmb3IgZW5jcnlw dGVkIG1lZGlhIHRvIGJlIHVzZWQgaW4gZW52aXJvbm1lbnRzDQo+Pj4+Pj53aGVyZQ0KPj4+Pj4+ ICBzdXBwb3J0IGZvciBlbmNyeXB0aW9uIGlzIG5vdCBrbm93biBpbiBhZHZhbmNlLCBhbmQgbm90 IHJlcXVpcmVkLg0KPj4+Pj4+ICBUaGUgc2FtZSBtZWNoYW5pc20gaXMgYWxzbyBhcHBsaWVkIHRv IG5lZ290aWF0aW9uIG9mIHRoZSBFeHRlbmRlZA0KPj4+Pj4+UlRQDQo+Pj4+Pj4gIFByb2ZpbGUg Zm9yIFJlYWwtdGltZSBUcmFuc3BvcnQgQ29udHJvbCBQcm90b2NvbCBCYXNlZCBGZWVkYmFjaw0K Pj4+Pj4+KFJUUC8NCj4+Pj4+PiAgQVZQRikgW1JGQzQ1ODVdLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4+Pj4+Pg0KPj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvDQo+Pj4+Pj50aQ0KPj4+Pj4+YXQNCj4+Pj4+PmkN Cj4+Pj4+PiBvbi8NCj4+Pj4+Pg0KPj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pg0KPj4+Pj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpDQo+Pj4+Pj5vbg0K Pj4+Pj4+LTANCj4+Pj4+PjENCj4+Pj4+Pg0KPj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljDQo+Pj4+Pj4tbg0K Pj4+Pj4+ZWcNCj4+Pj4+Pm8NCj4+Pj4+PiB0aWF0aW9uLTAxDQo+Pj4+Pj4NCj4+Pj4+PiBBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4NCj4+ Pj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1tdXNpYy1v cHBvcnR1bmlzdGljLW5lZw0KPj4+Pj4+b3QNCj4+Pj4+PmlhDQo+Pj4+Pj50DQo+Pj4+Pj4gaW9u LTAxDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj4+Pj4gc3VibWlzc2lvbg0K Pj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+Pj4NCj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbW11c2ljIG1haWxpbmcgbGlzdA0K Pj4+Pj4+IG1tdXNpY0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbW11c2ljIG1haWxpbmcg bGlzdA0KPj4+Pj4+IG1tdXNpY0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPj4+Pj4+DQo+ Pj4+DQo+Pg0KDQo= From nobody Fri Nov 3 05:38:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A9413AF75 for ; Fri, 3 Nov 2017 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 z4MH9Nk0H_eA for ; Fri, 3 Nov 2017 05:38:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB9213FD2F for ; Fri, 3 Nov 2017 05:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=274; q=dns/txt; s=iport; t=1509712719; x=1510922319; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=4FfdPZirOuOJarInfNP0fZtFO0OOAQRXw4/M0lSA2YQ=; b=HmsLgIVTri+CQtU8ytsf7QWYiZLPSz1ImlblNtP8vzoRPLTOMyPNPDYP RyeiIAHuvdjREWdWfyzfr7teayN2VfrhwIc3FnCrgCrhfAs626psNFW48 IzBLWOO2umfY6V+vyO8mvXmOlYqG1By7ffz5wcRuzXYmvhyBtVNE98Fay 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AwC0YvxZ/4MNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzSBUoQkmTmBVo5QhTSCZ4IRCoUxhGFBFgEBAQEBAQEBAWsohUcPAQV?= =?us-ascii?q?2AiYCXw0IAQGKEg2nMYIniw8BAQgCJoEPgh+CB4FTghILixyCYgWiDo4khliBf?= =?us-ascii?q?AGJe4c8lhaBOSUBMYFsVSUVgy6EeiWNbAEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,338,1505779200"; d="scan'208";a="305620652" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2017 12:38:39 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA3CccPQ018023 for ; Fri, 3 Nov 2017 12:38:38 GMT To: mmusic From: Flemming Andreasen Message-ID: <1b6e4c21-7609-529d-ffeb-1e26f5f919e5@cisco.com> Date: Fri, 3 Nov 2017 08:39:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [MMUSIC] Cancel MMUSIC meeting in Singapore ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 12:38:46 -0000 Greetings We no longer have any requests for meeting time in Singapore and the final agenda is due this coming Monday (November 6). If we do not receive any agenda topics before,  then we will go ahead and cancel the MMUSIC meeting. Thanks -- Bo & Flemming From nobody Fri Nov 3 09:04:44 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A48913FED2 for ; Fri, 3 Nov 2017 09:04:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.64.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150972508262.16499.14537074412564426209.idtracker@ietfa.amsl.com> Date: Fri, 03 Nov 2017 09:04:42 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 16:04:43 -0000 Changed milestone "Submit SCTP-Based Media Transport in SDP as Proposed Standard.", resolved as "Done". Changed milestone "Using the SDP Offer/Answer Mechanism for DTLS", resolved as "Done". URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Fri Nov 3 11:43:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5055213FF44 for ; Fri, 3 Nov 2017 11:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LvhzNvZqkO_E for ; Fri, 3 Nov 2017 11:43:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0006413FF43 for ; Fri, 3 Nov 2017 11:43:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 227AAB80D88; Fri, 3 Nov 2017 11:42:52 -0700 (PDT) To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, bo.burman@ericsson.com, fandreas@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: saitha@qti.qualcomm.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171103184252.227AAB80D88@rfc-editor.org> Date: Fri, 3 Nov 2017 11:42:52 -0700 (PDT) Archived-At: Subject: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 18:43:04 -0000 The following errata report has been submitted for RFC3264, "An Offer/Answer Model with Session Description Protocol (SDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5177 -------------------------------------- Type: Technical Reported by: Sandeep Kumar Aitha Section: 5.1 Original Text ------------- Section 5.1 says: However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. Section 6.2 says: In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Corrected Text -------------- Only one of the above statements can be correct. Notes ----- Above two statements are conflicting. The answerer should be able to either map the payload type to a different codec or not. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3264 (draft-ietf-mmusic-sdp-offer-answer-02) -------------------------------------- Title : An Offer/Answer Model with Session Description Protocol (SDP) Publication Date : June 2002 Author(s) : J. Rosenberg, H. Schulzrinne Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Fri Nov 3 13:41:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C91613FFCD for ; Fri, 3 Nov 2017 13:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wFYOhuTnYnif for ; Fri, 3 Nov 2017 13:41:53 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9748513FFCB for ; Fri, 3 Nov 2017 13:41:53 -0700 (PDT) X-AuditID: 12074413-38bff70000007929-27-59fcd4906bca Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 6F.3E.31017.094DCF95; Fri, 3 Nov 2017 16:41:52 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vA3KfpHI018064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Nov 2017 16:41:52 -0400 To: saitha@qti.qualcomm.com Cc: mmusic@ietf.org References: <20171103184252.227AAB80D88@rfc-editor.org> From: Paul Kyzivat Message-ID: Date: Fri, 3 Nov 2017 16:41:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171103184252.227AAB80D88@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYndR1J1w5U+kQdsPfYupyx+zWHz4e43J gcljyZKfTB6Lpj5jDGCK4rJJSc3JLEst0rdL4MpYN6mJueA+T8Wj66uYGxgnc3UxcnJICJhI bDrdxdbFyMUhJLCDSWLj1iMsIAkhgQdMEn/OsYLYwgIOEts/n2ACsUUEpCWmL7vABmIzCwhL 3Fn+nxGi3lziX89msDibgJbEnEP/webwCthLzNj1HsxmEVCRWNL6hRnEFhVIk7gz4yETRI2g xMmZT8BqOAUsJM5/6WOBmG8mMW/zQ2YIW1zi1pP5TBC2vMT2t3OYJzAKzELSPgtJyywkLbOQ tCxgZFnFKJeYU5qrm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJERLAwjsYd52UO8QowMGo xMPLMfl3pBBrYllxZe4hRkkOJiVR3g0n/kQK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuF9WQSU 401JrKxKLcqHSUlzsCiJ86otUfcTEkhPLEnNTk0tSC2CycpwcChJ8PpdBmoULEpNT61Iy8wp QUgzcXCCDOcBGp4IUsNbXJCYW5yZDpE/xWjM0dNz4w8Tx7OZrxuYhVjy8vNSpcR5W0FKBUBK M0rz4KbBktArRnGg54R5w0GqeIAJDG7eK6BVTECrZnOArSpJREhJNTC66n4LkthWNG9pksl3 7zVHRFdYbU27d7+67uJPxc1WU/fvE1/ulW59lovF6vu0Jx5HzNPKwwLnCtwLymZZILbEZZIu 18/jXT7O9R/Mpr/eksOQc2vh5n5ZrU+luT8uN5evW/Xw85OfNY7iB6YfTZ+2TWLGg0w1lsen lttZzWdJa1WdnPMhav1SJZbijERDLeai4kQAtsDi7x0DAAA= Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 03 Nov 2017 20:41:55 -0000 Just to get a head start on discussion of this, comment at end. On 11/3/17 2:42 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC3264, > "An Offer/Answer Model with Session Description Protocol (SDP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5177 > > -------------------------------------- > Type: Technical > Reported by: Sandeep Kumar Aitha > > Section: 5.1 > > Original Text > ------------- > Section 5.1 says: > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > Section 6.2 says: > In the case of RTP, if a particular codec was referenced with a > specific payload type number in the offer, that same payload type > number SHOULD be used for that codec in the answer. > > Corrected Text > -------------- > Only one of the above statements can be correct. > > > Notes > ----- > Above two statements are conflicting. > The answerer should be able to either map the payload type to a different codec or not. These statements are not in conflict. "SHOULD" is different from "MUST", in that it may be violated with valid reason. There are a variety of reasons why an answerer might have to violate the SHOULD. And in this case the offerer MUST send media using the PT in the answer, while the answerer MUST send media using the PT from the offer. Thanks, Paul From nobody Mon Nov 6 02:23:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877CC13FB1A for ; Mon, 6 Nov 2017 02:23:23 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hVB-c4ij98Be for ; Mon, 6 Nov 2017 02:23:21 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994C213FA82 for ; Mon, 6 Nov 2017 02:23:21 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id b189so12561723wmd.4 for ; Mon, 06 Nov 2017 02:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=rgRZW9P7i7Wf7z4bhRAOj4eBb/bloG77JiIMioXtIHs=; b=Des5MTTdIj4LkHeINFJ+/7jsKf7fN+dn5mBWL93zmu0RN6WZ+0xildrBhRX9xKBS4c 3veFMk1/sauUdGn2A6qgGnd0LBdq9NLriVaz1x5lKCdfwtfn5ZUd26GFy3y78QqcXY7b y0Kd0h8jlCUwAKh66fAPv/LnDgTkFc5C7U2TlRrAz8k5IHlJWeoR+musuXnS4iEC3wnR JcnLh8d5wIgsxWt7D97rZ9rZfdu5fC+DxPAfklRfxciAQWL9iexYhSCQwMtkngMKUJoc Z5CY6iVykFSDFZxFEsY/vmFNVuEX9AN9iGgLJWLzmp+8mNq50a0ycxBn/rzLS+r7zq06 +rsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=rgRZW9P7i7Wf7z4bhRAOj4eBb/bloG77JiIMioXtIHs=; b=pYY53ZZl6edIk/dhOumW4mc3Y56i+F14o6WAtZkZDWDdwqPAqK7g0frKQyxy0MyNPW iQ0BVfHjdFrexqQ/IZwnUaHfCWhj1uyih0g/YF/R7+cLUjSFADwpWFvtaDPUIK3SgLMj EfJ+N0EB0ZqTvE4eJ2P4IwEJK7vgrIDXMCCuLlsaUygkABZB5SyD9TJTKARAW48sINqJ y/dDSL6mRMKr8q8IytCaSal5vSmYo44FLIY4ECwoBtKaJtcztHNLVhazEsGIB1LrgqA9 9qu0j1K9LP6PUQ0FYETnMtPvDaqXhCC6Ey/V1j6oSIzZYvbrmDYksVosahSRY8u+b69s quhw== X-Gm-Message-State: AMCzsaUw8Xxz+HhCk/OSa4ZQBPpB9wtqm2tL6edAI+fAxijMM5t6z3YG VDcOPW8XtTJ2JWPh+oKPT6Sro43k X-Google-Smtp-Source: ABhQp+Q0e6JOneq9c9XzeXuPDI0QPsvZWER2d2pIATYsWxfrbtOJwcwFRWcwxacOqioM61YNbo7utQ== X-Received: by 10.80.245.21 with SMTP id t21mr19868886edm.169.1509963799802; Mon, 06 Nov 2017 02:23:19 -0800 (PST) Received: from [192.168.2.113] (d91-130-11-3.cust.tele2.at. [91.130.11.3]) by smtp.googlemail.com with ESMTPSA id n20sm11043394edb.93.2017.11.06.02.23.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 02:23:19 -0800 (PST) To: Christer Holmberg , MMUSIC References: From: Thomas Stach Message-ID: <03514411-8b63-0b0a-402a-c2264fa5c3bc@gmail.com> Date: Mon, 6 Nov 2017 11:23:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2D56A10D24F588E843B76681" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] ICE check list state X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 10:23:23 -0000 This is a multi-part message in MIME format. --------------2D56A10D24F588E843B76681 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Christer, On 2017-11-03 10:00, Christer Holmberg wrote: > Hi, > > Section 8.1 of draft-mmusic-trickle-ice talks about “active” and > “frozen” check lists. What document are you talking about? I'm only aware of draft-ietf-mmusic-trickle-ice-sip and this doesn't lose a single word about the ICE states. > > Note that the concept of “active" and “frozen" check lists has been > removed from ICEbis. Only the check list states (Running, Completed > and Failed) remain. > > So, IF the concept is needed for trickle, it has to be defined in the > ICE trickle spec, and then reflected in the MMUSIC trickle spec. You may be right for draft-ietf-ice-trickle, but draft-ietf-mmusic-trickle-ice-sip never signalled any states of any check lists at the - what we call it - ICE agents. I also can't imagine such a need now, since draft-ietf-mmusic-trickle-ice-sip only defines how the candidates are trickled, but it is deliberately silent about ICE's connectivity checking algorithm.  Maybe you can advise in case I'm missing something, but currently I don't see that changes necessary for draft-ietf-mmusic-trickle-ice-sip. > > Commenting on the actual text in section 8.1., which says: > "Given that with trickle ICE, other check lists may still be empty at that point, a trickle ICE > agent SHOULD also maintain an explicit Active/Frozen state for every check list,…" > In my opinion you should not call it an Active/Frozen state. Rather > call it flag, or something. After quite some searching I only found this text in in section 8.1 of https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01 (!) If this is the document you are talking about at the top, it seems to be  slightly out of date :) Regards Thomas > > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------2D56A10D24F588E843B76681 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Christer,


On 2017-11-03 10:00, Christer Holmberg wrote:
Hi,

Section 8.1 of draft-mmusic-trickle-ice talks about “active” and “frozen” check lists.
What document are you talking about?
I'm only aware of draft-ietf-mmusic-trickle-ice-sip and this  doesn't lose a single word about the ICE states.


Note that the concept of “active" and “frozen" check lists has been removed from ICEbis. Only the check list states (Running, Completed and Failed) remain.

So, IF the concept is needed for trickle, it has to be defined in the ICE trickle spec, and then reflected in the MMUSIC trickle spec.
You may be right for draft-ietf-ice-trickle, but draft-ietf-mmusic-trickle-ice-sip never signalled any states of any check lists at the - what we call it - ICE agents.
I also can't imagine such a need now, since draft-ietf-mmusic-trickle-ice-sip only defines how the candidates are trickled,
but it is deliberately silent about ICE's connectivity checking algorithm.
 Maybe you can advise in case I'm missing something, but currently I don't see that changes necessary for draft-ietf-mmusic-trickle-ice-sip.


Commenting on the actual text in section 8.1., which says:
   "Given that with trickle ICE, other check lists may still be empty at that point, a trickle ICE
   agent SHOULD also maintain an explicit Active/Frozen state for every check list,…"
In my opinion you should not call it an Active/Frozen state. Rather call it flag, or something.
After quite some searching I only found this text in in section 8.1 of https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01 (!)
If this is the document you are talking about at the top, it seems to be  slightly out of date :)

Regards
Thomas


Regards,

Christer


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

--------------2D56A10D24F588E843B76681-- From nobody Mon Nov 6 02:39:17 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A549D13FC1B for ; Mon, 6 Nov 2017 02:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iBOeOeGuP8bZ for ; Mon, 6 Nov 2017 02:39:06 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA34713FC15 for ; Mon, 6 Nov 2017 02:38:56 -0800 (PST) X-AuditID: c1b4fb3a-1c7889c000006897-4e-5a003bbed788 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 57.E4.26775.EBB300A5; Mon, 6 Nov 2017 11:38:54 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Mon, 6 Nov 2017 11:38:10 +0100 From: Christer Holmberg To: Thomas Stach , MMUSIC Thread-Topic: [MMUSIC] ICE check list state Thread-Index: AQHTVIIu8TYbxgoL5k+3T6Yx192s7KMHGL2AgAAXCQA= Date: Mon, 6 Nov 2017 10:38:09 +0000 Message-ID: References: <03514411-8b63-0b0a-402a-c2264fa5c3bc@gmail.com> In-Reply-To: <03514411-8b63-0b0a-402a-c2264fa5c3bc@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D626097425B04christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2J7uO4+a4YogyXdVhZTlz9msfh0YiuT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx8dk7poJJvhVXntxlamDscupi5OSQEDCR 2PHwKksXIxeHkMBhRokls14yQziLGCVe/TkBlOHgYBOwkOj+pw3SICLgIvHoxQx2EFtYQEvi 5KorTCAlIgLaEu1HqyFMK4mZFxRBKlgEVCS+rtsCVs0rYC2xb+FnZhBbSCBP4tODs2CdnAK2 Eq8PcIKEGQXEJL6fWsMEYjMLiEvcejKfCeJKAYkle84zQ9iiEi8f/2MFsUUF9CQ2nLjNDjJG QkBRYnm/HIjJLJAg8X4qJ8RSQYmTM5+wTGAUmYVk6CyEqllIqiBKDCTen5vPDGFrSyxb+BrK 1pfY+OUsI4RtLdH6s5kdWc0CRo5VjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIExdnDLb6sd jAefOx5iFOBgVOLhddJmiBJiTSwrrsw9xCjBwawkwrtdHSjEm5JYWZValB9fVJqTWnyIUZqD RUmc12HfhQghgfTEktTs1NSC1CKYLBMHp1QD41KdlNTngXm2PM8f7nrl67bcM7f90C7fIrfy ZcxrxAMnL3kuve+728f4yR1pm/XMf23W0NWI0lO3Opnbtd3s7bb+2Ldb5+wsvj8h3s6wfEK/ qptYGON1v5jDmeq+G2QL3h1jeNM91d+Puzj6g4/F2p4//eIi1u5Xgjblu79eOs37KYe9wCdB JZbijERDLeai4kQAmGv8H60CAAA= Archived-At: Subject: Re: [MMUSIC] ICE check list state X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 10:39:15 -0000 --_000_D626097425B04christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, You are right =96 I was looking at an old version of the document. I double checked the latest version of draft-ietf-mmusic-trickle-ice-sip, a= nd the issue does NOT exist there. Sorry for the confusion. The problem DOES seem to exist in draft-ietf-mmusic-ice-sip-sdp, however, b= ut that=92s a separate discussion :) Regards, Christer From: Thomas Stach = > Date: Monday 6 November 2017 at 13:23 To: Christer Holmberg >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] ICE check list state Christer, On 2017-11-03 10:00, Christer Holmberg wrote: Hi, Section 8.1 of draft-mmusic-trickle-ice talks about =93active=94 and =93fro= zen=94 check lists. What document are you talking about? I'm only aware of draft-ietf-mmusic-trickle-ice-sip and this doesn't lose = a single word about the ICE states. Note that the concept of =93active" and =93frozen" check lists has been rem= oved from ICEbis. Only the check list states (Running, Completed and Failed= ) remain. So, IF the concept is needed for trickle, it has to be defined in the ICE t= rickle spec, and then reflected in the MMUSIC trickle spec. You may be right for draft-ietf-ice-trickle, but draft-ietf-mmusic-trickle-= ice-sip never signalled any states of any check lists at the - what we call= it - ICE agents. I also can't imagine such a need now, since draft-ietf-mmusic-trickle-ice-s= ip only defines how the candidates are trickled, but it is deliberately silent about ICE's connectivity checking algorithm. Maybe you can advise in case I'm missing something, but currently I don't = see that changes necessary for draft-ietf-mmusic-trickle-ice-sip. Commenting on the actual text in section 8.1., which says: "Given that with trickle ICE, other check lists may still be empty at th= at point, a trickle ICE agent SHOULD also maintain an explicit Active/Frozen state for every che= ck list,=85" In my opinion you should not call it an Active/Frozen state. Rather call it= flag, or something. After quite some searching I only found this text in in section 8.1 of http= s://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01 (!) If this is the document you are talking about at the top, it seems to be s= lightly out of date :) Regards Thomas Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.orghttps://www.ietf.org/mailman/listinf= o/mmusic --_000_D626097425B04christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <55DECA1D90C91142A34AD2C98A1BE9CE@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Thomas,

You are right =96 I was looking at an old version of the document.

I double checked the latest version of draft-ietf-mmusic-trickle-ice-sip, a= nd the issue does NOT exist there.

Sorry for the confusion.

The= problem DOES seem to exist in draft-ietf-mmusic-ice-sip-sdp, however, but that=92s a separate discussion :)

Regards,

Christer



From: Thomas Stach <thomass.stach@gmail.com>
Date: Monday 6 November 2017 at 13:= 23
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" = <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE check lis= t state

Christer,


On 2017-11-03 10:00, Christer Holmberg wrote= :
Hi,

Section 8.1 of draft-mmusic-trickle-ice talks about =93active=94 and = =93frozen=94 check lists.
What document are you talking about?
I'm only aware of draft-ietf-mmusic-trickle-ice-sip and this  doesn't = lose a single word about the ICE states.


Note that the concept of =93active" and =93frozen" check lis= ts has been removed from ICEbis. Only the check list states (Running, Compl= eted and Failed) remain.

So, IF the concept is needed for trickle, it has to be defined in the = ICE trickle spec, and then reflected in the MMUSIC trickle spec.
You may be right for draft-ietf-ice-trickle, but draft-ietf-mmusic-trickle-= ice-sip never signalled any states of any check lists at the - what we call= it - ICE agents.
I also can't imagine such a need now, since draft-ietf-mmusic-trickle-ice-s= ip only defines how the candidates are trickled,
but it is deliberately silent about ICE's connectivity checking algorithm.<= br>  Maybe you can advise in case I'm missing something, but currently I d= on't see that changes necessary for draft-ietf-mmusic-trickle-ice-sip.


Commenting on the actual text in section 8.1., which says:
   "Given that with trickle I=
CE, other check lists may still be empty at that point, a trickle ICE
   agent SHOULD also maintain an explicit Active/Frozen state for every che=
ck list,=85"
In my opinion you should not call it an Active/Frozen state. Rather ca= ll it flag, or something.
After quite some searching I only found this text in in section 8.1 of https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01 (!)
If this is the document you are talking about at the top, it seems to be&nb= sp; slightly out of date :)

Regards
Thomas


Regards,

Christer


_______________________________________________
mmusic mailing list
mmusi=
c@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic

 --_000_D626097425B04christerholmbergericssoncom_-- From nobody Mon Nov 6 04:26:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A403813FB6A for ; Mon, 6 Nov 2017 04:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4lte_RXkcWkK for ; Mon, 6 Nov 2017 04:26:26 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C019813FB18 for ; Mon, 6 Nov 2017 04:26:25 -0800 (PST) X-AuditID: c1b4fb30-759ff70000007d10-78-5a0054ef92a8 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.EF.32016.FE4500A5; Mon, 6 Nov 2017 13:26:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Mon, 6 Nov 2017 13:26:23 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: PR on BUNDLE transport terminology Thread-Index: AQHTVvp0mPqfiEBiQUyZYpGw48JhHg== Date: Mon, 6 Nov 2017 12:26:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D626235425C02christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7iO77EIYog0lrTC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLaubSwFP/kq+m8fYG5g/MjTxcjJISFgIvF9x0zmLkYuDiGB w4wSG95tZIVwFjFKdF15CZTh4GATsJDo/qcN0iAioC7xdW8PM4gtLGAs0TirnRkibiGx+ex9 dpByEQE9ia2NRSBhFgEViRV7DzKC2LwC1hJNV+eClTMKiEl8P7WGCcRmFhCXuPVkPhPEPQIS S/acZ4awRSVePv7HCmKLAo3ccOI2O0RcUeLjq32MEL0JEi0rf7BBzBeUODnzCcsERqFZSMbO QlI2C0kZRNxA4v25+cwQtrbEsoWvoWx9iY1fzjJC2NYSJ1qPsCOrWcDIsYpRtDi1OCk33chI L7UoM7m4OD9PLy+1ZBMjMFIObvltsIPx5XPHQ4wCHIxKPLxPfRmihFgTy4orcw8xSnAwK4nw blcHCvGmJFZWpRblxxeV5qQWH2KU5mBREud13HchQkggPbEkNTs1tSC1CCbLxMEp1cAYqzPr 56nnSspNRq3uazIXum6V4Zn66NIyz4wqK82irzs0C5f/S3NrkT2tteRevLSFraduVNb9G9ZR 6pLZ80M6bX5fCnhhV7T7f3STjLacltu1qH7TaVPck7vSWfiuvbhydZHbrPL1a1umdzwteHBx opJ5mrRq6/pTGn1rdUz0tjEF7HgyI16JpTgj0VCLuag4EQA30B42kAIAAA== Archived-At: Subject: [MMUSIC] BUNDLE: PR on BUNDLE transport terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 12:26:28 -0000 --_000_D626235425C02christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on Taylor=92s PR, I have created a dedicated PR that introduces the = =91BUNDLE transport=92 concept. A =91BUNDLE transport=92 is a 5-tuple that = is used for receiving media within a BUNDLE group. A =91BUNDLE transport=92= is also used for sending media. The same =91BUNDLE transports=92 may be us= ed for sending and receiving media (e.g., if symmetric RTP is used), or sep= arate ones might be used. https://github.com/cdh4u/draft-sdp-bundle/pull/41 Regards, Christer --_000_D626235425C02christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Based on Taylor=92s PR, I have created a dedicated PR that introduces = the =91BUNDLE transport=92 concept. A =91BUNDLE transport=92 is a 5-tuple t= hat is used for receiving media within a BUNDLE group. A =91BUNDLE transpor= t=92 is also used for sending media. The same =91BUNDLE transports=92 may be used for sending and receiving media (e.g.,= if symmetric RTP is used), or separate ones might be used.

Regards,

Christer
--_000_D626235425C02christerholmbergericssoncom_-- From nobody Mon Nov 6 06:03:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5415413FC1E for ; Mon, 6 Nov 2017 06:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Bqz3PskcOAQg for ; Mon, 6 Nov 2017 06:03:43 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3768513FB40 for ; Mon, 6 Nov 2017 06:03:41 -0800 (PST) X-AuditID: c1b4fb3a-de7ff70000006897-df-5a006bbbb8a8 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 98.FF.26775.BBB600A5; Mon, 6 Nov 2017 15:03:39 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Mon, 6 Nov 2017 15:03:38 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Mandating symmetric media? Thread-Index: AQHTVwgLo+gWRS+bMkmXyKhd/WGGcA== Date: Mon, 6 Nov 2017 14:03:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D6263A1F25CD4christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7n+7ubIYog7VPpC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO1bprMVLOWs6H/cwtjA2MvRxcjJISFgIrHr2S22LkYuDiGB w4wSJ09NZIZwFjFKdG56C5Th4GATsJDo/qcN0iAioC7xdW8PM4gtLKAt8WzBRCaIuIHE/Hvz 2SBsPYnnG9tYQWwWARWJ5U9WMILYvALWEg2tE1lAbEYBMYnvp9aA9TILiEvcejKfCeIgAYkl e84zQ9iiEi8f/wObIwo0c8OJ2+wQcSWJHxsusUD0Jki8uL4Mar6gxMmZT1gmMArNQjJ2FpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwGKrXWqJ36Q0mZDULGDlWMYoWpxYX56YbGemlFmUm Fxfn5+nlpZZsYgTGysEtv612MB587niIUYCDUYmHd0UWQ5QQa2JZcWXuIUYJDmYlEd7t6kAh 3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRmp6YWpBbBZJk4OKUaGMX2u8aH/td/ OilB9MfrdzdvKxoIfGPRPmnga3qBZ8n2xS4biyqnGl85eHNTxeG5TZI8eXduH/3PZO5/YI78 UsGvz/9tLK+6FW3g623PIPr95PSrB+UbXnFbvYp4NeGMbrSHsfijS4/nvE9hv+Wz8dObOzMe ZD9g3/mhP9joI/e5Xl09P/0XVQpKLMUZiYZazEXFiQBe1mrnkQIAAA== Archived-At: Subject: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 14:03:45 -0000 --_000_D6263A1F25CD4christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, With ICE, DTLS, symmetric RTP etc becoming more common, would anyone have a= problem with mandating symmetric media when using BUNDLE? Regards, Christer --_000_D6263A1F25CD4christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8DCFFC225310A74982A4B3636CB5D890@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

With ICE, DTLS, symmetric RTP etc becoming more common, would anyone h= ave a problem with mandating symmetric media when us= ing BUNDLE?

Regards,

Christer
--_000_D6263A1F25CD4christerholmbergericssoncom_-- From nobody Mon Nov 6 06:54:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECA613FC2C for ; Mon, 6 Nov 2017 06:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sYC7a2DqiB3w for ; Mon, 6 Nov 2017 06:54:45 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E67213F698 for ; Mon, 6 Nov 2017 06:54:45 -0800 (PST) X-AuditID: c1b4fb2d-bddff7000000268d-ce-5a0077b31c9d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1A.3F.09869.3B7700A5; Mon, 6 Nov 2017 15:54:43 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Mon, 6 Nov 2017 15:54:43 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: PR on ICE Thread-Index: AQHTVw8tX/jjEQXn6ECK/15wsyF/wQ== Date: Mon, 6 Nov 2017 14:54:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D626461825D11christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7uu7mcoYog+8zjSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHeXFrIXPOSq+Nj9nLGBcStnFyMnh4SAiURTxxn2LkYuDiGB w4wSi+d1MUM4ixglFvbtYe1i5OBgE7CQ6P6nDdIgIqAu8XVvDzOILSwgJXHgzjJGiLi8RMvl 3Uwg5SICehLXuoJAwiwCKhJPj3SClfMKWEssvH4LzGYUEJP4fmoNE4jNLCAucevJfCaIewQk luw5zwxhi0q8fPyPFcQWBRq54cRtdpDxEgJKEtO2pkG0Jkgs23uEBWK8oMTJmU9YJjAKzUIy dRaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858Biq11riy/lpKGoWMHKsYhQtTi0uzk03MtZL LcpMLi7Oz9PLSy3ZxAiMk4NbfuvuYFz92vEQowAHoxIP75VMhigh1sSy4srcQ4wSHMxKIrzb 1YFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0tSC2CyTJxcEo1MKZGa9Rm S2VFm6bY6KvHPIsNPn/13IPVWiVfl9SFHhd1SZ8bwLRk1+6yAGtb144Vwka800367k06/cn4 3nGtysdXrLjmqW+Pt+9SOusvdX+/pXW47qWfjp6xm06auGmtETpiaWDS4vVEfWXj3xapxUnm Lzl6XuaEfg+9wZ45kdHtXdXV7pkPlFiKMxINtZiLihMBl0kckI8CAAA= Archived-At: Subject: [MMUSIC] BUNDLE: PR on ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 14:54:48 -0000 --_000_D626461825D11christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A PR making some editorial changes to the ICE text, and also aligning the I= CE references (the current version references both the RFC and the bis). https://github.com/cdh4u/draft-sdp-bundle/pull/42 Regards, Christer --_000_D626461825D11christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

A PR making some editorial changes to the ICE text, and also aligning = the ICE references (the current version references both the RFC and the bis= ).


Regards,

Christer
--_000_D626461825D11christerholmbergericssoncom_-- From nobody Mon Nov 6 08:55:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F5D13FB36 for ; Mon, 6 Nov 2017 08:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com 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 KWm9O9LzTGd0 for ; Mon, 6 Nov 2017 08:55:41 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD2D13FB1D for ; Mon, 6 Nov 2017 08:55:41 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id 8so11759739qtv.1 for ; Mon, 06 Nov 2017 08:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vZ2zUI0FcmfZpav1YaXRuAg1iVvAVd4GO4V3ktbV8T0=; b=deCy/j/63bGdhoV+87FrQs1W37nILsdqgNbQvJ1HkFiqry38Ulqt1C8O0EgueaGeru 9N09kWkNu/XP+1J0Lslz7SS0UcjZrf9s90vfQyv/ORI8SQJS+fbkT5Ior/iSvyGg/oES oaW79Q5rZqG1KRSoYV7AugdJBvk68vsxhURrmb0MLxzM/nC0LPg9v9MemzDIRWDo7C6g xDXS/Cz3VB0lV37c5G9g0BGJeaxFpUsSVnoUxScpBhN2K5ekzK9IZoU7OiL5Yp37Ab/s GSqfGkq2IYTHiNWDTpG/OFQz3A+Cq6tGXk7V9a0a39uAV2ZXK7N62gFCyqfmlgpTdWgl dMqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vZ2zUI0FcmfZpav1YaXRuAg1iVvAVd4GO4V3ktbV8T0=; b=KdFOZR77j6+11Eklp72VJ/i7SE18JekNBUUJbBupXa78GWpRau0SadmArXs5rHE17p Kf5yR3WPywSJQbefKB4HSIDIitBBFzZW9acopsvKxwMzYz0zAyheQy2Js13bNO+oN4R/ nGIRNFJiX9+XI+Ktx7kuUHl20SYND+fS5m7I7Jw88Wh8IdiSrGzKarIUfPGeOyVFWb8K SyAQ/XJgJCwYi0mae5iSZ2Ueef20nptLy7+FiV23mjNWR0KAPCsTwvOgNJrkpag8qT0i 5fDBvtqaH+ZsPgoUfXlvPOcWScZ1a2qZEj9z4Emy3WGK9UjKhwVM+XdZeiume2ShQiUW XyNA== X-Gm-Message-State: AMCzsaVs4V3kzAR/M0UXxTTOmIMiCP4GDoYzxq8pTLpoWu+Q/9zKNnEH MMG/he1gwuch1W1/7iI1jsM2lQ== X-Google-Smtp-Source: ABhQp+TYrtbeO0oa20/PuFujN1RGKjFbfArRe5MWZO8RxBXX+YWoXFPM9Ix56aQkrDB7X9h1+ZBDPA== X-Received: by 10.200.43.146 with SMTP id m18mr22065705qtm.99.1509987340842; Mon, 06 Nov 2017 08:55:40 -0800 (PST) Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id g47sm8870293qtk.37.2017.11.06.08.55.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 08:55:39 -0800 (PST) From: Jonathan Lennox Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_067F951E-7F50-438C-832B-E462D4ED66D1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 6 Nov 2017 11:55:39 -0500 In-Reply-To: Cc: mmusic To: Christer Holmberg References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 16:55:43 -0000 --Apple-Mail=_067F951E-7F50-438C-832B-E462D4ED66D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What do you mean by symmetric media? If you mean each side has to send = using the same codec, or even that the answerer has to reflect the = offerer=E2=80=99s codec list verbatim (in the same order), that sounds = like a terrible idea (and I don=E2=80=99t see what it has to do with ICE = or DTLS). If you mean something else, I don=E2=80=99t know what you mean. :-) > On Nov 6, 2017, at 9:03 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > With ICE, DTLS, symmetric RTP etc becoming more common, would anyone = have a problem with mandating symmetric media when using BUNDLE? >=20 > Regards, >=20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_067F951E-7F50-438C-832B-E462D4ED66D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
What do you mean by symmetric media?  If = you mean each side has to send using the same codec, or even that the = answerer has to reflect the offerer=E2=80=99s codec list verbatim (in = the same order), that sounds like a terrible idea (and I don=E2=80=99t = see what it has to do with ICE or DTLS).

If you mean something else, I don=E2=80=99= t know what you mean. :-)

On Nov 6, 2017, at 9:03 AM, = Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

With ICE, DTLS, symmetric RTP etc becoming more common, = would anyone have a problem with mandating symmetric = media when using BUNDLE?

Regards,

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

= --Apple-Mail=_067F951E-7F50-438C-832B-E462D4ED66D1-- From nobody Mon Nov 6 09:03:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C33213FB7D for ; Mon, 6 Nov 2017 09:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 B38GOVOcx-XC for ; Mon, 6 Nov 2017 09:03:42 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797EC13FB36 for ; Mon, 6 Nov 2017 09:03:42 -0800 (PST) X-AuditID: c1b4fb2d-fc3a89c00000268d-50-5a0095ecf867 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.5C.09869.CE5900A5; Mon, 6 Nov 2017 18:03:40 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Mon, 6 Nov 2017 18:03:40 +0100 From: Christer Holmberg To: Jonathan Lennox CC: mmusic Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric media? Thread-Index: AQHTVwgLo+gWRS+bMkmXyKhd/WGGcKMHgVGAgAATAEY= Date: Mon, 6 Nov 2017 17:03:39 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E018BB9ABD374F3DAD384A7AD9D0F092ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdUffNVIYog093tSz2Lz7PbDF1+WMW ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJUx8dpTpoKfshWLtpU2MJ6V7GLk5JAQMJE4 d2YGSxcjF4eQwGFGiWkbW9kgnEWMEpNn3AbKcHCwCVhIdP/TBmkQEdCQuPjsAxuIzSwgIzHj bCMTiC0MVHKj+w0zRI2lxOP9j9khbCuJjrOTwGpYBFQkHtw9BBbnFbCXmLpkEQuILSSQI7Fx wyMwm1PAVmLlnW+sIDajgJjE91NrmCB2iUvcejKfCeJoAYkle84zQ9iiEi8f/2OFqEmWOPh7 KyPEfEGJkzOfsExgFJ6FpH0WkrJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhFZfAEj+ypG 0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwOg5uOW37g7G1a8dDzEKcDAq8fCubmaIEmJNLCuu zD3EKMHBrCTCu10dKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+FCCGB9MSS1OzU1ILUIpgs EwenVAOjcOLFNHGLzMuH1DofT7Jy13Q+NXe7WuJsfTP1eNnba1b0tP8Ut/gY5td3p6Lm+sGs 8GlLhGq3fYw+84LHTc28+37N/UsvTlXdmXto98SVq5tfryl3a+xWWT3FvXCVwnZDp2Nxm0qi T8n/bws1fNK88A+j9UzJV8JH6k50uGyXsI2ac3peRYelEktxRqKhFnNRcSIAjT3tfZoCAAA= Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 17:03:44 -0000 --_000_E018BB9ABD374F3DAD384A7AD9D0F092ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I mean using the same address:port for both sending and receiving data (whe= ther it=92s RTP or something else). Regards, Christer Sent from my iPhone On 6 Nov 2017, at 18.55, Jonathan Lennox > wrote: What do you mean by symmetric media? If you mean each side has to send usi= ng the same codec, or even that the answerer has to reflect the offerer=92s= codec list verbatim (in the same order), that sounds like a terrible idea = (and I don=92t see what it has to do with ICE or DTLS). If you mean something else, I don=92t know what you mean. :-) On Nov 6, 2017, at 9:03 AM, Christer Holmberg > wrote: Hi, With ICE, DTLS, symmetric RTP etc becoming more common, would anyone have a= problem with mandating symmetric media when using BUNDLE? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_E018BB9ABD374F3DAD384A7AD9D0F092ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi,

I mean using the same address:port for both sending and receiving data= (whether it=92s RTP or something else).

Regards,

Christer

Sent from my iPhone

On 6 Nov 2017, at 18.55, Jonathan Lennox <jonathan@vidyo.com> wrote:

What do you mean by symmetric media?  If you mean each= side has to send using the same codec, or even that the answerer has to re= flect the offerer=92s codec list verbatim (in the same order), that sounds = like a terrible idea (and I don=92t see what it has to do with ICE or DTLS).

If you mean something else, I don=92t know what you mean. := -)

On Nov 6, 2017, at 9:03 AM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:

Hi,

With ICE, DTLS, symmetric RTP etc becoming more common, wou= ld anyone have a problem with mandating symmetric me= dia when using BUNDLE?

Regards,

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

--_000_E018BB9ABD374F3DAD384A7AD9D0F092ericssoncom_-- From nobody Mon Nov 6 22:09:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B663D13FBF4 for ; Mon, 6 Nov 2017 22:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cuIU-9ML2zlb for ; Mon, 6 Nov 2017 22:09:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3025F13FAFE for ; Mon, 6 Nov 2017 22:09:26 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSD20957; Tue, 07 Nov 2017 06:09:24 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 7 Nov 2017 06:09:23 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 14:09:20 +0800 From: Roni Even To: Christer Holmberg , Jonathan Lennox CC: mmusic Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric media? Thread-Index: AQHTVyAfSmGrX/Re/kq5ttoeFeQsaaMHDgWAgAFhaOA= Date: Tue, 7 Nov 2017 06:09:20 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD835024DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5A014E14.00C1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 48a0648429bff785fa3244bc2e8c33ea Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 06:09:29 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD835024DGGEMM506MBXchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Symmetric as specified in RFC4961? Roni From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: =E9=E5=ED =E1 06 =F0=E5=E1=EE=E1=F8 2017 19:04 To: Jonathan Lennox Cc: mmusic Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? Hi, I mean using the same address:port for both sending and receiving data (whe= ther it=92s RTP or something else). Regards, Christer Sent from my iPhone On 6 Nov 2017, at 18.55, Jonathan Lennox > wrote: What do you mean by symmetric media? If you mean each side has to send usi= ng the same codec, or even that the answerer has to reflect the offerer=92s= codec list verbatim (in the same order), that sounds like a terrible idea = (and I don=92t see what it has to do with ICE or DTLS). If you mean something else, I don=92t know what you mean. :-) On Nov 6, 2017, at 9:03 AM, Christer Holmberg > wrote: Hi, With ICE, DTLS, symmetric RTP etc becoming more common, would anyone have a= problem with mandating symmetric media when using BUNDLE? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_6E58094ECC8D8344914996DAD28F1CCD835024DGGEMM506MBXchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

Symmetric as specified in= RFC4961?

Roni

 <= /p>

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: =E9=E5=ED =E1 06 =F0=E5=E1=EE=E1=F8 2017 19:04
To: Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media?<= /span>

 

Hi,

 

I mean using the same address:port for both sending = and receiving data (whether it=92s RTP or something else).

 

Regards,

 

Christer

Sent from my iPhone


On 6 Nov 2017, at 18.55, Jonathan Lennox <jonathan@vidyo.com> wrote:

What do you mean by symmetric media?  If you me= an each side has to send using the same codec, or even that the answerer ha= s to reflect the offerer=92s codec list verbatim (in the same order), that = sounds like a terrible idea (and I don=92t see what it has to do with ICE or DTLS).

 

If you mean something else, I don=92t know what you = mean. :-)

 

On Nov 6, 2017, at 9:03 AM, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

 

Hi,

 

With ICE, DTLS, symmetric RTP etc becom= ing more common, would anyone have a problem with mandating symmetric media when using BUNDLE?

 

Regards,

 

Christer

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

 

--_000_6E58094ECC8D8344914996DAD28F1CCD835024DGGEMM506MBXchina_-- From nobody Mon Nov 6 23:17:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC72613FC05 for ; Mon, 6 Nov 2017 23:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nsODA_dgWx9M for ; Mon, 6 Nov 2017 23:17:20 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0911E13FBFD for ; Mon, 6 Nov 2017 23:17:19 -0800 (PST) X-AuditID: c1b4fb30-b48ed9c000007d10-6c-5a015dfda511 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 22.55.32016.DFD510A5; Tue, 7 Nov 2017 08:17:18 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Tue, 7 Nov 2017 08:17:17 +0100 From: Christer Holmberg To: Roni Even CC: Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric media? Thread-Index: AQHTVwgLo+gWRS+bMkmXyKhd/WGGcKMHgVGAgAATAEaAAMrBAIAAI8Ci Date: Tue, 7 Nov 2017 07:17:17 +0000 Message-ID: References: , , <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A5B9B718D9A44D90BFD853034EA40532ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7se6/WMYog+n/eSz2Lz7PbDF1+WMW i0/HzrM4MHu0HHnL6rFkyU8mj7Znd9gDmKO4bFJSczLLUov07RK4MlYe3sVacNajYuLCTuYG xu/2XYycHBICJhK3/y1n6mLk4hASOMwo8fLWfShnEaPEnKa5bF2MHBxsAhYS3f+0QRpEBFQk Dp1fwwxiMws4SfzZeY8JxBYGKrnR/YYZosZS4vH+x+wQtptEy687bCA2C1DvszUTWEBG8grY S2x7Igex6i2jxIHevSwgNZwCIRL9zXdZQWxGATGJ76fWMEHsEpe49WQ+E8TRAhJL9pxnhrBF JV4+/scKMpNZIFni4T6wVbwCghInZz5hmcAoPAtJ9yyEqllIqiBKDCTObd/IDmFrSyxb+JoZ wtaX2H57Jiuy+AJG9lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgfF0cMtvgx2ML587HmIU 4GBU4uGd7sYYJcSaWFZcmXuIUYKDWUmEd7s6Q5QQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9 FyKEBNITS1KzU1MLUotgskwcnFINjFx66v4zSnOuRt3+u5GX1ypgoelxN2/p08p59g2lKko9 e8z36FqV/Zu/6ddDrTWc846VFuxJPXuea8u37ubJMzRMoud757Setd4kKHHubE/U/n27f31f z6Gf8+SVSf+hh5XP9G61VzctOypUP08hSVzjustVnW4lT2ZrhhW/nX9HWNWKrzUtUmIpzkg0 1GIuKk4EAOAQrgWjAgAA Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 07:17:22 -0000 --_000_A5B9B718D9A44D90BFD853034EA40532ericssoncom_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Symmetric as in sending and receiving using the same local address:port, i.= e., using the same transport/5-tuple in both directions. For RTP-based data, that would be 4961, yes. Regards, Christer Sent from my iPhone On 7 Nov 2017, at 8.09, Roni Even > wrote: Hi, Symmetric as specified in RFC4961? Roni From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: =E9=E5=ED =E1 06 =F0=E5=E1=EE=E1=F8 2017 19:04 To: Jonathan Lennox Cc: mmusic Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? Hi, I mean using the same address:port for both sending and receiving data (whe= ther it=92s RTP or something else). Regards, Christer Sent from my iPhone On 6 Nov 2017, at 18.55, Jonathan Lennox > wrote: What do you mean by symmetric media? If you mean each side has to send usi= ng the same codec, or even that the answerer has to reflect the offerer=92s= codec list verbatim (in the same order), that sounds like a terrible idea = (and I don=92t see what it has to do with ICE or DTLS). If you mean something else, I don=92t know what you mean. :-) On Nov 6, 2017, at 9:03 AM, Christer Holmberg > wrote: Hi, With ICE, DTLS, symmetric RTP etc becoming more common, would anyone have a= problem with mandating symmetric media when using BUNDLE? Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_A5B9B718D9A44D90BFD853034EA40532ericssoncom_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi,

Symmetric as in sending and receiving using the same local address:por= t, i.e., using the same transport/5-tuple in both directions.

For RTP-based data,  that would be 4961, yes.

Regards,

Christer 

Sent from my iPhone

On 7 Nov 2017, at 8.09, Roni Even <roni.even@huawei.com> wrote:

Hi,

Symmetric as specified in= RFC4961?

Roni

 <= /p>

 

Hi,

 

I mean using the same address:port for both sending = and receiving data (whether it=92s RTP or something else).

 

Regards,

 

Christer

Sent from my iPhone

What do you mean by symmetric media?  If you me= an each side has to send using the same codec, or even that the answerer ha= s to reflect the offerer=92s codec list verbatim (in the same order), that = sounds like a terrible idea (and I don=92t see what it has to do with ICE or DTLS).

 

If you mean something else, I don=92t know what you = mean. :-)

 

On Nov 6, 2017, at 9:03 AM, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

 

Hi,

 

With ICE, DTLS, symmetric RTP etc becom= ing more common, would anyone have a problem with mandating symmetric media when using BUNDLE?

 

Regards,

 

Christer

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

 

--_000_A5B9B718D9A44D90BFD853034EA40532ericssoncom_-- From nobody Tue Nov 7 02:34:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06A713FD8A for ; Tue, 7 Nov 2017 02:34:16 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jmqbjdAY-P2F for ; Tue, 7 Nov 2017 02:34:14 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8978E13FD82 for ; Tue, 7 Nov 2017 02:34:13 -0800 (PST) Received: from [130.209.247.112] (port=59302 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eC1Cm-00034u-KJ; Tue, 07 Nov 2017 10:34:09 +0000 From: Colin Perkins Message-Id: <57848637-B007-4167-8868-18F0876384A0@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_E78A3C80-5C00-49FF-8D1D-7A1222CE3F61" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 7 Nov 2017 10:33:55 +0000 In-Reply-To: Cc: Roni Even , Jonathan Lennox , mmusic To: Christer Holmberg References: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 24 Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 10:34:17 -0000 --Apple-Mail=_E78A3C80-5C00-49FF-8D1D-7A1222CE3F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Section 4.7 of draft-ietf-rtcweb-rtp-usage already mandates this for = WebRTC endpoints, which are probably the major users of BUNDLE. Colin > On 7 Nov 2017, at 07:17, Christer Holmberg = wrote: >=20 > Hi, >=20 > Symmetric as in sending and receiving using the same local = address:port, i.e., using the same transport/5-tuple in both directions. >=20 > For RTP-based data, that would be 4961, yes. >=20 > Regards, >=20 > Christer=20 >=20 > Sent from my iPhone >=20 > On 7 Nov 2017, at 8.09, Roni Even > wrote: >=20 >> Hi, >> Symmetric as specified in RFC4961? >> Roni >> =20 >> From: mmusic [mailto:mmusic-bounces@ietf.org = ] On Behalf Of Christer Holmberg >> Sent: =D7=99=D7=95=D7=9D =D7=91 06 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 19:04 >> To: Jonathan Lennox >> Cc: mmusic >> Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? >> =20 >> Hi,=20 >> =20 >> I mean using the same address:port for both sending and receiving = data (whether it=E2=80=99s RTP or something else). >> =20 >> Regards, >> =20 >> Christer >>=20 >> Sent from my iPhone >>=20 >> On 6 Nov 2017, at 18.55, Jonathan Lennox > wrote: >>=20 >> What do you mean by symmetric media? If you mean each side has to = send using the same codec, or even that the answerer has to reflect the = offerer=E2=80=99s codec list verbatim (in the same order), that sounds = like a terrible idea (and I don=E2=80=99t see what it has to do with ICE = or DTLS). >> =20 >> If you mean something else, I don=E2=80=99t know what you mean. :-) >> =20 >> On Nov 6, 2017, at 9:03 AM, Christer Holmberg = > = wrote: >> =20 >> Hi, >> =20 >> With ICE, DTLS, symmetric RTP etc becoming more common, would anyone = have a problem with mandating symmetric media when using BUNDLE? >> =20 >> Regards, >> =20 >> Christer >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic = >> =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_E78A3C80-5C00-49FF-8D1D-7A1222CE3F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Section= 4.7 of draft-ietf-rtcweb-rtp-usage already mandates this for WebRTC = endpoints, which are probably the major users of BUNDLE.

Colin



On 7 Nov 2017, at 07:17, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
Symmetric as in sending and = receiving using the same local address:port, i.e., using the same = transport/5-tuple in both directions.

For RTP-based data, =  that would be 4961, yes.

Regards,
Christer 
Sent from my iPhone

On 7 Nov 2017, at 8.09, Roni Even <roni.even@huawei.com> = wrote:

Hi,
Symmetric as specified in RFC4961?
Roni
 
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: =D7=99=D7=95=D7=9D =D7=91 06 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 19:04
To: Jonathan Lennox
Cc: mmusic
Subject: Re: [MMUSIC] BUNDLE: = Mandating symmetric media?
 
Hi, 
 
I mean using the same address:port for = both sending and receiving data (whether it=E2=80=99s RTP or something = else).
 
Regards,
 

Christer

Sent from my iPhone


On 6 Nov 2017, at 18.55, Jonathan Lennox = <jonathan@vidyo.com> = wrote:

What do you mean by symmetric media? =  If you mean each side has to send using the same codec, or even = that the answerer has to reflect the offerer=E2=80=99s codec list = verbatim (in the same order), that sounds like a terrible idea (and I = don=E2=80=99t see what it has to do with ICE or DTLS).
 
If you mean something else, I don=E2=80=99t= know what you mean. :-)
 
On = Nov 6, 2017, at 9:03 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
 
Hi,
 
With ICE, DTLS, symmetric RTP etc becoming more common, would = anyone have a problem with mandating symmetric media when using = BUNDLE?
 
Regards,
 
Christer
_______________________________________________
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



-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_E78A3C80-5C00-49FF-8D1D-7A1222CE3F61-- From nobody Tue Nov 7 02:42:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BFD13FD5F for ; Tue, 7 Nov 2017 02:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PB8b_RFsOLxF for ; Tue, 7 Nov 2017 02:42:30 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6872413FBCE for ; Tue, 7 Nov 2017 02:42:29 -0800 (PST) X-AuditID: c1b4fb30-b48ed9c000007d10-0d-5a018e13b1f9 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.C0.32016.31E810A5; Tue, 7 Nov 2017 11:42:27 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 7 Nov 2017 11:42:23 +0100 From: Christer Holmberg To: Colin Perkins CC: Roni Even , Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric media? Thread-Index: AQHTVwgLo+gWRS+bMkmXyKhd/WGGcKMHgVGAgAATAEaAAMrBAIAAI8CigAAmLYCAABVAgA== Date: Tue, 7 Nov 2017 10:42:22 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> <57848637-B007-4167-8868-18F0876384A0@csperkins.org> In-Reply-To: <57848637-B007-4167-8868-18F0876384A0@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D6275C0D25DBCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2J7uK5wH2OUwZkmEYvlL08wWuxffJ7Z YuryxywWn46dZ3Fg8Zh2/z6bR8uRt6weS5b8ZPJoe3aHPYAlissmJTUnsyy1SN8ugSvjz9o3 bAUzrjBW/Dl1g7WB8eQ5xi5GTg4JAROJ1jPf2bsYuTiEBA4zSkw+/pgVwlnEKPHkzxugDAcH m4CFRPc/bZAGEQFViR3H/4E1MwukSdw9/BzMFgYqudH9hhmixlLi8f7HYK0iAmESq3/WgYRZ BFQkVjyHaOUVsJZ4cOM11N7bTBKTtk5jA0lwCjhKLJt+hwXEZhQQk/h+ag0TxC5xiVtP5jNB HC0gsWTPeWYIW1Ti5eN/rCC2qICexIYTt9kh4ooSO8+2M0P0JkicuPKTHWKxoMTJmU9YJjCK zkIydhaSsllIymYBvcAsoCmxfpc+RImixJTuh+wQtoZE65y5ULa1xK7tV5iQ1Sxg5FjFKFqc WpyUm25kpJdalJlcXJyfp5eXWrKJERixB7f8NtjB+PK54yFGAQ5GJR5esVTGKCHWxLLiytxD jBIczEoivNvVGaKEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi 4JRqYJwxb1d4zp26ySx8jFL1JxONAhcvmsbCeefqnKYlkxQTf0znibH1tXg3acVyp41/V3dm aySxsn1i8Ez2zBcv+XzroojzxLwGx945HYt2PFjWcel+rsROuSVRCX4s68TScp7O2CCo6n6g 1/FbvYavz8Tbxtcc1pzUnpDqVlcRtG/GwkNHNva2/lNiKc5INNRiLipOBADZ2KWq1AIAAA== Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 10:42:33 -0000 --_000_D6275C0D25DBCchristerholmbergericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5TZWN0aW9uIDQuNyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UgYWxyZWFk eSBtYW5kYXRlcyB0aGlzIGZvciBXZWJSVEMgZW5kcG9pbnRzLCB3aGljaCBhcmUgcHJvYmFibHkg dGhlIG1ham9yIHVzZXJzIG9mIEJVTkRMRS4NCg0KQ29ycmVjdC4gQW5kLCB0aGUgZGF0YSBjaGFu bmVsIHdpbGwgYWx3YXlzIGJlIHN5bW1ldHJpYyBieSBkZXNpZ24uDQoNCkNvbGluLCBhcyBzb21l b25lIHdobyBoYXMgZ29vZCBpbnNpZ2h0IGluIHRoZSB3b3JsZCBvZiBSVFAsIGRvIHlvdSBzZWUg YW55IGdlbmVyYWwgKG91dHNpZGUgb2YgV2ViUlRDKSBpc3N1ZXMgd2l0aCBtYW5kYXRpbmcgc3lt bWV0cmljPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQpPbiA3IE5vdiAyMDE3LCBh dCAwNzoxNywgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpLA0K DQpTeW1tZXRyaWMgYXMgaW4gc2VuZGluZyBhbmQgcmVjZWl2aW5nIHVzaW5nIHRoZSBzYW1lIGxv Y2FsIGFkZHJlc3M6cG9ydCwgaS5lLiwgdXNpbmcgdGhlIHNhbWUgdHJhbnNwb3J0LzUtdHVwbGUg aW4gYm90aCBkaXJlY3Rpb25zLg0KDQpGb3IgUlRQLWJhc2VkIGRhdGEsICB0aGF0IHdvdWxkIGJl IDQ5NjEsIHllcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IGlQaG9u ZQ0KDQpPbiA3IE5vdiAyMDE3LCBhdCA4LjA5LCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWku Y29tPG1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSwNClN5bW1ldHJp YyBhcyBzcGVjaWZpZWQgaW4gUkZDNDk2MT8NClJvbmkNCg0KRnJvbTogbW11c2ljIFttYWlsdG86 bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0K U2VudDog15nXldedINeRIDA2INeg15XXkdee15HXqCAyMDE3IDE5OjA0DQpUbzogSm9uYXRoYW4g TGVubm94DQpDYzogbW11c2ljDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gQlVORExFOiBNYW5kYXRp bmcgc3ltbWV0cmljIG1lZGlhPw0KDQpIaSwNCg0KSSBtZWFuIHVzaW5nIHRoZSBzYW1lIGFkZHJl c3M6cG9ydCBmb3IgYm90aCBzZW5kaW5nIGFuZCByZWNlaXZpbmcgZGF0YSAod2hldGhlciBpdOKA mXMgUlRQIG9yIHNvbWV0aGluZyBlbHNlKS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINClNlbnQg ZnJvbSBteSBpUGhvbmUNCg0KT24gNiBOb3YgMjAxNywgYXQgMTguNTUsIEpvbmF0aGFuIExlbm5v eCA8am9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToN CldoYXQgZG8geW91IG1lYW4gYnkgc3ltbWV0cmljIG1lZGlhPyAgSWYgeW91IG1lYW4gZWFjaCBz aWRlIGhhcyB0byBzZW5kIHVzaW5nIHRoZSBzYW1lIGNvZGVjLCBvciBldmVuIHRoYXQgdGhlIGFu c3dlcmVyIGhhcyB0byByZWZsZWN0IHRoZSBvZmZlcmVy4oCZcyBjb2RlYyBsaXN0IHZlcmJhdGlt IChpbiB0aGUgc2FtZSBvcmRlciksIHRoYXQgc291bmRzIGxpa2UgYSB0ZXJyaWJsZSBpZGVhIChh bmQgSSBkb27igJl0IHNlZSB3aGF0IGl0IGhhcyB0byBkbyB3aXRoIElDRSBvciBEVExTKS4NCg0K SWYgeW91IG1lYW4gc29tZXRoaW5nIGVsc2UsIEkgZG9u4oCZdCBrbm93IHdoYXQgeW91IG1lYW4u IDotKQ0KDQpPbiBOb3YgNiwgMjAxNywgYXQgOTowMyBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpXaXRoIElDRSwgRFRMUywgc3ltbWV0cmljIFJU UCBldGMgYmVjb21pbmcgbW9yZSBjb21tb24sIHdvdWxkIGFueW9uZSBoYXZlIGEgcHJvYmxlbSB3 aXRoIG1hbmRhdGluZyBzeW1tZXRyaWMgbWVkaWEgd2hlbiB1c2luZyBCVU5ETEU/DQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp Yw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11 c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCg0KLS0N CkNvbGluIFBlcmtpbnMNCmh0dHBzOi8vY3NwZXJraW5zLm9yZy8NCg0KDQoNCg0K --_000_D6275C0D25DBCchristerholmbergericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <2710D801516BA14B9D587EBF3A9AA3AA@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSw8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRp dj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPiZndDtTZWN0aW9uIDQuNyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAt dXNhZ2UgYWxyZWFkeSBtYW5kYXRlcyB0aGlzIGZvciBXZWJSVEMgZW5kcG9pbnRzLCB3aGljaCBh cmUgcHJvYmFibHkgdGhlIG1ham9yIHVzZXJzIG9mIEJVTkRMRS48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Db3JyZWN0LiBBbmQsIHRoZSBk YXRhIGNoYW5uZWwgd2lsbCBhbHdheXMgYmUgc3ltbWV0cmljIGJ5IGRlc2lnbi48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNvbGluLCBhcyBzb21lb25lIHdobyBoYXMgZ29vZCBpbnNp Z2h0IGluIHRoZSB3b3JsZCBvZiBSVFAsIGRvIHlvdSBzZWUgYW55IGdlbmVyYWwgKG91dHNpZGUg b2YgV2ViUlRDKSBpc3N1ZXMgd2l0aCBtYW5kYXRpbmcgc3ltbWV0cmljPzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PkNocmlzdGVyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gNyBOb3YgMjAx NywgYXQgMDc6MTcsIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5IaSw8L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTBweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NClN5 bW1ldHJpYyBhcyBpbiBzZW5kaW5nIGFuZCByZWNlaXZpbmcgdXNpbmcgdGhlIHNhbWUgbG9jYWwg YWRkcmVzczpwb3J0LCBpLmUuLCB1c2luZyB0aGUgc2FtZSB0cmFuc3BvcnQvNS10dXBsZSBpbiBi b3RoIGRpcmVjdGlvbnMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTBweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCkZvciBS VFAtYmFzZWQgZGF0YSwgJm5ic3A7dGhhdCB3b3VsZCBiZSA0OTYxLCB5ZXMuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEwcHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTBweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NClJlZ2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTBweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCkNocmlzdGVyJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KT24gNyBOb3YgMjAxNywgYXQgOC4wOSwgUm9uaSBFdmVuICZsdDs8YSBocmVmPSJt YWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnJvbmkuZXZlbkBodWF3ZWkuY29tPC9hPiZn dDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7Ij4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IiBjbGFzcz0iIj5IaSw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5TeW1tZXRyaWMgYXMgc3BlY2lmaWVkIGlu IFJGQzQ5NjE/PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+Um9uaTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUg bm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBib3JkZXItbGVmdC1jb2xvcjog Ymx1ZTsgcGFkZGluZzogMGNtIDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3At d2lkdGg6IDFwdDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBwYWRkaW5n OiAzcHQgMGNtIDBjbTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw cHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5tbXVzaWMgWzxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRm Lm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+T24NCiBCZWhh bGYgT2Y8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9i PkNocmlzdGVyIEhvbG1iZXJnPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkhFIiBkaXI9IlJUTCIgY2xhc3M9IiI+15nXldedPC9zcGFuPjxzcGFuIGRpcj0iTFRSIiBjbGFz cz0iIj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiIGNsYXNzPSIiPjwvc3Bhbj4mbmJzcDs8c3BhbiBs YW5nPSJIRSIgZGlyPSJSVEwiIGNsYXNzPSIiPteRPC9zcGFuPjxzcGFuIGRpcj0iTFRSIiBjbGFz cz0iIj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiIGNsYXNzPSIiPjwvc3Bhbj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MDY8c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIiBj bGFzcz0iIj7XoNeV15HXnteR16g8L3NwYW4+PHNwYW4gZGlyPSJMVFIiIGNsYXNzPSIiPjwvc3Bh bj48c3BhbiBkaXI9IkxUUiIgY2xhc3M9IiI+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4yMDE3DQogMTk6MDQ8YnIgY2xhc3M9IiI+DQo8YiBj bGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkpvbmF0aGFuIExlbm5veDxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bW11c2ljPGJy IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbTU1VU0lDXSBCVU5ETEU6IE1hbmRhdGlu ZyBzeW1tZXRyaWMgbWVkaWE/PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSGksPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSSBt ZWFuIHVzaW5nIHRoZSBzYW1lIGFkZHJlc3M6cG9ydCBmb3IgYm90aCBzZW5kaW5nIGFuZCByZWNl aXZpbmcgZGF0YSAod2hldGhlciBpdOKAmXMgUlRQIG9yIHNvbWV0aGluZyBlbHNlKS48bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KUmVnYXJkcyw8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiPg0KQ2hyaXN0ZXI8bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPGJyIGNsYXNzPSIiPg0KT24gNiBOb3YgMjAxNywgYXQgMTguNTUsIEpv bmF0aGFuIExlbm5veCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ am9uYXRoYW5AdmlkeW8uY29tPC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0 b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KV2hhdCBkbyB5b3Ug bWVhbiBieSBzeW1tZXRyaWMgbWVkaWE/ICZuYnNwO0lmIHlvdSBtZWFuIGVhY2ggc2lkZSBoYXMg dG8gc2VuZCB1c2luZyB0aGUgc2FtZSBjb2RlYywgb3IgZXZlbiB0aGF0IHRoZSBhbnN3ZXJlciBo YXMgdG8gcmVmbGVjdCB0aGUgb2ZmZXJlcuKAmXMgY29kZWMgbGlzdCB2ZXJiYXRpbSAoaW4gdGhl IHNhbWUgb3JkZXIpLCB0aGF0IHNvdW5kcyBsaWtlIGEgdGVycmlibGUgaWRlYSAoYW5kIEkgZG9u 4oCZdCBzZWUgd2hhdCBpdCBoYXMgdG8gZG8NCiB3aXRoIElDRSBvciBEVExTKS48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSWYgeW91IG1lYW4gc29tZXRoaW5nIGVsc2UsIEkg ZG9u4oCZdCBrbm93IHdoYXQgeW91IG1lYW4uIDotKTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQpPbiBOb3YgNiwgMjAxNywgYXQgOTowMyBBTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIi PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5IaSw8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPldpdGggSUNFLCBEVExTLCBzeW1tZXRyaWMg UlRQIGV0YyBiZWNvbWluZyBtb3JlIGNvbW1vbiwgd291bGQgYW55b25lIGhhdmUgYSBwcm9ibGVt IHdpdGg8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIg Y2xhc3M9IiI+bWFuZGF0aW5nPC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5zeW1tZXRyaWMNCiBtZWRpYSB3aGVuIHVzaW5nIEJVTkRMRT88bzpwIGNs YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPlJlZ2FyZHMsPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj5DaHJpc3RlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFz cz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86 bW11c2ljQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+bW11c2ljDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTBweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmci IGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljPC9hPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQotLSZuYnNwOzxiciBjbGFzcz0iIj4NCkNvbGluIFBlcmtpbnM8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJodHRwczovL2NzcGVya2lucy5vcmcvIiBjbGFzcz0iIj5odHRwczovL2NzcGVya2lu cy5vcmcvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D6275C0D25DBCchristerholmbergericssoncom_-- From nobody Tue Nov 7 02:45:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFA513FD8E for ; Tue, 7 Nov 2017 02:45:21 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eR1RqUn7gd6v for ; Tue, 7 Nov 2017 02:45:20 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A7813FD8F for ; Tue, 7 Nov 2017 02:45:11 -0800 (PST) Received: from [130.209.247.112] (port=59673 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eC1NR-0004Gy-Vb; Tue, 07 Nov 2017 10:45:06 +0000 From: Colin Perkins Message-Id: <26AA3D0B-857E-4BF3-BF92-045B7517A858@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_71F0DEF7-4D8D-429D-BC69-9BB7C1CD2A05" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 7 Nov 2017 10:45:02 +0000 In-Reply-To: Cc: Roni Even , Jonathan Lennox , mmusic To: Christer Holmberg References: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> <57848637-B007-4167-8868-18F0876384A0@csperkins.org> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 10:45:22 -0000 --Apple-Mail=_71F0DEF7-4D8D-429D-BC69-9BB7C1CD2A05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Nov 2017, at 10:42, Christer Holmberg = wrote: >=20 > Hi, >=20 > >Section 4.7 of draft-ietf-rtcweb-rtp-usage already mandates this for = WebRTC endpoints, which are probably the major users of BUNDLE. >=20 > Correct. And, the data channel will always be symmetric by design. >=20 > Colin, as someone who has good insight in the world of RTP, do you see = any general (outside of WebRTC) issues with mandating symmetric? No issues that I know of. I think it=E2=80=99s a good idea, and needed = for NAT traversal in many cases. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_71F0DEF7-4D8D-429D-BC69-9BB7C1CD2A05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 7 Nov 2017, at 10:42, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

>Section 4.7 of draft-ietf-rtcweb-rtp-usage already = mandates this for WebRTC endpoints, which are probably the major users = of BUNDLE.

Correct. And, the data channel will always be symmetric = by design.

Colin, as someone who has good insight in the world of = RTP, do you see any general (outside of WebRTC) issues with mandating = symmetric?

No issues that I know of. I think it=E2=80=99s a good idea, and needed = for NAT traversal in many cases.

-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_71F0DEF7-4D8D-429D-BC69-9BB7C1CD2A05-- From nobody Tue Nov 7 07:20:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61B413FF05 for ; Tue, 7 Nov 2017 07:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 R1Ehaz3hJxQC for ; Tue, 7 Nov 2017 07:20:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DC975A97 for ; Tue, 7 Nov 2017 07:13:37 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZI97285; Tue, 07 Nov 2017 15:13:35 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 7 Nov 2017 15:13:33 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 23:13:29 +0800 From: Roni Even To: Colin Perkins , Christer Holmberg CC: Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric media? Thread-Index: AQHTV7V/G/5wYghxAEaIPhqNXOqljqMJBjsQ Date: Tue, 7 Nov 2017 15:13:28 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD835304@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> <57848637-B007-4167-8868-18F0876384A0@csperkins.org> <26AA3D0B-857E-4BF3-BF92-045B7517A858@csperkins.org> In-Reply-To: <26AA3D0B-857E-4BF3-BF92-045B7517A858@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD835304DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5A01CDA0.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 090ebbbf5c66fed1c7dff28b31a4708a Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 15:20:55 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD835304DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBDb2xsaW4gdmlldw0KUm9uaQ0KDQpGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86 Y3NwQGNzcGVya2lucy5vcmddDQpTZW50OiDXmdeV150g15IgMDcg16DXldeR157XkdeoIDIwMTcg MTI6NDUNClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IFJvbmkgRXZlbjsgSm9uYXRoYW4gTGVu bm94OyBtbXVzaWMNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBCVU5ETEU6IE1hbmRhdGluZyBzeW1t ZXRyaWMgbWVkaWE/DQoNCk9uIDcgTm92IDIwMTcsIGF0IDEwOjQyLCBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGksDQoNCj5TZWN0aW9uIDQuNyBvZiBkcmFmdC1p ZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UgYWxyZWFkeSBtYW5kYXRlcyB0aGlzIGZvciBXZWJSVEMgZW5k cG9pbnRzLCB3aGljaCBhcmUgcHJvYmFibHkgdGhlIG1ham9yIHVzZXJzIG9mIEJVTkRMRS4NCg0K Q29ycmVjdC4gQW5kLCB0aGUgZGF0YSBjaGFubmVsIHdpbGwgYWx3YXlzIGJlIHN5bW1ldHJpYyBi eSBkZXNpZ24uDQoNCkNvbGluLCBhcyBzb21lb25lIHdobyBoYXMgZ29vZCBpbnNpZ2h0IGluIHRo ZSB3b3JsZCBvZiBSVFAsIGRvIHlvdSBzZWUgYW55IGdlbmVyYWwgKG91dHNpZGUgb2YgV2ViUlRD KSBpc3N1ZXMgd2l0aCBtYW5kYXRpbmcgc3ltbWV0cmljPw0KDQpObyBpc3N1ZXMgdGhhdCBJIGtu b3cgb2YuIEkgdGhpbmsgaXTigJlzIGEgZ29vZCBpZGVhLCBhbmQgbmVlZGVkIGZvciBOQVQgdHJh dmVyc2FsIGluIG1hbnkgY2FzZXMuDQoNCi0tDQpDb2xpbiBQZXJraW5zDQpodHRwczovL2NzcGVy a2lucy5vcmcvDQoNCg0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD835304DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1cHBvcnQgQ29sbGluIHZpZXc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9uaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmdd DQo8YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV150mbmJz cDvXkiAwNyDXoNeV15HXnteR16ggMjAxNyAxMjo0NTwvc3Bhbj48YnI+DQo8Yj5Ubzo8L2I+IENo cmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBSb25pIEV2ZW47IEpvbmF0aGFuIExlbm5v eDsgbW11c2ljPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBCVU5ETEU6IE1hbmRh dGluZyBzeW1tZXRyaWMgbWVkaWE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDcgTm92IDIwMTcsIGF0IDEwOjQyLCBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7 U2VjdGlvbiA0Ljcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlIGFscmVhZHkgbWFuZGF0 ZXMgdGhpcyBmb3IgV2ViUlRDIGVuZHBvaW50cywgd2hpY2ggYXJlIHByb2JhYmx5IHRoZSBtYWpv ciB1c2VycyBvZiBCVU5ETEUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db3JyZWN0LiBB bmQsIHRoZSBkYXRhIGNoYW5uZWwgd2lsbCBhbHdheXMgYmUgc3ltbWV0cmljIGJ5IGRlc2lnbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Q29saW4sIGFzIHNvbWVvbmUgd2hvIGhhcyBnb29kIGluc2lnaHQgaW4gdGhl IHdvcmxkIG9mIFJUUCwgZG8geW91IHNlZSBhbnkgZ2VuZXJhbCAob3V0c2lkZSBvZiBXZWJSVEMp IGlzc3VlcyB3aXRoIG1hbmRhdGluZyBzeW1tZXRyaWM/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk5vIGlzc3VlcyB0aGF0IEkga25vdyBv Zi4gSSB0aGluayBpdOKAmXMgYSBnb29kIGlkZWEsIGFuZCBuZWVkZWQgZm9yIE5BVCB0cmF2ZXJz YWwgaW4gbWFueSBjYXNlcy48YnI+DQo8YnI+DQotLSZuYnNwOzxicj4NCkNvbGluIFBlcmtpbnM8 YnI+DQo8YSBocmVmPSJodHRwczovL2NzcGVya2lucy5vcmcvIj5odHRwczovL2NzcGVya2lucy5v cmcvPC9hPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD835304DGGEMM506MBXchina_-- From nobody Tue Nov 7 11:32:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F84126BF3 for ; Tue, 7 Nov 2017 11:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 Ic4iyxP5l9ff for ; Tue, 7 Nov 2017 11:32:16 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099C412421A for ; Tue, 7 Nov 2017 11:32:15 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id k7so251211pga.3 for ; Tue, 07 Nov 2017 11:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xqbBSZhwCFW0LSmtYggPRuKEms+cjCjRc6ez4KJHRgM=; b=xbOyHjiw9jyGDAIi5KdnBJsR7eqImmLw3tu44i/82u6tdHTOR2Eg646f64MC8bLnCm xAsquxSOb+bIDsmZGe+kjegisIHzfmx3TknfBoaVox6fTZWyZ0NB/vlWlVuGr0CQzVoZ Bo1VgoP1hk+D8k7wftWMExawDpQMPZZ7aFVcUDBC6NFyUOPlIFE1BQSn5Eccc1q7lRFv wcVB9T7FaRMZhZmvKTvsFImhf+5pQ17hXTtIMxtfEambJ13PnbGakberrktbej8Sr8b7 VtibOJrooCSJLrBPRKDuohN8KVGgfo7T0rN9EZYXhc1mq7ryXaLcHtI+JfWUUzROE5X2 eE0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xqbBSZhwCFW0LSmtYggPRuKEms+cjCjRc6ez4KJHRgM=; b=ET09WV5miasMWG+qLSZC4cMGGLFGb5ZH391KrtJn0Db+xEpfOTT0tVa037lWzEsRMA EvhB9LfVuPM6J3xf1TZW0yOW3wxpMwYFYrErCXSl4XXlgDZ/1j2BYtC5EWySrcMFir0L 9x9/f/PzX4Ty4IntguN5wMFLMmU3lY1ZNwR3mAY+wRoGOzUIdRrEVrjNhZ462Ui8pCXd LIz7sVIdpvmmZztp/BXOxQLflLg2zAUCXOTDY0kyw9bOGx+DXQq7JUiD7mEa95GbTQiD UF8nMful6d+ilWYtcRHyGQbMkcmhRrItePt5WVeqKfXWg5dCklW+H+JsI21NFhiXw2go VEXw== X-Gm-Message-State: AMCzsaXfH5hiI2ajTWHOP/LRz1jwbbtoPtiwrzg/Uy/m+qOlKiegw2wB s4anAs7iBIwIuHGk20RfFfd50gPg X-Google-Smtp-Source: ABhQp+TpWvCay8kJ9pHrsANNfZgs79pYRnzyT/3uDHqPhWULkEnrdWBsl2rku1e8hFstCFDPiq91iQ== X-Received: by 10.99.176.6 with SMTP id h6mr19502048pgf.358.1510083135351; Tue, 07 Nov 2017 11:32:15 -0800 (PST) Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com. [74.125.83.43]) by smtp.gmail.com with ESMTPSA id r18sm3523603pge.87.2017.11.07.11.32.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 11:32:14 -0800 (PST) Received: by mail-pg0-f43.google.com with SMTP id m18so227169pgd.13 for ; Tue, 07 Nov 2017 11:32:14 -0800 (PST) X-Received: by 10.84.200.39 with SMTP id s36mr10323355pld.9.1510083134184; Tue, 07 Nov 2017 11:32:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.128.131 with HTTP; Tue, 7 Nov 2017 11:32:13 -0800 (PST) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD835304@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> <57848637-B007-4167-8868-18F0876384A0@csperkins.org> <26AA3D0B-857E-4BF3-BF92-045B7517A858@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD835304@DGGEMM506-MBX.china.huawei.com> From: Roman Shpount Date: Tue, 7 Nov 2017 14:32:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Roni Even Cc: Colin Perkins , Christer Holmberg , Jonathan Lennox , mmusic Content-Type: multipart/alternative; boundary="94eb2c145ce4cb6281055d69a08a" Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 19:32:18 -0000 --94eb2c145ce4cb6281055d69a08a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree. Make it symmetric. _____________ Roman Shpount On Tue, Nov 7, 2017 at 10:13 AM, Roni Even wrote: > Support Collin view > > Roni > > > > *From:* Colin Perkins [mailto:csp@csperkins.org] > *Sent:* =D7=99=D7=95=D7=9D =D7=92 07 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 12:45 > *To:* Christer Holmberg > *Cc:* Roni Even; Jonathan Lennox; mmusic > *Subject:* Re: [MMUSIC] BUNDLE: Mandating symmetric media? > > > > On 7 Nov 2017, at 10:42, Christer Holmberg > wrote: > > > > Hi, > > > > >Section 4.7 of draft-ietf-rtcweb-rtp-usage already mandates this for > WebRTC endpoints, which are probably the major users of BUNDLE. > > > > Correct. And, the data channel will always be symmetric by design. > > > > Colin, as someone who has good insight in the world of RTP, do you see an= y > general (outside of WebRTC) issues with mandating symmetric? > > > > No issues that I know of. I think it=E2=80=99s a good idea, and needed fo= r NAT > traversal in many cases. > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c145ce4cb6281055d69a08a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree. Make it symmetric.

_____________
Roman Shpount

On Tue, Nov 7, 2017 at 10:13 AM, Roni Even <= span dir=3D"ltr"><roni.even@huawei.com> wrote:

Support Collin view

Roni=

=C2=A0

From: Colin Pe= rkins [mailto:csp@cs= perkins.org]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=92 0= 7 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 12:45
To: Christer Holmberg
Cc: Roni Even; Jonathan Lennox; mmusic
Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media?

=C2=A0

On 7 Nov 2017, at 10:42, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:

=C2=A0

Hi,

=C2=A0

>Section 4.7 of draft-ietf-rtcweb-rt= p-usage already mandates this for WebRTC endpoints, which are probably the = major users of BUNDLE.

=C2=A0

Correct. And, the data channel will alw= ays be symmetric by design.

=C2=A0

Colin, as someone who has good insight = in the world of RTP, do you see any general (outside of WebRTC) issues with= mandating symmetric?

=C2=A0

No issues that I know= of. I think it=E2=80=99s a good idea, and needed for NAT traversal in many= cases.

--=C2=A0
Colin Perkins
https://csperkins.org/=


=C2=A0


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

--94eb2c145ce4cb6281055d69a08a-- From nobody Wed Nov 8 07:45:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30F0127876 for ; Wed, 8 Nov 2017 07:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hAKQgR_4nt3C for ; Wed, 8 Nov 2017 07:45:11 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4225C127873 for ; Wed, 8 Nov 2017 07:45:10 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id l8so2799972wre.12 for ; Wed, 08 Nov 2017 07:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VxBKtAuzLtsXA1vAGI1G+NjkdpB+BAIKPUGiDCm6eoE=; b=rKvGGmgDRpz9xUZ3rJyn6vIMzYDfgqydikMz5sSGwsIGBLDaVMQLwCP81tBVd9MA7P Mc2xgVUqinuSoLN9iYSzy1fGTRZgirwwBN05ufwfzWtJ4gmlN6ktRN3gQwZOE+SSZt0J aAz5Y3SHuyJqYl2Io8CuFe0AXNPCBUguhALWppkUooGiP7YVvpGarjuAsTTB6s52tGTe vZMlFTZPnljm2aMNfBNv1h5ELsAO0Hb/KGboy5DIsqZ7eZRICHaA1FQCEMPSV2O28qBp Rt1gHkwO4dOBrBmloyouzsMwFiHR6/yW4WiF/PDBi2EzsmwLLVsz0yFxbHH+xakT2SX2 mF4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VxBKtAuzLtsXA1vAGI1G+NjkdpB+BAIKPUGiDCm6eoE=; b=kQT21mSL5BYCuQjCryZnDfCWGwDRvPXKWfO3Igi5a65BqNk8RRK0QXU4HROUNvxtKn u5/GDtbfGJfpzgGfFFarFLQ8Acnn611ibxJDfzPlmi/DNeECzptnjH4RM5hrjQTemnid PwUulYj6CeMePaRWUdkqJYR/Jzye1cVPtcwndIw7hLpi1K1QB1GpOAlXN1XmDrQEJt30 xY1CvKh+YRzj6SDWphBGCINgu1n2cue95zpCzGp9ofsKsYe+lLNVxPgq1IMzUNr7OSWi mVVHnmIOHZxZe7Yiiaw7BIdmVsEIhVHmGvTqW/EhNUicghjLGruDNBvH0Ty79QMk+dSF QvrQ== X-Gm-Message-State: AJaThX5fmfDj4zToTBViY9ybtOzsQrj7U/LQyLDj8pPn+w/EG1IiiHuW Wu/ujTKydexSvNtwrJhcv7C5b7lOSq5GGaRH50k= X-Google-Smtp-Source: ABhQp+QOB+LLN1yE5w+vRS257w3e7wJ3G1s5H+kdmA7jeMwNNaI+busa5VoRyD4cB9JfacjjcTK7DehryQdXaETuALg= X-Received: by 10.223.129.41 with SMTP id 38mr906453wrm.57.1510155908696; Wed, 08 Nov 2017 07:45:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.147.68 with HTTP; Wed, 8 Nov 2017 07:45:08 -0800 (PST) In-Reply-To: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> From: Andy Hutton Date: Wed, 8 Nov 2017 15:45:08 +0000 Message-ID: To: Christer Holmberg Cc: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 15:45:13 -0000 On Fri, Nov 3, 2017 at 11:05 AM, Christer Holmberg wrote: >>But is it really necessary in this case? > > Seriously, I think it is. This is something that is expected to be widely > implemented (as we know, there are already implementations and SIP > profiles doing it), so I think the procedures need to be clear. Just > because those of use familiar with SDP might think it=E2=80=99s simple, i= t doesn=E2=80=99t > mean others will. > > Now, the draft says: > > "The exact negotiation mechanism is however outside the scope of this > document, an example mechanism can be found in > [I-D.ietf-sipbrandy-osrtp].=E2=80=9D > > > How do you implement and test something based on a statement like that? I= n > addition, the =E2=80=9Cexample mechanism=E2=80=9D does not cover subseque= nt offers. > > And, ietf-sipbrandy-osrtp says: > > "The use of SDP Security Descriptions using the RTP/AVP profile is > defined in > [I-D.mmusic-opportunistic-negotiation].=E2=80=9D > > > So, both drafts seem to say that one shall look at the other draft for > details :) > > So, I think you should add the following sections: > > X. SDP Offer/Answer Procedures > X.1. Generating the Initial SDP Offer > X.2. Generating the SDP Answer > X.3. Offerer Processing of the SDP Answer > X.4. Modifying the Session > > > In addition to defining how the offers and answers are created (that is > the simple part), it also needs to be clear whether there are restriction= s > in subsequent offers. > > For example, what does it mean to send a subsequent offer with RTP/AVP, > WITHOUT a=3Dfingerprint/crypto/zrtp-hash? Is the security disabled? > > Also, as this document updates RFCs 4568 and 4585, I=E2=80=99d prefer to = have a > dedicated section named =E2=80=9CUpdates to RFC 4568 and RFC 4585=E2=80= =9D, and then > indicate what is updated. > > Also, are there BUNDLE considerations? For example, can you use > opportunistic security in one bundled m- section, while you use vanilla > security in another m- section? > > These are questions that may come up sooner or later, so let=E2=80=99s tr= y to > answer them from the beginning. > > Regards, > > Christer > Thanks Christer for the details comments and I have a lot of sympathy regarding the view that all this should all be specified in the MMUSIC draft however this is all contrary to the decisions made a couple of years ago in Dispatch when it was decided to form SIPBrandy to do this specification work. Unfortunately once we had started down the path of doing the work in SIPBrandy we discovered that we needed to update RFC 4568 and the AD's instructed us write a short MMUSIC draft to update the RFC 4568 as the SIPBrandy charter did not allow for this. So now we are going round in circles and we need to decide whether we do the OSRTP work in MMUSIC which is what we wanted in the first place or we continue with SIPBrandy. Please can the relevant chairs and AD's get together and tell us how to pro= ceed. Regards Andy From nobody Wed Nov 8 08:10:32 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78221273E2 for ; Wed, 8 Nov 2017 08:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 T_ngonpGjsmO for ; Wed, 8 Nov 2017 08:10:17 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9546F128768 for ; Wed, 8 Nov 2017 08:10:17 -0800 (PST) X-AuditID: c1b4fb3a-dffff70000006897-32-5a032c672d2c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.A6.26775.76C230A5; Wed, 8 Nov 2017 17:10:15 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Wed, 8 Nov 2017 17:10:14 +0100 From: Christer Holmberg To: Andy Hutton CC: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUAgACwtID//7EEIIAAs6WAgAA+fYCAOGvZgIAAF2yA///41QCAACC4AIAIFtAAgAAWyaA= Date: Wed, 8 Nov 2017 16:10:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C6963F0@ESESSMB109.ericsson.se> References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdTDddhznKYP4RSYtL67YyWcyd4mcx dfljFgdmjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZq7r+MBb84a7YunYOcwPj Fe4uRk4OCQETicu3zjF3MXJxCAkcZpRYv/QiK4SziFHi5fdGxi5GDg42AQuJ7n/aIA0iAtoS 76bsYAWxmQXiJA6vncwOYgsLhElsu9DCAlETLjH73UFWCLtMYuaKTkYQm0VARWLT0X9gI3kF fCVOHNSCWDWfVeLTllPMIDWcAoESP6cuZwKxGQXEJL6fWsMEsUtc4taT+UwQRwtILNlznhnC FpV4+fgfK4StJNG45AkryHxmAU2J9bv0IVoVJaZ0PwQ7k1dAUOLkzCcsExhFZyGZOguhYxaS jllIOhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyag1t+W+1gPPjc8RCjAAejEg+v tjxzlBBrYllxZe4hRgkOZiUR3i5loBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNL UrNTUwtSi2CyTBycUg2MTRrOvjeufbq0cVJTb/rm1TyvLy+V2829O7lDU2bi7os8rS8nTc9R +D6jqvjeOfaQ2YlZbnymgs8zORtNxNY5uqxZVzJ1d8yRWrcNPrLrTgcd4pX0+X/u4JOJ83Rq eXazGX4Qr/rt9mTzo8Za/qUr7y10V5jlv7RD6j3PDusvW6fX+bAeY9ELU2Ipzkg01GIuKk4E AAh0GcOWAgAA Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 16:10:21 -0000 SGksDQoNCi4uLg0KDQo+IFRoYW5rcyBDaHJpc3RlciBmb3IgdGhlIGRldGFpbHMgY29tbWVudHMg YW5kIEkgaGF2ZSBhIGxvdCBvZiBzeW1wYXRoeSByZWdhcmRpbmcgdGhlIHZpZXcgdGhhdCBhbGwg dGhpcyBzaG91bGQNCj4gYWxsIGJlIHNwZWNpZmllZCBpbiB0aGUgTU1VU0lDIGRyYWZ0IGhvd2V2 ZXIgdGhpcyBpcyBhbGwgY29udHJhcnkgdG8gdGhlIGRlY2lzaW9ucyBtYWRlIGEgY291cGxlIG9m IHllYXJzIGFnbyBpbiBEaXNwYXRjaA0KDQpPbmUgY2FuIGFsd2F5cyBtYWtlIGEgbmV3IGRlY2lz aW9uLg0KDQo+IHdoZW4gaXQgd2FzIGRlY2lkZWQgdG8gZm9ybSBTSVBCcmFuZHkgdG8gZG8gdGhp cyBzcGVjaWZpY2F0aW9uIHdvcmsuIA0KDQpTbywgd2hlcmUgaXMgdGhlIFNJUEJyYW5keSBzcGVj aWZpY2F0aW9uIHdvcms/IEFsbCBJIGZpbmQgaXMgYW4gSU5GT1JNQVRJVkUgZHJhZnQgKGRyYWZ0 LWlldGYtc2lwYnJhbmR5LW9zcnRwKSwgd2hpY2ggZG9lcyBOT1QgY29udGFpbiB0aGUgc3BlY2lm aWNhdGlvbnMgSSBhbSBhc2tpbmcgZm9yLg0KDQo+IFVuZm9ydHVuYXRlbHkgb25jZSB3ZSBoYWQg c3RhcnRlZCBkb3duIHRoZSBwYXRoIG9mIGRvaW5nIHRoZSB3b3JrIGluIFNJUEJyYW5keSB3ZSBk aXNjb3ZlcmVkIHRoYXQgd2UgbmVlZGVkIHRvIHVwZGF0ZSBSRkMNCj4gNDU2OCBhbmQgdGhlIEFE J3MgaW5zdHJ1Y3RlZCB1cyB3cml0ZSBhIHNob3J0IE1NVVNJQyBkcmFmdCB0byB1cGRhdGUgdGhl IFJGQyA0NTY4IGFzIHRoZSBTSVBCcmFuZHkgY2hhcnRlciBkaWQgbm90IGFsbG93IGZvciB0aGlz Lg0KPg0KPiBTbyBub3cgd2UgYXJlIGdvaW5nIHJvdW5kIGluIGNpcmNsZXMgYW5kIHdlIG5lZWQg dG8gZGVjaWRlIHdoZXRoZXIgd2UgZG8gdGhlIE9TUlRQIHdvcmsgaW4gTU1VU0lDIHdoaWNoIGlz IHdoYXQgd2Ugd2FudGVkDQo+IGluIHRoZSBmaXJzdCBwbGFjZSBvciB3ZSBjb250aW51ZSB3aXRo IFNJUEJyYW5keS4NCj4NCj4gUGxlYXNlIGNhbiB0aGUgcmVsZXZhbnQgY2hhaXJzIGFuZCBBRCdz IGdldCB0b2dldGhlciBhbmQgdGVsbCB1cyBob3cgdG8gcHJvY2VlZC4NCg0KWWVzLCBsZXQncyBk byB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Wed Nov 8 09:37:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C59C12949A for ; Wed, 8 Nov 2017 09:37:45 -0800 (PST) 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 autolearn_force=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 yiILZ6NmZP32 for ; Wed, 8 Nov 2017 09:37:44 -0800 (PST) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8998C12949F for ; Wed, 8 Nov 2017 09:37:44 -0800 (PST) X-AuditID: 12074413-38bff70000007929-97-5a0340e76c3e Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id FE.D1.31017.7E0430A5; Wed, 8 Nov 2017 12:37:43 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vA8HbgTu030141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Nov 2017 12:37:43 -0500 To: mmusic@ietf.org References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Wed, 8 Nov 2017 12:37:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYndR1H3uwBxl8LfDyGLq8scsFis2HGB1 YPL4+/4Dk8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIaf7awFxxmrJi84itbA+Nkxi5GTg4JAROJ 5Re/sHYxcnEICexgkrj6Yx07hPOASWLO7q3sIFXCAmESpzYfYwKxRQSEJWa8/csGUTSfVeLT llPMIAk2AS2JOYf+s4DYvAL2EovWPwZbwSKgInHg0S5WEFtUIE3izoyHTBA1ghInZz4Bq+cU CJT4OXU5WJxZwExi3uaHzBC2uMStJ/Oh4vIS29/OYZ7AyD8LSfssJC2zkLTMQtKygJFlFaNc Yk5prm5uYmZOcWqybnFyYl5eapGuuV5uZoleakrpJkZIsArvYNx1Uu4QowAHoxIPr4YiU5QQ a2JZcWXuIUZJDiYlUd4Hr4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHh79ZmjhHhTEiurUovy YVLSHCxK4rxqS9T9hATSE0tSs1NTC1KLYLIyHBxKErw99kCNgkWp6akVaZk5JQhpJg5OkOE8 QMPzQWp4iwsSc4sz0yHypxjtOXpWXPzDxHHj4XUg2dNzA0g+m/m6gVmIJS8/L1VKnPcOSJsA SFtGaR7cZFgiesUoDvSoMC8LMC0J8QCTGNzsV0BrmYDW7g9hAFlbkoiQkmpgzK6cM3NPfGx7 5mMvlTvpL6yk7YSEL5r5M3+d4zOFLcbt6+Nd61W/bBPjOC66sKaI3/zDpt25ezmPze6duFhZ hqU2VYX5o/c55aedDxZbxsoFLRXJfrR11jMBi8aQJbs+vj27gJFHyTBjoWb5oqmXpm9WWCtw +47FEseKDVaNPTFKvmziQvYNSizFGYmGWsxFxYkAWGXwsh8DAAA= Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 17:37:46 -0000 On 11/8/17 10:45 AM, Andy Hutton wrote: > Please can the relevant chairs and AD's get together and tell us how to proceed. Yes, this is the proper way to sort this out. Thanks, Paul From nobody Wed Nov 8 11:03:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4E129B45 for ; Wed, 8 Nov 2017 11:03:46 -0800 (PST) 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 autolearn_force=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 l8wOikpvXSsh for ; Wed, 8 Nov 2017 11:03:44 -0800 (PST) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id F375E129537 for ; Wed, 8 Nov 2017 11:03:43 -0800 (PST) X-AuditID: 1207440f-a43ff70000007960-e4-5a03550b2e5b Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.F0.31072.C05530A5; Wed, 8 Nov 2017 14:03:40 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vA8J3cUC002781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Nov 2017 14:03:39 -0500 To: Sandeep Kumar Aitha Cc: "mmusic@ietf.org" References: <20171103184252.227AAB80D88@rfc-editor.org> <688c4d9715ec46edad0b2c5eaee4f9f1@APHYDEXM01E.ap.qualcomm.com> From: Paul Kyzivat Message-ID: <80e5c05d-25d5-0837-9684-ce3de3bcc825@alum.mit.edu> Date: Wed, 8 Nov 2017 14:03:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <688c4d9715ec46edad0b2c5eaee4f9f1@APHYDEXM01E.ap.qualcomm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYndR1OUNZY4ymHhZ3WLq8scsFh/+XmNy YPJYsuQnk8eiqc8YA5iiuGxSUnMyy1KL9O0SuDKW364tOCpU0X1rC3MD43u+LkZODgkBE4lz VyawdjFycQgJ7GCS2D55ETuE84BJov/wZVaQKmEBB4ntn08wdTFycIgIGEqsW6YOEmYWUJeY OPcGE0T9OkaJs2++gNWzCWhJzDn0nwXE5hWwl9j58zETiM0ioCJxtHUZG4gtKpAmcWfGQyaI GkGJkzOfgNVzCnhLtDVdZIJYYCYxb/NDZghbXOLWk/lQcXmJ7W/nME9gFJiFpH0WkpZZSFpm IWlZwMiyilEuMac0Vzc3MTOnODVZtzg5MS8vtUjXRC83s0QvNaV0EyMkgPl3MHatlznEKMDB qMTDq6HIFCXEmlhWXJl7iFGSg0lJlPfBK6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd5efeYo Id6UxMqq1KJ8mJQ0B4uSOK/6EnU/IYH0xJLU7NTUgtQimKwMB4eSBO+pYKBGwaLU9NSKtMyc EoQ0EwcnyHAeoOGFIDW8xQWJucWZ6RD5U4zGHD09N/4wcTyb+bqBWYglLz8vVUqc9zxIqQBI aUZpHtw0WBJ6xSgO9JwwL08IUBUPMIHBzXsFtIoJaNX+EAaQVSWJCCmpBkY5LdNvm23Xls7b PFdY+fqd7D+tPC9XtTBENSl4LJrNbWjdH5Z/9POvjtjoiOa1W/4vP7v4yxqdrg1XOy9fcF74 omZl78cLXqbRPrdul/95dut3cpH8yixd0ZjLMx5O5Wy1sZ7A9ZC19WTNsfpS/z3G4hWLPjAe cbc/NSkrZ/ka50Q99agcB1MlluKMREMt5qLiRADW2JTOHQMAAA== Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 19:03:46 -0000 On 11/4/17 12:01 AM, Sandeep Kumar Aitha wrote: > Hi Paul , > > Thanks for the commnets. > Can you please point me to the variety of reasons in which the answerer might change the mapping of codecs. Can someone else chime in here? I can't recall. I think there were cases related to interoperation with H.323, but I don't know anything about H.323. Thanks, Paul > Best Regards, > Sandeep Kumar Aitha. > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Saturday, November 04, 2017 2:12 AM > To: Sandeep Kumar Aitha > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) > > Just to get a head start on discussion of this, comment at end. > > On 11/3/17 2:42 PM, RFC Errata System wrote: >> The following errata report has been submitted for RFC3264, "An >> Offer/Answer Model with Session Description Protocol (SDP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5177 >> >> -------------------------------------- >> Type: Technical >> Reported by: Sandeep Kumar Aitha >> >> Section: 5.1 >> >> Original Text >> ------------- >> Section 5.1 says: >> However, for sendonly and sendrecv streams, the answer might indicate >> different payload type numbers for the same codecs, in which case, the >> offerer MUST send with the payload type numbers from the answer. >> >> Section 6.2 says: >> In the case of RTP, if a particular codec was referenced with a >> specific payload type number in the offer, that same payload type >> number SHOULD be used for that codec in the answer. >> >> Corrected Text >> -------------- >> Only one of the above statements can be correct. >> >> >> Notes >> ----- >> Above two statements are conflicting. >> The answerer should be able to either map the payload type to a different codec or not. > > These statements are not in conflict. "SHOULD" is different from "MUST", in that it may be violated with valid reason. There are a variety of reasons why an answerer might have to violate the SHOULD. And in this case the offerer MUST send media using the PT in the answer, while the answerer MUST send media using the PT from the offer. > > Thanks, > Paul > From nobody Wed Nov 8 19:08:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E22129ADF for ; Wed, 8 Nov 2017 19:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 Q1RAyyLuH6A9 for ; Wed, 8 Nov 2017 19:08:18 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDFE129467 for ; Wed, 8 Nov 2017 19:08:18 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id CdC7efCWKt8cgCdCTePdtD; Thu, 09 Nov 2017 03:08:17 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-10v.sys.comcast.net with SMTP id CdCReJySPVigWCdCSeFLHN; Thu, 09 Nov 2017 03:08:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id vA938FtV017268; Wed, 8 Nov 2017 22:08:15 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vA938E80017265; Wed, 8 Nov 2017 22:08:14 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat Cc: saitha@qti.qualcomm.com, mmusic@ietf.org In-Reply-To: <80e5c05d-25d5-0837-9684-ce3de3bcc825@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 08 Nov 2017 22:08:14 -0500 Message-ID: <874lq4409t.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOZj7czIR3RcgpvST26kKuaxYL+mg74QLUeXRQFO4mR77EjAtIq+9oueTdPd1nOQOq3L0axzxtOxxitmGHmCw8wNIeSBuXyAZYJMd8fIYYJooXlKEuQK /VsLYeYLI3Lfk3LyLxINd87boCEiVT4nfAstzfT9Ol4wy4yzdU7NGJc2qEayxlt2rInNgTJDKb9jE2VKwp49jullV/9HoAxt7+utUuteJkooRs2Pr1HYCBcp Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 09 Nov 2017 03:08:19 -0000 Paul Kyzivat writes: > On 11/4/17 12:01 AM, Sandeep Kumar Aitha wrote: >> Hi Paul , >> >> Thanks for the commnets. >> Can you please point me to the variety of reasons in which the >> answerer might change the mapping of codecs. > > Can someone else chime in here? I can't recall. I think there were cases > related to interoperation with H.323, but I don't know anything about H.323. In regard to the erratum for the RFC, why a device might deviate from using the same payload type numbers isn't particularly relevant. As Paul says, it is a strict requirement that "the offerer MUST send with the payload type numbers from the answer". And that behavior of a device can be test straightforwardly. That a device should prefer to use the same payload type numbers in its answer that it received in the offer is not directly enforcable, of course, but is a guide to implementors. I believe Paul is right that in some instances of interworking with H.323, having different payload type numbers in the two directions can't be (easily) avoided. But I do not know the details. The only RFC with an obvious title, RFC 4123, does not seem to discuss payload type numbers. One situation where a device may not be free in selecting payload type numbers is when it is carrying out third-party call control and passing offers and answers between other devices. See for example RFC 3725 and RFC 7088, especially the hair-splitting analysis in RFC 7088 section 2.8. Dale From nobody Wed Nov 8 22:03:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9374F12EB76 for ; Wed, 8 Nov 2017 22:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6hDyDXs5Y6Yl for ; Wed, 8 Nov 2017 22:03:35 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43ECC12EB83 for ; Wed, 8 Nov 2017 22:03:29 -0800 (PST) X-Halon-ID: aeaee0d6-c513-11e7-969e-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [87.96.178.34]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id aeaee0d6-c513-11e7-969e-005056917f90; Thu, 09 Nov 2017 07:03:19 +0100 (CET) To: Paul Kyzivat , Sandeep Kumar Aitha Cc: "mmusic@ietf.org" References: <20171103184252.227AAB80D88@rfc-editor.org> <688c4d9715ec46edad0b2c5eaee4f9f1@APHYDEXM01E.ap.qualcomm.com> <80e5c05d-25d5-0837-9684-ce3de3bcc825@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 9 Nov 2017 07:03:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <80e5c05d-25d5-0837-9684-ce3de3bcc825@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 09 Nov 2017 06:03:37 -0000 Den 2017-11-08 kl. 20:03, skrev Paul Kyzivat: > On 11/4/17 12:01 AM, Sandeep Kumar Aitha wrote: >> Hi Paul , >> >> Thanks for the commnets. >> Can you please point me to the variety of reasons in which the >> answerer might change the mapping of codecs. > > Can someone else chime in here? I can't recall. I think there were > cases related to interoperation with H.323, but I don't know anything > about H.323. I can only agree that the exception is because of H.323. This sentence is further down in section 5.1 of RFC 3264: " Different payload type numbers may be needed in each direction because of interoperability concerns with H.323." I have however seen a number of SIP implementations with no clear relation to H.323 using the exception. So, it is best to keep on implementing the offering side for cases when the answering side just selects its own Payload Type numbers and ignores the SHOULD for keeping them equal. Regards Gunnar > >     Thanks, >     Paul > >> Best Regards, >> Sandeep Kumar Aitha. >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Saturday, November 04, 2017 2:12 AM >> To: Sandeep Kumar Aitha >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) >> >> Just to get a head start on discussion of this, comment at end. >> >> On 11/3/17 2:42 PM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC3264, "An >>> Offer/Answer Model with Session Description Protocol (SDP)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5177 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Sandeep Kumar Aitha >>> >>> Section: 5.1 >>> >>> Original Text >>> ------------- >>> Section 5.1 says: >>> However, for sendonly and sendrecv streams, the answer might indicate >>> different payload type numbers for the same codecs, in which case, the >>> offerer MUST send with the payload type numbers from the answer. >>> >>> Section 6.2 says: >>> In the case of RTP, if a particular codec was referenced with a >>> specific payload type number in the offer, that same payload type >>> number SHOULD be used for that codec in the answer. >>> >>> Corrected Text >>> -------------- >>> Only one of the above statements can be correct. >>> >>> >>> Notes >>> ----- >>> Above two statements are conflicting. >>> The answerer should be able to either map the payload type to a >>> different codec or not. >> >> These statements are not in conflict. "SHOULD" is different from >> "MUST", in that it may be violated with valid reason. There are a >> variety of reasons why an answerer might have to violate the SHOULD. >> And in this case the offerer MUST send media using the PT in the >> answer, while the answerer MUST send media using the PT from the offer. >> >>     Thanks, >>     Paul >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Nov 9 01:55:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D645412F258 for ; Thu, 9 Nov 2017 01:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jA22ONCM7KKz for ; Thu, 9 Nov 2017 01:55:09 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE091289C3 for ; Thu, 9 Nov 2017 01:55:08 -0800 (PST) X-AuditID: c1b4fb30-b48ed9c000007d10-a5-5a0425fa8834 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1D.E4.32016.AF5240A5; Thu, 9 Nov 2017 10:55:07 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Thu, 9 Nov 2017 10:55:06 +0100 From: Christer Holmberg To: Roman Shpount , Roni Even CC: Colin Perkins , Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric media? Thread-Index: AQHTVwgLo+gWRS+bMkmXyKhd/WGGcKMHgVGAgAATAEaAAMrBAIAAI8CigAAmLYCAABVAgP//7dsAgABLAACAAEhLgIACk+1A Date: Thu, 9 Nov 2017 09:55:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C69769E@ESESSMB109.ericsson.se> References: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> <57848637-B007-4167-8868-18F0876384A0@csperkins.org> <26AA3D0B-857E-4BF3-BF92-045B7517A858@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD835304@DGGEMM506-MBX.china.huawei.com> 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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B5C69769EESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2J7iO5vVZYog5mTuS2WvzzBaLF/8Xlm i6nLH7NYzLgwldni07HzLA6sHtPu32fzaDnyltVjyZKfTB63phR4tD27wx7AGsVlk5Kak1mW WqRvl8CV8fXbMvaCFy2MFV3XJjI2MC5oZOxi5OSQEDCRaNi0m7WLkYtDSOAwo8TBlxsYIZxF jBKru14AZTg42AQsJLr/aYM0iAi4S6zqecUEYjMLpEvcWXKfGcQWBiq58OYRE0SNpcTj/Y/Z Iew8iTcn14DFWQRUJPqmrmYDGckr4CtxcEM2xKqrLBKTPq9hBolzCgRKHJtWDVLOKCAm8f3U GqhV4hK3nsxngrhZQGLJnvPMELaoxMvH/1ghbCWJRbc/Q9XnS6z+t5YFxOYVEJQ4OfMJywRG kVlIRs1CUjYLSdksoCuYBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4qTcdCMj vdSizOTi4vw8vbzUkk2MwIg8uOW3wQ7Gl88dDzEKcDAq8fDuUmKJEmJNLCuuzD3EKMHBrCTC K/KWOUqINyWxsiq1KD++qDQntfgQozQHi5I4r+O+CxFCAumJJanZqakFqUUwWSYOTqkGxnxl ae9vj0+evnHkkOP9ycdVfog9FbpRqK447VDy1acL70fNzH5rJDt/n2HBxH5XuUdBFU3sszTf Mrz65JvwizuiUDT0XNQRyRlKBzzrDtUq7MjP2J2y7Vm80GE+xtY2n0ecjEFZ7nJ6are1tf8/ MvmbsTxyz30V03+t78OPtU07Ov+PW+Y3PSWW4oxEQy3mouJEAM7KIb7EAgAA Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 09 Nov 2017 09:55:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B5C69769EESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSB1cGRhdGVkIG15IOKAnHRyYW5zcG9ydOKAnSBQUiwgdG8gYWxzbyBpbmNs dWRlIHVzYWdlIG9mIHN5bW1ldHJpYyBtZWRpYSBmb3IgYnVuZGxlZCBtZWRpYS4NCg0KaHR0cHM6 Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvcHVsbC80MQ0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5j b21dDQpTZW50OiAwNyBOb3ZlbWJlciAyMDE3IDIxOjMyDQpUbzogUm9uaSBFdmVuIDxyb25pLmV2 ZW5AaHVhd2VpLmNvbT4NCkNjOiBDb2xpbiBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZz47IENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBKb25hdGhh biBMZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbT47IG1tdXNpYyA8bW11c2ljQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtNTVVTSUNdIEJVTkRMRTogTWFuZGF0aW5nIHN5bW1ldHJpYyBtZWRpYT8N Cg0KSSBhZ3JlZS4gTWFrZSBpdCBzeW1tZXRyaWMuDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNo cG91bnQNCg0KT24gVHVlLCBOb3YgNywgMjAxNyBhdCAxMDoxMyBBTSwgUm9uaSBFdmVuIDxyb25p LmV2ZW5AaHVhd2VpLmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+PiB3cm90ZToNClN1 cHBvcnQgQ29sbGluIHZpZXcNClJvbmkNCg0KRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNz cEBjc3BlcmtpbnMub3JnPG1haWx0bzpjc3BAY3NwZXJraW5zLm9yZz5dDQpTZW50OiDXmdeV150g 15IgMDcg16DXldeR157XkdeoIDIwMTcgMTI6NDUNClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6 IFJvbmkgRXZlbjsgSm9uYXRoYW4gTGVubm94OyBtbXVzaWMNClN1YmplY3Q6IFJlOiBbTU1VU0lD XSBCVU5ETEU6IE1hbmRhdGluZyBzeW1tZXRyaWMgbWVkaWE/DQoNCk9uIDcgTm92IDIwMTcsIGF0 IDEwOjQyLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGksDQoN Cj5TZWN0aW9uIDQuNyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UgYWxyZWFkeSBtYW5k YXRlcyB0aGlzIGZvciBXZWJSVEMgZW5kcG9pbnRzLCB3aGljaCBhcmUgcHJvYmFibHkgdGhlIG1h am9yIHVzZXJzIG9mIEJVTkRMRS4NCg0KQ29ycmVjdC4gQW5kLCB0aGUgZGF0YSBjaGFubmVsIHdp bGwgYWx3YXlzIGJlIHN5bW1ldHJpYyBieSBkZXNpZ24uDQoNCkNvbGluLCBhcyBzb21lb25lIHdo byBoYXMgZ29vZCBpbnNpZ2h0IGluIHRoZSB3b3JsZCBvZiBSVFAsIGRvIHlvdSBzZWUgYW55IGdl bmVyYWwgKG91dHNpZGUgb2YgV2ViUlRDKSBpc3N1ZXMgd2l0aCBtYW5kYXRpbmcgc3ltbWV0cmlj Pw0KDQpObyBpc3N1ZXMgdGhhdCBJIGtub3cgb2YuIEkgdGhpbmsgaXTigJlzIGEgZ29vZCBpZGVh LCBhbmQgbmVlZGVkIGZvciBOQVQgdHJhdmVyc2FsIGluIG1hbnkgY2FzZXMuDQoNCi0tDQpDb2xp biBQZXJraW5zDQpodHRwczovL2NzcGVya2lucy5vcmcvDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11 c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B5C69769EESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgaGF2ZSB1cGRhdGVkIG15IOKA nHRyYW5zcG9ydOKAnSBQUiwgdG8gYWxzbyBpbmNsdWRlIHVzYWdlIG9mIHN5bW1ldHJpYyBtZWRp YSBmb3IgYnVuZGxlZCBtZWRpYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAtYnVuZGxlL3B1 bGwvNDEiPmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAtYnVuZGxlL3B1bGwvNDE8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJp eC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDcgTm92ZW1iZXIgMjAxNyAyMTozMjxicj4NCjxi PlRvOjwvYj4gUm9uaSBFdmVuICZsdDtyb25pLmV2ZW5AaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IENvbGluIFBlcmtpbnMgJmx0O2NzcEBjc3BlcmtpbnMub3JnJmd0OzsgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs7IEpvbmF0aGFu IExlbm5veCAmbHQ7am9uYXRoYW5AdmlkeW8uY29tJmd0OzsgbW11c2ljICZsdDttbXVzaWNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBCVU5ETEU6IE1hbmRh dGluZyBzeW1tZXRyaWMgbWVkaWE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBhZ3JlZS4gTWFrZSBpdCBzeW1tZXRyaWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4N ClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIE5vdiA3LCAyMDE3IGF0IDEwOjEzIEFNLCBSb25pIEV2ZW4gJmx0OzxhIGhy ZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbmkuZXZl bkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3VwcG9ydCBDb2xsaW4gdmlldzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvbmk8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBDb2xpbg0KIFBlcmtpbnMg W21haWx0bzo8YSBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmciIHRhcmdldD0iX2JsYW5r Ij5jc3BAY3NwZXJraW5zLm9yZzwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gPC9zcGFuPjxzcGFu IGxhbmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPteZ15XXnSZuYnNwO9eSIDA3INeg15XXkdee 15HXqCAyMDE3IDEyOjQ1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K PGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gUm9uaSBFdmVuOyBK b25hdGhhbiBMZW5ub3g7IG1tdXNpYzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10g QlVORExFOiBNYW5kYXRpbmcgc3ltbWV0cmljIG1lZGlhPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5PbiA3IE5vdiAyMDE3LCBhdCAxMDo0MiwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5IaSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O1NlY3Rpb24gNC43IG9m IGRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZSBhbHJlYWR5IG1hbmRhdGVzIHRoaXMgZm9yIFdl YlJUQyBlbmRwb2ludHMsIHdoaWNoIGFyZSBwcm9iYWJseQ0KIHRoZSBtYWpvciB1c2VycyBvZiBC VU5ETEUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q29ycmVjdC4gQW5kLCB0aGUgZGF0 YSBjaGFubmVsIHdpbGwgYWx3YXlzIGJlIHN5bW1ldHJpYyBieSBkZXNpZ24uPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Db2xpbiwgYXMgc29tZW9uZSB3aG8gaGFzIGdvb2QgaW5zaWdodCBpbiB0aGUgd29ybGQgb2Yg UlRQLCBkbyB5b3Ugc2VlIGFueSBnZW5lcmFsIChvdXRzaWRlIG9mIFdlYlJUQykNCiBpc3N1ZXMg d2l0aCBtYW5kYXRpbmcgc3ltbWV0cmljPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Tm8gaXNzdWVzIHRoYXQgSSBr bm93IG9mLiBJIHRoaW5rIGl04oCZcyBhIGdvb2QgaWRlYSwgYW5kIG5lZWRlZCBmb3IgTkFUIHRy YXZlcnNhbCBpbiBtYW55IGNhc2VzLjxicj4NCjxicj4NCi0tJm5ic3A7PGJyPg0KQ29saW4gUGVy a2luczxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY3NwZXJraW5zLm9yZy8iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2NzcGVya2lucy5vcmcvPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0Bp ZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B5C69769EESESSMB109erics_-- From nobody Thu Nov 9 11:48:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35F7126B71 for ; Thu, 9 Nov 2017 11:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yS6uyfmXFn1T for ; Thu, 9 Nov 2017 11:48:44 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14ECA129649 for ; Thu, 9 Nov 2017 11:48:44 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id v3so4727566vkb.8 for ; Thu, 09 Nov 2017 11:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OztU81wd4PV5i2QeY8zlu+o+KV2WHberbul41/AkFoM=; b=lwf72uzsfPXfdBB7/FVWoAA7PYF0nxZlUoJbeARZV9hZ5SGmTxs2ABMJ4NXB8K9tti FiiDsjCx8HE7r4UaeGjtaGRAGPcsBQmTz29g1nossTf3houv42zC8XXXVFqfML0GCjle A/doNRCJGYoC6r1nE7OmJc75eVsBWUcaG8E0NZC8kQ1UDcJJKNbMeR9PPdpx/1VEd64v IAM2P+a5Up7W06AaFiJ2PtsjM/q5FQvalOdu08usJqzmO56Z9Ax7IbP0ZUcDnHLRBzot ZbWgRByXC3S0/5M/zrWT3GA0AxCSv645YhoTKCW2FsdpWr+Lr/ifDT6O3whuz5ud0aMn fQvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OztU81wd4PV5i2QeY8zlu+o+KV2WHberbul41/AkFoM=; b=U22bv9VAEtUBC1MTU4jUz5cVj4Pza8HpTKWVzzlw8MIX4NGqugpyyX655TsW6+6OYn 7GtssyyKBIo4WEuQOvvSCnhAOzULmpUpG1V5Mlci093jEfty0tu+tfHMm4xDpievTMPP J/X71URpKcNcYHbuQ4S/UDK5UekinnImo4oePhEd5CPWRjOUdz75mnXxjIBSe/MRkxX7 Nx0J1rCLIW1shtbn9eDpyDr35KDp+vUgvBYTFtwsfNMyZPn/DrIeLTYZSPlXIdiqXLfB dwhOrHgonap9txF7bo1yzcGYL5y6nJUKL8iJA9UMLpyNQbdxTlz/VWrcz4okO86+6erd Rzkw== X-Gm-Message-State: AJaThX64R/VTKWnnh2XO5evvpJTYuBq1jj+SdoVSqNmXZpcpHppY5Bog TyEcivCIMTQvaLjN96TyFw4UTCr01ul/ihlY01E= X-Google-Smtp-Source: AGs4zMYkQWyofv4nzKXajqqETm9rvHKY+5fuHupNs4ev464NT8ind1rtBUvhq4SS0Kt7cRpYXw9BaF3Q3bsSHnnl3kw= X-Received: by 10.31.223.1 with SMTP id w1mr1421128vkg.150.1510256922932; Thu, 09 Nov 2017 11:48:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.142.141 with HTTP; Thu, 9 Nov 2017 11:48:42 -0800 (PST) In-Reply-To: References: <20171103184252.227AAB80D88@rfc-editor.org> <688c4d9715ec46edad0b2c5eaee4f9f1@APHYDEXM01E.ap.qualcomm.com> <80e5c05d-25d5-0837-9684-ce3de3bcc825@alum.mit.edu> From: Stephen Botzko Date: Thu, 9 Nov 2017 14:48:42 -0500 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: Paul Kyzivat , Sandeep Kumar Aitha , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07ab38693d30055d9217e0" Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 09 Nov 2017 19:48:47 -0000 --94eb2c07ab38693d30055d9217e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In H.323 systems, the two senders chose dynamic payload types independently, and there is no requirement for them to match. In version 16 (2011) version of H.245 a mechanism was added to address this - it allows the receiver (e.g. a non-transcoding H.323/SIP gateway) to request the sender to switch to a specified payload value. But support for that mechanism is optional. Regards Stephen On Thu, Nov 9, 2017 at 1:03 AM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > Den 2017-11-08 kl. 20:03, skrev Paul Kyzivat: > >> On 11/4/17 12:01 AM, Sandeep Kumar Aitha wrote: >> >>> Hi Paul , >>> >>> Thanks for the commnets. >>> Can you please point me to the variety of reasons in which the answerer >>> might change the mapping of codecs. >>> >> >> Can someone else chime in here? I can't recall. I think there were cases >> related to interoperation with H.323, but I don't know anything about H.= 323. >> > I can only agree that the exception is because of H.323. This sentence is > further down in section 5.1 of RFC 3264: > " Different payload type numbers may be needed in each direction because > of interoperability concerns with H.323." > > I have however seen a number of SIP implementations with no clear relatio= n > to H.323 using the exception. So, it is best to keep on implementing the > offering side for cases when the answering side just selects its own > Payload Type numbers and ignores the SHOULD for keeping them equal. > > Regards > Gunnar > > >> Thanks, >> Paul >> >> Best Regards, >>> Sandeep Kumar Aitha. >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Saturday, November 04, 2017 2:12 AM >>> To: Sandeep Kumar Aitha >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177) >>> >>> Just to get a head start on discussion of this, comment at end. >>> >>> On 11/3/17 2:42 PM, RFC Errata System wrote: >>> >>>> The following errata report has been submitted for RFC3264, "An >>>> Offer/Answer Model with Session Description Protocol (SDP)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata/eid5177 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Sandeep Kumar Aitha >>>> >>>> Section: 5.1 >>>> >>>> Original Text >>>> ------------- >>>> Section 5.1 says: >>>> However, for sendonly and sendrecv streams, the answer might indicate >>>> different payload type numbers for the same codecs, in which case, the >>>> offerer MUST send with the payload type numbers from the answer. >>>> >>>> Section 6.2 says: >>>> In the case of RTP, if a particular codec was referenced with a >>>> specific payload type number in the offer, that same payload type >>>> number SHOULD be used for that codec in the answer. >>>> >>>> Corrected Text >>>> -------------- >>>> Only one of the above statements can be correct. >>>> >>>> >>>> Notes >>>> ----- >>>> Above two statements are conflicting. >>>> The answerer should be able to either map the payload type to a >>>> different codec or not. >>>> >>> >>> These statements are not in conflict. "SHOULD" is different from "MUST"= , >>> in that it may be violated with valid reason. There are a variety of >>> reasons why an answerer might have to violate the SHOULD. And in this c= ase >>> the offerer MUST send media using the PT in the answer, while the answe= rer >>> MUST send media using the PT from the offer. >>> >>> Thanks, >>> Paul >>> >>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c07ab38693d30055d9217e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In H.323 systems, the two senders chose dynamic payload ty= pes independently, and there is no requirement for them to match.=C2=A0
In version 16 (2011) version of H.245 a mechanism was added= to address this - it allows the receiver (e.g. a non-transcoding H.323/SIP= gateway) to request the sender to switch to a specified payload value.=C2= =A0 =C2=A0But support for that mechanism is optional.

<= div>Regards
Stephen

On Thu, Nov 9, 2017 at 1:03 AM, Gunnar Hellstr=C3= =B6m <gunnar.hellstrom@omnitor.se> wrote:
Den 2017-11-08 kl. 20:03, skrev = Paul Kyzivat:
On 11/4/17 12:01 AM, Sandeep Kumar Aitha wrote:
Hi Paul ,

Thanks for the commnets.
Can you please point me to the variety of reasons in which the answerer mig= ht change the mapping of codecs.

Can someone else chime in here? I can't recall. I think there were case= s related to interoperation with H.323, but I don't know anything about= H.323.
 I can only agree that the exception is because of H.323. This sentence is f= urther down in section 5.1 of RFC 3264:
" Different payload type numbers may be needed in each direction becau= se of interoperability concerns with H.323."

I have however seen a number of SIP implementations with no clear relation = to H.323 using the exception. So, it is best to keep on implementing the of= fering side for cases when the answering side just selects its own Payload = Type numbers and ignores the SHOULD for keeping them equal.

Regards
Gunnar


=C2=A0=C2=A0=C2=A0=C2=A0Thanks,
=C2=A0=C2=A0=C2=A0=C2=A0Paul

Best Regards,
Sandeep Kumar Aitha.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
Sent: Saturday, November 04, 2017 2:12 AM
To: Sandeep Kumar Aitha <saitha@qti.qualcomm.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC3264 (5177)

Just to get a head start on discussion of this, comment at end.

On 11/3/17 2:42 PM, RFC Errata System wrote:
The following errata report has been submitted for RFC3264, "An
Offer/Answer Model with Session Description Protocol (SDP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5177

--------------------------------------
Type: Technical
Reported by: Sandeep Kumar Aitha <saitha@qti.qualcomm.com>

Section: 5.1

Original Text
-------------
Section 5.1 says:
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case, the
offerer MUST send with the payload type numbers from the answer.

Section 6.2 says:
In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.

Corrected Text
--------------
Only one of the above statements can be correct.


Notes
-----
Above two statements are conflicting.
The answerer should be able to either map the payload type to a different c= odec or not.

These statements are not in conflict. "SHOULD" is different from = "MUST", in that it may be violated with valid reason. There are a= variety of reasons why an answerer might have to violate the SHOULD. And i= n this case the offerer MUST send media using the PT in the answer, while t= he answerer MUST send media using the PT from the offer.

=C2=A0=C2=A0=C2=A0=C2=A0Thanks,
=C2=A0=C2=A0=C2=A0=C2=A0Paul


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

--
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hel= lstrom@omnitor.se
+46 708 204 288


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

--94eb2c07ab38693d30055d9217e0-- From nobody Thu Nov 9 14:25:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0DA127137 for ; Thu, 9 Nov 2017 14:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com 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 iE5ElTSDNQSQ for ; Thu, 9 Nov 2017 14:25:25 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2593128CDB for ; Thu, 9 Nov 2017 14:25:25 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id f8so9696726qta.5 for ; Thu, 09 Nov 2017 14:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=L3GNnYmcYFMyoMZllpapw5hGpYVFx0pchMEEz0fTCRQ=; b=hkSE90TwYYl2qnCtTgi+rDIXw+aPTnFobFTqYseOkAHlRCulHPjfFjS977WrgElOCv IR5RTrxlmhGsDYFylMVMYp5MCet7XmZHBXpHvqWNMPke8e3f0g09Mx+KEfmAoO5bP6Lk BZjZi6mVQhhSNVPlKsLkAVqVF3j6vDnmHTF/bshDziBBGiwrDBZRHGsrva8QhGigM6Uz b8LzstW1cAGG+twsfXl7MUrQ0tYQBf7Ys8y6YUdxE07xhEbS16ZdWVxkGyV9GdO9pChO lqVhgAwwJG0x2okOzSsnY81Yx/n9IicuUzaZpbFupdTuLvbqNFr1Z7ZE9N0PwATsoAei 4Jog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=L3GNnYmcYFMyoMZllpapw5hGpYVFx0pchMEEz0fTCRQ=; b=qNG6eMExO5TZOnoJh6zbVynGvd42p2ARa0lXRjBVe3XwkA7Z4ukhwxcQ0ntG9wTmqG BKGKJduFlx3hD5/LEyj6TqQ8LOWraFFtddFSEZYYMR7fC9HlwZ+mVTzKB3NWyjkar6OO LfZKGKbk4cj6o5SuxwIWGJXDeY0xNZ0Y4N5rFKcDH8ymvhGgq7zPhgKSlCneCoxfXN3K jXQWmer/vd9plUBi4VS03fy6awA8HF7cCSFtt5bHT+4ODFYOdk1sZy9iK0KGpDUUQ/oD oYkkTHy5rSXJYtKcIJwdj+4CzbjVVBjtLriFChI9ETTwB71LaRGaV9pbtFsZ1ooDbt63 8oSQ== X-Gm-Message-State: AJaThX5lpky1a8uICebTuVjGKHtWqCsKfQ6di2Yh5wdWLbvxJqic7N8A RH82MRe3YI4aNoborwOwU56bHz6482w= X-Google-Smtp-Source: AGs4zMafM/nWAM/VAS7pQDhBxBm6ly4kHcvGGXROUvOCZj2TuDxl8q+vCw0qamKu9vvxDmtRPCgXWQ== X-Received: by 10.200.23.196 with SMTP id r4mr3541927qtk.158.1510266324591; Thu, 09 Nov 2017 14:25:24 -0800 (PST) Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id t34sm5341174qtb.79.2017.11.09.14.25.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 14:25:23 -0800 (PST) From: Jonathan Lennox Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <58277100-1D4C-44E0-B621-30972D8BBC41@vidyo.com> Date: Thu, 9 Nov 2017 17:25:23 -0500 To: mmusic X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [MMUSIC] Simulcast and 5576 source attributes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 09 Nov 2017 22:25:27 -0000 The latest Simulcast draft (draft-ietf-mmusic-sdp-simulcast-10) has a = paragraph at the end of Section 5.1 that says: It is possible to use source-specific signaling [RFC5576] with "a=3Dsimulcast", but it is only in certain cases possible to learn = from that signaling which SSRC will belong to a particular simulcast stream. However, there=E2=80=99s no other mention of 5576 in the document, and = no registration of any 5576-style source-specific attributes. What are the =E2=80=9Ccertain cases=E2=80=9D? It=E2=80=99s not clear to = me there=E2=80=99s any way for the currently-registered 5576 attributes = to tell you which SSRC corresponds to which simulcast stream, prior to = receiving RID in RTCP or header extensions. (Notably, there=E2=80=99s = no rid source attribute.) From nobody Sat Nov 11 01:13:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158E612420B for ; Sat, 11 Nov 2017 01:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 OR7WZ2dXmMz0 for ; Sat, 11 Nov 2017 01:13:04 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CBC129418 for ; Sat, 11 Nov 2017 01:13:03 -0800 (PST) X-AuditID: c1b4fb30-a0dff70000002554-21-5a06bf1dd38c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.1E.09556.D1FB60A5; Sat, 11 Nov 2017 10:13:01 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Sat, 11 Nov 2017 10:13:00 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount , Roni Even CC: Jonathan Lennox , Colin Perkins , mmusic Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric media? Thread-Index: AQHTVwgLo+gWRS+bMkmXyKhd/WGGcKMHgVGAgAATAEaAAMrBAIAAI8CigAAmLYCAABVAgP//7dsAgABLAACAAEhLgIACk+1AgAMYiOA= Date: Sat, 11 Nov 2017 09:13:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C69C391@ESESSMB109.ericsson.se> References: <6E58094ECC8D8344914996DAD28F1CCD835024@DGGEMM506-MBX.china.huawei.com> <57848637-B007-4167-8868-18F0876384A0@csperkins.org> <26AA3D0B-857E-4BF3-BF92-045B7517A858@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD835304@DGGEMM506-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B5C69769E@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C69769E@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B5C69C391ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2J7iK7sfrYogwmX5S2WvzzBaLF/8Xlm i6nLH7NYzLgwldni07HzLA6sHtPu32fzaDnyltVjyZKfTB63phR4tD27wx7AGsVlk5Kak1mW WqRvl8CVsW/1DfaCGUsZKybOXM/awPhkAWMXIyeHhICJxMkpy5i6GLk4hAQOM0pM2/qEEcJZ zChxuu8saxcjBwebgIVE9z9tkAYRgVqJff//MYHYzALpEs93/WAHsYWBSi68ecQEUWMp8Xj/ Y3aQVhGBMomlG9VBwiwCqhIzOyazgdi8Ar4S589NZYFYNZNVYuaMC8wgCU4BP4n/v9+BFTEK iEl8P7UGape4xK0n85kgjhaQWLLnPDOELSrx8vE/VghbSWLt4e0sIHuZBfIlZj3Mg9glKHFy 5hOWCYwis5BMmoVQNQtJFURYU2L9Ln2IakWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi1Oyk03 MtJLLcpMLi7Oz9PLSy3ZxAiMx4NbfhvsYHz53PEQowAHoxIP79nFbFFCrIllxZW5hxglOJiV RHjZwoBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MC5q s3yjdIqTMzLEYAljp4ZlSMncaVNlJmvL/V9dIHBl1wavQx9WJjl5vdp6gT8u8z6D6fU5C4XK RT9cm/9bxeWDxkod98VHIkTYd6dpv/V/py5SYHC4+9bS0NCP1ZkPuzI/f7b6+OVTfIpk0b15 Gi+evhML2jWv02+xYdiBnWL6381CpR+1z1ViKc5INNRiLipOBAB/bUgTwwIAAA== Archived-At: Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric media? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 11 Nov 2017 09:13:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B5C69C391ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBQUiBoYXMgYmVlbiBtZXJnZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN CkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDA5IE5vdmVtYmVyIDIwMTcgMTE6NTUNClRvOiBS b21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT47IFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1 YXdlaS5jb20+DQpDYzogSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb20+OyBDb2xp biBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZz47IG1tdXNpYyA8bW11c2ljQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtNTVVTSUNdIEJVTkRMRTogTWFuZGF0aW5nIHN5bW1ldHJpYyBtZWRpYT8N Cg0KSGksDQoNCkkgaGF2ZSB1cGRhdGVkIG15IOKAnHRyYW5zcG9ydOKAnSBQUiwgdG8gYWxzbyBp bmNsdWRlIHVzYWdlIG9mIHN5bW1ldHJpYyBtZWRpYSBmb3IgYnVuZGxlZCBtZWRpYS4NCg0KaHR0 cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvcHVsbC80MQ0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJp eC5jb21dDQpTZW50OiAwNyBOb3ZlbWJlciAyMDE3IDIxOjMyDQpUbzogUm9uaSBFdmVuIDxyb25p LmV2ZW5AaHVhd2VpLmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+Pg0KQ2M6IENvbGlu IFBlcmtpbnMgPGNzcEBjc3BlcmtpbnMub3JnPG1haWx0bzpjc3BAY3NwZXJraW5zLm9yZz4+OyBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgSm9uYXRoYW4gTGVubm94IDxqb25hdGhh bkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT4+OyBtbXVzaWMgPG1tdXNpY0Bp ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBC VU5ETEU6IE1hbmRhdGluZyBzeW1tZXRyaWMgbWVkaWE/DQoNCkkgYWdyZWUuIE1ha2UgaXQgc3lt bWV0cmljLg0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFR1ZSwgTm92IDcs IDIwMTcgYXQgMTA6MTMgQU0sIFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb208bWFpbHRv OnJvbmkuZXZlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpTdXBwb3J0IENvbGxpbiB2aWV3DQpSb25p DQoNCkZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZzxtYWlsdG86 Y3NwQGNzcGVya2lucy5vcmc+XQ0KU2VudDog15nXldedINeSIDA3INeg15XXkdee15HXqCAyMDE3 IDEyOjQ1DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBSb25pIEV2ZW47IEpvbmF0aGFuIExl bm5veDsgbW11c2ljDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gQlVORExFOiBNYW5kYXRpbmcgc3lt bWV0cmljIG1lZGlhPw0KDQpPbiA3IE5vdiAyMDE3LCBhdCAxMDo0MiwgQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpLA0KDQo+U2VjdGlvbiA0Ljcgb2YgZHJhZnQt aWV0Zi1ydGN3ZWItcnRwLXVzYWdlIGFscmVhZHkgbWFuZGF0ZXMgdGhpcyBmb3IgV2ViUlRDIGVu ZHBvaW50cywgd2hpY2ggYXJlIHByb2JhYmx5IHRoZSBtYWpvciB1c2VycyBvZiBCVU5ETEUuDQoN CkNvcnJlY3QuIEFuZCwgdGhlIGRhdGEgY2hhbm5lbCB3aWxsIGFsd2F5cyBiZSBzeW1tZXRyaWMg YnkgZGVzaWduLg0KDQpDb2xpbiwgYXMgc29tZW9uZSB3aG8gaGFzIGdvb2QgaW5zaWdodCBpbiB0 aGUgd29ybGQgb2YgUlRQLCBkbyB5b3Ugc2VlIGFueSBnZW5lcmFsIChvdXRzaWRlIG9mIFdlYlJU QykgaXNzdWVzIHdpdGggbWFuZGF0aW5nIHN5bW1ldHJpYz8NCg0KTm8gaXNzdWVzIHRoYXQgSSBr bm93IG9mLiBJIHRoaW5rIGl04oCZcyBhIGdvb2QgaWRlYSwgYW5kIG5lZWRlZCBmb3IgTkFUIHRy YXZlcnNhbCBpbiBtYW55IGNhc2VzLg0KDQotLQ0KQ29saW4gUGVya2lucw0KaHR0cHM6Ly9jc3Bl cmtpbnMub3JnLw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Y0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B5C69C391ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgUFIgaGFzIGJlZW4gbWVyZ2Vk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1t dXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiAwOSBOb3ZlbWJlciAyMDE3IDEx OjU1PGJyPg0KPGI+VG86PC9iPiBSb21hbiBTaHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZn dDs7IFJvbmkgRXZlbiAmbHQ7cm9uaS5ldmVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBKb25hdGhhbiBMZW5ub3ggJmx0O2pvbmF0aGFuQHZpZHlvLmNvbSZndDs7IENvbGluIFBlcmtp bnMgJmx0O2NzcEBjc3BlcmtpbnMub3JnJmd0OzsgbW11c2ljICZsdDttbXVzaWNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBCVU5ETEU6IE1hbmRhdGluZyBz eW1tZXRyaWMgbWVkaWE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBoYXZl IHVwZGF0ZWQgbXkg4oCcdHJhbnNwb3J04oCdIFBSLCB0byBhbHNvIGluY2x1ZGUgdXNhZ2Ugb2Yg c3ltbWV0cmljIG1lZGlhIGZvciBidW5kbGVkIG1lZGlhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0 LXNkcC1idW5kbGUvcHVsbC80MSI+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1i dW5kbGUvcHVsbC80MTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFJvbWFuIFNocG91bnQgWzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+ bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNyBOb3Zl bWJlciAyMDE3IDIxOjMyPGJyPg0KPGI+VG86PC9iPiBSb25pIEV2ZW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSI+cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+Jmd0Ozxi cj4NCjxiPkNjOjwvYj4gQ29saW4gUGVya2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNzcEBjc3Bl cmtpbnMub3JnIj5jc3BAY3NwZXJraW5zLm9yZzwvYT4mZ3Q7OyBDaHJpc3RlciBIb2xtYmVyZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs7IEpvbmF0aGFuIExlbm5veCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSI+am9uYXRoYW5AdmlkeW8uY29tPC9hPiZn dDs7DQogbW11c2ljICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gQlVORExF OiBNYW5kYXRpbmcgc3ltbWV0cmljIG1lZGlhPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYWdyZWUuIE1ha2UgaXQgc3ltbWV0cmljLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f X188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgNywgMjAxNyBhdCAxMDoxMyBBTSwgUm9uaSBFdmVuICZs dDs8YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5y b25pLmV2ZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5TdXBwb3J0IENvbGxpbiB2aWV3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9uaTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IENvbGluDQogUGVya2lucyBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpjc3BAY3NwZXJraW5zLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNzcEBjc3Blcmtp bnMub3JnPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iSEUiIGRp cj0iUlRMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZiI+15nXldedJm5ic3A715IgMDcg16DXldeR157XkdeoIDIwMTcgMTI6 NDU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5Ubzo8L2I+IENo cmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBSb25pIEV2ZW47IEpvbmF0aGFuIExlbm5v eDsgbW11c2ljPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBCVU5ETEU6IE1hbmRh dGluZyBzeW1tZXRyaWMgbWVkaWE/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDcgTm92IDIw MTcsIGF0IDEwOjQyLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7U2VjdGlvbiA0Ljcgb2YgZHJhZnQtaWV0Zi1y dGN3ZWItcnRwLXVzYWdlIGFscmVhZHkgbWFuZGF0ZXMgdGhpcyBmb3IgV2ViUlRDIGVuZHBvaW50 cywgd2hpY2ggYXJlIHByb2JhYmx5DQogdGhlIG1ham9yIHVzZXJzIG9mIEJVTkRMRS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db3JyZWN0LiBBbmQsIHRoZSBkYXRhIGNoYW5uZWwgd2ls bCBhbHdheXMgYmUgc3ltbWV0cmljIGJ5IGRlc2lnbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNvbGluLCBhcyBz b21lb25lIHdobyBoYXMgZ29vZCBpbnNpZ2h0IGluIHRoZSB3b3JsZCBvZiBSVFAsIGRvIHlvdSBz ZWUgYW55IGdlbmVyYWwgKG91dHNpZGUgb2YgV2ViUlRDKQ0KIGlzc3VlcyB3aXRoIG1hbmRhdGlu ZyBzeW1tZXRyaWM/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5ObyBpc3N1ZXMgdGhhdCBJIGtub3cgb2YuIEkgdGhp bmsgaXTigJlzIGEgZ29vZCBpZGVhLCBhbmQgbmVlZGVkIGZvciBOQVQgdHJhdmVyc2FsIGluIG1h bnkgY2FzZXMuPGJyPg0KPGJyPg0KLS0mbmJzcDs8YnI+DQpDb2xpbiBQZXJraW5zPGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly9jc3BlcmtpbnMub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY3Nw ZXJraW5zLm9yZy88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B5C69C391ESESSMB109erics_-- From nobody Sun Nov 12 19:49:31 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E071293FD for ; Sun, 12 Nov 2017 19:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 rsDSaG_pzNo5 for ; Sun, 12 Nov 2017 19:49:28 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4458E12932A for ; Sun, 12 Nov 2017 19:49:28 -0800 (PST) X-AuditID: c1b4fb25-da9ff700000020f7-75-5a09164692c4 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4D.40.08439.646190A5; Mon, 13 Nov 2017 04:49:26 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 13 Nov 2017 04:49:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q+g0zVQZur+VtHGU6cjROX5XiFE4rZ3W1M+FmNtk8uQ=; b=k5IRRmxEQYa7M/I2ksAOGsfnbW5Qf+MxPT5QToqgs8LQT/ksdBc0r63k425hf+jJlOZz63S5Fw3wNRqDAFz3qC3EPxSgcWyb83sl6E62qpBOttcmeIK0gytAeMnzutbGxnOGioo2lG72O4yO8FSHHHMM4yGFDjUDESUeqsEnUyU= Received: from AM4SPR01MB270.eurprd07.prod.outlook.com (10.171.191.143) by AM4PR07MB3251.eurprd07.prod.outlook.com (10.171.189.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 03:49:23 +0000 Received: from AM4SPR01MB270.eurprd07.prod.outlook.com ([fe80::212d:d7d4:12f4:84d6]) by AM4SPR01MB270.eurprd07.prod.outlook.com ([fe80::212d:d7d4:12f4:84d6%13]) with mapi id 15.20.0239.005; Mon, 13 Nov 2017 03:49:23 +0000 From: Bo Burman To: Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] Simulcast and 5576 source attributes? Thread-Index: AQHTWam3m/hZm2SmqUi3bH1y4trDkaMRsXRG Date: Mon, 13 Nov 2017 03:49:23 +0000 Message-ID: References: <58277100-1D4C-44E0-B621-30972D8BBC41@vidyo.com> In-Reply-To: <58277100-1D4C-44E0-B621-30972D8BBC41@vidyo.com> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [95.192.188.130] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3251; 6:eOoeJxZCE50jOJ88ghkB24j3ZsPBFZmVT9Uc+5WLDv8h34F9DpkO2UF9DycOPpMZCp/LUjPNBdldza7mQb9TYmHTHH+j2N9bAZxVLXSt17jnOxOhNWAURHwJFo84LogFczaM+JjebpQMFc+gwxq0p/C0/z/UA+TCqUwGJkY5r7hf5Ypk3W1Zyavvplt1Dr3ZQJV2VQtSn0N/034Q68jnhrjsbSG4FbCrLQCR8Oywe2/oBbMPB9dlURiMSOtfO+YizEoWZsWD15/IDWq6cru/NZVhR0WuozIjaPb7LR32ovvA1Bw6Fu46+ZTTTSIKZoQOR9CN1KrgDyapQMFlwEf0ZraDsDuz3ZeA9/tjFlL9iIA=; 5:kkwBUpkcxHy5eXlP/2JUvzOQi3o84+euil+l0RSrfnid8Nwc5hguzqNb6Kb649/avSn9uFo4cvMMBqX2RY7I2Gv4XrsGHRWcJsCJssaAfXWVBiy2U0eOy4Z++ILd4eIThoDqn0+9w+HCODPqaLYqtQCMvQ9anGjMThQFNBBs4FA=; 24:tzKZCP7en+zEC1Lj85ZQld/y89PLRZZ7s9uXJieeFrPQNoXqq7GgavEOUMG8umFq1S3o4fOQKhvBWNlI9XOP1GruE+gXoTa5BXP81uobtj0=; 7:1YECT0mdPJnFs/dOEY5z1t0cDJ78VIIKZTN4XPHjOVP/OierSXelJAipTJpHkA9z6t4YnKXexiv1xRbgIsTWOtvX+rb+iGN0G4o1BfL9OlP2KQ/4njofGYXXXa/moNNvgESF+zM4XyH6uczWGlpyzMTkbD3jJa++oxuHiNgz2YpxUCeg5bzikvbv/XhoQkOLH6Lhv+x7vvAyeVKozdgGG32uOfyjgZY3l5DrJP+fgIwbKwvTIOdL9BhvKRTmdKPQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c14a350d-2b24-482f-ec3a-08d52a49879b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:AM4PR07MB3251; x-ms-traffictypediagnostic: AM4PR07MB3251: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3231022)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3251; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3251; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(189002)(13464003)(199003)(63666004)(50986999)(6436002)(25786009)(8676002)(53546010)(316002)(966005)(478600001)(33646002)(189998001)(106356001)(110136005)(606006)(68736007)(2950100002)(76176999)(2900100001)(99286004)(81156014)(3846002)(236005)(66066001)(8936002)(54896002)(6246003)(105586002)(53936002)(102836003)(6512007)(7736002)(6116002)(51650200002)(5660300001)(3660700001)(54356999)(229853002)(3280700002)(6306002)(81166006)(5250100002)(97736004)(101416001)(2906002)(6486002)(95246002)(6506006)(86362001)(14454004)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3251; H:AM4SPR01MB270.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_qbfr28fwgrgcelwf0qc3rsl51510544803607emailandroidcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c14a350d-2b24-482f-ec3a-08d52a49879b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 03:49:23.2665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3251 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee7d3e5Wq9t8O1kmzoQwnWYWkiZpaPsS1JewVeTUi4pz2q5J 9ml9Gb4VioX4xkxXqZU5cToikqam5vsrYb4Ml6PSkWQkpVjOZ4Hffvz/5/zPOQ8PTUoaKG86 XZ3DatRKlZQv4lUkdMiD4z2FitD8Of+IzvoRMuLRMxvvHCE3GH4Tcp19VnCJUIiiUlhVei6r CYlOFKVtrN4js/uO3ulq1hNaVOdbiIQ0MOEw3dVKFiIRLWG6EFj7n/CdhoTpQ/C86IqTecx9 EowDWVgvJ2BsGnCDDYH2oZ1yGnzmGOjNc8jJ7kws9FQ3bqfStBsTCd1DcixHwd+NJT7mMJgb rCdxfgBYf4zuxIiZeLB3tFN4VhToigcJJwuZs1BWmy9wMmJ8YGF9nudkkvGCtRorgY9hwPBm hMTsAV9tWxSuvwplpUMCrEuhYGaQj9kHxvVFyHkLMBYBlG7ZKGzIwFTqQJgvQsvLL3xcVIFg aniZh41AcPQ/cCVlwHq70TUhEhq/rVK4YZKCqvc9rvUOg226VICNGQqMve1UCQqq3HUGZhWY tYuocuc5DkB/xWce1kPh+7CexHwcnj5ednEIGH8Ood16LRI0IQ+O5ZIyU8NOylhNejLHZall ajanFW3/n3dtGwFmNLESY0EMjaR7xctioUJCKXO5vEwLApqUuou7F2iFRJyizLvLarJuam6r WM6CDtE8qZc45u1ogoRJVeawGSybzWr+uwQt9NaiZHszK+//9Ms3Xldw2dSg3iMzteyLPU0k Sa1/queqRNbXAW1V3vs7br2aCBtbC1YMpzrqdHmLnJ0O6j0lq1moMr84P5nbmCj1v7C5FJ0X TqWWX7+hG5+c8tM6BuKEH0sM12Sds2OZZzYLVj4seZrmG8OLY474HexzMzbFOTIJKY9LU54I JDWc8h8HS2EJOwMAAA== Archived-At: Subject: Re: [MMUSIC] Simulcast and 5576 source attributes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 03:49:31 -0000 --_000_qbfr28fwgrgcelwf0qc3rsl51510544803607emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One "certain case" is when using a 1:1 mapping of rid-id and RTP PT, in com= bination with a 1:1 mapping of SSRC and RTP PT. This would e.g. be: a=3Drid: pt=3D a=3Dssrc: fmtp: a=3Drid: pt=3D a=3Dssrc: fmtp: a=3Dsimulcast:send 1,2 This way, ssrc1 can be known to use rid-id1 and ssrc2 rid-id2, via knowledg= e what RTP PT they use. Therefore, which simulcast stream uses which SSRC i= s also known. Cheers Bo (as individual) -------- Original Message -------- Subject: [MMUSIC] Simulcast and 5576 source attributes? From: Jonathan Lennox Date: 9 nov. 2017 15:25 To: mmusic The latest Simulcast draft (draft-ietf-mmusic-sdp-simulcast-10) has a parag= raph at the end of Section 5.1 that says: It is possible to use source-specific signaling [RFC5576] with "a=3Dsimulcast", but it is only in certain cases possible to learn from that signaling which SSRC will belong to a particular simulcast stream. However, there=92s no other mention of 5576 in the document, and no registr= ation of any 5576-style source-specific attributes. What are the =93certain cases=94? It=92s not clear to me there=92s any way = for the currently-registered 5576 attributes to tell you which SSRC corresp= onds to which simulcast stream, prior to receiving RID in RTCP or header ex= tensions. (Notably, there=92s no rid source attribute.) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_qbfr28fwgrgcelwf0qc3rsl51510544803607emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
One "certain case" is when using a 1:1 mapping o= f rid-id and RTP PT, in combination with a 1:1 mapping of SSRC and RTP PT. = This would e.g. be:
a=3Drid:<rid-id1> pt=3D<pt1>
a=3Dssrc:<ssrc1> fmtp:<pt1>
a=3Drid:<rid-id2> pt=3D<pt2>
a=3Dssrc:<ssrc2> fmtp:<pt2>
a=3Dsimulcast:send 1,2

This way, ssrc1 can be known to use rid-id1 and ssrc2 rid-= id2, via knowledge what RTP PT they use. Therefore, which simulcast stream = uses which SSRC is also known.

Cheers
Bo
(as individual)


-------- Original Message --------
Subject: [MMUSIC] Simulcast and 5576 source attributes?
From: Jonathan Lennox <jonathan@vidyo.com>
Date: 9 nov. 2017 15:25
To: mmusic <mmusic@ietf.org>

The latest Simulcast draft (draft-ietf-mmusic-sdp-simulcast-10) has a parag= raph at the end of Section 5.1 that says:

   It is possible to use source-specific signaling [RFC5576] with=
   "a=3Dsimulcast", but it is only in certain cases pos= sible to learn from
   that signaling which SSRC will belong to a particular simulcas= t
   stream.

However, there=92s no other mention of 5576 in the document, and no registr= ation of any 5576-style source-specific attributes.

What are the =93certain cases=94? It=92s not clear to me there=92s any way = for the currently-registered 5576 attributes to tell you which SSRC corresp= onds to which simulcast stream, prior to receiving RID in RTCP or header ex= tensions.  (Notably, there=92s no rid source attribute.)


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_qbfr28fwgrgcelwf0qc3rsl51510544803607emailandroidcom_-- From nobody Sun Nov 12 22:49:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8996A12949E for ; Sun, 12 Nov 2017 22:49:13 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com 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 4QYIewZ-9gcs for ; Sun, 12 Nov 2017 22:49:06 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B231294A4 for ; Sun, 12 Nov 2017 22:49:06 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id a84so6301645pfl.0 for ; Sun, 12 Nov 2017 22:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LkTHB52oQvfWAWVZspm9HwdnzWsR6ti90K2dt2YficM=; b=RdyN4nQUnRGEcTe0kNc2XVdiMITb3XnE7M6XbVoXFLS6J0yVWIuz3RTf4n552iJn9s pYaqOVUy8pwlUhs+juYZ0ay1C3ijvm6I3bTJACviWVQVhuqhRz4KJ79nyLvOx2b98SJW 2GdvL25Xg4flBxWGBogQh+PESJzo1ugyupWdn9zOtlC7LUKvyKHgIT7cmn2h8ZrPDtiz mMNkWKXrCQK7wVYWu0R3fCMHxf8xqOHGXJn8c8/8RTEqiJOy+l0IOfb52av6wFaol42T sT5KN+bjQCiZqbTW+Ii5gMaIzhym82EKUmLk+TV+dxaWG10osSat95zGy6eyHwHSXKO1 4ShA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LkTHB52oQvfWAWVZspm9HwdnzWsR6ti90K2dt2YficM=; b=dBxCUGXUGFklENKXBtJCo61Vud7qlK+Wp1q/Ing7S3qw57jbalrO1ZgRP2s27ahI+A W2k0kcxImpK6EVzNVIADpl0OIWOeHcCXUkqiFT3Y2VJa3BGlsA+RnwCWA3VK2R/YHLXv 8taL92TACeiCIvGBf5MzsH4K47waQb45PMydATW07M8RAta8cvIMveLXRqRB5nsJLuaK lBu6rqi/E2JxDzE0L8YV10wJ2X2eTL3wQiB9PxEPeOXtB4nKKB12PO7wHrMH6s2m2cW9 Xo0ze/9nf+7iVWWQAz9JGgqgzhtCH18yJmgTOOm6yw1z44Nj2o8RwDcD6qg+kGIYrYaL EFjA== X-Gm-Message-State: AJaThX6hhfpkG9HAbXOEGE7zmk6NaHEE2+LzrJBl9Nt10vUg6Z7IdT4Z WY4WhW05LnV5eNjnfdUQpILtm6g0MEM= X-Google-Smtp-Source: AGs4zMZ1nw8UEaBeJDunIjKNv6QHfNnvyRE63u6rBn//K9hm/uqHoi3rw/wO1h/5cFODbab6n0toog== X-Received: by 10.99.97.76 with SMTP id v73mr7535683pgb.378.1510555745871; Sun, 12 Nov 2017 22:49:05 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:ed0d:3546:761f:c4d5? ([2001:67c:1232:144:ed0d:3546:761f:c4d5]) by smtp.gmail.com with ESMTPSA id t81sm31536650pfg.187.2017.11.12.22.49.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 22:49:05 -0800 (PST) From: Jonathan Lennox Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_831EF181-341C-4D50-BE44-77275AC2860F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 14:49:01 +0800 In-Reply-To: Cc: mmusic To: Bo Burman References: <58277100-1D4C-44E0-B621-30972D8BBC41@vidyo.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] Simulcast and 5576 source attributes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 06:49:13 -0000 --Apple-Mail=_831EF181-341C-4D50-BE44-77275AC2860F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 a=3Dssrc: fmtp: doesn=E2=80=99t constrain what payload types = the SSRC can use; it just gives additional format parameters for that = payload type as applied to that SSRC. (The motivating use case was = H.264 sprop- parameters.) =20 > On Nov 13, 2017, at 11:49 AM, Bo Burman = wrote: >=20 > One "certain case" is when using a 1:1 mapping of rid-id and RTP PT, = in combination with a 1:1 mapping of SSRC and RTP PT. This would e.g. = be: > a=3Drid: pt=3D > a=3Dssrc: fmtp: > a=3Drid: pt=3D > a=3Dssrc: fmtp: > a=3Dsimulcast:send 1,2 >=20 > This way, ssrc1 can be known to use rid-id1 and ssrc2 rid-id2, via = knowledge what RTP PT they use. Therefore, which simulcast stream uses = which SSRC is also known. >=20 > Cheers > Bo=20 > (as individual) >=20 >=20 > -------- Original Message -------- > Subject: [MMUSIC] Simulcast and 5576 source attributes? > From: Jonathan Lennox > > Date: 9 nov. 2017 15:25 > To: mmusic > >=20 > The latest Simulcast draft (draft-ietf-mmusic-sdp-simulcast-10) has a = paragraph at the end of Section 5.1 that says: >=20 > It is possible to use source-specific signaling [RFC5576] with > "a=3Dsimulcast", but it is only in certain cases possible to learn = from > that signaling which SSRC will belong to a particular simulcast > stream. >=20 > However, there=E2=80=99s no other mention of 5576 in the document, and = no registration of any 5576-style source-specific attributes. >=20 > What are the =E2=80=9Ccertain cases=E2=80=9D? It=E2=80=99s not clear = to me there=E2=80=99s any way for the currently-registered 5576 = attributes to tell you which SSRC corresponds to which simulcast stream, = prior to receiving RID in RTCP or header extensions. (Notably, = there=E2=80=99s no rid source attribute.) >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = --Apple-Mail=_831EF181-341C-4D50-BE44-77275AC2860F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
a=3Dssrc:<ssrc> fmtp:<pt> = doesn=E2=80=99t constrain what payload types the SSRC can use; it just = gives additional format parameters for that payload type as applied to = that SSRC.  (The motivating use case was H.264 sprop- parameters.) =  

On Nov 13, 2017, at 11:49 AM, Bo Burman <bo.burman@ericsson.com> wrote:

One "certain case" is when using = a 1:1 mapping of rid-id and RTP PT, in combination with a 1:1 mapping of = SSRC and RTP PT. This would e.g. be:
a=3Drid:<rid-id1> pt=3D<pt1>
a=3Dssrc:<ssrc1> fmtp:<pt1>
a=3Drid:<rid-id2> pt=3D<pt2>
a=3Dssrc:<ssrc2> fmtp:<pt2>
a=3Dsimulcast:send 1,2

This way, ssrc1 can be known to use rid-id1 and ssrc2 = rid-id2, via knowledge what RTP PT they use. Therefore, which simulcast = stream uses which SSRC is also known.

Cheers
Bo 
(as individual)


-------- Original Message --------
Subject: [MMUSIC] Simulcast and 5576 source = attributes?
From: Jonathan Lennox = <jonathan@vidyo.com>
Date: 9 nov. 2017 15:25
To: = mmusic <mmusic@ietf.org>

The latest Simulcast draft = (draft-ietf-mmusic-sdp-simulcast-10) has a paragraph at the end of = Section 5.1 that says:

   It is = possible to use source-specific signaling [RFC5576] with
   "a=3Dsimulcast", but it is only in certain cases = possible to learn from
   that signaling which = SSRC will belong to a particular simulcast
   = stream.

However, there=E2=80=99s no other = mention of 5576 in the document, and no registration of any 5576-style = source-specific attributes.

What are the = =E2=80=9Ccertain cases=E2=80=9D? It=E2=80=99s not clear to me there=E2=80=99= s any way for the currently-registered 5576 attributes to tell you which = SSRC corresponds to which simulcast stream, prior to receiving RID in = RTCP or header extensions.  (Notably, there=E2=80=99s no rid source = attribute.)


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

= --Apple-Mail=_831EF181-341C-4D50-BE44-77275AC2860F-- From nobody Mon Nov 13 02:25:00 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBD3129485; Mon, 13 Nov 2017 02:24:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151056869246.21474.36592165547565896@ietfa.amsl.com> Date: Mon, 13 Nov 2017 02:24:52 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 10:24:53 -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 WG of the IETF. Title : RTP Payload Format Restrictions Author : Adam Roach Filename : draft-ietf-mmusic-rid-12.txt Pages : 26 Date : 2017-11-13 Abstract: In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-12 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rid-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-12 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 Mon Nov 13 06:11:13 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3301288B8; Mon, 13 Nov 2017 06:11:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151058226786.652.5844964636658074600@ietfa.amsl.com> Date: Mon, 13 Nov 2017 06:11:07 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-sip-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:11:08 -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 WG of the IETF. Title : A Session Initiation Protocol (SIP) usage for Trickle ICE Authors : Emil Ivov Thomas Stach Enrico Marocco Christer Holmberg Filename : draft-ietf-mmusic-trickle-ice-sip-11.txt Pages : 42 Date : 2017-11-13 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP) and defines a new SIP Info Package. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-11 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-11 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 Mon Nov 13 06:13:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AB212943E for ; Mon, 13 Nov 2017 06:13:36 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RWipDSTlL2cQ for ; Mon, 13 Nov 2017 06:13:29 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499D0127BA3 for ; Mon, 13 Nov 2017 06:13:29 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id e143so18503901lfg.12 for ; Mon, 13 Nov 2017 06:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=/akSWXEJg15uchU9p2+fJ4n8x58TO5aXmexvdiP6aTc=; b=TCC5abRHWNvY7Mohi9i9EVH33kp84qOIqRGmRjq3BMXVUaR3On/256rQK6fz6J0149 ncUvBOhG4wu81d7cLeLFlYMq14dONwkGk3BMvi/0N1Vi9lwBbxVTYhoqHc3btT/+NLcu wai58xiD7v63gxfA3BSciMsQD7T2LFFv3c/jIDiBXR1qRe4FGWw8iOB1VnWLZnsj1MN4 xk20Nw2Pfx+00Yra/JdCb+vez+uW0O/OD4o+5vT4X2bd18qRV1k9cgxK70/JkoF2Ma7w H+gr8DKZreBEMUqiXtU42W2edYT6pLwa9skl1Rr+R9624FahD/gWzyJtOjNTcXIRy/KF EPAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/akSWXEJg15uchU9p2+fJ4n8x58TO5aXmexvdiP6aTc=; b=rXM7RwYf7W99MIfZ7V5hpddRFFNTnUqzA0xMzXVfX1HLxfe8c+XWSUS//f9FncCKEG I276WUxG8Q5GrrnNsqLld1rM4xhVwuYZR37wGVP+47hqnXvzCmeiGji20cyoCoobrap7 F9dge/J+PydFqHc6Xe0bcaEJOd4UWkMxfhHoDlUwqwsPtgMuCFTyAlgGKyRwztkS58H4 9UeV+ZSm/8Kzt1A8uJmi6xX0HAI0dOjB8kBXb/qOxsgvgonbMiaZ3gFoyj1BoTJe5LZ2 75I/5hPgSc8zrKv23u+73yoocqv13zJzPlx9oItqzbZ04kPjEoYhEgO+olEXmKg9Rn0E 6VCQ== X-Gm-Message-State: AJaThX6iq0KvmXE/aGJvSV4jq5Y9oPc3Da0MWQHeWbhBzSZ30FxDoroV TYsSDdd/QdYOKj5HQMsWG5i1ErEo X-Google-Smtp-Source: AGs4zMaoX+m2nDcVbrXVcc4H1ZWrbgTx9nuNbISGHhl/zVIAmPkoSLOpDRRQUWvM5/YVi7yEsrzpyw== X-Received: by 10.25.143.194 with SMTP id s63mr2475627lfk.143.1510582405743; Mon, 13 Nov 2017 06:13:25 -0800 (PST) Received: from [192.168.2.113] (d91-130-23-188.cust.tele2.at. [91.130.23.188]) by smtp.googlemail.com with ESMTPSA id p15sm3180034lje.24.2017.11.13.06.13.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 06:13:25 -0800 (PST) References: <151058226805.652.4452946201547420614.idtracker@ietfa.amsl.com> To: MMUSIC From: Thomas Stach X-Forwarded-Message-Id: <151058226805.652.4452946201547420614.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 13 Nov 2017 15:13:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <151058226805.652.4452946201547420614.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 14:13:36 -0000 All, this is just an update to satisfy idnits as can be seen from the Diff:-URL below. Kind regards Thomas -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-11.txt Date: Mon, 13 Nov 2017 06:11:08 -0800 From: internet-drafts@ietf.org To: Christer Holmberg , Enrico Marocco , Thomas Stach , Emil Ivov A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-11.txt has been successfully submitted by Thomas Stach and posted to the IETF repository. Name: draft-ietf-mmusic-trickle-ice-sip Revision: 11 Title: A Session Initiation Protocol (SIP) usage for Trickle ICE Document date: 2017-11-13 Group: mmusic Pages: 42 URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-11.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-11 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip-11 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-11 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP) and defines a new SIP Info Package. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Nov 13 09:40:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436E1129B23 for ; Mon, 13 Nov 2017 09:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 SdrrTeJcCrhv for ; Mon, 13 Nov 2017 09:40:54 -0800 (PST) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0C112946B for ; Mon, 13 Nov 2017 09:40:54 -0800 (PST) X-AuditID: 1207440f-a5bff70000007960-19-5a09d92349ca Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id AA.35.31072.329D90A5; Mon, 13 Nov 2017 12:40:52 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vADHeohN006256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 13 Nov 2017 12:40:51 -0500 To: mmusic@ietf.org References: <58277100-1D4C-44E0-B621-30972D8BBC41@vidyo.com> From: Paul Kyzivat Message-ID: Date: Mon, 13 Nov 2017 12:40:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixO6iqKtykzPKYNlSbYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY8uebsaC7YIVHy7dZG5gbOTrYuTgkBAwkZi0xb6LkYtDSGAH k8S3Q7dYIJzvTBLzz8xiASkSFrCWOHLWo4uRk0NEQFhixtu/bCC2kEClxKXVr1hAbDYBLYk5 h/6D2bwC9hJzXxwFs1kEVCVeHO5gArFFBdIk7sx4yARRIyhxcuYTsBpOAXeJplWvwOLMArYS d+buZoawxSVuPZkPFZeXaN46m3kCI/8sJO2zkLTMQtIyC0nLAkaWVYxyiTmlubq5iZk5xanJ usXJiXl5qUW6Jnq5mSV6qSmlmxghIcm/g7FrvcwhRgEORiUeXocrnFFCrIllxZW5hxglOZiU RHlVPrNHCfEl5adUZiQWZ8QXleakFh9ilOBgVhLh/bQOqJw3JbGyKrUoHyYlzcGiJM6rvkTd T0ggPbEkNTs1tSC1CCYrw8GhJME75zpQo2BRanpqRVpmTglCmomDE2Q4D9BwfZAa3uKCxNzi zHSI/ClGY46enht/mDiezXzdwCzEkpeflyolzvsOpFQApDSjNA9uGiytvGIUB3pOmFf0BlAV DzAlwc17BbSKCWiVFMiPvMUliQgpqQZGrb2G3FmatefV1AI2GQW/Urx89PvhBxlV8lOvrtvW qpFp63XBLErt3qdfWi9P1wh+yWQWfq9rr5jxuGSx+0+uSlcFnubzPCElu578MEoKF/GbHhVk 7Sa37cKWudwnrvNvW/Dy7AWHpOv7634G5hfZrq01MW7e+sU4p2992C51lsVmCzdyKe9SYinO SDTUYi4qTgQAGL59sQYDAAA= Archived-At: Subject: Re: [MMUSIC] Simulcast and 5576 source attributes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 17:40:56 -0000 On 11/12/17 10:49 PM, Bo Burman wrote: > One "certain case" is when using a 1:1 mapping of rid-id and RTP PT, in > combination with a 1:1 mapping of SSRC and RTP PT. This would e.g. be: > a=rid: pt= > a=ssrc: fmtp: > a=rid: pt= > a=ssrc: fmtp: > a=simulcast:send 1,2 > > This way, ssrc1 can be known to use rid-id1 and ssrc2 rid-id2, via > knowledge what RTP PT they use. Therefore, which simulcast stream uses > which SSRC is also known. I'm scratching my head trying to figure out how any of this would be helpful in practice. I'm coming up dry. Anything that simply allows you to figure out something in the limited case where the other side uses a particular subset of features in coordination can't be relied upon because you don't know that the situation will arise when you need it. Thanks, Paul > Cheers > Bo > (as individual) > > > -------- Original Message -------- > Subject: [MMUSIC] Simulcast and 5576 source attributes? > From: Jonathan Lennox > Date: 9 nov. 2017 15:25 > To: mmusic > > The latest Simulcast draft (draft-ietf-mmusic-sdp-simulcast-10) has a > paragraph at the end of Section 5.1 that says: > >    It is possible to use source-specific signaling [RFC5576] with >    "a=simulcast", but it is only in certain cases possible to learn from >    that signaling which SSRC will belong to a particular simulcast >    stream. > > However, there’s no other mention of 5576 in the document, and no > registration of any 5576-style source-specific attributes. > > What are the “certain cases”? It’s not clear to me there’s any way for > the currently-registered 5576 attributes to tell you which SSRC > corresponds to which simulcast stream, prior to receiving RID in RTCP or > header extensions.  (Notably, there’s no rid source attribute.) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Nov 13 19:10:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58B6129ACD for ; Mon, 13 Nov 2017 19:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 yqIo6dZjw3I1 for ; Mon, 13 Nov 2017 19:10:23 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE6E124217 for ; Mon, 13 Nov 2017 19:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=329; q=dns/txt; s=iport; t=1510629017; x=1511838617; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=7tQQ/VDLIcoKZC5O3PGri8wwEhZJ2HKAYFzAKQ6KIgU=; b=WheqVjKJXhe9sywmoaMFv0wFpUxRbbHK+rKT0+8TvNW45GYlWsXiAcP1 /2ciTgh2JnMhThEtEFwEEMvOS9/FjywiHffiI5Sp7lKwCrgxRY4i/Hpeu Xt8uh+O4DTpdxl74wWT/Gu3O7bttnulpKV+qaEtjs18T8bRCzsM5FwhJQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAABJXQpa/5RdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1ZG6EJYofjy+BV5Z2ghEKI4l/PxgBAQEBAQEBAQFrKIVIFXY?= =?us-ascii?q?CJgJfDQgBAYoRDRCrJoInixABAQEBBgEBAQEfBYEPgiWCB4FVghILiyKCYwWSe?= =?us-ascii?q?48vh2uNGYF8ARiGCINgh0WMaIk8gTkfOIFyVSUVgx0BAQ+EfCOIfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,392,1505779200"; d="scan'208";a="318399003" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2017 03:10:17 +0000 Received: from [10.82.249.233] (rtp-vpn6-488.cisco.com [10.82.249.233]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAE3AFS8014861 for ; Tue, 14 Nov 2017 03:10:16 GMT To: mmusic From: Flemming Andreasen Message-ID: Date: Mon, 13 Nov 2017 22:10:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MMUSIC] Updated MMUSIC Agenda for Singapore X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 14 Nov 2017 03:10:25 -0000 Please note that we just updated the MMUSIC agenda for the meeting this Thursday: https://datatracker.ietf.org/meeting/100/materials/agenda-100-mmusic/ There are a couple of open issues in the simulcast draft which require discussion. You should see an e-mail with further detail later today. Thanks -- Flemming From nobody Mon Nov 13 19:37:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00F3128C84 for ; Mon, 13 Nov 2017 19:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 V4yl5Q_Jeh18 for ; Mon, 13 Nov 2017 19:37:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBE52127342 for ; Mon, 13 Nov 2017 19:37:27 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0B14479B5166C; Tue, 14 Nov 2017 03:37:25 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 03:37:26 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 11:37:22 +0800 From: Roni Even To: Jonathan Lennox , Bo Burman CC: mmusic Thread-Topic: [MMUSIC] Simulcast and 5576 source attributes? Thread-Index: AQHTXEuRh+eXA8dV/UujXHEiqe0+nKMTOXMw Date: Tue, 14 Nov 2017 03:37:21 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD83698E@DGGEMM506-MBX.china.huawei.com> References: <58277100-1D4C-44E0-B621-30972D8BBC41@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.38.9] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD83698EDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [MMUSIC] Simulcast and 5576 source attributes? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 14 Nov 2017 03:37:31 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD83698EDGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSB0ZXh0IGluIDA2IHdhcyAiIEl0IGlzIHBvc3NpYmxlLCBidXQgbm90IHJlcXVp cmVkIHRvIHVzZSBzb3VyY2Utc3BlY2lmaWMgc2lnbmFsaW5nDQoNCiAgICAgIFtSRkM1NTc2XSB3 aXRoIHRoZSBwcm9wb3NlZCBzb2x1dGlvbi4iDQoNCkkgbWFkZSB0aGUgY29tbWVudCBhdCB0aGUg dGltZSBhYm91dCBpZGVudGlmeWluZyB3aGljaCBTU1JDIGlzIHJlbGF0ZWQgdG8gZWFjaCBzaW11 bGNhc3Qgc3RyZWFtLiBUaGUgY3VycmVudCB0ZXh0IHRyaWVkIHRvIGFkZHJlc3MgbXkgY29tbWVu dCBpbiAwNw0KDQpJIGFncmVlIHdpdGggSm9uYXRoYW4gaGVyZS4gICBOb3RlIHRoZSBTU1JDIG1h eSBjaGFuZ2UgaW4gdGhlIFJUUCBkdWUgdG8gY29sbGlzaW9uIGZvciBleGFtcGxlLg0KDQpCVFc6 ICByZXBlYXRpbmcgbXlzZWxmLCB0aGlzIGlzIHdoYXQgd2UgdHJpZWQgdG8gYWRkcmVzcyBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZXZlbi1tbXVzaWMtYXBwbGljYXRpb24t dG9rZW4tMDMgIHNlZSBzZWN0aW9uIDUNCg0KUm9uaQ0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzpt bXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbmF0aGFuIExlbm5veA0KU2Vu dDog15nXldedINeRIDEzINeg15XXkdee15HXqCAyMDE3IDA4OjQ5DQpUbzogQm8gQnVybWFuDQpD YzogbW11c2ljDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gU2ltdWxjYXN0IGFuZCA1NTc2IHNvdXJj ZSBhdHRyaWJ1dGVzPw0KDQphPXNzcmM6PHNzcmM+IGZtdHA6PHB0PiBkb2VzbuKAmXQgY29uc3Ry YWluIHdoYXQgcGF5bG9hZCB0eXBlcyB0aGUgU1NSQyBjYW4gdXNlOyBpdCBqdXN0IGdpdmVzIGFk ZGl0aW9uYWwgZm9ybWF0IHBhcmFtZXRlcnMgZm9yIHRoYXQgcGF5bG9hZCB0eXBlIGFzIGFwcGxp ZWQgdG8gdGhhdCBTU1JDLiAgKFRoZSBtb3RpdmF0aW5nIHVzZSBjYXNlIHdhcyBILjI2NCBzcHJv cC0gcGFyYW1ldGVycy4pDQoNCk9uIE5vdiAxMywgMjAxNywgYXQgMTE6NDkgQU0sIEJvIEJ1cm1h biA8Ym8uYnVybWFuQGVyaWNzc29uLmNvbTxtYWlsdG86Ym8uYnVybWFuQGVyaWNzc29uLmNvbT4+ IHdyb3RlOg0KDQpPbmUgImNlcnRhaW4gY2FzZSIgaXMgd2hlbiB1c2luZyBhIDE6MSBtYXBwaW5n IG9mIHJpZC1pZCBhbmQgUlRQIFBULCBpbiBjb21iaW5hdGlvbiB3aXRoIGEgMToxIG1hcHBpbmcg b2YgU1NSQyBhbmQgUlRQIFBULiBUaGlzIHdvdWxkIGUuZy4gYmU6DQphPXJpZDo8cmlkLWlkMT4g cHQ9PHB0MT4NCmE9c3NyYzo8c3NyYzE+IGZtdHA6PHB0MT4NCmE9cmlkOjxyaWQtaWQyPiBwdD08 cHQyPg0KYT1zc3JjOjxzc3JjMj4gZm10cDo8cHQyPg0KYT1zaW11bGNhc3Q6c2VuZCAxLDINCg0K VGhpcyB3YXksIHNzcmMxIGNhbiBiZSBrbm93biB0byB1c2UgcmlkLWlkMSBhbmQgc3NyYzIgcmlk LWlkMiwgdmlhIGtub3dsZWRnZSB3aGF0IFJUUCBQVCB0aGV5IHVzZS4gVGhlcmVmb3JlLCB3aGlj aCBzaW11bGNhc3Qgc3RyZWFtIHVzZXMgd2hpY2ggU1NSQyBpcyBhbHNvIGtub3duLg0KDQpDaGVl cnMNCkJvDQooYXMgaW5kaXZpZHVhbCkNCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LS0tLQ0KU3ViamVjdDogW01NVVNJQ10gU2ltdWxjYXN0IGFuZCA1NTc2IHNvdXJjZSBhdHRyaWJ1 dGVzPw0KRnJvbTogSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpv bmF0aGFuQHZpZHlvLmNvbT4+DQpEYXRlOiA5IG5vdi4gMjAxNyAxNToyNQ0KVG86IG1tdXNpYyA8 bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Pg0KDQpUaGUgbGF0ZXN0IFNp bXVsY2FzdCBkcmFmdCAoZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0xMCkgaGFzIGEg cGFyYWdyYXBoIGF0IHRoZSBlbmQgb2YgU2VjdGlvbiA1LjEgdGhhdCBzYXlzOg0KDQogICBJdCBp cyBwb3NzaWJsZSB0byB1c2Ugc291cmNlLXNwZWNpZmljIHNpZ25hbGluZyBbUkZDNTU3Nl0gd2l0 aA0KICAgImE9c2ltdWxjYXN0IiwgYnV0IGl0IGlzIG9ubHkgaW4gY2VydGFpbiBjYXNlcyBwb3Nz aWJsZSB0byBsZWFybiBmcm9tDQogICB0aGF0IHNpZ25hbGluZyB3aGljaCBTU1JDIHdpbGwgYmVs b25nIHRvIGEgcGFydGljdWxhciBzaW11bGNhc3QNCiAgIHN0cmVhbS4NCg0KSG93ZXZlciwgdGhl cmXigJlzIG5vIG90aGVyIG1lbnRpb24gb2YgNTU3NiBpbiB0aGUgZG9jdW1lbnQsIGFuZCBubyBy ZWdpc3RyYXRpb24gb2YgYW55IDU1NzYtc3R5bGUgc291cmNlLXNwZWNpZmljIGF0dHJpYnV0ZXMu DQoNCldoYXQgYXJlIHRoZSDigJxjZXJ0YWluIGNhc2Vz4oCdPyBJdOKAmXMgbm90IGNsZWFyIHRv IG1lIHRoZXJl4oCZcyBhbnkgd2F5IGZvciB0aGUgY3VycmVudGx5LXJlZ2lzdGVyZWQgNTU3NiBh dHRyaWJ1dGVzIHRvIHRlbGwgeW91IHdoaWNoIFNTUkMgY29ycmVzcG9uZHMgdG8gd2hpY2ggc2lt dWxjYXN0IHN0cmVhbSwgcHJpb3IgdG8gcmVjZWl2aW5nIFJJRCBpbiBSVENQIG9yIGhlYWRlciBl eHRlbnNpb25zLiAgKE5vdGFibHksIHRoZXJl4oCZcyBubyByaWQgc291cmNlIGF0dHJpYnV0ZS4p DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1t dXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_6E58094ECC8D8344914996DAD28F1CCD83698EDGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYu TXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlRoZSB0ZXh0IGluIDA2IHdhcyAmcXVvdDsgSXQgaXMgcG9zc2li bGUsIGJ1dCBub3QgcmVxdWlyZWQgdG8gdXNlIHNvdXJjZS1zcGVjaWZpYyBzaWduYWxpbmc8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBbUkZDNTU3Nl0gd2l0aCB0aGUgcHJvcG9zZWQgc29sdXRpb24uJnF1b3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIG1hZGUgdGhlIGNvbW1lbnQg YXQgdGhlIHRpbWUgYWJvdXQgaWRlbnRpZnlpbmcgd2hpY2ggU1NSQyBpcyByZWxhdGVkIHRvIGVh Y2ggc2ltdWxjYXN0IHN0cmVhbS4gVGhlIGN1cnJlbnQgdGV4dCB0cmllZCB0byBhZGRyZXNzIG15 IGNvbW1lbnQgaW4gMDcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGggSm9uYXRoYW4gaGVyZS4gJm5ic3A7Jm5i c3A7Tm90ZSB0aGUgU1NSQyBtYXkgY2hhbmdlIGluIHRoZSBSVFAgZHVlIHRvIGNvbGxpc2lvbiBm b3IgZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJUVzogJm5ic3A7cmVwZWF0aW5nIG15c2VsZiwgdGhpcyBp cyB3aGF0IHdlIHRyaWVkIHRvIGFkZHJlc3MgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1ldmVuLW1tdXNpYy1hcHBsaWNhdGlvbi10b2tlbi0wMyI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWV2ZW4tbW11c2ljLWFwcGxpY2F0aW9uLXRva2Vu LTAzPC9hPiAmbmJzcDtzZWUgc2VjdGlvbiA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb25hdGhhbiBMZW5ub3g8YnI+DQo8 Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV150mbmJzcDvXkSAxMyDX oNeV15HXnteR16ggMjAxNyAwODo0OTwvc3Bhbj48YnI+DQo8Yj5Ubzo8L2I+IEJvIEJ1cm1hbjxi cj4NCjxiPkNjOjwvYj4gbW11c2ljPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBT aW11bGNhc3QgYW5kIDU1NzYgc291cmNlIGF0dHJpYnV0ZXM/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmE9c3NyYzombHQ7c3NyYyZndDsgZm10 cDombHQ7cHQmZ3Q7IGRvZXNu4oCZdCBjb25zdHJhaW4gd2hhdCBwYXlsb2FkIHR5cGVzIHRoZSBT U1JDIGNhbiB1c2U7IGl0IGp1c3QgZ2l2ZXMgYWRkaXRpb25hbCBmb3JtYXQgcGFyYW1ldGVycyBm b3IgdGhhdCBwYXlsb2FkIHR5cGUgYXMgYXBwbGllZCB0byB0aGF0IFNTUkMuICZuYnNwOyhUaGUg bW90aXZhdGluZyB1c2UgY2FzZSB3YXMgSC4yNjQgc3Byb3AtIHBhcmFtZXRlcnMuKSAmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDEz LCAyMDE3LCBhdCAxMTo0OSBBTSwgQm8gQnVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86Ym8uYnVy bWFuQGVyaWNzc29uLmNvbSI+Ym8uYnVybWFuQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uZSAmcXVvdDtjZXJ0YWluIGNhc2UmcXVvdDsgaXMg d2hlbiB1c2luZyBhIDE6MSBtYXBwaW5nIG9mIHJpZC1pZCBhbmQgUlRQIFBULCBpbiBjb21iaW5h dGlvbiB3aXRoIGEgMToxIG1hcHBpbmcgb2YgU1NSQyBhbmQgUlRQIFBULiBUaGlzIHdvdWxkIGUu Zy4gYmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YT1yaWQ6Jmx0O3JpZC1pZDEm Z3Q7IHB0PSZsdDtwdDEmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YT1zc3Jj OiZsdDtzc3JjMSZndDsgZm10cDombHQ7cHQxJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmE9cmlkOiZsdDtyaWQtaWQyJmd0OyBwdD0mbHQ7cHQyJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPmE9c3NyYzombHQ7c3NyYzImZ3Q7IGZtdHA6Jmx0O3B0MiZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5hPXNpbXVsY2FzdDpzZW5kIDEsMjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMg d2F5LCBzc3JjMSBjYW4gYmUga25vd24gdG8gdXNlIHJpZC1pZDEgYW5kIHNzcmMyIHJpZC1pZDIs IHZpYSBrbm93bGVkZ2Ugd2hhdCBSVFAgUFQgdGhleSB1c2UuIFRoZXJlZm9yZSwgd2hpY2ggc2lt dWxjYXN0IHN0cmVhbSB1c2VzIHdoaWNoIFNTUkMgaXMgYWxzbyBrbm93bi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DaGVlcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CbzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4oYXMg aW5kaXZpZHVhbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLS0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0 OiBbTU1VU0lDXSBTaW11bGNhc3QgYW5kIDU1NzYgc291cmNlIGF0dHJpYnV0ZXM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTogSm9uYXRoYW4gTGVubm94ICZsdDs8YSBocmVm PSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhdGU6IDkgbm92LiAyMDE3IDE1OjI1PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86IG1tdXNpYyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpUaGUgbGF0ZXN0IFNpbXVsY2FzdCBk cmFmdCAoZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0xMCkgaGFzIGEgcGFyYWdyYXBo IGF0IHRoZSBlbmQgb2YgU2VjdGlvbiA1LjEgdGhhdCBzYXlzOjxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyBJdCBpcyBwb3NzaWJsZSB0byB1c2Ugc291cmNlLXNwZWNpZmljIHNpZ25hbGluZyBbUkZD NTU3Nl0gd2l0aDxicj4NCiZuYnNwOyZuYnNwOyAmcXVvdDthPXNpbXVsY2FzdCZxdW90OywgYnV0 IGl0IGlzIG9ubHkgaW4gY2VydGFpbiBjYXNlcyBwb3NzaWJsZSB0byBsZWFybiBmcm9tPGJyPg0K Jm5ic3A7Jm5ic3A7IHRoYXQgc2lnbmFsaW5nIHdoaWNoIFNTUkMgd2lsbCBiZWxvbmcgdG8gYSBw YXJ0aWN1bGFyIHNpbXVsY2FzdDxicj4NCiZuYnNwOyZuYnNwOyBzdHJlYW0uPGJyPg0KPGJyPg0K SG93ZXZlciwgdGhlcmXigJlzIG5vIG90aGVyIG1lbnRpb24gb2YgNTU3NiBpbiB0aGUgZG9jdW1l bnQsIGFuZCBubyByZWdpc3RyYXRpb24gb2YgYW55IDU1NzYtc3R5bGUgc291cmNlLXNwZWNpZmlj IGF0dHJpYnV0ZXMuPGJyPg0KPGJyPg0KV2hhdCBhcmUgdGhlIOKAnGNlcnRhaW4gY2FzZXPigJ0/ IEl04oCZcyBub3QgY2xlYXIgdG8gbWUgdGhlcmXigJlzIGFueSB3YXkgZm9yIHRoZSBjdXJyZW50 bHktcmVnaXN0ZXJlZCA1NTc2IGF0dHJpYnV0ZXMgdG8gdGVsbCB5b3Ugd2hpY2ggU1NSQyBjb3Jy ZXNwb25kcyB0byB3aGljaCBzaW11bGNhc3Qgc3RyZWFtLCBwcmlvciB0byByZWNlaXZpbmcgUklE IGluIFJUQ1Agb3IgaGVhZGVyIGV4dGVuc2lvbnMuJm5ic3A7IChOb3RhYmx5LCB0aGVyZeKAmXMg bm8gcmlkIHNvdXJjZQ0KIGF0dHJpYnV0ZS4pPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW11c2ljIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD83698EDGGEMM506MBXchina_-- From nobody Mon Nov 13 20:22:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0B128796 for ; Mon, 13 Nov 2017 20:22:43 -0800 (PST) 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 autolearn_force=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 n7ENvnS3T_Oj for ; Mon, 13 Nov 2017 20:22:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD21C127058 for ; Mon, 13 Nov 2017 20:22:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 96DEFB817C9; Mon, 13 Nov 2017 20:22:22 -0800 (PST) To: M.Handley@cs.ucl.ac.uk, van@packetdesign.com, csp@csperkins.org, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, bo.burman@ericsson.com, fandreas@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: block.rxckin.beats@gmail.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171114042222.96DEFB817C9@rfc-editor.org> Date: Mon, 13 Nov 2017 20:22:22 -0800 (PST) Archived-At: Subject: [MMUSIC] [Editorial Errata Reported] RFC4566 (5183) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 14 Nov 2017 04:22:43 -0000 The following errata report has been submitted for RFC4566, "SDP: Session Description Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5183 -------------------------------------- Type: Editorial Reported by: no space before encoding parameter in rtpmap value Section: 6. SDP Attr Original Text ------------- a=rtpmap: / [/] Corrected Text -------------- a=rtpmap: /[/] Notes ----- rtpmap requires format below a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 no space between clock rate and optional parameter Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4566 (draft-ietf-mmusic-sdp-new-26) -------------------------------------- Title : SDP: Session Description Protocol Publication Date : July 2006 Author(s) : M. Handley, V. Jacobson, C. Perkins Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Mon Nov 13 21:04:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6B1286C7 for ; Mon, 13 Nov 2017 21:04:16 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com 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 vEL_UwDqusx4 for ; Mon, 13 Nov 2017 21:04:14 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9215F127876 for ; Mon, 13 Nov 2017 21:04:14 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id 17so13556431pfn.12 for ; Mon, 13 Nov 2017 21:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MGx+tcCseNsedZ7YpRBb0Nqz/nkR+cY9y/PrKm7loYA=; b=jKgXgHStDJdZxEEfiBbV9pgeOCwqdLWImUW/Wc/opuxSqR+Pz4ACRTyMkHjCfFdOWt nZIkpIjHTNHR9X/CGALygjCbyXEDL8W+0cLi+H5Ota/na9aTgynJ/5hdu/K+uZpTvy0G OsJ1sutDPouD0hgyECf9cn9ZJgMDf+5O+vv6kyMdWHN2J5IcEYC9I8Kv2xZ3BBZhGBHW +OAo9U3MJqjG6iyUto+KqQP3TtVb2Lh7X/xFiz94JcVIOstsegK7a009sIpwbOncPu1/ okjS+mh/TfaEmt1zLpf6TILD27hrWCNp2+zClid+VDqsxEq50qjiaOcS8uABUM+I6gBe Gq/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MGx+tcCseNsedZ7YpRBb0Nqz/nkR+cY9y/PrKm7loYA=; b=fvIR03aVHJwx7wUUjhfuFsuZqN4QAy0sSruu9A8pKQDtd7HJiZHdRZhxwb4NEZiUIU 6I3NXD7etai3iW7IJ76YAI+Kul/BsUiB0oI5Hb3yC83cHE72LwSihACtwtL0j0PJAVQ5 VpAhh82Sb+hU8mp+EjjCoFjg1yKZCb0zSz+MqZe2YC6jNm0kAQZmVkQZIArogj46q+ZK WwQtTIvcaUpPIEy/MD2Pk28mOCP/uP+ltNPFnKvLpC8EEe+3fVRbumgXQC3pIvYGfXk/ qL6yH4OO4K3K8P0a2eN3XskYC9F3Hz/s/Rd4YUcQ6uwTKao4VDk7eJDVhFCjEaQAGBae ZCXg== X-Gm-Message-State: AJaThX5cekDpDVSWo6RKqC0/1k36ZuJCBi3W23RS8OY6Vc6D1TwWRB7p cTjuKEsz9H7Lc3y0YOnG5jFZ9Q== X-Google-Smtp-Source: AGs4zMb5z1o/0WJTjRzMQ/Som/DX3b52iAjxl6QF6g+J/0o5PyjTlvgb0rr4WKr7qlc0dARZvH2UdA== X-Received: by 10.99.115.4 with SMTP id o4mr10770511pgc.371.1510635854119; Mon, 13 Nov 2017 21:04:14 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:50f0:96f4:259f:9c4? ([2001:67c:370:128:50f0:96f4:259f:9c4]) by smtp.gmail.com with ESMTPSA id z71sm25844353pfi.172.2017.11.13.21.04.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 21:04:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: "Ali C. Begen" In-Reply-To: <20171114042222.96DEFB817C9@rfc-editor.org> Date: Tue, 14 Nov 2017 13:04:09 +0800 Cc: M.Handley@cs.ucl.ac.uk, Colin Perkins , Ben Campbell , aamelnikov@fastmail.fm, Adam Roach , Bo Burman , Flemming Andreasen , block.rxckin.beats@gmail.com, mmusic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171114042222.96DEFB817C9@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [MMUSIC] [Editorial Errata Reported] RFC4566 (5183) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 14 Nov 2017 05:04:16 -0000 The reported error is correct, but does not exist in 4566bis which is = WGLC=E2=80=99ed already and getting ready for publication. -acbegen > On Nov 14, 2017, at 12:22 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC4566, > "SDP: Session Description Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5183 >=20 > -------------------------------------- > Type: Editorial > Reported by: no space before encoding parameter in rtpmap value = >=20 > Section: 6. SDP Attr >=20 > Original Text > ------------- > a=3Drtpmap: / [/ parameters>] >=20 > Corrected Text > -------------- > a=3Drtpmap: /[/ parameters>] >=20 > Notes > ----- > rtpmap requires format below >=20 > a=3Drtpmap:97 L16/8000 > a=3Drtpmap:98 L16/11025/2 >=20 > no space between clock rate and optional parameter >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4566 (draft-ietf-mmusic-sdp-new-26) > -------------------------------------- > Title : SDP: Session Description Protocol > Publication Date : July 2006 > Author(s) : M. Handley, V. Jacobson, C. Perkins > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Nov 13 23:13:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C880E128961 for ; Mon, 13 Nov 2017 23:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 OoySgxbEtHAQ for ; Mon, 13 Nov 2017 23:13:47 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D8A124BE8 for ; Mon, 13 Nov 2017 23:13:46 -0800 (PST) X-AuditID: c1b4fb2d-f0bff70000001e3d-7c-5a0a97a997f6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.8B.07741.9A79A0A5; Tue, 14 Nov 2017 08:13:45 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Tue, 14 Nov 2017 08:13:45 +0100 From: Christer Holmberg To: mmusic Thread-Topic: BUNDLE: moving an m- section from one bundle group to another Thread-Index: AdNdF/u9Xd8OPZWMTQKEgp1GLQD/jw== Date: Tue, 14 Nov 2017 07:13:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C6A0F6C@ESESSMB109.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B5C6A0F6CESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7hO7K6VxRBi/uS1pMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGfMndLEX/FCqmD1nAksD4yq5LkZODgkBE4l1zxcydTFycQgJ HGaU+L/vNwuEs5hRYnLjZSCHg4NNwEKi+582SIOIgIzE3k2bmUFsYQE3iT8ne1hBSkQEvCUW 7ayBKNGT6F57mB3EZhFQlZhz7T6YzSvgK7H/3V4wm1FATOL7qTVMIDazgLjErSfzmSDuEZBY suc8M4QtKvHy8T9WCFtJYtHtz1D1+RKH1s6FmikocXLmE5YJjIKzkIyahaRsFpIyiLiOxILd n9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMPAPbvmt u4Nx9WvHQ4wCHIxKPLyzJ3FFCbEmlhVX5h5ilOBgVhLhDQkGCvGmJFZWpRblxxeV5qQWH2KU 5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cC4gsV+c9oMTam7W8/HLrGJub5bTlSH6XD4 FJ7Vh/isjdwcCsXu/Fl/wHbOqbct8r3nv4RnTM8UuCzqeWnn4YVf7N9pSm6aulzowO1lyye0 tuZKqD5yXp+QoGBlYdwixVo2W6EsflqYmLtAbjHnQhvpXf9fC1/XjtRe3PWiO3J7p5qitqfL violluKMREMt5qLiRAAA1ar0eAIAAA== Archived-At: Subject: [MMUSIC] BUNDLE: moving an m- section from one bundle group to another X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 14 Nov 2017 07:13:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B5C6A0F6CESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One open issue related to BUNDLE that was discussed sometimes ago (there wa= s also an GitHub issue related to the same issue) is how the BUNDLE address= is affected if m- sections are moved between multiple BUNDLE groups (read:= the identification-tag of an m- line is moved from one SDP group attribute= to another). I have created a PR which clarifies that a BUNDLE address is never "owned" = by a BUNDLE group - the BUNDLE address is always represented by the first m= - section within a group list. https://github.com/cdh4u/draft-sdp-bundle/pull/43 This is the last open issue I am aware of. So, once the PR is merged I inte= nd to submit a new version of the draft, and hopefully we can then move it = forward. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B5C6A0F6CESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One open issue related to BUNDLE that was discussed = sometimes ago (there was also an GitHub issue related to the same issue) is= how the BUNDLE address is affected if m- sections are moved between multip= le BUNDLE groups (read: the identification-tag of an m- line is moved from one SDP group attribute to another).

 

I have created a PR which clarifies that a BUNDLE ad= dress is never “owned” by a BUNDLE group – the BUNDLE add= ress is always represented by the first m- section within a group list.

 

https://github.com/cdh4u/draft-s= dp-bundle/pull/43

 

This is the last open issue I am aware of. So, once = the PR is merged I intend to submit a new version of the draft, and hopeful= ly we can then move it forward.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B5C6A0F6CESESSMB109erics_-- From nobody Tue Nov 14 05:16:32 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B862A12025C; Tue, 14 Nov 2017 05:16:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Flemming Andreasen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, iesg-secretary@ietf.org, mmusic@ietf.org Message-ID: <151066539175.5874.13665750740773132354.idtracker@ietfa.amsl.com> Date: Tue, 14 Nov 2017 05:16:31 -0800 Archived-At: Subject: [MMUSIC] Publication has been requested for draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 13:16:32 -0000 Flemming Andreasen has requested publication of draft-ietf-mmusic-trickle-ice-sip-11 as Proposed Standard on behalf of the MMUSIC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ From nobody Tue Nov 14 18:09:49 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1622129485; Tue, 14 Nov 2017 18:09:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Flemming Andreasen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, iesg-secretary@ietf.org, mmusic@ietf.org, Flemming Andreasen Message-ID: <151071178878.26053.337341224248650779.idtracker@ietfa.amsl.com> Date: Tue, 14 Nov 2017 18:09:48 -0800 Archived-At: Subject: [MMUSIC] Publication has been requested for draft-ietf-mmusic-rid-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:09:49 -0000 Flemming Andreasen has requested publication of draft-ietf-mmusic-rid-12 as Proposed Standard on behalf of the MMUSIC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ From nobody Wed Nov 15 00:32:09 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1E8128B27 for ; Wed, 15 Nov 2017 00:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qKXhHAR3q0bt for ; Wed, 15 Nov 2017 00:32:01 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C5C126C0F for ; Wed, 15 Nov 2017 00:32:00 -0800 (PST) X-AuditID: c1b4fb3a-039e19c000004c48-5f-5a0bfb7fac78 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.B3.19528.F7BFB0A5; Wed, 15 Nov 2017 09:31:59 +0100 (CET) Received: from [100.94.52.217] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 09:31:37 +0100 To: IETF MMUSIC WG From: Magnus Westerlund Message-ID: Date: Wed, 15 Nov 2017 16:33:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060006080402030603090906" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM2K7k279b+4ogwvrBC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBMty5kLdpdVPNzRydTAeCe9i5GTQ0LAROL48yuMXYxcHEIC hxklZkyYzQThbGKU2PhtGTtIlYiAisS/dw/YQGw2AQuJmz8awWxhAXOJy5/fMILYvAL2Eg/6 QJo5OVgEVCXezL8FViMqECMx8cFFqBpBiZMzn7CALGAW6GaUaF9/ihUkISSgLdHQ1MEKcZKS xPV511kmMPLOQtIzC1kPSIJZwFbiztzdzBC2tsSyha+hbHGJpi8roWqsJWb8OsgGYStKTOl+ yA5hm0q8PvqREcI2kni3p5F9ASPnKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAgD645bfV DsaDzx0PMQpwMCrx8C55xR0lxJpYVlyZe4hRBWjOow2rLzBKseTl56UqifAm9wOleVMSK6tS i/Lji0pzUosPMUpzsCiJ83qIAKUE0hNLUrNTUwtSi2CyTBycUg2MVaENS31Yf7zo8d2amOtw /MXr3m99YQe++M1s0mvwKdFMELijdiXNNOR7oJG4TkS2x8ddYaKHr/qtEbiwPbaujH3d7W9V SnMVVvWbLFx+KnbpdKtAm/nrXhpkzvikIWPlYnXRf51uY1nV7WBFYd2DXDfvOu3dfOrAWrkI h50CLZ57/rjHMOYrsRRnJBpqMRcVJwIAlgnOn3ACAAA= Archived-At: Subject: [MMUSIC] Summary of issues to be discussed in MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 15 Nov 2017 08:32:08 -0000 --------------ms060006080402030603090906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB WG, This email is to summarize the issues that has been noted the last=20 couple of week related to Simulcast (draft-ietf-mmusic-sdp-simulcast-10) = and RID (draft-ietf-mmusic-rid-12). These issues and suggested=20 resolution will be discussed tomorrow in the MMUSIC WG session. Jonathan = Lennox, Mo Zanaty and I have discussed this issue off-line here in=20 Singapore, and gotten input from Adam Roach and Bo Burman. 1. Flemming found this issue in his review for the write-up. Current=20 Simulcast draft says: In those cases, such "related" formats MUST NOT be defined as having=20 their own rid-id listed explicitly in the attribute parameters, since=20 they are not strictly simulcast streams of the media source, but rather=20 a specific way of generating the RTP stream of a single simulcast stream = with varying RTP payload type. Flemming noted this as problematic. We agree that this is problematic,=20 and all formats that may be used to fulfil the restriction needs to be=20 listed in the PT parameter in the RID attribute. Thus the above text=20 should be removed from simulcast. We also noticed that the text in=20 MMUSIC RID on this topic could be clearer. Thus, we also suggest that=20 MMUSIC RID is updated in Section 4: OLD: The optional "pt=3D" lists one or more PT values that can = be used in the associated RTP Stream. If the "a=3Drid" attribute contains= =20 no "pt", then any of the PT values specified in the corresponding "m=3D" = line may be used. NEW: The optional "pt=3D" lists one or more PT values that can = be used in the associated RTP Stream. If 'pt=3D' is present,=20 then the RTP sender MUST NOT send any unlisted payload type in the=20 associated RTP Stream. If the "a=3Drid" attribute contains no "pt", then = any of the PT values specified in the corresponding "m=3D" line may be us= ed. 2. This issue is closely related to 1, and was found in discussion of 1. = So when using formats like RED that will use one payload type for itself = and have one or more payload types that are encapsulated, there are a=20 real difference between only including the RED payload type and=20 including both the RED payload type and the encapsulated payload types.=20 The first would mean only RED payloads will be sent, but can contain=20 these encapsulated payloads as indicated by the RED payload types a=3Dfmt= p=20 line. For the second, one can send either RED or the encapsulated codecs = stand alone. The above may not be that clear, even if with the issue 1 text changes=20 it should be clearer. Therefore we propose that an example is added for=20 RED after Issue 1 text to avoid and confusion on this in the future. We=20 have not yet written that text proposal. 3.=A0 This issue is another that was noted in the discussion. Section 4 o= f=20 MMUSIC RID states: Implementations that use the "a=3Drid" parameter in SDP and that make use= =20 of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or=A0=A0 FEC = [RFC5109] [I-D.ietf-payload-flexible-fec-scheme], for any of the source=20 RTP streams that have "a=3Drid" lines remaining after applying the rules = in Section 6 and its subsections, MUST support and use=20 RepairedRtpStreamId SDES item described in [I-D.ietf-avtext-rid] for=20 those redundancy RTP streams. The issue with this text is that it mandates USE of RepairedRtpStreamId. = However, if draft-ietf-payload-flexible-fec-scheme is used, it can=20 perform FEC operations across packets from multiple SSRCs.=20 RepairedStreamID can only point to a single RID. Thus,=20 RepairedRtpStreamId can't be used in some cases. Nor is it actually=20 needed, as the Flex FEC does the reference to the source packets=20 internally in each repair packet. Therefore, we propose to change the=20 text in MMUSIC RID to allow exceptions: Implementations that use the "a=3Drid" parameter in SDP and that make use= =20 of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or FEC=20 [RFC5109], for any of the source RTP streams that have "a=3Drid" lines=20 remaining after applying the rules in Section 6 and its subsections,=20 MUST support and use RepairedRtpStreamId SDES item described in=20 [I-D.ietf-avtext-rid] for those redundancy RTP streams when applicable.=20 Use is not applicable for redundancy formats that directly associate RTP = streams using SSRCs within RTP, an example of such a mechanism is=20 [I-D.ietf-payload-flexible-fec-scheme] or other cases that=20 RepairedRtpSteamId can't support. 4.=A0 Another issue related to redundancy streams is that if one has=20 dynamic mapping of RID to SSRCs, i.e. a given RID may be fulfilled by=20 different SSRCs at different times. The change of SSRC for a RID value=20 may create an issue for any redundancy stream with correct association.=20 This is due to the indirection that is created by the chain RepairStream = (SSRC-R) has RepairedStreamId=3DA that points to RID=3DA that is bound fi= rst=20 to SSRC-A, but then changed to SSRC-B. Thus, at the time of change of=20 the SSRC, it is possible that the wrong source flow is referenced. Due=20 to racing update of references. This type of issue can't arise in=20 redundancy solutions that directly reference its source RTP packet(s)=20 using SSRC and sequence number. Proposal is that MMUSIC RID needs to note this issue and be clear that=20 redundancy mechanism that directly indicate the SSRC and sequence of the = source packets will avoid this issue. The text has not yet been written. 5. The Simulcast draft authors has noted that the examples in simulcast=20 have some short comings in using RID restrictions, and show examples=20 with redundancy and related streams. The authors intend to propose some=20 additional examples to better cover the space of possibilities. There=20 are already more complex examples in draft-ietf-rtcweb-sdp, maybe=20 possible to borrow from there and focus them on simulcast. 6. Jonathan Lennox asked about the below paragraph in Section 5.1 of=20 simulcast: It is possible to use source-specific signaling [RFC5576] with=20 "a=3Dsimulcast", but it is only in certain cases possible to learn from=20 that signaling which SSRC will belong to a particular simulcast stream. So, in general a=3DSSRC and a=3Drid are independent from each other. If t= he=20 a=3Dssrc actually include a=3Dfmtp line with a PT that is in a RID lilne = it=20 would be possible to link them currently. However, the only RTP Payload=20 format that has source specific parameters are H.265. Our conclusion is=20 that this text is not really necessary in Simulcast, thus we propose to=20 remove it. There is a question if this properties need any mention in MMUSIC RID or = can be ignored? 7. In our offline discussion we also noted there are a feature parity=20 difference when it comes to possibility to perform binding information=20 to SSRCs in SDP Signalling. So the MID in an media description is bound=20 to the SSRC due the presence of the a=3DSSRC attribute within the MID=20 labelled. However, the corresponding possibility is not defined for RID. = So, it is not strictly need as the RTP header extension and RTCP SDES=20 item for RID ensures that we have a working solution. The short coming=20 is the possibility to do early binding of RID to SSRC in cases where RID = will be statically bound to the SSRC. Note that RID in a=3Dssrc is not=20 sufficient as a general solution, as it can't handle the dynamic RID=20 mapping cases as well as the signalling race condition that exist when=20 Answers include new SSRCs. So defining how RID is included in a=3Dssrc is= =20 an optimization for a sub-set of the possible usages. As we understand it adding this would mean a new section in MMUSIC RID=20 defining a new source specific parameter for RID, how its relate to any=20 inband updates of RID, and a IANA section entry to add it to the=20 registry. So this is likely in total 1 page of text. Or as an=20 alternative way to implement would be to have this in its own document.=20 But, then the support of this feature needs to be specified separately=20 or be truly optional. Thus, we really like to discuss this. The people discussing it so far=20 has been very split about this. That was all the issues, so please consider them and we will go through=20 and discuss them tomorrow in MMUSIC WG session at 13:30 here in Singapore= =2E Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms060006080402030603090906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzExMTUwODMzMzJaMC8GCSqGSIb3DQEJBDEiBCBaOAFt+dXVoaaP4xNN 0GsVk7mYXyskFCvMUA0cz01YBzBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAOnwaUrf5s4T+TCW9SFvT3TEmbByw4OOkCtb6b9R/E7Jk1oAb JYQmLYPYPKZ7jaPkLJggX+QjS/99D5PRjrF+fS8GI/FsfHAq7D6UUrnJbnEK1dKjv0XHKLvr /+QlyzOmNEKJaIo+9CwP09Z7dkqIrs0IrPmRMjGrOPu9HEOW5E3aAUbPHv795nf4eeDdCwJa VUNp4ZRFcUD2o0xV5AbATHDCUBfDzElODMQcqfJBCMa5IvpG/O9kIp1mW2y2o/6PQYGt/vYZ +ZNcOkhauz/paOvb7Qg8AcYYcZpVJf/KHyece8uaAoqW4hVcykhLrru5f13aOzFU49KTHMdx ccgUeAAAAAAAAA== --------------ms060006080402030603090906-- From nobody Wed Nov 15 16:27:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100CA120721 for ; Wed, 15 Nov 2017 16:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 fy6c5DjzVEge for ; Wed, 15 Nov 2017 16:27:46 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29E1120227 for ; Wed, 15 Nov 2017 16:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=331; q=dns/txt; s=iport; t=1510792066; x=1512001666; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=3wmAEzFAfXY93Vh38/IwXR0VmPXs39f5p7CwBqzBx54=; b=FfS6g9+5dLN2gWe4i52rwkp5GG7UsbF6oW4jQK8RvIbgKCbddXDUOCUb /d/Cyc4srsfyr/TQOX3GfMgGmQoTKsUHGxONADPXjcWkDZHvE5RjTVm9J Y3Q5WYIflXVZraSvh30Iinp4OHPOXop7tR6LW9dLGqxEJ0IMOSR0n0Efl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQBf2gxa/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG6EJpk/mmsKI4ooQhUBAQEBAQEBAQFrKIVIFXYCJgJfDQg?= =?us-ascii?q?BAYoTDRCpZoIniw8BAQEBBgEBAQEBHgWBD4IlggeBVYISiy6CYwWTBY8yh22NG?= =?us-ascii?q?YF8ARiGCoNgh0WMb4k/gTk1IoF0VSUVgx0BAQ+EfCOLUAEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,401,1505779200"; d="scan'208";a="31512189" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 00:27:46 +0000 Received: from [10.82.178.139] ([10.82.178.139]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAG0RiqU010591 for ; Thu, 16 Nov 2017 00:27:45 GMT To: mmusic From: Flemming Andreasen Message-ID: <056ceab8-ec15-c933-ca39-a6a9a7df735a@cisco.com> Date: Wed, 15 Nov 2017 19:27:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MMUSIC] MMUSIC meeting is at 13:30-15:30 (local time) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 16 Nov 2017 00:27:48 -0000 Please note that the MMUSIC meeting at IETF 100 in Singapore is today (November 16) from 13:30 to 15:30 local time (as shown on the meeting agenda). A previous version of the MMUSIC agenda incorrectly showed a different time. https://datatracker.ietf.org/meeting/100/materials/agenda-100-mmusic/ Thanks -- Flemming From nobody Fri Nov 17 21:40:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B96612711A; Fri, 17 Nov 2017 21:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aZJ2QQmwDgbE; Fri, 17 Nov 2017 21:40:26 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26888124207; Fri, 17 Nov 2017 21:40:25 -0800 (PST) X-AuditID: c1b4fb30-a0dff70000002554-4d-5a0fc7c848d3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C8.95.09556.8C7CF0A5; Sat, 18 Nov 2017 06:40:24 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Sat, 18 Nov 2017 06:40:23 +0100 From: Christer Holmberg To: mmusic CC: RTCWeb IETF Thread-Topic: BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer Thread-Index: AdNgJ0q7n/w0ioPdQOmqfDRPNH59Dw== Date: Sat, 18 Nov 2017 05:40:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2K7uu6J4/xRBs/38FtMXf6YxWLtv3Z2 ByaPJUt+MgUwRnHZpKTmZJalFunbJXBltBw5zFbwQq7iw7pG9gbGc1JdjJwcEgImEqsamhm7 GLk4hAQOM0o07V7BCuEsYZRYN2MVSxcjBwebgIVE9z9tkAYRARmJvZs2M4PYzAKKEl+Wz2cD sYUFkiWW3XjNClGTIdHbcpoZwtaTePDjEFicRUBV4t27JWAjeQV8JV4eUQcJMwqISXw/tYYJ YqS4xK0n85kgbhOQWLLnPDOELSrx8vE/VghbSWLt4e0sEPX5Eh+alrOD2LwCghInZz5hmcAo NAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uTctONjPRSizKT i4vz8/TyUks2MQJj4+CW3wY7GF8+dzzEKMDBqMTDO+sof5QQa2JZcWXuIUYJDmYlEd4Zy/mi hHhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTDOdFUz4uUM KZVg/mEbNct5Ze6cmF5hV61tm6r+iVh7f9otJsYUwMTZdCBV+dei6E3xVpOu3alLKV3ezXOt tU9wq8d7Z8GtHGJ3Wlor9i9y5GVu9uT7wHrfxedTpyLzhVyngGNnz8heSqoL2mh8vvHzUgEv 370rOvWva17vNmmIdWh9u3O2uBJLcUaioRZzUXEiAFedrimJAgAA Archived-At: Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Nov 2017 05:40:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (CC:ing RTCWEB, but please reply on the MMUSIC list) Hi, Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is. Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add wi= thin the same offer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(CC:ing RTCWEB, but please reply on the MMUSIC list)=

 

Hi,

 

Would anyone object to not allowing moving m- sectio= ns between BUNDLE groups within a single O/A transaction? The documentation= of that is a little more complicated than I thought, and there is a risk t= he text becomes more confusing than it already is.

 

Note, that one could still send an offer where an m-= section is moved out of a BUNDLE group, and then send another offer where = the m- line is added to another BUNDLE group (following the normal procedur= es for adding an m- section to a BUNDLE group). But, one would not be allowed to remove and add within the same of= fer.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_-- From nobody Sat Nov 18 09:17:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7154124BFA; Sat, 18 Nov 2017 09:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xEj7Hdaps8b5; Sat, 18 Nov 2017 09:17:00 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07209120726; Sat, 18 Nov 2017 09:16:59 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-66-5a106b09981e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.07.19528.90B601A5; Sat, 18 Nov 2017 18:16:58 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Sat, 18 Nov 2017 18:16:57 +0100 From: Christer Holmberg To: mmusic CC: RTCWeb IETF Thread-Topic: BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer Thread-Index: AdNgJ0q7n/w0ioPdQOmqfDRPNH59DwAaahoA Date: Sat, 18 Nov 2017 17:16:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> 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_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbFdQpcrWyDK4NVFVoupyx+zWKz9187u wOSxZMlPpgDGKC6blNSczLLUIn27BK6MeUv3sxWcM6j4e/M/cwPjSa0uRk4OCQETicPXfrJ0 MXJxCAkcZpRYfuc7K4SzhFFi2pW3zF2MHBxsAhYS3f+0QRpEBGQk9m7azAxiMwsoSnxZPp8N xBYWSJfonXSACaImQ6K35TQzhG0k8a9vJQvIGBYBVYm+0yEgYV4BX4nzDWtYQWwhIPt/12dG EJtTwE9iyqJOsFZGATGJ76fWMEGsEpe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStJNC55wgpR ny+xfPtUZohdghInZz5hmcAoMgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEF jOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQJj6eCW31Y7GA8+dzzEKMDBqMTDWxUoECXE mlhWXJl7iFGCg1lJhDc3CSjEm5JYWZValB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2ampB ahFMlomDU6qBkX+eUXfaDeZg1z8J4ntj3LJ87/792T9fyiPB0n7iXcFHx9Zey97Ifdv+3t/Q BJHUXXPbuNILW/p8l/1pZM94I7H6x7mKvwKX1j/oVzxcPXtNYU7h/CfBoZ3v72btXeew/Ef0 lVqrjRqG83nEz8Zc3NMg4bMgx7pl/6/EvSx8z+fd9amdNaNwnhJLcUaioRZzUXEiACs5jf6h AgAA Archived-At: Subject: Re: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Nov 2017 17:17:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The change below would look something like this: https://github.com/cdh4u/draft-sdp-bundle/pull/44 (Also contains a few spelling fixes) Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 18 November 2017 07:40 To: mmusic Cc: RTCWeb IETF Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE g= roups within a single SDP offer (CC:ing RTCWEB, but please reply on the MMUSIC list) Hi, Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is. Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add wi= thin the same offer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The change below would= look something like this:

 

https://github.com/cdh4u/draft-sdp-= bundle/pull/44

 

(Also contains a few s= pelling fixes)

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 November 2017 07:40
To: mmusic <mmusic@ietf.org>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between B= UNDLE groups within a single SDP offer

 

(CC:ing RTCWEB, but please reply on the MMUSIC list)=

 

Hi,

 

Would anyone object to not allowing moving m- sectio= ns between BUNDLE groups within a single O/A transaction? The documentation= of that is a little more complicated than I thought, and there is a risk t= he text becomes more confusing than it already is.

 

Note, that one could still send an offer where an m-= section is moved out of a BUNDLE group, and then send another offer where = the m- line is added to another BUNDLE group (following the normal procedur= es for adding an m- section to a BUNDLE group). But, one would not be allowed to remove and add within the same of= fer.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_-- From nobody Sat Nov 18 12:18:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10142126D85 for ; Sat, 18 Nov 2017 12:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 aIsbjUYmOFNM for ; Sat, 18 Nov 2017 12:18:40 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C102A1200FC for ; Sat, 18 Nov 2017 12:18:40 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id u3so4398772pgn.7 for ; Sat, 18 Nov 2017 12:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JBcuMq9XvryopDYqxGYZT2JIZG8PCoPjfS/iPz0wbtI=; b=Bw0BVTmq08SJo476QK/VLGtImRb0dfIziCtyNcWtewICM4x8FaGaXl0Vt39aTlsWQx xzo11t6A2ao5cQGM4x+HHIrlS9My8DYilEhuUe1Vesy6XuRD3Zmw3QO1sc/cVCWpARZ3 NZjV4fr9J1xNPfa/N0NG7pb43Tr5e1E7PWSLo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JBcuMq9XvryopDYqxGYZT2JIZG8PCoPjfS/iPz0wbtI=; b=Fw3Mzvwz98HVyGnJ6txRhoK1XxYr5NZeXT8AvYn3cNjtBbZKBlGk0WbZaodi8uqoTU oStx4w/f+BtqJHXRporGGc0ylkng16rrKrioRWme/TBLDs1xCG/qyCBwhSGqTU+Cykob Lk+ogonar6TZVVmFR5s2ZgmoOvhKQEyD8g/xsJ4iCzKyVmpgZC9kNii0Wc5gnBOrorB6 VEMwF838E2/gM0pIFCX0EZRvHX0D/00yG04cHsdEhtIjilPjdG7iJwnTZ8KRgEI4r7/9 Hw4hTFl2sAIM2h0+WKF+vR5dyLtQteauuf62/Y9L5q/TWo4/+d0CSSMRFoyIhSceGuLl xq8g== X-Gm-Message-State: AJaThX52ItWgX4M8KlVnfTywMc5qn6B+XU/AVURzYAPsgI9g1PO/E/7Z Aylz18ID13It3vrvCwzc2I9fHxnWybY= X-Google-Smtp-Source: AGs4zMa28tDgV/hKWoSCP0N8dIHeMVod2pMsy7r3DRr8c0D4Dk5mRPWGM+R04B9n33fr8n24fThyIQ== X-Received: by 10.84.128.72 with SMTP id 66mr9413542pla.119.1511036320098; Sat, 18 Nov 2017 12:18:40 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:1d4d:1a81:316e:fdc6? ([2601:647:4600:3f31:1d4d:1a81:316e:fdc6]) by smtp.gmail.com with ESMTPSA id v64sm12775138pfi.187.2017.11.18.12.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 12:18:38 -0800 (PST) From: Nils Ohlmeier Message-Id: <2F4EE4D9-12CF-4FA0-A038-2EBECCCB8035@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Sat, 18 Nov 2017 12:18:35 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se> Cc: mmusic , RTCWeb IETF To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 18 Nov 2017 20:18:44 -0000 --Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83 Content-Type: multipart/alternative; boundary="Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41" --Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m in favor of your proposed change, because the use case is = small, there is a work around, and the code for handling this (hopefully = rare) use case is really complex. Best regards Nils Ohlmeier > On Nov 18, 2017, at 09:16, Christer Holmberg = wrote: >=20 > The change below would look something like this: >=20 > https://github.com/cdh4u/draft-sdp-bundle/pull/44 = >=20 > (Also contains a few spelling fixes) >=20 > Regards, >=20 > Christer > =C2=A0 <> > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer = Holmberg > Sent: 18 November 2017 07:40 > To: mmusic > Cc: RTCWeb IETF > Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between = BUNDLE groups within a single SDP offer >=20 > (CC:ing RTCWEB, but please reply on the MMUSIC list) >=20 > Hi, >=20 > Would anyone object to not allowing moving m- sections between BUNDLE = groups within a single O/A transaction? The documentation of that is a = little more complicated than I thought, and there is a risk the text = becomes more confusing than it already is. >=20 > Note, that one could still send an offer where an m- section is moved = out of a BUNDLE group, and then send another offer where the m- line is = added to another BUNDLE group (following the normal procedures for = adding an m- section to a BUNDLE group). But, one would not be allowed = to remove and add within the same offer. >=20 > Regards, >=20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m in favor of your proposed change, because the use case is small, = there is a work around, and the code for handling this (hopefully rare) = use case is really complex.

Best regards
  Nils Ohlmeier

On Nov 18, 2017, at 09:16, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

The = change below would look something like this:
 
 
(Also = contains a few spelling fixes)
 
Regards,
 
Christer
 
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: 18 November 2017 07:40
To: mmusic <mmusic@ietf.org>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: [MMUSIC] BUNDLE: = Disallowing moving an m- section between BUNDLE groups within a single = SDP offer
 
(CC:ing RTCWEB, but please reply on the = MMUSIC list)
 
Hi,
 
Would anyone object to not allowing moving m- sections = between BUNDLE groups within a single O/A transaction? The documentation = of that is a little more complicated than I thought, and there is a risk = the text becomes more confusing than it already is.
 
Note, = that one could still send an offer where an m- section is moved out of a = BUNDLE group, and then send another offer where the m- line is added to = another BUNDLE group (following the normal procedures for adding an m- = section to a BUNDLE group). But, one would not be allowed to remove and = add within the same offer.
 
Regards,
 
Christer
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41-- --Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAloQlZwACgkQY2o/VmzJ +KHZwBAAiwPw7i3BdUR8q/UdKVgSreBld+O5QGcLaqHgRiuSe/6iHemO0OWBDtOm pK8Nf5JKOHXxv29JW2aKEEvU4F/t6S+bCr8GDaQNuxPBzm72TxDughZXdoJbQvIw UtSDH0LqsA8w9yVmlJMA7pZtrEZEfB/ih5QK8QYcjbV4T7W0mlY88AC1BYlu3jfV IFGRBlntXfaz7JQYAZ53jcAIy3GktNKNiRdixd3T55GoKn3aq50p/qdMZKnl8Qpi I1gEe14gEBys3ycRlfnab5eXCXaMq54XrbXiLUVpjRGFgyYDD6O0+4Ew6FIuf+db juGTDKSrqQrdnA1nnkQxOPpcy2lDyRAreuuLmigs4VingYJI5qWnmTzPvuMh2lW2 uiAt7etf3yYgI/cxg46EhZNxaPf8hqdtD70B4xngv+mpLhXjqO0me/uG7mYMf9TL ppQCwY0AFg/MlrxAnmnyBMwnUdr2subWKH+drg1PJMx9NURkjMqfNi0TQKycgsWy uln5zsKjm/vSqTu0zCh6ehT9fIaUewpR5Cm8rAxaVUBZlZri2EIPdekWJhrgwNS6 4YU51CmO5fvDqCjBcsU7nnG9ta1GoVCY9N7YmNWqhjSNA6w1y20OoLKIrX/DfCeY Zu5pkZsnyIiU5GrLi1br4+P97Uj5/5k3HBipUdofY+WdKk4WxRM= =TpGI -----END PGP SIGNATURE----- --Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83-- From nobody Sat Nov 18 20:38:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4325120725; Sat, 18 Nov 2017 20:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gr5UFXoAAzll; Sat, 18 Nov 2017 20:37:51 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A612E1242F5; Sat, 18 Nov 2017 20:37:50 -0800 (PST) X-AuditID: c1b4fb2d-f23ff70000001e3d-85-5a110a9c505d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.CC.07741.C9A011A5; Sun, 19 Nov 2017 05:37:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Sun, 19 Nov 2017 05:37:48 +0100 From: Christer Holmberg To: Nils Ohlmeier CC: mmusic , RTCWeb IETF Thread-Topic: [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer Thread-Index: AdNgJ0q7n/w0ioPdQOmqfDRPNH59DwAaahoAAARFFIAAE4e8MA== Date: Sun, 19 Nov 2017 04:37:47 +0000 Message-ID: <3EF428FE-0764-4CAE-8714-2A8981E7F6CF@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se>, <2F4EE4D9-12CF-4FA0-A038-2EBECCCB8035@mozilla.com> In-Reply-To: <2F4EE4D9-12CF-4FA0-A038-2EBECCCB8035@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbHdTHcul2CUwaWbjBZTlz9msbg+bzKj xdp/7ewOzB5Llvxk8ug70MUawBTFZZOSmpNZllqkb5fAlbH49lLmgl/JFf0LH7A2ME4N72Lk 5JAQMJH4tPMeYxcjF4eQwGFGiQMP3zFBOEsYJf7OPs3cxcjBwSZgIdH9TxvEFBHQlDixkQ/E ZBawlvh2QwhkjLBAgcT/hU2sILaIQKHEgo4ZbBC2k0TXnO9MIDaLgKrEgamLwWp4BewlFu9b zgqx6QijxJzHX5lBEpxAidMnb4HZjAJiEt9PrQFrZhYQl7j1ZD4TxM0CEkv2nGeGsEUlXj7+ xwpRkyzxbtd1FogFghInZz5hmcAoPAtJ+ywkZbOQlEHEDSTen5vPDGFrSyxb+BrK1pfY+OUs I7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBcXRwy2/dHYyrXzseYhTgYFTi4T3/ XiBKiDWxrLgy9xCjBAezkghvbhJQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU 7NTUgtQimCwTB6dUA+NapePMdc89uiYwqaRw7Zh2a8rMZQoXd67WMS4SOJL/+mTokn4j1m2L hJdtS3x75P93sXsqpzd0dWWYfS3c/OPm6azg29IfWb67F95s7Kp61ctb+nf3x8zHnRIHStZ8 W5WR7HnbxmTVs0M1GxX0KyVXL2fILNx5XaPzrnzbu6R5Vx9OTs+a0c2vxFKckWioxVxUnAgA 5fjFlp8CAAA= Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Nov 2017 04:37:53 -0000 --_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Nils! Unless someone objects, the plan is to merge the PR and submit a new versio= n of the draft next week. Then we can hopefully do the pub req. Regards, Christer Sent from my iPhone On 18 Nov 2017, at 23.18, Nils Ohlmeier > wrote: I=92m in favor of your proposed change, because the use case is small, ther= e is a work around, and the code for handling this (hopefully rare) use cas= e is really complex. Best regards Nils Ohlmeier On Nov 18, 2017, at 09:16, Christer Holmberg > wrote: The change below would look something like this: https://github.com/cdh4u/draft-sdp-bundle/pull/44 (Also contains a few spelling fixes) Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 18 November 2017 07:40 To: mmusic > Cc: RTCWeb IETF > Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE g= roups within a single SDP offer (CC:ing RTCWEB, but please reply on the MMUSIC list) Hi, Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is. Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add wi= thin the same offer. Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Nils!

Unless someone objects, the plan is to merge the PR and submit a new v= ersion of the draft next week. Then we can hopefully do the pub req.

Regards,

Christer


Sent from my iPhone

On 18 Nov 2017, at 23.18, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

I=92m in favor of your proposed change, because the use case is small,= there is a work around, and the code for handling this (hopefully rare) us= e case is really complex.

Best regards
  Nils Ohlmeier

On Nov 18, 2017, at 09:16, Christer Holmberg <christer.holmberg@ericss= on.com> wrote:

The change below would = look something like this:
 <= /o:p>
https://github.com/cdh4u/draft-sdp-b= undle/pull/44
 <= /o:p>
(Also contains a few sp= elling fixes)
 <= /o:p>
Regards,
 <= /o:p>
Christer
 
From: mmusi= c [mailto:mmusic-boun= ces@ietf.org] On Behalf Of Christer H= olmberg
Sent: 1= 8 November 2017 07:40
To: mmu= sic <mmusic@ietf.org&g= t;
Cc: RTC= Web IETF <rtcweb@ietf.org<= /a>>
Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE groups w= ithin a single SDP offer
 
(CC:ing RTCWEB, but please reply on the MMUSIC list)<= /div>
 
Hi,
 
Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is.
 
Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add within the same offer.
 
Regards,
 
Christer
___________________________________________= ____
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_-- From nobody Mon Nov 20 03:08:21 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1A1294FF; Mon, 20 Nov 2017 03:08:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151117610011.22032.14355800728875111000@ietfa.amsl.com> Date: Mon, 20 Nov 2017 03:08:20 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-40.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 11:08:20 -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 WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-40.txt Pages : 64 Date : 2017-11-20 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m= section without meaning that the media described by the "m=" section is disabled or rejected. When RTP-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-40 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-40 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-40 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 Mon Nov 20 03:12:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E03127010 for ; Mon, 20 Nov 2017 03:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KWyAkARZUPBd for ; Mon, 20 Nov 2017 03:12:04 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F407B12953B for ; Mon, 20 Nov 2017 03:12:03 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-95-5a12b88179b1 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.5C.19528.188B21A5; Mon, 20 Nov 2017 12:12:01 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Mon, 20 Nov 2017 12:12:01 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-40 Thread-Index: AQHTYfBjWbwWzO1zhkWQzJjXCqP/Og== Date: Mon, 20 Nov 2017 11:12:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D638870C26170christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7pW7jDqEog/lLLSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIcf7rMUHBasuPj8MFMD4xW+LkYODgkBE4n935i7GLk4hAQO M0qsOP+esYuRE8hZwijRvDgDpIZNwEKi+582SFhEQF3i694eZhBbWEBVYsu7z4wgJSICWhJd e6FK9CS+7fwBVsICVPJ49SomEJtXwFqib0cHK4jNKCAm8f3UGrA4s4C4xK0n88FsCQEBiSV7 zjND2KISLx//A6sXBZq54cRtdoi4osTHV/sYIXoTJDo7V7NCzBeUODnzCcsERqFZSMbOQlI2 C0kZRNxA4v25+cwQtrbEsoWvoWx9iY1fzjJC2NYSJ1/2sSGrWcDIsYpRtDi1uDg33chIL7Uo M7m4OD9PLy+1ZBMjMEoObvlttYPx4HPHQ4wCHIxKPLw3ZgpFCbEmlhVX5h5ilOBgVhLhVYsC CvGmJFZWpRblxxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBaBJNl4uCUamDknxH0YvnS Y2FTlj5LNL5ibLjWZpUup3KTxk2DtBfb9pd+NbOtMfB8qpahYHNW1NpLv3TbTeETf7LnHX3H ujF95ZUZJ4sPCRXE7DiQ833NkpmBgRwFs+daHo55ttk8Ky56W/T9gsviKrnTHQ8+OLrs3b8b ncvPmJ7ZcPcdU2ty7FoOzUM7/nCdVGIpzkg01GIuKk4EAI0njaOOAgAA Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-40 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Nov 2017 11:12:10 -0000 --_000_D638870C26170christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ladies and Gentlemen, I have submitted a new version (-40) of BUNDLE. The new version contains a number of editorial changes (based on the PRs th= at have been announced on the list). It also introduces the =93BUNDLE trans= port=94 concept. And, it clarifies that an m- section can not be directly m= oved from one group to another. I know there are still editorial changes that people would have liked to do= ne. But, we can=92t go on doing editorial changes forever, so my suggestion= is that we now do the publication request, and then we=92ll deal with what= ever changes are to be done based on the IESG reviews etc. Regards, Christer --_000_D638870C26170christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B1358D7A86B6142A6BA1C47E44CE0A3@ericsson.com> Content-Transfer-Encoding: quoted-printable
Ladies and Gentlemen,

I have submitted a new version (-40) of BUNDLE.

The new version contains a number of editorial changes (based on the P= Rs that have been announced on the list). It also introduces the =93BUNDLE = transport=94 concept. And, it clarifies that an m- section can not be direc= tly moved from one group to another.

I know there are still editorial changes that people would have liked = to done. But, we can=92t go on doing editorial changes forever, so my sugge= stion is that we now do the publication request, and then we=92ll deal with= whatever changes are to be done based on the IESG reviews etc.

Regards,

Christer


--_000_D638870C26170christerholmbergericssoncom_-- From nobody Mon Nov 20 14:58:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3027C12EAA6 for ; Mon, 20 Nov 2017 14:58:17 -0800 (PST) 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 autolearn_force=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 58R-8RAcn0O7 for ; Mon, 20 Nov 2017 14:58:15 -0800 (PST) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id B53CE12E056 for ; Mon, 20 Nov 2017 14:58:15 -0800 (PST) X-AuditID: 12074413-3a3ff70000007929-2c-5a135e06f000 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 4D.38.31017.60E531A5; Mon, 20 Nov 2017 17:58:15 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vAKMwEYJ016033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Nov 2017 17:58:14 -0500 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: Date: Mon, 20 Nov 2017 17:58:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqMseJxxlMHkrq8XU5Y9ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsW/Pa9aCNZIVpzt3MzUwvhPuYuTkkBAwkej8upOxi5GLQ0hg B5PE9w1T2CCc70wSy/9/ZAWpEhYwkrgw8RQziC0iICwx4+1fNhBbSMBa4vbSSUwgNpuAlsSc Q/9ZQGxeAXuJJWdXgfWyCKhKHLt8H6xGVCBN4s6Mh0wQNYISJ2c+Aarn4OAUsJFoOy0GEmYW sJW4M3c3M4QtLnHryXwmCFteonnrbOYJjPyzkHTPQtIyC0nLLCQtCxhZVjHKJeaU5urmJmbm FKcm6xYnJ+blpRbpmuvlZpbopaaUbmKEBKXwDsZdJ+UOMQpwMCrx8H7gEYoSYk0sK67MPcQo ycGkJMq76jdQiC8pP6UyI7E4I76oNCe1+BCjBAezkgivWhRQjjclsbIqtSgfJiXNwaIkzqu2 RN1PSCA9sSQ1OzW1ILUIJivDwaEkwdscIxwlJFiUmp5akZaZU4KQZuLgBBnOAzR8cSxQDW9x QWJucWY6RP4UozFHT8+NP0wcz2a+bmAWYsnLz0uVEuflBykVACnNKM2DmwZLLK8YxYGeE+Zd BbKUB5iU4Oa9AlrFBLTK5QI/yKqSRISUVAPjvIK1Wxa8a1q1KPKDx2/1xfst5d1O/LqUv/VY i+wOPca7CyynfX3loSb+pm9nRdjd34YiS3VPalwW3Wi85xSHremMz3tUV60/qymX5FXekaXp pXHm1o7HrwMF5wef3fbj/sTvOTprrtX+jhS5W+34oO3gwpW7Xt0ymHp+btv9q9fa5n89lph6 eJsSS3FGoqEWc1FxIgD1ptkoBwMAAA== Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-40 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 20 Nov 2017 22:58:17 -0000 On 11/20/17 6:12 AM, Christer Holmberg wrote: > Ladies and Gentlemen, > > I have submitted a new version (-40) of BUNDLE. > > The new version contains a number of editorial changes (based on the PRs > that have been announced on the list). It also introduces the “BUNDLE > transport” concept. And, it clarifies that an m- section can not be > directly moved from one group to another. > > I know there are still editorial changes that people would have liked to > done. But, we can’t go on doing editorial changes forever, so my > suggestion is that we now do the publication request, and then we’ll > deal with whatever changes are to be done based on the IESG reviews etc. I was intimidated by the volume of changes in this version. But while that makes re-reviewing it more difficult I am generally happy with the results. I'm fine with new editorial changes being handled during post publication request processing. I offer the following to be handled whenever: * Section 8.3.1: If all of the criteria above are fulfilled, the answerer MUST select the address assigned to the "m=" section as the offerer BUNDLE address. In the answer, the answerer BUNDLE-tag represents the "m=" section, and the address assigned to the "m=" section in the offer becomes the offerer BUNDLE address. I'm having trouble following this. It feels to me that it doesn't quite say what I think it intends/needs to say. How about the following: If all of the criteria above are fulfilled, the answerer MUST accept the address assigned to that "m=" section as the offerer BUNDLE address. In the answer, the answerer BUNDLE-tag MUST identify the corresponding "m=" section in the answer. There is still a bit of semantic trouble with this. The problem is that (as defined in the terminology section) the Offerer BUNDLE-tag and Offerer BUNDLE address are defined solely by the offer. But when the answerer is processing the offer, it may reject the section associated with those and choose a different tag and address as the Offerer BUNDLE-tab and Offerer BUNDLE address. There really is no terminology for those. Effectively the offerer supplies a list of tags that serve as a priority list for which tag and address will become the Offerer BUNDLE-tag and Offerer BUNDLE address. But it is the answered who makes the final decision, and then signals it back to the offerer via the Answerer BUNDLE-tag. This also impacts the language in section 8.4. A way to alter the text to say this simply doesn't come to me right now. * Section 8.5: In the case of sections that were bundle-only in the initial offer, should bundle-only still be included in the new offer? (Section 6 says that they are not required, but doesn't ban them.) In general it is unclear to me when/how bundle-only is to be used in subsequent o/a exchanges. - It seems that it may be appropriate when sending an offer that adds a new m= section. - Perhaps when offering a change in BUNDLE address, if in this case unique addresses are used for some/all of the bundled m= sections. Are those the only cases when it should be used? Thanks, Paul From nobody Mon Nov 20 22:51:41 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D9E1273B1; Mon, 20 Nov 2017 22:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kgv2AF2IhPHn; Mon, 20 Nov 2017 22:51:38 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CC2127275; Mon, 20 Nov 2017 22:51:35 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id s197so7017370vkh.11; Mon, 20 Nov 2017 22:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hVKje+eNtVdilFAI0pF8HLFOWf/gqjQse3G2CxkiEBU=; b=X46wXiWVgNhsFyToW/Zp/h+Q9ApZArtprX/Xa0S86sM7sRKfvy1LklPXBPoiBcL/Gv mYbmiTnqsqADgLqhO3obizQuzHFexZSp8Iw1icvf6vNtuUKUB6YQw/I8Nss9gzzbXZa6 nQcdxGi6S/wRYFyDq/jMifCcxmHb1KlmSQmWHo3VgZjwjVmFwnxukkqnWMn1EuR004/T cbjrJIbuIwz74TutM1RehOu2gOqC01m9ZWSI+qR4aSgJFfksQNgFD2tgn0U7vxlgUsDf SxDDKbNApyZsS5qmjwYZU8ZsJqvRT1JJ5gLcHBOducehcmHBBHeii0tPPSUl8mm0FKRs gcrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hVKje+eNtVdilFAI0pF8HLFOWf/gqjQse3G2CxkiEBU=; b=J6zqASCsZ7w8cp96Ey+Ec99rZRjjUSrxyL345BuerVVbdv5lJAtQy7776egTyVDCCn QmaSBrUgoBsGkko6iYKMnxPtg97/tZa2ev98qlq8Yn2EsUN1kHGKpq9jMtKnvLntbC8z +7zJ139EPVpdlR4Dtw0iotoHK+EK90oVaiDtfKxG5gM7clY7po2/jlqG1LpAly6z0QOE cL0sNonrtHlcexG21lQ7Kl+ebfDK3vHAldfkhA1lFQBlbCz0BJbpAJWj/89tTgJTcj0i dD0L1RV0/jG3CWIxuhI2n+/TpgiyfmGHsG/ywiABp6c3HFmG4psT6UO4hODLUTeM0Zmh hT7g== X-Gm-Message-State: AJaThX72sele6c/jb+9CS533mPyR7RHR9NkWhrCuRoYr2lXc8vPT8aPg Df8VkE+lTi5D+C7fpW0JoNV1xtS8trCOmkWAKdU= X-Google-Smtp-Source: AGs4zMZ5UHJ8pwlwDN2jsa98znDum26lFmC6PHnwIHVS/308qAYcoW6IJyUw/83CzGGRdfvXZCB169MUWCdw9rvCWHI= X-Received: by 10.31.110.10 with SMTP id j10mr11687054vkc.123.1511247094358; Mon, 20 Nov 2017 22:51:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.194 with HTTP; Mon, 20 Nov 2017 22:51:34 -0800 (PST) In-Reply-To: References: From: Suhas Nandakumar Date: Mon, 20 Nov 2017 22:51:34 -0800 Message-ID: To: Christer Holmberg Cc: Flemming Andreasen , mmusic , "draft-ietf-mmusic-ice-sip-sdp@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c14ada63a28bf055e78a2b6" Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-ice-sip-sdp-14 - ICE mismatch X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Nov 2017 06:51:41 -0000 --94eb2c14ada63a28bf055e78a2b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure Christer, I will update the section title as suggested. Also i need to do another rev of ice-sip-sdp to match the latest section number references in the ICE-BIS. I will work on sending the updated version with the above changes. Sorry for the delay in responding Cheers Suhas On Tue, Oct 17, 2017 at 5:40 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > In 5245bis, I have suggested to rename the =C2=B3Verifying ICE support=C2= =B2 section > to =C2=B3ICE mismatch=C2=B2. I suggest to make a similar change in draft-= ice-sdp. > > Regards, > > Christer > > On 17/10/17 04:18, "mmusic on behalf of Flemming Andreasen" > wrote: > > >Greetings MMUSIC > > > >This is to announce a 2 week WGLC on the draft: > > > > https://www.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-14.txt > > > >as Proposed Standard. Please review and provide any comments you may > >have on the document by Monday, October 30, 2017. Comments should be > >sent to the document authors and the MMUSIC WG list. If you review the > >document but do not have any comments, please send a note to that effect > >as well. > > > >Thanks > > > >-- Flemming (MMUSIC co-chair) > > > >_______________________________________________ > >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 > --94eb2c14ada63a28bf055e78a2b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure Christer, I will update the section title as suggeste= d. Also i need to do another rev of ice-sip-sdp to match the latest section= number references in the ICE-BIS.

I will work on sendin= g the updated version with the above changes.

Sorr= y for the delay in responding

Cheers
Suh= as

On = Tue, Oct 17, 2017 at 5:40 AM, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:
= Hi,

In 5245bis, I have suggested to rename the =C2=B3Verifying ICE support=C2= =B2 section
to =C2=B3ICE mismatch=C2=B2. I suggest to make a similar change in draft-ic= e-sdp.

Regards,

Christer

On 17/10/17 04:18, "mmusic on behalf of Flemming Andreasen"
<mmusic-bounces@ietf.org = on behalf of fandreas@cisco.com&g= t; wrote:

>Greetings MMUSIC
>
>This is to announce a 2 week WGLC on the draft:
>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf= .org/id/draft-ietf-mmusic-ice-sip-sdp-14.txt
>
>as Proposed Standard. Please review and provide any comments you may >have on the document by Monday, October 30, 2017. Comments should be >sent to the document authors and the MMUSIC WG list. If you review the<= br> >document but do not have any comments, please send a note to that effec= t
>as well.
>
>Thanks
>
>-- Flemming (MMUSIC co-chair)
>
>_______________________________________________
>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

--94eb2c14ada63a28bf055e78a2b6-- From nobody Tue Nov 21 05:09:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B3F129482 for ; Tue, 21 Nov 2017 05:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OvyB-kN_GKMg for ; Tue, 21 Nov 2017 05:09:34 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D73126BFD for ; Tue, 21 Nov 2017 05:09:34 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-8c-5a14258c2d65 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.25.19528.C85241A5; Tue, 21 Nov 2017 14:09:32 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Tue, 21 Nov 2017 14:09:32 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-40 Thread-Index: AQHTYfBjWbwWzO1zhkWQzJjXCqP/OqMd0XGAgAB2IHA= Date: Tue, 21 Nov 2017 13:09:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C010C7F@ESESSMB109.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <95F234CA6859AE468DFA8F62E0245165@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdXbdHVSTK4N05c4upyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYf3AHc8EU8YoVq+4yNTAuEOpi5OSQEDCR eHL9HEsXIxeHkMBhRolrWzaxQzhLGCXOrrkO5HBwsAlYSHT/0wZpEBHwlXj2+DYbiC0sYCTx 9fc/Zoi4scSDRytYIGwriRm/esBqWARUJU7P+MYIYvMC9S78fJ0VxBYSKJQ42TsLzGYUEJP4 fmoNE4jNLCAucevJfCaI4wQkluw5zwxhi0q8fPwPrF5UQE9iw4nbYKdJCChJTNuaBtGqJ3Fj 6hQ2CNta4saPI1C2tsSyha+ZIU4QlDg58wnLBEbRWUi2zULSPgtJ+ywk7bOQtC9gZF3FKFqc Wlycm25kpJdalJlcXJyfp5eXWrKJERg9B7f8ttrBePC54yFGAQ5GJR7enTwiUUKsiWXFlbmH GCU4mJVEeDNlgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5T3ryRgkJpCeWpGanphakFsFkmTg4 pRoYHVJOOk2I2CwRuWVbOmOYlMu0UnVFjabPwQ4XP09YKRPTNP9JzC9dD8dLv44/+tN8Tudk QWPPjCu6gWtPvjpmPH9FcyDnsiVVb2MvT/609JL0RrMzc5XFLaynfyqo14x6t5Gv/kZm7vRr K+xuqPOskzVrX1fJ9nWOVcT5s0/+yc4J3Zij+uBqkhJLcUaioRZzUXEiADzJnt6aAgAA Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-40 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Nov 2017 13:09:37 -0000 Hi Paul, ... > I'm fine with new editorial changes being handled during post >publication request processing. I offer the following to be handled > whenever: > > * Section 8.3.1: > > If all of the criteria above are fulfilled, the answerer MUST select > the address assigned to the "m=3D" section as the offerer BUNDLE > address. In the answer, the answerer BUNDLE-tag represents the "m=3D" > section, and the address assigned to the "m=3D" section in the offer > becomes the offerer BUNDLE address. > > I'm having trouble following this. It feels to me that it doesn't quite >say what I think it intends/needs to say. How about the following: > > If all of the criteria above are fulfilled, the answerer MUST accept > the address assigned to that "m=3D" section as the offerer BUNDLE > address. In the answer, the answerer BUNDLE-tag MUST identify the > corresponding "m=3D" section in the answer. > > There is still a bit of semantic trouble with this. The problem is that >(as defined in the terminology section) > the Offerer BUNDLE-tag and Offerer BUNDLE address are > defined solely >by the offer. But when the answerer > is processing the offer, it may reject the section associated with those >and choose a different tag and address as > the Offerer BUNDLE-tab and Offerer BUNDLE address. There really is no >terminology for those. > > Effectively the offerer supplies a list of tags that serve as a priority >list for which tag and address will become the > Offerer BUNDLE-tag and Offerer BUNDLE address. But it is the answered >who makes the final decision, and then > signals it back to the offerer via the Answerer BUNDLE-tag. This also >impacts the language in section 8.4. > > A way to alter the text to say this simply doesn't come to me right now. ------------ > * Section 8.5: > > In the case of sections that were bundle-only in the initial offer, >should bundle-only still be included in > the new offer? (Section 6 says that they are not required, but doesn't >ban them.) > > In general it is unclear to me when/how bundle-only is to be used in >subsequent o/a exchanges. > > - It seems that it may be appropriate when sending an offer that adds a >new m=3D section. > > - Perhaps when offering a change in BUNDLE address, if in this case >unique addresses are used for some/all of the bundled m=3D sections. > > Are those the only cases when it should be used? It has been suggested that, in subsequent offers, each bundled m- section (except the one carrying the BUNDLE address) would use bundle-only. That way we would not have to talk about "shared address=B2 - we would simply sa= y that the "BUNDLE address" is assigned to the m=3D section associated with the identification-tag. After all, many SDP attributes are only placed in that m=3D section, so why should the address and port be any different. Regards, Christer From nobody Tue Nov 21 07:02:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706C91294A1 for ; Tue, 21 Nov 2017 07:02:15 -0800 (PST) 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 autolearn_force=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 r7jsZXdFCIf9 for ; Tue, 21 Nov 2017 07:02:09 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8EB91294B2 for ; Tue, 21 Nov 2017 07:02:03 -0800 (PST) X-AuditID: 12074411-f95ff70000007f0a-a7-5a143feb1428 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 42.25.32522.BEF341A5; Tue, 21 Nov 2017 10:02:03 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vALF22Q4028199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Nov 2017 10:02:02 -0500 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C010C7F@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <0fd04f17-e2b7-2722-eb61-096870beb7a2@alum.mit.edu> Date: Tue, 21 Nov 2017 10:02:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C010C7F@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixO6iqPvaXiTK4M8iAYsLMw8zWkxd/pjF gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mro7m1iLNjMVdF4pZ2xgXEKRxcjJ4eEgIlE /6TnrCC2kMAOJomdD3i6GLmA7IdMEuun3mECSQgLGElcmHiKuYuRg0NEIEXiSBcjRP1WRolF C+1AbDYBLYk5h/6zgJTwCthLzJoYCBJmEVCV+LPyFAuILSqQJnFnxkOwibwCghInZz4Bi3MK +EksmrQPLM4sYCYxb/NDZghbXOLWk/lQcXmJ5q2zmScw8s9C0j4LScssJC2zkLQsYGRZxSiX mFOaq5ubmJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iRESpII7GGeclDvEKMDBqMTDu8NYJEqI NbGsuDL3EKMkB5OSKK+kKVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG+mLFCONyWxsiq1KB8m Jc3BoiTOy7dE3U9IID2xJDU7NbUgtQgmK8PBoSTBywCMRiHBotT01Iq0zJwShDQTByfIcB6g 4X/sQIYXFyTmFmemQ+RPMRpz9PTc+MPE8Wzm6wZmIZa8/LxUKXHefyClAiClGaV5cNNgieYV ozjQc8K8PiBLeYBJCm7eK6BVTECrfh4XBllVkoiQkmpgXD/H543kpagEJ8tQJqXDela84hH5 r5dbLMn6UsP2Km9a0klBHYZNraILfwSozE/bG7A5yf/7hw3Flj3Rt313zIjXXpyaK6kezPlq Edu8eqGTVzQC9R1cchet/Lpn+76ra2T7uXY4+2WrdV5N/O7R0b5g/0cfIemol7+/fSk/FCGa t6JmydppSizFGYmGWsxFxYkAv9fvxA8DAAA= Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-40 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Nov 2017 15:02:15 -0000 On 11/21/17 8:09 AM, Christer Holmberg wrote: >> * Section 8.5: >> >> In the case of sections that were bundle-only in the initial offer, >> should bundle-only still be included in >> the new offer? (Section 6 says that they are not required, but doesn't >> ban them.) >> >> In general it is unclear to me when/how bundle-only is to be used in >> subsequent o/a exchanges. >> >> - It seems that it may be appropriate when sending an offer that adds a >> new m= section. >> >> - Perhaps when offering a change in BUNDLE address, if in this case >> unique addresses are used for some/all of the bundled m= sections. >> >> Are those the only cases when it should be used? > > It has been suggested that, in subsequent offers, each bundled m- section > (except the one carrying the BUNDLE address) would use bundle-only. That > way we would not have to talk about "shared address² - we would simply say > that the "BUNDLE address" is assigned to the m= section associated with > the identification-tag. > > After all, many SDP attributes are only placed in that m= section, so why > should the address and port be any different. That is an interesting idea. But would that prevent you from moving an m= section out of a bundle group after it has been accepted into the group? Thanks, Paul From nobody Tue Nov 21 07:08:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7D21294A2 for ; Tue, 21 Nov 2017 07:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6iUeeJEgjLoS for ; Tue, 21 Nov 2017 07:08:19 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AF21294A1 for ; Tue, 21 Nov 2017 07:08:19 -0800 (PST) X-AuditID: c1b4fb3a-039e19c000004c48-3f-5a1441616713 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.AF.19528.161441A5; Tue, 21 Nov 2017 16:08:17 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Tue, 21 Nov 2017 16:08:16 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-40 Thread-Index: AQHTYfBjWbwWzO1zhkWQzJjXCqP/OqMd0XGAgAB2IHCAAJcqAIAAJZIA Date: Tue, 21 Nov 2017 15:08:16 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C010C7F@ESESSMB109.ericsson.se> <0fd04f17-e2b7-2722-eb61-096870beb7a2@alum.mit.edu> In-Reply-To: <0fd04f17-e2b7-2722-eb61-096870beb7a2@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="euc-kr" Content-ID: <2DC4A71E6FEE39408B98577855DA9AF7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7om6io0iUwcwXShZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxZ/Y11oJtghVPVj5jbmD8I9DFyMkhIWAi 8WPNbNYuRi4OIYHDjBI/V5xhgnCWMErcnNQElOHgYBOwkOj+pw3SICLgK/Hs8W02EFtYwEji wsRTzBBxY4kHj1awQNhuEiu6/oPVsAioShzbtJERxOYVsJY4+uUYM8T814wSM/qWgTVzCjhI 3LowjxXEZhQQk/h+ag0TiM0sIC5x68l8JohLBSSW7DnPDGGLSrx8/A+sXlRAT2LDidvsEHEl iR8bLrFA9GpJfPmxjw3CtpbYs2IHI4StKDGl+yE7xEGCEidnPmGZwCg2C8m6WUjaZyFpn4Wk fRaS9gWMrKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAiPr4JbfVjsYDz53PMQowMGoxMP7 QkMkSog1say4MvcQowQHs5IIb6YsUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS 1OzU1ILUIpgsEwenVAPjok8u5tWzmaZP2ZqoYaCm1B979FDL9xpLT5+8dVYcR87rpZ07foJl QZub4e0Pd5x1f3O1Xv9++OiLu1PF9RSndrS2d9slLpJqi5U+NOHQgbWTjdMz+B8tq4qKWswx IadD6c+1d1sCVxndUFz2t4OpYM7b9U2nVwU8UfUr/sSv3X8kXFE2JPSpEktxRqKhFnNRcSIA nVO8nagCAAA= Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-40 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 21 Nov 2017 15:08:20 -0000 SGksDQoNCj4+PiAqIFNlY3Rpb24gOC41Og0KPj4+DQo+Pj4gSW4gdGhlIGNhc2Ugb2Ygc2VjdGlv bnMgdGhhdCB3ZXJlIGJ1bmRsZS1vbmx5IGluIHRoZSBpbml0aWFsIG9mZmVyLA0KPj4+IHNob3Vs ZCBidW5kbGUtb25seSBzdGlsbCBiZSBpbmNsdWRlZCBpbg0KPj4+IHRoZSBuZXcgb2ZmZXI/IChT ZWN0aW9uIDYgc2F5cyB0aGF0IHRoZXkgYXJlIG5vdCByZXF1aXJlZCwgYnV0IGRvZXNuJ3QNCj4+ PiBiYW4gdGhlbS4pDQo+Pj4NCj4+PiBJbiBnZW5lcmFsIGl0IGlzIHVuY2xlYXIgdG8gbWUgd2hl bi9ob3cgYnVuZGxlLW9ubHkgaXMgdG8gYmUgdXNlZCBpbg0KPj4+IHN1YnNlcXVlbnQgby9hIGV4 Y2hhbmdlcy4NCj4+Pg0KPj4+IC0gSXQgc2VlbXMgdGhhdCBpdCBtYXkgYmUgYXBwcm9wcmlhdGUg d2hlbiBzZW5kaW5nIGFuIG9mZmVyIHRoYXQgYWRkcyBhDQo+Pj4gbmV3IG09IHNlY3Rpb24uDQo+ Pj4NCj4+PiAtIFBlcmhhcHMgd2hlbiBvZmZlcmluZyBhIGNoYW5nZSBpbiBCVU5ETEUgYWRkcmVz cywgaWYgaW4gdGhpcyBjYXNlDQo+Pj4gdW5pcXVlIGFkZHJlc3NlcyBhcmUgdXNlZCBmb3Igc29t ZS9hbGwgb2YgdGhlIGJ1bmRsZWQgbT0gc2VjdGlvbnMuDQo+Pj4NCj4+PiBBcmUgdGhvc2UgdGhl IG9ubHkgY2FzZXMgd2hlbiBpdCBzaG91bGQgYmUgdXNlZD8NCj4+IA0KPj4gSXQgaGFzIGJlZW4g c3VnZ2VzdGVkIHRoYXQsIGluIHN1YnNlcXVlbnQgb2ZmZXJzLCBlYWNoIGJ1bmRsZWQgbS0NCj4+ c2VjdGlvbg0KPj4gKGV4Y2VwdCB0aGUgb25lIGNhcnJ5aW5nIHRoZSBCVU5ETEUgYWRkcmVzcykg d291bGQgdXNlIGJ1bmRsZS1vbmx5LiBUaGF0DQo+PiB3YXkgd2Ugd291bGQgbm90IGhhdmUgdG8g dGFsayBhYm91dCAic2hhcmVkIGFkZHJlc3Op9yAtIHdlIHdvdWxkIHNpbXBseQ0KPj5zYXkNCj4+ IHRoYXQgdGhlICJCVU5ETEUgYWRkcmVzcyIgaXMgYXNzaWduZWQgdG8gdGhlIG09IHNlY3Rpb24g YXNzb2NpYXRlZCB3aXRoDQo+PiB0aGUgaWRlbnRpZmljYXRpb24tdGFnLg0KPj4gDQo+PiBBZnRl ciBhbGwsIG1hbnkgU0RQIGF0dHJpYnV0ZXMgYXJlIG9ubHkgcGxhY2VkIGluIHRoYXQgbT0gc2Vj dGlvbiwgc28NCj4+d2h5DQo+PiBzaG91bGQgdGhlIGFkZHJlc3MgYW5kIHBvcnQgYmUgYW55IGRp ZmZlcmVudC4NCj4NCj5UaGF0IGlzIGFuIGludGVyZXN0aW5nIGlkZWEuDQo+DQo+QnV0IHdvdWxk IHRoYXQgcHJldmVudCB5b3UgZnJvbSBtb3ZpbmcgYW4gbT0gc2VjdGlvbiBvdXQgb2YgYSBidW5k bGUNCj5ncm91cCBhZnRlciBpdCBoYXMgYmVlbiBhY2NlcHRlZCBpbnRvIHRoZSBncm91cD8NCg0K WWVzLiBZb3Ugd291bGQgc2ltcGx5IHNlbmQgYSBuZXcgb2ZmZXIsIHdoZXJlIHlvdSBhc3NpZ24g YSB1bmlxdWUgYWRkcmVzcw0KdG8gdGhhdCBtPSBzZWN0aW9uLCBhbmQgYXNzaWduIHRoZSBCVU5E TEUgYWRkcmVzcyB0byBhbm90aGVyIG09IHNlY3Rpb24NCndpdGhpbiB0aGUgQlVORExFIGdyb3Vw Lg0KDQpPZiBjb3Vyc2UsIGV2ZW4gd2l0aCBidW5kbGUtb25seSwgeW91IHN0aWxsIGFzc2lnbiB0 aGUgYWRkcmVzcyB0byB0aGUgbT0NCnNlY3Rpb24sIGJ1dCB3aXRoIGEgemVybyBwb3J0IHZhbHVl Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg== From nobody Thu Nov 23 21:54:37 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23CB129AA8; Thu, 23 Nov 2017 21:54:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151150287471.9110.17148562358533395520@ietfa.amsl.com> Date: Thu, 23 Nov 2017 21:54:34 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 05:54:35 -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 WG of the IETF. Title : Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-15.txt Pages : 43 Date : 2017-11-23 Abstract: This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-15 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-15 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 Thu Nov 23 21:58:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0D512943A for ; Thu, 23 Nov 2017 21:58:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mLFumdB2i_0Z for ; Thu, 23 Nov 2017 21:58:18 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B94E129AA0 for ; Thu, 23 Nov 2017 21:58:18 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id f14so14060195uaa.5 for ; Thu, 23 Nov 2017 21:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XmKvJL4JHtcE9wnlTSPyFGcX1rSnZnesQQzwWDns0vk=; b=KPwO9IMQxYiDWvLDerb0uPUWP2GSmAGZqWzGx3YM9Jl58uOoyziac1f/2wKtB4JJV2 VirQlP93IlqBcX5gIofHiEIfkjnsW4tbpYU8hiHyW3EgytczZwJbcDdqCW7Xrj/WwujX 0/VN5QJjlnsud9Lw/YmdoCyzdePYSl68w+E7sYfIik2Ny+UjZ3q78QldN8rKro7eAut2 hMK4DfyHlwpct95puXQPM45C/bJNHdHpVDYmsGmzrXwycMO6jdo5NNrkhm6rfElfxqws pyWIJV130tvDqsYQb7hei/L/Oa9deJIz1kVjC27sgCekrdyH88SyjOov8Zk0UhNESLvq pCbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XmKvJL4JHtcE9wnlTSPyFGcX1rSnZnesQQzwWDns0vk=; b=F6RtiXHpmNP2b4Q8TCCxmxsD6u60Zq2XbFyiLbx7K6aZiaDT1c/sqpbYFGMuYE9wkw fSZgK+w0FWcIyZ/EDkkRlaIWjgV8zEf7ZoV9rf0mdxr7RntFeJjeeXJwenAC9h017XmS e12FQTWzBS0+Cj388XamE2E1JEo4qWvQ8njspiDw103odil+Z0YjxTXxkj7MnhHKY7tg i5rbiCgK21OQRpVGCU3zKWn7XQKFaVFaNJzDQwl51kM/g79/c+FR6RQyO38JdbCicMWe t9dk+MQhgf9MKQG7GPB5IuxaOygA4ixz2iFI5DvdeF9GcH0BogPUOS6z4g3p7OZnv9sq IQcA== X-Gm-Message-State: AJaThX46HN0+FHFK+Hbb+2igPeVChzi4OCrbDFQOISa7B9ohpQkIv8E+ 2K9nTnPiAgH9p2xW05ELuXp0b55DAIojgjuy2UA= X-Google-Smtp-Source: AGs4zMZJr3VXAyfJnvgyUkSIJ3gShGcK+t3IyVa2FIQZUm4eIJk1EJuEUgbrzinSC1eYWZmrkcqzT8vqA3VEHpvfO7s= X-Received: by 10.176.89.79 with SMTP id o15mr20101807uad.163.1511503097222; Thu, 23 Nov 2017 21:58:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.194 with HTTP; Thu, 23 Nov 2017 21:58:16 -0800 (PST) In-Reply-To: <151150287471.9110.17148562358533395520@ietfa.amsl.com> References: <151150287471.9110.17148562358533395520@ietfa.amsl.com> From: Suhas Nandakumar Date: Thu, 23 Nov 2017 21:58:16 -0800 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary="001a1149815c2fdb36055eb43d44" Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Nov 2017 05:58:20 -0000 --001a1149815c2fdb36055eb43d44 Content-Type: text/plain; charset="UTF-8" Hi This version incorporates Last Call comment from Christer and also updates the references to new section numbers in ICE-BIS Thanks Suhas On Thu, Nov 23, 2017 at 9:54 PM, wrote: > > 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 WG > of the IETF. > > Title : Session Description Protocol (SDP) Offer/Answer > procedures for Interactive Connectivity Establishment (ICE) > Authors : Marc Petit-Huguenin > Ari Keranen > Suhas Nandakumar > Filename : draft-ietf-mmusic-ice-sip-sdp-15.txt > Pages : 43 > Date : 2017-11-23 > > Abstract: > This document describes Session Description Protocol (SDP) Offer/ > Answer procedures for carrying out Interactive Connectivity > Establishment (ICE) between the agents. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-15 > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-15 > > > 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 > --001a1149815c2fdb36055eb43d44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

=C2=A0 This version incorporat= es Last Call comment from Christer and also updates the references to new s= ection numbers in ICE-BIS

Thanks
Suhas

On Thu,= Nov 23, 2017 at 9:54 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Multiparty Multimedia Session Control WG o= f the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Session Description Protocol (SDP) Offer/Answer procedures for Interactive= Connectivity Establishment (ICE)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-15.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-11-23

Abstract:
=C2=A0 =C2=A0This document describes Session Description Protocol (SDP) Off= er/
=C2=A0 =C2=A0Answer procedures for carrying out Interactive Connectivity =C2=A0 =C2=A0Establishment (ICE) between the agents.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-mmusic-ice-sip-sdp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-15
https://datatracker.ietf.org/<= wbr>doc/html/draft-ietf-mmusic-ice-sip-sdp-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-15


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

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

--001a1149815c2fdb36055eb43d44-- From nobody Fri Nov 24 00:39:47 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71245127698; Fri, 24 Nov 2017 00:39:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151151277940.9182.10446829024965160314@ietfa.amsl.com> Date: Fri, 24 Nov 2017 00:39:39 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 08:39:39 -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 WG of the IETF. Title : Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-16.txt Pages : 43 Date : 2017-11-24 Abstract: This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-16 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-16 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 Nov 24 06:35:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F11C128896 for ; Fri, 24 Nov 2017 06:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 inLRYGhxHAic for ; Fri, 24 Nov 2017 06:35:21 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5BC12426E for ; Fri, 24 Nov 2017 06:35:20 -0800 (PST) X-AuditID: c1b4fb30-a0dff70000002554-a2-5a182e26902d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 94.EE.09556.62E281A5; Fri, 24 Nov 2017 15:35:18 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Fri, 24 Nov 2017 15:35:18 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Disable individual m= section does not affect other m= sections within BUNDLE group Thread-Index: AQHTZTFywlFFTYD9oke3wINhSSdaVA== Date: Fri, 24 Nov 2017 14:35:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D63D97362649Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7iq6ankSUwZPjlhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsv8g2wFE7UqFv+9wtzA+E+pi5GDQ0LARGLp/IouRi4OIYHD jBLPZp1nhHCWMEqcvDmXHaSITcBCovufdhcjJ4eIgLrE1709zCBhYYE0iSVryiHC2RKTjvey Qdh6Ek8ezWcCsVkEVCXuLZ0IZvMKWEtc23CeHcRmFBCT+H5qDVicWUBc4tYTiHoJAQGJJXvO M0PYohIvH/9jBbFFgWZuOHGbHSKuKNH+tIER5ARmgQSJrR/DIMYLSpyc+YRlAqPQLCRTZyFU zUJSBVFiIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxrics7JzIiq1nAyLGKUbQ4tTgpN93ISC+1 KDO5uDg/Ty8vtWQTIzBGDm75bbCD8eVzx0OMAhyMSjy8MyQkooRYE8uKK3MPMUpwMCuJ8Mo/ FYsS4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvSkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwJh5q1lu ++TCWbYTZ07NYuFZPp2z/hnTjBVSTyIypvDYlPvsOGxrdOWegnzfa2MJkTShiTu/slxXnTA/ 1urU5LMd6U59732c5z7vr90cde35MpYlng79Wz/nFsQ5XqzskRc5KXxYLUe7fGXmVsWF2j7P n9pJPKtfnXd6r2GoTnflRs47tTvjVZRYijMSDbWYi4oTAS36D4aNAgAA Archived-At: Subject: [MMUSIC] BUNDLE: Disable individual m= section does not affect other m= sections within BUNDLE group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Nov 2017 14:35:26 -0000 --_000_D63D97362649Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have lately received some questions regarding BUNDLE, indicating that the= procedures are unclear. As you know, the latest version (-40) includes a number of editorial change= s and clarifications. But, I=92m afraid that=92s not enough. Especially the SDP Offer/Answer proc= edures are unclear, and I=92ve spent quite a bit of time looking into how t= hey can be clarified. However, based on my judgement, it would be very difficult to make them mor= e clear. So, I have submitted a PR, where I do some TECHNICAL changes, and introduce= some restrictions, in order to make things more clear. * When a BUNDLE group has been negotiated, the offerer/answerer BUNDLE = address is ONLY assigned to the m- section represented by the BUNDLE-tag. E= very other bundled m- section contains a zero port value and an SDP bundle-= only attribute. This makes the text more clear, and removes the =93shared a= ddress=94 concept. * RESTRICTION: The suggested text says that, when an answerer receives = an offer with a BUNDLE address (previously negotiated, or new suggested), t= he answerer cannot move the m- section including the BUNDLE address (the m-= section represented by the offerer BUNDLE-tag) out of the BUNDLE group. Th= e answerer will either have to reject the whole offer, and/or send an offer= of it=92s own where it removes the m- section out of the BUNDLE group. * RESTRICTION: The suggested text says that, when an answerer receives = an offer with a BUNDLE address (previously negotiated, or new suggested), t= he answerer cannot reject the m- section including the BUNDLE address (the = m- section represented by the offerer BUNDLE-tag). The answerer will either= have to reject the whole offer, or send an offer of it=92s own where it di= sables the m- section. With the changes/restrictions above, I personally think the SDP offer/answe= r procedures are easier to understand. The PR can be found here: https://github.com/cdh4u/draft-sdp-bundle/pull/45 I ask anyone that is interested in BUNDLE to take a look. Regards, Christer --_000_D63D97362649Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I have lately received some questions regarding BUNDLE, indicating tha= t the procedures are unclear.

As you know, the latest version (-40) includes a number of editorial c= hanges and clarifications.

But, I=92m afraid that=92s not enough. Especially the SDP Offer/Answer= procedures are unclear, and I=92ve spent quite a bit of time looking into = how they can be clarified.

However, based on my judgement, it would be very difficult to make the= m more clear.

So, I have submitted a PR, where I do some TECHNICAL changes, and intr= oduce some restrictions, in order to make things more clear.

  • When a BUNDLE group has been negotiated, the offerer/answerer BUNDLE ad= dress is ONLY assigned to the m- section represented by the BUNDLE-tag. Eve= ry other bundled m- section contains a zero port value and an SDP bundle-on= ly attribute. This makes the text more clear, and removes the =93shared address=94 concept.
  • RESTRICT= ION: The suggested text says that, when an answerer receives an offer with = a BUNDLE address (previously negotiated, or new suggested), the answerer ca= nnot move the m- section including the BUNDLE address (the m- section repre= sented by the offerer BUNDLE-tag) out of the BUNDLE group. The answerer will either have to reje= ct the whole offer, and/or send an offer of it=92s own where it removes the= m- section out of the BUNDLE group.
  • RESTRICTION: The suggested tex= t says that, when an answerer receives an offer with a BUNDLE address (prev= iously negotiated, or new suggested), the answerer cannot reject the m- sec= tion including the BUNDLE address (the m- section represented by the offere= r BUNDLE-tag). The answerer will either have to reject the whole offer, or s= end an offer of it=92s own where it disables the m- section.
With the changes/restrictions above, I personally think the SDP offer/= answer procedures are easier to understand.

The PR can be found here:


I ask anyone that is interested in BUNDLE to take a look.

Regards,

Christer

--_000_D63D97362649Bchristerholmbergericssoncom_-- From nobody Fri Nov 24 06:47:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D5D127010 for ; Fri, 24 Nov 2017 06:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4WZoFnbrr1yO for ; Fri, 24 Nov 2017 06:47:16 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72804126D0C for ; Fri, 24 Nov 2017 06:47:16 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-60-5a1830f207ae Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 98.67.19528.2F0381A5; Fri, 24 Nov 2017 15:47:14 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Fri, 24 Nov 2017 15:47:14 +0100 From: Christer Holmberg To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Disable individual m= section does not affect other m= sections within BUNDLE group Thread-Index: AQHTZTMd20P6JHkrD0Ogwr9kzhQOdQ== Date: Fri, 24 Nov 2017 14:47:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D63DFF762652Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7uu4nA4kog0nNRhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp2T6xgLjltU3G2axNjA+FS/i5GDQ0LARGLHDqMuRi4OIYHD jBIrejawQDhLGCVurT3GBlLEJmAh0f1Pu4uRk0NEIFbi67r3TCC2sECxxLtNOxkh4iUSXXvO MUPYehJnJjxiA7FZBFQlzq5YyQIyhlfAWmJfsypImFFATOL7qTVgY5gFxCVuPZkPZksICEgs 2XOeGcIWlXj5+B8riC0KNHLDidvsEHFFiZ1n25khehMkPn7bBWbzCghKnJz5hGUCo9AsJGNn ISmbhaQMIm4g8f7cfGYIW1ti2cLXULa+xMYvZxlnAV3NDHR10099ZCULGDlWMYoWpxYX56Yb GemlFmUmFxfn5+nlpZZsYgRGycEtv612MB587niIUYCDUYmHV1BCIkqINbGsuDL3EKMEB7OS CK/8U7EoId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYwd 3pyHvu58vzL4t+Tl7QvdN7obZYn6hJne/VukXnn+S8BThytcZ9K+BjxLFV87YQKvxdF2K6bz DRVvJBz3ZhXMNhbTmx2xXcYncu0S06ffZN5eN+P5HTo9IOJTyQ3lFaKLTZLCX2mvlO1lvWDu 8W7y77mOsY++b8uuDLRXE2zIunezQN7QKluJpTgj0VCLuag4EQDLjFPtjgIAAA== Archived-At: Subject: Re: [MMUSIC] BUNDLE: Disable individual m= section does not affect other m= sections within BUNDLE group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 24 Nov 2017 14:47:18 -0000 --_000_D63DFF762652Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable BTW, don=92t worry about the subject. Copy/paste error. From: mmusic > on b= ehalf of Christer Holmberg > Date: Friday 24 November 2017 at 16:35 To: "mmusic@ietf.org" > Subject: [MMUSIC] BUNDLE: Disable individual m=3D section does not affect o= ther m=3D sections within BUNDLE group Hi, I have lately received some questions regarding BUNDLE, indicating that the= procedures are unclear. As you know, the latest version (-40) includes a number of editorial change= s and clarifications. But, I=92m afraid that=92s not enough. Especially the SDP Offer/Answer proc= edures are unclear, and I=92ve spent quite a bit of time looking into how t= hey can be clarified. However, based on my judgement, it would be very difficult to make them mor= e clear. So, I have submitted a PR, where I do some TECHNICAL changes, and introduce= some restrictions, in order to make things more clear. * When a BUNDLE group has been negotiated, the offerer/answerer BUNDLE = address is ONLY assigned to the m- section represented by the BUNDLE-tag. E= very other bundled m- section contains a zero port value and an SDP bundle-= only attribute. This makes the text more clear, and removes the =93shared a= ddress=94 concept. * RESTRICTION: The suggested text says that, when an answerer receives = an offer with a BUNDLE address (previously negotiated, or new suggested), t= he answerer cannot move the m- section including the BUNDLE address (the m-= section represented by the offerer BUNDLE-tag) out of the BUNDLE group. Th= e answerer will either have to reject the whole offer, and/or send an offer= of it=92s own where it removes the m- section out of the BUNDLE group. * RESTRICTION: The suggested text says that, when an answerer receives = an offer with a BUNDLE address (previously negotiated, or new suggested), t= he answerer cannot reject the m- section including the BUNDLE address (the = m- section represented by the offerer BUNDLE-tag). The answerer will either= have to reject the whole offer, or send an offer of it=92s own where it di= sables the m- section. With the changes/restrictions above, I personally think the SDP offer/answe= r procedures are easier to understand. The PR can be found here: https://github.com/cdh4u/draft-sdp-bundle/pull/45 I ask anyone that is interested in BUNDLE to take a look. Regards, Christer --_000_D63DFF762652Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <04AAFC86BD895343838998B1EC51F6DF@ericsson.com> Content-Transfer-Encoding: quoted-printable
BTW, don=92t worry about the subject. Copy/paste error.

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Friday 24 November 2017 at 16= :35
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] BUNDLE: Disable i= ndividual m=3D section does not affect other m=3D sections within BUNDLE gr= oup

Hi,

I have lately received some questions regarding BUNDLE, indicating tha= t the procedures are unclear.

As you know, the latest version (-40) includes a number of editorial c= hanges and clarifications.

But, I=92m afraid that=92s not enough. Especially the SDP Offer/Answer= procedures are unclear, and I=92ve spent quite a bit of time looking into = how they can be clarified.

However, based on my judgement, it would be very difficult to make the= m more clear.

So, I have submitted a PR, where I do some TECHNICAL changes, and intr= oduce some restrictions, in order to make things more clear.

  • When a BUNDLE group has been negotiated, the offerer/answerer BUNDLE ad= dress is ONLY assigned to the m- section represented by the BUNDLE-tag. Eve= ry other bundled m- section contains a zero port value and an SDP bundle-on= ly attribute. This makes the text more clear, and removes the =93shared address=94 concept.
  • RESTRICT= ION: The suggested text says that, when an answerer receives an offer with = a BUNDLE address (previously negotiated, or new suggested), the answerer ca= nnot move the m- section including the BUNDLE address (the m- section repre= sented by the offerer BUNDLE-tag) out of the BUNDLE group. The answerer will either have to reje= ct the whole offer, and/or send an offer of it=92s own where it removes the= m- section out of the BUNDLE group.
  • RESTRICTION: The suggested tex= t says that, when an answerer receives an offer with a BUNDLE address (prev= iously negotiated, or new suggested), the answerer cannot reject the m- sec= tion including the BUNDLE address (the m- section represented by the offere= r BUNDLE-tag). The answerer will either have to reject the whole offer, or s= end an offer of it=92s own where it disables the m- section.
With the changes/restrictions above, I personally think the SDP offer/= answer procedures are easier to understand.

The PR can be found here:


I ask anyone that is interested in BUNDLE to take a look.

Regards,

Christer

 --_000_D63DFF762652Bchristerholmbergericssoncom_-- From nobody Mon Nov 27 02:25:00 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56683120725; Mon, 27 Nov 2017 02:24:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151177829931.30862.13697738173548851981@ietfa.amsl.com> Date: Mon, 27 Nov 2017 02:24:59 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-41.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 10:24:59 -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 WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-41.txt Pages : 65 Date : 2017-11-27 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m= section without meaning that the media described by the "m=" section is disabled or rejected. When RTP-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-41 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-41 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-41 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 Mon Nov 27 02:29:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D351126BF6 for ; Mon, 27 Nov 2017 02:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zFZGXEcozvrK for ; Mon, 27 Nov 2017 02:29:54 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A379B1250B8 for ; Mon, 27 Nov 2017 02:29:53 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-85-5a1be91fceca Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 30.30.08439.F19EB1A5; Mon, 27 Nov 2017 11:29:51 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Mon, 27 Nov 2017 11:29:50 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-41 Thread-Index: AQHTZ2qnSSgmVM4+UUCEm6R514r+Qw== Date: Mon, 27 Nov 2017 10:29:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D641B7BD26612christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7q678S+kogzV9ahZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvOd8ywFnwQrHuy8ztrA+Iuvi5GTQ0LARGJJ8xemLkYuDiGB w4wS13a+Z4NwljBK3Jl/Acjh4GATsJDo/qcN0iAioC7xdW8PM4gtLKAqcXn/XyaIuJbEsaUT WSBsPYkfh3awgtgsQDVvJk1nB7F5BawlTr5+BNbLKCAm8f3UGrBeZgFxiVtP5jNBHCQgsWTP eWYIW1Ti5eN/YHNEgWZuOHGbHSKuKHF1+nImkNOYBRIkNk6ThBgvKHFy5hOWCYxCs5BMnYVQ NQtJFUSJjsSC3Z/YIGxtiWULXzPD2GcOPGaCsK0lbrYuZUVWs4CRYxWjaHFqcVJuupGxXmpR ZnJxcX6eXl5qySZGYJwc3PJbdQfj5TeOhxgFOBiVeHhnPpaOEmJNLCuuzD3EKMHBrCTCK/sQ KMSbklhZlVqUH19UmpNafIhRmoNFSZz3pCdvlJBAemJJanZqakFqEUyWiYNTqoFRxq2n+kvb tljbfd3b7IoUL0/5+yJQbKnXpX0eM6dW1THl/nUL/B/22/HqzO3ZvK++7QqPXux0yLTitRx7 ZK+8ekDjxcbg2Yp2i12OZku+z7z1uXb18/XCWnPF35n681jLcSwV9ZjjMWlTyi6hRWqxDYGc s6Ln7i1iWX9OJ4bh20cW5pNNdlOUWIozEg21mIuKEwEX0JchjwIAAA== Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-41 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Nov 2017 10:29:55 -0000 --_000_D641B7BD26612christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have submitted a new version (-41) of BUNDLE. The main technical changes are in the Offer/Answer sections: * The SDP bundle-only attribute is now used both in offers (initial and= subsequent) and answers. * If the m- section of an offer contains a BUNDLE address, the answerer= cannot reject that m- section or move the m- section out of the BUNDLE gro= up in the answer. * Some of the ICE offer/answer subsections were removed, because most o= f the text was duplications and people asked why it is needed. I have tried to address to questions/comments I have received, and I person= ally think the procedures are easier to understand now. Regards, Christer --_000_D641B7BD26612christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I have submitted a new version (-41) of BUNDLE.

The main technical changes are in the Offer/Answer sections:
  • The SDP bundle-only attribute is now used both in offers (initial and s= ubsequent) and answers.
  • If the m- section of an offer contains a BU= NDLE address, the answerer cannot reject that m- section or move the m- sec= tion out of the BUNDLE group in the answer.
  • Some of the ICE offer/a= nswer subsections were removed, because most of the text was duplications a= nd people asked why it is needed.
I have tried to address to questions/comments I have received, and I p= ersonally think the procedures are easier to understand now.

Regards,

Christer

--_000_D641B7BD26612christerholmbergericssoncom_-- From nobody Mon Nov 27 05:03:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8911286B1 for ; Mon, 27 Nov 2017 05:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ujfAttrbvJLJ for ; Mon, 27 Nov 2017 05:03:19 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F27612711E for ; Mon, 27 Nov 2017 05:03:19 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-f9-5a1c0d15d3eb Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.B3.19528.51D0C1A5; Mon, 27 Nov 2017 14:03:17 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Mon, 27 Nov 2017 14:03:17 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-40 Thread-Index: AQHTYfBjWbwWzO1zhkWQzJjXCqP/OqMd0XGAgAp+AIA= Date: Mon, 27 Nov 2017 13:03:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6B05346D5A294146A94E0ECAD1FD54D5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7rq4or0yUweIlFhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRsW8GY8F20Yq5x1+wNzD+F+hi5OSQEDCR ODn1BGsXIxeHkMBhRonei2egnCWMEgtmfwByODjYBCwkuv9pgzSICPhKPHt8mw3EFhYwkrgw 8RQzRNxY4sGjFSwQtpVE36oVYDUsAqoSG46eBovzClhL7Om/yQpiCwkUSpzsnQVmcwo4SLyb 8RHMZhQQk/h+ag0TiM0sIC5x68l8JohDBSSW7DnPDGGLSrx8/A+sXlRAT2LDidvsEHFFiZ1n 25kheg0k3p+bD2VbS/zpXAVla0ssW/iaGeIeQYmTM5+wTGAUm4Vk3Swk7bOQtM9C0j4LSfsC RtZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIFxdXDLb6sdjAefOx5iFOBgVOLh7eaUiRJi TSwrrsw9xCjBwawkwiv7UDpKiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU7NTU gtQimCwTB6dUA+OC97uvaTXm5s7jNFeYr/5i5dbb7zoSj97+eutRmZWu80NeuewmBuUe24dp frFzeSQj/nDO6u5SuPfHe1uJb8Zfx9Nn2FhEzd4bLBTY73nu/PfW2dIrS1+bTOpqlNtfl17a /sMnQqK3emtj4/RpnffrDm15WKrrWeZ+oMiXXyBD8/yWyRXmbUosxRmJhlrMRcWJAISITomn AgAA Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-40 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 27 Nov 2017 13:03:26 -0000 Hi Paul, I realised that I forgot to address the issue below in version -41. >I'm fine with new editorial changes being handled during post >publication request processing. I offer the following to be handled >whenever: > >* Section 8.3.1: > > If all of the criteria above are fulfilled, the answerer MUST select > the address assigned to the "m=3D" section as the offerer BUNDLE > address. In the answer, the answerer BUNDLE-tag represents the "m=3D" > section, and the address assigned to the "m=3D" section in the offer > becomes the offerer BUNDLE address. > >I'm having trouble following this. It feels to me that it doesn't quite >say what I think it intends/needs to say. How about the following: > > If all of the criteria above are fulfilled, the answerer MUST accept > the address assigned to that "m=3D" section as the offerer BUNDLE > address. In the answer, the answerer BUNDLE-tag MUST identify the > corresponding "m=3D" section in the answer. Maybe something like: "If all of the criteria above are fulfilled, the answerer MUST accept the address assigned to that "m=3D" section as the offerer BUNDLE address. In the answer, the answerer MUST assign the answerer BUNDLE Address to the corresponding =B3m=3D=B3 section, and the answerer BUNDLE-ta= g MUST identify that =B3m=3D=B3 section." =8Awhich makes me wonder whether we really need section 8.3.2. At least the first paragraph is covered by the second sentence above, in my opinion. >There is still a bit of semantic trouble with this. The problem is that >(as defined in the terminology section) the Offerer BUNDLE-tag and >Offerer BUNDLE address are defined solely by the offer. But when the >answerer is processing the offer, it may reject the section associated >with those and choose a different tag and address as the Offerer >BUNDLE-tab and Offerer BUNDLE address. There really is no terminology >for those. > >Effectively the offerer supplies a list of tags that serve as a priority >list for which tag and address will become the Offerer BUNDLE-tag and >Offerer BUNDLE address. But it is the answered who makes the final >decision, and then signals it back to the offerer via the Answerer >BUNDLE-tag. This also impacts the language in section 8.4. > >A way to alter the text to say this simply doesn't come to me right now. One way would be to say that the answerer must either accept the offerer BUNDLE address, or reject the BUNDLE group. That way the offerer is able to choose what address to use if the BUNDLE group is created, and the procedures would be more simply. Whether it=B9s too restrictive, I don=B9t know... Regards, Christer From nobody Tue Nov 28 02:55:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB860126C23 for ; Tue, 28 Nov 2017 02:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wQUqVKf72nze for ; Tue, 28 Nov 2017 02:55:53 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95EF124BE8 for ; Tue, 28 Nov 2017 02:55:52 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-29-5a1d40b6fecd Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.78.19528.6B04D1A5; Tue, 28 Nov 2017 11:55:50 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Tue, 28 Nov 2017 11:55:50 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-40 Thread-Index: AQHTYfBjWbwWzO1zhkWQzJjXCqP/OqMd0XGAgAp+AICAAW67AA== Date: Tue, 28 Nov 2017 10:55:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: <593AF0169F561D40BDDEE052EB75882D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7k+42B9kogx/vTC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj7rGvLAVflCr6d+1naWBsUOpi5OSQEDCR 6Pt2kbWLkYtDSOAwo8SJN08ZIZwljBKXDrUDORwcbAIWEt3/tEHiIgLNjBLXzi9nAekWFjCS uDDxFDOILSJgLPHg0QoWCNtJYv+mq2wgNouAqsS6Z6/B5vAKWEu8PGMCMX8xo8TNtetZQWo4 BWwkZizexQhiMwqISXw/tYYJxGYWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/gfWKyqgJ7HhxG12 kPkSAooSy/vlQExmAU2J9bv0IaZYSzydM5EVwlaUmNL9kB3E5hUQlDg58wnLBEaxWUiWzULo noWkexaS7llIuhcwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIypg1t+W+1gPPjc8RCj AAejEg+vr6FslBBrYllxZe4hRgkOZiURXnELoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568 UUIC6YklqdmpqQWpRTBZJg5OqQbGkrVfFqxomVbByxtlxxD8VI7t0vPKpMfl3Txfz2p3vMzS k1a17dWawcEdfUVMZZfA5ksWv+pjjc98NL0UErtG1bI7OLrHueSW+cxchZ3+haetWt1C9p87 ftbOOvtk9/y4gFPi/UsmLt3XIR7xZvtU1d070p4oPpPbwvqBp1Txn5zhqu1SVziVWIozEg21 mIuKEwF1iFE1pQIAAA== Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-40 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 28 Nov 2017 10:55:55 -0000 SGksDQoNCkkgY3JlYXRlZCBhIHNtYWxsIFBSLCB3aGljaCBob3BlZnVsbHkgY2xhcmlmaWVzIHRo ZSBvZmZlcmVyL2Fuc3dlcmVyDQpCVU5ETEUgYWRkcmVzcyBzZWxlY3Rpb24gcHJvY2VkdXJlLg0K DQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2RwLWJ1bmRsZS9wdWxsLzQ2DQoNCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIDI3LzExLzE3IDE1OjAzLCAibW11c2ljIG9u IGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyINCjxtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCj5I aSBQYXVsLA0KPg0KPkkgcmVhbGlzZWQgdGhhdCBJIGZvcmdvdCB0byBhZGRyZXNzIHRoZSBpc3N1 ZSBiZWxvdyBpbiB2ZXJzaW9uIC00MS4NCj4NCj4+SSdtIGZpbmUgd2l0aCBuZXcgZWRpdG9yaWFs IGNoYW5nZXMgYmVpbmcgaGFuZGxlZCBkdXJpbmcgcG9zdA0KPj5wdWJsaWNhdGlvbiByZXF1ZXN0 IHByb2Nlc3NpbmcuIEkgb2ZmZXIgdGhlIGZvbGxvd2luZyB0byBiZSBoYW5kbGVkDQo+PndoZW5l dmVyOg0KPj4NCj4+KiBTZWN0aW9uIDguMy4xOg0KPj4NCj4+ICAgIElmIGFsbCBvZiB0aGUgY3Jp dGVyaWEgYWJvdmUgYXJlIGZ1bGZpbGxlZCwgdGhlIGFuc3dlcmVyIE1VU1Qgc2VsZWN0DQo+PiAg ICB0aGUgYWRkcmVzcyBhc3NpZ25lZCB0byB0aGUgIm09IiBzZWN0aW9uIGFzIHRoZSBvZmZlcmVy IEJVTkRMRQ0KPj4gICAgYWRkcmVzcy4gIEluIHRoZSBhbnN3ZXIsIHRoZSBhbnN3ZXJlciBCVU5E TEUtdGFnIHJlcHJlc2VudHMgdGhlICJtPSINCj4+ICAgIHNlY3Rpb24sIGFuZCB0aGUgYWRkcmVz cyBhc3NpZ25lZCB0byB0aGUgIm09IiBzZWN0aW9uIGluIHRoZSBvZmZlcg0KPj4gICAgYmVjb21l cyB0aGUgb2ZmZXJlciBCVU5ETEUgYWRkcmVzcy4NCj4+DQo+PkknbSBoYXZpbmcgdHJvdWJsZSBm b2xsb3dpbmcgdGhpcy4gSXQgZmVlbHMgdG8gbWUgdGhhdCBpdCBkb2Vzbid0IHF1aXRlDQo+PnNh eSB3aGF0IEkgdGhpbmsgaXQgaW50ZW5kcy9uZWVkcyB0byBzYXkuIEhvdyBhYm91dCB0aGUgZm9s bG93aW5nOg0KPj4NCj4+ICAgIElmIGFsbCBvZiB0aGUgY3JpdGVyaWEgYWJvdmUgYXJlIGZ1bGZp bGxlZCwgdGhlIGFuc3dlcmVyIE1VU1QgYWNjZXB0DQo+PiAgICB0aGUgYWRkcmVzcyBhc3NpZ25l ZCB0byB0aGF0ICJtPSIgc2VjdGlvbiBhcyB0aGUgb2ZmZXJlciBCVU5ETEUNCj4+ICAgIGFkZHJl c3MuICBJbiB0aGUgYW5zd2VyLCB0aGUgYW5zd2VyZXIgQlVORExFLXRhZyBNVVNUIGlkZW50aWZ5 IHRoZQ0KPj4gICAgY29ycmVzcG9uZGluZyAibT0iIHNlY3Rpb24gaW4gdGhlIGFuc3dlci4NCj4N Cj5NYXliZSBzb21ldGhpbmcgbGlrZToNCj4NCj4iSWYgYWxsIG9mIHRoZSBjcml0ZXJpYSBhYm92 ZSBhcmUgZnVsZmlsbGVkLCB0aGUgYW5zd2VyZXIgTVVTVCBhY2NlcHQNCj4gICAgdGhlIGFkZHJl c3MgYXNzaWduZWQgdG8gdGhhdCAibT0iIHNlY3Rpb24gYXMgdGhlIG9mZmVyZXIgQlVORExFDQo+ ICAgIGFkZHJlc3MuICBJbiB0aGUgYW5zd2VyLCB0aGUgYW5zd2VyZXIgTVVTVCBhc3NpZ24gdGhl IGFuc3dlcmVyIEJVTkRMRQ0KPkFkZHJlc3MgdG8gdGhlIGNvcnJlc3BvbmRpbmcgwrNtPcKzIHNl Y3Rpb24sIGFuZCB0aGUgYW5zd2VyZXIgQlVORExFLXRhZw0KPk1VU1QgaWRlbnRpZnkgdGhhdCDC s209wrMgc2VjdGlvbi4iDQo+DQo+DQo+xaB3aGljaCBtYWtlcyBtZSB3b25kZXIgd2hldGhlciB3 ZSByZWFsbHkgbmVlZCBzZWN0aW9uIDguMy4yLiBBdCBsZWFzdCB0aGUNCj5maXJzdCBwYXJhZ3Jh cGggaXMgY292ZXJlZCBieSB0aGUgc2Vjb25kIHNlbnRlbmNlIGFib3ZlLCBpbiBteSBvcGluaW9u Lg0KPg0KPg0KPj5UaGVyZSBpcyBzdGlsbCBhIGJpdCBvZiBzZW1hbnRpYyB0cm91YmxlIHdpdGgg dGhpcy4gVGhlIHByb2JsZW0gaXMgdGhhdA0KPj4oYXMgZGVmaW5lZCBpbiB0aGUgdGVybWlub2xv Z3kgc2VjdGlvbikgdGhlIE9mZmVyZXIgQlVORExFLXRhZyBhbmQNCj4+T2ZmZXJlciBCVU5ETEUg YWRkcmVzcyBhcmUgZGVmaW5lZCBzb2xlbHkgYnkgdGhlIG9mZmVyLiBCdXQgd2hlbiB0aGUNCj4+ YW5zd2VyZXIgaXMgcHJvY2Vzc2luZyB0aGUgb2ZmZXIsIGl0IG1heSByZWplY3QgdGhlIHNlY3Rp b24gYXNzb2NpYXRlZA0KPj53aXRoIHRob3NlIGFuZCBjaG9vc2UgYSBkaWZmZXJlbnQgdGFnIGFu ZCBhZGRyZXNzIGFzIHRoZSBPZmZlcmVyDQo+PkJVTkRMRS10YWIgYW5kIE9mZmVyZXIgQlVORExF IGFkZHJlc3MuIFRoZXJlIHJlYWxseSBpcyBubyB0ZXJtaW5vbG9neQ0KPj5mb3IgdGhvc2UuDQo+ Pg0KPj5FZmZlY3RpdmVseSB0aGUgb2ZmZXJlciBzdXBwbGllcyBhIGxpc3Qgb2YgdGFncyB0aGF0 IHNlcnZlIGFzIGEgcHJpb3JpdHkNCj4+bGlzdCBmb3Igd2hpY2ggdGFnIGFuZCBhZGRyZXNzIHdp bGwgYmVjb21lIHRoZSBPZmZlcmVyIEJVTkRMRS10YWcgYW5kDQo+Pk9mZmVyZXIgQlVORExFIGFk ZHJlc3MuIEJ1dCBpdCBpcyB0aGUgYW5zd2VyZWQgd2hvIG1ha2VzIHRoZSBmaW5hbA0KPj5kZWNp c2lvbiwgYW5kIHRoZW4gc2lnbmFscyBpdCBiYWNrIHRvIHRoZSBvZmZlcmVyIHZpYSB0aGUgQW5z d2VyZXINCj4+QlVORExFLXRhZy4gVGhpcyBhbHNvIGltcGFjdHMgdGhlIGxhbmd1YWdlIGluIHNl Y3Rpb24gOC40Lg0KPj4NCj4+QSB3YXkgdG8gYWx0ZXIgdGhlIHRleHQgdG8gc2F5IHRoaXMgc2lt cGx5IGRvZXNuJ3QgY29tZSB0byBtZSByaWdodCBub3cuDQo+DQo+T25lIHdheSB3b3VsZCBiZSB0 byBzYXkgdGhhdCB0aGUgYW5zd2VyZXIgbXVzdCBlaXRoZXIgYWNjZXB0IHRoZSBvZmZlcmVyDQo+ QlVORExFIGFkZHJlc3MsIG9yIHJlamVjdCB0aGUgQlVORExFIGdyb3VwLg0KPg0KPlRoYXQgd2F5 IHRoZSBvZmZlcmVyIGlzIGFibGUgdG8gY2hvb3NlIHdoYXQgYWRkcmVzcyB0byB1c2UgaWYgdGhl IEJVTkRMRQ0KPmdyb3VwIGlzIGNyZWF0ZWQsIGFuZCB0aGUgcHJvY2VkdXJlcyB3b3VsZCBiZSBt b3JlIHNpbXBseS4gV2hldGhlciBpdMK5cw0KPnRvbyByZXN0cmljdGl2ZSwgSSBkb27CuXQga25v dy4uLg0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCj4NCj4NCj4NCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm1tdXNpYyBtYWlsaW5nIGxp c3QNCj5tbXVzaWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYw0KDQo= From nobody Tue Nov 28 03:14:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA6E126BF0 for ; Tue, 28 Nov 2017 03:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 x3sJ3aYT87pA for ; Tue, 28 Nov 2017 03:14:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6FF124B18 for ; Tue, 28 Nov 2017 03:14:50 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-ad-5a1d45296827 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 12.50.08439.9254D1A5; Tue, 28 Nov 2017 12:14:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Tue, 28 Nov 2017 12:14:18 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Additional update to RFC 3264 Thread-Index: AQHTaDoIMKlYK91uo0ebW2NsjMAXjQ== Date: Tue, 28 Nov 2017 11:14:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D64313AB26775christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7ga6mq2yUwYXTAhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoO2V8wFjTwVr/YuZWtg3MzVxcjJISFgIrFk1VxGEFtI4DCj xK5fal2MXED2EkaJiX+/MnUxcnCwCVhIdP/TBqkREVCX+Lq3hxnEFhbQk3hy7TobRNxYomHf PEYIW09ix5P9rCA2i4CqxM69u8DivALWEm8+HQGzGQXEJL6fWsMEYjMLiEvcejKfCeIeAYkl e84zQ9iiEi8f/wObIwo0c8OJ2+wQcSWJHxsusUD0Jkjcv7CPBWK+oMTJmU9YJjAKzUIydhaS sllIyiDiOhILdn9ig7C1JZYtfM0MY5858Biq11pi/q0PzMhqFjByrGIULU4tTspNNzLWSy3K TC4uzs/Ty0st2cQIjJSDW36r7mC8/MbxEKMAB6MSD2+AsWyUEGtiWXFl7iFGCQ5mJRFecQug EG9KYmVValF+fFFpTmrxIUZpDhYlcd6TnrxRQgLpiSWp2ampBalFMFkmDk6pBkZb7ZoZrksW xu24H9WwPfZgeV7Fv6Xbbv1KbmWq+Pl4Qcfn6Y0fg16uTrnr57bkYbzQyotSAXs3n95dqlYu HajoZ5guFmVudmn6uhsyOUnrPpyNvsKRw/7sz5vbnDf93yl8ZDDdElrjssn6kEjvjFkNp3+L rHpxuXuR/odZa+Tqm58xL9Fssu5VYinOSDTUYi4qTgQAbVBIspACAAA= Archived-At: Subject: [MMUSIC] BUNDLE: Additional update to RFC 3264 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 28 Nov 2017 11:14:53 -0000 --_000_D64313AB26775christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As the latest version of BUNDLE also uses bundle-only and zero port value i= n answers, section 6 of RFC 3264 needs to be updated, to indicate that a ze= ro port value in an answer can have other meaning than rejected stream. https://github.com/cdh4u/draft-sdp-bundle/pull/47 Regards, Christer --_000_D64313AB26775christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5009277C397F8D4C952DBF1953F09931@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

As the latest version of BUNDLE also uses bundle-only and zero port va= lue in answers, section 6 of RFC 3264 needs to be updated, to indicate that= a zero port value in an answer can have other meaning than rejected stream= . 


Regards,

Christer
--_000_D64313AB26775christerholmbergericssoncom_-- From nobody Wed Nov 29 00:42:31 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11058124217; Wed, 29 Nov 2017 00:42:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151194494402.8086.18203359009860840974@ietfa.amsl.com> Date: Wed, 29 Nov 2017 00:42:24 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-42.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 08:42:24 -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 WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-42.txt Pages : 65 Date : 2017-11-29 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m= section without meaning that the media described by the "m=" section is disabled or rejected. When RTP-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-42 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-42 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-42 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 Nov 29 00:43:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AE4127286 for ; Wed, 29 Nov 2017 00:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pC8tOzi85iyo for ; Wed, 29 Nov 2017 00:43:26 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CC6124B17 for ; Wed, 29 Nov 2017 00:43:25 -0800 (PST) X-AuditID: c1b4fb2d-d6fff700000036aa-d9-5a1e732b180b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.86.13994.B237E1A5; Wed, 29 Nov 2017 09:43:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Wed, 29 Nov 2017 09:43:23 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-42 Thread-Index: AQHTaO4dx1INJplnO0eQ/JYcar5KuQ== Date: Wed, 29 Nov 2017 08:43:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D64441D02682Echristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7n652sVyUwZMDBhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtaVsxgLfnNWNG+7yNbAeIWji5GTQ0LAROLMzkbmLkYuDiGB w4wSHXuXsUE4Sxgldi9YAeRwcLAJWEh0/9MGaRARUJf4ureHGcQWFlCV+HH/GxtEXEvi1/cz LBC2nsSDDY/BbBagmpdXHjKB2LwC1hItJ3pZQWxGATGJ76fWgMWZBcQlbj2ZzwRxkIDEkj3n mSFsUYmXj/+B1YsCzdxw4jY7RFxRov1pAyPIacwCCRK9vyshxgtKnJz5hGUCo9AsJFNnIVTN QlIFUWIg8f7cfGYIW1ti2cLXULa+xMYvZxkhbGuJeftusyKrWcDIsYpRtDi1uDg33chYL7Uo M7m4OD9PLy+1ZBMjME4Obvmtu4Nx9WvHQ4wCHIxKPLwJ+XJRQqyJZcWVuYcYJTiYlUR4N3gB hXhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTDWdW6ff+ON yEvBVad9f3558o2n+vQjgbafnBNsZKzbM3Ifv/fu/W5idDbn/J4ipxnd+9rYc5YZX95zMyZz qVpGyr5Dkeqfw/X/dFzcfiqPocUk4kCTd9IcLen68kuLNug9+T9PICA0xWxOR+yHd0+muGy/ /qzxtLicS1eRWr/pO2sBf//M9UVKLMUZiYZazEXFiQCptuexjwIAAA== Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-42 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 08:43:27 -0000 --_000_D64441D02682Echristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-42) of BUNDLE. The new version contains editorial clarifications to the BUNDLE address sel= ection procedures, and updates section 6 of RFC 3264. Regards, Christer --_000_D64441D02682Echristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-42) of BUNDLE.

The new version contains editorial clarifications to the BUNDLE addres= s selection procedures, and updates section 6 of RFC 3264.

Regards,

Christer
--_000_D64441D02682Echristerholmbergericssoncom_-- From nobody Wed Nov 29 08:36:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7291C12945C; Wed, 29 Nov 2017 08:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 t04DOFZSYj_q; Wed, 29 Nov 2017 08:36:10 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A051129431; Wed, 29 Nov 2017 08:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=675; q=dns/txt; s=iport; t=1511973370; x=1513182970; h=to:from:subject:cc:message-id:date:mime-version: content-transfer-encoding; bh=pI7Urknga56AspcAygR3Kg0wJE2vAEAR7jbbgvKsHGI=; b=jSsWfGv/1dnP84zWZHkqMw1OVvGnakhdpbGpnLawgD5MEIqlIrMu5+nB PdGYIxmghSauyrOPMWSowIi9RQst+GO4EA7hbBC3Vh7vKbh3Q1d8i/C6l v7rS+wXOdjuceJjqLqDmgiadcAbzoxXA1HoBaakyORMA4acxNpnh4pAKx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAQBR4R5a/5hdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm6EJpkQgU6OfoU+gmeCEQojhRiFFkEWAQEBAQEBAQEBayi?= =?us-ascii?q?FSRVBNQImAl8NCAEBihENEKcngieKZwEBAQEBAQQBAQEBAQEdBYEPgjKCCYFWg?= =?us-ascii?q?hKLN4JjBZMNj0CHdIZChliCFoYPg2OHSYx5iUmBOiUBMoFRTCMVOoIqgwaBbCO?= =?us-ascii?q?KLQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,338,1508803200"; d="scan'208";a="324608161" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 16:36:07 +0000 Received: from [10.118.10.18] (rtp-fandreas-2-881-ap.cisco.com [10.118.10.18]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vATGa5fo013420; Wed, 29 Nov 2017 16:36:05 GMT To: mmusic From: Flemming Andreasen Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Message-ID: <3f84e02a-79aa-db8c-bc20-bad82a90dada@cisco.com> Date: Wed, 29 Nov 2017 11:36:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 16:36:16 -0000 Greetings At this point, there are no further outstanding technical issues in bundle and we believe the authors have addressed all the editorial comments that can reasonably be addressed. We are planning to move ahead with publication request of https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-42 unless we hear any objections from anybody, and hence this will be your last chance to comment on the recent changes. If you have any comments (incl. indications of "reviewed and ready"), please send those to the MMUSIC list and document authors no later than Friday, December 8, 2017. Thanks -- Flemming (as MMUSIC co-chair) From nobody Wed Nov 29 13:39:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CC4126CF6 for ; Wed, 29 Nov 2017 13:39:10 -0800 (PST) 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 autolearn_force=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 ewpbpQLwA34u for ; Wed, 29 Nov 2017 13:39:08 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C921126CD6 for ; Wed, 29 Nov 2017 13:39:08 -0800 (PST) X-AuditID: 12074411-f7dff70000007f0a-be-5a1f28fa92b8 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B0.C5.32522.AF82F1A5; Wed, 29 Nov 2017 16:39:06 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vATLd51f021622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 29 Nov 2017 16:39:06 -0500 To: mmusic@ietf.org References: <3f84e02a-79aa-db8c-bc20-bad82a90dada@cisco.com> From: Paul Kyzivat Message-ID: <211ca5ea-41a3-64ed-8999-028cf81ae8ff@alum.mit.edu> Date: Wed, 29 Nov 2017 16:39:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3f84e02a-79aa-db8c-bc20-bad82a90dada@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqPtbQz7K4PRsToupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY/XhmYwFJ7krevtesTcwzuTsYuTkkBAwkejc0cDUxcjFISSw g0li98tprBDOdyaJhT1v2UCqhAWqJNb+fMEMYosICEvMePsXLC4kYCOxeskaFhCbTUBLYs6h /2A2r4C9xIfDrxlBbBYBVYmFi6aB1YsKpEnsudABVSMocXLmEyCbg4NTwFbixyo+kDCzgJnE vM0PmSFscYlbT+YzQdjyEtvfzmGewMg/C0n3LCQts5C0zELSsoCRZRWjXGJOaa5ubmJmTnFq sm5xcmJeXmqRrqlebmaJXmpK6SZGSFAK7mCccVLuEKMAB6MSD+8NNfkoIdbEsuLK3EOMkhxM SqK8nxbKRgnxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4VXYLRclxJuSWFmVWpQPk5LmYFES5+Vb ou4nJJCeWJKanZpakFoEk5Xh4FCS4P2jDrRHsCg1PbUiLTOnBCHNxMEJMpwHaLgiMIqFeIsL EnOLM9Mh8qcYjTl6em78YeJ4NvN1A7MQS15+XqqUOG8wSKkASGlGaR7cNFhiecUoDvScMG8A SBUPMCnBzXsFtIoJaNXN/dIgq0oSEVJSDYyBZn5HVh+QtxaLDNuWsngJ2+V/R9tEH18VkNVz yTnvuZA9+JaISltNebDh2d1+gtytAjNlsycufTLnlUJri+4TD9PVWmKvrWyyTuukO774/99a wcrMSpklZkrb3Vefpkee7liqy/Hchz2/bLeK23cV/p2PzhxWi9OQY322b//+01Gb//026FBi Kc5INNRiLipOBAC7pxfyBwMAAA== Archived-At: Subject: Re: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 21:39:11 -0000 On 11/29/17 11:36 AM, Flemming Andreasen wrote: > Greetings > > At this point, there are no further outstanding technical issues in > bundle and we believe the authors have addressed all the editorial > comments that can reasonably be addressed. We are planning to move ahead > with publication request of > > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-42 > > unless we hear any objections from anybody, and hence this will be your > last chance to comment on the recent changes. I really wanted to be satisfied with this. But I still have a problem with the language. Christer has definitely improved things by introducing the notion of "suggested offerer BUNDLE address". But this terminology is only used in passing in the text, and lacks a definition. And "Offerer BUNDLE address" is still the term that is defined and used. And it is used in ways that conflict with its definition. I propose that the terminology be revised, and then some minor tweaks the the other text be updated to use it. I think the following definitions will work: Suggested Offerer BUNDLE address: the address:port combination in the "m=" section identified by the Offerer BUNDLE-tag. Offerer BUNDLE address: the address:port combination in the "m=" section of the offer that corresponds (per [RFC3264]) to the "m=" section of the answer that is identified by the Answerer BUNDLE-tag. Thanks, Paul From nobody Thu Nov 30 04:33:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE40F1289C3 for ; Thu, 30 Nov 2017 04:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 WaTwYBawmVLK for ; Thu, 30 Nov 2017 04:33:09 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89214127F0E for ; Thu, 30 Nov 2017 04:33:09 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-9b-5a1ffa83728e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D2.EA.08439.38AFF1A5; Thu, 30 Nov 2017 13:33:07 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Thu, 30 Nov 2017 13:33:04 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) Thread-Index: AQHTaTAvEyyjghXhc02nO9T36F6fJqMr0dGAgAEduIA= Date: Thu, 30 Nov 2017 12:33:04 +0000 Message-ID: References: <3f84e02a-79aa-db8c-bc20-bad82a90dada@cisco.com> <211ca5ea-41a3-64ed-8999-028cf81ae8ff@alum.mit.edu> In-Reply-To: <211ca5ea-41a3-64ed-8999-028cf81ae8ff@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <457E82D75BC75440BEC948942A45458D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7uG7zL/kog58fpCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj4bMpjAXNYhXtd9uZGxgfCHYxcnJICJhI rFm6nrmLkYtDSOAwo8Tl2TtYIJwljBJ3pn1l62Lk4GATsJDo/qcN0iAi4Cvx7PFtNhBbWKBK Yu3PF8wQ8WqJY0cOskLYVhI/WiawgrSyCKhKbJ5qB2LyClhLfProBFIhJFAkcX/hcbApnAIO EpMWnWcBsRkFxCS+n1rDBGIzC4hL3HoynwniTAGJJXvOM0PYohIvH/8D2yQqoCex4cRtdoi4 okT70wZGiF49iRtTp7BB2NYSPc/WMkPY2hLLFr4Gs3kFBCVOznzCMoFRbBaSdbOQtM9C0j4L SfssJO0LGFlXMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgTG1MEtv1V3MF5+43iIUYCDUYmH N/yjfJQQa2JZcWXuIUYJDmYlEV7lE0Ah3pTEyqrUovz4otKc1OJDjNIcLErivCc9eaOEBNIT S1KzU1MLUotgskwcnFINjKLcs7cdyFTbzj7L5kdG351Fx5keKG2bHbC52POXe+DBNV4x+8q+ G6ya7K+0Tf/K1kvJSf8Cp3jvOXhlzvHtuxxscr7U+mWlyClavo3ldLJYbqzb9rz3yuvtvDf7 jzW8OXuzhE1U/JO7h8DRSIW4NxbHi0Wc234Yb5Ni36pQ8YnNeUkep/j+UCWW4oxEQy3mouJE AIcxnlWlAgAA Archived-At: Subject: Re: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 30 Nov 2017 12:33:12 -0000 Hi, >>Greetings >>=20 >> At this point, there are no further outstanding technical issues in >> bundle and we believe the authors have addressed all the editorial >> comments that can reasonably be addressed. We are planning to move >>ahead=20 >> with publication request of >>=20 >> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-42 >>=20 >> unless we hear any objections from anybody, and hence this will be your >> last chance to comment on the recent changes. > >I really wanted to be satisfied with this. But I still have a problem >with the language. > >Christer has definitely improved things by introducing the notion of >"suggested offerer BUNDLE address". But this terminology is only used in >passing in the text, and lacks a definition. And "Offerer BUNDLE >address" is still the term that is defined and used. And it is used in >ways that conflict with its definition. > >I propose that the terminology be revised, and then some minor tweaks >the the other text be updated to use it. I think the following >definitions will work: > > Suggested Offerer BUNDLE address: the address:port combination in the > "m=3D" section identified by the Offerer BUNDLE-tag. > > Offerer BUNDLE address: the address:port combination in the "m=3D" > section of the offer that corresponds (per [RFC3264]) to the "m=3D" > section of the answer that is identified by the Answerer BUNDLE-tag. I don=B9t think that works as suggested. =B3suggested=B2 is only used when a new offerer BUNDLE address is to be negotiated. In subsequent offers, once the BUNDLE group has been created, it is not =B3suggested=B2 anymore: "When an offerer generates a subsequent offer (i.e., a BUNDLE group has previously been negotiated), it MUST assign the previously selected offer BUNDLE address=B2 So, we can fore sure say that the offerer BUNDLE address is selected by the answerer, but when used in subsequent offers it has nothing to do with the answerer BUNDLE-tag. Perhaps something like: Offerer BUNDLE address: once a suggested offerer BUNDLE address has been selected by the answerer, the address:port combination used by the offerer for sending and receiving media. Suggested Offerer BUNDLE address: before an offerer BUNDLE address has been selected by the answerer, or when the offerer wants to change a previously selected offerer BUNDLE address, the address:port combination that the offerer wants to use for sending and receiving media. While suggested by the offerer, the selection of the offerer BUNDLE address is done by the answerer. Do we really need to talk about the BUNDLE-tags in the definition section? How the BUNDLE addresses are identified is described in the spec. Regards, Christer From nobody Thu Nov 30 08:30:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB9B128B93 for ; Thu, 30 Nov 2017 08:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 OxNxYGIHxSwy for ; Thu, 30 Nov 2017 08:30:43 -0800 (PST) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id F36FC1200FC for ; Thu, 30 Nov 2017 08:30:42 -0800 (PST) X-AuditID: 12074414-0ebff70000006ddf-73-5a203231d446 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 91.CE.28127.132302A5; Thu, 30 Nov 2017 11:30:42 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vAUGUdW2010414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Nov 2017 11:30:40 -0500 To: Christer Holmberg , "mmusic@ietf.org" References: <3f84e02a-79aa-db8c-bc20-bad82a90dada@cisco.com> <211ca5ea-41a3-64ed-8999-028cf81ae8ff@alum.mit.edu> From: Paul Kyzivat Message-ID: <9c324955-f5d2-d003-dfe7-14d5f49d6a5f@alum.mit.edu> Date: Thu, 30 Nov 2017 11:30:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixO6iqGtkpBBlsGwhl8WFmYcZLaYuf8zi wOTx6+tVNo8lS34yBTBFcdmkpOZklqUW6dslcGWceX2XteCnTMWDs/+YGxgbxbsYOTkkBEwk Vmx7z9TFyMUhJLCDSWLR3n9sEM5DJomJFw4wgVQJC1RJrP35grmLkYNDRCBF4kgXI0TNEkaJ OT8ngNWwCWhJzDn0nwXE5hWwl1h36jkjSD2LgKrEqbc2IGFRgTSJPRc6oEoEJU7OfAJmcwrY SDw83wRmMwuYSczb/JAZwhaXuPVkPhOELS/RvHU28wRG/llI2mchaZmFpGUWkpYFjCyrGOUS c0pzdXMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MUICVWQH45GTcocYBTgYlXh4JwgrRAmx JpYVV+YeYpTkYFIS5X2jCxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwqt8Qj5KiDclsbIqtSgf JiXNwaIkzvttsbqfkEB6YklqdmpqQWoRTFaGg0NJgpffEGioYFFqempFWmZOCUKaiYMTZDgP 0PBEkBre4oLE3OLMdIj8KUZjjp6eG3+YOJ7NfN3ALMSSl5+XKiXO+8QAqFQApDSjNA9uGizZ vGIUB3pOmJcHZCAPMFHBzXsFtIoJaFXmcpA/iksSEVJSDYxzLl80/P4rQqVhamF12fMaPp/4 c1XSPRmapYZXX59l9Dp8+q5Yu8P++UWRLB+ij7EU3U0/6WVfX9musv2iYutqzc61EwM5Vofc CI41y12xVKz74P5PpV8+LWvdn97Rx5JonHOMX0iqT/Hq83Ydtfczcw1tEnle8s40UAn/eaFg d+f8zVetjJRYijMSDbWYi4oTAQg1ORcRAwAA Archived-At: Subject: Re: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 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, 30 Nov 2017 16:30:45 -0000 On 11/30/17 7:33 AM, Christer Holmberg wrote: > Hi, > >>> Greetings >>> >>> At this point, there are no further outstanding technical issues in >>> bundle and we believe the authors have addressed all the editorial >>> comments that can reasonably be addressed. We are planning to move >>> ahead >>> with publication request of >>> >>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-42 >>> >>> unless we hear any objections from anybody, and hence this will be your >>> last chance to comment on the recent changes. >> >> I really wanted to be satisfied with this. But I still have a problem >> with the language. >> >> Christer has definitely improved things by introducing the notion of >> "suggested offerer BUNDLE address". But this terminology is only used in >> passing in the text, and lacks a definition. And "Offerer BUNDLE >> address" is still the term that is defined and used. And it is used in >> ways that conflict with its definition. >> >> I propose that the terminology be revised, and then some minor tweaks >> the the other text be updated to use it. I think the following >> definitions will work: >> >> Suggested Offerer BUNDLE address: the address:port combination in the >> "m=" section identified by the Offerer BUNDLE-tag. >> >> Offerer BUNDLE address: the address:port combination in the "m=" >> section of the offer that corresponds (per [RFC3264]) to the "m=" >> section of the answer that is identified by the Answerer BUNDLE-tag. > > I don¹t think that works as suggested. > > ³suggested² is only used when a new offerer BUNDLE address is to be > negotiated. In subsequent offers, once the BUNDLE group has been created, > it is not ³suggested² anymore: We could argue about whether it is a suggestion when a new offer is sent that doesn't change the address. (It can be considered a degenerate suggestion, where the only alternative is refusal.) But it isn't worth picking over. I think your proposal below will work. > "When an offerer generates a subsequent offer (i.e., a BUNDLE group > has previously been negotiated), it MUST assign the previously > selected offer BUNDLE address² > > > So, we can fore sure say that the offerer BUNDLE address is selected by > the answerer, but when used in subsequent offers it has nothing to do with > the answerer BUNDLE-tag. Identifying it by the answerer bundle tag will still work. Just different ways of thinking of it. > Perhaps something like: > > Offerer BUNDLE address: once a suggested offerer BUNDLE address has been > selected by the answerer, the address:port combination used by the offerer > for sending and receiving media. > > > Suggested Offerer BUNDLE address: before an offerer BUNDLE address has > been selected by the answerer, or when the offerer wants to change a > previously selected offerer BUNDLE address, the address:port combination > that the offerer wants to use for sending and receiving media. While > suggested by the offerer, the selection of the offerer BUNDLE address is > done by the answerer. > > Do we really need to talk about the BUNDLE-tags in the definition section? > How the BUNDLE addresses are identified is described in the spec. Perhaps not. I was trying to get things nailed down in the definitions. Certainly the way I have been thinking of it is as I wrote it. But the way you have proposed also seems to work as long as the supporting text is consistent. My main concern was that Offerer BUNDLE address is currently used in the text in ways that are inconsistent with the current definition. Thanks, Paul