From nobody Mon Jan 4 16:33:36 2016 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 881331ACDB6; Mon, 4 Jan 2016 16:33:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105003335.29488.57587.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 16:33:35 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 00:33: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 Working Group of the IETF. Title : A Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-11.txt Pages : 96 Date : 2016-01-04 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. Typically media associated with individual media descriptions ("m=" lines) represent RTP sessions and are thus carried over individual underlying transport layer flows. For scenarios where SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions, it is required to understand the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. This specification also categorizes the existing SDP attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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 Jan 4 16:39:47 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2391ACDD6 for ; Mon, 4 Jan 2016 16:39:45 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moXaZjie4VAH for ; Mon, 4 Jan 2016 16:39:42 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 A2DD01ACDD3 for ; Mon, 4 Jan 2016 16:39:42 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id a123so100217097vkh.1 for ; Mon, 04 Jan 2016 16:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aVaSPdyjzHdwwE9jbJGMcgEbPlxirCETIlHBSTW3SNo=; b=cwSbPNscRPg3nB1P7xvTzGbmV611V7i0LEv1h4Pl9PlHNcWbFvEc7tZ2IBuFq+R8Fv k1ApBDPt83WlfbcmKEjS41PBpzseKq2RZYCJTO2u2po+6PhZu0QmJXqB0pUTNASBw0qG osoSimMKCW/7So5DNm3ia4EoagYzXtFgTDiQ1BE2jiES8JqzTBWUbfdvEcm3UxScdPjd aCKJ1rIBea+ayjmUBI+VVtb2qIzZo4KuvTLR0iqef1JIHy2D7ORAgXvahPZRraDSbCUH O3klk1ahNC5h4QBnPeNSBb40XquOBx5i7zfZvgNNLhtsOXAEMEUGhQJQYXFVyZGRTd7y aurw== MIME-Version: 1.0 X-Received: by 10.31.166.208 with SMTP id p199mr64239880vke.122.1451954381454; Mon, 04 Jan 2016 16:39:41 -0800 (PST) Received: by 10.31.106.130 with HTTP; Mon, 4 Jan 2016 16:39:41 -0800 (PST) In-Reply-To: <20160105003335.29488.57587.idtracker@ietfa.amsl.com> References: <20160105003335.29488.57587.idtracker@ietfa.amsl.com> Date: Mon, 4 Jan 2016 16:39:41 -0800 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=001a11416fbc23063305288b7980 Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 00:39:45 -0000 --001a11416fbc23063305288b7980 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello All This version incorporates comments from Bo Burman (Thanks Bo for the review) However, there was one comment that isn't addressed and would love to hear Chairs/WG inputs on the same "The current table ends with =E2=80=9Ccalgextmap=E2=80=9D, but the IANA t= able continues with =E2=80=9Cphone-context=E2=80=9D, =E2=80=9Cclir=E2=80=9D, =E2=80=9CQ763= -nature=E2=80=9D, =E2=80=9CQ763-plan=E2=80=9D, =E2=80=9CQ763-INN=E2=80=9D, =E2=80=9Crequire=E2=80=9D, =E2=80=9Crecord=E2=80=9D, and =E2=80=9Crecordpre= f=E2=80=9D, some of which refer quite old RFCs. Why are those not included in the table?" [Suhas] : These attributes appeared in IANA after we froze assigning categories. Thus as of now, if the MUX draft gets published, these attributes gets the mux category of TBD. Please let me know your thoughts Cheers Suhas On Mon, Jan 4, 2016 at 4:33 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 > Working Group of the IETF. > > Title : A Framework for SDP Attributes when Multiplexin= g > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-11.txt > Pages : 96 > Date : 2016-01-04 > > Abstract: > The Session Description Protocol (SDP) provides mechanisms to > describe attributes of multimedia sessions and of individual media > streams (e.g., Real-time Transport Protocol (RTP) sessions) within a > multimedia session. Typically media associated with individual media > descriptions ("m=3D" lines) represent RTP sessions and are thus carrie= d > over individual underlying transport layer flows. For scenarios > where SDP is used to negotiate the usage of single 5-tuple for > sending and receiving media associated with multiple media > descriptions, it is required to understand the semantic implications > of the SDP attributes associated with the RTP Media Streams > multiplexed over a single underlying transport layer flow. > > The purpose of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. This > specification also categorizes the existing SDP attributes based on > the framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-mux-attributes-= 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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11416fbc23063305288b7980 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 This version incorpora= tes comments from Bo Burman (Thanks Bo for the review)

=
=C2=A0 However, there was one comment that isn't addressed and wou= ld love to hear Chairs/WG inputs on the same

=C2= =A0 "The current table ends with =E2=80=9Ccalgextmap= =E2=80=9D, but the IANA table continues with =E2=80=9Cphone-context=E2=80= =9D, =E2=80=9Cclir=E2=80=9D, =E2=80=9CQ763-nature=E2=80=9D, =E2=80=9CQ763-p= lan=E2=80=9D, =E2=80=9CQ763-INN=E2=80=9D, =E2=80=9Crequire=E2=80=9D, =E2=80= =9Crecord=E2=80=9D, and =E2=80=9Crecordpref=E2=80=9D, some of which refer q= uite old RFCs. Why are those not included in the table?"=

=C2=A0 [Suhas] : These attributes appeared in IANA after w= e froze assigning categories. Thus as of now, if the MUX draft gets publish= ed, these attributes gets the mux category of TBD.
=C2=A0<= /div>
Please let me know your thoughts


Cheers
Suhas

On Mon, Jan 4, 2016 at 4:33 PM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-04

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 Typically media associated with indi= vidual media
=C2=A0 =C2=A0descriptions ("m=3D" lines) represent RTP sessions a= nd are thus carried
=C2=A0 =C2=A0over individual underlying transport layer flows.=C2=A0 For sc= enarios
=C2=A0 =C2=A0where SDP is used to negotiate the usage of single 5-tuple for=
=C2=A0 =C2=A0sending and receiving media associated with multiple media
=C2=A0 =C2=A0descriptions, it is required to understand the semantic implic= ations
=C2=A0 =C2=A0of the SDP attributes associated with the RTP Media Streams =C2=A0 =C2=A0multiplexed over a single underlying transport layer flow.

=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-mmusic-sdp-mux-attributes/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft= -ietf-mmusic-sdp-mux-attributes-11

A diff from the previous version is available at:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-mmusic-sdp-mux-attributes-11


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

--001a11416fbc23063305288b7980-- From nobody Mon Jan 4 17:25:32 2016 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 AFC0D1ACE24; Mon, 4 Jan 2016 17:25:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105012529.25269.83563.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 17:25:29 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-proto-iana-registration-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:25:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles. Author : Suhas Nandakumar Filename : draft-ietf-mmusic-proto-iana-registration-03.txt Pages : 8 Date : 2016-01-04 Abstract: Real-time Transport Protocol (RTP) provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast network services. The data transport is augmented by RTP Control Protocol (RTCP), to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. The RTP specification [RFC3550] establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/ SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-proto-iana-registration-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-proto-iana-registration-03 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 Jan 4 17:29:49 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564131ACE2E for ; Mon, 4 Jan 2016 17:29:48 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKetal1Szs1h for ; Mon, 4 Jan 2016 17:29:46 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 4A02B1ACE28 for ; Mon, 4 Jan 2016 17:29:46 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id k1so132000996vkb.2 for ; Mon, 04 Jan 2016 17:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7gvsbbLD4UWXolDP2ei1f2v8XnDXQ7gpXi0M5fNLNw4=; b=lqkYpuHbFk0an5nYaAHgySvLVIDAS6mN5WOzoWWTckM6kP4xOjmLwLwHHSjFM7vwTt zozzjiXB5iqXFznSdyyiXu6suLGOuBH2cA3cFFmqPXfe1VJJ5zCRP+83gIwHVY/lPI5P Of07yQSBK9gZFGvrpH1P05jZX4EmgkSLhivGzCXnx52sVByqhziwOO6RhRHEAHZDCnW2 O8Qce3wMW2ojvmzHT3vp0fZtE/1IT9TWDZI9rs5bi+eUNJPTUMzn/rZQKwd+z4QXUXC1 0JdUVWTEr88IMK1rVX9plYYxcJGW5/suSrTHbgyZeDPOEbilsHQh/OYx8Fn9fPhl6L+4 02DA== MIME-Version: 1.0 X-Received: by 10.31.50.213 with SMTP id y204mr43532275vky.109.1451957385300; Mon, 04 Jan 2016 17:29:45 -0800 (PST) Received: by 10.31.106.130 with HTTP; Mon, 4 Jan 2016 17:29:45 -0800 (PST) In-Reply-To: <20160105012529.25269.83563.idtracker@ietfa.amsl.com> References: <20160105012529.25269.83563.idtracker@ietfa.amsl.com> Date: Mon, 4 Jan 2016 17:29:45 -0800 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=001a1144053c2e0f5e05288c2c2e Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-proto-iana-registration-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:29:48 -0000 --001a1144053c2e0f5e05288c2c2e Content-Type: text/plain; charset=UTF-8 Hello All This version incorporates comments from Bo Burman and are editorial in nature. Cheers Suhas On Mon, Jan 4, 2016 at 5:25 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 > Working Group of the IETF. > > Title : IANA registrations of SDP 'proto' attribute for > transporting RTP Media over TCP under various RTP profiles. > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-proto-iana-registration-03.txt > Pages : 8 > Date : 2016-01-04 > > Abstract: > Real-time Transport Protocol (RTP) provides end-to-end network > transport functions suitable for applications transmitting real-time > data such as audio, video or simulation data, over multicast or > unicast network services. The data transport is augmented by RTP > Control Protocol (RTCP), to allow monitoring of the data delivery in > a manner scalable to large multicast networks, and to provide minimal > control and identification functionality. > > The RTP specification [RFC3550] establishes a registry of profile > names for use by higher-level control protocols, such as the Session > Description Protocol (SDP), to refer to the transport methods. This > specification describes the following new SDP transport protocol > identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', > 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/ > SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-proto-iana-registration-03 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-proto-iana-registration-03 > > > 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 > --001a1144053c2e0f5e05288c2c2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 This version incorpora= tes comments from Bo Burman and are editorial in nature.

Cheers
Suhas

On Mon, Jan 4, 2016 at 5:25 PM, = <internet-= drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IANA registrations of SDP 'proto' attribute for transporting RTP M= edia over TCP under various RTP profiles.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-proto-iana-registration-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-04

Abstract:
=C2=A0 =C2=A0Real-time Transport Protocol (RTP) provides end-to-end network=
=C2=A0 =C2=A0transport functions suitable for applications transmitting rea= l-time
=C2=A0 =C2=A0data such as audio, video or simulation data, over multicast o= r
=C2=A0 =C2=A0unicast network services.=C2=A0 The data transport is augmente= d by RTP
=C2=A0 =C2=A0Control Protocol (RTCP), to allow monitoring of the data deliv= ery in
=C2=A0 =C2=A0a manner scalable to large multicast networks, and to provide = minimal
=C2=A0 =C2=A0control and identification functionality.

=C2=A0 =C2=A0The RTP specification [RFC3550] establishes a registry of prof= ile
=C2=A0 =C2=A0names for use by higher-level control protocols, such as the S= ession
=C2=A0 =C2=A0Description Protocol (SDP), to refer to the transport methods.= =C2=A0 This
=C2=A0 =C2=A0specification describes the following new SDP transport protoc= ol
=C2=A0 =C2=A0identifiers for transporting RTP Media over TCP: 'TCP/RTP/= AVPF',
=C2=A0 =C2=A0'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS= /RTP/SAVP', 'TCP/DTLS/RTP/
=C2=A0 =C2=A0SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF&#= 39;.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.= org/doc/draft-ietf-mmusic-proto-iana-registration/

There's also a htmlized version available at:
https://tools.ietf.org/html/= draft-ietf-mmusic-proto-iana-registration-03

A diff from the previous version is available at:
https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-mmusic-proto-iana-registration-03


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

--001a1144053c2e0f5e05288c2c2e-- From nobody Tue Jan 5 14:56:32 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF331B2DA4 for ; Tue, 5 Jan 2016 14:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mVYJ9PHwNmk for ; Tue, 5 Jan 2016 14:56:28 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 5D5E11AC41D for ; Tue, 5 Jan 2016 14:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=p9NHpTDnyx6zAHQwvY8/WoWk3qfym6+E6TTkVcg3OHI=; b=fMjI2qZaNwVQcIlZsznbOsYmrr lDRUS8IT5ypK35+jst0f3DNWlCcukhpI3+OzOoE4/hVTkoUMjw/efObzREAoadAnrO9h02LhoDSjR IVH8bazVYB9OxtrMGcUBOeXHNhOkSFjaRvqnZBBaayOcz7g37e/IoDAuIfUdFihReTvQjMSZTjebN Xf2WhmXxnn2m9A1yNOvs1ZmycsELI047+LFHq94Mp9pebPD2QsotORZdynAydkLqAdKM8Rw69988U fAcQD7LMOB9f9x2IIjFVAq/ImDXBxDX3DIonjM0N0mu7Uk6Y7Uvsn1huqvOXeyOA6PHXhcmTGC2/9 ZEYiocQw==; Received: from ppp118-209-157-38.lns20.mel8.internode.on.net ([118.209.157.38]:50221 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aGaWc-00048E-Uf for mmusic@ietf.org; Wed, 06 Jan 2016 09:56:23 +1100 To: mmusic@ietf.org References: <20160105003335.29488.57587.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <568C4A12.8050707@nteczone.com> Date: Wed, 6 Jan 2016 09:56:18 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 22:56:30 -0000 Hello Suhas, My recollection is that RFC2848 which defines the attributes doesn't actually result in an RTP media flow. PINT uses SIP/SDP to trigger a gateway to do something on the GSTN side. Basically its use with multiplexing should be "Not Recommended". As the draft text already says that for "TBD" implementations should treat it as "not recommended", its probably OK to label the attributes as TBD. Regards, Christian On 5/01/2016 11:39 AM, Suhas Nandakumar wrote: > Hello All > > This version incorporates comments from Bo Burman (Thanks Bo for the > review) > > However, there was one comment that isn't addressed and would love > to hear Chairs/WG inputs on the same > > "The current table ends with “calgextmap”, but the IANA table > continues with “phone-context”, “clir”, “Q763-nature”, “Q763-plan”, > “Q763-INN”, “require”, “record”, and “recordpref”, some of which refer > quite old RFCs. Why are those not included in the table?" > > [Suhas] : These attributes appeared in IANA after we froze assigning > categories. Thus as of now, if the MUX draft gets published, these > attributes gets the mux category of TBD. > Please let me know your thoughts > > > Cheers > Suhas > > On Mon, Jan 4, 2016 at 4:33 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 Working Group of the IETF. > > Title : A Framework for SDP Attributes when > Multiplexing > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-11.txt > Pages : 96 > Date : 2016-01-04 > > Abstract: > The Session Description Protocol (SDP) provides mechanisms to > describe attributes of multimedia sessions and of individual media > streams (e.g., Real-time Transport Protocol (RTP) sessions) > within a > multimedia session. Typically media associated with individual > media > descriptions ("m=" lines) represent RTP sessions and are thus > carried > over individual underlying transport layer flows. For scenarios > where SDP is used to negotiate the usage of single 5-tuple for > sending and receiving media associated with multiple media > descriptions, it is required to understand the semantic > implications > of the SDP attributes associated with the RTP Media Streams > multiplexed over a single underlying transport layer flow. > > The purpose of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. This > specification also categorizes the existing SDP attributes based on > the framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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/ > > _______________________________________________ > 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 Tue Jan 5 15:40:16 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819F51A0248 for ; Tue, 5 Jan 2016 15:40:14 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfMcJLZBWDjM for ; Tue, 5 Jan 2016 15:40:12 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 C8E3C1ACCE7 for ; Tue, 5 Jan 2016 15:40:11 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id a123so116858856vkh.1 for ; Tue, 05 Jan 2016 15:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W9LTVJ7EwI423vF2CBSZBJ93FLF6bDHIIQ6dnZkabac=; b=yekW4MHpCdQdpUHj6H5kyvkkTnFVH89Lx9b9pMepy1LEDC+kth0GlsQjYnqDPQ9iND 1Csm7y3XzCvox+sSfKcf74nT1zq+/zO8EwVozHm598B5Gx1yBj+DK9n1Mc2CIT4wYLmv 63O01HcmcwiwqHcXSB8IOom0IJF0jg8TthTV9oIEEI/MJrkyUlvLa2jUBCVT6t3NKrjR dekmkNoOpQuCUciRXDZeGqYg7KQaE9QtiiBRl2cwQrykxofgyo4MXV7b3/dLWvVPey0E /sf/ObLcENv78Z/m/kKmWvmgYhGwXdTt9COsCUnhOW28gffpCPfrrDIHvsfEG4fqOzXG LMaQ== MIME-Version: 1.0 X-Received: by 10.31.5.15 with SMTP id 15mr65360719vkf.108.1452037210834; Tue, 05 Jan 2016 15:40:10 -0800 (PST) Received: by 10.31.106.130 with HTTP; Tue, 5 Jan 2016 15:40:10 -0800 (PST) In-Reply-To: <568C4A12.8050707@nteczone.com> References: <20160105003335.29488.57587.idtracker@ietfa.amsl.com> <568C4A12.8050707@nteczone.com> Date: Tue, 5 Jan 2016 15:40:10 -0800 Message-ID: From: Suhas Nandakumar To: Christian Groves Content-Type: multipart/alternative; boundary=001a1143df74270dbe05289ec28a Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 23:40:14 -0000 --001a1143df74270dbe05289ec28a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Christian for checking on this. Also regarding the updates to the document, I was thinking of not adding these attributes to the draft. Since the IANA section says, for all the attributes in the IANA registry that doesn't has the category assigned by the MUX draft, IANA should assign the category as TBD. please let me know if this works as well Cheers Suhas On Tue, Jan 5, 2016 at 2:56 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Suhas, > > My recollection is that RFC2848 which defines the attributes doesn't > actually result in an RTP media flow. PINT uses SIP/SDP to trigger a > gateway to do something on the GSTN side. Basically its use with > multiplexing should be "Not Recommended". As the draft text already says > that for "TBD" implementations should treat it as "not recommended", its > probably OK to label the attributes as TBD. > > Regards, Christian > > On 5/01/2016 11:39 AM, Suhas Nandakumar wrote: > >> Hello All >> >> This version incorporates comments from Bo Burman (Thanks Bo for the >> review) >> >> However, there was one comment that isn't addressed and would love to >> hear Chairs/WG inputs on the same >> >> "The current table ends with =E2=80=9Ccalgextmap=E2=80=9D, but the IANA = table continues >> with =E2=80=9Cphone-context=E2=80=9D, =E2=80=9Cclir=E2=80=9D, =E2=80=9CQ= 763-nature=E2=80=9D, =E2=80=9CQ763-plan=E2=80=9D, =E2=80=9CQ763-INN=E2=80= =9D, >> =E2=80=9Crequire=E2=80=9D, =E2=80=9Crecord=E2=80=9D, and =E2=80=9Crecord= pref=E2=80=9D, some of which refer quite old RFCs. >> Why are those not included in the table?" >> >> [Suhas] : These attributes appeared in IANA after we froze assigning >> categories. Thus as of now, if the MUX draft gets published, these >> attributes gets the mux category of TBD. >> Please let me know your thoughts >> >> >> Cheers >> Suhas >> >> On Mon, Jan 4, 2016 at 4:33 PM, > 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 Working Group of the IETF. >> >> Title : A Framework for SDP Attributes when >> Multiplexing >> Author : Suhas Nandakumar >> Filename : draft-ietf-mmusic-sdp-mux-attributes-11.tx= t >> Pages : 96 >> Date : 2016-01-04 >> >> Abstract: >> The Session Description Protocol (SDP) provides mechanisms to >> describe attributes of multimedia sessions and of individual medi= a >> streams (e.g., Real-time Transport Protocol (RTP) sessions) >> within a >> multimedia session. Typically media associated with individual >> media >> descriptions ("m=3D" lines) represent RTP sessions and are thus >> carried >> over individual underlying transport layer flows. For scenarios >> where SDP is used to negotiate the usage of single 5-tuple for >> sending and receiving media associated with multiple media >> descriptions, it is required to understand the semantic >> implications >> of the SDP attributes associated with the RTP Media Streams >> multiplexed over a single underlying transport layer flow. >> >> The purpose of this specification is to provide a framework for >> analyzing the multiplexing characteristics of SDP attributes. Th= is >> specification also categorizes the existing SDP attributes based = on >> the framework described herein. >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-11 >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-mux-attributes= -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/ >> >> _______________________________________________ >> 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 > --001a1143df74270dbe05289ec28a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Christian for checking on this.=C2=A0

Also regarding the updates to the document, I was thinking of not add= ing these attributes to the draft. Since the IANA section says, for all the= attributes in the IANA registry that doesn't has the category assigned= by the MUX draft, IANA should assign the category as TBD.

please let me know if this works as well

= Cheers
Suhas


On Tue, Jan 5, 2016 at 2:56 PM, Christian G= roves <Christian.Groves@nteczone.com> wrote:
=
Hello Suhas,

My recollection is that RFC2848 which defines the attributes doesn't ac= tually result in an RTP media flow. PINT uses SIP/SDP to trigger a gateway = to do something on the GSTN side. Basically its use with multiplexing shoul= d be "Not Recommended". As the draft text already says that for &= quot;TBD" implementations should treat it as "not recommended&quo= t;, its probably OK to label the attributes as TBD.

Regards, Christian

On 5/01/2016 11:39 AM, Suhas Nandakumar wrote:
Hello All

=C2=A0 This version incorporates comments from Bo Burman (Thanks Bo for the= review)

=C2=A0 However, there was one comment that isn't addressed and would lo= ve to hear Chairs/WG inputs on the same

"The current table ends with =E2=80=9Ccalgextmap=E2=80=9D, but the IAN= A table continues with =E2=80=9Cphone-context=E2=80=9D, =E2=80=9Cclir=E2=80= =9D, =E2=80=9CQ763-nature=E2=80=9D, =E2=80=9CQ763-plan=E2=80=9D, =E2=80=9CQ= 763-INN=E2=80=9D, =E2=80=9Crequire=E2=80=9D, =E2=80=9Crecord=E2=80=9D, and = =E2=80=9Crecordpref=E2=80=9D, some of which refer quite old RFCs. Why are t= hose not included in the table?"

[Suhas] : These attributes appeared in IANA after we froze assigning catego= ries. Thus as of now, if the MUX draft gets published, these attributes get= s the mux category of TBD.
Please let me know your thoughts


Cheers
Suhas

On Mon, Jan 4, 2016 at 4:33 PM, <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org<= /a>>> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts
=C2=A0 =C2=A0 directories.
=C2=A0 =C2=A0 =C2=A0This draft is a work item of the Multiparty Multimedia = Session
=C2=A0 =C2=A0 Control Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: A Framework for SDP Attributes when
=C2=A0 =C2=A0 Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 : Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-mmusic-sdp-mux-attributes-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2016-01-04

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0The Session Description Protocol (SDP) provides = mechanisms to
=C2=A0 =C2=A0 =C2=A0 =C2=A0describe attributes of multimedia sessions and o= f individual media
=C2=A0 =C2=A0 =C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP= ) sessions)
=C2=A0 =C2=A0 within a
=C2=A0 =C2=A0 =C2=A0 =C2=A0multimedia session.=C2=A0 Typically media associ= ated with individual
=C2=A0 =C2=A0 media
=C2=A0 =C2=A0 =C2=A0 =C2=A0descriptions ("m=3D" lines) represent = RTP sessions and are thus
=C2=A0 =C2=A0 carried
=C2=A0 =C2=A0 =C2=A0 =C2=A0over individual underlying transport layer flows= .=C2=A0 For scenarios
=C2=A0 =C2=A0 =C2=A0 =C2=A0where SDP is used to negotiate the usage of sing= le 5-tuple for
=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving media associated with mult= iple media
=C2=A0 =C2=A0 =C2=A0 =C2=A0descriptions, it is required to understand the s= emantic
=C2=A0 =C2=A0 implications
=C2=A0 =C2=A0 =C2=A0 =C2=A0of the SDP attributes associated with the RTP Me= dia Streams
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiplexed over a single underlying transport l= ayer flow.

=C2=A0 =C2=A0 =C2=A0 =C2=A0The purpose of this specification is to provide = a framework for
=C2=A0 =C2=A0 =C2=A0 =C2=A0analyzing the multiplexing characteristics of SD= P attributes.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 =C2=A0specification also categorizes the existing SDP = attributes based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0the framework described herein.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://datatrac= ker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/

=C2=A0 =C2=A0 There's also a htmlized version available at:
=C2=A0 =C2=A0 https://tools.ietf.= org/html/draft-ietf-mmusic-sdp-mux-attributes-11

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 https://www= .ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-mux-attributes-11


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of
=C2=A0 =C2=A0 submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at
=C2=A0 =C2=A0 tools.ietf.org <http://tools.ietf.org>.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 mmusic mailing list
 =C2=A0 =C2=A0 mmusic@i= etf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mmu= sic




_______________________________________________
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

--001a1143df74270dbe05289ec28a-- From nobody Fri Jan 8 02:30:35 2016 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 CA1821AD084; Fri, 8 Jan 2016 02:30:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160108103034.29825.7212.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 02:30:34 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-proto-iana-registration-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:30: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 Working Group of the IETF. Title : IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles. Author : Suhas Nandakumar Filename : draft-ietf-mmusic-proto-iana-registration-04.txt Pages : 8 Date : 2016-01-08 Abstract: Real-time Transport Protocol (RTP) provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast network services. The data transport is augmented by RTP Control Protocol (RTCP), to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. The RTP specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/ SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-proto-iana-registration-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-proto-iana-registration-04 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 Jan 8 04:50:44 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9EE1B2850 for ; Fri, 8 Jan 2016 04:50:43 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tZWdW1XROqt for ; Fri, 8 Jan 2016 04:50:41 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EC01AE4CB for ; Fri, 8 Jan 2016 04:50:40 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-a1-568fb09e7a05 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.00.02707.E90BF865; Fri, 8 Jan 2016 13:50:38 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.202]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Fri, 8 Jan 2016 13:50:38 +0100 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Thread-Topic: Publication requested for draft-ietf-mmusic-proto-iana-registration-04 Thread-Index: AdFKECoXHC8ACIG6RqaTkD56o4I2jw== Date: Fri, 8 Jan 2016 12:50:36 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E91B7B0ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2J7lO68Df1hBptuqFhMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGff372EumC1Z8Wq7fAPjHbEuRk4OCQETiQNvXzJD2GISF+6t Z+ti5OIQEjjMKHHg1msmCGcxo0TP5o1MIFVsAhoS83fcZQSxRQQMJGavnAFmCwsESkydvIEN Ih4m0XL9KguErScx7eANdhCbRUBFYvnXZ2A2r4CvxNIPX8E2MwrIStz/fg+snllAXOLWk/lM EBcJSCzZcx7qOlGJl4//sXYxcgDZihLL++UgyvMlzh/sYoEYKShxcuYTlgmMQrOQTJqFpGwW kjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLU4KTfdyEgvtSgzubg4P08vL7Vk EyMwIg5u+W2wg/Hlc8dDjAIcjEo8vB/e9oUJsSaWFVfmHmKU4GBWEuFds7Q/TIg3JbGyKrUo P76oNCe1+BCjNAeLkjhvkkxjmJBAemJJanZqakFqEUyWiYNTqoFRI4EjmDdapdv3QUgx28SU loj5y3sUZk5m61WNCLlTEcy5z3m9ZVOXae+cyeKWawKKU/Pes0neePKbr1PVtV3wY6S2W7nS qZyt5mafS/Vun7p/5XvAU9d1NuzshwwvL6jdkmBbLHpz9cWweNXlTfOj7daoCO6bvPau2epj +8xurHdfkv5TZKMSS3FGoqEWc1FxIgDKlxuUhAIAAA== Archived-At: Subject: [MMUSIC] Publication requested for draft-ietf-mmusic-proto-iana-registration-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:50:43 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E91B7B0ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MMUSIC, I just requested publication for draft-ietf-mmusic-proto-iana-registration-= 04. Version -04 removed a minor nit, compared to -03. You can find the shepherd's write-up here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/= shepherdwriteup/ /Bo MMUSIC co-chair --_000_BBE9739C2C302046BD34B42713A1E2A22E91B7B0ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MMUSIC,

 

I just requested publication for draft-ietf-mmusic-p= roto-iana-registration-04.

Version -04 removed a minor nit, compared to -03.

 

You can find the shepherd’s write-up here:

https://datatracker.iet= f.org/doc/draft-ietf-mmusic-proto-iana-registration/shepherdwriteup/

 

/Bo

MMUSIC co-chair

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E91B7B0ESESSMB105erics_-- From nobody Fri Jan 8 05:20:50 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8A1A8952; Fri, 8 Jan 2016 05:20:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3rkDKC7QQVV; Fri, 8 Jan 2016 05:20:45 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69D91A8996; Fri, 8 Jan 2016 05:20:41 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-f3-568fb7a71087 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.FF.05041.7A7BF865; Fri, 8 Jan 2016 14:20:39 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.202]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Fri, 8 Jan 2016 14:20:39 +0100 From: Bo Burman To: "mmusic@ietf.org" , "mmusic-ads@ietf.org" Thread-Topic: [MMUSIC] Call for WG adoption of draft-holmberg-mmusic-mux-exclusive Thread-Index: AdE3Sd368eATP/9mTBSWzyZmj+5snAAakrqAAA+GI4AEiJ1awA== Date: Fri, 8 Jan 2016 13:20:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E91B88FESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7lu7y7f1hBrdPy1s8vcNjMXX5YxYH Jo8lS34yBTBGcdmkpOZklqUW6dslcGX07L7AVrCnpOJp3ySmBsaF6V2MnBwSAiYSbxZuZISw xSQu3FvP1sXIxSEkcJhRYvn5S6wQzmJGic5Zf9hAqtgENCTm77gL1MHBISIQJvH6WDlImFnA TOLSrRMsILawQLDE31M7wMpFBEIkvrc+hrKdJNreXGAFsVkEVCR+nnjLDGLzCvhKfFrawwKx ayOjxI5/f8CKOAVsJe5PmQRWxCggK3H/+z0WiGXiEreezGeCuFpAYsme88wQtqjEy8f/WEFu kxBQlFjeLwdRni9xftlhVohdghInZz5hmcAoOgvJpFlIymYhKYOI60gs2P2JDcLWlli28DUz jH3mwGMmZPEFjOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQJj7OCW31Y7GA8+dzzEKMDB qMTD++FtX5gQa2JZcWXuIUYJDmYlEd5VW/vDhHhTEiurUovy44tKc1KLDzFKc7AoifMmyTSG CQmkJ5akZqemFqQWwWSZODilGhg7RKViDPvVrZl+ib2Zta528TyJBM6fzKK/YuQ23Hr97//B awwfu/+LcoooNW1r+q/oZHM0LCz6+6QNLNEBEp/zJhTb3ZJXYDGY6OJyvPf+zFa/zttfc17e sqkVKX9yg6M81170RarRMvkTUy+U2p75eUsrJSl7f7H7jYs7/hy3ZXBZqPlth4kSS3FGoqEW c1FxIgCNQ94DrQIAAA== Archived-At: Cc: Christer Holmberg Subject: Re: [MMUSIC] Call for WG adoption of draft-holmberg-mmusic-mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:20:48 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E91B88FESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MMUSIC, The call for adoption closed Jan 5 and there were only supportive responses= to work on this, and to adopt the document as WG starting point, no object= ions. I therefore conclude there is consensus to start working on this and = to adopt this draft. MMUSIC ADs, please add a milestone for this work. /Bo MMUSIC co-chair From: Hutton, Andrew [mailto:andrew.hutton@unify.com] Sent: den 16 december 2015 13:10 To: mmusic@ietf.org; Bo Burman; Christer Holmberg Subject: Re: [MMUSIC] Call for WG adoption of draft-holmberg-mmusic-mux-exc= lusive I support working on this problem and adopting the draft. Andy On 15 Dec 2015, at 23:45, Bernard Aboba > wrote: I support working on this issue and will participate in the discussion. Als= o, I believe the draft is worthy of adoption. On Dec 15, 2015, at 3:40 PM, Bo Burman > wrote: MMUSIC, Do you support working on this problem? If so, we should ask for a mileston= e for it. Do you support adopting draft-holmberg-mmusic-mux-exclusive-03 as a WG docu= ment for such work? Please indicate your support or non-support to the two questions above by r= esponding to this mail. If you support that the WG work on this, also indic= ate if you will participate in the discussion. If you do not support this d= raft becoming a WG document, please also provide the reason why. Please provide your response by Jan 5, 2016, 23:59 UTC; this longer consens= us period is chosen due to holiday season coming up. /Bo & Flemming MMUSIC co-chairs From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: den 15 december 2015 15:47 To: mmusic@ietf.org Cc: mmusic-chairs@ietf.org Subject: Draft new version: draft-holmberg-mmusic-mux-exclusive-03 Hi, Yet a new version (-03), where the status has been changed to "Standards tr= ack". Thanks to Sean for spotting it! There are no other changes compared to the -02 version. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 15. joulukuuta 2015 14:52 To: mmusic@ietf.org Cc: mmusic-chairs@ietf.org Subject: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-02 Hi, I've submitted a new version (-02) of draft-mux-exclusive. The only change (based on the comment from Roman) compared to the previous = version is the clarification that, if the SDP 'rtcp' attribute contains the= IP address part, it must be identical to the value of the associated c=3D = line. 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 --_000_BBE9739C2C302046BD34B42713A1E2A22E91B88FESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MMUSIC,

 

The call for adoption = closed Jan 5 and there were only supportive responses to work on this, and = to adopt the document as WG starting point, no objections. I therefore conc= lude there is consensus to start working on this and to adopt this draft.

 

MMUSIC ADs, please add= a milestone for this work.

 

/Bo<= /p>

MMUSIC co-chair

 

From: Hutton, = Andrew [mailto:andrew.hutton@unify.com]
Sent: den 16 december 2015 13:10
To: mmusic@ietf.org; Bo Burman; Christer Holmberg
Subject: Re: [MMUSIC] Call for WG adoption of draft-holmberg-mmusic-= mux-exclusive

 

I support working on this problem and adopting the d= raft.

 

Andy


On 15 Dec 2015, at 23:45, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

I support working on this issue and will participate= in the discussion. Also, I believe the draft is worthy of adoption.


On Dec 15, 2015, at 3:40 PM, Bo Burman <bo.burman@ericsson.com> wrote:

MMUSIC,

 

Do you support working= on this problem? If so, we should ask for a milestone for it.<= /o:p>

 

Do you support adoptin= g draft-holmberg-mmusic-mux-exclusive-03 as a WG document for such work?

 

Please indicate your s= upport or non-support to the two questions above by responding to this mail= . If you support that the WG work on this, also indicate if you will partic= ipate in the discussion. If you do not support this draft becoming a WG document, please also provide the reason = why.

 

Please provide your re= sponse by Jan 5, 2016, 23:59 UTC; this longer consensus period is chosen du= e to holiday season coming up.

 

/Bo & Flemming

MMUSIC co-chairs

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: den 15 december 2015 15:47
To: mmusic@ietf.org
Cc: mmusic-chairs@ietf.org=
Subject: Draft new version: draft-holmberg-mmusic-mux-exclusive-03

 

Hi,<= /p>

 

Yet a new version (-03= ), where the status has been changed to ”Standards track”. Than= ks to Sean for spotting it!

 

There are no other cha= nges compared to the -02 version.

 

Regards,

 

Christer

 

From:<= /b> mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 15. joulukuuta 2015 14:52
To: mmusic@ietf.org
Cc: mmusic-chairs@ietf.org=
Subject: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclu= sive-02

 

Hi,

 

I’ve submitted a new version (-02) of draft-mu= x-exclusive.

 

The only change (based on the comment from Roman) co= mpared to the previous version is the clarification that, if the SDP ‘= ;rtcp’ attribute contains the IP address part, it must be identical t= o the value of the associated c=3D line.

 

Regards,

 

Christer

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

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

--_000_BBE9739C2C302046BD34B42713A1E2A22E91B88FESESSMB105erics_-- From nobody Mon Jan 11 11:36:49 2016 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 053E61A88D6; Mon, 11 Jan 2016 11:36:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111193649.21598.79056.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 11:36:49 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-24.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:36:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-24.txt Pages : 50 Date : 2016-01-11 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 address:port combination (BUNDLE address) for receiving media, referred to as bundled media, associated with multiple SDP media descriptions ("m=" lines). 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. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. 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 media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 05:28:35 2016 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 E14191AD2F6 for ; Tue, 12 Jan 2016 05:28:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112132833.13160.39446.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 05:28:33 -0800 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:28:34 -0000 Changed milestone "Submit RTP Payload Format Constraints as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit MSRP over Data Channels as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP as Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/mmusic/charter/ From nobody Tue Jan 12 05:47:46 2016 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 19EBA1AD356; Tue, 12 Jan 2016 05:47:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112134745.20475.62087.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 05:47:45 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:47:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-00.txt Pages : 7 Date : 2016-01-12 Abstract: This document defines how an endpoint can indicate exclusive support of RTP/RTCP multiplexing using the Session Description Protocol (SDP). The document updates RFC 5761, by defining how the SDP 'rtcp' attribute is used, together with the SDP 'rtcp-mux' attribute, to indicate exclusive support of RTP/RTCP multiplexing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 05:54:07 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B061B29F5 for ; Tue, 12 Jan 2016 05:54:06 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LD0s5fBVhRB for ; Tue, 12 Jan 2016 05:54:04 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DEC1B29F2 for ; Tue, 12 Jan 2016 05:54:03 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-8e-569505794666 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.59.30208.97505965; Tue, 12 Jan 2016 14:54:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Tue, 12 Jan 2016 14:54:01 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-00 Thread-Index: AdFNQKvnhFioKRyrRWK7xETtrraLew== Date: Tue, 12 Jan 2016 13:54:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D14CC5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D14CC5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7om4l69QwgwUdUhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpm/fAVbpCouzPRqYHwg3sXIwSEhYCLR9dm6i5ETyBSTuHBv PVsXIxeHkMBhRonrS2awQDiLGSUmrZzPBtLAJmAh0f1PG6RBREBd4uveHmYQW1jATmLewsVM EHFnib7OT6wQtp7Eht+L2UBsFgFViS1HloPZvAK+EqtndrKD2IxAi7+fWgPWyywgLnHryXwm iIMEJJbsOc8MYYtKvHz8jxXCVpS4On05VH2+xKMNt1khZgpKnJz5hGUCo9AsJKNmISmbhaQM Iq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQI jIaDW36r7mC8/MbxEKMAB6MSD+8H4ylhQqyJZcWVuYcYJTiYlUR4L/8GCvGmJFZWpRblxxeV 5qQWH2KU5mBREudNkmkMExJITyxJzU5NLUgtgskycXBKNTAyPRFL5L+xn9Eyan9V3LJdvqK7 zr1a+HVCmcuMztNL60SvmF9SczusG/6i/anODWnPCd3cO058nrH6wqUPV85c3x4nc/Hj2UlX Tyw6UsplpnF+hqHJ6YcSG+t+HDwp864z7OfU5L7Dp1/83xA1c8Fs+bDOhp5zjhbrjFjsA/9I fuTKfip3x+WTpxJLcUaioRZzUXEiANZPDIyCAgAA Archived-At: Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:54:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D14CC5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted the -00 version of draft-ietf-mmusic-mux-exclusive. There are no technical changes from the previous individual version. The draft can also be found no github: https://github.com/cdh4u/draft-mux-e= xclusive (NOTE: personal repo) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D14CC5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted the -00 ve= rsion of draft-ietf-mmusic-mux-exclusive.

 

There are no technical changes = from the previous individual version.

 

The draft can also be found no = github: https://github.com/cdh4u/draft-mux-exclusive (NOTE: personal repo)=

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D14CC5ESESSMB209erics_-- From nobody Tue Jan 12 12:48:06 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745151A88C6 for ; Tue, 12 Jan 2016 12:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c19RtXVdc2uK for ; Tue, 12 Jan 2016 12:48:03 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::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 6FC341A88C3 for ; Tue, 12 Jan 2016 12:48:03 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id t15so130176586igr.0 for ; Tue, 12 Jan 2016 12:48:03 -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:date:message-id:subject:from:to :content-type; bh=/RZRu/f0kNvQ3KUpnCgd81o05nNoZ3VFKDwaFIh8gJg=; b=GmY+yXJMapLNrLdwzAFRGRdeaHrxH/jQI4ndvcSwt5yG/3z5qjJtq+UQI9qXjSK2yS gaF0DYSpgjp3viwgDxI7FxoxW/pxfzlS2cjuRcix90UZT3sGwArdkxmDP2HKFeSeElQe KelN/1PBSF2VW3D/M5FUT/YCi+aTpdQBHgI34m2ZNJ7PMd0DzUciE1ZFrulmLgUUq4u4 HDewC1lCWi6qfBQqTaEzLN1toeG8uSaOzweNLVMzEOB/bGlRF27hiPncnBgPKnpgB/hV hODM0NEJz4Z0OzH0uGk1TSBpUTaBcI8NScCKSc2wvHSR7wDDw0xo4dmJGzc+MMqFiion oXoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=/RZRu/f0kNvQ3KUpnCgd81o05nNoZ3VFKDwaFIh8gJg=; b=E0qkLOpsQkUNgoG36N0pMwih4caC2UNau4X6M07AWCQCeubdh/kNmTKJNlGCx4+rSc fBGcwEZ8OORt/8edNRlwHjWHo2HWNKYdLA1eXjw4Am3Py6OqlUpHWKvAoRNnlz7z3vxN 8UmPjwFEogZK6G2rx4JlB/02X+NS8tWKuByuFFLyA8PentE7rGOcGg2Y+Iv88OUjLb5E raVXTlFq16ujR+clTNQudmwnOBXkO2NAfteklo7QpVXmS5tZczChCORxxJ7KoD+aUmcW bgqOBRNrNCjtTw9m9BebN9STjCp3dMtt+mm+fId+o5xGQ/PYEKyByWosfnHqMUdLxR0S uHNw== X-Gm-Message-State: ALoCoQnnmGBsN1tXi1zrbGU8RRvr6gjKjBiQgZXQyFwaky9lD5pCpyP/AEpyOdvNHxYjkOKYmxaPp8OZYXzY4vhs05P7wsd+Wg== X-Received: by 10.50.33.20 with SMTP id n20mr19581483igi.17.1452631682739; Tue, 12 Jan 2016 12:48:02 -0800 (PST) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by smtp.gmail.com with ESMTPSA id h96sm41628758iod.28.2016.01.12.12.48.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 12:48:01 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id z14so135533318igp.1; Tue, 12 Jan 2016 12:48:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr19859507igb.24.1452631680694; Tue, 12 Jan 2016 12:48:00 -0800 (PST) Received: by 10.36.105.15 with HTTP; Tue, 12 Jan 2016 12:48:00 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> Date: Tue, 12 Jan 2016 15:48:00 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "ice@ietf.org" , "mmusic@ietf.org" , Christer Holmberg , marc@petit-huguenin.org, =?UTF-8?B?QXJpIEtlcsOkbmVu?= , snandaku@cisco.com Content-Type: multipart/alternative; boundary=089e011841685143ef0529292bbe Archived-At: Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 20:48:05 -0000 --089e011841685143ef0529292bbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable H All, Cross-posting to MMUSIC, since this affects both RFC 5245bis and draft-ietf-mmusic-ice-sip-sdp RFC 5245 and draft-ietf-mmusic-ice-sip-sdp currently say the following: The default candidates are added to the SDP as the default destination for media. For streams based on RTP, this is done by placing the IP address and port of the RTP candidate into the c and m lines, respectively. *If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605 [RFC3605 ].* If RTCP is not in use, the agent MUST signal that using b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556 ]. There is an ongoing discussion whether the rtcp attribute is required in case of trickle ICE, when an offer is sent without candidate information, the RTP port set to 9, and the RTP IP address set to 0.0.0.0. Example: a=3Drtcp: 9 IN IP4 0.0.0.0 According to Christer this is not needed, as there is no candidate to =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested mechanis= m for indicating exclusive support of RTP/RTCP multiplexing (draft-holmberg-mmusic-mux-exclusive). Furthermore, according to section 2.1 of RFC 3605: The RTCP attribute is used to document the RTCP port used for media stream, when that port is not the next higher (odd) port number following the RTP port described in the media line. RFC 5245 overwrites the guideline from RFC 3605 and states that SDP rtcp attribute MUST be present even when RTCP default candidate is not present or when RTCP candidate is using port rtp+1, which is currently the the most common scenario since sequential port is typically allocated for RTCP by TURN. I suggest changing the language in section 4.2 of draft-ietf-mmusic-ice-sip-sdp to: The default candidates are added to the SDP as the default destination for media. For streams based on RTP, this is done by placing the IP address and port of the RTP candidate into the c and m lines, respectively. *If the agent is utilizing RTCP and if RTCP * * candidate is present and not equal to the same address and * * the next higher port number of the RTP candidate, the agent MUST encode the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605 [RFC3605 ].* If RTCP is not in use, the agent MUST signal that using b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556 ]. Regards, _____________ Roman Shpount On Tue, Jan 12, 2016 at 8:02 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > RFC 5245 says the following: > > > > =E2=80=9CIf the agent is utilizing RTCP, i= t MUST > encode > > the RTCP candidate using the a=3Drtcp > attribute as defined in RFC 3605 > > [RFC3605].=E2=80=9D > > > > There is an ongoing discussion whether the rtcp attribute is required in > case of trickle ICE, when an offer is sent without candidate information, > the RTP port set to 9, and the RTP IP address set to 0.0.0.0. > > > > Example: > > > > a=3Drtcp: 9 IN IP4 0.0.0.0 > > > > In my opinion this is not needed, as there is no candidate to =E2=80=9Cen= code=E2=80=9D, > and it also conflicts with the suggested mechanism for indicating exclusi= ve > support of RTP/RTCP multiplexing (draft-holmberg-mmusic-mux-exclusive). > > > > Regards, > > > > Christer > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --089e011841685143ef0529292bbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
H All,

Cross-posting to MMUSIC, s= ince this affects both RFC 5245bis and draft-ietf-mmusic-ice-sip-sdp
RFC 5245 and=C2=A0draft-ietf-mmusic-ice-sip-sd= p currently=C2=A0say the following:

   The default candidates are added t=
o the SDP as the default
   destination for media.  For streams based on RTP, this is done by
   placing the IP address and port of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP, it MUST encode
   the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605
   [RFC3605].  If RTCP is not in use, the agent=
 MUST signal that using
   b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556].

There is an ongoing discussion whether the rtcp attribute is =
required in case of trickle ICE, when an offer is sent without candidate in=
formation, the RTP port set to 9, and the RTP IP address set to 0.0.0.0.=

=C2=A0
Example:
=
=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 =C2=A0 =C2=A0 =C2=A0a=
=3Drtcp: 9 IN IP4 0.0.0.0
=C2=A0
According to Christer =
this is not needed, as there is no candidate to =E2=80=9Cencode=E2=80=9D, a=
nd it also conflicts with the suggested mechanism for indicating exclusive =
support of RTP/RTCP multiplexing (draft-holmberg-mmusic-mux-exclusive).
=

Furthermore, according to section 2.1 of RFC 3605:

   The RTCP attribute is used to document the RTCP port used for =
media
   stream, when that port is not the next higher (odd) port number
   following the RTP port described in the media line.

RFC 5245= overwrites the guideline from RFC 3605 and states that SDP rtcp attribute = MUST be present even when RTCP default candidate is not present or when RTC= P candidate is using port rtp+1, which is currently the the most common sce= nario since sequential port is typically allocated for RTCP by TURN.
<= div class=3D"gmail_extra">
I suggest ch= anging the language in section 4.2 of=C2=A0draft-ietf-mmusic-ice-sip-sdp to= :

The default candidates are added to the SDP a= s the default destination for media. For streams based on RTP, this is done by placing the IP address and port of the RTP candidate into the c and m lines, respectively. If the agent is utilizing RTCP and if RTCP = 
   candidate is present and not equ=
al to the same address and 
   t=
he next higher port number of the RTP candidate, the agent MUST encode
   the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605
   [RFC3605].  If RTCP is not in use, the agent=
 MUST signal that using
   b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556].

Regards,
_____________
Roman Shpount

On Tue, Jan 12, 2016 at 8:02 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

RFC 5245 says the following:=

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =E2=80=9CIf the agent is utilizing RTCP, it MUST encode

=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=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=C2=A0=C2=A0=C2=A0the RT= CP candidate using the a=3Drtcp attribute as defined in RFC 3605<= /u>

=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=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=C2=A0=C2=A0=C2=A0=C2=A0[RFC3605].=E2=80=9D

=C2=A0

There is an ongoing discussion = whether the rtcp attribute is required in case of trickle ICE, when an offe= r is sent without candidate information, the RTP port set to 9, and the RTP= IP address set to 0.0.0.0.

=C2=A0

Example:

=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=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=C2=A0=C2=A0=C2=A0 a=3Drtcp: 9= IN IP4 0.0.0.0

=C2=A0

In my opinion this is not neede= d, as there is no candidate to =E2=80=9Cencode=E2=80=9D, and it also confli= cts with the suggested mechanism for indicating exclusive support of RTP/RT= CP multiplexing (draft-holmberg-mmusic-mux-exclusive).=

=C2=A0

Regards,

<= font color=3D"#888888">

=C2=A0

Christer


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


--089e011841685143ef0529292bbe-- From nobody Wed Jan 13 07:52:47 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A191A8AAF; Wed, 13 Jan 2016 07:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.601 X-Spam-Level: X-Spam-Status: No, score=-13.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2wOBFHB3kwR; Wed, 13 Jan 2016 07:52:44 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44A21A8AA0; Wed, 13 Jan 2016 07:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19238; q=dns/txt; s=iport; t=1452700363; x=1453909963; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=efYD3Q22CGSo3nrpfe+hx6F+5AQzc2fqwWd0llimRZs=; b=DbmXgQ0B2KEF/+cwnMPVhcHz3IbQKzNQkxVqhrFpnDLD67wogqeQsBIH WxYAKgnV0gbaSqylvw+NL7iG7l79EdWmX0FGQH1OBvwlzAWCoubb7DXqC FS7XMtflUe6Kdsdrgfjzas3zApl+7QT3upkWd0jBzxBhVwz9yPKWgWZxp 4=; X-IronPort-AV: E=Sophos; i="5.22,289,1449532800"; d="scan'208,217"; a="66772137" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 15:52:43 +0000 Received: from [10.131.44.84] ([10.131.44.84]) (authenticated bits=0) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0DFqec9015642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2016 15:52:42 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_759A37A7-D786-4242-A840-466764798C3A" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Wed, 13 Jan 2016 10:52:38 -0500 Message-Id: <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.3112) X-Authenticated-User: dwing Archived-At: Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , Christer Holmberg , snandaku@cisco.com Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:52:46 -0000 --Apple-Mail=_759A37A7-D786-4242-A840-466764798C3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 12-Jan-2016 03:48 pm, Roman Shpount wrote:=20 > H All, >=20 > Cross-posting to MMUSIC, since this affects both RFC 5245bis and = draft-ietf-mmusic-ice-sip-sdp >=20 > RFC 5245 and draft-ietf-mmusic-ice-sip-sdp currently say the = following: >=20 > The default candidates are added to the SDP as the default > destination for media. For streams based on RTP, this is done by > placing the IP address and port of the RTP candidate into the c and = m > lines, respectively. If the agent is utilizing RTCP, it MUST = encode > the RTCP candidate using the a=3Drtcp attribute as defined in RFC = 3605 > [RFC3605 ]. If RTCP is not in = use, the agent MUST signal that using > b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 = [RFC3556 = ]. >=20 > There is an ongoing discussion whether the rtcp attribute is required = in case of trickle ICE, when an offer is sent without candidate = information, the RTP port set to 9, and the RTP IP address set to = 0.0.0.0. > =20 > Example: > a=3Drtcp: 9 IN IP4 0.0.0.0 > =20 > According to Christer this is not needed, as there is no candidate to = =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested = mechanism for indicating exclusive support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive). >=20 > Furthermore, according to section 2.1 of RFC 3605: >=20 > The RTCP attribute is used to document the RTCP port used for media > stream, when that port is not the next higher (odd) port number > following the RTP port described in the media line. >=20 > RFC 5245 overwrites the guideline from RFC 3605 and states that SDP = rtcp attribute MUST be present even when RTCP default candidate is not = present or when RTCP candidate is using port rtp+1, which is currently = the the most common scenario since sequential port is typically = allocated for RTCP by TURN. >=20 > I suggest changing the language in section 4.2 of = draft-ietf-mmusic-ice-sip-sdp to: >=20 > The default candidates are added to the SDP as the default > destination for media. For streams based on RTP, this is done by > placing the IP address and port of the RTP candidate into the c and = m > lines, respectively. If the agent is utilizing RTCP and if RTCP=20 > candidate is present and not equal to the same address and=20 > the next higher port number of the RTP candidate,=20 One reason for the text in RFC5245 (to require a=3Drtcp, always) is to = destroy the "port + 1" assumption of RTCP; it simply breaks too many = times with NAT. So, I would go for your proposed text if you removed = "and not equal to the same address and next-higher port number of the = RTP candidate"; that is, if you're using RTCP on any different port, the = port number has to be explicitly signaled with a=3Drtcp. =20 -d > the agent MUST encode > the RTCP candidate using the a=3Drtcp attribute as defined in RFC = 3605 > [RFC3605 ]. If RTCP is not in = use, the agent MUST signal that using > b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 = [RFC3556 = ]. >=20 > Regards, > _____________ > Roman Shpount >=20 > On Tue, Jan 12, 2016 at 8:02 AM, Christer Holmberg = > = wrote: > Hi, >=20 > =20 >=20 > RFC 5245 says the following: >=20 > =20 >=20 > =E2=80=9CIf the agent is utilizing = RTCP, it MUST encode >=20 > the RTCP candidate using the a=3Drtcp = attribute as defined in RFC 3605 >=20 > [RFC3605].=E2=80=9D >=20 > =20 >=20 > There is an ongoing discussion whether the rtcp attribute is required = in case of trickle ICE, when an offer is sent without candidate = information, the RTP port set to 9, and the RTP IP address set to = 0.0.0.0. >=20 > =20 >=20 > Example: >=20 > =20 >=20 > a=3Drtcp: 9 IN IP4 0.0.0.0 >=20 > =20 >=20 > In my opinion this is not needed, as there is no candidate to = =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested = mechanism for indicating exclusive support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive). >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Christer >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice = >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_759A37A7-D786-4242-A840-466764798C3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 12-Jan-2016 03:48 pm, Roman Shpount <roman@telurix.com> = wrote:
H = All,

Cross-posting to MMUSIC, = since this affects both RFC 5245bis and = draft-ietf-mmusic-ice-sip-sdp

RFC 5245 = and draft-ietf-mmusic-ice-sip-sdp currently say the following:

   The default candidates are added to the SDP as the default
   destination for media.  For streams based on RTP, this is done by
   placing the IP address and port of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP, =
it MUST encode
   the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605
   [RFC3605].  If RTCP is =
not in use, the agent MUST signal that using
   b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556].
There is an ongoing discussion whether the rtcp attribute is =
required in case of trickle ICE, when an offer is sent without candidate =
information, the RTP port set to 9, and the RTP IP address set to =
0.0.0.0.
 
Example:
                 =
             a=3Drtcp: 9 IN IP4 =
0.0.0.0
 
According to Christer this is =
not needed, as there is no candidate to =E2=80=9Cencode=E2=80=9D, and it =
also conflicts with the suggested mechanism for indicating exclusive =
support of RTP/RTCP multiplexing =
(draft-holmberg-mmusic-mux-exclusive).

Furthermore, according to =
section 2.1 of RFC 3605:

   The =
RTCP attribute is used to document the RTCP port used for media
   stream, when that port is not the next higher (odd) port number
   following the RTP port described in the media =
line.

RFC 5245 overwrites the = guideline from RFC 3605 and states that SDP rtcp attribute MUST be = present even when RTCP default candidate is not present or when RTCP = candidate is using port rtp+1, which is currently the the most common = scenario since sequential port is typically allocated for RTCP by = TURN.

I suggest changing the language in section 4.2 = of draft-ietf-mmusic-ice-sip-sdp to:

The default candidates are added to = the SDP as the default destination for media. For streams based on RTP, this is done by placing the IP address and port of the RTP candidate into the c and m lines, respectively. If the agent is utilizing RTCP = and if RTCP 
=
   candidate is present and not equal to the same address and =

   the =
next higher port number of the RTP candidate, =

One reason for the text in RFC5245 (to require = a=3Drtcp, always) is to destroy the "port + 1" assumption of RTCP; it = simply breaks too many times with NAT.  So, I would go for your = proposed text if you removed "and not equal to the same address and = next-higher port number of the RTP candidate"; that is, if you're using = RTCP on any different port, the port number has to be explicitly = signaled with a=3Drtcp.  

-d



the agent MUST encode
   the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605
   [RFC3605].  If RTCP is =
not in use, the agent MUST signal that using
   b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556].

Regards,
_____________
Roman = Shpount

On Tue, Jan 12, 2016 at 8:02 = AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

RFC 5245 says the following:

 

   =             &n= bsp;           &nbs= p;   =E2=80=9CIf the agent is utilizing RTCP, it MUST = encode

   =             &n= bsp;           &nbs= p;  the RTCP candidate using the a=3Drtcp attribute as defined = in RFC 3605

   =             &n= bsp;           &nbs= p;   [RFC3605].=E2=80=9D

 

There is an ongoing discussion whether the rtcp attribute is = required in case of trickle ICE, when an offer is sent without candidate = information, the RTP port set to 9, and the RTP IP address set to = 0.0.0.0.

 

Example:

 

          &nb= sp;            = ;      a=3Drtcp: 9 IN IP4 0.0.0.0

 

In my opinion this is not needed, as there is no candidate to = =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested = mechanism for indicating exclusive support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive).

 

Regards,

 

Christer


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


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


= --Apple-Mail=_759A37A7-D786-4242-A840-466764798C3A-- From nobody Wed Jan 13 08:32:14 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689A51B2C85; Wed, 13 Jan 2016 08:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gpyKLYWkZf3; Wed, 13 Jan 2016 08:32:08 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE611B2C7F; Wed, 13 Jan 2016 08:32:07 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-72-56967c05582a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.F6.30208.50C76965; Wed, 13 Jan 2016 17:32:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Wed, 13 Jan 2016 17:32:05 +0100 From: Christer Holmberg To: =?utf-8?B?8J+Uk0RhbiBXaW5n?= , Roman Shpount Thread-Topic: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE Thread-Index: AdFNOVt7kQ2pmkCTSmeGFH6bEUVINQAOMjAAACf50gAAA2qfQA== Date: Wed, 13 Jan 2016 16:32:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> In-Reply-To: <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> 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_7594FB04B1934943A5C02806D1A2204B37D169C5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2K7qy5rzbQwgz0bdSwuXnvIZPHtQq3F 2uM3GS2mLn/MYjHjwlRmi8UH7rM6sHlM+b2R1WPJkp9MHsdPX2f1uDWlIIAlissmJTUnsyy1 SN8ugSujc9pH1oJLDUwVD58vZ2xg/PKTsYuRk0NCwETi/O8OdghbTOLCvfVsXYxcHEIChxkl 3lxvg3IWM0o0H3jE0sXIwcEmYCHR/U8bpEFEIFyi4fd9VpAaZoH7jBKLvn5hBkkIC9hLPDrV xwJR5CBxvn8mM4TtJLFr4mOwzSwCqhK95w+xgdi8Ar4Spy5sZYdYdpxR4sa/V2DNnAK2Ejs/ dTGB2IxA530/tQbMZhYQl7j1ZD4TxNkCEkv2nGeGsEUlXj7+xwphK0k0LnnCClGfL3F8wnUW iGWCEidnPmGZwCg6C8moWUjKZiEpmwX0M7OApsT6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRf xShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYrQe3/FbdwXj5jeMhRgEORiUe3g17p4YJsSaW FVfmHmKU4GBWEuGNqZgWJsSbklhZlVqUH19UmpNafIhRmoNFSZw3SaYxTEggPbEkNTs1tSC1 CCbLxMEp1cBoIGDj+/1wzaeogtImUZ8F1/SPr/tR4nywL3lOxbz2iBufGf1aPzL6uD04s+qf kWaWw5c42Qfrdi2OTvQquhrlzZA91WOhxfQPJmrCvtLm/VcZ2KN/y/Z/XH0103Pp22+/5z0r X+3RsUry0a4VPlvOJqgkPD5rdrsnnL+w/egi1lVWSQvU/7spsRRnJBpqMRcVJwIALPOGT9IC AAA= Archived-At: Cc: "snandaku@cisco.com" , Marc Petit-Huguenin , =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:32:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D169C5ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuLA0KDQpUaGUgY2FzZSB0aGF0IHJhaXNlZCB0aGUgaXNzdWUgaXMgd2hlbiB0cmlja2xl IElDRSBpcyB1c2VkIOKAkyBhbmQgbm8gcG9ydHMgYXJlIHNpZ25hbGxlZCB0byBiZWdpbiB3aXRo LCBhbmQgdGhlIGM9IGxpbmUgY29udGFpbnMgcG9ydCA5IGFuZCBhIDAuMC4wLjAgYWRkcmVzcy4g SW4gbXkgb3BpbmlvbiB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgUlRDUCBhdHRyaWJ1dGUgaW4g dGhhdCBjYXNlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiDwn5STRGFuIFdpbmcg W21haWx0bzpkd2luZ0BjaXNjby5jb21dDQpTZW50OiAxMyBKYW51YXJ5IDIwMTYgMTc6NTMNClRv OiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiBpY2VAaWV0Zi5vcmc7IG1t dXNpY0BpZXRmLm9yZzsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT47IE1hcmMgUGV0aXQtSHVndWVuaW4gPG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPjsg QXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+OyBzbmFuZGFrdUBjaXNjby5j b20NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbSWNlXSBTRFAgcnRjcCBhdHRyaWJ1dGUgd2l0aCB0 cmlja2xlIElDRQ0KDQoNCk9uIDEyLUphbi0yMDE2IDAzOjQ4IHBtLCBSb21hbiBTaHBvdW50IDxy b21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCkggQWxs LA0KDQpDcm9zcy1wb3N0aW5nIHRvIE1NVVNJQywgc2luY2UgdGhpcyBhZmZlY3RzIGJvdGggUkZD IDUyNDViaXMgYW5kIGRyYWZ0LWlldGYtbW11c2ljLWljZS1zaXAtc2RwDQoNClJGQyA1MjQ1IGFu ZCBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcCBjdXJyZW50bHkgc2F5IHRoZSBmb2xsb3dp bmc6DQoNCg0KICAgVGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBhcmUgYWRkZWQgdG8gdGhlIFNEUCBh cyB0aGUgZGVmYXVsdA0KDQogICBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuICBGb3Igc3RyZWFtcyBi YXNlZCBvbiBSVFAsIHRoaXMgaXMgZG9uZSBieQ0KDQogICBwbGFjaW5nIHRoZSBJUCBhZGRyZXNz IGFuZCBwb3J0IG9mIHRoZSBSVFAgY2FuZGlkYXRlIGludG8gdGhlIGMgYW5kIG0NCg0KICAgbGlu ZXMsIHJlc3BlY3RpdmVseS4gIElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcgUlRDUCwgaXQgTVVT VCBlbmNvZGUNCg0KICAgdGhlIFJUQ1AgY2FuZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3AgYXR0cmli dXRlIGFzIGRlZmluZWQgaW4gUkZDIDM2MDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzM2MDU+DQoNCiAgIFtSRkMzNjA1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjA1 Pl0uICBJZiBSVENQIGlzIG5vdCBpbiB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVz aW5nDQoNCiAgIGI9UlM6MCBhbmQgYj1SUjowIGFzIGRlZmluZWQgaW4gUkZDIDM1NTY8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTY+IFtSRkMzNTU2PGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmMzNTU2Pl0uDQoNCg0KDQpUaGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Np b24gd2hldGhlciB0aGUgcnRjcCBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQgaW4gY2FzZSBvZiB0cmlj a2xlIElDRSwgd2hlbiBhbiBvZmZlciBpcyBzZW50IHdpdGhvdXQgY2FuZGlkYXRlIGluZm9ybWF0 aW9uLCB0aGUgUlRQIHBvcnQgc2V0IHRvIDksIGFuZCB0aGUgUlRQIElQIGFkZHJlc3Mgc2V0IHRv IDAuMC4wLjAuDQoNCg0KDQpFeGFtcGxlOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhPXJ0Y3A6IDkgSU4gSVA0IDAuMC4wLjANCg0KDQoNCkFjY29yZGluZyB0byBDaHJpc3RlciB0 aGlzIGlzIG5vdCBuZWVkZWQsIGFzIHRoZXJlIGlzIG5vIGNhbmRpZGF0ZSB0byDigJxlbmNvZGXi gJ0sIGFuZCBpdCBhbHNvIGNvbmZsaWN0cyB3aXRoIHRoZSBzdWdnZXN0ZWQgbWVjaGFuaXNtIGZv ciBpbmRpY2F0aW5nIGV4Y2x1c2l2ZSBzdXBwb3J0IG9mIFJUUC9SVENQIG11bHRpcGxleGluZyAo ZHJhZnQtaG9sbWJlcmctbW11c2ljLW11eC1leGNsdXNpdmUpLg0KDQoNCg0KRnVydGhlcm1vcmUs IGFjY29yZGluZyB0byBzZWN0aW9uIDIuMSBvZiBSRkMgMzYwNToNCg0KDQoNCiAgIFRoZSBSVENQ IGF0dHJpYnV0ZSBpcyB1c2VkIHRvIGRvY3VtZW50IHRoZSBSVENQIHBvcnQgdXNlZCBmb3IgbWVk aWENCg0KICAgc3RyZWFtLCB3aGVuIHRoYXQgcG9ydCBpcyBub3QgdGhlIG5leHQgaGlnaGVyIChv ZGQpIHBvcnQgbnVtYmVyDQoNCiAgIGZvbGxvd2luZyB0aGUgUlRQIHBvcnQgZGVzY3JpYmVkIGlu IHRoZSBtZWRpYSBsaW5lLg0KDQpSRkMgNTI0NSBvdmVyd3JpdGVzIHRoZSBndWlkZWxpbmUgZnJv bSBSRkMgMzYwNSBhbmQgc3RhdGVzIHRoYXQgU0RQIHJ0Y3AgYXR0cmlidXRlIE1VU1QgYmUgcHJl c2VudCBldmVuIHdoZW4gUlRDUCBkZWZhdWx0IGNhbmRpZGF0ZSBpcyBub3QgcHJlc2VudCBvciB3 aGVuIFJUQ1AgY2FuZGlkYXRlIGlzIHVzaW5nIHBvcnQgcnRwKzEsIHdoaWNoIGlzIGN1cnJlbnRs eSB0aGUgdGhlIG1vc3QgY29tbW9uIHNjZW5hcmlvIHNpbmNlIHNlcXVlbnRpYWwgcG9ydCBpcyB0 eXBpY2FsbHkgYWxsb2NhdGVkIGZvciBSVENQIGJ5IFRVUk4uDQoNCkkgc3VnZ2VzdCBjaGFuZ2lu ZyB0aGUgbGFuZ3VhZ2UgaW4gc2VjdGlvbiA0LjIgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNp cC1zZHAgdG86DQoNCg0KICAgVGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBhcmUgYWRkZWQgdG8gdGhl IFNEUCBhcyB0aGUgZGVmYXVsdA0KDQogICBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuICBGb3Igc3Ry ZWFtcyBiYXNlZCBvbiBSVFAsIHRoaXMgaXMgZG9uZSBieQ0KDQogICBwbGFjaW5nIHRoZSBJUCBh ZGRyZXNzIGFuZCBwb3J0IG9mIHRoZSBSVFAgY2FuZGlkYXRlIGludG8gdGhlIGMgYW5kIG0NCg0K ICAgbGluZXMsIHJlc3BlY3RpdmVseS4gIElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcgUlRDUCBh bmQgaWYgUlRDUA0KDQogICBjYW5kaWRhdGUgaXMgcHJlc2VudCBhbmQgbm90IGVxdWFsIHRvIHRo ZSBzYW1lIGFkZHJlc3MgYW5kDQoNCiAgIHRoZSBuZXh0IGhpZ2hlciBwb3J0IG51bWJlciBvZiB0 aGUgUlRQIGNhbmRpZGF0ZSwNCg0KT25lIHJlYXNvbiBmb3IgdGhlIHRleHQgaW4gUkZDNTI0NSAo dG8gcmVxdWlyZSBhPXJ0Y3AsIGFsd2F5cykgaXMgdG8gZGVzdHJveSB0aGUgInBvcnQgKyAxIiBh c3N1bXB0aW9uIG9mIFJUQ1A7IGl0IHNpbXBseSBicmVha3MgdG9vIG1hbnkgdGltZXMgd2l0aCBO QVQuICBTbywgSSB3b3VsZCBnbyBmb3IgeW91ciBwcm9wb3NlZCB0ZXh0IGlmIHlvdSByZW1vdmVk ICJhbmQgbm90IGVxdWFsIHRvIHRoZSBzYW1lIGFkZHJlc3MgYW5kIG5leHQtaGlnaGVyIHBvcnQg bnVtYmVyIG9mIHRoZSBSVFAgY2FuZGlkYXRlIjsgdGhhdCBpcywgaWYgeW91J3JlIHVzaW5nIFJU Q1Agb24gYW55IGRpZmZlcmVudCBwb3J0LCB0aGUgcG9ydCBudW1iZXIgaGFzIHRvIGJlIGV4cGxp Y2l0bHkgc2lnbmFsZWQgd2l0aCBhPXJ0Y3AuDQoNCi1kDQoNCg0KDQoNCg0KdGhlIGFnZW50IE1V U1QgZW5jb2RlDQoNCiAgIHRoZSBSVENQIGNhbmRpZGF0ZSB1c2luZyB0aGUgYT1ydGNwIGF0dHJp YnV0ZSBhcyBkZWZpbmVkIGluIFJGQyAzNjA1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzNjA1Pg0KDQogICBbUkZDMzYwNTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYw NT5dLiAgSWYgUlRDUCBpcyBub3QgaW4gdXNlLCB0aGUgYWdlbnQgTVVTVCBzaWduYWwgdGhhdCB1 c2luZw0KDQogICBiPVJTOjAgYW5kIGI9UlI6MCBhcyBkZWZpbmVkIGluIFJGQyAzNTU2PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTU2PiBbUkZDMzU1NjxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMzU1Nj5dLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4g U2hwb3VudA0KDQpPbiBUdWUsIEphbiAxMiwgMjAxNiBhdCA4OjAyIEFNLCBDaHJpc3RlciBIb2xt YmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpSRkMgNTI0NSBzYXlzIHRoZSBmb2xs b3dpbmc6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDigJxJZiB0aGUgYWdlbnQg aXMgdXRpbGl6aW5nIFJUQ1AsIGl0IE1VU1QgZW5jb2RlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1dGUgYXMg ZGVmaW5lZCBpbiBSRkMgMzYwNQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtSRkMz NjA1XS7igJ0NCg0KVGhlcmUgaXMgYW4gb25nb2luZyBkaXNjdXNzaW9uIHdoZXRoZXIgdGhlIHJ0 Y3AgYXR0cmlidXRlIGlzIHJlcXVpcmVkIGluIGNhc2Ugb2YgdHJpY2tsZSBJQ0UsIHdoZW4gYW4g b2ZmZXIgaXMgc2VudCB3aXRob3V0IGNhbmRpZGF0ZSBpbmZvcm1hdGlvbiwgdGhlIFJUUCBwb3J0 IHNldCB0byA5LCBhbmQgdGhlIFJUUCBJUCBhZGRyZXNzIHNldCB0byAwLjAuMC4wLg0KDQpFeGFt cGxlOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGE9cnRjcDogOSBJTiBJUDQgMC4w LjAuMA0KDQpJbiBteSBvcGluaW9uIHRoaXMgaXMgbm90IG5lZWRlZCwgYXMgdGhlcmUgaXMgbm8g Y2FuZGlkYXRlIHRvIOKAnGVuY29kZeKAnSwgYW5kIGl0IGFsc28gY29uZmxpY3RzIHdpdGggdGhl IHN1Z2dlc3RlZCBtZWNoYW5pc20gZm9yIGluZGljYXRpbmcgZXhjbHVzaXZlIHN1cHBvcnQgb2Yg UlRQL1JUQ1AgbXVsdGlwbGV4aW5nIChkcmFmdC1ob2xtYmVyZy1tbXVzaWMtbXV4LWV4Y2x1c2l2 ZSkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpJY2UgbWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmc8bWFp bHRvOkljZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWNlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt bXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37D169C5ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBT eW1ib2wiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+SGkgRGFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ VGhlIGNhc2UgdGhhdCByYWlzZWQgdGhlIGlzc3VlIGlzIHdoZW4gdHJpY2tsZSBJQ0UgaXMgdXNl ZCDigJMgYW5kIG5vIHBvcnRzIGFyZSBzaWduYWxsZWQgdG8gYmVnaW4gd2l0aCwgYW5kIHRoZSBj PSBsaW5lIGNvbnRhaW5zIHBvcnQNCiA5IGFuZCBhIDAuMC4wLjAgYWRkcmVzcy4gSW4gbXkgb3Bp bmlvbiB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgUlRDUCBhdHRyaWJ1dGUgaW4gdGhhdCBjYXNl 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+DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OyxzYW5zLXNlcmlmIj7wn5STPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRhbiBXaW5nIFttYWlsdG86ZHdpbmdAY2lzY28u Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDEzIEphbnVhcnkgMjAxNiAxNzo1Mzxicj4NCjxiPlRv OjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBpY2VAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9yZzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0 O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs7IE1hcmMgUGV0aXQtSHVndWVuaW4g Jmx0O21hcmNAcGV0aXQtaHVndWVuaW4ub3JnJmd0OzsgQXJpIEtlcsOkbmVuICZsdDthcmkua2Vy YW5lbkBlcmljc3Nvbi5jb20mZ3Q7OyBzbmFuZGFrdUBjaXNjby5jb208YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtNTVVTSUNdIFtJY2VdIFNEUCBydGNwIGF0dHJpYnV0ZSB3aXRoIHRyaWNrbGUg SUNFPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpPbiAxMi1KYW4tMjAxNiAwMzo0OCBwbSwgUm9tYW4gU2hwb3VudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4m Z3Q7IHdyb3RlOg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SCBBbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3Jvc3MtcG9zdGluZyB0byBNTVVTSUMsIHNpbmNlIHRoaXMg YWZmZWN0cyBib3RoIFJGQyA1MjQ1YmlzIGFuZCBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNk cDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5SRkMgNTI0NSBhbmQmbmJzcDs8L3NwYW4+ZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNp cC1zZHAgY3VycmVudGx5Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5zYXkgdGhlIGZvbGxvd2luZzo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxl PSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7Jm5ic3A7IFRoZSBkZWZhdWx0IGNhbmRpZGF0 ZXMgYXJlIGFkZGVkIHRvIHRoZSBTRFAgYXMgdGhlIGRlZmF1bHQ8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgZGVzdGluYXRpb24gZm9yIG1lZGlhLiZuYnNwOyBGb3Igc3RyZWFt cyBiYXNlZCBvbiBSVFAsIHRoaXMgaXMgZG9uZSBieTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBwbGFjaW5nIHRoZSBJUCBhZGRyZXNzIGFuZCBwb3J0IG9mIHRoZSBSVFAgY2Fu ZGlkYXRlIGludG8gdGhlIGMgYW5kIG08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgbGluZXMsIHJlc3BlY3RpdmVseS4mbmJzcDsgPGI+SWYgdGhlIGFnZW50IGlzIHV0aWxpemlu ZyBSVENQLCBpdCBNVVNUIGVuY29kZTxvOnA+PC9vOnA+PC9iPjwvcHJlPg0KPHByZT48Yj4mbmJz cDsmbmJzcDsgdGhlIFJUQ1AgY2FuZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3AgYXR0cmlidXRlIGFz IGRlZmluZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2MDUi IHRhcmdldD0iX2JsYW5rIj5SRkMgMzYwNTwvYT48bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+ PGI+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MzYwNSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtSZWFsIFRpbWUgQ29udHJvbCBQcm90 b2NvbCAoUlRDUCkgYXR0cmlidXRlIGluIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNE UCkmcXVvdDsiPlJGQzM2MDU8L2E+XS48L2I+Jm5ic3A7IElmIFJUQ1AgaXMgbm90IGluIHVzZSwg dGhlIGFnZW50IE1VU1Qgc2lnbmFsIHRoYXQgdXNpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgYj1SUzowIGFuZCBiPVJSOjAgYXMgZGVmaW5lZCBpbiA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1NiIgdGFyZ2V0PSJfYmxhbmsiPlJGQyAzNTU2 PC9hPiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTYiIHRhcmdl dD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7U2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQ KSBCYW5kd2lkdGggTW9kaWZpZXJzIGZvciBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgQmFu ZHdpZHRoJnF1b3Q7Ij5SRkMzNTU2PC9hPl0uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 IndoaXRlLXNwYWNlOnByZS13cmFwIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGRpdj4NCjxw cmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gd2hldGhlciB0aGUgcnRjcCBhdHRy aWJ1dGUgaXMgcmVxdWlyZWQgaW4gY2FzZSBvZiB0cmlja2xlIElDRSwgd2hlbiBhbiBvZmZlciBp cyBzZW50IHdpdGhvdXQgY2FuZGlkYXRlIGluZm9ybWF0aW9uLCB0aGUgUlRQIHBvcnQgc2V0IHRv IDksIGFuZCB0aGUgUlRQIElQIGFkZHJlc3Mgc2V0IHRvIDAuMC4wLjAuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5FeGFtcGxlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9cnRjcDogOSBJTiBJUDQgMC4wLjAu MDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+QWNjb3JkaW5nIHRvIENocmlzdGVyIHRoaXMgaXMgbm90IG5lZWRlZCwgYXMg dGhlcmUgaXMgbm8gY2FuZGlkYXRlIHRvIOKAnGVuY29kZeKAnSwgYW5kIGl0IGFsc28gY29uZmxp Y3RzIHdpdGggdGhlIHN1Z2dlc3RlZCBtZWNoYW5pc20gZm9yIGluZGljYXRpbmcgZXhjbHVzaXZl IHN1cHBvcnQgb2YgUlRQL1JUQ1AgbXVsdGlwbGV4aW5nIChkcmFmdC1ob2xtYmVyZy1tbXVzaWMt bXV4LWV4Y2x1c2l2ZSkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZ1cnRoZXJtb3JlLCBhY2NvcmRpbmcgdG8gc2VjdGlvbiAyLjEgb2YgUkZD IDM2MDU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8L2Rpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBSVENQIGF0dHJpYnV0ZSBp cyB1c2VkIHRvIGRvY3VtZW50IHRoZSBSVENQIHBvcnQgdXNlZCBmb3IgbWVkaWE8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3RyZWFtLCB3aGVuIHRoYXQgcG9ydCBpcyBub3Qg dGhlIG5leHQgaGlnaGVyIChvZGQpIHBvcnQgbnVtYmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGZvbGxvd2luZyB0aGUgUlRQIHBvcnQgZGVzY3JpYmVkIGluIHRoZSBtZWRp YSBsaW5lLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UkZDIDUyNDUgb3ZlcndyaXRlcyB0aGUgZ3VpZGVsaW5lIGZyb20gUkZD IDM2MDUgYW5kIHN0YXRlcyB0aGF0IFNEUCBydGNwIGF0dHJpYnV0ZSBNVVNUIGJlIHByZXNlbnQg ZXZlbiB3aGVuIFJUQ1AgZGVmYXVsdCBjYW5kaWRhdGUgaXMgbm90IHByZXNlbnQgb3Igd2hlbiBS VENQIGNhbmRpZGF0ZSBpcyB1c2luZyBwb3J0IHJ0cCYjNDM7MSwgd2hpY2ggaXMgY3VycmVudGx5 IHRoZSB0aGUgbW9zdCBjb21tb24gc2NlbmFyaW8NCiBzaW5jZSBzZXF1ZW50aWFsIHBvcnQgaXMg dHlwaWNhbGx5IGFsbG9jYXRlZCBmb3IgUlRDUCBieSBUVVJOLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1Z2dlc3QgY2hhbmdpbmcgdGhl IGxhbmd1YWdlIGluIHNlY3Rpb24gNC4yIG9mJm5ic3A7ZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNp cC1zZHAgdG86PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Indo aXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDsmbmJzcDsgVGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBh cmUgYWRkZWQgdG8gdGhlIFNEUCBhcyB0aGUgZGVmYXVsdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuJm5ic3A7IEZvciBzdHJlYW1zIGJh c2VkIG9uIFJUUCwgdGhpcyBpcyBkb25lIGJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHBsYWNpbmcgdGhlIElQIGFkZHJlc3MgYW5kIHBvcnQgb2YgdGhlIFJUUCBjYW5kaWRh dGUgaW50byB0aGUgYyBhbmQgbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBs aW5lcywgcmVzcGVjdGl2ZWx5LiZuYnNwOyA8Yj5JZiB0aGUgYWdlbnQgaXMgdXRpbGl6aW5nIFJU Q1AgYW5kIGlmIFJUQ1AgPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2FuZGlkYXRlIGlzIHByZXNlbnQg YW5kIG5vdCBlcXVhbCB0byB0aGUgc2FtZSBhZGRyZXNzIGFuZCA8L2I+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48Yj4mbmJzcDsmbmJzcDsmbmJz cDt0aGUgbmV4dCBoaWdoZXIgcG9ydCBudW1iZXIgb2YgdGhlIFJUUCBjYW5kaWRhdGUsIDwvYj48 bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIHJlYXNvbiBmb3IgdGhlIHRleHQgaW4g UkZDNTI0NSAodG8gcmVxdWlyZSBhPXJ0Y3AsIGFsd2F5cykgaXMgdG8gZGVzdHJveSB0aGUgJnF1 b3Q7cG9ydCAmIzQzOyAxJnF1b3Q7IGFzc3VtcHRpb24gb2YgUlRDUDsgaXQgc2ltcGx5IGJyZWFr cyB0b28gbWFueSB0aW1lcyB3aXRoIE5BVC4gJm5ic3A7U28sIEkgd291bGQgZ28gZm9yIHlvdXIg cHJvcG9zZWQgdGV4dCBpZiB5b3UgcmVtb3ZlZCAmcXVvdDthbmQgbm90IGVxdWFsIHRvIHRoZSBz YW1lIGFkZHJlc3MNCiBhbmQgbmV4dC1oaWdoZXIgcG9ydCBudW1iZXIgb2YgdGhlIFJUUCBjYW5k aWRhdGUmcXVvdDs7IHRoYXQgaXMsIGlmIHlvdSdyZSB1c2luZyBSVENQIG9uIGFueSBkaWZmZXJl bnQgcG9ydCwgdGhlIHBvcnQgbnVtYmVyIGhhcyB0byBiZSBleHBsaWNpdGx5IHNpZ25hbGVkIHdp dGggYT1ydGNwLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGI+dGhlIGFnZW50IE1VU1Qg ZW5jb2RlPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyB0aGUgUlRD UCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1dGUgYXMgZGVmaW5lZCBpbiA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFyZ2V0PSJfYmxhbmsi PlJGQyAzNjA1PC9hPjxvOnA+PC9vOnA+PC9iPjwvcHJlPg0KPHByZT48Yj4mbmJzcDsmbmJzcDsg WzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjA1IiB0YXJnZXQ9Il9i bGFuayIgdGl0bGU9IiZxdW90O1JlYWwgVGltZSBDb250cm9sIFByb3RvY29sIChSVENQKSBhdHRy aWJ1dGUgaW4gU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSZxdW90OyI+UkZDMzYw NTwvYT5dLjwvYj4mbmJzcDsgSWYgUlRDUCBpcyBub3QgaW4gdXNlLCB0aGUgYWdlbnQgTVVTVCBz aWduYWwgdGhhdCB1c2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBiPVJT OjAgYW5kIGI9UlI6MCBhcyBkZWZpbmVkIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzNTU2IiB0YXJnZXQ9Il9ibGFuayI+UkZDIDM1NTY8L2E+IFs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1NiIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSImcXVvdDtTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIEJhbmR3aWR0aCBNb2Rp ZmllcnMgZm9yIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBCYW5kd2lkdGgmcXVvdDsiPlJG QzM1NTY8L2E+XS48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFuIDEyLCAyMDE2 IGF0IDg6MDIgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkZJIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkMgNTI0NSBzYXlzIHRoZSBmb2xsb3dpbmc6PC9zcGFu PjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDvigJxJZiB0aGUgYWdlbnQgaXMgdXRpbGl6aW5nIFJUQ1AsIGl0IE1V U1QgZW5jb2RlPC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIFJUQ1AgY2Fu ZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3AgYXR0cmlidXRlIGFzIGRlZmluZWQgaW4gUkZDIDM2MDU8 L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRkkiPltSRkMzNjA1XS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBpcyBhbiBvbmdv aW5nIGRpc2N1c3Npb24gd2hldGhlciB0aGUgcnRjcCBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQgaW4g Y2FzZSBvZiB0cmlja2xlIElDRSwgd2hlbiBhbiBvZmZlciBpcyBzZW50IHdpdGhvdXQgY2FuZGlk YXRlIGluZm9ybWF0aW9uLCB0aGUgUlRQIHBvcnQNCiBzZXQgdG8gOSwgYW5kIHRoZSBSVFAgSVAg YWRkcmVzcyBzZXQgdG8gMC4wLjAuMC48L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+RXhhbXBsZTo8L3NwYW4+PHNwYW4g bGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGE9 cnRjcDogOSBJTiBJUDQgMC4wLjAuMDwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBteSBvcGluaW9uIHRoaXMgaXMg bm90IG5lZWRlZCwgYXMgdGhlcmUgaXMgbm8gY2FuZGlkYXRlIHRvIOKAnGVuY29kZeKAnSwgYW5k IGl0IGFsc28gY29uZmxpY3RzIHdpdGggdGhlIHN1Z2dlc3RlZCBtZWNoYW5pc20gZm9yIGluZGlj YXRpbmcgZXhjbHVzaXZlIHN1cHBvcnQgb2YNCiBSVFAvUlRDUCBtdWx0aXBsZXhpbmcgKGRyYWZ0 LWhvbG1iZXJnLW1tdXNpYy1tdXgtZXhjbHVzaXZlKS48L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3Nw YW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRkkiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRkkiIHN0eWxlPSJj b2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkljZSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWNlQGlldGYub3JnIj5JY2VAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p Y2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ljZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNp Y0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37D169C5ESESSMB209erics_-- From nobody Wed Jan 13 08:39:47 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AD91B2F02; Wed, 13 Jan 2016 08:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.601 X-Spam-Level: X-Spam-Status: No, score=-13.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMC8ffmCSNxa; Wed, 13 Jan 2016 08:39:42 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE8A1B2AD6; Wed, 13 Jan 2016 08:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36848; q=dns/txt; s=iport; t=1452703181; x=1453912781; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=O6e43n253BxEfmK0LMiOlDfhmNj68pPcMKg+2FfJEBU=; b=RKnl3504CYtoZhVm0QCLeL21ttPv2N49k+ZjPaROrSU7sSYNE/nM3Hjh fbqVvgQs0k6L9/BYFiLtdvZr7r1TDsIUh2J1Nd//4JOa/bJmTWoPRVrtU /MILuPKhhwQCwRSBKPnJ37aa8G+afmQD7uzeLFvpRHDrfEPF72CDBZeII Y=; X-IronPort-AV: E=Sophos;i="5.22,290,1449532800"; d="scan'208,217";a="631608127" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 16:39:39 +0000 Received: from [10.131.44.84] ([10.131.44.84]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0DGdWgU024724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2016 16:39:36 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_A48FC36A-885E-470C-83B5-384DFD38B63B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> Date: Wed, 13 Jan 2016 11:39:32 -0500 Message-Id: <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-Authenticated-User: dwing Archived-At: Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:39:45 -0000 --Apple-Mail=_A48FC36A-885E-470C-83B5-384DFD38B63B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 13-Jan-2016 11:32 am, Christer Holmberg = wrote:=20 > Hi Dan, > =20 > The case that raised the issue is when trickle ICE is used =E2=80=93 = and no ports are signalled to begin with, and the c=3D line contains = port 9 and a 0.0.0.0 address. In my opinion there is no need for the = RTCP attribute in that case. Then you'll need a MUST to indicate "MUST signal using Trickle", right? -d > =20 > Regards, > =20 > Christer > =C2=A0 <> > From: =F0=9F=94=93Dan Wing [mailto:dwing@cisco.com = ]=20 > Sent: 13 January 2016 17:53 > To: Roman Shpount > > Cc: ice@ietf.org ; mmusic@ietf.org = ; Christer Holmberg = >; Marc Petit-Huguenin = >; Ari Ker=C3=A4n= en >; = snandaku@cisco.com > Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE > =20 >=20 > On 12-Jan-2016 03:48 pm, Roman Shpount > wrote: > H All, > =20 > Cross-posting to MMUSIC, since this affects both RFC 5245bis and = draft-ietf-mmusic-ice-sip-sdp > =20 > RFC 5245 and draft-ietf-mmusic-ice-sip-sdp currently say the = following: > =20 > The default candidates are added to the SDP as the default > destination for media. For streams based on RTP, this is done by > placing the IP address and port of the RTP candidate into the c and = m > lines, respectively. If the agent is utilizing RTCP, it MUST = encode > the RTCP candidate using the a=3Drtcp attribute as defined in RFC = 3605 > [RFC3605 ]. If RTCP is not in = use, the agent MUST signal that using > b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 = [RFC3556 = ]. > =20 > There is an ongoing discussion whether the rtcp attribute is required = in case of trickle ICE, when an offer is sent without candidate = information, the RTP port set to 9, and the RTP IP address set to = 0.0.0.0. > =20 > Example: > a=3Drtcp: 9 IN IP4 0.0.0.0 > =20 > According to Christer this is not needed, as there is no candidate to = =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested = mechanism for indicating exclusive support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive). > =20 > Furthermore, according to section 2.1 of RFC 3605: > =20 > The RTCP attribute is used to document the RTCP port used for media > stream, when that port is not the next higher (odd) port number > following the RTP port described in the media line. > =20 > RFC 5245 overwrites the guideline from RFC 3605 and states that SDP = rtcp attribute MUST be present even when RTCP default candidate is not = present or when RTCP candidate is using port rtp+1, which is currently = the the most common scenario since sequential port is typically = allocated for RTCP by TURN. > =20 > I suggest changing the language in section 4.2 of = draft-ietf-mmusic-ice-sip-sdp to: > =20 > The default candidates are added to the SDP as the default > destination for media. For streams based on RTP, this is done by > placing the IP address and port of the RTP candidate into the c and = m > lines, respectively. If the agent is utilizing RTCP and if RTCP=20 > candidate is present and not equal to the same address and=20 > the next higher port number of the RTP candidate,=20 > =20 > One reason for the text in RFC5245 (to require a=3Drtcp, always) is to = destroy the "port + 1" assumption of RTCP; it simply breaks too many = times with NAT. So, I would go for your proposed text if you removed = "and not equal to the same address and next-higher port number of the = RTP candidate"; that is, if you're using RTCP on any different port, the = port number has to be explicitly signaled with a=3Drtcp. =20 > =20 > -d > =20 > =20 >=20 >=20 > the agent MUST encode > the RTCP candidate using the a=3Drtcp attribute as defined in RFC = 3605 > [RFC3605 ]. If RTCP is not in = use, the agent MUST signal that using > b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 = [RFC3556 = ]. > =20 > Regards, > _____________ > Roman Shpount > =20 > On Tue, Jan 12, 2016 at 8:02 AM, Christer Holmberg = > = wrote: > Hi, > =20 > RFC 5245 says the following: > =20 > =E2=80=9CIf the agent is utilizing = RTCP, it MUST encode > the RTCP candidate using the a=3Drtcp = attribute as defined in RFC 3605 > [RFC3605].=E2=80=9D > =20 > There is an ongoing discussion whether the rtcp attribute is required = in case of trickle ICE, when an offer is sent without candidate = information, the RTP port set to 9, and the RTP IP address set to = 0.0.0.0. > =20 > Example: > =20 > a=3Drtcp: 9 IN IP4 0.0.0.0 > =20 > In my opinion this is not needed, as there is no candidate to = =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested = mechanism for indicating exclusive support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive). > =20 > Regards, > =20 > Christer >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice = > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = --Apple-Mail=_A48FC36A-885E-470C-83B5-384DFD38B63B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 13-Jan-2016 11:32 am, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Dan,
 
The case that raised = the issue is when trickle ICE is used =E2=80=93 and no ports are = signalled to begin with, and the c=3D line contains port 9 and a 0.0.0.0 = address. In my opinion there is no need for the RTCP attribute in that = case.

Then you'll need a MUST to indicate "MUST signal = using Trickle", right?

-d


 
Regards,
 
Christer
 
From: =F0=9F=94=93Dan Wing [mailto:dwing@cisco.com] 
Sent: 13 = January 2016 17:53
To: Roman Shpount <roman@telurix.com>
Cc: ice@ietf.org; mmusic@ietf.org; Christer Holmberg <christer.holmberg@ericsson.com>; Marc Petit-Huguenin = <marc@petit-huguenin.org>; = Ari Ker=C3=A4nen <ari.keranen@ericsson.com>; snandaku@cisco.com
Subject: Re: [MMUSIC] [Ice] SDP rtcp = attribute with trickle ICE
 

On = 12-Jan-2016 03:48 pm, Roman Shpount <roman@telurix.com> = wrote:
H All,
 
Cross-posting to MMUSIC, since this affects both RFC = 5245bis and draft-ietf-mmusic-ice-sip-sdp
 
RFC 5245 = and draft-ietf-mmusic-ice-sip-sdp currently say the following:
 
   The default candidates =
are added to the SDP as the default
   destination for media.  For =
streams based on RTP, this is done by
   placing the IP address and port =
of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP, it MUST encode
   the RTCP candidate using the a=3Drtcp attribute =
as defined in RFC 3605
   [RFC3605].  If RTCP =
is not in use, the agent MUST signal that using
   =
b=3DRS:0 and b=3DRR:0 as defined in RFC =
3556 [RFC3556].
 
There is an ongoing discussion whether the rtcp =
attribute is required in case of trickle ICE, when an offer is sent =
without candidate information, the RTP port set to 9, and the RTP IP =
address set to 0.0.0.0.
 
Example:
       =
                    =
   a=3Drtcp: 9 IN IP4 0.0.0.0
 
According to Christer this is not =
needed, as there is no candidate to =E2=80=9Cencode=E2=80=9D, and it =
also conflicts with the suggested mechanism for indicating exclusive =
support of RTP/RTCP multiplexing =
(draft-holmberg-mmusic-mux-exclusive).
 
Furthermore, =
according to section 2.1 of RFC 3605:
 
   The RTCP attribute is used to document the RTCP =
port used for media
   stream, when that port is not the next higher =
(odd) port number
   following the RTP port described in the media =
line.
 
RFC 5245 overwrites the guideline from RFC 3605 and = states that SDP rtcp attribute MUST be present even when RTCP default = candidate is not present or when RTCP candidate is using port rtp+1, = which is currently the the most common scenario since sequential port is = typically allocated for RTCP by TURN.
 
I suggest changing the language in = section 4.2 of draft-ietf-mmusic-ice-sip-sdp to:
 
   The =
default candidates are added to the SDP as the default
   =
destination for media.  For streams based on RTP, this is done =
by
   =
placing the IP address and port of the RTP candidate into the c and =
m
   =
lines, respectively.  If the agent is utilizing RTCP =
and if RTCP 
   candidate is =
present and not equal to the same address and 
   the next higher port number =
of the RTP candidate,
 
One reason for the text in RFC5245 (to require = a=3Drtcp, always) is to destroy the "port + 1" assumption of RTCP; it = simply breaks too many times with NAT.  So, I would go for your = proposed text if you removed "and not equal to the same address and = next-higher port number of the RTP candidate"; that is, if you're using = RTCP on any different port, the port number has to be explicitly = signaled with a=3Drtcp.  
 
-d
 
 


the agent MUST encode
   the RTCP candidate =
using the a=3Drtcp attribute as defined in RFC =
3605
   [RFC3605].  =
If RTCP is not in use, the agent MUST signal that using
   =
b=3DRS:0 and b=3DRR:0 as defined in RFC =
3556 [RFC3556].
 
Regards,
_____________
Roman Shpount
 
On Tue, Jan 12, 2016 at 8:02 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,
 
RFC 5245 = says the following:
 
   =             &n= bsp;           &nbs= p;   =E2=80=9CIf the agent is utilizing RTCP, it MUST = encode
   =             &n= bsp;           &nbs= p;  the RTCP candidate using the a=3Drtcp attribute as defined = in RFC 3605
   =             &n= bsp;           &nbs= p;   [RFC3605].=E2=80=9D=
 
There is an ongoing discussion whether the = rtcp attribute is required in case of trickle ICE, when an offer is sent = without candidate information, the RTP port set to 9, and the RTP IP = address set to 0.0.0.0.
 
Example:
 
          &nb= sp;            = ;      a=3Drtcp: 9 IN IP4 0.0.0.0
 
In my opinion this is not needed, as there is = no candidate to =E2=80=9Cencode=E2=80=9D, and it also conflicts with the = suggested mechanism for indicating exclusive support of RTP/RTCP = multiplexing (draft-holmberg-mmusic-mux-exclusive).
 
Regards,
 
Christer


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

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


= --Apple-Mail=_A48FC36A-885E-470C-83B5-384DFD38B63B-- From nobody Wed Jan 13 08:42:14 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3971B2AE7; Wed, 13 Jan 2016 08:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBKF5nVOcH9A; Wed, 13 Jan 2016 08:42:07 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC341B2F0A; Wed, 13 Jan 2016 08:42:06 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-bc-56967e5b3ef0 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.E2.04914.B5E76965; Wed, 13 Jan 2016 17:42:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Wed, 13 Jan 2016 17:42:03 +0100 From: Christer Holmberg To: =?utf-8?B?8J+Uk0RhbiBXaW5n?= Thread-Topic: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE Thread-Index: AdFNOVt7kQ2pmkCTSmeGFH6bEUVINQAOMjAAACf50gAAA2qfQP//8cUA///uguA= Date: Wed, 13 Jan 2016 16:42:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> In-Reply-To: <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> 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_7594FB04B1934943A5C02806D1A2204B37D16A3FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7sW5M3bQwg62mFhevPWSy+Hah1mLt 8ZuMFlOXP2axmHFhKrPF4gP3WR3YPKb83sjqsWTJTyaP46evs3rcmlIQwBLFZZOSmpNZllqk b5fAlbH1zDT2gimLmSr2H9jB2MB4ZDZTFyMnh4SAicSp01eYIWwxiQv31rN1MXJxCAkcZpSY NG06I4SzmFHi6refrF2MHBxsAhYS3f+0QUwRASOJRX/jQEqYBZqYJB7fmcEOMkhYwF7i0ak+ FhBbRMBB4nz/TGYI20/i3I8vTCC9LAKqEku/6oCEeQV8JY7vmwW1ah+TxKqWj2wgNZwCthKb btiB1DAC3fb91Bqwm5kFxCVuPZkPdb+AxJI956HuF5V4+fgfK4StJNG45AkrRH2+xLv+tWwQ uwQlTs58wjKBUXQWklGzkJTNQlI2C+gKZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6K UbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzBKD275rbuDcfVrx0OMAhyMSjy8G/ZODRNiTSwr rsw9xCjBwawkwitUOy1MiDclsbIqtSg/vqg0J7X4EKM0B4uSOG+yTGOYkEB6YklqdmpqQWoR TJaJg1OqgXH56QedjdG3N+0LnOmw0Mpq2cOkkw6rjyp1rVu9t3oPJ1vOu2j/UlU1k7WHY7xl Pc94Ly3vdpDr/dFbXbldrubw9m4RmwvJ066nfThytnyalOLW198Dw+OSn+sfPX2A+2myalJa 6Cnfde1bdljwXb0t3NnyPW2FbGbX39gLef0H5m01tuUv3qfEUpyRaKjFXFScCAD7Ht7ozgIA AA== Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:42:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D16A3FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3Qgc3VyZSBJIHVuZGVyc3Rvb2QgeW91IGxhc3QgaW5wdXQgOikNCg0KRnJvbTog8J+U k0RhbiBXaW5nIFttYWlsdG86ZHdpbmdAY2lzY28uY29tXQ0KU2VudDogMTMgSmFudWFyeSAyMDE2 IDE4OjQwDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4NCkNjOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT47IGljZUBpZXRmLm9y ZzsgbW11c2ljQGlldGYub3JnOyBNYXJjIFBldGl0LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3Vl bmluLm9yZz47IEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPjsgc25hbmRh a3VAY2lzY28uY29tDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gW0ljZV0gU0RQIHJ0Y3AgYXR0cmli dXRlIHdpdGggdHJpY2tsZSBJQ0UNCg0KDQpPbiAxMy1KYW4tMjAxNiAxMTozMiBhbSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBEYW4sDQoNClRoZSBjYXNlIHRo YXQgcmFpc2VkIHRoZSBpc3N1ZSBpcyB3aGVuIHRyaWNrbGUgSUNFIGlzIHVzZWQg4oCTIGFuZCBu byBwb3J0cyBhcmUgc2lnbmFsbGVkIHRvIGJlZ2luIHdpdGgsIGFuZCB0aGUgYz0gbGluZSBjb250 YWlucyBwb3J0IDkgYW5kIGEgMC4wLjAuMCBhZGRyZXNzLiBJbiBteSBvcGluaW9uIHRoZXJlIGlz IG5vIG5lZWQgZm9yIHRoZSBSVENQIGF0dHJpYnV0ZSBpbiB0aGF0IGNhc2UuDQoNClRoZW4geW91 J2xsIG5lZWQgYSBNVVNUIHRvIGluZGljYXRlICJNVVNUIHNpZ25hbCB1c2luZyBUcmlja2xlIiwg cmlnaHQ/DQoNCi1kDQoNCg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IPCflJNE YW4gV2luZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNvbV0NClNlbnQ6IDEzIEphbnVhcnkgMjAxNiAx Nzo1Mw0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbT4+DQpDYzogaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+OyBtbXVz aWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz47IENocmlzdGVyIEhvbG1iZXJnIDxj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4+OyBNYXJjIFBldGl0LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9y ZzxtYWlsdG86bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc+PjsgQXJpIEtlcsOkbmVuIDxhcmkua2Vy YW5lbkBlcmljc3Nvbi5jb208bWFpbHRvOmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT4+OyBzbmFu ZGFrdUBjaXNjby5jb208bWFpbHRvOnNuYW5kYWt1QGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlOiBb TU1VU0lDXSBbSWNlXSBTRFAgcnRjcCBhdHRyaWJ1dGUgd2l0aCB0cmlja2xlIElDRQ0KDQoNCk9u IDEyLUphbi0yMDE2IDAzOjQ4IHBtLCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxt YWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCkggQWxsLA0KDQpDcm9zcy1wb3N0aW5n IHRvIE1NVVNJQywgc2luY2UgdGhpcyBhZmZlY3RzIGJvdGggUkZDIDUyNDViaXMgYW5kIGRyYWZ0 LWlldGYtbW11c2ljLWljZS1zaXAtc2RwDQoNClJGQyA1MjQ1IGFuZCBkcmFmdC1pZXRmLW1tdXNp Yy1pY2Utc2lwLXNkcCBjdXJyZW50bHkgc2F5IHRoZSBmb2xsb3dpbmc6DQoNCg0KICAgVGhlIGRl ZmF1bHQgY2FuZGlkYXRlcyBhcmUgYWRkZWQgdG8gdGhlIFNEUCBhcyB0aGUgZGVmYXVsdA0KDQog ICBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuICBGb3Igc3RyZWFtcyBiYXNlZCBvbiBSVFAsIHRoaXMg aXMgZG9uZSBieQ0KDQogICBwbGFjaW5nIHRoZSBJUCBhZGRyZXNzIGFuZCBwb3J0IG9mIHRoZSBS VFAgY2FuZGlkYXRlIGludG8gdGhlIGMgYW5kIG0NCg0KICAgbGluZXMsIHJlc3BlY3RpdmVseS4g IElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcgUlRDUCwgaXQgTVVTVCBlbmNvZGUNCg0KICAgdGhl IFJUQ1AgY2FuZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3AgYXR0cmlidXRlIGFzIGRlZmluZWQgaW4g UkZDIDM2MDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2MDU+DQoNCiAgIFtSRkMz NjA1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjA1Pl0uICBJZiBSVENQIGlzIG5v dCBpbiB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVzaW5nDQoNCiAgIGI9UlM6MCBh bmQgYj1SUjowIGFzIGRlZmluZWQgaW4gUkZDIDM1NTY8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzM1NTY+IFtSRkMzNTU2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTU2 Pl0uDQoNCg0KDQpUaGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gd2hldGhlciB0aGUgcnRj cCBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQgaW4gY2FzZSBvZiB0cmlja2xlIElDRSwgd2hlbiBhbiBv ZmZlciBpcyBzZW50IHdpdGhvdXQgY2FuZGlkYXRlIGluZm9ybWF0aW9uLCB0aGUgUlRQIHBvcnQg c2V0IHRvIDksIGFuZCB0aGUgUlRQIElQIGFkZHJlc3Mgc2V0IHRvIDAuMC4wLjAuDQoNCg0KDQpF eGFtcGxlOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhPXJ0Y3A6IDkgSU4gSVA0 IDAuMC4wLjANCg0KDQoNCkFjY29yZGluZyB0byBDaHJpc3RlciB0aGlzIGlzIG5vdCBuZWVkZWQs IGFzIHRoZXJlIGlzIG5vIGNhbmRpZGF0ZSB0byDigJxlbmNvZGXigJ0sIGFuZCBpdCBhbHNvIGNv bmZsaWN0cyB3aXRoIHRoZSBzdWdnZXN0ZWQgbWVjaGFuaXNtIGZvciBpbmRpY2F0aW5nIGV4Y2x1 c2l2ZSBzdXBwb3J0IG9mIFJUUC9SVENQIG11bHRpcGxleGluZyAoZHJhZnQtaG9sbWJlcmctbW11 c2ljLW11eC1leGNsdXNpdmUpLg0KDQoNCg0KRnVydGhlcm1vcmUsIGFjY29yZGluZyB0byBzZWN0 aW9uIDIuMSBvZiBSRkMgMzYwNToNCg0KDQoNCiAgIFRoZSBSVENQIGF0dHJpYnV0ZSBpcyB1c2Vk IHRvIGRvY3VtZW50IHRoZSBSVENQIHBvcnQgdXNlZCBmb3IgbWVkaWENCg0KICAgc3RyZWFtLCB3 aGVuIHRoYXQgcG9ydCBpcyBub3QgdGhlIG5leHQgaGlnaGVyIChvZGQpIHBvcnQgbnVtYmVyDQoN CiAgIGZvbGxvd2luZyB0aGUgUlRQIHBvcnQgZGVzY3JpYmVkIGluIHRoZSBtZWRpYSBsaW5lLg0K DQpSRkMgNTI0NSBvdmVyd3JpdGVzIHRoZSBndWlkZWxpbmUgZnJvbSBSRkMgMzYwNSBhbmQgc3Rh dGVzIHRoYXQgU0RQIHJ0Y3AgYXR0cmlidXRlIE1VU1QgYmUgcHJlc2VudCBldmVuIHdoZW4gUlRD UCBkZWZhdWx0IGNhbmRpZGF0ZSBpcyBub3QgcHJlc2VudCBvciB3aGVuIFJUQ1AgY2FuZGlkYXRl IGlzIHVzaW5nIHBvcnQgcnRwKzEsIHdoaWNoIGlzIGN1cnJlbnRseSB0aGUgdGhlIG1vc3QgY29t bW9uIHNjZW5hcmlvIHNpbmNlIHNlcXVlbnRpYWwgcG9ydCBpcyB0eXBpY2FsbHkgYWxsb2NhdGVk IGZvciBSVENQIGJ5IFRVUk4uDQoNCkkgc3VnZ2VzdCBjaGFuZ2luZyB0aGUgbGFuZ3VhZ2UgaW4g c2VjdGlvbiA0LjIgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAgdG86DQoNCg0KICAg VGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBhcmUgYWRkZWQgdG8gdGhlIFNEUCBhcyB0aGUgZGVmYXVs dA0KDQogICBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuICBGb3Igc3RyZWFtcyBiYXNlZCBvbiBSVFAs IHRoaXMgaXMgZG9uZSBieQ0KDQogICBwbGFjaW5nIHRoZSBJUCBhZGRyZXNzIGFuZCBwb3J0IG9m IHRoZSBSVFAgY2FuZGlkYXRlIGludG8gdGhlIGMgYW5kIG0NCg0KICAgbGluZXMsIHJlc3BlY3Rp dmVseS4gIElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcgUlRDUCBhbmQgaWYgUlRDUA0KDQogICBj YW5kaWRhdGUgaXMgcHJlc2VudCBhbmQgbm90IGVxdWFsIHRvIHRoZSBzYW1lIGFkZHJlc3MgYW5k DQoNCiAgIHRoZSBuZXh0IGhpZ2hlciBwb3J0IG51bWJlciBvZiB0aGUgUlRQIGNhbmRpZGF0ZSwN Cg0KT25lIHJlYXNvbiBmb3IgdGhlIHRleHQgaW4gUkZDNTI0NSAodG8gcmVxdWlyZSBhPXJ0Y3As IGFsd2F5cykgaXMgdG8gZGVzdHJveSB0aGUgInBvcnQgKyAxIiBhc3N1bXB0aW9uIG9mIFJUQ1A7 IGl0IHNpbXBseSBicmVha3MgdG9vIG1hbnkgdGltZXMgd2l0aCBOQVQuICBTbywgSSB3b3VsZCBn byBmb3IgeW91ciBwcm9wb3NlZCB0ZXh0IGlmIHlvdSByZW1vdmVkICJhbmQgbm90IGVxdWFsIHRv IHRoZSBzYW1lIGFkZHJlc3MgYW5kIG5leHQtaGlnaGVyIHBvcnQgbnVtYmVyIG9mIHRoZSBSVFAg Y2FuZGlkYXRlIjsgdGhhdCBpcywgaWYgeW91J3JlIHVzaW5nIFJUQ1Agb24gYW55IGRpZmZlcmVu dCBwb3J0LCB0aGUgcG9ydCBudW1iZXIgaGFzIHRvIGJlIGV4cGxpY2l0bHkgc2lnbmFsZWQgd2l0 aCBhPXJ0Y3AuDQoNCi1kDQoNCg0KDQoNCg0KDQp0aGUgYWdlbnQgTVVTVCBlbmNvZGUNCg0KICAg dGhlIFJUQ1AgY2FuZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3AgYXR0cmlidXRlIGFzIGRlZmluZWQg aW4gUkZDIDM2MDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2MDU+DQoNCiAgIFtS RkMzNjA1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjA1Pl0uICBJZiBSVENQIGlz IG5vdCBpbiB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVzaW5nDQoNCiAgIGI9UlM6 MCBhbmQgYj1SUjowIGFzIGRlZmluZWQgaW4gUkZDIDM1NTY8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzM1NTY+IFtSRkMzNTU2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMz NTU2Pl0uDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFR1 ZSwgSmFuIDEyLCAyMDE2IGF0IDg6MDIgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+IHdyb3RlOg0KSGksDQoNClJGQyA1MjQ1IHNheXMgdGhlIGZvbGxvd2luZzoNCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIOKAnElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcgUlRD UCwgaXQgTVVTVCBlbmNvZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBSVENQ IGNhbmRpZGF0ZSB1c2luZyB0aGUgYT1ydGNwIGF0dHJpYnV0ZSBhcyBkZWZpbmVkIGluIFJGQyAz NjA1DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1JGQzM2MDVdLuKAnQ0KDQpUaGVy ZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gd2hldGhlciB0aGUgcnRjcCBhdHRyaWJ1dGUgaXMg cmVxdWlyZWQgaW4gY2FzZSBvZiB0cmlja2xlIElDRSwgd2hlbiBhbiBvZmZlciBpcyBzZW50IHdp dGhvdXQgY2FuZGlkYXRlIGluZm9ybWF0aW9uLCB0aGUgUlRQIHBvcnQgc2V0IHRvIDksIGFuZCB0 aGUgUlRQIElQIGFkZHJlc3Mgc2V0IHRvIDAuMC4wLjAuDQoNCkV4YW1wbGU6DQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYT1ydGNwOiA5IElOIElQNCAwLjAuMC4wDQoNCkluIG15IG9w aW5pb24gdGhpcyBpcyBub3QgbmVlZGVkLCBhcyB0aGVyZSBpcyBubyBjYW5kaWRhdGUgdG8g4oCc ZW5jb2Rl4oCdLCBhbmQgaXQgYWxzbyBjb25mbGljdHMgd2l0aCB0aGUgc3VnZ2VzdGVkIG1lY2hh bmlzbSBmb3IgaW5kaWNhdGluZyBleGNsdXNpdmUgc3VwcG9ydCBvZiBSVFAvUlRDUCBtdWx0aXBs ZXhpbmcgKGRyYWZ0LWhvbG1iZXJnLW1tdXNpYy1tdXgtZXhjbHVzaXZlKS4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxp c3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37D16A3FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBT eW1ib2wiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0b29kIHlvdSBsYXN0 IGlucHV0IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90Oyxz YW5zLXNlcmlmIj7wn5STPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRhbiBX aW5nIFttYWlsdG86ZHdpbmdAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDEzIEphbnVh cnkgMjAxNiAxODo0MDxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2Nocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJvbWFuIFNocG91 bnQgJmx0O3JvbWFuQHRlbHVyaXguY29tJmd0OzsgaWNlQGlldGYub3JnOyBtbXVzaWNAaWV0Zi5v cmc7IE1hcmMgUGV0aXQtSHVndWVuaW4gJmx0O21hcmNAcGV0aXQtaHVndWVuaW4ub3JnJmd0Ozsg QXJpIEtlcsOkbmVuICZsdDthcmkua2VyYW5lbkBlcmljc3Nvbi5jb20mZ3Q7OyBzbmFuZGFrdUBj aXNjby5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIFtJY2VdIFNEUCBydGNw IGF0dHJpYnV0ZSB3aXRoIHRyaWNrbGUgSUNFPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpPbiAxMy1KYW4tMjAxNiAxMToz MiBhbSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgRGFuLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlIGNhc2UgdGhhdCByYWlzZWQgdGhlIGlzc3VlIGlzIHdoZW4gdHJpY2ts ZSBJQ0UgaXMgdXNlZCDigJMgYW5kIG5vIHBvcnRzIGFyZSBzaWduYWxsZWQgdG8gYmVnaW4gd2l0 aCwgYW5kIHRoZSBjPSBsaW5lIGNvbnRhaW5zIHBvcnQgOSBhbmQgYSAwLjAuMC4wIGFkZHJlc3Mu DQogSW4gbXkgb3BpbmlvbiB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgUlRDUCBhdHRyaWJ1dGUg aW4gdGhhdCBjYXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuIHlvdSdsbCBuZWVk IGEgTVVTVCB0byBpbmRpY2F0ZSAmcXVvdDtNVVNUIHNpZ25hbCB1c2luZyBUcmlja2xlJnF1b3Q7 LCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIFN5bWJv bCZxdW90OyxzYW5zLXNlcmlmIj7wn5STPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkRhbg0KIFdpbmcgWzxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNjby5jb20iPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpkd2luZ0BjaXNjby5jb208L3NwYW4+PC9hPl08c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2Vu dDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjEz IEphbnVhcnkgMjAxNiAxNzo1Mzxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJvbWFuQHRlbHVyaXguY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yb21hbkB0 ZWx1cml4LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWNlQGlldGYub3JnPC9zcGFuPjwvYT47 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1tdXNp Y0BpZXRmLm9yZzwvc3Bhbj48L2E+Ow0KIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDs7IE1h cmMgUGV0aXQtSHVndWVuaW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJjQHBldGl0LWh1Z3Vlbmlu Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc8 L3NwYW4+PC9hPiZndDs7DQogQXJpIEtlcsOkbmVuICZsdDs8YSBocmVmPSJtYWlsdG86YXJpLmtl cmFuZW5AZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hcmkua2VyYW5l bkBlcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDs7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzbmFuZGFrdUBjaXNjby5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNuYW5kYWt1QGNpc2NvLmNvbTwvc3Bhbj48L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJlOiBbTU1VU0lDXSBbSWNlXSBTRFAgcnRjcCBhdHRyaWJ1dGUgd2l0aCB0 cmlja2xlIElDRTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gMTIt SmFuLTIwMTYgMDM6NDggcG0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21h bkB0ZWx1cml4LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cm9tYW5AdGVsdXJpeC5j b208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SCBBbGws PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3Jvc3MtcG9zdGluZyB0byBNTVVTSUMsIHNpbmNlIHRoaXMg YWZmZWN0cyBib3RoIFJGQyA1MjQ1YmlzIGFuZCBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNk cDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SRkMgNTI0NSBhbmQmbmJzcDs8 L3NwYW4+ZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAgY3VycmVudGx5Jm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5zYXkgdGhlIGZvbGxvd2luZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Indo aXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDsmbmJzcDsgVGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBh cmUgYWRkZWQgdG8gdGhlIFNEUCBhcyB0aGUgZGVmYXVsdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuJm5ic3A7IEZvciBzdHJlYW1zIGJh c2VkIG9uIFJUUCwgdGhpcyBpcyBkb25lIGJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHBsYWNpbmcgdGhlIElQIGFkZHJlc3MgYW5kIHBvcnQgb2YgdGhlIFJUUCBjYW5kaWRh dGUgaW50byB0aGUgYyBhbmQgbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBs aW5lcywgcmVzcGVjdGl2ZWx5LiZuYnNwOyA8Yj5JZiB0aGUgYWdlbnQgaXMgdXRpbGl6aW5nIFJU Q1AsIGl0IE1VU1QgZW5jb2RlPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZu YnNwOyB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1dGUgYXMgZGVm aW5lZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQyAzNjA1PC9zcGFuPjwv YT48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSImcXVvdDtSZWFsIFRpbWUgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgYXR0cmlidXRlIGluIFNl c3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkmcXVvdDsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPlJGQzM2MDU8L3NwYW4+PC9hPl0uPC9iPiZuYnNwOyBJZiBSVENQIGlzIG5vdCBp biB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVzaW5nPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGI9UlM6MCBhbmQgYj1SUjowIGFzIGRlZmluZWQgaW4gPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTYiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5SRkMgMzU1Njwvc3Bhbj48L2E+IFs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1NiIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSImcXVvdDtTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIEJhbmR3aWR0aCBNb2Rp ZmllcnMgZm9yIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBCYW5kd2lkdGgmcXVvdDsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQzM1NTY8L3NwYW4+PC9hPl0uPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDs8bzpwPjwvbzpw PjwvcHJlPg0KPGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gd2hl dGhlciB0aGUgcnRjcCBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQgaW4gY2FzZSBvZiB0cmlja2xlIElD RSwgd2hlbiBhbiBvZmZlciBpcyBzZW50IHdpdGhvdXQgY2FuZGlkYXRlIGluZm9ybWF0aW9uLCB0 aGUgUlRQIHBvcnQgc2V0IHRvIDksIGFuZCB0aGUgUlRQIElQIGFkZHJlc3Mgc2V0IHRvIDAuMC4w LjAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FeGFtcGxlOjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9cnRjcDogOSBJTiBJUDQgMC4w LjAuMDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWNjb3JkaW5n IHRvIENocmlzdGVyIHRoaXMgaXMgbm90IG5lZWRlZCwgYXMgdGhlcmUgaXMgbm8gY2FuZGlkYXRl IHRvIOKAnGVuY29kZeKAnSwgYW5kIGl0IGFsc28gY29uZmxpY3RzIHdpdGggdGhlIHN1Z2dlc3Rl ZCBtZWNoYW5pc20gZm9yIGluZGljYXRpbmcgZXhjbHVzaXZlIHN1cHBvcnQgb2YgUlRQL1JUQ1Ag bXVsdGlwbGV4aW5nIChkcmFmdC1ob2xtYmVyZy1tbXVzaWMtbXV4LWV4Y2x1c2l2ZSkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZ1cnRoZXJtb3JlLCBhY2NvcmRpbmcgdG8gc2VjdGlv biAyLjEgb2YgUkZDIDM2MDU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Rpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBSVENQIGF0dHJpYnV0ZSBpcyB1c2VkIHRvIGRv Y3VtZW50IHRoZSBSVENQIHBvcnQgdXNlZCBmb3IgbWVkaWE8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgc3RyZWFtLCB3aGVuIHRoYXQgcG9ydCBpcyBub3QgdGhlIG5leHQgaGln aGVyIChvZGQpIHBvcnQgbnVtYmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGZvbGxvd2luZyB0aGUgUlRQIHBvcnQgZGVzY3JpYmVkIGluIHRoZSBtZWRpYSBsaW5lLjxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyA1MjQ1IG92ZXJ3cml0ZXMgdGhlIGd1aWRlbGlu ZSBmcm9tIFJGQyAzNjA1IGFuZCBzdGF0ZXMgdGhhdCBTRFAgcnRjcCBhdHRyaWJ1dGUgTVVTVCBi ZSBwcmVzZW50IGV2ZW4gd2hlbiBSVENQIGRlZmF1bHQgY2FuZGlkYXRlIGlzIG5vdCBwcmVzZW50 IG9yIHdoZW4gUlRDUCBjYW5kaWRhdGUgaXMgdXNpbmcgcG9ydCBydHAmIzQzOzEsIHdoaWNoIGlz IGN1cnJlbnRseSB0aGUgdGhlIG1vc3QgY29tbW9uIHNjZW5hcmlvDQogc2luY2Ugc2VxdWVudGlh bCBwb3J0IGlzIHR5cGljYWxseSBhbGxvY2F0ZWQgZm9yIFJUQ1AgYnkgVFVSTi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdnZXN0IGNoYW5naW5nIHRoZSBsYW5ndWFnZSBpbiBzZWN0 aW9uIDQuMiBvZiZuYnNwO2RyYWZ0LWlldGYtbW11c2ljLWljZS1zaXAtc2RwIHRvOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5 bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDsmbmJzcDsgVGhlIGRlZmF1bHQgY2FuZGlk YXRlcyBhcmUgYWRkZWQgdG8gdGhlIFNEUCBhcyB0aGUgZGVmYXVsdDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuJm5ic3A7IEZvciBzdHJl YW1zIGJhc2VkIG9uIFJUUCwgdGhpcyBpcyBkb25lIGJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IHBsYWNpbmcgdGhlIElQIGFkZHJlc3MgYW5kIHBvcnQgb2YgdGhlIFJUUCBj YW5kaWRhdGUgaW50byB0aGUgYyBhbmQgbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBsaW5lcywgcmVzcGVjdGl2ZWx5LiZuYnNwOyA8Yj5JZiB0aGUgYWdlbnQgaXMgdXRpbGl6 aW5nIFJUQ1AgYW5kIGlmIFJUQ1AgPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2FuZGlkYXRlIGlzIHBy ZXNlbnQgYW5kIG5vdCBlcXVhbCB0byB0aGUgc2FtZSBhZGRyZXNzIGFuZCA8L2I+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48Yj4mbmJzcDsmbmJz cDsmbmJzcDt0aGUgbmV4dCBoaWdoZXIgcG9ydCBudW1iZXIgb2YgdGhlIFJUUCBjYW5kaWRhdGUs IDwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uZSByZWFzb24gZm9yIHRoZSB0ZXh0IGluIFJGQzUyNDUgKHRvIHJlcXVpcmUgYT1ydGNwLCBh bHdheXMpIGlzIHRvIGRlc3Ryb3kgdGhlICZxdW90O3BvcnQgJiM0MzsgMSZxdW90OyBhc3N1bXB0 aW9uIG9mIFJUQ1A7IGl0IHNpbXBseSBicmVha3MgdG9vIG1hbnkgdGltZXMgd2l0aCBOQVQuICZu YnNwO1NvLCBJIHdvdWxkIGdvIGZvciB5b3VyIHByb3Bvc2VkIHRleHQgaWYgeW91IHJlbW92ZWQg JnF1b3Q7YW5kIG5vdCBlcXVhbCB0byB0aGUgc2FtZSBhZGRyZXNzDQogYW5kIG5leHQtaGlnaGVy IHBvcnQgbnVtYmVyIG9mIHRoZSBSVFAgY2FuZGlkYXRlJnF1b3Q7OyB0aGF0IGlzLCBpZiB5b3Un cmUgdXNpbmcgUlRDUCBvbiBhbnkgZGlmZmVyZW50IHBvcnQsIHRoZSBwb3J0IG51bWJlciBoYXMg dG8gYmUgZXhwbGljaXRseSBzaWduYWxlZCB3aXRoIGE9cnRjcC4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi1kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGI+dGhlIGFnZW50IE1V U1QgZW5jb2RlPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyB0aGUg UlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1dGUgYXMgZGVmaW5lZCBpbiA8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQyAzNjA1PC9zcGFuPjwvYT48L2I+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtS ZWFsIFRpbWUgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgYXR0cmlidXRlIGluIFNlc3Npb24gRGVz Y3JpcHRpb24gUHJvdG9jb2wgKFNEUCkmcXVvdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PlJGQzM2MDU8L3NwYW4+PC9hPl0uPC9iPiZuYnNwOyBJZiBSVENQIGlzIG5vdCBpbiB1c2UsIHRo ZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVzaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IGI9UlM6MCBhbmQgYj1SUjowIGFzIGRlZmluZWQgaW4gPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5SRkMgMzU1Njwvc3Bhbj48L2E+IFs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjMzU1NiIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtT ZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIEJhbmR3aWR0aCBNb2RpZmllcnMgZm9y IFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBCYW5kd2lkdGgmcXVvdDsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPlJGQzM1NTY8L3NwYW4+PC9hPl0uPG86cD48L286cD48L3ByZT4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKYW4gMTIsIDIwMTYgYXQgODowMiBBTSwgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RkkiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UkZD IDUyNDUgc2F5cyB0aGUgZm9sbG93aW5nOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAnElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcg UlRDUCwgaXQgTVVTVCBlbmNvZGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBSVENQIGNh bmRpZGF0ZSB1c2luZyB0aGUgYT1ydGNwIGF0dHJpYnV0ZSBhcyBkZWZpbmVkIGluIFJGQyAzNjA1 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPltS RkMzNjA1XS7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoZXJlIGlzIGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiB3aGV0aGVyIHRoZSBydGNwIGF0dHJpYnV0 ZSBpcyByZXF1aXJlZCBpbiBjYXNlIG9mIHRyaWNrbGUgSUNFLCB3aGVuIGFuIG9mZmVyIGlzIHNl bnQgd2l0aG91dCBjYW5kaWRhdGUgaW5mb3JtYXRpb24sIHRoZSBSVFAgcG9ydCBzZXQgdG8gOSwg YW5kIHRoZSBSVFAgSVAgYWRkcmVzcyBzZXQgdG8gMC4wLjAuMC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkV4YW1wbGU6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYT1ydGNwOiA5IElOIElQNCAwLjAuMC4wPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBteSBvcGlu aW9uIHRoaXMgaXMgbm90IG5lZWRlZCwgYXMgdGhlcmUgaXMgbm8gY2FuZGlkYXRlIHRvIOKAnGVu Y29kZeKAnSwgYW5kIGl0IGFsc28gY29uZmxpY3RzIHdpdGggdGhlIHN1Z2dlc3RlZCBtZWNoYW5p c20gZm9yIGluZGljYXRpbmcgZXhjbHVzaXZlIHN1cHBvcnQgb2YgUlRQL1JUQ1AgbXVsdGlwbGV4 aW5nIChkcmFmdC1ob2xtYmVyZy1tbXVzaWMtbXV4LWV4Y2x1c2l2ZSkuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojODg4ODg4Ij5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklj ZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWNlQGlldGYub3JnPC9zcGFu PjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ljZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVz aWNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1tdXNpY0BpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37D16A3FESESSMB209erics_-- From nobody Wed Jan 13 08:51:04 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13D91B2F32; Wed, 13 Jan 2016 08:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.001 X-Spam-Level: X-Spam-Status: No, score=-13.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqN5IsiSt13O; Wed, 13 Jan 2016 08:50:49 -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 39F641B2B04; Wed, 13 Jan 2016 08:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44884; q=dns/txt; s=iport; t=1452703849; x=1453913449; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=gwyUyIgghiC1mFyefx2LnaUjOnLHmd2ezfbR3h3Ls+4=; b=EkBiwxc9vKHsLKxpourZcs1XD7CvvGbv2Ti+UMlyk2RRGEc1wRC1Seh5 JVrzPr5r4xV74TH3noY/sQlKyOfwmfsvM1nkzww5b0q8kp53Jt3u49XJh 52Ts5cWZeCqI+EuG92zwF0UbSgtijbT6OTrv+YsEy+nfgwh8CG1ZkejJo 8=; X-IronPort-AV: E=Sophos; i="5.22,290,1449532800"; d="scan'208,217"; a="61133406" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jan 2016 16:50:48 +0000 Received: from [10.131.44.84] ([10.131.44.84]) (authenticated bits=0) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0DGoW76029323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2016 16:50:46 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_667C609A-E41D-4218-BF20-6F6015464AA9" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> Date: Wed, 13 Jan 2016 11:50:30 -0500 Message-Id: <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-Authenticated-User: dwing Archived-At: Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:50:53 -0000 --Apple-Mail=_667C609A-E41D-4218-BF20-6F6015464AA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 13-Jan-2016 11:42 am, Christer Holmberg = wrote:=20 > I am not sure I understood you last input :) With existing proposed new text, lack of a=3Drtcp could be interpreted = to mean: * RTCP on port+1 * no RTCP at all need to differentiate between those. I like a=3Drtcp to differentiate = between those, I think you're saying existence of a=3Dtrickle = differentiates (or whatever the trickle SDP, I forget what it's supposed = to be right now, sorry). -d > =C2=A0 <> > From: =F0=9F=94=93Dan Wing [mailto:dwing@cisco.com = ]=20 > Sent: 13 January 2016 18:40 > To: Christer Holmberg > > Cc: Roman Shpount >; = ice@ietf.org ; mmusic@ietf.org = ; Marc Petit-Huguenin >; Ari Ker=C3=A4nen = >; = snandaku@cisco.com > Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE > =20 >=20 > On 13-Jan-2016 11:32 am, Christer Holmberg = > = wrote: > Hi Dan, > =20 > The case that raised the issue is when trickle ICE is used =E2=80=93 = and no ports are signalled to begin with, and the c=3D line contains = port 9 and a 0.0.0.0 address. In my opinion there is no need for the = RTCP attribute in that case. > =20 > Then you'll need a MUST to indicate "MUST signal using Trickle", = right? > =20 > -d > =20 >=20 >=20 > =20 > Regards, > =20 > Christer > =20 > From: =F0=9F=94=93Dan Wing [mailto:dwing@cisco.com = ]=20 > Sent: 13 January 2016 17:53 > To: Roman Shpount > > Cc: ice@ietf.org ; mmusic@ietf.org = ; Christer Holmberg = >; Marc Petit-Huguenin = >; Ari Ker=C3=A4n= en >; = snandaku@cisco.com > Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE > =20 >=20 > On 12-Jan-2016 03:48 pm, Roman Shpount > wrote: > H All, > =20 > Cross-posting to MMUSIC, since this affects both RFC 5245bis and = draft-ietf-mmusic-ice-sip-sdp > =20 > RFC 5245 and draft-ietf-mmusic-ice-sip-sdp currently say the = following: > =20 > The default candidates are added to the SDP as the default > destination for media. For streams based on RTP, this is done by > placing the IP address and port of the RTP candidate into the c and = m > lines, respectively. If the agent is utilizing RTCP, it MUST = encode > the RTCP candidate using the a=3Drtcp attribute as defined in RFC = 3605 > [RFC3605 ]. If RTCP is not in = use, the agent MUST signal that using > b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 = [RFC3556 = ]. > =20 > There is an ongoing discussion whether the rtcp attribute is required = in case of trickle ICE, when an offer is sent without candidate = information, the RTP port set to 9, and the RTP IP address set to = 0.0.0.0. > =20 > Example: > a=3Drtcp: 9 IN IP4 0.0.0.0 > =20 > According to Christer this is not needed, as there is no candidate to = =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested = mechanism for indicating exclusive support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive). > =20 > Furthermore, according to section 2.1 of RFC 3605: > =20 > The RTCP attribute is used to document the RTCP port used for media > stream, when that port is not the next higher (odd) port number > following the RTP port described in the media line. > =20 > RFC 5245 overwrites the guideline from RFC 3605 and states that SDP = rtcp attribute MUST be present even when RTCP default candidate is not = present or when RTCP candidate is using port rtp+1, which is currently = the the most common scenario since sequential port is typically = allocated for RTCP by TURN. > =20 > I suggest changing the language in section 4.2 of = draft-ietf-mmusic-ice-sip-sdp to: > =20 > The default candidates are added to the SDP as the default > destination for media. For streams based on RTP, this is done by > placing the IP address and port of the RTP candidate into the c and = m > lines, respectively. If the agent is utilizing RTCP and if RTCP=20 > candidate is present and not equal to the same address and=20 > the next higher port number of the RTP candidate,=20 > =20 > One reason for the text in RFC5245 (to require a=3Drtcp, always) is to = destroy the "port + 1" assumption of RTCP; it simply breaks too many = times with NAT. So, I would go for your proposed text if you removed = "and not equal to the same address and next-higher port number of the = RTP candidate"; that is, if you're using RTCP on any different port, the = port number has to be explicitly signaled with a=3Drtcp. =20 > =20 > -d > =20 > =20 >=20 >=20 >=20 > the agent MUST encode > the RTCP candidate using the a=3Drtcp attribute as defined in RFC = 3605 > [RFC3605 ]. If RTCP is not in = use, the agent MUST signal that using > b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 = [RFC3556 = ]. > =20 > Regards, > _____________ > Roman Shpount > =20 > On Tue, Jan 12, 2016 at 8:02 AM, Christer Holmberg = > = wrote: > Hi, > =20 > RFC 5245 says the following: > =20 > =E2=80=9CIf the agent is utilizing = RTCP, it MUST encode > the RTCP candidate using the a=3Drtcp = attribute as defined in RFC 3605 > [RFC3605].=E2=80=9D > =20 > There is an ongoing discussion whether the rtcp attribute is required = in case of trickle ICE, when an offer is sent without candidate = information, the RTP port set to 9, and the RTP IP address set to = 0.0.0.0. > =20 > Example: > =20 > a=3Drtcp: 9 IN IP4 0.0.0.0 > =20 > In my opinion this is not needed, as there is no candidate to = =E2=80=9Cencode=E2=80=9D, and it also conflicts with the suggested = mechanism for indicating exclusive support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive). > =20 > Regards, > =20 > Christer >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice = > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = --Apple-Mail=_667C609A-E41D-4218-BF20-6F6015464AA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 13-Jan-2016 11:42 am, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
I am not sure I understood you last input = :)

With existing proposed new text, lack of a=3Drtcp = could be interpreted to mean:

  = * RTCP on port+1
  * no RTCP at all

need to differentiate between those.  I like = a=3Drtcp to differentiate between those, I think you're saying existence = of a=3Dtrickle differentiates (or whatever the trickle SDP, I forget = what it's supposed to be right now, sorry).

-d


 
From: =F0=9F=94=93Dan Wing [mailto:dwing@cisco.com] 
Sent: 13 = January 2016 18:40
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Roman= Shpount <roman@telurix.com>; ice@ietf.org; mmusic@ietf.org; Marc Petit-Huguenin <marc@petit-huguenin.org>; = Ari Ker=C3=A4nen <ari.keranen@ericsson.com>; snandaku@cisco.com
Subject: Re: [MMUSIC] [Ice] SDP rtcp = attribute with trickle ICE
 

On = 13-Jan-2016 11:32 am, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi = Dan,
 
The case that raised the issue is when = trickle ICE is used =E2=80=93 and no ports are signalled to begin with, = and the c=3D line contains port 9 and a 0.0.0.0 address. In my opinion = there is no need for the RTCP attribute in that case.
 
Then you'll need a MUST to indicate "MUST signal = using Trickle", right?
 
-d
 


 
Regards,
 
Christer
 
From: =F0=9F=94=93Dan Wing [mailto:dwing@cisco.com] 
Sent: 13 = January 2016 17:53
To: Roman Shpount <roman@telurix.com>
Cc: ice@ietf.org; mmusic@ietf.org; Christer Holmberg <christer.holmberg@ericsson.com>; Marc = Petit-Huguenin <marc@petit-huguenin.org>; Ari Ker=C3=A4nen = <ari.keranen@ericsson.com>; snandaku@cisco.com
Subject: Re: [MMUSIC] [Ice] SDP rtcp = attribute with trickle ICE
 

On = 12-Jan-2016 03:48 pm, Roman Shpount <roman@telurix.com> wrote:
H = All,
 
Cross-posting to MMUSIC, since this affects both RFC = 5245bis and draft-ietf-mmusic-ice-sip-sdp
 
RFC 5245 = and draft-ietf-mmusic-ice-sip-sdp currently say the following:
 
   The default candidates =
are added to the SDP as the default
   destination for media.  For =
streams based on RTP, this is done by
   placing the IP address and port =
of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP, it MUST encode
   the RTCP candidate using the a=3Drtcp attribute =
as defined in RFC =
3605
   [RFC3605].  If RTCP is not in =
use, the agent MUST signal that using
   b=3DRS:0 and b=3DRR:0 as defined =
in RFC 3556 [RFC3556].
 
There is an ongoing =
discussion whether the rtcp attribute is required in case of trickle =
ICE, when an offer is sent without candidate information, the RTP port =
set to 9, and the RTP IP address set to 0.0.0.0.
 
Example:
       =
                    =
   a=3Drtcp: 9 IN IP4 0.0.0.0
 
According to Christer this is not =
needed, as there is no candidate to =E2=80=9Cencode=E2=80=9D, and it =
also conflicts with the suggested mechanism for indicating exclusive =
support of RTP/RTCP multiplexing =
(draft-holmberg-mmusic-mux-exclusive).
 
Furthermore, according to section 2.1 =
of RFC 3605:
 
   =
The RTCP attribute is used to document the RTCP port used for media
   =
stream, when that port is not the next higher (odd) port number
   =
following the RTP port described in the media line.
 
RFC 5245 overwrites the guideline from = RFC 3605 and states that SDP rtcp attribute MUST be present even when = RTCP default candidate is not present or when RTCP candidate is using = port rtp+1, which is currently the the most common scenario since = sequential port is typically allocated for RTCP by TURN.
 
I suggest changing the language in = section 4.2 of draft-ietf-mmusic-ice-sip-sdp to:
 
   The default candidates =
are added to the SDP as the default
   destination for media.  For =
streams based on RTP, this is done by
   placing the IP address and port =
of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP and if RTCP 
   candidate is present and not =
equal to the same address and 
   the next higher port number of the RTP =
candidate,
 
One reason for the text in RFC5245 (to = require a=3Drtcp, always) is to destroy the "port + 1" assumption of = RTCP; it simply breaks too many times with NAT.  So, I would go for = your proposed text if you removed "and not equal to the same address and = next-higher port number of the RTP candidate"; that is, if you're using = RTCP on any different port, the port number has to be explicitly = signaled with a=3Drtcp.  
 
-d
 
 



the agent MUST encode
   the RTCP candidate =
using the a=3Drtcp attribute as defined in RFC 3605
   [RFC3605].  If RTCP is not in =
use, the agent MUST signal that using
   b=3DRS:0 and b=3DRR:0 as defined =
in RFC 3556 [RFC3556].
 
Regards,
_____________
Roman Shpount
 
On Tue, Jan 12, 2016 at 8:02 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,
 
RFC 5245 says the = following:
 
   =             &n= bsp;           &nbs= p;   =E2=80=9CIf the agent is utilizing RTCP, it MUST = encode
   =             &n= bsp;           &nbs= p;  the RTCP candidate using the a=3Drtcp attribute as defined = in RFC 3605
   =             &n= bsp;           &nbs= p;   [RFC3605].=E2=80=9D
 
There is an ongoing = discussion whether the rtcp attribute is required in case of trickle = ICE, when an offer is sent without candidate information, the RTP port = set to 9, and the RTP IP address set to 0.0.0.0.
 
Example:
 
          &nb= sp;            = ;      a=3Drtcp: 9 IN IP4 0.0.0.0
 
In my opinion this is not = needed, as there is no candidate to =E2=80=9Cencode=E2=80=9D, and it = also conflicts with the suggested mechanism for indicating exclusive = support of RTP/RTCP multiplexing = (draft-holmberg-mmusic-mux-exclusive).
 
Regards,
 
Christer


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

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


= --Apple-Mail=_667C609A-E41D-4218-BF20-6F6015464AA9-- From nobody Wed Jan 13 09:01:00 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865A81B2B00 for ; Wed, 13 Jan 2016 09:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiMB1qjuFVIF for ; Wed, 13 Jan 2016 09:00:55 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 4E0A51A6FA3 for ; Wed, 13 Jan 2016 09:00:55 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id q21so424646157iod.0 for ; Wed, 13 Jan 2016 09:00:55 -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:date:message-id:subject:from:to :cc:content-type; bh=NShNmIqh0pHiNmcJL6uTvz4JwFP3CPQQxtI6gZgauHU=; b=PFHGXfeRP9TojIKW04dB0wl44eGhf557LYAtSUQlTOL1zqEho1VY69Eai53TFHQwhE 6BElRP8CRrrrvN0j/3XrOSkNLAlhovtROdFs1J5RG0LWBVEzfYmMih+1aML8Tbg4HNjz cMepVL9uS97s3FN+uPifoeDnIk+o5SBGaYdnIVArULD+7fK6Idex86xAKptHwUrCAm6k Kh1coCrpMVYHp+dH6NOm5aeoZHYAVifrCQA/uZS25TMjZTNCV8Vo0wpypDyKwgyILPvv G7gY5eRw7Fb9QLz8aJEqknfXeRviD03V4WiNF675t17m9PIDG+pEpssnyTbBBgNe6aHY zZ9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NShNmIqh0pHiNmcJL6uTvz4JwFP3CPQQxtI6gZgauHU=; b=mgqc4yPo4yKGa+VgVwLPTVSODzzYDBOSNMXRvzAYIIfvx73Bs/iy7i8rGVPhgp9TXI lrVenI1hjkwRTOJQxpJp3CfHXhezqzzzenFn/UTkvVYFMEFRrOQmROK70+TRI3l5ANWV 1djijWObF97B3xnHE2W5r5Vl+FiG2hFfojU+xEThmUp5xyKousiopsVNHhNsDlcEPTOz GGuqCYVloeyGB4WTDIRgtDi+adCao6qW9Rcdg3BK9PPthC1seQ0XQXdp+KbZtsLrBocr KSxy8mWv6VVYfF7rEqzYDT3mKiGmrNABExlgHjE8u1hkWydv08RDsC5tikVHXDr210UU VGlA== X-Gm-Message-State: ALoCoQm3/TykVi1Vi0xomJfg/HQT4RsdHsoBAbca6Ii3buu18AohbYO1gRSEUqxg+q7ba1jh8ryjcSjP2JQGa4gI4F4aea2aAQ== X-Received: by 10.107.46.11 with SMTP id i11mr128923717ioo.67.1452704454694; Wed, 13 Jan 2016 09:00:54 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id 124sm1191034ioz.10.2016.01.13.09.00.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 09:00:53 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id 1so377684958ion.1; Wed, 13 Jan 2016 09:00:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.41.142 with SMTP id p136mr112061980iop.70.1452704452435; Wed, 13 Jan 2016 09:00:52 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 13 Jan 2016 09:00:52 -0800 (PST) In-Reply-To: <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> Date: Wed, 13 Jan 2016 12:00:52 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=001a1141f3e2d9e6d705293a1c9c Archived-At: Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , Christer Holmberg , snandaku@cisco.com Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 17:00:56 -0000 --001a1141f3e2d9e6d705293a1c9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 13, 2016 at 10:52 AM, =F0=9F=94=93Dan Wing wr= ote: > > One reason for the text in RFC5245 (to require a=3Drtcp, always) is to > destroy the "port + 1" assumption of RTCP; it simply breaks too many time= s > with NAT. So, I would go for your proposed text if you removed "and not > equal to the same address and next-higher port number of the RTP > candidate"; that is, if you're using RTCP on any different port, the port > number has to be explicitly signaled with a=3Drtcp. > > I wanted to clarify one thing: if TURN is used in conjunction with ICE then relay candidate is used as default. This, I believe is recommended and the most common ICE use case scenario. TURN server allocates RTCP on the RTP port + 1. How would this break in case of NAT? On my service, for instance, since TURN is used all SDP comes with a=3Drtcp pointing to rtp port+1. The only time a=3Drtcp attribute is useful is when reflexive candidates are use= d as default which is just the fraction of all the use cases. Furthermore, presence or absence of a=3Drtcp attribute cannot be used to determine if RTCP is present. b=3DRS:0 and b=3DRR:0 are supposed to be used= for this. _____________ Roman Shpount --001a1141f3e2d9e6d705293a1c9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 13, 2016 at 10:52 AM, =F0=9F=94=93Dan Wing <dwing@cisco.com= > wrote:

One reason for the text in RFC5245 (to require = a=3Drtcp, always) is to destroy the "port + 1" assumption of RTCP= ; it simply breaks too many times with NAT.=C2=A0 So, I would go for your p= roposed text if you removed "and not equal to the same address and nex= t-higher port number of the RTP candidate"; that is, if you're usi= ng RTCP on any different port, the port number has to be explicitly signale= d with a=3Drtcp. =C2=A0

<= br>
I wanted to clarify one thing: if TURN is used in conjunction= with ICE then relay candidate is used as default.=C2=A0 This, I believe is= recommended and the most common ICE use case scenario. TURN server allocat= es RTCP on the RTP port + 1. How would this break in case of NAT? On my ser= vice, for instance, since TURN is used all SDP comes with a=3Drtcp pointing= to rtp port+1. The only time a=3Drtcp attribute is useful is when reflexiv= e candidates are used as default which is just the fraction of all the use = cases.

Furthermore, presence or absence of a=3Drtc= p attribute cannot be used to determine if RTCP is present.=C2=A0b=3DRS:0 and b=3DRR:0 are su= pposed to be used for this.
_____________
Roman Shpount
=C2=A0
--001a1141f3e2d9e6d705293a1c9c-- From nobody Wed Jan 13 09:01:25 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B111A1B1E; Wed, 13 Jan 2016 09:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsUunZPR5IE3; Wed, 13 Jan 2016 09:01:16 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998A71B2B08; Wed, 13 Jan 2016 09:01:15 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-8d-569682d97380 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.BA.30208.9D286965; Wed, 13 Jan 2016 18:01:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Wed, 13 Jan 2016 18:01:13 +0100 From: Christer Holmberg To: =?utf-8?B?8J+Uk0RhbiBXaW5n?= Thread-Topic: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE Thread-Index: AdFNOVt7kQ2pmkCTSmeGFH6bEUVINQAOMjAAACf50gAAA2qfQP//8cUA///uguCAABSOAP//7SWg Date: Wed, 13 Jan 2016 17:01:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> In-Reply-To: <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> 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_7594FB04B1934943A5C02806D1A2204B37D16AE3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7qO7NpmlhBm0PzSwuXnvIZPHtQq3F 2uM3GS2mLn/MYjHjwlRmi8UH7rM6sHlM+b2R1WPJkp9MHsdPX2f1uDWlIIAlissmJTUnsyy1 SN8ugSuj+WYje8G6ecwVH/t2sTUwnpjM3MXIySEhYCLRf/MNG4QtJnHh3nogm4tDSOAwo8SR jrvMEM5iRolTb68wdjFycLAJWEh0/9MGMUUEjCQW/Y0DKWEWaGKSeHxnBjvIIGEBe4lHp/pY QGwRAQeJ8/0zmSHsKImOrW/AbBYBVYmTy96B2bwCvhKdt5pYIXZtZZaYPGUNWDOngK3EgSd3 wa5jBLru+6k1TCA2s4C4xK0n85kgrhaQWLLnPNQ3ohIvH/9jhbCVJBqXPGGFqM+XWNL7B2qZ oMTJmU9YJjCKzkIyahaSsllIymYB/cksoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzGK FqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExurBLb9VdzBefuN4iFGAg1GJh3fD3qlhQqyJZcWV uYcYJTiYlUR4hWqnhQnxpiRWVqUW5ccXleakFh9ilOZgURLnTZJpDBMSSE8sSc1OTS1ILYLJ MnFwSjUwBvhb81lkLcpMFrjgbXhp2tbW649SzZ3V6uu4jm/qvne5Oa5g9tNJsdsXnbhpsfWj k25Iwd+j+1smrtt62nZTX+lyY4Ur5vqxLkGTDe4o/9KNnDJBRFo9e+vVPla1n4s2TygPl3+v 7Pb5wS2pV40HTlnpKsqIrDquKxf0Sun3jI8anhHLp+1fpsRSnJFoqMVcVJwIAPX4MO/RAgAA Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 17:01:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D16AE3ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk15IHN1Z2dlc3Rpb24gb2YgbGFjayBvZiBhPXJ0Y3AgaXM6DQoNCg0KLSAgICAgICAg ICBJZiBhbiBSVFAgbm9uLTkgcG9ydCBpcyBwcm92aWRlZCwgdGhlIFJUQ1AgcG9ydCBpcyBSVFAr MQ0KDQotICAgICAgICAgIElmIGFuIFJUUCA5IChkaXNhYmxlZCkgcG9ydCBpcyBwcm92aWRlZCwg dGhlIFJUQ1AgcG9ydCBpcyBpbXBsaWNpdGx5IGFsc28gZGlzYWJsZWQNCg0KVGhlcmUgYXJlIG90 aGVyIG1lY2hhbmlzbXMgdG8gaW5kaWNhdGUgdGhhdCBSVENQIHdvbuKAmXQgYmUgdXNlZCB0byBi ZWdpbiB3aXRoLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiDwn5STRGFuIFdpbmcg W21haWx0bzpkd2luZ0BjaXNjby5jb21dDQpTZW50OiAxMyBKYW51YXJ5IDIwMTYgMTg6NTENClRv OiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6 IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPjsgaWNlQGlldGYub3JnOyBtbXVzaWNA aWV0Zi5vcmc7IE1hcmMgUGV0aXQtSHVndWVuaW4gPG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPjsg QXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+OyBzbmFuZGFrdUBjaXNjby5j b20NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbSWNlXSBTRFAgcnRjcCBhdHRyaWJ1dGUgd2l0aCB0 cmlja2xlIElDRQ0KDQoNCk9uIDEzLUphbi0yMDE2IDExOjQyIGFtLCBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0b29kIHlvdSBs YXN0IGlucHV0IDopDQoNCldpdGggZXhpc3RpbmcgcHJvcG9zZWQgbmV3IHRleHQsIGxhY2sgb2Yg YT1ydGNwIGNvdWxkIGJlIGludGVycHJldGVkIHRvIG1lYW46DQoNCiAgKiBSVENQIG9uIHBvcnQr MQ0KICAqIG5vIFJUQ1AgYXQgYWxsDQoNCm5lZWQgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRo b3NlLiAgSSBsaWtlIGE9cnRjcCB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhvc2UsIEkgdGhp bmsgeW91J3JlIHNheWluZyBleGlzdGVuY2Ugb2YgYT10cmlja2xlIGRpZmZlcmVudGlhdGVzIChv ciB3aGF0ZXZlciB0aGUgdHJpY2tsZSBTRFAsIEkgZm9yZ2V0IHdoYXQgaXQncyBzdXBwb3NlZCB0 byBiZSByaWdodCBub3csIHNvcnJ5KS4NCg0KLWQNCg0KDQoNCg0KRnJvbTog8J+Uk0RhbiBXaW5n IFttYWlsdG86ZHdpbmdAY2lzY28uY29tXQ0KU2VudDogMTMgSmFudWFyeSAyMDE2IDE4OjQwDQpU bzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiBSb21hbiBTaHBvdW50IDxy b21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PjsgaWNlQGlldGYub3Jn PG1haWx0bzppY2VAaWV0Zi5vcmc+OyBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRm Lm9yZz47IE1hcmMgUGV0aXQtSHVndWVuaW4gPG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPG1haWx0 bzptYXJjQHBldGl0LWh1Z3VlbmluLm9yZz4+OyBBcmkgS2Vyw6RuZW4gPGFyaS5rZXJhbmVuQGVy aWNzc29uLmNvbTxtYWlsdG86YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPj47IHNuYW5kYWt1QGNp c2NvLmNvbTxtYWlsdG86c25hbmRha3VAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IFtNTVVTSUNd IFtJY2VdIFNEUCBydGNwIGF0dHJpYnV0ZSB3aXRoIHRyaWNrbGUgSUNFDQoNCg0KT24gMTMtSmFu LTIwMTYgMTE6MzIgYW0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K SGkgRGFuLA0KDQpUaGUgY2FzZSB0aGF0IHJhaXNlZCB0aGUgaXNzdWUgaXMgd2hlbiB0cmlja2xl IElDRSBpcyB1c2VkIOKAkyBhbmQgbm8gcG9ydHMgYXJlIHNpZ25hbGxlZCB0byBiZWdpbiB3aXRo LCBhbmQgdGhlIGM9IGxpbmUgY29udGFpbnMgcG9ydCA5IGFuZCBhIDAuMC4wLjAgYWRkcmVzcy4g SW4gbXkgb3BpbmlvbiB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgUlRDUCBhdHRyaWJ1dGUgaW4g dGhhdCBjYXNlLg0KDQpUaGVuIHlvdSdsbCBuZWVkIGEgTVVTVCB0byBpbmRpY2F0ZSAiTVVTVCBz aWduYWwgdXNpbmcgVHJpY2tsZSIsIHJpZ2h0Pw0KDQotZA0KDQoNCg0KDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCkZyb206IPCflJNEYW4gV2luZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNvbV0N ClNlbnQ6IDEzIEphbnVhcnkgMjAxNiAxNzo1Mw0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRl bHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+DQpDYzogaWNlQGlldGYub3JnPG1h aWx0bzppY2VAaWV0Zi5vcmc+OyBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9y Zz47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBNYXJjIFBldGl0LUh1Z3Vlbmlu IDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZzxtYWlsdG86bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc+ PjsgQXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb208bWFpbHRvOmFyaS5rZXJh bmVuQGVyaWNzc29uLmNvbT4+OyBzbmFuZGFrdUBjaXNjby5jb208bWFpbHRvOnNuYW5kYWt1QGNp c2NvLmNvbT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbSWNlXSBTRFAgcnRjcCBhdHRyaWJ1dGUg d2l0aCB0cmlja2xlIElDRQ0KDQoNCk9uIDEyLUphbi0yMDE2IDAzOjQ4IHBtLCBSb21hbiBTaHBv dW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToN CkggQWxsLA0KDQpDcm9zcy1wb3N0aW5nIHRvIE1NVVNJQywgc2luY2UgdGhpcyBhZmZlY3RzIGJv dGggUkZDIDUyNDViaXMgYW5kIGRyYWZ0LWlldGYtbW11c2ljLWljZS1zaXAtc2RwDQoNClJGQyA1 MjQ1IGFuZCBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcCBjdXJyZW50bHkgc2F5IHRoZSBm b2xsb3dpbmc6DQoNCg0KICAgVGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBhcmUgYWRkZWQgdG8gdGhl IFNEUCBhcyB0aGUgZGVmYXVsdA0KDQogICBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuICBGb3Igc3Ry ZWFtcyBiYXNlZCBvbiBSVFAsIHRoaXMgaXMgZG9uZSBieQ0KDQogICBwbGFjaW5nIHRoZSBJUCBh ZGRyZXNzIGFuZCBwb3J0IG9mIHRoZSBSVFAgY2FuZGlkYXRlIGludG8gdGhlIGMgYW5kIG0NCg0K ICAgbGluZXMsIHJlc3BlY3RpdmVseS4gIElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcgUlRDUCwg aXQgTVVTVCBlbmNvZGUNCg0KICAgdGhlIFJUQ1AgY2FuZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3Ag YXR0cmlidXRlIGFzIGRlZmluZWQgaW4gUkZDIDM2MDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzM2MDU+DQoNCiAgIFtSRkMzNjA1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzNjA1Pl0uICBJZiBSVENQIGlzIG5vdCBpbiB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0 aGF0IHVzaW5nDQoNCiAgIGI9UlM6MCBhbmQgYj1SUjowIGFzIGRlZmluZWQgaW4gUkZDIDM1NTY8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTY+IFtSRkMzNTU2PGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTU2Pl0uDQoNCg0KDQpUaGVyZSBpcyBhbiBvbmdvaW5nIGRp c2N1c3Npb24gd2hldGhlciB0aGUgcnRjcCBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQgaW4gY2FzZSBv ZiB0cmlja2xlIElDRSwgd2hlbiBhbiBvZmZlciBpcyBzZW50IHdpdGhvdXQgY2FuZGlkYXRlIGlu Zm9ybWF0aW9uLCB0aGUgUlRQIHBvcnQgc2V0IHRvIDksIGFuZCB0aGUgUlRQIElQIGFkZHJlc3Mg c2V0IHRvIDAuMC4wLjAuDQoNCg0KDQpFeGFtcGxlOg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhPXJ0Y3A6IDkgSU4gSVA0IDAuMC4wLjANCg0KDQoNCkFjY29yZGluZyB0byBDaHJp c3RlciB0aGlzIGlzIG5vdCBuZWVkZWQsIGFzIHRoZXJlIGlzIG5vIGNhbmRpZGF0ZSB0byDigJxl bmNvZGXigJ0sIGFuZCBpdCBhbHNvIGNvbmZsaWN0cyB3aXRoIHRoZSBzdWdnZXN0ZWQgbWVjaGFu aXNtIGZvciBpbmRpY2F0aW5nIGV4Y2x1c2l2ZSBzdXBwb3J0IG9mIFJUUC9SVENQIG11bHRpcGxl eGluZyAoZHJhZnQtaG9sbWJlcmctbW11c2ljLW11eC1leGNsdXNpdmUpLg0KDQoNCg0KRnVydGhl cm1vcmUsIGFjY29yZGluZyB0byBzZWN0aW9uIDIuMSBvZiBSRkMgMzYwNToNCg0KDQoNCiAgIFRo ZSBSVENQIGF0dHJpYnV0ZSBpcyB1c2VkIHRvIGRvY3VtZW50IHRoZSBSVENQIHBvcnQgdXNlZCBm b3IgbWVkaWENCg0KICAgc3RyZWFtLCB3aGVuIHRoYXQgcG9ydCBpcyBub3QgdGhlIG5leHQgaGln aGVyIChvZGQpIHBvcnQgbnVtYmVyDQoNCiAgIGZvbGxvd2luZyB0aGUgUlRQIHBvcnQgZGVzY3Jp YmVkIGluIHRoZSBtZWRpYSBsaW5lLg0KDQpSRkMgNTI0NSBvdmVyd3JpdGVzIHRoZSBndWlkZWxp bmUgZnJvbSBSRkMgMzYwNSBhbmQgc3RhdGVzIHRoYXQgU0RQIHJ0Y3AgYXR0cmlidXRlIE1VU1Qg YmUgcHJlc2VudCBldmVuIHdoZW4gUlRDUCBkZWZhdWx0IGNhbmRpZGF0ZSBpcyBub3QgcHJlc2Vu dCBvciB3aGVuIFJUQ1AgY2FuZGlkYXRlIGlzIHVzaW5nIHBvcnQgcnRwKzEsIHdoaWNoIGlzIGN1 cnJlbnRseSB0aGUgdGhlIG1vc3QgY29tbW9uIHNjZW5hcmlvIHNpbmNlIHNlcXVlbnRpYWwgcG9y dCBpcyB0eXBpY2FsbHkgYWxsb2NhdGVkIGZvciBSVENQIGJ5IFRVUk4uDQoNCkkgc3VnZ2VzdCBj aGFuZ2luZyB0aGUgbGFuZ3VhZ2UgaW4gc2VjdGlvbiA0LjIgb2YgZHJhZnQtaWV0Zi1tbXVzaWMt aWNlLXNpcC1zZHAgdG86DQoNCg0KICAgVGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBhcmUgYWRkZWQg dG8gdGhlIFNEUCBhcyB0aGUgZGVmYXVsdA0KDQogICBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuICBG b3Igc3RyZWFtcyBiYXNlZCBvbiBSVFAsIHRoaXMgaXMgZG9uZSBieQ0KDQogICBwbGFjaW5nIHRo ZSBJUCBhZGRyZXNzIGFuZCBwb3J0IG9mIHRoZSBSVFAgY2FuZGlkYXRlIGludG8gdGhlIGMgYW5k IG0NCg0KICAgbGluZXMsIHJlc3BlY3RpdmVseS4gIElmIHRoZSBhZ2VudCBpcyB1dGlsaXppbmcg UlRDUCBhbmQgaWYgUlRDUA0KDQogICBjYW5kaWRhdGUgaXMgcHJlc2VudCBhbmQgbm90IGVxdWFs IHRvIHRoZSBzYW1lIGFkZHJlc3MgYW5kDQoNCiAgIHRoZSBuZXh0IGhpZ2hlciBwb3J0IG51bWJl ciBvZiB0aGUgUlRQIGNhbmRpZGF0ZSwNCg0KT25lIHJlYXNvbiBmb3IgdGhlIHRleHQgaW4gUkZD NTI0NSAodG8gcmVxdWlyZSBhPXJ0Y3AsIGFsd2F5cykgaXMgdG8gZGVzdHJveSB0aGUgInBvcnQg KyAxIiBhc3N1bXB0aW9uIG9mIFJUQ1A7IGl0IHNpbXBseSBicmVha3MgdG9vIG1hbnkgdGltZXMg d2l0aCBOQVQuICBTbywgSSB3b3VsZCBnbyBmb3IgeW91ciBwcm9wb3NlZCB0ZXh0IGlmIHlvdSBy ZW1vdmVkICJhbmQgbm90IGVxdWFsIHRvIHRoZSBzYW1lIGFkZHJlc3MgYW5kIG5leHQtaGlnaGVy IHBvcnQgbnVtYmVyIG9mIHRoZSBSVFAgY2FuZGlkYXRlIjsgdGhhdCBpcywgaWYgeW91J3JlIHVz aW5nIFJUQ1Agb24gYW55IGRpZmZlcmVudCBwb3J0LCB0aGUgcG9ydCBudW1iZXIgaGFzIHRvIGJl IGV4cGxpY2l0bHkgc2lnbmFsZWQgd2l0aCBhPXJ0Y3AuDQoNCi1kDQoNCg0KDQoNCg0KDQoNCnRo ZSBhZ2VudCBNVVNUIGVuY29kZQ0KDQogICB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9 cnRjcCBhdHRyaWJ1dGUgYXMgZGVmaW5lZCBpbiBSRkMgMzYwNTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMzYwNT4NCg0KICAgW1JGQzM2MDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzM2MDU+XS4gIElmIFJUQ1AgaXMgbm90IGluIHVzZSwgdGhlIGFnZW50IE1VU1Qgc2ln bmFsIHRoYXQgdXNpbmcNCg0KICAgYj1SUzowIGFuZCBiPVJSOjAgYXMgZGVmaW5lZCBpbiBSRkMg MzU1NjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1Nj4gW1JGQzM1NTY8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTY+XS4NCg0KUmVnYXJkcywNCl9fX19fX19fX19f X18NClJvbWFuIFNocG91bnQNCg0KT24gVHVlLCBKYW4gMTIsIDIwMTYgYXQgODowMiBBTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KUkZDIDUyNDUgc2F5 cyB0aGUgZm9sbG93aW5nOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg4oCcSWYg dGhlIGFnZW50IGlzIHV0aWxpemluZyBSVENQLCBpdCBNVVNUIGVuY29kZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdGhlIFJUQ1AgY2FuZGlkYXRlIHVzaW5nIHRoZSBhPXJ0Y3AgYXR0 cmlidXRlIGFzIGRlZmluZWQgaW4gUkZDIDM2MDUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUkZDMzYwNV0u4oCdDQoNClRoZXJlIGlzIGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiB3aGV0 aGVyIHRoZSBydGNwIGF0dHJpYnV0ZSBpcyByZXF1aXJlZCBpbiBjYXNlIG9mIHRyaWNrbGUgSUNF LCB3aGVuIGFuIG9mZmVyIGlzIHNlbnQgd2l0aG91dCBjYW5kaWRhdGUgaW5mb3JtYXRpb24sIHRo ZSBSVFAgcG9ydCBzZXQgdG8gOSwgYW5kIHRoZSBSVFAgSVAgYWRkcmVzcyBzZXQgdG8gMC4wLjAu MC4NCg0KRXhhbXBsZToNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhPXJ0Y3A6IDkg SU4gSVA0IDAuMC4wLjANCg0KSW4gbXkgb3BpbmlvbiB0aGlzIGlzIG5vdCBuZWVkZWQsIGFzIHRo ZXJlIGlzIG5vIGNhbmRpZGF0ZSB0byDigJxlbmNvZGXigJ0sIGFuZCBpdCBhbHNvIGNvbmZsaWN0 cyB3aXRoIHRoZSBzdWdnZXN0ZWQgbWVjaGFuaXNtIGZvciBpbmRpY2F0aW5nIGV4Y2x1c2l2ZSBz dXBwb3J0IG9mIFJUUC9SVENQIG11bHRpcGxleGluZyAoZHJhZnQtaG9sbWJlcmctbW11c2ljLW11 eC1leGNsdXNpdmUpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWNlIG1haWxpbmcgbGlzdA0KSWNlQGll dGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ljZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp Yw0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37D16AE3ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlNlZ29lIFVJIFN5bWJvbCI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsN CgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjIwODA2NjYyNzE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi05MDY4MzM0OCA1NjEzMDU2NDYgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0 ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU0LjBwdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5 MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjYuMHB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoxNjIuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTk4LjBwdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjI3MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDYuMHB0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzQyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+TXkgc3VnZ2VzdGlvbiBvZiBsYWNrIG9mIGE9cnRjcCBpczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPklmIGFuIFJUUCBub24tOSBwb3J0IGlzIHByb3ZpZGVkLCB0aGUgUlRDUCBw b3J0IGlzIFJUUCYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JZiBhbiBS VFAgOSAoZGlzYWJsZWQpIHBvcnQgaXMgcHJvdmlkZWQsIHRoZSBSVENQIHBvcnQgaXMgaW1wbGlj aXRseSBhbHNvIGRpc2FibGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGVyZSBhcmUgb3RoZXIgbWVjaGFuaXNtcyB0byBpbmRpY2F0ZSB0aGF0IFJUQ1Agd29u4oCZ dCBiZSB1c2VkIHRvIGJlZ2luIHdpdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LHNh bnMtc2VyaWYiPvCflJM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGFuIFdp bmcgW21haWx0bzpkd2luZ0BjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTMgSmFudWFy eSAyMDE2IDE4OjUxPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9tYW4gU2hwb3Vu dCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7OyBpY2VAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9y ZzsgTWFyYyBQZXRpdC1IdWd1ZW5pbiAmbHQ7bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmcmZ3Q7OyBB cmkgS2Vyw6RuZW4gJmx0O2FyaS5rZXJhbmVuQGVyaWNzc29uLmNvbSZndDs7IHNuYW5kYWt1QGNp c2NvLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gW0ljZV0gU0RQIHJ0Y3Ag YXR0cmlidXRlIHdpdGggdHJpY2tsZSBJQ0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIDEzLUphbi0yMDE2IDExOjQy IGFtLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsg d3JvdGU6DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFtIG5vdCBzdXJl IEkgdW5kZXJzdG9vZCB5b3UgbGFzdCBpbnB1dCA6KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XaXRoIGV4aXN0aW5nIHByb3Bvc2VkIG5ldyB0ZXh0LCBsYWNrIG9mIGE9cnRjcCBjb3VsZCBi ZSBpbnRlcnByZXRlZCB0byBtZWFuOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgKiBSVENQIG9uIHBvcnQmIzQzOzE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAqIG5vIFJU Q1AgYXQgYWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPm5lZWQgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRob3NlLiAmbmJzcDtJIGxpa2Ug YT1ydGNwIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aG9zZSwgSSB0aGluayB5b3UncmUgc2F5 aW5nIGV4aXN0ZW5jZSBvZiBhPXRyaWNrbGUgZGlmZmVyZW50aWF0ZXMgKG9yIHdoYXRldmVyIHRo ZSB0cmlja2xlIFNEUCwgSSBmb3JnZXQgd2hhdCBpdCdzIHN1cHBvc2VkIHRvIGJlIHJpZ2h0IG5v dywgc29ycnkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29l IFVJIFN5bWJvbCZxdW90OyxzYW5zLXNlcmlmIj7wn5STPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkRhbg0KIFdpbmcgWzxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNjby5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpkd2luZ0BjaXNjby5jb208L3NwYW4+ PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjEzIEphbnVhcnkgMjAxNiAxODo0MDxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRl bHVyaXguY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yb21hbkB0ZWx1cml4LmNvbTwv c3Bhbj48L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aWNlQGlldGYub3JnPC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+Ow0KIE1h cmMgUGV0aXQtSHVndWVuaW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJjQHBldGl0LWh1Z3Vlbmlu Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc8 L3NwYW4+PC9hPiZndDs7IEFyaSBLZXLDpG5lbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyaS5rZXJh bmVuQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YXJpLmtlcmFuZW5A ZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c25hbmRha3VAY2lzY28uY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zbmFuZGFrdUBjaXNjby5jb208L3NwYW4+PC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5SZTogW01NVVNJQ10gW0ljZV0gU0RQIHJ0Y3AgYXR0cmlidXRlIHdpdGggdHJp Y2tsZSBJQ0U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIDEzLUph bi0yMDE2IDExOjMyIGFtLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhbiw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjYXNlIHRoYXQg cmFpc2VkIHRoZSBpc3N1ZSBpcyB3aGVuIHRyaWNrbGUgSUNFIGlzIHVzZWQg4oCTIGFuZCBubyBw b3J0cyBhcmUgc2lnbmFsbGVkIHRvIGJlZ2luIHdpdGgsIGFuZCB0aGUgYz0gbGluZSBjb250YWlu cyBwb3J0IDkgYW5kIGEgMC4wLjAuMCBhZGRyZXNzLg0KIEluIG15IG9waW5pb24gdGhlcmUgaXMg bm8gbmVlZCBmb3IgdGhlIFJUQ1AgYXR0cmlidXRlIGluIHRoYXQgY2FzZS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiB5b3UnbGwg bmVlZCBhIE1VU1QgdG8gaW5kaWNhdGUgJnF1b3Q7TVVTVCBzaWduYWwgdXNpbmcgVHJpY2tsZSZx dW90OywgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1kPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssc2Fu cy1zZXJpZiI+8J+Ukzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EYW4NCiBX aW5nIFs8YSBocmVmPSJtYWlsdG86ZHdpbmdAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5tYWlsdG86ZHdpbmdAY2lzY28uY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4xMyBKYW51YXJ5IDIw MTYgMTc6NTM8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cm9tYW5AdGVsdXJpeC5jb208 L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppY2VAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmljZUBpZXRmLm9yZzwvc3Bhbj48L2E+OzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW11 c2ljQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tbXVzaWNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjsNCiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7OyBNYXJjIFBldGl0LUh1 Z3VlbmluICZsdDs8YSBocmVmPSJtYWlsdG86bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPC9zcGFuPjwvYT4m Z3Q7Ow0KIEFyaSBLZXLDpG5lbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyaS5rZXJhbmVuQGVyaWNz c29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YXJpLmtlcmFuZW5AZXJpY3Nzb24u Y29tPC9zcGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c25hbmRha3VAY2lzY28uY29tIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5zbmFuZGFrdUBjaXNjby5jb208L3NwYW4+PC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5SZTogW01NVVNJQ10gW0ljZV0gU0RQIHJ0Y3AgYXR0cmlidXRlIHdpdGggdHJpY2tsZSBJQ0U8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCk9uIDEyLUphbi0yMDE2IDAzOjQ4IHBtLCBSb21hbiBTaHBvdW50ICZsdDs8 YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnJvbWFuQHRlbHVyaXguY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkggQWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNyb3NzLXBvc3RpbmcgdG8gTU1VU0lDLCBzaW5j ZSB0aGlzIGFmZmVjdHMgYm90aCBSRkMgNTI0NWJpcyBhbmQgZHJhZnQtaWV0Zi1tbXVzaWMtaWNl LXNpcC1zZHA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+UkZDIDUyNDUgYW5kJm5ic3A7PC9zcGFuPmRyYWZ0LWlldGYtbW11 c2ljLWljZS1zaXAtc2RwIGN1cnJlbnRseSZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+c2F5IHRoZSBm b2xsb3dpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9 IndoaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDsmbmJzcDsgVGhlIGRlZmF1bHQgY2FuZGlkYXRl cyBhcmUgYWRkZWQgdG8gdGhlIFNEUCBhcyB0aGUgZGVmYXVsdDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiBmb3IgbWVkaWEuJm5ic3A7IEZvciBzdHJlYW1z IGJhc2VkIG9uIFJUUCwgdGhpcyBpcyBkb25lIGJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IHBsYWNpbmcgdGhlIElQIGFkZHJlc3MgYW5kIHBvcnQgb2YgdGhlIFJUUCBjYW5k aWRhdGUgaW50byB0aGUgYyBhbmQgbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBsaW5lcywgcmVzcGVjdGl2ZWx5LiZuYnNwOyA8Yj5JZiB0aGUgYWdlbnQgaXMgdXRpbGl6aW5n IFJUQ1AsIGl0IE1VU1QgZW5jb2RlPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxiPiZuYnNw OyZuYnNwOyB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1dGUgYXMg ZGVmaW5lZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQyAzNjA1PC9zcGFu PjwvYT48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7IFs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFyZ2V0PSJfYmxhbmsiIHRp dGxlPSImcXVvdDtSZWFsIFRpbWUgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgYXR0cmlidXRlIGlu IFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkmcXVvdDsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPlJGQzM2MDU8L3NwYW4+PC9hPl0uPC9iPiZuYnNwOyBJZiBSVENQIGlzIG5v dCBpbiB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVzaW5nPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGI9UlM6MCBhbmQgYj1SUjowIGFzIGRlZmluZWQgaW4gPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTYiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5SRkMgMzU1Njwvc3Bhbj48L2E+IFs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1NiIgdGFyZ2V0PSJfYmxhbmsiIHRp dGxlPSImcXVvdDtTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIEJhbmR3aWR0aCBN b2RpZmllcnMgZm9yIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBCYW5kd2lkdGgmcXVvdDsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQzM1NTY8L3NwYW4+PC9hPl0uPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24g d2hldGhlciB0aGUgcnRjcCBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQgaW4gY2FzZSBvZiB0cmlja2xl IElDRSwgd2hlbiBhbiBvZmZlciBpcyBzZW50IHdpdGhvdXQgY2FuZGlkYXRlIGluZm9ybWF0aW9u LCB0aGUgUlRQIHBvcnQgc2V0IHRvIDksIGFuZCB0aGUgUlRQIElQIGFkZHJlc3Mgc2V0IHRvIDAu MC4wLjAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FeGFtcGxl Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2E9cnRjcDogOSBJTiBJUDQg MC4wLjAuMDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWNjb3Jk aW5nIHRvIENocmlzdGVyIHRoaXMgaXMgbm90IG5lZWRlZCwgYXMgdGhlcmUgaXMgbm8gY2FuZGlk YXRlIHRvIOKAnGVuY29kZeKAnSwgYW5kIGl0IGFsc28gY29uZmxpY3RzIHdpdGggdGhlIHN1Z2dl c3RlZCBtZWNoYW5pc20gZm9yIGluZGljYXRpbmcgZXhjbHVzaXZlIHN1cHBvcnQgb2YgUlRQL1JU Q1AgbXVsdGlwbGV4aW5nIChkcmFmdC1ob2xtYmVyZy1tbXVzaWMtbXV4LWV4Y2x1c2l2ZSkuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZ1cnRoZXJtb3JlLCBhY2NvcmRpbmcgdG8gc2Vj dGlvbiAyLjEgb2YgUkZDIDM2MDU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBSVENQIGF0dHJpYnV0ZSBpcyB1c2VkIHRv IGRvY3VtZW50IHRoZSBSVENQIHBvcnQgdXNlZCBmb3IgbWVkaWE8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgc3RyZWFtLCB3aGVuIHRoYXQgcG9ydCBpcyBub3QgdGhlIG5leHQg aGlnaGVyIChvZGQpIHBvcnQgbnVtYmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGZvbGxvd2luZyB0aGUgUlRQIHBvcnQgZGVzY3JpYmVkIGluIHRoZSBtZWRpYSBsaW5lLjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SRkMgNTI0 NSBvdmVyd3JpdGVzIHRoZSBndWlkZWxpbmUgZnJvbSBSRkMgMzYwNSBhbmQgc3RhdGVzIHRoYXQg U0RQIHJ0Y3AgYXR0cmlidXRlIE1VU1QgYmUgcHJlc2VudCBldmVuIHdoZW4gUlRDUCBkZWZhdWx0 IGNhbmRpZGF0ZSBpcyBub3QgcHJlc2VudCBvciB3aGVuIFJUQ1AgY2FuZGlkYXRlIGlzIHVzaW5n IHBvcnQgcnRwJiM0MzsxLCB3aGljaCBpcyBjdXJyZW50bHkgdGhlIHRoZSBtb3N0IGNvbW1vbiBz Y2VuYXJpbw0KIHNpbmNlIHNlcXVlbnRpYWwgcG9ydCBpcyB0eXBpY2FsbHkgYWxsb2NhdGVkIGZv ciBSVENQIGJ5IFRVUk4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgc3VnZ2VzdCBjaGFuZ2luZyB0aGUgbGFuZ3VhZ2UgaW4gc2VjdGlv biA0LjIgb2YmbmJzcDtkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcCB0bzo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDsmbmJz cDsgVGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBhcmUgYWRkZWQgdG8gdGhlIFNEUCBhcyB0aGUgZGVm YXVsdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiBmb3Ig bWVkaWEuJm5ic3A7IEZvciBzdHJlYW1zIGJhc2VkIG9uIFJUUCwgdGhpcyBpcyBkb25lIGJ5PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHBsYWNpbmcgdGhlIElQIGFkZHJlc3Mg YW5kIHBvcnQgb2YgdGhlIFJUUCBjYW5kaWRhdGUgaW50byB0aGUgYyBhbmQgbTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBsaW5lcywgcmVzcGVjdGl2ZWx5LiZuYnNwOyA8Yj5J ZiB0aGUgYWdlbnQgaXMgdXRpbGl6aW5nIFJUQ1AgYW5kIGlmIFJUQ1AgPC9iPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y2FuZGlkYXRlIGlzIHByZXNlbnQgYW5kIG5vdCBlcXVhbCB0byB0aGUgc2FtZSBhZGRy ZXNzIGFuZCA8L2I+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnBy ZS13cmFwIj48Yj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUgbmV4dCBoaWdoZXIgcG9ydCBudW1iZXIg b2YgdGhlIFJUUCBjYW5kaWRhdGUsIDwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgcmVhc29uIGZv ciB0aGUgdGV4dCBpbiBSRkM1MjQ1ICh0byByZXF1aXJlIGE9cnRjcCwgYWx3YXlzKSBpcyB0byBk ZXN0cm95IHRoZSAmcXVvdDtwb3J0ICYjNDM7IDEmcXVvdDsgYXNzdW1wdGlvbiBvZiBSVENQOyBp dCBzaW1wbHkgYnJlYWtzIHRvbyBtYW55IHRpbWVzIHdpdGggTkFULiAmbmJzcDtTbywgSSB3b3Vs ZCBnbyBmb3IgeW91ciBwcm9wb3NlZCB0ZXh0IGlmIHlvdSByZW1vdmVkICZxdW90O2FuZCBub3Qg ZXF1YWwgdG8gdGhlIHNhbWUgYWRkcmVzcw0KIGFuZCBuZXh0LWhpZ2hlciBwb3J0IG51bWJlciBv ZiB0aGUgUlRQIGNhbmRpZGF0ZSZxdW90OzsgdGhhdCBpcywgaWYgeW91J3JlIHVzaW5nIFJUQ1Ag b24gYW55IGRpZmZlcmVudCBwb3J0LCB0aGUgcG9ydCBudW1iZXIgaGFzIHRvIGJlIGV4cGxpY2l0 bHkgc2lnbmFsZWQgd2l0aCBhPXJ0Y3AuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3Jh cCI+PGI+dGhlIGFnZW50IE1VU1QgZW5jb2RlPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxi PiZuYnNwOyZuYnNwOyB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1 dGUgYXMgZGVmaW5lZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MzYwNSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQyAzNjA1 PC9zcGFuPjwvYT48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7IFs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFyZ2V0PSJfYmxh bmsiIHRpdGxlPSImcXVvdDtSZWFsIFRpbWUgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgYXR0cmli dXRlIGluIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkmcXVvdDsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPlJGQzM2MDU8L3NwYW4+PC9hPl0uPC9iPiZuYnNwOyBJZiBSVENQ IGlzIG5vdCBpbiB1c2UsIHRoZSBhZ2VudCBNVVNUIHNpZ25hbCB0aGF0IHVzaW5nPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGI9UlM6MCBhbmQgYj1SUjowIGFzIGRlZmluZWQg aW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTYiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5SRkMgMzU1Njwvc3Bhbj48L2E+IFs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1NiIgdGFyZ2V0PSJfYmxh bmsiIHRpdGxlPSImcXVvdDtTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIEJhbmR3 aWR0aCBNb2RpZmllcnMgZm9yIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBCYW5kd2lkdGgm cXVvdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQzM1NTY8L3NwYW4+PC9hPl0uPG86 cD48L286cD48L3ByZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFuIDEy LCAyMDE2IGF0IDg6MDIgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9zcGFuPjwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIj5IaSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlJGQyA1MjQ1IHNheXMgdGhlIGZvbGxvd2luZzo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDvigJxJZiB0aGUgYWdlbnQgaXMgdXRpbGl6aW5nIFJUQ1AsIGl0IE1V U1QgZW5jb2RlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgUlRD UCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1dGUgYXMgZGVmaW5lZCBpbiBSRkMg MzYwNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkZJIj5bUkZDMzYwNV0u4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRkkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBp cyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gd2hldGhlciB0aGUgcnRjcCBhdHRyaWJ1dGUgaXMgcmVx dWlyZWQgaW4gY2FzZSBvZiB0cmlja2xlIElDRSwgd2hlbiBhbiBvZmZlciBpcyBzZW50IHdpdGhv dXQgY2FuZGlkYXRlIGluZm9ybWF0aW9uLCB0aGUgUlRQIHBvcnQgc2V0IHRvIDksIGFuZCB0aGUg UlRQIElQIGFkZHJlc3Mgc2V0IHRvIDAuMC4wLjAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5FeGFt cGxlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGE9cnRjcDogOSBJTiBJUDQgMC4wLjAuMDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SW4gbXkgb3BpbmlvbiB0aGlzIGlzIG5vdCBuZWVkZWQsIGFzIHRoZXJl IGlzIG5vIGNhbmRpZGF0ZSB0byDigJxlbmNvZGXigJ0sIGFuZCBpdCBhbHNvIGNvbmZsaWN0cyB3 aXRoIHRoZSBzdWdnZXN0ZWQgbWVjaGFuaXNtIGZvciBpbmRpY2F0aW5nIGV4Y2x1c2l2ZSBzdXBw b3J0IG9mIFJUUC9SVENQIG11bHRpcGxleGluZyAoZHJhZnQtaG9sbWJlcmctbW11c2ljLW11eC1l eGNsdXNpdmUpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Q2hyaXN0 ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJY2Ug bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+SWNlQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWNlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bW11 c2ljQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tbXVzaWNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37D16AE3ESESSMB209erics_-- From nobody Thu Jan 14 06:33:00 2016 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 B0A0A1ACE60; Thu, 14 Jan 2016 06:32:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> Date: Thu, 14 Jan 2016 06:32:57 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:32:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-12.txt Pages : 96 Date : 2016-01-14 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. Typically media associated with individual media descriptions ("m=" lines) represent RTP sessions and are thus carried over individual underlying transport layer flows. For scenarios where SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions, it is required to understand the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. This specification also categorizes the existing SDP attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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 Thu Jan 14 06:34:33 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0131B2DEF; Thu, 14 Jan 2016 06:34:31 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvyArTA_ktjc; Thu, 14 Jan 2016 06:34:26 -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 66FC61B2E00; Thu, 14 Jan 2016 06:34:20 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id k1so280878070vkb.2; Thu, 14 Jan 2016 06:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GgGjyRB5eIZ35387qsb+Cygc/zwmkPKba8DJWnFgpkE=; b=NOrdPTtjzJBDxGfMKHDS5kh/qEC2Fx6ntTuw50RUMFEFdLw5+itrX4LXtYC7cX7j2Q k5h/UafkNAUKv7vM36aX9TEoePL4ZS3/J7AGjHDV17efZeeRfxt4sS/JwZ3EGXQSr/cf yj428vaIRPF4ui9emlyynu0mPR6go9mKX9KbUNw6n0q3uTwyh7lqDJ+5XPzdfgd8NEfr O1XNjt+4Ek+4EhSCuZ7RJf+6Dvz6YmqSJW6ht2SclcxcJAMPJw0mbBZcE4V1xreXxAWk 5J/K+T5jgE8kFGm6u2iLIsUWmt80tIK4UfZYSPJsjk7ICmub6167ieNiE9hHDF0gi4hK 9+Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GgGjyRB5eIZ35387qsb+Cygc/zwmkPKba8DJWnFgpkE=; b=gpDgpKeymAUGgHNTc0giMZHSaVw+KvnafH67zLfvgKXZ8vV8y2P3NCXOvgClcQaLlW mrfQg5Bf05vluAQj9OrkOTLmWCIL78blBxlFVX7IFwh6XrbiZkXkfnhj66RNYUAW6J7V bnFFkMb5Bdl2Unp6Vchfnq6KBKclo1+yWthdgTMRXZbxl0V7krorRvsHQ+HBjITD9chs tOK3y5sSK3mEFHkerDjkafQNUtedTtvkKLc1seAdPhbCsZgi6pmNjTR9bpK4DqfeR+Hu W+Gh/VZ6F66g5ky4FaUMWYyNXSQLs0iZcxhVQu6Iplr+H6XoYd7myTt1v+6MZi5l1lJ/ j4QA== X-Gm-Message-State: ALoCoQliL8gBxZUuqxnG6CJCuuHBW/6Rt+8l/kTsQ53vRKXPBLJVJs6MuT7KuZuJBaQnOByYILIenaz1HswG0obeJiEU/RiSMw== MIME-Version: 1.0 X-Received: by 10.31.54.23 with SMTP id d23mr3364191vka.25.1452782059541; Thu, 14 Jan 2016 06:34:19 -0800 (PST) Received: by 10.31.106.130 with HTTP; Thu, 14 Jan 2016 06:34:19 -0800 (PST) In-Reply-To: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> Date: Thu, 14 Jan 2016 06:34:19 -0800 Message-ID: From: Suhas Nandakumar To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a114385d898573705294c2e15 Archived-At: Cc: mmusic WG , i-d-announce@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:34:32 -0000 --001a114385d898573705294c2e15 Content-Type: text/plain; charset=UTF-8 Hello All This version fixes couple of ID nits and updates the references to the latest RFCs. Cheers suhas On Thu, Jan 14, 2016 at 6:32 AM, 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 > Working Group of the IETF. > > Title : A Framework for SDP Attributes when Multiplexing > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-12.txt > Pages : 96 > Date : 2016-01-14 > > Abstract: > The Session Description Protocol (SDP) provides mechanisms to > describe attributes of multimedia sessions and of individual media > streams (e.g., Real-time Transport Protocol (RTP) sessions) within a > multimedia session. Typically media associated with individual media > descriptions ("m=" lines) represent RTP sessions and are thus carried > over individual underlying transport layer flows. For scenarios > where SDP is used to negotiate the usage of single 5-tuple for > sending and receiving media associated with multiple media > descriptions, it is required to understand the semantic implications > of the SDP attributes associated with the RTP Media Streams > multiplexed over a single underlying transport layer flow. > > The purpose of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. This > specification also categorizes the existing SDP attributes based on > the framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114385d898573705294c2e15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

This version fixes coup= le of ID nits and updates the references to the latest RFCs.

=

Cheers
suhas

On Thu, Jan 14, 2016 at 6:32 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-14

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 Typically media associated with indi= vidual media
=C2=A0 =C2=A0descriptions ("m=3D" lines) represent RTP sessions a= nd are thus carried
=C2=A0 =C2=A0over individual underlying transport layer flows.=C2=A0 For sc= enarios
=C2=A0 =C2=A0where SDP is used to negotiate the usage of single 5-tuple for=
=C2=A0 =C2=A0sending and receiving media associated with multiple media
=C2=A0 =C2=A0descriptions, it is required to understand the semantic implic= ations
=C2=A0 =C2=A0of the SDP attributes associated with the RTP Media Streams =C2=A0 =C2=A0multiplexed over a single underlying transport layer flow.

=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-mmusic-sdp-mux-attributes/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft= -ietf-mmusic-sdp-mux-attributes-12

A diff from the previous version is available at:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-mmusic-sdp-mux-attributes-12


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

--001a114385d898573705294c2e15-- From nobody Thu Jan 14 08:05:10 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993B31A0273 for ; Thu, 14 Jan 2016 08:05:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gONgE7F0MBEf for ; Thu, 14 Jan 2016 08:05:05 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3A71A0406 for ; Thu, 14 Jan 2016 08:05:04 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-34-5697c72fd70c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E7.BB.02707.F27C7965; Thu, 14 Jan 2016 17:05:03 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.202]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Thu, 14 Jan 2016 17:05:02 +0100 From: Bo Burman To: Suhas Nandakumar , Christian Groves Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-11.txt Thread-Index: AQHRR1C5EraQxzVw7UCFc1ulc6vMgJ7sA7uAgAF1cgCAAAxCAIANti7Q Date: Thu, 14 Jan 2016 16:05:01 +0000 Message-ID: References: <20160105003335.29488.57587.idtracker@ietfa.amsl.com> <568C4A12.8050707@nteczone.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E920D0FESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7hK7+8elhBo9eCll8ed/IYjF1+WMW i51zO5gdmD12zrrL7rFkyU8mjxXnZ7IEMEdx2aSk5mSWpRbp2yVwZUz7eYmtYMsGxooV158y NjDeWc3YxcjJISFgIrF69QtmCFtM4sK99WxdjFwcQgKHGSVmnNrKBOEsYZTYdX8SK0gVm4CG xPwdd8G6RQTiJJ7c3s8GYjMLyEtcWLKGCcQWFvCV+NZylA2iJkCi9dQl9i5GDiDbTeLPKn2Q MIuAqsSSxmVgY3iByvc2rWKF2PWRUWL1rNUsIAlOgUCJh5cWgc1kFJCVuP/9HgvELnGJW0/m M0FcLSCxZM95qA9EJV4+/scKsktCQFFieb8ciMkskC+xcKMlxCpBiZMzn7BMYBSdhWTQLISq WUiqIMKaEut36UNUK0pM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+nl5e askmRmAEHtzy22AH48vnjocYBTgYlXh4DfinhwmxJpYVV+YeYpTgYFYS4d14ECjEm5JYWZVa lB9fVJqTWnyIUZqDRUmcN0mmMUxIID2xJDU7NbUgtQgmy8TBKdXA6BBhe8DlrmWohY7yhEzN O/ca1GIknbv6HS21PNh9d86q4Nh5XDhk5ZV1DDEZCkdnVjHaMGV861vRv2JTE5t8vVjGmYui 5SU+S76XRnF06GqscWh4FV/JrszkWDI1IJVP/SXb4lzdXTmfCv6unDhf1/6H2rP7l8yCslh1 XM9sfrOQ6eU2+RwlluKMREMt5qLiRACeQ7U5vAIAAA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 16:05:08 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E920D0FESESSMB105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5sZXNzIHRoZXJlIGFyZSBvYmplY3Rpb25zIG9yIGZ1cnRoZXIgY29tbWVudHMgZnJvbSB0aGUg Z3JvdXAsIEkgY29uY2x1ZGUgdGhhdCBubyBkb2N1bWVudCBjaGFuZ2VzIGFyZSByZXF1aXJlZCBv biB0aGlzIHRvcGljLg0KDQovQm8NCk1NVVNJQyBjby1jaGFpcg0KDQpGcm9tOiBtbXVzaWMgW21h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1aGFzIE5hbmRha3Vt YXINClNlbnQ6IGRlbiA2IGphbnVhcmkgMjAxNiAwMDo0MA0KVG86IENocmlzdGlhbiBHcm92ZXMN CkNjOiBtbXVzaWMgV0cNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTEudHh0DQoNClRoYW5rcyBDaHJpc3RpYW4g Zm9yIGNoZWNraW5nIG9uIHRoaXMuDQoNCkFsc28gcmVnYXJkaW5nIHRoZSB1cGRhdGVzIHRvIHRo ZSBkb2N1bWVudCwgSSB3YXMgdGhpbmtpbmcgb2Ygbm90IGFkZGluZyB0aGVzZSBhdHRyaWJ1dGVz IHRvIHRoZSBkcmFmdC4gU2luY2UgdGhlIElBTkEgc2VjdGlvbiBzYXlzLCBmb3IgYWxsIHRoZSBh dHRyaWJ1dGVzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IHRoYXQgZG9lc24ndCBoYXMgdGhlIGNhdGVn b3J5IGFzc2lnbmVkIGJ5IHRoZSBNVVggZHJhZnQsIElBTkEgc2hvdWxkIGFzc2lnbiB0aGUgY2F0 ZWdvcnkgYXMgVEJELg0KDQpwbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhpcyB3b3JrcyBhcyB3ZWxs DQoNCkNoZWVycw0KU3VoYXMNCg0KDQpPbiBUdWUsIEphbiA1LCAyMDE2IGF0IDI6NTYgUE0sIENo cmlzdGlhbiBHcm92ZXMgPENocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPG1haWx0bzpDaHJp c3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbT4+IHdyb3RlOg0KSGVsbG8gU3VoYXMsDQoNCk15IHJl Y29sbGVjdGlvbiBpcyB0aGF0IFJGQzI4NDggd2hpY2ggZGVmaW5lcyB0aGUgYXR0cmlidXRlcyBk b2Vzbid0IGFjdHVhbGx5IHJlc3VsdCBpbiBhbiBSVFAgbWVkaWEgZmxvdy4gUElOVCB1c2VzIFNJ UC9TRFAgdG8gdHJpZ2dlciBhIGdhdGV3YXkgdG8gZG8gc29tZXRoaW5nIG9uIHRoZSBHU1ROIHNp ZGUuIEJhc2ljYWxseSBpdHMgdXNlIHdpdGggbXVsdGlwbGV4aW5nIHNob3VsZCBiZSAiTm90IFJl Y29tbWVuZGVkIi4gQXMgdGhlIGRyYWZ0IHRleHQgYWxyZWFkeSBzYXlzIHRoYXQgZm9yICJUQkQi IGltcGxlbWVudGF0aW9ucyBzaG91bGQgdHJlYXQgaXQgYXMgIm5vdCByZWNvbW1lbmRlZCIsIGl0 cyBwcm9iYWJseSBPSyB0byBsYWJlbCB0aGUgYXR0cmlidXRlcyBhcyBUQkQuDQoNClJlZ2FyZHMs IENocmlzdGlhbg0KDQpPbiA1LzAxLzIwMTYgMTE6MzkgQU0sIFN1aGFzIE5hbmRha3VtYXIgd3Jv dGU6DQpIZWxsbyBBbGwNCg0KICBUaGlzIHZlcnNpb24gaW5jb3Jwb3JhdGVzIGNvbW1lbnRzIGZy b20gQm8gQnVybWFuIChUaGFua3MgQm8gZm9yIHRoZSByZXZpZXcpDQoNCiAgSG93ZXZlciwgdGhl cmUgd2FzIG9uZSBjb21tZW50IHRoYXQgaXNuJ3QgYWRkcmVzc2VkIGFuZCB3b3VsZCBsb3ZlIHRv IGhlYXIgQ2hhaXJzL1dHIGlucHV0cyBvbiB0aGUgc2FtZQ0KDQoiVGhlIGN1cnJlbnQgdGFibGUg ZW5kcyB3aXRoIOKAnGNhbGdleHRtYXDigJ0sIGJ1dCB0aGUgSUFOQSB0YWJsZSBjb250aW51ZXMg d2l0aCDigJxwaG9uZS1jb250ZXh04oCdLCDigJxjbGly4oCdLCDigJxRNzYzLW5hdHVyZeKAnSwg 4oCcUTc2My1wbGFu4oCdLCDigJxRNzYzLUlOTuKAnSwg4oCccmVxdWlyZeKAnSwg4oCccmVjb3Jk 4oCdLCBhbmQg4oCccmVjb3JkcHJlZuKAnSwgc29tZSBvZiB3aGljaCByZWZlciBxdWl0ZSBvbGQg UkZDcy4gV2h5IGFyZSB0aG9zZSBub3QgaW5jbHVkZWQgaW4gdGhlIHRhYmxlPyINCg0KW1N1aGFz XSA6IFRoZXNlIGF0dHJpYnV0ZXMgYXBwZWFyZWQgaW4gSUFOQSBhZnRlciB3ZSBmcm96ZSBhc3Np Z25pbmcgY2F0ZWdvcmllcy4gVGh1cyBhcyBvZiBub3csIGlmIHRoZSBNVVggZHJhZnQgZ2V0cyBw dWJsaXNoZWQsIHRoZXNlIGF0dHJpYnV0ZXMgZ2V0cyB0aGUgbXV4IGNhdGVnb3J5IG9mIFRCRC4N ClBsZWFzZSBsZXQgbWUga25vdyB5b3VyIHRob3VnaHRzDQoNCg0KQ2hlZXJzDQpTdWhhcw0KT24g TW9uLCBKYW4gNCwgMjAxNiBhdCA0OjMzIFBNLCA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IDxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pj4gd3JvdGU6DQoNCg0KICAg IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cw0KICAgIGRpcmVjdG9yaWVzLg0KICAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lvbg0KICAgIENvbnRyb2wgV29y a2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDog QSBGcmFtZXdvcmsgZm9yIFNEUCBBdHRyaWJ1dGVzIHdoZW4NCiAgICBNdWx0aXBsZXhpbmcNCiAg ICAgICAgICAgIEF1dGhvciAgICAgICAgICA6IFN1aGFzIE5hbmRha3VtYXINCiAgICAgICAgICAg IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0x MS50eHQNCiAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDk2DQogICAgICAgICAgICBEYXRl ICAgICAgICAgICAgOiAyMDE2LTAxLTA0DQoNCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGUgU2Vz c2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBwcm92aWRlcyBtZWNoYW5pc21zIHRvDQog ICAgICAgZGVzY3JpYmUgYXR0cmlidXRlcyBvZiBtdWx0aW1lZGlhIHNlc3Npb25zIGFuZCBvZiBp bmRpdmlkdWFsIG1lZGlhDQogICAgICAgc3RyZWFtcyAoZS5nLiwgUmVhbC10aW1lIFRyYW5zcG9y dCBQcm90b2NvbCAoUlRQKSBzZXNzaW9ucykNCiAgICB3aXRoaW4gYQ0KICAgICAgIG11bHRpbWVk aWEgc2Vzc2lvbi4gIFR5cGljYWxseSBtZWRpYSBhc3NvY2lhdGVkIHdpdGggaW5kaXZpZHVhbA0K ICAgIG1lZGlhDQogICAgICAgZGVzY3JpcHRpb25zICgibT0iIGxpbmVzKSByZXByZXNlbnQgUlRQ IHNlc3Npb25zIGFuZCBhcmUgdGh1cw0KICAgIGNhcnJpZWQNCiAgICAgICBvdmVyIGluZGl2aWR1 YWwgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgZmxvd3MuICBGb3Igc2NlbmFyaW9zDQogICAg ICAgd2hlcmUgU0RQIGlzIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSB1c2FnZSBvZiBzaW5nbGUgNS10 dXBsZSBmb3INCiAgICAgICBzZW5kaW5nIGFuZCByZWNlaXZpbmcgbWVkaWEgYXNzb2NpYXRlZCB3 aXRoIG11bHRpcGxlIG1lZGlhDQogICAgICAgZGVzY3JpcHRpb25zLCBpdCBpcyByZXF1aXJlZCB0 byB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpYw0KICAgIGltcGxpY2F0aW9ucw0KICAgICAgIG9mIHRo ZSBTRFAgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJUUCBNZWRpYSBTdHJlYW1zDQog ICAgICAgbXVsdGlwbGV4ZWQgb3ZlciBhIHNpbmdsZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBsYXll ciBmbG93Lg0KDQogICAgICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRv IHByb3ZpZGUgYSBmcmFtZXdvcmsgZm9yDQogICAgICAgYW5hbHl6aW5nIHRoZSBtdWx0aXBsZXhp bmcgY2hhcmFjdGVyaXN0aWNzIG9mIFNEUCBhdHRyaWJ1dGVzLiAgVGhpcw0KICAgICAgIHNwZWNp ZmljYXRpb24gYWxzbyBjYXRlZ29yaXplcyB0aGUgZXhpc3RpbmcgU0RQIGF0dHJpYnV0ZXMgYmFz ZWQgb24NCiAgICAgICB0aGUgZnJhbWV3b3JrIGRlc2NyaWJlZCBoZXJlaW4uDQoNCg0KICAgIFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgt YXR0cmlidXRlcy8NCg0KICAgIFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNp Yy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTENCg0KICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTExDQoNCg0KICAgIFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mDQogICAgc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCiAgICB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMu aWV0Zi5vcmc+IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQogICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIG1tdXNpYyBtYWlsaW5nIGxpc3QNCiAgICBtbXVz aWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4gPG1haWx0bzptbXVzaWNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCg0K --_000_BBE9739C2C302046BD34B42713A1E2A22E920D0FESESSMB105erics_ 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 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Vbmxl c3MgdGhlcmUgYXJlIG9iamVjdGlvbnMgb3IgZnVydGhlciBjb21tZW50cyBmcm9tIHRoZSBncm91 cCwgSSBjb25jbHVkZSB0aGF0IG5vIGRvY3VtZW50IGNoYW5nZXMgYXJlIHJlcXVpcmVkIG9uIHRo aXMgdG9waWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4vQm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TU1V U0lDIGNvLWNoYWlyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5TdWhhcyBOYW5kYWt1bWFyPGJyPg0KPGI+U2VudDo8L2I+IGRlbiA2IGphbnVhcmkgMjAx NiAwMDo0MDxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0aWFuIEdyb3Zlczxicj4NCjxiPkNjOjwvYj4g bW11c2ljIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTEudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBDaHJpc3RpYW4g Zm9yIGNoZWNraW5nIG9uIHRoaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbHNvIHJlZ2FyZGluZyB0aGUgdXBkYXRlcyB0byB0aGUgZG9jdW1l bnQsIEkgd2FzIHRoaW5raW5nIG9mIG5vdCBhZGRpbmcgdGhlc2UgYXR0cmlidXRlcyB0byB0aGUg ZHJhZnQuIFNpbmNlIHRoZSBJQU5BIHNlY3Rpb24gc2F5cywgZm9yIGFsbCB0aGUgYXR0cmlidXRl cyBpbiB0aGUgSUFOQSByZWdpc3RyeSB0aGF0IGRvZXNuJ3QgaGFzIHRoZSBjYXRlZ29yeSBhc3Np Z25lZCBieSB0aGUgTVVYIGRyYWZ0LCBJQU5BDQogc2hvdWxkIGFzc2lnbiB0aGUgY2F0ZWdvcnkg YXMgVEJELjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5wbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhpcyB3b3JrcyBhcyB3ZWxsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVyczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VoYXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs IEphbiA1LCAyMDE2IGF0IDI6NTYgUE0sIENocmlzdGlhbiBHcm92ZXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpDaHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlz dGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBTdWhhcyw8YnI+DQo8YnI+DQpNeSByZWNvbGxlY3Rp b24gaXMgdGhhdCBSRkMyODQ4IHdoaWNoIGRlZmluZXMgdGhlIGF0dHJpYnV0ZXMgZG9lc24ndCBh Y3R1YWxseSByZXN1bHQgaW4gYW4gUlRQIG1lZGlhIGZsb3cuIFBJTlQgdXNlcyBTSVAvU0RQIHRv IHRyaWdnZXIgYSBnYXRld2F5IHRvIGRvIHNvbWV0aGluZyBvbiB0aGUgR1NUTiBzaWRlLiBCYXNp Y2FsbHkgaXRzIHVzZSB3aXRoIG11bHRpcGxleGluZyBzaG91bGQgYmUgJnF1b3Q7Tm90IFJlY29t bWVuZGVkJnF1b3Q7LiBBcyB0aGUgZHJhZnQNCiB0ZXh0IGFscmVhZHkgc2F5cyB0aGF0IGZvciAm cXVvdDtUQkQmcXVvdDsgaW1wbGVtZW50YXRpb25zIHNob3VsZCB0cmVhdCBpdCBhcyAmcXVvdDtu b3QgcmVjb21tZW5kZWQmcXVvdDssIGl0cyBwcm9iYWJseSBPSyB0byBsYWJlbCB0aGUgYXR0cmli dXRlcyBhcyBUQkQuPGJyPg0KPGJyPg0KUmVnYXJkcywgQ2hyaXN0aWFuPGJyPg0KPGJyPg0KT24g NS8wMS8yMDE2IDExOjM5IEFNLCBTdWhhcyBOYW5kYWt1bWFyIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IZWxs byBBbGw8YnI+DQo8YnI+DQombmJzcDsgVGhpcyB2ZXJzaW9uIGluY29ycG9yYXRlcyBjb21tZW50 cyBmcm9tIEJvIEJ1cm1hbiAoVGhhbmtzIEJvIGZvciB0aGUgcmV2aWV3KTxicj4NCjxicj4NCiZu YnNwOyBIb3dldmVyLCB0aGVyZSB3YXMgb25lIGNvbW1lbnQgdGhhdCBpc24ndCBhZGRyZXNzZWQg YW5kIHdvdWxkIGxvdmUgdG8gaGVhciBDaGFpcnMvV0cgaW5wdXRzIG9uIHRoZSBzYW1lPGJyPg0K PGJyPg0KJnF1b3Q7VGhlIGN1cnJlbnQgdGFibGUgZW5kcyB3aXRoIOKAnGNhbGdleHRtYXDigJ0s IGJ1dCB0aGUgSUFOQSB0YWJsZSBjb250aW51ZXMgd2l0aCDigJxwaG9uZS1jb250ZXh04oCdLCDi gJxjbGly4oCdLCDigJxRNzYzLW5hdHVyZeKAnSwg4oCcUTc2My1wbGFu4oCdLCDigJxRNzYzLUlO TuKAnSwg4oCccmVxdWlyZeKAnSwg4oCccmVjb3Jk4oCdLCBhbmQg4oCccmVjb3JkcHJlZuKAnSwg c29tZSBvZiB3aGljaCByZWZlciBxdWl0ZSBvbGQgUkZDcy4gV2h5IGFyZSB0aG9zZSBub3QgaW5j bHVkZWQgaW4gdGhlIHRhYmxlPyZxdW90Ozxicj4NCjxicj4NCltTdWhhc10gOiBUaGVzZSBhdHRy aWJ1dGVzIGFwcGVhcmVkIGluIElBTkEgYWZ0ZXIgd2UgZnJvemUgYXNzaWduaW5nIGNhdGVnb3Jp ZXMuIFRodXMgYXMgb2Ygbm93LCBpZiB0aGUgTVVYIGRyYWZ0IGdldHMgcHVibGlzaGVkLCB0aGVz ZSBhdHRyaWJ1dGVzIGdldHMgdGhlIG11eCBjYXRlZ29yeSBvZiBUQkQuPGJyPg0KUGxlYXNlIGxl dCBtZSBrbm93IHlvdXIgdGhvdWdodHM8YnI+DQo8YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQpTdWhh czxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIEphbiA0LCAyMDE2IGF0IDQ6MzMgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQombmJzcDsg Jm5ic3A7IGRpcmVjdG9yaWVzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb248YnI+DQom bmJzcDsgJm5ic3A7IENvbnRyb2wgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBBIEZyYW1ld29yayBmb3IgU0RQIEF0 dHJpYnV0ZXMgd2hlbjxicj4NCiZuYnNwOyAmbmJzcDsgTXVsdGlwbGV4aW5nPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IFN1aGFzIE5hbmRha3VtYXI8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMS50eHQ8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiA5Njxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA6IDIwMTYtMDEtMDQ8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFi c3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBTZXNzaW9uIERlc2Ny aXB0aW9uIFByb3RvY29sIChTRFApIHByb3ZpZGVzIG1lY2hhbmlzbXMgdG88YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmliZSBhdHRyaWJ1dGVzIG9mIG11bHRpbWVkaWEgc2Vz c2lvbnMgYW5kIG9mIGluZGl2aWR1YWwgbWVkaWE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtzdHJlYW1zIChlLmcuLCBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChSVFApIHNl c3Npb25zKTxicj4NCiZuYnNwOyAmbmJzcDsgd2l0aGluIGE8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttdWx0aW1lZGlhIHNlc3Npb24uJm5ic3A7IFR5cGljYWxseSBtZWRpYSBhc3Nv Y2lhdGVkIHdpdGggaW5kaXZpZHVhbDxicj4NCiZuYnNwOyAmbmJzcDsgbWVkaWE8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbnMgKCZxdW90O209JnF1b3Q7IGxpbmVz KSByZXByZXNlbnQgUlRQIHNlc3Npb25zIGFuZCBhcmUgdGh1czxicj4NCiZuYnNwOyAmbmJzcDsg Y2FycmllZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO292ZXIgaW5kaXZpZHVhbCB1 bmRlcmx5aW5nIHRyYW5zcG9ydCBsYXllciBmbG93cy4mbmJzcDsgRm9yIHNjZW5hcmlvczxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3doZXJlIFNEUCBpcyB1c2VkIHRvIG5lZ290aWF0 ZSB0aGUgdXNhZ2Ugb2Ygc2luZ2xlIDUtdHVwbGUgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7c2VuZGluZyBhbmQgcmVjZWl2aW5nIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBtdWx0 aXBsZSBtZWRpYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2NyaXB0aW9ucywg aXQgaXMgcmVxdWlyZWQgdG8gdW5kZXJzdGFuZCB0aGUgc2VtYW50aWM8YnI+DQombmJzcDsgJm5i c3A7IGltcGxpY2F0aW9uczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mIHRoZSBT RFAgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJUUCBNZWRpYSBTdHJlYW1zPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bXVsdGlwbGV4ZWQgb3ZlciBhIHNpbmdsZSB1bmRl cmx5aW5nIHRyYW5zcG9ydCBsYXllciBmbG93Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1RoZSBwdXJwb3NlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRl IGEgZnJhbWV3b3JrIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuYWx5emlu ZyB0aGUgbXVsdGlwbGV4aW5nIGNoYXJhY3RlcmlzdGljcyBvZiBTRFAgYXR0cmlidXRlcy4mbmJz cDsgVGhpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb24gYWxz byBjYXRlZ29yaXplcyB0aGUgZXhpc3RpbmcgU0RQIGF0dHJpYnV0ZXMgYmFzZWQgb248YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgZnJhbWV3b3JrIGRlc2NyaWJlZCBoZXJlaW4u PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0 dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgt YXR0cmlidXRlcy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy88L2E+PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJs ZSBhdDo8YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAt bXV4LWF0dHJpYnV0ZXMtMTE8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTExIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1 dGVzLTExPC9hPjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8YnI+DQom bmJzcDsgJm5ic3A7IHN1Ym1pc3Npb248YnI+DQombmJzcDsgJm5ic3A7IHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9h PiAmbHQ7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3Rvb2xzLmlldGYub3JnPC9hPiZndDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0K Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz LyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9h Pjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7IG1tdXNpYyBtYWlsaW5nIGxpc3Q8 YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2lj IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1t dXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BBE9739C2C302046BD34B42713A1E2A22E920D0FESESSMB105erics_-- From nobody Thu Jan 14 08:08:59 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7D1A1A02 for ; Thu, 14 Jan 2016 08:08:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KCTe290aHhU for ; Thu, 14 Jan 2016 08:08:50 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7003C1A19FA for ; Thu, 14 Jan 2016 08:08:49 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-1b-5697c804b611 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9C.A3.05041.408C7965; Thu, 14 Jan 2016 17:08:36 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.202]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Thu, 14 Jan 2016 17:08:35 +0100 From: Bo Burman To: Suhas Nandakumar Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt Thread-Index: AQHRTth9ysS5GFKjnUun8fG/OM+DD577AtmAgAAqLTA= Date: Thu, 14 Jan 2016 16:08:34 +0000 Message-ID: References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E920D28ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7gS7LielhBosnSVhMXf6YxWLn3A5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj2e9J7AUt5RW/+3+zNDC+KO5i5OSQEDCR uD1xMSOELSZx4d56ti5GLg4hgcOMEjf2XGKGcJYwSrQtAslwcrAJaEjM33EXrENEQEti9eK5 TCA2s4C8xIUla4BsDg5hAV+J7q5QiJIAiaZ1x5hBwiICVhIdu/NAwiwCqhIdj6ewgNi8QNV/ pn9iBrGFBDoYJZbMzAaxOQUCJf4ePw22lVFAVuL+93ssEJvEJW49mc8EcbOAxJI955khbFGJ l4//sYKskhBQlFjeLwdRni/x4dcjZohVghInZz5hmcAoOgvJpFlIymYhKZsFNIlZQFNi/S59 iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjLSDW35b 7WA8+NzxEKMAB6MSD68B//QwIdbEsuLK3EOMEhzMSiK8Gw8ChXhTEiurUovy44tKc1KLDzFK c7AoifMmyTSGCQmkJ5akZqemFqQWwWSZODilGhhXmDbbLWQVvblQZvocre8+nekTmUOarj88 2TzjkoLuZQ7eI4tEJ+57q5ayktd/TmVP3o/3/VKdV922KTI+2cMqF6iR5+ntWGF4IyHglxHD vvzvXM/eXeePz/2hlPDkaHm3iZGjUqxDf93MwoR/Imk/rGyXnPZeFhDR/79IWuKz4seFuuai jkosxRmJhlrMRcWJALDdFbqwAgAA Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 16:08:57 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E920D28ESESSMB105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IFN1aGFzLA0KDQpJIGJlbGlldmUgdGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBhbGwg Y29tbWVudHMgcHJvdmlkZWQsIGhhcyBubyByZW1haW5pbmcgbml0cywgYW5kIEkgdGh1cyBpbnRl bmQgdG8gdXNlIGl0IGZvciB0aGUgcHVibGljYXRpb24gcmVxdWVzdC4NCg0KQ2hlZXJzLA0KL0Jv DQpNTVVTSUMgY28tY2hhaXINCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdWhhcyBOYW5kYWt1bWFyDQpTZW50OiBkZW4gMTQgamFu dWFyaSAyMDE2IDE1OjM0DQpUbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpDYzogbW11c2lj IFdHOyBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIudHh0DQoNCkhlbGxv IEFsbA0KDQpUaGlzIHZlcnNpb24gZml4ZXMgY291cGxlIG9mIElEIG5pdHMgYW5kIHVwZGF0ZXMg dGhlIHJlZmVyZW5jZXMgdG8gdGhlIGxhdGVzdCBSRkNzLg0KDQoNCkNoZWVycw0Kc3VoYXMNCg0K T24gVGh1LCBKYW4gMTQsIDIwMTYgYXQgNjozMiBBTSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4gd3JvdGU6DQoNCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXBhcnR5 IE11bHRpbWVkaWEgU2Vzc2lvbiBDb250cm9sIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoN CiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQSBGcmFtZXdvcmsgZm9yIFNEUCBBdHRyaWJ1dGVz IHdoZW4gTXVsdGlwbGV4aW5nDQogICAgICAgIEF1dGhvciAgICAgICAgICA6IFN1aGFzIE5hbmRh a3VtYXINCiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11 eC1hdHRyaWJ1dGVzLTEyLnR4dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiA5Ng0KICAgICAg ICBEYXRlICAgICAgICAgICAgOiAyMDE2LTAxLTE0DQoNCkFic3RyYWN0Og0KICAgVGhlIFNlc3Np b24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgcHJvdmlkZXMgbWVjaGFuaXNtcyB0bw0KICAg ZGVzY3JpYmUgYXR0cmlidXRlcyBvZiBtdWx0aW1lZGlhIHNlc3Npb25zIGFuZCBvZiBpbmRpdmlk dWFsIG1lZGlhDQogICBzdHJlYW1zIChlLmcuLCBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29s IChSVFApIHNlc3Npb25zKSB3aXRoaW4gYQ0KICAgbXVsdGltZWRpYSBzZXNzaW9uLiAgVHlwaWNh bGx5IG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBpbmRpdmlkdWFsIG1lZGlhDQogICBkZXNjcmlwdGlv bnMgKCJtPSIgbGluZXMpIHJlcHJlc2VudCBSVFAgc2Vzc2lvbnMgYW5kIGFyZSB0aHVzIGNhcnJp ZWQNCiAgIG92ZXIgaW5kaXZpZHVhbCB1bmRlcmx5aW5nIHRyYW5zcG9ydCBsYXllciBmbG93cy4g IEZvciBzY2VuYXJpb3MNCiAgIHdoZXJlIFNEUCBpcyB1c2VkIHRvIG5lZ290aWF0ZSB0aGUgdXNh Z2Ugb2Ygc2luZ2xlIDUtdHVwbGUgZm9yDQogICBzZW5kaW5nIGFuZCByZWNlaXZpbmcgbWVkaWEg YXNzb2NpYXRlZCB3aXRoIG11bHRpcGxlIG1lZGlhDQogICBkZXNjcmlwdGlvbnMsIGl0IGlzIHJl cXVpcmVkIHRvIHVuZGVyc3RhbmQgdGhlIHNlbWFudGljIGltcGxpY2F0aW9ucw0KICAgb2YgdGhl IFNEUCBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgUlRQIE1lZGlhIFN0cmVhbXMNCiAg IG11bHRpcGxleGVkIG92ZXIgYSBzaW5nbGUgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgZmxv dy4NCg0KICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRvIHByb3ZpZGUg YSBmcmFtZXdvcmsgZm9yDQogICBhbmFseXppbmcgdGhlIG11bHRpcGxleGluZyBjaGFyYWN0ZXJp c3RpY3Mgb2YgU0RQIGF0dHJpYnV0ZXMuICBUaGlzDQogICBzcGVjaWZpY2F0aW9uIGFsc28gY2F0 ZWdvcml6ZXMgdGhlIGV4aXN0aW5nIFNEUCBhdHRyaWJ1dGVzIGJhc2VkIG9uDQogICB0aGUgZnJh bWV3b3JrIGRlc2NyaWJlZCBoZXJlaW4uDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMvDQoNClRoZXJlJ3MgYWxzbyBh IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMg0KDQpBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEy DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5v cmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlz dA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_BBE9739C2C302046BD34B42713A1E2A22E920D28ESESSMB105erics_ 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 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFu ayB5b3UgU3VoYXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGJlbGlldmUgdGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBh bGwgY29tbWVudHMgcHJvdmlkZWQsIGhhcyBubyByZW1haW5pbmcgbml0cywgYW5kIEkgdGh1cyBp bnRlbmQgdG8gdXNlIGl0IGZvciB0aGUgcHVibGljYXRpb24gcmVxdWVzdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L0JvPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1NVVNJQyBjby1jaGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VoYXMgTmFuZGFrdW1hcjxicj4NCjxiPlNlbnQ6PC9iPiBk ZW4gMTQgamFudWFyaSAyMDE2IDE1OjM0PGJyPg0KPGI+VG86PC9iPiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpYyBXRzsgaS1kLWFubm91bmNlQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBBbGw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHZlcnNpb24gZml4ZXMg Y291cGxlIG9mIElEIG5pdHMgYW5kIHVwZGF0ZXMgdGhlIHJlZmVyZW5jZXMgdG8gdGhlIGxhdGVz dCBSRkNzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D aGVlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnN1aGFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFRodSwgSmFuIDE0LCAyMDE2IGF0IDY6MzIgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJv bCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiBBIEZyYW1ld29yayBmb3IgU0RQIEF0dHJpYnV0ZXMgd2hlbiBNdWx0aXBsZXhpbmc8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IFN1aGFzIE5hbmRha3VtYXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1pZXRmLW1t dXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDk2 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTYtMDEtMTQ8YnI+DQo8YnI+DQpBYnN0cmFjdDo8 YnI+DQombmJzcDsgJm5ic3A7VGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkg cHJvdmlkZXMgbWVjaGFuaXNtcyB0bzxicj4NCiZuYnNwOyAmbmJzcDtkZXNjcmliZSBhdHRyaWJ1 dGVzIG9mIG11bHRpbWVkaWEgc2Vzc2lvbnMgYW5kIG9mIGluZGl2aWR1YWwgbWVkaWE8YnI+DQom bmJzcDsgJm5ic3A7c3RyZWFtcyAoZS5nLiwgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAo UlRQKSBzZXNzaW9ucykgd2l0aGluIGE8YnI+DQombmJzcDsgJm5ic3A7bXVsdGltZWRpYSBzZXNz aW9uLiZuYnNwOyBUeXBpY2FsbHkgbWVkaWEgYXNzb2NpYXRlZCB3aXRoIGluZGl2aWR1YWwgbWVk aWE8YnI+DQombmJzcDsgJm5ic3A7ZGVzY3JpcHRpb25zICgmcXVvdDttPSZxdW90OyBsaW5lcykg cmVwcmVzZW50IFJUUCBzZXNzaW9ucyBhbmQgYXJlIHRodXMgY2FycmllZDxicj4NCiZuYnNwOyAm bmJzcDtvdmVyIGluZGl2aWR1YWwgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgZmxvd3MuJm5i c3A7IEZvciBzY2VuYXJpb3M8YnI+DQombmJzcDsgJm5ic3A7d2hlcmUgU0RQIGlzIHVzZWQgdG8g bmVnb3RpYXRlIHRoZSB1c2FnZSBvZiBzaW5nbGUgNS10dXBsZSBmb3I8YnI+DQombmJzcDsgJm5i c3A7c2VuZGluZyBhbmQgcmVjZWl2aW5nIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBtdWx0aXBsZSBt ZWRpYTxicj4NCiZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbnMsIGl0IGlzIHJlcXVpcmVkIHRvIHVu ZGVyc3RhbmQgdGhlIHNlbWFudGljIGltcGxpY2F0aW9uczxicj4NCiZuYnNwOyAmbmJzcDtvZiB0 aGUgU0RQIGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBSVFAgTWVkaWEgU3RyZWFtczxi cj4NCiZuYnNwOyAmbmJzcDttdWx0aXBsZXhlZCBvdmVyIGEgc2luZ2xlIHVuZGVybHlpbmcgdHJh bnNwb3J0IGxheWVyIGZsb3cuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBwdXJwb3NlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGEgZnJhbWV3b3JrIGZvcjxicj4NCiZu YnNwOyAmbmJzcDthbmFseXppbmcgdGhlIG11bHRpcGxleGluZyBjaGFyYWN0ZXJpc3RpY3Mgb2Yg U0RQIGF0dHJpYnV0ZXMuJm5ic3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7c3BlY2lmaWNhdGlv biBhbHNvIGNhdGVnb3JpemVzIHRoZSBleGlzdGluZyBTRFAgYXR0cmlidXRlcyBiYXNlZCBvbjxi cj4NCiZuYnNwOyAmbmJzcDt0aGUgZnJhbWV3b3JrIGRlc2NyaWJlZCBoZXJlaW4uPGJyPg0KPGJy Pg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmli dXRlcy88L2E+PGJyPg0KPGJyPg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFp bGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0 ZXMtMTI8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMt c2RwLW11eC1hdHRyaWJ1dGVzLTEyPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0K dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_BBE9739C2C302046BD34B42713A1E2A22E920D28ESESSMB105erics_-- From nobody Thu Jan 14 12:06:37 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FD81ACC72 for ; Thu, 14 Jan 2016 12:06:36 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPou4sDI1gW8 for ; Thu, 14 Jan 2016 12:06:34 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844E51ACAD4 for ; Thu, 14 Jan 2016 12:06:33 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-93-5697ffc768a4 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.3B.05041.7CFF7965; Thu, 14 Jan 2016 21:06:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 14 Jan 2016 21:06:31 +0100 From: Christer Holmberg To: Bo Burman , Suhas Nandakumar Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt Thread-Index: AQHRTtiKTRMTzhksn0awFfCLqeDbx577AtmAgAAaVQCAAFLO0A== Date: Thu, 14 Jan 2016 20:06:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> References: <20160114143257.21051.19934.idtracker@ietfa.amsl.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_7594FB04B1934943A5C02806D1A2204B37D188F6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7me7x/9PDDHbtUrG4vOIhq8XU5Y9Z LHbO7WB2YPbYOesuu8eCTaUeS5b8ZApgjuKySUnNySxLLdK3S+DK+L77KktB10LGijdbL7A3 MD6Zw9jFyMkhIWAi0dC0khnCFpO4cG89WxcjF4eQwGFGiYP3/rBDOIsZJbY1XwPq4OBgE7CQ 6P6nDdIgIuAnsWDFbyYQm1nAR+LP49VMICXCAr4S3V2hECUBEk3rjjFD2E4SVzv2gdksAqoS O46fB5vIC1Q+YWMgxKYzjBITb30Du40TaPz15odg9YxAt30/tQZqlbjErSfzmSBuFpBYsuc8 1P2iEi8f/2OFsJUkFt3+DFWfL/H7+Qcwm1dAUOLkzCcsExhFZyEZNQtJ2SwkZbOAzmMW0JRY v0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI/Dg lt9WOxgPPnc8xCjAwajEw2vAPz1MiDWxrLgy9xCjBAezkggv0y+gEG9KYmVValF+fFFpTmrx IUZpDhYlcd4kmcYwIYH0xJLU7NTUgtQimCwTB6dUAyNT08uZXIz389/uTzQ9/vvUnz8e4tNc JnRUX5yyW5d53799vxVCi6+KNR60fCLOw60s4raz3qhH0O9E+t313S4LUsMnqpTyisRa7RIS mcqWeZxvi/btjssa252Vdzz156ie0feAN3X729jH3Ctm6e99tpBDPu3Q55nnTzWr104R3/Or pslcsEmJpTgj0VCLuag4EQCodMmivAIAAA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 20:06:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D188F6ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG9sZCBvbiA6KQ0KDQpTb21lIHRpbWUgYWdvIHRoZXJlIHdhcyBhIHF1ZXN0aW9uIGZyb20gVGF5 bG9yIEJyYW5kc3RldHRlci4gV2FzIHRoYXQgc29sdmVkPyBUaGUgdG9waWMgbWVudGlvbmVkIEJV TkRMRSwgYnV0IEkgdGhpbmsgdGhlIHF1ZXN0aW9uIHdhcyBhbHNvIHJlbGF0ZWQgdG8gdGhlIHNk cC1tdXgtYXR0cmlidXRlIGRyYWZ0Lg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNnMTU0MjEuaHRtbA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEJvIEJ1cm1hbg0KU2VudDogMTQgSmFudWFyeSAyMDE2IDE4OjA5DQpUbzogU3VoYXMg TmFuZGFrdW1hciA8c3VoYXNpZXRmQGdtYWlsLmNvbT4NCkNjOiBtbXVzaWMgV0cgPG1tdXNpY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1t dXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIudHh0DQoNClRoYW5rIHlvdSBTdWhhcywNCg0KSSBi ZWxpZXZlIHRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgYWxsIGNvbW1lbnRzIHByb3ZpZGVkLCBoYXMg bm8gcmVtYWluaW5nIG5pdHMsIGFuZCBJIHRodXMgaW50ZW5kIHRvIHVzZSBpdCBmb3IgdGhlIHB1 YmxpY2F0aW9uIHJlcXVlc3QuDQoNCkNoZWVycywNCi9Cbw0KTU1VU0lDIGNvLWNoYWlyDQoNCkZy b206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg U3VoYXMgTmFuZGFrdW1hcg0KU2VudDogZGVuIDE0IGphbnVhcmkgMjAxNiAxNTozNA0KVG86IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K Q2M6IG1tdXNpYyBXRzsgaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEyLnR4dA0KDQpIZWxsbyBBbGwNCg0KVGhpcyB2ZXJz aW9uIGZpeGVzIGNvdXBsZSBvZiBJRCBuaXRzIGFuZCB1cGRhdGVzIHRoZSByZWZlcmVuY2VzIHRv IHRoZSBsYXRlc3QgUkZDcy4NCg0KDQpDaGVlcnMNCnN1aGFzDQoNCk9uIFRodSwgSmFuIDE0LCAy MDE2IGF0IDY6MzIgQU0sIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Np b24gQ29udHJvbCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAg ICAgICAgICA6IEEgRnJhbWV3b3JrIGZvciBTRFAgQXR0cmlidXRlcyB3aGVuIE11bHRpcGxleGlu Zw0KICAgICAgICBBdXRob3IgICAgICAgICAgOiBTdWhhcyBOYW5kYWt1bWFyDQogICAgICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMi50 eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogOTYNCiAgICAgICAgRGF0ZSAgICAgICAgICAg IDogMjAxNi0wMS0xNA0KDQpBYnN0cmFjdDoNCiAgIFRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFBy b3RvY29sIChTRFApIHByb3ZpZGVzIG1lY2hhbmlzbXMgdG8NCiAgIGRlc2NyaWJlIGF0dHJpYnV0 ZXMgb2YgbXVsdGltZWRpYSBzZXNzaW9ucyBhbmQgb2YgaW5kaXZpZHVhbCBtZWRpYQ0KICAgc3Ry ZWFtcyAoZS5nLiwgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBzZXNzaW9ucykg d2l0aGluIGENCiAgIG11bHRpbWVkaWEgc2Vzc2lvbi4gIFR5cGljYWxseSBtZWRpYSBhc3NvY2lh dGVkIHdpdGggaW5kaXZpZHVhbCBtZWRpYQ0KICAgZGVzY3JpcHRpb25zICgibT0iIGxpbmVzKSBy ZXByZXNlbnQgUlRQIHNlc3Npb25zIGFuZCBhcmUgdGh1cyBjYXJyaWVkDQogICBvdmVyIGluZGl2 aWR1YWwgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgZmxvd3MuICBGb3Igc2NlbmFyaW9zDQog ICB3aGVyZSBTRFAgaXMgdXNlZCB0byBuZWdvdGlhdGUgdGhlIHVzYWdlIG9mIHNpbmdsZSA1LXR1 cGxlIGZvcg0KICAgc2VuZGluZyBhbmQgcmVjZWl2aW5nIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBt dWx0aXBsZSBtZWRpYQ0KICAgZGVzY3JpcHRpb25zLCBpdCBpcyByZXF1aXJlZCB0byB1bmRlcnN0 YW5kIHRoZSBzZW1hbnRpYyBpbXBsaWNhdGlvbnMNCiAgIG9mIHRoZSBTRFAgYXR0cmlidXRlcyBh c3NvY2lhdGVkIHdpdGggdGhlIFJUUCBNZWRpYSBTdHJlYW1zDQogICBtdWx0aXBsZXhlZCBvdmVy IGEgc2luZ2xlIHVuZGVybHlpbmcgdHJhbnNwb3J0IGxheWVyIGZsb3cuDQoNCiAgIFRoZSBwdXJw b3NlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGEgZnJhbWV3b3JrIGZvcg0K ICAgYW5hbHl6aW5nIHRoZSBtdWx0aXBsZXhpbmcgY2hhcmFjdGVyaXN0aWNzIG9mIFNEUCBhdHRy aWJ1dGVzLiAgVGhpcw0KICAgc3BlY2lmaWNhdGlvbiBhbHNvIGNhdGVnb3JpemVzIHRoZSBleGlz dGluZyBTRFAgYXR0cmlidXRlcyBiYXNlZCBvbg0KICAgdGhlIGZyYW1ld29yayBkZXNjcmliZWQg aGVyZWluLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVz aWMtc2RwLW11eC1hdHRyaWJ1dGVzLw0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9u IGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1t dXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37D188F6ESESSMB209erics_ 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 bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44 NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhvbGQg b24gOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvbWUgdGltZSBh Z28gdGhlcmUgd2FzIGEgcXVlc3Rpb24gZnJvbSBUYXlsb3IgQnJhbmRzdGV0dGVyLiBXYXMgdGhh dCBzb2x2ZWQ/IFRoZSB0b3BpYyBtZW50aW9uZWQgQlVORExFLCBidXQgSSB0aGluayB0aGUgcXVl c3Rpb24NCiB3YXMgYWxzbyByZWxhdGVkIHRvIHRoZSBzZHAtbXV4LWF0dHJpYnV0ZSBkcmFmdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tbXVzaWMvY3VycmVudC9tc2cxNTQyMS5odG1s Ij5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNn MTU0MjEuaHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Qm8gQnVybWFuPGJyPg0KPGI+U2VudDo8L2I+IDE0IEphbnVhcnkgMjAx NiAxODowOTxicj4NCjxiPlRvOjwvYj4gU3VoYXMgTmFuZGFrdW1hciAmbHQ7c3VoYXNpZXRmQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpYyBXRyAmbHQ7bW11c2ljQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IFN1aGFzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGJlbGlldmUgdGhp cyB2ZXJzaW9uIGFkZHJlc3NlcyBhbGwgY29tbWVudHMgcHJvdmlkZWQsIGhhcyBubyByZW1haW5p bmcgbml0cywgYW5kIEkgdGh1cyBpbnRlbmQgdG8gdXNlIGl0IGZvciB0aGUgcHVibGljYXRpb24g cmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+L0JvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NTVVTSUMgY28tY2hhaXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gbW11c2ljIFs8YSBo cmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzptbXVzaWMtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN1aGFzIE5hbmRha3VtYXI8YnI+ DQo8Yj5TZW50OjwvYj4gZGVuIDE0IGphbnVhcmkgMjAxNiAxNTozNDxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gbW11c2ljIFdHOyA8YSBocmVmPSJtYWlsdG86 aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1z ZHAtbXV4LWF0dHJpYnV0ZXMtMTIudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBBbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhpcyB2ZXJzaW9uIGZpeGVzIGNvdXBsZSBvZiBJRCBuaXRzIGFuZCB1cGRh dGVzIHRoZSByZWZlcmVuY2VzIHRvIHRoZSBsYXRlc3QgUkZDcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hlZXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPnN1aGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUaHUsIEphbiAxNCwgMjAxNiBhdCA2OjMyIEFNLCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbCBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRs ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBBIEZyYW1ld29yayBm b3IgU0RQIEF0dHJpYnV0ZXMgd2hlbiBNdWx0aXBsZXhpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFN1 aGFzIE5hbmRha3VtYXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0 dHJpYnV0ZXMtMTIudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDk2PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6IDIwMTYtMDEtMTQ8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5i c3A7VGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgcHJvdmlkZXMgbWVjaGFu aXNtcyB0bzxicj4NCiZuYnNwOyAmbmJzcDtkZXNjcmliZSBhdHRyaWJ1dGVzIG9mIG11bHRpbWVk aWEgc2Vzc2lvbnMgYW5kIG9mIGluZGl2aWR1YWwgbWVkaWE8YnI+DQombmJzcDsgJm5ic3A7c3Ry ZWFtcyAoZS5nLiwgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBzZXNzaW9ucykg d2l0aGluIGE8YnI+DQombmJzcDsgJm5ic3A7bXVsdGltZWRpYSBzZXNzaW9uLiZuYnNwOyBUeXBp Y2FsbHkgbWVkaWEgYXNzb2NpYXRlZCB3aXRoIGluZGl2aWR1YWwgbWVkaWE8YnI+DQombmJzcDsg Jm5ic3A7ZGVzY3JpcHRpb25zICgmcXVvdDttPSZxdW90OyBsaW5lcykgcmVwcmVzZW50IFJUUCBz ZXNzaW9ucyBhbmQgYXJlIHRodXMgY2FycmllZDxicj4NCiZuYnNwOyAmbmJzcDtvdmVyIGluZGl2 aWR1YWwgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgZmxvd3MuJm5ic3A7IEZvciBzY2VuYXJp b3M8YnI+DQombmJzcDsgJm5ic3A7d2hlcmUgU0RQIGlzIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSB1 c2FnZSBvZiBzaW5nbGUgNS10dXBsZSBmb3I8YnI+DQombmJzcDsgJm5ic3A7c2VuZGluZyBhbmQg cmVjZWl2aW5nIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBtdWx0aXBsZSBtZWRpYTxicj4NCiZuYnNw OyAmbmJzcDtkZXNjcmlwdGlvbnMsIGl0IGlzIHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgdGhlIHNl bWFudGljIGltcGxpY2F0aW9uczxicj4NCiZuYnNwOyAmbmJzcDtvZiB0aGUgU0RQIGF0dHJpYnV0 ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBSVFAgTWVkaWEgU3RyZWFtczxicj4NCiZuYnNwOyAmbmJz cDttdWx0aXBsZXhlZCBvdmVyIGEgc2luZ2xlIHVuZGVybHlpbmcgdHJhbnNwb3J0IGxheWVyIGZs b3cuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBwdXJwb3NlIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiBpcyB0byBwcm92aWRlIGEgZnJhbWV3b3JrIGZvcjxicj4NCiZuYnNwOyAmbmJzcDthbmFs eXppbmcgdGhlIG11bHRpcGxleGluZyBjaGFyYWN0ZXJpc3RpY3Mgb2YgU0RQIGF0dHJpYnV0ZXMu Jm5ic3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7c3BlY2lmaWNhdGlvbiBhbHNvIGNhdGVnb3Jp emVzIHRoZSBleGlzdGluZyBTRFAgYXR0cmlidXRlcyBiYXNlZCBvbjxicj4NCiZuYnNwOyAmbmJz cDt0aGUgZnJhbWV3b3JrIGRlc2NyaWJlZCBoZXJlaW4uPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtc2Rw LW11eC1hdHRyaWJ1dGVzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy88L2E+PGJyPg0K PGJyPg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNk cC1tdXgtYXR0cmlidXRlcy0xMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTI8L2E+PGJyPg0K PGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1 dGVzLTEyPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8 L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37D188F6ESESSMB209erics_-- From nobody Thu Jan 14 12:49:17 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01BA1ACD63 for ; Thu, 14 Jan 2016 12:49:16 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SLllESt_UrB for ; Thu, 14 Jan 2016 12:49:14 -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 043021ACD62 for ; Thu, 14 Jan 2016 12:49:14 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id a123so257672923vkh.1 for ; Thu, 14 Jan 2016 12:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VkoXNhd0qQCTNrGTSo3ILBAE7v16HU+i3gn0O6n5xnw=; b=yKOz2FpOHJDKVAq8g94FutafW+PxirmIwPNlv6SkP2t+1hJiN5ZofuzTTKjra3wM7z Q7w+rgow42nqJ+dczHvRg9W0XcjOPIgLV6Shs9RDs1wEw+L8Kw9Dsfuo+tvsMa8XrU2L ywppfyVSCIKdvaBa/5uwZ4tkpq4R+R8DoO1WXydogQ9BTKFgV6TwBJrdAQ9OBW1lBbaa aaiWD4S5HnXkR3iViU33YSgGjC5WmD6cHxSqdJPrO0VySYgFmjj6eyXq/HkVn9khKlus 6NbzNY+mb13Xvd3MZmgifuqPv7EKNM8q+37CNlo8pebXuOXAZFM+oOBRXHkIjoo+Flob wWEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VkoXNhd0qQCTNrGTSo3ILBAE7v16HU+i3gn0O6n5xnw=; b=knqoD60CgPgybFnyDovwkPrthdxYWQgwQTHK8aMqm0VdiLh0tzKtBv5X2g96Lgj48z 8+gEMdH0wWNkqcPL+qZqyjo1mkAi1EFRA7yEJkBiRbbA3YIp5dsAzroUMlopTitm58Ro o82NdLYb9OTExyU8rhsyMKw9Ki0+ZJsTMwO78R7hYyFlC6cf64iJLfn21O8Dbvj7tiVl vWLuHlk9lzWVtJDUM/oq3LV1MIVngl+RteMSUD/HOiYbEaXhNA5dN8EdflnOBLWgpOlZ f9xmSLGJCNPbMudsfCy9UPJJriTosQFufUp/WKH+LXr16/T026F2hMY+eNtJl8kkW5Nm sG9Q== X-Gm-Message-State: ALoCoQlWwpzkHdTNI4ReujHSYE9eyQnSddC7MbjljdFoodDL6C9hOIH7SZfzva5nO7/b5g61+sEr2ybKN44aReil4UHYAxClYA== MIME-Version: 1.0 X-Received: by 10.31.50.213 with SMTP id y204mr4711087vky.109.1452804553174; Thu, 14 Jan 2016 12:49:13 -0800 (PST) Received: by 10.31.106.130 with HTTP; Thu, 14 Jan 2016 12:49:13 -0800 (PST) In-Reply-To: References: Date: Thu, 14 Jan 2016 12:49:13 -0800 Message-ID: From: Suhas Nandakumar To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=001a1144053c51f4130529516b0d Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] In BUNDLE negotiation, when do "IDENTICAL" attributes need to be identical? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 20:49:16 -0000 --001a1144053c51f4130529516b0d Content-Type: text/plain; charset=UTF-8 Hi Taylor As an offerer when I am offering BUNDLE, i will apply IDENTICAL when offering for those attribute that needs such a behavior. So yes we need to specify the IDENTICAL on first proposal, also in answer if the Answerer supports the BUNDLE and the attribute specified and in the subsequent offer as well if the BUNDLE gets accepted. Also to note a particular category gets applies internally (in the code) only after the successful Offer/Answer negotiation. Hope that helps Thanks Suhas On Mon, Dec 14, 2015 at 3:46 PM, Taylor Brandstetter wrote: > I'm referring to "IDENTICAL" as defined by this draft: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes > > The definition is: > > Attributes and their associated values (if any) that MUST be > identical across all the media descriptions being multiplexed. > > However, it's not clear to me at what point in BUNDLE negotiation this > restriction starts to apply. Is it: > > 1. When an offer first proposes a BUNDLE group > 2. When an answer accepts a BUNDLE group > 3. When a subsequent offer is made, with an already-established BUNDLE > group > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1144053c51f4130529516b0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Taylor

=C2=A0 As an offerer when I a= m offering BUNDLE, i will apply IDENTICAL when offering for those attribute= that needs such a behavior.

So yes we need to spe= cify the IDENTICAL on first proposal, also in answer if the Answerer suppor= ts the BUNDLE and the attribute specified and in the subsequent offer as we= ll if the BUNDLE gets accepted.

Also to note a par= ticular category gets applies internally (in the code) only after the succe= ssful Offer/Answer negotiation.


Hop= e that helps

Thanks
Suhas

On Mon, Dec 14, 2015= at 3:46 PM, Taylor Brandstetter <deadbeef@google.com> wro= te:



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


--001a1144053c51f4130529516b0d-- From nobody Thu Jan 14 12:50:52 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C2E1ACD61 for ; Thu, 14 Jan 2016 12:50:51 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krZavxwrpL0I for ; Thu, 14 Jan 2016 12:50:44 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 5918A1ACD77 for ; Thu, 14 Jan 2016 12:50:44 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id n1so133213184vkb.3 for ; Thu, 14 Jan 2016 12:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j2hgBQVGsYGGyQqyx4MRE8s9A2zG2+ibZeKsBeYz2qY=; b=m3SzaviVEv6w6hzyzhaGrimIU8hGOnZ8DvYsILrPs5OA/lBF0Y43gqe0ZC1yCWQybe 9bWhXI8dtCfm7IUmqsrvFyvyd1GXQBFNiA/DPNhQYsiy2nTqylXMQYjbouLwIkeg9SSl Leo095MFxgmKTF+2QWtHnaE5l8pJoaWqVRbvqikq+5J4CvaZDeVtvLrX9TO6tRrXxJUw 2BIX0sDRqdtnR/xevloo0wM9X32ccbDxI7zwUUEoPQLVBhzqbAneqwMA7Ovw3Rw/3R3H U9MCVYUmC3cmGVoHgZfaQBh3Yp0CaRYMfl5TCTVMaDS/21ADiwrusVseO2ue9o5NdrU1 H12Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j2hgBQVGsYGGyQqyx4MRE8s9A2zG2+ibZeKsBeYz2qY=; b=mOWSNuF/7AMZ3QvTqa/sW1fqCRBfZHERT6BGX/FJ+oOoR1JZCwVnSVHm/hfu6dnL2d SWSBewPOogVBYcq4aFM/cKfmaiCTGLR8CW8KNQHPijWreojNWvbYMVXfMi9IAoH+6n56 S2geMZTTrtMQMUbgNPnKwt5nBHlwkPt26yUkFwGzTUjZDX9U/WbAQeNSukOukSjyOd9z dx2OPUo4l+xWb0Nkalx+8zSYomzajmSYACmxTPpMYdKJ+nAG1oJx9+f9exW2yzoI/NPP 4VoFrWPHp7KJ+3muivcLIM+Mgw+7lOQTjm+lLayyQtJtLsHNGpTcuBalVAk4+UBNM4lv 4ArA== X-Gm-Message-State: ALoCoQleEUv0XnrPTrxWXUZrKiQc5DAGLzJB0y+myo8i0r27IWW8DdUCpmxt7aPFnYkfpEUgDiEQ3aopDe9cXzBujAd1wpEKLA== MIME-Version: 1.0 X-Received: by 10.31.150.23 with SMTP id y23mr4896734vkd.87.1452804643537; Thu, 14 Jan 2016 12:50:43 -0800 (PST) Received: by 10.31.106.130 with HTTP; Thu, 14 Jan 2016 12:50:43 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> Date: Thu, 14 Jan 2016 12:50:43 -0800 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140f59cb4c9e90529517039 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 20:50:51 -0000 --001a1140f59cb4c9e90529517039 Content-Type: text/plain; charset=UTF-8 Thanks Christer for bringing this to our notice. I just responded to Taylor's clarification question and I don't think the response to his question changes any of the behavior for BUNDLE or MUX. Please let me know your thoughts on my response. Thanks Suhas On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hold on :) > > > > Some time ago there was a question from Taylor Brandstetter. Was that > solved? The topic mentioned BUNDLE, but I think the question was also > related to the sdp-mux-attribute draft. > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg15421.html > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman > *Sent:* 14 January 2016 18:09 > *To:* Suhas Nandakumar > *Cc:* mmusic WG > > *Subject:* Re: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-mux-attributes-12.txt > > > > Thank you Suhas, > > > > I believe this version addresses all comments provided, has no remaining > nits, and I thus intend to use it for the publication request. > > > > Cheers, > > /Bo > > MMUSIC co-chair > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org ] *On > Behalf Of *Suhas Nandakumar > *Sent:* den 14 januari 2016 15:34 > *To:* internet-drafts@ietf.org > *Cc:* mmusic WG; i-d-announce@ietf.org > *Subject:* Re: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-mux-attributes-12.txt > > > > Hello All > > > > This version fixes couple of ID nits and updates the references to the > latest RFCs. > > > > > > Cheers > > suhas > > > > On Thu, Jan 14, 2016 at 6:32 AM, 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 > Working Group of the IETF. > > Title : A Framework for SDP Attributes when Multiplexing > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-12.txt > Pages : 96 > Date : 2016-01-14 > > Abstract: > The Session Description Protocol (SDP) provides mechanisms to > describe attributes of multimedia sessions and of individual media > streams (e.g., Real-time Transport Protocol (RTP) sessions) within a > multimedia session. Typically media associated with individual media > descriptions ("m=" lines) represent RTP sessions and are thus carried > over individual underlying transport layer flows. For scenarios > where SDP is used to negotiate the usage of single 5-tuple for > sending and receiving media associated with multiple media > descriptions, it is required to understand the semantic implications > of the SDP attributes associated with the RTP Media Streams > multiplexed over a single underlying transport layer flow. > > The purpose of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. This > specification also categorizes the existing SDP attributes based on > the framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --001a1140f59cb4c9e90529517039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Christer for bringing this to our notice. I just re= sponded to Taylor's clarification question and I don't =C2=A0think = the response to his question changes any of the behavior for BUNDLE or MUX.=

Please let me know your thoughts on my response.
<= div>
Thanks
Suhas

On Thu, Jan 14, 2016 at 12:06 PM, Chris= ter Holmberg <christer.holmberg@ericsson.com> w= rote:

Hold on :)

=C2=A0

Some time ago there was a question fr= om Taylor Brandstetter. Was that solved? The topic mentioned BUNDLE, but I = think the question was also related to the sdp-mux-attribute draft.

=C2=A0

http://www.ietf.= org/mail-archive/web/mmusic/current/msg15421.html<= /p>

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: 14 January 2016 18:09
To: Suhas Nandakumar <suhasietf@gmail.com>
Cc: mmusic WG <mmusic@ietf.org>


Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Thank you Suhas,

=C2=A0

I believe this version= addresses all comments provided, has no remaining nits, and I thus intend = to use it for the publication request.

=C2=A0

Cheers,<= /span>

/Bo

MMUSIC co-chair=

=C2=A0

From: mm= usic [mailto:m= music-bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: den 14 januari 2016 15:34
To: in= ternet-drafts@ietf.org
Cc: mmusic WG; i-d-announce@ietf.org
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Hello All<= /p>

=C2=A0

This version fixes couple of ID= nits and updates the references to the latest RFCs.

=C2=A0

=C2=A0

Cheers

suhas

=C2=A0

On Thu, Jan 14, 2016 at 6:32 AM= , <interne= t-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-14

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 Typically media associated with indi= vidual media
=C2=A0 =C2=A0descriptions ("m=3D" lines) represent RTP sessions a= nd are thus carried
=C2=A0 =C2=A0over individual underlying transport layer flows.=C2=A0 For sc= enarios
=C2=A0 =C2=A0where SDP is used to negotiate the usage of single 5-tuple for=
=C2=A0 =C2=A0sending and receiving media associated with multiple media
=C2=A0 =C2=A0descriptions, it is required to understand the semantic implic= ations
=C2=A0 =C2=A0of the SDP attributes associated with the RTP Media Streams =C2=A0 =C2=A0multiplexed over a single underlying transport layer flow.

=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusi= c-sdp-mux-attributes/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mu= x-attributes-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-mmusic-sdp-mux-attributes-12


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

=C2=A0


--001a1140f59cb4c9e90529517039-- From nobody Thu Jan 14 14:12:37 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0890A1A00B5; Thu, 14 Jan 2016 14:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqxnL4EXlYXv; Thu, 14 Jan 2016 14:12:35 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 2D9021A00BC; Thu, 14 Jan 2016 14:12:25 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0EMCONl064908 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Jan 2016 16:12:24 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: draft-ietf-mmusic-proto-iana-registration.all@ietf.org, mmusic Date: Thu, 14 Jan 2016 16:12:24 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-proto-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 22:12:36 -0000 Hi, Here's my AD Evaluation of draft-ietf-mmusic-proto-iana-registration. I have a couple of comments I'd like to resolve before last call, and a few editorial comments.: Substantive (to be resolved before last call): - (This is really editorial, but I think there's a chance for confusion.) The references in section 3 seem insufficient. Section 1 lists RFCs that define most of all of the related transport protocol profiles. For example, [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That information should probably also go in section 3, since that's the section referenced by the IANA considerations section. To avoid duplication, consider moving the bits after the first paragraph of section 1 into the respective subsections of 3. - The security considerations seem inadequate. Most, if not all, of the proto values listed here refer to some other RFC that has it's own security considerations. So it doesn't really seem true to say there are no considerations other than those in 4566. Editorial (non-blocking): - The abstract is long. The 2nd paragraph describes what the draft does. Can some or all of the first paragraph be relegated to the intro? - 3: It would be helpful to mention that the transport protocol mentioned in the first paragraph goes in the field in the M-line. From nobody Fri Jan 15 04:30:04 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389CD1B2C2E for ; Fri, 15 Jan 2016 04:30:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOA3yMphdXty for ; Fri, 15 Jan 2016 04:30:00 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BEA1B2BDE for ; Fri, 15 Jan 2016 04:29:59 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-19-5698e645297c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.E2.05041.546E8965; Fri, 15 Jan 2016 13:29:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Fri, 15 Jan 2016 13:29:55 +0100 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt Thread-Index: AQHRTtiKTRMTzhksn0awFfCLqeDbx577AtmAgAAaVQCAAFLO0P///AeAgAEQrzA= Date: Fri, 15 Jan 2016 12:29:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D19CED@ESESSMB209.ericsson.se> References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D19CEDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM+Jvja7bsxlhBlNPsFhcXvGQ1WLq8scs FteWv2a12Dm3g9mBxWPnrLvsHgs2lXosWfKTKYA5issmJTUnsyy1SN8ugSvjX/t2loIlzUwV 01susTQw7vnD2MXIySEhYCJx/dx6JghbTOLCvfVsXYxcHEICRxglNp/sgHIWM0rcaO4Ecjg4 2AQsJLr/aYM0iAhoSaxePJcJpIZZYCajxKkVR1lBaoQFfCW6u0IhagIkmtYdY4aw/SSe3r4M tphFQFXiStN5sHJeoPJLZz0gVl1nktj3aCbYQZwCgRJdv2eA9TICHff91BqwOLOAuMStJ/Oh jhaQWLLnPDOELSrx8vE/VghbUWLn2XZmkPnMAvkSP19wg4R5BQQlTs58wjKBUXQWkkmzEKpm IamCCGtKrN+lD1GtKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxcW56UZGeqlFmcnFxfl5enmp JZsYgZF4cMtvqx2MB587HmIU4GBU4uEt0JgRJsSaWFZcmXuIUYKDWUmEl/cOUIg3JbGyKrUo P76oNCe1+BCjNAeLkjhvkkxjmJBAemJJanZqakFqEUyWiYNTqoFR7UCNgOOuEuXTdWcC7O+7 JAq9K5y10y9iq7pfSGH4ZdkLq6t4ZrXYXV4tZFioJaq/a2FH3XzRj9Mipgqb5TVujZFaa+hp uvVIzKNnDAfL3LakfP4nHXuAtSfzElvL7u9VkyTOfVBllS7qPr+QK0qlK+z/k9krzkkeNnt5 10D51X8+lgCFnU1KLMUZiYZazEXFiQCWFRDBwAIAAA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 12:30:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D19CEDESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIGlzIGFsc28gYW5vdGhlciBpc3N1ZToNCg0KU29tZSB0aW1lIGFnbywgUGV0 ZXIgVGhhdGNoZXIgYXNrZWQgd2hldGhlciBpdCBpcyByZWFsbHkgbmVlZGVkIHRvIGluY2x1ZGUg dGhlIFNEUCBjYW5kaWRhdGUgYXR0cmlidXRlcyBpbiBhbGwgYnVuZGxlZCBtLSBsaW5lcy4NCg0K aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzE1 MzMxLmh0bWwNCg0KTG9va2luZyBhdCBTRFAgYXR0cmlidXRlcyBpbiBnZW5lcmFsLCBJIGd1ZXNz IHRoZSBxdWVzdGlvbiBpczogaWYgYW4gYXR0cmlidXRlIGJlbG9uZ3MgdG8gSURFTlRJQ0FMLCBk b2VzIGl0IG5lZWQgdG8gYmUgaW5jbHVkZWQgaW4gYWxsIG0tIGxpbmVzIHdpdGhpbiBhIEJVTkRM RSBncm91cD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogU3VoYXMgTmFuZGFrdW1h ciBbbWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb21dDQpTZW50OiAxNC4gdGFtbWlrdXV0YSAyMDE2 IDIyOjUxDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBCbyBCdXJtYW47IG1tdXNpYyBXRzsg VGF5bG9yIEJyYW5kc3RldHRlcg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMi50eHQNCg0KVGhhbmtzIENocmlz dGVyIGZvciBicmluZ2luZyB0aGlzIHRvIG91ciBub3RpY2UuIEkganVzdCByZXNwb25kZWQgdG8g VGF5bG9yJ3MgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbiBhbmQgSSBkb24ndCAgdGhpbmsgdGhlIHJl c3BvbnNlIHRvIGhpcyBxdWVzdGlvbiBjaGFuZ2VzIGFueSBvZiB0aGUgYmVoYXZpb3IgZm9yIEJV TkRMRSBvciBNVVguDQoNClBsZWFzZSBsZXQgbWUga25vdyB5b3VyIHRob3VnaHRzIG9uIG15IHJl c3BvbnNlLg0KDQpUaGFua3MNClN1aGFzDQoNCk9uIFRodSwgSmFuIDE0LCAyMDE2IGF0IDEyOjA2 IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhvbGQgb24gOikN Cg0KU29tZSB0aW1lIGFnbyB0aGVyZSB3YXMgYSBxdWVzdGlvbiBmcm9tIFRheWxvciBCcmFuZHN0 ZXR0ZXIuIFdhcyB0aGF0IHNvbHZlZD8gVGhlIHRvcGljIG1lbnRpb25lZCBCVU5ETEUsIGJ1dCBJ IHRoaW5rIHRoZSBxdWVzdGlvbiB3YXMgYWxzbyByZWxhdGVkIHRvIHRoZSBzZHAtbXV4LWF0dHJp YnV0ZSBkcmFmdC4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNp Yy9jdXJyZW50L21zZzE1NDIxLmh0bWwNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTog bW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEJvIEJ1cm1hbg0KU2VudDogMTQgSmFudWFyeSAy MDE2IDE4OjA5DQpUbzogU3VoYXMgTmFuZGFrdW1hciA8c3VoYXNpZXRmQGdtYWlsLmNvbTxtYWls dG86c3VoYXNpZXRmQGdtYWlsLmNvbT4+DQpDYzogbW11c2ljIFdHIDxtbXVzaWNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIudHh0DQoNClRoYW5r IHlvdSBTdWhhcywNCg0KSSBiZWxpZXZlIHRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgYWxsIGNvbW1l bnRzIHByb3ZpZGVkLCBoYXMgbm8gcmVtYWluaW5nIG5pdHMsIGFuZCBJIHRodXMgaW50ZW5kIHRv IHVzZSBpdCBmb3IgdGhlIHB1YmxpY2F0aW9uIHJlcXVlc3QuDQoNCkNoZWVycywNCi9Cbw0KTU1V U0lDIGNvLWNoYWlyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU3VoYXMgTmFuZGFrdW1hcg0KU2VudDogZGVuIDE0IGphbnVhcmkg MjAxNiAxNTozNA0KVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPg0KQ2M6IG1tdXNpYyBXRzsgaS1kLWFubm91bmNlQGlldGYub3JnPG1h aWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEyLnR4dA0KDQpIZWxs byBBbGwNCg0KVGhpcyB2ZXJzaW9uIGZpeGVzIGNvdXBsZSBvZiBJRCBuaXRzIGFuZCB1cGRhdGVz IHRoZSByZWZlcmVuY2VzIHRvIHRoZSBsYXRlc3QgUkZDcy4NCg0KDQpDaGVlcnMNCnN1aGFzDQoN Ck9uIFRodSwgSmFuIDE0LCAyMDE2IGF0IDY6MzIgQU0sIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQpBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwYXJ0 eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0K DQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgRnJhbWV3b3JrIGZvciBTRFAgQXR0cmlidXRl cyB3aGVuIE11bHRpcGxleGluZw0KICAgICAgICBBdXRob3IgICAgICAgICAgOiBTdWhhcyBOYW5k YWt1bWFyDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1t dXgtYXR0cmlidXRlcy0xMi50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogOTYNCiAgICAg ICAgRGF0ZSAgICAgICAgICAgIDogMjAxNi0wMS0xNA0KDQpBYnN0cmFjdDoNCiAgIFRoZSBTZXNz aW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIHByb3ZpZGVzIG1lY2hhbmlzbXMgdG8NCiAg IGRlc2NyaWJlIGF0dHJpYnV0ZXMgb2YgbXVsdGltZWRpYSBzZXNzaW9ucyBhbmQgb2YgaW5kaXZp ZHVhbCBtZWRpYQ0KICAgc3RyZWFtcyAoZS5nLiwgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2Nv bCAoUlRQKSBzZXNzaW9ucykgd2l0aGluIGENCiAgIG11bHRpbWVkaWEgc2Vzc2lvbi4gIFR5cGlj YWxseSBtZWRpYSBhc3NvY2lhdGVkIHdpdGggaW5kaXZpZHVhbCBtZWRpYQ0KICAgZGVzY3JpcHRp b25zICgibT0iIGxpbmVzKSByZXByZXNlbnQgUlRQIHNlc3Npb25zIGFuZCBhcmUgdGh1cyBjYXJy aWVkDQogICBvdmVyIGluZGl2aWR1YWwgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgZmxvd3Mu ICBGb3Igc2NlbmFyaW9zDQogICB3aGVyZSBTRFAgaXMgdXNlZCB0byBuZWdvdGlhdGUgdGhlIHVz YWdlIG9mIHNpbmdsZSA1LXR1cGxlIGZvcg0KICAgc2VuZGluZyBhbmQgcmVjZWl2aW5nIG1lZGlh IGFzc29jaWF0ZWQgd2l0aCBtdWx0aXBsZSBtZWRpYQ0KICAgZGVzY3JpcHRpb25zLCBpdCBpcyBy ZXF1aXJlZCB0byB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpYyBpbXBsaWNhdGlvbnMNCiAgIG9mIHRo ZSBTRFAgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJUUCBNZWRpYSBTdHJlYW1zDQog ICBtdWx0aXBsZXhlZCBvdmVyIGEgc2luZ2xlIHVuZGVybHlpbmcgdHJhbnNwb3J0IGxheWVyIGZs b3cuDQoNCiAgIFRoZSBwdXJwb3NlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRl IGEgZnJhbWV3b3JrIGZvcg0KICAgYW5hbHl6aW5nIHRoZSBtdWx0aXBsZXhpbmcgY2hhcmFjdGVy aXN0aWNzIG9mIFNEUCBhdHRyaWJ1dGVzLiAgVGhpcw0KICAgc3BlY2lmaWNhdGlvbiBhbHNvIGNh dGVnb3JpemVzIHRoZSBleGlzdGluZyBTRFAgYXR0cmlidXRlcyBiYXNlZCBvbg0KICAgdGhlIGZy YW1ld29yayBkZXNjcmliZWQgaGVyZWluLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLw0KDQpUaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTINCg0KQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0x Mg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYu b3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxp c3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37D19CEDESESSMB209erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkZJO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4w Y207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgYWxzbyBhbm90aGVyIGlzc3VlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb21lIHRpbWUgYWdvLCBQZXRlciBUaGF0Y2hl ciBhc2tlZCB3aGV0aGVyIGl0IGlzIHJlYWxseSBuZWVkZWQgdG8gaW5jbHVkZSB0aGUgU0RQIGNh bmRpZGF0ZSBhdHRyaWJ1dGVzIGluIGFsbCBidW5kbGVkIG0tIGxpbmVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNnMTUzMzEuaHRtbCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzE1MzMxLmh0bWw8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvb2tpbmcgYXQgU0RQIGF0dHJpYnV0 ZXMgaW4gZ2VuZXJhbCwgSSBndWVzcyB0aGUgcXVlc3Rpb24gaXM6IGlmIGFuIGF0dHJpYnV0ZSBi ZWxvbmdzIHRvIElERU5USUNBTCwgZG9lcyBpdCBuZWVkIHRvIGJlIGluY2x1ZGVkIGluIGFsbCBt LSBsaW5lcw0KIHdpdGhpbiBhIEJVTkRMRSBncm91cD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFN1aGFzIE5hbmRha3VtYXIgW21haWx0 bzpzdWhhc2lldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE0LiB0YW1taWt1dXRh IDIwMTYgMjI6NTE8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6 PC9iPiBCbyBCdXJtYW47IG1tdXNpYyBXRzsgVGF5bG9yIEJyYW5kc3RldHRlcjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2Rw LW11eC1hdHRyaWJ1dGVzLTEyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBDaHJpc3RlciBmb3IgYnJpbmdpbmcgdGhpcyB0byBvdXIgbm90aWNlLiBJIGp1 c3QgcmVzcG9uZGVkIHRvIFRheWxvcidzIGNsYXJpZmljYXRpb24gcXVlc3Rpb24gYW5kIEkgZG9u J3QgJm5ic3A7dGhpbmsgdGhlIHJlc3BvbnNlIHRvIGhpcyBxdWVzdGlvbiBjaGFuZ2VzIGFueSBv ZiB0aGUgYmVoYXZpb3IgZm9yIEJVTkRMRSBvciBNVVguPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgbGV0IG1lIGtub3cgeW91ciB0aG91Z2h0cyBv biBteSByZXNwb25zZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TdWhhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAxNCwgMjAxNiBhdCAxMjowNiBQTSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhvbGQgb24gOik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb21l IHRpbWUgYWdvIHRoZXJlIHdhcyBhIHF1ZXN0aW9uIGZyb20gVGF5bG9yIEJyYW5kc3RldHRlci4g V2FzIHRoYXQgc29sdmVkPyBUaGUgdG9waWMNCiBtZW50aW9uZWQgQlVORExFLCBidXQgSSB0aGlu ayB0aGUgcXVlc3Rpb24gd2FzIGFsc28gcmVsYXRlZCB0byB0aGUgc2RwLW11eC1hdHRyaWJ1dGUg ZHJhZnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzE1NDIxLmh0 bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bW11c2ljL2N1cnJlbnQvbXNnMTU0MjEuaHRtbDwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNo cmlzdGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9IjcyNjU3NDkyOF9fTWFpbEVuZENvbXBvc2Ui PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIG1tdXNp YyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+Qm8gQnVybWFuPGJyPg0KPGI+U2VudDo8L2I+IDE0IEphbnVhcnkgMjAxNiAxODowOTxicj4N CjxiPlRvOjwvYj4gU3VoYXMgTmFuZGFrdW1hciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0 ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdWhhc2lldGZAZ21haWwuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IG1tdXNpYyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtNTVVTSUNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmli dXRlcy0xMi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoYW5rIHlvdSBTdWhhcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGJlbGlldmUgdGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBhbGwgY29tbWVudHMgcHJvdmlkZWQsIGhh cyBubyByZW1haW5pbmcgbml0cywgYW5kIEkNCiB0aHVzIGludGVuZCB0byB1c2UgaXQgZm9yIHRo ZSBwdWJsaWNhdGlvbiByZXF1ZXN0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNoZWVycyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vQm88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NTVVTSUMgY28tY2hhaXI8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtbXVzaWMNCiBbPGEgaHJlZj0ibWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOm1tdXNpYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VoYXMgTmFuZGFrdW1hcjxicj4N CjxiPlNlbnQ6PC9iPiBkZW4gMTQgamFudWFyaSAyMDE2IDE1OjM0PGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gbW11c2ljIFdHOyA8 YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aS1k LWFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEyLnR4dDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBBbGw8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIHZlcnNpb24gZml4 ZXMgY291cGxlIG9mIElEIG5pdHMgYW5kIHVwZGF0ZXMgdGhlIHJlZmVyZW5jZXMgdG8gdGhlIGxh dGVzdCBSRkNzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5DaGVlcnM8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPnN1aGFzPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgSmFu IDE0LCAyMDE2IGF0IDY6MzIgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZn dDsgd3JvdGU6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbCBXb3JraW5nIEdyb3VwIG9m IHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBBIEZyYW1ld29yayBmb3Ig U0RQIEF0dHJpYnV0ZXMgd2hlbiBNdWx0aXBsZXhpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFN1aGFz IE5hbmRha3VtYXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJp YnV0ZXMtMTIudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDk2PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IDIwMTYtMDEtMTQ8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7 VGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgcHJvdmlkZXMgbWVjaGFuaXNt cyB0bzxicj4NCiZuYnNwOyAmbmJzcDtkZXNjcmliZSBhdHRyaWJ1dGVzIG9mIG11bHRpbWVkaWEg c2Vzc2lvbnMgYW5kIG9mIGluZGl2aWR1YWwgbWVkaWE8YnI+DQombmJzcDsgJm5ic3A7c3RyZWFt cyAoZS5nLiwgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBzZXNzaW9ucykgd2l0 aGluIGE8YnI+DQombmJzcDsgJm5ic3A7bXVsdGltZWRpYSBzZXNzaW9uLiZuYnNwOyBUeXBpY2Fs bHkgbWVkaWEgYXNzb2NpYXRlZCB3aXRoIGluZGl2aWR1YWwgbWVkaWE8YnI+DQombmJzcDsgJm5i c3A7ZGVzY3JpcHRpb25zICgmcXVvdDttPSZxdW90OyBsaW5lcykgcmVwcmVzZW50IFJUUCBzZXNz aW9ucyBhbmQgYXJlIHRodXMgY2FycmllZDxicj4NCiZuYnNwOyAmbmJzcDtvdmVyIGluZGl2aWR1 YWwgdW5kZXJseWluZyB0cmFuc3BvcnQgbGF5ZXIgZmxvd3MuJm5ic3A7IEZvciBzY2VuYXJpb3M8 YnI+DQombmJzcDsgJm5ic3A7d2hlcmUgU0RQIGlzIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSB1c2Fn ZSBvZiBzaW5nbGUgNS10dXBsZSBmb3I8YnI+DQombmJzcDsgJm5ic3A7c2VuZGluZyBhbmQgcmVj ZWl2aW5nIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBtdWx0aXBsZSBtZWRpYTxicj4NCiZuYnNwOyAm bmJzcDtkZXNjcmlwdGlvbnMsIGl0IGlzIHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgdGhlIHNlbWFu dGljIGltcGxpY2F0aW9uczxicj4NCiZuYnNwOyAmbmJzcDtvZiB0aGUgU0RQIGF0dHJpYnV0ZXMg YXNzb2NpYXRlZCB3aXRoIHRoZSBSVFAgTWVkaWEgU3RyZWFtczxicj4NCiZuYnNwOyAmbmJzcDtt dWx0aXBsZXhlZCBvdmVyIGEgc2luZ2xlIHVuZGVybHlpbmcgdHJhbnNwb3J0IGxheWVyIGZsb3cu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBwdXJwb3NlIG9mIHRoaXMgc3BlY2lmaWNhdGlv biBpcyB0byBwcm92aWRlIGEgZnJhbWV3b3JrIGZvcjxicj4NCiZuYnNwOyAmbmJzcDthbmFseXpp bmcgdGhlIG11bHRpcGxleGluZyBjaGFyYWN0ZXJpc3RpY3Mgb2YgU0RQIGF0dHJpYnV0ZXMuJm5i c3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7c3BlY2lmaWNhdGlvbiBhbHNvIGNhdGVnb3JpemVz IHRoZSBleGlzdGluZyBTRFAgYXR0cmlidXRlcyBiYXNlZCBvbjxicj4NCiZuYnNwOyAmbmJzcDt0 aGUgZnJhbWV3b3JrIGRlc2NyaWJlZCBoZXJlaW4uPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11 eC1hdHRyaWJ1dGVzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy88L2E+PGJyPg0KPGJy Pg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1t dXgtYXR0cmlidXRlcy0xMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTI8L2E+PGJyPg0KPGJy Pg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1t dXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVz LTEyPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+ Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVz aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwv YT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37D19CEDESESSMB209erics_-- From nobody Fri Jan 15 08:20:16 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5491B2FA6 for ; Fri, 15 Jan 2016 08:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI-EN03Ajt8U for ; Fri, 15 Jan 2016 08:20:13 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 D9B891B2FA0 for ; Fri, 15 Jan 2016 08:20:12 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id p187so120388678oia.2 for ; Fri, 15 Jan 2016 08:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h633ul3kVpr8cjGmag6w9GNrUwUPPAYuqpk1niMRhoY=; b=hoXF2tLIcXg2sux5bAsl/myKsHmwNPL65uOyQSxK4xVQexXY/KAUHxK7DsyIEqRW3k D+QSwYGkOULhx2GAGYSXCEX35PlcbjhDMAoWriXwO4TIlESRhWiXJYzCm4zp4VWzh5TK s05L5NoJw0GZwuvoTGvBBgK5kYiK/V4zo4kfadPolmI2QBL0suwwh3B1iX9r6H67NVFt BqLElNbEbY9dEFU2U/hCAetRpg6DW+H5lfrpjQ4i77CxIlXB/hRGgqkOnn+KyDjwv6K4 EYXDwqS9vsk9foh1t40G11LiEmTQDdwdae+1sV32LWVrvAH4pkNnmJJ34yHqt1Ny0Z0w wr8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h633ul3kVpr8cjGmag6w9GNrUwUPPAYuqpk1niMRhoY=; b=Rn67VqOgXyUq9pYRkBZDwObyDFzdmMgcoJn8fZ6p0JDwvOPWuyEqVTq7SnG+BpWSpO ++iH+0Z/SqWJrmeMkWEY5OuKQm8L6ww9WtG+dSWfQ995Tgib9f/yK/wAPYeqMKMxyvrg j+ygQBlCcHZ7CXE/LSOuariIEjFVWJcAmcTyVPuJcdAyTCAm/HBp6BQdJknPjinSjj7C 5ax3Z+8ZZXpG9O+E5zDgOq592j+Jp1zAeGkjA5WZv527FPXZJu9R5nh2PaZiEZ10qTHw T1C4nWQm/N6xPv6DG+IM33JG1ZfO9q7pVp6H0YKUVizLnHELZmksDElRNunhAb5PTVWh Jg0A== X-Gm-Message-State: ALoCoQlWkHR0r/Jpc4iVX2Uh/cAnEC0Xi7CViEdER/9hxwIAmDNu8W0dNdVCdkNDmAzA9N0McKn7qACVhVxrugGB/EnRJizA4xO+jVTZdLd2BBCCElMir2Q= MIME-Version: 1.0 X-Received: by 10.202.204.136 with SMTP id c130mr8901876oig.93.1452874812183; Fri, 15 Jan 2016 08:20:12 -0800 (PST) Received: by 10.60.117.163 with HTTP; Fri, 15 Jan 2016 08:20:12 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D19CED@ESESSMB209.ericsson.se> References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D19CED@ESESSMB209.ericsson.se> Date: Fri, 15 Jan 2016 08:20:12 -0800 Message-ID: From: Taylor Brandstetter To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1137b11215a628052961c729 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 16:20:15 -0000 --001a1137b11215a628052961c729 Content-Type: text/plain; charset=UTF-8 "candidate" is in the TRANSPORT category though, which doesn't prevent it from being different in different media sections. It's the BUNDLE negotiation draft that imposes the candidate duplication requirement, with a combination of these two paragraphs: When the answerer selects a BUNDLE address for itself, referred to as the answerer BUNDLE address, it MUST associate that address with each bundled "m=" line within the created BUNDLE group in the answer. When an offerer or answerer associates a shared address (i.e. a previously selected BUNDLE address) with one or more bundled "m=" lines, it MUST associate identical ICE candidates (referred to as shared ICE candidates) with each of those "m=" lines. On Fri, Jan 15, 2016 at 4:29 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > There is also another issue: > > > > Some time ago, Peter Thatcher asked whether it is really needed to include > the SDP candidate attributes in all bundled m- lines. > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg15331.html > > > > Looking at SDP attributes in general, I guess the question is: if an > attribute belongs to IDENTICAL, does it need to be included in all m- lines > within a BUNDLE group? > > > > Regards, > > > > Christer > > > > *From:* Suhas Nandakumar [mailto:suhasietf@gmail.com] > *Sent:* 14. tammikuuta 2016 22:51 > *To:* Christer Holmberg > *Cc:* Bo Burman; mmusic WG; Taylor Brandstetter > > *Subject:* Re: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-mux-attributes-12.txt > > > > Thanks Christer for bringing this to our notice. I just responded to > Taylor's clarification question and I don't think the response to his > question changes any of the behavior for BUNDLE or MUX. > > > > Please let me know your thoughts on my response. > > > > Thanks > > Suhas > > > > On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hold on :) > > > > Some time ago there was a question from Taylor Brandstetter. Was that > solved? The topic mentioned BUNDLE, but I think the question was also > related to the sdp-mux-attribute draft. > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg15421.html > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman > *Sent:* 14 January 2016 18:09 > *To:* Suhas Nandakumar > *Cc:* mmusic WG > > > *Subject:* Re: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-mux-attributes-12.txt > > > > Thank you Suhas, > > > > I believe this version addresses all comments provided, has no remaining > nits, and I thus intend to use it for the publication request. > > > > Cheers, > > /Bo > > MMUSIC co-chair > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org ] *On > Behalf Of *Suhas Nandakumar > *Sent:* den 14 januari 2016 15:34 > *To:* internet-drafts@ietf.org > *Cc:* mmusic WG; i-d-announce@ietf.org > *Subject:* Re: [MMUSIC] I-D Action: > draft-ietf-mmusic-sdp-mux-attributes-12.txt > > > > Hello All > > > > This version fixes couple of ID nits and updates the references to the > latest RFCs. > > > > > > Cheers > > suhas > > > > On Thu, Jan 14, 2016 at 6:32 AM, 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 > Working Group of the IETF. > > Title : A Framework for SDP Attributes when Multiplexing > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-12.txt > Pages : 96 > Date : 2016-01-14 > > Abstract: > The Session Description Protocol (SDP) provides mechanisms to > describe attributes of multimedia sessions and of individual media > streams (e.g., Real-time Transport Protocol (RTP) sessions) within a > multimedia session. Typically media associated with individual media > descriptions ("m=" lines) represent RTP sessions and are thus carried > over individual underlying transport layer flows. For scenarios > where SDP is used to negotiate the usage of single 5-tuple for > sending and receiving media associated with multiple media > descriptions, it is required to understand the semantic implications > of the SDP attributes associated with the RTP Media Streams > multiplexed over a single underlying transport layer flow. > > The purpose of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. This > specification also categorizes the existing SDP attributes based on > the framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > --001a1137b11215a628052961c729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"candidate" is in the TRANSPORT category though,= which doesn't prevent it from being different in different media secti= ons. It's the BUNDLE negotiation draft that imposes the candidate dupli= cation requirement, with a combination of these two paragraphs:

   When th=
e answerer selects a BUNDLE address for itself, referred to as
   the answerer BUNDLE address, it MUST associate that address with each
   bundled "m=3D" line within the created BUNDLE group in the ans=
wer.
   When an offerer or answerer associates a shared=
 address (i.e. a
   previously selected BUNDLE address) with one or more bundled "m=3D&=
quot;
   lines, it MUST associate identical ICE candidates (referred to as
   shared ICE candidates) with each of those "m=3D" lines.
<= div class=3D"gmail_quote">
On Fri, Jan = 15, 2016 at 4:29 AM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:

Hi,

=C2=A0

There is also another issue:<= u>

=C2=A0

Some time ago, Peter Thatcher= asked whether it is really needed to include the SDP candidate attributes = in all bundled m- lines.

=C2=A0

http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg15331.html=

=C2=A0

Looking at SDP attributes in = general, I guess the question is: if an attribute belongs to IDENTICAL, doe= s it need to be included in all m- lines within a BUNDLE group?

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Suhas Nandakumar [mailto:suhasietf@gmail.com= ]
Sent: 14. tammikuuta 2016 22:51
To: Christer Holmberg
Cc: Bo Burman; mmusic WG; Taylor Brandstetter


Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Thanks Christer for bringing this to our notice. I j= ust responded to Taylor's clarification question and I don't =C2=A0= think the response to his question changes any of the behavior for BUNDLE o= r MUX.

=C2=A0

Please let me know your thoughts on my response.<= /u>

=C2=A0

Thanks

Suhas

=C2=A0

On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hold on :)

=C2=A0

Some time ago there was a que= stion from Taylor Brandstetter. Was that solved? The topic mentioned BUNDLE, but I think the question was also related to the sdp-mux= -attribute draft.

=C2=A0

http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg15421.html

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: 14 January 2016 18:09
To: Suhas Nandakumar <suhasietf@gmail.com>
Cc: mmusic WG <mmusic@ietf.org>=


Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Thank you Suhas,

=C2=A0

I believe this version addres= ses all comments provided, has no remaining nits, and I thus intend to use it for the publication request.

=C2=A0

Cheers,

/Bo

MMUSIC co-chair

=C2=A0

From: mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: den 14 januari 2016 15:34
To: in= ternet-drafts@ietf.org
Cc: mmusic WG; i-d-announce@ietf.org
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Hello All

=C2=A0

This version fixes couple of ID= nits and updates the references to the latest RFCs.

=C2=A0

=C2=A0

Cheers

suhas

=C2=A0

On Thu, Jan 14, 2016 at 6:32 AM= , <interne= t-drafts@ietf.org> wrote:<= /span>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-14

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 Typically media associated with indi= vidual media
=C2=A0 =C2=A0descriptions ("m=3D" lines) represent RTP sessions a= nd are thus carried
=C2=A0 =C2=A0over individual underlying transport layer flows.=C2=A0 For sc= enarios
=C2=A0 =C2=A0where SDP is used to negotiate the usage of single 5-tuple for=
=C2=A0 =C2=A0sending and receiving media associated with multiple media
=C2=A0 =C2=A0descriptions, it is required to understand the semantic implic= ations
=C2=A0 =C2=A0of the SDP attributes associated with the RTP Media Streams =C2=A0 =C2=A0multiplexed over a single underlying transport layer flow.

=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusi= c-sdp-mux-attributes/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mu= x-attributes-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-mmusic-sdp-mux-attributes-12


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

=C2=A0

=C2=A0


--001a1137b11215a628052961c729-- From nobody Mon Jan 18 05:14:09 2016 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 D3AAB1B36A8; Mon, 18 Jan 2016 05:14:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160118131406.30923.39823.idtracker@ietfa.amsl.com> Date: Mon, 18 Jan 2016 05:14:06 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 13:14:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-04.txt Pages : 21 Date : 2016-01-18 Abstract: This draft defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The draft also defines the criteria for when a new DTLS association must be established. This draft defines a new SDP media-level attribute, 'dtls- connection'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-04 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 Jan 18 05:18:55 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549841B36B0; Mon, 18 Jan 2016 05:18:53 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki3wfP7qgQa5; Mon, 18 Jan 2016 05:18:52 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C721B36AE; Mon, 18 Jan 2016 05:18:51 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-d5-569ce639caca Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.08.02707.936EC965; Mon, 18 Jan 2016 14:18:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Mon, 18 Jan 2016 14:18:49 +0100 From: Christer Holmberg To: mmusic WG Thread-Topic: Draft new version: draft-ietf-mmusic-dtls-sdp-04 Thread-Index: AdFR8kp5uwUz/Dy9QxSJ6St5otz3dw== Date: Mon, 18 Jan 2016 13:18:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D4212E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D4212EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdTtfy2Zwwg7MntS3O71zPZDF1+WMW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl3P73i6XgvVTF3CuTGBsYv4h3MXJySAiYSPQf6GCC sMUkLtxbz9bFyMUhJHCYUWL1709MEM4SRonLHX+AHA4ONgELie5/2iANIgLyEh87zzGC2MwC phIPX60Bs4UFLCUmrLrBBFFjJ/FoVys7hK0nsevBehYQm0VAVWLd3kXMIDavgK9E/6RNYDWM QEd8P7WGCWKmuMStJ/OhjhOQWLLnPDOELSrx8vE/VpBzJASUJKZtTQMxmQXyJbZv0YaYKChx cuYTlgmMwrOQDJqFUDULSRVEiY7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLU4KTfd yEgvtSgzubg4P08vL7VkEyMwXg5u+W2wg/Hlc8dDjAIcjEo8vBuezA4TYk0sK67MPcQowcGs JMJbeXFOmBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeJJnGMCGB9MSS1OzU1ILUIpgsEwenVANj mOu3w7UrRTJ2pR7uaNl1vC3+/cQHmziyPs+PK2jo7H7c9vHNrMzyU1Pi9wS8UvR0FK86s01S 1OmWctehn6veeehnBm+tWqLOfPhRadHnzxHG/94dY3qlceHTwqfLzXdnGfOkz/3+deWu72qm zRuYepY9Wyy9w84pMTXk9yYps7M18V9DS/r5lViKMxINtZiLihMB0LFWAZMCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 13:18:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D4212EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-04) of draft-ietf-mmusic-dtls-sdp. The changes are based on comments made by Paul K and Martin T. Martin T did have a comment on the cipher text, which may require some list= discussion, so I have not done any changes based on that comment yet. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D4212EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new vers= ion (-04) of draft-ietf-mmusic-dtls-sdp.

 

The changes are based on commen= ts made by Paul K and Martin T.

 

Martin T did have a comment on = the cipher text, which may require some list discussion, so I have not done= any changes based on that comment yet.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D4212EESESSMB209erics_-- From nobody Mon Jan 18 07:47:34 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B211B38B7 for ; Mon, 18 Jan 2016 07:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvrAHZPYrc7G for ; Mon, 18 Jan 2016 07:47:32 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651C31B38B3 for ; Mon, 18 Jan 2016 07:47:32 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-03v.sys.comcast.net with comcast id 7TnP1s00D2AWL2D01TnXec; Mon, 18 Jan 2016 15:47:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with comcast id 7TnX1s0013KdFy101TnXbl; Mon, 18 Jan 2016 15:47:31 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37D4212E@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <569D0911.90007@alum.mit.edu> Date: Mon, 18 Jan 2016 10:47:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D4212E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453132051; bh=+z4NKjTwqvR/yCxj3vF73Xa2WZto28NK7/n3GCsmvZU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=g/o7ZY6UBAWcHRimTM6uwEFa3FrwoJxZFmw1eXL6VQCRqyNymcQHu0c1G02zQTE/I wt8Kc9KWJUENdbOQU1sljvHcmPti3HI0sHaXsiXHWEHeK0EHPicH9eU8S70mo8JpjR olbqdcidJ4Xi63fVK2IeCtWx8qwdUk2pvq8sscH397v0pcrxhif3tFWzXlZ1suGnJj eoH+HhaCToHRbXyhi3XQqDU8gNAb2EbgT2bbfrkHL9GIvI4nbquWkMh/01LSPTQzBL nP0B5k4H42FXdlejeG+T0jpwJN93UZLoDX16S/dVQL8Gfq2OK+/ipQIwpNZfrXNbGq Thspxwor4y8LA== Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:47:33 -0000 Christer, There seem to be a couple of typos in the new version: Section 3.1: Whenever an entity determines, based on the criteria above, that a new DTLS association is the entity MUST initiate an associated SDP offer/answer transaction, following to the procedures in Section 5. Missing a word: "new DTLS association is [required?] the entity ...". Section 5.1: Endpoints MUST support the algorithms defined in **** Endpoints MUST support SHA-256 for generating and verifying the fingerprint value associated with the DTLS association. The use of SHA-256 is preferred. The above seems just messed up. I don't remember what was intended. Thanks, Paul On 1/18/16 8:18 AM, Christer Holmberg wrote: > Hi, > > I’ve submitted a new version (-04) of draft-ietf-mmusic-dtls-sdp. > > The changes are based on comments made by Paul K and Martin T. > > Martin T did have a comment on the cipher text, which may require some > list discussion, so I have not done any changes based on that comment yet. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Jan 18 09:20:17 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71791B3AC8 for ; Mon, 18 Jan 2016 09:20: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 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 N_GfK0ed2DlA for ; Mon, 18 Jan 2016 09:20:14 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE09F1B3A78 for ; Mon, 18 Jan 2016 09:20:13 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-9c-569d1ecb45e9 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.19.04914.BCE1D965; Mon, 18 Jan 2016 18:20:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Mon, 18 Jan 2016 18:19:24 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-04 Thread-Index: AdFR8kp5uwUz/Dy9QxSJ6St5otz3dwADNzuAAAR+wNA= Date: Mon, 18 Jan 2016 17:19:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D43732@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D4212E@ESESSMB209.ericsson.se> <569D0911.90007@alum.mit.edu> In-Reply-To: <569D0911.90007@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7uu5publhBt/XWFhMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGnoVXmAvW8lSs+rmOrYHxKWcXIyeHhICJ xJUX7xkhbDGJC/fWs3UxcnEICRxmlLj8/T4rhLOEUeLA8xXsXYwcHGwCFhLd/7RBGkQEfCWe Pb7NBmILC7hJvJwCMUhEwF3i9JmVULaVRGvLbWYQm0VAVeLw4x6wel6g3oV9f8FsIYFcie7v z1lBbE4BLYm+DU0sIDYj0EHfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xQthKEotu f4aq15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLc dCNjvdSizOTi4vw8vbzUkk2MwDg5uOW37g7G1a8dDzEKcDAq8fAW9M4JE2JNLCuuzD3EKMHB rCTCO1d8bpgQb0piZVVqUX58UWlOavEhRmkOFiVx3mSZxjAhgfTEktTs1NSC1CKYLBMHp1QD oy1vjPbX2S/fqfCE9S1aOsVwW/z1lHh7F/PJfMv0Fd+u+b1JLGHN74U5J295KLO/mdKTNfv7 igU3/XjXvZmxKPb5nC+XDjAIJ0q+/NMjsvb2+/PL8gJFI0Xl7nnXbD3WFlN7/30zr9rXXw4y ddetTl658WDT291Oa2QfyWzn0OE6HryV6fE9wRIlluKMREMt5qLiRADVdXK4jwIAAA== Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 17:20:16 -0000 Hi Paul, > Section 3.1: > > Whenever an entity determines, based on the criteria above, that a > new DTLS association is the entity MUST initiate an associated SDP > offer/answer transaction, following to the procedures in Section 5. > > Missing a word: "new DTLS association is [required?] the entity ...". Correct. I'll fix that. > Section 5.1: > > Endpoints MUST support the algorithms defined in **** Endpoints MUST > support SHA-256 for generating and verifying the fingerprint value > associated with the DTLS association. The use of SHA-256 is > preferred. > > The above seems just messed up. I don't remember what was intended. Seems strange. The first part ("Endpoints MUST support the algorithms defin= ed in ****")shall be removed. I'll do the fixes and submit a new version, so avoid further confusion. Thanks! Regards, Christer On 1/18/16 8:18 AM, Christer Holmberg wrote: > Hi, > > I've submitted a new version (-04) of draft-ietf-mmusic-dtls-sdp. > > The changes are based on comments made by Paul K and Martin T. > > Martin T did have a comment on the cipher text, which may require some=20 > list discussion, so I have not done any changes based on that comment yet= . > > 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 From nobody Mon Jan 18 09:30:13 2016 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 7A0101B3AE9; Mon, 18 Jan 2016 09:30:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> Date: Mon, 18 Jan 2016 09:30:11 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 17:30:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-05.txt Pages : 21 Date : 2016-01-18 Abstract: This draft defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The draft also defines the criteria for when a new DTLS association must be established. This draft defines a new SDP media-level attribute, 'dtls- connection'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 18 09:32:03 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204281B3AF0; Mon, 18 Jan 2016 09:32:02 -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 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 UL_fNncscVZx; Mon, 18 Jan 2016 09:32:01 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8CF1B3AEF; Mon, 18 Jan 2016 09:32:00 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-ce-569d218e830d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.4A.04914.E812D965; Mon, 18 Jan 2016 18:31:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Mon, 18 Jan 2016 18:31:58 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-dtls-sdp-05 Thread-Index: AdFSFhB8c9kMSO3YS0GOcQtXXMNOEg== Date: Mon, 18 Jan 2016 17:31:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D437CC@ESESSMB209.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM2K7om6/4twwgxfP2C3O71zPZDF1+WMW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlvP03hbGgg7Hi8Ar/Bsa0LkYODgkBE4mLf6q7GDmB TDGJC/fWs3UxcnEICRxmlLjz6yuUs4RRom1xNyNIA5uAhUT3P22QBhEBdYmve3uYQWxmAVOJ h6/WMILYwgKWEru79rNB1NhJzJt2kwnC1pP4c+o7mM0ioCpx/+VTsBpeAV+Jb4c6WUBsRqAj vp9awwQxU1zi1pP5TBDHCUgs2XOeGcIWlXj5+B8rhK0ksej2Z6h6HYkFuz+xQdjaEssWvmaG mC8ocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQI DP+DW37r7mBc/drxEKMAB6MSD29B75wwIdbEsuLK3EOMEhzMSiK8c8XnhgnxpiRWVqUW5ccX leakFh9ilOZgURLnTZZpDBMSSE8sSc1OTS1ILYLJMnFwSjUw+vb69Ro0uVfmLNtUsjwkTFBp yzrJx7c+nF946935nz2Gi2VMVx6cXFD7NeCA5el+uVV9L+p0hE00/119bT7zZoLJmufGzWom O/1sXZc5zeqLLd8Q8EPp4tm3C985upxJlNsYxr/rZediqQfzwz7eLL59P+8X0zXlhCxRtRkP ZwWe4/qdJaWhr8RSnJFoqMVcVJwIAI7sRXZ7AgAA Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 17:32:02 -0000 Hi, I've submitted a new version (-05) of the dtls-sdp draft, fixing the editor= ial nits found by Paul. Regards, Christer From nobody Mon Jan 18 10:47:15 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F591B3BAC for ; Mon, 18 Jan 2016 10:47:13 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLW8TWtPVFhu for ; Mon, 18 Jan 2016 10:47:11 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA081B3BA9 for ; Mon, 18 Jan 2016 10:47:11 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-ec-569d332d04d2 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0A.89.05041.D233D965; Mon, 18 Jan 2016 19:47:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Mon, 18 Jan 2016 19:47:09 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Is support of mux exclusive a MUST/SHOULD/MAY/RECOMMENDED? Thread-Index: AdFSIHDldlmmcNh4RhSwHgQukuMFtA== Date: Mon, 18 Jan 2016 18:47:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D438DF@ESESSMB209.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_7594FB04B1934943A5C02806D1A2204B37D438DFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7rq6u8dwwgxtn5C2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujM13JrMUfJCoOH/tMnMDY4tYFyMnh4SAicSmxjNsELaYxIV7 64FsLg4hgcOMEt/79rBCOEsYJT49e8PSxcjBwSZgIdH9TxukQURAXeLr3h5mkLCwgLfEmU/h EOEgiddvOtggbD2JI0fvgdksAqoSd3qPMoLYvAK+EscPfgOzGYH2fj+1hgnEZhYQl7j1ZD4T xD0CEkv2nGeGsEUlXj7+xwphK0ksuv0Zqj5fovXqZnaImYISJ2c+YZnAKDQLyahZSMpmISmD iOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC I+Lglt9WOxgPPnc8xCjAwajEw7vhyewwIdbEsuLK3EOMEhzMSiK8c8XnhgnxpiRWVqUW5ccX leakFh9ilOZgURLnTZJpDBMSSE8sSc1OTS1ILYLJMnFwSjUwyv9u2255J2zddn4Zof8epb8a a+5qlK+Qjq8205jw8FPsL9Vilfr1Fx60RoqutZii+L/s/YxJOjkWFqUOyq+uTha0np2ysu/H 26uCB+1CQnTTHJeW3Yku2mghYPR27u6vLSHTZjmc/6YannpK82edl1jSMt+Zshpuq59mipxU C1p1cd56pVWXlViKMxINtZiLihMBTLMUiIQCAAA= Archived-At: Subject: [MMUSIC] BUNDLE: Is support of mux exclusive a MUST/SHOULD/MAY/RECOMMENDED? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 18:47:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D438DFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We previously agreed that, within a BUNDLE group, RTP/RTCP multiplexing MUS= T be used for all RTP-based media. The question is: do we also mandate BUNDLE entities to also support mux-exc= lusive? Or, should support of mux-exclusive be a SHALL/SHOULD/MAY/RECOMMENDED? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D438DFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We previously agreed that, within a BUNDLE group, RT= P/RTCP multiplexing MUST be used for all RTP-based media.

 

The question is: do we also mandate BUNDLE entities = to also support mux-exclusive?

 

Or, should support of mux-exclusive be a SHALL/SHOUL= D/MAY/RECOMMENDED?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D438DFESESSMB209erics_-- From nobody Mon Jan 18 11:55:09 2016 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 1CDD41B3C94; Mon, 18 Jan 2016 11:55:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160118195507.6180.63154.idtracker@ietfa.amsl.com> Date: Mon, 18 Jan 2016 11:55:07 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-25.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 19:55:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-25.txt Pages : 51 Date : 2016-01-18 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 address:port combination (BUNDLE address) for receiving media, referred to as bundled media, associated with multiple SDP media descriptions ("m=" lines). 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. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. 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 media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-25 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 Jan 18 12:01:53 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08781B3CA4; Mon, 18 Jan 2016 12:01:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juPVo7a4trbJ; Mon, 18 Jan 2016 12:01:49 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3E81B3CA1; Mon, 18 Jan 2016 12:01:48 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-3b-569d44ab3d03 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8C.CC.30208.BA44D965; Mon, 18 Jan 2016 21:01:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Mon, 18 Jan 2016 21:01:46 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQ== Date: Mon, 18 Jan 2016 20:01:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.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_7594FB04B1934943A5C02806D1A2204B37D44B4AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7t+5ql7lhBtuniFic37meyWLq8scs DkweS5b8ZApgjOKySUnNySxLLdK3S+DKWP9iJ3PBLqmK1ht5DYxrxLsYOTkkBEwk9t1cwQph i0lcuLeeDcQWEjjMKNGw3BnCXsIoMfdYURcjBwebgIVE9z9tkLCIgLrE1709zCA2s4CpxMNX axhBSoQFVCU+HXaBKNGSWPRgHVhYREBP4um1dJAwC1DFi7M/wBbxCvhKTO+azg5iMwId8P3U GiaIieISt57MZ4I4TEBiyZ7zzBC2qMTLx/+gDlaSWHT7M1R9vsT0GXtYIWYKSpyc+YRlAqPw LCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLU7KTTcy1kstykwu Ls7P08tLLdnECIyVg1t+q+5gvPzG8RCjAAejEg/vhiezw4RYE8uKK3MPMUpwMCuJ8M4Vnxsm xJuSWFmVWpQfX1Sak1p8iFGag0VJnDdJpjFMSCA9sSQ1OzW1ILUIJsvEwSnVwChhmuf29r9i 0IbNBS85pm++pKlmlHCJdcPU+IDjP9hUZBxlLeZoSp9/sE+uecbDfusvz09c2hUkdX7S9MpC xSXskdZGGhuX/l/ZrMX/jyuhuEv80QPrVWmusz1FubV77k56F6vYLu58KtA+Tel78584xe9r Dr0Sdzp42u56YfjeZbP3nuD5VqrEUpyRaKjFXFScCADz6e0ikQIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 20:01:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D44B4AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-25) of draft-ietf-mmusic-sdp-bundle-negotiat= ion. I have added text regarding mux-exclusive to the RTP/RTCP multiplexing chap= ter. However, as I wrote in another mail, I think we need to say whether support= of mux-exclusive is mandated by bundle entities. Currently we only mandate= support of RTP/RTCP multiplexing in general. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D44B4AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-25) of draft-ie= tf-mmusic-sdp-bundle-negotiation.

 

I have added text regarding mux-exclusive to the RTP= /RTCP multiplexing chapter.

 

However, as I wrote in another mail, I think we need= to say whether support of mux-exclusive is mandated by bundle entities. Cu= rrently we only mandate support of RTP/RTCP multiplexing in general.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D44B4AESESSMB209erics_-- From nobody Mon Jan 18 16:09:38 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F299B1A6F6F; Mon, 18 Jan 2016 16:09:36 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BHiSnCNkDHI; Mon, 18 Jan 2016 16:09:34 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 CDEF01A6F6E; Mon, 18 Jan 2016 16:09:33 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id k1so339675658vkb.2; Mon, 18 Jan 2016 16:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kiezr9pO8burGUB2Gt3oabFNFtEhvjD48ZOc4SKV/2Q=; b=FoKxytXzSt10HZdPCdv1FMP0DGqYUgcAClhwWdCRD/dLhl5vsfcHdemDn9JnEDE83m uTT/yJflEq3ssVKe2DiZeRSI9M+N15Ypxm+WBE9X4EFRjIoX6eM7q4jbB0LO6UyOzGxa 1HqNvqVm/Vu9IGyTbEiicI3+LdoSa+5XMQ06zbqhguIbux2ijzwP6mdCCvK4sE1+Q58q cesDG855MbFf6gAooZUVp7sd/JlXgGzbwfOWeeSgR7f0QHXdIHmM32hUZ/pRoYYAvG5k anbU4s0JaNyNvs0X1RS7Kkyv2pbwvdCCA57r7QjShtb/mDLqJwOz2Lerx/lxjRcZ8ybz j6rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Kiezr9pO8burGUB2Gt3oabFNFtEhvjD48ZOc4SKV/2Q=; b=UqZd2EVJ0yi+RPUjRVFUHn0BjfsoVokfC+eFrc9h2bXa1RkI4DYB/nxGUVE472L+Dd VaLIvm/UqEzSGbZVRYif/iYmV6woQ47Do2452+EIjw8h+sJhb8bweb7OUz8XhWpblc0w 7tAN9cg913GqDVwDO47zMZyOW8FjzoCzlgTP0EdLkY8O31ImaFbsvjUOpjh1UFxOYBaO EELo7S7uDpODZrqDlQUgPZ7NrzhN3eYdE98Jwj1O/14ZZB+EJLOEMwDYrjzxrq+C4dw0 j4Mm1M0W20aFUs79zgWLQiKt30B4siVA4O/6H89bdDqw6dGUofcYc68v47fUfFhLNA2M KR7w== X-Gm-Message-State: ALoCoQkrzIixUjkl7HjdClg52QaceezPI3UYT5at+AysO6enrXWWeI2ff7rneSC/qcVfDv/2Qjx9cc0y9TtqlnN2ZiJZT3hMyA== MIME-Version: 1.0 X-Received: by 10.31.150.23 with SMTP id y23mr18161414vkd.87.1453162172635; Mon, 18 Jan 2016 16:09:32 -0800 (PST) Received: by 10.31.106.130 with HTTP; Mon, 18 Jan 2016 16:09:32 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Jan 2016 16:09:32 -0800 Message-ID: From: Suhas Nandakumar To: Ben Campbell Content-Type: multipart/alternative; boundary=001a1140f59c19e0f10529a4af10 Archived-At: Cc: draft-ietf-mmusic-proto-iana-registration.all@ietf.org, mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-proto-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 00:09:37 -0000 --001a1140f59c19e0f10529a4af10 Content-Type: text/plain; charset=UTF-8 Hello Ben Thanks for the review. Please see below for the resolutions on your comments (marked in bold). Substantive (to be resolved before last call): *- (This is really editorial, but I think there's a chance for confusion.) The references in section 3 seem insufficient. Section 1 lists RFCs that define most of all of the related transport protocol profiles. For example, [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That information should probably also go in section 3, since that's the section referenced by the IANA considerations section. To avoid duplication, consider moving the bits after the first paragraph of section 1 into the respective subsections of 3.* [Suhas] Removed the detailed proto descriptions from Section 1 and moved them to individual sections in Section 3. Now the Section1 just has the following para regarding the identifiers. " This specification describes additional SDP transport protocol identifiers for transporting RTP Media over TCP as defined in Section 3 <#sec.proto-identifiers>. " and Section 3 has been updated to have template as below " 3.1. <#rfc.section.3.1> TCP/RTP/AVPF Transport Realization <#sec.tcp.rtp.avpf> The TCP/RTP/AVPF transport describes RTP Media with RTCP-based Feedback [RFC4585] <#RFC4585> over TCP. It is realized as described below: - RTP/AVPF stream over the TCP transport is realized using the framing method defined in[RFC4571] <#RFC4571>. 3.2. <#rfc.section.3.2> TCP/RTP/SAVP Transport Realization <#sec.tcp.rtp.savp> The TCP/RTP/SAVP transport describes Secure RTP (SRTP) Media [RFC3711] <#RFC3711> over TCP. It is realized as described below: - RTP/SAVP stream over the TCP transport is realized using the framing method defined in[RFC4571] <#RFC4571>. and so on for other proto identifiers *- The security considerations seem inadequate. Most, if not all, of the proto values listed here refer to some other RFC that has it's own security considerations. So it doesn't really seem true to say there are no considerations other than those in 4566.* [Suhas] The new security considerations sections is as below " 6. <#rfc.section.6> Security Considerations <#sec.security> The new "proto" identifiers registered by this document in the SDP parameters registry maintained by IANA is primarily for use by the offer/answer model of the Session Description Protocol[RFC3264] <#RFC3264> for the negotiation and establishment of RTP based Media over the TCP transport. This specification doesn't introduce any additional security considerations beyond those specified by the individual transport protocols identified in the "proto" identifiers and those detailed in Section 7 of [RFC4566] <#RFC4566>. " Editorial (non-blocking): *- The abstract is long. The 2nd paragraph describes what the draft does. Can some or all of the first paragraph be relegated to the intro?* [Suhas] I have removed the first para from the abstract and moved it to the intro section. The new abstract is : " Abstract <#rfc.abstract> The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF' " *- 3: It would be helpful to mention that the transport protocol mentioned in the first paragraph goes in the field in the M-line.* [Suhas]. I updated the section 3 intro to have the follow new text " The 'm=' line in SDP specifies, among other items, the transport protocol *(identified via the 'proto' field)* to be used for the media in the session. See the "MediaDescriptions" section of SDP [RFC4566] <#RFC4566>for a discussion on transport protocol identifiers. " Please let me know if these edits look fine and I can produce a new version for further review. Cheers Suhas On Thu, Jan 14, 2016 at 2:12 PM, Ben Campbell wrote: > Hi, > > Here's my AD Evaluation of draft-ietf-mmusic-proto-iana-registration. I > have a couple of comments I'd like to resolve before last call, and a few > editorial comments.: > > Substantive (to be resolved before last call): > > - (This is really editorial, but I think there's a chance for confusion.) > The references in section 3 seem insufficient. Section 1 lists RFCs that > define most of all of the related transport protocol profiles. For example, > [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That information > should probably also go in section 3, since that's the section referenced > by the IANA considerations section. To avoid duplication, consider moving > the bits after the first paragraph of section 1 into the respective > subsections of 3. > > - The security considerations seem inadequate. Most, if not all, of the > proto values listed here refer to some other RFC that has it's own security > considerations. So it doesn't really seem true to say there are no > considerations other than those in 4566. > > Editorial (non-blocking): > > - The abstract is long. The 2nd paragraph describes what the draft does. > Can some or all of the first paragraph be relegated to the intro? > > - 3: It would be helpful to mention that the transport protocol mentioned > in the first paragraph goes in the field in the M-line. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1140f59c19e0f10529a4af10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben

=C2=A0Thanks for the review. = Please see below for the resolutions =C2=A0on your comments (marked in bold= ).


Substantive (to be resolved before last call):

<= b>- (This is really editorial, but I think there's a chance for confusi= on.) The references in section 3 seem insufficient. Section 1 lists RFCs th= at define most of all of the related transport protocol profiles. For examp= le, [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That informa= tion should probably also go in section 3, since that's the section ref= erenced by the IANA considerations section. To avoid duplication, consider = moving the bits after the first paragraph of section 1 into the respective = subsections of 3.

[Suhas] Removed the d= etailed proto descriptions from Section 1 and moved them to individual sect= ions in Section 3.

Now the Section1 just has the f= ollowing para regarding the identifiers.

"
This specification describes additional SD= P transport protocol identifiers for transporting RTP Media over TCP as def= ined in=C2=A0Section 3.
"


and Section 3 has been updated =C2=A0to have template = as below

"
3.1.=C2=A0The TCP/RTP/A= VPF transport describes RTP Media with RTCP-based Feedback=C2=A0[RFC4585]=C2=A0over TCP.

It is realized as described below:

  • RTP/AVPF stream over the TCP transport is realized us= ing the framing method defined in[RFC4571].

3.2.=C2=A0TCP/RTP/SAVP Transport Realization

The TCP/= RTP/SAVP transport describes Secure RTP (SRTP) Media=C2=A0[RFC3711]=C2=A0over TCP.

I= t is realized as described below:

  • RTP/SAVP stream over the TCP transport is realized using th= e framing method defined in[RFC4571].


and so on for other proto identifiers=



- The security considerations seem inadequate. Most, = if not all, of the proto values listed here refer to some other RFC that ha= s it's own security considerations. So it doesn't really seem true = to say there are no considerations other than those in 4566.
=

[Suhas] The new security considerations sections = is as below
"

6.=C2=A0Security Considera= tions

The new "proto" identifiers registered by this= document in the SDP parameters registry maintained by IANA is primarily fo= r use by the offer/answer model of the Session Description Protocol[RFC3264]=C2=A0for the neg= otiation and establishment of RTP based Media over the TCP transport. This = specification doesn't introduce any additional security considerations = beyond those specified by the individual transport protocols identified in = the "proto" identifiers and those detailed in Section 7 of[RFC4566].

&= quot;

Editorial (= non-blocking):

- The abstract is long. The 2nd= paragraph describes what the draft does. Can some or all of the first para= graph be relegated to the intro?
<= br>[Suhas] I have removed the first para from the abstract and moved it to = the intro section. The new abstract is :

"


"


Please let me know if these edits loo= k fine and I can produce a new version for further review.


Cheers
Suhas

On Thu, Jan 14, 2016 at 2:12 PM, B= en Campbell <ben@nostrum.com> wrote:
Hi,

Here's my AD Evaluation of draft-ietf-mmusic-proto-iana-registration. I= have a couple of comments I'd like to resolve before last call, and a = few editorial comments.:

Substantive (to be resolved before last call):

- (This is really editorial, but I think there's a chance for confusion= .) The references in section 3 seem insufficient. Section 1 lists RFCs that= define most of all of the related transport protocol profiles. For example= , [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That informati= on should probably also go in section 3, since that's the section refer= enced by the IANA considerations section. To avoid duplication, consider mo= ving the bits after the first paragraph of section 1 into the respective su= bsections of 3.

- The security considerations seem inadequate. Most, if not all, of the pro= to values listed here refer to some other RFC that has it's own securit= y considerations. So it doesn't really seem true to say there are no co= nsiderations other than those in 4566.

Editorial (non-blocking):

- The abstract is long. The 2nd paragraph describes what the draft does. Ca= n some or all of the first paragraph be relegated to the intro?

- 3: It would be helpful to mention that the transport protocol mentioned i= n the first paragraph goes in the <proto> field in the M-line.

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

--001a1140f59c19e0f10529a4af10-- From nobody Mon Jan 18 20:46:02 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15E71A9041 for ; Mon, 18 Jan 2016 20:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5ul9k90lsPX for ; Mon, 18 Jan 2016 20:45:58 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 DAA681A903E for ; Mon, 18 Jan 2016 20:45:57 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id n1so187589995vkb.3 for ; Mon, 18 Jan 2016 20:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=acp1+lX4pI2hQThpC3EIJvKBYgN9hWXj9DxO9zt0niM=; b=P69Gds3Jah3WHH17veathJS74DO79OP5Xv1CK4hiE4u7fi20troTx7kzX80/NMC0K0 /aQml877YFQLkIWi+BzOCfq3RjoSJZVAklSQg3hAn6PvKBLTKBmj90NAcdru1kIettmq dfk46+Vsvo7Ic/A+ujqOxWBrPvWryHyedosGdO5R6CSeazN9J47/h5fYmOQOBRkckiRI 5aFN/BcE14zxUlYUBVSU/z9Ooow2h3FHXoBPM/RCOnVAxoAQaXgzqMsAuQVngEzOw/Oy /Uv4olXhBQLlyqi4bkE+Qg4fpQ2OSJFi2w44cRMyxNHfeuh6k+Zdk3ef0FOErfX1IvwT G0xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=acp1+lX4pI2hQThpC3EIJvKBYgN9hWXj9DxO9zt0niM=; b=DUR1uDNyjBYkifMU6bR3vAHvSiVbchYEapVvdRIsSDy+kgqktyiM8xKfQAkziw0t/3 dQvF78ggeUi4fsrpCJGsbC12VLu0KAsU4gQXiarJhG7OjavMlFRcP2PygDAmLbLmr4NZ OZGd/sz6iOBXQ0Tgx1wlFpkfr5Kec3jyztus70juUN2ovDN+dmJ47CVhFT+n5VGSX2hV WhOK/U4WV//oiXMR+djIQXKSXi2MZYLK/eQ5vSy7YZZFvgTJ2SjsQWfqyV2wlBHod0ho R9MQOWRiE6NLwlGT5R0bVjbtSDoFJwfyahbv2sIjCF8d8hiwYp9fJST/wwOlU1Y+/lYZ Q3xQ== X-Gm-Message-State: ALoCoQlNonhT5jyoRCMGpQ1TLMlsAuF5IKELGgd9/7Yv6Ib1jxq/AkkIZcKMJWfej9bUNDHtlAb2VWI8JZ5Suud5ln0fZcjmiw== MIME-Version: 1.0 X-Received: by 10.31.166.208 with SMTP id p199mr19180554vke.122.1453178756970; Mon, 18 Jan 2016 20:45:56 -0800 (PST) Received: by 10.31.106.130 with HTTP; Mon, 18 Jan 2016 20:45:56 -0800 (PST) In-Reply-To: References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D19CED@ESESSMB209.ericsson.se> Date: Mon, 18 Jan 2016 20:45:56 -0800 Message-ID: From: Suhas Nandakumar To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=001a11416fbc9abe9f0529a88b97 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 04:46:01 -0000 --001a11416fbc9abe9f0529a88b97 Content-Type: text/plain; charset=UTF-8 I agree with Taylor. The Mux draft assigns category "TRANSPORT" to the ICE candidates. So the candidate information from the "m=" line which corresponds to the BUNDLED m=line shall be considered for the entire group. As far as implementation is concerned, i think one should be fine just trickling the candidate information for the m=line selected for a given BUNDLE group and no need to copy it for the rest unless there is a explicit need (Initial offer, plan to change the bundle group address, drop a m=line) to include different candidates. I would recommend we update the BUNDLE draft (if there is any confusion) to match the MUX draft unless people think otherwise. Hope this helps. Tanks Suhas On Fri, Jan 15, 2016 at 8:20 AM, Taylor Brandstetter wrote: > "candidate" is in the TRANSPORT category though, which doesn't prevent it > from being different in different media sections. It's the BUNDLE > negotiation draft that imposes the candidate duplication requirement, with > a combination of these two paragraphs: > > When the answerer selects a BUNDLE address for itself, referred to as > the answerer BUNDLE address, it MUST associate that address with each > bundled "m=" line within the created BUNDLE group in the answer. > > When an offerer or answerer associates a shared address (i.e. a > previously selected BUNDLE address) with one or more bundled "m=" > lines, it MUST associate identical ICE candidates (referred to as > shared ICE candidates) with each of those "m=" lines. > > > On Fri, Jan 15, 2016 at 4:29 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> There is also another issue: >> >> >> >> Some time ago, Peter Thatcher asked whether it is really needed to >> include the SDP candidate attributes in all bundled m- lines. >> >> >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg15331.html >> >> >> >> Looking at SDP attributes in general, I guess the question is: if an >> attribute belongs to IDENTICAL, does it need to be included in all m- lines >> within a BUNDLE group? >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* Suhas Nandakumar [mailto:suhasietf@gmail.com] >> *Sent:* 14. tammikuuta 2016 22:51 >> *To:* Christer Holmberg >> *Cc:* Bo Burman; mmusic WG; Taylor Brandstetter >> >> *Subject:* Re: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-mux-attributes-12.txt >> >> >> >> Thanks Christer for bringing this to our notice. I just responded to >> Taylor's clarification question and I don't think the response to his >> question changes any of the behavior for BUNDLE or MUX. >> >> >> >> Please let me know your thoughts on my response. >> >> >> >> Thanks >> >> Suhas >> >> >> >> On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> Hold on :) >> >> >> >> Some time ago there was a question from Taylor Brandstetter. Was that >> solved? The topic mentioned BUNDLE, but I think the question was also >> related to the sdp-mux-attribute draft. >> >> >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg15421.html >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman >> *Sent:* 14 January 2016 18:09 >> *To:* Suhas Nandakumar >> *Cc:* mmusic WG >> >> >> *Subject:* Re: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-mux-attributes-12.txt >> >> >> >> Thank you Suhas, >> >> >> >> I believe this version addresses all comments provided, has no remaining >> nits, and I thus intend to use it for the publication request. >> >> >> >> Cheers, >> >> /Bo >> >> MMUSIC co-chair >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org ] >> *On Behalf Of *Suhas Nandakumar >> *Sent:* den 14 januari 2016 15:34 >> *To:* internet-drafts@ietf.org >> *Cc:* mmusic WG; i-d-announce@ietf.org >> *Subject:* Re: [MMUSIC] I-D Action: >> draft-ietf-mmusic-sdp-mux-attributes-12.txt >> >> >> >> Hello All >> >> >> >> This version fixes couple of ID nits and updates the references to the >> latest RFCs. >> >> >> >> >> >> Cheers >> >> suhas >> >> >> >> On Thu, Jan 14, 2016 at 6:32 AM, 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 >> Working Group of the IETF. >> >> Title : A Framework for SDP Attributes when Multiplexing >> Author : Suhas Nandakumar >> Filename : draft-ietf-mmusic-sdp-mux-attributes-12.txt >> Pages : 96 >> Date : 2016-01-14 >> >> Abstract: >> The Session Description Protocol (SDP) provides mechanisms to >> describe attributes of multimedia sessions and of individual media >> streams (e.g., Real-time Transport Protocol (RTP) sessions) within a >> multimedia session. Typically media associated with individual media >> descriptions ("m=" lines) represent RTP sessions and are thus carried >> over individual underlying transport layer flows. For scenarios >> where SDP is used to negotiate the usage of single 5-tuple for >> sending and receiving media associated with multiple media >> descriptions, it is required to understand the semantic implications >> of the SDP attributes associated with the RTP Media Streams >> multiplexed over a single underlying transport layer flow. >> >> The purpose of this specification is to provide a framework for >> analyzing the multiplexing characteristics of SDP attributes. This >> specification also categorizes the existing SDP attributes based on >> the framework described herein. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-12 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> > > --001a11416fbc9abe9f0529a88b97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Taylor.=C2=A0

The Mux draf= t assigns category "TRANSPORT" to the ICE candidates. So the cand= idate information from the "m=3D" line which corresponds to the B= UNDLED m=3Dline shall be considered for the entire group.=C2=A0
<= br>
As far as implementation is concerned, i think one should be = fine just trickling the candidate information for the m=3Dline selected for= a given BUNDLE group and no need to copy it for the rest unless there is a= explicit need (Initial offer, plan to change the bundle group address, dro= p a m=3Dline) =C2=A0to include different candidates.

=C2=A0I would recommend we update the BUNDLE draft (if there is any conf= usion) to match the MUX draft unless people think otherwise.

=
Hope this helps.

Tanks
Suhas<= /div>




On Fri, Jan 15= , 2016 at 8:20 AM, Taylor Brandstetter <deadbeef@google.com> wrote:
"candidat= e" is in the TRANSPORT category though, which doesn't prevent it f= rom being different in different media sections. It's the BUNDLE negoti= ation draft that imposes the candidate duplication requirement, with a comb= ination of these two paragraphs:

   When the answerer selects a BUNDLE add=
ress for itself, referred to as
   the answerer BUNDLE address, it MUST associate that address with each
   bundled "m=3D" line within the created BUNDLE group in the ans=
wer.
   When an offerer or answerer associates a shared=
 address (i.e. a
   previously selected BUNDLE address) with one or more bundled "m=3D&=
quot;
   lines, it MUST associate identical ICE candidates (referred to as
   shared ICE candidates) with each of those "m=3D" lines.
<= div>

On Fri, Jan 15, 2016 at 4:29 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

There is also another issue:<= u>

=C2=A0

Some time ago, Peter Thatcher= asked whether it is really needed to include the SDP candidate attributes = in all bundled m- lines.

=C2=A0

http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg15331.html=

=C2=A0

Looking at SDP attributes in = general, I guess the question is: if an attribute belongs to IDENTICAL, doe= s it need to be included in all m- lines within a BUNDLE group?

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Suhas Nandakumar [mailto:suhasietf@gmail.com= ]
Sent: 14. tammikuuta 2016 22:51
To: Christer Holmberg
Cc: Bo Burman; mmusic WG; Taylor Brandstetter

Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Thanks Christer for bringing this to our notice. I j= ust responded to Taylor's clarification question and I don't =C2=A0= think the response to his question changes any of the behavior for BUNDLE o= r MUX.

=C2=A0

Please let me know your thoughts on my response.<= /u>

=C2=A0

Thanks

Suhas

=C2=A0

On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hold on :)

=C2=A0

Some time ago there was a que= stion from Taylor Brandstetter. Was that solved? The topic mentioned BUNDLE, but I think the question was also related to the sdp-mux= -attribute draft.

=C2=A0

http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg15421.html

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0=

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: 14 January 2016 18:09
To: Suhas Nandakumar <suhasietf@gmail.com>
Cc: mmusic WG <mmusic@ietf.org>=


Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Thank you Suhas,

=C2=A0

I believe this version addres= ses all comments provided, has no remaining nits, and I thus intend to use it for the publication request.

=C2=A0

Cheers,

/Bo

MMUSIC co-chair

=C2=A0

From: mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: den 14 januari 2016 15:34
To: in= ternet-drafts@ietf.org
Cc: mmusic WG; i-d-announce@ietf.org
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Hello All

=C2=A0

This version fixes couple of ID= nits and updates the references to the latest RFCs.

=C2=A0

=C2=A0

Cheers

suhas

=C2=A0

On Thu, Jan 14, 2016 at 6:32 AM= , <interne= t-drafts@ietf.org> wrote:<= /span>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-14

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 Typically media associated with indi= vidual media
=C2=A0 =C2=A0descriptions ("m=3D" lines) represent RTP sessions a= nd are thus carried
=C2=A0 =C2=A0over individual underlying transport layer flows.=C2=A0 For sc= enarios
=C2=A0 =C2=A0where SDP is used to negotiate the usage of single 5-tuple for=
=C2=A0 =C2=A0sending and receiving media associated with multiple media
=C2=A0 =C2=A0descriptions, it is required to understand the semantic implic= ations
=C2=A0 =C2=A0of the SDP attributes associated with the RTP Media Streams =C2=A0 =C2=A0multiplexed over a single underlying transport layer flow.

=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusi= c-sdp-mux-attributes/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mu= x-attributes-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-mmusic-sdp-mux-attributes-12


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

=C2=A0

=C2=A0



--001a11416fbc9abe9f0529a88b97-- From nobody Tue Jan 19 06:08:29 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC231B2F18; Tue, 19 Jan 2016 06:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXw57d9DClkp; Tue, 19 Jan 2016 06:08:25 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE331B2F17; Tue, 19 Jan 2016 06:08:24 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-34-569e43568edc Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.C7.04914.6534E965; Tue, 19 Jan 2016 15:08:22 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.247]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Tue, 19 Jan 2016 15:08:22 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE Thread-Index: AdFNOVt7kQ2pmkCTSmeGFH6bEUVINQAOMjAAACf50gAAA2qfQP//8cUA///uguCAABSOAP//7SWggAlTi4A= Date: Tue, 19 Jan 2016 14:08:21 +0000 Message-ID: <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.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: text/plain; charset="utf-8" Content-ID: <61EFC10A5CBE3049AB140A2E06F3092E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7jW6Y87wwg4Z7JhYXrz1ksvh2odZi 7fGbjBZTlz9msZhxYSqzxeID91kd2Dym/N7I6rFkyU8mj+Onr7N63JpSEMASxWWTkpqTWZZa pG+XwJUxc/d3loILrBWf3m5laWDcw9rFyMkhIWAicWPXRyhbTOLCvfVsXYxcHEIChxklts6+ ywzhLGGUePN7KQtIFZuArcST1n1gHSICsRJf171nAiliFrjEKPFozUb2LkYODmEBe4mPp6sg ahwkzvfPZIawkySO/1gLNodFQFXi5cQf7CA2L1D5uc1XoZb9ZJZ48/gkG8gcTgE/ie3HvEFq GIGu+35qDROIzSwgLnHryXwmiKsFJJbsOc8MYYtKvHz8D+obJYlFtz8zgYxhFtCUWL9LH6LV WmLmzM+MELaixJTuh1AnCEqcnPmEZQKj+CwkG2YhdM9C0j0LSfcsJN0LGFlXMYoWpxYX56Yb GeulFmUmFxfn5+nlpZZsYgRG6cEtv3V3MK5+7XiIUYCDUYmHtyBvbpgQa2JZcWXuIUYJDmYl Ed6HpvPChHhTEiurUovy44tKc1KLDzFKc7AoifMmyzSGCQmkJ5akZqemFqQWwWSZODilGhjN tvO9U3rKUbhN/oODSd/XHs5FIcmMKw6VenGKMDKcCAxsz63vKjKoW5L917fqkOepow7/v+18 Wxac/HEl15N5T51NDKpbmsTe96bkFJ5MXbzopbT0G4UP3l3x+T4nX8w9sLvCekHIplsCN9tf xPDOsDLh8bmkk3XwntEKiUPNef12cqEekUosxRmJhlrMRcWJAITzGk/OAgAA Archived-At: Cc: "snandaku@cisco.com" , Marc Petit-Huguenin , =?utf-8?B?8J+Uk0RhbiBXaW5n?= , "ice@ietf.org" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:08:26 -0000 SGksDQoNClRoaXMgc2VlbXMgbGlrZSBhIGdvb2Qgd2F5IGZvcndhcmQuDQoNCg0KQ2hlZXJzLA0K QXJpIChhcyBpbmRpdmlkdWFsKQ0KDQo+IE9uIDEzIEphbiAyMDE2LCBhdCAxOTowMSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0K PiBIaSwNCj4gIA0KPiBNeSBzdWdnZXN0aW9uIG9mIGxhY2sgb2YgYT1ydGNwIGlzOg0KPiAgDQo+ IC0gICAgICAgICAgSWYgYW4gUlRQIG5vbi05IHBvcnQgaXMgcHJvdmlkZWQsIHRoZSBSVENQIHBv cnQgaXMgUlRQKzENCj4gLSAgICAgICAgICBJZiBhbiBSVFAgOSAoZGlzYWJsZWQpIHBvcnQgaXMg cHJvdmlkZWQsIHRoZSBSVENQIHBvcnQgaXMgaW1wbGljaXRseSBhbHNvIGRpc2FibGVkDQo+ICAN Cj4gVGhlcmUgYXJlIG90aGVyIG1lY2hhbmlzbXMgdG8gaW5kaWNhdGUgdGhhdCBSVENQIHdvbuKA mXQgYmUgdXNlZCB0byBiZWdpbiB3aXRoLg0KPiAgDQo+IFJlZ2FyZHMsDQo+ICANCj4gQ2hyaXN0 ZXINCj4gIA0KDQo= From nobody Tue Jan 19 08:02:42 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87CC1B310B for ; Tue, 19 Jan 2016 08:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSbwnR4xeCb2 for ; Tue, 19 Jan 2016 08:02:35 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 2F29B1B3109 for ; Tue, 19 Jan 2016 08:02:35 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id 77so553879190ioc.2 for ; Tue, 19 Jan 2016 08:02:35 -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:date:message-id:subject:from:to :cc:content-type; bh=m7DAGFW/ovdncIWJ8DF0Ke7yhmczSACMOKDr1ahbEUc=; b=dMX22sfMkJMJ6B+gD8Ap3VAMizI5QZElqYMaid0oNiGzK7JZ11/rbnH2WaNwIn/9Xp bXYHYIgxJc1ShLXBerwzEnjZhj1AsUa6RImWPYB2BaVxcDhetyQ68PQcv/ptIm8MBqF0 kYU6NdjFXOSjo8qsTmWyQ4JgsIcooU9yJ1WXmC9u4q8/DVr7Xox23pNOy1X7KySG2aPT e+Qw1guYtswcKHktuUN5KMf0Ij3NZx9OUv3f02tQs5lPbJDxr7wngWW/QW8LhDTB5DLL PiaxvMLGA/N12XDkGgMbhz4p2Yniepbcn2GXEgw1TAFNW4ca4zyZZ+SE9YUhdxL5JNyK F1/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m7DAGFW/ovdncIWJ8DF0Ke7yhmczSACMOKDr1ahbEUc=; b=l8s/8Duo04JO/CAiNShwv+1ph9yJoQdbabHulgnLjUeZxReEhGD13yHzbhlSchNgpx SZpUkaYPtKbaTdEOr5hWz4HS8kI2sJrzChe14b9JW85d9guvN8wzXCMgUSMWO/mIlsxH 3KJvWuibI403Nwttn/1MfR+U3X2+mu1DfQG2j0qjYoZzmZy1Wo/21zw4CWTASw2tt9kF lKewhVQFsv8rjWQJ3DXV/ckQ/wViGN1ym2zsFQNTkbdQel9GInax5wuecILMHvF4sReT vP0I8L42KE4p6g6nfnZ96MmCu/CYMWnIv2RJ0p/dotgZozDI8sn3Q+vjHzNOZUHdbFkR HbYA== X-Gm-Message-State: ALoCoQlWAgl4UYaONoGlXfUyFWt/iJ3FrY6eOW30x7PkfTv6lm01l4D2kNE1Gl0vpn+N+l7yHxWBXRznFtC+Mwh2stjuCy3WzQ== X-Received: by 10.107.25.145 with SMTP id 139mr26361396ioz.89.1453219354564; Tue, 19 Jan 2016 08:02:34 -0800 (PST) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id h19sm7441859igq.6.2016.01.19.08.02.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jan 2016 08:02:32 -0800 (PST) Received: by mail-io0-f182.google.com with SMTP id 1so538341496ion.1; Tue, 19 Jan 2016 08:02:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.41.142 with SMTP id p136mr28771879iop.70.1453219352270; Tue, 19 Jan 2016 08:02:32 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 19 Jan 2016 08:02:32 -0800 (PST) In-Reply-To: <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> Date: Tue, 19 Jan 2016 11:02:32 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: multipart/alternative; boundary=001a1141f3e245e39b0529b1ff82 Archived-At: Cc: "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= , Christer Holmberg , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:02:39 -0000 --001a1141f3e245e39b0529b1ff82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Do you think the text that I have suggested for section 4.2 of draft-ietf-mmusic-ice-sip-sdp is enough: The default candidates are added to the SDP as the default destination for media. For streams based on RTP, this is done by placing the IP address and port of the RTP candidate into the c and m lines, respectively. *If the agent is utilizing RTCP and if RTCP * * candidate is present and not equal to the same address and * * the next higher port number of the RTP candidate, the agent MUST encode the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605 [RFC3605 ].* If RTCP is not in use, the agent MUST signal that using b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556 ]. Or do you think it need to have the language regarding RTP port 9 added as well? Based on the language that I am proposing if RTCP ICE candidate is not present, SDP rtcp attribute should not be present as well. This, of cause would be further updated by the Christer's draft for RTCP MUX required, which will state that SDP rtcp attribute can also be present when RTCP ICE candidate is not present but RTCP MUX is required. Regards, _____________ Roman Shpount On Tue, Jan 19, 2016 at 9:08 AM, Ari Ker=C3=A4nen wrote: > Hi, > > This seems like a good way forward. > > > Cheers, > Ari (as individual) > > > On 13 Jan 2016, at 19:01, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi, > > > > My suggestion of lack of a=3Drtcp is: > > > > - If an RTP non-9 port is provided, the RTCP port is RTP+1 > > - If an RTP 9 (disabled) port is provided, the RTCP port is > implicitly also disabled > > > > There are other mechanisms to indicate that RTCP won=E2=80=99t be used = to begin > with. > > > > Regards, > > > > Christer > > > > --001a1141f3e245e39b0529b1ff82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Do you think the text that I have s= uggested for section 4.2 =C2=A0of=C2=A0draft-ietf-mmusic-ice-sip-sdp is eno= ugh:

The default cand= idates are added to the SDP as the default
   destination for media.  For st=
reams based on RTP, this is done by
   placing the IP address and port of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP and if RTCP =

   candidate is present and not equ=
al to the same address and 
   t=
he next higher port number of the RTP candidate, the agent MUST encode
   the RTCP candidate using the a=3Drtcp attribute as defined in RFC 3605
   [RFC3605].  If RTCP is not in use, the agent=
 MUST signal that using
   b=3DRS:0 and b=3DRR:0 as defined in RFC 3556 [RFC3556].

Or do you think it need to have = the language regarding RTP port 9 added as well? Based on the language that= I am proposing if RTCP ICE candidate is not present, SDP rtcp attribute sh= ould not be present as well. This, of cause would be further updated by the= Christer's draft for RTCP MUX required, which will state that SDP rtcp= attribute can also be present when RTCP ICE candidate is not present but R= TCP MUX is required.

Regards,

_____________
Roman Shpount

On Tue, Jan 19, 2016 at 9:08 AM, Ari Ker=C3= =A4nen <ari.keranen@ericsson.com> wrote:
Hi,

This seems like a good way forward.


Cheers,
Ari (as individual)

> On 13 Jan 2016, at 19:01, Christer Holmberg <christer.holmberg@ericsson.com> wrote: >
> Hi,
>
> My suggestion of lack o= f a=3Drtcp is:
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If an RTP non-9 port is provided, = the RTCP port is RTP+1
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If an RTP 9 (disabled) port is pro= vided, the RTCP port is implicitly also disabled
>
> There are other mechanisms to indicate that RTCP won=E2=80=99t be used= to begin with.
>
> Regards,
>
> Christer
>


--001a1141f3e245e39b0529b1ff82-- From nobody Wed Jan 20 00:13:31 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38CC1B3290; Wed, 20 Jan 2016 00:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1Ev1zoji8gu; Wed, 20 Jan 2016 00:13:28 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA581B31EF; Wed, 20 Jan 2016 00:13:26 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-05-569f41a52e91 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D7.C6.30208.5A14F965; Wed, 20 Jan 2016 09:13:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 09:13:24 +0100 From: Christer Holmberg To: Roman Shpount , =?utf-8?B?QXJpIEtlcsOkbmVu?= Thread-Topic: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE Thread-Index: AQHRUsLbYoIO9Cdwkkm8RdxkvF2BKJ8C71IAgAEWIQA= Date: Wed, 20 Jan 2016 08:13:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D4C4FD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D4C4FDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7lu5Sx/lhBnM/CFlcvPaQyeLbhVqL tcdvMlpMXf6YxWLGhanMFosP3Gd1YPOY8nsjq8eSJT+ZPI6fvs7qcWtKQQBLFJdNSmpOZllq kb5dAlfG+q/zWQse1VQ07rnL1MC4pbKLkZNDQsBE4s7aUywQtpjEhXvr2boYuTiEBA4zSuyZ +4QRJCEksIRRYv4H2y5GDg42AQuJ7n/aIGERgQSJp/t+g9UzC1xhlNh3fTE7SEJYwF7i0ak+ FogiB4nz/TOZIWwriRu3toLVsAioSpxd+QHM5hXwlfg8sZcZYvE3FolD5/aANXMKBErsalzE BmIzAl33/dQaJhCbWUBc4taT+UwQVwtILNlznhnCFpV4+fgfK4StKPHx1T5GiPp8iba/r6GW CUqcnPmEZQKj6Cwko2YhKZuFpGwW0M/MApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWj aHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYJwe3PJbdQfj5TeOhxgFOBiVeHg3tM8LE2JNLCuu zD3EKMHBrCTCm6I/P0yINyWxsiq1KD++qDQntfgQozQHi5I4b5JMY5iQQHpiSWp2ampBahFM lomDU6qB0ePutf6Sgtlzr8zOKu+V/tsmYHZ5bsE99T+HHq96oRu/+cgUjQvee28xurlI6NaK iute2LsmSuwS5+119nkTnxxZaWEiqaPguEN7Y0O98YZd96+fMDdS17h2a1ra+cvbv2nopMw/ WnNd8FWzgmvFGrcPWxuFC3mXtC6oWsbuxvSNJ2rXqcqXHEosxRmJhlrMRcWJAIlEbZfPAgAA Archived-At: Cc: "snandaku@cisco.com" , Marc Petit-Huguenin , "mmusic@ietf.org" , =?utf-8?B?8J+Uk0RhbiBXaW5n?= , "ice@ietf.org" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 08:13:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D4C4FDESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCllvdXIgc3VnZ2VzdGVkIHRleHQgbG9va3Mgb2ssIGJ1dCBpdCBkb2VzIG5v dCBzb2x2ZSBteSBpc3N1ZSA6KSBJIHRoaW5rIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0LCBpZiB0 aGVyZSBpcyBubyBSVENQIGNhbmRpZGF0ZSwgdGhlIHNwZWMgZG9lcyBub3QgZGVmaW5lIHVzYWdl IG9mIHRoZSBTRFAgcnRjcCBhdHRyaWJ1dGUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZy b206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDE5LiB0 YW1taWt1dXRhIDIwMTYgMTg6MDMNClRvOiBBcmkgS2Vyw6RuZW4NCkNjOiBDaHJpc3RlciBIb2xt YmVyZzsgbW11c2ljQGlldGYub3JnOyDwn5STRGFuIFdpbmc7IGljZUBpZXRmLm9yZzsgTWFyYyBQ ZXRpdC1IdWd1ZW5pbjsgc25hbmRha3VAY2lzY28uY29tDQpTdWJqZWN0OiBSZTogW01NVVNJQ10g W0ljZV0gU0RQIHJ0Y3AgYXR0cmlidXRlIHdpdGggdHJpY2tsZSBJQ0UNCg0KSGksDQoNCkRvIHlv dSB0aGluayB0aGUgdGV4dCB0aGF0IEkgaGF2ZSBzdWdnZXN0ZWQgZm9yIHNlY3Rpb24gNC4yICBv ZiBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcCBpcyBlbm91Z2g6DQoNClRoZSBkZWZhdWx0 IGNhbmRpZGF0ZXMgYXJlIGFkZGVkIHRvIHRoZSBTRFAgYXMgdGhlIGRlZmF1bHQNCg0KICAgZGVz dGluYXRpb24gZm9yIG1lZGlhLiAgRm9yIHN0cmVhbXMgYmFzZWQgb24gUlRQLCB0aGlzIGlzIGRv bmUgYnkNCg0KICAgcGxhY2luZyB0aGUgSVAgYWRkcmVzcyBhbmQgcG9ydCBvZiB0aGUgUlRQIGNh bmRpZGF0ZSBpbnRvIHRoZSBjIGFuZCBtDQoNCiAgIGxpbmVzLCByZXNwZWN0aXZlbHkuICBJZiB0 aGUgYWdlbnQgaXMgdXRpbGl6aW5nIFJUQ1AgYW5kIGlmIFJUQ1ANCg0KICAgY2FuZGlkYXRlIGlz IHByZXNlbnQgYW5kIG5vdCBlcXVhbCB0byB0aGUgc2FtZSBhZGRyZXNzIGFuZA0KDQogICB0aGUg bmV4dCBoaWdoZXIgcG9ydCBudW1iZXIgb2YgdGhlIFJUUCBjYW5kaWRhdGUsIHRoZSBhZ2VudCBN VVNUIGVuY29kZQ0KDQogICB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRy aWJ1dGUgYXMgZGVmaW5lZCBpbiBSRkMgMzYwNTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMzYwNT4NCg0KICAgW1JGQzM2MDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2 MDU+XS4gIElmIFJUQ1AgaXMgbm90IGluIHVzZSwgdGhlIGFnZW50IE1VU1Qgc2lnbmFsIHRoYXQg dXNpbmcNCg0KICAgYj1SUzowIGFuZCBiPVJSOjAgYXMgZGVmaW5lZCBpbiBSRkMgMzU1NjxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1Nj4gW1JGQzM1NTY8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzM1NTY+XS4NCg0KT3IgZG8geW91IHRoaW5rIGl0IG5lZWQgdG8gaGF2 ZSB0aGUgbGFuZ3VhZ2UgcmVnYXJkaW5nIFJUUCBwb3J0IDkgYWRkZWQgYXMgd2VsbD8gQmFzZWQg b24gdGhlIGxhbmd1YWdlIHRoYXQgSSBhbSBwcm9wb3NpbmcgaWYgUlRDUCBJQ0UgY2FuZGlkYXRl IGlzIG5vdCBwcmVzZW50LCBTRFAgcnRjcCBhdHRyaWJ1dGUgc2hvdWxkIG5vdCBiZSBwcmVzZW50 IGFzIHdlbGwuIFRoaXMsIG9mIGNhdXNlIHdvdWxkIGJlIGZ1cnRoZXIgdXBkYXRlZCBieSB0aGUg Q2hyaXN0ZXIncyBkcmFmdCBmb3IgUlRDUCBNVVggcmVxdWlyZWQsIHdoaWNoIHdpbGwgc3RhdGUg dGhhdCBTRFAgcnRjcCBhdHRyaWJ1dGUgY2FuIGFsc28gYmUgcHJlc2VudCB3aGVuIFJUQ1AgSUNF IGNhbmRpZGF0ZSBpcyBub3QgcHJlc2VudCBidXQgUlRDUCBNVVggaXMgcmVxdWlyZWQuDQoNClJl Z2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVHVlLCBKYW4gMTks IDIwMTYgYXQgOTowOCBBTSwgQXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb208 bWFpbHRvOmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNClRoaXMgc2Vl bXMgbGlrZSBhIGdvb2Qgd2F5IGZvcndhcmQuDQoNCg0KQ2hlZXJzLA0KQXJpIChhcyBpbmRpdmlk dWFsKQ0KDQo+IE9uIDEzIEphbiAyMDE2LCBhdCAxOTowMSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQo+DQo+IEhpLA0KPg0KPiBNeSBzdWdnZXN0aW9uIG9mIGxhY2sg b2YgYT1ydGNwIGlzOg0KPg0KPiAtICAgICAgICAgIElmIGFuIFJUUCBub24tOSBwb3J0IGlzIHBy b3ZpZGVkLCB0aGUgUlRDUCBwb3J0IGlzIFJUUCsxDQo+IC0gICAgICAgICAgSWYgYW4gUlRQIDkg KGRpc2FibGVkKSBwb3J0IGlzIHByb3ZpZGVkLCB0aGUgUlRDUCBwb3J0IGlzIGltcGxpY2l0bHkg YWxzbyBkaXNhYmxlZA0KPg0KPiBUaGVyZSBhcmUgb3RoZXIgbWVjaGFuaXNtcyB0byBpbmRpY2F0 ZSB0aGF0IFJUQ1Agd29u4oCZdCBiZSB1c2VkIHRvIGJlZ2luIHdpdGguDQo+DQo+IFJlZ2FyZHMs DQo+DQo+IENocmlzdGVyDQo+DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37D4C4FDESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIFN5bWJvbCI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpGSTt9DQpzcGFuLmltDQoJe21zby1zdHlsZS1uYW1lOmltO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBj bSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb21hbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Zb3VyIHN1Z2dlc3RlZCB0ZXh0IGxvb2tzIG9rLCBidXQgaXQgZG9lcyBu b3Qgc29sdmUgbXkgaXNzdWUgOikgSSB0aGluayBpdCBzaG91bGQgYmUgY2xlYXIgdGhhdCwgaWYg dGhlcmUgaXMgbm8gUlRDUCBjYW5kaWRhdGUsIHRoZSBzcGVjIGRvZXMgbm90DQogZGVmaW5lIHVz YWdlIG9mIHRoZSBTRFAgcnRjcCBhdHRyaWJ1dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNo cmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9t YW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTkuIHRhbW1pa3V1dGEgMjAxNiAx ODowMzxicj4NCjxiPlRvOjwvYj4gQXJpIEtlcsOkbmVuPGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3Rl ciBIb2xtYmVyZzsgbW11c2ljQGlldGYub3JnOyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIFN5bWJvbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7wn5STPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGFuIFdpbmc7IGljZUBpZXRmLm9yZzsgTWFyYyBQZXRp dC1IdWd1ZW5pbjsNCiBzbmFuZGFrdUBjaXNjby5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtNTVVTSUNdIFtJY2VdIFNEUCBydGNwIGF0dHJpYnV0ZSB3aXRoIHRyaWNrbGUgSUNFPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgdGhpbmsgdGhlIHRleHQgdGhhdCBJIGhh dmUgc3VnZ2VzdGVkIGZvciBzZWN0aW9uIDQuMiAmbmJzcDtvZiZuYnNwO2RyYWZ0LWlldGYtbW11 c2ljLWljZS1zaXAtc2RwIGlzIGVub3VnaDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj5UaGUgZGVmYXVsdCBjYW5kaWRhdGVzIGFyZSBhZGRlZCB0byB0aGUg U0RQIGFzIHRoZSBkZWZhdWx0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IGRlc3RpbmF0aW9uIGZvciBtZWRpYS4mbmJzcDsgRm9yIHN0cmVhbXMg YmFzZWQgb24gUlRQLCB0aGlzIGlzIGRvbmUgYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcGxhY2luZyB0aGUgSVAg YWRkcmVzcyBhbmQgcG9ydCBvZiB0aGUgUlRQIGNhbmRpZGF0ZSBpbnRvIHRoZSBjIGFuZCBtPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGxpbmVzLCByZXNwZWN0aXZlbHkuJm5ic3A7IDxiPklmIHRoZSBhZ2VudCBpcyB1 dGlsaXppbmcgUlRDUCBhbmQgaWYgUlRDUCA8L2I+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtjYW5kaWRhdGUgaXMgcHJlc2VudCBhbmQgbm90IGVxdWFs IHRvIHRoZSBzYW1lIGFkZHJlc3MgYW5kIDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnBy ZS13cmFwIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3Ro ZSBuZXh0IGhpZ2hlciBwb3J0IG51bWJlciBvZiB0aGUgUlRQIGNhbmRpZGF0ZSwgdGhlIGFnZW50 IE1VU1QgZW5jb2RlPG86cD48L286cD48L3NwYW4+PC9iPjwvcHJlPg0KPHByZT48Yj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcg dGhlIGE9cnRjcCBhdHRyaWJ1dGUgYXMgZGVmaW5lZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjMzYwNSIgdGFyZ2V0PSJfYmxhbmsiPlJGQyAzNjA1PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvYj48L3ByZT4NCjxwcmU+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMz NjA1IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O1JlYWwgVGltZSBDb250cm9sIFByb3Rv Y29sIChSVENQKSBhdHRyaWJ1dGUgaW4gU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQ KSZxdW90OyI+UkZDMzYwNTwvYT5dLjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgSWYgUlRDUCBpcyBub3QgaW4gdXNlLCB0aGUgYWdlbnQgTVVTVCBzaWduYWwgdGhh dCB1c2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBiPVJTOjAgYW5kIGI9UlI6MCBhcyBkZWZpbmVkIGluIDxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTU2IiB0YXJnZXQ9Il9ibGFuayI+ UkZDIDM1NTY8L2E+IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1 NiIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtTZXNzaW9uIERlc2NyaXB0aW9uIFByb3Rv Y29sIChTRFApIEJhbmR3aWR0aCBNb2RpZmllcnMgZm9yIFJUUCBDb250cm9sIFByb3RvY29sIChS VENQKSBCYW5kd2lkdGgmcXVvdDsiPlJGQzM1NTY8L2E+XS48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yIGRvIHlvdSB0aGluayBpdCBuZWVk IHRvIGhhdmUgdGhlIGxhbmd1YWdlIHJlZ2FyZGluZyBSVFAgcG9ydCA5IGFkZGVkIGFzIHdlbGw/ IEJhc2VkIG9uIHRoZSBsYW5ndWFnZSB0aGF0IEkgYW0gcHJvcG9zaW5nIGlmIFJUQ1AgSUNFIGNh bmRpZGF0ZSBpcyBub3QgcHJlc2VudCwgU0RQIHJ0Y3AgYXR0cmlidXRlIHNob3VsZCBub3QgYmUg cHJlc2VudCBhcyB3ZWxsLiBUaGlzLCBvZiBjYXVzZSB3b3VsZCBiZSBmdXJ0aGVyDQogdXBkYXRl ZCBieSB0aGUgQ2hyaXN0ZXIncyBkcmFmdCBmb3IgUlRDUCBNVVggcmVxdWlyZWQsIHdoaWNoIHdp bGwgc3RhdGUgdGhhdCBTRFAgcnRjcCBhdHRyaWJ1dGUgY2FuIGFsc28gYmUgcHJlc2VudCB3aGVu IFJUQ1AgSUNFIGNhbmRpZGF0ZSBpcyBub3QgcHJlc2VudCBidXQgUlRDUCBNVVggaXMgcmVxdWly ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxi cj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIEphbiAxOSwgMjAxNiBhdCA5OjA4IEFNLCBBcmkgS2Vyw6RuZW4gJmx0 OzxhIGhyZWY9Im1haWx0bzphcmkua2VyYW5lbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5hcmkua2VyYW5lbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NClRoaXMgc2VlbXMgbGlrZSBhIGdv b2Qgd2F5IGZvcndhcmQuPGJyPg0KPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCkFyaSAoYXMgaW5k aXZpZHVhbCk8YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgT24gMTMgSmFuIDIwMTYs IGF0IDE5OjAxLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDsgd3JvdGU6PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0Ozwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgSGksPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+ Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IE15IHN1Z2dlc3Rpb24gb2Yg bGFjayBvZiBhPXJ0Y3AgaXM6PGJyPg0KJmd0Ozxicj4NCiZndDsgLSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSWYgYW4gUlRQIG5vbi05IHBvcnQgaXMgcHJvdmlkZWQsIHRoZSBS VENQIHBvcnQgaXMgUlRQJiM0MzsxPGJyPg0KJmd0OyAtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBJZiBhbiBSVFAgOSAoZGlzYWJsZWQpIHBvcnQgaXMgcHJvdmlkZWQsIHRoZSBS VENQIHBvcnQgaXMgaW1wbGljaXRseSBhbHNvIGRpc2FibGVkPGJyPg0KJmd0Ozxicj4NCiZndDsg VGhlcmUgYXJlIG90aGVyIG1lY2hhbmlzbXMgdG8gaW5kaWNhdGUgdGhhdCBSVENQIHdvbuKAmXQg YmUgdXNlZCB0byBiZWdpbiB3aXRoLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0K Jmd0Ozxicj4NCiZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37D4C4FDESESSMB209erics_-- From nobody Wed Jan 20 08:30:10 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37771A90BA for ; Wed, 20 Jan 2016 08:30:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUS8We9EJJ99 for ; Wed, 20 Jan 2016 08:30:08 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D4C1A90E0 for ; Wed, 20 Jan 2016 08:29:45 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-a8-569fb5f7ee82 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6A.B4.05041.7F5BF965; Wed, 20 Jan 2016 17:29:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 17:29:43 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdw Date: Wed, 20 Jan 2016 16:29:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D4F561ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbE9Svf71vlhBrv71C2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAnfWlgK1mpWXH61mqWB8bRKFyMnh4SAicSqd4tYIWwxiQv3 1rN1MXJxCAkcZpSYeekcO4SzhFHiy/s7LF2MHBxsAhYS3f+0QRpEBNQlvu7tYQaxhQU0JRY8 WcEKEdeSWPRgHSOEbSSx7Vw7mM0ioCox7cJ0JhCbV8BXYsuMeWBxISB79YFP7CA2p4CfxIX9 29hAbEagg76fWgNWzywgLnHryXwmiEMFJJbsOc8MYYtKvHz8D+oBJYkV2y8xQtTnS3y6sY4d YpegxMmZT1gmMIrMQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU 4uLcdCMjvdSizOTi4vw8vbzUkk2MwBg6uOW31Q7Gg88dDzEKcDAq8fBuaJ8XJsSaWFZcmXuI UYKDWUmE13Lz/DAh3pTEyqrUovz4otKc1OJDjNIcLErivEkyjWFCAumJJanZqakFqUUwWSYO TqkGRt8TjVcsyo8EVMn8918z90nwzfAtseyWi/qe9TQLa+ptqHfRTw0/7yDtyrhMtMpFRGaS 5/yfT+dOZvhSq6xamma/++r5sMyCVy1FsRc2f235fT348+/aPrms5Uu/9s4t+B/Ss2xSROFM VrdPPPuXpXsX2j02EwxZ3vjWJKtaQzFHWm3Rvxh9JZbijERDLeai4kQAfNyhHp0CAAA= Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 16:30:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D4F561ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any opinions on whether BUNDLE should mandate support of mux-exclusive? Keep in mind that we are about to ship BUNDLE to IESG for publication soon.= .. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 18 January 2016 22:02 To: mmusic@ietf.org Cc: mmusic-chairs@ietf.org Subject: [MMUSIC] Draft new version: BUNDLE-25 Hi, I've submitted a new version (-25) of draft-ietf-mmusic-sdp-bundle-negotiat= ion. I have added text regarding mux-exclusive to the RTP/RTCP multiplexing chap= ter. However, as I wrote in another mail, I think we need to say whether support= of mux-exclusive is mandated by bundle entities. Currently we only mandate= support of RTP/RTCP multiplexing in general. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D4F561ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Any opinions on whethe= r BUNDLE should mandate support of mux-exclusive?

 

Keep in mind that we a= re about to ship BUNDLE to IESG for publication soon…

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 January 2016 22:02
To: mmusic@ietf.org
Cc: mmusic-chairs@ietf.org
Subject: [MMUSIC] Draft new version: BUNDLE-25

 

Hi,

 

I’ve submitted a new version (-25) of draft-ie= tf-mmusic-sdp-bundle-negotiation.

 

I have added text regarding mux-exclusive to the RTP= /RTCP multiplexing chapter.

 

However, as I wrote in another mail, I think we need= to say whether support of mux-exclusive is mandated by bundle entities. Cu= rrently we only mandate support of RTP/RTCP multiplexing in general.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D4F561ESESSMB209erics_-- From nobody Wed Jan 20 10:53:14 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD5B1ACD33 for ; Wed, 20 Jan 2016 10:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nZwaYh_ph24 for ; Wed, 20 Jan 2016 10:53:11 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F82E1ACD32 for ; Wed, 20 Jan 2016 10:53:10 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-12v.sys.comcast.net with comcast id 8Jsb1s0032JGN3p01JtAaq; Wed, 20 Jan 2016 18:53:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id 8Jt91s00K3KdFy101Jt9gy; Wed, 20 Jan 2016 18:53:10 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <569FD795.1010104@alum.mit.edu> Date: Wed, 20 Jan 2016 13:53:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453315990; bh=1vhRuP65RZkPYo/vKO52YEYM5YNMoVLeG8mG9Ek9yk0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pvnezt0tGIVnKD+AOZtlNgxUWfFUWm1E3Gb8KxLeVRgQP9Iu48I860/G+juhT8NAB VWS+TI56ZDAurKJQ3iyJwoCPzNEPX53nQIeI6mvhGDhPE1HCoSw7UHZMzPUWRLKxIv oYEhgLdETCd/iSaZHwwWsc8EzFcZ3owon61lgka7TzJNmszDsrfwb77+VqFX3+HIM9 LWjOszS5Ex1Nnp5dLGuAO1bQ6O0nLZkMxSs4crVbhSZwUmfDnqOqj+4e6acYmFjZ8y A4E+4vsXAYSCNMFaVlPCUvtar9LNFq663J3GpZsJEwCVzt7BxhggQtRQxD1wP3oS48 pGhEROmi0YvRA== Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 18:53:12 -0000 On 1/20/16 11:29 AM, Christer Holmberg wrote: > Any opinions on whether BUNDLE should mandate support of mux-exclusive? > > Keep in mind that we are about to ship BUNDLE to IESG for publication soon… Are you asking if bundle should have a normative dependency on mux-exclusive? If bundle itself mandates that multiplexing is required to be used for RTP, then it provides a parallel (separate but equal) mechanism for ensuring that fact, so a normative reference isn't required. Then there won't be a normative dependency between the drafts. Presumably you could still use the mux-exclusive mechanism with bundle if you wanted. Thanks, Paul > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 18 January 2016 22:02 > *To:* mmusic@ietf.org > *Cc:* mmusic-chairs@ietf.org > *Subject:* [MMUSIC] Draft new version: BUNDLE-25 > > Hi, > > I’ve submitted a new version (-25) of > draft-ietf-mmusic-sdp-bundle-negotiation. > > I have added text regarding mux-exclusive to the RTP/RTCP multiplexing > chapter. > > However, as I wrote in another mail, I think we need to say whether > support of mux-exclusive is mandated by bundle entities. Currently we > only mandate support of RTP/RTCP multiplexing in general. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Jan 20 11:56:26 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614781A8912 for ; Wed, 20 Jan 2016 11:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEuPOuVbjL4c for ; Wed, 20 Jan 2016 11:56:20 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 C8CD71A87C1 for ; Wed, 20 Jan 2016 11:56:20 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id t15so109914512igr.0 for ; Wed, 20 Jan 2016 11:56:20 -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:date:message-id:subject:from:to :cc:content-type; bh=7klmZoceVA/KcxabHDr+wB45Ha/rxoU563E5fRACWNk=; b=AEBJFEQtbCeuUQhdaDPChYAQhKHIVjyWfVa9wXzpHwaHMEQzG9qXrQv0DJ1D8DR4m7 OtYkKzf6wFJn3mU+OjnnutmCGg7zfg1PA2LXqfL6taVHUceaHRJGsSVqh0fgIIUI6wje dGhmJeRc9obZhieterPqbwAgFh3+IpliNaOO9mvDM9XoKWrRKVB4XHN5PBWSJN9NP1QY xYGnreLegibMEqbeEiZgqkoarHv2WpjpH9zYWyUe0WiW4xEdESCLdd6kki0pkfWw5n7j 1zQEtlVlG4TEk/CDQ7e45ee0xdLsoKnym/ShWEz/9WLXSRqMGEeUOZKDMH5s8r2lGY1D XshA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7klmZoceVA/KcxabHDr+wB45Ha/rxoU563E5fRACWNk=; b=WszQLaPhoueQypSYYA+q7Xk787LZh7oDAmo1L58K/7jut0O6t0uAJHLHPWDm9pNXuJ bCtOcu7LydFbxMO5GJJ/NusL4ckrvYB5jajPy/ryxsULoz7nYlkle7vH3QxUa3TjdVLz 5kf9YYk5f9bYaEzZI8lHTGjKGMwdO5VyMfQTprLITwc2jOKhS3k+ebUttOWPmUq9xGBQ uurWnOxYO/cRvOqyF9yxNDSWFJNMzQvZ4c+BHnyUipbvvO+3fqLmHtfgcAbiF3aAyen+ 4vLoYO19+YYNLTm9MST7g3pEdrMk3wwzJhjU5GxIKQ3DmVPEoTr3A66ahaE2Re8/BqFU kEKA== X-Gm-Message-State: AG10YORWL1PGYiYmwjEDY2K/lM1HtOuFStv1/0FIwPtBUkhaawgKvj1C6oANrzgxSCQFhw== X-Received: by 10.50.129.97 with SMTP id nv1mr5800460igb.0.1453319780168; Wed, 20 Jan 2016 11:56:20 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com. [209.85.213.181]) by smtp.gmail.com with ESMTPSA id r80sm12933563ioi.26.2016.01.20.11.56.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 11:56:18 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id h5so19121241igh.0; Wed, 20 Jan 2016 11:56:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.155.65 with SMTP id vu1mr1806862igb.2.1453319777956; Wed, 20 Jan 2016 11:56:17 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 20 Jan 2016 11:56:17 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D4C4FD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37D4C4FD@ESESSMB209.ericsson.se> Date: Wed, 20 Jan 2016 14:56:17 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113464101c41ac0529c96161 Archived-At: Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:56:25 -0000 --001a113464101c41ac0529c96161 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 20, 2016 at 3:13 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Your suggested text looks ok, but it does not solve my issue :) I think it > should be clear that, if there is no RTCP candidate, the spec does not > define usage of the SDP rtcp attribute. > > > Well, in my proposed text "*if RTCP candidate is present* and not equal to the same address and the next higher port number of the RTP candidate, the agent MUST encode the RTCP candidate using the a=rtcp attribute". Do you also want text saying that a=rtcp attribute MUST not be present of no RTCP candidates are present and rtcp-mux is not used? _____________ Roman Shpount --001a113464101c41ac0529c96161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 20, 2016 at 3:13 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Your suggested text looks ok, but it does no= t solve my issue :) I think it should be clear that, if there is no RTCP ca= ndidate, the spec does not define usage of the SDP rtcp attribute.



Well= , in my proposed text "if RTCP candidate is present and not equ= al to the same address and the next higher port number of the RTP candidate= , the agent MUST encode the RTCP candidate using the a=3Drtcp attribute&quo= t;. Do you also want text saying that a=3Drtcp attribute MUST not be presen= t of no RTCP candidates are present and rtcp-mux is not used?
_____________
Roman Shpount
=C2=A0=
--001a113464101c41ac0529c96161-- From nobody Wed Jan 20 12:01:11 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650E91A8790 for ; Wed, 20 Jan 2016 12:01:09 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VCa1avk1tP2 for ; Wed, 20 Jan 2016 12:01:07 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12A51A893C for ; Wed, 20 Jan 2016 12:01:04 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-6b-569fe77e68af Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AD.02.02707.E77EF965; Wed, 20 Jan 2016 21:01:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 21:01:01 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4A== Date: Wed, 20 Jan 2016 20:01:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> In-Reply-To: <569FD795.1010104@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7nG7d8/lhBpefGVhMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGkePLmQv28Vds/T2BpYHxMk8XIyeHhICJ xNUta9ggbDGJC/fWA9lcHEIChxkl+rpXMkE4Sxgl/kxZxdrFyMHBJmAh0f1PG6RBRMBX4tnj 22DNwgJGEr/3TGWFiBtLTNj3jB3CdpKYOXszE0gri4CqxMrDESBhXqDW08uvMEKM38wo8eHa EUaQGk4BHYk962xBahiB7vl+ag0TiM0sIC5x68l8Jog7BSSW7DnPDGGLSrx8/I8VwlaSWLH9 EiNEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFifl phsZ6aUWZSYXF+fn6eWllmxiBEbJwS2/DXYwvnzueIhRgINRiYfX4Ob8MCHWxLLiytxDjBIc zEoivHqPgEK8KYmVValF+fFFpTmpxYcYpTlYlMR5k2Qaw4QE0hNLUrNTUwtSi2CyTBycUg2M BSn9te0fxKuy40Tzb1rcn8Vi+kBes/jOw0xvCdUJT3ZcOdzNmVD9Jz3JaJOA18MJW/t+Sqi/ NHnpqXtttYnkMsnfP6W5raYpi4WdXFZ5kHW/uPKuabnnf5vP/uR+Kn1a6OsmQ79z6yfxVKW+ 2b8o6fF6meNZ/I9/KWc/35nduvJi8jZ+GUklJZbijERDLeai4kQASlUQxY4CAAA= Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:01:09 -0000 Hi, >> Any opinions on whether BUNDLE should mandate support of mux-exclusive? >> >> Keep in mind that we are about to ship BUNDLE to IESG for publication=20 >> soon... > > Are you asking if bundle should have a normative dependency on mux-exclus= ive? Yes. > If bundle itself mandates that multiplexing is required to be used for RT= P, then it provides a parallel (separate but equal) mechanism for > ensuring that fact, so a normative reference isn't required. Then there w= on't be a normative dependency between the drafts. Presumably=20 > you could still use the mux-exclusive mechanism with bundle if you wanted= . BUNDLE mandates multiplexing if the answerer keeps the m- line within the B= UNDLE group, and it's true that you don't need mux-exclusive for that.=20 But, mux-exclusive would mandate multiplexing even if the answerer moves th= e m- line out of the BUNDLE group, so the question is whether we want to ma= ndate support for that by BUNDLE entities. Regards, Christer > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer=20 > Holmberg > *Sent:* 18 January 2016 22:02 > *To:* mmusic@ietf.org > *Cc:* mmusic-chairs@ietf.org > *Subject:* [MMUSIC] Draft new version: BUNDLE-25 > > Hi, > > I've submitted a new version (-25) of > draft-ietf-mmusic-sdp-bundle-negotiation. > > I have added text regarding mux-exclusive to the RTP/RTCP multiplexing=20 > chapter. > > However, as I wrote in another mail, I think we need to say whether=20 > support of mux-exclusive is mandated by bundle entities. Currently we=20 > only mandate support of RTP/RTCP multiplexing in general. > > 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 From nobody Wed Jan 20 12:09:45 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746301A8920; Wed, 20 Jan 2016 12:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us36P2EWYcZo; Wed, 20 Jan 2016 12:09:40 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5651A8792; Wed, 20 Jan 2016 12:09:39 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-75-569fe981b892 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.B2.02707.189EF965; Wed, 20 Jan 2016 21:09:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 21:09:37 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE Thread-Index: AQHRUsLbYoIO9Cdwkkm8RdxkvF2BKJ8C71IAgAEWIQCAAL2DgIAAEsgQ Date: Wed, 20 Jan 2016 20:09:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D4FC90@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37D4C4FD@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7vW7jy/lhBl+/WFlcvPaQyeLbhVqL tcdvMlpMXf6YxWLGhanMFosP3Gd1YPOY8nsjq8eSJT+ZPI6fvs7qcWtKQQBLFJdNSmpOZllq kb5dAlfGnnPHmAvOcFZ0TXrF0sC4hrOLkZNDQsBEYuHyi4wQtpjEhXvr2boYuTiEBA4zSux4 NZMdJCEksIRR4tsy/S5GDg42AQuJ7n/aIGERAVWJv98nM4HUMwv0M0lMW3eNBSQhLGAv8ehU HwtEkYPE+f6ZzBC2m8TOTe/BbBag5mn7NrGC2LwCvhL3bk5nhljcyCZx+NRVNpAEp0CgREPz abDrGIGu+35qDROIzSwgLnHryXwmiKsFJJbsOc8MYYtKvHz8jxXCVpJYsf0SI8jRzAKaEut3 6UO0KkpM6X7IDrFXUOLkzCcsExjFZiGZOguhYxaSjllIOhYwsqxiFC1OLU7KTTcy0kstykwu Ls7P08tLLdnECIy6g1t+G+xgfPnc8RCjAAejEg+vwc35YUKsiWXFlbmHGCU4mJVEePUeAYV4 UxIrq1KL8uOLSnNSiw8xSnOwKInzJsk0hgkJpCeWpGanphakFsFkmTg4pRoYE6xLNObJSIeu Xj3JfWq2ys9Phl4BwiHLz7rKP9f7HuujkelYJTur1lL1w/ejeqJzMz3Dhbrn712R6HfVpf72 I93sLXe1k982Wm5UUjk1uXD+rmURsZJ8ExZvcdeoEP39dktq0jl9m5iupyyTNcuLxSc/j8n5 P+myJpOQ00WjU+8/TLmyY5uQEktxRqKhFnNRcSIAnFrHM7YCAAA= Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , =?utf-8?B?8J+Uk0RhbiBXaW5n?= , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:09:41 -0000 SGkgUm9tYW4sDQoNCj4+IFlvdXIgc3VnZ2VzdGVkIHRleHQgbG9va3Mgb2ssIGJ1dCBpdCBkb2Vz IG5vdCBzb2x2ZSBteSBpc3N1ZSA6KSBJIHRoaW5rIGl0IHNob3VsZCBiZSBjbGVhciANCj4+IHRo YXQsIGlmIHRoZXJlIGlzIG5vIFJUQ1AgY2FuZGlkYXRlLCB0aGUgc3BlYyBkb2VzIG5vdCBkZWZp bmUgdXNhZ2Ugb2YgdGhlIFNEUCBydGNwIGF0dHJpYnV0ZS4NCj4NCj4gV2VsbCwgaW4gbXkgcHJv cG9zZWQgdGV4dCAiaWYgUlRDUCBjYW5kaWRhdGUgaXMgcHJlc2VudCBhbmQgbm90IGVxdWFsIHRv IHRoZSBzYW1lIGFkZHJlc3MgYW5kIA0KPiB0aGUgbmV4dCBoaWdoZXIgcG9ydCBudW1iZXIgb2Yg dGhlIFJUUCBjYW5kaWRhdGUsIHRoZSBhZ2VudCBNVVNUIGVuY29kZSB0aGUgUlRDUCBjYW5kaWRh dGUgdXNpbmcgdGhlIGE9cnRjcCBhdHRyaWJ1dGUiLiANCj4gRG8geW91IGFsc28gd2FudCB0ZXh0 IHNheWluZyB0aGF0IGE9cnRjcCBhdHRyaWJ1dGUgTVVTVCBub3QgYmUgcHJlc2VudCBvZiBubyBS VENQIGNhbmRpZGF0ZXMgYXJlIHByZXNlbnQgYW5kIHJ0Y3AtbXV4IGlzIG5vdCB1c2VkPw0KDQpJ IGFtIG5vdCBzdXJlIHdlIG5lZWQgdG8gc2F5IGFueXRoaW5nIGFib3V0IG11eC4NCg0KV2hlbiBy ZWFkaW5nIHlvdXIgdGV4dCBhZ2FpbiwgSSBub3cgYWdyZWUgdGhhdCBpdCBjb3ZlcnMgbXkgY2Fz ZS4gSSBqdXN0IGhvcGUgaXQgaXMgY2xlYXIgZW5vdWdoIDopDQoNClBlcmhhcHMsIGluIHRoZSB0 cmlja2xlIElDRSBkb2N1bWVudCwgd2UgY291bGQgaGF2ZSBhIG5vdGUgc29tZXdoZXJlIGNsYXJp ZnlpbmcgdGhhdCB0aGUgUlRDUCBjYW5kaWRhdGUgaXMgbm90IHVzZWQgd2hlbiB0aGUgUlRQIHBv cnQgaXMgOS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KwqANCg== From nobody Wed Jan 20 12:12:10 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5F61A87F0; Wed, 20 Jan 2016 12:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ8ivyJ2_XU3; Wed, 20 Jan 2016 12:12:06 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4282D1A87E6; Wed, 20 Jan 2016 12:12:06 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-2c-569fea13331f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.BA.05041.31AEF965; Wed, 20 Jan 2016 21:12:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 21:12:03 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount Thread-Topic: [Ice] [MMUSIC] SDP rtcp attribute with trickle ICE Thread-Index: AQHRU76CIV1s/SPb/ESV0rR4QgcG/58E1fjw Date: Wed, 20 Jan 2016 20:12:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D4FCFD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37D4C4FD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4FC90@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D4FC90@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2J7iK7Iq/lhBhfyLS5ee8hk8e1CrcXa 4zcZLaYuf8xiMePCVGaLxQfuszqweUz5vZHVY8mSn0wex09fZ/W4NaUggCWKyyYlNSezLLVI 3y6BK+PF/0eMBccEK7pn3WdvYOwR7GLk5JAQMJGYdfYwO4QtJnHh3nq2LkYuDiGBw4wSR24d Y4VwljBKHH++FyjDwcEmYCHR/U8bpEFEIFriw4cFTCA1zAL9TBLdU98zgiSEBRwkpjyYzwhR 5Cgxe+dzNgjbSGLdi6OsIDaLgKrEofW3weK8Ar4SX3/tgFp2lE1iy553YEWcAn4SM/c2M4PY jEDnfT+1hgnEZhYQl7j1ZD4TxNkCEkv2nGeGsEUlXj7+xwphK0ms2H6JEeRoZgFNifW79CFa FSWmdD9kh9grKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxihanFhfnphsZ6aUWZSYXF+fn 6eWllmxiBEbdwS2/rXYwHnzueIhRgINRiYfX4Ob8MCHWxLLiytxDjBIczEoivHqPgEK8KYmV ValF+fFFpTmpxYcYpTlYlMR5k2Qaw4QE0hNLUrNTUwtSi2CyTBycUg2Mgis4+E6LTQ58dOea 3LaEgvUChlYeDfLcPu22L/2cs27NPDwzvqP2ItOds9taN0xbft7t3M006TL5xrDvXocKBP/K ck68esj5yD+NKRHnL27PXZE4LSw3b84t50Xb9CPT0yX6HC68W5JRpyFgK23+OqvzG5Ne+L3U JQHTX57mEQ+ZtFfAcWK6EktxRqKhFnNRcSIAZlHvZbYCAAA= Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , =?utf-8?B?8J+Uk0RhbiBXaW5n?= , "snandaku@cisco.com" Subject: Re: [MMUSIC] [Ice] SDP rtcp attribute with trickle ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:12:08 -0000 QW5vdGhlciwgbW9yZSBhZG1pbmlzdHJhdGl2ZSBpc3N1ZSwgaXMgdGhhdCB3ZSBhbHNvIHdvdWxk IG5lZWQgdG8gZ2V0IHRoaXMgY2hhbmdlIGludG8gSlNFUCBhbmQgdHJpY2tsZSBJQ0UuIFVubGVz cyBJIHJlbWVtYmVyIHdyb25nLCBib3RoIG9mIHRob3NlIHNwZWNzIGN1cnJlbnRseSByZWZlcmVu Y2VzIFJGQyA1MjQ1Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogSWNlIFttYWlsdG86aWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMjAgSmFudWFyeSAyMDE2IDIyOjEwDQpU bzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+DQpDYzogQXJpIEtlcsOkbmVuIDxh cmkua2VyYW5lbkBlcmljc3Nvbi5jb20+OyBtbXVzaWNAaWV0Zi5vcmc7IE1hcmMgUGV0aXQtSHVn dWVuaW4gPG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPjsgaWNlQGlldGYub3JnOyDwn5STRGFuIFdp bmcgPGR3aW5nQGNpc2NvLmNvbT47IHNuYW5kYWt1QGNpc2NvLmNvbQ0KU3ViamVjdDogUmU6IFtJ Y2VdIFtNTVVTSUNdIFNEUCBydGNwIGF0dHJpYnV0ZSB3aXRoIHRyaWNrbGUgSUNFDQoNCkhpIFJv bWFuLA0KDQo+PiBZb3VyIHN1Z2dlc3RlZCB0ZXh0IGxvb2tzIG9rLCBidXQgaXQgZG9lcyBub3Qg c29sdmUgbXkgaXNzdWUgOikgSSANCj4+IHRoaW5rIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0LCBp ZiB0aGVyZSBpcyBubyBSVENQIGNhbmRpZGF0ZSwgdGhlIHNwZWMgZG9lcyBub3QgZGVmaW5lIHVz YWdlIG9mIHRoZSBTRFAgcnRjcCBhdHRyaWJ1dGUuDQo+DQo+IFdlbGwsIGluIG15IHByb3Bvc2Vk IHRleHQgImlmIFJUQ1AgY2FuZGlkYXRlIGlzIHByZXNlbnQgYW5kIG5vdCBlcXVhbCANCj4gdG8g dGhlIHNhbWUgYWRkcmVzcyBhbmQgdGhlIG5leHQgaGlnaGVyIHBvcnQgbnVtYmVyIG9mIHRoZSBS VFAgY2FuZGlkYXRlLCB0aGUgYWdlbnQgTVVTVCBlbmNvZGUgdGhlIFJUQ1AgY2FuZGlkYXRlIHVz aW5nIHRoZSBhPXJ0Y3AgYXR0cmlidXRlIi4NCj4gRG8geW91IGFsc28gd2FudCB0ZXh0IHNheWlu ZyB0aGF0IGE9cnRjcCBhdHRyaWJ1dGUgTVVTVCBub3QgYmUgcHJlc2VudCBvZiBubyBSVENQIGNh bmRpZGF0ZXMgYXJlIHByZXNlbnQgYW5kIHJ0Y3AtbXV4IGlzIG5vdCB1c2VkPw0KDQpJIGFtIG5v dCBzdXJlIHdlIG5lZWQgdG8gc2F5IGFueXRoaW5nIGFib3V0IG11eC4NCg0KV2hlbiByZWFkaW5n IHlvdXIgdGV4dCBhZ2FpbiwgSSBub3cgYWdyZWUgdGhhdCBpdCBjb3ZlcnMgbXkgY2FzZS4gSSBq dXN0IGhvcGUgaXQgaXMgY2xlYXIgZW5vdWdoIDopDQoNClBlcmhhcHMsIGluIHRoZSB0cmlja2xl IElDRSBkb2N1bWVudCwgd2UgY291bGQgaGF2ZSBhIG5vdGUgc29tZXdoZXJlIGNsYXJpZnlpbmcg dGhhdCB0aGUgUlRDUCBjYW5kaWRhdGUgaXMgbm90IHVzZWQgd2hlbiB0aGUgUlRQIHBvcnQgaXMg OS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KwqANCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpJY2UgbWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQo= From nobody Wed Jan 20 12:25:34 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF6E1ACDE6 for ; Wed, 20 Jan 2016 12:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKSavDRtbtXg for ; Wed, 20 Jan 2016 12:25:31 -0800 (PST) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 788981ACDE5 for ; Wed, 20 Jan 2016 12:25:31 -0800 (PST) X-AuditID: 1207440c-f79e16d000002a6e-d5-569fed3ad0b5 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 1B.19.10862.A3DEF965; Wed, 20 Jan 2016 15:25:30 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u0KKPTwk026825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Jan 2016 15:25:30 -0500 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <569FED38.7060905@alum.mit.edu> Date: Wed, 20 Jan 2016 15:25:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixO6iqGv1dn6Ywd7VihYXZh5mtJi6/DGL A5PHr69X2TyWLPnJFMAUxW2TlFhSFpyZnqdvl8Cdse/KY+aCN/wVmz98Zm1gvMjTxcjJISFg InFsw1wmCFtM4sK99WxdjFwcQgKXGSU6Z2xgh3CeMkms3rScGaRKWMBIYlNjH1CCg0NEIEXi SBcjRM13RomXn96D1bAJaEnMOfSfBaSGV0BbYsm3FJAwi4CqxMn+5SwgtqhAmkT/i/tg5bwC ghInZz4Bi3MK+Ens3Lwe7CBmAVuJO3N3M0PY8hLb385hnsDIPwtJyywkZbOQlC1gZF7FKJeY U5qrm5uYmVOcmqxbnJyYl5dapGuol5tZopeaUrqJERKSPDsYv62TOcQowMGoxMNrcHN+mBBr YllxZe4hRkkOJiVR3lOvgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEePUeAeV4UxIrq1KL8mFS 0hwsSuK8qkvU/YQE0hNLUrNTUwtSi2CyMhwcShK8u0GGChalpqdWpGXmlCCkmTg4QYZzSYkU p+alpBYllpZkxIMiMr4YGJMgKR6gvQdA2nmLCxJzgaIQracYFaXEefeBJARAEhmleXBjYYnm FaM40JfCvBpvgKp4gEkKrvsV0GAmoMF7zcAGlyQipKQaGHOqV3MWzvo/49f0OubAE//r4l5w yXF+mvz8cmHtquOLfdw7PqfXii19fN7vl9OsqT43xIstP9komP/YK/LA4Ja2x9X5J35cm3w+ +HLDo+2XD1QXrn5l6SNZaM7guWjTzU+z/3mGeR+T33Wy+ppLnRGngvABsy+9h3esK/3rw5G9 /eDVG7EMP8uUWIozEg21mIuKEwEtJZw6DwMAAA== Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:25:33 -0000 On 1/20/16 3:01 PM, Christer Holmberg wrote: > Hi, > >>> Any opinions on whether BUNDLE should mandate support of mux-exclusive? >>> >>> Keep in mind that we are about to ship BUNDLE to IESG for publication >>> soon... >> >> Are you asking if bundle should have a normative dependency on mux-exclusive? > > Yes. > >> If bundle itself mandates that multiplexing is required to be used for RTP, then it provides a parallel (separate but equal) mechanism for >> ensuring that fact, so a normative reference isn't required. Then there won't be a normative dependency between the drafts. Presumably >> you could still use the mux-exclusive mechanism with bundle if you wanted. > > BUNDLE mandates multiplexing if the answerer keeps the m- line within the BUNDLE group, and it's true that you don't need mux-exclusive for that. > > But, mux-exclusive would mandate multiplexing even if the answerer moves the m- line out of the BUNDLE group, so the question is whether we want to mandate support for that by BUNDLE entities. Hmm. While trying to figure out how to answer you I think I see a problem with mux-exclusive - it provides no way to discover whether it is requested, supported, or used. So it is only useful when the involved parties agree to it out-of-band, or when dependency upon it is coupled to some other feature that is signaled. So coupling it to bundle would mean that it is negotiated along with bundle. Note, even then, it could apply to m-lines moved out of a bundle group as long as support for bundle was still negotiated. But if bundle wasn't supported in the answer then it wouldn't apply. So, I guess either it needs to be coupled to bundle, or else mux-exclusive should be updated to include some sort of signaling that it is supported. What this is coming down to is that the only totally safe way to offer an rtp session without reserving port+1 for rtcp is to negotiate the address/port with ICE, and avoid putting any in m=/c=. Thanks, Paul From nobody Wed Jan 20 13:15:12 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4C11ACED5 for ; Wed, 20 Jan 2016 13:15:10 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqrkUzc74QKz for ; Wed, 20 Jan 2016 13:15:07 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C571ACED4 for ; Wed, 20 Jan 2016 13:15:04 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-45-569ff8d59f0e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.CC.30208.5D8FF965; Wed, 20 Jan 2016 22:15:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 22:15:01 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4A= Date: Wed, 20 Jan 2016 21:15:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> In-Reply-To: <569FED38.7060905@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7hO61H/PDDBbM57KYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MrWtuMBV8F6to/TmFqYFxhVAXIweHhICJ xJrfNl2MnECmmMSFe+vZuhi5OIQEDjNKfDnVyw7hLGGUuDTxLTNIA5uAhUT3P22QBhEBX4ln j2+zgdjCAkYSv/dMZYWIG0tM2PeMHaRcRMBPYlK/E0iYRUBVYk3XPkYQmxeotfFKHyPE+JlM Eg93XWQCqecU0JG4fsAFpIYR6J7vp9YwgdjMAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/9YIWwl iRXbLzFC1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hx anFSbrqRsV5qUWZycXF+nl5easkmRmCMHNzyW3UH4+U3jocYBTgYlXh4DW7ODxNiTSwrrsw9 xCjBwawkwqv3CCjEm5JYWZValB9fVJqTWnyIUZqDRUmcN0mmMUxIID2xJDU7NbUgtQgmy8TB KdXA2CHazrpp9+l83dmKTtqGDJsUT3dztCfPuzy/4jNjcJRDupRnlcnX7M43dj9agzodu5OV eELuble6vVjlkWDFPYegifs2CVoL/0xrmvtsw7mgwyn9Hq4vd7zN3fxToVnJXlxsi86nP1Fb Lfg+HrrhXMFoXnVihWRwY8HqmXzfzQq8jYqm1R1WYinOSDTUYi4qTgQADJp8VY0CAAA= Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 21:15:10 -0000 Hi, >>>> Any opinions on whether BUNDLE should mandate support of mux-exclusive= ? >>>> >>>> Keep in mind that we are about to ship BUNDLE to IESG for=20 >>>> publication soon... >>> >>> Are you asking if bundle should have a normative dependency on mux-excl= usive? >> >> Yes. >> >>> If bundle itself mandates that multiplexing is required to be used=20 >>> for RTP, then it provides a parallel (separate but equal) mechanism=20 >>> for ensuring that fact, so a normative reference isn't required. Then t= here won't be a normative dependency between=20 >>> the drafts. Presumably you could still use the mux-exclusive mechanism = with bundle if you wanted. >> >> BUNDLE mandates multiplexing if the answerer keeps the m- line within th= e BUNDLE group, and it's true that you don't need mux-exclusive for that. >> >> But, mux-exclusive would mandate multiplexing even if the answerer moves= the m- line out of the BUNDLE group, so the question is whether we want to= mandate support for that by BUNDLE entities. > > Hmm. While trying to figure out how to answer you I think I see a problem= with mux-exclusive - it provides no way to discover whether=20 > it is requested, supported, or used. So it is only useful when the involv= ed parties agree to it out-of-band, or when dependency upon it is=20 > coupled to some other feature that is signaled. The currently suggested mechanism is to use the SDP rtcp attribute, contain= ing the same port value as for RTP, to indicate support. > So coupling it to bundle would mean that it is negotiated along with bund= le. You can still use mux-exclusive without BUNDLE. The question is whether a B= UNDLE entity should be required to support it. > Note, even then, it could apply to m-lines moved out of a bundle group as= long as support for bundle was still=20 > negotiated. But if bundle wasn't supported in the answer then it wouldn't= apply. Not sure I follow. If the answerer doesn't support BUNDLE it could still su= pport mux-exclusive. I am not suggesting that supporting mux-exclusive mand= ates supporting BUNDLE - I am asking whether supporting BUNDLE mandates sup= porting mux-exclusive :) > So, I guess either it needs to be coupled to bundle, or else mux-exclusiv= e should be updated to include some sort of signaling that it is supported. The currently suggested mechanism is to use the SDP rtcp attribute, with a = port value same as for RTP. > What this is coming down to is that the only totally safe way to offer an= rtp session without reserving port+1 for rtcp is to negotiate the address/= port with ICE, and avoid putting any in m=3D/c=3D. AFAIR both BUNDLE and ICE mandates support of the rtcp attribute. The issue comes up if the answerer does not support the rtcp attribute. But= , as we have discussed before, that issue already exists in RFC 3605.=20 Regards, Christer From nobody Wed Jan 20 14:05:00 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EEA1AD2A9 for ; Wed, 20 Jan 2016 14:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYTdntBo9orj for ; Wed, 20 Jan 2016 14:04:56 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89991AD291 for ; Wed, 20 Jan 2016 14:04:56 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-07v.sys.comcast.net with comcast id 8N1l1s00726dK1R01N4wwd; Wed, 20 Jan 2016 22:04:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id 8N4v1s00F3KdFy101N4vEV; Wed, 20 Jan 2016 22:04:55 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56A00486.8090303@alum.mit.edu> Date: Wed, 20 Jan 2016 17:04:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453327496; bh=J9sZTyyBAdvDPJ1ZRX2C8dxD+0hS+i+oIKd0s7pnLhI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ecesx2NVgTXTeCRZupdzbWYFvRi3cm55z82pvLIhZXaFSIvXEo2pKqDHgESmHshQi xEWNztIzWOfGcko9MsJ5Pad1Z9ftYeA3TMvyokAgvzSD0/oFGisI1xBtGEgye71lqt 3oNZ90G/Ov2D6hXYlewxwWgo084s+79bAN6VWWV8tBEk3dsOY8RZ3GxEDCRGg2nRJs lpMt5c81f0wxuWAIFpDq0ODdVKnea1iGT1dJj19yQRNgaVgTNNJb3lI2MeIm7QdVbJ 4rv/PyUClCUlQjeGWeEL/p+sE7MIVbTkZTQXhiHYBQ6BG5bhw+KVCqB6Noj7LACBMh DSkI1iE6CkrbQ== Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:04:58 -0000 On 1/20/16 4:15 PM, Christer Holmberg wrote: > Hi, > >>>>> Any opinions on whether BUNDLE should mandate support of mux-exclusive? >>>>> >>>>> Keep in mind that we are about to ship BUNDLE to IESG for >>>>> publication soon... >>>> >>>> Are you asking if bundle should have a normative dependency on mux-exclusive? >>> >>> Yes. >>> >>>> If bundle itself mandates that multiplexing is required to be used >>>> for RTP, then it provides a parallel (separate but equal) mechanism >>>> for ensuring that fact, so a normative reference isn't required. Then there won't be a normative dependency between >>>> the drafts. Presumably you could still use the mux-exclusive mechanism with bundle if you wanted. >>> >>> BUNDLE mandates multiplexing if the answerer keeps the m- line within the BUNDLE group, and it's true that you don't need mux-exclusive for that. >>> >>> But, mux-exclusive would mandate multiplexing even if the answerer moves the m- line out of the BUNDLE group, so the question is whether we want to mandate support for that by BUNDLE entities. >> >> Hmm. While trying to figure out how to answer you I think I see a problem with mux-exclusive - it provides no way to discover whether >> it is requested, supported, or used. So it is only useful when the involved parties agree to it out-of-band, or when dependency upon it is >> coupled to some other feature that is signaled. > > The currently suggested mechanism is to use the SDP rtcp attribute, containing the same port value as for RTP, to indicate support. The problem is, if you are doing this you haven't reserved port+1. If the answerer doesn't understand either bundle, or a=rtcp, then it will simply assume that rtcp will be on port+1. What is lacking is a way to signal mux-exclusive that doesn't result in rtcp being sent on an unassigned port. AFAIK the only way to assure that right now is to use c=0. That would "work", but then another O/A would be needed once rtcp-mux has been negotiated. >> So coupling it to bundle would mean that it is negotiated along with bundle. > > You can still use mux-exclusive without BUNDLE. The question is whether a BUNDLE entity should be required to support it. > >> Note, even then, it could apply to m-lines moved out of a bundle group as long as support for bundle was still >> negotiated. But if bundle wasn't supported in the answer then it wouldn't apply. > > Not sure I follow. If the answerer doesn't support BUNDLE it could still support mux-exclusive. I am not suggesting that supporting mux-exclusive mandates supporting BUNDLE - I am asking whether supporting BUNDLE mandates supporting mux-exclusive :) Yes, the answerer could support mux-exclusive and not bundle. But then you are in the position I just noted above: does the answerer support mux-exclusive? Or does the answerer not support either mux-excusive or the rtcp attribute? The signaling doesn't say. >> So, I guess either it needs to be coupled to bundle, or else mux-exclusive should be updated to include some sort of signaling that it is supported. > > The currently suggested mechanism is to use the SDP rtcp attribute, with a port value same as for RTP. > >> What this is coming down to is that the only totally safe way to offer an rtp session without reserving port+1 for rtcp is to negotiate the address/port with ICE, and avoid putting any in m=/c=. > > AFAIR both BUNDLE and ICE mandates support of the rtcp attribute. > > The issue comes up if the answerer does not support the rtcp attribute. But, as we have discussed before, that issue already exists in RFC 3605. But that is the crux of the problem. Thanks, Paul > Regards, > > Christer > > From nobody Wed Jan 20 14:20:49 2016 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 123851B2D9D; Fri, 15 Jan 2016 06:32:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160115143202.24003.14308.idtracker@ietfa.amsl.com> Date: Fri, 15 Jan 2016 06:32:02 -0800 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2016 14:20:48 -0800 Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, mmusic@ietf.org, ben@nostrum.com Subject: [MMUSIC] mmusic - New Meeting Session Request for IETF 95 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:32:02 -0000 A new meeting session request has just been submitted by Flemming Andreasen, a Chair of the mmusic working group. --------------------------------------------------------- Working Group Name: Multiparty Multimedia Session Control Area Name: Applications and Real-Time Area Session Requester: Flemming Andreasen Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: i2nsf dots core payload dispatch sipcore avtext avtcore rtcweb httpbis ice Second Priority: clue p2psip straw xrblock rmcat stir tram sfc sacm Special Requests: --------------------------------------------------------- From nobody Wed Jan 20 14:35:13 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18381B29D5 for ; Wed, 20 Jan 2016 14:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA_cHB0I_Yh9 for ; Wed, 20 Jan 2016 14:35:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924CC1B29D3 for ; Wed, 20 Jan 2016 14:35:07 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-5c-56a00b99876c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 22.25.05041.99B00A65; Wed, 20 Jan 2016 23:35:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 23:35:05 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4CAADVJAP//7W3A Date: Wed, 20 Jan 2016 22:35:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> In-Reply-To: <56A00486.8090303@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7h+5M7gVhBg37VCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj4fLdjAUb5SuOH1nB2MDYLtnFyMEhIWAi 0dEs08XICWSKSVy4t56ti5GLQ0jgMKPEm2XfmSCcJYwSNzd8ZQVpYBOwkOj+pw3SICLgK/Hs 8W02EFtYwEji956prBBxY4kJ+56xg5SLCERJHFykBBJmEVCVWDVnElg5L1Dri//bWSHG/2eS WPf+OQtIglNAR+LX7bnsIDYj0EHfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xQthK Eiu2X2KEqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRtHi 1OLi3HQjI73Uoszk4uL8PL281JJNjMAoObjlt9UOxoPPHQ8xCnAwKvHwGtycHybEmlhWXJl7 iFGCg1lJhFfvEVCINyWxsiq1KD++qDQntfgQozQHi5I4b5JMY5iQQHpiSWp2ampBahFMlomD U6qBcaHZrXybDudDD/zkGmcn3LF6+OqZfENCyZpT0eu8bibw5OTaMeqqfY3lXubAq/lr0ZaT Th49C0VeMmvpHd6ZFrJr9fxnfaxn51rsNnGzs8g1uS2zLOHg573mReG/o5wFhY1DLSLNp0rd X9rgdkNbYJWxpd8B3dn6PVcWBm+9GP58tt5D68XVSizFGYmGWsxFxYkAcOqLf44CAAA= Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:35:10 -0000 Hi, .... >>>>> If bundle itself mandates that multiplexing is required to be used=20 >>>>> for RTP, then it provides a parallel (separate but equal) mechanism=20 >>>>> for ensuring that fact, so a normative reference isn't required.=20 >>>>> Then there won't be a normative dependency between the drafts. Presum= ably you could still use the mux-exclusive mechanism with bundle if you wan= ted. >>>> >>>> BUNDLE mandates multiplexing if the answerer keeps the m- line within = the BUNDLE group, and it's true that you don't need mux-exclusive for that. >>>> >>>> But, mux-exclusive would mandate multiplexing even if the answerer mov= es the m- line out of the BUNDLE group, so the=20 >>>> question is whether we want to mandate support for that by BUNDLE enti= ties. >>> >>> Hmm. While trying to figure out how to answer you I think I see a=20 >>> problem with mux-exclusive - it provides no way to discover whether=20 >>> it is requested, supported, or used. So it is only useful when the invo= lved parties agree to it out-of-band, or when dependency upon it is coupled= to some other feature that is signaled. >> >> The currently suggested mechanism is to use the SDP rtcp attribute, cont= aining the same port value as for RTP, to indicate support. > > The problem is, if you are doing this you haven't reserved port+1. If the= answerer doesn't understand either=20 > bundle, or a=3Drtcp, then it will simply assume that rtcp will be on port= +1. What is lacking is a way to signal mux-exclusive=20 > that doesn't result in rtcp being sent on an unassigned port. Yes. But, you have the same problem even without mux-exclusive, if you want to u= se a non-port+1 for RTCP. There is no "Require header field" in SDP. I think this is a case where vendors simply will have to realize that they = need to support the SDP 'rtcp' attribute in order to make sure their stuff = work. I don't think it's a big problem in deployments, and it will eventual= ly go away. > AFAIK the only way to assure that right now is to use c=3D0. That would "= work", but then another O/A would be needed once rtcp-mux has been negotiat= ed. You can use c=3D0 if you want to be absolutely sure, but I don't think mux-= exclusive should mandate it (in that case RFC3605 should mandate it). Howev= er, we can point out the problem, and describe mechanisms to avoid it. >>> So coupling it to bundle would mean that it is negotiated along with bu= ndle. >> >> You can still use mux-exclusive without BUNDLE. The question is whether = a BUNDLE entity should be required to support it. >> >>> Note, even then, it could apply to m-lines moved out of a bundle=20 >>> group as long as support for bundle was still negotiated. But if bundle= wasn't supported in the answer then it wouldn't apply. >> >> Not sure I follow. If the answerer doesn't support BUNDLE it could=20 >> still support mux-exclusive. I am not suggesting that supporting=20 >> mux-exclusive mandates supporting BUNDLE - I am asking whether=20 >> supporting BUNDLE mandates supporting mux-exclusive :) > > Yes, the answerer could support mux-exclusive and not bundle. But then yo= u are in the position I just noted above: does the > answerer support mux-exclusive? Or does the answerer not support either m= ux-excusive or the rtcp attribute? The signaling doesn't say. If the answerer supports the rtcp attribute, it will see that the port numb= er is identical to the RTP port. So, either it will start sending RTCP on t= hat port, or it will not accept the m- line. People want to get away from reserving separate ports for RTP and RTCP, the= support of ICE is increasing as we speak, so I think this is a problem tha= t will be fixed by the market. We should not prevent it because of some end= points that we don't even know if they exist... You have to support the rtc= p attribute if you want to be able to communicate with an entity behind a N= AT. Regards, Christer From nobody Wed Jan 20 14:57:55 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510191A9127 for ; Wed, 20 Jan 2016 14:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uemsqIPRkREE for ; Wed, 20 Jan 2016 14:57:52 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE5A1B2A4D for ; Wed, 20 Jan 2016 14:57:49 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-12v.sys.comcast.net with comcast id 8Nxl1s001516pyw01NxoB1; Wed, 20 Jan 2016 22:57:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-08v.sys.comcast.net with comcast id 8Nxo1s0033KdFy101NxoKa; Wed, 20 Jan 2016 22:57:48 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56A010EB.9030201@alum.mit.edu> Date: Wed, 20 Jan 2016 17:57:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453330668; bh=ywcJSR7v9RDvL48lop0v8LxZ7lXTpB1OwA7Vzu/sn0s=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=FR9u8SoKTgdw1Lym6kI1GD9wRaKvDKxdgr4iVwumPnzSYcvfeL1vT1xSpIRMQzed2 HL0OK9ZBxPhlpucvEahLjui7njksME2+5kWnTJNScj50YuQ8ojEdqxw31l5EzbkIAm DW6GqqCG5nDiTNiG/tK5+4thEiLuReLxuor2sJ33HTYA+xUwwmRFxNfx22nzB7Rceu qF1WuQ52H7yJ5H64kitZcHlOxTyFe2OFDk0Ji9zpRC2Hjacms813NABm7tMdtdUklE kQC8Njwc+PdzMUdKIYsH9lExx44wPQR6zFlFTdbnMzq2kOoQUBvrLOiSdiBe/92pwB 0KOkmisLoPJKA== Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:57:53 -0000 On 1/20/16 5:35 PM, Christer Holmberg wrote: >> The problem is, if you are doing this you haven't reserved port+1. If the answerer doesn't understand either >> bundle, or a=rtcp, then it will simply assume that rtcp will be on port+1. What is lacking is a way to signal mux-exclusive >> that doesn't result in rtcp being sent on an unassigned port. > > Yes. > > But, you have the same problem even without mux-exclusive, if you want to use a non-port+1 for RTCP. There is no "Require header field" in SDP. > > I think this is a case where vendors simply will have to realize that they need to support the SDP 'rtcp' attribute in order to make sure their stuff work. I don't think it's a big problem in deployments, and it will eventually go away. ... > People want to get away from reserving separate ports for RTP and RTCP, the support of ICE is increasing as we speak, so I think this is a problem that will be fixed by the market. We should not prevent it because of some endpoints that we don't even know if they exist... You have to support the rtcp attribute if you want to be able to communicate with an entity behind a NAT. I'm not sure what the right path is here. If you don't reserve port+1, and the other end fails to support the rtcp attribute, then you have rtcp going to an unassigned port. You might get lucky, and then it won't hurt *you*. But maybe it is hitting some unrelated app on the same IP. With NAT boxes in the way it might end up hitting some other app on a different IP. If the offerer detects that this has happened it could take a recovery action: either offer again with a port pair, or offer again disabling the media line in question. This assumes that the offerer can detect it. Unfortunately 3605 didn't even define the O/A semantics, or provide a way to indicate that the answerer accepted the attribute. It need not be used symmetrically. So I guess you are suggesting that support for 3605 for any user of sdp with rtp transport. And we will assume that is fully deployed. If that is the path forward, then I think it needs some sort of extraordinary process to bless that. I don't know what it is. But I bet it involves the IESG. Thanks, Paul From nobody Wed Jan 20 15:53:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B2B1B2AF3 for ; Wed, 20 Jan 2016 15:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFXFjXW3SLCr for ; Wed, 20 Jan 2016 15:53:50 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 6851D1B2AF5 for ; Wed, 20 Jan 2016 15:53:50 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id ik10so112363925igb.1 for ; Wed, 20 Jan 2016 15:53:50 -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:date:message-id:subject:from:to :cc:content-type; bh=mdYMH5pQ+sxqPWVmC8s78gCVN4nQ55c8xJtNLBszoAo=; b=ws7OYJmzzXddU6iaJFEeL+ulM3q7Qu2GCaph2Zpa3Bs+r8crjzgCvgfL0bxjxHzKAj zhzjVMF0kM/yuA3kPMwJhCX6RY2BBRkaU+NO9T9QV5HVUWjJYhZUezJ1KHVG+jOspCzL t5CxhLFveo6Bmtc8GTVtMSXckG3cGVA7wqz4aCG+M/qsRc5feZ7w2AzrZAV7jMRnmd5K EY66po2iC3OWpH72usQ7Tg+nyO/q7GyWtQoFXxeS5fonrZu4GHpsYX9yi1q9r93kjuTE PdqTm7M1T5ugQaLJJ6KX/IqzOaaFHmseOGqY6XELqc5afTvoQgZi+Wj9QVXMHMfIAC8L UReQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mdYMH5pQ+sxqPWVmC8s78gCVN4nQ55c8xJtNLBszoAo=; b=jQzeyPc/uVjbL3YmUJFsB0Ko0mXyoy7npyTzEXtWzLwbpp2pwaKZMS0J0EZ3iqT7dQ 1MEv2XzyT8BD2I60YJTdHX+0n0z3cT31n897off8CmINb5zGbSBW4K2x6fww76ULlrDB 4TUlMmYHRTgzi4ca7++W061uvCCIVcqOFKuR3p2HQDIFYx7diM8ql2F8weSFJcOKBuGk oAj0nQjHwky0DxQghQoBkQOUd/qCd6kWN5lXVLfnuNAoq5osdAfwzhDDMeSs+orQ6N4h S65y/PKTKj9F04SM7rt/tByG4tQwr1jL/1t2+ZL48Q/fyQFPR6TsZ2/+EP2XMR9zNvj4 Y0uw== X-Gm-Message-State: AG10YOTLFGlCATZwVx31Qeqx0szPwLGar21Mcpf74FMX5gsJ6qWysJOwNqm5dbrCuV9aSQ== X-Received: by 10.50.88.72 with SMTP id be8mr6072645igb.45.1453334029602; Wed, 20 Jan 2016 15:53:49 -0800 (PST) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id j136sm169106ioj.32.2016.01.20.15.53.47 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 15:53:47 -0800 (PST) Received: by mail-io0-f180.google.com with SMTP id 77so37218338ioc.2 for ; Wed, 20 Jan 2016 15:53:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.14.72 with SMTP id 69mr35528637ioo.145.1453334027219; Wed, 20 Jan 2016 15:53:47 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 20 Jan 2016 15:53:47 -0800 (PST) In-Reply-To: <56A010EB.9030201@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> Date: Wed, 20 Jan 2016 18:53:47 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113fcf0e6ebebb0529ccb21d Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 23:53:52 -0000 --001a113fcf0e6ebebb0529ccb21d Content-Type: text/plain; charset=UTF-8 On Wed, Jan 20, 2016 at 5:57 PM, Paul Kyzivat wrote: > I'm not sure what the right path is here. If you don't reserve port+1, and > the other end fails to support the rtcp attribute, then you have rtcp going > to an unassigned port. You might get lucky, and then it won't hurt *you*. > But maybe it is hitting some unrelated app on the same IP. With NAT boxes > in the way it might end up hitting some other app on a different IP. > > If the offerer detects that this has happened it could take a recovery > action: either offer again with a port pair, or offer again disabling the > media line in question. This assumes that the offerer can detect it. > > Unfortunately 3605 didn't even define the O/A semantics, or provide a way > to indicate that the answerer accepted the attribute. It need not be used > symmetrically. > > So I guess you are suggesting that support for 3605 for any user of sdp > with rtp transport. And we will assume that is fully deployed. > > If that is the path forward, then I think it needs some sort of > extraordinary process to bless that. I don't know what it is. But I bet it > involves the IESG. > > Another option is to support ICE only and drop support for non ICE end points. ICE support by both end points is easily detected. In order to prevent non-ICE end points from sending media to your end points, you can create an offer with c=0 and no a=rtcp with valid ICE candidates. If remote end point responds without ICE, the no media is sent and you can terminate the media session (or do another offer/answer for legacy). This is not legal according to the current ICE specification since it requires a valid IP in c= line and a=rtcp attribute. I think it would make sense to extend ICE to allow this. This is how WebRTC works. It is also how any end point on the publicly open IP network should work since this enables consent for sending media. So, the question I would ask, do we care about BUNDLE without ICE? If we do not, then all the a=rtcp related problems can be easily solved. _____________ Roman Shpount --001a113fcf0e6ebebb0529ccb21d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 20, 2016 at 5:57 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
I'm not sure what the right path is here. If you don't re= serve port+1, and the other end fails to support the rtcp attribute, then y= ou have rtcp going to an unassigned port. You might get lucky, and then it = won't hurt *you*. But maybe it is hitting some unrelated app on the sam= e IP. With NAT boxes in the way it might end up hitting some other app on a= different IP.

If the offerer detects that this has happened it could take a recovery acti= on: either offer again with a port pair, or offer again disabling the media= line in question. This assumes that the offerer can detect it.

Unfortunately 3605 didn't even define the O/A semantics, or provide a w= ay to indicate that the answerer accepted the attribute. It need not be use= d symmetrically.

So I guess you are suggesting that support for 3605 for any user of sdp wit= h rtp transport. And we will assume that is fully deployed.

If that is the path forward, then I think it needs some sort of extraordina= ry process to bless that. I don't know what it is. But I bet it involve= s the IESG.


Another option is to support ICE only = and drop support for non ICE end points. ICE support by both end points is = easily detected. In order to prevent non-ICE end points from sending media = to your end points, you can create an offer with c=3D0 and no a=3Drtcp with= valid ICE candidates. If remote end point responds without ICE, the no med= ia is sent and you can terminate the media session (or do another offer/ans= wer for legacy). This is not legal according to the current ICE specificati= on since it requires a valid IP in c=3D line and a=3Drtcp attribute.=C2=A0 = I think it would make sense to extend ICE to allow this. This is how WebRTC= works. It is also how any end point on the publicly open IP network should= work since this enables consent for sending media.

So, the question I would ask, do we care about BUNDLE without ICE? If we = do not, then all the a=3Drtcp related problems can be easily solved.=C2=A0<= /div>
_____________
Roman Shpount
=C2=A0
--001a113fcf0e6ebebb0529ccb21d-- From nobody Wed Jan 20 18:08:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DE41B2D1B for ; Wed, 20 Jan 2016 18:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHwwUhOsIvoi for ; Wed, 20 Jan 2016 18:08:51 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10431B2B83 for ; Wed, 20 Jan 2016 18:08:51 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with comcast id 8S8R1s00C2XD5SV01S8qS1; Thu, 21 Jan 2016 02:08:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id 8S8q1s0063KdFy101S8q2T; Thu, 21 Jan 2016 02:08:50 +0000 To: Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> From: Paul Kyzivat Message-ID: <56A03DB1.6070501@alum.mit.edu> Date: Wed, 20 Jan 2016 21:08:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453342130; bh=eXjDKGIcQ7sg7L7DpYj4CnkcCNc6sIUpLTle2g7jQzw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uuN6B022iwQRtVVLV/YjGzRyuuiQHqxyqxVaXb1h/RwNDvcaIr6Q5p/0YwWccp6TO hC7whFeAFMrJPEHrlusMd6q2W1S8Jk+15oimib/ly1pOcQTldW4M53lOHxXihA8MGz i07RxmWvX5/3utzvzvr7J4Tf9FsjbVuLGirqHCWjABppEepMBmU50Qp8PasXodMQ0R 8E4tbQXNkUKRKVOETF5cGOQaebOF5SiwEsb4zcEiQz3FXDdnzYYp6R+hDFJwvngKY7 Xr1U23hYPBR6LQj8a9oAMIh952Bt07VJ964RhIkAYkAjeen4ANciYMVQm3W2DNCHiR m4r/Lun1e+5rg== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 02:08:52 -0000 On 1/20/16 6:53 PM, Roman Shpount wrote: > So, the question I would ask, do we care about BUNDLE without ICE? If we > do not, then all the a=rtcp related problems can be easily solved. Well, CLUE has no reason to couple those. CLUE wants to have the possibility to interoperate with legacy endpoints, but it also will often have many media streams and so want to offer BUNDLE. In any case, this isn't really about bundle. The real issue is that 3605 is broken, and has been. Pretty much any offerer that has a need to use a=rtcp will break if the answerer doesn't support it. I expect that one action that could be taken is to file an errata against it. Thanks, Paul From nobody Wed Jan 20 23:16:33 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424211A010C for ; Wed, 20 Jan 2016 23:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zKQwOAtfhfu for ; Wed, 20 Jan 2016 23:16:30 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0CC1A0107 for ; Wed, 20 Jan 2016 23:16:29 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-13-56a085cb729b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D9.D0.04914.BC580A65; Thu, 21 Jan 2016 08:16:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 08:16:26 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4CAADVJAP//7W3AgAAhWYD//2ke4A== Date: Thu, 21 Jan 2016 07:16:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D51711@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> In-Reply-To: <56A010EB.9030201@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7lu7p1gVhBrN/qVhMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG4zNTGQs+iVYc+bmGuYFxumAXIyeHhICJ xL0tT9khbDGJC/fWs4HYQgKHGSWuLPbqYuQCspcwSixeP42xi5GDg03AQqL7nzZIjYiAr8Sz x7fB6oUFjCR+75nKChE3lpiw7xk7SLmIQJbEkl1ZIGEWAVWJ7i8vwVbxArV+3TOJEWL8U2aJ xrmbwXo5BXQk5h+7B2YzAt3z/dQaJhCbWUBc4taT+UwQdwpILNlznhnCFpV4+fgfK4StKHF1 +nKoeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLS7O TTcy1kstykwuLs7P08tLLdnECIySg1t+6+5gXP3a8RCjAAejEg+vwc35YUKsiWXFlbmHGCU4 mJVEeOVUFoQJ8aYkVlalFuXHF5XmpBYfYpTmYFES502WaQwTEkhPLEnNTk0tSC2CyTJxcEo1 MMrt5DPneHX8QkTx04pd6hczspxf9M+au/DzBZ/V05sXOF+paA6bkD/78ok3EqrSn2M1Em7P cHrOovLzL/eS39Fu5f4pot+9d07pjlHus/i03P4BW8ZOryUshoJf8v+1P3HbOiEyXel+/v6Q LKcpuqWn1iR/vzLZJKFURNiBV8E352uewqsnM5RYijMSDbWYi4oTAWVaT0eOAgAA Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 07:16:32 -0000 Hi, >>> The problem is, if you are doing this you haven't reserved port+1. If=20 >>> the answerer doesn't understand either bundle, or a=3Drtcp, then it=20 >>> will simply assume that rtcp will be on port+1. What is lacking is a wa= y to signal mux-exclusive that doesn't result in rtcp being sent on an unas= signed port. >> >> Yes. >> >> But, you have the same problem even without mux-exclusive, if you want t= o use a non-port+1 for RTCP. There is no "Require header field" in SDP. >> >> I think this is a case where vendors simply will have to realize that th= ey need to support the SDP 'rtcp' attribute in order to make sure their stu= ff work. I don't think it's a big problem in deployments, and it will event= ually go away. >>... >> People want to get away from reserving separate ports for RTP and RTCP, = the support of ICE is increasing as we speak, so I think this is a problem = that will be=20 >> fixed by the market. We should not prevent it because of some endpoints = that we don't even know if they exist... You have to support the rtcp attri= bute if you want to be able to communicate with an entity behind a NAT. > > I'm not sure what the right path is here. If you don't reserve port+1, an= d the other end fails to support the rtcp attribute, then you have rtcp goi= ng to an unassigned port. You might get lucky, and=20 > then it won't hurt *you*. But maybe it is hitting some unrelated app on t= he same IP.=20 > With NAT boxes in the way it might end up hitting some other app on a dif= ferent IP. Yes. > If the offerer detects that this has happened it could take a recovery > action: either offer again with a port pair, or offer again disabling the= media line in question. This assumes that the offerer can detect it. The offerer needs to be able to handle the scenario anyway, because malicio= us endpoints could send RTCP packets to whatever ports... Keep in mind that, at the end of the day, mux-exclusive is nothing more tha= n one single usage of RFC 3605. > Unfortunately 3605 didn't even define the O/A semantics, or provide a way= to indicate that the answerer accepted the attribute. It need not be used = symmetrically. > > So I guess you are suggesting that support for 3605 for any user of sdp w= ith rtp transport. And we will assume that is fully deployed. Correct.=20 But, I'd be interested in hearing if someone has a different view regarding= what is deployed. > If that is the path forward, then I think it needs some sort of extraordi= nary process to bless that. I don't know what it is. But I bet it involves = the IESG. I think we could document the assumption, and what can go wrong if the attr= ibute is not supported, and then it's acceptable. Regards, Christer From nobody Wed Jan 20 23:20:09 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856551A0114 for ; Wed, 20 Jan 2016 23:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63t4S_6sSwUa for ; Wed, 20 Jan 2016 23:20:07 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8D81A0110 for ; Wed, 20 Jan 2016 23:20:07 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-4b-56a086a5242f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 68.85.02707.5A680A65; Thu, 21 Jan 2016 08:20:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 08:20:05 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4CAADVJAP//7W3AgAAhWYCAAA+mgIAAJbqA//+YzmA= Date: Thu, 21 Jan 2016 07:20:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <56A03DB1.6070501@alum.mit.edu> In-Reply-To: <56A03DB1.6070501@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7uu7StgVhBoeWillMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DK2Nk0kbFgHXvFh7WtTA2M D1i7GDk5JARMJPZ8/sMCYYtJXLi3nq2LkYtDSOAwo8SZPcvYQBJCAksYJXYdzehi5OBgE7CQ 6P6nDRIWEfCWmDB/NRtImFlAXeLq4iCQsLCAkcTvPVNZIUqMJSbse8YOYZdJTD9zHizOIqAq cWzGNzCbV8BXYu/EDkaItedYJJ42bmYGSXAK6EhMvrsXrIgR6Lbvp9YwgdjMAuISt57MZ4K4 WUBiyZ7zzBC2qMTLx/+g/lKUuDp9OVS9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIExtPBLb8NdjC+fO54iFGA g1GJh7dAcEGYEGtiWXFl7iFGCQ5mJRFeORWgEG9KYmVValF+fFFpTmrxIUZpDhYlcd4kmcYw IYH0xJLU7NTUgtQimCwTB6dUA+MMPV6F51sm/j89P6+K7R2f+BHmtr2Jk1j5jBdEblmyaNGV fwLRbj2lO4Nvm5v2x0iv/G6y53PzCum7eVdU4loZ3dfx37LQWGXqyLZwIevfW6w5u6Pkp1x8 1BCnFvFiJsPG4H0th17v/Zk4R1SqiUPQz33WSWXR1YZtUqdiEhnWNbs9vN3jyaDEUpyRaKjF XFScCABLSP9KowIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 07:20:08 -0000 Hi, >> So, the question I would ask, do we care about BUNDLE without ICE? If=20 >> we do not, then all the a=3Drtcp related problems can be easily solved. > > Well, CLUE has no reason to couple those. CLUE wants to have the possibil= ity to interoperate with legacy endpoints, but it also will often have many= media streams and so want to offer BUNDLE. > > In any case, this isn't really about bundle. The real issue is that 3605 = is broken, and has been. Pretty much any offerer that has a need to use a= =3Drtcp will break if the answerer doesn't support it. > > I expect that one action that could be taken is to file an errata against= it. Wouldn't the errata be against SDP or offer/answer, where we would mandate = support of the rtcp attribute? (Of course, maybe we want to fix something in 3605 too, but the mandate to = support 3605 in the first place would have to be elsewhere.) Regards, Christer From nobody Thu Jan 21 08:13:50 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1A81B3280 for ; Thu, 21 Jan 2016 08:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL-I9bGftu2y for ; Thu, 21 Jan 2016 08:13:47 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804D71B327F for ; Thu, 21 Jan 2016 08:13:47 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-05v.sys.comcast.net with comcast id 8gDW1s0042D5gil01gDmZ5; Thu, 21 Jan 2016 16:13:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-06v.sys.comcast.net with comcast id 8gDm1s0053KdFy101gDmSY; Thu, 21 Jan 2016 16:13:46 +0000 To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <56A03DB1.6070501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56A103B8.1050309@alum.mit.edu> Date: Thu, 21 Jan 2016 11:13:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453392826; bh=APQuEGgA04zSYEudvswV40TEgKEGpirIzE3nQML9h+Y=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Zxhxefl3/VJdrqvRM7Q+CgC6YsdkIyyT2ggKofwqRWj7ms2vjpN2KEMeMOtbCxwkt O+7aam1DzsBpvRi9p4pglHSq1lUrrDUZezW832CL0jTkC54AwzOeqI7w3PTnpdZ092 5iR2bAeLY/Cbd9PNrBcok02gUGMvZxb7gwJ8ifWqHZxu48g8GwU/TmLjTtD80fPqwM LxuwS5RQ058gqwILlI1KklQbJPYyj7k4vrfieHQW5KurM7x/IK2TSrFwyrFYl7EgD4 k5NZY0D+5RgYASe5z6s+KrrHJRoht6M6zUaEevbw3qCqUVKKdeh6MLhNAdAxv3Pel5 PJkertbJ0zgiA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:13:48 -0000 On 1/21/16 2:20 AM, Christer Holmberg wrote: > Hi, > >>> So, the question I would ask, do we care about BUNDLE without ICE? If >>> we do not, then all the a=rtcp related problems can be easily solved. >> >> Well, CLUE has no reason to couple those. CLUE wants to have the possibility to interoperate with legacy endpoints, but it also will often have many media streams and so want to offer BUNDLE. >> >> In any case, this isn't really about bundle. The real issue is that 3605 is broken, and has been. Pretty much any offerer that has a need to use a=rtcp will break if the answerer doesn't support it. >> >> I expect that one action that could be taken is to file an errata against it. > > Wouldn't the errata be against SDP or offer/answer, where we would mandate support of the rtcp attribute? > > (Of course, maybe we want to fix something in 3605 too, but the mandate to support 3605 in the first place would have to be elsewhere.) On further thought I doubt that an errata works for this. It isn't that anything in 3605 is *wrong*. Rather, it is simply incomplete. By current standards it wouldn't be approved because it lacks a section describing how it works with O/A. Also, it failed to address backward compatibility. Unfortunately, backward compatibility isn't something that can added later. :-( I don't know the best way to handle this. Maybe the ADs have an idea. Thanks, Paul From nobody Thu Jan 21 08:18:05 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F269A1B3280 for ; Thu, 21 Jan 2016 08:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT8eeVynxc8P for ; Thu, 21 Jan 2016 08:18:02 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B940B1B322F for ; Thu, 21 Jan 2016 08:18:02 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-06v.sys.comcast.net with comcast id 8gHf1s0062VvR6D01gJ113; Thu, 21 Jan 2016 16:18:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id 8gJ11s0063KdFy101gJ10b; Thu, 21 Jan 2016 16:18:01 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51711@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56A104B8.3020507@alum.mit.edu> Date: Thu, 21 Jan 2016 11:18:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D51711@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453393081; bh=9zom1q/YQNWPFOTcg3A7ZSyU9BepVMiWx9pV7j6r/U8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=jSs8+WR03maZaDTsiIki2WCDVJ/xDSR35KG0lXzc5ukxf/jjfUUYCTiSnoSTzQw9n H12JiXncHFrtq41UA/AQ+WK9WV+6moIvgzTJBi8V2gAKzLoAf7XyzQeR9Y7Hclp7wq /UF+F7ijpN5jADJ2t+MG7WHmf5llwY7fFlu6bVRSm2Xn1kuezA0x6KOnmwmSl+p4gW goY6sgE5EWASMat1CJFbFJ0uOjrwEN1x4A/DX7wbmX6u8kF5iVJtrzMg/hzWyhR2Uc NVpV47sAJNwgV1n+DZbVNxFzM1TgLuzh2NyM1EMwzrr0Gqvjk2TVUVJ5OqHlZfrB2Y 6snUoVbEtfc2w== Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:18:04 -0000 On 1/21/16 2:16 AM, Christer Holmberg wrote: > Hi, > >>>> The problem is, if you are doing this you haven't reserved port+1. If >>>> the answerer doesn't understand either bundle, or a=rtcp, then it >>>> will simply assume that rtcp will be on port+1. What is lacking is a way to signal mux-exclusive that doesn't result in rtcp being sent on an unassigned port. >>> >>> Yes. >>> >>> But, you have the same problem even without mux-exclusive, if you want to use a non-port+1 for RTCP. There is no "Require header field" in SDP. >>> >>> I think this is a case where vendors simply will have to realize that they need to support the SDP 'rtcp' attribute in order to make sure their stuff work. I don't think it's a big problem in deployments, and it will eventually go away. >>> ... >>> People want to get away from reserving separate ports for RTP and RTCP, the support of ICE is increasing as we speak, so I think this is a problem that will be >>> fixed by the market. We should not prevent it because of some endpoints that we don't even know if they exist... You have to support the rtcp attribute if you want to be able to communicate with an entity behind a NAT. >> >> I'm not sure what the right path is here. If you don't reserve port+1, and the other end fails to support the rtcp attribute, then you have rtcp going to an unassigned port. You might get lucky, and >> then it won't hurt *you*. But maybe it is hitting some unrelated app on the same IP. >> With NAT boxes in the way it might end up hitting some other app on a different IP. > > Yes. > >> If the offerer detects that this has happened it could take a recovery >> action: either offer again with a port pair, or offer again disabling the media line in question. This assumes that the offerer can detect it. > > The offerer needs to be able to handle the scenario anyway, because malicious endpoints could send RTCP packets to whatever ports... > > Keep in mind that, at the end of the day, mux-exclusive is nothing more than one single usage of RFC 3605. > >> Unfortunately 3605 didn't even define the O/A semantics, or provide a way to indicate that the answerer accepted the attribute. It need not be used symmetrically. >> >> So I guess you are suggesting that support for 3605 for any user of sdp with rtp transport. And we will assume that is fully deployed. > > Correct. > > But, I'd be interested in hearing if someone has a different view regarding what is deployed. > >> If that is the path forward, then I think it needs some sort of extraordinary process to bless that. I don't know what it is. But I bet it involves the IESG. > > I think we could document the assumption, and what can go wrong if the attribute is not supported, Yes. > and then it's acceptable. It is? It is better than *not* documenting it. But the potential problems remain. It is acceptable if those problems don't occur in practice. But if the do occur then it isn't acceptable, at least to me. Thanks, Paul From nobody Thu Jan 21 09:29:32 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656CD1B3350 for ; Thu, 21 Jan 2016 09:29:31 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XlZhSB5gRus for ; Thu, 21 Jan 2016 09:29:30 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63FA1B334E for ; Thu, 21 Jan 2016 09:29:29 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-09-56a11577a857 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 50.A1.04914.77511A65; Thu, 21 Jan 2016 18:29:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 18:29:27 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4CAADVJAP//7W3AgAAhWYD//2ke4AA3MJ0A///cSQA= Date: Thu, 21 Jan 2016 17:29:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D54C5D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51711@ESESSMB209.ericsson.se> <56A104B8.3020507@alum.mit.edu> In-Reply-To: <56A104B8.3020507@alum.mit.edu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7hG656MIwg3etWhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxu0es4LFAxZU5X5kbGJt4uxg5OSQETCRe rHjNCmGLSVy4t56ti5GLQ0jgMKPEopV7WCGcJYwSDT+eMncxcnCwCVhIdP/TBmkQEfCVePb4 NhuILSxgJPF7z1RWiLixxIR9z9gh7DKJnR2PmEBsFgFVibNfzrCAjOEF6r30Rhxi/GkWiQ8T LoL1cgroSLyceAqsnhHooO+n1oDZzALiEreezGeCOFRAYsme88wQtqjEy8f/oB5Qklh7eDsL RL2OxILdn9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PT jYz1Uosyk4uL8/P08lJLNjECo+Tglt+6OxhXv3Y8xCjAwajEw2twc36YEGtiWXFl7iFGCQ5m JRHeXv6FYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5k2Uaw4QE0hNLUrNTUwtSi2CyTBycUg2M E3N5l74xlz5fki+6pWeR6bTVR796C4oaBR6ZIuwXfYh3HcO1jvXrhTY9dfjyzfWsrfDX2IDX z66aH6yp/WvfsFN204Sj62Vm9Gkq7p919N1f8Zmr/gQwn3VbIbydl5ftr/byP/ed5G2tNu/+ envT557Kx+3miv2Fajf7TVkWB7RL8C/Yf+HKcyWW4oxEQy3mouJEAOWqmhOOAgAA Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 17:29:31 -0000 Hi, .... >>> I'm not sure what the right path is here. If you don't reserve=20 >>> port+1, and the other end fails to support the rtcp attribute, then you= have rtcp going to an=20 >>> unassigned port. You might get lucky, and then it won't hurt *you*. But= maybe it is hitting some=20 >>> unrelated app on the same IP. >>> With NAT boxes in the way it might end up hitting some other app on a d= ifferent IP. >> >> Yes. >> >>> If the offerer detects that this has happened it could take a=20 >>> recovery >>> action: either offer again with a port pair, or offer again disabling t= he media line in question. This assumes that the offerer can detect it. >> >> The offerer needs to be able to handle the scenario anyway, because mali= cious endpoints could send RTCP packets to whatever ports... >> >> Keep in mind that, at the end of the day, mux-exclusive is nothing more = than one single usage of RFC 3605. >> >>> Unfortunately 3605 didn't even define the O/A semantics, or provide a w= ay to indicate that the answerer accepted the attribute. It need not be use= d symmetrically. >>> >>> So I guess you are suggesting that support for 3605 for any user of sdp= with rtp transport. And we will assume that is fully deployed. >> >> Correct. >> >> But, I'd be interested in hearing if someone has a different view regard= ing what is deployed. >> >>> If that is the path forward, then I think it needs some sort of extraor= dinary process to bless that. I don't know what it is. But I bet it involve= s the IESG. >> >> I think we could document the assumption, and what can go wrong if the = attribute is not supported, > > Yes. > >> and then it's acceptable. > > It is? Sorry - it seems like I dropped some words :) It was meant to say "and then= see if it's acceptable". > It is better than *not* documenting it. But the potential problems remain= . It is acceptable if those problems don't=20 > occur in practice. But if the do occur then it isn't acceptable, at least= to me. If it would be an issue, I think we would be aware of it by now.=20 Regards, Christer From nobody Thu Jan 21 09:33:15 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541711B3358 for ; Thu, 21 Jan 2016 09:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC_a8HP7m-yN for ; Thu, 21 Jan 2016 09:33:11 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAC91B3351 for ; Thu, 21 Jan 2016 09:33:11 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-d9-56a116555723 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 33.CB.30208.55611A65; Thu, 21 Jan 2016 18:33:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 18:33:09 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4CAADVJAP//7W3AgAAhWYCAAA+mgIAAJbqA//+YzmAAKmh3AP//2bRg Date: Thu, 21 Jan 2016 17:33:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D54C91@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <56A03DB1.6070501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> <56A103B8.1050309@alum.mit.edu> In-Reply-To: <56A103B8.1050309@alum.mit.edu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7h26o2MIwg2lPlS2mLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlrF/7j7ngJm/FlTMHmBoY n3J1MXJySAiYSJw8s4IdwhaTuHBvPVsXIxeHkMBhRomn1x8zgSSEBJYwSjxYHtXFyMHBJmAh 0f1PGyQsIuAtMWH+ajaQMLOAusTVxUEgYWEBI4nfe6ayQpQYS0zY94wdZKSIQBOjxJX+hWwg CRYBVYnDN6aDjecV8JX4vK4Fau8WVonlG9exgCQ4BXQkTm3+zAhiMwId9/3UGrAGZgFxiVtP 5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksTaw9tZIOp1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYw is1CMnYWkpZZSFpmIWlZwMiyilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwog5u+a26g/Hy G8dDjAIcjEo8vAY354cJsSaWFVfmHmKU4GBWEuHt5V8YJsSbklhZlVqUH19UmpNafIhRmoNF SZw3SaYxTEggPbEkNTs1tSC1CCbLxMEp1cAYyLDtr7fzqb3Cx82W3evff3qu0HHR8lPfHI4f v38m/PBqcbXVAjE7/tqxBvP5Wd+P+L1u7ZHXvR6apzum3/BdxMU12bpU+kdGclzuqXZnTb7l 56cKTYrSyjn451Dr7utrrO2fKtydraqyJcom5GdAhF+I/FOFyzJf731/l+1puLGzIIcxJc9X iaU4I9FQi7moOBEAz6uJ4aQCAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 17:33:13 -0000 Hi, >>>> So, the question I would ask, do we care about BUNDLE without ICE?=20 >>>> If we do not, then all the a=3Drtcp related problems can be easily sol= ved. >>> >>> Well, CLUE has no reason to couple those. CLUE wants to have the possib= ility to interoperate with legacy endpoints, but it also will often have ma= ny media streams and so want to offer BUNDLE. >>> >>> In any case, this isn't really about bundle. The real issue is that 360= 5 is broken, and has been. Pretty much any offerer that has a need to use a= =3Drtcp will break if the answerer doesn't support it. >>> >>> I expect that one action that could be taken is to file an errata again= st it. >> >> Wouldn't the errata be against SDP or offer/answer, where we would manda= te support of the rtcp attribute? >> >> (Of course, maybe we want to fix something in 3605 too, but the=20 >> mandate to support 3605 in the first place would have to be=20 >> elsewhere.) > > On further thought I doubt that an errata works for this. It isn't that a= nything in 3605 is *wrong*. Rather, it is simply incomplete. > > By current standards it wouldn't be approved because it lacks a section d= escribing how it works with O/A. Also, it failed to address backward compat= ibility. > > Unfortunately, backward compatibility isn't something that can added late= r. :-( > > I don't know the best way to handle this. Maybe the ADs have an idea. As this hasn't caused any major problem (at least nobody has raised any iss= ues in IETF), the question is whether we really need to do something. We kn= ow that, in theory, problems can occur, but as those problem don't seem to = occur in deployments we could just leave it like that. Regards, Christer From nobody Thu Jan 21 09:39:36 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF3C1A1B29 for ; Thu, 21 Jan 2016 09:39:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XjqhZDMwCvv for ; Thu, 21 Jan 2016 09:39:33 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1E51B3370 for ; Thu, 21 Jan 2016 09:39:33 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-00-56a117d26a32 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.9E.05041.2D711A65; Thu, 21 Jan 2016 18:39:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 18:39:30 +0100 From: Christer Holmberg To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Is support of mux exclusive a MUST/SHOULD/MAY/RECOMMENDED? Thread-Index: AdFUcmNQYqS1llIoTmOA+p32rXXORA== Date: Thu, 21 Jan 2016 17:39:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D54D03@ESESSMB209.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_7594FB04B1934943A5C02806D1A2204B37D54D03ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7tO5l8YVhBn+vMllMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGY3bXrIU7NatWHtnHXMD4x/1LkZODgkBE4mudx0sELaYxIV7 69m6GLk4hAQOM0pc2vGHBcJZwihx4/pM1i5GDg42AQuJ7n/aIA0iArESX9e9ZwKxhQWiJJb9 /MMGEY+WuP7oJpStJ3H7UidYK4uAqsThZUIgYV4BX4kfR86yg9iMQHu/n1oDNoZZQFzi1pP5 TBD3CEgs2XOeGcIWlXj5+B8rhK0ksfbwdhaI+nyJR7+nMUHMFJQ4OfMJywRGoVlIRs1CUjYL SRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFpcnJtuZKSXWpSZXFycn6eXl1qy iREYEQe3/LbawXjwueMhRgEORiUeXoOb88OEWBPLiitzDzFKcDArifD28i8ME+JNSaysSi3K jy8qzUktPsQozcGiJM6bJNMYJiSQnliSmp2aWpBaBJNl4uCUamC0zmWvTl14LFLiiMLHBGfP iVOCPuypL7Pekb+e1z3/8+sfl7OKJj8/wXmgxUftvcb+POsGdd+josLSmTcFL1//o3907ofg Owcrniy5dLPJVeXg9rVtLRO/L0zdbcadd2XL7PrPl5n2Fy9RvrfSg+G6dPW/X5eknZY+3Br3 N4jN49S9mrydz9RklFiKMxINtZiLihMBXuZtdoQCAAA= Archived-At: Subject: Re: [MMUSIC] BUNDLE: Is support of mux exclusive a MUST/SHOULD/MAY/RECOMMENDED? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 17:39:35 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D54D03ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like to get back to the initial question I had: do we mandate support o= f mux-exclusive (however the solution will look like) by BUNDLE entities? It is not needed for BUNDLE as such, because we already say that bundled m-= lines must use mux, but it would ensure the possibility to mandate mux eve= n if the answerer moves an m- line out of a BUNDLE group. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 18 January 2016 20:47 To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE: Is support of mux exclusive a MUST/SHOULD/MAY/REC= OMMENDED? Hi, We previously agreed that, within a BUNDLE group, RTP/RTCP multiplexing MUS= T be used for all RTP-based media. The question is: do we also mandate BUNDLE entities to also support mux-exc= lusive? Or, should support of mux-exclusive be a SHALL/SHOULD/MAY/RECOMMENDED? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D54D03ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I’d like to get = back to the initial question I had: do we mandate support of mux-exclusive = (however the solution will look like) by BUNDLE entities?=

 

It is not needed for B= UNDLE as such, because we already say that bundled m- lines must use mux, b= ut it would ensure the possibility to mandate mux even if the answerer move= s an m- line out of a BUNDLE group.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 January 2016 20:47
To: mmusic@ietf.org
Subject: [MMUSIC] BUNDLE: Is support of mux exclusive a MUST/SHOULD/= MAY/RECOMMENDED?

 

Hi,

 

We previously agreed that, within a BUNDLE group, RT= P/RTCP multiplexing MUST be used for all RTP-based media.

 

The question is: do we also mandate BUNDLE entities = to also support mux-exclusive?

 

Or, should support of mux-exclusive be a SHALL/SHOUL= D/MAY/RECOMMENDED?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D54D03ESESSMB209erics_-- From nobody Thu Jan 21 10:03:03 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484C31A891E for ; Thu, 21 Jan 2016 10:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc2OC2qv1oGR for ; Thu, 21 Jan 2016 10:03:00 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::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 EE6451A891C for ; Thu, 21 Jan 2016 10:02:59 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id z14so131422578igp.1 for ; Thu, 21 Jan 2016 10:02:59 -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:date:message-id:subject:from:to :cc:content-type; bh=Tyb5tBGyp/1ElViYaYrU0zKuJOXBzM6T2EatzMXYvjE=; b=LYmcaI07rpeP8gUyH4AEdWafB29v0G6RPlrfnS4kEqioJbsj+4Q74EVKEsnOSHn4ci dRAm+8YVv85fuxoVVfez3rAYbmZ0qoIETMsGthowOEBiqLGAYGm0NdAogFXdW9mx033x iYmPvbA4xLN8Y3t5dsJtad87cqKzXuqaOgEH5qYXouaLwQjgVzrzcNui/TL4VEWeChSh K6konVasqgKfkGxl1dvdw2GS4XRQCqQFZILxfV6NJxc3yrXI82fogTcSizlZMLpE6jJg cQr9NXyjcU1D7lDU8ueXhUV3fZ3qpvgOct3oTx9tZAmyjROgEG9/gfTgkiYOwDF1p0U7 sL5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tyb5tBGyp/1ElViYaYrU0zKuJOXBzM6T2EatzMXYvjE=; b=ej+iPuaIa+PTQcwsVPI3iLi+Q/rA7RLu69FQkGEKYtgi/AoaVblmkjCzK/IQeI29HD 5zuDRVieThVDnItDTfevOg7CfdxWvfXtj09sJ/4bJYGw9zZ0cJE96DcIAVdgWQ1+RCfT pvhdg4BcYA66CThqjesU+JURWYM7EM8RspY/+fTQtAf9O96GBxRwnYQrsW98pa4idFJ4 fD2clsTcOKseoUT8RODr7ZH04IFx+Yqlltw3j3ehsXqTBVD7ZN2ekuyyAGUliHt7WXkf 5nZCczReVJ6Lkl+E3dS0aSbcoMTtL5uiBbu0a8V1aMa+HAE5UO13/lRTCWq0Sr7CDBcV M62g== X-Gm-Message-State: AG10YOReW3LlVjjsyr4Z05HrdfFwUJvIXrfPvcBt28yv1K3SGjK1htN1sTmrq+fau+Rk8A== X-Received: by 10.50.4.3 with SMTP id g3mr11095156igg.49.1453399379315; Thu, 21 Jan 2016 10:02:59 -0800 (PST) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com. [209.85.223.173]) by smtp.gmail.com with ESMTPSA id l11sm1524283iol.17.2016.01.21.10.02.57 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 10:02:57 -0800 (PST) Received: by mail-io0-f173.google.com with SMTP id g73so63996446ioe.3 for ; Thu, 21 Jan 2016 10:02:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.136.226 with SMTP id s95mr35785272ioi.38.1453399376938; Thu, 21 Jan 2016 10:02:56 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 21 Jan 2016 10:02:56 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D54C91@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <56A03DB1.6070501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> <56A103B8.1050309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D54C91@ESESSMB209.ericsson.se> Date: Thu, 21 Jan 2016 13:02:56 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113ec9629452cb0529dbe9e6 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:03:01 -0000 --001a113ec9629452cb0529dbe9e6 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 21, 2016 at 12:33 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > As this hasn't caused any major problem (at least nobody has raised any > issues in IETF), the question is whether we really need to do something. We > know that, in theory, problems can occur, but as those problem don't seem > to occur in deployments we could just leave it like that. > > The reason no issues were reported so far is likely related to the fact that a=rtcp attribute, despite being widely implemented, is virtually useless and almost never used. In cases when end points are placed behind NAT most current solutions implement either host based NAT traversal or ICE. In case of host based NAT traversal one end point is placed on the public IP and will send RTP and RTCP to address/port from which it receives media from the end point behind NAT. This solution ignores a=rtcp attribute. ICE obviously ignores a=rtcp attribute and uses addresses in candidates. Only place where a=rtcp attribute is used are solutions based on STUN based local address discovery. From my experience such solutions are so fragile that they are almost never deployed. _____________ Roman Shpount --001a113ec9629452cb0529dbe9e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 21, 2016 at 12:33 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

As this hasn't caused any major problem (at least nobody has rai= sed any issues in IETF), the question is whether we really need to do somet= hing. We know that, in theory, problems can occur, but as those problem don= 't seem to occur in deployments we could just leave it like that.


The reason no issues were reported so = far is likely related to the fact that a=3Drtcp attribute, despite being wi= dely implemented, is virtually useless and almost never used. In cases when= end points are placed behind NAT most current solutions implement either h= ost based NAT traversal or ICE. In case of host based NAT traversal one end= point is placed on the public IP and will send RTP and RTCP to address/por= t from which it receives media from the end point behind NAT. This solution= ignores a=3Drtcp attribute. ICE obviously ignores a=3Drtcp attribute and u= ses addresses in candidates. Only place where a=3Drtcp attribute is used ar= e solutions based on STUN based local address discovery. From my experience= such solutions are so fragile that they are almost never deployed.
_____________
Roman Shpount
=C2=A0
--001a113ec9629452cb0529dbe9e6-- From nobody Thu Jan 21 10:14:12 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CB71A6FB2 for ; Thu, 21 Jan 2016 10:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2qkA9XyYx1A for ; Thu, 21 Jan 2016 10:14:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740941A893A for ; Thu, 21 Jan 2016 10:14:09 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-c7-56a11fef2024 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.E5.04914.FEF11A65; Thu, 21 Jan 2016 19:14:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 19:14:07 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4CAADVJAP//7W3AgAAhWYCAAA+mgIAAJbqA//+YzmAAKmh3AP//2bRg//+7MQD//2KSQA== Date: Thu, 21 Jan 2016 18:14:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D54DE2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <56A03DB1.6070501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> <56A103B8.1050309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D54C91@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D54DE2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7q+57+YVhBgcWKFlMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKuH54D2PBNr+KbSv7WBsY F/h0MXJwSAiYSFxZntXFyAlkiklcuLeerYuRi0NI4DCjxJIzb1kgnCWMEp9aTrCBNLAJWEh0 /9MGaRARUJX4+30yE4jNLOAr8XLBF2YQW1jASOL3nqmsEDXGEhP2PWMHmSMiMIlR4tejGywg CRag5ml9C8BsXqDm9aunMUMs288mManhKVg3p0CgxMfN18GKGIHO+35qDdQ2cYlbT+YzQZwt ILFkz3lmCFtU4uXjf6wQtpLE2sPbWSDq8yVuLj3ICrFMUOLkzCcsExhFZyEZNQtJ2SwkZbOA fmYW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjECI/Dglt+6OxhXv3Y8xCjAwajEw2twc36YEGtiWXFl7iFGCQ5mJRHeXv6FYUK8KYmVValF +fFFpTmpxYcYpTlYlMR5k2Uaw4QE0hNLUrNTUwtSi2CyTBycUg2MpnZ8bAwzY3oVF0ltfvTy Y82612eFD4suzDJdtGCOi9zz1BevNeZf+9L70T7prdExy6zJtybtyrzy6OgyzwsBWxLC1r7e fi5hUoAXw2n5FZZvo8y2Pb61pydo5zHtu3dP1SRmqR0x2XyMi+PbPWfGJb/mycxnr/TMaLuk 8fXs4rLPu8MuvneYXanEUpyRaKjFXFScCADKwUcivAIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:14:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D54DE2ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNClRoYW5rcyBmb3IgeW91ciBpbnB1dC4gU28sIGRvIHlvdSBhZ3JlZSB0aGF0 IHdlIGRvbuKAmXQgbmVlZCB0byDigJxmaXjigJ0gYT1ydGNwPw0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpT ZW50OiAyMSBKYW51YXJ5IDIwMTYgMjA6MDMNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1 bS5taXQuZWR1PjsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gRHJhZnQg bmV3IHZlcnNpb246IEJVTkRMRS0yNQ0KDQpPbiBUaHUsIEphbiAyMSwgMjAxNiBhdCAxMjozMyBQ TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkFzIHRoaXMgaGFz bid0IGNhdXNlZCBhbnkgbWFqb3IgcHJvYmxlbSAoYXQgbGVhc3Qgbm9ib2R5IGhhcyByYWlzZWQg YW55IGlzc3VlcyBpbiBJRVRGKSwgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2UgcmVhbGx5IG5l ZWQgdG8gZG8gc29tZXRoaW5nLiBXZSBrbm93IHRoYXQsIGluIHRoZW9yeSwgcHJvYmxlbXMgY2Fu IG9jY3VyLCBidXQgYXMgdGhvc2UgcHJvYmxlbSBkb24ndCBzZWVtIHRvIG9jY3VyIGluIGRlcGxv eW1lbnRzIHdlIGNvdWxkIGp1c3QgbGVhdmUgaXQgbGlrZSB0aGF0Lg0KDQpUaGUgcmVhc29uIG5v IGlzc3VlcyB3ZXJlIHJlcG9ydGVkIHNvIGZhciBpcyBsaWtlbHkgcmVsYXRlZCB0byB0aGUgZmFj dCB0aGF0IGE9cnRjcCBhdHRyaWJ1dGUsIGRlc3BpdGUgYmVpbmcgd2lkZWx5IGltcGxlbWVudGVk LCBpcyB2aXJ0dWFsbHkgdXNlbGVzcyBhbmQgYWxtb3N0IG5ldmVyIHVzZWQuIEluIGNhc2VzIHdo ZW4gZW5kIHBvaW50cyBhcmUgcGxhY2VkIGJlaGluZCBOQVQgbW9zdCBjdXJyZW50IHNvbHV0aW9u cyBpbXBsZW1lbnQgZWl0aGVyIGhvc3QgYmFzZWQgTkFUIHRyYXZlcnNhbCBvciBJQ0UuIEluIGNh c2Ugb2YgaG9zdCBiYXNlZCBOQVQgdHJhdmVyc2FsIG9uZSBlbmQgcG9pbnQgaXMgcGxhY2VkIG9u IHRoZSBwdWJsaWMgSVAgYW5kIHdpbGwgc2VuZCBSVFAgYW5kIFJUQ1AgdG8gYWRkcmVzcy9wb3J0 IGZyb20gd2hpY2ggaXQgcmVjZWl2ZXMgbWVkaWEgZnJvbSB0aGUgZW5kIHBvaW50IGJlaGluZCBO QVQuIFRoaXMgc29sdXRpb24gaWdub3JlcyBhPXJ0Y3AgYXR0cmlidXRlLiBJQ0Ugb2J2aW91c2x5 IGlnbm9yZXMgYT1ydGNwIGF0dHJpYnV0ZSBhbmQgdXNlcyBhZGRyZXNzZXMgaW4gY2FuZGlkYXRl cy4gT25seSBwbGFjZSB3aGVyZSBhPXJ0Y3AgYXR0cmlidXRlIGlzIHVzZWQgYXJlIHNvbHV0aW9u cyBiYXNlZCBvbiBTVFVOIGJhc2VkIGxvY2FsIGFkZHJlc3MgZGlzY292ZXJ5LiBGcm9tIG15IGV4 cGVyaWVuY2Ugc3VjaCBzb2x1dGlvbnMgYXJlIHNvIGZyYWdpbGUgdGhhdCB0aGV5IGFyZSBhbG1v c3QgbmV2ZXIgZGVwbG95ZWQuDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37D54DE2ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSb21hbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgeW91ciBpbnB1dC4gU28s IGRvIHlvdSBhZ3JlZSB0aGF0IHdlIGRvbuKAmXQgbmVlZCB0byDigJxmaXjigJ0gYT1ydGNwPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIxIEphbnVhcnkgMjAxNiAyMDowMzxicj4NCjxiPlRvOjwv Yj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1 Jmd0OzsgbW11c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBE cmFmdCBuZXcgdmVyc2lvbjogQlVORExFLTI1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMjEsIDIwMTYgYXQgMTI6 MzMgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCkFzIHRoaXMgaGFzbid0IGNhdXNlZCBhbnkgbWFqb3IgcHJvYmxl bSAoYXQgbGVhc3Qgbm9ib2R5IGhhcyByYWlzZWQgYW55IGlzc3VlcyBpbiBJRVRGKSwgdGhlIHF1 ZXN0aW9uIGlzIHdoZXRoZXIgd2UgcmVhbGx5IG5lZWQgdG8gZG8gc29tZXRoaW5nLiBXZSBrbm93 IHRoYXQsIGluIHRoZW9yeSwgcHJvYmxlbXMgY2FuIG9jY3VyLCBidXQgYXMgdGhvc2UgcHJvYmxl bSBkb24ndCBzZWVtIHRvIG9jY3VyIGluIGRlcGxveW1lbnRzIHdlIGNvdWxkIGp1c3QNCiBsZWF2 ZSBpdCBsaWtlIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVhc29uIG5vIGlzc3VlcyB3ZXJlIHJlcG9ydGVkIHNv IGZhciBpcyBsaWtlbHkgcmVsYXRlZCB0byB0aGUgZmFjdCB0aGF0IGE9cnRjcCBhdHRyaWJ1dGUs IGRlc3BpdGUgYmVpbmcgd2lkZWx5IGltcGxlbWVudGVkLCBpcyB2aXJ0dWFsbHkgdXNlbGVzcyBh bmQgYWxtb3N0IG5ldmVyIHVzZWQuIEluIGNhc2VzIHdoZW4gZW5kIHBvaW50cyBhcmUgcGxhY2Vk IGJlaGluZCBOQVQgbW9zdCBjdXJyZW50IHNvbHV0aW9ucw0KIGltcGxlbWVudCBlaXRoZXIgaG9z dCBiYXNlZCBOQVQgdHJhdmVyc2FsIG9yIElDRS4gSW4gY2FzZSBvZiBob3N0IGJhc2VkIE5BVCB0 cmF2ZXJzYWwgb25lIGVuZCBwb2ludCBpcyBwbGFjZWQgb24gdGhlIHB1YmxpYyBJUCBhbmQgd2ls bCBzZW5kIFJUUCBhbmQgUlRDUCB0byBhZGRyZXNzL3BvcnQgZnJvbSB3aGljaCBpdCByZWNlaXZl cyBtZWRpYSBmcm9tIHRoZSBlbmQgcG9pbnQgYmVoaW5kIE5BVC4gVGhpcyBzb2x1dGlvbiBpZ25v cmVzIGE9cnRjcA0KIGF0dHJpYnV0ZS4gSUNFIG9idmlvdXNseSBpZ25vcmVzIGE9cnRjcCBhdHRy aWJ1dGUgYW5kIHVzZXMgYWRkcmVzc2VzIGluIGNhbmRpZGF0ZXMuIE9ubHkgcGxhY2Ugd2hlcmUg YT1ydGNwIGF0dHJpYnV0ZSBpcyB1c2VkIGFyZSBzb2x1dGlvbnMgYmFzZWQgb24gU1RVTiBiYXNl ZCBsb2NhbCBhZGRyZXNzIGRpc2NvdmVyeS4gRnJvbSBteSBleHBlcmllbmNlIHN1Y2ggc29sdXRp b25zIGFyZSBzbyBmcmFnaWxlIHRoYXQgdGhleSBhcmUgYWxtb3N0IG5ldmVyDQogZGVwbG95ZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37D54DE2ESESSMB209erics_-- From nobody Thu Jan 21 10:22:53 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DAC1A896A for ; Thu, 21 Jan 2016 10:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeCk9nr0PxPF for ; Thu, 21 Jan 2016 10:22:51 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 E093C1A895D for ; Thu, 21 Jan 2016 10:22:50 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id g73so64612331ioe.3 for ; Thu, 21 Jan 2016 10:22:50 -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:date:message-id:subject:from:to :cc:content-type; bh=yiy6z0J8GIznywhM9Y4CLYZkliX/SgHROOXIAfX0HUI=; b=LXnFyBrby3/J1eDCdjzWehCrWd1C+OHHJqRLy3wscjGemww28TGu1zN4/M6X/04Av0 Z6Yl9J0Jv87UAet+/lG7d7YRrR0tLG2PmGvTPWPeo4bETri8jdYfC8lEcWQjAliC3qiq dC2vPa/iTNZcq1ioP6z7IUujRMl6Aw2W0LWLE8vJ1iBYuBlGIn75pcnmzb3RDVd1Cts2 58JeJ/BMkMMPRzZ0MG2IpLfPD9sSTmbMY2w3UtFcWzFNHYWA885S+yLh+wXu0eCkUEAw V77Vln/Os9pIMw4vP7UaXcWvrUhQyjK2Y76ftm5KdJEJ2Kxugi7BXfwgVebwvQZ/1jG+ YNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yiy6z0J8GIznywhM9Y4CLYZkliX/SgHROOXIAfX0HUI=; b=GHIauBCkVxKqoQA9bWzvWA6HHCjZBMSzirYRZULFFjzONOasrAJOjGbh00c9gYtP5U uBiNtpLzdiGTiEld6Q7dzYH8cOalB9bVHEWyw/SyFvruIKY16GAHkXZHeGCcZx0CEgbM rnFkHW/zrkIadbeb9lB++iTBFtkXoyvg53p7kGGVOglIH3R9s1i2sZR1QFy7A3S5DVms s69QSBGCJEfaksY4aeQ+1lRFiYxaTIvoQQbW3omzD5PKVTlsUas4NNu+2hW90oOcMAFB 68YFgoRv530lLrBbpc8J9AhAgcRnXunR9MVbx8WAgemy3Tstm0CKhwUm7px+TFRvkjys CrcA== X-Gm-Message-State: ALoCoQkC8HYv2+7JJ41kK6TGA/t2//6v1elurzDlnZlcjXohKKgB/vhGnewCl917YpDzYvaLvEnHNXGyS77UDrmSJoSPFhDBZA== X-Received: by 10.107.16.95 with SMTP id y92mr44299887ioi.194.1453400570207; Thu, 21 Jan 2016 10:22:50 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id p18sm1555705ioi.1.2016.01.21.10.22.48 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 10:22:48 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id z14so129940788igp.0 for ; Thu, 21 Jan 2016 10:22:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.155.65 with SMTP id vu1mr7381008igb.2.1453400567883; Thu, 21 Jan 2016 10:22:47 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 21 Jan 2016 10:22:47 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D54DE2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <56A03DB1.6070501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> <56A103B8.1050309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D54C91@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D54DE2@ESESSMB209.ericsson.se> Date: Thu, 21 Jan 2016 13:22:47 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1134641090b36e0529dc3093 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:22:52 -0000 --001a1134641090b36e0529dc3093 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 21, 2016 at 1:14 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Thanks for your input. So, do you agree that we don=E2=80=99t need to =E2= =80=9Cfix=E2=80=9D a=3Drtcp? > > > I think I would agree we don't need to "fix" a=3Drtcp if we did not plan on re-using for new purposes. I think technology moved on since the time "a=3Drtcp" was designed and new NAT traversal solutions should be ICE based= . If you are looking at a=3Drtcp attribute as a way to signal new functionali= ty such as rtcp-mux required in the backwards inter-operable manner, a=3Drtcp might be more trouble then it is worth, since it never worked quite well. It might be better to define a new SDP attribute for rtcp-mux-required with well defined offer/answer behavior which would allow to determine if both sides support it. _____________ Roman Shpount --001a1134641090b36e0529dc3093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 21, 2016 at 1:14 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Thanks for your input. So, do you agree that= we don=E2=80=99t need to =E2=80=9Cfix=E2=80=9D a=3Drtcp?



I think I would agree we don't need to "fix" a=3Drtcp if we = did not plan on re-using for new purposes. I think technology moved on sinc= e the time "a=3Drtcp" was designed and new NAT traversal solution= s should be ICE based. If you are looking at a=3Drtcp attribute as a way to= signal new functionality such as rtcp-mux required in the backwards inter-= operable manner, a=3Drtcp might be more trouble then it is worth, since it = never worked quite well. It might be better to define a new SDP attribute f= or rtcp-mux-required with well defined offer/answer behavior which would al= low to determine if both sides support it.
_____________
Roman Shpount
=C2=A0
<= /div>
--001a1134641090b36e0529dc3093-- From nobody Thu Jan 21 10:29:12 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03FC1A8980 for ; Thu, 21 Jan 2016 10:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxpZbj2uvqux for ; Thu, 21 Jan 2016 10:29:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823B11A897F for ; Thu, 21 Jan 2016 10:29:09 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-a7-56a123727e92 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.33.05041.27321A65; Thu, 21 Jan 2016 19:29:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 19:29:06 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Draft new version: BUNDLE-25 Thread-Index: AdFSKkPjQysqapYIRpeuqwOylqJimQBdVbdwAAL0XIAABFqX4P//9vYA///mf4CAADVJAP//7W3AgAAhWYCAAA+mgIAAJbqA//+YzmAAKmh3AP//2bRg//+7MQD//2KSQP/+02iA//2UcMA= Date: Thu, 21 Jan 2016 18:29:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D54E8D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D44B4A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4F561@ESESSMB209.ericsson.se> <569FD795.1010104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FC56@ESESSMB209.ericsson.se> <569FED38.7060905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D4FE40@ESESSMB209.ericsson.se> <56A00486.8090303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D50037@ESESSMB209.ericsson.se> <56A010EB.9030201@alum.mit.edu> <56A03DB1.6070501@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D51764@ESESSMB209.ericsson.se> <56A103B8.1050309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D54C91@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D54DE2@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D54E8DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7k26x8sIwg3fzmCymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBltE88z1rwzLtiTc9VtgbG G55djJwcEgImEqt/zGCFsMUkLtxbz9bFyMUhJHCYUaJt6X0mCGcJo8TVV+eAqjg42AQsJLr/ aYM0iAioSvz9PpkJxGYW8JV4ueALM4gtLGAk8XvPVFaIGmOJCfuesYPMERGYxyjx8+NFdpAE C1DzyY47YM28QM23J2+C2nyKXeLol6dgCU6BQIkL+3vBbEag876fWgO1TVzi1pP5TBBnC0gs 2XOeGcIWlXj5+B/UO0oSaw9vZ4Goz5d4t2Ul1DJBiZMzn7BMYBSdhWTULCRls5CUzQL6mVlA U2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiM wYNbflvtYDz43PEQowAHoxIPr8HN+WFCrIllxZW5hxglOJiVRHhTlBaGCfGmJFZWpRblxxeV 5qQWH2KU5mBREudNkmkMExJITyxJzU5NLUgtgskycXBKNTA6PNVOzj/TzaG3oMTGZc6vhBVZ 50/uyj3NWe+gd8bDLVvWcu2u85yC35Yz667tW6kW9X1Tzvl16bfkmiP+zAmo6dyeHTo9yjTO OZrx413Jd51How5LGul+urr90fzToW4NiRmCIfcLFBl2FDBqXP6iZtwqzuuvYfeO0etB/5RD fVHHA1KNu5RYijMSDbWYi4oTAT9V3B69AgAA Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft new version: BUNDLE-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:29:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D54E8DESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG9u4oCZdCB0aGluayB1c2luZyBhPXJ0Y3AgZm9yIHNpZ25hbGxpbmcgbXV4LWV4 Y2x1c2l2ZSBpcyBuZXcgZnVuY3Rpb25hbGl0eS4gV2Ugc3RpbGwgdXNlIGl0IHRvIHNpZ25hbCB0 aGUgUlRDUCBwb3J0LCB3aGljaCBpbiB0aGUgY2FzZSBvZiBtdXgtZXhjbHVzaXZlIGhhcHBlbnMg dG8gYmUgc2FtZSBhcyB0aGUgUlRQIHBvcnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZy b206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDIxIEph bnVhcnkgMjAxNiAyMDoyMw0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+DQpDYzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+ OyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEcmFmdCBuZXcgdmVyc2lv bjogQlVORExFLTI1DQoNCk9uIFRodSwgSmFuIDIxLCAyMDE2IGF0IDE6MTQgUE0sIENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB5b3VyIGlucHV0LiBT bywgZG8geW91IGFncmVlIHRoYXQgd2UgZG9u4oCZdCBuZWVkIHRvIOKAnGZpeOKAnSBhPXJ0Y3A/ DQoNCg0KSSB0aGluayBJIHdvdWxkIGFncmVlIHdlIGRvbid0IG5lZWQgdG8gImZpeCIgYT1ydGNw IGlmIHdlIGRpZCBub3QgcGxhbiBvbiByZS11c2luZyBmb3IgbmV3IHB1cnBvc2VzLiBJIHRoaW5r IHRlY2hub2xvZ3kgbW92ZWQgb24gc2luY2UgdGhlIHRpbWUgImE9cnRjcCIgd2FzIGRlc2lnbmVk IGFuZCBuZXcgTkFUIHRyYXZlcnNhbCBzb2x1dGlvbnMgc2hvdWxkIGJlIElDRSBiYXNlZC4gSWYg eW91IGFyZSBsb29raW5nIGF0IGE9cnRjcCBhdHRyaWJ1dGUgYXMgYSB3YXkgdG8gc2lnbmFsIG5l dyBmdW5jdGlvbmFsaXR5IHN1Y2ggYXMgcnRjcC1tdXggcmVxdWlyZWQgaW4gdGhlIGJhY2t3YXJk cyBpbnRlci1vcGVyYWJsZSBtYW5uZXIsIGE9cnRjcCBtaWdodCBiZSBtb3JlIHRyb3VibGUgdGhl biBpdCBpcyB3b3J0aCwgc2luY2UgaXQgbmV2ZXIgd29ya2VkIHF1aXRlIHdlbGwuIEl0IG1pZ2h0 IGJlIGJldHRlciB0byBkZWZpbmUgYSBuZXcgU0RQIGF0dHJpYnV0ZSBmb3IgcnRjcC1tdXgtcmVx dWlyZWQgd2l0aCB3ZWxsIGRlZmluZWQgb2ZmZXIvYW5zd2VyIGJlaGF2aW9yIHdoaWNoIHdvdWxk IGFsbG93IHRvIGRldGVybWluZSBpZiBib3RoIHNpZGVzIHN1cHBvcnQgaXQuDQpfX19fX19fX19f X19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37D54E8DESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgZG9u4oCZdCB0aGluayB1c2luZyBhPXJ0Y3AgZm9y IHNpZ25hbGxpbmcgbXV4LWV4Y2x1c2l2ZSBpcyBuZXcgZnVuY3Rpb25hbGl0eS4gV2Ugc3RpbGwg dXNlIGl0IHRvIHNpZ25hbCB0aGUgUlRDUCBwb3J0LCB3aGljaCBpbiB0aGUNCiBjYXNlIG9mIG11 eC1leGNsdXNpdmUgaGFwcGVucyB0byBiZSBzYW1lIGFzIHRoZSBSVFAgcG9ydC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiAyMSBKYW51YXJ5IDIwMTYgMjA6MjM8YnI+DQo8Yj5Ubzo8L2I+IENocmlz dGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVkdSZndDs7IG1t dXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gRHJhZnQgbmV3 IHZlcnNpb246IEJVTkRMRS0yNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDIxLCAyMDE2IGF0IDE6MTQgUE0sIENo cmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBpbnB1dC4gU28sIGRvIHlvdSBh Z3JlZSB0aGF0IHdlIGRvbuKAmXQgbmVlZCB0byDigJxmaXjigJ0gYT1ydGNwPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayBJIHdvdWxkIGFncmVlIHdlIGRvbid0IG5lZWQgdG8gJnF1b3Q7Zml4JnF1 b3Q7IGE9cnRjcCBpZiB3ZSBkaWQgbm90IHBsYW4gb24gcmUtdXNpbmcgZm9yIG5ldyBwdXJwb3Nl cy4gSSB0aGluayB0ZWNobm9sb2d5IG1vdmVkIG9uIHNpbmNlIHRoZSB0aW1lICZxdW90O2E9cnRj cCZxdW90OyB3YXMgZGVzaWduZWQgYW5kIG5ldyBOQVQgdHJhdmVyc2FsIHNvbHV0aW9ucyBzaG91 bGQgYmUgSUNFIGJhc2VkLiBJZiB5b3UgYXJlIGxvb2tpbmcNCiBhdCBhPXJ0Y3AgYXR0cmlidXRl IGFzIGEgd2F5IHRvIHNpZ25hbCBuZXcgZnVuY3Rpb25hbGl0eSBzdWNoIGFzIHJ0Y3AtbXV4IHJl cXVpcmVkIGluIHRoZSBiYWNrd2FyZHMgaW50ZXItb3BlcmFibGUgbWFubmVyLCBhPXJ0Y3AgbWln aHQgYmUgbW9yZSB0cm91YmxlIHRoZW4gaXQgaXMgd29ydGgsIHNpbmNlIGl0IG5ldmVyIHdvcmtl ZCBxdWl0ZSB3ZWxsLiBJdCBtaWdodCBiZSBiZXR0ZXIgdG8gZGVmaW5lIGEgbmV3IFNEUCBhdHRy aWJ1dGUgZm9yDQogcnRjcC1tdXgtcmVxdWlyZWQgd2l0aCB3ZWxsIGRlZmluZWQgb2ZmZXIvYW5z d2VyIGJlaGF2aW9yIHdoaWNoIHdvdWxkIGFsbG93IHRvIGRldGVybWluZSBpZiBib3RoIHNpZGVz IHN1cHBvcnQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37D54E8DESESSMB209erics_-- From nobody Thu Jan 21 11:03:37 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C011A8A8D for ; Thu, 21 Jan 2016 11:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBl1DqFGv0xE for ; Thu, 21 Jan 2016 11:03:34 -0800 (PST) Received: from mail-ig0-x243.google.com (mail-ig0-x243.google.com [IPv6:2607:f8b0:4001:c05::243]) (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 F171E1A8A8E for ; Thu, 21 Jan 2016 11:03:33 -0800 (PST) Received: by mail-ig0-x243.google.com with SMTP id ik10so5087095igb.1 for ; Thu, 21 Jan 2016 11:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=AYu8IpMZyhHiAMmjYoHQEnkXeynvzYxdO4Q3dok7a4w=; b=rNmbPOuKjX2t9z042p7F0XDopVoqo4SlR4aNA0dl5jua3cEpoy5rTkD/gUpvG2lGBF PATbTYDB89AmnypTqmVpsAYyqsQN3Q+FvX6dkpx+4XrOKn10fBtezCfN3coEo6+5yySd U5Jzp7M/mPurTE9v6OrWS5y3ux9Ij1yrusaX5VH22O0ZWq2KGbmGuHp9oZtT0x4/cgnm +31Au8hh7Ipsfzgl2ZqXfE5rMyXPFItLUwakSjKtZyrSi3H/fjmvAirSPo0gJjixAWsn RvxxX56RT8kTV0lcxlfUuw3cSn7mF0UTfjSPML8bKQcHDeHxVjv8VQ/bXr3iM8k1LgE7 +7UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=AYu8IpMZyhHiAMmjYoHQEnkXeynvzYxdO4Q3dok7a4w=; b=eyWFtutyJW2T4T6x6FaLv0WK4uBNXKAs4Q/lakvHPvTu2ohNbPerBQnq5WTWsuutGT jsOWTn8YU0AflckQ4Z9LajpIZwKza1TfrzqCkGQZ0HuzjW8e9f54568nqsCu6+FlhvwU Rsx3u3hy5+iK6TeAC0mH7w0zs4FWImRCg0kHsry0toVgRc3d/I5HyGi01VHeoenB4P3z UOZUn/9kqu1Qu90nI1x/UpAeuodQksk2DxVylQiYEpcYNkd9qlDrw/rY8SYar05fAn8Z /FyNMHtwWiRPIqTqkeoOp81m5j9O5byML3+r0l3pfW6zgcqnPA9k+Kwzl+kNABGrLBh2 C48Q== X-Gm-Message-State: AG10YOT8SYtNOMaODioMtluoSZZ+oQjSz0Rve262mgKSp/06KgOGMwZ4FdMF2KFv7scvHQ== X-Received: by 10.50.126.8 with SMTP id mu8mr10640443igb.52.1453403013281; Thu, 21 Jan 2016 11:03:33 -0800 (PST) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id e88sm1625473ioj.7.2016.01.21.11.03.31 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 11:03:31 -0800 (PST) Received: by mail-io0-f170.google.com with SMTP id g73so65834309ioe.3 for ; Thu, 21 Jan 2016 11:03:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.14.72 with SMTP id 69mr40371411ioo.145.1453403010845; Thu, 21 Jan 2016 11:03:30 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 21 Jan 2016 11:03:30 -0800 (PST) Date: Thu, 21 Jan 2016 14:03:30 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113fcf0e2d65f90529dcc2d7 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 19:03:35 -0000 --001a113fcf0e2d65f90529dcc2d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Changing the subject since we are not talking just about BUNDLE any more. On Thu, Jan 21, 2016 at 1:29 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I don=E2=80=99t think using a=3Drtcp for signalling mux-exclusive is new > functionality. We still use it to signal the RTCP port, which in the case > of mux-exclusive happens to be same as the RTP port. > > > I agree rtcp mux exclusive is not entirely new functionality for a=3Drtcp. What I am trying to say is that at this point a=3Drtcp attribute is require= d to be generated by ICE but it could be safely ignored when received. It carries no additional or useful information for anything ICE enabled. It also not used or carries no useful information when legacy server side NAT traversal is used. In practice, there is no need to parse a=3Drtcp or do anything based on its value. With a=3Drtcp being used to signal rtcp mux exclusive, modern end points will need to parse a=3Drtcp and make decisions based on its value. This extends the lifetime of the feature which is essentially under-designed and never operated properly. This is the reason I was asking for a way to signal mux-exclusive for anything ICE enabled without relying on a=3Drtcp. I have no problem with a=3Drtcp being used to improve interop with legacy end points, but I do not like seeing new use scenarios which are centered exclusively around a=3Drtcp. If we do this, we run into problem that we need to fix all the exiting a=3Drtcp problems with offer/answer, which I do not think is even possible in backwards compatible manner. Bottom line -- I would prefer another SDP attribute to signal RTCP mux exclusive which is negotiated over offer/answer so that both end points can detect that it is used. This attribute can be used in parallel with a=3Drtc= p, but I believe a=3Drtcp will be made totally redundant in this case. I would also like to update ICE-SDP not include a=3Drtcp when it carries no additional information. I believe after switching rtcp mux exclusive to a different attribute and ICE not being required to insert a=3Drtcp when it carries no additional information, a=3Drtcp will almost never be used in practical deployments, so the need to fix it disappears. _____________ Roman Shpount --001a113fcf0e2d65f90529dcc2d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Changing the subject since we are not talking just about BUNDLE any mo= re.

On Thu, Jan 21, 2016 at 1:29 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

I don=E2=80=99t think using a=3Drtcp for sig= nalling mux-exclusive is new functionality. We still use it to signal the R= TCP port, which in the case of mux-exclusive happens to be same as the RTP port.



I agree rtcp mux exclusive is not entirely new functionality for a=3Drtcp.= What I am trying to say is that at this point a=3Drtcp attribute is requir= ed to be generated by ICE but it could be safely ignored when received. It = carries no additional or useful information for anything ICE enabled. It al= so not used or carries no useful information when legacy server side NAT tr= aversal is used. In practice, there is no need to parse a=3Drtcp or do anyt= hing based on its value. With a=3Drtcp being used to signal rtcp mux exclus= ive, modern end points will need to parse a=3Drtcp and make decisions based= on its value. This extends the lifetime of the feature which is essentiall= y under-designed and never operated properly. This is the reason I was aski= ng for a way to signal mux-exclusive for anything ICE enabled without relyi= ng on a=3Drtcp. I have no problem with a=3Drtcp being used to improve inter= op with legacy end points, but I do not like seeing new use scenarios which= are centered exclusively around a=3Drtcp. If we do this, we run into probl= em that we need to fix all the exiting a=3Drtcp problems with offer/answer,= which I do not think is even possible in backwards compatible manner.

Bottom line -- I would prefer another SDP attribute to= signal RTCP mux exclusive which is negotiated over offer/answer so that bo= th end points can detect that it is used. This attribute can be used in par= allel with a=3Drtcp, but I believe a=3Drtcp will be made totally redundant = in this case.

I would also like to update ICE-SDP = not include a=3Drtcp when it carries no additional information. I believe a= fter switching rtcp mux exclusive to a different attribute and ICE not bein= g required to insert a=3Drtcp when it carries no additional information, a= =3Drtcp will almost never be used in practical deployments, so the need to = fix it disappears.
_____________Roman Shpount
=C2=A0
--001a113fcf0e2d65f90529dcc2d7-- From nobody Thu Jan 21 13:31:46 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8C91B31C6 for ; Thu, 21 Jan 2016 13:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSTimBmPWKbA for ; Thu, 21 Jan 2016 13:31:43 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589CC1B31AF for ; Thu, 21 Jan 2016 13:31:43 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-52-56a14e3d5873 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 52.A4.04914.D3E41A65; Thu, 21 Jan 2016 22:31:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Thu, 21 Jan 2016 22:31:40 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug Date: Thu, 21 Jan 2016 21:31:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdQ9fWb2GYQddlMYupyx+zWKzYcIDV YsaFqcwOzB5/339g8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZr+fMYCyYJFOxavMulgbG LdJdjBwcEgImEstfG3QxcgKZYhIX7q1n62Lk4hASOMwo0fl6LiuEs4RR4v72P4wgDWwCFhLd /7RBGkQEVCX+fp/MBGIzC/hKvFzwhRnEFhYwlXh7bj8TRI2ZxOv+T2wQtpHEzBXfwGwWoN5P e7rAaniBehd0TWIBGS8kECDx838dSJhTIFBi2eJN7CA2I9Bt30+tgVolLnHryXwmiJsFJJbs Oc8MYYtKvHz8jxXCVpJYe3g72EhmAU2J9bv0IVoVJaZ0P2SH2CoocXLmE5YJjGKzkEydhdAx C0nHLCQdCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERtLBLb91dzCufu14iFGAg1GJ h9fg5vwwIdbEsuLK3EOMEhzMSiK8/9wXhgnxpiRWVqUW5ccXleakFh9ilOZgURLnTZZpDBMS SE8sSc1OTS1ILYLJMnFwSjUwNhSe/mH3eLLGwbJ+zocfo3ys9f1WuAQdZ1MpFp2yyfv1D2UV 01i34HNCzVt0eKrP/qhgKhUz1jiqtGi19FbDv0wrGrQXl2uWfXZT6z+2+ual6ROXHf6ju+K4 vybLrjU7lY/VvHjLcvyfpNqpaxODnpu+0jofKN3QbaHZfNTm4V7lyQfjOedfV2Ipzkg01GIu Kk4EAOvYsP6gAgAA Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 21:31:45 -0000 SGksDQoNCj4gQ2hhbmdpbmcgdGhlIHN1YmplY3Qgc2luY2Ugd2UgYXJlIG5vdCB0YWxraW5nIGp1 c3QgYWJvdXQgQlVORExFIGFueSBtb3JlLg0KDQpXZWxsLCBJ4oCZZCBsaWtlIHRvIHRhbGsgYWJv dXQgQlVORExFLCBhbmQgd2hldGhlciBpdCBzaG91bGQgbWFuZGF0ZSBzdXBwb3J0IG9mIG11eC1l eGNsdXNpdmUgOikNCg0KPj4gSSBkb27igJl0IHRoaW5rIHVzaW5nIGE9cnRjcCBmb3Igc2lnbmFs bGluZyBtdXgtZXhjbHVzaXZlIGlzIG5ldyBmdW5jdGlvbmFsaXR5LiBXZSBzdGlsbCB1c2UgaXQg dG8gc2lnbmFsIHRoZSANCj4+IFJUQ1AgcG9ydCwgd2hpY2ggaW4gdGhlIGNhc2Ugb2YgbXV4LWV4 Y2x1c2l2ZSBoYXBwZW5zIHRvIGJlIHNhbWUgYXMgdGhlIFJUUCBwb3J0Lg0KPg0KPiBJIGFncmVl IHJ0Y3AgbXV4IGV4Y2x1c2l2ZSBpcyBub3QgZW50aXJlbHkgbmV3IGZ1bmN0aW9uYWxpdHkgZm9y IGE9cnRjcC4gV2hhdCBJIGFtIHRyeWluZyB0byBzYXkgaXMgdGhhdCBhdCB0aGlzIHBvaW50IGE9 cnRjcCBhdHRyaWJ1dGUgDQo+IGlzIHJlcXVpcmVkIHRvIGJlIGdlbmVyYXRlZCBieSBJQ0UgYnV0 IGl0IGNvdWxkIGJlIHNhZmVseSBpZ25vcmVkIHdoZW4gcmVjZWl2ZWQuIEl0IGNhcnJpZXMgbm8g YWRkaXRpb25hbCBvciB1c2VmdWwgaW5mb3JtYXRpb24gZm9yIA0KPiBhbnl0aGluZyBJQ0UgZW5h YmxlZC4gSXQgYWxzbyBub3QgdXNlZCBvciBjYXJyaWVzIG5vIHVzZWZ1bCBpbmZvcm1hdGlvbiB3 aGVuIGxlZ2FjeSBzZXJ2ZXIgc2lkZSBOQVQgdHJhdmVyc2FsIGlzIHVzZWQuIEluIHByYWN0aWNl LCANCj4gdGhlcmUgaXMgbm8gbmVlZCB0byBwYXJzZSBhPXJ0Y3Agb3IgZG8gYW55dGhpbmcgYmFz ZWQgb24gaXRzIHZhbHVlLiBXaXRoIGE9cnRjcCBiZWluZyB1c2VkIHRvIHNpZ25hbCBydGNwIG11 eCBleGNsdXNpdmUsIG1vZGVybiANCj4gZW5kIHBvaW50cyB3aWxsIG5lZWQgdG8gcGFyc2UgYT1y dGNwIGFuZCBtYWtlIGRlY2lzaW9ucyBiYXNlZCBvbiBpdHMgdmFsdWUuIFRoaXMgZXh0ZW5kcyB0 aGUgbGlmZXRpbWUgb2YgdGhlIGZlYXR1cmUgd2hpY2ggaXMgZXNzZW50aWFsbHkgDQo+IHVuZGVy LWRlc2lnbmVkIGFuZCBuZXZlciBvcGVyYXRlZCBwcm9wZXJseS4gVGhpcyBpcyB0aGUgcmVhc29u IEkgd2FzIGFza2luZyBmb3IgYSB3YXkgdG8gc2lnbmFsIG11eC1leGNsdXNpdmUgZm9yIGFueXRo aW5nIElDRSBlbmFibGVkIA0KPiB3aXRob3V0IHJlbHlpbmcgb24gYT1ydGNwLg0KPg0KPiBJIGhh dmUgbm8gcHJvYmxlbSB3aXRoIGE9cnRjcCBiZWluZyB1c2VkIHRvIGltcHJvdmUgaW50ZXJvcCB3 aXRoIGxlZ2FjeSBlbmQgcG9pbnRzLCBidXQgSSBkbyBub3QgbGlrZSBzZWVpbmcgbmV3IHVzZSBz Y2VuYXJpb3MgDQo+IHdoaWNoIGFyZSBjZW50ZXJlZCBleGNsdXNpdmVseSBhcm91bmQgYT1ydGNw LiBJZiB3ZSBkbyB0aGlzLCB3ZSBydW4gaW50byBwcm9ibGVtIHRoYXQgd2UgbmVlZCB0byBmaXgg YWxsIHRoZSBleGl0aW5nIGE9cnRjcCBwcm9ibGVtcyANCj4gd2l0aCBvZmZlci9hbnN3ZXIsIHdo aWNoIEkgZG8gbm90IHRoaW5rIGlzIGV2ZW4gcG9zc2libGUgaW4gYmFja3dhcmRzIGNvbXBhdGli bGUgbWFubmVyLg0KPg0KPiBCb3R0b20gbGluZSAtLSBJIHdvdWxkIHByZWZlciBhbm90aGVyIFNE UCBhdHRyaWJ1dGUgdG8gc2lnbmFsIFJUQ1AgbXV4IGV4Y2x1c2l2ZSB3aGljaCBpcyBuZWdvdGlh dGVkIG92ZXIgb2ZmZXIvYW5zd2VyIHNvIHRoYXQgYm90aCBlbmQgcG9pbnRzIA0KPiBjYW4gZGV0 ZWN0IHRoYXQgaXQgaXMgdXNlZC4gVGhpcyBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQgaW4gcGFyYWxs ZWwgd2l0aCBhPXJ0Y3AsIGJ1dCBJIGJlbGlldmUgYT1ydGNwIHdpbGwgYmUgbWFkZSB0b3RhbGx5 IHJlZHVuZGFudCBpbiB0aGlzIGNhc2UuDQo+DQo+IEkgd291bGQgYWxzbyBsaWtlIHRvIHVwZGF0 ZSBJQ0UtU0RQIG5vdCBpbmNsdWRlIGE9cnRjcCB3aGVuIGl0IGNhcnJpZXMgbm8gYWRkaXRpb25h bCBpbmZvcm1hdGlvbi4gSSBiZWxpZXZlIGFmdGVyIHN3aXRjaGluZyBydGNwIG11eCANCj4gZXhj bHVzaXZlIHRvIGEgZGlmZmVyZW50IGF0dHJpYnV0ZSBhbmQgSUNFIG5vdCBiZWluZyByZXF1aXJl ZCB0byBpbnNlcnQgYT1ydGNwIHdoZW4gaXQgY2FycmllcyBubyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uLCBhPXJ0Y3Agd2lsbCANCj4gYWxtb3N0IG5ldmVyIGJlIHVzZWQgaW4gcHJhY3RpY2FsIGRl cGxveW1lbnRzLCBzbyB0aGUgbmVlZCB0byBmaXggaXQgZGlzYXBwZWFycy4NCg0KV2UgY2FuIGZv ciBzdXJlIGRlZmluZSBhIG5ldyBhdHRyaWJ1dGUsIGlmIHBlb3BsZSBwcmVmZXIgdGhhdC4gDQoN CkJ1dCwgaXQgc3RpbGwgd291bGRuJ3Qgc29sdmUgUGF1bCdzIGlzc3VlLCB0aGF0IGEgbm9uLUlD RSBlbmRwb2ludCB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgYXR0cmlidXRlIG1heSBzdGFydCBz ZW5kaW5nIFJUQ1Agb24gUlRQKzEuIEJ1dCwgYXQgbGVhc3QgdGhlIG9mZmVyZXIgd291bGQgc2Vl IGZyb20gdGhlIGFuc3dlciB0aGF0IHRoZSBhbnN3ZXJlciBkb2VzIG5vdCBzdXBwb3J0IG11eC1l eGNsdXNpdmUsIGFuZCBjYW4gdGFrZSBwcm9wZXIgYWN0aW9ucy4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0K From nobody Thu Jan 21 14:07:21 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21611B33D6 for ; Thu, 21 Jan 2016 14:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xqsl09M1k6y for ; Thu, 21 Jan 2016 14:07:18 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 AFD801B33D5 for ; Thu, 21 Jan 2016 14:07:18 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g73so71004384ioe.3 for ; Thu, 21 Jan 2016 14:07:18 -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:date:message-id:subject:from:to :cc:content-type; bh=HGlKGPD/+21h5biRUjj6OYJN+ZcpBtJ/yRppDgKVYw4=; b=jIpCV0Gw3D2Gj7wd1bEv2b3JVWhtFNeL50YBo81nQVzbsrddkn7iYc55UPczub92cu l3xq+z2MmT9NANG6sphB7x+fVE1h0eClbG6809INiFSBYXiLZgsLnw11/8lrq2i8S801 378YlbAe5hhBYedc7bmAjZQf3dc2hvtQ6XHrp7qguhNsBd246XCKq1HS+kp+3P4xdXFw DAOTpy/Ex75a0PALk6Y63A9D9uVDj6FGuBnuszZAEtM4RxRnqmq2zgMg60Gtk8rAqfhZ F8cbHDLmHD5lEA8Pp6TIEIYJb2c5BbTTXp2cO446+TRg3ChbVbkaFNoocaotV3KhWHIx cHjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HGlKGPD/+21h5biRUjj6OYJN+ZcpBtJ/yRppDgKVYw4=; b=HLAL32jCmcxGpdaLN1tZFRHYWaEoFEOWopYTfLEWn+tsPoSg/XdXXDf/ClyB7Tip7Z 6o5O70RAj3zfLhp7x517ZtpD4nuuQUWFBzbHzN3I/wkvHf50V3Vm24JmOTivnTm0HMEC R6ujN/Jwkl9LPSMXsJE807s9QIO09woXmTFWeQKPwReebtv9VlFOODXoVxb0S2VM5WVb daUMi9ZUOusyeQrlimyE4Uxov781S37Xi7UxWWuTj69j+6YAVsYyWxDvkZa9D11VxQ20 IRymW8+pSe3gnwjilqzgwqnuxmV8bnRyGa2tFg8ta/4CKJRY1l0idaAXvpTWs+RjCZe3 +HTA== X-Gm-Message-State: AG10YOT5Gr812Y9fL4EqaHVdUYxNuv2A180ZW47GkpBrFi37qR8xjEnrcWWojmZmt0QBhw== X-Received: by 10.107.3.154 with SMTP id e26mr176798ioi.99.1453414038027; Thu, 21 Jan 2016 14:07:18 -0800 (PST) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com. [209.85.223.178]) by smtp.gmail.com with ESMTPSA id f13sm1896526ioj.13.2016.01.21.14.07.16 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 14:07:16 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id q21so69586888iod.0 for ; Thu, 21 Jan 2016 14:07:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.41.142 with SMTP id p136mr262788iop.70.1453414035994; Thu, 21 Jan 2016 14:07:15 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 21 Jan 2016 14:07:15 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> Date: Thu, 21 Jan 2016 17:07:15 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1141f3e253d7f50529df5380 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 22:07:20 -0000 --001a1141f3e253d7f50529df5380 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 21, 2016 at 4:31 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > We can for sure define a new attribute, if people prefer that. > > But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that > doesn't support the attribute may start sending RTCP on RTP+1. But, at > least the offerer would see from the answer that the answerer does not > support mux-exclusive, and can take proper actions. > We can define new attribute that specifies address and port for both RTP and RTCP similar to ICE candidate or a=rtcp attribute and set address in c= line to IN IP4 0.0.0.0. This way any end point that does not understand this attribute will send no media. _____________ Roman Shpount --001a1141f3e253d7f50529df5380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 21, 2016 at 4:31 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
We can for sure define a new attribute, i= f people prefer that.

But, it still wouldn't solve Paul's issue, that a non-ICE endpoint = that doesn't support the attribute may start sending RTCP on RTP+1. But= , at least the offerer would see from the answer that the answerer does not= support mux-exclusive, and can take proper actions.
<= br>
We can define new attribute that specifies address and port f= or both RTP and RTCP similar to ICE candidate or a=3Drtcp attribute and set= address in c=3D line to IN IP4 0.0.0.0. This way any end point that does n= ot understand this attribute will send no media.
_____________
Roman Shpount
=C2=A0
<= /div>
--001a1141f3e253d7f50529df5380-- From nobody Thu Jan 21 20:33:39 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A771B37EA for ; Thu, 21 Jan 2016 20:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXS01EstiobA for ; Thu, 21 Jan 2016 20:33:34 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 8F5F01B37EB for ; Thu, 21 Jan 2016 20:33:34 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id e185so35204999vkb.1 for ; Thu, 21 Jan 2016 20:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a5Ddk2CZsypavy/NjZcPdSyGrnNPtgn1+uVKcCvRdr0=; b=tLL6RUhbavKdSXP2vZCcM1pnYLSMMrL2rA4du1VJyIrom9YhrztOVcEpgKlUbzKafH Ku4MLXXRJREIHVGtFra/WLCUZWcyoWvt38uf9Gmj5/ZHSIURJ5KpQKKimg/9c58NP4V6 vX/h4gvZVGYiy+VuKWJLpj7VjymxVkDBCPn7ODd4n+cT+6fVqbg8hXal1OtITvMMih5g 0uiMNsqNPaozujycEeXBd5n0+MMixEbDJRuVMyv2ZIVUr8FgK01hNJvbrpjc+A86F8Ep R/QjCckcGyQlpEBB9KCgI6TIkP6BU9DeX27QtKNrLI1Nl4+Ws15qPG6m3XFVS/GZ/ORY pGXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a5Ddk2CZsypavy/NjZcPdSyGrnNPtgn1+uVKcCvRdr0=; b=XSsGd4F74lhcH/vDg6pWPVttcpYNRlibXTOMZDI+Sw+aLuEJbAxR3y18VFrDJz5OIO IFiS5x5TfiimLGD86cMzyiV/o2fVDJwkkBJo0H9j2kMRercxiG9dPJdGxlEl2TPRiXQs HZUC8ZOslFzn746aozBnw9Ez2ya0tnQ+SO/4d3LQAniebNZl74rwJUOsh4WXU/LiWRJG wkhBBnbCMPZlh8+pn1HqdkYqpKqH52dB9I/0hynJlvripZYOPYlr0+f5AgMjfN6rEblm 9C1EXNsLksYAWzfW0gtyXRdkY5vkEQx9PPkZ4pS5jEKbgxWsbTTEoLuyEillhrTb0yM7 f/uQ== X-Gm-Message-State: AG10YORsOXWyxwKE7TMUpnFL9R3Z7lawcE4Lak/EfM7vNFq3nyF78aT9apmb71q96sN1XH7B3d4CcOLrTtFyOw== MIME-Version: 1.0 X-Received: by 10.31.16.72 with SMTP id g69mr579550vki.152.1453437213761; Thu, 21 Jan 2016 20:33:33 -0800 (PST) Received: by 10.31.106.130 with HTTP; Thu, 21 Jan 2016 20:33:33 -0800 (PST) In-Reply-To: References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D19CED@ESESSMB209.ericsson.se> Date: Thu, 21 Jan 2016 20:33:33 -0800 Message-ID: From: Suhas Nandakumar To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=001a114323f8d467490529e4b8f0 Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 04:33:38 -0000 --001a114323f8d467490529e4b8f0 Content-Type: text/plain; charset=UTF-8 Hello Christer/Bo/Peter Do we think the understanding of dealing with the candidates when muxing is clear or does either of the drafts needs more explanation on what needs to be done. Thanks Suhas On Mon, Jan 18, 2016 at 8:45 PM, Suhas Nandakumar wrote: > I agree with Taylor. > > The Mux draft assigns category "TRANSPORT" to the ICE candidates. So the > candidate information from the "m=" line which corresponds to the BUNDLED > m=line shall be considered for the entire group. > > As far as implementation is concerned, i think one should be fine just > trickling the candidate information for the m=line selected for a given > BUNDLE group and no need to copy it for the rest unless there is a explicit > need (Initial offer, plan to change the bundle group address, drop a > m=line) to include different candidates. > > I would recommend we update the BUNDLE draft (if there is any confusion) > to match the MUX draft unless people think otherwise. > > Hope this helps. > > Tanks > Suhas > > > > > On Fri, Jan 15, 2016 at 8:20 AM, Taylor Brandstetter > wrote: > >> "candidate" is in the TRANSPORT category though, which doesn't prevent it >> from being different in different media sections. It's the BUNDLE >> negotiation draft that imposes the candidate duplication requirement, with >> a combination of these two paragraphs: >> >> When the answerer selects a BUNDLE address for itself, referred to as >> the answerer BUNDLE address, it MUST associate that address with each >> bundled "m=" line within the created BUNDLE group in the answer. >> >> When an offerer or answerer associates a shared address (i.e. a >> previously selected BUNDLE address) with one or more bundled "m=" >> lines, it MUST associate identical ICE candidates (referred to as >> shared ICE candidates) with each of those "m=" lines. >> >> >> On Fri, Jan 15, 2016 at 4:29 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >>> >>> There is also another issue: >>> >>> >>> >>> Some time ago, Peter Thatcher asked whether it is really needed to >>> include the SDP candidate attributes in all bundled m- lines. >>> >>> >>> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg15331.html >>> >>> >>> >>> Looking at SDP attributes in general, I guess the question is: if an >>> attribute belongs to IDENTICAL, does it need to be included in all m- lines >>> within a BUNDLE group? >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From:* Suhas Nandakumar [mailto:suhasietf@gmail.com] >>> *Sent:* 14. tammikuuta 2016 22:51 >>> *To:* Christer Holmberg >>> *Cc:* Bo Burman; mmusic WG; Taylor Brandstetter >>> >>> *Subject:* Re: [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-mux-attributes-12.txt >>> >>> >>> >>> Thanks Christer for bringing this to our notice. I just responded to >>> Taylor's clarification question and I don't think the response to his >>> question changes any of the behavior for BUNDLE or MUX. >>> >>> >>> >>> Please let me know your thoughts on my response. >>> >>> >>> >>> Thanks >>> >>> Suhas >>> >>> >>> >>> On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>> Hold on :) >>> >>> >>> >>> Some time ago there was a question from Taylor Brandstetter. Was that >>> solved? The topic mentioned BUNDLE, but I think the question was also >>> related to the sdp-mux-attribute draft. >>> >>> >>> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg15421.html >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman >>> *Sent:* 14 January 2016 18:09 >>> *To:* Suhas Nandakumar >>> *Cc:* mmusic WG >>> >>> >>> *Subject:* Re: [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-mux-attributes-12.txt >>> >>> >>> >>> Thank you Suhas, >>> >>> >>> >>> I believe this version addresses all comments provided, has no remaining >>> nits, and I thus intend to use it for the publication request. >>> >>> >>> >>> Cheers, >>> >>> /Bo >>> >>> MMUSIC co-chair >>> >>> >>> >>> *From:* mmusic [mailto:mmusic-bounces@ietf.org ] >>> *On Behalf Of *Suhas Nandakumar >>> *Sent:* den 14 januari 2016 15:34 >>> *To:* internet-drafts@ietf.org >>> *Cc:* mmusic WG; i-d-announce@ietf.org >>> *Subject:* Re: [MMUSIC] I-D Action: >>> draft-ietf-mmusic-sdp-mux-attributes-12.txt >>> >>> >>> >>> Hello All >>> >>> >>> >>> This version fixes couple of ID nits and updates the references to the >>> latest RFCs. >>> >>> >>> >>> >>> >>> Cheers >>> >>> suhas >>> >>> >>> >>> On Thu, Jan 14, 2016 at 6:32 AM, 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 >>> Working Group of the IETF. >>> >>> Title : A Framework for SDP Attributes when >>> Multiplexing >>> Author : Suhas Nandakumar >>> Filename : draft-ietf-mmusic-sdp-mux-attributes-12.txt >>> Pages : 96 >>> Date : 2016-01-14 >>> >>> Abstract: >>> The Session Description Protocol (SDP) provides mechanisms to >>> describe attributes of multimedia sessions and of individual media >>> streams (e.g., Real-time Transport Protocol (RTP) sessions) within a >>> multimedia session. Typically media associated with individual media >>> descriptions ("m=" lines) represent RTP sessions and are thus carried >>> over individual underlying transport layer flows. For scenarios >>> where SDP is used to negotiate the usage of single 5-tuple for >>> sending and receiving media associated with multiple media >>> descriptions, it is required to understand the semantic implications >>> of the SDP attributes associated with the RTP Media Streams >>> multiplexed over a single underlying transport layer flow. >>> >>> The purpose of this specification is to provide a framework for >>> analyzing the multiplexing characteristics of SDP attributes. This >>> specification also categorizes the existing SDP attributes based on >>> the framework described herein. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-12 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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/ >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> >>> >> >> > --001a114323f8d467490529e4b8f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Christer/Bo/Peter

=C2=A0 Do we th= ink the understanding of dealing with the candidates when muxing is clear o= r does either of the drafts needs more explanation on what needs to be done= .

Thanks
Suhas

On Mon, Jan 18, 2016 at 8:45 PM= , Suhas Nandakumar <suhasietf@gmail.com> wrote:
I agree with Taylor.=C2=A0
The Mux draft assigns category "TRANSPORT" to the ICE= candidates. So the candidate information from the "m=3D" line wh= ich corresponds to the BUNDLED m=3Dline shall be considered for the entire = group.=C2=A0

As far as implementation is concerned= , i think one should be fine just trickling the candidate information for t= he m=3Dline selected for a given BUNDLE group and no need to copy it for th= e rest unless there is a explicit need (Initial offer, plan to change the b= undle group address, drop a m=3Dline) =C2=A0to include different candidates= .

=C2=A0I would recommend we update the BUNDLE dra= ft (if there is any confusion) to match the MUX draft unless people think o= therwise.

Hope this helps.

Tanks
Suhas



=

On Fri, Jan 15, 2016 at 8:20 AM, Taylor= Brandstetter <deadbeef@google.com> wrote:
"candidate" is in the TRANSPO= RT category though, which doesn't prevent it from being different in di= fferent media sections. It's the BUNDLE negotiation draft that imposes = the candidate duplication requirement, with a combination of these two para= graphs:

   When the answerer selects a BUNDLE address for itself, referred=
 to as
   the answerer BUNDLE address, it MUST associate that address with each
   bundled "m=3D" line within the created BUNDLE group in the ans=
wer.
   When an offerer or answerer associates a shared=
 address (i.e. a
   previously selected BUNDLE address) with one or more bundled "m=3D&=
quot;
   lines, it MUST associate identical ICE candidates (referred to as
   shared ICE candidates) with each of those "m=3D" lines.
<= div>

On= Fri, Jan 15, 2016 at 4:29 AM, Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:

Hi,

=C2=A0

There is also another issue:<= u>

=C2=A0

Some time ago, Peter Thatcher= asked whether it is really needed to include the SDP candidate attributes = in all bundled m- lines.

=C2=A0

http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg15331.html=

=C2=A0

Looking at SDP attributes in = general, I guess the question is: if an attribute belongs to IDENTICAL, doe= s it need to be included in all m- lines within a BUNDLE group?

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Suhas Nandakumar [mailto:suhasietf@gmail.com= ]
Sent: 14. tammikuuta 2016 22:51
To: Christer Holmberg
Cc: Bo Burman; mmusic WG; Taylor Brandstetter

Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Thanks Christer for bringing this to our notice. I j= ust responded to Taylor's clarification question and I don't =C2=A0= think the response to his question changes any of the behavior for BUNDLE o= r MUX.

=C2=A0

Please let me know your thoughts on my response.<= /u>

=C2=A0

Thanks

Suhas

=C2=A0

On Thu, Jan 14, 2016 at 12:06 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hold on :)

=C2=A0

Some time ago there was a que= stion from Taylor Brandstetter. Was that solved? The topic mentioned BUNDLE, but I think the question was also related to the sdp-mux= -attribute draft.

=C2=A0

http://w= ww.ietf.org/mail-archive/web/mmusic/current/msg15421.html

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: 14 January 2016 18:09
To: Suhas Nandakumar <suhasietf@gmail.com>
Cc: mmusic WG <mmusic@ietf.org>=


Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Thank you Suhas,

=C2=A0

I believe this version addres= ses all comments provided, has no remaining nits, and I thus intend to use it for the publication request.

=C2=A0

Cheers,

/Bo

MMUSIC co-chair

=C2=A0

From: mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: den 14 januari 2016 15:34
To: in= ternet-drafts@ietf.org
Cc: mmusic WG; i-d-announce@ietf.org
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attribut= es-12.txt

=C2=A0

Hello All

=C2=A0

This version fixes couple of ID= nits and updates the references to the latest RFCs.

=C2=A0

=C2=A0

Cheers

suhas

=C2=A0

On Thu, Jan 14, 2016 at 6:32 AM= , <interne= t-drafts@ietf.org> wrote:<= /span>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-14

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 Typically media associated with indi= vidual media
=C2=A0 =C2=A0descriptions ("m=3D" lines) represent RTP sessions a= nd are thus carried
=C2=A0 =C2=A0over individual underlying transport layer flows.=C2=A0 For sc= enarios
=C2=A0 =C2=A0where SDP is used to negotiate the usage of single 5-tuple for=
=C2=A0 =C2=A0sending and receiving media associated with multiple media
=C2=A0 =C2=A0descriptions, it is required to understand the semantic implic= ations
=C2=A0 =C2=A0of the SDP attributes associated with the RTP Media Streams =C2=A0 =C2=A0multiplexed over a single underlying transport layer flow.

=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusi= c-sdp-mux-attributes/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mu= x-attributes-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-mmusic-sdp-mux-attributes-12


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

=C2=A0

=C2=A0




--001a114323f8d467490529e4b8f0-- From nobody Fri Jan 22 00:27:51 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA421ACD6A for ; Fri, 22 Jan 2016 00:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW4P2bkLTHW3 for ; Fri, 22 Jan 2016 00:27:49 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465E81ACD61 for ; Fri, 22 Jan 2016 00:27:49 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-92-56a1e8035f5e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EA.4C.04914.308E1A65; Fri, 22 Jan 2016 09:27:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Fri, 22 Jan 2016 09:27:47 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkA== Date: Fri, 22 Jan 2016 08:27:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbE9RJf5xcIwg4MnFS2mLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlrP67nangH2fF/ds7WRoY 73B2MXJySAiYSLw9+I4NwhaTuHBvPZDNxSEkcJhR4u+OgywQzhJGiQMdR9m7GDk42AQsJLr/ aYM0iAioSvz9PpkJxGYW8JV4ueALM4gtLGAq8fbcfiaIGjOJ1/2f2CBsJ4mLHa1gNSxAve2P 97OCjOQF6n3TJAex6jajxNIFl1lBajgFAiX+LfkJZjMCHff91BqoXeISt57MZ4I4WkBiyZ7z zBC2qMTLx/9YIWxFifanDYwg85kFNCXW79KHaFWUmNL9kB3E5hUQlDg58wnLBEaxWUimzkLo mIWkYxaSjgWMLKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAqPp4JbfujsYV792PMQowMGo xMP7IWlhmBBrYllxZe4hRgkOZiURXoarQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8yTKNYUIC 6YklqdmpqQWpRTBZJg5OqQZG5tbOEl7Rr5GfXnr7Wd6Q7eZUXe4xgWfV7Ev5+TvSzl7gn8Jx kmH5m502vsf+PPw6j3fdhRMOypzbTRK17vy5w1U7f2/sr3j+xO8P9no0z3dqPeKhM//V8vi0 /Bf+JWqRB/11opv2Gs5cECFY+XDNH/mM5vzCFGa+df0+piFTL9+fYSvp4X5AiaU4I9FQi7mo OBEAObaWsaICAAA= Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 08:27:50 -0000 SGksDQoNCj4gV2UgY2FuIGZvciBzdXJlIGRlZmluZSBhIG5ldyBhdHRyaWJ1dGUsIGlmIHBlb3Bs ZSBwcmVmZXIgdGhhdC4NCj4NCj4gQnV0LCBpdCBzdGlsbCB3b3VsZG4ndCBzb2x2ZSBQYXVsJ3Mg aXNzdWUsIHRoYXQgYSBub24tSUNFIGVuZHBvaW50IHRoYXQgZG9lc24ndCBzdXBwb3J0IHRoZSBh dHRyaWJ1dGUgbWF5IHN0YXJ0IHNlbmRpbmcgUlRDUCBvbiBSVFArMS4gQnV0LCBhdCBsZWFzdCB0 aGUgb2ZmZXJlciB3b3VsZCBzZWUgZnJvbSB0aGUgYW5zd2VyIHRoYXQgdGhlIGFuc3dlcmVyIGRv ZXMgbm90IHN1cHBvcnQgbXV4LWV4Y2x1c2l2ZSwgYW5kIGNhbiB0YWtlIHByb3BlciBhY3Rpb25z Lg0KPg0KPiBXZSBjYW4gZGVmaW5lIG5ldyBhdHRyaWJ1dGUgdGhhdCBzcGVjaWZpZXMgYWRkcmVz cyBhbmQgcG9ydCBmb3IgYm90aCBSVFAgYW5kIFJUQ1Agc2ltaWxhciB0byBJQ0UgY2FuZGlkYXRl IG9yIGE9cnRjcCBhdHRyaWJ1dGUgYW5kIHNldCBhZGRyZXNzIGluIGM9IGxpbmUgdG8gSU4gSVA0 IDAuMC4wLjAuIFRoaXMgd2F5IGFueSBlbmQgcG9pbnQgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5k IHRoaXMgYXR0cmlidXRlIHdpbGwgc2VuZCBubyBtZWRpYS4NCg0KQW5vdGhlciBvcHRpb24gd291 bGQgYmUgdG8gc2V0IHRoZSBtLSBsaW5lIHBvcnQgdG8gemVybywgbGlrZSB3ZSBkbyBmb3IgYnVu ZGxlLW9ubHkuIFRoZW4sIGlmIHRoZSBhbnN3ZXJlciBkb2Vzbid0IHN1cHBvcnQgdGhlIGF0dHJp YnV0ZSwgaXQgd29uJ3QgdXNlIHRoZSBtLSBsaW5lLg0KDQpFeGFtcGxlOg0KDQpjPUlOIElQNCAx MS4yMi4zMy40NA0KbT0wIFJUUC9BVlAgMCA5OQ0KYT1tdXgtZXhjbHVzaXZlOiAxMjM0NSAgPC0t LS0tLS0gMTIzNDUgaXMgdGhlIHBvcnQgdG8gYmUgdXNlZCBmb3IgUlRQIGFuZCBSVENQDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Fri Jan 22 01:35:50 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1F31ACE50 for ; Fri, 22 Jan 2016 01:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRJTlEUDtT6e for ; Fri, 22 Jan 2016 01:35:47 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 89FE21A1AB2 for ; Fri, 22 Jan 2016 01:35:47 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id a85so80012202ykb.1 for ; Fri, 22 Jan 2016 01:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LqxEthbemAwpZda44YznPTUPTG9wGnhr488A5Y0vr10=; b=H4tW1MrlZv0Cm1dbrTHFG4TicrcLPEt3HFUQr5CcrYorFVL9aEGyYljMX06fnUHvaU zvRCYP2T/HV8wFto75fMORu8uw9WuKgCmn8WiQRLQlOexeKBqPSmd0NOdT2sfQmEc1go kUBxboimW4MfVT6QaJRv3xeHjQv2UrdKuYP0ALWH+hP/cFeoTjz4pk5a/K46WQFje7C8 lpzp9Sa6Ko29RsyQwn849GvnugFbrNzlrkv08saVhjfTcu3CTnXkS7F/gRMRw3qp5V9H ksIGnqPgpP8zmReicRHZ5lLU7f1vPjyjDKc9nOhQWdl60Sq9RPdXbMR8UnnpbsZOKvxK vH2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LqxEthbemAwpZda44YznPTUPTG9wGnhr488A5Y0vr10=; b=as/ZQidfgkuNaMCpSI/mToo0v/sZFmc9LYatNvr2Gj7CKvAJN9q3737aFCasDWXclT 2V90x2IoE/52I/UTxLoNegHFZE9+Rg21I3LmirvG1/Ekk1PrW49s5wgaYEtQN5Xu+zCQ fwSGh2KEudoWoOTTC8du+MJgvftLDcejVf40J2fnYjodUGcdivFgzK1yaSxPwAVZyF7k 0hxe0oeZ0nHQgwSmmOwQ1Ct6xs2/I3SGIuXzE8CxcU1orrVf/ybBJ9uZQdndizMdIwOs 1QwKYaJSn7M5agr7Hsp7NTwjZzl/4EdP9cFpimURHCYL+yFG7tYj2QIvbKN5KYUo6H+Z xrjA== X-Gm-Message-State: AG10YORoOiSdCKstLHkc/u04Z0Vc3QQMTFRiYIcD0mZbKKO5lvi1uc5TCwx68hGUjgViszUUAI0+/v8784SLTA== MIME-Version: 1.0 X-Received: by 10.37.33.133 with SMTP id h127mr1005554ybh.170.1453455346891; Fri, 22 Jan 2016 01:35:46 -0800 (PST) Received: by 10.129.128.69 with HTTP; Fri, 22 Jan 2016 01:35:46 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> Date: Fri, 22 Jan 2016 09:35:46 +0000 Message-ID: From: Kevin Dempsey To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1143e92aa604b50529e8f1fd Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 09:35:49 -0000 --001a1143e92aa604b50529e8f1fd Content-Type: text/plain; charset=UTF-8 Would changing the protocol field of the m= line make sense in this case? For example: c=IN IP4 11.22.33.44 m=12345 RTPMUX/AVP 0 99 Endpoints that don't support mux-exclusive should reject that m= line. On 22 January 2016 at 08:27, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > We can for sure define a new attribute, if people prefer that. > > > > But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that > doesn't support the attribute may start sending RTCP on RTP+1. But, at > least the offerer would see from the answer that the answerer does not > support mux-exclusive, and can take proper actions. > > > > We can define new attribute that specifies address and port for both RTP > and RTCP similar to ICE candidate or a=rtcp attribute and set address in c= > line to IN IP4 0.0.0.0. This way any end point that does not understand > this attribute will send no media. > > Another option would be to set the m- line port to zero, like we do for > bundle-only. Then, if the answerer doesn't support the attribute, it won't > use the m- line. > > Example: > > c=IN IP4 11.22.33.44 > m=0 RTP/AVP 0 99 > a=mux-exclusive: 12345 <------- 12345 is the port to be used for RTP and > RTCP > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1143e92aa604b50529e8f1fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would changing the protocol field of the m=3D line make se= nse in this case? For example:

c=3DIN IP4 11.22.33.44
m=3D12345 RTPMUX/AVP 0 99

Endpoints that d= on't support mux-exclusive should reject that m=3D line.

On 22 January 2016 a= t 08:27, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

> We can for sure define a new attribute, if people prefer that.
>
> But, it still wouldn't solve Paul's issue, that a non-ICE endp= oint that doesn't support the attribute may start sending RTCP on RTP+1= . But, at least the offerer would see from the answer that the answerer doe= s not support mux-exclusive, and can take proper actions.
>
> We can define new attribute that specifies address and port for both R= TP and RTCP similar to ICE candidate or a=3Drtcp attribute and set address = in c=3D line to IN IP4 0.0.0.0. This way any end point that does not unders= tand this attribute will send no media.

Another option would be to set the m- line port to zero, like we do = for bundle-only. Then, if the answerer doesn't support the attribute, i= t won't use the m- line.

Example:

c=3DIN IP4 11.22.33.44
m=3D0 RTP/AVP 0 99
a=3Dmux-exclusive: 12345=C2=A0 <------- 12345 is the port to be used for= RTP and RTCP

Regards,

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

--001a1143e92aa604b50529e8f1fd-- From nobody Fri Jan 22 01:53:14 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DA01A004E for ; Fri, 22 Jan 2016 01:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YzalCMaeE-Z for ; Fri, 22 Jan 2016 01:53:11 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46A91A004D for ; Fri, 22 Jan 2016 01:53:10 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-b8-56a1fc047385 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.D9.05041.40CF1A65; Fri, 22 Jan 2016 10:53:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Fri, 22 Jan 2016 10:53:08 +0100 From: Christer Holmberg To: Kevin Dempsey Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAA1MAgAAVBVA= Date: Fri, 22 Jan 2016 09:53:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D55AE5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7ii7Ln4VhBluvGVvcnP+WxWLq8scs Fis2HGC1mHFhKrMDi8ff9x+YPHbOusvusWTJTyaPW1MKAliiuGxSUnMyy1KL9O0SuDL6b+5i K+gTrFi8fR1bA+MVgS5GTg4JAROJe4t3skDYYhIX7q1n62Lk4hASOMwo8WbvNBYIZwmjxJm2 ZiCHg4NNwEKi+582SIOIgI7EwfuT2UFsZoEiiaYFm8EGCQvYSTSfXs8MUWMvcWrtB0YI209i zpftTCA2i4CqRH9bG1gNr4CvxMnehWwgtpDAMyaJV9vSQWxOgUCJzUfXg81kBDru+6k1TBC7 xCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2IoS7U8bGEFOZhbQlFi/Sx+iVVFiSvdDdoi1ghIn Zz5hmcAoNgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmCEHdzy 22oH48HnjocYBTgYlXh4PyQtDBNiTSwrrsw9xCjBwawkwstwFSjEm5JYWZValB9fVJqTWnyI UZqDRUmcN0mmMUxIID2xJDU7NbUgtQgmy8TBKdXAKMzDXul9bbeC5W6nqaIxrrefX3yz1nqr V+FO1/JyQbUVYsKOzbmJCXelLG4faXWo7Ta4LPB3182mGVurDzUF/FK5WbikPWdC0nOuvHRh Ptkd+astlzRpvvdzK5mSqf+rx//e5BP7p4Z6Hz0oZ3JOJbmEb/rJ71XzEnmuLn5jGTw7RElX NOGDEktxRqKhFnNRcSIAQQibpKwCAAA= Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 09:53:12 -0000 SGksDQoNCj5Xb3VsZCBjaGFuZ2luZyB0aGUgcHJvdG9jb2wgZmllbGQgb2YgdGhlIG09IGxpbmUg bWFrZSBzZW5zZSBpbiB0aGlzIGNhc2U/IEZvciBleGFtcGxlOg0KPg0KPmM9SU4gSVA0IDExLjIy LjMzLjQ0DQo+bT0xMjM0NSBSVFBNVVgvQVZQIDAgOTkNCj4NCj5FbmRwb2ludHMgdGhhdCBkb24n dCBzdXBwb3J0IG11eC1leGNsdXNpdmUgc2hvdWxkIHJlamVjdCB0aGF0IG09IGxpbmUuDQoNCkkg Z3Vlc3MgaXQgY291bGQgYmUgZG9uZSB0aGF0IHdheSwgYnV0IHBlcnNvbmFsbHkgSSBkb24ndCB0 aGluayBpdCB3b3VsZCBiZSBzZW1hbnRpY2FsbHkgY29ycmVjdC4gQWxzbywgd2UgdXNlICJSVFAi IHdoZW4gbmVnb3RpYXRpbmcgbm9uLWV4Y2x1c2l2ZSBtdXgsIGFuZCB3aGVuIG11eGluZyBidW5k bGVkIFJUUCBzdHJlYW1zLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpPbiAyMiBKYW51YXJ5 IDIwMTYgYXQgMDg6MjcsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+IHdyb3RlOg0KSGksDQoNCj4gV2UgY2FuIGZvciBzdXJlIGRlZmluZSBhIG5ldyBh dHRyaWJ1dGUsIGlmIHBlb3BsZSBwcmVmZXIgdGhhdC4NCj4NCj4gQnV0LCBpdCBzdGlsbCB3b3Vs ZG4ndCBzb2x2ZSBQYXVsJ3MgaXNzdWUsIHRoYXQgYSBub24tSUNFIGVuZHBvaW50IHRoYXQgZG9l c24ndCBzdXBwb3J0IHRoZSBhdHRyaWJ1dGUgbWF5IHN0YXJ0IHNlbmRpbmcgUlRDUCBvbiBSVFAr MS4gQnV0LCBhdCBsZWFzdCB0aGUgb2ZmZXJlciB3b3VsZCBzZWUgZnJvbSB0aGUgYW5zd2VyIHRo YXQgdGhlIGFuc3dlcmVyIGRvZXMgbm90IHN1cHBvcnQgbXV4LWV4Y2x1c2l2ZSwgYW5kIGNhbiB0 YWtlIHByb3BlciBhY3Rpb25zLg0KPg0KPiBXZSBjYW4gZGVmaW5lIG5ldyBhdHRyaWJ1dGUgdGhh dCBzcGVjaWZpZXMgYWRkcmVzcyBhbmQgcG9ydCBmb3IgYm90aCBSVFAgYW5kIFJUQ1Agc2ltaWxh ciB0byBJQ0UgY2FuZGlkYXRlIG9yIGE9cnRjcCBhdHRyaWJ1dGUgYW5kIHNldCBhZGRyZXNzIGlu IGM9IGxpbmUgdG8gSU4gSVA0IDAuMC4wLjAuIFRoaXMgd2F5IGFueSBlbmQgcG9pbnQgdGhhdCBk b2VzIG5vdCB1bmRlcnN0YW5kIHRoaXMgYXR0cmlidXRlIHdpbGwgc2VuZCBubyBtZWRpYS4NCg0K QW5vdGhlciBvcHRpb24gd291bGQgYmUgdG8gc2V0IHRoZSBtLSBsaW5lIHBvcnQgdG8gemVybywg bGlrZSB3ZSBkbyBmb3IgYnVuZGxlLW9ubHkuIFRoZW4sIGlmIHRoZSBhbnN3ZXJlciBkb2Vzbid0 IHN1cHBvcnQgdGhlIGF0dHJpYnV0ZSwgaXQgd29uJ3QgdXNlIHRoZSBtLSBsaW5lLg0KDQpFeGFt cGxlOg0KDQpjPUlOIElQNCAxMS4yMi4zMy40NA0KbT0wIFJUUC9BVlAgMCA5OQ0KYT1tdXgtZXhj bHVzaXZlOiAxMjM0NcKgIDwtLS0tLS0tIDEyMzQ1IGlzIHRoZSBwb3J0IHRvIGJlIHVzZWQgZm9y IFJUUCBhbmQgUlRDUA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNp Y0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMN Cg0K From nobody Fri Jan 22 03:47:12 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3AF1A1A25 for ; Fri, 22 Jan 2016 03:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjUBzwzBCB6f for ; Fri, 22 Jan 2016 03:47:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CDF1A1A1E for ; Fri, 22 Jan 2016 03:47:08 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-81-56a216ba94e4 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5F.31.05041.BB612A65; Fri, 22 Jan 2016 12:47:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Fri, 22 Jan 2016 12:47:06 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount Thread-Topic: Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGow Date: Fri, 22 Jan 2016 11:47:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7q+5usUVhBrM/81hMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKmD7hOmPBS86KnWuXMDcw 3mTvYuTkkBAwkbjz9jOULSZx4d56ti5GLg4hgcOMEvfPLmQCSQgJLGGUOPm3tIuRg4NNwEKi +582SFhEIFriw4cFYCXMAr4S739OB5sjLGAq8fbcfiaIGjOJ1/2f2CBsN4lVtyBGsgioSsxu WcgCYvMC9X5pe8YMsXc+k8ShK69ZQHZxCvhJfD5WC1LDCHTb91NroHaJS9x6Mp8J4mYBiSV7 zjND2KISLx//Y4WwFSXanzYwQtTrSCzYDXEDs4C2xLKFr5kh9gpKnJz5hGUCo9gsJGNnIWmZ haRlFpKWBYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC4+nglt9WOxgPPnc8xCjAwajE w/shaWGYEGtiWXFl7iFGCQ5mJRFeRaFFYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5D/IDpQTS E0tSs1NTC1KLYLJMHJxSDYxTj2g8VzqVaJUW3uIut+RlXMmvWCaWpZMilvHeWPbwq6ajKVP5 93bxmf/jm9TX/JO4MucCT0D01x2n9JP/bdT5/a44xIKjY4f0p92mVamJps3n/NzZtrILbYl0 j9sUaGPZcLBoyyznKUJf/VY8CeVM2PO+jo15U/ge2f6al1Msvj1cxquR3aDEUpyRaKjFXFSc CABE7TEgowIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 11:47:11 -0000 Hi, Commenting on my own comment. >> We can for sure define a new attribute, if people prefer that. >> >> But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that = doesn't support the attribute may start sending RTCP on RTP+1. But, at leas= t the offerer would see from the answer that the answerer does not support = mux-exclusive, and can take proper actions. >> >> We can define new attribute that specifies address and port for both RTP= and RTCP similar to ICE candidate or a=3Drtcp attribute and set address in= c=3D line to IN IP4 0.0.0.0. This way any end point that does not understa= nd this attribute will send no media. > > Another option would be to set the m- line port to zero, like we do for b= undle-only. Then, if the answerer doesn't support the attribute, it won't u= se the m- line. > > Example: > > c=3DIN IP4 11.22.33.44 > m=3D0 RTP/AVP 0 99 > a=3Dmux-exclusive: 12345 <------- 12345 is the port to be used for RTP a= nd RTCP One problem with this solution is that an intermediary that doesn't support= the attribute won't know where to forward the media, it the m- line port v= alue is 0. It very likely will assume there will be no media to begin with. Regards, Christer From nobody Fri Jan 22 10:09:08 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB541B2B42 for ; Fri, 22 Jan 2016 10:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BAP2znmtUUt for ; Fri, 22 Jan 2016 10:09:01 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 915BB1B2B41 for ; Fri, 22 Jan 2016 10:09:01 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id mw1so59630977igb.1 for ; Fri, 22 Jan 2016 10:09:01 -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:date:message-id:subject:from:to :cc:content-type; bh=tBdlMYYBxBTz4fpo6wCx+A01bPFgyuVnszWh/bd1ba0=; b=K+xU1ERx8nInoJIoNMTLCs2XPx9KtgMqMV38AXtBbL4+C6AgpgRCcWinXMIhI7qEnZ 289haSAMbEm0hNBlrcarT13lHky5sbdui6uW2uO6/tQgYONYPDw/Q8hyMGZ7LhnuOaS8 o2Ha1UCwVHb/KhXgdnQ2dRLeQBK3WS2sBeMFc4ABM1d/zKU1kQ2fYhAahwdgVBUjF6Q8 hSkz8i6j3lfnSph8TO1CcKeN9oKuhjnPnkVTyFSgaiER6LbZRwk7Zl6Owe82o1nCugEW rVdx+51Tt6/fUFbedZ//tTrKalZ+EDxgRO+QNhAOmORCbxE7Qhfjn1JcONA1/ReLLoFZ 7ilg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tBdlMYYBxBTz4fpo6wCx+A01bPFgyuVnszWh/bd1ba0=; b=bCD8S6itc02DCsT6VbAug87345OkRv5ueSrmSufZROsf+4USy9DU+geTsVY5X2z/IA X+0kn8irnbGsIrtg/icvt0bR8cFNKvwjwHyrH0YqDGjqD9OFkcnGwIbmJWeHSFPtLWPx FZhTobwhTBXUmhRsZqGaDbKW4jsnYP0FxLhSyhI0woYpg1HmuPQ2Fx/EBlwGslwFzkS9 8Qmb9y4g1LpABabMeda6LuS5VgaezZsVWoq2eYIH/2Ho8/odUhl8qU+ffghRym7snmR0 3cK4f5ts//o2Xa2X9PMnAK/EEtqNE3Yp/VXHNn24s3aBVt0dxpW0GnDNIT4B9HUhfVfn jlMQ== X-Gm-Message-State: AG10YORBJYouRa3ovsWiuwBU+4ofP4uW/8aHMhbga8TFMtP87dbRjCPVpNItVQNBcLMp3g== X-Received: by 10.50.28.19 with SMTP id x19mr4996949igg.92.1453486140886; Fri, 22 Jan 2016 10:09:00 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id 95sm3446275iop.35.2016.01.22.10.08.59 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 10:08:59 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id ik10so16251825igb.1 for ; Fri, 22 Jan 2016 10:08:59 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr4928540igb.24.1453486138718; Fri, 22 Jan 2016 10:08:58 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 22 Jan 2016 10:08:58 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> Date: Fri, 22 Jan 2016 13:08:58 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01184168fc09cb0529f01c18 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 18:09:06 -0000 --089e01184168fc09cb0529f01c18 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 22, 2016 at 6:47 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >> We can for sure define a new attribute, if people prefer that. > >> > >> But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that > doesn't support the attribute may start sending RTCP on RTP+1. But, at > least the offerer would see from the answer that the answerer does not > support mux-exclusive, and can take proper actions. > >> > >> We can define new attribute that specifies address and port for both > RTP and RTCP similar to ICE candidate or a=rtcp attribute and set address > in c= line to IN IP4 0.0.0.0. This way any end point that does not > understand this attribute will send no media. > > > > Another option would be to set the m- line port to zero, like we do for > bundle-only. Then, if the answerer doesn't support the attribute, it won't > use the m- line. > > > > Example: > > > > c=IN IP4 11.22.33.44 > > m=0 RTP/AVP 0 99 > > a=mux-exclusive: 12345 <------- 12345 is the port to be used for RTP > and RTCP > > One problem with this solution is that an intermediary that doesn't > support the attribute won't know where to forward the media, it the m- line > port value is 0. It very likely will assume there will be no media to begin > with. > I always wondered what intermediary we are talking about which is supposed to know where to forward media. If we are talking about firewalls which dynamically open ports, then, most of the time it has no access to signaling information due to use of secure channels. If we are talking about something that does something to the media and forwards it (rtp proxy in combination with sip proxy), then we actually want such proxy to support rtcp mux exclusive or fail the connection for the same reason we want regular end points to fail during connection setup -- to prevent RTCP from being sent to unexpected destination. _____________ Roman Shpount --089e01184168fc09cb0529f01c18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 22, 2016 at 6:47 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
>> We can for sure= define a new attribute, if people prefer that.
>>
>> But, it still wouldn't solve Paul's issue, that a non-ICE = endpoint that doesn't support the attribute may start sending RTCP on R= TP+1. But, at least the offerer would see from the answer that the answerer= does not support mux-exclusive, and can take proper actions.
>>
>> We can define new attribute that specifies address and port for bo= th RTP and RTCP similar to ICE candidate or a=3Drtcp attribute and set addr= ess in c=3D line to IN IP4 0.0.0.0. This way any end point that does not un= derstand this attribute will send no media.
>
> Another option would be to set the m- line port to zero, like we do fo= r bundle-only. Then, if the answerer doesn't support the attribute, it = won't use the m- line.
>
> Example:
>
> c=3DIN IP4 11.22.33.44
> m=3D0 RTP/AVP 0 99
> a=3Dmux-exclusive: 12345=C2=A0 <------- 12345 is the port to be use= d for RTP and RTCP

One problem with this solution is that an intermediary that doesn= 9;t support the attribute won't know where to forward the media, it the= m- line port value is 0. It very likely will assume there will be no media= to begin with.

I always wondered what = intermediary we are talking about which is supposed to know where to forwar= d media. If we are talking about firewalls which dynamically open ports, th= en, most of the time it has no access to signaling information due to use o= f secure channels. If we are talking about something that does something to= the media and forwards it (rtp proxy in combination with sip proxy), then = we actually want such proxy to support rtcp mux exclusive or fail the conne= ction for the same reason we want regular end points to fail during connect= ion setup -- to prevent RTCP from being sent to unexpected destination.=C2= =A0
_____________
Roman Shpount=
=C2=A0
--089e01184168fc09cb0529f01c18-- From nobody Sat Jan 23 06:06:09 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374181A1B88 for ; Sat, 23 Jan 2016 06:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAjPXKbLjIQt for ; Sat, 23 Jan 2016 06:06:06 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD221A1B83 for ; Sat, 23 Jan 2016 06:06:06 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-6b-56a388cc336e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AB.A1.05041.CC883A65; Sat, 23 Jan 2016 15:06:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Sat, 23 Jan 2016 15:06:04 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoA== Date: Sat, 23 Jan 2016 14:06:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7ve6ZjsVhBusmKVpMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKmDzzPmPBPLGKM1MvsDQw XhHtYuTkkBAwkZjz/zoThC0mceHeerYuRi4OIYHDjBInjnxkh3CWMEp09j0Ecjg42AQsJLr/ aYM0iAioSvz9PhmsmVnAV+L9z+nsILawgKnE23P7mSBqzCRe939ig7DDJJ42QdgsQL2bZnSB 1fMC9V5t3g+1axWzxNQXy1lBEpwCgRI/7q8AK2IEuu77qTVQy8Qlbj2ZD3W1gMSSPeeZIWxR iZeP/7FC2EoSjUuesILczCygKbF+lz5Eq6LElO6HUHsFJU7OfMIygVFsFpKpsxA6ZiHpmIWk YwEjyypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwHg6uOW31Q7Gg88dDzEKcDAq8fAWbFkU JsSaWFZcmXuIUYKDWUmEV7hxcZgQb0piZVVqUX58UWlOavEhRmkOFiVx3oP8QNUC6Yklqdmp qQWpRTBZJg5OqQZGIx8Zq+fXgh8EBk1VLU1LOynw6sLCaY1VqwXqBDYV5zr4T/pStrSH5fTO r1d4/Xq4maOr9xzQXbYpOvXf3sLZDplch45J90/Nl9LN/tvr/1Ypoth2xsMT07TWCnol/FJk vnau4+yrnVVLH+e2W5f3uH7a0C+tXvRrwckzgoaf+1dXyluGJWYqsRRnJBpqMRcVJwIArkXb 4qMCAAA= Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 14:06:08 -0000 SGksDQoNCj4+PiBXZSBjYW4gZm9yIHN1cmUgZGVmaW5lIGEgbmV3IGF0dHJpYnV0ZSwgaWYgcGVv cGxlIHByZWZlciB0aGF0Lg0KPj4+DQo+Pj4gQnV0LCBpdCBzdGlsbCB3b3VsZG4ndCBzb2x2ZSBQ YXVsJ3MgaXNzdWUsIHRoYXQgYSBub24tSUNFIGVuZHBvaW50IHRoYXQgZG9lc24ndCBzdXBwb3J0 IHRoZSBhdHRyaWJ1dGUgbWF5DQo+Pj4gc3RhcnQgc2VuZGluZyBSVENQIG9uIFJUUCsxLiBCdXQs IGF0IGxlYXN0IHRoZSBvZmZlcmVyIHdvdWxkIHNlZSBmcm9tIHRoZSBhbnN3ZXIgdGhhdCB0aGUg YW5zd2VyZXIgZG9lcyANCj4+PiBub3Qgc3VwcG9ydCBtdXgtZXhjbHVzaXZlLCBhbmQgY2FuIHRh a2UgcHJvcGVyIGFjdGlvbnMuDQo+Pj4NCj4+PiBXZSBjYW4gZGVmaW5lIG5ldyBhdHRyaWJ1dGUg dGhhdCBzcGVjaWZpZXMgYWRkcmVzcyBhbmQgcG9ydCBmb3IgYm90aCBSVFAgYW5kIFJUQ1Agc2lt aWxhciB0byBJQ0UgY2FuZGlkYXRlIA0KPj4+IG9yIGE9cnRjcCBhdHRyaWJ1dGUgYW5kIHNldCBh ZGRyZXNzIGluIGM9IGxpbmUgdG8gSU4gSVA0IDAuMC4wLjAuIFRoaXMgd2F5IGFueSBlbmQgcG9p bnQgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5kIA0KPj4+IHRoaXMgYXR0cmlidXRlIHdpbGwgc2Vu ZCBubyBtZWRpYS4NCj4+DQo+PiBBbm90aGVyIG9wdGlvbiB3b3VsZCBiZSB0byBzZXQgdGhlIG0t IGxpbmUgcG9ydCB0byB6ZXJvLCBsaWtlIHdlIGRvIGZvciBidW5kbGUtb25seS4gVGhlbiwgaWYg dGhlIGFuc3dlcmVyIA0KPj4gZG9lc24ndCBzdXBwb3J0IHRoZSBhdHRyaWJ1dGUsIGl0IHdvbid0 IHVzZSB0aGUgbS0gbGluZS4NCj4+DQo+PiBFeGFtcGxlOg0KPj4NCj4+IGM9SU4gSVA0IDExLjIy LjMzLjQ0DQo+PiBtPTAgUlRQL0FWUCAwIDk5DQo+PiBhPW11eC1leGNsdXNpdmU6IDEyMzQ1wqAg PC0tLS0tLS0gMTIzNDUgaXMgdGhlIHBvcnQgdG8gYmUgdXNlZCBmb3IgUlRQIGFuZCBSVENQDQo+ Pg0KPj4gT25lIHByb2JsZW0gd2l0aCB0aGlzIHNvbHV0aW9uIGlzIHRoYXQgYW4gaW50ZXJtZWRp YXJ5IHRoYXQgZG9lc24ndCBzdXBwb3J0IHRoZSBhdHRyaWJ1dGUgd29uJ3Qga25vdyB3aGVyZSB0 byANCj4+IGZvcndhcmQgdGhlIG1lZGlhLCBpdCB0aGUgbS0gbGluZSBwb3J0IHZhbHVlIGlzIDAu IEl0IHZlcnkgbGlrZWx5IHdpbGwgYXNzdW1lIHRoZXJlIHdpbGwgYmUgbm8gbWVkaWEgdG8gYmVn aW4gd2l0aC4NCj4NCj4gSSBhbHdheXMgd29uZGVyZWQgd2hhdCBpbnRlcm1lZGlhcnkgd2UgYXJl IHRhbGtpbmcgYWJvdXQgd2hpY2ggaXMgc3VwcG9zZWQgdG8ga25vdyB3aGVyZSB0byBmb3J3YXJk IG1lZGlhLiBJZiANCj4gd2UgYXJlIHRhbGtpbmcgYWJvdXQgZmlyZXdhbGxzIHdoaWNoIGR5bmFt aWNhbGx5IG9wZW4gcG9ydHMsIHRoZW4sIG1vc3Qgb2YgdGhlIHRpbWUgaXQgaGFzIG5vIGFjY2Vz cyB0byBzaWduYWxpbmcgaW5mb3JtYXRpb24gDQo+IGR1ZSB0byB1c2Ugb2Ygc2VjdXJlIGNoYW5u ZWxzLiBJZiB3ZSBhcmUgdGFsa2luZyBhYm91dCBzb21ldGhpbmcgdGhhdCBkb2VzIHNvbWV0aGlu ZyB0byB0aGUgbWVkaWEgYW5kIGZvcndhcmRzIGl0IChydHAgcHJveHkgDQo+IGluIGNvbWJpbmF0 aW9uIHdpdGggc2lwIHByb3h5KSwgdGhlbiB3ZSBhY3R1YWxseSB3YW50IHN1Y2ggcHJveHkgdG8g c3VwcG9ydCBydGNwIG11eCBleGNsdXNpdmUgb3IgZmFpbCB0aGUgY29ubmVjdGlvbiBmb3IgDQo+ IHRoZSBzYW1lIHJlYXNvbiB3ZSB3YW50IHJlZ3VsYXIgZW5kIHBvaW50cyB0byBmYWlsIGR1cmlu ZyBjb25uZWN0aW9uIHNldHVwIC0tIHRvIHByZXZlbnQgUlRDUCBmcm9tIGJlaW5nIHNlbnQgdG8g DQo+IHVuZXhwZWN0ZWQgZGVzdGluYXRpb24uDQoNCklmIHN1Y2ggcHJveHkgb25seSBmb3J3YXJk cyB3aGF0IGl0IHJlY2VpdmVzLCBpdCBkb2Vzbid0IG5lZWQgdG8gc3VwcG9ydCBtdXgtZXhjbHVz aXZlLiBJdCBvbmx5IGZvcndhcmRzIHdoYXQgaXQgZ2V0cy4gSG93ZXZlciwgaWYgaXQgc2VlcyBh biBtLSBsaW5lIHdpdGggcG9ydCAwLCBpdCBtYXkgbm90IGZvcndhcmQgYW55dGhpbmcuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCsKgDQo= From nobody Sat Jan 23 08:59:40 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39F1B3991 for ; Sat, 23 Jan 2016 08:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWoYH5pAoKmS for ; Sat, 23 Jan 2016 08:59:37 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 17FBB1B3989 for ; Sat, 23 Jan 2016 08:59:37 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id h5so9468930igh.0 for ; Sat, 23 Jan 2016 08:59:37 -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:date:message-id:subject:from:to :cc:content-type; bh=/E5b7Z/kbx2ICF1NJWXCjSG2nl9dmgNZEQCXD65wtgI=; b=1RxfGSHAMZ92czDOFmjcZJ5brKNRCKv+fEtzZqlOH08pAVrNm2VJEZsrcnCwEbyi2F HwPyqvgU9X6GcsgU8UxRcULw6bIDQVE/XVV8SXy5nmJb0jWmuN3eKRtkxkMzuDxBJjEF fbMazN6J70LMb9SUyVgiUc3gBTWTZ8KGLJmFc6AqamotPHISdhaxmuqXUxE7sn5TyS5w LMs8JaxHFRMaauOwVu0lN4RMAZHdRu23B0sXg36bWsKLlXTi+SizXnmn9Tn+wLNQO+dp Ib66r+RGvo8dIeLGLKx3ySHZw1V6DpYO4PIy6ksNNTu5y5N1xCRlt4YD3DukscDVwb83 OpLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/E5b7Z/kbx2ICF1NJWXCjSG2nl9dmgNZEQCXD65wtgI=; b=k8QMNr2Ed/rYtkFGHvtbmorI5p0TIOejICFnolrNWMxUGk82sl1N2rVv/cx4wd78Oc uG4QPXbD5OxDtBCjLjOz1CElEfz5K8OxLsl5XKrC2OaAQ2SHdLNtVlMRblfR1wy67PFi BaO/CkBMxTGX2p2YlEMVf2gG2XsZ4kubcvFieop1HuqlGz2f4XiqvZH5jtqDDe3OqHwf AwwrmbVJvc+7W3xOsNOOvyLeOB8uUFoN7CfQoENCIK8v2eTj9e9Vbp2p1LY2D2djR+4s ApGge6lCHbAZKkyJ3zlhfniEZ/MFZC69Kz1drl3B/spEIR0ChDAw1h/3MXht7JwP8aZL RpxA== X-Gm-Message-State: AG10YOQaK+SzDD3UkB7OoRpHelJkwT9ZCLUxfD9H/j82XmKlnoWfE+84DpqePhdea5wbsw== X-Received: by 10.50.20.133 with SMTP id n5mr9828673ige.31.1453568375416; Sat, 23 Jan 2016 08:59:35 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id r80sm5035532ioi.26.2016.01.23.08.59.33 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jan 2016 08:59:34 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id ik10so10532156igb.1 for ; Sat, 23 Jan 2016 08:59:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.157.100 with SMTP id wl4mr9526024igb.2.1453568373416; Sat, 23 Jan 2016 08:59:33 -0800 (PST) Received: by 10.36.105.77 with HTTP; Sat, 23 Jan 2016 08:59:33 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> Date: Sat, 23 Jan 2016 11:59:33 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1136b3108df6b2052a0342a8 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 16:59:38 -0000 --001a1136b3108df6b2052a0342a8 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > I always wondered what intermediary we are talking about which is > supposed to know where to forward media. If > > we are talking about firewalls which dynamically open ports, then, most > of the time it has no access to signaling information > > due to use of secure channels. If we are talking about something that > does something to the media and forwards it (rtp proxy > > in combination with sip proxy), then we actually want such proxy to > support rtcp mux exclusive or fail the connection for > > the same reason we want regular end points to fail during connection > setup -- to prevent RTCP from being sent to > > unexpected destination. > > If such proxy only forwards what it receives, it doesn't need to support > mux-exclusive. It only forwards what it gets. However, if it sees an m- > line with port 0, it may not forward anything. > > Can you give me an example of the product you are referring to? I was thinking about http://ag-projects.com/mediaproxy/ and http://www.rtpproxy.org/ which both generate RTCP. We are dealing with trade of between not sending unexpected traffic and backwards compatibility. I do not think there is a way to prevent unexpected traffic and still work with all the legacy end points. I would argue that RTCP mux required is not backwards compatible change and should not work unless it is supported end-to-end. Only backwards compatibility required should be ability to detect end points that do not support rtcp mux and not to set the media session with them. Regards, _____________ Roman Shpount --001a1136b3108df6b2052a0342a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
> I always wondered w= hat intermediary we are talking about which is supposed to know where to fo= rward media. If
> we are talking about firewalls which dynamically open ports, then, mos= t of the time it has no access to signaling information
> due to use of secure channels. If we are talking about something that = does something to the media and forwards it (rtp proxy
> in combination with sip proxy), then we actually want such proxy to su= pport rtcp mux exclusive or fail the connection for
> the same reason we want regular end points to fail during connection s= etup -- to prevent RTCP from being sent to
> unexpected destination.

If such proxy only forwards what it receives, it doesn't need to= support mux-exclusive. It only forwards what it gets. However, if it sees = an m- line with port 0, it may not forward anything.


Can you give me an example of the prod= uct you are referring to? I was thinking about=C2=A0http://ag-projects.com/mediaproxy/ and=C2=A0http://www.rtpproxy.org/ which both g= enerate RTCP.

We are dealing with trade of between= not sending unexpected traffic and backwards compatibility. I do not think= there is a way to prevent unexpected traffic and still work with all the l= egacy end points. I would argue that RTCP mux required is not backwards com= patible change and should not work unless it is supported end-to-end. Only = backwards compatibility required should be ability to detect end points tha= t do not support rtcp mux and not to set the media session with them.
=

Regards,
_____________
Roman Shpount
=C2=A0
--001a1136b3108df6b2052a0342a8-- From nobody Sun Jan 24 01:41:16 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8E1B2A40 for ; Sun, 24 Jan 2016 01:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWU9TsQU4KQk for ; Sun, 24 Jan 2016 01:41:12 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 0B9081ACDF9 for ; Sun, 24 Jan 2016 01:41:12 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id n1so60808154vkb.3 for ; Sun, 24 Jan 2016 01:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2JTYh1FuiQBSRBSdcXHmF8iaRVoUjn/JkUIkppduMLI=; b=VnRoK6e0eHzFTrsVvGCFNo2cYOoI+PZAxk2c86uLxw94HIn8uozMzfmwW+eQsl23TI 9xElv1LGaeOcVs4f0+ixc2XPYR0tEivWha+4GTLsotULfvUSiVNteiHB0sLJehWyfxl6 GQPhldGC1rzskYjLeVR5av+rcnxOFov2wpihGCniMOCt6s6EuIOn67EZy1b0d/T5diZ1 kQGmzvn9Se47bCQBpmNZCjMktPNX0BwxERKapyCBR2mmE9uveeNFrmTnyu2t+y9hTfll HjPJvBiaDl91L5e90fHKeq3on9F2Kh4CuNZ2i74xp1sElOTedGWlwPvXkuMjeSpE0wyv kjdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2JTYh1FuiQBSRBSdcXHmF8iaRVoUjn/JkUIkppduMLI=; b=b7lObcUGDoOHuKUC6QYAWlD85sGuX5d9ISYji+Q0oFF8woBvoTHoYoGW3ok1jWD/gS Np8t6PYfCTaU0q/iAZFREQuPoi5v5dOknsH+qhEcMe8oWLQ59clV6bF/OxzY5k7nyiyj LBbu/UxMAhW7ZPwmaIMhbKOUAg7ErApfdAe3PPjSK8MXoerIOfRJo2/VjfRMYQ69qg/R nh0OSYtlNzSsAdl8FlONtaWcG+S1DAgqF9huSqIuVewfsXxYU6O1bpAr6BuNSB/I/abJ E5hq/6IvWCRX5r13FcsqEmheSHPOOB7ecK1rrjPYE5rDdLdl676ihTD+1Zlc8r2TKbZD whhA== X-Gm-Message-State: AG10YOQlHqMD8qzVAQLS44D/CaqvPDWdVXb9CZOT6R9BAAB8tZWStnJx6f9K99A1EI/+3IHKk9hTYZB5UomMDA== MIME-Version: 1.0 X-Received: by 10.31.50.213 with SMTP id y204mr7246782vky.109.1453628471148; Sun, 24 Jan 2016 01:41:11 -0800 (PST) Received: by 10.31.106.130 with HTTP; Sun, 24 Jan 2016 01:41:11 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> Date: Sun, 24 Jan 2016 01:41:11 -0800 Message-ID: From: Suhas Nandakumar To: Roman Shpount Content-Type: multipart/alternative; boundary=001a1144053ca88bc0052a11405a Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 09:41:14 -0000 --001a1144053ca88bc0052a11405a Content-Type: text/plain; charset=UTF-8 I might be repeating some discussions already made. So please forgive me if all of the below suggestions is beaten to death *Use-case: Explicitly indicate RTCP Muxing and possibly backward compatibility* I support a new attribute along with some rules for existing attributes which allows backward compatibility (Strong goal of SDP) and also exclusiveness of RTCP multiplexing Define a new attribute *"a=rtcp-mux-only" , which *in a offer indicates that the end-point can't receive rtcp on separate port than rtp. Also include a=rtcp attribute with* RTP port *as defined the mux-exclusive draft todau. That way even if the answerer who doesn't understand a=rtcp-mux-only, will still send RTCP to RTP port (as needed for this use-case). The answerer can do the same or include a=rtcp-mux based on its requirements When ICE is in usage and the Offer want to support a=rtcp-mux-only, it does the following a) include a=rtcp-mux-only b) include a=rtcp <-- RTP port c) include RTCP candidate with port information that matches RTP. No need to do new turn allocation for RTCP either. If the answerer doesn't understand a=rtcp-mux-only, it will still multiplex RTP and RTCP based on the candidate information. Not sure if i missed all the corner scenarios. Please let me know your thoughts Cheers Suhas On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount wrote: > On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> > I always wondered what intermediary we are talking about which is >> supposed to know where to forward media. If >> > we are talking about firewalls which dynamically open ports, then, most >> of the time it has no access to signaling information >> > due to use of secure channels. If we are talking about something that >> does something to the media and forwards it (rtp proxy >> > in combination with sip proxy), then we actually want such proxy to >> support rtcp mux exclusive or fail the connection for >> > the same reason we want regular end points to fail during connection >> setup -- to prevent RTCP from being sent to >> > unexpected destination. >> >> If such proxy only forwards what it receives, it doesn't need to support >> mux-exclusive. It only forwards what it gets. However, if it sees an m- >> line with port 0, it may not forward anything. >> >> > Can you give me an example of the product you are referring to? I was > thinking about http://ag-projects.com/mediaproxy/ and > http://www.rtpproxy.org/ which both generate RTCP. > > We are dealing with trade of between not sending unexpected traffic and > backwards compatibility. I do not think there is a way to prevent > unexpected traffic and still work with all the legacy end points. I would > argue that RTCP mux required is not backwards compatible change and should > not work unless it is supported end-to-end. Only backwards compatibility > required should be ability to detect end points that do not support rtcp > mux and not to set the media session with them. > > Regards, > _____________ > Roman Shpount > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1144053ca88bc0052a11405a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I might be repeating some discussions already made. S= o please forgive me if all of the below suggestions is beaten to death=C2= =A0

Use-case: Explicitly indicate RTCP Muxing a= nd possibly backward compatibility

I support a= new attribute along with some rules for existing attributes which allows b= ackward compatibility (Strong goal of SDP) and also exclusiveness of RTCP m= ultiplexing=C2=A0

Define a new attribute "= a=3Drtcp-mux-only" , which=C2=A0in a offer indicates that the end-= point can't receive rtcp on separate port than rtp. =C2=A0
Al= so =C2=A0include a=3Drtcp attribute with RTP port as defined the mux= -exclusive draft todau.
=C2=A0
That way even if the= answerer who doesn't understand a=3Drtcp-mux-only, will still send RTC= P to RTP port (as needed for this use-case). The answerer can do the same o= r include a=3Drtcp-mux based on its requirements

<= br>
When ICE is in usage and the Offer want to support a=3Drtcp-m= ux-only, it does the following
a) include a=3Drtcp-mux-only
=
b) include a=3Drtcp <rtp-port> <-- RTP port
c) incl= ude RTCP candidate with port information that matches RTP. No need to do ne= w turn allocation for RTCP either.

If the answerer= doesn't understand a=3Drtcp-mux-only, it will still multiplex RTP and = RTCP based on the candidate information.


Not sure if i missed all the corner scenarios. Please let me know you= r thoughts

Cheers
Suhas



On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount &l= t;roman@telurix.com<= /a>> wrote:
> I always wondered what intermediary= we are talking about which is supposed to know where to forward media. If<= br> > we are talking about firewalls which dynamically open ports, then, mos= t of the time it has no access to signaling information
> due to use of secure channels. If we are talking about something that = does something to the media and forwards it (rtp proxy
> in combination with sip proxy), then we actually want such proxy to su= pport rtcp mux exclusive or fail the connection for
> the same reason we want regular end points to fail during connection s= etup -- to prevent RTCP from being sent to
> unexpected destination.

If such proxy only forwards what it receives, it doesn't need to= support mux-exclusive. It only forwards what it gets. However, if it sees = an m- line with port 0, it may not forward anything.



We are dealing with trade of between not sending unexpected traffic = and backwards compatibility. I do not think there is a way to prevent unexp= ected traffic and still work with all the legacy end points. I would argue = that RTCP mux required is not backwards compatible change and should not wo= rk unless it is supported end-to-end. Only backwards compatibility required= should be ability to detect end points that do not support rtcp mux and no= t to set the media session with them.

Regards,
_____________
Ro= man Shpount
=C2=A0

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


--001a1144053ca88bc0052a11405a-- From nobody Sun Jan 24 10:58:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0550A1ACD9A for ; Sun, 24 Jan 2016 10:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVUCpvCXZTCu for ; Sun, 24 Jan 2016 10:58:50 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637DF1ACD9C for ; Sun, 24 Jan 2016 10:58:49 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-02v.sys.comcast.net with comcast id 9uw01s0022Bo0NV01uyooh; Sun, 24 Jan 2016 18:58:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id 9uyo1s0083KdFy101uyoSm; Sun, 24 Jan 2016 18:58:48 +0000 To: Suhas Nandakumar , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56A51EE7.8060406@alum.mit.edu> Date: Sun, 24 Jan 2016 13:58:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453661928; bh=tcewQGKJFCgis9OLCvnjnUgqZ4VM7U+qclTaUCdjHyY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=NN6/VoASWxoArileq8X1IRFMeCoOjrOibx/tekuAJzKkZ35qcbO37NXQDbT139U2h v/hCCGtu+8AScTiQ7ngNxkvtwrHcoEODwFNoe/AHJRRvkh3Fr+Is3d7FR4fitiOejA v0mntECGIUlM/Mv/MI5kfa4TFvHL25SchHDeuBUZasNht5cqNe2kxmz+fk3Nn4jUKn vKLpSH564+kj6ZWjsoZA9gHBmRXC4fVtlsV5V8Nw1weIuOIVKnw7xd/buOxlqI94Az Nh4B63NpqDnybPywD2d2aKLAYpbNXWiDl4HTye1riOVAKqnc9dVnduxPgLuComCDm0 DiPH1kJ0Pte3w== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 18:58:53 -0000 On 1/24/16 4:41 AM, Suhas Nandakumar wrote: > I might be repeating some discussions already made. So please forgive me > if all of the below suggestions is beaten to death > > *Use-case: Explicitly indicate RTCP Muxing and possibly backward > compatibility* > > I support a new attribute along with some rules for existing attributes > which allows backward compatibility (Strong goal of SDP) and also > exclusiveness of RTCP multiplexing > > Define a new attribute *"a=rtcp-mux-only" , which *in a offer indicates > that the end-point can't receive rtcp on separate port than rtp. It is *essential* to indicate the answerer behavior too. For this to provide backward support, the answerer who supports must also include this attribute in the answer. If it isn't present in the answer, then the offerer knows that it hasn't been supported. I think, in that case it must reoffer and either provide a port pair, or else drop the media stream, to prevent RTCP from going to an uncontrolled port. I think this ought to be viewed as an update to 3605. Thanks, Paul > Also include a=rtcp attribute with*RTP port *as defined the > mux-exclusive draft todau. > That way even if the answerer who doesn't understand a=rtcp-mux-only, > will still send RTCP to RTP port (as needed for this use-case). The > answerer can do the same or include a=rtcp-mux based on its requirements > > > When ICE is in usage and the Offer want to support a=rtcp-mux-only, it > does the following > a) include a=rtcp-mux-only > b) include a=rtcp <-- RTP port > c) include RTCP candidate with port information that matches RTP. No > need to do new turn allocation for RTCP either. > > If the answerer doesn't understand a=rtcp-mux-only, it will still > multiplex RTP and RTCP based on the candidate information. > > > Not sure if i missed all the corner scenarios. Please let me know your > thoughts > > Cheers > Suhas > > > > On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount > wrote: > > On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg > > wrote: > > > I always wondered what intermediary we are talking about which is supposed to know where to forward media. If > > we are talking about firewalls which dynamically open ports, then, most of the time it has no access to signaling information > > due to use of secure channels. If we are talking about something that does something to the media and forwards it (rtp proxy > > in combination with sip proxy), then we actually want such proxy to support rtcp mux exclusive or fail the connection for > > the same reason we want regular end points to fail during connection setup -- to prevent RTCP from being sent to > > unexpected destination. > > If such proxy only forwards what it receives, it doesn't need to > support mux-exclusive. It only forwards what it gets. However, > if it sees an m- line with port 0, it may not forward anything. > > > Can you give me an example of the product you are referring to? I > was thinking about http://ag-projects.com/mediaproxy/ and > http://www.rtpproxy.org/ which both generate RTCP. > > We are dealing with trade of between not sending unexpected traffic > and backwards compatibility. I do not think there is a way to > prevent unexpected traffic and still work with all the legacy end > points. I would argue that RTCP mux required is not backwards > compatible change and should not work unless it is supported > end-to-end. Only backwards compatibility required should be ability > to detect end points that do not support rtcp mux and not to set the > media session with them. > > Regards, > _____________ > Roman Shpount > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > From nobody Sun Jan 24 11:36:08 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510FE1ACEEC for ; Sun, 24 Jan 2016 11:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCDQn-CxcfDJ for ; Sun, 24 Jan 2016 11:36:02 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 910891ACEA9 for ; Sun, 24 Jan 2016 11:36:02 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id e185so64106729vkb.1 for ; Sun, 24 Jan 2016 11:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=24pBp6VRbuKzfxr/bFt/lhR/FeXwmlvcHcjJs8SQpHM=; b=Ih1oij4U8jy7OiuuTmbDbFG6w7/UsbDjMbiX+jKV1CbmqB3oSO0FgJ9ej/A0MetJp5 4V9qE0oyWrQ5eDKI4zqM903/AVEvuPXRbAqZFzbRHkhHNL7OAYYVZhvayJn2S5adHes2 3KEz2Ir5+bxLve9zjz8WFajHbHiUzXieWnYv8E7dwfllxIq5iGX951AGGL5jAu1Wq4E3 F3JgMx2wtOyFJJhAXpblnnrjJVu/UOJqEwpVkLK+eFa5wFaVB1S1xFkXmZz0336Enkv/ dVl2jt+AEZ0xTbXtQNr2XTPUvLUCgykP2tR9tmR++cf4glr+HlMxyW0agUHOm4C92AcI WleA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=24pBp6VRbuKzfxr/bFt/lhR/FeXwmlvcHcjJs8SQpHM=; b=mAS5mVnL2lxKDhqiH6BR3STN6tKpyjFjaNkQp5Jv9ApPe0oz/1IctZhOEpxr5Gwh8g QJPbIcxIVD5GyG/ofU/S+rzJFXBLTfnH3uOTGDNAK5PyXLy6aCK9x7UCRQ1dYGxsQqPg LBx0npwIA8qSpyE3WRY5LxVnJYcfVBiGLBjlffPNlNrIBee0fcWmPKT3HrMw2XU1OmUh RKJQBihyJsfe4ZIw7dD0jt8zmEmH9ywfUifV3Fd3LwdlYNDtPFvYGmcF8+OsfmQ2c33E 9ZxbhRjhqqKQVnbLWyI+YQv6JKG7gaViltn3gzn05GedV/tzuI8Ug3Qmiw8PzjIE0w+v Xusg== X-Gm-Message-State: AG10YOT+thi6A1swi4MmZURx6lG4XoMLTbL2oCcHV9mbYjzHsq3MztgcxtqgKMAJ9sSjJ0nT4M7fUxljZ1d5Hg== MIME-Version: 1.0 X-Received: by 10.31.54.23 with SMTP id d23mr8569250vka.25.1453664161591; Sun, 24 Jan 2016 11:36:01 -0800 (PST) Received: by 10.31.106.130 with HTTP; Sun, 24 Jan 2016 11:36:01 -0800 (PST) In-Reply-To: <56A51EE7.8060406@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> Date: Sun, 24 Jan 2016 11:36:01 -0800 Message-ID: From: Suhas Nandakumar To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114385d8f9778b052a198f2e Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 19:36:05 -0000 --001a114385d8f9778b052a198f2e Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat wrote: > On 1/24/16 4:41 AM, Suhas Nandakumar wrote: > >> I might be repeating some discussions already made. So please forgive me >> if all of the below suggestions is beaten to death >> >> *Use-case: Explicitly indicate RTCP Muxing and possibly backward >> compatibility* >> >> I support a new attribute along with some rules for existing attributes >> which allows backward compatibility (Strong goal of SDP) and also >> exclusiveness of RTCP multiplexing >> >> Define a new attribute *"a=rtcp-mux-only" , which *in a offer indicates >> that the end-point can't receive rtcp on separate port than rtp. >> > > It is *essential* to indicate the answerer behavior too. For this to > provide backward support, the answerer who supports must also include this > attribute in the answer. If it isn't present in the answer, then the > offerer knows that it hasn't been supported. I think, in that case it must > reoffer and either provide a port pair, or else drop the media stream, to > prevent RTCP from going to an uncontrolled port. > > [Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One where the agent understands a=rtcp-mux but not the a=rtcp-mux-only and second where the agent doesn't understand either. Let's think the answerer behavior in both the cases Case 1: Agent supports RFC5761 but not mux-only In this scenario we mandate that the offer includes RFC5761 a=rtcp-mux as well whenever he offers with mux-only. Thus the answerer will still MUX the RTCP to RTP port following RFC5761 rules. Case 2: Agent doesn't support RFC5761 and mux-only as well This is the case where the answerer can process just the RFC3605 a=rtcp attribute and can either : 2a) send the rtcp to the port indicated in a=rtcp attribute , thus effectively muxing 2b) will think rtcp port specified as being error since it matches the RTP port and reject the m=line. [[ note: this isn't defined as an error in RFC3605 ]] Case 3: Answerer supports RFC5761, Mux-exclusive In this successful scenario, the answerer can just include a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good enough for the Offerer to know that Answerer is able to mux the rtcp traffic towards the offerer and also wishes to receive muxed (no fallback) rtcp traffic from the offerer These seems to convert most of all the cases right > I think this ought to be viewed as an update to 3605. > [Suhas] Paul, why do you think it needs an update to RFC3605 ? > > Thanks, > Paul > > Also include a=rtcp attribute with*RTP port *as defined the >> mux-exclusive draft todau. >> That way even if the answerer who doesn't understand a=rtcp-mux-only, >> will still send RTCP to RTP port (as needed for this use-case). The >> answerer can do the same or include a=rtcp-mux based on its requirements >> >> >> When ICE is in usage and the Offer want to support a=rtcp-mux-only, it >> does the following >> a) include a=rtcp-mux-only >> b) include a=rtcp <-- RTP port >> c) include RTCP candidate with port information that matches RTP. No >> need to do new turn allocation for RTCP either. >> >> If the answerer doesn't understand a=rtcp-mux-only, it will still >> multiplex RTP and RTCP based on the candidate information. >> >> >> Not sure if i missed all the corner scenarios. Please let me know your >> thoughts >> >> Cheers >> Suhas >> >> >> >> On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount > > wrote: >> >> On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg >> > > wrote: >> >> > I always wondered what intermediary we are talking about which >> is supposed to know where to forward media. If >> > we are talking about firewalls which dynamically open ports, >> then, most of the time it has no access to signaling information >> > due to use of secure channels. If we are talking about >> something that does something to the media and forwards it (rtp proxy >> > in combination with sip proxy), then we actually want such >> proxy to support rtcp mux exclusive or fail the connection for >> > the same reason we want regular end points to fail during >> connection setup -- to prevent RTCP from being sent to >> > unexpected destination. >> >> If such proxy only forwards what it receives, it doesn't need to >> support mux-exclusive. It only forwards what it gets. However, >> if it sees an m- line with port 0, it may not forward anything. >> >> >> Can you give me an example of the product you are referring to? I >> was thinking about http://ag-projects.com/mediaproxy/ and >> http://www.rtpproxy.org/ which both generate RTCP. >> >> We are dealing with trade of between not sending unexpected traffic >> and backwards compatibility. I do not think there is a way to >> prevent unexpected traffic and still work with all the legacy end >> points. I would argue that RTCP mux required is not backwards >> compatible change and should not work unless it is supported >> end-to-end. Only backwards compatibility required should be ability >> to detect end points that do not support rtcp mux and not to set the >> media session with them. >> >> Regards, >> _____________ >> Roman Shpount >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> > --001a114385d8f9778b052a198f2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 1/24/16 4:41 AM, Suhas Nandakumar wrote:
I might be repeating some discussions already made. So please forgive me if all of the below suggestions is beaten to death

 *Use-case: Explicitly indicate RTCP Muxing and possibly backward
compatibility*

I support a new attribute along with some rules for existing attributes
which allows backward compatibility (Strong goal of SDP) and also
exclusiveness of RTCP multiplexing

 Define a new attribute *"a=3Drtcp-mux-only" , which *in a offer i= ndicates
that the end-point can't receive rtcp on separate port than rtp.

It is *essential* to indicate the answerer behavior too. For this to provid= e backward support, the answerer who supports must also include this attrib= ute in the answer. If it isn't present in the answer, then the offerer = knows that it hasn't been supported. I think, in that case it must reof= fer and either provide a port pair, or else drop the media stream, to preve= nt RTCP from going to an uncontrolled port.


[Suhas] - Agreed Paul. I see backward = compatibility in 2 ways. One where the agent understands a=3Drtcp-mux but n= ot the a=3Drtcp-mux-only and second where the agent doesn't understand = either. Let's think the answerer behavior in both the cases
<= br>
Case 1: Agent supports RFC5761 but not mux-only
=C2= =A0 =C2=A0In this scenario we mandate that the offer includes RFC5761 a=3Dr= tcp-mux as well whenever he offers with mux-only. Thus the answerer will st= ill MUX the RTCP to RTP port following RFC5761 rules.

<= div>Case 2: Agent doesn't support RFC5761 and mux-only as well
This is =C2=A0the case where the answerer can process just the RFC3605 a= =3Drtcp attribute and can either :
=C2=A0 =C2=A0 =C2=A0 =C2=A02a)= send the rtcp to the port indicated in a=3Drtcp attribute , thus effective= ly muxing=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A02b) will think rtcp po= rt specified as being error since it matches the RTP port and reject the m= =3Dline. [[ note: this isn't defined as an error in RFC3605 ]]

Case 3: Answerer supports RFC5761, Mux-exclusive
=C2=A0 =C2=A0In this successful scenario, the answerer can just include a= =3Drtcp-mux and a=3Drtcp-mux-exclusive in its answer and that is good enoug= h for the Offerer to know that Answerer is able to mux the rtcp traffic tow= ards the offerer and also wishes to receive muxed (no fallback) rtcp traffi= c from the offerer

These seems to convert most of = all the cases right=C2=A0
=C2=A0
=C2=A0
I think this ought to be viewed as an update to 3605.
=
[Suhas] Paul, why do you think it needs an update to RFC3605= ?
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Also=C2=A0 include a=3Drtcp attribute with*RTP port *as defined the
mux-exclusive draft todau.
That way even if the answerer who doesn't understand a=3Drtcp-mux-only,=
will still send RTCP to RTP port (as needed for this use-case). The
answerer can do the same or include a=3Drtcp-mux based on its requirements<= br>

When ICE is in usage and the Offer want to support a=3Drtcp-mux-only, it does the following
a) include a=3Drtcp-mux-only
b) include a=3Drtcp <rtp-port> <-- RTP port
c) include RTCP candidate with port information that matches RTP. No
need to do new turn allocation for RTCP either.

If the answerer doesn't understand a=3Drtcp-mux-only, it will still
multiplex RTP and RTCP based on the candidate information.


Not sure if i missed all the corner scenarios. Please let me know your
thoughts

Cheers
Suhas



On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount <roman@telurix.com
 <mailto:roman@tel= urix.com>> wrote:

=C2=A0 =C2=A0 On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg
=C2=A0 =C2=A0 <christer.holmberg@ericsson.com
=C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > I always wondered what intermediary we are= talking about which is supposed to know where to forward media. If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > we are talking about firewalls which dynam= ically open ports, then, most of the time it has no access to signaling inf= ormation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > due to use of secure channels. If we are t= alking about something that does something to the media and forwards it (rt= p proxy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > in combination with sip proxy), then we ac= tually want such proxy to support rtcp mux exclusive or fail the connection= for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > the same reason we want regular end points= to fail during connection setup -- to prevent RTCP from being sent to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > unexpected destination.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If such proxy only forwards what it receives, i= t doesn't need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 support mux-exclusive. It only forwards what it= gets. However,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if it sees an m- line with port 0, it may not f= orward anything.


=C2=A0 =C2=A0 Can you give me an example of the product you are referring t= o? I
=C2=A0 =C2=A0 was thinking about http://ag-projects.com/mediaproxy= / and
=C2=A0 =C2=A0 http://www.rtpproxy.org/ which both generate RTCP.

=C2=A0 =C2=A0 We are dealing with trade of between not sending unexpected t= raffic
=C2=A0 =C2=A0 and backwards compatibility. I do not think there is a way to=
=C2=A0 =C2=A0 prevent unexpected traffic and still work with all the legacy= end
=C2=A0 =C2=A0 points. I would argue that RTCP mux required is not backwards=
=C2=A0 =C2=A0 compatible change and should not work unless it is supported<= br> =C2=A0 =C2=A0 end-to-end. Only backwards compatibility required should be a= bility
=C2=A0 =C2=A0 to detect end points that do not support rtcp mux and not to = set the
=C2=A0 =C2=A0 media session with them.

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 _____________
=C2=A0 =C2=A0 Roman Shpount

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 mmusic mailing list
=C2=A0 =C2=A0 mmusic@i= etf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mmu= sic




--001a114385d8f9778b052a198f2e-- From nobody Sun Jan 24 12:21:36 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C81B3270 for ; Sun, 24 Jan 2016 12:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLcogu24enku for ; Sun, 24 Jan 2016 12:21:33 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9190B1B326D for ; Sun, 24 Jan 2016 12:21:31 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-12v.sys.comcast.net with comcast id 9wML1s00C2EPM3101wMWxF; Sun, 24 Jan 2016 20:21:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id 9wMW1s0073KdFy101wMWX7; Sun, 24 Jan 2016 20:21:30 +0000 To: Suhas Nandakumar References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> From: Paul Kyzivat Message-ID: <56A53249.5020709@alum.mit.edu> Date: Sun, 24 Jan 2016 15:21:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453666890; bh=YMUk5mfXIbSku2TdrhEq3ohVJNzLXPiRtjDBnZpFShk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=H38O38bM7RUYy9QBNK1y5B2Q1E+9eNd4eHkZuCocjNVCK11W/ec0a+04n1Nwui28r uJhRhY/lpXHnBClbtBRFi4pr35FbfpciaHrlkcEqx+s3hkn/CQXpVC1rTjShCL1qgW GVkENYlf2WgAAFXuOCZ7kgnESbBMnzZRJgtZ5A4TYvVnIj0Kbun3i2nQe7OUguq59e AB4BY3Wgjte2jcP5ECwxHFQkr+WUT8OrI2noM158NPbeKQCLJvK9vYR4FapHQu2jxx 21IA/oUamDSYWwkZOGTs74Kc00xfnVgIlFgil1/Uz/8mQ5MfCcEi+vLGI+9sEQMTYB 0V8SNwWlD7asw== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 20:21:35 -0000 On 1/24/16 2:36 PM, Suhas Nandakumar wrote: > > > On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat > wrote: > > On 1/24/16 4:41 AM, Suhas Nandakumar wrote: > > I might be repeating some discussions already made. So please > forgive me > if all of the below suggestions is beaten to death > > *Use-case: Explicitly indicate RTCP Muxing and possibly backward > compatibility* > > I support a new attribute along with some rules for existing > attributes > which allows backward compatibility (Strong goal of SDP) and also > exclusiveness of RTCP multiplexing > > Define a new attribute *"a=rtcp-mux-only" , which *in a offer > indicates > that the end-point can't receive rtcp on separate port than rtp. > > > It is *essential* to indicate the answerer behavior too. For this to > provide backward support, the answerer who supports must also > include this attribute in the answer. If it isn't present in the > answer, then the offerer knows that it hasn't been supported. I > think, in that case it must reoffer and either provide a port pair, > or else drop the media stream, to prevent RTCP from going to an > uncontrolled port. > > > [Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One where > the agent understands a=rtcp-mux but not the a=rtcp-mux-only and second > where the agent doesn't understand either. Let's think the answerer > behavior in both the cases > > Case 1: Agent supports RFC5761 but not mux-only > In this scenario we mandate that the offer includes RFC5761 > a=rtcp-mux as well whenever he offers with mux-only. Thus the answerer > will still MUX the RTCP to RTP port following RFC5761 rules. > > Case 2: Agent doesn't support RFC5761 and mux-only as well > This is the case where the answerer can process just the RFC3605 a=rtcp > attribute and can either : > 2a) send the rtcp to the port indicated in a=rtcp attribute , > thus effectively muxing > 2b) will think rtcp port specified as being error since it > matches the RTP port and reject the m=line. [[ note: this isn't defined > as an error in RFC3605 ]] > > Case 3: Answerer supports RFC5761, Mux-exclusive > In this successful scenario, the answerer can just include > a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good > enough for the Offerer to know that Answerer is able to mux the rtcp > traffic towards the offerer and also wishes to receive muxed (no > fallback) rtcp traffic from the offerer > > These seems to convert most of all the cases right Agree. > I think this ought to be viewed as an update to 3605. Maybe that isn't quite right, but it ought to be an update to *something*. It is mostly a=rtcp that is broken, because it isn't acknowledged. Any plausible use of it ends up being broken if the answerer doesn't support it, but the offerer has no way of telling that. a=rtcp-mux is negotiated. So the offerer can tell when the answerer doesn't support it. In that case it can take remedial action. There may be some stray rtcp packets until that happens. So a=rtcp-mux-only isn't really *needed*. What it does is prevent those few stray packets. But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because it doesn't solve cases when the offerer wants separate rtcp, but not on port+1, and the answerer doesn't support that. Perhaps the right solution is to introduce a new attribute to *replace* a=rtcp. It would have similar semantics, but require negotiation. It could in principle also replace a=rtcp-mux, since if you use the same address/port for both rtp and rtcp you are obviously requesting mux. You could still use a=rtcp and/or a=rtcp-mux for backward compatibility, but if you need rtcp-mux-only semantics, then you could just use this new attribute. If it isn't ack'ed, then take remedial action. This new attribute would have same syntax as a=rtcp, except for the name. New rules for it would be: - if in offer, must also be in answer. The answer gives the port(/addr) for the answerer. If the answerer wants port+1 it needs to compute what that is and put it in. - if it is *not* in the offer, it can't be used in the answer. If the answerer can't do rtcp on port+1 then it needs to refuse the media stream. It could try sending a subsequent offer for what it can do. - we *could* explicitly allow the port to be set to zero, and/or the address to be set to 0.0.0.0, to indicate that rtcp is not desired. (Don't know if it is a good idea.) Thanks, Paul From nobody Sun Jan 24 13:58:58 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4677E1B33AE for ; Sun, 24 Jan 2016 13:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyHL_E7GJGFX for ; Sun, 24 Jan 2016 13:58:55 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 15E851B333C for ; Sun, 24 Jan 2016 13:58:55 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id e64so65683963vkg.0 for ; Sun, 24 Jan 2016 13:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eZo8yodxTSUqz8b/yH2Pea7Sdz5NmVdIBibhkQbZkic=; b=k1OEfklLv6iHX70wE1Rthdh7lAOuZJxcU7yFPv85Zlz4U60TYl3stP+Uy69GmY+ETM 4Uq4rgco324HZl7Q7D35w8j92LyJkpIaPANxzpqS96THERPz/NrU2wpHVEC7z9lVGptH Ej9o3T41OZ/eL6wRCIaT1tA7lESljG+Md1aGPCtaAVBqGoTyG+URd7m0at4T0Q4BYlWj G69IL8lPzKS6l151NE7mF4ZHas+e7I+a2hQ1dnK/BuODE/jjHdCtN+EE9+60nbVl8f9A qrnjf1JmsfCZR4CcLNjp1pQ24sYfWWt7WJzJW5DYL8Lkf4CMfSXw/XlTuZgp9lAd5Kww Efbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eZo8yodxTSUqz8b/yH2Pea7Sdz5NmVdIBibhkQbZkic=; b=OWywbLKPCekOgDzjGu2eVdJC8lOFuBIKA0hRWmhuej4iMZsv5wxZN4Fxp2urKf6nPY ElysVOT4ygLi0gzh/dCMz5AG5GcJbOhfpNZeKrEXqFQHnPH/bNgLDIkE/JxYZX9n670b 56EjR7gw8AyqH/EjjIKsikXCxi73jykY84jHkas54MgZuBA2aX1UD3PkgLob8h0GfW/C 16FhGC/rW3kot7eRRxkL0rKhmofsR7ON3a6zyEIwGImnfu6cLZ9iNCFNL2eJX9724CB+ 9Mqq3MeFo44Nk2jqB3jynEYlyDKx2pV1TYR9a2HCm6DGQkZoXUUe0DXk09KG3O4kR+A9 DmwQ== X-Gm-Message-State: AG10YORIFjWPqHr7vHHLpo61ZHnsht7REcbgmrQ9kg2xJtAI3FEr/79ogjV0bUGTHQV+mGCphkucWxEzMjLebg== MIME-Version: 1.0 X-Received: by 10.31.50.213 with SMTP id y204mr8470415vky.109.1453672734207; Sun, 24 Jan 2016 13:58:54 -0800 (PST) Received: by 10.31.106.130 with HTTP; Sun, 24 Jan 2016 13:58:54 -0800 (PST) In-Reply-To: <56A53249.5020709@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> Date: Sun, 24 Jan 2016 13:58:54 -0800 Message-ID: From: Suhas Nandakumar To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1144053cf13321052a1b8ecf Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 21:58:57 -0000 --001a1144053cf13321052a1b8ecf Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 12:21 PM, Paul Kyzivat wrote: > On 1/24/16 2:36 PM, Suhas Nandakumar wrote: > >> >> >> On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat > > wrote: >> >> On 1/24/16 4:41 AM, Suhas Nandakumar wrote: >> >> I might be repeating some discussions already made. So please >> forgive me >> if all of the below suggestions is beaten to death >> >> *Use-case: Explicitly indicate RTCP Muxing and possibly backward >> compatibility* >> >> I support a new attribute along with some rules for existing >> attributes >> which allows backward compatibility (Strong goal of SDP) and also >> exclusiveness of RTCP multiplexing >> >> Define a new attribute *"a=rtcp-mux-only" , which *in a offer >> indicates >> that the end-point can't receive rtcp on separate port than rtp. >> >> >> It is *essential* to indicate the answerer behavior too. For this to >> provide backward support, the answerer who supports must also >> include this attribute in the answer. If it isn't present in the >> answer, then the offerer knows that it hasn't been supported. I >> think, in that case it must reoffer and either provide a port pair, >> or else drop the media stream, to prevent RTCP from going to an >> uncontrolled port. >> >> >> [Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One where >> the agent understands a=rtcp-mux but not the a=rtcp-mux-only and second >> where the agent doesn't understand either. Let's think the answerer >> behavior in both the cases >> >> Case 1: Agent supports RFC5761 but not mux-only >> In this scenario we mandate that the offer includes RFC5761 >> a=rtcp-mux as well whenever he offers with mux-only. Thus the answerer >> will still MUX the RTCP to RTP port following RFC5761 rules. >> >> Case 2: Agent doesn't support RFC5761 and mux-only as well >> This is the case where the answerer can process just the RFC3605 a=rtcp >> attribute and can either : >> 2a) send the rtcp to the port indicated in a=rtcp attribute , >> thus effectively muxing >> 2b) will think rtcp port specified as being error since it >> matches the RTP port and reject the m=line. [[ note: this isn't defined >> as an error in RFC3605 ]] >> >> Case 3: Answerer supports RFC5761, Mux-exclusive >> In this successful scenario, the answerer can just include >> a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good >> enough for the Offerer to know that Answerer is able to mux the rtcp >> traffic towards the offerer and also wishes to receive muxed (no >> fallback) rtcp traffic from the offerer >> >> These seems to convert most of all the cases right >> > > Agree. > > I think this ought to be viewed as an update to 3605. >> > > Maybe that isn't quite right, but it ought to be an update to *something*. > [Suhas] .. If i am not wrong, the above proposal doesn't need updates to RFC3605 and when used in combination with a=rtcp-mux-only the intent is clear. > It is mostly a=rtcp that is broken, because it isn't acknowledged. Any > plausible use of it ends up being broken if the answerer doesn't support > it, but the offerer has no way of telling that. > > a=rtcp-mux is negotiated. So the offerer can tell when the answerer > doesn't support it. In that case it can take remedial action. There may be > some stray rtcp packets until that happens. So a=rtcp-mux-only isn't really > *needed*. What it does is prevent those few stray packets. > > But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because it > doesn't solve cases when the offerer wants separate rtcp, but not on > port+1, and the answerer doesn't support that. > > Perhaps the right solution is to introduce a new attribute to *replace* > a=rtcp. It would have similar semantics, but require negotiation. It could > in principle also replace a=rtcp-mux, since if you use the same > address/port for both rtp and rtcp you are obviously requesting mux. You > could still use a=rtcp and/or a=rtcp-mux for backward compatibility, but if > you need rtcp-mux-only semantics, then you could just use this new > attribute. If it isn't ack'ed, then take remedial action. > > This new attribute would have same syntax as a=rtcp, except for the name. > New rules for it would be: > > - if in offer, must also be in answer. The answer gives the port(/addr) > for the answerer. If the answerer wants port+1 it needs to compute > what that is and put it in. > - if it is *not* in the offer, it can't be used in the answer. If the > answerer can't do rtcp on port+1 then it needs to refuse the media > stream. It could try sending a subsequent offer for what it can do. > > - we *could* explicitly allow the port to be set to zero, and/or the > address to be set to 0.0.0.0, to indicate that rtcp is not desired. > (Don't know if it is a good idea.) > > Thanks, > Paul > --001a1144053cf13321052a1b8ecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 24, 2016 at 12:21 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 1/24/16 2:36 PM, Suhas Nandakumar wrote:


On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 On 1/24/16 4:41 AM, Suhas Nandakumar wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I might be repeating some discussions already m= ade. So please
=C2=A0 =C2=A0 =C2=A0 =C2=A0 forgive me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if all of the below suggestions is beaten to de= ath

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Use-case: Explicitly indicate RTCP Muxing and = possibly backward
=C2=A0 =C2=A0 =C2=A0 =C2=A0 compatibility*

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I support a new attribute along with some rules= for existing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which allows backward compatibility (Strong goa= l of SDP) and also
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exclusiveness of RTCP multiplexing

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Define a new attribute *"a=3Drtcp-mux-only= " , which *in a offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 indicates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that the end-point can't receive rtcp on se= parate port than rtp.


=C2=A0 =C2=A0 It is *essential* to indicate the answerer behavior too. For = this to
=C2=A0 =C2=A0 provide backward support, the answerer who supports must also=
=C2=A0 =C2=A0 include this attribute in the answer. If it isn't present= in the
=C2=A0 =C2=A0 answer, then the offerer knows that it hasn't been suppor= ted. I
=C2=A0 =C2=A0 think, in that case it must reoffer and either provide a port= pair,
=C2=A0 =C2=A0 or else drop the media stream, to prevent RTCP from going to = an
=C2=A0 =C2=A0 uncontrolled port.


[Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One where the agent understands a=3Drtcp-mux but not the a=3Drtcp-mux-only and second=
where the agent doesn't understand either. Let's think the answerer=
behavior in both the cases

Case 1: Agent supports RFC5761 but not mux-only
=C2=A0 =C2=A0 In this scenario we mandate that the offer includes RFC5761 a=3Drtcp-mux as well whenever he offers with mux-only. Thus the answerer will still MUX the RTCP to RTP port following RFC5761 rules.

Case 2: Agent doesn't support RFC5761 and mux-only as well
This is=C2=A0 the case where the answerer can process just the RFC3605 a=3D= rtcp
attribute and can either :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2a) send the rtcp to the port indicated in a=3D= rtcp attribute ,
thus effectively muxing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2b) will think rtcp port specified as being err= or since it
matches the RTP port and reject the m=3Dline. [[ note: this isn't defin= ed
as an error in RFC3605 ]]

Case 3: Answerer supports RFC5761, Mux-exclusive
=C2=A0 =C2=A0 In this successful scenario, the answerer can just include a=3Drtcp-mux and a=3Drtcp-mux-exclusive in its answer and that is good
enough for the Offerer to know that Answerer is able to mux the rtcp
traffic towards the offerer and also wishes to receive muxed (no
fallback) rtcp traffic from the offerer

These seems to convert most of all the cases right

Agree.

=C2=A0 =C2=A0 I think this ought to be viewed as an update to 3605.

 Maybe that isn't quite right, but it ought to be an update to *somethin= g*.

[Suhas] .. If i am not wrong, the a= bove proposal doesn't need updates to RFC3605 and when used in combinat= ion with a=3Drtcp-mux-only the intent is clear. =C2=A0

=

It is mostly a=3Drtcp that is broken, because it isn't acknowledged. An= y plausible use of it ends up being broken if the answerer doesn't supp= ort it, but the offerer has no way of telling that.

a=3Drtcp-mux is negotiated. So the offerer can tell when the answerer doesn= 't support it. In that case it can take remedial action. There may be s= ome stray rtcp packets until that happens. So a=3Drtcp-mux-only isn't r= eally *needed*. What it does is prevent those few stray packets.

But a=3Drtcp-mux-only isn't the best answer for fixing a=3Drtcp, becaus= e it doesn't solve cases when the offerer wants separate rtcp, but not = on port+1, and the answerer doesn't support that.

Perhaps the right solution is to introduce a new attribute to *replace* a= =3Drtcp. It would have similar semantics, but require negotiation. It could= in principle also replace a=3Drtcp-mux, since if you use the same address/= port for both rtp and rtcp you are obviously requesting mux. You could stil= l use a=3Drtcp and/or a=3Drtcp-mux for backward compatibility, but if you n= eed rtcp-mux-only semantics, then you could just use this new attribute. If= it isn't ack'ed, then take remedial action.

This new attribute would have same syntax as a=3Drtcp, except for the name.= New rules for it would be:

- if in offer, must also be in answer. The answer gives the port(/addr)
=C2=A0 for the answerer. If the answerer wants port+1 it needs to compute =C2=A0 what that is and put it in.
- if it is *not* in the offer, it can't be used in the answer. If the =C2=A0 answerer can't do rtcp on port+1 then it needs to refuse the med= ia
=C2=A0 stream. It could try sending a subsequent offer for what it can do.<= br>
- we *could* explicitly allow the port to be set to zero, and/or the
=C2=A0 address to be set to 0.0.0.0, to indicate that rtcp is not desired.<= br> =C2=A0 (Don't know if it is a good idea.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

--001a1144053cf13321052a1b8ecf-- From nobody Sun Jan 24 23:36:38 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62881AD26B for ; Sun, 24 Jan 2016 23:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuC-2tCPiByB for ; Sun, 24 Jan 2016 23:36:35 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290B31AD21C for ; Sun, 24 Jan 2016 23:36:35 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-67-56a5d0807754 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.71.05041.080D5A65; Mon, 25 Jan 2016 08:36:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Mon, 25 Jan 2016 08:36:31 +0100 From: Christer Holmberg To: Suhas Nandakumar , Roman Shpount Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoIAAIcaAgAEX24CAAX87kA== Date: Mon, 25 Jan 2016 07:36:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D59386@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7k27DhaVhBheW61pMXf6YxWLFhgOs FjMuTGW22Dm3g9mBxePv+w9MHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBkXX39m LtjFVnF00UW2BsYlbF2MnBwSAiYSXfsXQtliEhfurQeyuTiEBA4zSqx5tZ8RwlnCKLHlTTtL FyMHB5uAhUT3P22QBhEBX4mdc5pYQWxmIPv9z+nsILawgJ1E8+n1zBA19hKn1n5ghLCzJE4t OQUWZxFQlTh+8C4jyEheoN5pl0ohVv1hkVi5axnYKk6BQInOZR4g5YxAt30/tYYJYpW4xK0n 85kgbhaQWLLnPDOELSrx8vE/VghbUeLjq31g45kFNCXW79KHaFWUmNL9EOxKXgFBiZMzn7BM YBSbhWTqLISOWUg6ZiHpWMDIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjML4ObvlttYPx 4HPHQ4wCHIxKPLwF4UvDhFgTy4orcw8xSnAwK4nwLt4PFOJNSaysSi3Kjy8qzUktPsQozcGi JM57kH9RmJBAemJJanZqakFqEUyWiYNTqoFRteW3xa+uyAPap1qPldhxLJuaP1Xz9FXhfT5d lx2PT7a6aMsfGtrteuKs4ud/qeVajblH7fL+VHWs68pYI69iWXfkJdvbu2Fnnvin7tx1ento Xlz+wun2Uw8LCR9MfRR/pW1OqnBGmPDKstL71pcvzHNpPZRv+bs0wki/qLVbm01xkYDSltdK LMUZiYZazEXFiQDl31InqwIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 07:36:36 -0000 SGksDQoNCi4uLg0KDQo+V2hlbiBJQ0UgaXMgaW4gdXNhZ2UgYW5kIHRoZSBPZmZlciB3YW50IHRv IHN1cHBvcnQgYT1ydGNwLW11eC1vbmx5LCBpdCBkb2VzIHRoZSBmb2xsb3dpbmcNCj5hKSBpbmNs dWRlIGE9cnRjcC1tdXgtb25seQ0KPmIpIGluY2x1ZGUgYT1ydGNwIDxydHAtcG9ydD4gPC0tIFJU UCBwb3J0DQo+YykgaW5jbHVkZSBSVENQIGNhbmRpZGF0ZSB3aXRoIHBvcnQgaW5mb3JtYXRpb24g dGhhdCBtYXRjaGVzIFJUUC4gTm8gbmVlZCB0byBkbyBuZXcgdHVybiBhbGxvY2F0aW9uIGZvciBS VENQIGVpdGhlci4NCg0KTm90ZSB0aGF0IHN1Z2dlc3RlZCBJQ0UgdGV4dCBzYXlzIHRoYXQgaWYg YW4gZW50aXR5IG9ubHkgc3VwcG9ydHMgbXV4IHRoZXJlIGlzIG5vIG5lZWQgdG8gaW5jbHVkZSBS VENQIGNhbmRpZGF0ZXMuIEluc3RlYWQgdGhlIGVudGl0eSB3aWxsIG9ubHkgaW5jbHVkZSBSVFAg Y2FuZGlkYXRlcyAodGhlcmUgYXJlIG90aGVyIG1lY2hhbmlzbXMgdG8gaW5kaWNhdGUgd2hldGhl ciB0aGUgZW50aXR5IGRvZXNuJ3Qgc3VwcG9ydC93YW50IHRvIHVzZSBSVENQIHRvIGJlZ2luIHdp dGgpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Sun Jan 24 23:44:21 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369D01AD356 for ; Sun, 24 Jan 2016 23:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 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, HTML_OBFUSCATE_05_10=0.26, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRTGRUHHj4mz for ; Sun, 24 Jan 2016 23:44:20 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 CD75E1AD353 for ; Sun, 24 Jan 2016 23:44:19 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id k1so69426503vkb.2 for ; Sun, 24 Jan 2016 23:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8KFWCFpswJ/j2Yjqvv6qkZPqW56uMTWaVoNoa2wRYqM=; b=kglvVMeYTt+TMSbFG9C8vMLuQNS/whd2I7am1CdWR6ca2ooonHqbilqi7bPNwsDv4P Aqye7L6Gy06/pGBtSPPY2yZg1DsI7Y2s9h9ZqYEqPCpQQtkzIQnE95txZN2LS4Jdqpp6 RwLhl7uN/MHjyeBldOBWG1Gb/K/z3UqO3iYASfzPZRbW9+aeQ4daeWLIcjOihywis9SQ oXIUiUoGsyseh+tyjn5cW051injbXuB/6nPy348iEXHCoaHcVUQuOghc3mS+Si4L9I4P BJ8icOMpyrSThnW0DZNiqic4a2XVavRNY5AFaZefUZhlL4mcpRYh+X8FEpnQIbcS7Aja 2Hiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8KFWCFpswJ/j2Yjqvv6qkZPqW56uMTWaVoNoa2wRYqM=; b=WEnL+MEm74YvIZ5ra3iojyLuAB4kmA3JgylGHyUd1GEuSvPCEaP2iiC9hGgaeLkiBE qq5co++E36H6aLwkCfGTgozIDJshS0MSRwydXxNUF7evWOiLCqHYXMl04yChgkvXWxd+ nWzYVz8rNRovCVSXU7ekl/V4pO/ydiiGIUZqiNb1D5PZ9ENtbvVr6mKLlE5Npu2s7FfA C7kynjQ3w8UU4RvZq/k/TRSA3BDUcZe2HyTOX6CokrBQ6G6dsl4LBMEPsTl/UbmFW52f 7bVsDaDRgGoJQiFI2GorTn3wHZKJBBnHOar6ktHAtIDnqp29TIrBF1ipmbPaXWVk4JDh PXlA== X-Gm-Message-State: AG10YOSFILKlpBEUchB+wXwuARQJrCZU0yfD5K9pIzWqMrMQROkmvfaIRuQj/ptbjgrlkJ7V2LQ0rL+NCz3i2w== MIME-Version: 1.0 X-Received: by 10.31.54.23 with SMTP id d23mr9728987vka.25.1453707858999; Sun, 24 Jan 2016 23:44:18 -0800 (PST) Received: by 10.31.106.130 with HTTP; Sun, 24 Jan 2016 23:44:18 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D59386@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D59386@ESESSMB209.ericsson.se> Date: Sun, 24 Jan 2016 23:44:18 -0800 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114385d88affcc052a23bcf9 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 07:44:21 -0000 --001a114385d88affcc052a23bcf9 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 11:36 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > ... > > >When ICE is in usage and the Offer want to support a=rtcp-mux-only, it > does the following > >a) include a=rtcp-mux-only > >b) include a=rtcp <-- RTP port > >c) include RTCP candidate with port information that matches RTP. No need > to do new turn allocation for RTCP either. > > Note that suggested ICE text says that if an entity only supports mux > there is no need to include RTCP candidates. Instead the entity will only > include RTP candidates (there are other mechanisms to indicate whether the > entity doesn't support/want to use RTCP to begin with). > > [Suhas] As an offerer you have no idea if the Answerer supports RTCP Mux. So it needs to include RTCP candidates. This is what RFC5245bis says "In the case of RTP, this would happen when one agent provides candidates for RTCP, and the other does not. As another example, the initiating agent can multiplex RTP and RTCP on the same port [RFC5761]. However, since the initiating agent doesn't know if the peer agent can perform such multiplexing, it includes candidates for RTP and RTCP on separate ports. If the peer agent can perform such multiplexing, it would include just a single component for each candidate -- for the combined RTP/RTCP mux. ICE would end up acting as if there was just a single component for this candidate." > Regards, > > Christer > > --001a114385d88affcc052a23bcf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 24, 2016 at 11:36 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,
...

>When ICE is in usage and the Offer want to support a=3Drtcp-mux-only, i= t does the following
>a) include a=3Drtcp-mux-only
>b) include a=3Drtcp <rtp-port> <-- RTP port
>c) include RTCP candidate with port information that matches RTP. No ne= ed to do new turn allocation for RTCP either.

Note that suggested ICE text says that if an entity only supports mu= x there is no need to include RTCP candidates. Instead the entity will only= include RTP candidates (there are other mechanisms to indicate whether the= entity doesn't support/want to use RTCP to begin with).


[Suhas] As an offerer you have no idea= if the Answerer supports RTCP Mux. So it needs to include RTCP candidates.=
This is what RFC5245bis says

"In the = case of RTP, this would happen when one agent provides=C2=A0candidates = for RTCP, and the other does not. As another example, the=C2=A0initiat= ing agent can multiplex RTP and RTCP on the same port=C2=A0[RFC5761]. = However, since the initiating agent doesn't know if the=C2=A0peer a= gent can perform such multiplexing, it includes candidates for=C2=A0= RTP= and RTCP on separate ports. If the peer agent can perform such=C2=A0= =C2=A0multiplexing, it would include just a single component for each= =C2=A0candidate -- for the combined RTP/RTCP mux. ICE would end up acting<= /span>=C2=A0as if there was just a single component for this candidate."<= /span>
=C2=A0
Regards,

Christer


--001a114385d88affcc052a23bcf9-- From nobody Sun Jan 24 23:51:08 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB11A87B2 for ; Sun, 24 Jan 2016 23:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO1jhsTDCZP0 for ; Sun, 24 Jan 2016 23:51:06 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAEC1A87A5 for ; Sun, 24 Jan 2016 23:51:05 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-20-56a5d3e7d943 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.3F.05690.7E3D5A65; Mon, 25 Jan 2016 08:51:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Mon, 25 Jan 2016 08:51:03 +0100 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoIAAIcaAgAEX24CAAX87kP//8nEAgAASKmA= Date: Mon, 25 Jan 2016 07:51:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D59446@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D59386@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2J7oO7zy0vDDDZeVbSYuvwxi8WKDQdY LWZcmMpssXNuB7MDi8ff9x+YPHbOusvusWTJTyaPW1MKAliiuGxSUnMyy1KL9O0SuDI+7upg KZgmWnFs+lvGBsYLIl2MnBwSAiYSm7/eZoWwxSQu3FvP1sXIxSEkcJhRYlNzPzuEs4RRonl5 I1MXIwcHm4CFRPc/bZAGEQEtidWL5zKB2MwCRRJNCzazgNjCAnYSzafXM0PU2EucWvuBEcIu k7i24zsbiM0ioCqx8MYUsBpeAV+JWS+esEDsameTON8/B6yBUyBQ4vbBx2BFjEDXfT+1BmqZ uMStJ/OZIK4WkFiy5zwzhC0q8fLxP6hvFCU+vtrHCHIzs4CmxPpd+hCtihJTuh+yQ+wVlDg5 8wnLBEaxWUimzkLomIWkYxaSjgWMLKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAmPs4Jbf ujsYV792PMQowMGoxMNbEL40TIg1say4MvcQowQHs5II7+L9QCHelMTKqtSi/Pii0pzU4kOM 0hwsSuK8B/kXhQkJpCeWpGanphakFsFkmTg4pRoYWSfP+sR8o/mf6U815oiyltTS5cpT/or0 JfkvcFZ6IqRbVD/fXPeezqSeM8+TpAUURMTcdM8IXhE5vqb51JkTKxre2AU+nve+3G+O4l3T Zfm1d0S4y5ie59tPzeI8/PDU/wVdzjOztgjpB7U+m1xiICIlvEApKGXXX8kYuXuHc0Iqtiln ra9WYinOSDTUYi4qTgQAcc99Oq0CAAA= Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 07:51:07 -0000 SGksDQoNCj4+V2hlbiBJQ0UgaXMgaW4gdXNhZ2UgYW5kIHRoZSBPZmZlciB3YW50IHRvIHN1cHBv cnQgYT1ydGNwLW11eC1vbmx5LCBpdCBkb2VzIHRoZSBmb2xsb3dpbmcNCj4+YSkgaW5jbHVkZSBh PXJ0Y3AtbXV4LW9ubHkNCj4+YikgaW5jbHVkZSBhPXJ0Y3AgPHJ0cC1wb3J0PiA8LS0gUlRQIHBv cnQNCj4+YykgaW5jbHVkZSBSVENQIGNhbmRpZGF0ZSB3aXRoIHBvcnQgaW5mb3JtYXRpb24gdGhh dCBtYXRjaGVzIFJUUC4gTm8gbmVlZCB0byBkbyBuZXcgdHVybiBhbGxvY2F0aW9uIGZvciBSVENQ IGVpdGhlci4NCj4NCj5Ob3RlIHRoYXQgc3VnZ2VzdGVkIElDRSB0ZXh0IHNheXMgdGhhdCBpZiBh biBlbnRpdHkgb25seSBzdXBwb3J0cyBtdXggdGhlcmUgaXMgbm8gbmVlZCB0byBpbmNsdWRlIFJU Q1AgY2FuZGlkYXRlcy4gSW5zdGVhZCB0aGUgZW50aXR5IHdpbGwgb25seSBpbmNsdWRlIFJUUCBj YW5kaWRhdGVzICh0aGVyZSBhcmUgb3RoZXIgbWVjaGFuaXNtcyB0byBpbmRpY2F0ZSB3aGV0aGVy IHRoZSBlbnRpdHkgZG9lc24ndCBzdXBwb3J0L3dhbnQgdG8gdXNlIFJUQ1AgdG8gYmVnaW4gd2l0 aCkuDQo+DQo+W1N1aGFzXSBBcyBhbiBvZmZlcmVyIHlvdSBoYXZlIG5vIGlkZWEgaWYgdGhlIEFu c3dlcmVyIHN1cHBvcnRzIFJUQ1AgTXV4LiBTbyBpdCBuZWVkcyB0byBpbmNsdWRlIFJUQ1AgY2Fu ZGlkYXRlcy4NCj5UaGlzIGlzIHdoYXQgUkZDNTI0NWJpcyBzYXlzDQo+DQo+IkluIHRoZSBjYXNl IG9mIFJUUCwgdGhpcyB3b3VsZCBoYXBwZW4gd2hlbiBvbmUgYWdlbnQgcHJvdmlkZXPCoGNhbmRp ZGF0ZXMgZm9yIFJUQ1AsIGFuZCB0aGUgb3RoZXIgZG9lcyBub3QuIEFzIGFub3RoZXIgZXhhbXBs ZSwgdGhlwqBpbml0aWF0aW5nIGFnZW50IGNhbg0KPiBtdWx0aXBsZXggUlRQIGFuZCBSVENQIG9u IHRoZSBzYW1lIHBvcnTCoFtSRkM1NzYxXS4gSG93ZXZlciwgc2luY2UgdGhlIGluaXRpYXRpbmcg YWdlbnQgZG9lc24ndCBrbm93IGlmIHRoZcKgcGVlciBhZ2VudCBjYW4gcGVyZm9ybSBzdWNoIG11 bHRpcGxleGluZywgaXQgaW5jbHVkZXMgDQo+IGNhbmRpZGF0ZXMgZm9ywqBSVFAgYW5kIFJUQ1Ag b24gc2VwYXJhdGUgcG9ydHMuIElmIHRoZSBwZWVyIGFnZW50IGNhbiBwZXJmb3JtIHN1Y2jCoMKg bXVsdGlwbGV4aW5nLCBpdCB3b3VsZCBpbmNsdWRlIGp1c3QgYSBzaW5nbGUgY29tcG9uZW50IGZv ciBlYWNowqBjYW5kaWRhdGUgLS0gZm9yIA0KPnRoZSBjb21iaW5lZCBSVFAvUlRDUCBtdXguIElD RSB3b3VsZCBlbmQgdXAgYWN0aW5nwqBhcyBpZiB0aGVyZSB3YXMganVzdCBhIHNpbmdsZSBjb21w b25lbnQgZm9yIHRoaXMgY2FuZGlkYXRlLiINCg0KVGhlIGZvbGxvd2luZyBuZXh0IHRleHQgaGFz IGJlZW4gZGlzY3Vzc2VkIG9uIHRoZSBJQ0UgbGlzdDoNCg0KIiAgICAgV2hlbiBjYW5kaWRhdGVz IGFyZSBvYnRhaW5lZCwgdW5sZXNzIHRoZSBhZ2VudCBrbm93cyBmb3Igc3VyZSB0aGF0DQogICAg ICAgUlRQL1JUQ1AgbXVsdGlwbGV4aW5nIHdpbGwgYmUgdXNlZCAoaS5lLiB0aGUgYWdlbnQga25v d3MgdGhhdCB0aGUNCiAgICAgICBvdGhlciBhZ2VudCBhbHNvIHN1cHBvcnRzLCBhbmQgaXMgd2ls bGluZyB0byB1c2UsIFJUUC9SVENQDQogICAgICAgbXVsdGlwbGV4aW5nKSwgb3IgdW5sZXNzIHRo ZSBhZ2VudCBvbmx5IHN1cHBvcnRzIFJUUC9SVENQDQogICAgICAgbXVsdGlwbGV4aW5nLCB0aGUg YWdlbnQgTVVTVCBvYnRhaW4gYSBzZXBhcmF0ZSBjYW5kaWRhdGUgZm9yIFJUQ1AuDQogICAgICAg SWYgYW4gYWdlbnQgaGFzIG9idGFpbmVkIGEgY2FuZGlkYXRlIGZvciBSVENQLCBhbmQgZW5kcyB1 cCB1c2luZyBSVFAvDQogICAgICAgUlRDUCBtdWx0aXBsZXhpbmcsIHRoZSBhZ2VudCBkb2VzIG5v dCBuZWVkIHRvIHBlcmZvcm0gY29ubmVjdGl2aXR5DQogICAgICAgY2hlY2tzIG9uIHRoZSBSVENQ IGNhbmRpZGF0ZS4iDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Sun Jan 24 23:58:07 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEEA1AD36F for ; Sun, 24 Jan 2016 23:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCCRR642Uzlu for ; Sun, 24 Jan 2016 23:58:04 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 CC66C1A87B8 for ; Sun, 24 Jan 2016 23:58:03 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id e64so70252964vkg.0 for ; Sun, 24 Jan 2016 23:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dgi0K4+JkzQNQVnmWrNWt1/MXrJTAVU3tNwVlkJ3KOg=; b=iF0+bZv/FzopwpXlDF2mAn20Xq5MckPEcx4Ypj5Gojci8TugD9qgcbJfPVqYzmsHSa FNZR9MR9qqBNiy0Ya7B535FzW+JiObxYUHR1mYBZPc07XnsQYVBoF0g76M4fi2w5kfTy RfxcxBJJ+YQYsSFutBH+oVqj6jMZ/jPGBx1axmFcMPnmZvXJNcEPearMOx3es+KSQ1TQ uev7gOKVBDAada/ubqvnSOEjWG+Ili8FQPDcmdPaN4Zh3JMEt5A1RgokqXwPnREbEd6F I765MEGwg//Y8PwH+1RnOdx+cPIHGud7sAS95nlYE3ckl6dJwGJpvmATCCf3CaRjEOgq nXmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Dgi0K4+JkzQNQVnmWrNWt1/MXrJTAVU3tNwVlkJ3KOg=; b=gcgnIyXAuq64IyCthkSbATQL9edwO4nerjeIgyF4MMMSt1I6K8d4bgvzzW7wpyEYRy 0o47jfH7EazUjIS+E/AmYRqxBPJvcD1rVLJIg/9sCdy6lrVFXW2992/zzJVOosX6p7jX qpKfAMVIDUta/4FD6UzbXwYO4/UO47713NLKNEeTOaPve1kwvGg8+7JUOIcTgyGJ/kBR DshA8DIE1lYegC3jhls+23RiECpR3PKUUsHjrI71zWozuxq9VJMPBaGlYKRV99Bfevfk DwkSaD6szNxgC9s2tZtFvf08iGqJRZzJ01TDvpYzizR3/CR5mPY9XDCF/W3xbt26ej78 aTGg== X-Gm-Message-State: AG10YOQUjEm5URqmVs8UiUJSEhRqi3p63kw5MWEVSq5hAWDG1qfVzePHt6+X6dRkEC8njKOWPhFBZNHdLoNBsQ== MIME-Version: 1.0 X-Received: by 10.31.50.213 with SMTP id y204mr9407416vky.109.1453708682852; Sun, 24 Jan 2016 23:58:02 -0800 (PST) Received: by 10.31.106.130 with HTTP; Sun, 24 Jan 2016 23:58:02 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D59446@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D59386@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D59446@ESESSMB209.ericsson.se> Date: Sun, 24 Jan 2016 23:58:02 -0800 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1144053ca5fec1052a23edde Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 07:58:05 -0000 --001a1144053ca5fec1052a23edde Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 11:51 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>When ICE is in usage and the Offer want to support a=rtcp-mux-only, it > does the following > >>a) include a=rtcp-mux-only > >>b) include a=rtcp <-- RTP port > >>c) include RTCP candidate with port information that matches RTP. No > need to do new turn allocation for RTCP either. > > > >Note that suggested ICE text says that if an entity only supports mux > there is no need to include RTCP candidates. Instead the entity will only > include RTP candidates (there are other mechanisms to indicate whether the > entity doesn't support/want to use RTCP to begin with). > > > >[Suhas] As an offerer you have no idea if the Answerer supports RTCP Mux. > So it needs to include RTCP candidates. > >This is what RFC5245bis says > > > >"In the case of RTP, this would happen when one agent provides candidates > for RTCP, and the other does not. As another example, the initiating agent > can > > multiplex RTP and RTCP on the same port [RFC5761]. However, since the > initiating agent doesn't know if the peer agent can perform such > multiplexing, it includes > > candidates for RTP and RTCP on separate ports. If the peer agent can > perform such multiplexing, it would include just a single component for > each candidate -- for > >the combined RTP/RTCP mux. ICE would end up acting as if there was just a > single component for this candidate." > > The following next text has been discussed on the ICE list: > > " When candidates are obtained, unless the agent knows for sure that > RTP/RTCP multiplexing will be used (i.e. the agent knows that the > other agent also supports, and is willing to use, RTP/RTCP > multiplexing), or unless the agent only supports RTP/RTCP > multiplexing, the agent MUST obtain a separate candidate for RTCP. > If an agent has obtained a candidate for RTCP, and ends up using > RTP/ > RTCP multiplexing, the agent does not need to perform connectivity > checks on the RTCP candidate." > > [Suhas] I see .. however I am not sure about the below statement " i.e. the agent knows that the other agent also supports, and is willing to use, RTP/RTCP multiplexing" what mechanism is available to ensure the *peer supports and is willing to use *RTCP multiplexing. At any point as a peer, I can support RTCP Mux but might decide not to use for a given session. These were the few reasons that i thought motivated for supporting mux-exclusive in the first place Regards, > > Christer > > --001a1144053ca5fec1052a23edde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 24, 2016 at 11:51 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,
>>When ICE is in usage and the Offer want to support a=3Drtcp-mux-onl= y, it does the following
>>a) include a=3Drtcp-mux-only
>>b) include a=3Drtcp <rtp-port> <-- RTP port
>>c) include RTCP candidate with port information that matches RTP. N= o need to do new turn allocation for RTCP either.
>
>Note that suggested ICE text says that if an entity only supports mux t= here is no need to include RTCP candidates. Instead the entity will only in= clude RTP candidates (there are other mechanisms to indicate whether the en= tity doesn't support/want to use RTCP to begin with).
>
>[Suhas] As an offerer you have no idea if the Answerer supports RTCP Mu= x. So it needs to include RTCP candidates.
>This is what RFC5245bis says
>
>"In the case of RTP, this would happen when one agent provides=C2= =A0candidates for RTCP, and the other does not. As another example, the=C2= =A0initiating agent can
> multiplex RTP and RTCP on the same port=C2=A0[RFC5761]. However, since= the initiating agent doesn't know if the=C2=A0peer agent can perform s= uch multiplexing, it includes
> candidates for=C2=A0RTP and RTCP on separate ports. If the peer agent = can perform such=C2=A0=C2=A0multiplexing, it would include just a single co= mponent for each=C2=A0candidate -- for
>the combined RTP/RTCP mux. ICE would end up acting=C2=A0as if there was= just a single component for this candidate."

The following next text has been discussed on the ICE list:

"=C2=A0 =C2=A0 =C2=A0When candidates are obtained, unless the agent kn= ows for sure that
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP/RTCP multiplexing will be used (i.e. the age= nt knows that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0other agent also supports, and is willing to use= , RTP/RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiplexing), or unless the agent only supports= RTP/RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiplexing, the agent MUST obtain a separate c= andidate for RTCP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an agent has obtained a candidate for RTCP, a= nd ends up using RTP/
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP multiplexing, the agent does not need to pe= rform connectivity
=C2=A0 =C2=A0 =C2=A0 =C2=A0checks on the RTCP candidate."


[Suhas]=C2=A0
I see .. howev= er I am not sure about the below statement=C2=A0

&= quot;=C2=A0i.e. the agent knows that the= =C2=A0other agent also supports, an= d is willing to use, RTP/RTCP=C2=A0= multiplexing"

what mechanism is availa= ble to ensure the peer supports and is willing to use =C2=A0RTCP mul= tiplexing. At any point as a peer, I can support RTCP Mux but might decide = not to use for a given session. These were the few reasons that i thought m= otivated for supporting mux-exclusive in the first place
=C2=A0

Regards,

Christer


--001a1144053ca5fec1052a23edde-- From nobody Mon Jan 25 00:01:28 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9FF1AD379 for ; Mon, 25 Jan 2016 00:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSDrlC-UfIBf for ; Mon, 25 Jan 2016 00:01:23 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094171AD378 for ; Mon, 25 Jan 2016 00:01:22 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-ba-56a5d651b493 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 89.0E.02707.156D5A65; Mon, 25 Jan 2016 09:01:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Mon, 25 Jan 2016 09:01:20 +0100 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoIAAIcaAgAEX24CAAX87kP//8nEAgAASKmD///GtAAACLltg Date: Mon, 25 Jan 2016 08:01:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D594AC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D59386@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D59446@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D594ACESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7om7gtaVhBg/eCVlMXf6YxWLFhgOs FjMuTGW22Dm3g9mBxePv+w9MHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBmzX8xi LLhQXHHu1EPWBsYDBV2MHBwSAiYSt5+odzFyApliEhfurWfrYuTiEBI4zCgx/cVnZghnCaPE y2XH2EAa2AQsJLr/aYM0iAhoSaxePJcJxGYWKJJoWrCZBcQWFrCTaD69nhmixl7i1NoPjCBz RASaGCWe/94JVsQioCrxfctpsCJeAV+JyysmsEAsm8Qu8fPkArCpnAKBEocfLWIHsRmBzvt+ ag3UNnGJW0/mM0GcLSCxZM95ZghbVOLl43+sELaixMdX+xgh6vMlZuzbwwixTFDi5MwnLBMY RWchGTULSdksJGWzgH5mFtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtTi5Ny042M 9FKLMpOLi/Pz9PJSSzYxAqPy4JbfBjsYXz53PMQowMGoxMNbEL40TIg1say4MvcQowQHs5II 7+L9QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8B/kXhQkJpCeWpGanphakFsFkmTg4pRoYO1bM XizUv0033jpfWYrr4DtZvoCGsPDvXyxYTojluU3OdOlplNkV2shcLBnnWvIot7vqwsnFdiL5 oa9PSYqkv7rjPV1vfkvHiqV//seU3Wm9bcXCtMiBdRt/3r0JPGtrvx6XyTZju1u2Rd7mVlr6 nyPX/zXd/cV6UlHNJmPNVa2JRgv+K11TYinOSDTUYi4qTgQAIy6PYsYCAAA= Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:01:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D594ACESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIHlvdSBoYXZlIGNvbmNlcm5zIHdpdGggdGhlIHRleHQsIHBsZWFzZSB0YWtlIGl0 IHRvIHRoZSBJQ0UgbGlzdCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBTdWhh cyBOYW5kYWt1bWFyIFttYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbV0NClNlbnQ6IDI1LiB0YW1t aWt1dXRhIDIwMTYgOTo1OA0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogUm9tYW4gU2hwb3Vu dDsgbW11c2ljQGlldGYub3JnOyBQYXVsIEt5eml2YXQNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBO b3QgZml4aW5nIGE9cnRjcCBhbmQgcnRjcC1tdXggZXhjbHVzaXZlDQoNCg0KDQpPbiBTdW4sIEph biAyNCwgMjAxNiBhdCAxMTo1MSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4g d3JvdGU6DQpIaSwNCg0KPj5XaGVuIElDRSBpcyBpbiB1c2FnZSBhbmQgdGhlIE9mZmVyIHdhbnQg dG8gc3VwcG9ydCBhPXJ0Y3AtbXV4LW9ubHksIGl0IGRvZXMgdGhlIGZvbGxvd2luZw0KPj5hKSBp bmNsdWRlIGE9cnRjcC1tdXgtb25seQ0KPj5iKSBpbmNsdWRlIGE9cnRjcCA8cnRwLXBvcnQ+IDwt LSBSVFAgcG9ydA0KPj5jKSBpbmNsdWRlIFJUQ1AgY2FuZGlkYXRlIHdpdGggcG9ydCBpbmZvcm1h dGlvbiB0aGF0IG1hdGNoZXMgUlRQLiBObyBuZWVkIHRvIGRvIG5ldyB0dXJuIGFsbG9jYXRpb24g Zm9yIFJUQ1AgZWl0aGVyLg0KPg0KPk5vdGUgdGhhdCBzdWdnZXN0ZWQgSUNFIHRleHQgc2F5cyB0 aGF0IGlmIGFuIGVudGl0eSBvbmx5IHN1cHBvcnRzIG11eCB0aGVyZSBpcyBubyBuZWVkIHRvIGlu Y2x1ZGUgUlRDUCBjYW5kaWRhdGVzLiBJbnN0ZWFkIHRoZSBlbnRpdHkgd2lsbCBvbmx5IGluY2x1 ZGUgUlRQIGNhbmRpZGF0ZXMgKHRoZXJlIGFyZSBvdGhlciBtZWNoYW5pc21zIHRvIGluZGljYXRl IHdoZXRoZXIgdGhlIGVudGl0eSBkb2Vzbid0IHN1cHBvcnQvd2FudCB0byB1c2UgUlRDUCB0byBi ZWdpbiB3aXRoKS4NCj4NCj5bU3VoYXNdIEFzIGFuIG9mZmVyZXIgeW91IGhhdmUgbm8gaWRlYSBp ZiB0aGUgQW5zd2VyZXIgc3VwcG9ydHMgUlRDUCBNdXguIFNvIGl0IG5lZWRzIHRvIGluY2x1ZGUg UlRDUCBjYW5kaWRhdGVzLg0KPlRoaXMgaXMgd2hhdCBSRkM1MjQ1YmlzIHNheXMNCj4NCj4iSW4g dGhlIGNhc2Ugb2YgUlRQLCB0aGlzIHdvdWxkIGhhcHBlbiB3aGVuIG9uZSBhZ2VudCBwcm92aWRl cyBjYW5kaWRhdGVzIGZvciBSVENQLCBhbmQgdGhlIG90aGVyIGRvZXMgbm90LiBBcyBhbm90aGVy IGV4YW1wbGUsIHRoZSBpbml0aWF0aW5nIGFnZW50IGNhbg0KPiBtdWx0aXBsZXggUlRQIGFuZCBS VENQIG9uIHRoZSBzYW1lIHBvcnQgW1JGQzU3NjFdLiBIb3dldmVyLCBzaW5jZSB0aGUgaW5pdGlh dGluZyBhZ2VudCBkb2Vzbid0IGtub3cgaWYgdGhlIHBlZXIgYWdlbnQgY2FuIHBlcmZvcm0gc3Vj aCBtdWx0aXBsZXhpbmcsIGl0IGluY2x1ZGVzDQo+IGNhbmRpZGF0ZXMgZm9yIFJUUCBhbmQgUlRD UCBvbiBzZXBhcmF0ZSBwb3J0cy4gSWYgdGhlIHBlZXIgYWdlbnQgY2FuIHBlcmZvcm0gc3VjaCAg bXVsdGlwbGV4aW5nLCBpdCB3b3VsZCBpbmNsdWRlIGp1c3QgYSBzaW5nbGUgY29tcG9uZW50IGZv ciBlYWNoIGNhbmRpZGF0ZSAtLSBmb3INCj50aGUgY29tYmluZWQgUlRQL1JUQ1AgbXV4LiBJQ0Ug d291bGQgZW5kIHVwIGFjdGluZyBhcyBpZiB0aGVyZSB3YXMganVzdCBhIHNpbmdsZSBjb21wb25l bnQgZm9yIHRoaXMgY2FuZGlkYXRlLiINCg0KVGhlIGZvbGxvd2luZyBuZXh0IHRleHQgaGFzIGJl ZW4gZGlzY3Vzc2VkIG9uIHRoZSBJQ0UgbGlzdDoNCg0KIiAgICAgV2hlbiBjYW5kaWRhdGVzIGFy ZSBvYnRhaW5lZCwgdW5sZXNzIHRoZSBhZ2VudCBrbm93cyBmb3Igc3VyZSB0aGF0DQogICAgICAg UlRQL1JUQ1AgbXVsdGlwbGV4aW5nIHdpbGwgYmUgdXNlZCAoaS5lLiB0aGUgYWdlbnQga25vd3Mg dGhhdCB0aGUNCiAgICAgICBvdGhlciBhZ2VudCBhbHNvIHN1cHBvcnRzLCBhbmQgaXMgd2lsbGlu ZyB0byB1c2UsIFJUUC9SVENQDQogICAgICAgbXVsdGlwbGV4aW5nKSwgb3IgdW5sZXNzIHRoZSBh Z2VudCBvbmx5IHN1cHBvcnRzIFJUUC9SVENQDQogICAgICAgbXVsdGlwbGV4aW5nLCB0aGUgYWdl bnQgTVVTVCBvYnRhaW4gYSBzZXBhcmF0ZSBjYW5kaWRhdGUgZm9yIFJUQ1AuDQogICAgICAgSWYg YW4gYWdlbnQgaGFzIG9idGFpbmVkIGEgY2FuZGlkYXRlIGZvciBSVENQLCBhbmQgZW5kcyB1cCB1 c2luZyBSVFAvDQogICAgICAgUlRDUCBtdWx0aXBsZXhpbmcsIHRoZSBhZ2VudCBkb2VzIG5vdCBu ZWVkIHRvIHBlcmZvcm0gY29ubmVjdGl2aXR5DQogICAgICAgY2hlY2tzIG9uIHRoZSBSVENQIGNh bmRpZGF0ZS4iDQoNCltTdWhhc10NCkkgc2VlIC4uIGhvd2V2ZXIgSSBhbSBub3Qgc3VyZSBhYm91 dCB0aGUgYmVsb3cgc3RhdGVtZW50DQoNCiIgaS5lLiB0aGUgYWdlbnQga25vd3MgdGhhdCB0aGUg b3RoZXIgYWdlbnQgYWxzbyBzdXBwb3J0cywgYW5kIGlzIHdpbGxpbmcgdG8gdXNlLCBSVFAvUlRD UCBtdWx0aXBsZXhpbmciDQoNCndoYXQgbWVjaGFuaXNtIGlzIGF2YWlsYWJsZSB0byBlbnN1cmUg dGhlIHBlZXIgc3VwcG9ydHMgYW5kIGlzIHdpbGxpbmcgdG8gdXNlICBSVENQIG11bHRpcGxleGlu Zy4gQXQgYW55IHBvaW50IGFzIGEgcGVlciwgSSBjYW4gc3VwcG9ydCBSVENQIE11eCBidXQgbWln aHQgZGVjaWRlIG5vdCB0byB1c2UgZm9yIGEgZ2l2ZW4gc2Vzc2lvbi4gVGhlc2Ugd2VyZSB0aGUg ZmV3IHJlYXNvbnMgdGhhdCBpIHRob3VnaHQgbW90aXZhdGVkIGZvciBzdXBwb3J0aW5nIG11eC1l eGNsdXNpdmUgaW4gdGhlIGZpcnN0IHBsYWNlDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B37D594ACESESSMB209erics_ 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 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SWYgeW91IGhhdmUgY29uY2VybnMgd2l0aCB0aGUgdGV4dCwgcGxlYXNl IHRha2UgaXQgdG8gdGhlIElDRSBsaXN0IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlz dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdWhhcyBOYW5kYWt1bWFyIFttYWlsdG86c3Vo YXNpZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNS4gdGFtbWlrdXV0YSAyMDE2 IDk6NTg8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBS b21hbiBTaHBvdW50OyBtbXVzaWNAaWV0Zi5vcmc7IFBhdWwgS3l6aXZhdDxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW01NVVNJQ10gTm90IGZpeGluZyBhPXJ0Y3AgYW5kIHJ0Y3AtbXV4IGV4Y2x1 c2l2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgSmFuIDI0LCAyMDE2IGF0IDEx OjUxIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQomZ3Q7Jmd0 O1doZW4gSUNFIGlzIGluIHVzYWdlIGFuZCB0aGUgT2ZmZXIgd2FudCB0byBzdXBwb3J0IGE9cnRj cC1tdXgtb25seSwgaXQgZG9lcyB0aGUgZm9sbG93aW5nPGJyPg0KJmd0OyZndDthKSBpbmNsdWRl IGE9cnRjcC1tdXgtb25seTxicj4NCiZndDsmZ3Q7YikgaW5jbHVkZSBhPXJ0Y3AgJmx0O3J0cC1w b3J0Jmd0OyAmbHQ7LS0gUlRQIHBvcnQ8YnI+DQomZ3Q7Jmd0O2MpIGluY2x1ZGUgUlRDUCBjYW5k aWRhdGUgd2l0aCBwb3J0IGluZm9ybWF0aW9uIHRoYXQgbWF0Y2hlcyBSVFAuIE5vIG5lZWQgdG8g ZG8gbmV3IHR1cm4gYWxsb2NhdGlvbiBmb3IgUlRDUCBlaXRoZXIuPGJyPg0KJmd0Ozxicj4NCiZn dDtOb3RlIHRoYXQgc3VnZ2VzdGVkIElDRSB0ZXh0IHNheXMgdGhhdCBpZiBhbiBlbnRpdHkgb25s eSBzdXBwb3J0cyBtdXggdGhlcmUgaXMgbm8gbmVlZCB0byBpbmNsdWRlIFJUQ1AgY2FuZGlkYXRl cy4gSW5zdGVhZCB0aGUgZW50aXR5IHdpbGwgb25seSBpbmNsdWRlIFJUUCBjYW5kaWRhdGVzICh0 aGVyZSBhcmUgb3RoZXIgbWVjaGFuaXNtcyB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBlbnRpdHkg ZG9lc24ndCBzdXBwb3J0L3dhbnQgdG8gdXNlIFJUQ1ANCiB0byBiZWdpbiB3aXRoKS48YnI+DQom Z3Q7PGJyPg0KJmd0O1tTdWhhc10gQXMgYW4gb2ZmZXJlciB5b3UgaGF2ZSBubyBpZGVhIGlmIHRo ZSBBbnN3ZXJlciBzdXBwb3J0cyBSVENQIE11eC4gU28gaXQgbmVlZHMgdG8gaW5jbHVkZSBSVENQ IGNhbmRpZGF0ZXMuPGJyPg0KJmd0O1RoaXMgaXMgd2hhdCBSRkM1MjQ1YmlzIHNheXM8YnI+DQom Z3Q7PGJyPg0KJmd0OyZxdW90O0luIHRoZSBjYXNlIG9mIFJUUCwgdGhpcyB3b3VsZCBoYXBwZW4g d2hlbiBvbmUgYWdlbnQgcHJvdmlkZXMmbmJzcDtjYW5kaWRhdGVzIGZvciBSVENQLCBhbmQgdGhl IG90aGVyIGRvZXMgbm90LiBBcyBhbm90aGVyIGV4YW1wbGUsIHRoZSZuYnNwO2luaXRpYXRpbmcg YWdlbnQgY2FuPGJyPg0KJmd0OyBtdWx0aXBsZXggUlRQIGFuZCBSVENQIG9uIHRoZSBzYW1lIHBv cnQmbmJzcDtbUkZDNTc2MV0uIEhvd2V2ZXIsIHNpbmNlIHRoZSBpbml0aWF0aW5nIGFnZW50IGRv ZXNuJ3Qga25vdyBpZiB0aGUmbmJzcDtwZWVyIGFnZW50IGNhbiBwZXJmb3JtIHN1Y2ggbXVsdGlw bGV4aW5nLCBpdCBpbmNsdWRlczxicj4NCiZndDsgY2FuZGlkYXRlcyBmb3ImbmJzcDtSVFAgYW5k IFJUQ1Agb24gc2VwYXJhdGUgcG9ydHMuIElmIHRoZSBwZWVyIGFnZW50IGNhbiBwZXJmb3JtIHN1 Y2gmbmJzcDsmbmJzcDttdWx0aXBsZXhpbmcsIGl0IHdvdWxkIGluY2x1ZGUganVzdCBhIHNpbmds ZSBjb21wb25lbnQgZm9yIGVhY2gmbmJzcDtjYW5kaWRhdGUgLS0gZm9yPGJyPg0KJmd0O3RoZSBj b21iaW5lZCBSVFAvUlRDUCBtdXguIElDRSB3b3VsZCBlbmQgdXAgYWN0aW5nJm5ic3A7YXMgaWYg dGhlcmUgd2FzIGp1c3QgYSBzaW5nbGUgY29tcG9uZW50IGZvciB0aGlzIGNhbmRpZGF0ZS4mcXVv dDs8YnI+DQo8YnI+DQpUaGUgZm9sbG93aW5nIG5leHQgdGV4dCBoYXMgYmVlbiBkaXNjdXNzZWQg b24gdGhlIElDRSBsaXN0Ojxicj4NCjxicj4NCiZxdW90OyZuYnNwOyAmbmJzcDsgJm5ic3A7V2hl biBjYW5kaWRhdGVzIGFyZSBvYnRhaW5lZCwgdW5sZXNzIHRoZSBhZ2VudCBrbm93cyBmb3Igc3Vy ZSB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UlRQL1JUQ1AgbXVsdGlwbGV4 aW5nIHdpbGwgYmUgdXNlZCAoaS5lLiB0aGUgYWdlbnQga25vd3MgdGhhdCB0aGU8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvdGhlciBhZ2VudCBhbHNvIHN1cHBvcnRzLCBhbmQgaXMg d2lsbGluZyB0byB1c2UsIFJUUC9SVENQPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 bXVsdGlwbGV4aW5nKSwgb3IgdW5sZXNzIHRoZSBhZ2VudCBvbmx5IHN1cHBvcnRzIFJUUC9SVENQ PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bXVsdGlwbGV4aW5nLCB0aGUgYWdlbnQg TVVTVCBvYnRhaW4gYSBzZXBhcmF0ZSBjYW5kaWRhdGUgZm9yIFJUQ1AuPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7SWYgYW4gYWdlbnQgaGFzIG9idGFpbmVkIGEgY2FuZGlkYXRlIGZv ciBSVENQLCBhbmQgZW5kcyB1cCB1c2luZyBSVFAvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7UlRDUCBtdWx0aXBsZXhpbmcsIHRoZSBhZ2VudCBkb2VzIG5vdCBuZWVkIHRvIHBlcmZv cm0gY29ubmVjdGl2aXR5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hlY2tzIG9u IHRoZSBSVENQIGNhbmRpZGF0ZS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPltTdWhhc10mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIC4uIGhvd2V2ZXIgSSBhbSBub3Qgc3VyZSBh Ym91dCB0aGUgYmVsb3cgc3RhdGVtZW50Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OyZuYnNwOzxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQiPmkuZS4gdGhlIGFnZW50IGtub3dzIHRoYXQgdGhlJm5ic3A7b3RoZXIgYWdl bnQgYWxzbyBzdXBwb3J0cywgYW5kIGlzIHdpbGxpbmcgdG8gdXNlLCBSVFAvUlRDUCZuYnNwO211 bHRpcGxleGluZyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hhdCBtZWNoYW5pc20gaXMgYXZhaWxhYmxlIHRvIGVuc3Vy ZSB0aGUgPGI+cGVlciBzdXBwb3J0cyBhbmQgaXMgd2lsbGluZyB0byB1c2UgJm5ic3A7PC9iPlJU Q1AgbXVsdGlwbGV4aW5nLiBBdCBhbnkgcG9pbnQgYXMgYSBwZWVyLCBJIGNhbiBzdXBwb3J0IFJU Q1AgTXV4IGJ1dCBtaWdodCBkZWNpZGUgbm90IHRvIHVzZSBmb3IgYSBnaXZlbiBzZXNzaW9uLiBU aGVzZSB3ZXJlIHRoZSBmZXcgcmVhc29ucyB0aGF0IGkgdGhvdWdodA0KIG1vdGl2YXRlZCBmb3Ig c3VwcG9ydGluZyBtdXgtZXhjbHVzaXZlIGluIHRoZSBmaXJzdCBwbGFjZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+UmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3RlcjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37D594ACESESSMB209erics_-- From nobody Mon Jan 25 00:14:04 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D071B29B3 for ; Mon, 25 Jan 2016 00:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j_dYhAR2_KT for ; Mon, 25 Jan 2016 00:14:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC4B1B29B2 for ; Mon, 25 Jan 2016 00:14:01 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-26-56a5d946318e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.73.05690.649D5A65; Mon, 25 Jan 2016 09:13:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 25 Jan 2016 09:13:57 +0100 From: Christer Holmberg To: Paul Kyzivat , Suhas Nandakumar Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoIAAIcaAgAEX24CAAJvKgIAACmeAgAAMtICAAM4ZgA== Date: Mon, 25 Jan 2016 08:13:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> In-Reply-To: <56A53249.5020709@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7h67bzaVhBu/OmlpMXf6YxWLFhgOs FjMuTGW22Dm3g9mBxePv+w9MHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBn962ez FMyzqNj0uKCB8YlZFyMnh4SAicSTyz+YIGwxiQv31rN1MXJxCAkcZpTYu+oslLOEUWLikV8s XYwcHGwCFhLd/7RBGkQEgiTOrrrKBmIzC3hJNMzeDmYLC9hJNJ9ezwxRYy9xau0HRgi7TuLg 99lgNSwCqhLb+laxg9i8Ar4SB7csY4LY1c4mcbuvB+wiTgEdielTr7CC2IxA130/tYYJYpm4 xK0n86GuFpBYsuc8M4QtKvHy8T9WCFtR4uOrfYwgNzMLaEqs36UP0aooMaX7IdReQYmTM5+w TGAUm4Vk6iyEjllIOmYh6VjAyLKKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzDCDm75rbuD cfVrx0OMAhyMSjy8BeFLw4RYE8uKK3MPMUpwMCuJ8C7eDxTiTUmsrEotyo8vKs1JLT7EKM3B oiTOe5B/UZiQQHpiSWp2ampBahFMlomDU6qBUc5fUezGRXfRvfevT2/i3No/RWBn5+4D1usn VU7JvCxrsv7Kzm+ZCUyT9bak/xcodf8boxPEp7jGxVFMPeJX2Cb/HWulS63Yu2Wn/Px0flte 6Rm5tsNTPznt77GYu/7Zch3htE3bFJY/2BsoP8OR6Xl8sOr+Uz9MVNxLXN14Pxdm3fHLCfZR U2Ipzkg01GIuKk4EAAqfhKGsAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:14:03 -0000 SGksDQoNCkkgZG9uJ3Qga25vdyB3aGV0aGVyIGl0IHdvdWxkIGJlIHdvcnRoIHRoZSBlZmZvcnQg dG8gInJlcGxhY2UiIGE9cnRjcCwgYW5kIHdoZXRoZXIgaXQgd291bGQgcmVhbGx5IGNoYW5nZSBh bnl0aGluZy4NCg0KSSBzdGlsbCBjbGFpbSB0aGF0IHdlIHNob3VsZCBhc3N1bWUgdGhhdCBkZXBs b3ltZW50cyBETyBzdXBwb3J0IGE9cnRjcC4gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86 cGt5eml2YXRAYWx1bS5taXQuZWR1XSANClNlbnQ6IDI0LiB0YW1taWt1dXRhIDIwMTYgMjI6MjEN ClRvOiBTdWhhcyBOYW5kYWt1bWFyDQpDYzogUm9tYW4gU2hwb3VudDsgQ2hyaXN0ZXIgSG9sbWJl cmc7IG1tdXNpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIE5vdCBmaXhpbmcgYT1y dGNwIGFuZCBydGNwLW11eCBleGNsdXNpdmUNCg0KT24gMS8yNC8xNiAyOjM2IFBNLCBTdWhhcyBO YW5kYWt1bWFyIHdyb3RlOg0KPg0KPg0KPiBPbiBTdW4sIEphbiAyNCwgMjAxNiBhdCAxMDo1OCBB TSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHUgDQo+IDxtYWlsdG86cGt5eml2 YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQo+DQo+ICAgICBPbiAxLzI0LzE2IDQ6NDEgQU0sIFN1 aGFzIE5hbmRha3VtYXIgd3JvdGU6DQo+DQo+ICAgICAgICAgSSBtaWdodCBiZSByZXBlYXRpbmcg c29tZSBkaXNjdXNzaW9ucyBhbHJlYWR5IG1hZGUuIFNvIHBsZWFzZQ0KPiAgICAgICAgIGZvcmdp dmUgbWUNCj4gICAgICAgICBpZiBhbGwgb2YgdGhlIGJlbG93IHN1Z2dlc3Rpb25zIGlzIGJlYXRl biB0byBkZWF0aA0KPg0KPiAgICAgICAgICpVc2UtY2FzZTogRXhwbGljaXRseSBpbmRpY2F0ZSBS VENQIE11eGluZyBhbmQgcG9zc2libHkgYmFja3dhcmQNCj4gICAgICAgICBjb21wYXRpYmlsaXR5 Kg0KPg0KPiAgICAgICAgIEkgc3VwcG9ydCBhIG5ldyBhdHRyaWJ1dGUgYWxvbmcgd2l0aCBzb21l IHJ1bGVzIGZvciBleGlzdGluZw0KPiAgICAgICAgIGF0dHJpYnV0ZXMNCj4gICAgICAgICB3aGlj aCBhbGxvd3MgYmFja3dhcmQgY29tcGF0aWJpbGl0eSAoU3Ryb25nIGdvYWwgb2YgU0RQKSBhbmQg YWxzbw0KPiAgICAgICAgIGV4Y2x1c2l2ZW5lc3Mgb2YgUlRDUCBtdWx0aXBsZXhpbmcNCj4NCj4g ICAgICAgICBEZWZpbmUgYSBuZXcgYXR0cmlidXRlICoiYT1ydGNwLW11eC1vbmx5IiAsIHdoaWNo ICppbiBhIG9mZmVyDQo+ICAgICAgICAgaW5kaWNhdGVzDQo+ICAgICAgICAgdGhhdCB0aGUgZW5k LXBvaW50IGNhbid0IHJlY2VpdmUgcnRjcCBvbiBzZXBhcmF0ZSBwb3J0IHRoYW4gcnRwLg0KPg0K Pg0KPiAgICAgSXQgaXMgKmVzc2VudGlhbCogdG8gaW5kaWNhdGUgdGhlIGFuc3dlcmVyIGJlaGF2 aW9yIHRvby4gRm9yIHRoaXMgdG8NCj4gICAgIHByb3ZpZGUgYmFja3dhcmQgc3VwcG9ydCwgdGhl IGFuc3dlcmVyIHdobyBzdXBwb3J0cyBtdXN0IGFsc28NCj4gICAgIGluY2x1ZGUgdGhpcyBhdHRy aWJ1dGUgaW4gdGhlIGFuc3dlci4gSWYgaXQgaXNuJ3QgcHJlc2VudCBpbiB0aGUNCj4gICAgIGFu c3dlciwgdGhlbiB0aGUgb2ZmZXJlciBrbm93cyB0aGF0IGl0IGhhc24ndCBiZWVuIHN1cHBvcnRl ZC4gSQ0KPiAgICAgdGhpbmssIGluIHRoYXQgY2FzZSBpdCBtdXN0IHJlb2ZmZXIgYW5kIGVpdGhl ciBwcm92aWRlIGEgcG9ydCBwYWlyLA0KPiAgICAgb3IgZWxzZSBkcm9wIHRoZSBtZWRpYSBzdHJl YW0sIHRvIHByZXZlbnQgUlRDUCBmcm9tIGdvaW5nIHRvIGFuDQo+ICAgICB1bmNvbnRyb2xsZWQg cG9ydC4NCj4NCj4NCj4gW1N1aGFzXSAtIEFncmVlZCBQYXVsLiBJIHNlZSBiYWNrd2FyZCBjb21w YXRpYmlsaXR5IGluIDIgd2F5cy4gT25lIA0KPiB3aGVyZSB0aGUgYWdlbnQgdW5kZXJzdGFuZHMg YT1ydGNwLW11eCBidXQgbm90IHRoZSBhPXJ0Y3AtbXV4LW9ubHkgYW5kIA0KPiBzZWNvbmQgd2hl cmUgdGhlIGFnZW50IGRvZXNuJ3QgdW5kZXJzdGFuZCBlaXRoZXIuIExldCdzIHRoaW5rIHRoZSAN Cj4gYW5zd2VyZXIgYmVoYXZpb3IgaW4gYm90aCB0aGUgY2FzZXMNCj4NCj4gQ2FzZSAxOiBBZ2Vu dCBzdXBwb3J0cyBSRkM1NzYxIGJ1dCBub3QgbXV4LW9ubHkNCj4gICAgIEluIHRoaXMgc2NlbmFy aW8gd2UgbWFuZGF0ZSB0aGF0IHRoZSBvZmZlciBpbmNsdWRlcyBSRkM1NzYxIA0KPiBhPXJ0Y3At bXV4IGFzIHdlbGwgd2hlbmV2ZXIgaGUgb2ZmZXJzIHdpdGggbXV4LW9ubHkuIFRodXMgdGhlIGFu c3dlcmVyIA0KPiB3aWxsIHN0aWxsIE1VWCB0aGUgUlRDUCB0byBSVFAgcG9ydCBmb2xsb3dpbmcg UkZDNTc2MSBydWxlcy4NCj4NCj4gQ2FzZSAyOiBBZ2VudCBkb2Vzbid0IHN1cHBvcnQgUkZDNTc2 MSBhbmQgbXV4LW9ubHkgYXMgd2VsbCBUaGlzIGlzICANCj4gdGhlIGNhc2Ugd2hlcmUgdGhlIGFu c3dlcmVyIGNhbiBwcm9jZXNzIGp1c3QgdGhlIFJGQzM2MDUgYT1ydGNwIA0KPiBhdHRyaWJ1dGUg YW5kIGNhbiBlaXRoZXIgOg0KPiAgICAgICAgIDJhKSBzZW5kIHRoZSBydGNwIHRvIHRoZSBwb3J0 IGluZGljYXRlZCBpbiBhPXJ0Y3AgYXR0cmlidXRlICwgDQo+IHRodXMgZWZmZWN0aXZlbHkgbXV4 aW5nDQo+ICAgICAgICAgMmIpIHdpbGwgdGhpbmsgcnRjcCBwb3J0IHNwZWNpZmllZCBhcyBiZWlu ZyBlcnJvciBzaW5jZSBpdCANCj4gbWF0Y2hlcyB0aGUgUlRQIHBvcnQgYW5kIHJlamVjdCB0aGUg bT1saW5lLiBbWyBub3RlOiB0aGlzIGlzbid0IA0KPiBkZWZpbmVkIGFzIGFuIGVycm9yIGluIFJG QzM2MDUgXV0NCj4NCj4gQ2FzZSAzOiBBbnN3ZXJlciBzdXBwb3J0cyBSRkM1NzYxLCBNdXgtZXhj bHVzaXZlDQo+ICAgICBJbiB0aGlzIHN1Y2Nlc3NmdWwgc2NlbmFyaW8sIHRoZSBhbnN3ZXJlciBj YW4ganVzdCBpbmNsdWRlIA0KPiBhPXJ0Y3AtbXV4IGFuZCBhPXJ0Y3AtbXV4LWV4Y2x1c2l2ZSBp biBpdHMgYW5zd2VyIGFuZCB0aGF0IGlzIGdvb2QgDQo+IGVub3VnaCBmb3IgdGhlIE9mZmVyZXIg dG8ga25vdyB0aGF0IEFuc3dlcmVyIGlzIGFibGUgdG8gbXV4IHRoZSBydGNwIA0KPiB0cmFmZmlj IHRvd2FyZHMgdGhlIG9mZmVyZXIgYW5kIGFsc28gd2lzaGVzIHRvIHJlY2VpdmUgbXV4ZWQgKG5v DQo+IGZhbGxiYWNrKSBydGNwIHRyYWZmaWMgZnJvbSB0aGUgb2ZmZXJlcg0KPg0KPiBUaGVzZSBz ZWVtcyB0byBjb252ZXJ0IG1vc3Qgb2YgYWxsIHRoZSBjYXNlcyByaWdodA0KDQpBZ3JlZS4NCg0K PiAgICAgSSB0aGluayB0aGlzIG91Z2h0IHRvIGJlIHZpZXdlZCBhcyBhbiB1cGRhdGUgdG8gMzYw NS4NCg0KTWF5YmUgdGhhdCBpc24ndCBxdWl0ZSByaWdodCwgYnV0IGl0IG91Z2h0IHRvIGJlIGFu IHVwZGF0ZSB0byAqc29tZXRoaW5nKi4NCg0KSXQgaXMgbW9zdGx5IGE9cnRjcCB0aGF0IGlzIGJy b2tlbiwgYmVjYXVzZSBpdCBpc24ndCBhY2tub3dsZWRnZWQuIEFueSBwbGF1c2libGUgdXNlIG9m IGl0IGVuZHMgdXAgYmVpbmcgYnJva2VuIGlmIHRoZSBhbnN3ZXJlciBkb2Vzbid0IHN1cHBvcnQg aXQsIGJ1dCB0aGUgb2ZmZXJlciBoYXMgbm8gd2F5IG9mIHRlbGxpbmcgdGhhdC4NCg0KYT1ydGNw LW11eCBpcyBuZWdvdGlhdGVkLiBTbyB0aGUgb2ZmZXJlciBjYW4gdGVsbCB3aGVuIHRoZSBhbnN3 ZXJlciBkb2Vzbid0IHN1cHBvcnQgaXQuIEluIHRoYXQgY2FzZSBpdCBjYW4gdGFrZSByZW1lZGlh bCBhY3Rpb24uIFRoZXJlIG1heSBiZSBzb21lIHN0cmF5IHJ0Y3AgcGFja2V0cyB1bnRpbCB0aGF0 IGhhcHBlbnMuIFNvIGE9cnRjcC1tdXgtb25seSBpc24ndCByZWFsbHkgKm5lZWRlZCouIFdoYXQg aXQgZG9lcyBpcyBwcmV2ZW50IHRob3NlIGZldyBzdHJheSBwYWNrZXRzLg0KDQpCdXQgYT1ydGNw LW11eC1vbmx5IGlzbid0IHRoZSBiZXN0IGFuc3dlciBmb3IgZml4aW5nIGE9cnRjcCwgYmVjYXVz ZSBpdCBkb2Vzbid0IHNvbHZlIGNhc2VzIHdoZW4gdGhlIG9mZmVyZXIgd2FudHMgc2VwYXJhdGUg cnRjcCwgYnV0IG5vdCBvbiANCnBvcnQrMSwgYW5kIHRoZSBhbnN3ZXJlciBkb2Vzbid0IHN1cHBv cnQgdGhhdC4NCg0KUGVyaGFwcyB0aGUgcmlnaHQgc29sdXRpb24gaXMgdG8gaW50cm9kdWNlIGEg bmV3IGF0dHJpYnV0ZSB0byAqcmVwbGFjZSogDQphPXJ0Y3AuIEl0IHdvdWxkIGhhdmUgc2ltaWxh ciBzZW1hbnRpY3MsIGJ1dCByZXF1aXJlIG5lZ290aWF0aW9uLiBJdCANCmNvdWxkIGluIHByaW5j aXBsZSBhbHNvIHJlcGxhY2UgYT1ydGNwLW11eCwgc2luY2UgaWYgeW91IHVzZSB0aGUgc2FtZSAN CmFkZHJlc3MvcG9ydCBmb3IgYm90aCBydHAgYW5kIHJ0Y3AgeW91IGFyZSBvYnZpb3VzbHkgcmVx dWVzdGluZyBtdXguIFlvdSANCmNvdWxkIHN0aWxsIHVzZSBhPXJ0Y3AgYW5kL29yIGE9cnRjcC1t dXggZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGJ1dCANCmlmIHlvdSBuZWVkIHJ0Y3AtbXV4 LW9ubHkgc2VtYW50aWNzLCB0aGVuIHlvdSBjb3VsZCBqdXN0IHVzZSB0aGlzIG5ldyANCmF0dHJp YnV0ZS4gSWYgaXQgaXNuJ3QgYWNrJ2VkLCB0aGVuIHRha2UgcmVtZWRpYWwgYWN0aW9uLg0KDQpU aGlzIG5ldyBhdHRyaWJ1dGUgd291bGQgaGF2ZSBzYW1lIHN5bnRheCBhcyBhPXJ0Y3AsIGV4Y2Vw dCBmb3IgdGhlIA0KbmFtZS4gTmV3IHJ1bGVzIGZvciBpdCB3b3VsZCBiZToNCg0KLSBpZiBpbiBv ZmZlciwgbXVzdCBhbHNvIGJlIGluIGFuc3dlci4gVGhlIGFuc3dlciBnaXZlcyB0aGUgcG9ydCgv YWRkcikNCiAgIGZvciB0aGUgYW5zd2VyZXIuIElmIHRoZSBhbnN3ZXJlciB3YW50cyBwb3J0KzEg aXQgbmVlZHMgdG8gY29tcHV0ZQ0KICAgd2hhdCB0aGF0IGlzIGFuZCBwdXQgaXQgaW4uDQotIGlm IGl0IGlzICpub3QqIGluIHRoZSBvZmZlciwgaXQgY2FuJ3QgYmUgdXNlZCBpbiB0aGUgYW5zd2Vy LiBJZiB0aGUNCiAgIGFuc3dlcmVyIGNhbid0IGRvIHJ0Y3Agb24gcG9ydCsxIHRoZW4gaXQgbmVl ZHMgdG8gcmVmdXNlIHRoZSBtZWRpYQ0KICAgc3RyZWFtLiBJdCBjb3VsZCB0cnkgc2VuZGluZyBh IHN1YnNlcXVlbnQgb2ZmZXIgZm9yIHdoYXQgaXQgY2FuIGRvLg0KDQotIHdlICpjb3VsZCogZXhw bGljaXRseSBhbGxvdyB0aGUgcG9ydCB0byBiZSBzZXQgdG8gemVybywgYW5kL29yIHRoZQ0KICAg YWRkcmVzcyB0byBiZSBzZXQgdG8gMC4wLjAuMCwgdG8gaW5kaWNhdGUgdGhhdCBydGNwIGlzIG5v dCBkZXNpcmVkLg0KICAgKERvbid0IGtub3cgaWYgaXQgaXMgYSBnb29kIGlkZWEuKQ0KDQoJVGhh bmtzLA0KCVBhdWwNCg== From nobody Mon Jan 25 08:36:19 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5541B2D0A for ; Mon, 25 Jan 2016 08:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQjV14Y9nXWp for ; Mon, 25 Jan 2016 08:36:16 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070831B2C8A for ; Mon, 25 Jan 2016 08:36:15 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-01v.sys.comcast.net with comcast id AGbs1s00827uzMh01GcFdh; Mon, 25 Jan 2016 16:36:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with comcast id AGcD1s00Y3KdFy101GcEnE; Mon, 25 Jan 2016 16:36:15 +0000 To: Christer Holmberg , Suhas Nandakumar References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56A64EFD.4000509@alum.mit.edu> Date: Mon, 25 Jan 2016 11:36:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453739775; bh=7qTL+j2fgUibiVX0TBaFqVfz77FmQizEn9oX9laneQ4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=t/0DyyrexxDXX10cl5ulBMn1oPppOW7Y5/J1piYQXxxsJTK9IWOp8MvfVLX1YNEXd b2jSWTVMc5Q1s1mVBa9/S8Kz54cH+FNP6Hv/owN3zy1Yg5PBbi7iZDr9lLqF+srZZe dzYjurhtvgaM/8nAvwh/GEFjt+r1xBMV1COEmpXwKXfkeVSQ50exvTj1rynLOgt04m ucgpjmNOXPQqCHNweXQ8c+F7GR1oq5e+Ik7nNG13pT5y0JK45UFtoY97MOcTVehlzh q9vN7fiAOKQc9CPVcazf160V6NwoBbCMg1Vl+ozIf/ZVV3w6Qf5gBZggIl9wEu4lAC 447cxv/Edy64A== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 16:36:17 -0000 On 1/25/16 3:13 AM, Christer Holmberg wrote: > Hi, > > I don't know whether it would be worth the effort to "replace" a=rtcp, and whether it would really change anything. > > I still claim that we should assume that deployments DO support a=rtcp. My point is that *if* we need to introduce *something* new (e.g. rtcp-mux-only), then a replacement for rtcp would be a better solution, because it would fix more problems, and be no more trouble to implement. Thanks, Paul > Regards, > > Christer > > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 24. tammikuuta 2016 22:21 > To: Suhas Nandakumar > Cc: Roman Shpount; Christer Holmberg; mmusic@ietf.org > Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive > > On 1/24/16 2:36 PM, Suhas Nandakumar wrote: >> >> >> On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat > > wrote: >> >> On 1/24/16 4:41 AM, Suhas Nandakumar wrote: >> >> I might be repeating some discussions already made. So please >> forgive me >> if all of the below suggestions is beaten to death >> >> *Use-case: Explicitly indicate RTCP Muxing and possibly backward >> compatibility* >> >> I support a new attribute along with some rules for existing >> attributes >> which allows backward compatibility (Strong goal of SDP) and also >> exclusiveness of RTCP multiplexing >> >> Define a new attribute *"a=rtcp-mux-only" , which *in a offer >> indicates >> that the end-point can't receive rtcp on separate port than rtp. >> >> >> It is *essential* to indicate the answerer behavior too. For this to >> provide backward support, the answerer who supports must also >> include this attribute in the answer. If it isn't present in the >> answer, then the offerer knows that it hasn't been supported. I >> think, in that case it must reoffer and either provide a port pair, >> or else drop the media stream, to prevent RTCP from going to an >> uncontrolled port. >> >> >> [Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One >> where the agent understands a=rtcp-mux but not the a=rtcp-mux-only and >> second where the agent doesn't understand either. Let's think the >> answerer behavior in both the cases >> >> Case 1: Agent supports RFC5761 but not mux-only >> In this scenario we mandate that the offer includes RFC5761 >> a=rtcp-mux as well whenever he offers with mux-only. Thus the answerer >> will still MUX the RTCP to RTP port following RFC5761 rules. >> >> Case 2: Agent doesn't support RFC5761 and mux-only as well This is >> the case where the answerer can process just the RFC3605 a=rtcp >> attribute and can either : >> 2a) send the rtcp to the port indicated in a=rtcp attribute , >> thus effectively muxing >> 2b) will think rtcp port specified as being error since it >> matches the RTP port and reject the m=line. [[ note: this isn't >> defined as an error in RFC3605 ]] >> >> Case 3: Answerer supports RFC5761, Mux-exclusive >> In this successful scenario, the answerer can just include >> a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good >> enough for the Offerer to know that Answerer is able to mux the rtcp >> traffic towards the offerer and also wishes to receive muxed (no >> fallback) rtcp traffic from the offerer >> >> These seems to convert most of all the cases right > > Agree. > >> I think this ought to be viewed as an update to 3605. > > Maybe that isn't quite right, but it ought to be an update to *something*. > > It is mostly a=rtcp that is broken, because it isn't acknowledged. Any plausible use of it ends up being broken if the answerer doesn't support it, but the offerer has no way of telling that. > > a=rtcp-mux is negotiated. So the offerer can tell when the answerer doesn't support it. In that case it can take remedial action. There may be some stray rtcp packets until that happens. So a=rtcp-mux-only isn't really *needed*. What it does is prevent those few stray packets. > > But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because it doesn't solve cases when the offerer wants separate rtcp, but not on > port+1, and the answerer doesn't support that. > > Perhaps the right solution is to introduce a new attribute to *replace* > a=rtcp. It would have similar semantics, but require negotiation. It > could in principle also replace a=rtcp-mux, since if you use the same > address/port for both rtp and rtcp you are obviously requesting mux. You > could still use a=rtcp and/or a=rtcp-mux for backward compatibility, but > if you need rtcp-mux-only semantics, then you could just use this new > attribute. If it isn't ack'ed, then take remedial action. > > This new attribute would have same syntax as a=rtcp, except for the > name. New rules for it would be: > > - if in offer, must also be in answer. The answer gives the port(/addr) > for the answerer. If the answerer wants port+1 it needs to compute > what that is and put it in. > - if it is *not* in the offer, it can't be used in the answer. If the > answerer can't do rtcp on port+1 then it needs to refuse the media > stream. It could try sending a subsequent offer for what it can do. > > - we *could* explicitly allow the port to be set to zero, and/or the > address to be set to 0.0.0.0, to indicate that rtcp is not desired. > (Don't know if it is a good idea.) > > Thanks, > Paul > From nobody Mon Jan 25 08:38:51 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143B31B2D15 for ; Mon, 25 Jan 2016 08:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10lTsDomZssP for ; Mon, 25 Jan 2016 08:38:40 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990191B2D14 for ; Mon, 25 Jan 2016 08:38:40 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-01v.sys.comcast.net with comcast id AGdC1s00B52QWKC01GegD2; Mon, 25 Jan 2016 16:38:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-09v.sys.comcast.net with comcast id AGef1s0013KdFy101GefCf; Mon, 25 Jan 2016 16:38:39 +0000 To: Suhas Nandakumar References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> From: Paul Kyzivat Message-ID: <56A64F8A.5030708@alum.mit.edu> Date: Mon, 25 Jan 2016 11:38:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453739920; bh=M6vRnrMhdlYepDNQZVxJ0DZBAlIP5HKOXPrYCHRrcjE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GrcWSl5cu9+WmFAySHelO7JlE2ySLJNyiqCQpKl3Bt6N/HFrKuIxqZiBbkJeX3kyQ F9h2AzwVlwlp12tKW2xeZG1m3Y9trz7lr3Tm7SYhjO+MsG16nKEemVTRN0ouBcaalg CZJpZkyNapEJ88hP5SiwXObAO9FtXv4Yt7eojzD+y5i3aiUXXgFeb1Uy+wZ8t0sm1x p7fBQrlU0WC0g090oCdSbSjtS/euaOe7g3m6DywJjfW+7xI0zri5NgXACO+6vcVRiM EZER0FbMIWQQzyzVuFtd3SKpctggX1Zhwrs3xsX3dhBoGzwEQYNzRHKis5ctfDOfJN /uFicg7jX/jfw== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 16:38:42 -0000 On 1/24/16 4:58 PM, Suhas Nandakumar wrote: > > > On Sun, Jan 24, 2016 at 12:21 PM, Paul Kyzivat > wrote: > > On 1/24/16 2:36 PM, Suhas Nandakumar wrote: > > > > On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat > > >> > wrote: > > On 1/24/16 4:41 AM, Suhas Nandakumar wrote: > > I might be repeating some discussions already made. So > please > forgive me > if all of the below suggestions is beaten to death > > *Use-case: Explicitly indicate RTCP Muxing and possibly > backward > compatibility* > > I support a new attribute along with some rules for > existing > attributes > which allows backward compatibility (Strong goal of > SDP) and also > exclusiveness of RTCP multiplexing > > Define a new attribute *"a=rtcp-mux-only" , which *in a > offer > indicates > that the end-point can't receive rtcp on separate port > than rtp. > > > It is *essential* to indicate the answerer behavior too. > For this to > provide backward support, the answerer who supports must also > include this attribute in the answer. If it isn't present > in the > answer, then the offerer knows that it hasn't been supported. I > think, in that case it must reoffer and either provide a > port pair, > or else drop the media stream, to prevent RTCP from going to an > uncontrolled port. > > > [Suhas] - Agreed Paul. I see backward compatibility in 2 ways. > One where > the agent understands a=rtcp-mux but not the a=rtcp-mux-only and > second > where the agent doesn't understand either. Let's think the answerer > behavior in both the cases > > Case 1: Agent supports RFC5761 but not mux-only > In this scenario we mandate that the offer includes RFC5761 > a=rtcp-mux as well whenever he offers with mux-only. Thus the > answerer > will still MUX the RTCP to RTP port following RFC5761 rules. > > Case 2: Agent doesn't support RFC5761 and mux-only as well > This is the case where the answerer can process just the > RFC3605 a=rtcp > attribute and can either : > 2a) send the rtcp to the port indicated in a=rtcp > attribute , > thus effectively muxing > 2b) will think rtcp port specified as being error since it > matches the RTP port and reject the m=line. [[ note: this isn't > defined > as an error in RFC3605 ]] > > Case 3: Answerer supports RFC5761, Mux-exclusive > In this successful scenario, the answerer can just include > a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good > enough for the Offerer to know that Answerer is able to mux the rtcp > traffic towards the offerer and also wishes to receive muxed (no > fallback) rtcp traffic from the offerer > > These seems to convert most of all the cases right > > > Agree. > > I think this ought to be viewed as an update to 3605. > > > Maybe that isn't quite right, but it ought to be an update to > *something*. > > > [Suhas] .. If i am not wrong, the above proposal doesn't need updates to > RFC3605 and when used in combination with a=rtcp-mux-only the intent is > clear. My point is that introducing a new replacement for a=rtcp solves the problem that rtcp-mux-only solves, but also solves other problems. Thanks, Paul > It is mostly a=rtcp that is broken, because it isn't acknowledged. > Any plausible use of it ends up being broken if the answerer doesn't > support it, but the offerer has no way of telling that. > > a=rtcp-mux is negotiated. So the offerer can tell when the answerer > doesn't support it. In that case it can take remedial action. There > may be some stray rtcp packets until that happens. So > a=rtcp-mux-only isn't really *needed*. What it does is prevent those > few stray packets. > > But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because > it doesn't solve cases when the offerer wants separate rtcp, but not > on port+1, and the answerer doesn't support that. > > Perhaps the right solution is to introduce a new attribute to > *replace* a=rtcp. It would have similar semantics, but require > negotiation. It could in principle also replace a=rtcp-mux, since if > you use the same address/port for both rtp and rtcp you are > obviously requesting mux. You could still use a=rtcp and/or > a=rtcp-mux for backward compatibility, but if you need rtcp-mux-only > semantics, then you could just use this new attribute. If it isn't > ack'ed, then take remedial action. > > This new attribute would have same syntax as a=rtcp, except for the > name. New rules for it would be: > > - if in offer, must also be in answer. The answer gives the port(/addr) > for the answerer. If the answerer wants port+1 it needs to compute > what that is and put it in. > - if it is *not* in the offer, it can't be used in the answer. If the > answerer can't do rtcp on port+1 then it needs to refuse the media > stream. It could try sending a subsequent offer for what it can do. > > - we *could* explicitly allow the port to be set to zero, and/or the > address to be set to 0.0.0.0, to indicate that rtcp is not desired. > (Don't know if it is a good idea.) > > Thanks, > Paul > > From nobody Mon Jan 25 09:58:14 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7EC1B3801 for ; Mon, 25 Jan 2016 09:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deOCTRp-pZNF for ; Mon, 25 Jan 2016 09:58:11 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528F41B3802 for ; Mon, 25 Jan 2016 09:58:10 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-18-56a6622f4077 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9C.3D.05041.F2266A65; Mon, 25 Jan 2016 18:58:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Mon, 25 Jan 2016 18:58:00 +0100 From: Christer Holmberg To: Paul Kyzivat , Suhas Nandakumar Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoIAAIcaAgAEX24CAAJvKgIAACmeAgAAMtICAAM4ZgIAAhUyAgAAi3NA= Date: Mon, 25 Jan 2016 17:57:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> <56A64EFD.4000509@alum.mit.edu> In-Reply-To: <56A64EFD.4000509@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7iq5B0rIwgwnvuSymLn/MYrFiwwFW ixkXpjJb7JzbwezA4vH3/Qcmj52z7rJ7LFnyk8nj1pSCAJYoLpuU1JzMstQifbsEroyOlpyC TS4Vjzf/YmtgvODUxcjJISFgIvF1+QQ2CFtM4sK99UA2F4eQwGFGiY7fkxghnCWMEn19X5m7 GDk42AQsJLr/aYM0iAgESZxddRWsmVnAS6Jh9nYwW1jATqL59HpmiBp7iVNrP4DNERHoYpS4 8GwFG8gcFgFViXdrdEBqeAV8Jc42vmKH2PWWTWLarjVMIDWcAjoSC29Fg9QwAh33/RRIGGSX uMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW0lixfZLjCBjmAU0Jdbv0odoVZSY0v2QHWKtoMTJ mU9YJjCKzUIydRZCxywkHbOQdCxgZFnFKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERhfB7f8 ttrBePC54yFGAQ5GJR7egvClYUKsiWXFlbmHGCU4mJVEeP/zLQsT4k1JrKxKLcqPLyrNSS0+ xCjNwaIkznuQf1GYkEB6YklqdmpqQWoRTJaJg1OqgXFx+asl+7WWT/VY/X1Kn6bsH+OO+8t2 5xasKHQTOfulsH6JKGfawz3vjuwyfyu1pL3+eVZD7Mz374P//ojZ+yr2/qLqswnvOeRqK/+b dv38c6xr69FZ/3yUQqsurc+70LDvccSVZXNmyXkLhddPUnrCG8+mwfZv689Js6QuH329VtFf WjtP+8kqJZbijERDLeai4kQAKkmRlKsCAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 17:58:13 -0000 SGksDQoNCj4+IEkgZG9uJ3Qga25vdyB3aGV0aGVyIGl0IHdvdWxkIGJlIHdvcnRoIHRoZSBlZmZv cnQgdG8gInJlcGxhY2UiIGE9cnRjcCwgYW5kIHdoZXRoZXIgaXQgd291bGQgcmVhbGx5IGNoYW5n ZSBhbnl0aGluZy4NCj4+DQo+PiBJIHN0aWxsIGNsYWltIHRoYXQgd2Ugc2hvdWxkIGFzc3VtZSB0 aGF0IGRlcGxveW1lbnRzIERPIHN1cHBvcnQgYT1ydGNwLg0KPg0KPiBNeSBwb2ludCBpcyB0aGF0 ICppZiogd2UgbmVlZCB0byBpbnRyb2R1Y2UgKnNvbWV0aGluZyogbmV3IChlLmcuIA0KPiBydGNw LW11eC1vbmx5KSwgdGhlbiBhIHJlcGxhY2VtZW50IGZvciBydGNwIHdvdWxkIGJlIGEgYmV0dGVy IHNvbHV0aW9uLCBiZWNhdXNlIA0KPiBpdCB3b3VsZCBmaXggbW9yZSBwcm9ibGVtcywgYW5kIGJl IG5vIG1vcmUgdHJvdWJsZSB0byBpbXBsZW1lbnQuDQoNCldlIG5lZWQgdG8gYXNrIG91cnNlbHZl cyBGT1IgV0hBVCB3ZSB3b3VsZCBuZWVkIHNvbWV0aGluZyBuZXcuDQoNCkRvIHdlIG5lZWQgc29t ZXRoaW5nIG5ldyBpbiBvcmRlciB0byBpbmRpY2F0ZSBhbiBub24tUlRQKzEgUlRDUCBwb3J0IG51 bWJlcj8gU29tZSBwZW9wbGUgc2F5IHdlIGRvbid0OiBhcyBJQ0UgYmVjb21lcyBtb3JlIGFuZCBt b3JlIGRlcGxveWVkLCB5b3Ugd2lsbCB1c2UgY2FuZGlkYXRlcyB0byBpbmRpY2F0ZSB0aGUgUlRD UCBwb3J0IG51bWJlci4gVGhlIGE9cnRjcCB2YWx1ZSB3b24ndCBldmVuIHdvcmsgaW4gbWFueSBj YXNlcyAtIG5vIG1hdHRlciBpZiBlbnRpdGllcyBjYW4gaW5kaWNhdGUgc3VwcG9ydCBmb3IgdGhl IGF0dHJpYnV0ZSBvciBub3QuDQoNCkRvIHdlIG5lZWQgc29tZXRoaW5nIG5ldyBpbiBvcmRlciB0 byBpbmRpY2F0ZSBleGNsdXNpdmUtbXV4PyBNeSBvcGluaW9uIGlzIHRoYXQgd2UgZG8sIGJlY2F1 c2UgZS5nLiBpbiB0cmlja2xlIElDRSBjYXNlcyB5b3Ugd2lsbCBub3QgYmUgYWJsZSB0byBpbmRp Y2F0ZSBleGNsdXNpdmUtbXV4IHVzaW5nIGNhbmRpZGF0ZXMuDQoNClRoZSBsYXVuY2ggY3VzdG9t ZXJzIG9mIGV4Y2x1c2l2ZS1tdXggYXJlIFdlYlJUQyBlbmFibGVkIGJyb3dzZXJzLCBhbmQgYW55 IGVudGl0eSB0aGF0IHdhbnRzIHRvIGNvbW11bmljYXRlIHdpdGggc3VjaCBicm93c2VycyBuZWVk cyB0byBzdXBwb3J0IElDRS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2 YXRAYWx1bS5taXQuZWR1XQ0KPiBTZW50OiAyNC4gdGFtbWlrdXV0YSAyMDE2IDIyOjIxDQo+IFRv OiBTdWhhcyBOYW5kYWt1bWFyDQo+IENjOiBSb21hbiBTaHBvdW50OyBDaHJpc3RlciBIb2xtYmVy ZzsgbW11c2ljQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBOb3QgZml4aW5nIGE9 cnRjcCBhbmQgcnRjcC1tdXggZXhjbHVzaXZlDQo+DQo+IE9uIDEvMjQvMTYgMjozNiBQTSwgU3Vo YXMgTmFuZGFrdW1hciB3cm90ZToNCj4+DQo+Pg0KPj4gT24gU3VuLCBKYW4gMjQsIDIwMTYgYXQg MTA6NTggQU0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1IA0KPj4gPG1haWx0 bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCj4+DQo+PiAgICAgIE9uIDEvMjQvMTYg NDo0MSBBTSwgU3VoYXMgTmFuZGFrdW1hciB3cm90ZToNCj4+DQo+PiAgICAgICAgICBJIG1pZ2h0 IGJlIHJlcGVhdGluZyBzb21lIGRpc2N1c3Npb25zIGFscmVhZHkgbWFkZS4gU28gcGxlYXNlDQo+ PiAgICAgICAgICBmb3JnaXZlIG1lDQo+PiAgICAgICAgICBpZiBhbGwgb2YgdGhlIGJlbG93IHN1 Z2dlc3Rpb25zIGlzIGJlYXRlbiB0byBkZWF0aA0KPj4NCj4+ICAgICAgICAgICpVc2UtY2FzZTog RXhwbGljaXRseSBpbmRpY2F0ZSBSVENQIE11eGluZyBhbmQgcG9zc2libHkgYmFja3dhcmQNCj4+ ICAgICAgICAgIGNvbXBhdGliaWxpdHkqDQo+Pg0KPj4gICAgICAgICAgSSBzdXBwb3J0IGEgbmV3 IGF0dHJpYnV0ZSBhbG9uZyB3aXRoIHNvbWUgcnVsZXMgZm9yIGV4aXN0aW5nDQo+PiAgICAgICAg ICBhdHRyaWJ1dGVzDQo+PiAgICAgICAgICB3aGljaCBhbGxvd3MgYmFja3dhcmQgY29tcGF0aWJp bGl0eSAoU3Ryb25nIGdvYWwgb2YgU0RQKSBhbmQgYWxzbw0KPj4gICAgICAgICAgZXhjbHVzaXZl bmVzcyBvZiBSVENQIG11bHRpcGxleGluZw0KPj4NCj4+ICAgICAgICAgIERlZmluZSBhIG5ldyBh dHRyaWJ1dGUgKiJhPXJ0Y3AtbXV4LW9ubHkiICwgd2hpY2ggKmluIGEgb2ZmZXINCj4+ICAgICAg ICAgIGluZGljYXRlcw0KPj4gICAgICAgICAgdGhhdCB0aGUgZW5kLXBvaW50IGNhbid0IHJlY2Vp dmUgcnRjcCBvbiBzZXBhcmF0ZSBwb3J0IHRoYW4gcnRwLg0KPj4NCj4+DQo+PiAgICAgIEl0IGlz ICplc3NlbnRpYWwqIHRvIGluZGljYXRlIHRoZSBhbnN3ZXJlciBiZWhhdmlvciB0b28uIEZvciB0 aGlzIHRvDQo+PiAgICAgIHByb3ZpZGUgYmFja3dhcmQgc3VwcG9ydCwgdGhlIGFuc3dlcmVyIHdo byBzdXBwb3J0cyBtdXN0IGFsc28NCj4+ICAgICAgaW5jbHVkZSB0aGlzIGF0dHJpYnV0ZSBpbiB0 aGUgYW5zd2VyLiBJZiBpdCBpc24ndCBwcmVzZW50IGluIHRoZQ0KPj4gICAgICBhbnN3ZXIsIHRo ZW4gdGhlIG9mZmVyZXIga25vd3MgdGhhdCBpdCBoYXNuJ3QgYmVlbiBzdXBwb3J0ZWQuIEkNCj4+ ICAgICAgdGhpbmssIGluIHRoYXQgY2FzZSBpdCBtdXN0IHJlb2ZmZXIgYW5kIGVpdGhlciBwcm92 aWRlIGEgcG9ydCBwYWlyLA0KPj4gICAgICBvciBlbHNlIGRyb3AgdGhlIG1lZGlhIHN0cmVhbSwg dG8gcHJldmVudCBSVENQIGZyb20gZ29pbmcgdG8gYW4NCj4+ICAgICAgdW5jb250cm9sbGVkIHBv cnQuDQo+Pg0KPj4NCj4+IFtTdWhhc10gLSBBZ3JlZWQgUGF1bC4gSSBzZWUgYmFja3dhcmQgY29t cGF0aWJpbGl0eSBpbiAyIHdheXMuIE9uZSANCj4+IHdoZXJlIHRoZSBhZ2VudCB1bmRlcnN0YW5k cyBhPXJ0Y3AtbXV4IGJ1dCBub3QgdGhlIGE9cnRjcC1tdXgtb25seSANCj4+IGFuZCBzZWNvbmQg d2hlcmUgdGhlIGFnZW50IGRvZXNuJ3QgdW5kZXJzdGFuZCBlaXRoZXIuIExldCdzIHRoaW5rIHRo ZSANCj4+IGFuc3dlcmVyIGJlaGF2aW9yIGluIGJvdGggdGhlIGNhc2VzDQo+Pg0KPj4gQ2FzZSAx OiBBZ2VudCBzdXBwb3J0cyBSRkM1NzYxIGJ1dCBub3QgbXV4LW9ubHkNCj4+ICAgICAgSW4gdGhp cyBzY2VuYXJpbyB3ZSBtYW5kYXRlIHRoYXQgdGhlIG9mZmVyIGluY2x1ZGVzIFJGQzU3NjEgDQo+ PiBhPXJ0Y3AtbXV4IGFzIHdlbGwgd2hlbmV2ZXIgaGUgb2ZmZXJzIHdpdGggbXV4LW9ubHkuIFRo dXMgdGhlIA0KPj4gYW5zd2VyZXIgd2lsbCBzdGlsbCBNVVggdGhlIFJUQ1AgdG8gUlRQIHBvcnQg Zm9sbG93aW5nIFJGQzU3NjEgcnVsZXMuDQo+Pg0KPj4gQ2FzZSAyOiBBZ2VudCBkb2Vzbid0IHN1 cHBvcnQgUkZDNTc2MSBhbmQgbXV4LW9ubHkgYXMgd2VsbCBUaGlzIGlzIA0KPj4gdGhlIGNhc2Ug d2hlcmUgdGhlIGFuc3dlcmVyIGNhbiBwcm9jZXNzIGp1c3QgdGhlIFJGQzM2MDUgYT1ydGNwIA0K Pj4gYXR0cmlidXRlIGFuZCBjYW4gZWl0aGVyIDoNCj4+ICAgICAgICAgIDJhKSBzZW5kIHRoZSBy dGNwIHRvIHRoZSBwb3J0IGluZGljYXRlZCBpbiBhPXJ0Y3AgYXR0cmlidXRlIA0KPj4gLCB0aHVz IGVmZmVjdGl2ZWx5IG11eGluZw0KPj4gICAgICAgICAgMmIpIHdpbGwgdGhpbmsgcnRjcCBwb3J0 IHNwZWNpZmllZCBhcyBiZWluZyBlcnJvciBzaW5jZSBpdCANCj4+IG1hdGNoZXMgdGhlIFJUUCBw b3J0IGFuZCByZWplY3QgdGhlIG09bGluZS4gW1sgbm90ZTogdGhpcyBpc24ndCANCj4+IGRlZmlu ZWQgYXMgYW4gZXJyb3IgaW4gUkZDMzYwNSBdXQ0KPj4NCj4+IENhc2UgMzogQW5zd2VyZXIgc3Vw cG9ydHMgUkZDNTc2MSwgTXV4LWV4Y2x1c2l2ZQ0KPj4gICAgICBJbiB0aGlzIHN1Y2Nlc3NmdWwg c2NlbmFyaW8sIHRoZSBhbnN3ZXJlciBjYW4ganVzdCBpbmNsdWRlIA0KPj4gYT1ydGNwLW11eCBh bmQgYT1ydGNwLW11eC1leGNsdXNpdmUgaW4gaXRzIGFuc3dlciBhbmQgdGhhdCBpcyBnb29kIA0K Pj4gZW5vdWdoIGZvciB0aGUgT2ZmZXJlciB0byBrbm93IHRoYXQgQW5zd2VyZXIgaXMgYWJsZSB0 byBtdXggdGhlIHJ0Y3AgDQo+PiB0cmFmZmljIHRvd2FyZHMgdGhlIG9mZmVyZXIgYW5kIGFsc28g d2lzaGVzIHRvIHJlY2VpdmUgbXV4ZWQgKG5vDQo+PiBmYWxsYmFjaykgcnRjcCB0cmFmZmljIGZy b20gdGhlIG9mZmVyZXINCj4+DQo+PiBUaGVzZSBzZWVtcyB0byBjb252ZXJ0IG1vc3Qgb2YgYWxs IHRoZSBjYXNlcyByaWdodA0KPg0KPiBBZ3JlZS4NCj4NCj4+ICAgICAgSSB0aGluayB0aGlzIG91 Z2h0IHRvIGJlIHZpZXdlZCBhcyBhbiB1cGRhdGUgdG8gMzYwNS4NCj4NCj4gTWF5YmUgdGhhdCBp c24ndCBxdWl0ZSByaWdodCwgYnV0IGl0IG91Z2h0IHRvIGJlIGFuIHVwZGF0ZSB0byAqc29tZXRo aW5nKi4NCj4NCj4gSXQgaXMgbW9zdGx5IGE9cnRjcCB0aGF0IGlzIGJyb2tlbiwgYmVjYXVzZSBp dCBpc24ndCBhY2tub3dsZWRnZWQuIEFueSBwbGF1c2libGUgdXNlIG9mIGl0IGVuZHMgdXAgYmVp bmcgYnJva2VuIGlmIHRoZSBhbnN3ZXJlciBkb2Vzbid0IHN1cHBvcnQgaXQsIGJ1dCB0aGUgb2Zm ZXJlciBoYXMgbm8gd2F5IG9mIHRlbGxpbmcgdGhhdC4NCj4NCj4gYT1ydGNwLW11eCBpcyBuZWdv dGlhdGVkLiBTbyB0aGUgb2ZmZXJlciBjYW4gdGVsbCB3aGVuIHRoZSBhbnN3ZXJlciBkb2Vzbid0 IHN1cHBvcnQgaXQuIEluIHRoYXQgY2FzZSBpdCBjYW4gdGFrZSByZW1lZGlhbCBhY3Rpb24uIFRo ZXJlIG1heSBiZSBzb21lIHN0cmF5IHJ0Y3AgcGFja2V0cyB1bnRpbCB0aGF0IGhhcHBlbnMuIFNv IGE9cnRjcC1tdXgtb25seSBpc24ndCByZWFsbHkgKm5lZWRlZCouIFdoYXQgaXQgZG9lcyBpcyBw cmV2ZW50IHRob3NlIGZldyBzdHJheSBwYWNrZXRzLg0KPg0KPiBCdXQgYT1ydGNwLW11eC1vbmx5 IGlzbid0IHRoZSBiZXN0IGFuc3dlciBmb3IgZml4aW5nIGE9cnRjcCwgYmVjYXVzZSANCj4gaXQg ZG9lc24ndCBzb2x2ZSBjYXNlcyB3aGVuIHRoZSBvZmZlcmVyIHdhbnRzIHNlcGFyYXRlIHJ0Y3As IGJ1dCBub3QgDQo+IG9uDQo+IHBvcnQrMSwgYW5kIHRoZSBhbnN3ZXJlciBkb2Vzbid0IHN1cHBv cnQgdGhhdC4NCj4NCj4gUGVyaGFwcyB0aGUgcmlnaHQgc29sdXRpb24gaXMgdG8gaW50cm9kdWNl IGEgbmV3IGF0dHJpYnV0ZSB0byANCj4gKnJlcGxhY2UqIGE9cnRjcC4gSXQgd291bGQgaGF2ZSBz aW1pbGFyIHNlbWFudGljcywgYnV0IHJlcXVpcmUgDQo+IG5lZ290aWF0aW9uLiBJdCBjb3VsZCBp biBwcmluY2lwbGUgYWxzbyByZXBsYWNlIGE9cnRjcC1tdXgsIHNpbmNlIGlmIA0KPiB5b3UgdXNl IHRoZSBzYW1lIGFkZHJlc3MvcG9ydCBmb3IgYm90aCBydHAgYW5kIHJ0Y3AgeW91IGFyZSBvYnZp b3VzbHkgDQo+IHJlcXVlc3RpbmcgbXV4LiBZb3UgY291bGQgc3RpbGwgdXNlIGE9cnRjcCBhbmQv b3IgYT1ydGNwLW11eCBmb3IgDQo+IGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGJ1dCBpZiB5b3Ug bmVlZCBydGNwLW11eC1vbmx5IHNlbWFudGljcywgdGhlbiANCj4geW91IGNvdWxkIGp1c3QgdXNl IHRoaXMgbmV3IGF0dHJpYnV0ZS4gSWYgaXQgaXNuJ3QgYWNrJ2VkLCB0aGVuIHRha2UgcmVtZWRp YWwgYWN0aW9uLg0KPg0KPiBUaGlzIG5ldyBhdHRyaWJ1dGUgd291bGQgaGF2ZSBzYW1lIHN5bnRh eCBhcyBhPXJ0Y3AsIGV4Y2VwdCBmb3IgdGhlIA0KPiBuYW1lLiBOZXcgcnVsZXMgZm9yIGl0IHdv dWxkIGJlOg0KPg0KPiAtIGlmIGluIG9mZmVyLCBtdXN0IGFsc28gYmUgaW4gYW5zd2VyLiBUaGUg YW5zd2VyIGdpdmVzIHRoZSBwb3J0KC9hZGRyKQ0KPiAgICAgZm9yIHRoZSBhbnN3ZXJlci4gSWYg dGhlIGFuc3dlcmVyIHdhbnRzIHBvcnQrMSBpdCBuZWVkcyB0byBjb21wdXRlDQo+ICAgICB3aGF0 IHRoYXQgaXMgYW5kIHB1dCBpdCBpbi4NCj4gLSBpZiBpdCBpcyAqbm90KiBpbiB0aGUgb2ZmZXIs IGl0IGNhbid0IGJlIHVzZWQgaW4gdGhlIGFuc3dlci4gSWYgdGhlDQo+ICAgICBhbnN3ZXJlciBj YW4ndCBkbyBydGNwIG9uIHBvcnQrMSB0aGVuIGl0IG5lZWRzIHRvIHJlZnVzZSB0aGUgbWVkaWEN Cj4gICAgIHN0cmVhbS4gSXQgY291bGQgdHJ5IHNlbmRpbmcgYSBzdWJzZXF1ZW50IG9mZmVyIGZv ciB3aGF0IGl0IGNhbiBkby4NCj4NCj4gLSB3ZSAqY291bGQqIGV4cGxpY2l0bHkgYWxsb3cgdGhl IHBvcnQgdG8gYmUgc2V0IHRvIHplcm8sIGFuZC9vciB0aGUNCj4gICAgIGFkZHJlc3MgdG8gYmUg c2V0IHRvIDAuMC4wLjAsIHRvIGluZGljYXRlIHRoYXQgcnRjcCBpcyBub3QgZGVzaXJlZC4NCj4g ICAgIChEb24ndCBrbm93IGlmIGl0IGlzIGEgZ29vZCBpZGVhLikNCj4NCj4gCVRoYW5rcywNCj4g CVBhdWwNCj4NCg0K From nobody Mon Jan 25 10:51:58 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7880B1B390B for ; Mon, 25 Jan 2016 10:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASmyuiy_OtrS for ; Mon, 25 Jan 2016 10:51:55 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 DEC091B390A for ; Mon, 25 Jan 2016 10:51:54 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id g73so165038557ioe.3 for ; Mon, 25 Jan 2016 10:51:54 -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:date:message-id:subject:from:to :cc:content-type; bh=hsYe2apKzfHrDuR1DBRX9t3mwhboqHsbKlKJoEVM2ZY=; b=E7UQhn4jaeHJOcOqwweMfTP3EEsjHzyBPG+H+foIErZ09Zwims3b+L2hgA4S9F5uqT 7tS/IBpTIamA7NmJVR+Ax1lHX8s7zksPJeH/PZoY6Zdt2a/6TF0ujH1JaaWfp45vVyY3 kF8IvdOJV5xeDLzsHwKqv+0a7K64WK4j1slreFFU/GYafa3XgCqiAYmisf08yjUlbT09 b7oYcFML0o+AIE6m3Nu1L/QvlNW8VWJf1uRSw2NKdq+EyxpZTIoJ+nmtBmLbhJZ5DEPz n8jtVmgn+owEj6a2TVv/TVVsSELxTwQDM0cQCrVG4W+lOZwiyVuMRbI8O7GTCYPRdMsE nX+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hsYe2apKzfHrDuR1DBRX9t3mwhboqHsbKlKJoEVM2ZY=; b=jv2r38pzFiZ80Sy8uJ0eZU1jVTOf3IIiXPxoZ2fTN2J/Em8+UfrGI8ELp85aD29092 SYhGORlGzcpdZtl9tmpsBBV0Mbe1Mq4xjnCrQUd2w9oaBPU+af+72vCE8Sd8XxvFMLx3 alJvd8hX3z4kE05Ctq7Pd4h9bxaMoLrjXw5v2MXTsv+yR0oaxzhYMNDhujsuBruaqXWm oH7Sb6IPW9A1hczFz1iATxc2ZweDc6hqdFuYiTzsunzgGJtuZ70HOebiAWXvpe8tGZHo ap6diFd3brX5B5MMnrybEAoZaKQg0JCLgyO2nA6BPL+DkHMK9OUePCy2IICLotI/EjaV oDhg== X-Gm-Message-State: AG10YOQBMzV5/R5udYYMrcnaTggSOukIvDbcwmzIA0PoK68w6Zw3czefShJ93c1/yHt2cw== X-Received: by 10.107.3.154 with SMTP id e26mr17056570ioi.99.1453747914103; Mon, 25 Jan 2016 10:51:54 -0800 (PST) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id sd10sm21126igb.13.2016.01.25.10.51.52 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 10:51:52 -0800 (PST) Received: by mail-io0-f180.google.com with SMTP id g73so165037272ioe.3 for ; Mon, 25 Jan 2016 10:51:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.14.72 with SMTP id 69mr18819418ioo.145.1453747911617; Mon, 25 Jan 2016 10:51:51 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 25 Jan 2016 10:51:51 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> <56A64EFD.4000509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> Date: Mon, 25 Jan 2016 13:51:51 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113fcf0edd791d052a2d0fc5 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 18:51:56 -0000 --001a113fcf0edd791d052a2d0fc5 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 25, 2016 at 12:57 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > We need to ask ourselves FOR WHAT we would need something new. > > Do we need something new in order to indicate an non-RTP+1 RTCP port > number? Some people say we don't: as ICE becomes more and more deployed, > you will use candidates to indicate the RTCP port number. The a=rtcp value > won't even work in many cases - no matter if entities can indicate support > for the attribute or not. > > Do we need something new in order to indicate exclusive-mux? My opinion is > that we do, because e.g. in trickle ICE cases you will not be able to > indicate exclusive-mux using candidates. > > The launch customers of exclusive-mux are WebRTC enabled browsers, and any > entity that wants to communicate with such browsers needs to support ICE. > > I agree. If end-points are deployed behind NAT they really should use ICE. If end points are not deployed behind NAT they do not need a=rtcp. I think what we need the simplest possible solution that works with end points on public addresses and end points that use ICE. I think a simple, flag like negotiated attribute would be ideal for this. Furthermore, we should decide if we care about few RTCP packets being sent during the session setup by an end point that does not understand a=rtcp, a=mux, or new attribute. If we can allow those packets, then flag like attribute is sufficient. If we need to block those few packets, then we need to either set c= line to IN IP4 0.0.0.0 or m= line port to 0 and provide the actual address/port elsewhere. Finally, whatever design is used, I would like to see something that would definitely fail to setup the media session when both sides do not support RTCP mux. What I would like to avoid is an end point continuously sending RTCP to address/port which is not expecting it. When deploying this can be a hard issue to detect during the interop testing and it can produce a lot of interesting and unexpected results. This is one of the reasons I do not linke a=rtcp only solution. Regards, _____________ Roman Shpount --001a113fcf0edd791d052a2d0fc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 25, 2016 at 12:57 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:
We need to ask ourselves FOR WHAT we woul= d need something new.

Do we need something new in order to indicate an non-RTP+1 RTCP port number= ? Some people say we don't: as ICE becomes more and more deployed, you = will use candidates to indicate the RTCP port number. The a=3Drtcp value wo= n't even work in many cases - no matter if entities can indicate suppor= t for the attribute or not.

Do we need something new in order to indicate exclusive-mux? My opinion is = that we do, because e.g. in trickle ICE cases you will not be able to indic= ate exclusive-mux using candidates.

The launch customers of exclusive-mux are WebRTC enabled browsers, and any = entity that wants to communicate with such browsers needs to support ICE.


I agree.

If end-points are deployed behind= NAT they really should use ICE. If end points are not deployed behind NAT = they do not need a=3Drtcp. I think what we need the simplest possible solut= ion that works with end points on public addresses and end points that use = ICE. I think a simple, flag like negotiated attribute would be ideal for th= is.

Furthermore, we should decide if we care about= few RTCP packets being sent during the session setup by an end point that = does not understand a=3Drtcp, a=3Dmux, or new attribute. If we can allow th= ose packets, then flag like attribute is sufficient. If we need to block th= ose few packets, then we need to either set c=3D line to IN IP4 0.0.0.0 or = m=3D line port to 0 and provide the actual address/port elsewhere.

Finally, whatever design is used, I would like to see some= thing that would definitely fail to setup the media session when both sides= do not support RTCP mux. What I would like to avoid is an end point contin= uously sending RTCP to address/port which is not expecting it. When deployi= ng this can be a hard issue to detect during the interop testing and it can= produce a lot of interesting and unexpected results. This is one of the re= asons I do not linke a=3Drtcp only solution.

Regar= ds,
_____________
Roman Shpount=
=C2=A0
--001a113fcf0edd791d052a2d0fc5-- From nobody Mon Jan 25 11:38:09 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9B1A0035 for ; Mon, 25 Jan 2016 11:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kyp_AhJ4OISu for ; Mon, 25 Jan 2016 11:38:05 -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 CF69E1A0033 for ; Mon, 25 Jan 2016 11:38:04 -0800 (PST) X-AuditID: 12074414-f794f6d000007852-1b-56a6799b7333 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.7E.30802.B9976A65; Mon, 25 Jan 2016 14:38:04 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u0PJc26f029119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Jan 2016 14:38:03 -0500 To: Christer Holmberg , Suhas Nandakumar References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> <56A64EFD.4000509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56A67995.4040309@alum.mit.edu> Date: Mon, 25 Jan 2016 14:37:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixO6iqDunclmYwYZgiwszDzNaTF3+mMVi xoWpzBY753YwO7B4/Pp6lc1j56y77B5Llvxk8rg1pSCAJYrbJimxpCw4Mz1P3y6BO6N/lUrB ctOKU9u5GxhXaHYxcnBICJhIfFyr2sXICWSKSVy4t56ti5GLQ0jgMqPE0yWPWSCcp0wSXa/a mECqhAXsJFav3sUKYosIpEsc+LuaGaJoI7vE8jcPGEESzAJeEmf/XGAHsdkEtCTmHPrPAmLz CmhLbFl6FWwQi4CqxMbm42A1ogJpEvtn/2aCqBGUODnzCVg9p4CfxKPb39ggZppJzNv8kBnC lpfY/nYO8wRGgVlIWmYhKZuFpGwBI/MqRrnEnNJc3dzEzJzi1GTd4uTEvLzUIl0LvdzMEr3U lNJNjJBgFtnBeOSk3CFGAQ5GJR7eDQXLwoRYE8uKK3MPMUpyMCmJ8s7SAwrxJeWnVGYkFmfE F5XmpBYfYpTgYFYS4f3PB5TjTUmsrEotyodJSXOwKInzflus7ickkJ5YkpqdmlqQWgSTleHg UJLgTa0AahQsSk1PrUjLzClBSDNxcIIM55ISKU7NS0ktSiwtyYgHxWl8MTBSQVI8QHvTQNp5 iwsSc4GiEK2nGBWlxHk/lgMlBEASGaV5cGNhKeoVozjQl8K880DaeYDpDa77FdBgJqDBfzUX gwwuSURISTUwWlz/+8XweNhZe7u6QNlFOwrFfax0cy9tTDx5yuu33VsXNbP4DddvHlWfb75+ kmPK6pi8N/e75a+uy2E3TNp4gmv1WmOlFm/GqzeLl7dqySv8mei+dDPHUbkuLtUErczWHanP Xv9/9NVU/9O7LUutNh+3X96Rr935dF5+X+2FsDWGm0/lCl7XUGIpzkg01GIuKk4EAIx1Wjws AwAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 19:38:07 -0000 On 1/25/16 12:57 PM, Christer Holmberg wrote: > Hi, > >>> I don't know whether it would be worth the effort to "replace" a=rtcp, and whether it would really change anything. >>> >>> I still claim that we should assume that deployments DO support a=rtcp. >> >> My point is that *if* we need to introduce *something* new (e.g. >> rtcp-mux-only), then a replacement for rtcp would be a better solution, because >> it would fix more problems, and be no more trouble to implement. > > We need to ask ourselves FOR WHAT we would need something new. > > Do we need something new in order to indicate an non-RTP+1 RTCP port number? Some people say we don't: as ICE becomes more and more deployed, you will use candidates to indicate the RTCP port number. The a=rtcp value won't even work in many cases - no matter if entities can indicate support for the attribute or not. > > Do we need something new in order to indicate exclusive-mux? My opinion is that we do, because e.g. in trickle ICE cases you will not be able to indicate exclusive-mux using candidates. > > The launch customers of exclusive-mux are WebRTC enabled browsers, and any entity that wants to communicate with such browsers needs to support ICE. But, if we need to implement something new anyway, why not have it be something, that in addition to specifying exclusive-mux in this case can *also* provide a fix to the problems of a=rtcp in other cases? Thanks, Paul > Regards, > > Christer > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 24. tammikuuta 2016 22:21 >> To: Suhas Nandakumar >> Cc: Roman Shpount; Christer Holmberg; mmusic@ietf.org >> Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive >> >> On 1/24/16 2:36 PM, Suhas Nandakumar wrote: >>> >>> >>> On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat >> > wrote: >>> >>> On 1/24/16 4:41 AM, Suhas Nandakumar wrote: >>> >>> I might be repeating some discussions already made. So please >>> forgive me >>> if all of the below suggestions is beaten to death >>> >>> *Use-case: Explicitly indicate RTCP Muxing and possibly backward >>> compatibility* >>> >>> I support a new attribute along with some rules for existing >>> attributes >>> which allows backward compatibility (Strong goal of SDP) and also >>> exclusiveness of RTCP multiplexing >>> >>> Define a new attribute *"a=rtcp-mux-only" , which *in a offer >>> indicates >>> that the end-point can't receive rtcp on separate port than rtp. >>> >>> >>> It is *essential* to indicate the answerer behavior too. For this to >>> provide backward support, the answerer who supports must also >>> include this attribute in the answer. If it isn't present in the >>> answer, then the offerer knows that it hasn't been supported. I >>> think, in that case it must reoffer and either provide a port pair, >>> or else drop the media stream, to prevent RTCP from going to an >>> uncontrolled port. >>> >>> >>> [Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One >>> where the agent understands a=rtcp-mux but not the a=rtcp-mux-only >>> and second where the agent doesn't understand either. Let's think the >>> answerer behavior in both the cases >>> >>> Case 1: Agent supports RFC5761 but not mux-only >>> In this scenario we mandate that the offer includes RFC5761 >>> a=rtcp-mux as well whenever he offers with mux-only. Thus the >>> answerer will still MUX the RTCP to RTP port following RFC5761 rules. >>> >>> Case 2: Agent doesn't support RFC5761 and mux-only as well This is >>> the case where the answerer can process just the RFC3605 a=rtcp >>> attribute and can either : >>> 2a) send the rtcp to the port indicated in a=rtcp attribute >>> , thus effectively muxing >>> 2b) will think rtcp port specified as being error since it >>> matches the RTP port and reject the m=line. [[ note: this isn't >>> defined as an error in RFC3605 ]] >>> >>> Case 3: Answerer supports RFC5761, Mux-exclusive >>> In this successful scenario, the answerer can just include >>> a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good >>> enough for the Offerer to know that Answerer is able to mux the rtcp >>> traffic towards the offerer and also wishes to receive muxed (no >>> fallback) rtcp traffic from the offerer >>> >>> These seems to convert most of all the cases right >> >> Agree. >> >>> I think this ought to be viewed as an update to 3605. >> >> Maybe that isn't quite right, but it ought to be an update to *something*. >> >> It is mostly a=rtcp that is broken, because it isn't acknowledged. Any plausible use of it ends up being broken if the answerer doesn't support it, but the offerer has no way of telling that. >> >> a=rtcp-mux is negotiated. So the offerer can tell when the answerer doesn't support it. In that case it can take remedial action. There may be some stray rtcp packets until that happens. So a=rtcp-mux-only isn't really *needed*. What it does is prevent those few stray packets. >> >> But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because >> it doesn't solve cases when the offerer wants separate rtcp, but not >> on >> port+1, and the answerer doesn't support that. >> >> Perhaps the right solution is to introduce a new attribute to >> *replace* a=rtcp. It would have similar semantics, but require >> negotiation. It could in principle also replace a=rtcp-mux, since if >> you use the same address/port for both rtp and rtcp you are obviously >> requesting mux. You could still use a=rtcp and/or a=rtcp-mux for >> backward compatibility, but if you need rtcp-mux-only semantics, then >> you could just use this new attribute. If it isn't ack'ed, then take remedial action. >> >> This new attribute would have same syntax as a=rtcp, except for the >> name. New rules for it would be: >> >> - if in offer, must also be in answer. The answer gives the port(/addr) >> for the answerer. If the answerer wants port+1 it needs to compute >> what that is and put it in. >> - if it is *not* in the offer, it can't be used in the answer. If the >> answerer can't do rtcp on port+1 then it needs to refuse the media >> stream. It could try sending a subsequent offer for what it can do. >> >> - we *could* explicitly allow the port to be set to zero, and/or the >> address to be set to 0.0.0.0, to indicate that rtcp is not desired. >> (Don't know if it is a good idea.) >> >> Thanks, >> Paul >> > From nobody Mon Jan 25 11:46:11 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507B31A007C for ; Mon, 25 Jan 2016 11:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEof2KqEPiIL for ; Mon, 25 Jan 2016 11:46:08 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 EBF251A0018 for ; Mon, 25 Jan 2016 11:46:07 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 1so163018340ion.1 for ; Mon, 25 Jan 2016 11:46:07 -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:date:message-id:subject:from:to :cc:content-type; bh=IHdr0eejZ52Vty6lcWiTFYCWA28YN3KzIcjDmIGJfs4=; b=OIatrtpN5PM7P7Wc5LbKUSgUhm6gZsU3WcAkZ8WU7jqQpEeLDthWBgPErYl69zMc0z VJ1cwgR3lEtslona7Fl223WJF7GoYfYnzbSEPWAK+pxDqdXqI2ILvFjEZvJBuqzcnZAn INAAvz2K6TM784s17XTNxwxGAqfVpC/FA9up9vw4kR1ipWp/x1qbijm5WYtjlV5M4LJl zwN36XD4r/x42g3G0Fcu25FIvC1M8+HYYD43p7YvuXOL1gSynGYTudmxQQYxgNsBvRTG dkprcQ7Gfyabd3tGkaugQ8GKwm0ZGfMt/tLy14TNoAzvNdtXiTlBYlyGWeuRvXuvCD35 kaoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IHdr0eejZ52Vty6lcWiTFYCWA28YN3KzIcjDmIGJfs4=; b=WNB38337Ajr9gncD3TuIGp/2ME0PBq1dDOgVZgwTGcneAewh5okl2Lo5CFHZI/OFBv lFf3W2e6uySToanCJ0pn7FI4XDfuIQqpYabVUTcQ+X0f/uFwPAXqsfIFcIAF/TZPYvIm FAyUmLtliHrahY0/ihZG6q8VTHi9K+pEAfvlypoYgRNaPZNFHu1vT0kfVM6/OMKTOEcC VcZbUiWS6gBioekTK84IBOqPrYITGxzg0fFvrNb2ndLBBsabO137g6ho9dPzfc98HTGp QfUICDR/5irx21RG1kdkWlMlPIhWMdUkJzpPqdrfat5VDLaNK47CWTWMTq9stgk/HO9s OpPg== X-Gm-Message-State: AG10YOQnSI2XbxuWxeTbQlqDGkQWSDn+WvCuGmu9hH5D4duFGGArn8v41Zy3vjuGARKSdA== X-Received: by 10.107.170.67 with SMTP id t64mr22829591ioe.71.1453751167093; Mon, 25 Jan 2016 11:46:07 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id p8sm102407iga.10.2016.01.25.11.46.05 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 11:46:05 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id g73so166647422ioe.3 for ; Mon, 25 Jan 2016 11:46:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.136.226 with SMTP id s95mr17124523ioi.38.1453751164844; Mon, 25 Jan 2016 11:46:04 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 25 Jan 2016 11:46:04 -0800 (PST) In-Reply-To: <56A67995.4040309@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37D5509D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> <56A64EFD.4000509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> <56A67995.4040309@alum.mit.edu> Date: Mon, 25 Jan 2016 14:46:04 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113ec962c5c18d052a2dd1e3 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 19:46:09 -0000 --001a113ec962c5c18d052a2dd1e3 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 25, 2016 at 2:37 PM, Paul Kyzivat wrote: > But, if we need to implement something new anyway, why not have it be > something, that in addition to specifying exclusive-mux in this case can > *also* provide a fix to the problems of a=rtcp in other cases? > What other cases? There is practically no existing usage for a=rtcp. Why fix something that is not going to be used? _____________ Roman Shpount --001a113ec962c5c18d052a2dd1e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 25, 2016 at 2:37 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
But, if we need to implement something new anyway, why not have i= t be something, that in addition to specifying exclusive-mux in this case c= an *also* provide a fix to the problems of a=3Drtcp in other cases?

What other cases? There is practically no exis= ting usage for a=3Drtcp. Why fix something that is not going to be used?
_____________
Roman Shpount
=
=C2=A0
--001a113ec962c5c18d052a2dd1e3-- From nobody Mon Jan 25 11:55:44 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341D61A00A8 for ; Mon, 25 Jan 2016 11:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUInDUaN1SXR for ; Mon, 25 Jan 2016 11:55:41 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 815E31A00A5 for ; Mon, 25 Jan 2016 11:55:41 -0800 (PST) X-AuditID: 12074412-f79a76d000007c8b-50-56a67dbccdc2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.33.31883.CBD76A65; Mon, 25 Jan 2016 14:55:40 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u0PJtdaX030041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Jan 2016 14:55:40 -0500 To: Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> <56A64EFD.4000509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> <56A67995.4040309@alum.mit.edu> From: Paul Kyzivat Message-ID: <56A67DBB.1000509@alum.mit.edu> Date: Mon, 25 Jan 2016 14:55:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixO6iqLundlmYwZWtJhYXZh5mtJi6/DGL xYwLU5ktds7tYHZg8fj19Sqbx85Zd9k9liz5yeRxa0pBAEsUt01SYklZcGZ6nr5dAnfG7rln 2At+slRcXHaKtYHxJXMXIweHhICJxKN/9l2MnECmmMSFe+vZQGwhgcuMEttXO0DYT5kkfiwT BrGFBewkVq/exQpiiwioSvz9PpkJouYau8Ts9zJdjFwczAJTGSUm/XvODpJgE9CSmHPoPwuI zSugLfHixjSwOAtQ89o/y8EGiQqkSeyf/ZsJokZQ4uTMJ2D1nAKBErt+NTKC2MwCZhLzNj9k hrDlJba/ncM8gVFgFpKWWUjKZiEpW8DIvIpRLjGnNFc3NzEzpzg1Wbc4OTEvL7VI10wvN7NE LzWldBMjJJyFdjCuPyl3iFGAg1GJh3dDwbIwIdbEsuLK3EOMkhxMSqK87JVAIb6k/JTKjMTi jPii0pzU4kOMEhzMSiK8HNVAOd6UxMqq1KJ8mJQ0B4uSOO/Pxep+QgLpiSWp2ampBalFMFkZ Dg4lCV7VGqBGwaLU9NSKtMycEoQ0EwcnyHAuKZHi1LyU1KLE0pKMeFCcxhcDIxUkxQO0Nxmk nbe4IDEXKArReopRl2PBj9trmYRY8vLzUqXEeR1AigRAijJK8+BWwJLXK0ZxoI+FeXNAqniA iQ9u0iugJUxAS/5qLgZZUpKIkJJqYNx0r/azqMUZ27XTOS4Xej85e/dG4GvxA1v6pU69yeZT Ma6OE57oPu/J0bm/srnOzPKrvLzpwUXtZrvpNV7zedc3pijmBRzcfItpTaz5s8K735eHtmVt 6CpiPn/zQf3OdIPtOqr9OueOTai4s+/mTz2DD7PFr/ydmr5q65vgxU3JAZdtb33PnmisxFKc kWioxVxUnAgA8kk3BzkDAAA= Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 19:55:43 -0000 On 1/25/16 2:46 PM, Roman Shpount wrote: > On Mon, Jan 25, 2016 at 2:37 PM, Paul Kyzivat > wrote: > > But, if we need to implement something new anyway, why not have it > be something, that in addition to specifying exclusive-mux in this > case can *also* provide a fix to the problems of a=rtcp in other cases? > > > What other cases? There is practically no existing usage for a=rtcp. Why > fix something that is not going to be used? Do you have data supporting this assertion? Maybe we can find some. Perhaps from sipits. Thanks, Paul From nobody Mon Jan 25 13:10:44 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87051A026F for ; Mon, 25 Jan 2016 13:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlB27awi_8oD for ; Mon, 25 Jan 2016 13:10:34 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 D4F701A0266 for ; Mon, 25 Jan 2016 13:10:33 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 77so165220647ioc.2 for ; Mon, 25 Jan 2016 13:10:33 -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:date:message-id:subject:from:to :cc:content-type; bh=1sN0wd85EOyS7EB2Q9ho+ImzRJz1um8XDvXV+t+rZ/M=; b=oWhGsVBBI600u5RWME5HLK7e5jRvQ2zQcsdlYOCxsI3M6A/F3i/gRxGovVLR8ImK4w GTEyEKQu76x2FpaT3+fI+Zuy8Q+D2JXF4oNNtNH/pqFhbGqB8WZGFmNervSOh2jER+zk SaDe3gWkDRdQMB3Gl9rD/581/6EPQHtPisaoV3BtI5HNPIEx0Ns6gnnO7PPopy/b15iT HmCAFExboEQDVPylMDhRkhPvTV3besWthtCeQojz7RL48UB91A7AnYHBQOw65w8rH8xq iAIpk9mLu74TmsQEH7HRlfIh/t+VYd7LQwHnMGqsa8AnFPF2sjjGLSq1H9nU3w8FVmhD G5sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1sN0wd85EOyS7EB2Q9ho+ImzRJz1um8XDvXV+t+rZ/M=; b=PlmNgwna8dnhhR4uH8zIUbhgDPhaepDIlUvuOTbn472xiSh5P/6ibxPix9jWsE8s9f 94H00im72dB+2CCpKjznryxxw6Eqnq6C2iOCOvZY9f6bS0rgdnr3aSpF2a90CD66jXTv bGnaMAU7GjN28cJgZepReuwBjlHTU7yRJQxwPvUa33s3iZ1NqGfTF/CjiS16tDLyq3ax G0v3KFxPnVeyHnHAsS5wStf/zQ+jdNaxYiktXHy0bGObmxrEiWohnxKKH0jfqKyifEDq 8FqcJk6t5Ad1+uriN+1ry/XcqCfAJUpoovZtoWuNl760iddjoI24wmCCNz5wUfPCaYTp j7Uw== X-Gm-Message-State: AG10YOTP2maDsh08SXbTXuAdMXZeAuZB3jvp8qpu2vIT16MvqDoVL8quTt9btNM1qJhq4A== X-Received: by 10.107.46.228 with SMTP id u97mr18993917iou.136.1453756233059; Mon, 25 Jan 2016 13:10:33 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id nq10sm237107igb.2.2016.01.25.13.10.31 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 13:10:31 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id mw1so39586284igb.1 for ; Mon, 25 Jan 2016 13:10:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr19695382igb.24.1453756231011; Mon, 25 Jan 2016 13:10:31 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 25 Jan 2016 13:10:30 -0800 (PST) In-Reply-To: <56A67DBB.1000509@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <56A51EE7.8060406@alum.mit.edu> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> <56A64EFD.4000509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> <56A67995.4040309@alum.mit.edu> <56A67DBB.1000509@alum.mit.edu> Date: Mon, 25 Jan 2016 16:10:30 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e01184168bd5924052a2efff7 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 21:10:43 -0000 --089e01184168bd5924052a2efff7 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 25, 2016 at 2:55 PM, Paul Kyzivat wrote: > Do you have data supporting this assertion? > I believe a=rtcp was developed to work in conjunction with RFC 3489. In practice such deployment scenarios are recipes for disaster since end points will end up not getting connected often enough for large groups of your customers to complain. Such architecture also has serious security problems. This entire architecture was later completely redesigned (see https://tools.ietf.org/html/rfc5389#section-2 for more details). Anything commercially viable is using either something like ICE or host based NAT traversal. I think we should strongly steer service implementers towards ICE when NAT support is required and do not extend or promote a=rtcp based solutions. ICE does mention a=rtcp but it is only used there for legacy interop with exiting end points which were designed to work with RFC 3489 derived addresses. I do not think a=rtcp has any use cases beyond such legacy interop. _____________ Roman Shpount --089e01184168bd5924052a2efff7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 25, 2016 at 2:55 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
Do you have data supporting this assertion?
=

I believe a=3Drtcp was developed to work in c= onjunction with RFC 3489. In practice such deployment scenarios are recipes= for disaster since end points will end up not getting connected often enou= gh for large groups of your customers to complain. Such architecture also h= as serious security problems.=C2=A0This entire architecture was later compl= etely redesigned (see https://tools.ietf.org/html/rfc5389#section-2 for more details).= =C2=A0

Anything commercially viable is using eithe= r something like ICE or host based NAT traversal. I think we should strongl= y steer service implementers towards ICE when NAT support is required and d= o not extend or promote a=3Drtcp based solutions. ICE does mention a=3Drtcp= but it is only used there for legacy interop with exiting end points which= were designed to work with RFC 3489 derived addresses. I do not think a=3D= rtcp has any use cases beyond such legacy interop.
_____________
Roman Shpount
=C2=A0
--089e01184168bd5924052a2efff7-- From nobody Mon Jan 25 15:31:11 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B551B1A1EF9; Mon, 25 Jan 2016 15:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN79XmBQsexK; Mon, 25 Jan 2016 15:31:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 96C181A1EF7; Mon, 25 Jan 2016 15:31:07 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0PNV25I087588 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jan 2016 17:31:02 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Suhas Nandakumar" Date: Mon, 25 Jan 2016 17:31:02 -0600 Message-ID: <219BC1C8-6F90-4E23-AF7B-49B2D7BAF172@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: draft-ietf-mmusic-proto-iana-registration.all@ietf.org, mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-proto-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 23:31:09 -0000 Thanks Suhas, those edits look good, and would resolve my concerns. Ben. On 18 Jan 2016, at 18:09, Suhas Nandakumar wrote: > Hello Ben > > Thanks for the review. Please see below for the resolutions on your > comments (marked in bold). > > > Substantive (to be resolved before last call): > > *- (This is really editorial, but I think there's a chance for > confusion.) > The references in section 3 seem insufficient. Section 1 lists RFCs > that > define most of all of the related transport protocol profiles. For > example, > [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That > information > should probably also go in section 3, since that's the section > referenced > by the IANA considerations section. To avoid duplication, consider > moving > the bits after the first paragraph of section 1 into the respective > subsections of 3.* > > [Suhas] Removed the detailed proto descriptions from Section 1 and > moved > them to individual sections in Section 3. > > Now the Section1 just has the following para regarding the > identifiers. > > " > This specification describes additional SDP transport protocol > identifiers > for transporting RTP Media over TCP as defined in Section 3 > <#sec.proto-identifiers>. > " > > > and Section 3 has been updated to have template as below > > " > 3.1. <#rfc.section.3.1> TCP/RTP/AVPF Transport Realization > <#sec.tcp.rtp.avpf> > > The TCP/RTP/AVPF transport describes RTP Media with RTCP-based > Feedback > [RFC4585] <#RFC4585> over TCP. > > It is realized as described below: > > > - RTP/AVPF stream over the TCP transport is realized using the framing > method defined in[RFC4571] <#RFC4571>. > > 3.2. <#rfc.section.3.2> TCP/RTP/SAVP Transport Realization > <#sec.tcp.rtp.savp> > > The TCP/RTP/SAVP transport describes Secure RTP (SRTP) Media [RFC3711] > <#RFC3711> over TCP. > > It is realized as described below: > > > - RTP/SAVP stream over the TCP transport is realized using the framing > method defined in[RFC4571] <#RFC4571>. > > > and so on for other proto identifiers > > > > > *- The security considerations seem inadequate. Most, if not all, of > the > proto values listed here refer to some other RFC that has it's own > security > considerations. So it doesn't really seem true to say there are no > considerations other than those in 4566.* > > [Suhas] The new security considerations sections is as below > " > 6. <#rfc.section.6> Security Considerations <#sec.security> > > The new "proto" identifiers registered by this document in the SDP > parameters registry maintained by IANA is primarily for use by the > offer/answer model of the Session Description Protocol[RFC3264] > <#RFC3264> for > the negotiation and establishment of RTP based Media over the TCP > transport. This specification doesn't introduce any additional > security > considerations beyond those specified by the individual transport > protocols > identified in the "proto" identifiers and those detailed in Section 7 > of > [RFC4566] <#RFC4566>. > " > > Editorial (non-blocking): > > > *- The abstract is long. The 2nd paragraph describes what the draft > does. > Can some or all of the first paragraph be relegated to the intro?* > [Suhas] I have removed the first para from the abstract and moved it > to the > intro section. The new abstract is : > > " > Abstract <#rfc.abstract> > > The Real-time Transport Protocol (RTP) specification establishes a > registry > of profile names for use by higher-level control protocols, such as > the > Session Description Protocol (SDP), to refer to the transport methods. > This > specification describes the following new SDP transport protocol > identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', > 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', > 'TCP/DTLS/RTP/SAVPF', > 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF' > " > > > > *- 3: It would be helpful to mention that the transport protocol > mentioned > in the first paragraph goes in the field in the M-line.* > > [Suhas]. I updated the section 3 intro to have the follow new text > > " > The 'm=' line in SDP specifies, among other items, the transport > protocol *(identified > via the 'proto' field)* to be used for the media in the session. See > the > "MediaDescriptions" section of SDP [RFC4566] <#RFC4566>for a > discussion on > transport protocol identifiers. > " > > > Please let me know if these edits look fine and I can produce a new > version > for further review. > > > Cheers > Suhas > > On Thu, Jan 14, 2016 at 2:12 PM, Ben Campbell wrote: > >> Hi, >> >> Here's my AD Evaluation of draft-ietf-mmusic-proto-iana-registration. >> I >> have a couple of comments I'd like to resolve before last call, and a >> few >> editorial comments.: >> >> Substantive (to be resolved before last call): >> >> - (This is really editorial, but I think there's a chance for >> confusion.) >> The references in section 3 seem insufficient. Section 1 lists RFCs >> that >> define most of all of the related transport protocol profiles. For >> example, >> [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That >> information >> should probably also go in section 3, since that's the section >> referenced >> by the IANA considerations section. To avoid duplication, consider >> moving >> the bits after the first paragraph of section 1 into the respective >> subsections of 3. >> >> - The security considerations seem inadequate. Most, if not all, of >> the >> proto values listed here refer to some other RFC that has it's own >> security >> considerations. So it doesn't really seem true to say there are no >> considerations other than those in 4566. >> >> Editorial (non-blocking): >> >> - The abstract is long. The 2nd paragraph describes what the draft >> does. >> Can some or all of the first paragraph be relegated to the intro? >> >> - 3: It would be helpful to mention that the transport protocol >> mentioned >> in the first paragraph goes in the field in the M-line. >> >> _______________________________________________ >> 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 Tue Jan 26 00:32:03 2016 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 128C91A023E; Tue, 26 Jan 2016 00:32:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160126083201.8874.25316.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 00:32:01 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-proto-iana-registration-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 08:32:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles. Author : Suhas Nandakumar Filename : draft-ietf-mmusic-proto-iana-registration-05.txt Pages : 8 Date : 2016-01-26 Abstract: The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/ SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-proto-iana-registration-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-proto-iana-registration-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 26 00:33:29 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8421A033B for ; Tue, 26 Jan 2016 00:33:28 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUzVA3vl6vIf for ; Tue, 26 Jan 2016 00:33:26 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 D192A1A19E3 for ; Tue, 26 Jan 2016 00:33:16 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id n1so87644190vkb.3 for ; Tue, 26 Jan 2016 00:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xVIAwJtvns+peW3O0/sFJGB4ftf7Zy2QaxOp2DlStl4=; b=U9l0OAJXqBgFRLKVLD/a7mwtuz0eZLmh7IdRTgRW2xT1SBokkUA6E8MjzPlhymzjLr PYVD5/8eZJ8iqZOshPlkg42pGj/uZzyPVsE0Nr1Pm8chEIf6QAinMBSqJV3d5mLxdaOJ uPw2q6XhDiT7vQ38RdL6Ein58optWs7jor1ImdAWzEOryS4+v7woQVsuIt52j6sOzNIW 0Mx2dm4S/ekpCgTzJYCnAH0iokEnYC+fxmRRv5XhVE24ExrWU96lQBRxZOhgvJhieioR keIwqJjARKrLzUZI+Vntz0YqOKaanCbX5ru+kMsxCDWM3w9J3e58vI3nTkPMXrBYZ9/q sRxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xVIAwJtvns+peW3O0/sFJGB4ftf7Zy2QaxOp2DlStl4=; b=kAFBsJj12+6kvP4Ok1xWMPUGhyKyOFuYrL6wFoBh6j2V0jdUQYQL91mH2DoFcmyFZC moYEF/a0la7yp5yDdNXdCqRGkXfDpUd/NSrueYkjcxXXnvlSdN5YuxVTyeR2I9c1A9YU dmPQvC+n4epZ5IeOXcfuWY0C47JvLmb2mKCMuSx3RkyJJIJR72tHJmczo4/zai/Qvynb eynuVVBl9FoiO0HuNEn/nSV3wm2ShiQnhsRjShLUiWdgMJwoS+KzXcJI0CxJol1OoOP0 cuDz5YwSfHGWTBHA3LMEJLORv8KlYREoOeLGtBlJXVm8toI0ti6ctFJv+oaDP6kFcvlx 5TUg== X-Gm-Message-State: AG10YOTW59bnV9SK3tKZefVZeAYylpLaZpe68P66bX9StxLhkrBB+1yjE9wXhkUcUYqZRO2ZrvSXX+WzojMWeg== MIME-Version: 1.0 X-Received: by 10.31.54.23 with SMTP id d23mr13799286vka.25.1453797195913; Tue, 26 Jan 2016 00:33:15 -0800 (PST) Received: by 10.31.106.130 with HTTP; Tue, 26 Jan 2016 00:33:15 -0800 (PST) In-Reply-To: <20160126083201.8874.25316.idtracker@ietfa.amsl.com> References: <20160126083201.8874.25316.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 00:33:15 -0800 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=001a114385d8702112052a388976 Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-proto-iana-registration-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 08:33:28 -0000 --001a114385d8702112052a388976 Content-Type: text/plain; charset=UTF-8 This version incorporate comments from the AD evaluation. Thanks Ben for the comments. Cheers Suhas On Tue, Jan 26, 2016 at 12:32 AM, 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 > Working Group of the IETF. > > Title : IANA registrations of SDP 'proto' attribute for > transporting RTP Media over TCP under various RTP profiles. > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-proto-iana-registration-05.txt > Pages : 8 > Date : 2016-01-26 > > Abstract: > The Real-time Transport Protocol (RTP) specification establishes a > registry of profile names for use by higher-level control protocols, > such as the Session Description Protocol (SDP), to refer to the > transport methods. This specification describes the following new > SDP transport protocol identifiers for transporting RTP Media over > TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/ > SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-proto-iana-registration-05 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-proto-iana-registration-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114385d8702112052a388976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This version incorporate comments from the AD evaluation. = Thanks Ben for the comments.

Cheers
Suhas

On Tue, Ja= n 26, 2016 at 12:32 AM, <internet-drafts@ietf.org> w= rote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IANA registrations of SDP 'proto' attribute for transporting RTP M= edia over TCP under various RTP profiles.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-proto-iana-registration-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-26

Abstract:
=C2=A0 =C2=A0The Real-time Transport Protocol (RTP) specification establish= es a
=C2=A0 =C2=A0registry of profile names for use by higher-level control prot= ocols,
=C2=A0 =C2=A0such as the Session Description Protocol (SDP), to refer to th= e
=C2=A0 =C2=A0transport methods.=C2=A0 This specification describes the foll= owing new
=C2=A0 =C2=A0SDP transport protocol identifiers for transporting RTP Media = over
=C2=A0 =C2=A0TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/= RTP/SAVPF', 'TCP/DTLS/RTP/
=C2=A0 =C2=A0SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP&= #39;, 'TCP/TLS/RTP/AVPF'.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.= org/doc/draft-ietf-mmusic-proto-iana-registration/

There's also a htmlized version available at:
https://tools.ietf.org/html/= draft-ietf-mmusic-proto-iana-registration-05

A diff from the previous version is available at:
https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-mmusic-proto-iana-registration-05


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

--001a114385d8702112052a388976-- From nobody Tue Jan 26 09:38:01 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A7C1A90BD for ; Tue, 26 Jan 2016 09:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKqw_HjQLK6J for ; Tue, 26 Jan 2016 09:37:56 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39431A90B7 for ; Tue, 26 Jan 2016 09:37:54 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-00-56a7aef08e89 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 90.10.02707.0FEA7A65; Tue, 26 Jan 2016 18:37:52 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.156]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Tue, 26 Jan 2016 18:37:52 +0100 From: Bo Burman To: Suhas Nandakumar , Taylor Brandstetter Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt Thread-Index: AQHRTth9ysS5GFKjnUun8fG/OM+DD577AtmAgAAqLTCAADKiAIAADFuAgAEGZoCAAEBaAIAFh1kAgASziYCABzPAsA== Date: Tue, 26 Jan 2016 17:37:51 +0000 Message-ID: References: <20160114143257.21051.19934.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B37D188F6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D19CED@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E954072ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7je6HdcvDDLbMMrW4vOIhq8XU5Y9Z LK4tf81qsXNuB7MDi8fOWXfZPRZsKvVYsuQnUwBzFJdNSmpOZllqkb5dAlfGzxlrmApedDNX rJk9mbmB8UAjcxcjB4eEgInE1R9CXYycQKaYxIV769m6GLk4hAQOM0psevGOHcJZwiix69Ar VpAqNgENifk77jKC2CIC4RI/ek6ygdjMAjUSDzZfYAIZKizgK9HdFQpREiDRtO4YM4SdJXFi +hl2EJtFQFXi3ap+FhCbF6j80vFORohdH1gkJh2cwAYyh1MgUGLuDnuQGkYBWYn73++xQKwS l7j1ZD4TxNECEkv2nGeGsEUlXj7+xwrxl6LE8n45EJNZIF/iyG45iE2CEidnPmGZwCg6C8mg WQhVs5BUQYQ1Jdbv0oeoVpSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8 PL281JJNjMAoPLjlt8EOxpfPHQ8xCnAwKvHwbihYFibEmlhWXJl7iFGCg1lJhPfqmuVhQrwp iZVVqUX58UWlOanFhxilOViUxHkP8i8KExJITyxJzU5NLUgtgskycXBKNTDmr2sw+t62+XHU de07l7jMpwrssrpssa4gx+kp17YtFdzu7o3tU6SX561c6lPnlrJrtZFER/9yQzmnvYEH3Wf4 uvz4sTshw9zW7fnarre39Pj/hN869/O73/VdHBrvJxka7rn57mDQZu7utU/ZVMVmSE+RNPzg 90fQrVp/d22C289z3HxV8yYosRRnJBpqMRcVJwIAB5/mMr4CAAA= Archived-At: Cc: mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:37:59 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E954072ESESSMB105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkZyb20gd2hhdCBJIGNhbiB1bmRlcnN0YW5kLCB0aGVyZSBzZWVtcyB0byBiZSBubyBy ZWFzb24gdG8gY2hhbmdlIOKAk211eC1hdHRyaWJ1dGVzLTEyIGF0IHRoaXMgcG9pbnQuIEkgYWxz byBzZWUgbm8gb3Bwb3NpdGlvbiB0byBTdWhhc+KAmSBwcm9wb3NhbCBiZWxvdyB0aGF0IGlmIGEg Y2xhcmlmaWNhdGlvbiBpcyBuZWVkZWQsIGl0IHNob3VsZCBnbyBpbnRvIHRoZSBCVU5ETEUgZHJh ZnQuDQoNCklmIHRoZXJlIGFyZSBubyBmdXJ0aGVyIGNvbW1lbnRzLCBJIGludGVuZCB0byBwcm9j ZWVkIHdpdGggdGhlIHB1YmxpY2F0aW9uIHJlcXVlc3Qgb2Yg4oCTbXV4LWF0dHJpYnV0ZXMtMTIu DQoNCi9Cbw0KTU1VU0lDIGNvLWNoYWlyDQoNCkZyb206IFN1aGFzIE5hbmRha3VtYXIgW21haWx0 bzpzdWhhc2lldGZAZ21haWwuY29tXQ0KU2VudDogZGVuIDIyIGphbnVhcmkgMjAxNiAwNTozNA0K VG86IFRheWxvciBCcmFuZHN0ZXR0ZXINCkNjOiBDaHJpc3RlciBIb2xtYmVyZzsgQm8gQnVybWFu OyBtbXVzaWMgV0c7IFBldGVyIFRoYXRjaGVyDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEyLnR4dA0KDQpIZWxs byBDaHJpc3Rlci9Cby9QZXRlcg0KDQogIERvIHdlIHRoaW5rIHRoZSB1bmRlcnN0YW5kaW5nIG9m IGRlYWxpbmcgd2l0aCB0aGUgY2FuZGlkYXRlcyB3aGVuIG11eGluZyBpcyBjbGVhciBvciBkb2Vz IGVpdGhlciBvZiB0aGUgZHJhZnRzIG5lZWRzIG1vcmUgZXhwbGFuYXRpb24gb24gd2hhdCBuZWVk cyB0byBiZSBkb25lLg0KDQpUaGFua3MNClN1aGFzDQoNCk9uIE1vbiwgSmFuIDE4LCAyMDE2IGF0 IDg6NDUgUE0sIFN1aGFzIE5hbmRha3VtYXIgPHN1aGFzaWV0ZkBnbWFpbC5jb208bWFpbHRvOnN1 aGFzaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkkgYWdyZWUgd2l0aCBUYXlsb3IuDQoNClRoZSBN dXggZHJhZnQgYXNzaWducyBjYXRlZ29yeSAiVFJBTlNQT1JUIiB0byB0aGUgSUNFIGNhbmRpZGF0 ZXMuIFNvIHRoZSBjYW5kaWRhdGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgIm09IiBsaW5lIHdoaWNo IGNvcnJlc3BvbmRzIHRvIHRoZSBCVU5ETEVEIG09bGluZSBzaGFsbCBiZSBjb25zaWRlcmVkIGZv ciB0aGUgZW50aXJlIGdyb3VwLg0KDQpBcyBmYXIgYXMgaW1wbGVtZW50YXRpb24gaXMgY29uY2Vy bmVkLCBpIHRoaW5rIG9uZSBzaG91bGQgYmUgZmluZSBqdXN0IHRyaWNrbGluZyB0aGUgY2FuZGlk YXRlIGluZm9ybWF0aW9uIGZvciB0aGUgbT1saW5lIHNlbGVjdGVkIGZvciBhIGdpdmVuIEJVTkRM RSBncm91cCBhbmQgbm8gbmVlZCB0byBjb3B5IGl0IGZvciB0aGUgcmVzdCB1bmxlc3MgdGhlcmUg aXMgYSBleHBsaWNpdCBuZWVkIChJbml0aWFsIG9mZmVyLCBwbGFuIHRvIGNoYW5nZSB0aGUgYnVu ZGxlIGdyb3VwIGFkZHJlc3MsIGRyb3AgYSBtPWxpbmUpICB0byBpbmNsdWRlIGRpZmZlcmVudCBj YW5kaWRhdGVzLg0KDQogSSB3b3VsZCByZWNvbW1lbmQgd2UgdXBkYXRlIHRoZSBCVU5ETEUgZHJh ZnQgKGlmIHRoZXJlIGlzIGFueSBjb25mdXNpb24pIHRvIG1hdGNoIHRoZSBNVVggZHJhZnQgdW5s ZXNzIHBlb3BsZSB0aGluayBvdGhlcndpc2UuDQoNCkhvcGUgdGhpcyBoZWxwcy4NCg0KVGFua3MN ClN1aGFzDQoNCg0KDQoNCk9uIEZyaSwgSmFuIDE1LCAyMDE2IGF0IDg6MjAgQU0sIFRheWxvciBC cmFuZHN0ZXR0ZXIgPGRlYWRiZWVmQGdvb2dsZS5jb208bWFpbHRvOmRlYWRiZWVmQGdvb2dsZS5j b20+PiB3cm90ZToNCiJjYW5kaWRhdGUiIGlzIGluIHRoZSBUUkFOU1BPUlQgY2F0ZWdvcnkgdGhv dWdoLCB3aGljaCBkb2Vzbid0IHByZXZlbnQgaXQgZnJvbSBiZWluZyBkaWZmZXJlbnQgaW4gZGlm ZmVyZW50IG1lZGlhIHNlY3Rpb25zLiBJdCdzIHRoZSBCVU5ETEUgbmVnb3RpYXRpb24gZHJhZnQg dGhhdCBpbXBvc2VzIHRoZSBjYW5kaWRhdGUgZHVwbGljYXRpb24gcmVxdWlyZW1lbnQsIHdpdGgg YSBjb21iaW5hdGlvbiBvZiB0aGVzZSB0d28gcGFyYWdyYXBoczoNCg0KDQogICBXaGVuIHRoZSBh bnN3ZXJlciBzZWxlY3RzIGEgQlVORExFIGFkZHJlc3MgZm9yIGl0c2VsZiwgcmVmZXJyZWQgdG8g YXMNCg0KICAgdGhlIGFuc3dlcmVyIEJVTkRMRSBhZGRyZXNzLCBpdCBNVVNUIGFzc29jaWF0ZSB0 aGF0IGFkZHJlc3Mgd2l0aCBlYWNoDQoNCiAgIGJ1bmRsZWQgIm09IiBsaW5lIHdpdGhpbiB0aGUg Y3JlYXRlZCBCVU5ETEUgZ3JvdXAgaW4gdGhlIGFuc3dlci4NCg0KICAgV2hlbiBhbiBvZmZlcmVy IG9yIGFuc3dlcmVyIGFzc29jaWF0ZXMgYSBzaGFyZWQgYWRkcmVzcyAoaS5lLiBhDQoNCiAgIHBy ZXZpb3VzbHkgc2VsZWN0ZWQgQlVORExFIGFkZHJlc3MpIHdpdGggb25lIG9yIG1vcmUgYnVuZGxl ZCAibT0iDQoNCiAgIGxpbmVzLCBpdCBNVVNUIGFzc29jaWF0ZSBpZGVudGljYWwgSUNFIGNhbmRp ZGF0ZXMgKHJlZmVycmVkIHRvIGFzDQoNCiAgIHNoYXJlZCBJQ0UgY2FuZGlkYXRlcykgd2l0aCBl YWNoIG9mIHRob3NlICJtPSIgbGluZXMuDQoNCk9uIEZyaSwgSmFuIDE1LCAyMDE2IGF0IDQ6Mjkg QU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNClRoZXJl IGlzIGFsc28gYW5vdGhlciBpc3N1ZToNCg0KU29tZSB0aW1lIGFnbywgUGV0ZXIgVGhhdGNoZXIg YXNrZWQgd2hldGhlciBpdCBpcyByZWFsbHkgbmVlZGVkIHRvIGluY2x1ZGUgdGhlIFNEUCBjYW5k aWRhdGUgYXR0cmlidXRlcyBpbiBhbGwgYnVuZGxlZCBtLSBsaW5lcy4NCg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzE1MzMxLmh0bWwNCg0K TG9va2luZyBhdCBTRFAgYXR0cmlidXRlcyBpbiBnZW5lcmFsLCBJIGd1ZXNzIHRoZSBxdWVzdGlv biBpczogaWYgYW4gYXR0cmlidXRlIGJlbG9uZ3MgdG8gSURFTlRJQ0FMLCBkb2VzIGl0IG5lZWQg dG8gYmUgaW5jbHVkZWQgaW4gYWxsIG0tIGxpbmVzIHdpdGhpbiBhIEJVTkRMRSBncm91cD8NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogU3VoYXMgTmFuZGFrdW1hciBbbWFpbHRvOnN1 aGFzaWV0ZkBnbWFpbC5jb208bWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20+XQ0KU2VudDogMTQu IHRhbW1pa3V1dGEgMjAxNiAyMjo1MQ0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogQm8gQnVy bWFuOyBtbXVzaWMgV0c7IFRheWxvciBCcmFuZHN0ZXR0ZXINCg0KU3ViamVjdDogUmU6IFtNTVVT SUNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMi50 eHQNCg0KVGhhbmtzIENocmlzdGVyIGZvciBicmluZ2luZyB0aGlzIHRvIG91ciBub3RpY2UuIEkg anVzdCByZXNwb25kZWQgdG8gVGF5bG9yJ3MgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbiBhbmQgSSBk b24ndCAgdGhpbmsgdGhlIHJlc3BvbnNlIHRvIGhpcyBxdWVzdGlvbiBjaGFuZ2VzIGFueSBvZiB0 aGUgYmVoYXZpb3IgZm9yIEJVTkRMRSBvciBNVVguDQoNClBsZWFzZSBsZXQgbWUga25vdyB5b3Vy IHRob3VnaHRzIG9uIG15IHJlc3BvbnNlLg0KDQpUaGFua3MNClN1aGFzDQoNCk9uIFRodSwgSmFu IDE0LCAyMDE2IGF0IDEyOjA2IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3 cm90ZToNCkhvbGQgb24gOikNCg0KU29tZSB0aW1lIGFnbyB0aGVyZSB3YXMgYSBxdWVzdGlvbiBm cm9tIFRheWxvciBCcmFuZHN0ZXR0ZXIuIFdhcyB0aGF0IHNvbHZlZD8gVGhlIHRvcGljIG1lbnRp b25lZCBCVU5ETEUsIGJ1dCBJIHRoaW5rIHRoZSBxdWVzdGlvbiB3YXMgYWxzbyByZWxhdGVkIHRv IHRoZSBzZHAtbXV4LWF0dHJpYnV0ZSBkcmFmdC4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzE1NDIxLmh0bWwNCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEJvIEJ1cm1hbg0K U2VudDogMTQgSmFudWFyeSAyMDE2IDE4OjA5DQpUbzogU3VoYXMgTmFuZGFrdW1hciA8c3VoYXNp ZXRmQGdtYWlsLmNvbTxtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbT4+DQpDYzogbW11c2ljIFdH IDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJl OiBbTU1VU0lDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0 ZXMtMTIudHh0DQoNClRoYW5rIHlvdSBTdWhhcywNCg0KSSBiZWxpZXZlIHRoaXMgdmVyc2lvbiBh ZGRyZXNzZXMgYWxsIGNvbW1lbnRzIHByb3ZpZGVkLCBoYXMgbm8gcmVtYWluaW5nIG5pdHMsIGFu ZCBJIHRodXMgaW50ZW5kIHRvIHVzZSBpdCBmb3IgdGhlIHB1YmxpY2F0aW9uIHJlcXVlc3QuDQoN CkNoZWVycywNCi9Cbw0KTU1VU0lDIGNvLWNoYWlyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1t dXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VoYXMgTmFuZGFrdW1hcg0KU2Vu dDogZGVuIDE0IGphbnVhcmkgMjAxNiAxNTozNA0KVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KQ2M6IG1tdXNpYyBXRzsgaS1kLWFu bm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW01NVVNJQ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1 dGVzLTEyLnR4dA0KDQpIZWxsbyBBbGwNCg0KVGhpcyB2ZXJzaW9uIGZpeGVzIGNvdXBsZSBvZiBJ RCBuaXRzIGFuZCB1cGRhdGVzIHRoZSByZWZlcmVuY2VzIHRvIHRoZSBsYXRlc3QgUkZDcy4NCg0K DQpDaGVlcnMNCnN1aGFzDQoNCk9uIFRodSwgSmFuIDE0LCAyMDE2IGF0IDY6MzIgQU0sIDxpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdy b3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbCBXb3JraW5nIEdy b3VwIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgRnJhbWV3b3Jr IGZvciBTRFAgQXR0cmlidXRlcyB3aGVuIE11bHRpcGxleGluZw0KICAgICAgICBBdXRob3IgICAg ICAgICAgOiBTdWhhcyBOYW5kYWt1bWFyDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMi50eHQNCiAgICAgICAgUGFnZXMgICAg ICAgICAgIDogOTYNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNi0wMS0xNA0KDQpBYnN0 cmFjdDoNCiAgIFRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIHByb3ZpZGVz IG1lY2hhbmlzbXMgdG8NCiAgIGRlc2NyaWJlIGF0dHJpYnV0ZXMgb2YgbXVsdGltZWRpYSBzZXNz aW9ucyBhbmQgb2YgaW5kaXZpZHVhbCBtZWRpYQ0KICAgc3RyZWFtcyAoZS5nLiwgUmVhbC10aW1l IFRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBzZXNzaW9ucykgd2l0aGluIGENCiAgIG11bHRpbWVk aWEgc2Vzc2lvbi4gIFR5cGljYWxseSBtZWRpYSBhc3NvY2lhdGVkIHdpdGggaW5kaXZpZHVhbCBt ZWRpYQ0KICAgZGVzY3JpcHRpb25zICgibT0iIGxpbmVzKSByZXByZXNlbnQgUlRQIHNlc3Npb25z IGFuZCBhcmUgdGh1cyBjYXJyaWVkDQogICBvdmVyIGluZGl2aWR1YWwgdW5kZXJseWluZyB0cmFu c3BvcnQgbGF5ZXIgZmxvd3MuICBGb3Igc2NlbmFyaW9zDQogICB3aGVyZSBTRFAgaXMgdXNlZCB0 byBuZWdvdGlhdGUgdGhlIHVzYWdlIG9mIHNpbmdsZSA1LXR1cGxlIGZvcg0KICAgc2VuZGluZyBh bmQgcmVjZWl2aW5nIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBtdWx0aXBsZSBtZWRpYQ0KICAgZGVz Y3JpcHRpb25zLCBpdCBpcyByZXF1aXJlZCB0byB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpYyBpbXBs aWNhdGlvbnMNCiAgIG9mIHRoZSBTRFAgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJU UCBNZWRpYSBTdHJlYW1zDQogICBtdWx0aXBsZXhlZCBvdmVyIGEgc2luZ2xlIHVuZGVybHlpbmcg dHJhbnNwb3J0IGxheWVyIGZsb3cuDQoNCiAgIFRoZSBwdXJwb3NlIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiBpcyB0byBwcm92aWRlIGEgZnJhbWV3b3JrIGZvcg0KICAgYW5hbHl6aW5nIHRoZSBtdWx0 aXBsZXhpbmcgY2hhcmFjdGVyaXN0aWNzIG9mIFNEUCBhdHRyaWJ1dGVzLiAgVGhpcw0KICAgc3Bl Y2lmaWNhdGlvbiBhbHNvIGNhdGVnb3JpemVzIHRoZSBleGlzdGluZyBTRFAgYXR0cmlidXRlcyBi YXNlZCBvbg0KICAgdGhlIGZyYW1ld29yayBkZXNjcmliZWQgaGVyZWluLg0KDQoNClRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVz Lw0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0 ZXMtMTINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLXNk cC1tdXgtYXR0cmlidXRlcy0xMg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8 aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQoN Cg0KDQo= --_000_BBE9739C2C302046BD34B42713A1E2A22E954072ESESSMB105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUt bmFtZTpob2VuemI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gcm9tIHdoYXQgSSBjYW4gdW5kZXJzdGFuZCwgdGhlcmUg c2VlbXMgdG8gYmUgbm8gcmVhc29uIHRvIGNoYW5nZSDigJNtdXgtYXR0cmlidXRlcy0xMiBhdCB0 aGlzIHBvaW50LiBJIGFsc28gc2VlIG5vIG9wcG9zaXRpb24gdG8gU3VoYXPigJkgcHJvcG9zYWwg YmVsb3cgdGhhdCBpZg0KIGEgY2xhcmlmaWNhdGlvbiBpcyBuZWVkZWQsIGl0IHNob3VsZCBnbyBp bnRvIHRoZSBCVU5ETEUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB0aGVyZSBhcmUgbm8gZnVydGhlciBj b21tZW50cywgSSBpbnRlbmQgdG8gcHJvY2VlZCB3aXRoIHRoZSBwdWJsaWNhdGlvbiByZXF1ZXN0 IG9mIOKAk211eC1hdHRyaWJ1dGVzLTEyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L0JvPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1NVVNJQyBjby1jaGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBTdWhhcyBOYW5kYWt1bWFyIFttYWlsdG86c3VoYXNpZXRmQGdtYWls LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMjIgamFudWFyaSAyMDE2IDA1OjM0PGJyPg0K PGI+VG86PC9iPiBUYXlsb3IgQnJhbmRzdGV0dGVyPGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBI b2xtYmVyZzsgQm8gQnVybWFuOyBtbXVzaWMgV0c7IFBldGVyIFRoYXRjaGVyPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAt bXV4LWF0dHJpYnV0ZXMtMTIudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIENocmlzdGVyL0JvL1BldGVyPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgRG8gd2UgdGhpbmsgdGhlIHVu ZGVyc3RhbmRpbmcgb2YgZGVhbGluZyB3aXRoIHRoZSBjYW5kaWRhdGVzIHdoZW4gbXV4aW5nIGlz IGNsZWFyIG9yIGRvZXMgZWl0aGVyIG9mIHRoZSBkcmFmdHMgbmVlZHMgbW9yZSBleHBsYW5hdGlv biBvbiB3aGF0IG5lZWRzIHRvIGJlIGRvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VoYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gMTgsIDIwMTYgYXQgODo0 NSBQTSwgU3VoYXMgTmFuZGFrdW1hciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0ZkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdWhhc2lldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRo IFRheWxvci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBNdXggZHJhZnQgYXNzaWducyBjYXRlZ29yeSAmcXVvdDtUUkFOU1BPUlQmcXVvdDsg dG8gdGhlIElDRSBjYW5kaWRhdGVzLiBTbyB0aGUgY2FuZGlkYXRlIGluZm9ybWF0aW9uIGZyb20g dGhlICZxdW90O209JnF1b3Q7IGxpbmUgd2hpY2ggY29ycmVzcG9uZHMgdG8gdGhlIEJVTkRMRUQg bT1saW5lIHNoYWxsIGJlIGNvbnNpZGVyZWQgZm9yIHRoZSBlbnRpcmUgZ3JvdXAuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGZh ciBhcyBpbXBsZW1lbnRhdGlvbiBpcyBjb25jZXJuZWQsIGkgdGhpbmsgb25lIHNob3VsZCBiZSBm aW5lIGp1c3QgdHJpY2tsaW5nIHRoZSBjYW5kaWRhdGUgaW5mb3JtYXRpb24gZm9yIHRoZSBtPWxp bmUgc2VsZWN0ZWQgZm9yIGEgZ2l2ZW4gQlVORExFIGdyb3VwIGFuZCBubyBuZWVkIHRvIGNvcHkg aXQgZm9yIHRoZSByZXN0IHVubGVzcyB0aGVyZSBpcyBhIGV4cGxpY2l0IG5lZWQgKEluaXRpYWwg b2ZmZXIsDQogcGxhbiB0byBjaGFuZ2UgdGhlIGJ1bmRsZSBncm91cCBhZGRyZXNzLCBkcm9wIGEg bT1saW5lKSAmbmJzcDt0byBpbmNsdWRlIGRpZmZlcmVudCBjYW5kaWRhdGVzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtJIHdvdWxk IHJlY29tbWVuZCB3ZSB1cGRhdGUgdGhlIEJVTkRMRSBkcmFmdCAoaWYgdGhlcmUgaXMgYW55IGNv bmZ1c2lvbikgdG8gbWF0Y2ggdGhlIE1VWCBkcmFmdCB1bmxlc3MgcGVvcGxlIHRoaW5rIG90aGVy d2lzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SG9wZSB0aGlzIGhlbHBzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlN1aGFzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDE1LCAy MDE2IGF0IDg6MjAgQU0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpk ZWFkYmVlZkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZxdW90O2NhbmRpZGF0ZSZxdW90OyBpcyBpbiB0aGUgVFJBTlNQT1JUIGNhdGVnb3J5IHRob3Vn aCwgd2hpY2ggZG9lc24ndCBwcmV2ZW50IGl0IGZyb20gYmVpbmcgZGlmZmVyZW50IGluIGRpZmZl cmVudCBtZWRpYSBzZWN0aW9ucy4gSXQncyB0aGUgQlVORExFIG5lZ290aWF0aW9uIGRyYWZ0IHRo YXQgaW1wb3NlcyB0aGUgY2FuZGlkYXRlIGR1cGxpY2F0aW9uIHJlcXVpcmVtZW50LCB3aXRoIGEg Y29tYmluYXRpb24gb2YgdGhlc2UNCiB0d28gcGFyYWdyYXBoczo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91 bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6 I0ZGRkRGNTtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbTt3b3JkLXdyYXA6YnJlYWstd29yZDtib3Jk ZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFdoZW4gdGhlIGFuc3dlcmVyIHNlbGVjdHMgYSBC VU5ETEUgYWRkcmVzcyBmb3IgaXRzZWxmLCByZWZlcnJlZCB0byBhczxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE RjU7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIGFuc3dlcmVyIEJVTkRMRSBhZGRyZXNzLCBp dCBNVVNUIGFzc29jaWF0ZSB0aGF0IGFkZHJlc3Mgd2l0aCBlYWNoPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG NTtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBidW5kbGVkICZxdW90O209JnF1b3Q7IGxpbmUgd2l0 aGluIHRoZSBjcmVhdGVkIEJVTkRMRSBncm91cCBpbiB0aGUgYW5zd2VyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVu dDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBw dCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFy Z2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7Ym9yZGVyOm5vbmU7cGFkZGluZzow Y207d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBX aGVuIGFuIG9mZmVyZXIgb3IgYW5zd2VyZXIgYXNzb2NpYXRlcyBhIHNoYXJlZCBhZGRyZXNzIChp LmUuIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHByZXZpb3Vz bHkgc2VsZWN0ZWQgQlVORExFIGFkZHJlc3MpIHdpdGggb25lIG9yIG1vcmUgYnVuZGxlZCAmcXVv dDttPSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbGlu ZXMsIGl0IE1VU1QgYXNzb2NpYXRlIGlkZW50aWNhbCBJQ0UgY2FuZGlkYXRlcyAocmVmZXJyZWQg dG8gYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNoYXJlZCBJ Q0UgY2FuZGlkYXRlcykgd2l0aCBlYWNoIG9mIHRob3NlICZxdW90O209JnF1b3Q7IGxpbmVzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDE1LCAyMDE2IGF0IDQ6MjkgQU0sIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDwv c3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGVyZSBpcyBhbHNvIGFub3RoZXIgaXNzdWU6PC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRkki PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvbWUgdGltZSBhZ28sIFBldGVyIFRo YXRjaGVyIGFza2VkIHdoZXRoZXIgaXQgaXMgcmVhbGx5IG5lZWRlZCB0byBpbmNsdWRlIHRoZSBT RFAgY2FuZGlkYXRlIGF0dHJpYnV0ZXMNCiBpbiBhbGwgYnVuZGxlZCBtLSBsaW5lcy48L3NwYW4+ PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50 L21zZzE1MzMxLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNnMTUzMzEuaHRtbDwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TG9va2luZyBh dCBTRFAgYXR0cmlidXRlcyBpbiBnZW5lcmFsLCBJIGd1ZXNzIHRoZSBxdWVzdGlvbiBpczogaWYg YW4gYXR0cmlidXRlIGJlbG9uZ3MgdG8gSURFTlRJQ0FMLA0KIGRvZXMgaXQgbmVlZCB0byBiZSBp bmNsdWRlZCBpbiBhbGwgbS0gbGluZXMgd2l0aGluIGEgQlVORExFIGdyb3VwPzwvc3Bhbj48c3Bh biBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRz LDwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaHJpc3Rlcjwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdWhhcyBO YW5kYWt1bWFyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5zdWhhc2lldGZAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiAxNC4gdGFtbWlrdXV0YSAyMDE2IDIyOjUxPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xt YmVyZzxicj4NCjxiPkNjOjwvYj4gQm8gQnVybWFuOyBtbXVzaWMgV0c7IFRheWxvciBCcmFuZHN0 ZXR0ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2Rw LW11eC1hdHRyaWJ1dGVzLTEyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkki PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZJIj5UaGFua3MgQ2hyaXN0ZXIgZm9yIGJyaW5naW5nIHRoaXMgdG8g b3VyIG5vdGljZS4gSSBqdXN0IHJlc3BvbmRlZCB0byBUYXlsb3IncyBjbGFyaWZpY2F0aW9uIHF1 ZXN0aW9uIGFuZCBJIGRvbid0ICZuYnNwO3RoaW5rIHRoZSByZXNwb25zZSB0byBoaXMgcXVlc3Rp b24gY2hhbmdlcyBhbnkNCiBvZiB0aGUgYmVoYXZpb3IgZm9yIEJVTkRMRSBvciBNVVguPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRkkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPlBsZWFzZSBsZXQgbWUga25vdyB5b3Vy IHRob3VnaHRzIG9uIG15IHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRkkiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPlN1aGFzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+T24gVGh1LCBKYW4gMTQsIDIw MTYgYXQgMTI6MDYgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9sZCBvbiA6KTwvc3Bhbj48c3Bh biBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvbWUgdGltZSBhZ28gdGhlcmUgd2FzIGEgcXVlc3Rpb24gZnJv bSBUYXlsb3IgQnJhbmRzdGV0dGVyLiBXYXMgdGhhdCBzb2x2ZWQ/IFRoZSB0b3BpYw0KIG1lbnRp b25lZCBCVU5ETEUsIGJ1dCBJIHRoaW5rIHRoZSBxdWVzdGlvbiB3YXMgYWxzbyByZWxhdGVkIHRv IHRoZSBzZHAtbXV4LWF0dHJpYnV0ZSBkcmFmdC48L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbW11c2ljL2N1 cnJlbnQvbXNnMTU0MjEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9tbXVzaWMvY3VycmVudC9tc2cxNTQyMS5odG1sPC9hPjwvc3Bhbj48 c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0iLTExNDk4NTUxMDdfNjg1MTc0MTI4Xy02 NjQ0NjYyMThfNzI2NTc0OSI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtbXVzaWMgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVz aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJvIEJ1cm1hbjxi cj4NCjxiPlNlbnQ6PC9iPiAxNCBKYW51YXJ5IDIwMTYgMTg6MDk8YnI+DQo8Yj5Ubzo8L2I+IFN1 aGFzIE5hbmRha3VtYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+c3VoYXNpZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBtbXVzaWMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMi50eHQ8L3Nw YW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSBTdWhhcyw8L3NwYW4+PHNwYW4gbGFuZz0i RkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHRoaXMg dmVyc2lvbiBhZGRyZXNzZXMgYWxsIGNvbW1lbnRzIHByb3ZpZGVkLCBoYXMgbm8gcmVtYWluaW5n IG5pdHMsIGFuZCBJIHRodXMgaW50ZW5kDQogdG8gdXNlIGl0IGZvciB0aGUgcHVibGljYXRpb24g cmVxdWVzdC48L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Q2hlZXJzLDwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+L0JvPC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5NTVVTSUMgY28tY2hhaXI8L3NwYW4+PHNwYW4gbGFuZz0iRkki PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBtbXVzaWMgWzxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN1aGFzIE5hbmRha3VtYXI8YnI+DQo8Yj5TZW50Ojwv Yj4gZGVuIDE0IGphbnVhcmkgMjAxNiAxNTozNDxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IG1tdXNpYyBXRzsgPGEgaHJlZj0ibWFp bHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0xMi50eHQ8L3NwYW4+PHNwYW4g bGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVsbG8gQWxsPHNwYW4g bGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHZlcnNpb24gZml4ZXMgY291 cGxlIG9mIElEIG5pdHMgYW5kIHVwZGF0ZXMgdGhlIHJlZmVyZW5jZXMgdG8gdGhlIGxhdGVzdCBS RkNzLjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBs YW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5DaGVlcnM8c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdWhhczxzcGFuIGxhbmc9 IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSmFuIDE0LCAyMDE2 IGF0IDY6MzIgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDsgd3JvdGU6 PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZuYnNwO1RoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE11bHRpcGFydHkgTXVsdGltZWRpYSBTZXNzaW9uIENvbnRy b2wgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzogQSBGcmFtZXdvcmsgZm9yIFNEUCBBdHRyaWJ1dGVzIHdoZW4gTXVsdGlwbGV4aW5nPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgOiBTdWhhcyBOYW5kYWt1bWFyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEyLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiA5 Njxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE2LTAxLTE0PGJyPg0KPGJyPg0KQWJzdHJhY3Q6 PGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFAp IHByb3ZpZGVzIG1lY2hhbmlzbXMgdG88YnI+DQombmJzcDsgJm5ic3A7ZGVzY3JpYmUgYXR0cmli dXRlcyBvZiBtdWx0aW1lZGlhIHNlc3Npb25zIGFuZCBvZiBpbmRpdmlkdWFsIG1lZGlhPGJyPg0K Jm5ic3A7ICZuYnNwO3N0cmVhbXMgKGUuZy4sIFJlYWwtdGltZSBUcmFuc3BvcnQgUHJvdG9jb2wg KFJUUCkgc2Vzc2lvbnMpIHdpdGhpbiBhPGJyPg0KJm5ic3A7ICZuYnNwO211bHRpbWVkaWEgc2Vz c2lvbi4mbmJzcDsgVHlwaWNhbGx5IG1lZGlhIGFzc29jaWF0ZWQgd2l0aCBpbmRpdmlkdWFsIG1l ZGlhPGJyPg0KJm5ic3A7ICZuYnNwO2Rlc2NyaXB0aW9ucyAoJnF1b3Q7bT0mcXVvdDsgbGluZXMp IHJlcHJlc2VudCBSVFAgc2Vzc2lvbnMgYW5kIGFyZSB0aHVzIGNhcnJpZWQ8YnI+DQombmJzcDsg Jm5ic3A7b3ZlciBpbmRpdmlkdWFsIHVuZGVybHlpbmcgdHJhbnNwb3J0IGxheWVyIGZsb3dzLiZu YnNwOyBGb3Igc2NlbmFyaW9zPGJyPg0KJm5ic3A7ICZuYnNwO3doZXJlIFNEUCBpcyB1c2VkIHRv IG5lZ290aWF0ZSB0aGUgdXNhZ2Ugb2Ygc2luZ2xlIDUtdHVwbGUgZm9yPGJyPg0KJm5ic3A7ICZu YnNwO3NlbmRpbmcgYW5kIHJlY2VpdmluZyBtZWRpYSBhc3NvY2lhdGVkIHdpdGggbXVsdGlwbGUg bWVkaWE8YnI+DQombmJzcDsgJm5ic3A7ZGVzY3JpcHRpb25zLCBpdCBpcyByZXF1aXJlZCB0byB1 bmRlcnN0YW5kIHRoZSBzZW1hbnRpYyBpbXBsaWNhdGlvbnM8YnI+DQombmJzcDsgJm5ic3A7b2Yg dGhlIFNEUCBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgUlRQIE1lZGlhIFN0cmVhbXM8 YnI+DQombmJzcDsgJm5ic3A7bXVsdGlwbGV4ZWQgb3ZlciBhIHNpbmdsZSB1bmRlcmx5aW5nIHRy YW5zcG9ydCBsYXllciBmbG93Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgcHVycG9zZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24gaXMgdG8gcHJvdmlkZSBhIGZyYW1ld29yayBmb3I8YnI+DQom bmJzcDsgJm5ic3A7YW5hbHl6aW5nIHRoZSBtdWx0aXBsZXhpbmcgY2hhcmFjdGVyaXN0aWNzIG9m IFNEUCBhdHRyaWJ1dGVzLiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRp b24gYWxzbyBjYXRlZ29yaXplcyB0aGUgZXhpc3RpbmcgU0RQIGF0dHJpYnV0ZXMgYmFzZWQgb248 YnI+DQombmJzcDsgJm5ic3A7dGhlIGZyYW1ld29yayBkZXNjcmliZWQgaGVyZWluLjxicj4NCjxi cj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0 IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJp YnV0ZXMvPC9hPjxicj4NCjxicj4NClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMTIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1 dGVzLTEyPC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTEyIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2lj LXNkcC1tdXgtYXR0cmlidXRlcy0xMjwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0iZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWM8L2E+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGSSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkZJIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BBE9739C2C302046BD34B42713A1E2A22E954072ESESSMB105erics_-- From nobody Thu Jan 28 13:58:29 2016 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 C92691A910F; Thu, 28 Jan 2016 13:58:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128215827.1402.21935.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 13:58:27 -0800 Archived-At: Cc: mmusic-chairs@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Ben Campbell's Yes on charter-ietf-mmusic-03-00: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:58:28 -0000 Ben Campbell has entered the following ballot position for charter-ietf-mmusic-03-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-mmusic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a a recharter to deal with the restructuring of ICE work into a dedicated working group, and to update some bits that have been overtaken by events. I propose that it does not need an external review. From nobody Thu Jan 28 18:19:43 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58CE1B370E for ; Thu, 28 Jan 2016 18:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aWo7gvFnn-h for ; Thu, 28 Jan 2016 18:19:38 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E673A1B3704 for ; Thu, 28 Jan 2016 18:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17872; q=dns/txt; s=iport; t=1454033977; x=1455243577; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=9o17MvaPtYuNl4YbAqnxEzvBEni6roIb+NVtkIhWppU=; b=NPz/Jg/Kc1o2JJP0jGNj2iXE9ac3Fl2SJQB878IaIKtCHsclSUZzuTQL vV04IlQ7UZ8F/LtKSZWTQf/S5W4k6LQ6b1o/clAesnccf+YsgfaJue/rG WDqqB/GRACLiTt4vVDN6iUdS0CgIXOAe8pxWpmXXp9RdOyhgiRDCoVz+u Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBzy6pW/4sNJK1UCg6DKVJtiFixR?= =?us-ascii?q?AENgWIYCoUjSgKBSDgUAQEBAQEBAYEKhEEBAQEEAQEBGhsvBAECBAQCDQQLDgM?= =?us-ascii?q?EAQEBCRYIBwkDAgECARUfCQgGAQkDBgIBAYgXDsAFAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBEQSGDYM8e4QIBIRgBY4YiFaIM4UYgVuEQoMCI4QVgRqFboR+g1EeAQF?= =?us-ascii?q?Cgy9ZHi6HRIE5AQEB?= X-IronPort-AV: E=Sophos;i="5.22,361,1449532800"; d="scan'208";a="68038286" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jan 2016 02:19:36 +0000 Received: from [10.155.86.217] ([10.155.86.217]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0T2JZp9001604; Fri, 29 Jan 2016 02:19:36 GMT To: Paul Kyzivat , mmusic@ietf.org References: <565C6CE3.3050007@alum.mit.edu> <565CDF90.7050107@nteczone.com> <565CEA14.2040607@alum.mit.edu> <565CEF7B.7010305@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE16A00@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56682B96.9020008@alcatel-lucent.com> <56684C13.9030106@alum.mit.edu> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> From: Flemming Andreasen Message-ID: <56AACC37.8090900@cisco.com> Date: Thu, 28 Jan 2016 21:19:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <566AEB05.3040501@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 02:19:41 -0000 Apologies for joining in late here, but I would like to go back to the beginning of this thread to understand better why we believe there is a need for attributes to specifically define whether they can be used with the "dcsa" attribute. The way I see it, the "dcsa" attribute is simply an encapsulating attribute that specifies attributes for the data channel sub-protocol. What I believe we need here is a set of clear procedures that explain how you take those encapsulated procedures, "decapsulate" them and negotiate based on the resulting set of parameters (which may need to include a few parameters from the media description containing them). This is similar to the approach we took with SDP Capability Negotiation (RFC 5939). It has the benefit of specifying a generic algorithm for dealing with these, and above and beyond that, it's up to the entity generating the SDP to include a set of parameters that make sense for the given sub-protocol. This is similar to what we do with normal SDP (i.e. don't specify all the valid combinations) and avoids the rather painful approach that we have with mux-attributes. Thanks -- Flemming On 12/11/15 10:25 AM, Paul Kyzivat wrote: > On 12/10/15 7:25 PM, DRAGE, Keith (Keith) wrote: >> I agree with Christian. >> >> But Paul and myself have had this discussion before. He seems >> convinced we can essentially put stuff in the IANA registry that >> needs to be in an RFC. > > Keith - yes, we continue to disagree. But not for the reason you say. > I do not, and have never, proposed that things be put into the > registry *instead* of into a document. > > But I do believe that registries are important as an index/discovery > tool. You cannot expect people to be aware of every pertinent RFC that > may have been published that pertains to something of interest. If I > have an interop problem with a new peer, and see something being used > that I am not familiar with, then I need a way discover the specs that > might pertain to that. The IANA registries serve that function. > > (There are *some* cases where the registries are more important. When > there is something where the bar for extension is low, and no public > document is required, then the registry becomes only public place to > learn about it.) > >> It is probably worth others (such as the WG chairs) weighing on this >> discussion. > > Agreed. > > Thanks, > Paul > >> Keith >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: 11 December 2015 00:21 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg >> >> Hello Paul, >> >> On 10/12/2015 3:47 PM, Paul Kyzivat wrote: >>> On 12/9/15 11:04 PM, Christian Groves wrote: >>>> Hello Juergen and Paul, >>>> >>>> The proposed text by Juergen is OK. >>>> >>>> Paul: Is an IANA registry the right place to capture the nuances of >>>> what you're describing below? I agree that when people are defining >>>> new attributes that they should consider their use with data >>>> channels, but shouldn't that be documented in an RFC rather than >>>> the IANA registry? >>>> People need to read the RFC rather than simply relying on the >>>> registry. >>> >>> It shouldn't *only* be in the IANA registry. The registry serves as an >>> index getting you to the right place, and helping you figure out what >>> you need to read. >> [CNG] This is what I was getting at. It not just a registry update >> we're talking about there's a much more significant document >> explaining the use of the attributes with dcsa. >>> >>> Won't it be confusing if the registry covers usage of attributes a >>> session, media, and source level but doesn't cover their use in dcsa? >> [CNG] The registry is a short cut. Even if the registry mentions that >> its a source attribute, a person still needs to read the RFC to see >> how it works. I see that people want to use an attribute for its >> functionality not because of what the IANA reg says. >>> >>> If this isn't needed for dcsa, then by the same logic we ought to >>> strip out that other information, and reduce the table to contain only >>> references to documents. >>> >>>> Also isn't the consequence of what you're suggesting is that another >>>> draft similar to draft-ietf-mmusic-sdp-mux-attributes would have to >>>> be completed in order to populate the IANA registry field that you're >>>> proposing? >>> >>> Perhaps. We'd have to discuss the best way. It may be that most of the >>> existing attributes can be covered with a couple of default rules, and >>> maybe a few exceptions. >> [CNG] Still the analysis of each attribute would need to be done and >> documented to get to the few rules. I not completely against doing >> this, I'm just keen to get this work finished and this will just >> delay things. >> >> Regards, Christian >> >>> >>> Thanks, >>> Paul >>> >>>> Regards, Christian >>>> >>>> On 10/12/2015 2:43 AM, Paul Kyzivat wrote: >>>>> Juergen and others, >>>>> >>>>> What you have below is a good start. >>>>> >>>>> I still think we need to at least specify how dcsa impacts IANA >>>>> registration of attributes. >>>>> >>>>> The attribute registration is (going to be) updated so that there is >>>>> one table containing all attributes, with fields indicating for each >>>>> attribute whether it can be used at session level, media level, or >>>>> source level. >>>>> >>>>> Now consider an attribute usable at media and/or source level: >>>>> >>>>> It *might* *also* be usable with dcsa, or it might not. That will at >>>>> least in part be determined by whether the protocol that it applies >>>>> to can run over a data channel. >>>>> >>>>> There was a suggestion (Keith?) that media level attributes be >>>>> implicitly allowed with dcsa if the protocol they apply to is >>>>> defined over a data channel. I find that plausible. But then the >>>>> instructions for registration ought to say that. Also, if there can >>>>> be exceptions (attributes that *can't* be used with dcsa even when >>>>> the protocol is defined over data channel) then there should be a >>>>> way to register that. >>>>> >>>>> Source level attributes add another complication. They only apply >>>>> over RTP. For now, RTP isn't defined over a data channel. (Though in >>>>> principle it *could* be.) If it were, then I suppose the ussage >>>>> would have to be 'a=dcsa nn source ...'. I don't think we need to >>>>> deal with that right now. >>>>> >>>>> And then there is the possibility of new attributes being defined >>>>> that can be used *only* with dcsa, not directly at media level: >>>>> >>>>> If this is because the protocol is only defined to run over a data >>>>> channel, then it could possibly be registered as a media level >>>>> attribute (which is then allowed by default with dcsa). If the >>>>> protocol were ever defined over another transport the sdp would be >>>>> ready for it. >>>>> >>>>> But if, for some reason, the protocol can run over a data channel >>>>> and also over some other transport, but for some reason a particular >>>>> attribute only applies with data channels, or only applies without >>>>> data channels, then there ought to be a way to record that in the >>>>> registry. >>>>> >>>>> The worst case is for every spec that defines an attribute to pick >>>>> its own way to specify all this, and for there to be no hint in the >>>>> iana registry. >>>>> >>>>> IMO it is still better for the iana registry to be given another >>>>> field to indicate applicability with data channels. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 12/9/15 8:24 AM, Juergen Stoetzer-Bradler wrote: >>>>>> Paul, Christian, Keith, >>>>>> >>>>>> Would propose to add following two new paragraphs to the end of >>>>>> current section 5.1.2.1 (dcsa Attribute) in order to more clearly >>>>>> describe the relationship of a subprotocol's attribute and the >>>>>> subprotocol's transport protocol, especially data channel. >>>>>> >>>>>> >>>>>> It is assumed that in general the usages of subprotocol related >>>>>> media >>>>>> level attributes are independent from the subprotocol's >>>>>> transport >>>>>> protocol. Such transport protocol independent subprotocol >>>>>> related >>>>>> attributes are used in the same way as defined in the original >>>>>> subprotocol specification, also if the subprotocol is >>>>>> transported >>>>>> over a data channel and if the attribute is correspondingly >>>>>> embedded >>>>>> in a "a=dcsa" attribute. >>>>>> >>>>>> There may be cases, where the usage of a subprotocol related >>>>>> media >>>>>> level attribute depends on the subprotocol's transport >>>>>> protocol. In >>>>>> such cases the subprotocol related usage of the attribute is >>>>>> expected >>>>>> to be described for the data channel transport, e.g. in an >>>>>> extension >>>>>> of the original subprotocol specification. >>>>>> >>>>>> >>>>>> Section 5.1.2 already explicitly mentions that (subprotocol >>>>>> related) media level attributes may follow a data channel >>>>>> declaration (the a=dcmap line). Thus the restriction to subprotocol >>>>>> related media level attributes only seems to be covered already. >>>>>> >>>>>> Thanks, >>>>>> Juergen >>>>>> >>>>>> >>>>>> On 01.12.2015 02:12, DRAGE, Keith (Keith) wrote: >>>>>>> I think we need to be a little bit careful here. >>>>>>> >>>>>>> In a large number of cases, the use of the attribute will be >>>>>>> unaltered by the transport that is being used, and I do not think >>>>>>> we should have a need of saying anything if this is the case - it >>>>>>> should be the default. >>>>>>> >>>>>>> So for example for MSRP, there are a number of attributes >>>>>>> associated with MSRP - for file transfer and so on, and as far as >>>>>>> I can tell, they are used when MSRP is sent over a data channel in >>>>>>> exactly the same way as when MSRP is sent over TCP or SCTP. We >>>>>>> don't write special rules for TCP, so why write special rules for >>>>>>> datachannel. >>>>>>> >>>>>>> We do need to identify how we document any special cases, and yes >>>>>>> when we find them, drafts like the msrp draft are the way to do >>>>>>> that. >>>>>>> >>>>>>> Additionally, if we find when defining a new attribute, that it is >>>>>>> inappropriate for datachannel usage in some way, then we can write >>>>>>> that in the defining specification for the new attribute (although >>>>>>> I suspect in this case it will be inappropriate to other >>>>>>> transports than just datachannel). >>>>>>> >>>>>>> I do assume this entire discussion is limited to attributes that >>>>>>> can be applied to media lines. We might find it useful to say that >>>>>>> in the general draft, if we have not done so already. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of >>>>>>> Christian Groves >>>>>>> Sent: 01 December 2015 00:53 >>>>>>> To: mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] WGLC for >>>>>>> draft-ietf-mmusic-data-channel-sdpneg >>>>>>> >>>>>>> Hello Paul, >>>>>>> >>>>>>> I actually meant to post the reply to the list, sorry for the >>>>>>> confusion. >>>>>>> >>>>>>> I do understand your concerns. For multiplexing it makes sense to >>>>>>> check all the existing attributes to see whether they're >>>>>>> applicable due to the fact that quite alot may be used when >>>>>>> multiplexing occurs. >>>>>>> I think the data channel usage is quite a bit more narrow in scope. >>>>>>> >>>>>>> Whilst this draft does introduce a general purpose mechanism the >>>>>>> actual use of the dcsa is being defined by other drafts. E.g. >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what >>>>>>> happens when both a=setup and a=dcsa:setup are present. msrp-cema >>>>>>> is another one discussed, etc. >>>>>>> >>>>>>> I think you need to understand the application protocol being >>>>>>> carried in a data channel before you can say whether particular >>>>>>> attributes should be carried in dcsa and what that actually means. >>>>>>> Going through the IANA registry wouldn't be trivial and unless the >>>>>>> attributes are put in context of an application protocol I don't >>>>>>> think it will be terribly helpful. >>>>>>> >>>>>>> draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate >>>>>>> that the dsca parameters follow the procedures defined in the >>>>>>> subprotocol specific documents. Maybe we could strengthen this to >>>>>>> indicate that the use of dsca by an application protocol should be >>>>>>> documented in a specification? >>>>>>> >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 1/12/2015 11:30 AM, Paul Kyzivat wrote: >>>>>>>> Christian, >>>>>>>> >>>>>>>> On 11/30/15 6:45 PM, Christian Groves wrote: >>>>>>>>> Is this level of detail really needed? There are several drafts >>>>>>>>> for CLUE, MSRP and BFCP related to the use of this sdpneg >>>>>>>>> mechanism. >>>>>>>>> E.g. >>>>>>>>> CLUE doesn't use dcsa and MSRP provides guidelines on the use of >>>>>>>>> dcsa. >>>>>>>>> >>>>>>>>> Can't we just follow the principle that the use of the dcsa >>>>>>>>> attribute should be detailed in a specification and leave it at >>>>>>>>> that? I'm not sure what we gain by analysing every existing >>>>>>>>> attribute and forcing every new attribute to do this analyses >>>>>>>>> when the set of possible parameters in likely to be very small. >>>>>>>> I guess it is arguable both ways. Originally there was only >>>>>>>> session level and media level. That was always supposed to be >>>>>>>> identified, but it wasn't always followed. >>>>>>>> >>>>>>>> Then we got source level. That has complicated the registry and >>>>>>>> the usage. I am not convinced that two SDP experts would come up >>>>>>>> with the same list of which attributes can be used at source >>>>>>>> level. >>>>>>>> >>>>>>>> The dcsa attribute becomes the 4th "level" for attributes. It at >>>>>>>> least makes sense to me that it ought to be managed analogously >>>>>>>> to the source attribute. But I agree it doesn't provide the same >>>>>>>> degree of confusion as the others. It only makes sense if the >>>>>>>> usage the attribute applies to works over a data channel. And >>>>>>>> that should be known to whatever is processing the SDP. >>>>>>>> >>>>>>>> I see this was a private message. Why don't you repost it on the >>>>>>>> list and lets see what other people think? (Feel free to repost >>>>>>>> this reply if you wish.) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 1/12/2015 2:36 AM, Paul Kyzivat wrote: >>>>>>>>>> One thing occurred to me that we may have forgotten about: >>>>>>>>>> >>>>>>>>>> This draft introduces the dcsa attribute, which allows other >>>>>>>>>> attributes to be used in this new scope. It notes that not all >>>>>>>>>> attributes are suitable for use this way. >>>>>>>>>> >>>>>>>>>> ISTM that in the future other attribute definitions should >>>>>>>>>> include an indication of whether they can be used with dcsa, >>>>>>>>>> and the IANA registration of the attribute ought to include >>>>>>>>>> this. And then there is a need to update the iana registry for >>>>>>>>>> all the existing attributes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On 11/25/15 4:52 AM, Bo Burman wrote: >>>>>>>>>>> This is to announce a 4 week Working Group Last Call for >>>>>>>>>>> >>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg-06 >>>>>>>>>>> >>>>>>>>>>> as proposed standard. >>>>>>>>>>> >>>>>>>>>>> Please review and provide any comments you may have on the >>>>>>>>>>> document by Wednesday, December 23, 2015. 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. >>>>>>>>>>> >>>>>>>>>>> Please also forward this WGLC call to any other interested >>>>>>>>>>> parties who may be able to review the draft, asking them to >>>>>>>>>>> also direct their comments to the authors and the list as >>>>>>>>>>> above. >>>>>>>>>>> >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> Bo Burman (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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 Thu Jan 28 18:29:51 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588141B3725 for ; Thu, 28 Jan 2016 18:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gBFfHgEHHpT for ; Thu, 28 Jan 2016 18:29:46 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CCD81B3722 for ; Thu, 28 Jan 2016 18:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6235; q=dns/txt; s=iport; t=1454034586; x=1455244186; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=bdrwfeG+uINYuBpERfV2V/PZWnt9r0JHDsFafr8x8Co=; b=LPuwcbZMK/k7Nh5hwb5a1aBFbOZgv/Soh8/n8uSSyZBdkrJ3Y8cRpPl/ jotM3TZf7ijTCTNLLH4BMWZfMIEJcPwEtf01EmGGpb6S6kMIygN9Z2acV qJzNQ5lxbgAB2SKs0pB5b6WmxIp8IPct1ngqZfiXTlrMK1la5HJ5w8iB/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDwzapW/4cNJK1egzdSbYhYsUUBD?= =?us-ascii?q?YFiGAEJhSNKAoE+OBQBAQEBAQEBgQqEQQEBAQQBAQFrChEcAwECChYPCQMCAQI?= =?us-ascii?q?BFSYCCAYNBgIBAYgXDsAEAQEBAQEBAQEBAQEBAQEBAQEBAQEWhg2EN4RShBoFj?= =?us-ascii?q?hiIVoVHiASBW0qDeIMChVKOPR4BAUKECB4uiH0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,361,1449532800"; d="scan'208,217";a="230818471" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jan 2016 02:29:45 +0000 Received: from [10.155.86.217] ([10.155.86.217]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0T2Tj67012909 for ; Fri, 29 Jan 2016 02:29:45 GMT References: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> To: mmusic From: Flemming Andreasen X-Forwarded-Message-Id: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> Message-ID: <56AACE99.5060905@cisco.com> Date: Thu, 28 Jan 2016 21:29:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090903030607070705040007" Archived-At: Subject: [MMUSIC] Fwd: I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 02:29:48 -0000 This is a multi-part message in MIME format. --------------090903030607070705040007 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Greetings MMUSIC We would like to start moving towards WGLC on this draft - do people believe the draft is ready for that at this point ? If not, please let us know which issues you see. Thanks -- Flemming (as MMUSIC chair) -------- Forwarded Message -------- Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt Date: Mon, 18 Jan 2016 09:30:11 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mmusic@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-05.txt Pages : 21 Date : 2016-01-18 Abstract: This draft defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The draft also defines the criteria for when a new DTLS association must be established. This draft defines a new SDP media-level attribute, 'dtls- connection'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic . --------------090903030607070705040007 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Greetings MMUSIC

We would like to start moving towards WGLC on this draft - do people believe the draft is ready for that at this point ? If not, please let us know which issues you see.

Thanks

-- Flemming (as MMUSIC chair)




-------- Forwarded Message --------
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt
Date: Mon, 18 Jan 2016 09:30:11 -0800
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: mmusic@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : Using the SDP Offer/Answer Mechanism for DTLS
        Authors         : Christer Holmberg
                          Roman Shpount
	Filename        : draft-ietf-mmusic-dtls-sdp-05.txt
	Pages           : 21
	Date            : 2016-01-18

Abstract:
   This draft defines the SDP offer/answer procedures for negotiating
   and establishing a DTLS association.  The draft also defines the
   criteria for when a new DTLS association must be established.

   This draft defines a new SDP media-level attribute, 'dtls-
   connection'.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-05


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


--------------090903030607070705040007-- From nobody Fri Jan 29 07:30:38 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B5F1ACEE4 for ; Fri, 29 Jan 2016 07:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o_rDZIxRxCN for ; Fri, 29 Jan 2016 07:30:32 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82EF41ACEE9 for ; Fri, 29 Jan 2016 07:30:32 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-04v.sys.comcast.net with comcast id BrWD1s00B2Qkjl901rWXxz; Fri, 29 Jan 2016 15:30:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id BrWX1s0063KdFy101rWXZl; Fri, 29 Jan 2016 15:30:31 +0000 To: Flemming Andreasen , mmusic@ietf.org References: <565C6CE3.3050007@alum.mit.edu> <565CDF90.7050107@nteczone.com> <565CEA14.2040607@alum.mit.edu> <565CEF7B.7010305@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE16A00@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56682B96.9020008@alcatel-lucent.com> <56684C13.9030106@alum.mit.edu> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> From: Paul Kyzivat Message-ID: <56AB8596.9090304@alum.mit.edu> Date: Fri, 29 Jan 2016 10:30:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AACC37.8090900@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1454081431; bh=NR2yvGfktK3Zql246FpFNw9dohU47IUmaIeysPiU8xE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=sHv2GCJ/gCRMvipEpEvdcg/f3BvcTu4iKbMxfoUDmM80t4sLbst2EjSDQW+L6/Zot ryoG4HyqybyTVtf2SozsgZL1JVmXoQRs0BijUQjdDSnqdcdklP7fG5V8VvTc4ZYK5p +Oo+6+6HgRqNpA72hFxpVb6IqCcE3HYbZDCJPwAeDOzwdsD/vg1qMbel+eabt1c/yk X3sMHoeaKnBWG/7h3kfzF+2lqmsqs8V00PGjmhRsE5mdCLzcWCC37SXMToy/ZQi+HH Mfz71GIZECzf5ylOqqvQrG53sNs7u2iL9+2CQuNUgxATaHQzKh+LIFojCzH9qqiAdr 6miv8ddk/SNyg== Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:30:36 -0000 Flemming, On 1/28/16 9:19 PM, Flemming Andreasen wrote: > Apologies for joining in late here, but I would like to go back to the > beginning of this thread to understand better why we believe there is a > need for attributes to specifically define whether they can be used with > the "dcsa" attribute. > > The way I see it, the "dcsa" attribute is simply an encapsulating > attribute that specifies attributes for the data channel sub-protocol. > What I believe we need here is a set of clear procedures that explain > how you take those encapsulated procedures, "decapsulate" them and > negotiate based on the resulting set of parameters (which may need to > include a few parameters from the media description containing them). > This is similar to the approach we took with SDP Capability Negotiation > (RFC 5939). It has the benefit of specifying a generic algorithm for > dealing with these, and above and beyond that, it's up to the entity > generating the SDP to include a set of parameters that make sense for > the given sub-protocol. This is similar to what we do with normal SDP > (i.e. don't specify all the valid combinations) and avoids the rather > painful approach that we have with mux-attributes. Originally there were two distinct scopes in which attributes could appear: session level and media level. Each attribute needs to specify at which of those levels it is valid, and the semantics in each scope. IANA registries were defined for the attributes and identify which scope(s) are applicable to each. Later we added source level attributes as another scope. And IANA was extended to record that scope as well. The introduction of dcsa clearly adds another scope, at least as distinct as source level. If it is important to put scope in the registry, then this one belongs there as much as any other. We *could* rethink this, and reduce the information put in IANA for attributes. It would be sufficient for the IANA registry to give the attribute name, and a reference to the document where it is defined. (As long as we are assured that the information is present in the referenced document. It may be that this is not the case for some older attributes.) But we should be consistent about this. Thanks, Paul > Thanks > > -- Flemming > > > > On 12/11/15 10:25 AM, Paul Kyzivat wrote: >> On 12/10/15 7:25 PM, DRAGE, Keith (Keith) wrote: >>> I agree with Christian. >>> >>> But Paul and myself have had this discussion before. He seems >>> convinced we can essentially put stuff in the IANA registry that >>> needs to be in an RFC. >> >> Keith - yes, we continue to disagree. But not for the reason you say. >> I do not, and have never, proposed that things be put into the >> registry *instead* of into a document. >> >> But I do believe that registries are important as an index/discovery >> tool. You cannot expect people to be aware of every pertinent RFC that >> may have been published that pertains to something of interest. If I >> have an interop problem with a new peer, and see something being used >> that I am not familiar with, then I need a way discover the specs that >> might pertain to that. The IANA registries serve that function. >> >> (There are *some* cases where the registries are more important. When >> there is something where the bar for extension is low, and no public >> document is required, then the registry becomes only public place to >> learn about it.) >> >>> It is probably worth others (such as the WG chairs) weighing on this >>> discussion. >> >> Agreed. >> >> Thanks, >> Paul >> >>> Keith >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 11 December 2015 00:21 >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg >>> >>> Hello Paul, >>> >>> On 10/12/2015 3:47 PM, Paul Kyzivat wrote: >>>> On 12/9/15 11:04 PM, Christian Groves wrote: >>>>> Hello Juergen and Paul, >>>>> >>>>> The proposed text by Juergen is OK. >>>>> >>>>> Paul: Is an IANA registry the right place to capture the nuances of >>>>> what you're describing below? I agree that when people are defining >>>>> new attributes that they should consider their use with data >>>>> channels, but shouldn't that be documented in an RFC rather than >>>>> the IANA registry? >>>>> People need to read the RFC rather than simply relying on the >>>>> registry. >>>> >>>> It shouldn't *only* be in the IANA registry. The registry serves as an >>>> index getting you to the right place, and helping you figure out what >>>> you need to read. >>> [CNG] This is what I was getting at. It not just a registry update >>> we're talking about there's a much more significant document >>> explaining the use of the attributes with dcsa. >>>> >>>> Won't it be confusing if the registry covers usage of attributes a >>>> session, media, and source level but doesn't cover their use in dcsa? >>> [CNG] The registry is a short cut. Even if the registry mentions that >>> its a source attribute, a person still needs to read the RFC to see >>> how it works. I see that people want to use an attribute for its >>> functionality not because of what the IANA reg says. >>>> >>>> If this isn't needed for dcsa, then by the same logic we ought to >>>> strip out that other information, and reduce the table to contain only >>>> references to documents. >>>> >>>>> Also isn't the consequence of what you're suggesting is that another >>>>> draft similar to draft-ietf-mmusic-sdp-mux-attributes would have to >>>>> be completed in order to populate the IANA registry field that you're >>>>> proposing? >>>> >>>> Perhaps. We'd have to discuss the best way. It may be that most of the >>>> existing attributes can be covered with a couple of default rules, and >>>> maybe a few exceptions. >>> [CNG] Still the analysis of each attribute would need to be done and >>> documented to get to the few rules. I not completely against doing >>> this, I'm just keen to get this work finished and this will just >>> delay things. >>> >>> Regards, Christian >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, Christian >>>>> >>>>> On 10/12/2015 2:43 AM, Paul Kyzivat wrote: >>>>>> Juergen and others, >>>>>> >>>>>> What you have below is a good start. >>>>>> >>>>>> I still think we need to at least specify how dcsa impacts IANA >>>>>> registration of attributes. >>>>>> >>>>>> The attribute registration is (going to be) updated so that there is >>>>>> one table containing all attributes, with fields indicating for each >>>>>> attribute whether it can be used at session level, media level, or >>>>>> source level. >>>>>> >>>>>> Now consider an attribute usable at media and/or source level: >>>>>> >>>>>> It *might* *also* be usable with dcsa, or it might not. That will at >>>>>> least in part be determined by whether the protocol that it applies >>>>>> to can run over a data channel. >>>>>> >>>>>> There was a suggestion (Keith?) that media level attributes be >>>>>> implicitly allowed with dcsa if the protocol they apply to is >>>>>> defined over a data channel. I find that plausible. But then the >>>>>> instructions for registration ought to say that. Also, if there can >>>>>> be exceptions (attributes that *can't* be used with dcsa even when >>>>>> the protocol is defined over data channel) then there should be a >>>>>> way to register that. >>>>>> >>>>>> Source level attributes add another complication. They only apply >>>>>> over RTP. For now, RTP isn't defined over a data channel. (Though in >>>>>> principle it *could* be.) If it were, then I suppose the ussage >>>>>> would have to be 'a=dcsa nn source ...'. I don't think we need to >>>>>> deal with that right now. >>>>>> >>>>>> And then there is the possibility of new attributes being defined >>>>>> that can be used *only* with dcsa, not directly at media level: >>>>>> >>>>>> If this is because the protocol is only defined to run over a data >>>>>> channel, then it could possibly be registered as a media level >>>>>> attribute (which is then allowed by default with dcsa). If the >>>>>> protocol were ever defined over another transport the sdp would be >>>>>> ready for it. >>>>>> >>>>>> But if, for some reason, the protocol can run over a data channel >>>>>> and also over some other transport, but for some reason a particular >>>>>> attribute only applies with data channels, or only applies without >>>>>> data channels, then there ought to be a way to record that in the >>>>>> registry. >>>>>> >>>>>> The worst case is for every spec that defines an attribute to pick >>>>>> its own way to specify all this, and for there to be no hint in the >>>>>> iana registry. >>>>>> >>>>>> IMO it is still better for the iana registry to be given another >>>>>> field to indicate applicability with data channels. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 12/9/15 8:24 AM, Juergen Stoetzer-Bradler wrote: >>>>>>> Paul, Christian, Keith, >>>>>>> >>>>>>> Would propose to add following two new paragraphs to the end of >>>>>>> current section 5.1.2.1 (dcsa Attribute) in order to more clearly >>>>>>> describe the relationship of a subprotocol's attribute and the >>>>>>> subprotocol's transport protocol, especially data channel. >>>>>>> >>>>>>> >>>>>>> It is assumed that in general the usages of subprotocol related >>>>>>> media >>>>>>> level attributes are independent from the subprotocol's >>>>>>> transport >>>>>>> protocol. Such transport protocol independent subprotocol >>>>>>> related >>>>>>> attributes are used in the same way as defined in the original >>>>>>> subprotocol specification, also if the subprotocol is >>>>>>> transported >>>>>>> over a data channel and if the attribute is correspondingly >>>>>>> embedded >>>>>>> in a "a=dcsa" attribute. >>>>>>> >>>>>>> There may be cases, where the usage of a subprotocol related >>>>>>> media >>>>>>> level attribute depends on the subprotocol's transport >>>>>>> protocol. In >>>>>>> such cases the subprotocol related usage of the attribute is >>>>>>> expected >>>>>>> to be described for the data channel transport, e.g. in an >>>>>>> extension >>>>>>> of the original subprotocol specification. >>>>>>> >>>>>>> >>>>>>> Section 5.1.2 already explicitly mentions that (subprotocol >>>>>>> related) media level attributes may follow a data channel >>>>>>> declaration (the a=dcmap line). Thus the restriction to subprotocol >>>>>>> related media level attributes only seems to be covered already. >>>>>>> >>>>>>> Thanks, >>>>>>> Juergen >>>>>>> >>>>>>> >>>>>>> On 01.12.2015 02:12, DRAGE, Keith (Keith) wrote: >>>>>>>> I think we need to be a little bit careful here. >>>>>>>> >>>>>>>> In a large number of cases, the use of the attribute will be >>>>>>>> unaltered by the transport that is being used, and I do not think >>>>>>>> we should have a need of saying anything if this is the case - it >>>>>>>> should be the default. >>>>>>>> >>>>>>>> So for example for MSRP, there are a number of attributes >>>>>>>> associated with MSRP - for file transfer and so on, and as far as >>>>>>>> I can tell, they are used when MSRP is sent over a data channel in >>>>>>>> exactly the same way as when MSRP is sent over TCP or SCTP. We >>>>>>>> don't write special rules for TCP, so why write special rules for >>>>>>>> datachannel. >>>>>>>> >>>>>>>> We do need to identify how we document any special cases, and yes >>>>>>>> when we find them, drafts like the msrp draft are the way to do >>>>>>>> that. >>>>>>>> >>>>>>>> Additionally, if we find when defining a new attribute, that it is >>>>>>>> inappropriate for datachannel usage in some way, then we can write >>>>>>>> that in the defining specification for the new attribute (although >>>>>>>> I suspect in this case it will be inappropriate to other >>>>>>>> transports than just datachannel). >>>>>>>> >>>>>>>> I do assume this entire discussion is limited to attributes that >>>>>>>> can be applied to media lines. We might find it useful to say that >>>>>>>> in the general draft, if we have not done so already. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of >>>>>>>> Christian Groves >>>>>>>> Sent: 01 December 2015 00:53 >>>>>>>> To: mmusic@ietf.org >>>>>>>> Subject: Re: [MMUSIC] WGLC for >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg >>>>>>>> >>>>>>>> Hello Paul, >>>>>>>> >>>>>>>> I actually meant to post the reply to the list, sorry for the >>>>>>>> confusion. >>>>>>>> >>>>>>>> I do understand your concerns. For multiplexing it makes sense to >>>>>>>> check all the existing attributes to see whether they're >>>>>>>> applicable due to the fact that quite alot may be used when >>>>>>>> multiplexing occurs. >>>>>>>> I think the data channel usage is quite a bit more narrow in scope. >>>>>>>> >>>>>>>> Whilst this draft does introduce a general purpose mechanism the >>>>>>>> actual use of the dcsa is being defined by other drafts. E.g. >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what >>>>>>>> happens when both a=setup and a=dcsa:setup are present. msrp-cema >>>>>>>> is another one discussed, etc. >>>>>>>> >>>>>>>> I think you need to understand the application protocol being >>>>>>>> carried in a data channel before you can say whether particular >>>>>>>> attributes should be carried in dcsa and what that actually means. >>>>>>>> Going through the IANA registry wouldn't be trivial and unless the >>>>>>>> attributes are put in context of an application protocol I don't >>>>>>>> think it will be terribly helpful. >>>>>>>> >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate >>>>>>>> that the dsca parameters follow the procedures defined in the >>>>>>>> subprotocol specific documents. Maybe we could strengthen this to >>>>>>>> indicate that the use of dsca by an application protocol should be >>>>>>>> documented in a specification? >>>>>>>> >>>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 1/12/2015 11:30 AM, Paul Kyzivat wrote: >>>>>>>>> Christian, >>>>>>>>> >>>>>>>>> On 11/30/15 6:45 PM, Christian Groves wrote: >>>>>>>>>> Is this level of detail really needed? There are several drafts >>>>>>>>>> for CLUE, MSRP and BFCP related to the use of this sdpneg >>>>>>>>>> mechanism. >>>>>>>>>> E.g. >>>>>>>>>> CLUE doesn't use dcsa and MSRP provides guidelines on the use of >>>>>>>>>> dcsa. >>>>>>>>>> >>>>>>>>>> Can't we just follow the principle that the use of the dcsa >>>>>>>>>> attribute should be detailed in a specification and leave it at >>>>>>>>>> that? I'm not sure what we gain by analysing every existing >>>>>>>>>> attribute and forcing every new attribute to do this analyses >>>>>>>>>> when the set of possible parameters in likely to be very small. >>>>>>>>> I guess it is arguable both ways. Originally there was only >>>>>>>>> session level and media level. That was always supposed to be >>>>>>>>> identified, but it wasn't always followed. >>>>>>>>> >>>>>>>>> Then we got source level. That has complicated the registry and >>>>>>>>> the usage. I am not convinced that two SDP experts would come up >>>>>>>>> with the same list of which attributes can be used at source >>>>>>>>> level. >>>>>>>>> >>>>>>>>> The dcsa attribute becomes the 4th "level" for attributes. It at >>>>>>>>> least makes sense to me that it ought to be managed analogously >>>>>>>>> to the source attribute. But I agree it doesn't provide the same >>>>>>>>> degree of confusion as the others. It only makes sense if the >>>>>>>>> usage the attribute applies to works over a data channel. And >>>>>>>>> that should be known to whatever is processing the SDP. >>>>>>>>> >>>>>>>>> I see this was a private message. Why don't you repost it on the >>>>>>>>> list and lets see what other people think? (Feel free to repost >>>>>>>>> this reply if you wish.) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> Regards, Christian >>>>>>>>>> >>>>>>>>>> On 1/12/2015 2:36 AM, Paul Kyzivat wrote: >>>>>>>>>>> One thing occurred to me that we may have forgotten about: >>>>>>>>>>> >>>>>>>>>>> This draft introduces the dcsa attribute, which allows other >>>>>>>>>>> attributes to be used in this new scope. It notes that not all >>>>>>>>>>> attributes are suitable for use this way. >>>>>>>>>>> >>>>>>>>>>> ISTM that in the future other attribute definitions should >>>>>>>>>>> include an indication of whether they can be used with dcsa, >>>>>>>>>>> and the IANA registration of the attribute ought to include >>>>>>>>>>> this. And then there is a need to update the iana registry for >>>>>>>>>>> all the existing attributes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> On 11/25/15 4:52 AM, Bo Burman wrote: >>>>>>>>>>>> This is to announce a 4 week Working Group Last Call for >>>>>>>>>>>> >>>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg-06 >>>>>>>>>>>> >>>>>>>>>>>> as proposed standard. >>>>>>>>>>>> >>>>>>>>>>>> Please review and provide any comments you may have on the >>>>>>>>>>>> document by Wednesday, December 23, 2015. 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. >>>>>>>>>>>> >>>>>>>>>>>> Please also forward this WGLC call to any other interested >>>>>>>>>>>> parties who may be able to review the draft, asking them to >>>>>>>>>>>> also direct their comments to the authors and the list as >>>>>>>>>>>> above. >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> Bo Burman (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 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 >> . >> > >