From nobody Mon Feb 1 13:22: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 80E391B36E3 for ; Mon, 1 Feb 2016 13:22:27 -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 1Br5bJFW7EC1 for ; Mon, 1 Feb 2016 13:22:25 -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 6F8AA1B2DDE for ; Mon, 1 Feb 2016 13:22:25 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u11LME2h041009 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Feb 2016 15:22:15 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Magnus Westerlund , Harald Alvestrand , "mmusic@ietf.org" References: <56279638.9030007@alvestrand.no> <5628F926.7060304@nostrum.com> <562A37FC.1010805@ericsson.com> From: Adam Roach Message-ID: <56AFCC86.7050809@nostrum.com> Date: Mon, 1 Feb 2016 15:22:14 -0600 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: <562A37FC.1010805@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] Simulcast worries: What bitrate? (from the WEBRTC list) 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, 01 Feb 2016 21:22:27 -0000 On 10/23/15 08:37, Magnus Westerlund wrote: > Den 2015-10-22 kl. 16:56, skrev Adam Roach: >> On 10/21/15 08:42, Harald Alvestrand wrote: >>> I'd be happier if we could say "this is the same bitrate as b=TEAS" or >>> something like that - if an implementation has to stick to multiple >>> definitions of bitrate for the same media flow, which will happen with >>> a=rid .. max-br and b= in the same message, it would be nice to be able >>> to use the same counters. >> >> I'm good either way. We can keep this as-is, or add a reference to >> RFC3890. Anyone want to speak for or against moving over to the RFC3890 >> definition of bandwidth? > > Hi, > > I am of the opinion (having authored RFC 3890) that we should use a > more well defined bit-rate definition than what is in TIAS. > In fact the current definition is well matching that of TIAS, with the > additional constraints of a measuring interval. I think this is the > minimal improvement we should do. I read this to say that you think the text in draft-ietf-mmusic-rid is sufficient without any external reference. I'm happy with that as an answer. :) > I can argue for an even more specific bandwidth definitions. My > personal position is that the stream specific ones (SMT and SLT) in > our SDP bandwidth proposal (now expired) actually makes sense to be > used with RID: > https://www.ietf.org/archive/id/draft-westerlund-mmusic-sdp-bw-attribute-02.txt > All of the definitions in that document are problematic for the vast majority of WebRTC's use cases, since they all include the phrase "including protocol overhead." In general, web browsers operate high enough on the protocol stack that getting access to "protocol overhead" introduced by layers 1 through 4 is simply implausible. /a From nobody Mon Feb 1 13:31: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 C69031B3713 for ; Mon, 1 Feb 2016 13:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 oeEnnxi7oOqt for ; Mon, 1 Feb 2016 13:31:13 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 E1DAC1B370F for ; Mon, 1 Feb 2016 13:31:12 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id z14so46307322igp.0 for ; Mon, 01 Feb 2016 13:31:12 -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=A3go4P6/whgtPxslNyZ+sFS3WVLcZE6ipgHbiZ1S+DU=; b=iloevXOE/js4H32rUksr/hbc0eEUlP36sccsIzBsAEeO/nHtSdi2RMaPRTlGmPRKGT 2avahUpe4MqpPWbtihCQIAS+3tKtwQ0A61gNBg+wci9GD8W7Cukf9tyTBceaaUV2Q2yZ slv3At0TQK74sxxE1Uw4FhjDG+vufML3UYeMbO0G4SDc3h/Exq69Oy/OCEifsmXACDWv ojXAgemVp+NLN8Rksa3+rdZXRx0OhIml2i5swndyYcNxQVQgejYqHjx7R2Q1MyRHZ8a8 XZ8N7e0bctsqhwW4K4kvRhVxRKFmiqbuZ7sgcKQA1Ea46YvF/ZULZ8lCG4MoEMY4tJYF 2C2Q== 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=A3go4P6/whgtPxslNyZ+sFS3WVLcZE6ipgHbiZ1S+DU=; b=KDK7yaTl8KOJCVbPaevQFIXTzTmqK7D8UrlHlPM5Dc4SCH0Syg5klOmZzW+E3n9PzX Nmcfq+k4aPKOj1QVwFicNi+CJb7BB5KQfaIAzDbB1XsT5JpFrpt2rPSjiAL2+opOa1we IDb4GGaDHZOnOrz/pGDPI/M9MVR4dQ9xN5ttv8o+PTBXUZifYY8Ozow65bGyt9f6TLMD 754/6XO54N744kdSTFgMHzVW9iTJO9M+cz7icGJFZtryfE6AlTHVFQ/g53H1Iu7JkuDj Alm2NCvLAP1/DSaIn76CV/tax+05fJUxMA3GJ8sPsIyZnUrY1TvaYLM2hNBzxiv4p2iO IQTg== X-Gm-Message-State: AG10YOScsTTEH+MsO+O+ENoj9QM0Ngn7/ywoW7/D3LJK3WceCsCluUDmT7zZTjXnGeMT/g== X-Received: by 10.50.129.67 with SMTP id nu3mr5845320igb.48.1454362272308; Mon, 01 Feb 2016 13:31:12 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id kc8sm5043445igb.4.2016.02.01.13.31.10 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 13:31:10 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id ik10so46239884igb.1 for ; Mon, 01 Feb 2016 13:31:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.136 with SMTP id w8mr13310811igl.96.1454362270361; Mon, 01 Feb 2016 13:31:10 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 1 Feb 2016 13:31:10 -0800 (PST) In-Reply-To: <56AACE99.5060905@cisco.com> References: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> <56AACE99.5060905@cisco.com> Date: Mon, 1 Feb 2016 16:31:10 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Flemming Andreasen Content-Type: multipart/alternative; boundary=089e011602a87ff1c9052abc1a2f Archived-At: Cc: mmusic Subject: Re: [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: Mon, 01 Feb 2016 21:31:14 -0000 --089e011602a87ff1c9052abc1a2f Content-Type: text/plain; charset=UTF-8 Flemming, We should be ready for WGLC. Regards, _____________ Roman Shpount On Thu, Jan 28, 2016 at 9:29 PM, Flemming Andreasen wrote: > 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 listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic > > . > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e011602a87ff1c9052abc1a2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Flemming= ,

We should b= e ready for WGLC.

Regards,

_____________
Roman Shpount

On Thu, Jan 28, 2016 at 9:29 PM, Flemming An= dreasen <fandreas@cisco.com> wrote:
=20 =20 =20
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 th=
e on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king 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=3Ddraft-ietf-mmusic-=
dtls-sdp-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

.



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


--089e011602a87ff1c9052abc1a2f-- From nobody Mon Feb 1 14:54:57 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 638191B384B; Mon, 1 Feb 2016 14:54:52 -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: <20160201225452.23868.32870.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 14:54:52 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-01.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, 01 Feb 2016 22:54:52 -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 : RTP Payload Format Constraints Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-01.txt Pages : 22 Date : 2016-02-01 Abstract: In this specification, we define a framework for identifying RTP Streams with the constraints on its payload format in the Session Description Protocol. This framework defines a new "rid" SDP attribute to: a) effectively identify the RID RTP Streams within a RTP Session, b) constrain their payload format parameters in a codec- agnostic way beyond what is provided with the regular Payload Types and c) enable unambiguous mapping between the RID RTP Streams to their media format specification in the SDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 1 15:07:18 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 76B3E1B3861 for ; Mon, 1 Feb 2016 15:07:16 -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 zzkG6UliOhtQ for ; Mon, 1 Feb 2016 15:07:15 -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 467941B3862 for ; Mon, 1 Feb 2016 15:07:15 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u11N7E1c050284 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 1 Feb 2016 17:07:14 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "mmusic@ietf.org" From: Adam Roach Message-ID: <56AFE521.1040305@nostrum.com> Date: Mon, 1 Feb 2016 17:07:13 -0600 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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] New version of RID document 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, 01 Feb 2016 23:07:16 -0000 As noted by the automated notice, I've submitted a new version of the RID document, with the following main changes: 1. I made an editorial clean-up pass. 2. Motivation section rolled into Introduction 3. SDES item now references separate AVTEXT document 4. Meaning of "pt=" is now clearly defined rather than being implicit 5. New "max-bpp" parameter, at the suggestion of Stephan Wenger 6. Unknown "send" constraints no longer cause a negotiation failiure 7. New section on declarative SDP Please see section 11 for the current open issues, along with my recommendations. If you disagree with any of the recommendations, please speak up quickly. A complete diff can be found here: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-01 /a From nobody Mon Feb 1 23:16: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 5BF771A88CB for ; Mon, 1 Feb 2016 23:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 JhPid8Y5WHiy for ; Mon, 1 Feb 2016 23:15:51 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DAB1A88C9 for ; Mon, 1 Feb 2016 23:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2706; q=dns/txt; s=iport; t=1454397350; x=1455606950; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WieG2NmWmMF5EB1jJvQIbmHtPZ0cC2gnNEP5bV37luw=; b=N4T95nQhFE2TUHFeJ/5mwqhaA1a6YOjUR01p/44404pYOFT4lAEmnHpi eWjJvMAI1+7OfErF8VR+N98lriWQIps/DZ5PkX3grdiMuqaK9ODLQd25n KZKr9qGC31pWhREcy62+mR4uggTgp4Qp5TLvFbcCzBhnvA9a64TUSwIyl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgBvV7BW/5BdJa1egzpSXg8GiFOxX?= =?us-ascii?q?wENgWQYCoUjSgKBODgUAQEBAQEBAYEKhEEBAQEDAQEBATc0CwULAgEIEQMBAgE?= =?us-ascii?q?eECcLHQgCBA4FiBMIDr1yAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYPAYFsgkqEM?= =?us-ascii?q?IMtgQ8FlnEBhUaIBIFbSoN4gyaFLo4+AR4BAUKDbWqIb3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,384,1449532800"; d="scan'208";a="233285069" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2016 07:15:44 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u127FiPH012408 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Feb 2016 07:15:44 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 01:15:43 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Tue, 2 Feb 2016 01:15:43 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "Flemming Andreasen (fandreas)" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt Thread-Index: AQHRXYmHpXkS9qu1A0Sw+0V99l4KFA== Date: Tue, 2 Feb 2016 07:15:43 +0000 Message-ID: References: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> <56AACE99.5060905@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.252.108] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D37E7520A67464C84F1A4CFDE03460F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: mmusic Subject: Re: [MMUSIC] 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: Tue, 02 Feb 2016 07:15:53 -0000 Hi Flemming -=20 I have read this draft and think it is in good shape and ready for WGLC. -G > On Thu, Jan 28, 2016 at 9:29 PM, Flemming Andreasen = wrote: > Greetings MMUSIC >=20 > We would like to start moving towards WGLC on this draft - do people beli= eve the draft is ready for that at this point ? If not, please let us know = which issues you see.=20 >=20 > Thanks=20 >=20 > -- Flemming (as MMUSIC chair) >=20 >=20 >=20 >=20 > -------- 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 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control W= orking Group of the IETF. >=20 > 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 >=20 > 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. >=20 > This draft defines a new SDP media-level attribute, 'dtls- > connection'. >=20 >=20 > The IETF datatracker status page for this draft is: >=20 > https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ >=20 >=20 > There's also a htmlized version available at: >=20 > https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-05 >=20 >=20 > A diff from the previous version is available at: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-dtls-sdp-05 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at=20 > tools.ietf.org > . >=20 > Internet-Drafts are also available by anonymous FTP at: >=20 > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > mmusic mailing list >=20 > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > . >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Feb 2 01:32:22 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 5AA901ACD61 for ; Tue, 2 Feb 2016 01:32:21 -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 0feB_0Pw9_GA for ; Tue, 2 Feb 2016 01:32:19 -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 D229E1ACD60 for ; Tue, 2 Feb 2016 01:32:18 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-74-56b077a0e0f6 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 27.7A.05690.0A770B65; Tue, 2 Feb 2016 10:32:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Tue, 2 Feb 2016 10:32:16 +0100 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoIAAIcaAgAEX24CAAJvKgIAACmeAgAAMtICAAM4ZgIAAhUyAgAAi3NCAAA/qgIAAAkUAgAACrYCAABTqAIAL3+xQ Date: Tue, 2 Feb 2016 09:32:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D664F2@ESESSMB209.ericsson.se> 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D664F2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7pe6C8g1hBkee6VhMXf6YxWLFhgOs FjMuTGW22Dm3g9mBxePv+w9MHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBm3Z5YV dIRUdLz8zNTA+CCwi5GTQ0LAROLk0uuMELaYxIV769m6GLk4hAQOM0q0/VkC5SxmlHjwbh5r FyMHB5uAhUT3P22QBhEBb4m+vg52EJtZIFDi2YU+FhBbWMBOovn0emaIGnuJU2s/MILMERFY xSixafErsCIWARWJlacfgzXzCvhKHNt4hh1i2X4OiXWznjCBJDiBps5c+xzsPEag876fWsME sU1c4taT+UwQZwtILNlznhnCFpV4+fgf2KESAooSy/vlIMrzJR5MvskIsUtQ4uTMJywTGEVn IZk0C0nZLCRls4AmMQtoSqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcXFuelGxnqp RZnJxcX5eXp5qSWbGIExeXDLb90djKtfOx5iFOBgVOLhLXi8PkyINbGsuDL3EKMEB7OSCO/+ 9A1hQrwpiZVVqUX58UWlOanFhxilOViUxHnXOANVC6QnlqRmp6YWpBbBZJk4OKUaGIObZP3e 7Io7schoL5dndeq9i7PeXvqT2nN7ReGfVOsJ7VeXX/f90DZjRYFP78ZOjw/Mmm3lzx1Zl7Qu 6uDcFOW2dNXKsyf+Mk9k1jxlOvtB/8p25mWKD1bv4nAs1Xyxv+xab0SN0+06wY5Fp3SKel2K 01ytYo6nskqr+tU+WqYd6Hgkb9kDDSWW4oxEQy3mouJEAJwLKnfFAgAA 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: Tue, 02 Feb 2016 09:32:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D664F2ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNvLCBhc3N1bWluZyB3ZSB3b3VsZCBkZWZpbmUgYSBuZXcgYXR0cmlidXRlIHRvIGlu ZGljYXRlL25lZ290aWF0ZSBtdXgtZXhjbHVzaXZlLCBJIHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8g c2F5IHNvbWV0aGluZyBhYm91dCBhPXJ0Y3AsIGRvbuKAmXQgd2U/DQoNCldlIGNvdWxkIHNpbXBs eSBzYXkgdGhhdCB0aGUgYT1ydGNwIGF0dHJpYnV0ZSB2YWx1ZSBtdXN0IGJlIGlkZW50aWNhbCB0 byB0aGUgcG9ydCBhbmQgYWRkcmVzcyBmb3IgUlRQLiBUaGF0IHdvdWxkIHdvcmsgYWxzbyBmb3Ig dHJpY2tsZSBJQ0UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNocG91 bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDI1LiB0YW1taWt1dXRhIDIwMTYg MjM6MTENClRvOiBQYXVsIEt5eml2YXQNCkNjOiBDaHJpc3RlciBIb2xtYmVyZzsgU3VoYXMgTmFu ZGFrdW1hcjsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gTm90IGZpeGlu ZyBhPXJ0Y3AgYW5kIHJ0Y3AtbXV4IGV4Y2x1c2l2ZQ0KDQpPbiBNb24sIEphbiAyNSwgMjAxNiBh dCAyOjU1IFBNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5 eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQpEbyB5b3UgaGF2ZSBkYXRhIHN1cHBvcnRpbmcg dGhpcyBhc3NlcnRpb24/DQoNCg0KSSBiZWxpZXZlIGE9cnRjcCB3YXMgZGV2ZWxvcGVkIHRvIHdv cmsgaW4gY29uanVuY3Rpb24gd2l0aCBSRkMgMzQ4OS4gSW4gcHJhY3RpY2Ugc3VjaCBkZXBsb3lt ZW50IHNjZW5hcmlvcyBhcmUgcmVjaXBlcyBmb3IgZGlzYXN0ZXIgc2luY2UgZW5kIHBvaW50cyB3 aWxsIGVuZCB1cCBub3QgZ2V0dGluZyBjb25uZWN0ZWQgb2Z0ZW4gZW5vdWdoIGZvciBsYXJnZSBn cm91cHMgb2YgeW91ciBjdXN0b21lcnMgdG8gY29tcGxhaW4uIFN1Y2ggYXJjaGl0ZWN0dXJlIGFs c28gaGFzIHNlcmlvdXMgc2VjdXJpdHkgcHJvYmxlbXMuIFRoaXMgZW50aXJlIGFyY2hpdGVjdHVy ZSB3YXMgbGF0ZXIgY29tcGxldGVseSByZWRlc2lnbmVkIChzZWUgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzUzODkjc2VjdGlvbi0yIGZvciBtb3JlIGRldGFpbHMpLg0KDQpBbnl0aGlu ZyBjb21tZXJjaWFsbHkgdmlhYmxlIGlzIHVzaW5nIGVpdGhlciBzb21ldGhpbmcgbGlrZSBJQ0Ug b3IgaG9zdCBiYXNlZCBOQVQgdHJhdmVyc2FsLiBJIHRoaW5rIHdlIHNob3VsZCBzdHJvbmdseSBz dGVlciBzZXJ2aWNlIGltcGxlbWVudGVycyB0b3dhcmRzIElDRSB3aGVuIE5BVCBzdXBwb3J0IGlz IHJlcXVpcmVkIGFuZCBkbyBub3QgZXh0ZW5kIG9yIHByb21vdGUgYT1ydGNwIGJhc2VkIHNvbHV0 aW9ucy4gSUNFIGRvZXMgbWVudGlvbiBhPXJ0Y3AgYnV0IGl0IGlzIG9ubHkgdXNlZCB0aGVyZSBm b3IgbGVnYWN5IGludGVyb3Agd2l0aCBleGl0aW5nIGVuZCBwb2ludHMgd2hpY2ggd2VyZSBkZXNp Z25lZCB0byB3b3JrIHdpdGggUkZDIDM0ODkgZGVyaXZlZCBhZGRyZXNzZXMuIEkgZG8gbm90IHRo aW5rIGE9cnRjcCBoYXMgYW55IHVzZSBjYXNlcyBiZXlvbmQgc3VjaCBsZWdhY3kgaW50ZXJvcC4N Cl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37D664F2ESESSMB209erics_ 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+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCBhc3N1bWlu ZyB3ZSB3b3VsZCBkZWZpbmUgYSBuZXcgYXR0cmlidXRlIHRvIGluZGljYXRlL25lZ290aWF0ZSBt dXgtZXhjbHVzaXZlLCBJIHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8gc2F5IHNvbWV0aGluZyBhYm91 dCBhPXJ0Y3AsIGRvbuKAmXQgd2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PldlIGNvdWxkIHNpbXBseSBzYXkgdGhhdCB0aGUgYT1ydGNwIGF0dHJpYnV0ZSB2YWx1ZSBtdXN0 IGJlIGlkZW50aWNhbCB0byB0aGUgcG9ydCBhbmQgYWRkcmVzcyBmb3IgUlRQLiBUaGF0IHdvdWxk IHdvcmsgYWxzbyBmb3IgdHJpY2tsZSBJQ0UuPG86cD48L286cD48L3NwYW4+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 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5A dGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjUuIHRhbW1pa3V1dGEgMjAxNiAyMzox MTxicj4NCjxiPlRvOjwvYj4gUGF1bCBLeXppdmF0PGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBI b2xtYmVyZzsgU3VoYXMgTmFuZGFrdW1hcjsgbW11c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbTU1VU0lDXSBOb3QgZml4aW5nIGE9cnRjcCBhbmQgcnRjcC1tdXggZXhjbHVz aXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTW9uLCBKYW4gMjUsIDIwMTYgYXQgMjo1NSBQTSwgUGF1bCBLeXppdmF0ICZsdDs8 YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+cGt5 eml2YXRAYWx1bS5taXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3Ug aGF2ZSBkYXRhIHN1cHBvcnRpbmcgdGhpcyBhc3NlcnRpb24/PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSBhPXJ0 Y3Agd2FzIGRldmVsb3BlZCB0byB3b3JrIGluIGNvbmp1bmN0aW9uIHdpdGggUkZDIDM0ODkuIElu IHByYWN0aWNlIHN1Y2ggZGVwbG95bWVudCBzY2VuYXJpb3MgYXJlIHJlY2lwZXMgZm9yIGRpc2Fz dGVyIHNpbmNlIGVuZCBwb2ludHMgd2lsbCBlbmQgdXAgbm90IGdldHRpbmcgY29ubmVjdGVkIG9m dGVuIGVub3VnaCBmb3IgbGFyZ2UgZ3JvdXBzIG9mIHlvdXIgY3VzdG9tZXJzIHRvIGNvbXBsYWlu Lg0KIFN1Y2ggYXJjaGl0ZWN0dXJlIGFsc28gaGFzIHNlcmlvdXMgc2VjdXJpdHkgcHJvYmxlbXMu Jm5ic3A7VGhpcyBlbnRpcmUgYXJjaGl0ZWN0dXJlIHdhcyBsYXRlciBjb21wbGV0ZWx5IHJlZGVz aWduZWQgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzODkj c2VjdGlvbi0yIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTM4OSNzZWN0aW9uLTI8 L2E+IGZvciBtb3JlIGRldGFpbHMpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbnl0aGluZyBjb21tZXJjaWFsbHkgdmlhYmxlIGlz IHVzaW5nIGVpdGhlciBzb21ldGhpbmcgbGlrZSBJQ0Ugb3IgaG9zdCBiYXNlZCBOQVQgdHJhdmVy c2FsLiBJIHRoaW5rIHdlIHNob3VsZCBzdHJvbmdseSBzdGVlciBzZXJ2aWNlIGltcGxlbWVudGVy cyB0b3dhcmRzIElDRSB3aGVuIE5BVCBzdXBwb3J0IGlzIHJlcXVpcmVkIGFuZCBkbyBub3QgZXh0 ZW5kIG9yIHByb21vdGUgYT1ydGNwIGJhc2VkIHNvbHV0aW9ucy4NCiBJQ0UgZG9lcyBtZW50aW9u IGE9cnRjcCBidXQgaXQgaXMgb25seSB1c2VkIHRoZXJlIGZvciBsZWdhY3kgaW50ZXJvcCB3aXRo IGV4aXRpbmcgZW5kIHBvaW50cyB3aGljaCB3ZXJlIGRlc2lnbmVkIHRvIHdvcmsgd2l0aCBSRkMg MzQ4OSBkZXJpdmVkIGFkZHJlc3Nlcy4gSSBkbyBub3QgdGhpbmsgYT1ydGNwIGhhcyBhbnkgdXNl IGNhc2VzIGJleW9uZCBzdWNoIGxlZ2FjeSBpbnRlcm9wLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpS b21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37D664F2ESESSMB209erics_-- From nobody Tue Feb 2 04:16: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 900141A7026; Tue, 2 Feb 2016 04:16:00 -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 RlQwzklJudLf; Tue, 2 Feb 2016 04:15:56 -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 8CE3C1A6F7B; Tue, 2 Feb 2016 04:15:55 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-55-56b09df90686 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 23.C1.05690.9FD90B65; Tue, 2 Feb 2016 13:15:53 +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; Tue, 2 Feb 2016 13:15:53 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Initial comments on draft-ietf-mmusic-rid-01 Thread-Index: AdFdr+0yBZP7IDFZTLKr2iUM5X5ZLAAA3UOw Date: Tue, 2 Feb 2016 12:15:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D669A1@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_7594FB04B1934943A5C02806D1A2204B37D669A1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbE9UPfn3A1hBi1dRhbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyrnzYyVLw8ihjxderTxgbGHvWMnYxcnBICJhIPF1Z 38XICWSKSVy4t56ti5GLQ0jgMKPE+xdroJzFjBJX+n4zgTSwCVhIdP/TBmkQEVCX+Lq3hxnE ZhYwlXj4ag0jiC0MZF9ctIcNosZK4srPC2CtIgJGEs07skHCLAIqEiv/9YGV8Ar4Srzp2cAE YjMC3fD91BomiJHiEreezGeCuE1AYsme88wQtqjEy8f/WCFsRYmr05dD1edLfLl5iAVipqDE yZlPWCYwCs9CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbR4tTi4tx0 I2O91KLM5OLi/Dy9vNSSTYzAqDm45bfuDsbVrx0PMQpwMCrx8BY8Xh8mxJpYVlyZe4hRgoNZ SYR3f/qGMCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8a5yBqgXSE0tSs1NTC1KLYLJMHJxSDYzm u682KSZNEWRVPPiGWSJD2KvjSXztt6zz+y4VlnI+O7vwmsHzkHDnQpWVe7a5LWRSXL/5wJHN 7I4BXK0de7qT11pbFS2INrnk/y3gqOUhjqnzL178HXprx8TPi5YzSIhcFBDfOC/yDeuXk70i DFbBRzx2b71R9iPo7+K6/GV/3nKs+/8pwPqXEktxRqKhFnNRcSIATzYd25YCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Initial comments on draft-ietf-mmusic-rid-01 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, 02 Feb 2016 12:16:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D669A1ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was asked to take a look at the RID draft. I think some editorial work is going to be needed. I realize it may not be = the most important focus at this point, but if the draft is anyway updated = for technical reasons the editorials can be fixed at the same time in order= to make the draft easier to read. After all, there is a long list of autho= rs, so... :) I will not comment on all of the editorial issues ones I found (hopefully m= y general comments will get rid of most of them), but in this e-mail focus = mostly on sections 1 and 6 (with subsections). GENERAL: ------------ Q_G_1: Please pay attention to usage of consistent terminology. For example, I see "a=3D lines", "a=3D parameters", "a=3D attributes" type = of terminology... For example, I see "format of the RTP payload", "RTP payload format". Q_G_2: The draft talks a lot about "payload", "codec", "format" etc. I think the d= raft should contain a definition of those. If they are defined elsewhere, s= uch text can say e.g.: "As defined in [RFCXXXX], payload refers to blah blah blah..." Q_G_3: Is there a risk of conflicts between information provided in a=3Drid and a= =3Dfmtp/rtpmap? If so, how shall it be treated? SECTION 1: ------------- Q_1_1: The text says: "Payload Type (PT) in RTP provides a mapping between the format of the RTP payload and the media format description specified in the signaling. For applications that use SDP for signaling, the constructs rtpmap and/or fmtp describe the characteristics of the media that is carried in the RTP payload, mapped to a given PT." Assuming the scope of the draft is SDP, I think the paragraph can be shorte= r, e.g.: "Payload Type (PT) in RTP provides a mapping between the RTP payload for= mat and the associated SDP media description. The SDP rtpmap and/or fmtp att= ributes are used, for a given PT, to the describe the characteristics of the med= ia that is carried in the RTP payload." Q_1_2: The text says: "However, the assignment of static mapping of payload codes to payload formats and multiplexing of RTP with other protocols (such as RTCP) could result in limited number of payload type numbers available for the application usage." What is a "payload code"? Shall it be "codec"? Q_1_3: The text says: "and to effectively map a RID RTP Stream to its corresponding constraint= s." I know there is a reference for "RID RTP Stream" in the Terminology section= , would I think it would be good to have the reference also in the Introduc= tion. Q_1_4: The text says: "As described in Section 6.2.1, this mechanism achieves backwards compatibility via the normal SDP processing rules, which require unknown a=3D parameters to be ignored. This means that implementations need to be prepared to handle successful offers and answers from other implementations that neither indicate nor honor the constraints requested by this mechanism." SECTION 6: ------------- Q_6_1: The text says: "For each media description in the offer,..." It should say for each media description that describes RTP based media, or= something like that... Q_6_2: The text says: "It MUST generate a "rid-identifier" that is unique within a media desc= ription" Later, in section 6.5, the draft says that a new offer with "proposed chang= es" should use a new ID value. What about a subsequent RTP session? Is it o= k to re-use the value(s) from the previous session? Q_6_3: The text says: "The Offerer then chooses zero or more "a=3Drid" constraints (Section 5) to be applied to the rid, and adds them to the "a=3Drid" line." What is meant by "the rid"? Q_6_4: In section 6.2.1, the text says: "As a result, ignoring the "a=3Drid" line is always guaranteed to result= in a valid session description." While this is true, a few words about the consequences of the fact that RID= won't be used is needed. For example, if the offerer has indicated some constraints using a=3Drid, a= nd the answerer does not support a=3Drid, does the offerer have to be prepa= red to receive media "outside" of those constraints, etc? Just saying that unsupported attributes are ignored, but it doesn't matter = because the SDP will still be valid, is not enough when it comes to describ= ing the backward compatibility :) Q_6_5: In section 6.3, the text says: "Having performed verification of the SDP offer as described" I assume something is missing behind "described"? I guess the answer to the question above may clarify it, but what is meant = by "verification"? Q_6_6: In section 6.4, I see a mix of "MUSTs" and "SHALLs", but I can't really see= the difference. Q_6_7: In section 6.4, the text talks about cases where "the offerer shall conside= r the a=3D line as rejected". It is unclear whether it is meant to mean that the answerer rejected the a= =3D line (which I agree would be a little strange), or if the offerer shall= reject the a=3D line. Assuming it's the offerer, I think it would be more clear the say "the offe= rer shall reject the a=3D line". I also think it would be better to say "discard" instead of "reject", becau= se "reject" often means that some additional action is taken, which I assum= e is not the case here. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D669A1ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I was asked to take a look at t= he RID draft.

 

I think some editorial work is = going to be needed. I realize it may not be the most important focus at thi= s point, but if the draft is anyway updated for technical reasons the edito= rials can be fixed at the same time in order to make the draft easier to read. After all, there is a long list= of authors, so… :)

 

I will not comment on all of th= e editorial issues ones I found (hopefully my general comments will get rid= of most of them), but in this e-mail focus mostly on sections 1 and 6 (wit= h subsections).

 

 

GENERAL:

------------<= /p>

 

Q_G_1:

 

Please pay attention to usage o= f consistent terminology.

 

For example, I see “a=3D = lines”, “a=3D parameters”, “a=3D attributes” = type of terminology…

 

For example, I see “forma= t of the RTP payload”, “RTP payload format”.

 

 

Q_G_2:

 

The draft talks a lot about = 220;payload”, “codec”, “format” etc. I think = the draft should contain a definition of those. If they are defined elsewhe= re, such text can say e.g.:

 

   “As defined = in [RFCXXXX], payload refers to blah blah blah…”

 

 

Q_G_3:

 

Is there a risk of conflicts be= tween information provided in a=3Drid and a=3Dfmtp/rtpmap? If so, how shall= it be treated?

 

 

SECTION 1:

-------------=

 

Q_1_1:

 

The text says:

 

   “Payload Typ= e (PT) in RTP provides a mapping between the format of the

   RTP payload and th= e media format description specified in the

   signaling.  F= or applications that use SDP for signaling, the

   constructs rtpmap = and/or fmtp describe the characteristics of the

   media that is carr= ied in the RTP payload, mapped to a given PT.”

 

Assuming the scope of the draft= is SDP, I think the paragraph can be shorter, e.g.:

 

   “Payload Typ= e (PT) in RTP provides a mapping between the RTP payload format<= /span>

   and the associated= SDP media description. The SDP rtpmap and/or fmtp attributes

   are used, for a gi= ven PT, to the describe the characteristics of the media that is carried

   in the RTP pa= yload.”

 

 

Q_1_2:

 

The text says:

 

   “However, th= e assignment of static mapping of payload

   codes to payload f= ormats and multiplexing of RTP with other protocols

   (such as RTCP) cou= ld result in limited number of payload type numbers

   available for the = application usage.”

 

What is a “payload code&#= 8221;? Shall it be “codec”?

 

 

Q_1_3:

 

The text says:

 

   “and to effe= ctively map a RID RTP Stream to its corresponding constraints.”<= /o:p>

 

I know there is a reference for= “RID RTP Stream” in the Terminology section, would I think it = would be good to have the reference also in the Introduction.

 

 

Q_1_4:

 

The text says:

 

   “As describe= d in Section 6.2.1, this mechanism achieves backwards

   compatibility via = the normal SDP processing rules, which require

   unknown a=3D param= eters to be ignored.  This means that implementations

   need to be prepare= d to handle successful offers and answers from

   other implementati= ons that neither indicate nor honor the constraints

   requested by this = mechanism.”

 

 

SECTION 6:

-------------=

 

Q_6_1:

 

The text says:

 

    “For e= ach media description in the offer,…”

 

It should say for each media de= scription that describes RTP based media, or something like that…

 

 

Q_6_2:

 

The text says:

 

    “It MU= ST generate a "rid-identifier" that is unique within a media desc= ription”

 

Later, in section 6.5, the draf= t says that a new offer with “proposed changes” should use a ne= w ID value. What about a subsequent RTP session? Is it ok to re-use the val= ue(s) from the previous session?

 

 

Q_6_3:

 

The text says:

 

   “The Offerer= then chooses zero or more "a=3Drid" constraints

   (Section 5) to be = applied to the rid, and adds them to the

    "a=3Dri= d" line.”

 

What is meant by “the rid= ”?

 

 

Q_6_4:

 

In section 6.2.1, the text says= :

 

   “As a result= , ignoring the "a=3Drid" line is always guaranteed to result in a= valid session description.”

 

While this is true, a few words= about the consequences of the fact that RID won’t be used is needed.=

 

For example, if the offerer has= indicated some constraints using a=3Drid, and the answerer does not suppor= t a=3Drid, does the offerer have to be prepared to receive media “out= side” of those constraints, etc?

 

Just saying that unsupported at= tributes are ignored, but it doesn’t matter because the SDP will stil= l be valid, is not enough when it comes to describing the backward compatib= ility :)

 

 

Q_6_5:

 

In section 6.3, the text says:<= o:p>

 

    “Havin= g performed verification of the SDP offer as described”

 

I assume something is missing b= ehind “described”?

 

I guess the answer to the quest= ion above may clarify it, but what is meant by “verification”?<= o:p>

 

 

Q_6_6:

 

In section 6.4, I see a mix of = “MUSTs” and “SHALLs”, but I can’t really see = the difference.

 

 

Q_6_7:

 

In section 6.4, the text talks = about cases where “the offerer shall consider the a=3D line as reject= ed”.

 

It is unclear whether it is mea= nt to mean that the answerer rejected the a=3D line (which I agree would be= a little strange), or if the offerer shall reject the a=3D line.

 

Assuming it’s the offerer= , I think it would be more clear the say “the offerer shall reject th= e a=3D line”.

 

I also think it would be better= to say “discard” instead of “reject”, because R= 20;reject” often means that some additional action is taken, which I = assume is not the case here.

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D669A1ESESSMB209erics_-- From nobody Tue Feb 2 06:54: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 30CFB1B2BDB for ; Tue, 2 Feb 2016 06:54:08 -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 14Jh2wSIXiCV for ; Tue, 2 Feb 2016 06:54:07 -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 02F7D1B2BA1 for ; Tue, 2 Feb 2016 06:54:06 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id 9so19677286iom.1 for ; Tue, 02 Feb 2016 06:54:06 -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=61n1rTOQAdXv6eeHPFo5aQPM3i32wSF+GJxCdH9J8Zk=; b=jcIcEqVmh5AOsw6SCn7+6Lu70M9app8anD+tg5UsAzMfwfG6VSqb1Joj1RHM4OIc8Y DxgQ6dzFprg8vXPGHUiKTXFl1kKHr/XFdDvZWIm/gXYBUfybE0th6aM6ILNdQrDz0duM HqmSlYUPLhFZXfE6IMkSgkBB3KjGChw/TUB4JVrJWiMBLIl9h87UVWeVsWF0DY71ryR6 zEfBCWTxnCaWcZnAyJx4cdOA0ZRoJ9mDpESvnUhxHo7IdcLBHu7hSGNKQ3eEAQNUHGab GYcABqQklOrFW1xJrgZV5PSJp4PSCcprZ7Opu5e1sct+Oubakpry3RraSGEKvh3b/Yk2 XmTQ== 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=61n1rTOQAdXv6eeHPFo5aQPM3i32wSF+GJxCdH9J8Zk=; b=E2B+yU7REhvroacmLDEcZQngYe7+cASYQ/LqwHrQc2sIsEkdTucgJp0CWc3NI/yIx7 950i7UYDvpEg3BVC7xDVVZOywRAXrudY2ElP8Xe/m7YqKpb5L4U9nvGZl0iaxy0XSD4E jW9pqvvlF+6vKJSBjIe9B3aVJeUl8NoqIbv+zFN1O+OyzaI3R7W54R9eBCLda5VFucbS EVTOk3jzlcEZOLsirt2/ppQnH9kSz/u8DlyzXlmtFpAiqANkrNaPGF2RfwQF1ZF4EYiF FGwt539mBYNOr15WYZFQiJBJE2cqhnUuSDs72OI8u/8fFFfyBeNW9Nt+D+K5KhF8HEsV K7Sg== X-Gm-Message-State: AG10YOShZ+ORJUIyG60idgNy1uKl9SagEL7irLuS+H01DeI7ypwC++kj/LKOZ3Ex/JB3ww== X-Received: by 10.107.12.19 with SMTP id w19mr1863666ioi.114.1454424846352; Tue, 02 Feb 2016 06:54:06 -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 k16sm1216739igf.0.2016.02.02.06.54.04 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 06:54:05 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id f81so19583690iof.0 for ; Tue, 02 Feb 2016 06:54:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr17426142ioe.38.1454424844462; Tue, 02 Feb 2016 06:54:04 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 2 Feb 2016 06:54:04 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D664F2@ESESSMB209.ericsson.se> 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> <7594FB04B1934943A5C02806D1A2204B37D664F2@ESESSMB209.ericsson.se> Date: Tue, 2 Feb 2016 09:54:04 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b47234f591052acaacbc 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: Tue, 02 Feb 2016 14:54:08 -0000 --001a1140b47234f591052acaacbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 2, 2016 at 4:32 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > So, assuming we would define a new attribute to indicate/negotiate > mux-exclusive, I still think we need to say something about a=3Drtcp, don= =E2=80=99t > we? > > > > We could simply say that the a=3Drtcp attribute value must be identical t= o > the port and address for RTP. That would work also for trickle ICE. > > > There is no harm in specifying a=3Drtcp but, in most practical scenarios, i= t will serve no purpose. If legacy end point does not support mux-exclusive, then media connection will be torn down even if the legacy end point does support a=3Drtcp. The a=3Drtcp attribute should still be added for complian= ce with ICE specification and for support of any forwarding or monitoring agents. _____________ Roman Shpount --001a1140b47234f591052acaacbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 2, 2016 at 4:32 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

So, assuming we would define a new attribute= to indicate/negotiate mux-exclusive, I still think we need to say somethin= g about a=3Drtcp, don=E2=80=99t we?

=C2=A0

We could simply say that the = a=3Drtcp attribute value must be identical to the port and address for RTP.= That would work also for trickle ICE.



There is no harm in specifying a=3Drtcp but, in most practical scenarios, = it will serve no purpose. If legacy end point does not support mux-exclusiv= e, then media connection will be torn down even if the legacy end point doe= s support a=3Drtcp. The a=3Drtcp attribute should still be added for compli= ance with ICE specification and for support of any forwarding or monitoring= agents.
_____________
Roman Sh= pount
=C2=A0
--001a1140b47234f591052acaacbc-- From nobody Tue Feb 2 09:42: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 3A8A61B2DCB for ; Tue, 2 Feb 2016 09:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kk43uKTwMBPL for ; Tue, 2 Feb 2016 09:42:03 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1BA1B2DBA for ; Tue, 2 Feb 2016 09:42:03 -0800 (PST) Received: from [82.132.238.118] (port=47652 helo=[172.20.10.3]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aQexl-0006oN-IG for mmusic@ietf.org; Tue, 02 Feb 2016 17:42:01 +0000 From: Colin Perkins Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 2 Feb 2016 17:41:53 +0000 To: mmusic Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Subject: [MMUSIC] Comments on draft-ietf-mmusic-rid-01 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, 02 Feb 2016 17:42:05 -0000 Hi, I very much agree with Christer=E2=80=99s recent comments.=20 In addition, I didn=E2=80=99t find a precise specification in the draft = for what RID parameters constrain what =E2=80=9Ca=3Dfmtp:" parameters, = for what RTP payload formats. I think this draft needs a complete list = of which parameters are constrained by each RID parameter, to ensure = unambiguous behaviour with existing codecs.=20 Also, to ensure consistency going forward, the draft should probably = give some guidance to the PAYLOAD working group, mandating =E2=80=9Ca=3Dfm= tp:=E2=80=9D parameter names for common features when defining future = payload formats, so they match the RID parameter names if they=E2=80=99re = intended to be restricted by RID parameters, and to use different names = otherwise. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Feb 2 14:36: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 4F5E11A0126 for ; Tue, 2 Feb 2016 14:35:59 -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 iKhKn3DtsbRp for ; Tue, 2 Feb 2016 14:35:55 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A35B1A013F for ; Tue, 2 Feb 2016 14:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21238; q=dns/txt; s=iport; t=1454452555; x=1455662155; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rBs4lzSNtL/LY0DCR+/h7lqv8yZ5Cg9itqqFegoqyNc=; b=A9AhcRDjtI2BYzartD4w5SBWc9aez8v2X9QD0P+wrQpOylw2WSK0qJW/ 9e+7u7niWz6gdJ6B/JyfKM0PkdytE6endS1DbAoS7Zx+hZMsrdZCgo8Ls XqfxrQPNkDTl/okExp2taBrZSx0GkvT4LDlcLNbHlpD78CzUk0tY0Tyaf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgDRLrFW/40NJK1UCg6DLFJtiFmxb?= =?us-ascii?q?gENgWQXCoUiSgKBSjgUAQEBAQEBAYEKhEEBAQEDAQEBARcDGy8EAQIEBAgHBAs?= =?us-ascii?q?OAwQBAQEJHgcPAhYfCQgGAQkDBgIBAYgPCA6/MwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEhg+DPHuECASEYAWNJXSIWIdwQ4UYgVuEQoMDI4QUgRqFb4R+g1IeAQF?= =?us-ascii?q?CggMZgQ1ZHi6IMoE5AQEB?= X-IronPort-AV: E=Sophos;i="5.22,386,1449532800"; d="scan'208";a="69618668" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2016 22:35:53 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u12MZqOo005932; Tue, 2 Feb 2016 22:35:53 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> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> From: Flemming Andreasen Message-ID: <56B12F48.409@cisco.com> Date: Tue, 2 Feb 2016 17:35:52 -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: <56AB8596.9090304@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: Tue, 02 Feb 2016 22:35:59 -0000 On 1/29/16 10:30 AM, Paul Kyzivat wrote: > 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. It's not clear to me it's another scope, or at least that the scope is significantly different from having parameters that apply to only certain transports, etc. where we don't do something like this (think MSRP specific parameters, SRTP specific parameters, connection-oriented parameters, etc. - we don't need to specify explicitly how they interact with all other attributes ever defined). > 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. > I'm not concerned about the IANA registration. What I am concerned about is that we are heading down the path of explicitly thinking about and specifying interactions between different attributes. Again, I'm not convinced that it is really necessary here and that you couldn't solve the issue for dcsa with a more algorithmich approach similar to what we did for capability negotiation. Can you (and/or the authors) elaborate on why such an approach would not work ? Thanks -- Flemming > 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 >>> . >>> >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Wed Feb 3 00:57:20 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 5A8FA1A6FC6 for ; Wed, 3 Feb 2016 00:57:19 -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 l5c7wVt0BWZX for ; Wed, 3 Feb 2016 00:57:16 -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 622971A219E for ; Wed, 3 Feb 2016 00:57:16 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-00-56b1c0eaf3fd Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.40.02707.AE0C1B65; Wed, 3 Feb 2016 09:57:14 +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; Wed, 3 Feb 2016 09:57:13 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: mux-exclusive: a=mux-exclusive and a=rtcp-mux in the same m- line? Thread-Index: AdFeYGbEUl5ZALTxRXaQ4UThrGlu1w== Date: Wed, 3 Feb 2016 08:57:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D6C486@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D6C486ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7k+6rAxvDDLZ91LCYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mj5u6WYreGRS8Wz+E6YGxst6XYycHBICJhI3DvSzQNhiEhfu rWfrYuTiEBI4zCjx788kVghnMaPEh1crmLoYOTjYBCwkuv9pgzSICKhLfN3bwwxiCwt4S+yd vIENIh4kce33c1YIW0/i46m/YK0sAioSc9frgpi8Ar4Sm59WgVQwAq39fmoNE4jNLCAucevJ fCaIcwQkluw5zwxhi0q8fPyPFcJWlPj4ah8jRH2+xPfeS2A2r4CgxMmZT1gmMArNQjJqFpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4qTcdCMjvdSizOTi4vw8vbzU kk2MwHg4uOW3wQ7Gl88dDzEKcDAq8fBu+LMhTIg1say4MvcQowQHs5IIr+++jWFCvCmJlVWp RfnxRaU5qcWHGKU5WJTEeVc7rw8TEkhPLEnNTk0tSC2CyTJxcEo1MBZ/9X1hbdbzN//J6Yf8 LY6dSRaShXuv6dd+/fzjuVf6i9SAqVM2PPn3zZOjur/xQcD2hYYSUzsWbX2yqEzyVbD0+R03 XTnUzRZvmxU7TWoRV1Cgve2LtY073ePED8ZespNWyvq/YvXh7WamrStv/+/89erEJcUXbPw3 tbULwxfe7DV3ccnZGanEUpyRaKjFXFScCACNDQJegwIAAA== Archived-At: Subject: [MMUSIC] mux-exclusive: a=mux-exclusive and a=rtcp-mux in the same m- line? 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, 03 Feb 2016 08:57:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D6C486ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One issue is whether it's allowed to include both a=3Dmux-exclusive (or wha= tever we will end up calling it) and a=3Drtcp-mux in the same m- line, as a= =3Drtcp-mux means support of fallback to non-mux. OPTION #1: If one includes a=3Dmux-exclusive, one must also include a=3Drtcp-mux OPTION #2: If one includes a=3Dmux-exclusive, one must not include a=3Drtcp-mux. Now, assuming we'd go for option #2, we would need to change the following = text in BUNDLE: "When an offerer generates an initial offer, the offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled RTP-based "m=3D" line (including any bundle-only "m=3D" line) in the offer." So, we'd have to modify that text, and say that the offerer must include ei= ther a=3Drtcp-mux and a=3Dmux-exclusive (in bundle-only m- line it would al= ways be a=3Dmux-exclusive). Also, if we go for option #2, the question is whether different attributes = can be used for different m- lines within a BUNDLE group. If so, it would i= mpact draft-ietf-mmusic-sdp-mux-attributes, which currently assigns a=3Drtc= p-mux to IDENTICAL. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D6C486ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One issue is whether it’s= allowed to include both a=3Dmux-exclusive (or whatever we will end up call= ing it) and a=3Drtcp-mux in the same m- line, as a=3Drtcp-mux means support= of fallback to non-mux.

 

 

OPTION #1:

 

If one includes a=3Dmux-exclusi= ve, one must also include a=3Drtcp-mux

 

OPTION #2:

 

If one includes a=3Dmux-exclusi= ve, one must not include a=3Drtcp-mux.

 

 

Now, assuming we’d go for= option #2, we would need to change the following text in BUNDLE:

 

   “When an off= erer generates an initial offer, the offerer MUST

   associate an SDP '= rtcp-mux' attribute [RFC5761] with each bundled

   RTP-based "m= =3D" line (including any bundle-only "m=3D" line) in the

   offer.”=

 

So, we’d have to modify t= hat text, and say that the offerer must include either a=3Drtcp-mux and a= =3Dmux-exclusive (in bundle-only m- line it would always be a=3Dmux-exclusi= ve).

 

 

Also, if we go for option #2, t= he question is whether different attributes can be used for different m- li= nes within a BUNDLE group. If so, it would impact draft-ietf-mmusic-sdp-mux= -attributes, which currently assigns a=3Drtcp-mux to IDENTICAL.

 

 

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D6C486ESESSMB209erics_-- From nobody Wed Feb 3 01:09:37 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 E738B1A701C; Wed, 3 Feb 2016 01:09: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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203090935.8025.65489.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 01:09:35 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-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: Wed, 03 Feb 2016 09:09:36 -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 Simulcast in SDP and RTP Sessions Authors : Bo Burman Magnus Westerlund Suhas Nandakumar Mo Zanaty Filename : draft-ietf-mmusic-sdp-simulcast-04.txt Pages : 27 Date : 2016-02-03 Abstract: In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-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 Wed Feb 3 01:47: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 BFFBF1A884E for ; Wed, 3 Feb 2016 01:47:35 -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 fV_Y05UiM5kC for ; Wed, 3 Feb 2016 01:47: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 823DD1A884B for ; Wed, 3 Feb 2016 01:47:33 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-04-56b1ccb3c858 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2A.46.05041.3BCC1B65; Wed, 3 Feb 2016 10:47:31 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.156]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Wed, 3 Feb 2016 10:47:31 +0100 From: Bo Burman To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-simulcast-04.txt Thread-Index: AQHRXmKgFd2bqaJtlkWlg+RiWeCX8Z8aEgGg Date: Wed, 3 Feb 2016 09:47:30 +0000 Message-ID: References: <20160203090935.8025.65489.idtracker@ietfa.amsl.com> In-Reply-To: <20160203090935.8025.65489.idtracker@ietfa.amsl.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7iu7mMxvDDBb/FbGYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mv7uvsNScFii4tQUjQbGj0JdjJwcEgImEnMn3mWGsMUkLtxb z9bFyMUhJHCYUeLGvstMIAkhgcWMEvOPaoHYbAIaEvN33GUEsUUE1CW+7u0BaubgEBawl5hz 0BMi7CBx4PoVsLCIgJHErquxICaLgIrEhpshIBW8Ar4Sp892s0IMd5A4uOAoC4jNKeAoceTg R7DhjAKyEve/3wOLMwuIS9x6Mp8J4koBiSV7zkNdLCrx8vE/VpDxEgKKEsv75SDKdSQW7P7E BmFrSyxb+JoZYq2gxMmZT1gmMIrOQjJ1FpKWWUhaZiFpWcDIsopRtDi1uDg33chIL7UoM7m4 OD9PLy+1ZBMjMBIObvlttYPx4HPHQ4wCHIxKPLwb/mwIE2JNLCuuzD3EKMHBrCTC+/f4xjAh 3pTEyqrUovz4otKc1OJDjNIcLErivGuc14cJCaQnlqRmp6YWpBbBZJk4OKUaGCO7VA/UFtXF Gl3K32WtVyYRcEr/Y1Je8M0y0dBO0Zyc8ufp6rkq4Qszt/6JY79090tDdqtVnOl2nV5W4x0/ N8UZsL6Rqru17M2iXXvfpHxZXi50nk1vs/RblTVTp/w7yHb9v2FfnqZZtondGmbTxeWLXyke cI2r/yR3h1Xxkc6UlX8MAwOnKbEUZyQaajEXFScCAHM1lOuAAgAA Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 09:47:35 -0000 This new version contains the following changes: o Changed to only use RID identification, as was consensus during IETF 94. o ABNF improvements. o Clarified offer-answer rules for initially paused streams. o Changed references for RTP topologies and RTP taxonomy documents that are now published as RFC. o Added reference to the new RID draft in AVTEXT. o Re-structured section 6 to provide an easy reference by the updated IANA section. o Added a sub-section 7.1 with a discussion of bitrate adaptation. o Editorial improvements. /Bo (as individual) > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 3 februari 2016 10:10 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: I-D Action: draft-ietf-mmusic-sdp-simulcast-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control W= orking Group of the IETF. >=20 > Title : Using Simulcast in SDP and RTP Sessions > Authors : Bo Burman > Magnus Westerlund > Suhas Nandakumar > Mo Zanaty > Filename : draft-ietf-mmusic-sdp-simulcast-04.txt > Pages : 27 > Date : 2016-02-03 >=20 > Abstract: > In some application scenarios it may be desirable to send multiple > differently encoded versions of the same media source in different > RTP streams. This is called simulcast. This document describes how > to accomplish simulcast in RTP and how to signal it in SDP. The > described solution uses an RTP/RTCP identification method to identify > RTP streams belonging to the same media source, and makes an > extension to SDP to relate those RTP streams as being different > simulcast formats of that media source. The SDP extension consists > of a new media level SDP attribute that expresses capability to send > and/or receive simulcast RTP streams. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-simulcast-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Wed Feb 3 07:21:17 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 2578A1ACE1E; Wed, 3 Feb 2016 07:21:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203152115.2958.57905.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 07:21:15 -0800 Archived-At: Cc: mmusic-chairs@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Brian Haberman's No Objection 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: Wed, 03 Feb 2016 15:21:15 -0000 Brian Haberman has entered the following ballot position for charter-ietf-mmusic-03-00: No Objection 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: ---------------------------------------------------------------------- Was any thought given to advancing the base specifications to Internet Standard? From nobody Wed Feb 3 07:31: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 B06451ACE3D; Wed, 3 Feb 2016 07:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5Jn4vdKYAzwL; Wed, 3 Feb 2016 07:31:37 -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 F0B4E1ACDFF; Wed, 3 Feb 2016 07:31:36 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13FVUbK014804 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Feb 2016 09:31:31 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37D669A1@ESESSMB209.ericsson.se> From: Adam Roach Message-ID: <56B21D52.6060002@nostrum.com> Date: Wed, 3 Feb 2016 09:31:30 -0600 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: <7594FB04B1934943A5C02806D1A2204B37D669A1@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------030206090103020300090306" Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: Re: [MMUSIC] Initial comments on draft-ietf-mmusic-rid-01 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, 03 Feb 2016 15:31:43 -0000 This is a multi-part message in MIME format. --------------030206090103020300090306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/2/16 06:15, Christer Holmberg wrote: > I was asked to take a look at the RID draft. Thanks for a really quick turnaround on reviewing it! What would be really helpful is input on the explicitly-called-out open issues. > GENERAL: > > ------------ > > Q_G_1: > > Please pay attention to usage of consistent terminology. > > For example, I see “a= lines”, “a= parameters”, “a= attributes” type > of terminology… > I think this is consistent already, with one exception (which will be fixed in -02). If you can point out particular instances that are causing issues, I'd appreciate it. To be clear, the phrase '"a=rid" line' refers to an entire line; e.g.: a=rid:1 send max-width=1280;max-height=720;max-fps=30 Any reference to a "parameter" refers to a parameter on such a line. For example, "send" in the preceding line. Or "max-fps=30". The only way I think this could be made more clear would be with the addition of a rather superfluous paragraph in the terminology section, along the lines of: "The term 'attribute' is used in this document as having the same meaning as that word in Section 5.13 of [RFC4566]. The term 'line' is used in this document as having the same meaning as that word as used in section 5, and *almost* all of its subsections, in [RFC4566]. The term 'parameter' is used in this document to have its common English meaning, with deep parallels to its use in the 'a-fmtp:' description in section 6 of [RFC4566]." The point, in case it's not clear, is that these terms in the document are being used as they've been used to describe SDP components for decades. > Q_G_2: > > The draft talks a lot about “payload”, “codec”, “format” etc. I think > the draft should contain a definition of those. If they are defined > elsewhere, such text can say e.g.: > > “As defined in [RFCXXXX], payload refers to blah blah blah…” > Again referring to RFC4566, these terms are used freely with no definition or external citation. Are you expecting people to implement this SDP extension without having first understood base SDP? > Q_G_3: > > Is there a risk of conflicts between information provided in a=rid and > a=fmtp/rtpmap? If so, how shall it be treated? > Section 8 exists solely to address this question. What do you believe is missing? > SECTION 1: > > ------------- > > Q_1_1: > > The text says: > > “Payload Type (PT) in RTP provides a mapping between the format of the > > RTP payload and the media format description specified in the > > signaling. For applications that use SDP for signaling, the > > constructs rtpmap and/or fmtp describe the characteristics of the > > media that is carried in the RTP payload, mapped to a given PT.” > > Assuming the scope of the draft is SDP, I think the paragraph can be > shorter, e.g.: > > “Payload Type (PT) in RTP provides a mapping between the RTP > payload format > > and the associated SDP media description. The SDP rtpmap and/or > fmtp attributes > > are used, for a given PT, to the describe the characteristics of > the media that is carried > > in the RTP payload.” > Sure, why not. I've updated accordingly. > Q_1_2: > > The text says: > > “However, the assignment of static mapping of payload > > codes to payload formats and multiplexing of RTP with other protocols > > (such as RTCP) could result in limited number of payload type numbers > > available for the application usage.” > > What is a “payload code”? Shall it be “codec”? > In the language used by RFC 4566, this would be "RTP payload type number". I'll update accordingly. > Q_1_3: > > The text says: > > “and to effectively map a RID RTP Stream to its corresponding > constraints.” > > I know there is a reference for “RID RTP Stream” in the Terminology > section, would I think it would be good to have the reference also in > the Introduction. > Based on this and other previous comments, I'm biting the bullet and moving the terminology section to the front of the document, before the introduction. > Q_1_4: > > The text says: > > “As described in Section 6.2.1, this mechanism achieves backwards > > compatibility via the normal SDP processing rules, which require > > unknown a= parameters to be ignored. This means that implementations > > need to be prepared to handle successful offers and answers from > > other implementations that neither indicate nor honor the constraints > > requested by this mechanism.” > It does. Did you want to comment on it? > SECTION 6: > > ------------- > > Q_6_1: > > The text says: > > “For each media description in the offer,…” > > It should say for each media description that describes RTP based > media, or something like that… > Updated: "For each RTP media description..." > Q_6_2: > > The text says: > > “It MUST generate a "rid-identifier" that is unique within a media > description” > > Later, in section 6.5, the draft says that a new offer with “proposed > changes” should use a new ID value. What about a subsequent RTP > session? Is it ok to re-use the value(s) from the previous session? > Sure, but I think that's pretty self-evident. I can't think of any construct that calls out constraints between non-concurrent RTP sessions. > Q_6_3: > > The text says: > > “The Offerer then chooses zero or more "a=rid" constraints > > (Section 5) to be applied to the rid, and adds them to the > > "a=rid" line.” > > What is meant by “the rid”? > Updated: "...to the the RID RTP Stream..." > Q_6_4: > > In section 6.2.1, the text says: > > “As a result, ignoring the "a=rid" line is always guaranteed to > result in a valid session description.” > > While this is true, a few words about the consequences of the fact > that RID won’t be used is needed. > > For example, if the offerer has indicated some constraints using > a=rid, and the answerer does not support a=rid, does the offerer have > to be prepared to receive media “outside” of those constraints, etc? > > Just saying that unsupported attributes are ignored, but it doesn’t > matter because the SDP will still be valid, is not enough when it > comes to describing the backward compatibility :) > Sure, but this is true regardless of whether the remote endpoint supports "a=rid". It is quite possible that the result of applying the rules in the "answer" section results in any given m-section containing zero "a=rid" lines. I've added text to the "Offerer Processing of the SDP Answer" section: It is important to note that there are several ways in which an offer can contain a media section with "a=rid" lines, but the corresponding media section in the response does not. This includes situations in which the answerer does not support "a=rid" at all, or does not support the indicated constraints. Under such circumstances, the offerer MUST be prepared to receive a media stream to which no constraints have been applied. > Q_6_5: > > In section 6.3, the text says: > > “Having performed verification of the SDP offer as described” > > I assume something is missing behind “described”? > > I guess the answer to the question above may clarify it, but what is > meant by “verification”? > It's referring to the immediately preceding section, which uses the word "verify" several times. For absolute clarity, I've updated its initial paragraph to include the word "verification": If the answerer supports the "a=rid" attribute, the following verification steps are executed, in order, for each "a=rid" line in a given media description: And I've explicitly cited it in the sentence you point out: Having performed verification of the SDP offer as described in Section 6.2.2, the answerer shall perform the following steps to generate the SDP answer. > Q_6_6: > > In section 6.4, I see a mix of “MUSTs” and “SHALLs”, but I can’t > really see the difference. > I suppose that's good, since RFC2119 defines them to have no difference. MUST, SHALL, and REQUIRED all indicate the same normative level. This is kind of nice, since it allows authors to choose among several terms according to which one flows better in the sentence. > Q_6_7: > > In section 6.4, the text talks about cases where “the offerer shall > consider the a= line as rejected”. > > It is unclear whether it is meant to mean that the answerer rejected > the a= line (which I agree would be a little strange), or if the > offerer shall reject the a= line. > > Assuming it’s the offerer, I think it would be more clear the say “the > offerer shall reject the a= line”. > > I also think it would be better to say “discard” instead of “reject”, > because “reject” often means that some additional action is taken, > which I assume is not the case here. > Agreed. I've changed these to use language along the lines of "...shall discard the 'a=rid' line." I'll have an -02 version out shortly with these changes incorporated. /a --------------030206090103020300090306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/2/16 06:15, Christer Holmberg wrote:
I was asked to take a look at the RID draft.

Thanks for a really quick turnaround on reviewing it!

What would be really helpful is input on the explicitly-called-out open issues.

GENERAL:

------------

 

Q_G_1:

 

Please pay attention to usage of consistent terminology.

 

For example, I see “a= lines”, “a= parameters”, “a= attributes” type of terminology…


I think this is consistent already, with one exception (which will be fixed in -02). If you can point out particular instances that are causing issues, I'd appreciate it.

To be clear, the phrase '"a=rid" line' refers to an entire line; e.g.:

a=rid:1 send max-width=1280;max-height=720;max-fps=30

Any reference to a "parameter" refers to a parameter on such a line. For example, "send" in the preceding line. Or "max-fps=30".

The only way I think this could be made more clear would be with the addition of a rather superfluous paragraph in the terminology section, along the lines of:

"The term 'attribute' is used in this document as having the same meaning as that word in Section 5.13 of [RFC4566]. The term 'line' is used in this document as having the same meaning as that word as used in section 5, and *almost* all of its subsections, in [RFC4566]. The term 'parameter' is used in this document to have its common English meaning, with deep parallels to its use in the 'a-fmtp:' description in section 6 of [RFC4566]."
The point, in case it's not clear, is that these terms in the document are being used as they've been used to describe SDP components for decades.

 

Q_G_2:

 

The draft talks a lot about “payload”, “codec”, “format” etc. I think the draft should contain a definition of those. If they are defined elsewhere, such text can say e.g.:

 

   “As defined in [RFCXXXX], payload refers to blah blah blah…”


Again referring to RFC4566, these terms are used freely with no definition or external citation. Are you expecting people to implement this SDP extension without having first understood base SDP?

Q_G_3:

 

Is there a risk of conflicts between information provided in a=rid and a=fmtp/rtpmap? If so, how shall it be treated?


Section 8 exists solely to address this question. What do you believe is missing?

SECTION 1:

-------------

 

Q_1_1:

 

The text says:

 

   “Payload Type (PT) in RTP provides a mapping between the format of the

   RTP payload and the media format description specified in the

   signaling.  For applications that use SDP for signaling, the

   constructs rtpmap and/or fmtp describe the characteristics of the

   media that is carried in the RTP payload, mapped to a given PT.”

 

Assuming the scope of the draft is SDP, I think the paragraph can be shorter, e.g.:

 

   “Payload Type (PT) in RTP provides a mapping between the RTP payload format

   and the associated SDP media description. The SDP rtpmap and/or fmtp attributes

   are used, for a given PT, to the describe the characteristics of the media that is carried

   in the RTP payload.”


Sure, why not. I've updated accordingly.

 Q_1_2:

 

The text says:

 

   “However, the assignment of static mapping of payload

   codes to payload formats and multiplexing of RTP with other protocols

   (such as RTCP) could result in limited number of payload type numbers

   available for the application usage.”

 

What is a “payload code”? Shall it be “codec”?


In the language used by RFC 4566, this would be "RTP payload type number". I'll update accordingly.

Q_1_3:

 

The text says:

 

   “and to effectively map a RID RTP Stream to its corresponding constraints.”

 

I know there is a reference for “RID RTP Stream” in the Terminology section, would I think it would be good to have the reference also in the Introduction.


Based on this and other previous comments, I'm biting the bullet and moving the terminology section to the front of the document, before the introduction.

Q_1_4:

 

The text says:

 

   “As described in Section 6.2.1, this mechanism achieves backwards

   compatibility via the normal SDP processing rules, which require

   unknown a= parameters to be ignored.  This means that implementations

   need to be prepared to handle successful offers and answers from

   other implementations that neither indicate nor honor the constraints

   requested by this mechanism.”



It does. Did you want to comment on it?


SECTION 6:

-------------

 

Q_6_1:

 

The text says:

 

    “For each media description in the offer,…”

 

It should say for each media description that describes RTP based media, or something like that…


Updated: "For each RTP media description..."

 Q_6_2:

 

The text says:

 

    “It MUST generate a "rid-identifier" that is unique within a media description”

 

Later, in section 6.5, the draft says that a new offer with “proposed changes” should use a new ID value. What about a subsequent RTP session? Is it ok to re-use the value(s) from the previous session?


Sure, but I think that's pretty self-evident. I can't think of any construct that calls out constraints between non-concurrent RTP sessions.

 Q_6_3:

 

The text says:

 

   “The Offerer then chooses zero or more "a=rid" constraints

   (Section 5) to be applied to the rid, and adds them to the

    "a=rid" line.”

 

What is meant by “the rid”?


Updated: "...to the the RID RTP Stream..."

 Q_6_4:

 

In section 6.2.1, the text says:

 

   “As a result, ignoring the "a=rid" line is always guaranteed to result in a valid session description.”

 

While this is true, a few words about the consequences of the fact that RID won’t be used is needed.

 

For example, if the offerer has indicated some constraints using a=rid, and the answerer does not support a=rid, does the offerer have to be prepared to receive media “outside” of those constraints, etc?

 

Just saying that unsupported attributes are ignored, but it doesn’t matter because the SDP will still be valid, is not enough when it comes to describing the backward compatibility :)


Sure, but this is true regardless of whether the remote endpoint supports "a=rid". It is quite possible that the result of applying the rules in the "answer" section results in any given m-section containing zero "a=rid" lines. I've added text to the "Offerer Processing of the SDP Answer" section:

It is important to note that there are several ways in which an offer can
contain a media section with "a=rid" lines, but the corresponding media
section in the response does not. This includes situations in which the
answerer does not support "a=rid" at all, or does not support the indicated
constraints. Under such circumstances, the offerer MUST be prepared to
receive a media stream to which no constraints have been applied.


 Q_6_5:

 

In section 6.3, the text says:

 

    “Having performed verification of the SDP offer as described”

 

I assume something is missing behind “described”?

 

I guess the answer to the question above may clarify it, but what is meant by “verification”?


It's referring to the immediately preceding section, which uses the word "verify" several times. For absolute clarity, I've updated its initial paragraph to include the word "verification":

If the answerer supports the "a=rid" attribute, the following verification
steps are executed, in order, for each "a=rid" line in a given media
description:
And I've explicitly cited it in the sentence you point out:

   Having performed verification of the SDP offer as described in
   Section 6.2.2, the answerer shall perform the following steps to
   generate the SDP answer.


 Q_6_6:

 

In section 6.4, I see a mix of “MUSTs” and “SHALLs”, but I can’t really see the difference.


I suppose that's good, since RFC2119 defines them to have no difference.

MUST, SHALL, and REQUIRED all indicate the same normative level. This is kind of nice, since it allows authors to choose among several terms according to which one flows better in the sentence.

 Q_6_7:

 

In section 6.4, the text talks about cases where “the offerer shall consider the a= line as rejected”.

 

It is unclear whether it is meant to mean that the answerer rejected the a= line (which I agree would be a little strange), or if the offerer shall reject the a= line.

 

Assuming it’s the offerer, I think it would be more clear the say “the offerer shall reject the a= line”.

 

I also think it would be better to say “discard” instead of “reject”, because “reject” often means that some additional action is taken, which I assume is not the case here.


Agreed. I've changed these to use language along the lines of "...shall discard the 'a=rid' line."

I'll have an -02 version out shortly with these changes incorporated.

/a

--------------030206090103020300090306-- From nobody Wed Feb 3 08:14:27 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 871ED1AD2D5 for ; Wed, 3 Feb 2016 08:14:26 -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 Pah0j7q9H1QN for ; Wed, 3 Feb 2016 08:14:21 -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 7535E1AD2AF for ; Wed, 3 Feb 2016 08:14:21 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13GEFBK019574 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Feb 2016 10:14:16 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins , mmusic References: From: Adam Roach Message-ID: <56B22757.9090906@nostrum.com> Date: Wed, 3 Feb 2016 10:14:15 -0600 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: 8bit Archived-At: Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-01 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, 03 Feb 2016 16:14:26 -0000 On 2/2/16 11:41, Colin Perkins wrote: > I didn’t find a precise specification in the draft for what RID parameters constrain what “a=fmtp:" parameters, for what RTP payload formats. I think this draft needs a complete list of which parameters are constrained by each RID parameter, to ensure unambiguous behaviour with existing codecs. I fear such an approach may be intractable. On a quick analysis, I find almost 100 RFCs that define "a=fmtp" parameters, and most of those define more than one. If you want to volunteer to slog through that entire corpus and figure out which correspond to the constraints we're defining, I'll happily accept the output of that work. But I suspect you'll reach the same conclusion as I did: it's not a reasonable task. That said, the principle here is pretty easy to grasp: when the "a=fmtp" parameters constrain your encoding in some way, and the "a=rid" parameters also constrain your encoding in some way, you need to meet both constraints simultaneously. If you think there's some text we can add to Section 9 to clarify this principle, I'm happy to expound on it. But I'm pretty certain that the future-proof approach here is to lay out a principle of interaction, rather than (for example) spending the energy to figure out how the "pgroup" parameter for SMPTE 292M might interact with any of the constraints we're defining, and then doing that same kind of analysis hundreds of times over. > Also, to ensure consistency going forward, the draft should probably give some guidance to the PAYLOAD working group, mandating “a=fmtp:” parameter names for common features when defining future payload formats, so they match the RID parameter names if they’re intended to be restricted by RID parameters, and to use different names otherwise. Trying to harmonize PAYLOAD's handling of seems to be somewhat outside the scope of what this document is doing. I mean, I get that the lack of coordination of constraining parameters on video codecs is a pretty sad state of affairs, but it's not really fair to shackle this draft to the task of solving that mess before it can move forward. To be clear, I'd be happy to see some kind of guidance regarding put forth in an independent document so that there is at least a modicum of uniformity for future formats. I just think it's not in the scope of the RID work. /a From nobody Wed Feb 3 08:43: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 395A91B29F5 for ; Wed, 3 Feb 2016 08:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 18l8MatjJLlc for ; Wed, 3 Feb 2016 08:43:26 -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 035951B29F4 for ; Wed, 3 Feb 2016 08:43:26 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id ik10so90374444igb.1 for ; Wed, 03 Feb 2016 08:43:25 -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=7TPL//1XhX1uy6S3UyaPBX74MaTQsG4L+6QhuHzxDbI=; b=OFjBTOLX9pM5znt/88AgE2M/W7ftxlmi/1aBTiyM7LOXngd4+zEFB5vpHHSNMYbIaE ADVo5SXXERnK+c/fZ59bHwAFpE2NhbO1qzldOWfIrmiv+OT5Rifdc7ASitgu0LsdACMX cHajJEr0n2O14Th26/IWwHLY+64kiyaa1ivxOoFwVyom5HFYQhrAmE5DbIeQHwVEvqxW Q1B9+dwhYnl5ZeF9Z0padphFMXerbelF7qFh3oA6Km6FQ3GcfY3BwSrLTSch2gXBXKOY W8NsJp8Yh4unkxIyVgVwLuP12FMQXWRsILACVKAHWz1fHjZl/HKEn38P7tYnzNZpP9V7 xIYg== 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=7TPL//1XhX1uy6S3UyaPBX74MaTQsG4L+6QhuHzxDbI=; b=MaeMLgR/eotK4b2h4PWOYUayufebGl1Hpc/bH82i/S/PvNlu1QvV9D3OdEZiBnapP8 e7Flkic7yaSJRZx6FTCEhn4mLb1Kz/MMLhIEhf3TW6I5FP6kvq7PiM8OpgQuy1IcGrCw cSlJkm+9yxJrkjmx2Sewb+KxkWsedc/U5uMj/kniBv5NtF+5cJ4Tsppdf9uLRUw7UswY tMvgNxAxwriPvO9x7ORJJVRhu/V3m6B6Pzc0n0oynAInJ6j2IXW77nqpXD/IKetWT7ay NgOVNE02xNxx9JC5x1SbDzfyWOid83ykjrTRvT01X+HcGL12ydARTYQfbORp95TU3APh RJgQ== X-Gm-Message-State: AG10YORbuchlTnJPngtPXENkdZ7KkE/ikS1Y8tnOTeDQMBbn2hR/ZqSc2LH6MTKBs8ydBg== X-Received: by 10.50.61.145 with SMTP id p17mr24482391igr.28.1454517805325; Wed, 03 Feb 2016 08:43:25 -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 p8sm3222253ioe.38.2016.02.03.08.43.23 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 08:43:23 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id 9so61890145iom.1 for ; Wed, 03 Feb 2016 08:43:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.14.72 with SMTP id 69mr4448105ioo.145.1454517803123; Wed, 03 Feb 2016 08:43:23 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 3 Feb 2016 08:43:23 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D6C486@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D6C486@ESESSMB209.ericsson.se> Date: Wed, 3 Feb 2016 11:43:23 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113fcf0ef98a32052ae0507d Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] mux-exclusive: a=mux-exclusive and a=rtcp-mux in the same m- line? 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, 03 Feb 2016 16:43:27 -0000 --001a113fcf0ef98a32052ae0507d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 3, 2016 at 3:57 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > One issue is whether it=E2=80=99s allowed to include both a=3Dmux-exclusi= ve (or > whatever we will end up calling it) and a=3Drtcp-mux in the same m- line,= as > a=3Drtcp-mux means support of fallback to non-mux. > > > > OPTION #1: > > > > If one includes a=3Dmux-exclusive, one must also include a=3Drtcp-mux > > > > OPTION #2: > > > > If one includes a=3Dmux-exclusive, one must not include a=3Drtcp-mux. > > > Do we allow to setup a media session if end point sends an offer with a=3Dmux-exclusive and a=3Drtcp-mux and gets the answer back with a=3Drtcp-m= ux only? Regards, _____________ Roman Shpount --001a113fcf0ef98a32052ae0507d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 3, 2016 at 3:57 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

One issue is whether it=E2=80=99s allowed to include= both a=3Dmux-exclusive (or whatever we will end up calling it) and a=3Drtc= p-mux in the same m- line, as a=3Drtcp-mux means support of fallback to non= -mux.

=C2=A0

OPTION #1:=

=C2=A0

If one includes a=3Dmux-exclusi= ve, one must also include a=3Drtcp-mux

=C2=A0

OPTION #2:=

=C2=A0

If one includes a=3Dmux-exclusi= ve, one must not include a=3Drtcp-mux.



Do we allow to setup a media session if end point sends an offer with a=3D= mux-exclusive and a=3Drtcp-mux and gets the answer back with a=3Drtcp-mux o= nly?

Regards,
_____________
Roman Shpount
=C2=A0
--001a113fcf0ef98a32052ae0507d-- From nobody Wed Feb 3 09:21:41 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 594CA1B3541; Wed, 3 Feb 2016 09:21:33 -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 c2TgnIyovNeg; Wed, 3 Feb 2016 09:21:32 -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 A4F351B3540; Wed, 3 Feb 2016 09:21:31 -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 u13HLTVn027017 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Feb 2016 11:21:30 -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: "Brian Haberman" Date: Wed, 03 Feb 2016 11:21:29 -0600 Message-ID: In-Reply-To: <20160203152115.2958.57905.idtracker@ietfa.amsl.com> References: <20160203152115.2958.57905.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: mmusic-chairs@ietf.org, The IESG , mmusic@ietf.org Subject: Re: [MMUSIC] Brian Haberman's No Objection on charter-ietf-mmusic-03-00: (with COMMENT) 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, 03 Feb 2016 17:21:33 -0000 On 3 Feb 2016, at 9:21, Brian Haberman wrote: > Was any thought given to advancing the base specifications to Internet > Standard? Not really. This was mainly a restructuring of existing work. Advancing to internet-standard is worth discussion, but I think it would be better left for a separate charter exercise. (The dependency map for this stuff in pretty crazy.) Ben. From nobody Wed Feb 3 09:38: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 DB34B1A8A8D for ; Wed, 3 Feb 2016 09:38:38 -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 tcFrvNEPXTw2 for ; Wed, 3 Feb 2016 09:38:37 -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 514971A86EF for ; Wed, 3 Feb 2016 09:38:37 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-40-56b23b1b8022 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5D.E9.05041.B1B32B65; Wed, 3 Feb 2016 18:38:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Wed, 3 Feb 2016 18:38:35 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] mux-exclusive: a=mux-exclusive and a=rtcp-mux in the same m- line? Thread-Index: AdFeYGbEUl5ZALTxRXaQ4UThrGlu1wAOTZiAAAPylxA= Date: Wed, 3 Feb 2016 17:38:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D6D954@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D6C486@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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdT1faelOYwZyHihZTlz9msZhxYSqz A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyji84TVbQR9Xxcu15xgbGN9wdjFyckgImEj8 eLyOGcIWk7hwbz1bFyMXh5DAYUaJL4vns0I4ixklnq7Yz97FyMHBJmAh0f1PG6RBREBV4u/3 yUwgYWYBdYmri4NAwsICURInDjWxgYRFBKIl1j3ygDCtJJ7PLgKpYBFQkfi5ah87iM0r4Ctx adZaFohFUxglejvWMoEkOAUCJV63PgA7jRHotO+n1oDFmQXEJW49mc8EcbKAxJI956HOF5V4 +fgfK4StJLHo9meoyzQl1u/Sh2hVlJjS/RBqr6DEyZlPWCYwis1CMnUWQscsJB2zkHQsYGRZ xShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYNQe3/LbawXjwueMhRgEORiUe3g1/NoQJsSaW FVfmHmKU4GBWEuF9arQpTIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvGuf1YUIC6YklqdmpqQWp RTBZJg5OqQZGg73L729pbXgXJ5D4utP+crL+m9PfvLyPVlzdyiO0deW/8qyDj01WZ/7l3qC0 dNI0G4a4zqkK5uInxNWszde++2HVttpI7eVO7sL+iVffbI0umiP4cp6zrUnDXeHdx7RXTwp9 dNN2z9TWkzE+qTJsp5cssftsHfFyS3drt/aph8aP59WzhuzUV2Ipzkg01GIuKk4EANZ9toOW AgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] mux-exclusive: a=mux-exclusive and a=rtcp-mux in the same m- line? 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, 03 Feb 2016 17:38:39 -0000 SGksDQoNCj4+T25lIGlzc3VlIGlzIHdoZXRoZXIgaXTigJlzIGFsbG93ZWQgdG8gaW5jbHVkZSBi b3RoIGE9bXV4LWV4Y2x1c2l2ZSAob3Igd2hhdGV2ZXIgd2Ugd2lsbCBlbmQgdXAgY2FsbGluZyBp dCkgYW5kIGE9cnRjcC1tdXggaW4gdGhlIHNhbWUgbS0gbGluZSwgYXMgYT1ydGNwLW11eCBtZWFu cyBzdXBwb3J0IG9mIGZhbGxiYWNrIHRvIG5vbi1tdXguDQo+Pg0KPj5PUFRJT04gIzE6DQo+Pg0K Pj5JZiBvbmUgaW5jbHVkZXMgYT1tdXgtZXhjbHVzaXZlLCBvbmUgbXVzdCBhbHNvIGluY2x1ZGUg YT1ydGNwLW11eA0KPj7CoA0KPj5PUFRJT04gIzI6DQo+PsKgDQo+PklmIG9uZSBpbmNsdWRlcyBh PW11eC1leGNsdXNpdmUsIG9uZSBtdXN0IG5vdCBpbmNsdWRlIGE9cnRjcC1tdXguDQo+DQo+DQo+ IERvIHdlIGFsbG93IHRvIHNldHVwIGEgbWVkaWEgc2Vzc2lvbiBpZiBlbmQgcG9pbnQgc2VuZHMg YW4gb2ZmZXIgd2l0aCBhPW11eC1leGNsdXNpdmUgYW5kIGE9cnRjcC1tdXggYW5kIGdldHMgdGhl IGFuc3dlciBiYWNrIHdpdGggYT1ydGNwLW11eCBvbmx5Pw0KDQpJIHRoaW5rIHdlIHNob3VsZCAt IGJlY2F1c2UgdGhhdCBtZWFucyB0aGF0IHRoZSBhbnN3ZXJlciBhZ3JlZXMgdG8gZG8gbXV4Lg0K DQpBbmQsIHRoYXQgaXMgcGVyaGFwcyBhIGdvb2QganVzdGlmaWNhdGlvbiBmb3Igb3B0aW9uICMx LCBiZWNhdXNlIGl0IGFsbG93cyB0byBuZWdvdGlhdGUgbXV4IGV2ZW4gaWYgdGhlIGFuc3dlcmVy IGRvZXMgbm90IHN1cHBvcnQgYT1tdXgtZXhjbHVzaXZlLiBCZWNhdXNlLCBubyBtYXR0ZXIgaWYg d2UgaW5jbHVkZSBhPXJ0Y3AtbXV4IG9yIG5vdCwgaWYgdGhlIGFuc3dlcmVyIGRvZXNuJ3QgaW5k aWNhdGUgbXV4IGluIHRoZSBhbnN3ZXIgdGhlIG9mZmVyZXIgd2lsbCBoYXZlIHRvIHRha2UgYWN0 aW9ucy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Wed Feb 3 10:39: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 A9E621B2AF2 for ; Wed, 3 Feb 2016 10:39:37 -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 fM5yvplWelmj for ; Wed, 3 Feb 2016 10:39:36 -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 8E7F71B2AED for ; Wed, 3 Feb 2016 10:39:36 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13IdW3U035600 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Feb 2016 12:39:33 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins , mmusic References: <56B22757.9090906@nostrum.com> From: Adam Roach Message-ID: <56B24964.8060303@nostrum.com> Date: Wed, 3 Feb 2016 12:39:32 -0600 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: <56B22757.9090906@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-01 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, 03 Feb 2016 18:39:37 -0000 On 2/3/16 10:14, Adam Roach wrote: > If you think there's some text we can add to Section 9... Sorry, I meant Section 8. /a From nobody Wed Feb 3 11:08:34 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 8C2B31B2B62; Wed, 3 Feb 2016 11:08:33 -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: <20160203190833.8564.40469.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 11:08:33 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 19:08:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : RTP Payload Format Constraints Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-02.txt Pages : 22 Date : 2016-02-03 Abstract: In this specification, we define a framework for identifying RTP Streams with the constraints on its payload format in the Session Description Protocol. This framework defines a new "rid" SDP attribute to: a) effectively identify the RID RTP Streams within a RTP Session, b) constrain their payload format parameters in a codec- agnostic way beyond what is provided with the regular Payload Types and c) enable unambiguous mapping between the RID RTP Streams to their media format specification in the SDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 3 11:13: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 E5E561B2B6D for ; Wed, 3 Feb 2016 11:13:32 -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 aH1CWqySQ-mB for ; Wed, 3 Feb 2016 11:13:31 -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 F03CD1B2B6C for ; Wed, 3 Feb 2016 11:13:30 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with comcast id Dv9Z1s0032JGN3p01vDWpz; Wed, 03 Feb 2016 19:13:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id DvDV1s00Q3KdFy101vDVdZ; Wed, 03 Feb 2016 19:13:30 +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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> From: Paul Kyzivat Message-ID: <56B25159.70002@alum.mit.edu> Date: Wed, 3 Feb 2016 14:13: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: <56B12F48.409@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=1454526810; bh=O3W5PHrZE3o3lmJxn0oYQ3AmataJMfYpc1URJf7e0C4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aa8y2bX2zKlUXjqGl0iWcDYJt7hogmOrdU4ZPOwJAC/z2JPbhdjCF+GNHzv6cWSev 6ozgrVgT3J2MktZ+fZoUddRJ7jKJ7xXtv+Zg18yZ1nYIp0SZWeqJC5Wf4aKKA7IxqB AODwZ//1mrM0JIPliGs0SYej8LrIGffirflsh+/Dslt8v1XECjZ49PxHntfCTuaOng SbpqIfDZJOJ+fLYKguwW+wFbx8Vh2lly69PqYV1KJIhfqrMowon8MJ/WBbBCde1dyX x5SYiA2Oq4ppFxsfOt9VX6j99V8z+lq1exgeDkOxKaegXTZFyKDRrvdkcfiS9gYFz1 YD3LElSohh3Nw== 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: Wed, 03 Feb 2016 19:13:33 -0000 On 2/2/16 5:35 PM, Flemming Andreasen wrote: > > > On 1/29/16 10:30 AM, Paul Kyzivat wrote: >> 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. >> > I'm not concerned about the IANA registration. What I am concerned about > is that we are heading down the path of explicitly thinking about and > specifying interactions between different attributes. Again, I'm not > convinced that it is really necessary here and that you couldn't solve > the issue for dcsa with a more algorithmich approach similar to what we > did for capability negotiation. Are you referring to: When the attribute capability contains a session-level attribute, that "acap" attribute can only be provided at the session level. Conversely, media-level attributes can be provided in attribute capabilities at either the media level or session level. The base I don't see the parallel. capneg is really a "macro" mechanism, so it is really up to the user to ensure that all possible expansions of a macro are valid. But I see a direct analogy to the a=ssrc attribute. That one also is an attribute that recursively contains another attribute. But not all attributes "work" (or make sense) with a=ssrc. Only those whose effect can be narrowed to a particular RTP stream are valid. So it established a registry for those that do work with it. The a=dcsa attribute is very similar to that. Again not every attribute works with it. Only those that can be applied to a particular data channel apply. Rather than keeping separate registries for session level, media level, and "source" (a=ssrc) level, we have agreed to merge them and add a column to indicate which level(s) apply to each attribute. That makes it easier to add yet another (dcsa) "level". > Can you (and/or the authors) elaborate on why such an approach would not > work ? It isn't strictly necessary to have this information in IANA. It would be sufficient to have it in the documents that define each attribute. (As long as they really do have it.) And, if it was there and not in the registry, then each document could decide whether applicability can be specified via an algorithm, or if it must be done by enumeration. But, if that is the case, then it should apply for all the distinct contexts where attributes might be used: session level, media level, source level, dcsa level, and capneg level. (Every distinct place that can appear.) And there is a downside to this. Each time a new "level" is defined (e.g., when a=dcsa is defined) then either it has to provide a rule for every attribute, current and future, or else the definition of every attribute, current and future, will need to specify applicability to this new level. Consider a=ssrc. When some new attribute is defined, will it be usable with a=ssrc? Without the registry, how would anyone find out? Thanks, Paul From nobody Wed Feb 3 12:03: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 8A7141B2C02 for ; Wed, 3 Feb 2016 12:03:42 -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 D1611TpqHvdh for ; Wed, 3 Feb 2016 12:03:41 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6006C1B2C03 for ; Wed, 3 Feb 2016 12:03:41 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-11v.sys.comcast.net with comcast id Dw2P1s0044tLnxL01w3g34; Wed, 03 Feb 2016 20:03:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-02v.sys.comcast.net with comcast id Dw3g1s0023KdFy101w3gUx; Wed, 03 Feb 2016 20:03:40 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37D437CC@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56B25D1A.6030407@alum.mit.edu> Date: Wed, 3 Feb 2016 15:03:38 -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: <7594FB04B1934943A5C02806D1A2204B37D437CC@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=1454529820; bh=2kPlSSA3D+PYyw7fCtuBLNDjzKpJ7mDURe1SzxNStOQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=U4Jid1GSLXaigeBWFYHFe3kIx0CPac5hq0A2If2ZGqbX+mP7iVhBF9gSVvquyp4y5 J3DFlptUOcSg/oF8jcdSlmPZgjr/aYmiHKfJLwSfLMziLdFAu9AMfumT1g92HPbuB5 UP7FZRmevnZhPgTVHUq345vcqvQ7CH+xKclBQm7tohaHvFtJXIQ+XGTu931bCGRrhx 2jYvNtIxccW2TizJ97SvyhrzfHGXt6nV4KRmQS4MAjzET/Mm54pdSB1rHnJZ528mP+ Y24OXcB8P3wEvAcvunwC3oUTvs2XjSMWKIZ5MXB7/fHnrRbWqr/kDeh4uVxQcQ2nOP +WKEC3366d4wQ== Archived-At: Subject: Re: [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: Wed, 03 Feb 2016 20:03:42 -0000 I reviewed this and think it is ready for WGLC. I saw one thing that needs to be addressed: The IANA considerations say "Purpose: TBD". I think it needs to be determined before we complete WGLC. Thanks, Paul On 1/18/16 12:31 PM, Christer Holmberg wrote: > Hi, > > I've submitted a new version (-05) of the dtls-sdp draft, fixing the editorial nits found by Paul. > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Feb 3 12:11: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 2187F1B2C26 for ; Wed, 3 Feb 2016 12:11: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 6fFZ4cX_uFvh for ; Wed, 3 Feb 2016 12:11:29 -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 8437D1B2C20 for ; Wed, 3 Feb 2016 12:11:29 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-a0-56b25eefe77e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.27.05041.FEE52B65; Wed, 3 Feb 2016 21:11:27 +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; Wed, 3 Feb 2016 21:11:27 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-05 Thread-Index: AdFSFhB8c9kMSO3YS0GOcQtXXMNOEgMn4YoAAAJax1A= Date: Wed, 3 Feb 2016 20:11:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D6DC59@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D437CC@ESESSMB209.ericsson.se> <56B25D1A.6030407@alum.mit.edu> In-Reply-To: <56B25D1A.6030407@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+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7uu77uE1hBlNfC1pMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGtS2SBV9ZK973H2RpYHzC0sXIySEhYCJx +9pZVghbTOLCvfVsXYxcHEIChxkldq+/yAThLGaUODz3FXMXIwcHm4CFRPc/bZAGEQFfiWeP b7OB2MICbhI//m5ghYi7S/z+dYINwraSeP+kmx2klUVAReLaKT6QMC9Q69bLcxhBbCGBfInZ fe1g93AK6EgsvDIRrJUR6J7vp9YwgdjMAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/+g7leSWHT7 M1S9jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+em GxnppRZlJhcX5+fp5aWWbGIExsjBLb+tdjAefO54iFGAg1GJh9fAb1OYEGtiWXFl7iFGCQ5m JRHe37ZAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxrnNeHCQmkJ5akZqemFqQWwWSZODilGhgt j6h9//Jg2qPHiaW/LQJfHY6Y5LOzQS0i7903A4fyabJvr8Qb/1NPa2laFr34wtojYdfELjhZ p5gqaQR/+fziKN+HqcJTDlRen/8x1OaphvS28h9rTloqiHHWCXWlMbxYn5q0lzlz9/IEY+lb F6Pazn/9+9t7sfGhkB0KTy+eWmX57ef97ZejlViKMxINtZiLihMBS5yLyY0CAAA= Archived-At: Subject: Re: [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: Wed, 03 Feb 2016 20:11:31 -0000 Hi Paul, >I reviewed this and think it is ready for WGLC. > >I saw one thing that needs to be addressed: > >The IANA considerations say "Purpose: TBD". I think it needs to be determi= ned before we complete >WGLC. I agree. That will be fixed. Regards, Christer On 1/18/16 12:31 PM, Christer Holmberg wrote: > Hi, > > I've submitted a new version (-05) of the dtls-sdp draft, fixing the edit= orial nits found by Paul. > > 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 Feb 3 14:42: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 C42881B3600 for ; Wed, 3 Feb 2016 14:42:12 -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_14=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 DZfuxUTWw9Vu for ; Wed, 3 Feb 2016 14:42:11 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDBE1B35FE for ; Wed, 3 Feb 2016 14:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4493; q=dns/txt; s=iport; t=1454539330; x=1455748930; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DGUuNjbjXpC4ute2uuDfG++Y1kno+DFBqMpaUNa1snw=; b=Rk1V/I+ibjQCPEaENgVl973SBYsM1RkA4ILalx1FwdRGPr6L9Rj8MdMS /ANgyGrB0Pd2Sb1R3YLbwbM0wA9P3pOQxBXWM6RXRG74nMkrqZEhuUArc L1vuoCSku0nKHH+pqsiuBNCJGIYWeUxIzVxzPkIU5bkcnQPhAU+Doixlk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AgBJgbJW/4QNJK1eDoMsUm2IW7EbA?= =?us-ascii?q?Q2BZhcKhSJKAoFBOBQBAQEBAQEBgQpBDgGDcQEBAQMBAQEBNTYKBgsLDgoJFg8?= =?us-ascii?q?JAwIBAgEVMAYBDAYCAQGIDwgOwFUBAQEBAQEBAQEBAQEBAQEBAQEBEwSGEoQ3i?= =?us-ascii?q?GwFjSV0iFiNTYkghVGOQB4BAUKCAxmBDVkeLoE1iDYBAQE?= X-IronPort-AV: E=Sophos;i="5.22,392,1449532800"; d="scan'208";a="234003492" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2016 22:42:10 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u13Mg9fG005401; Wed, 3 Feb 2016 22:42:09 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> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> From: Flemming Andreasen Message-ID: <56B28240.7080206@cisco.com> Date: Wed, 3 Feb 2016 17:42:08 -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: <56B25159.70002@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: Wed, 03 Feb 2016 22:42:12 -0000 On 2/3/16 2:13 PM, Paul Kyzivat wrote: > On 2/2/16 5:35 PM, Flemming Andreasen wrote: >> >> >> On 1/29/16 10:30 AM, Paul Kyzivat wrote: > >>> 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. >>> >> I'm not concerned about the IANA registration. What I am concerned about >> is that we are heading down the path of explicitly thinking about and >> specifying interactions between different attributes. Again, I'm not >> convinced that it is really necessary here and that you couldn't solve >> the issue for dcsa with a more algorithmich approach similar to what we >> did for capability negotiation. > > Are you referring to: > > When the attribute capability contains a session-level attribute, > that "acap" attribute can only be provided at the session level. > Conversely, media-level attributes can be provided in attribute > capabilities at either the media level or session level. The base > > I don't see the parallel. capneg is really a "macro" mechanism, so it > is really up to the user to ensure that all possible expansions of a > macro are valid. I'm referring to CapNeg's "conceptual" construction of SDPs based on potential configurations - see e.g. Sections 3.1, 3.5.1 and 3.6.2 in RFC 5939 > > But I see a direct analogy to the a=ssrc attribute. That one also is > an attribute that recursively contains another attribute. But not all > attributes "work" (or make sense) with a=ssrc. Only those whose effect > can be narrowed to a particular RTP stream are valid. So it > established a registry for those that do work with it. > > The a=dcsa attribute is very similar to that. Again not every > attribute works with it. Only those that can be applied to a > particular data channel apply. > Right, but what are the constraints on a particular data channel that may or may not make them work with a data channel ? Why is this fundamentally different than specifying parameters for a media stream ? > Rather than keeping separate registries for session level, media > level, and "source" (a=ssrc) level, we have agreed to merge them and > add a column to indicate which level(s) apply to each attribute. That > makes it easier to add yet another (dcsa) "level". > >> Can you (and/or the authors) elaborate on why such an approach would not >> work ? > > It isn't strictly necessary to have this information in IANA. It would > be sufficient to have it in the documents that define each attribute. > (As long as they really do have it.) > > And, if it was there and not in the registry, then each document could > decide whether applicability can be specified via an algorithm, or if > it must be done by enumeration. > > But, if that is the case, then it should apply for all the distinct > contexts where attributes might be used: session level, media level, > source level, dcsa level, and capneg level. (Every distinct place that > can appear.) > > And there is a downside to this. Each time a new "level" is defined > (e.g., when a=dcsa is defined) then either it has to provide a rule > for every attribute, current and future, or else the definition of > every attribute, current and future, will need to specify > applicability to this new level. > > Consider a=ssrc. When some new attribute is defined, will it be usable > with a=ssrc? Without the registry, how would anyone find out? > I'm not concerned about the IANA part. I agree that *if* we need to expliclty specify attribute interactions for "dcsa", then it should be part of the IANA registry. What I am not agreeing with at this point is that there is indeed a need to explicitly speficy these interactions as opposed to relying on a more general algorithmic approach (plus the offerer being responsible for generating a valid offer if he wants to establish a data channel). Thanks -- Flemming > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Wed Feb 3 20:58:57 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 B2EA31A0122 for ; Wed, 3 Feb 2016 20:58:56 -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 TQuC7lupNOwv for ; Wed, 3 Feb 2016 20:58:55 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCDB1A011D for ; Wed, 3 Feb 2016 20:58:55 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-08v.sys.comcast.net with comcast id E4yu1s0032EPM31014yu6z; Thu, 04 Feb 2016 04:58:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id E4yu1s0043KdFy1014yuNT; Thu, 04 Feb 2016 04:58:54 +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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> From: Paul Kyzivat Message-ID: <56B2DA8D.2000909@alum.mit.edu> Date: Wed, 3 Feb 2016 23:58:53 -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: <56B28240.7080206@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=1454561934; bh=MamFEq+jsvpjCM6hHzT32J/P6eCgelfrB8MiUYeqwZg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PajLM0DTjQwWAcS/CT3wzasWHSyyAtxHg39ogB7MUd8ClvZnGvSCTc7wYrAF2DV6M rIEryhZpV+WTGgyJBiQ5oUY2zKFO1Nyj48dJ0+QEDFVvrpyriP0mOIiwEMHeEU8FET /15wW3n6HaLYLeAWjF8M/6WqnIDQ4zevZO4AjPRG6O/tBCQ0dmHp+vTznGuRt16ePI kuGnJvHDHRfOdWHBdcB/2Hnhlog0CTNIKNiDoheOJlrWHH//c5KTNn3VRACMl6dwTq DcGfL5FXmlycSFbYseoGh7wS2GaNSEgx/4+LpskHax+EwRgM/ATUVrg/LD4RzfXY1F eJPA9YQRti7lw== 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: Thu, 04 Feb 2016 04:58:56 -0000 On 2/3/16 5:42 PM, Flemming Andreasen wrote: > I'm not concerned about the IANA part. I agree that *if* we need to > expliclty specify attribute interactions for "dcsa", then it should be > part of the IANA registry. What I am not agreeing with at this point is > that there is indeed a need to explicitly speficy these interactions as > opposed to relying on a more general algorithmic approach (plus the > offerer being responsible for generating a valid offer if he wants to > establish a data channel). Well, an obvious one is that the protocol(s) the attribute pertains to need to be defined to work over data channels. Thanks, Paul From nobody Thu Feb 4 06:14:43 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 BD5901B2FF7; Thu, 4 Feb 2016 06:14:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160204141441.18475.61153.idtracker@ietfa.amsl.com> Date: Thu, 04 Feb 2016 06:14:41 -0800 Archived-At: Cc: mmusic-chairs@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Stephen Farrell's No Objection 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, 04 Feb 2016 14:14:42 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-mmusic-03-00: No Objection 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: ---------------------------------------------------------------------- Just checking - the work to avoid unwanted exposure of IP addresses is now being done by the ICE working group - that's right isn't it? From nobody Thu Feb 4 07:25: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 6175F1B3165; Thu, 4 Feb 2016 07:25:20 -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 mWFNf5_h1xyC; Thu, 4 Feb 2016 07:25:19 -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 31A2C1B315C; Thu, 4 Feb 2016 07:25:19 -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 u14FPEYM077099 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Feb 2016 09:25:14 -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: "Stephen Farrell" Date: Thu, 04 Feb 2016 09:25:13 -0600 Message-ID: <8393E5E3-78B3-40BC-BEBE-1DB1952F3E3B@nostrum.com> In-Reply-To: <20160204141441.18475.61153.idtracker@ietfa.amsl.com> References: <20160204141441.18475.61153.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: mmusic-chairs@ietf.org, The IESG , mmusic@ietf.org Subject: Re: [MMUSIC] Stephen Farrell's No Objection on charter-ietf-mmusic-03-00: (with COMMENT) 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, 04 Feb 2016 15:25:20 -0000 On 4 Feb 2016, at 8:14, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > charter-ietf-mmusic-03-00: No Objection > > 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: > ---------------------------------------------------------------------- > > > Just checking - the work to avoid unwanted exposure of IP addresses > is now being done by the ICE working group - that's right isn't it? IMO, that belongs in ICE. I will make sure it continues there. From nobody Thu Feb 4 07:54: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 EC3301B31E1 for ; Thu, 4 Feb 2016 07:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 1I8TnFM44smX for ; Thu, 4 Feb 2016 07:53:56 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190841B31E6 for ; Thu, 4 Feb 2016 07:53:56 -0800 (PST) Received: from [130.209.247.112] (port=58227 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRMEB-0002xA-Jw; Thu, 04 Feb 2016 15:53:53 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_B7E5823A-BB7B-442F-9EB1-953EFD9D758D" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D6A06E@ESESSMB209.ericsson.se> Date: Thu, 4 Feb 2016 15:53:48 +0000 Message-Id: References: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> <56AACE99.5060905@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D6A06E@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: mmusic Subject: Re: [MMUSIC] 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: Thu, 04 Feb 2016 15:53:59 -0000 --Apple-Mail=_B7E5823A-BB7B-442F-9EB1-953EFD9D758D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christer, I=E2=80=99ve read the draft, and have no objection to it going to = working group last call.=20 The only real technical comment I had is that the draft doesn=E2=80=99t = really describe how errors are to be handled in all cases, so there=E2=80=99= s perhaps scope for different interpretations (e.g., what does the = answering party do if the offer includes = =E2=80=9Ca=3Ddtls-connection:existing=E2=80=9D but there is no DTLS = connection? Or what happens if an existing connection is used, but the = answer contains a modified fingerprint? etc.) Much of this is likely = obvious to someone more familiar with all the referenced specs, but it = might not hurt to add extra references, or spell out the details. Cheers, Colin > On 3 Feb 2016, at 07:50, Christer Holmberg = wrote: >=20 > Hi Colin, > =20 > Could you take a look at the draft, and indicate on the list if you = think that we are ready to start WGLC (or, if you don=E2=80=99t think = we=E2=80=99re ready, indicate why). > =20 > Note that comments etc can still be given during WGLC, but personally = I don=E2=80=99t see any major issues that would have to be dealt with = before we begin WGLC. > =20 > Thanks! > =20 > Regards, > =20 > Christer > =20 > =20 > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming = Andreasen > Sent: 29. tammikuuta 2016 4:30 > To: mmusic > Subject: [MMUSIC] Fwd: I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt > =20 > Greetings MMUSIC >=20 > 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.=20 >=20 > Thanks=20 >=20 > -- Flemming (as MMUSIC chair) >=20 >=20 >=20 >=20 > -------- Forwarded Message --------=20 > Subject:=20 > [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt > Date:=20 > Mon, 18 Jan 2016 09:30:11 -0800 > From:=20 > internet-drafts@ietf.org > To:=20 > i-d-announce@ietf.org > CC:=20 > mmusic@ietf.org > =20 >=20 > 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. > =20 > 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 > =20 > 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. > =20 > This draft defines a new SDP media-level attribute, 'dtls- > connection'. > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ = > =20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-05 = > =20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-dtls-sdp-05 = > =20 > =20 > 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. > =20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = > . > =20 > =20 > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_B7E5823A-BB7B-442F-9EB1-953EFD9D758D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Christer,

I=E2=80=99ve read the draft, and have no objection to it = going to working group last call. 

The only real technical comment I had = is that the draft doesn=E2=80=99t really describe how errors are to be = handled in all cases, so there=E2=80=99s perhaps scope for different = interpretations (e.g., what does the answering party do if the offer = includes =E2=80=9Ca=3Ddtls-connection:existing=E2=80=9D but there is no = DTLS connection?  Or what happens if an existing connection is = used, but the answer contains a modified fingerprint? etc.) Much of this = is likely obvious to someone more familiar with all the referenced = specs, but it might not hurt to add extra references, or spell out the = details.

Cheers,
Colin



On 3 Feb 2016, at 07:50, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Colin,
 
Could you take = a look at the draft, and indicate on the list if you think that we are = ready to start WGLC (or, if you don=E2=80=99t think we=E2=80=99re ready, = indicate why).
 
Note that comments etc can still be given during WGLC, but = personally I don=E2=80=99t see any major issues that would have to be = dealt with before we begin WGLC.
 
Thanks!
 
Regards,
 
Christer
 
 
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf = Of Flemming = Andreasen
Sent: 29. tammikuuta 2016 4:30
To: mmusic
Subject: [MMUSIC] Fwd: I-D Action: = draft-ietf-mmusic-dtls-sdp-05.txt
 

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
          &nb=
sp;            =
;   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=3Ddraft-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
.
 
 
 
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

=


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



= --Apple-Mail=_B7E5823A-BB7B-442F-9EB1-953EFD9D758D-- From nobody Thu Feb 4 10:00:23 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 2F0EA1A8A4E for ; Thu, 4 Feb 2016 10:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 YcJB9DW2CSoy for ; Thu, 4 Feb 2016 10:00:18 -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 9EA871A8A48 for ; Thu, 4 Feb 2016 10:00:17 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-3d-56b391af8ce6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 09.B2.05041.FA193B65; Thu, 4 Feb 2016 19:00:15 +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, 4 Feb 2016 19:00:14 +0100 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt Thread-Index: AQHRX2RAQoFWgkFbDUq/qx9luOa4y58cK+Ow Date: Thu, 4 Feb 2016 18:00:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D70AB4@ESESSMB209.ericsson.se> References: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> <56AACE99.5060905@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D6A06E@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D70AB4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7hO76iZvDDK6uE7NY/vIEo8XU5Y9Z HJg8pt2/z+axZMlPpgCmKC6blNSczLLUIn27BK6Mf//jCmZ8YqxY2fuVqYHxxWvGLkZODgkB E4lJuyZA2WISF+6tZ+ti5OIQEjjMKPF36kVWCGcxo0TrslVADgcHm4CFRPc/bZAGEQFViR3H /4E1MwvISMw428gEYgsLuEgs37yaDaLGVeJ+6zt2CNtI4tL6SawgNouAisSCiQfAangFfCX+ fF3GDrHrNqPEmUnPwAZxCjhKND97xAxiMwJd9/3UGiaIZeISt57MZ4K4WkBiyZ7zzBC2qMTL x/9YIWwliRXbL0Edly9xvH0fI8QyQYmTM5+wTGAUnYVk1CwkZbOQlM0CeplZQFNi/S59iBJF iSndD9khbA2J1jlz2ZHFFzCyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjLiDW35b7WA8 +NzxEKMAB6MSD6+B36YwIdbEsuLK3EOMEhzMSiK8u1M2hwnxpiRWVqUW5ccXleakFh9ilOZg URLnXeO8PkxIID2xJDU7NbUgtQgmy8TBKdXAOPnCrYNyt4//zvExSi6KVY6unHcw9mRereuM /S7SuQaL0r4JxUlZz2VK4P6r+u/s4srqv5e5IhcvqzlSyZCj4HZe5EFLzSFzg5hDyqIfzqU0 z1FW2GaSsM9ZYQZz+o/Tb/qPNGR8WjdDtfFM5z6DOYxqQfduv7x4ZnH0jKv7nfcldL2rOC5W pcRSnJFoqMVcVJwIAMLlUUy0AgAA Archived-At: Cc: mmusic Subject: Re: [MMUSIC] 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: Thu, 04 Feb 2016 18:00:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D70AB4ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5J4oCZdmUgcmVhZCB0aGUgZHJhZnQsIGFuZCBoYXZlIG5vIG9iamVjdGlvbiB0byBp dCBnb2luZyB0byB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0KVGhhbmtzIQ0KDQo+VGhlIG9u bHkgcmVhbCB0ZWNobmljYWwgY29tbWVudCBJIGhhZCBpcyB0aGF0IHRoZSBkcmFmdCBkb2VzbuKA mXQgcmVhbGx5IGRlc2NyaWJlIGhvdyBlcnJvcnMgYXJlIHRvIGJlIGhhbmRsZWQgaW4gYWxsIGNh c2VzLCBzbyB0aGVyZeKAmXMgcGVyaGFwcyBzY29wZSBmb3IgZGlmZmVyZW50IGludGVycHJldGF0 aW9ucyAoZS5nLiwgd2hhdCBkb2VzID50aGUgYW5zd2VyaW5nIHBhcnR5IGRvIGlmIHRoZSBvZmZl ciBpbmNsdWRlcyDigJxhPWR0bHMtY29ubmVjdGlvbjpleGlzdGluZ+KAnSBidXQgdGhlcmUgaXMg bm8gRFRMUyBjb25uZWN0aW9uPyAgT3Igd2hhdCBoYXBwZW5zIGlmIGFuIGV4aXN0aW5nIGNvbm5l Y3Rpb24gaXMgdXNlZCwgYnV0IHRoZSBhbnN3ZXIgY29udGFpbnMgYSA+bW9kaWZpZWQgZmluZ2Vy cHJpbnQ/IGV0Yy4pIE11Y2ggb2YgdGhpcyBpcyBsaWtlbHkgb2J2aW91cyB0byBzb21lb25lIG1v cmUgZmFtaWxpYXIgd2l0aCBhbGwgdGhlIHJlZmVyZW5jZWQgc3BlY3MsIGJ1dCBpdCBtaWdodCBu b3QgaHVydCB0byBhZGQgZXh0cmEgcmVmZXJlbmNlcywgb3Igc3BlbGwgb3V0IHRoZSBkZXRhaWxz Lg0KDQpXZSBub3JtYWxseSBkb27igJl0IHNheSB0b28gbXVjaCBhYm91dCB0aGVzZSBraW5kIG9m IGVycm9yIGNhc2VzLiBCdXQsIGlmIHRoZXJlIGFyZSBwcm9jZWR1cmVzIHdlIGNhbiByZWZlciB0 byB3ZSBjYW4gZm9yIHN1cmUgYWRkIHJlZmVyZW5jZXMuIFdlIGNhbiBhbHNvIHNheSB0aGF0LCBp ZiBzdWNoIG9mZmVyL2Fuc3dlciBlcnJvciBvY2N1cnMsIHRoZSBvZmZlcmVyIG11c3QgdGVybWlu YXRlIHRoZSBzdHJlYW0gKGluY2x1ZGluZyBhbnkgcG9zc2libGUgRFRMUyBjb25uZWN0aW9uIGFz c29jaWF0ZWQgd2l0aCBpdCkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCk9uIDMg RmViIDIwMTYsIGF0IDA3OjUwLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90 ZToNCg0KSGkgQ29saW4sDQoNCkNvdWxkIHlvdSB0YWtlIGEgbG9vayBhdCB0aGUgZHJhZnQsIGFu ZCBpbmRpY2F0ZSBvbiB0aGUgbGlzdCBpZiB5b3UgdGhpbmsgdGhhdCB3ZSBhcmUgcmVhZHkgdG8g c3RhcnQgV0dMQyAob3IsIGlmIHlvdSBkb27igJl0IHRoaW5rIHdl4oCZcmUgcmVhZHksIGluZGlj YXRlIHdoeSkuDQoNCk5vdGUgdGhhdCBjb21tZW50cyBldGMgY2FuIHN0aWxsIGJlIGdpdmVuIGR1 cmluZyBXR0xDLCBidXQgcGVyc29uYWxseSBJIGRvbuKAmXQgc2VlIGFueSBtYWpvciBpc3N1ZXMg dGhhdCB3b3VsZCBoYXZlIHRvIGJlIGRlYWx0IHdpdGggYmVmb3JlIHdlIGJlZ2luIFdHTEMuDQoN ClRoYW5rcyENCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpGcm9tOiBtbXVzaWMgW21haWx0 bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZsZW1taW5nIEFuZHJlYXNl bg0KU2VudDogMjkuIHRhbW1pa3V1dGEgMjAxNiA0OjMwDQpUbzogbW11c2ljDQpTdWJqZWN0OiBb TU1VU0lDXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTA1LnR4 dA0KDQpHcmVldGluZ3MgTU1VU0lDDQoNCldlIHdvdWxkIGxpa2UgdG8gc3RhcnQgbW92aW5nIHRv d2FyZHMgV0dMQyBvbiB0aGlzIGRyYWZ0IC0gZG8gcGVvcGxlIGJlbGlldmUgdGhlIGRyYWZ0IGlz IHJlYWR5IGZvciB0aGF0IGF0IHRoaXMgcG9pbnQgPyBJZiBub3QsIHBsZWFzZSBsZXQgdXMga25v dyB3aGljaCBpc3N1ZXMgeW91IHNlZS4NCg0KVGhhbmtzDQoNCi0tIEZsZW1taW5nIChhcyBNTVVT SUMgY2hhaXIpDQoNCg0KDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpT dWJqZWN0Og0KDQpbTU1VU0lDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNk cC0wNS50eHQNCg0KRGF0ZToNCg0KTW9uLCAxOCBKYW4gMjAxNiAwOTozMDoxMSAtMDgwMA0KDQpG cm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NCg0KVG86DQoNCmktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91 bmNlQGlldGYub3JnPg0KDQpDQzoNCg0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0 Zi5vcmc+DQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNCiBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lvbiBDb250cm9sIFdv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6 IFVzaW5nIHRoZSBTRFAgT2ZmZXIvQW5zd2VyIE1lY2hhbmlzbSBmb3IgRFRMUw0KDQogICAgICAg IEF1dGhvcnMgICAgICAgICA6IENocmlzdGVyIEhvbG1iZXJnDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgUm9tYW4gU2hwb3VudA0KDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwLTA1LnR4dA0KDQogICAgICAgIFBhZ2VzICAgICAgICAgICA6 IDIxDQoNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNi0wMS0xOA0KDQoNCg0KQWJzdHJh Y3Q6DQoNCiAgIFRoaXMgZHJhZnQgZGVmaW5lcyB0aGUgU0RQIG9mZmVyL2Fuc3dlciBwcm9jZWR1 cmVzIGZvciBuZWdvdGlhdGluZw0KDQogICBhbmQgZXN0YWJsaXNoaW5nIGEgRFRMUyBhc3NvY2lh dGlvbi4gIFRoZSBkcmFmdCBhbHNvIGRlZmluZXMgdGhlDQoNCiAgIGNyaXRlcmlhIGZvciB3aGVu IGEgbmV3IERUTFMgYXNzb2NpYXRpb24gbXVzdCBiZSBlc3RhYmxpc2hlZC4NCg0KDQoNCiAgIFRo aXMgZHJhZnQgZGVmaW5lcyBhIG5ldyBTRFAgbWVkaWEtbGV2ZWwgYXR0cmlidXRlLCAnZHRscy0N Cg0KICAgY29ubmVjdGlvbicuDQoNCg0KDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLw0KDQoNCg0KVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0wNQ0KDQoNCg0KQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMDUNCg0KDQoNCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0K DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm1tdXNpYyBtYWlsaW5n IGxpc3QNCg0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCi4NCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWls aW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQotLQ0KQ29saW4gUGVy a2lucw0KaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37D70AB4ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 Okx1Y2lkYVNhbnMtVHlwZXdyaXRlcjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21z by1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0 eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SeKAmXZlIHJlYWQgdGhlIGRyYWZ0 LCBhbmQgaGF2ZSBubyBvYmplY3Rpb24gdG8gaXQgZ29pbmcgdG8gd29ya2luZyBncm91cCBsYXN0 IGNhbGwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1RoZSBvbmx5IHJlYWwgdGVjaG5p Y2FsIGNvbW1lbnQgSSBoYWQgaXMgdGhhdCB0aGUgZHJhZnQgZG9lc27igJl0IHJlYWxseSBkZXNj cmliZSBob3cgZXJyb3JzIGFyZSB0byBiZSBoYW5kbGVkIGluIGFsbCBjYXNlcywgc28gdGhlcmXi gJlzIHBlcmhhcHMgc2NvcGUgZm9yIGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbnMgKGUuZy4sIHdo YXQgZG9lcyAmZ3Q7dGhlIGFuc3dlcmluZyBwYXJ0eSBkbyBpZiB0aGUgb2ZmZXIgaW5jbHVkZXMN CiDigJxhPWR0bHMtY29ubmVjdGlvbjpleGlzdGluZ+KAnSBidXQgdGhlcmUgaXMgbm8gRFRMUyBj b25uZWN0aW9uPyAmbmJzcDtPciB3aGF0IGhhcHBlbnMgaWYgYW4gZXhpc3RpbmcgY29ubmVjdGlv biBpcyB1c2VkLCBidXQgdGhlIGFuc3dlciBjb250YWlucyBhICZndDttb2RpZmllZCBmaW5nZXJw cmludD8gZXRjLikgTXVjaCBvZiB0aGlzIGlzIGxpa2VseSBvYnZpb3VzIHRvIHNvbWVvbmUgbW9y ZSBmYW1pbGlhciB3aXRoIGFsbCB0aGUgcmVmZXJlbmNlZCBzcGVjcywNCiBidXQgaXQgbWlnaHQg bm90IGh1cnQgdG8gYWRkIGV4dHJhIHJlZmVyZW5jZXMsIG9yIHNwZWxsIG91dCB0aGUgZGV0YWls cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5XZSBub3JtYWxseSBkb27igJl0IHNheSB0b28gbXVjaCBhYm91dCB0aGVzZSBraW5kIG9mIGVy cm9yIGNhc2VzLiBCdXQsIGlmIHRoZXJlIGFyZSBwcm9jZWR1cmVzIHdlIGNhbiByZWZlciB0byB3 ZSBjYW4gZm9yIHN1cmUgYWRkIHJlZmVyZW5jZXMuIFdlIGNhbiBhbHNvIHNheSB0aGF0LCBpZiBz dWNoIG9mZmVyL2Fuc3dlcg0KIGVycm9yIG9jY3VycywgdGhlIG9mZmVyZXIgbXVzdCB0ZXJtaW5h dGUgdGhlIHN0cmVhbSAoaW5jbHVkaW5nIGFueSBwb3NzaWJsZSBEVExTIGNvbm5lY3Rpb24gYXNz b2NpYXRlZCB3aXRoIGl0KS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzIEZlYiAyMDE2LCBhdCAw Nzo1MCwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGkgQ29saW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q291 bGQgeW91IHRha2UgYSBsb29rIGF0IHRoZSBkcmFmdCwgYW5kIGluZGljYXRlIG9uIHRoZSBsaXN0 IGlmIHlvdSB0aGluayB0aGF0IHdlIGFyZSByZWFkeSB0byBzdGFydCBXR0xDIChvciwgaWYgeW91 IGRvbuKAmXQNCiB0aGluayB3ZeKAmXJlIHJlYWR5LCBpbmRpY2F0ZSB3aHkpLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5vdGUgdGhhdCBjb21tZW50cyBldGMgY2FuIHN0aWxs IGJlIGdpdmVuIGR1cmluZyBXR0xDLCBidXQgcGVyc29uYWxseSBJIGRvbuKAmXQgc2VlIGFueSBt YWpvciBpc3N1ZXMgdGhhdCB3b3VsZCBoYXZlIHRvIGJlDQogZGVhbHQgd2l0aCBiZWZvcmUgd2Ug YmVnaW4gV0dMQy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MhPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPm1tdXNpYw0KIFs8YSBocmVm PSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzptbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+RmxlbW1pbmcgQW5kcmVhc2VuPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjI5LiB0YW1taWt1dXRh IDIwMTYgNDozMDxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+bW11c2ljPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltNTVVTSUNdIEZ3ZDogSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMDUudHh0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91 bmQ6d2hpdGUiPkdyZWV0aW5ncyBNTVVTSUM8YnI+DQo8YnI+DQpXZSB3b3VsZCBsaWtlIHRvIHN0 YXJ0IG1vdmluZyB0b3dhcmRzIFdHTEMgb24gdGhpcyBkcmFmdCAtIGRvIHBlb3BsZSBiZWxpZXZl IHRoZSBkcmFmdCBpcyByZWFkeSBmb3IgdGhhdCBhdCB0aGlzIHBvaW50ID8gSWYgbm90LCBwbGVh c2UgbGV0IHVzIGtub3cgd2hpY2ggaXNzdWVzIHlvdSBzZWUuPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NClRoYW5rczxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQotLSBGbGVt bWluZyAoYXMgTU1VU0lDIGNoYWlyKTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS08c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5TdWJq ZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W01NVVNJQ10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMDUudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv dGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIg c3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Nb24sIDE4IEphbiAyMDE2IDA5OjMwOjExIC0wODAwPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJy aWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9 IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5U bzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3Vu Y2VAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmktZC1hbm5vdW5jZUBpZXRm Lm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPHRy Pg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxp Z246cmlnaHQiPjxiPkNDOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bW11c2ljQGll dGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIE11bHRpcGFydHkgTXVsdGltZWRpYSBTZXNzaW9uIENvbnRyb2wgV29y a2luZyBHcm91cCBvZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBU aXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA6IFVzaW5nIHRoZSBTRFAgT2ZmZXIvQW5zd2VyIE1lY2hhbmlzbSBmb3IgRFRMUzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9ycyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IENocmlzdGVyIEhvbG1iZXJnPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb21hbiBTaHBvdW50PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA6IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTA1LnR4dDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIwMTYtMDEtMTg8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsgVGhpcyBkcmFmdCBkZWZp bmVzIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHByb2NlZHVyZXMgZm9yIG5lZ290aWF0aW5nPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyBh bmQgZXN0YWJsaXNoaW5nIGEgRFRMUyBhc3NvY2lhdGlvbi4mbmJzcDsgVGhlIGRyYWZ0IGFsc28g ZGVmaW5lcyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7Jm5ic3A7IGNyaXRlcmlhIGZvciB3aGVuIGEgbmV3IERUTFMgYXNzb2NpYXRpb24g bXVzdCBiZSBlc3RhYmxpc2hlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyBUaGlzIGRyYWZ0IGRlZmluZXMgYSBuZXcgU0RQIG1lZGlh LWxldmVsIGF0dHJpYnV0ZSwgJ2R0bHMtPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyBjb25uZWN0aW9uJy48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAvIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNk cC88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0wNSI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbW11c2ljLWR0bHMtc2RwLTA1PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtbW11c2ljLWR0bHMtc2RwLTA1Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMDU8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciPnRvb2xzLmlldGYub3JnPC9hPi48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0iZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPm1tdXNpYyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYVNhbnMtVHlwZXdyaXRl ciZxdW90OyxzZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYVNhbnMtVHlwZXdyaXRlciZxdW90OyxzZXJpZiI+PGJy Pg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPm1tdXNpYyBtYWlsaW5nIGxpc3Q8L3Nw YW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYzwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Q29saW4gUGVya2luczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPjxhIGhy ZWY9Imh0dHBzOi8vY3NwZXJraW5zLm9yZy8iPmh0dHBzOi8vY3NwZXJraW5zLm9yZy88L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37D70AB4ESESSMB209erics_-- From nobody Thu Feb 4 11:42: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 A6B011ACE65 for ; Thu, 4 Feb 2016 11:42:08 -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_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e9XmFng8pdy for ; Thu, 4 Feb 2016 11:42:07 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 513031ACE2B for ; Thu, 4 Feb 2016 11:42:07 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id o185so54782691pfb.1 for ; Thu, 04 Feb 2016 11:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=bWgqCPyjw+10rbVe86+tBfDHrj+FpfPel7dDoHOPmW4=; b=MM30WD9v2YAJd0pnhSuwyE7oHRXO1+63i4GYd/3qM6a1ISns+HSa5U3AJjxrIhguAd acN76pE1bBNlvZ+N/EDDMsBLJpcrOMnTlOaIvSUpmsxAAgOzPwIWqRb7GWDD4fVgbNQ3 sibU7MpqyatpWN0nwTcR4W6K+yAXGc22zmCP96mlbSebXaLs3RNOh5zrU4rbiLkC/5Ro cevdr8expljIjAYQB0Yc0MPVLix+lfz049PEr/ogBkrUAyVUeB4UOOKdbenFH8Y4AlGT mnXiEe3ocAMK1ocwr/LzT1TWJyQzTEVi//FUpGCEEqgIOfeRJtB4M2XGYJBcUMciyrCn c9qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type; bh=bWgqCPyjw+10rbVe86+tBfDHrj+FpfPel7dDoHOPmW4=; b=EsPUkAMPoFpB4Wp8i8PI/qBaqwEccw1uYFzdVSlSvk40myxuElkRRppVghbgSqjXsG inO11hfkiLwsLxRxjf6VE2lfnU6Nv1U97ivO0jImx4UEBsOsMe4giyn8xvXUPJtoeZDj xDv6IURCqPA2MuDkyWgplhTYTcCpHWAozv45sHhMVpNJeWcGgKSlOs0z6Az4smJqXX9U Y+35wqIQOkOiQ7rTExYrIdq6MPh3DSBF4CPwMUYIKXp+gClotfp5wq77Iopxb8Z0UiFy TiFenz9GVGTNVGdFiL9dYvKuCZzKrXcJkkzUE0gd2y2B5nebwOB8vR9H8bkYneIhDIz1 U0Rw== X-Gm-Message-State: AG10YOTq7Ob/L6+dJ/UgHEtfe4hCEJcl75opzk5xA1SWFbvfPjyo22r6arYBt/cLTMXO5g== X-Received: by 10.98.17.129 with SMTP id 1mr13779889pfr.30.1454614926998; Thu, 04 Feb 2016 11:42:06 -0800 (PST) Received: from ?IPv6:2602:306:83ae:c480:9991:4e75:1b79:2fe5? ([2602:306:83ae:c480:9991:4e75:1b79:2fe5]) by smtp.googlemail.com with ESMTPSA id 195sm16123261pfa.5.2016.02.04.11.42.04 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 11:42:05 -0800 (PST) To: mmusic@ietf.org From: Byron Campen Message-ID: <56B3A98B.9030302@gmail.com> Date: Thu, 4 Feb 2016 13:42:03 -0600 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 Content-Type: multipart/alternative; boundary="------------030201070604050903000001" Archived-At: Subject: [MMUSIC] Comments on draft-ietf-mmusic-rid-02 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, 04 Feb 2016 19:42:08 -0000 This is a multi-part message in MIME format. --------------030201070604050903000001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As far as the open issues go, the proposals look fine to me. Issues: In section 6.4, step 5, we might want to point out that the offerer cannot simply look at the list of payload types, since the answerer may be using payload type asymmetry. The offerer will need to map each payload type to a codec description on both sides, and then make sure the set of codec descriptions for that rid in the answer is a subset of those in the offer. "Expressing all these codecs and resolutions using 32 dynamic PTs (2 audio + 10x3 video) would exhaust the primary dynamic space (96-127). RIDs are used to avoid PT exhaustion and express the resolution constraints." This is not adding up for me, because there is no requirement that PTs be unique across m-sections. The sendrecv m-section for video needs 10 PTs, but the other m-sections can overlap that. It might be kinda tricky to come up with a scenario that exceeds 32 without simulcast, but I don't really see why we need to talk about PT exhaustion in the RID spec, since that's more of a simulcast concern. Nits/editorial: "there is need a way to" "This framework can be thought of as complementary extension" I think it would read better if the paragraph beginning with "The additional constraints on individual streams are indicated with a " would follow the paragraph beginning with "This specification defines a new SDP framework for constraining", since both discuss SDP and how rid interacts with other methods of constraining streams. "supported constraints in their offer, abd (b) having answerers ignore" "possible during near resolution change boundaries. " "Codec-specific configuration set via format parameters ("a=fmtp"); for example, the H.264 "max-fs" format parameter" We should probably cite RFC 6185 here. "a=imgattr" should be a=imageattr "The SDP given below skips few lines" Best regards, Byron Campen --------------030201070604050903000001 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit     As far as the open issues go, the proposals look fine to me.

Issues:

    In section 6.4, step 5, we might want to point out that the offerer cannot simply look at the list of payload types, since the answerer may be using payload type asymmetry. The offerer will need to map each payload type to a codec description on both sides, and then make sure the set of codec descriptions for that rid in the answer is a subset of those in the offer.

"Expressing all these codecs and resolutions using 32 dynamic PTs (2 audio + 10x3 video) would exhaust the primary dynamic space (96-127). RIDs are used to avoid PT exhaustion and express the resolution constraints."

    This is not adding up for me, because there is no requirement that PTs be unique across m-sections. The sendrecv m-section for video needs 10 PTs, but the other m-sections can overlap that. It might be kinda tricky to come up with a scenario that exceeds 32 without simulcast, but I don't really see why we need to talk about PT exhaustion in the RID spec, since that's more of a simulcast concern.

Nits/editorial:

"there is need a way to"

"This framework can be thought of as complementary extension"

I think it would read better if the paragraph beginning with "The additional constraints on individual streams are indicated with a " would follow the paragraph beginning with "This specification defines a new SDP framework for constraining", since both discuss SDP and how rid interacts with other methods of constraining streams.

"supported constraints in their offer, abd (b) having answerers ignore"

"possible during near resolution change boundaries. "

"Codec-specific configuration set via format parameters ("a=fmtp"); for example, the H.264 "max-fs" format parameter"
   
    We should probably cite RFC 6185 here.

"a=imgattr"

    should be a=imageattr

"The SDP given below skips few lines"

Best regards,
Byron Campen

--------------030201070604050903000001-- From nobody Thu Feb 4 14:13: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 117801A1A1F for ; Thu, 4 Feb 2016 14:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 9Dz2vH-VWLKs for ; Thu, 4 Feb 2016 14:13:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2601B2AF9 for ; Thu, 4 Feb 2016 14:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3137; q=dns/txt; s=iport; t=1454623981; x=1455833581; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nQecSrWXhI5fxjARktFSUGAwWhTmN8JDQg+RB40m1xY=; b=KZMH7Evp4JYyFbVP90lqxVBXio87OeyIbN0SZO9t248NKzB2RTmBPU3q jjJHr/P8Y46hTueLhV/pIk3q3SEz3vTuxxe424Cg6z0jZpZfwm66KTGra NMFZrGi2Gqkj9A2rD+WKIC1nRKylgTq3gjVnX2Y8TZruWpGnrA0BbBYbn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQDPy7NW/4oNJK1egzpSXg8GiFWxA?= =?us-ascii?q?gENgWYXCoUiSgKBPzgUAQEBAQEBAYEKhEEBAQEEAQEBNzQLEAIBCBEDAQIBHhA?= =?us-ascii?q?nCx0IAgQBDQWIGw7AZAEBAQEBAQEBAQEBAQEBAQEBAQEBARWKSYhsBZZxAYVKi?= =?us-ascii?q?ASBW0qDeIMmhS6OPwEeAQFCg2Rqhy58AQEB?= X-IronPort-AV: E=Sophos;i="5.22,397,1449532800"; d="scan'208";a="73086974" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2016 22:13:00 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u14MD0K1030496 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Feb 2016 22:13:00 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 4 Feb 2016 16:12:59 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Thu, 4 Feb 2016 16:12:59 -0600 From: "Charles Eckel (eckelcu)" To: "Gonzalo Salgueiro (gsalguei)" , "Flemming Andreasen (fandreas)" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-05.txt Thread-Index: AQHRXYmnOn1S30ufBUmuJpapB0Hwyp8cVdcA Date: Thu, 4 Feb 2016 22:12:59 +0000 Message-ID: References: <20160118173011.24210.29939.idtracker@ietfa.amsl.com> <56AACE99.5060905@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 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: Thu, 04 Feb 2016 22:13:03 -0000 I think its ready for WG last call well. Cheers, Charles On 2/1/16, 11:15 PM, "mmusic on behalf of Gonzalo Salgueiro (gsalguei)" wrote: >Hi Flemming -=20 > >I have read this draft and think it is in good shape and ready for WGLC. > >-G > >> On Thu, Jan 28, 2016 at 9:29 PM, Flemming Andreasen >> wrote: >> Greetings MMUSIC >>=20 >> 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. >>=20 >> Thanks=20 >>=20 >> -- Flemming (as MMUSIC chair) >>=20 >>=20 >>=20 >>=20 >> -------- 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 >>=20 >> 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. >>=20 >> 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 >>=20 >> 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. >>=20 >> This draft defines a new SDP media-level attribute, 'dtls- >> connection'. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ >>=20 >>=20 >> There's also a htmlized version available at: >>=20 >> https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-05 >>=20 >>=20 >> A diff from the previous version is available at: >>=20 >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-dtls-sdp-05 >>=20 >>=20 >>=20 >> 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 >> . >>=20 >> Internet-Drafts are also available by anonymous FTP at: >>=20 >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >>=20 >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >> . >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >> _______________________________________________ >> 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 Feb 4 14:34: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 AAA281B31E0 for ; Thu, 4 Feb 2016 14:34:11 -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_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mloeNbk19GRt for ; Thu, 4 Feb 2016 14:34:10 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 C25291B31C4 for ; Thu, 4 Feb 2016 14:34:09 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e64so46394729vkg.0 for ; Thu, 04 Feb 2016 14:34:09 -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=4psjFwoMIMkIvSmd8CI4cC3gSPWtH9LZIaWWtdmGflw=; b=BuTWH171PsAriu0eCoJX8H+iFy9bDDu/9vjTY1XSvpA/KJc+YH4sDVRP7s/TOavvZn j1BUeQm0XEWBU0qum1wuGS0tb2PwGHgVMESBKorkVc8r5TuoRprRzci+QrDehe58/f4M QQB3Dp8krz2q1J1o6L7qGXceWOmEhbBz0YZMCAo6gX8qOxYb9FVBOh5NZckKufphmdqS vEHHxf1hl/V9G1UpvKSRAW+9X+aGHMNVagt8uLtO+3ArXYVJSQizu6OW3jkuPjElTbcr jMw2WpAarltjUfu4LhvxZ04l63YR8g+v+gRIpwAFbitXXvRRzJD0loYh516bg6fVphYz ytjg== 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=4psjFwoMIMkIvSmd8CI4cC3gSPWtH9LZIaWWtdmGflw=; b=MkMKcjoK5vbh3BuOK6PwuutHNwXjCb53LUQCYD0lvkSp+FHyTTSKPvMMzgQ/iQFXkg KV70gdgZWYGwazzAdI14CLogPpjLmHEioKqoW4HlIcQN6prgZhTR35BcoDPJ+r23fX2a bpi+yidoX1JtVjv+b648zcyjTl51GfqPGr/F3WLB11V74LopMJiWG/UEE/rkth2BtRwH 0KkYsTqBcOU6xVkCpIcABSN29Q7vfmdbj2BofNKOqQcYStEKse4hNtF55k/d79jXGJOJ oTsOQpiminXWFdnnm92tqXc7QoAtOWdJoBSDfNn9WmiyBvts4gS3qE0GYsQTiJAnDNBy x4+w== X-Gm-Message-State: AG10YOR7p5wIYRXhhmyNTmnuGdbhlMQo6EZuXwP4og7FxiG1LTgos3Yne/1sB2/KAEzaQAaIagCE3OejORvG4g== MIME-Version: 1.0 X-Received: by 10.31.47.205 with SMTP id v196mr7086568vkv.18.1454625248877; Thu, 04 Feb 2016 14:34:08 -0800 (PST) Received: by 10.31.94.209 with HTTP; Thu, 4 Feb 2016 14:34:08 -0800 (PST) In-Reply-To: <56B3A98B.9030302@gmail.com> References: <56B3A98B.9030302@gmail.com> Date: Thu, 4 Feb 2016 14:34:08 -0800 Message-ID: From: Suhas Nandakumar To: Byron Campen Content-Type: multipart/alternative; boundary=001a1143920e3da482052af95555 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-02 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, 04 Feb 2016 22:34:11 -0000 --001a1143920e3da482052af95555 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen wrote: > As far as the open issues go, the proposals look fine to me. > > Issues: > > In section 6.4, step 5, we might want to point out that the offerer > cannot simply look at the list of payload types, since the answerer may be > using payload type asymmetry. The offerer will need to map each payload > type to a codec description on both sides, and then make sure the set of > codec descriptions for that rid in the answer is a subset of those in the > offer. > > [Suhas] Payload type asymmetry is a standard feature with SDP out of RID. Should we really need to explicitly specify that fact ? > "Expressing all these codecs and resolutions using 32 dynamic PTs (2 audio > + 10x3 video) would exhaust the primary dynamic space (96-127). RIDs are > used to avoid PT exhaustion and express the resolution constraints." > > This is not adding up for me, because there is no requirement that PTs > be unique across m-sections. The sendrecv m-section for video needs 10 PTs, > but the other m-sections can overlap that. It might be kinda tricky to come > up with a scenario that exceeds 32 without simulcast, but I don't really > see why we need to talk about PT exhaustion in the RID spec, since that's > more of a simulcast concern. > > [Suhas] There are 10 video codecs and need to express 3 different resolutions. If I am not reading it wrong, the example shows just using 10 codecs coupled with RID for defining varied resolutions allows us not to exhaust the Payload Types. OTOH, if we remove the rid lines from the m= lines in the example and express the resolutions as part of PT, then we will end up with 10 X 3 Payload Types. > Nits/editorial: > > "there is need a way to" > > "This framework can be thought of as complementary extension" > > I think it would read better if the paragraph beginning with "The > additional constraints on individual streams are indicated with a " would > follow the paragraph beginning with "This specification defines a new SDP > framework for constraining", since both discuss SDP and how rid interacts > with other methods of constraining streams. > > "supported constraints in their offer, abd (b) having answerers ignore" > > "possible during near resolution change boundaries. " > > "Codec-specific configuration set via format parameters ("a=fmtp"); for > example, the H.264 "max-fs" format parameter" > > We should probably cite RFC 6185 here. > > "a=imgattr" > > should be a=imageattr > > "The SDP given below skips few lines" > > Best regards, > Byron Campen > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1143920e3da482052af95555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen <docfaraday@gmail.com= > wrote:
=20 =20 =20
=C2=A0=C2=A0=C2=A0 As far as the open issues go, the proposals look fin= e to me.

Issues:

=C2=A0=C2=A0=C2=A0 In section 6.4, step 5, we might want to point out t= hat the offerer cannot simply look at the list of payload types, since the answerer may be using payload type asymmetry. The offerer will need to map each payload type to a codec description on both sides, and then make sure the set of codec descriptions for that rid in the answer is a subset of those in the offer.


[Suhas] Payload type asymmet= ry is a standard feature with SDP out of RID. Should we really need to expl= icitly specify that fact ?

=C2=A0
"Expressing all these codecs and resolutions using 32 dynamic PTs = (2 audio + 10x3 video) would exhaust the primary dynamic space (96-127). RIDs are used to avoid PT exhaustion and express the resolution constraints."

=C2=A0=C2=A0=C2=A0 This is not adding up for me, because there is no re= quirement that PTs be unique across m-sections. The sendrecv m-section for video needs 10 PTs, but the other m-sections can overlap that. It might be kinda tricky to come up with a scenario that exceeds 32 without simulcast, but I don't really see why we need to talk about PT exhaustion in the RID spec, since that's more of a simulcast concern.


[Suhas] There are 10 video c= odecs and need to express 3 different resolutions. If I am not reading it w= rong, the example shows just using 10 codecs coupled with RID for defining = varied resolutions allows us not to exhaust the Payload Types.
OTOH, if we remove the rid lines from the m=3D lines in the ex= ample and express the resolutions as part of PT, then we will end up with 1= 0 X 3 Payload Types.

=C2=A0
Nits/editorial:

"there is need a way to"

"This framework can be thought of as complementary extension"=

I think it would read better if the paragraph beginning with "The additional constraints on individual streams are indicated with a =20 " would follow the paragraph beginning with "This specificati= on defines a new SDP framework for constraining", since both discuss SDP and how rid interacts with other methods of constraining streams.

"supported constraints in their offer, abd (b) having answerers ignore"

"possible during near resolution change boundaries. "

"Codec-specific configuration set via format parameters ("a= =3Dfmtp"); for example, the H.264 "max-fs" format parameter"
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 We should probably cite RFC 6185 here.
=20
"a=3Dimgattr"

=C2=A0=C2=A0=C2=A0 should be a=3Dimageattr

"The SDP given below skips few lines"

Best regards,
Byron Campen

=20 =20 =20 =20 =20 =20 =20 =20

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


--001a1143920e3da482052af95555-- From nobody Thu Feb 4 14:46: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 58B9E1B3343 for ; Thu, 4 Feb 2016 14:46:38 -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 10NBbM99jxpv for ; Thu, 4 Feb 2016 14:46:36 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 9400F1B3346 for ; Thu, 4 Feb 2016 14:46:32 -0800 (PST) Received: by mail-pa0-x22d.google.com with SMTP id cy9so22827599pac.0 for ; Thu, 04 Feb 2016 14:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=T7vsi8XvKR4JVmklnt7Jqe/Nvz9VnmJ8Dyokt2vZ5iM=; b=mWpqTHt0KuRHbtdCTApCcIJsq9GqB5qyuL2yiVQ064DZYCYXZEaGdnRXExEtk1UdeE 4p/guOOq5V/EThhKRKYyyBijpan8A1f8gCLj0GIe8OGAGau0jaHaQhKQ/f4S/jzcyMtC jZkKp333eEliZzg74A0vKaFN1pOoF7BvJzkZa77PqtY0zC+iV/3x6Ik+ndxpjxzAeoPc Prg5J8w5MxmymufYKiEtWEDcxd4vHq+fgoUQyYvI8hG+CFbSN5Qvj7LcBmXLp0vqhvK0 LeHstHgYiT2SVEO4Dv4veYsR9OKsyGaqGCOfIQTy+LZXIODkBZwEa6SVlwlikfE7qOUu tqAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=T7vsi8XvKR4JVmklnt7Jqe/Nvz9VnmJ8Dyokt2vZ5iM=; b=V3y20r0q6t7NRNUI5DfggJTIV4iUdAzKa7loPNjt19QFNEZCaB/LDXNgFhqp0AyBRt NaxZzeYRpnWCJqmfgr52Ct2jtdVMcbjhDdh4+CCeBLJXluDxwQV15uXd1JbbKmAYXAng R2Xk0tvIz0K/zkydbYvmfBgjtw9DrClpMIid34kGG093mVr7d9ERXvZwtCr+rpd1NAkA A78QonsMYK7MjbugHBcGmSzjz4gZC6ez2EoI+9IZDf78nNfWoxO2wc1yfPVCQV9A4awz kEuA7IK3/kMa5stm/Tkp/tZ2Ar3D/+a1cOksga7oBLU/428PyTlcdrDg4PeCEVCergev 9ZaA== X-Gm-Message-State: AG10YOSOAXyTzlAIy/uHs9GKQVeJld5AdzwYdYDcqZ8RMht5sZDpMEl2P+Rhh6/6Gqt85Q== X-Received: by 10.66.119.10 with SMTP id kq10mr10374607pab.37.1454625992184; Thu, 04 Feb 2016 14:46:32 -0800 (PST) Received: from ?IPv6:2602:306:83ae:c480:9991:4e75:1b79:2fe5? ([2602:306:83ae:c480:9991:4e75:1b79:2fe5]) by smtp.googlemail.com with ESMTPSA id i13sm19407325pfi.95.2016.02.04.14.46.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 14:46:31 -0800 (PST) To: Suhas Nandakumar References: <56B3A98B.9030302@gmail.com> From: Byron Campen Message-ID: <56B3D4C5.3060706@gmail.com> Date: Thu, 4 Feb 2016 16:46:29 -0600 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: Content-Type: multipart/alternative; boundary="------------030309000500030800090909" Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-02 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, 04 Feb 2016 22:46:38 -0000 This is a multi-part message in MIME format. --------------030309000500030800090909 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/4/16 4:34 PM, Suhas Nandakumar wrote: > > > On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen > wrote: > > As far as the open issues go, the proposals look fine to me. > > Issues: > > In section 6.4, step 5, we might want to point out that the > offerer cannot simply look at the list of payload types, since the > answerer may be using payload type asymmetry. The offerer will > need to map each payload type to a codec description on both > sides, and then make sure the set of codec descriptions for that > rid in the answer is a subset of those in the offer. > > > [Suhas] Payload type asymmetry is a standard feature with SDP out of > RID. Should we really need to explicitly specify that fact ? I think so, because otherwise I predict lots of interop problems. > > "Expressing all these codecs and resolutions using 32 dynamic PTs > (2 audio + 10x3 video) would exhaust the primary dynamic space > (96-127). RIDs are used to avoid PT exhaustion and express the > resolution constraints." > > This is not adding up for me, because there is no requirement > that PTs be unique across m-sections. The sendrecv m-section for > video needs 10 PTs, but the other m-sections can overlap that. It > might be kinda tricky to come up with a scenario that exceeds 32 > without simulcast, but I don't really see why we need to talk > about PT exhaustion in the RID spec, since that's more of a > simulcast concern. > > > [Suhas] There are 10 video codecs and need to express 3 different > resolutions. If I am not reading it wrong, the example shows just > using 10 codecs coupled with RID for defining varied resolutions > allows us not to exhaust the Payload Types. > > OTOH, if we remove the rid lines from the m= lines in the example and > express the resolutions as part of PT, then we will end up with 10 X 3 > Payload Types. > Each m-section has only 1 RID (because we're not doing simulcast), so there is no 3x multiplier here. Best regards, Byron Campen --------------030309000500030800090909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/4/16 4:34 PM, Suhas Nandakumar wrote:


On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen <docfaraday@gmail.com> wrote:
    As far as the open issues go, the proposals look fine to me.

Issues:

    In section 6.4, step 5, we might want to point out that the offerer cannot simply look at the list of payload types, since the answerer may be using payload type asymmetry. The offerer will need to map each payload type to a codec description on both sides, and then make sure the set of codec descriptions for that rid in the answer is a subset of those in the offer.


[Suhas] Payload type asymmetry is a standard feature with SDP out of RID. Should we really need to explicitly specify that fact ?
    I think so, because otherwise I predict lots of interop problems.


 
"Expressing all these codecs and resolutions using 32 dynamic PTs (2 audio + 10x3 video) would exhaust the primary dynamic space (96-127). RIDs are used to avoid PT exhaustion and express the resolution constraints."

    This is not adding up for me, because there is no requirement that PTs be unique across m-sections. The sendrecv m-section for video needs 10 PTs, but the other m-sections can overlap that. It might be kinda tricky to come up with a scenario that exceeds 32 without simulcast, but I don't really see why we need to talk about PT exhaustion in the RID spec, since that's more of a simulcast concern.


[Suhas] There are 10 video codecs and need to express 3 different resolutions. If I am not reading it wrong, the example shows just using 10 codecs coupled with RID for defining varied resolutions allows us not to exhaust the Payload Types.

OTOH, if we remove the rid lines from the m= lines in the example and express the resolutions as part of PT, then we will end up with 10 X 3 Payload Types.

   Each m-section has only 1 RID (because we're not doing simulcast), so there is no 3x multiplier here.

Best regards,
Byron Campen
--------------030309000500030800090909-- From nobody Thu Feb 4 16:17: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 E358E1ACE52 for ; Thu, 4 Feb 2016 16:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] 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 o3N_uwbWw0Ny for ; Thu, 4 Feb 2016 16:17:35 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904031ACE44 for ; Thu, 4 Feb 2016 16:17:35 -0800 (PST) Received: from [81.187.2.149] (port=46704 helo=[192.168.0.64]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRU5c-0002yL-Ss; Fri, 05 Feb 2016 00:17:33 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56B22757.9090906@nostrum.com> Date: Fri, 5 Feb 2016 00:17:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B22757.9090906@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: mmusic Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-01 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, 05 Feb 2016 00:17:37 -0000 > On 3 Feb 2016, at 16:14, Adam Roach wrote: > On 2/2/16 11:41, Colin Perkins wrote: >> I didn=E2=80=99t find a precise specification in the draft for what = RID parameters constrain what =E2=80=9Ca=3Dfmtp:" parameters, for what = RTP payload formats. I think this draft needs a complete list of which = parameters are constrained by each RID parameter, to ensure unambiguous = behaviour with existing codecs. >=20 > I fear such an approach may be intractable. On a quick analysis, I = find almost 100 RFCs that define "a=3Dfmtp" parameters, and most of = those define more than one. If you want to volunteer to slog through = that entire corpus and figure out which correspond to the constraints = we're defining, I'll happily accept the output of that work. But I = suspect you'll reach the same conclusion as I did: it=E2=80=99s not a = reasonable task. I=E2=80=99m not volunteering, but I think the problem is smaller than it = seems, since this only applies to video codecs that have flexibility in = encoding. Many of those 100 RFCs are for audio, text, or FEC formats, = and many of the remaining are for video codecs are have insufficient = flexibility to be impacted by the constraints, or are effectively = obsolete.=20 At the least, it ought to do the analysis and mapping of a=3Dfmtp = parameters to rid constraints for the small number of modern codecs that = people are likely to use - the WebRTC recommendations, for example. > That said, the principle here is pretty easy to grasp: when the = "a=3Dfmtp" parameters constrain your encoding in some way, and the = "a=3Drid" parameters also constrain your encoding in some way, you need = to meet both constraints simultaneously. If you think there's some text = we can add to Section 9 to clarify this principle, I'm happy to expound = on it. But I=E2=80=99m pretty certain that the future-proof approach = here is to lay out a principle of interaction, rather than (for example) = spending the energy to figure out how the "pgroup" parameter for SMPTE = 292M might interact with any of the constraints we're defining, and then = doing that same kind of analysis hundreds of times over. Sure, I understand, if it can be done without ambiguity.=20 >> Also, to ensure consistency going forward, the draft should probably = give some guidance to the PAYLOAD working group, mandating =E2=80=9Ca=3Dfm= tp:=E2=80=9D parameter names for common features when defining future = payload formats, so they match the RID parameter names if they=E2=80=99re = intended to be restricted by RID parameters, and to use different names = otherwise. >=20 > Trying to harmonize PAYLOAD's handling of = seems to be somewhat outside the scope of what this document is doing. I = mean, I get that the lack of coordination of constraining parameters on = video codecs is a pretty sad state of affairs, but it's not really fair = to shackle this draft to the task of solving that mess before it can = move forward. >=20 > To be clear, I'd be happy to see some kind of guidance regarding = put forth in an independent document so = that there is at least a modicum of uniformity for future formats. I = just think it's not in the scope of the RID work. I thought this wasn=E2=80=99t do bad: =E2=80=9Cregistrations of future = RTP payload format specifications that define media types that have = parameters matching the RID constraints specified in this memo SHOULD = name those parameters in a manner that matches the names of those RID = constraints, and SHOULD explicitly state what media type parameters are = constrained by what RID constraints=E2=80=9D? IANA considerations: "this draft updates RFC 4855 to give additional = guidance on choice of parameter names, and on their relation to RID = constraints [RFC XXXX]=E2=80=9D Whether that goes in this draft, or in a short draft for PAYLOAD, = isn=E2=80=99t so important.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Thu Feb 4 19:43: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 281651B3467 for ; Thu, 4 Feb 2016 19:43:15 -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 3hSnfgf6wHb7 for ; Thu, 4 Feb 2016 19:43:14 -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 0B6FB1B3466 for ; Thu, 4 Feb 2016 19:43:14 -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=CNjHeMSyW0ThqMqY37B4dAqXUTzVxzilBYX+2XTNoRM=; b=Be8zGU5BHvHSheT6wHRxMWNo7u uDQ/ZcqcJHKvNwnELLAnkGGxCMEM91azzoZOnLGMMDzkSSgKpJ5gkWaEBEa3W1B2UljVcM2kbY0E5 0ORW0fhZT49vEq9zz1o5VGW5/xEo3STywZgrPNAxBlYibZWSSOHGJoKaeahurMZpVtRskpEhR0GIE Gwh+YvTqNl4MdXkbVddqNBEha4f1k27NjxWgNjmBXxRee5li3cnprnzjmoVNr1WA/HKxjgOorm19/ wmiGiyDSBTxqqkvGBtVpstav912wDJQe6JncycN5SX2IteIyY964YYak6zgqVMuFr76qtMC2Ejxk0 dl/eGklQ==; Received: from ppp118-209-214-147.lns20.mel8.internode.on.net ([118.209.214.147]:50946 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aRXIc-0019bE-1p for mmusic@ietf.org; Fri, 05 Feb 2016 14:43:10 +1100 To: 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> From: Christian Groves Message-ID: <56B41A47.10901@nteczone.com> Date: Fri, 5 Feb 2016 14:43:03 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B2DA8D.2000909@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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, 05 Feb 2016 03:43:15 -0000 Isn't this the approach we're taking today? draft-ietf-mmusic-data-channel-sdpneg has general text and specific drafts are used to describe protocols that use the mechanism (i.e. draft-ietf-mmusic-msrp-usage-data-channel & draft-ietf-clue-datachannel). Regards, Christian On 4/02/2016 3:58 PM, Paul Kyzivat wrote: > On 2/3/16 5:42 PM, Flemming Andreasen wrote: > >> I'm not concerned about the IANA part. I agree that *if* we need to >> expliclty specify attribute interactions for "dcsa", then it should be >> part of the IANA registry. What I am not agreeing with at this point is >> that there is indeed a need to explicitly speficy these interactions as >> opposed to relying on a more general algorithmic approach (plus the >> offerer being responsible for generating a valid offer if he wants to >> establish a data channel). > > Well, an obvious one is that the protocol(s) the attribute pertains to > need to be defined to work over data channels. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Feb 5 02:57:10 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 AC0001A1B69; Fri, 5 Feb 2016 02:57:09 -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: <20160205105709.9575.96717.idtracker@ietfa.amsl.com> Date: Fri, 05 Feb 2016 02:57:09 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 10:57:09 -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-06.txt Pages : 21 Date : 2016-02-05 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 5 08:29: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 008741B3B37; Fri, 5 Feb 2016 08:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 ZyXA6MIu6sBY; Fri, 5 Feb 2016 08:29:05 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C901B3B2C; Fri, 5 Feb 2016 08:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=483; q=dns/txt; s=iport; t=1454689745; x=1455899345; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=zPJgsyaEtA9kfH/OzFpel8UM1/nItjbhnoSCX6eYOlw=; b=JRu3ahTjcAN+9vBpaoDR+gdjDabxoGKc0tLD8bctZZRaAXkAjI2jR5Lq vq6Bk9OGXKZBaxJtcvvn2uR9thUTNXQe6X8W4vW5T0xEmu+sAqntCT4pM +7rVs3d/vkiEJPP7uXtdTbC4jqPPrplXLP9KJ8kb2iUZGkfPp1RgwpLLj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAwBmzbRW/5BdJa1egzpSbYhbqW6FD?= =?us-ascii?q?IITAQ2BZiGFbIE2OBQBAQEBAQEBgQqERCcVQAE1AgUWCwILAwIBAgFLDQgBAYg?= =?us-ascii?q?XDrB6jmEBAQEBAQEBAwEBAQEBAQEVBHuFF4tpgToFjhuIWo1QgVuEQ4MDhDiBG?= =?us-ascii?q?o4+HgEBQoQCHi4BiXsBAQE?= X-IronPort-AV: E=Sophos;i="5.22,401,1449532800"; d="scan'208";a="235332302" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2016 16:29:05 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u15GT4ad003479; Fri, 5 Feb 2016 16:29:04 GMT To: mmusic From: Flemming Andreasen Message-ID: <56B4CDCF.4080100@cisco.com> Date: Fri, 5 Feb 2016 11:29:03 -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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-dtls-sdp@ietf.org Subject: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:29:07 -0000 Greetings MMUSIC This is to announce a 2 week WGLC on the draft: https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-06.txt as Proposed Standard. Please review and provide any comments you may have on the document by Friday, February 19, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Fri Feb 5 09:23:55 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 AEAE91B2B23; Fri, 5 Feb 2016 09:23:53 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160205172353.9403.37120.idtracker@ietfa.amsl.com> Date: Fri, 05 Feb 2016 09:23:53 -0800 Archived-At: Cc: mmusic-chairs@ietf.org, mmusic@ietf.org, The IESG Subject: [MMUSIC] WG Action: Rechartered Multiparty Multimedia Session Control (mmusic) 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, 05 Feb 2016 17:23:53 -0000 The Multiparty Multimedia Session Control (mmusic) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Multiparty Multimedia Session Control (mmusic) ----------------------------------------------------------------------- Current status: Active WG Chairs: Flemming Andreasen Bo Burman Assigned Area Director: Ben Campbell Mailing list: Address: mmusic@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/mmusic Archive: https://mailarchive.ietf.org/arch/browse/mmusic/ Charter: https://datatracker.ietf.org/doc/charter-ietf-mmusic/ The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was originally chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployment. Currently, the group is focused on using and negotiating media streams with the Session Description Protocol (SDP), which is used as a common protocol to express media and session descriptions. The group also maintains the Real-time Streaming Protocol (RTSP) specifications. The group has revised these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVTCORE, CLUE, ICE, and RTCWEB). In particular, the many uses of SDP have led to requests for numerous extensions as well as a recognition of several limitations in the original protocol design. Today, the SDP protocol is widely deployed and continues to see extensions being defined. The current aims of the working group include the following: - Provide SDP signaling support for the Interactive Connectivity Establishment (ICE) protocol and its extensions. These were originally defined in MMUSIC, but are now handled by the ICE WG. - To support the establishment of multi-party multimedia sessions for RTCWEB based implementations, MMUSIC provides SDP signaling support for a number of extensions required by RTCWEB. The MMUSIC WG will seek a balanced trade-off between general applicability of such extensions versus RTCWEB specific usage. - Various other extensions to SDP may be pursued to remedy the most urgent of SDP's shortcomings. These include updates to the SDP specification itself and missing IANA registrations. - With the exception of the items listed above, only extensions within the existing SDP framework will be done. - Maintain the specification of the (revised) Real Time Streaming Protocol (RTSP) as needed. The MMUSIC work items will be pursued in close coordination with other IETF WGs including AVTCORE, CLUE, ICE, RTCWEB and SIPCORE, as well as others where appropriate. Milestones: Dec 2015 - Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard Dec 2015 - Submit SDP extension for cross session stream identification as Proposed Standard Dec 2015 - Submit a framework for SDP attributes when multiplexing as Proposed Standard Dec 2015 - Submit SDP Negotiation of DataChannel sub-protocols as Proposed Standard Dec 2015 - Submit IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles as Proposed Standard Jan 2016 - Submit Using Simulcast in SDP and RTP Sessions as Proposed Standard Feb 2016 - Submit SIP usage for Trickle ICE as Proposed Standard Feb 2016 - Using the SDP Offer/Answer Mechanism for DTLS Feb 2016 - Submit RTP Payload Format Constraints as Proposed Standard Mar 2016 - Submit revised SDP specification to IETF as Proposed Standard Mar 2016 - Submit MSRP over Data Channels as Proposed Standard Apr 2016 - Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard May 2016 - Submit SCTP-Based Media Transport in SDP as Proposed Standard. May 2016 - Submit Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP as Proposed Standard From nobody Fri Feb 5 13:02: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 0C0271AD01E for ; Fri, 5 Feb 2016 13:02:31 -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 xaAoeRPMozKo for ; Fri, 5 Feb 2016 13:02:29 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 82D801AD0C8 for ; Fri, 5 Feb 2016 13:02:29 -0800 (PST) Received: by mail-ob0-x230.google.com with SMTP id wb13so100759548obb.1 for ; Fri, 05 Feb 2016 13:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eo/xCDm2X1U1nArVZa6DP6jPEwdw0fK7nxohyRpTcFQ=; b=nBot2lX3+tT0S6nBgdVGmhhscOT5wpkzUIg57jO8bNEkQCUOl6N6XBIWJlwJQYOT7v aE0clwb5877kotBl01SXobrClodEOaCKuYGGledVVAzM5ea/+TC+kOBi2P5+5N1EmmMV brzh8wWDa63HpnoptjLeHVwoxZNk+nfCmRoZgwvV6r9EItNOflVs6SBosyTn4tRVOQ7m 9zO3Z99CC2rYxFHQYVxpAEdIcCuajO3INFNeZpgsWbgtIgQDHB34OMPMvxl2EvwUf8+P vmYx1PRo5w+0g8rQZksxQmLBcOCkcjFp1XupBO0OIthrbGGQ5rnD1CZbsusPSvFFhy/3 z3TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eo/xCDm2X1U1nArVZa6DP6jPEwdw0fK7nxohyRpTcFQ=; b=Lq1ImjsQ/pO7C13xRNPdMbUEFnjXiFWcySK6hYRsOpex0pmULwUG1ZMR1dfwdi0w+C JZk9OmjbQQLyK6LOGxOe5JFQjCewMgktGLUQM64SvccBrzb+NAsNCWolJembdN1qwd7d r2fB8toi2MdPHE3/NQr4DnwOLtRJa0YUplBCxLNcCkTA2bwrXAXGWf0wq9dItAq/mA1R aXe95OYdgb71s3iLV0hgIxOgxyx5P0DF21ghOuEFPnhSpDgEoHmJEdB/0XPETVxyBsLE 5T2i/89vqk3r6v5krLlO4qDqpbz+i6qk2QUJIZ7QAzZDaooyHsS+QdCUq3y8Y2tN+HBn ZHnw== X-Gm-Message-State: AG10YOTsSTVKjXXT9dsJnRrpE/oizKcs0pWQTepFB/b+3X3iLrzLu8N4ZN2mE3NWDSOr4DC01RSpaJnHQ7Awy5BF X-Received: by 10.182.63.40 with SMTP id d8mr2834642obs.48.1454706148751; Fri, 05 Feb 2016 13:02:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Fri, 5 Feb 2016 13:01:48 -0800 (PST) In-Reply-To: <566F2202.5010107@cisco.com> References: <566F2202.5010107@cisco.com> From: Peter Thatcher Date: Fri, 5 Feb 2016 13:01:48 -0800 Message-ID: To: Flemming Andreasen Content-Type: multipart/alternative; boundary=e89a8fb1f7d04003fd052b0c2ba7 Archived-At: Cc: draft-ietf-mmusic-rid@ietf.org, mmusic Subject: Re: [MMUSIC] Progressing the rid draft (RTP Payload Format Constraints) 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, 05 Feb 2016 21:02:31 -0000 --e89a8fb1f7d04003fd052b0c2ba7 Content-Type: text/plain; charset=UTF-8 Having just re-read draft-ietf-mmusic-rid-02 from to top to bottom, I think it's in a very good state. I only have minor readability and editorial comments where I think it could be improvements. On small matters of readability: - We use the term "RID RTP streams", which is then defined in another spec as "source RTP Streams". Can we just call them "source RTP streams" here too and save the reader some indirection? - We use the terms "constraints", "parameters" and even "constraining parameters", which I believe all mean the same thing. Can we just pick one and save the reader some disambiguation? On the open issues: 11.1 (declarative SDP): I agree with keeping the current text. 11.2 (bitrate definition): I agree with keeping the current text. 11.3 (escaping values): I agree with option #3 (let a future extension define it, if needed). 11.4 (max-width and max-height): Either way is fine to me (included or not). 11.5 (max-fps definition): I agree with keeping the current text. And finally, some very minor editoral things: - The sentence "All "rid" parameters MUST be registered ... Section 12" doesn't have a period at the end. - The sentence "The SDP given below skips few lines" should be "The SDP given below skips a few lines". On Mon, Dec 14, 2015 at 12:09 PM, Flemming Andreasen wrote: > Greetings MMUSIC > > As you know, we have an external dependency and a fairly aggressive > timeline on the RTP Payload Format Constraints draft ( > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/) > > We haven't seen much list traffic on this draft since the Yokohama meeting > and hence would like to remind people to please take a look at and post any > comments you may have on the draft. If you have read the current version of > the draft and don't have any comments on it, we would like to hear about > that too. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > --e89a8fb1f7d04003fd052b0c2ba7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Having just re-read=C2=A0draft-ietf-mmusic-rid-02 from = to top to bottom, I think it's in a very good state.=C2=A0 I only have = minor readability and editorial comments where I think it could be improvem= ents. =C2=A0


On small matters of readability:

- We use the term "RID RTP streams&quo= t;, which is then defined in another spec as "source RTP Streams"= .=C2=A0 Can we just call them "source RTP streams" here too and s= ave the reader some indirection?

- We use the terms "constraints", "= ;parameters" and even "constraining parameters", which I bel= ieve all mean the same thing.=C2=A0 Can we just pick one and save the reade= r some=C2=A0disambiguation? =C2=A0<= /font>

<= div class=3D"gmail_default">On the open issues:
=

11.1 (declarative SDP): I agree with keeping the curr= ent text.

11.2 (bitrate definition): I agree with keep= ing the current text.

11.3 (escaping values): I agree= with option #3 (let a future extension define it, if needed).

=
11.4 (max-width and max-height): Either way is fine to me (include= d or not).

11.5 (max-fps definition): I agree with kee= ping the current text.


And finally, some very minor ed= itoral things:

- The sentence "All "rid"= ; parameters MUST be registered ... Section 12" doesn't have a per= iod at the end.

- The sentence "The SDP given bel= ow skips few lines" should be "The SDP given below skips a few li= nes".


=
On Mon, Dec 14, 2015 at 12:09 PM, Flemming A= ndreasen <fandreas@cisco.com> wrote:
Greetings MMUSIC

As you know, we have an external dependency and a fairly aggressive timelin= e on the RTP Payload Format Constraints draft (https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/)

We haven't seen much list traffic on this draft since the Yokohama meet= ing and hence would like to remind people to please take a look at and post= any comments you may have on the draft. If you have read the current versi= on of the draft and don't have any comments on it, we would like to hea= r about that too.

Thanks

-- Flemming (as MMUSIC co-chair)



--e89a8fb1f7d04003fd052b0c2ba7-- From nobody Fri Feb 5 13:36: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 8C4E51B2CE9; Fri, 5 Feb 2016 13:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 EZgkKnimHTT8; Fri, 5 Feb 2016 13:36:29 -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 F16D31B2CE1; Fri, 5 Feb 2016 13:36:28 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u15LaMZM059806 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 5 Feb 2016 15:36:23 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Peter Thatcher , Flemming Andreasen References: <566F2202.5010107@cisco.com> From: Adam Roach Message-ID: <56B515D6.9090005@nostrum.com> Date: Fri, 5 Feb 2016 15:36:22 -0600 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: multipart/alternative; boundary="------------010800090404020006070309" Archived-At: Cc: draft-ietf-mmusic-rid@ietf.org, mmusic Subject: Re: [MMUSIC] Progressing the rid draft (RTP Payload Format Constraints) 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, 05 Feb 2016 21:36:30 -0000 This is a multi-part message in MIME format. --------------010800090404020006070309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/5/16 15:01, Peter Thatcher wrote: > Having just re-read draft-ietf-mmusic-rid-02 from to top to bottom, I > think it's in a very good state. I only have minor readability and > editorial comments where I think it could be improvements. Thanks! > On small matters of readability: > > - We use the term "RID RTP streams", which is then defined in another > spec as "source RTP Streams". Can we just call them "source RTP > streams" here too and save the reader some indirection? But it's not exactly "a Source RTP Stream". It's "a Source RTP Rtream, *or* the non-redundant RTP Stream of a Dependent Stream," which is a bit too unwieldy to use all over the document. This distinction between "Source RTP Stream" and "RID RTP Stream" is small but important. If you want to suggest a different term for this construct, I'm quite keen to have a more intuitive term. But I spent probably way too much time scratching my head over this without coming up with anything better than "RID RTP Stream". You can argue that RFC 7576 should have defined a term that we could just use here, and I would heartily agree. But it didn't, and we've got to work with the terms as published. > - We use the terms "constraints", "parameters" and even "constraining > parameters", which I believe all mean the same thing. Can we just > pick one and save the reader some disambiguation? I'll make a pass to clean this up. I'm going to go with "constraint" so as to avoid confusion with ftmp parameters. > On the open issues: > > 11.1 (declarative SDP): I agree with keeping the current text. > > 11.2 (bitrate definition): I agree with keeping the current text. > > 11.3 (escaping values): I agree with option #3 (let a future extension > define it, if needed). > > 11.4 (max-width and max-height): Either way is fine to me (included or > not). > > 11.5 (max-fps definition): I agree with keeping the current text. Thanks for explicitly commenting on the open issues. :) > And finally, some very minor editoral things: > > - The sentence "All "rid" parameters MUST be registered ... Section > 12" doesn't have a period at the end. > > - The sentence "The SDP given below skips few lines" should be "The > SDP given below skips a few lines". > Good catches. Thanks. /a --------------010800090404020006070309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/5/16 15:01, Peter Thatcher wrote:
Having just re-read draft-ietf-mmusic-rid-02 from to top to bottom, I think it's in a very good state.  I only have minor readability and editorial comments where I think it could be improvements.

Thanks!

 On small matters of readability:

- We use the term "RID RTP streams", which is then defined in another spec as "source RTP Streams".  Can we just call them "source RTP streams" here too and save the reader some indirection?

But it's not exactly "a Source RTP Stream". It's "a Source RTP Rtream, *or* the non-redundant RTP Stream of a Dependent Stream," which is a bit too unwieldy to use all over the document.

This distinction between "Source RTP Stream" and "RID RTP Stream" is small but important. If you want to suggest a different term for this construct, I'm quite keen to have a more intuitive term. But I spent probably way too much time scratching my head over this without coming up with anything better than "RID RTP Stream".

You can argue that RFC 7576 should have defined a term that we could just use here, and I would heartily agree. But it didn't, and we've got to work with the terms as published.


- We use the terms "constraints", "parameters" and even "constraining parameters", which I believe all mean the same thing.  Can we just pick one and save the reader some disambiguation?

I'll make a pass to clean this up. I'm going to go with "constraint" so as to avoid confusion with ftmp parameters.
 
On the open issues:

11.1 (declarative SDP): I agree with keeping the current text.

11.2 (bitrate definition): I agree with keeping the current text.

11.3 (escaping values): I agree with option #3 (let a future extension define it, if needed).

11.4 (max-width and max-height): Either way is fine to me (included or not).

11.5 (max-fps definition): I agree with keeping the current text.

Thanks for explicitly commenting on the open issues. :)

And finally, some very minor editoral things:

- The sentence "All "rid" parameters MUST be registered ... Section 12" doesn't have a period at the end.

- The sentence "The SDP given below skips few lines" should be "The SDP given below skips a few lines".


Good catches. Thanks.

/a

--------------010800090404020006070309-- From nobody Fri Feb 5 13:45: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 8F65E1B2D74 for ; Fri, 5 Feb 2016 13:45:10 -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 XETWgP3ICSfI for ; Fri, 5 Feb 2016 13:45:08 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 7288F1B2D02 for ; Fri, 5 Feb 2016 13:45:08 -0800 (PST) Received: by mail-ob0-x235.google.com with SMTP id wb13so101655007obb.1 for ; Fri, 05 Feb 2016 13:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vvGrtUPQsPqabsxrV5WP8yCA6D/3qeoHCfsbYudDyYI=; b=CRCQSIUeOLUDeaGeh/joLLhoYAxlcP8+0RzRBI3VF3pZ6ZTTaj2V3FdiDfmFa4E7WD Sk868WIXn0gq6QmxyweBn9gzYFUkCckRPPdtrARLvV4KYAnnQCiC41MeO0irGilcZmXb Doqmh7rSfYCvh4RUNb8IaozksuaM10OBl2XCrjTPXiWnwz0sKNjFb9GVBqcbj7XuM5h1 yxlj8PWvtSt3IN9R+PymY0E01PwRlUhRuNd0orZBeKWqJSOqD6qMpy/GcHoCR8ed6k9p f1VbTNlVGFYLA+EUr97ZTyKIRCZ8dIvYK6z60mFrc3JDQMoEgBs7wPi4yYFh6vuaznSZ 6rbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vvGrtUPQsPqabsxrV5WP8yCA6D/3qeoHCfsbYudDyYI=; b=GHZjCFEdcT7cozT/sp8NtjWukEkJ6uozAPZQVDdWmta2HIaTLNMbcHPNAU+lgR9D1o R0GMGSCnwY8sEEsfdkk7mRUEW5glO5F18O/Mpmx6UeLYOKh/sAI6qwuv63LqVXsBOWaQ oXQMQ+6LQ90Vo7Pa/J8SbuGyADlpRlLdqkUO2yA8TJnHV5nMx9EZyQjvTnWHK2IQaGvL aDMhtbfkVR3ntPIYVFyVileLNuBnO3Z0nig5v3WSW4ty+L6yEevBNG+B6hcYtQ+m5chR bLRl8rmZlOKYbr1TyjcY/kS0sCjCQeYnIdiPMLDAzyEqp9twuM83sm6+FbDx/hbRFWGU 8DOA== X-Gm-Message-State: AG10YOQxAMnaZFFJrzEwZqt+PeGpq3ckMGwxoGrw5lMZWYuNXi/HsrfNdF8/x+aA3ZVS7R+zG2EHF9zO1SyG8N9Z X-Received: by 10.182.129.228 with SMTP id nz4mr13920689obb.14.1454708707723; Fri, 05 Feb 2016 13:45:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.226.205 with HTTP; Fri, 5 Feb 2016 13:44:28 -0800 (PST) In-Reply-To: <56B515D6.9090005@nostrum.com> References: <566F2202.5010107@cisco.com> <56B515D6.9090005@nostrum.com> From: Peter Thatcher Date: Fri, 5 Feb 2016 13:44:28 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=089e0149c716c6f0b8052b0cc336 Archived-At: Cc: Flemming Andreasen , draft-ietf-mmusic-rid@ietf.org, mmusic Subject: Re: [MMUSIC] Progressing the rid draft (RTP Payload Format Constraints) 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, 05 Feb 2016 21:45:10 -0000 --089e0149c716c6f0b8052b0cc336 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 5, 2016 at 1:36 PM, Adam Roach wrote: > On 2/5/16 15:01, Peter Thatcher wrote: > > Having just re-read draft-ietf-mmusic-rid-02 from to top to bottom, I > think it's in a very good state. I only have minor readability and > editorial comments where I think it could be improvements. > > > Thanks! > > On small matters of readability: > > - We use the term "RID RTP streams", which is then defined in another spe= c > as "source RTP Streams". Can we just call them "source RTP streams" here > too and save the reader some indirection? > > > But it's not exactly "a Source RTP Stream". It's "a Source RTP Rtream, > *or* the non-redundant RTP Stream of a Dependent Stream," which is a bit > too unwieldy to use all over the document. > Oh yes, I forgot about that little wrinkle in the taxonomy. =E2=80=8B > =E2=80=8B > > This distinction between "Source RTP Stream" and "RID RTP Stream" is smal= l > but important. If you want to suggest a different term for this construct= , > I'm quite keen to have a more intuitive term. But I spent probably way to= o > much time scratching my head over this without coming up with anything > better than "RID RTP Stream". > > You can argue that RFC 7576 should have defined a term that we could just > use here, and I would heartily agree. But it didn't, and we've got to wor= k > with the terms as published. > You're right. Let's just s tick =E2=80=8Bwith=E2=80=8B "RID RTP Stream" =E2=80=8B. =E2=80=8B > > > > - We use the terms "constraints", "parameters" and even "constraining > parameters", which I believe all mean the same thing. Can we just pick o= ne > and save the reader some disambiguation? > > > I'll make a pass to clean this up. I'm going to go with "constraint" so a= s > to avoid confusion with ftmp parameters. > =E2=80=8BSounds good. =E2=80=8B > > > > On the open issues: > > 11.1 (declarative SDP): I agree with keeping the current text. > > 11.2 (bitrate definition): I agree with keeping the current text. > > 11.3 (escaping values): I agree with option #3 (let a future extension > define it, if needed). > > 11.4 (max-width and max-height): Either way is fine to me (included or > not). > > 11.5 (max-fps definition): I agree with keeping the current text. > > > Thanks for explicitly commenting on the open issues. :) > > And finally, some very minor editoral things: > > - The sentence "All "rid" parameters MUST be registered ... Section 12" > doesn't have a period at the end. > > - The sentence "The SDP given below skips few lines" should be "The SDP > given below skips a few lines". > > > Good catches. Thanks. > > /a > > --089e0149c716c6f0b8052b0cc336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 5, 2016 at 1:36 PM, Adam Roach &= lt;adam@nostrum.com> wrote:
=20 =20 =20
On 2/5/16 15:01, Peter Thatcher wrote:
Having just re-read=C2=A0draft-ietf-mmusic-rid-02 from to top to bottom, I think it's in a very good state.=C2=A0 I only have minor readability and editorial comments where I think it could be improvements.

 Thanks!

=C2=A0On small matters of readability:

- We use the term "RID RTP streams", which is then defined in another spec as "s= ource RTP Streams".=C2=A0 Can we just call them "source RTP= streams" here too and save the reader some indirection?

 But it's not exactly "a Source RTP Stream". It's &quo= t;a Source RTP Rtream, *or* the non-redundant RTP Stream of a Dependent Stream," which is a bit too unwieldy to use all over the document.

Oh yes, = I forgot about that little wrinkle in the taxonomy.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;display:inline">


--089e0149c716c6f0b8052b0cc336-- From nobody Fri Feb 5 14:54:35 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 DACF71B2E7E for ; Fri, 5 Feb 2016 14:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 2VTcrg7XWHNi for ; Fri, 5 Feb 2016 14:54:30 -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 6259D1B2E79 for ; Fri, 5 Feb 2016 14:54:30 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u15MsRHM066809 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 5 Feb 2016 16:54:28 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Byron Campen , mmusic@ietf.org References: <56B3A98B.9030302@gmail.com> From: Adam Roach Message-ID: <56B52823.5060503@nostrum.com> Date: Fri, 5 Feb 2016 16:54:27 -0600 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: <56B3A98B.9030302@gmail.com> Content-Type: multipart/alternative; boundary="------------010209040102090008010203" Archived-At: Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-02 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, 05 Feb 2016 22:54:33 -0000 This is a multi-part message in MIME format. --------------010209040102090008010203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/4/16 13:42, Byron Campen wrote: > As far as the open issues go, the proposals look fine to me. Hooray! That's two-for-two. > Issues: > > In section 6.4, step 5, we might want to point out that the > offerer cannot simply look at the list of payload types, since the > answerer may be using payload type asymmetry. The offerer will need to > map each payload type to a codec description on both sides, and then > make sure the set of codec descriptions for that rid in the answer is > a subset of those in the offer. Good point. This is pretty easy to understand, but ended up being more difficult to describe than I expected. :) 5. If the "a=rid" line in the answer contains a "pt=" and the offer did as well, the offerer verifies that the list of payload types is a subset of those sent in the corresponding "a=rid" line in the offer. Note that this matching must be performed semantically rather than on literal PT values, as the remote end may not be using symmetric PTs. For the purpose of this comparison: for each PT listed in the "pt=", the offerer looks up the "a=rtpmap" and "a=fmtp" lines in the answer. It then searches the list of "pt=" values indicated in the offer, and attempts to find one with an equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If all PTs in the answer can be matched, then the "pt=" values pass validation; otherwise, it fails. If this validation fails, the offerer SHALL discard the "a=rid" line. > "Expressing all these codecs and resolutions using 32 dynamic PTs (2 > audio + 10x3 video) would exhaust the primary dynamic space (96-127). > RIDs are used to avoid PT exhaustion and express the resolution > constraints." > > This is not adding up for me, because there is no requirement that > PTs be unique across m-sections. The sendrecv m-section for video > needs 10 PTs, but the other m-sections can overlap that. It might be > kinda tricky to come up with a scenario that exceeds 32 without > simulcast, but I don't really see why we need to talk about PT > exhaustion in the RID spec, since that's more of a simulcast concern. I think you're right. I'm striking the paragraph. > Nits/editorial: Fixed. Thanks. Dropping a -03 soon. /a --------------010209040102090008010203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/4/16 13:42, Byron Campen wrote:
    As far as the open issues go, the proposals look fine to me.

Hooray! That's two-for-two.

Issues:

    In section 6.4, step 5, we might want to point out that the offerer cannot simply look at the list of payload types, since the answerer may be using payload type asymmetry. The offerer will need to map each payload type to a codec description on both sides, and then make sure the set of codec descriptions for that rid in the answer is a subset of those in the offer.

Good point. This is pretty easy to understand, but ended up being more difficult to describe than I expected. :)

5. If the "a=rid" line in the answer contains a "pt=" and the
    offer did as well, the offerer verifies that the list of payload types is a
    subset of those sent in the corresponding "a=rid" line in the offer. Note
    that this matching must be performed semantically rather than on literal PT
    values, as the remote end may not be using symmetric PTs. For the purpose
    of this comparison: for each PT listed in the "pt=", the offerer looks up
    the "a=rtpmap" and "a=fmtp" lines in the answer.  It then searches the list
    of "pt=" values indicated in the offer, and attempts to find one with an
    equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If all PTs in
    the answer can be matched, then the "pt=" values pass validation;
    otherwise, it fails.  If this validation fails, the offerer SHALL discard
    the "a=rid" line.


"Expressing all these codecs and resolutions using 32 dynamic PTs (2 audio + 10x3 video) would exhaust the primary dynamic space (96-127). RIDs are used to avoid PT exhaustion and express the resolution constraints."

    This is not adding up for me, because there is no requirement that PTs be unique across m-sections. The sendrecv m-section for video needs 10 PTs, but the other m-sections can overlap that. It might be kinda tricky to come up with a scenario that exceeds 32 without simulcast, but I don't really see why we need to talk about PT exhaustion in the RID spec, since that's more of a simulcast concern.

I think you're right. I'm striking the paragraph.

Nits/editorial:
Fixed. Thanks.

Dropping a -03 soon.

/a

--------------010209040102090008010203-- From nobody Fri Feb 5 15:17:19 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 49CCB1B2EDD; Fri, 5 Feb 2016 15:17:17 -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: <20160205231717.22903.28510.idtracker@ietfa.amsl.com> Date: Fri, 05 Feb 2016 15:17:17 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-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: Fri, 05 Feb 2016 23:17:17 -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 : RTP Payload Format Constraints Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-03.txt Pages : 22 Date : 2016-02-05 Abstract: In this specification, we define a framework for identifying RTP Streams with the constraints on its payload format in the Session Description Protocol. This framework defines a new "rid" SDP attribute to: a) effectively identify the RID RTP Streams within a RTP Session, b) constrain their payload format parameters in a codec- agnostic way beyond what is provided with the regular Payload Types and c) enable unambiguous mapping between the RID RTP Streams to their media format specification in the SDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-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 Sat Feb 6 02:59: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 A815B1B2B61; Sat, 6 Feb 2016 02:59:00 -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: <20160206105900.13938.56211.idtracker@ietfa.amsl.com> Date: Sat, 06 Feb 2016 02:59:00 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 10:59:00 -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-01.txt Pages : 8 Date : 2016-02-06 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- exclusive', that can be used by an endpoint 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 6 03:02: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 C21EC1ACD65 for ; Sat, 6 Feb 2016 03:02:39 -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 2gXeF3aLHWZo for ; Sat, 6 Feb 2016 03:02:38 -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 A16301B2B82 for ; Sat, 6 Feb 2016 03:02:37 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-c5-56b5d2ca8576 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.A7.05690.AC2D5B65; Sat, 6 Feb 2016 12:02:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Sat, 6 Feb 2016 12:02:34 +0100 From: Christer Holmberg To: mmusic Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-01 Thread-Index: AdFgzX/VWHNvZFvMR025jRlG2u/S1g== Date: Sat, 6 Feb 2016 11:02:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@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_7594FB04B1934943A5C02806D1A2204B37D8F2E5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7n+7pS1vDDI5N5LGYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mo60f2YvmCJd8brtFWsD4zvxLkZODgkBE4lJ+9axQ9hiEhfu rWfrYuTiEBI4zCjR9Go7M4SzmFGio/MZSxcjBwebgIVE9z9tkAYRARmJvZs2M4PYwgJ2Ep3n 3zJBxJ0ltt+cC2XrScw+NQGshkVAReLwm2dgy3gFfCVWHl4EZjMCLf5+ag1YPbOAuMStJ/OZ IA4SkFiy5zwzhC0q8fLxP1YIW0lixfZLjBD1+RId72+zQswUlDg58wnLBEahWUhGzUJSNgtJ GURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJ ERgTB7f81t3BuPq14yFGAQ5GJR5eg49bwoRYE8uKK3MPMUpwMCuJ8M5csTVMiDclsbIqtSg/ vqg0J7X4EKM0B4uSOO8a5/VhQgLpiSWp2ampBalFMFkmDk6pBsZFHH5T2s9sdeVfbznDQ3dF BXfdpWfKx83jur9v3C/y9ZBPutrX4/NWi9dpm0mdWF7dvM24V7e6UejiilcaE6onCSu8+G22 eWu6nq9jd/7khrXmXbKnTNhmLJ+wYeONkGatbWLLrx+znttudYqfZ8ItjbeJz14/9bwe79E4 L/lmVmeRdfSRsGolluKMREMt5qLiRADJKI2EhQIAAA== Archived-At: Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-01 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, 06 Feb 2016 11:02:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D8F2E5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-01) of draft-mux-exclusive. The main difference compared to the previous version is that the draft now = defines a new SDP attribute, 'rtcp-mux-exclusive', to indicate exclusive su= pport of, and negotiate usage of, RTP/RTCP multiplexing. There are currently no open issues in the draft, so I encourage people to t= ake a look, so that we can start moving towards WGLC. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D8F2E5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

 

The main difference compared to the previous version= is that the draft now defines a new SDP attribute, ‘rtcp-mux-exclusi= ve’, to indicate exclusive support of, and negotiate usage of, RTP/RT= CP multiplexing.

 

There are currently no open issues in the draft, so = I encourage people to take a look, so that we can start moving towards WGLC= .

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D8F2E5ESESSMB209erics_-- From nobody Sat Feb 6 10:44: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 9DA6E1A90A8 for ; Sat, 6 Feb 2016 10:44:11 -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 2lmMyt222Phv for ; Sat, 6 Feb 2016 10:44:10 -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 47A231A90A5 for ; Sat, 6 Feb 2016 10:44:10 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-12v.sys.comcast.net with comcast id F6k21s002516pyw016k9X4; Sat, 06 Feb 2016 18:44:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-08v.sys.comcast.net with comcast id F6k81s00S3KdFy1016k9i9; Sat, 06 Feb 2016 18:44:09 +0000 To: 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> From: Paul Kyzivat Message-ID: <56B63EF8.8080100@alum.mit.edu> Date: Sat, 6 Feb 2016 13:44:08 -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: <56B41A47.10901@nteczone.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=1454784249; bh=gCMufk+jAc1lLd3H8NBnLVWNskJpcN8lPLpqypVJd5I=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AC0itBWrdfbV7J0ieUncJQ7AxrhPqCzKRAxd+R1szWj7G+Vz0rS8IIuD9HUBXBOyo kE9HtY5ql8XAeQB22VaDRIrDWutQl3gkiZTW1lD/RdhgA4ODvG7THQG20c72vVFFBx kSBFnbwZuJX/CmU8FxivY32VrTkow1FxpyxM5Go/yWmWK3yWacJMMWPKXByS+xw/1f AHGOnz5NXaqWm5nzawM7AFzPiOFDhMJOdZnHWUUz02THZInSGfaVuv4EvTsbGNEBlL H7PEFe6eKDhwkt9wUn7NYpoO9mA39alcihSbyhXSBl0/TnvLyESlo1Kwmpxc1xEBdw GI5mEQJTVxL3Q== 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: Sat, 06 Feb 2016 18:44:11 -0000 On 2/4/16 10:43 PM, Christian Groves wrote: > Isn't this the approach we're taking today? > draft-ietf-mmusic-data-channel-sdpneg has general text and specific > drafts are used to describe protocols that use the mechanism (i.e. > draft-ietf-mmusic-msrp-usage-data-channel & draft-ietf-clue-datachannel). It remains to be seen if that will be enough. E.g., there currently aren't any iana considerations in draft-ietf-mmusic-msrp-usage-data-channel. Suppose I encounter some sdp that uses msrp over a data channel, but that usage is unknown to me. How do I find the spec (the reference to draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? I would like to think that the iana registries will allow me to trace back to the relevant specs. Thanks, Paul > Regards, Christian > > On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >> >>> I'm not concerned about the IANA part. I agree that *if* we need to >>> expliclty specify attribute interactions for "dcsa", then it should be >>> part of the IANA registry. What I am not agreeing with at this point is >>> that there is indeed a need to explicitly speficy these interactions as >>> opposed to relying on a more general algorithmic approach (plus the >>> offerer being responsible for generating a valid offer if he wants to >>> establish a data channel). >> >> Well, an obvious one is that the protocol(s) the attribute pertains to >> need to be defined to work over data channels. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 Sun Feb 7 15:13: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 97C2D1A876C for ; Sun, 7 Feb 2016 15:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_15=0.6, 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 UVvp7uAhrohq for ; Sun, 7 Feb 2016 15:13:35 -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 B9DCC1A876E for ; Sun, 7 Feb 2016 15:13:34 -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=rjcRUfaFzWLPDOWxwEItg5+xrQFxh6TjmxLl3Yr1Yo0=; b=SKE067zpUf40HPQ2FrPbb4ILKZ fEPdtoxnoKVAO3GQOaKm/7nP7q3YgchG5+1irQ8VNtSZki8QLbb8kSWx36V04GYio/9CjV819KZ9T WK/8LzAb0Py0XNaNmZVJKmwswSsD47IKHrDe6zM7Yucvyhb1mZOO4B/xleNJh6Vpsw80w+4m2C6uz 6LSyGzdMCjVuDlEQPIhKCGQUkzfKYoU7z4LLUMPVmLkqwfaAlo96b5Vq/1ss0D4iIhtSVYrYH6exr JQfh5xZPQP8LUUjbzkQC8X9wtsWESrz+3XZ/Ad1n4epSfY2LKrgjfZt9dAHk5/2KmKAVUDYyJd2ap m+J0cpfw==; Received: from ppp118-209-127-77.lns20.mel4.internode.on.net ([118.209.127.77]:50081 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aSYWI-004JzQ-VM for mmusic@ietf.org; Mon, 08 Feb 2016 10:13:31 +1100 To: 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> From: Christian Groves Message-ID: <56B7CF99.2020306@nteczone.com> Date: Mon, 8 Feb 2016 10:13:29 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B63EF8.8080100@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Sun, 07 Feb 2016 23:13:36 -0000 Hello Paul, On 7/02/2016 5:44 AM, Paul Kyzivat wrote: > On 2/4/16 10:43 PM, Christian Groves wrote: >> Isn't this the approach we're taking today? >> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >> drafts are used to describe protocols that use the mechanism (i.e. >> draft-ietf-mmusic-msrp-usage-data-channel & >> draft-ietf-clue-datachannel). > > It remains to be seen if that will be enough. E.g., there currently > aren't any iana considerations in > draft-ietf-mmusic-msrp-usage-data-channel. > > Suppose I encounter some sdp that uses msrp over a data channel, but > that usage is unknown to me. How do I find the spec (the reference to > draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? [CNG] If you're using data channel then you'd register a websocket subprotocol ID (e.g. as we do for CLUE). This should then point to the specification that defines the use of the sub-protocol within the datachannel. The dcsa parameters can't live without the a=dcmap line with the subprotocol. I agree we need to document something in the IANA considerations section. Regards, Christian From nobody Mon Feb 8 06:34: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 728D81B2C1E for ; Mon, 8 Feb 2016 06:34:06 -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 PrTNLoImDY78 for ; Mon, 8 Feb 2016 06:34:04 -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 6AA1F1B2BFA for ; Mon, 8 Feb 2016 06:34:04 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-ce-56b8a7591755 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.C5.05041.957A8B65; Mon, 8 Feb 2016 15:34:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Mon, 8 Feb 2016 15:33:16 +0100 From: Christer Holmberg To: mmusic Thread-Topic: DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrg== Date: Mon, 8 Feb 2016 14:33:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@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_7594FB04B1934943A5C02806D1A2204B37DBF1ADESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7sW7k8h1hBv8aTS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI2L37AXzJaq6G55wNjAeEi8i5GDQ0LARGLKBfsuRk4gU0zi wr31bF2MXBxCAocZJeb3nmAGSQgJLGaUuPApHqSeTcBCovufNkhYREBGYu+mzWAlwgIKEo+e PGGDiKtKbO99xgxh60mcXPGaHcRmEVCR2LniDiOIzSvgK/HwaSNYDSPQ3u+n1jCB2MwC4hK3 nsxngrhHQGLJnvPMELaoxMvH/1ghbEWJq9OXQ9XnS3QvvsQCMVNQ4uTMJywTGIVmIRk1C0nZ LCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5q ySZGYDwc3PLbagfjweeOhxgFOBiVeHgNpmwPE2JNLCuuzD3EKMHBrCTCu6N3R5gQb0piZVVq UX58UWlOavEhRmkOFiVx3jXO68OEBNITS1KzU1MLUotgskwcnFINjBlR96Qms36b6Jq7uO3B q8cvP7usvSmptSVMO29G1cl8iSX9Jndu7w1vXZunP7fQr4w1w0qdg+vGs8YWp17Vi48yw+z2 mja6/o+YatBUkNIn8TuP653ox+SiudGeG15sue71SmjFh3rlB7tXr54a2lCf3fHs/j+lxytK Xux5xuzVW3nv9eZrjUosxRmJhlrMRcWJAKqt1M+DAgAA Archived-At: Subject: [MMUSIC] DTLS-over-SCTP, anyone? 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, 08 Feb 2016 14:34:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DBF1ADESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A procedures for SCT= P, SCTP-over-DTLS, and DTLS-over-SCTP. As we know, SCTP-over-DTLS is used for the WebRTC data channel. My question is: does anyone intend to use DTLS-over-SCTP? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37DBF1ADESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

draft-ietf-mmusic-sctp-sdp curr= ently defines the SDP O/A procedures for SCTP, SCTP-over-DTLS, and DTLS-ove= r-SCTP.

 

As we know, SCTP-over-DTLS is u= sed for the WebRTC data channel.

 

My question is: does anyone int= end to use DTLS-over-SCTP?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37DBF1ADESESSMB209erics_-- From nobody Mon Feb 8 07:12: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 A12E81B2CF9 for ; Mon, 8 Feb 2016 07:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 SZWsnVPGzlLf for ; Mon, 8 Feb 2016 07:12:45 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 552631B2CED for ; Mon, 8 Feb 2016 07:12:45 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id A2B33D1040C6; Mon, 8 Feb 2016 15:12:40 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u18FCfq6001607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Feb 2016 15:12:42 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u18FCekf015661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Feb 2016 16:12:41 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.125]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 8 Feb 2016 16:12:41 +0100 From: "Schwarz, Albrecht (Nokia - DE)" To: EXT Christer Holmberg , mmusic Thread-Topic: DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dA Date: Mon, 8 Feb 2016 15:12:40 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1ACE19A359CFR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 08 Feb 2016 15:12:49 -0000 --_000_786615F3A85DF44AA2A76164A71FE1ACE19A359CFR711WXCHMBA03z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Christer, the titel of the (future) RFC will not exclude any SCTP transport modes. And a comprehensive and future safe protocol specification should cover all= existing ones, which is "DTLS/SCTP/IP" as well as "SCTP/UDP/IP" (RFC 6951)= . These two SCTP transport modes should be indicated as well, independent of = potential intentions to be used soon. Codepoint space could be reserved, placeholder sections tagged as "not yet = supported" of "for further studies", etc, but the worst case would be any k= ind of interaction issues in future. My view, Albrecht From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christer Hol= mberg Sent: Montag, 8. Februar 2016 15:33 To: mmusic Subject: [MMUSIC] DTLS-over-SCTP, anyone? Hi, draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A procedures for SCT= P, SCTP-over-DTLS, and DTLS-over-SCTP. As we know, SCTP-over-DTLS is used for the WebRTC data channel. My question is: does anyone intend to use DTLS-over-SCTP? Regards, Christer --_000_786615F3A85DF44AA2A76164A71FE1ACE19A359CFR711WXCHMBA03z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

H= ello Christer,

<= o:p> 

t= he titel of the (future) RFC will not exclude any SCTP transport modes.

A= nd a comprehensive and future safe protocol specification should cover all = existing ones, which is “DTLS/SCTP/IP” as well as “SCTP/U= DP/IP” (RFC 6951).

T= hese two SCTP transport modes should be indicated as well, independent of p= otential intentions to be used soon.

C= odepoint space could be reserved, placeholder sections tagged as “not= yet supported” of “for further studies”, etc, but the wo= rst case would be any kind of interaction issues in future.

<= o:p> 

M= y view,

A= lbrecht

<= o:p> 

 

From: mmusic [mailto:mmusic-bounces@ietf.org]= On Behalf Of EXT Christer Holmberg
Sent: Montag, 8. Februar 2016 15:33
To: mmusic <mmusic@ietf.org>
Subject: [MMUSIC] DTLS-over-SCTP, anyone?

 

Hi,

 

draft-ietf-mmusic-sctp-sdp currently defines the SDP= O/A procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.

 

As we know, SCTP-over-DTLS is used for the WebRTC da= ta channel.

 

My question is: does anyone intend to use DTLS-over-= SCTP?

 

Regards,

 

Christer

--_000_786615F3A85DF44AA2A76164A71FE1ACE19A359CFR711WXCHMBA03z_-- From nobody Mon Feb 8 08:09:18 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 5EA8A1B2E4F; Mon, 8 Feb 2016 08:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 bPTl2_hJAd8n; Mon, 8 Feb 2016 08:09:16 -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 43A771B2DFD; Mon, 8 Feb 2016 08:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3007; q=dns/txt; s=iport; t=1454947755; x=1456157355; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xK8gBMulWRmcCTZ5uaPF1gHf4ypnrIewyA57aM3noOk=; b=nFnQMl5fJzOZcs/+dN9pwgV2C2qWCwzovuflUeSe4/5YZCWCMkUyjPBs 3bGfEUKOYD3rt74Dt/fJ71pNRiIK2RrDm7wognkRR8xgIjyT9LG0bMuda 8hLBxnKTnt8ZZ/6Nhj1EM0ipAt5LzPBHwunTxTOT3pRragXotMCI7otni M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQBpvLhW/5xdJa1eDoMsUm2IW7ELA?= =?us-ascii?q?Q2BZhcKhSJKAoEuOBQBAQEBAQEBgQqEQQEBAQMBAQEBNTYKAQULCw4KCRYPCQM?= =?us-ascii?q?CAQIBFTAGAQwGAgEBiA8IDrx0AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ3i?= =?us-ascii?q?GwBBI4biFqNUIFbh0aFUopsg1IeAQFCgylZHi6IUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208";a="234363866" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 16:09:14 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u18G99nE007374; Mon, 8 Feb 2016 16:09:11 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> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> From: Flemming Andreasen Message-ID: <56B8BDA4.7060305@cisco.com> Date: Mon, 8 Feb 2016 11:09:08 -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: <56B63EF8.8080100@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org 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: Mon, 08 Feb 2016 16:09:17 -0000 On 2/6/16 1:44 PM, Paul Kyzivat wrote: > On 2/4/16 10:43 PM, Christian Groves wrote: >> Isn't this the approach we're taking today? >> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >> drafts are used to describe protocols that use the mechanism (i.e. >> draft-ietf-mmusic-msrp-usage-data-channel & >> draft-ietf-clue-datachannel). > > It remains to be seen if that will be enough. E.g., there currently > aren't any iana considerations in > draft-ietf-mmusic-msrp-usage-data-channel. > > Suppose I encounter some sdp that uses msrp over a data channel, but > that usage is unknown to me. How do I find the spec (the reference to > draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? > > I would like to think that the iana registries will allow me to trace > back to the relevant specs. > No disagreement on that part, however having taken another look at both sdpneg and the msrp-usage documents, I still don't agree with your original request for all (existing and new) attributes to specify how they may or may not be used with the dcsa attribute defined by sdpneg. As Christian noted, the sub-protocol specifics are defined in individual documents (like msrp-usage), which calls your the parameters that are at least needed to be supported for that usage. Taking MSRP as an example, why isn't that enough, and how do you see the resulting set of attributes that may or may not be used with MSRP differ between use in a data-channel (and hence encapsulated in dcsa) or as a regular media stream ? Also, it would be good to hear from more people on this, including the document authors. Thanks -- Flemming > Thanks, > Paul > >> Regards, Christian >> >> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>> >>>> I'm not concerned about the IANA part. I agree that *if* we need to >>>> expliclty specify attribute interactions for "dcsa", then it should be >>>> part of the IANA registry. What I am not agreeing with at this >>>> point is >>>> that there is indeed a need to explicitly speficy these >>>> interactions as >>>> opposed to relying on a more general algorithmic approach (plus the >>>> offerer being responsible for generating a valid offer if he wants to >>>> establish a data channel). >>> >>> Well, an obvious one is that the protocol(s) the attribute pertains to >>> need to be defined to work over data channels. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Mon Feb 8 08:29:48 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 F30231B2EAB for ; Mon, 8 Feb 2016 08:29:46 -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 cqpHSwcp8Dk3 for ; Mon, 8 Feb 2016 08:29:45 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C1D1B2EAF for ; Mon, 8 Feb 2016 08:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4626; q=dns/txt; s=iport; t=1454948985; x=1456158585; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=OEYzNgIN85LMraHCS24X84CkTDw1MFlW5/IP5g2Ti5A=; b=Mn7unZkJUieawIYwwmhAdOROnQmDVywsRIfVvOv03UgHk8naxTdJ7orK Vd9Cn66kEuNvVwfS3vXVzZsfy2IvgqM7Mt843U4lWaznydMgXXYewCt27 cyCtg12Ex8sDFyBIxCmYOhQCxDX6saIc/jzYg58YBEr3pJBr+EQE7M9qU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDPwbhW/5xdJa1egm5MUm2IW7ELA?= =?us-ascii?q?Q2BZhcBCYUiSgKBLzgUAQEBAQEBAYEKhEIBAQQBAQEqQQoRCxgJFg8JAwIBAgE?= =?us-ascii?q?VMAYBDAYCAQGIFw69EwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEN4hsBY4bi?= =?us-ascii?q?FqNUIFbhEODA4VSjj4eAQFChAIeLohTAQEB?= X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208,217";a="236122158" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 16:29:44 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u18GTgYw025426; Mon, 8 Feb 2016 16:29:43 GMT To: Christer Holmberg , mmusic References: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@ESESSMB209.ericsson.se> From: Flemming Andreasen Message-ID: <56B8C271.5000101@cisco.com> Date: Mon, 8 Feb 2016 11:29:37 -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: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------020200000807070409070300" Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-01 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, 08 Feb 2016 16:29:47 -0000 This is a multi-part message in MIME format. --------------020200000807070409070300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Folks, Please take a look at the draft and let us know if you think it is ready (or not) for WGLC at this point. Thanks -- Flemming (MMUSIC co-chair). On 2/6/16 6:02 AM, Christer Holmberg wrote: > > Hi, > > Ive submitted a new version (-01) of draft-mux-exclusive. > > The main difference compared to the previous version is that the draft > now defines a new SDP attribute, rtcp-mux-exclusive, to indicate > exclusive support of, and negotiate usage of, RTP/RTCP multiplexing. > > There are currently no open issues in the draft, so I encourage people > to take a look, so that we can start moving towards WGLC. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------020200000807070409070300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Folks,

Please take a look at the draft and let us know if you think it is ready (or not) for WGLC at this point.

Thanks

-- Flemming (MMUSIC co-chair).

On 2/6/16 6:02 AM, Christer Holmberg wrote:

Hi,

Ive submitted a new version (-01) of draft-mux-exclusive.

The main difference compared to the previous version is that the draft now defines a new SDP attribute, rtcp-mux-exclusive, to indicate exclusive support of, and negotiate usage of, RTP/RTCP multiplexing.

There are currently no open issues in the draft, so I encourage people to take a look, so that we can start moving towards WGLC.

Regards,

Christer



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

--------------020200000807070409070300-- From nobody Mon Feb 8 08:29:57 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 27CC31B2EA5 for ; Mon, 8 Feb 2016 08:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 GUiyd8paw-NR for ; Mon, 8 Feb 2016 08:29:54 -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 37E281B2EB3 for ; Mon, 8 Feb 2016 08:29:54 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id y8so33609259igp.0 for ; Mon, 08 Feb 2016 08:29: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=G7uvyO8i72O/ksPRAyAse/6TbS4zti/ElOO2Rh8b44Q=; b=PMubOCfzt3qZm+1LdoMsG3AeOM56QYqWOCDvXUXtXPwf0XaOxz7cBhwUwL6BolDzrH /6vYO9ZZotQGFBU1olpLfbf8X2H+uHo4AaL4ZGDvY5HrC27dXzWdI0XqxQaEUS0LsvG8 KkEUw97NmE6pEDGPTjz/UN/NswVhEjwdaMs7sp6N3wPXNSfGL/YnzxoJvvRLw68x2gi9 HahaepH1YBr9iEXFh+gAX3fxvklaKc8ywbzGuS5+Nv6CdM2AjwPPtnfPdYv4EKS6hz09 lBhMR8pDu4o3xBQNE68OYdmTNC/fz+Puxj4Ye63EY2pXXpXcBiIYTNcMuc/yYjSPW6dJ Vyaw== 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=G7uvyO8i72O/ksPRAyAse/6TbS4zti/ElOO2Rh8b44Q=; b=dIuY9q5SLIuph2anhG2gl5SgCEBpHyYZoXTFUs4TJ+Oa2AzONSl+loEmFZXb4OvVMk xriMC4+74KsjrZOSsm58Vnrot8YiocFGo+pB+u5ZXWLzc8dD1c52u4LrqEI2f1BzIV/d 5mg6H7fNLFdcCVBxeH9/esp86Nl5lnoeMV2RHR/HW6x/kCsSN+7Smbt1qE4Xt3aBq2OU VNETyx8Of1u7GE1kYUfqxwkVVhRkUKpcI6JfIF0NV0V2mwgZ3r36o9BS9/dbDjZuo1e1 4D0zL2C8SQYcK6+j6SWvaogMhz4jecgEAkXUomzytAvVZV1pc7EMRN9jv2anwwaSgUg2 0cUA== X-Gm-Message-State: AG10YOQUyUDhW9f44IFME0AHy0RxmQoKDhL9lh0AmNrYQh63cYNWbw3Sk+xxWoRXFbzs2w== X-Received: by 10.50.142.73 with SMTP id ru9mr25101856igb.92.1454948993622; Mon, 08 Feb 2016 08:29:53 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id vf11sm5405155igb.20.2016.02.08.08.29.52 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 08:29:52 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id xg9so58852130igb.1 for ; Mon, 08 Feb 2016 08:29:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr24109922igb.24.1454948991688; Mon, 08 Feb 2016 08:29:51 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 8 Feb 2016 08:29:51 -0800 (PST) In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Mon, 8 Feb 2016 11:29:51 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Schwarz, Albrecht (Nokia - DE)" Content-Type: multipart/alternative; boundary=089e01184168d0ed2e052b44b5ce Archived-At: Cc: mmusic , EXT Christer Holmberg Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 08 Feb 2016 16:29:56 -0000 --089e01184168d0ed2e052b44b5ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Albrecht, The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully compatible with draft-ietf-mmusic-dtls-sdp. In particular, RFC 6083 does not allow DTLS association span across multiple SCTP associations, but draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association through a transport change. The most likely solution to this is updating RFC 6083, but, if no one is using DTLS-over-SCTP, it would be easier just to say that DTLS-over-SCTP is not supported. Regards, _____________ Roman Shpount On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) < albrecht.schwarz@nokia.com> wrote: > Hello Christer, > > > > the titel of the (future) RFC will not exclude any SCTP transport modes. > > And a comprehensive and future safe protocol specification should cover > all existing ones, which is =E2=80=9CDTLS/SCTP/IP=E2=80=9D as well as =E2= =80=9CSCTP/UDP/IP=E2=80=9D (RFC > 6951). > > These two SCTP transport modes should be indicated as well, independent o= f > potential intentions to be used soon. > > Codepoint space could be reserved, placeholder sections tagged as =E2=80= =9Cnot yet > supported=E2=80=9D of =E2=80=9Cfor further studies=E2=80=9D, etc, but the= worst case would be any > kind of interaction issues in future. > > > > My view, > > Albrecht > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *EXT > Christer Holmberg > *Sent:* Montag, 8. Februar 2016 15:33 > *To:* mmusic > *Subject:* [MMUSIC] DTLS-over-SCTP, anyone? > > > > Hi, > > > > draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A procedures for > SCTP, SCTP-over-DTLS, and DTLS-over-SCTP. > > > > As we know, SCTP-over-DTLS is used for the WebRTC data channel. > > > > My question is: does anyone intend to use DTLS-over-SCTP? > > > > Regards, > > > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e01184168d0ed2e052b44b5ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Albrecht,

The problem with DTLS-over-SCTP (R= FC 6083) is that it is not fully compatible with draft-ietf-mmusic-dtls-sdp= . In particular, RFC 6083 does not allow DTLS association span across multi= ple SCTP associations, but=C2=A0draft-ietf-mmusic-dtls-sdp allows to preser= ve DTLS association through a transport change. The most likely solution to= this is updating RFC 6083, but, if no one is using DTLS-over-SCTP, it woul= d be easier just to say that=C2=A0DTLS-over-SCTP is not supported.

=
Regards,

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Al= brecht (Nokia - DE) <albrecht.schwarz@nokia.com> wr= ote:

H= ello Christer,

<= u>=C2=A0

t= he titel of the (future) RFC will not exclude any SCTP transport modes.<= /u>

A= nd a comprehensive and future safe protocol specification should cover all = existing ones, which is =E2=80=9CDTLS/SCTP/IP=E2=80=9D as well as =E2=80=9C= SCTP/UDP/IP=E2=80=9D (RFC 6951).

T= hese two SCTP transport modes should be indicated as well, independent of p= otential intentions to be used soon.

C= odepoint space could be reserved, placeholder sections tagged as =E2=80=9Cn= ot yet supported=E2=80=9D of =E2=80=9Cfor further studies=E2=80=9D, etc, bu= t the worst case would be any kind of interaction issues in future.<= u>

<= u>=C2=A0

M= y view,

A= lbrecht

<= u>=C2=A0

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Beh= alf Of EXT Christer Holmberg
Sent: Montag, 8. Februar 2016 15:33
To: mmusic <= mmusic@ietf.org>
Subject: [MMUSIC] DTLS-over-SCTP, anyone?

=C2=A0

Hi,

=C2=A0

draft-ietf-mmusic-sctp-sdp currently defines the SDP= O/A procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.=

=C2=A0

As we know, SCTP-over-DTLS is used for the WebRTC da= ta channel.

=C2=A0

My question is: does anyone intend to use DTLS-over-= SCTP?

=C2=A0

Regards,

=C2=A0

Christer


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


--089e01184168d0ed2e052b44b5ce-- From nobody Mon Feb 8 08:30: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 67BAC1B2EAF for ; Mon, 8 Feb 2016 08:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 vM-DWL2DVO3L for ; Mon, 8 Feb 2016 08:30:30 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 339FE1B2EA5 for ; Mon, 8 Feb 2016 08:30:30 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id ik10so88943973igb.1 for ; Mon, 08 Feb 2016 08:30:30 -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=P6hCOrEDJhqpCBWWDPTRZKGXp4qjnPskJH//+q0+szg=; b=MoovZugDkrA1tO0HN/Uhm9xblPCrqyFsr+6Dk4mHGHtP2evdTou8+Hts8aNBkPuyBk FMg50XC/sejTr/Rn4Ngm12Gc9HgSy9LoAFHWQ35r/R+iI0r90yc24RRt/OnGrkf5Lfp7 4I3fk/6Rypo7anjs/IbnMPbeLUMLYrw6vhDVMw9k2xst38OIfrt1MGuJeHAm1n+5pAGG /zj2Nlgq2SVQx4Lbo+BcOqqj173kDf4WC4rwAKS8+RDOSZ4lS3fRmzeOB8VsBZUgiKqK vgcOlUT9/7SKYgzoiYCCbiRX3zBjov5NeBHqs+a+vk2PdNrCqBswFKez4T30/7d8liT3 KK2Q== 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=P6hCOrEDJhqpCBWWDPTRZKGXp4qjnPskJH//+q0+szg=; b=i8bt/Es8kaLxsBIcZX+L9Yy5sY9FZB5nn4OPjawZIPLttdHX8rkIhGPEBaMVPO54bT 5e1jjHibhFaA+fCQIe93f9H/6gjDuT8bUJZBtCk6yWSkcjNG5MAOB7jsm3gbranZ0VND h8nkjycFmp2LEr7Y19Qgt/6lnhj9dx19qNsRbTgZtZKrmaq5ZlzKMIpjsuygOq1NSWVH CzMCtW2CF1NdGnVkCss+qOFzbw0fSKUwGBjo71bn2+wMb0fp7lR58aMo8q+lwdFSj/xW cpKZ3IvgIYFMGs1t+hqBkMyh3q0kIFXRMYPmSriq/768U/KkaQ3fif41Zv6TN+b2vR/T BAyw== X-Gm-Message-State: AG10YOQMOO9Vq8GvBWS4pGyvV+VpfnvV9RLy3v5nkSdkPK2Lzu9Ks8hAXbUhSsCJ5mbbOw== X-Received: by 10.50.33.51 with SMTP id o19mr24666687igi.2.1454949029520; Mon, 08 Feb 2016 08:30:29 -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 n75sm12767699ioe.28.2016.02.08.08.30.28 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 08:30:28 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id 9so200819976iom.1 for ; Mon, 08 Feb 2016 08:30:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.12.226 with SMTP id 95mr6214791iom.70.1454949028023; Mon, 08 Feb 2016 08:30:28 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 8 Feb 2016 08:30:27 -0800 (PST) In-Reply-To: <56B8C271.5000101@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@ESESSMB209.ericsson.se> <56B8C271.5000101@cisco.com> Date: Mon, 8 Feb 2016 11:30:27 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Flemming Andreasen Content-Type: multipart/alternative; boundary=001a113f8f8efb5b9e052b44b70d Archived-At: Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-01 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, 08 Feb 2016 16:30:31 -0000 --001a113f8f8efb5b9e052b44b70d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it is ready for WGLC _____________ Roman Shpount On Mon, Feb 8, 2016 at 11:29 AM, Flemming Andreasen wrote: > Folks, > > Please take a look at the draft and let us know if you think it is ready > (or not) for WGLC at this point. > > Thanks > > -- Flemming (MMUSIC co-chair). > > On 2/6/16 6:02 AM, Christer Holmberg wrote: > > Hi, > > > > I=E2=80=99ve submitted a new version (-01) of draft-mux-exclusive. > > > > The main difference compared to the previous version is that the draft no= w > defines a new SDP attribute, =E2=80=98rtcp-mux-exclusive=E2=80=99, to ind= icate exclusive > support of, and negotiate usage of, RTP/RTCP multiplexing. > > > > There are currently no open issues in the draft, so I encourage people to > take a look, so that we can start moving towards WGLC. > > > > Regards, > > > > Christer > > > _______________________________________________ > mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/m= music > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a113f8f8efb5b9e052b44b70d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it is ready for WGLC

_____________
R= oman Shpount

On Mon, Feb 8, 2016 at 11:29 AM, Flemming An= dreasen <fandreas@cisco.com> wrote:
=20 =20 =20
Folks,

Please take a look at the draft and let us know if you think it is ready (or not) for WGLC at this point.

Thanks

-- Flemming (MMUSIC co-chair).

On 2/6/16 6:02 AM, Christer Holmberg wrote:
=20 =20 =20

Hi,

=C2=A0

I=E2=80=99ve submitted a new version (-01) o= f draft-mux-exclusive.

=C2=A0

The main difference compared to the previous version is that the draft now defines a new SDP attribute, =E2=80=98rtcp-mux-exclusive=E2=80=99, to indicate excl= usive support of, and negotiate usage of, RTP/RTCP multiplexing.<= /p>

=C2=A0

There are currently no open issues in the draft, so I encourage people to take a look, so that we can start moving towards WGLC.

=C2=A0

Regards,

=C2=A0

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


--001a113f8f8efb5b9e052b44b70d-- From nobody Mon Feb 8 09:09: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 3C44B1B2F4F for ; Mon, 8 Feb 2016 09:09:13 -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 bCUAF4-9pejV for ; Mon, 8 Feb 2016 09:09:11 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9881B2C97 for ; Mon, 8 Feb 2016 09:09:11 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-09v.sys.comcast.net with comcast id Ft8v1s006516pyw01t9BAd; Mon, 08 Feb 2016 17:09:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-08v.sys.comcast.net with comcast id Ft9A1s0093KdFy101t9A90; Mon, 08 Feb 2016 17:09:11 +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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> From: Paul Kyzivat Message-ID: <56B8CBB5.7070507@alum.mit.edu> Date: Mon, 8 Feb 2016 12:09:09 -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: <56B8BDA4.7060305@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=1454951351; bh=mmcEZe/0p1zm9db8Yy/xyRpvwYozAbSttgKd1hFik/o=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gPrUSBaiPCTlyxuP59lGoqvyt6vgA+pFkIDeJjk+LYHfC3QmnSQmGxYsijk2kksHJ 2rUO9dUq3GoTRj4YKoajHV8N4Cm8w/0RUbW26/27tmop6t7qy1uIeMZuDMXGJ4Y3Mv kie73HDPaD9ADkKDQMczuIw6PWaqQZJtjUPmjwHv1nlfhejTI0x78L+/HvLXX8ZS7P IeQ0JKk1tT37aqEaSSy9Hx1cnMf1jPcsq/kvNDd4baB/UrKZb+/9R79GlP/s2VCfBR BO2j3hhcQB2VeRPZReA4y9GUYwHY3UVRu+uF78eppcVHVxx3PVnOT0iXF9NFNGnG2a GQJfMLrcb0pAQ== Archived-At: Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org 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: Mon, 08 Feb 2016 17:09:13 -0000 On 2/8/16 11:09 AM, Flemming Andreasen wrote: > > > On 2/6/16 1:44 PM, Paul Kyzivat wrote: >> On 2/4/16 10:43 PM, Christian Groves wrote: >>> Isn't this the approach we're taking today? >>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>> drafts are used to describe protocols that use the mechanism (i.e. >>> draft-ietf-mmusic-msrp-usage-data-channel & >>> draft-ietf-clue-datachannel). >> >> It remains to be seen if that will be enough. E.g., there currently >> aren't any iana considerations in >> draft-ietf-mmusic-msrp-usage-data-channel. >> >> Suppose I encounter some sdp that uses msrp over a data channel, but >> that usage is unknown to me. How do I find the spec (the reference to >> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >> >> I would like to think that the iana registries will allow me to trace >> back to the relevant specs. >> > No disagreement on that part, however having taken another look at both > sdpneg and the msrp-usage documents, I still don't agree with your > original request for all (existing and new) attributes to specify how > they may or may not be used with the dcsa attribute defined by sdpneg. > > As Christian noted, the sub-protocol specifics are defined in individual > documents (like msrp-usage), which calls your the parameters that are at > least needed to be supported for that usage. Taking MSRP as an example, > why isn't that enough, and how do you see the resulting set of > attributes that may or may not be used with MSRP differ between use in a > data-channel (and hence encapsulated in dcsa) or as a regular media > stream ? Based on this discussion, I conclude that it should be sufficient for this draft to say that before an attribute can be used with dcsa, such usage must be defined somewhere. This could be either: - as part of the definition of the attribute, OR - as part of the definition of the protocol referenced on the m-line. Thanks, Paul > Also, it would be good to hear from more people on this, including the > document authors. > > Thanks > > -- Flemming > > >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>> >>>>> I'm not concerned about the IANA part. I agree that *if* we need to >>>>> expliclty specify attribute interactions for "dcsa", then it should be >>>>> part of the IANA registry. What I am not agreeing with at this >>>>> point is >>>>> that there is indeed a need to explicitly speficy these >>>>> interactions as >>>>> opposed to relying on a more general algorithmic approach (plus the >>>>> offerer being responsible for generating a valid offer if he wants to >>>>> establish a data channel). >>>> >>>> Well, an obvious one is that the protocol(s) the attribute pertains to >>>> need to be defined to work over data channels. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > From nobody Mon Feb 8 09:17: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 4F2111B2F64 for ; Mon, 8 Feb 2016 09:17: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 Kc7BTbfE6hWA for ; Mon, 8 Feb 2016 09:17:41 -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 D26321AD09B for ; Mon, 8 Feb 2016 09:17:40 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-02v.sys.comcast.net with comcast id FtGu1s00D26dK1R01tHgCy; Mon, 08 Feb 2016 17:17:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id FtHf1s00N3KdFy101tHfa1; Mon, 08 Feb 2016 17:17:39 +0000 To: 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> From: Paul Kyzivat Message-ID: <56B8CDB2.9080505@alum.mit.edu> Date: Mon, 8 Feb 2016 12:17:38 -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: <56B8CBB5.7070507@alum.mit.edu> 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=1454951860; bh=WXIkevpoxNWDD5rVVUdy/hPvN87GP3X18frXEg16574=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=cAspGHpppnYoD2CiMlvhTey4gi5BZ+LV9hunZcnihm0Th/ehvf+hNYrKT5SmC/iCO +oGLi/RKpRb+mBo9ub9Pm/1IVGYDQGUEKXXra8+oPVPfs8nbII/uYJqdpF+qi3IaXZ +LSYNLoalMihct8IiX1+sjsZ2cB+TdLPzDGhyGZTEaLJoUhp7n+tELpzRdPFeE0Sts jk7P5YvX8ekz3prZYtCJvFTOcAEOxLNt0ha2b+xgY2Yxgl8uhF+hGdykADLGAswv3V s6d48MOEf4f48INqokfoBQyJYOBWXAQOySCusyT4n5Jk0uLTTMnu3ZvSrZ9SDDHZO1 iePH1wyPUpMgg== 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: Mon, 08 Feb 2016 17:17:42 -0000 BTW, ISTM that whatever is decided here will apply equally to attributes used with a=ssrc. Thanks, Paul On 2/8/16 12:09 PM, Paul Kyzivat wrote: > On 2/8/16 11:09 AM, Flemming Andreasen wrote: >> >> >> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>> Isn't this the approach we're taking today? >>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>>> drafts are used to describe protocols that use the mechanism (i.e. >>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>> draft-ietf-clue-datachannel). >>> >>> It remains to be seen if that will be enough. E.g., there currently >>> aren't any iana considerations in >>> draft-ietf-mmusic-msrp-usage-data-channel. >>> >>> Suppose I encounter some sdp that uses msrp over a data channel, but >>> that usage is unknown to me. How do I find the spec (the reference to >>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>> >>> I would like to think that the iana registries will allow me to trace >>> back to the relevant specs. >>> >> No disagreement on that part, however having taken another look at both >> sdpneg and the msrp-usage documents, I still don't agree with your >> original request for all (existing and new) attributes to specify how >> they may or may not be used with the dcsa attribute defined by sdpneg. >> >> As Christian noted, the sub-protocol specifics are defined in individual >> documents (like msrp-usage), which calls your the parameters that are at >> least needed to be supported for that usage. Taking MSRP as an example, >> why isn't that enough, and how do you see the resulting set of >> attributes that may or may not be used with MSRP differ between use in a >> data-channel (and hence encapsulated in dcsa) or as a regular media >> stream ? > > Based on this discussion, I conclude that it should be sufficient for > this draft to say that before an attribute can be used with dcsa, such > usage must be defined somewhere. This could be either: > - as part of the definition of the attribute, OR > - as part of the definition of the protocol referenced on the m-line. > > Thanks, > Paul > >> Also, it would be good to hear from more people on this, including the >> document authors. >> >> Thanks >> >> -- Flemming >> >> >>> Thanks, >>> Paul >>> >>>> Regards, Christian >>>> >>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>> >>>>>> I'm not concerned about the IANA part. I agree that *if* we need to >>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>> should be >>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>> point is >>>>>> that there is indeed a need to explicitly speficy these >>>>>> interactions as >>>>>> opposed to relying on a more general algorithmic approach (plus the >>>>>> offerer being responsible for generating a valid offer if he wants to >>>>>> establish a data channel). >>>>> >>>>> Well, an obvious one is that the protocol(s) the attribute pertains to >>>>> need to be defined to work over data channels. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> 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 Mon Feb 8 12:36: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 9E5721B32E0 for ; Mon, 8 Feb 2016 12:36: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 PqDN7kFw3DAA for ; Mon, 8 Feb 2016 12:36: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 E7FEB1B32DF for ; Mon, 8 Feb 2016 12:36:03 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-9e-56b8fc31611a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 71.58.30208.13CF8B65; Mon, 8 Feb 2016 21:36:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Mon, 8 Feb 2016 21:36:01 +0100 From: Christer Holmberg To: "Schwarz, Albrecht (Nokia - DE)" , mmusic Thread-Topic: DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAAuIpOA= Date: Mon, 8 Feb 2016 20:36:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DC3984@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.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_7594FB04B1934943A5C02806D1A2204B37DC3984ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7tK7Rnx1hBls3clh8PN/DbDF1+WMW ByaPJUt+MnncvXWJKYApissmJTUnsyy1SN8ugStj/dUdLAXfnSq+rpvB0sB4y7qLkYNDQsBE Yv9Uky5GTiBTTOLCvfVsXYxcHEIChxklli2cxAjhLGaUmLt6ARNIA5uAhUT3P22QBhGBWIlJ n56zgoSFBVQkNp3SggirSmzvfcYMYVtJ3F7+iwXEZgEqObDrDJjNK+Ar8WrRZHaI8QsYJRb9 +AfWwAk089qng2BFjEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0k0LnnC ClGfL9E68ykjxDJBiZMzn7BMYBSZhWTULCRls5CUQcR1JBbs/sQGYWsDg+I1M4x95sBjJmTx BYzsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECo+rglt+qOxgvv3E8xCjAwajEw2swZXuY EGtiWXFl7iFGCQ5mJRFem5c7woR4UxIrq1KL8uOLSnNSiw8xSnOwKInzrnFeHyYkkJ5Ykpqd mlqQWgSTZeLglGpg1Mj8Y731UtiM0DcqIkxseTaK+pWlldYGEbsyr2UIN98WsFNxfso/5ZaI kG5PNH9NwPm/77ner3yZvumg17WQpC2N6q+mBS889uqSCtOCqF99cvM3Tuu//OKAuNrZFI5Z V9+WPv/lFXS7e0F8+eWFG2W/5D15w3H3Qp3O2iXXFdyftYVHKFRlKbEUZyQaajEXFScCAGxi QkSmAgAA Archived-At: Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 08 Feb 2016 20:36:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DC3984ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Albrecht, was there an answer to my question in there somewhere? :) Regards, Christer From: Schwarz, Albrecht (Nokia - DE) [mailto:albrecht.schwarz@nokia.com] Sent: 08 February 2016 17:13 To: Christer Holmberg ; mmusic Subject: RE: DTLS-over-SCTP, anyone? Hello Christer, the titel of the (future) RFC will not exclude any SCTP transport modes. And a comprehensive and future safe protocol specification should cover all= existing ones, which is "DTLS/SCTP/IP" as well as "SCTP/UDP/IP" (RFC 6951)= . These two SCTP transport modes should be indicated as well, independent of = potential intentions to be used soon. Codepoint space could be reserved, placeholder sections tagged as "not yet = supported" of "for further studies", etc, but the worst case would be any k= ind of interaction issues in future. My view, Albrecht From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christer Hol= mberg Sent: Montag, 8. Februar 2016 15:33 To: mmusic > Subject: [MMUSIC] DTLS-over-SCTP, anyone? Hi, draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A procedures for SCT= P, SCTP-over-DTLS, and DTLS-over-SCTP. As we know, SCTP-over-DTLS is used for the WebRTC data channel. My question is: does anyone intend to use DTLS-over-SCTP? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37DC3984ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Albrecht, was there an answer to my question in there somewhere? :)

 

Regards,

 

Christer

 

From: Schwarz, Albrecht (Nokia - DE) [mailto:albrecht.schwarz@nokia.c= om]
Sent: 08 February 2016 17:13
To: Christer Holmberg <christer.holmberg@ericsson.com>; mmusic= <mmusic@ietf.org>
Subject: RE: DTLS-over-SCTP, anyone?

 

Hello Christer,

 

the titel of the (future) RFC will not exclude any SCTP trans= port modes.

And a comprehensive and future safe protocol specification sh= ould cover all existing ones, which is “DTLS/SCTP/IP” as well a= s “SCTP/UDP/IP” (RFC 6951).

These two SCTP transport modes should be indicated as well, i= ndependent of potential intentions to be used soon.

Codepoint space could be reserved, placeholder sections tagge= d as “not yet supported” of “for further studies”, = etc, but the worst case would be any kind of interaction issues in future.

 

My view,

Albrecht

 

 

From: mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of EXT Christer Holmberg
Sent: Montag, 8. Februar 2016 15:33
To: mmusic <mmusic@ietf.org>
Subject: [MMUSIC] DTLS-over-SCTP, anyone?

 

Hi,

 

draft-ietf-mmusic-sctp-sdp curr= ently defines the SDP O/A procedures for SCTP, SCTP-over-DTLS, and DTLS-ove= r-SCTP.

 

As we know, SCTP-over-DTLS is u= sed for the WebRTC data channel.

 

My question is: does anyone int= end to use DTLS-over-SCTP?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37DC3984ESESSMB209erics_-- From nobody Mon Feb 8 12:45: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 6B54F1B32F4 for ; Mon, 8 Feb 2016 12:45: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 qBXA-T8U8zlg for ; Mon, 8 Feb 2016 12:45: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 1F89E1B32EB for ; Mon, 8 Feb 2016 12:45:49 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-82-56b8fe7b9f57 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.E1.05041.B7EF8B65; Mon, 8 Feb 2016 21:45:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Mon, 8 Feb 2016 21:45:46 +0100 From: Christer Holmberg To: Roman Shpount , "Schwarz, Albrecht (Nokia - DE)" Thread-Topic: [MMUSIC] DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAADlkIAACsv+IA== Date: Mon, 8 Feb 2016 20:45:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DC39DBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7lG71vx1hBq0/xC0+nu9htpi6/DGL xYwLU5kdmD2WLPnJ5HH31iUmj1tTCgKYo7hsUlJzMstSi/TtErgy1vz5wFowZTFjxYL2g6wN jC/mMXYxcnJICJhINM/qY4awxSQu3FvPBmILCRxmlGg6x97FyAVkL2aUuLNoG1ADBwebgIVE 9z9tkBoRgTSJ3RfmsYLYzAIyEjPONjKB2MICuhLXWs8wQdToSUzY38IIYTtJNK14CGazCKhI vL7+GszmFfCV2DHtHgvErueMEtPbDoI1cwoEStzb9ALsIEag476fWsMEsUxc4taT+UwQRwtI LNlzHuoBUYmXj/+xQthKEo1LnrCC3MwskC9xa0U5xC5BiZMzn7BMYBSdhWTSLISqWUiqIMKa Eut36UNUK0pM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmD8 Hdzy22oH48HnjocYBTgYlXh4DaZsDxNiTSwrrsw9xCjBwawkwmvzckeYEG9KYmVValF+fFFp TmrxIUZpDhYlcd41zuvDhATSE0tSs1NTC1KLYLJMHJxSDYyTer/Fb18QZT3l0Je5LIpd9RnW h9919+fcTTi/NuaR1LXziVsmyrq1n2idaWywW3Sa1v3NHFvzK2zei+8wXRUT94E7d1Nzd+2D rEmeatz3N/I8r9IX0Znz9P6jZY+87p3Ob3+38kPjFTahQ3PuWHxYbvjhf4bXuwOmmll3XrRZ Lblzkvuuj6yfEktxRqKhFnNRcSIAgoIcgbsCAAA= Archived-At: Cc: mmusic Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 08 Feb 2016 20:45:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DC39DBESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4gVGhlIHByb2JsZW0gd2l0aCBEVExTLW92ZXItU0NUUCAoUkZDIDYwODMpIGlzIHRo YXQgaXQgaXMgbm90IGZ1bGx5IGNvbXBhdGlibGUgd2l0aCBkcmFmdC1pZXRmLW1tdXNpYy1kdGxz LXNkcC4NCj4gSW4gcGFydGljdWxhciwgUkZDIDYwODMgZG9lcyBub3QgYWxsb3cgRFRMUyBhc3Nv Y2lhdGlvbiBzcGFuIGFjcm9zcyBtdWx0aXBsZSBTQ1RQIGFzc29jaWF0aW9ucywgYnV0DQo+IGRy YWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIGFsbG93cyB0byBwcmVzZXJ2ZSBEVExTIGFzc29jaWF0 aW9uIHRocm91Z2ggYSB0cmFuc3BvcnQgY2hhbmdlLiBUaGUgbW9zdCBsaWtlbHkNCj4gc29sdXRp b24gdG8gdGhpcyBpcyB1cGRhdGluZyBSRkMgNjA4MywgYnV0LCBpZiBubyBvbmUgaXMgdXNpbmcg RFRMUy1vdmVyLVNDVFAsIGl0IHdvdWxkIGJlIGVhc2llciBqdXN0IHRvIHNheQ0KPiB0aGF0IERU TFMtb3Zlci1TQ1RQIGlzIG5vdCBzdXBwb3J0ZWQuDQoNCipJZiogd2UgZGVjaWRlIHRvIGtlZXAg RFRMUy1vdmVyLVNDVFAgaW4gdGhlIGRyYWZ0LCBteSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHNh eSB0aGF0IOKAnERUTFMgcHJlc2VydmF0aW9uIG92ZXIgdHJhbnNwb3J0IGNoYW5nZeKAnSBkb2Vz IG5vdCBhcHBseSB0byBEVExTLW92ZXItU0NUUCwgd2l0aCBhIHJlZmVyZW5jZSB0byBSRkMgNjA4 My4NCg0KVGhlbiwgaWYgc29tZW9uZSBhdCBzb21lIHBvaW50IHVwZGF0ZXMgUkZDIDYwODMsIHRo ZSBTQ1RQLVNEUCBzcGVjIGFsc28gaGFzIHRvIGJlIHVwZGF0ZWQuDQoNCkkgZG8gTk9UIHdhbnQg dG8gZGVsYXkgZHJhZnQtc2N0cC1zZHAgdW50aWwgYSBwb3NzaWJsZSBSRkMgNjA4MyB1cGRhdGUg aGFzIGJlZW4gZG9uZSAoYXNzdW1pbmcgcGVvcGxlIHdvdWxkIGFncmVlIHRvIGRvIGl0IGluIHRo ZSBmaXJzdCBwbGFjZSkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KX19fX19fX19fX19f Xw0KUm9tYW4gU2hwb3VudA0KDQpPbiBNb24sIEZlYiA4LCAyMDE2IGF0IDEwOjEyIEFNLCBTY2h3 YXJ6LCBBbGJyZWNodCAoTm9raWEgLSBERSkgPGFsYnJlY2h0LnNjaHdhcnpAbm9raWEuY29tPG1h aWx0bzphbGJyZWNodC5zY2h3YXJ6QG5va2lhLmNvbT4+IHdyb3RlOg0KSGVsbG8gQ2hyaXN0ZXIs DQoNCnRoZSB0aXRlbCBvZiB0aGUgKGZ1dHVyZSkgUkZDIHdpbGwgbm90IGV4Y2x1ZGUgYW55IFND VFAgdHJhbnNwb3J0IG1vZGVzLg0KQW5kIGEgY29tcHJlaGVuc2l2ZSBhbmQgZnV0dXJlIHNhZmUg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBzaG91bGQgY292ZXIgYWxsIGV4aXN0aW5nIG9uZXMsIHdo aWNoIGlzIOKAnERUTFMvU0NUUC9JUOKAnSBhcyB3ZWxsIGFzIOKAnFNDVFAvVURQL0lQ4oCdIChS RkMgNjk1MSkuDQpUaGVzZSB0d28gU0NUUCB0cmFuc3BvcnQgbW9kZXMgc2hvdWxkIGJlIGluZGlj YXRlZCBhcyB3ZWxsLCBpbmRlcGVuZGVudCBvZiBwb3RlbnRpYWwgaW50ZW50aW9ucyB0byBiZSB1 c2VkIHNvb24uDQpDb2RlcG9pbnQgc3BhY2UgY291bGQgYmUgcmVzZXJ2ZWQsIHBsYWNlaG9sZGVy IHNlY3Rpb25zIHRhZ2dlZCBhcyDigJxub3QgeWV0IHN1cHBvcnRlZOKAnSBvZiDigJxmb3IgZnVy dGhlciBzdHVkaWVz4oCdLCBldGMsIGJ1dCB0aGUgd29yc3QgY2FzZSB3b3VsZCBiZSBhbnkga2lu ZCBvZiBpbnRlcmFjdGlvbiBpc3N1ZXMgaW4gZnV0dXJlLg0KDQpNeSB2aWV3LA0KQWxicmVjaHQN Cg0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRVhUIENocmlzdGVyIEhvbG1i ZXJnDQpTZW50OiBNb250YWcsIDguIEZlYnJ1YXIgMjAxNiAxNTozMw0KVG86IG1tdXNpYyA8bW11 c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW01NVVNJQ10g RFRMUy1vdmVyLVNDVFAsIGFueW9uZT8NCg0KSGksDQoNCmRyYWZ0LWlldGYtbW11c2ljLXNjdHAt c2RwIGN1cnJlbnRseSBkZWZpbmVzIHRoZSBTRFAgTy9BIHByb2NlZHVyZXMgZm9yIFNDVFAsIFND VFAtb3Zlci1EVExTLCBhbmQgRFRMUy1vdmVyLVNDVFAuDQoNCkFzIHdlIGtub3csIFNDVFAtb3Zl ci1EVExTIGlzIHVzZWQgZm9yIHRoZSBXZWJSVEMgZGF0YSBjaGFubmVsLg0KDQpNeSBxdWVzdGlv biBpczogZG9lcyBhbnlvbmUgaW50ZW5kIHRvIHVzZSBEVExTLW92ZXItU0NUUD8NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37DC39DBESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTk5MzY4MTU5NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTQyMzIxODg1MiAxMzQ4MDc1NjkgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4 MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoZSBwcm9ibGVt IHdpdGggRFRMUy1vdmVyLVNDVFAgKFJGQyA2MDgzKSBpcyB0aGF0IGl0IGlzIG5vdCBmdWxseSBj b21wYXRpYmxlIHdpdGggZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPC9zcGFuPklu IHBhcnRpY3VsYXIsIFJGQyA2MDgzIGRvZXMgbm90IGFsbG93IERUTFMgYXNzb2NpYXRpb24gc3Bh biBhY3Jvc3MgbXVsdGlwbGUgU0NUUCBhc3NvY2lhdGlvbnMsIGJ1dCZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQo8L3NwYW4+ ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgYWxsb3dzIHRvIHByZXNlcnZlIERUTFMgYXNzb2Np YXRpb24gdGhyb3VnaCBhIHRyYW5zcG9ydCBjaGFuZ2UuIFRoZSBtb3N0IGxpa2VseQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwv c3Bhbj5zb2x1dGlvbiB0byB0aGlzIGlzIHVwZGF0aW5nIFJGQyA2MDgzLCBidXQsIGlmIG5vIG9u ZSBpcyB1c2luZyBEVExTLW92ZXItU0NUUCwgaXQgd291bGQgYmUgZWFzaWVyIGp1c3QgdG8gc2F5 DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0Ow0KPC9zcGFuPnRoYXQmbmJzcDtEVExTLW92ZXItU0NUUCBpcyBub3Qgc3VwcG9ydGVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPio8Yj5JZjwvYj4qIHdlIGRlY2lkZSB0byBrZWVwIERUTFMtb3Zlci1TQ1RQIGluIHRo ZSBkcmFmdCwgbXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBzYXkgdGhhdCDigJxEVExTIHByZXNl cnZhdGlvbiBvdmVyIHRyYW5zcG9ydCBjaGFuZ2XigJ0gZG9lcyBub3QgYXBwbHkgdG8gRFRMUy1v dmVyLVNDVFAsIHdpdGgNCiBhIHJlZmVyZW5jZSB0byBSRkMgNjA4My48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VGhlbiwgaWYgc29tZW9uZSBhdCBzb21lIHBvaW50IHVwZGF0ZXMgUkZDIDYwODMsIHRoZSBTQ1RQ LVNEUCBzcGVjIGFsc28gaGFzIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG8gTk9U IHdhbnQgdG8gZGVsYXkgZHJhZnQtc2N0cC1zZHAgdW50aWwgYSBwb3NzaWJsZSBSRkMgNjA4MyB1 cGRhdGUgaGFzIGJlZW4gZG9uZSAoYXNzdW1pbmcgcGVvcGxlIHdvdWxkIGFncmVlIHRvIGRvIGl0 IGluIHRoZSBmaXJzdCBwbGFjZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91 bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IEZlYiA4LCAyMDE2IGF0IDEwOjEyIEFNLCBTY2h3YXJ6LCBBbGJyZWNodCAoTm9raWEgLSBERSkg Jmx0OzxhIGhyZWY9Im1haWx0bzphbGJyZWNodC5zY2h3YXJ6QG5va2lhLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmFsYnJlY2h0LnNjaHdhcnpAbm9raWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+SGVsbG8gQ2hyaXN0ZXIsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzFGNDk3RCI+dGhlIHRpdGVsIG9mIHRoZSAoZnV0dXJlKSBSRkMgd2lsbCBub3QgZXhjbHVk ZSBhbnkgU0NUUCB0cmFuc3BvcnQgbW9kZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+QW5kIGEgY29t cHJlaGVuc2l2ZSBhbmQgZnV0dXJlIHNhZmUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBzaG91bGQg Y292ZXIgYWxsIGV4aXN0aW5nIG9uZXMsIHdoaWNoIGlzIOKAnERUTFMvU0NUUC9JUOKAnQ0KIGFz IHdlbGwgYXMg4oCcU0NUUC9VRFAvSVDigJ0gKFJGQyA2OTUxKS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5UaGVzZSB0d28gU0NUUCB0cmFuc3BvcnQgbW9kZXMgc2hvdWxkIGJlIGluZGljYXRlZCBhcyB3 ZWxsLCBpbmRlcGVuZGVudCBvZiBwb3RlbnRpYWwgaW50ZW50aW9ucyB0byBiZSB1c2VkIHNvb24u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+Q29kZXBvaW50IHNwYWNlIGNvdWxkIGJlIHJlc2VydmVkLCBw bGFjZWhvbGRlciBzZWN0aW9ucyB0YWdnZWQgYXMg4oCcbm90IHlldCBzdXBwb3J0ZWTigJ0gb2Yg 4oCcZm9yIGZ1cnRoZXIgc3R1ZGllc+KAnSwgZXRjLA0KIGJ1dCB0aGUgd29yc3QgY2FzZSB3b3Vs ZCBiZSBhbnkga2luZCBvZiBpbnRlcmFjdGlvbiBpc3N1ZXMgaW4gZnV0dXJlLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPk15IHZpZXcsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+QWxicmVjaHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBtbXVz aWMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkVYVCBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBNb250YWcsIDguIEZl YnJ1YXIgMjAxNiAxNTozMzxicj4NCjxiPlRvOjwvYj4gbW11c2ljICZsdDs8YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW01NVVNJQ10gRFRMUy1vdmVyLVNDVFAsIGFueW9uZT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5kcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcCBjdXJyZW50 bHkgZGVmaW5lcyB0aGUgU0RQIE8vQSBwcm9jZWR1cmVzIGZvciBTQ1RQLCBTQ1RQLW92ZXItRFRM UywgYW5kIERUTFMtb3Zlci1TQ1RQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHdlIGtub3cs IFNDVFAtb3Zlci1EVExTIGlzIHVzZWQgZm9yIHRoZSBXZWJSVEMgZGF0YSBjaGFubmVsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPk15IHF1ZXN0aW9uIGlzOiBkb2VzIGFueW9uZSBpbnRlbmQgdG8g dXNlIERUTFMtb3Zlci1TQ1RQPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37DC39DBESESSMB209erics_-- From nobody Mon Feb 8 12:46: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 AD4361B32F4 for ; Mon, 8 Feb 2016 12:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-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 BmHVdkFrDQxT for ; Mon, 8 Feb 2016 12:46: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 AF5911B32FA for ; Mon, 8 Feb 2016 12:46:35 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u18KkRMn013439 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Feb 2016 14:46:28 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins References: <56B22757.9090906@nostrum.com> From: Adam Roach Message-ID: <56B8FEA3.30200@nostrum.com> Date: Mon, 8 Feb 2016 14:46:27 -0600 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: 8bit Archived-At: Cc: mmusic Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-01 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, 08 Feb 2016 20:46:36 -0000 On 2/4/16 18:17, Colin Perkins wrote: >> On 3 Feb 2016, at 16:14, Adam Roach wrote: >> On 2/2/16 11:41, Colin Perkins wrote: >>> I didn’t find a precise specification in the draft for what RID parameters constrain what “a=fmtp:" parameters, for what RTP payload formats. I think this draft needs a complete list of which parameters are constrained by each RID parameter, to ensure unambiguous behaviour with existing codecs. >> I fear such an approach may be intractable. On a quick analysis, I find almost 100 RFCs that define "a=fmtp" parameters, and most of those define more than one. If you want to volunteer to slog through that entire corpus and figure out which correspond to the constraints we're defining, I'll happily accept the output of that work. But I suspect you'll reach the same conclusion as I did: it’s not a reasonable task. > I’m not volunteering, but I think the problem is smaller than it seems, since this only applies to video codecs that have flexibility in encoding. Many of those 100 RFCs are for audio, text, or FEC formats, and many of the remaining are for video codecs are have insufficient flexibility to be impacted by the constraints, or are effectively obsolete. > > At the least, it ought to do the analysis and mapping of a=fmtp parameters to rid constraints for the small number of modern codecs that people are likely to use - the WebRTC recommendations, for example. It seems that anything less than full coverage would be difficult to do in a normative way, unless we restrict RIDs for use with the subset of codecs we decided to analyze. That said, it seems reasonable and tractable to have a non-normative description of how the fmtp parameters of two codecs you indicate interact with the constraints defined in this document. I'll make a run at this and put the results out as a -04. >> >> Trying to harmonize PAYLOAD's handling of seems to be somewhat outside the scope of what this document is doing. I mean, I get that the lack of coordination of constraining parameters on video codecs is a pretty sad state of affairs, but it's not really fair to shackle this draft to the task of solving that mess before it can move forward. >> >> To be clear, I'd be happy to see some kind of guidance regarding put forth in an independent document so that there is at least a modicum of uniformity for future formats. I just think it's not in the scope of the RID work. > I thought this wasn’t do bad: “registrations of future RTP payload format specifications that define media types that have parameters matching the RID constraints specified in this memo SHOULD name those parameters in a manner that matches the names of those RID constraints, and SHOULD explicitly state what media type parameters are constrained by what RID constraints”? > > IANA considerations: "this draft updates RFC 4855 to give additional guidance on choice of parameter names, and on their relation to RID constraints [RFC XXXX]” I'm happy to add your proposed text, but I'm going to very quick to suggest pulling it out if it looks like it's going to slow down this document. It's really not the core purpose of this spec to fix PAYLOAD's format parameter naming morass. /a From nobody Mon Feb 8 15:20:41 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 CFF641B3D20; Mon, 8 Feb 2016 15:20:37 -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.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160208232037.11315.19138.idtracker@ietfa.amsl.com> Date: Mon, 08 Feb 2016 15:20:37 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-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, 08 Feb 2016 23:20:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : RTP Payload Format Constraints Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-04.txt Pages : 26 Date : 2016-02-08 Abstract: In this specification, we define a framework for identifying RTP Streams with the constraints on its payload format in the Session Description Protocol. This framework defines a new "rid" SDP attribute to: a) effectively identify the RID RTP Streams within a RTP Session, b) constrain their payload format parameters in a codec- agnostic way beyond what is provided with the regular Payload Types and c) enable unambiguous mapping between the RID RTP Streams to their media format specification in the SDP. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the constraints defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-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 Feb 8 15:23: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 1AB371B3D2D for ; Mon, 8 Feb 2016 15:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-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 DevdzJKgatvv for ; Mon, 8 Feb 2016 15:23:09 -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 D23961B3D1A for ; Mon, 8 Feb 2016 15:23:09 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u18NN4vO027357 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Feb 2016 17:23:05 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins References: <56B22757.9090906@nostrum.com> <56B8FEA3.30200@nostrum.com> From: Adam Roach Message-ID: <56B92358.70007@nostrum.com> Date: Mon, 8 Feb 2016 17:23:04 -0600 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: <56B8FEA3.30200@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: mmusic Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-01 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, 08 Feb 2016 23:23:11 -0000 Colin: I've dropped a new version (-04) that incorporates this feedback. Please review the changes (https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-04) and confirm that they address your feedback. /a On 2/8/16 14:46, Adam Roach wrote: > On 2/4/16 18:17, Colin Perkins wrote: >>> On 3 Feb 2016, at 16:14, Adam Roach wrote: >>> On 2/2/16 11:41, Colin Perkins wrote: >>>> I didn’t find a precise specification in the draft for what RID >>>> parameters constrain what “a=fmtp:" parameters, for what RTP >>>> payload formats. I think this draft needs a complete list of which >>>> parameters are constrained by each RID parameter, to ensure >>>> unambiguous behaviour with existing codecs. >>> I fear such an approach may be intractable. On a quick analysis, I >>> find almost 100 RFCs that define "a=fmtp" parameters, and most of >>> those define more than one. If you want to volunteer to slog through >>> that entire corpus and figure out which correspond to the >>> constraints we're defining, I'll happily accept the output of that >>> work. But I suspect you'll reach the same conclusion as I did: it’s >>> not a reasonable task. >> I’m not volunteering, but I think the problem is smaller than it >> seems, since this only applies to video codecs that have flexibility >> in encoding. Many of those 100 RFCs are for audio, text, or FEC >> formats, and many of the remaining are for video codecs are have >> insufficient flexibility to be impacted by the constraints, or are >> effectively obsolete. >> >> At the least, it ought to do the analysis and mapping of a=fmtp >> parameters to rid constraints for the small number of modern codecs >> that people are likely to use - the WebRTC recommendations, for example. > > It seems that anything less than full coverage would be difficult to > do in a normative way, unless we restrict RIDs for use with the subset > of codecs we decided to analyze. > > That said, it seems reasonable and tractable to have a non-normative > description of how the fmtp parameters of two codecs you indicate > interact with the constraints defined in this document. I'll make a > run at this and put the results out as a -04. > >>> >>> Trying to harmonize PAYLOAD's handling of >> parameters> seems to be somewhat outside the scope of what this >>> document is doing. I mean, I get that the lack of coordination of >>> constraining parameters on video codecs is a pretty sad state of >>> affairs, but it's not really fair to shackle this draft to the task >>> of solving that mess before it can move forward. >>> >>> To be clear, I'd be happy to see some kind of guidance regarding >>> put forth in an independent document so >>> that there is at least a modicum of uniformity for future formats. I >>> just think it's not in the scope of the RID work. >> I thought this wasn’t do bad: “registrations of future RTP payload >> format specifications that define media types that have parameters >> matching the RID constraints specified in this memo SHOULD name those >> parameters in a manner that matches the names of those RID >> constraints, and SHOULD explicitly state what media type parameters >> are constrained by what RID constraints”? >> >> IANA considerations: "this draft updates RFC 4855 to give additional >> guidance on choice of parameter names, and on their relation to RID >> constraints [RFC XXXX]” > > I'm happy to add your proposed text, but I'm going to very quick to > suggest pulling it out if it looks like it's going to slow down this > document. It's really not the core purpose of this spec to fix > PAYLOAD's format parameter naming morass. > > /a From nobody Mon Feb 8 17:57: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 5B4401B3F3E for ; Mon, 8 Feb 2016 17:57:20 -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 Olh0bIdtlu1T for ; Mon, 8 Feb 2016 17:57:18 -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 E6F7A1B3F3D for ; Mon, 8 Feb 2016 17:57:17 -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=EHvFt/0eU2oaQiAZbKVxwFw2Oa2eR5wwEtalKrXDsgM=; b=car+owhy3eBtj4F+QEvFpJn07p IQXhi2UnItCtGMuqnyxirMCRnUjcvxRBBIhRM8qawf+iJMrr2cwx6P8psUHpvZ7Gt70brfdkz4qoG 8dRgJ/ysBYCQDZTg6k00lRJNl6tYbio7BArTeeqsPPv4mA5s6qJw5tiZlSQ+wXjy8V5RV8f6DLtsJ oyu/CfnCtMPI2uS7tR+UzVfYWeFGcBrKfo2+nzGtHTQMXvELjb0TlX2gY4K2nZitAT4n9TL5JBOkR Tw75KHDuYFlvgF9SC3riSi2gd80p+bv0YA3R5q0VckQbsg0OUXDMiMutuDGKe1BgAhd3ZMwJoiZmc UvllRBIQ==; Received: from ppp118-209-127-77.lns20.mel4.internode.on.net ([118.209.127.77]:50315 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aSxYG-001y6Y-Tg for mmusic@ietf.org; Tue, 09 Feb 2016 12:57:13 +1100 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> From: Christian Groves Message-ID: <56B94776.3090606@nteczone.com> Date: Tue, 9 Feb 2016 12:57:10 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> 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] DTLS-over-SCTP, anyone? 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, 09 Feb 2016 01:57:20 -0000 Hello I think the fact that the draft doesn't support DTLS-over-SCTP has been known for some time. No one has been pushing for its inclusion. I'd be happy if it was left out to be able to progress the draft. Alternatively we can do what I think Albrecht is suggesting. Reserve proto values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate their use by SDP should be defined in a future specification. I don't think its worth solving that problem now. Regards, Christian On 9/02/2016 7:45 AM, Christer Holmberg wrote: > > Hi, > > > The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully > compatible with draft-ietf-mmusic-dtls-sdp. > > > In particular, RFC 6083 does not allow DTLS association span across > multiple SCTP associations, but > > > draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association > through a transport change. The most likely > > > solution to this is updating RFC 6083, but, if no one is using > DTLS-over-SCTP, it would be easier just to say > > > that DTLS-over-SCTP is not supported. > > **If** we decide to keep DTLS-over-SCTP in the draft, my suggestion > would be to say that DTLS preservation over transport change does > not apply to DTLS-over-SCTP, with a reference to RFC 6083. > > Then, if someone at some point updates RFC 6083, the SCTP-SDP spec > also has to be updated. > > I do NOT want to delay draft-sctp-sdp until a possible RFC 6083 update > has been done (assuming people would agree to do it in the first place). > > Regards, > > Christer > > _____________ > Roman Shpount > > On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) > > wrote: > > Hello Christer, > > the titel of the (future) RFC will not exclude any SCTP transport > modes. > > And a comprehensive and future safe protocol specification should > cover all existing ones, which is DTLS/SCTP/IP as well as > SCTP/UDP/IP (RFC 6951). > > These two SCTP transport modes should be indicated as well, > independent of potential intentions to be used soon. > > Codepoint space could be reserved, placeholder sections tagged as > not yet supported of for further studies, etc, but the worst > case would be any kind of interaction issues in future. > > My view, > > Albrecht > > *From:*mmusic [mailto:mmusic-bounces@ietf.org > ] *On Behalf Of *EXT Christer Holmberg > *Sent:* Montag, 8. Februar 2016 15:33 > *To:* mmusic > > *Subject:* [MMUSIC] DTLS-over-SCTP, anyone? > > Hi, > > draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A > procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP. > > As we know, SCTP-over-DTLS is used for the WebRTC data channel. > > My question is: does anyone intend to use DTLS-over-SCTP? > > 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 Tue Feb 9 04:30: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 502AA1A8A1A for ; Tue, 9 Feb 2016 04:30:25 -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 r494XQYS0hLa for ; Tue, 9 Feb 2016 04:30:23 -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 726F51A8A16 for ; Tue, 9 Feb 2016 04:30:23 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-d0-56b9dbdd4270 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FA.83.30208.DDBD9B65; Tue, 9 Feb 2016 13:30:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Tue, 9 Feb 2016 13:30:21 +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: AdFSIHDldlmmcNh4RhSwHgQukuMFtARFQgAA Date: Tue, 9 Feb 2016 12:30:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DC6DA3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D438DF@ESESSMB209.ericsson.se> In-Reply-To: <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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DC6DA3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbE9XPfu7Z1hBrf3KltMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGd9mdLIWfNau2Lv+HGsD4yz1LkZODgkBE4l/xyexQthiEhfu rWfrYuTiEBI4zCjRemAulLOYUWLO6tNAVRwcbAIWEt3/tEEaRARiJb6ue88EYgsLRElsPDmD DSIeLfFwcTszhG0kceHWBmaQVhYBFYmvkxxBwrwCvhLbXz9lBLGFgOwNu4+AjeEU8JNYsXIX 2BhGoHu+n1oDFmcWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/gd2mYSAosTyfjmI8nyJ498esUGs EpQ4OfMJywRGkVlIJs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqc lJtuZKyXWpSZXFycn6eXl1qyiREYPwe3/FbdwXj5jeMhRgEORiUe3g+yO8OEWBPLiitzDzFK cDArifA63QQK8aYkVlalFuXHF5XmpBYfYpTmYFES513jvD5MSCA9sSQ1OzW1ILUIJsvEwSnV wKg4kSmduUXo3F+eyENNymbqaZ/WHXn9m4nvscbhTT+33GkMNz3BfNs5VabSP0w3M/1MXKOO G1v3yu8O4b/mh7z6pdFR0SasMp9RR9Tx33vx4vk9t1v1Mk7U/956TzR+Ccd/YenbyyQk/qgG GH17XL/u5CNdrn2n/x6dICobxMknfSavydlyrhJLcUaioRZzUXEiAAthdeWbAgAA 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: Tue, 09 Feb 2016 12:30:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DC6DA3ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have heard no input on this, so my suggestion is to mandate that BUNDLE e= ntities at least understand the mux-exclusive attribute. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 18. tammikuuta 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_7594FB04B1934943A5C02806D1A2204B37DC6DA3ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I have = heard no input on this, so my suggestion is to mandate that BUNDLE entities= at least understand the mux-exclusive attribute.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

mmusi= c [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18. tammikuuta 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, with= in a BUNDLE group, RTP/RTCP multiplexing MUST be used for all RTP-based med= ia.

 

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

 

Or, should support of mux-exclu= sive be a SHALL/SHOULD/MAY/RECOMMENDED?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37DC6DA3ESESSMB209erics_-- From nobody Tue Feb 9 05:41: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 DA8361A9025 for ; Tue, 9 Feb 2016 05:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] 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 IHeJXNLQs3pW for ; Tue, 9 Feb 2016 05:41:00 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC791A9004 for ; Tue, 9 Feb 2016 05:41:00 -0800 (PST) Received: from [130.209.247.112] (port=53008 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aT8XJ-00024J-8V; Tue, 09 Feb 2016 13:40:58 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56B92358.70007@nostrum.com> Date: Tue, 9 Feb 2016 13:40:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B22757.9090906@nostrum.com> <56B8FEA3.30200@nostrum.com> <56B92358.70007@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: mmusic Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-01 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, 09 Feb 2016 13:41:03 -0000 Thanks - I do think that helps. Colin > On 8 Feb 2016, at 23:23, Adam Roach wrote: >=20 > Colin: >=20 > I've dropped a new version (-04) that incorporates this feedback. = Please review the changes = (https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rid-04) and = confirm that they address your feedback. >=20 > /a >=20 > On 2/8/16 14:46, Adam Roach wrote: >> On 2/4/16 18:17, Colin Perkins wrote: >>>> On 3 Feb 2016, at 16:14, Adam Roach wrote: >>>> On 2/2/16 11:41, Colin Perkins wrote: >>>>> I didn=E2=80=99t find a precise specification in the draft for = what RID parameters constrain what =E2=80=9Ca=3Dfmtp:" parameters, for = what RTP payload formats. I think this draft needs a complete list of = which parameters are constrained by each RID parameter, to ensure = unambiguous behaviour with existing codecs. >>>> I fear such an approach may be intractable. On a quick analysis, I = find almost 100 RFCs that define "a=3Dfmtp" parameters, and most of = those define more than one. If you want to volunteer to slog through = that entire corpus and figure out which correspond to the constraints = we're defining, I'll happily accept the output of that work. But I = suspect you'll reach the same conclusion as I did: it=E2=80=99s not a = reasonable task. >>> I=E2=80=99m not volunteering, but I think the problem is smaller = than it seems, since this only applies to video codecs that have = flexibility in encoding. Many of those 100 RFCs are for audio, text, or = FEC formats, and many of the remaining are for video codecs are have = insufficient flexibility to be impacted by the constraints, or are = effectively obsolete. >>>=20 >>> At the least, it ought to do the analysis and mapping of a=3Dfmtp = parameters to rid constraints for the small number of modern codecs that = people are likely to use - the WebRTC recommendations, for example. >>=20 >> It seems that anything less than full coverage would be difficult to = do in a normative way, unless we restrict RIDs for use with the subset = of codecs we decided to analyze. >>=20 >> That said, it seems reasonable and tractable to have a non-normative = description of how the fmtp parameters of two codecs you indicate = interact with the constraints defined in this document. I'll make a run = at this and put the results out as a -04. >>=20 >>>>=20 >>>> Trying to harmonize PAYLOAD's handling of seems to be somewhat outside the scope of what this document = is doing. I mean, I get that the lack of coordination of constraining = parameters on video codecs is a pretty sad state of affairs, but it's = not really fair to shackle this draft to the task of solving that mess = before it can move forward. >>>>=20 >>>> To be clear, I'd be happy to see some kind of guidance regarding = put forth in an independent document so = that there is at least a modicum of uniformity for future formats. I = just think it's not in the scope of the RID work. >>> I thought this wasn=E2=80=99t do bad: =E2=80=9Cregistrations of = future RTP payload format specifications that define media types that = have parameters matching the RID constraints specified in this memo = SHOULD name those parameters in a manner that matches the names of those = RID constraints, and SHOULD explicitly state what media type parameters = are constrained by what RID constraints=E2=80=9D? >>>=20 >>> IANA considerations: "this draft updates RFC 4855 to give additional = guidance on choice of parameter names, and on their relation to RID = constraints [RFC XXXX]=E2=80=9D >>=20 >> I'm happy to add your proposed text, but I'm going to very quick to = suggest pulling it out if it looks like it's going to slow down this = document. It's really not the core purpose of this spec to fix PAYLOAD's = format parameter naming morass. >>=20 >> /a >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Feb 9 08:10:41 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 888631AC3A5 for ; Tue, 9 Feb 2016 08:10:39 -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 kB7OMVt_F4ax for ; Tue, 9 Feb 2016 08:10:38 -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 501011AC3C1 for ; Tue, 9 Feb 2016 08:10:38 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-01v.sys.comcast.net with comcast id GG7w1s0054zp9eg01GAbHo; Tue, 09 Feb 2016 16:10:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-07v.sys.comcast.net with comcast id GGAa1s00S3KdFy101GAbiM; Tue, 09 Feb 2016 16:10:35 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37D438DF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DC6DA3@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56BA0F7A.3080101@alum.mit.edu> Date: Tue, 9 Feb 2016 11:10: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: <7594FB04B1934943A5C02806D1A2204B37DC6DA3@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=1455034235; bh=hK5Ks4C2woteZvJS485OE/pr8W6qhE2EKvoeC0m+URI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fOzNh2pjclRIly1EljSua/HAe7QmUDtNggD6zTejo3yPtM2DS0Z4Ee3o3in4yeeLj M45+PAga8Y8f78/ep0BY8ySrDhl+B0wOKnCwZBSrlnZRzFaj8yMXzBT8FVLo83Scfo CkDfoMY8x/hR+6jT36WewdKxF3hiU01i7YPRktRqJYDLH3ODpGys9bQK11xbdr+4jk G7n27q+vf4xPjXFDXCqUWdLdHnPidoASbGg9/vOF6LkpQLQpMsw79ltoTbu3v+SNe5 d6R7pM92ngtG4vh6QkdPqY5j31kfvb06Cy1IEthRuwVuC8EPVNA6cJXkb8lO+BsloH RCMksHEij2RMA== 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: Tue, 09 Feb 2016 16:10:39 -0000 On 2/9/16 7:30 AM, Christer Holmberg wrote: > Hi, > > I have heard no input on this, so my suggestion is to mandate that > BUNDLE entities at least understand the mux-exclusive attribute. +1 > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 18. tammikuuta 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, RTP/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/SHOULD/MAY/RECOMMENDED? > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Feb 9 16:05: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 506631B3216 for ; Tue, 9 Feb 2016 16:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 99I18CNcxyI0 for ; Tue, 9 Feb 2016 16:05:04 -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 1CD461B321D for ; Tue, 9 Feb 2016 16:05:03 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id f81so5109115iof.0 for ; Tue, 09 Feb 2016 16:05: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 :cc:content-type; bh=crblmUbYPiBZ0NPiajVGU+QUSzZIfJ8EApg2LyN2ONk=; b=TXOzcyWS3i/Nhe0zBB+1zbZUFBA2dklaSW7Q4/Uv2Er1APdtF0byGaBq2spIjDQVX0 Hrl8yjNuYN69bzqbmCE3jBaTz8tx/Q6lms0jcqfbeKHcROXCHjyueMkUlTRm2EB7bsdO xc0OFJeVVfph7VA6XpHwqHHjJ/4X8c6VwH4n7IZPQcfnAYvmcwgzncTKLvKhi8/iARq7 64UI7lAqBp1IjfGspNovWpenyl5v9bqAID+U71gImiE/VOMG1FnVisB+B6tKtfSoow+T p/ElutzkD8cqpqcwiSskIw8XkpaMiD/owBX/NjkyrmtAGMw0mDuFw5O6okZDsT9DWswg oENw== 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=crblmUbYPiBZ0NPiajVGU+QUSzZIfJ8EApg2LyN2ONk=; b=XvwaqjmXLng4PnZGgPZX+UIBul8zhv1kiGpoFQnFACoP98HKjwVpqhpuwZ3bc81Z9D zH2mJCKcaPjlBvHK5Mwk+IjQyFXyXCoSszAfWkFtIXTCwY+DHsLLGsEvPkXkpbpZHsVb s8XNFowe2HT+CknJBkttEcC54J34l84WpnTVKI0gBc+orH6JShEitnUdb1/BvxhWz3T1 679lytxB4wuilgOao2DisBIiXEpqR3waJL1xvX/LSEkiwil2J/g5GIKmCSqmzIUB4E1/ 0vvAIMDZH6VooVX/UU1gwgJm+fFJfbsiqKYXU9iF0Wrf05i0YvrtYd88p5oOTyJwkgkf SwMA== X-Gm-Message-State: AG10YORMPUVT9efj1gbdbYqCgDVKMl3xbDrIGE6FhH09pngP38HdM8AWQRjxYwFINjDGug== X-Received: by 10.107.132.12 with SMTP id g12mr15666596iod.145.1455062702308; Tue, 09 Feb 2016 16:05:02 -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 n3sm547632iga.9.2016.02.09.16.05.01 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Feb 2016 16:05:01 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id 5so3441983igt.0 for ; Tue, 09 Feb 2016 16:05:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.33.51 with SMTP id o19mr7218110igi.2.1455062700703; Tue, 09 Feb 2016 16:05:00 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 9 Feb 2016 16:05:00 -0800 (PST) In-Reply-To: <56B94776.3090606@nteczone.com> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> Date: Tue, 9 Feb 2016 19:05:00 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0158b06666d0ce052b5f2f9d Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 10 Feb 2016 00:05:06 -0000 --089e0158b06666d0ce052b5f2f9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we can add the following to section 7.1 of dtls-sdp: If DTLS is transmitted over a reliable transport and if DTLS procedures for retransmissions are not used, for instance as described in RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span across multiple transports. Using 'dtls-connection' attribute with an 'existing' value in combination with change of such a reliable transport should be treated as an error and DTLS association MUST be terminated. _____________ Roman Shpount On Mon, Feb 8, 2016 at 8:57 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello > > I think the fact that the draft doesn't support DTLS-over-SCTP has been > known for some time. No one has been pushing for its inclusion. I'd be > happy if it was left out to be able to progress the draft. > > Alternatively we can do what I think Albrecht is suggesting. Reserve prot= o > values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate their u= se > by SDP should be defined in a future specification. I don't think its wor= th > solving that problem now. > > Regards, Christian > > On 9/02/2016 7:45 AM, Christer Holmberg wrote: > >> >> Hi, >> >> > The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully >> compatible with draft-ietf-mmusic-dtls-sdp. >> >> > In particular, RFC 6083 does not allow DTLS association span across >> multiple SCTP associations, but >> >> > draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association through >> a transport change. The most likely >> >> > solution to this is updating RFC 6083, but, if no one is using >> DTLS-over-SCTP, it would be easier just to say >> >> > that DTLS-over-SCTP is not supported. >> >> **If** we decide to keep DTLS-over-SCTP in the draft, my suggestion woul= d >> be to say that =E2=80=9CDTLS preservation over transport change=E2=80=9D= does not apply to >> DTLS-over-SCTP, with a reference to RFC 6083. >> >> Then, if someone at some point updates RFC 6083, the SCTP-SDP spec also >> has to be updated. >> >> I do NOT want to delay draft-sctp-sdp until a possible RFC 6083 update >> has been done (assuming people would agree to do it in the first place). >> >> Regards, >> >> Christer >> >> _____________ >> Roman Shpount >> >> On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) < >> albrecht.schwarz@nokia.com > wrote: >> >> Hello Christer, >> >> the titel of the (future) RFC will not exclude any SCTP transport >> modes. >> >> And a comprehensive and future safe protocol specification should >> cover all existing ones, which is =E2=80=9CDTLS/SCTP/IP=E2=80=9D as = well as >> =E2=80=9CSCTP/UDP/IP=E2=80=9D (RFC 6951). >> >> These two SCTP transport modes should be indicated as well, >> independent of potential intentions to be used soon. >> >> Codepoint space could be reserved, placeholder sections tagged as >> =E2=80=9Cnot yet supported=E2=80=9D of =E2=80=9Cfor further studies= =E2=80=9D, etc, but the worst >> case would be any kind of interaction issues in future. >> >> My view, >> >> Albrecht >> >> *From:*mmusic [mailto:mmusic-bounces@ietf.org >> ] *On Behalf Of *EXT Christer >> Holmberg >> *Sent:* Montag, 8. Februar 2016 15:33 >> *To:* mmusic > >> *Subject:* [MMUSIC] DTLS-over-SCTP, anyone? >> >> Hi, >> >> draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A >> procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP. >> >> As we know, SCTP-over-DTLS is used for the WebRTC data channel. >> >> My question is: does anyone intend to use DTLS-over-SCTP? >> >> 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 >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --089e0158b06666d0ce052b5f2f9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we can add the following to section 7.1 of dtls-sd= p:

If DTLS is transmitted over a reliable transport and = if DTLS procedures for retransmissions are not used, for instance as descri= bed in RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span acr= oss multiple transports. Using 'dtls-connection' attribute with an = 'existing' value in combination with change of such a reliable tran= sport should be treated as an error and DTLS association MUST be terminated= .
 --089e0158b06666d0ce052b5f2f9d-- From nobody Wed Feb 10 02:30: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 F19D01A1A6B for ; Wed, 10 Feb 2016 02:30:20 -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 sDOzQBZZbfEQ for ; Wed, 10 Feb 2016 02:30:19 -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 54CA91A1A6A for ; Wed, 10 Feb 2016 02:30:14 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-5d-56bb1133790c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.3B.05690.3311BB65; Wed, 10 Feb 2016 11:30:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Wed, 10 Feb 2016 11:29:54 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAADlkIAACsv+IAAJBDYAAC5fwgAAF9Un8A== Date: Wed, 10 Feb 2016 10:29:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdUddEcHeYQWM3q8XU5Y9ZLGZcmMrs wOSxZMlPJo9bUwoCmKK4bFJSczLLUov07RK4MmYfnsxSsE2v4tnGk6wNjHN0uxg5OSQETCSO z9vKBmGLSVy4tx7I5uIQEjjMKLHu2GZWkISQwBJGieldZV2MHBxsAhYS3f+0QcIiAqoSf79P ZgIJMwuoS1xdHAQSFhbQlbjWeoYJokRPYsL+FkYIO0zi4INzYKtYgFrP9BwCq+EV8JWYtmE7 I8TaKcwS71Z9BFvLKRAocW/VKbAGRqDbvp9aA9bALCAucevJfCaImwUkluw5zwxhi0q8fPyP FcJWkvix4RILxG2aEut36UO0KkpM6X7IDrFXUOLkzCcsExjFZiGZOguhYxaSjllIOhYwsqxi FC1OLS7OTTcy1kstykwuLs7P08tLLdnECIybg1t+6+5gXP3a8RCjAAejEg+vgfmuMCHWxLLi ytxDjBIczEoivJPYd4cJ8aYkVlalFuXHF5XmpBYfYpTmYFES513jvD5MSCA9sSQ1OzW1ILUI JsvEwSnVwNgW+aPw4JcdnO2iLpH/JNtOz/i0RzpjRv68G5/nxrxgnvbqw88S1UyxPYfMbVKq 9Xf/0JxqarLn+TmdUyWXn0WubuwxOG1jsEd5AbvJpXt833fvy5vcZ/O8de/Fa50XZ/J4v+7Q /hEjHrTbfHdN6gLJ2l62U5yXr2Udjv8ua2vFEnZK+9fcos9KLMUZiYZazEXFiQDwafFdlwIA AA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 10 Feb 2016 10:30:21 -0000 SGkgUm9tYW4sDQoNCj4gSSB0aGluayB3ZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcgdG8gc2VjdGlv biA3LjEgb2YgZHRscy1zZHA6DQo+DQo+IElmIERUTFMgaXMgdHJhbnNtaXR0ZWQgb3ZlciBhIHJl bGlhYmxlIHRyYW5zcG9ydCBhbmQgaWYgRFRMUyBwcm9jZWR1cmVzIGZvciByZXRyYW5zbWlzc2lv bnMgYXJlIG5vdCB1c2VkLCBmb3IgaW5zdGFuY2UgYXMgZGVzY3JpYmVkIGluDQo+IFJGQyA2MDgz IGZvciBEVExTIG92ZXIgU0NUUCwgdGhlbiBEVExTIGFzc29jaWF0aW9uIE1VU1QgTk9UIHNwYW4g YWNyb3NzIG11bHRpcGxlIHRyYW5zcG9ydHMuIFVzaW5nICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJp YnV0ZSB3aXRoIA0KPiBhbiAnZXhpc3RpbmcnIHZhbHVlIGluIGNvbWJpbmF0aW9uIHdpdGggY2hh bmdlIG9mIHN1Y2ggYSByZWxpYWJsZSB0cmFuc3BvcnQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYW4g ZXJyb3IgYW5kIERUTFMgYXNzb2NpYXRpb24gTVVTVCBiZSANCj4gdGVybWluYXRlZC4NCg0KWW91 ciB0ZXh0IGFzIHN1Y2ggbG9va3Mgb2suIEJ1dCwgZG8gd2UgcmVhbGx5IHdhbnQgdG8gYWRkIGl0 IGFzIGEgZ2VuZXJpYyByZXN0cmljdGlvbiBpbiBkcmFmdC1kdGxzLXNkcD8gU2hvdWxkbid0IGl0 IGJlIHNwZWNpZmljIGZvciBEVExTLW92ZXItU0NUUCBpbnN0ZWFkPyBXaGF0IGlmIHNvbWVvbmUg ZGVmaW5lcyBEVExTLW92ZXItPG5ldy1mYW5jeS1yZWxpYWJsZS10cmFuc3BvcnQ+IGFuZCB0aGV5 IERPIGFsbG93IHNwYW4/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCl9fX19fX19f X19fX18NClJvbWFuIFNocG91bnQNCg0KT24gTW9uLCBGZWIgOCwgMjAxNiBhdCA4OjU3IFBNLCBD aHJpc3RpYW4gR3JvdmVzIDxDaHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbT4gd3JvdGU6DQpI ZWxsbw0KDQpJIHRoaW5rIHRoZSBmYWN0IHRoYXQgdGhlIGRyYWZ0IGRvZXNuJ3Qgc3VwcG9ydCBE VExTLW92ZXItU0NUUCBoYXMgYmVlbiBrbm93biBmb3Igc29tZSB0aW1lLiBObyBvbmUgaGFzIGJl ZW4gcHVzaGluZyBmb3IgaXRzIGluY2x1c2lvbi4gSSdkIGJlIGhhcHB5IGlmIGl0IHdhcyBsZWZ0 IG91dCB0byBiZSBhYmxlIHRvIHByb2dyZXNzIHRoZSBkcmFmdC4NCg0KQWx0ZXJuYXRpdmVseSB3 ZSBjYW4gZG8gd2hhdCBJIHRoaW5rIEFsYnJlY2h0IGlzIHN1Z2dlc3RpbmcuIFJlc2VydmUgcHJv dG8gdmFsdWVzIGZvciBEVExTL1NDVFAvSVAgYW5kIFNDVFAvVURQL0lQIGluIHRoZSBkcmFmdCBh bmQgaW5kaWNhdGUgdGhlaXIgdXNlIGJ5IFNEUCBzaG91bGQgYmUgZGVmaW5lZCBpbiBhIGZ1dHVy ZSBzcGVjaWZpY2F0aW9uLiBJIGRvbid0IHRoaW5rIGl0cyB3b3J0aCBzb2x2aW5nIHRoYXQgcHJv YmxlbSBub3cuDQoNClJlZ2FyZHMsIENocmlzdGlhbg0KDQpPbiA5LzAyLzIwMTYgNzo0NSBBTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQoNCkhpLA0KDQo+IFRoZSBwcm9ibGVtIHdpdGggRFRM Uy1vdmVyLVNDVFAgKFJGQyA2MDgzKSBpcyB0aGF0IGl0IGlzIG5vdCBmdWxseSBjb21wYXRpYmxl IHdpdGggZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuDQoNCj4gSW4gcGFydGljdWxhciwgUkZD IDYwODMgZG9lcyBub3QgYWxsb3cgRFRMUyBhc3NvY2lhdGlvbiBzcGFuIGFjcm9zcyBtdWx0aXBs ZSBTQ1RQIGFzc29jaWF0aW9ucywgYnV0DQoNCj4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAg YWxsb3dzIHRvIHByZXNlcnZlIERUTFMgYXNzb2NpYXRpb24gdGhyb3VnaCBhIHRyYW5zcG9ydCBj aGFuZ2UuIFRoZSBtb3N0IGxpa2VseQ0KDQo+IHNvbHV0aW9uIHRvIHRoaXMgaXMgdXBkYXRpbmcg UkZDIDYwODMsIGJ1dCwgaWYgbm8gb25lIGlzIHVzaW5nIERUTFMtb3Zlci1TQ1RQLCBpdCB3b3Vs ZCBiZSBlYXNpZXIganVzdCB0byBzYXkNCg0KPiB0aGF0IERUTFMtb3Zlci1TQ1RQIGlzIG5vdCBz dXBwb3J0ZWQuDQoNCioqSWYqKiB3ZSBkZWNpZGUgdG8ga2VlcCBEVExTLW92ZXItU0NUUCBpbiB0 aGUgZHJhZnQsIG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gc2F5IHRoYXQg4oCcRFRMUyBwcmVz ZXJ2YXRpb24gb3ZlciB0cmFuc3BvcnQgY2hhbmdl4oCdIGRvZXMgbm90IGFwcGx5IHRvIERUTFMt b3Zlci1TQ1RQLCB3aXRoIGEgcmVmZXJlbmNlIHRvIFJGQyA2MDgzLg0KDQpUaGVuLCBpZiBzb21l b25lIGF0IHNvbWUgcG9pbnQgdXBkYXRlcyBSRkMgNjA4MywgdGhlIFNDVFAtU0RQIHNwZWMgYWxz byBoYXMgdG8gYmUgdXBkYXRlZC4NCg0KSSBkbyBOT1Qgd2FudCB0byBkZWxheSBkcmFmdC1zY3Rw LXNkcCB1bnRpbCBhIHBvc3NpYmxlIFJGQyA2MDgzIHVwZGF0ZSBoYXMgYmVlbiBkb25lIChhc3N1 bWluZyBwZW9wbGUgd291bGQgYWdyZWUgdG8gZG8gaXQgaW4gdGhlIGZpcnN0IHBsYWNlKS4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpP biBNb24sIEZlYiA4LCAyMDE2IGF0IDEwOjEyIEFNLCBTY2h3YXJ6LCBBbGJyZWNodCAoTm9raWEg LSBERSkgPGFsYnJlY2h0LnNjaHdhcnpAbm9raWEuY29tIDxtYWlsdG86YWxicmVjaHQuc2Nod2Fy ekBub2tpYS5jb20+PiB3cm90ZToNCg0KwqAgwqAgSGVsbG8gQ2hyaXN0ZXIsDQoNCsKgIMKgIHRo ZSB0aXRlbCBvZiB0aGUgKGZ1dHVyZSkgUkZDIHdpbGwgbm90IGV4Y2x1ZGUgYW55IFNDVFAgdHJh bnNwb3J0DQrCoCDCoCBtb2Rlcy4NCg0KwqAgwqAgQW5kIGEgY29tcHJlaGVuc2l2ZSBhbmQgZnV0 dXJlIHNhZmUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBzaG91bGQNCsKgIMKgIGNvdmVyIGFsbCBl eGlzdGluZyBvbmVzLCB3aGljaCBpcyDigJxEVExTL1NDVFAvSVDigJ0gYXMgd2VsbCBhcw0KwqAg wqAg4oCcU0NUUC9VRFAvSVDigJ0gKFJGQyA2OTUxKS4NCg0KwqAgwqAgVGhlc2UgdHdvIFNDVFAg dHJhbnNwb3J0IG1vZGVzIHNob3VsZCBiZSBpbmRpY2F0ZWQgYXMgd2VsbCwNCsKgIMKgIGluZGVw ZW5kZW50IG9mIHBvdGVudGlhbCBpbnRlbnRpb25zIHRvIGJlIHVzZWQgc29vbi4NCg0KwqAgwqAg Q29kZXBvaW50IHNwYWNlIGNvdWxkIGJlIHJlc2VydmVkLCBwbGFjZWhvbGRlciBzZWN0aW9ucyB0 YWdnZWQgYXMNCsKgIMKgIOKAnG5vdCB5ZXQgc3VwcG9ydGVk4oCdIG9mIOKAnGZvciBmdXJ0aGVy IHN0dWRpZXPigJ0sIGV0YywgYnV0IHRoZSB3b3JzdA0KwqAgwqAgY2FzZSB3b3VsZCBiZSBhbnkg a2luZCBvZiBpbnRlcmFjdGlvbiBpc3N1ZXMgaW4gZnV0dXJlLg0KDQrCoCDCoCBNeSB2aWV3LA0K DQrCoCDCoCBBbGJyZWNodA0KDQrCoCDCoCAqRnJvbToqbW11c2ljIFttYWlsdG86bW11c2ljLWJv dW5jZXNAaWV0Zi5vcmcNCsKgIMKgIDxtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc+XSAq T24gQmVoYWxmIE9mICpFWFQgQ2hyaXN0ZXIgSG9sbWJlcmcNCsKgIMKgICpTZW50OiogTW9udGFn LCA4LiBGZWJydWFyIDIwMTYgMTU6MzMNCsKgIMKgICpUbzoqIG1tdXNpYyA8bW11c2ljQGlldGYu b3JnIDxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NCsKgIMKgICpTdWJqZWN0OiogW01NVVNJQ10g RFRMUy1vdmVyLVNDVFAsIGFueW9uZT8NCg0KwqAgwqAgSGksDQoNCsKgIMKgIGRyYWZ0LWlldGYt bW11c2ljLXNjdHAtc2RwIGN1cnJlbnRseSBkZWZpbmVzIHRoZSBTRFAgTy9BDQrCoCDCoCBwcm9j ZWR1cmVzIGZvciBTQ1RQLCBTQ1RQLW92ZXItRFRMUywgYW5kIERUTFMtb3Zlci1TQ1RQLg0KDQrC oCDCoCBBcyB3ZSBrbm93LCBTQ1RQLW92ZXItRFRMUyBpcyB1c2VkIGZvciB0aGUgV2ViUlRDIGRh dGEgY2hhbm5lbC4NCg0KwqAgwqAgTXkgcXVlc3Rpb24gaXM6IGRvZXMgYW55b25lIGludGVuZCB0 byB1c2UgRFRMUy1vdmVyLVNDVFA/DQoNCsKgIMKgIFJlZ2FyZHMsDQoNCsKgIMKgIENocmlzdGVy DQoNCg0KwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCsKgIMKgIG1tdXNpYyBtYWlsaW5nIGxpc3QNCsKgIMKgIG1tdXNpY0BpZXRmLm9yZyA8bWFp bHRvOm1tdXNpY0BpZXRmLm9yZz4NCsKgIMKgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0K bW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t dXNpYw0KDQo= From nobody Wed Feb 10 11:35: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 D739A1B2F07 for ; Wed, 10 Feb 2016 11:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 mOZoT6YGWKi5 for ; Wed, 10 Feb 2016 11:34:59 -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 85CBC1B2F05 for ; Wed, 10 Feb 2016 11:34:59 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g203so6986654iof.2 for ; Wed, 10 Feb 2016 11:34: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=VCKNLPGk0WBnWBnrZCq/Z505OjB7kBoccw9Ba2KQs88=; b=CjZdbEQ8WzAYTy6EO2yMgEdk6qfNyKLJSLIMW4IvDJXQswaAvNTaz+IWhJ50P/sUFU IGuLjjNeFz1SL7gIQv/Yn/3QC2Wb+IVXb/59JiDvEFLPrzuC+mGAO43AsqxfsxMYm6Ke 5qJJFpcoj/dHKVkmgxVggRpj32vihGBGZ/0K5qw5vQCrx13lAw73mcgDmtNnajbsieM8 FyCQkkAtHTuAZSJQfDTaG9akK+KRZJZ/38fL39ftfcR0GVvAoQptZIaW8os09H2LVAaw ADQVWx8LVPwFeiBQiZOiQU7yzWWi/yt/qWyIVuYI0m+OO9q5BtU8LGsaa8VcLfJRMFI+ faPg== 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=VCKNLPGk0WBnWBnrZCq/Z505OjB7kBoccw9Ba2KQs88=; b=Cmghu2fbGizadp95K/E8eREpqrROXBJ/U9MER+HqOyJm+sdlKrT7JNAH5owmnRHP69 JUAT5dxHcVwNYLVLyiQMVzCUE3I5UEeq4AuhZmN9ByBhknVc/U0NQuZkGdXp47Rc14JR /yBwvpUo2wKGgQ1ZX1ZsDp/TBF0XNCSbqvBcY/w98mxYC7evvl2OlVi8cpXaf6hne9Ch XBzBUsQGc8QgA2F9F49ZHCxvFJP6tR7fMXUuv+NYbk2fmanUX8cbqmgjGfNLCiguq7HM UOUK5vE6zXGy2gO53y2ZRncvUJkWAYiqiJcjMtUPp9VSt95upGpFK7cCoPRs2rackm3t JkaQ== X-Gm-Message-State: AG10YOR/Uz1hebaoELUy+gxhj9aiRwvoGCce/YLtngT61TB2gSOk00b3EMEsqbu6QrENiQ== X-Received: by 10.107.128.75 with SMTP id b72mr37114014iod.87.1455132898872; Wed, 10 Feb 2016 11:34:58 -0800 (PST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id 186sm2392743iof.22.2016.02.10.11.34.57 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 11:34:57 -0800 (PST) Received: by mail-io0-f172.google.com with SMTP id 9so32498952iom.1 for ; Wed, 10 Feb 2016 11:34:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr37215925ioe.38.1455132896703; Wed, 10 Feb 2016 11:34:56 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 10 Feb 2016 11:34:56 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> Date: Wed, 10 Feb 2016 14:34:56 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b47268e6ce052b6f875a Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 10 Feb 2016 19:35:01 -0000 --001a1140b47268e6ce052b6f875a Content-Type: text/plain; charset=UTF-8 Hi Christer, On Wed, Feb 10, 2016 at 5:29 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Roman, > > > I think we can add the following to section 7.1 of dtls-sdp: > > > > If DTLS is transmitted over a reliable transport and if DTLS procedures > for retransmissions are not used, for instance as described in > > RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span across > multiple transports. Using 'dtls-connection' attribute with > > an 'existing' value in combination with change of such a reliable > transport should be treated as an error and DTLS association MUST be > > terminated. > > Your text as such looks ok. But, do we really want to add it as a generic > restriction in draft-dtls-sdp? Shouldn't it be specific for DTLS-over-SCTP > instead? What if someone defines DTLS-over- > and they DO allow span? > > The reason multiple DTLS associations cannot span across several SCTP association is due to SCTP association handling DTLS packet retransmission and DTLS procedures for retransmissions not being used. We can make a generic statement or limit this to RFC 6083 only, but I think, stating the reason why DTLS association cannot span multiple transports is important. _____________ Roman Shpount --001a1140b47268e6ce052b6f875a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christer,

On Wed, Feb 10, 2016 at 5:29 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Roman,

> I think we can add the following to section 7.1 of dtls-sdp:
>
> If DTLS is transmitted over a reliable transport and if DTLS procedure= s for retransmissions are not used, for instance as described in
> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span acros= s multiple transports. Using 'dtls-connection' attribute with
> an 'existing' value in combination with change of such a relia= ble transport should be treated as an error and DTLS association MUST be > terminated.

Your text as such looks ok. But, do we really want to add it as a ge= neric restriction in draft-dtls-sdp? Shouldn't it be specific for DTLS-= over-SCTP instead? What if someone defines DTLS-over-<new-fancy-reliable= -transport> and they DO allow span?


The reason multiple DTLS associations cannot span across several SC= TP association is due to SCTP association handling DTLS packet retransmissi= on and DTLS procedures for retransmissions not being used. We can make a ge= neric statement or limit this to RFC 6083 only, but I think, stating the re= ason why DTLS association cannot span multiple transports is important.
_____________
Roman Shpount
<= /div>
=C2=A0
--001a1140b47268e6ce052b6f875a-- From nobody Wed Feb 10 11:59: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 D70821B2F0C for ; Wed, 10 Feb 2016 11:58:58 -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 01K3tWOiXvyK for ; Wed, 10 Feb 2016 11:58:57 -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 2ED611ACF02 for ; Wed, 10 Feb 2016 11:58:57 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-68-56bb967f5fce Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.EA.30208.F769BB65; Wed, 10 Feb 2016 20:58:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Wed, 10 Feb 2016 20:58:55 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAADlkIAACsv+IAAJBDYAAC5fwgAAF9Un8AARBt4AAALZElA= Date: Wed, 10 Feb 2016 19:58:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DCDC6C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbE9RLd+2u4wg7tfZS2mLn/MYjHjwlRm ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAlXFl0yP2gil8Ff/a1jM2MD7h7WLk5JAQMJHY 8qqDFcIWk7hwbz1bFyMXh5DAYUaJ5f8fskI4Sxglzn3tZ+5i5OBgE7CQ6P6nDdIgIqAq8ff7 ZCaQMLOAusTVxUEgYWEBXYlrrWeYIEr0JCbsb2GEsJMk1vz7xQ5iswC1zn19mRnE5hXwlTg7 cwfUqvksEm/ePAZr4BQIlFi9/z7YIEag476fWgNmMwuIS9x6Mp8J4mgBiSV7zjND2KISLx// g3pGSWLt4e0sELdpSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUm4Vk6iyEjllIOmYh6VjAyLKK UbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzByDm75rbqD8fIbx0OMAhyMSjy8Gzp2hwmxJpYV V+YeYpTgYFYS4VWoBQrxpiRWVqUW5ccXleakFh9ilOZgURLnXeO8PkxIID2xJDU7NbUgtQgm y8TBKdXA6Owp9UO8bhvj3sRTUZWHSg/J18wTn1K12j/q8r7pnwL5YoQt35+Zf8PEOfKaoddG e+Ulpopy2q06Z7We6BxwnGNScEf4/Y4e/4cXYqXrmKa7XAzetC1H3Nr7UOX0ptXROj8WiGjV RWek1n5kmBwWkX//QtFmXsVfuybz8Fdzve0ts/tTf7FJiaU4I9FQi7moOBEAlFu46pgCAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 10 Feb 2016 19:58:59 -0000 SGksDQoNCj4+PiBJIHRoaW5rIHdlIGNhbiBhZGQgdGhlIGZvbGxvd2luZyB0byBzZWN0aW9uIDcu MSBvZiBkdGxzLXNkcDoNCj4+Pg0KPj4+IElmIERUTFMgaXMgdHJhbnNtaXR0ZWQgb3ZlciBhIHJl bGlhYmxlIHRyYW5zcG9ydCBhbmQgaWYgRFRMUyBwcm9jZWR1cmVzIGZvciByZXRyYW5zbWlzc2lv bnMgYXJlIG5vdCB1c2VkLCBmb3IgaW5zdGFuY2UgYXMgZGVzY3JpYmVkIGluDQo+Pj4gUkZDIDYw ODMgZm9yIERUTFMgb3ZlciBTQ1RQLCB0aGVuIERUTFMgYXNzb2NpYXRpb24gTVVTVCBOT1Qgc3Bh biBhY3Jvc3MgbXVsdGlwbGUgdHJhbnNwb3J0cy4gVXNpbmcgJ2R0bHMtY29ubmVjdGlvbicgYXR0 cmlidXRlIHdpdGgNCj4+PiBhbiAnZXhpc3RpbmcnIHZhbHVlIGluIGNvbWJpbmF0aW9uIHdpdGgg Y2hhbmdlIG9mIHN1Y2ggYSByZWxpYWJsZSB0cmFuc3BvcnQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMg YW4gZXJyb3IgYW5kIERUTFMgYXNzb2NpYXRpb24gTVVTVCBiZQ0KPj4+IHRlcm1pbmF0ZWQuDQo+ Pg0KPj4gWW91ciB0ZXh0IGFzIHN1Y2ggbG9va3Mgb2suIEJ1dCwgZG8gd2UgcmVhbGx5IHdhbnQg dG8gYWRkIGl0IGFzIGEgZ2VuZXJpYyByZXN0cmljdGlvbiBpbiBkcmFmdC1kdGxzLXNkcD8gU2hv dWxkbid0IGl0IGJlDQo+PiBzcGVjaWZpYyBmb3IgRFRMUy1vdmVyLVNDVFAgaW5zdGVhZD8gV2hh dCBpZiBzb21lb25lIGRlZmluZXMgRFRMUy1vdmVyLTxuZXctZmFuY3ktcmVsaWFibGUtdHJhbnNw b3J0PiBhbmQgdGhleSBETyBhbGxvdyBzcGFuPw0KPg0KPiBUaGUgcmVhc29uIG11bHRpcGxlIERU TFMgYXNzb2NpYXRpb25zIGNhbm5vdCBzcGFuIGFjcm9zcyBzZXZlcmFsIFNDVFAgYXNzb2NpYXRp b24gaXMgZHVlIHRvIFNDVFAgYXNzb2NpYXRpb24gaGFuZGxpbmcgRFRMUyBwYWNrZXQgDQo+IHJl dHJhbnNtaXNzaW9uIGFuZCBEVExTIHByb2NlZHVyZXMgZm9yIHJldHJhbnNtaXNzaW9ucyBub3Qg YmVpbmcgdXNlZC4gV2UgY2FuIG1ha2UgYSBnZW5lcmljIHN0YXRlbWVudCBvciBsaW1pdCB0aGlz IHRvIFJGQyA2MDgzIA0KPiBvbmx5LCBidXQgSSB0aGluaywgc3RhdGluZyB0aGUgcmVhc29uIHdo eSBEVExTIGFzc29jaWF0aW9uIGNhbm5vdCBzcGFuIG11bHRpcGxlIHRyYW5zcG9ydHMgaXMgaW1w b3J0YW50Lg0KDQpJIGFncmVlLg0KDQpCdXQsIGFnYWluIERUTFMtb3Zlci1TQ1RQIGlzIGRlc2Ny aWJlZCBpbiBkcmFmdC1zY3RwLXNkcCwgc28gSSB0aGluayBzdWNoIHRleHQgYmVsb25ncyB0aGVy ZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNo cG91bnQNCsKgDQo= From nobody Wed Feb 10 12:41: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 55FDA1B2FA6 for ; Wed, 10 Feb 2016 12:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 yhcY7j33btdp for ; Wed, 10 Feb 2016 12:41:48 -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 DC92B1B2F9F for ; Wed, 10 Feb 2016 12:41:47 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id l127so34293504iof.3 for ; Wed, 10 Feb 2016 12:41:47 -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=Int7DLLY3KzgsfTrOBAXqIzPGb4+563CGa+9KTCWcg4=; b=2QdNGsQiqw/EnxeItEO9xkj20s7snFDhe9wSxvNvqZZsXIXVB6zRsjhGM9c1OXnpL2 o9efc3H6wNSekRoD6bhYPLx6T946sgJmQK1sD6Nqner6w29qgPZSniZYD8O6KsxMirVU HMci5wZJCDl24NpnbB/p5vmCSd14mMO8XgZOcT0//AgjdDD/9LEp/iVWWfU6+H97yM+0 pTpwTu+qTf4ItG7f4jjJdhEhK1wfo8Xvbi9KC6z3FggVicOPyY5HWib4NdvKFZgASfb/ aEOhSSC55y6mwAzzrhhYf5RM+BG8OnmMNlNi8FrZD0zev0F8jvsGYkj7KOl56TCB3hvg TsMQ== 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=Int7DLLY3KzgsfTrOBAXqIzPGb4+563CGa+9KTCWcg4=; b=A7u7stpkru98tIUp2K8ZnwSRDieQHXl4AyqOeUrqwZtdTJu3PXCeCLUtnlMlwkUNIK 7OI6b7DnpyFp/FuyeD/TwAxtACSBALLXLv3Q96gbEpG9O5GA/DT9LksbcxHfzdkBdi4Y HW61Opyz/ANcd9pC7/2nuHzukKG2VrVUNXcU8bFv8is9MvubYHiR0fGZvPnozDWzSxb5 J/o4ZPolgmIACudskgzRNo2XeqA//J8r896YxSl5Bd1wv4x7qmDbg4nuJrOOWVXZr8+C 9ttThr/aKAEH3T7frxk8o5AG4vV6OD4jwM1wEBs/f7uPBI3gdVPWfyByXI08CYE16Ky0 bNrg== X-Gm-Message-State: AG10YOTN4O7Yr7NrsiSKY5t+ZInCxS66AeyGbBF7ixaXa8QtnvQni/vKcsxP5DSSUlEj0w== X-Received: by 10.107.155.146 with SMTP id d140mr39025407ioe.92.1455136907274; Wed, 10 Feb 2016 12:41:47 -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 n3sm2484761igr.17.2016.02.10.12.41.45 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 12:41:45 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id 9so34416935iom.1 for ; Wed, 10 Feb 2016 12:41:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr37488013ioe.38.1455136904973; Wed, 10 Feb 2016 12:41:44 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 10 Feb 2016 12:41:44 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DCDC6C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCDC6C@ESESSMB209.ericsson.se> Date: Wed, 10 Feb 2016 15:41:44 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b472521cc2052b7076f3 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 10 Feb 2016 20:41:49 -0000 --001a1140b472521cc2052b7076f3 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 10, 2016 at 2:58 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >>> I think we can add the following to section 7.1 of dtls-sdp: > >>> > >>> If DTLS is transmitted over a reliable transport and if DTLS > procedures for retransmissions are not used, for instance as described in > >>> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span > across multiple transports. Using 'dtls-connection' attribute with > >>> an 'existing' value in combination with change of such a reliable > transport should be treated as an error and DTLS association MUST be > >>> terminated. > >> > >> Your text as such looks ok. But, do we really want to add it as a > generic restriction in draft-dtls-sdp? Shouldn't it be > >> specific for DTLS-over-SCTP instead? What if someone defines > DTLS-over- and they DO allow span? > > > > The reason multiple DTLS associations cannot span across several SCTP > association is due to SCTP association handling DTLS packet > > retransmission and DTLS procedures for retransmissions not being used. > We can make a generic statement or limit this to RFC 6083 > > only, but I think, stating the reason why DTLS association cannot span > multiple transports is important. > > I agree. > > But, again DTLS-over-SCTP is described in draft-sctp-sdp, so I think such > text belongs there. > > How about saying the following in draft-dtls-sdp: If DTLS is transmitted over a transport that prohibits spanning of DTLS association across multiple transports, such as DTLS over SCTP as described in RFC 6083, then 'dtls-connection' attribute MUST be set to 'new' every time transport is changed. And you can put the previous language in draft-sctp-sdp This way each draft only specified things relevant to itself. Regards, _____________ Roman Shpount --001a1140b472521cc2052b7076f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 10, 2016 at 2:5= 8 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
>>> I think = we can add the following to section 7.1 of dtls-sdp:
>>>
>>> If DTLS is transmitted over a reliable transport and if DTLS p= rocedures for retransmissions are not used, for instance as described in >>> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT sp= an across multiple transports. Using 'dtls-connection' attribute wi= th
>>> an 'existing' value in combination with change of such= a reliable transport should be treated as an error and DTLS association MU= ST be
>>> terminated.
>>
>> Your text as such looks ok. But, do we really want to add it as a = generic restriction in draft-dtls-sdp? Shouldn't it be
>> specific for DTLS-over-SCTP instead? What if someone defines DTLS-= over-<new-fancy-reliable-transport> and they DO allow span?
>
> The reason multiple DTLS associations cannot span across several SCTP = association is due to SCTP association handling DTLS packet
> retransmission and DTLS procedures for retransmissions not being used.= We can make a generic statement or limit this to RFC 6083
> only, but I think, stating the reason why DTLS association cannot span= multiple transports is important.

I agree.

But, again DTLS-over-SCTP is described in draft-sctp-sdp, so I think such t= ext belongs there.


How about saying the following in draft-dtls-sdp:

If DTLS is transmitted over a transport that prohibits spanning of = DTLS association across multiple transports, such as DTLS over SCTP as desc= ribed in RFC 6083, then 'dtls-connection' attribute MUST be set to = 'new' every time transport is changed.=C2=A0

And you can put the previous language in draft-sctp-sdp

This way each draft only specified things relevant to itself.

Regards,
____= _________
Roman Shpount
=C2=A0
--001a1140b472521cc2052b7076f3-- From nobody Wed Feb 10 13:01: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 4E8C41B2FE0 for ; Wed, 10 Feb 2016 13:01:09 -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 NCo4caYsH88t for ; Wed, 10 Feb 2016 13:01:08 -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 EA5FA1B2FE6 for ; Wed, 10 Feb 2016 13:01:06 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with comcast id Gl0k1s0032Udklx01l16lT; Wed, 10 Feb 2016 21:01:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id Gl151s00h3KdFy101l156z; Wed, 10 Feb 2016 21:01:06 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@ESESSMB209.ericsson.se> <56B8C271.5000101@cisco.com> From: Paul Kyzivat Message-ID: <56BBA510.2070902@alum.mit.edu> Date: Wed, 10 Feb 2016 16:01:04 -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: <56B8C271.5000101@cisco.com> 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=1455138066; bh=lxaYZnTBOpcXXJ5TWdnGWiOyyI1bYg6vfbINfVCll2w=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=RswXnF3V3aWeeqi82otUPPKJflXfMCwihPn/CwKAh7pWBfqvPQmfp+ctX2wdc9s22 Ot8r7pIWlQLRPFKaLJTE3tGdKzuKxKpxfOE704nfQLh1+bEqopg9CVp7E2W7Zqn8H8 Ea4Ns4WHFqxykv28Y8SbfEDbDdlWyVhQkUOloVmzE/qJl/N6FoZ1QPU+6z8Es+gbWK iQjwDpxtaqgRHF/SFpneVtkyOnTcb0XNIKhz64Gyj7gaMAn10XIieKUEBOhHmbxRiX yOjIajrDk4vbjYAmdsX/mKhKev5zo8lECCyX+iQeKzeeOsVa1yIfWYZCAm+hTsE82d Z6atYxaURYtVQ== Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-01 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, 10 Feb 2016 21:01:09 -0000 On 2/8/16 11:29 AM, Flemming Andreasen wrote: > Folks, > > Please take a look at the draft and let us know if you think it is ready > (or not) for WGLC at this point. IMO this draft is ready for WGLC. Thanks, Paul > Thanks > > -- Flemming (MMUSIC co-chair). > > On 2/6/16 6:02 AM, Christer Holmberg wrote: >> >> Hi, >> >> Ive submitted a new version (-01) of draft-mux-exclusive. >> >> The main difference compared to the previous version is that the draft >> now defines a new SDP attribute, rtcp-mux-exclusive, to indicate >> exclusive support of, and negotiate usage of, RTP/RTCP multiplexing. >> >> There are currently no open issues in the draft, so I encourage people >> to take a look, so that we can start moving towards WGLC. >> >> 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 Feb 10 23:09:35 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 3314A1A916D for ; Wed, 10 Feb 2016 23:09:34 -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 4i8_E3ZHQVv0 for ; Wed, 10 Feb 2016 23:09:32 -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 892F71A916B for ; Wed, 10 Feb 2016 23:09:31 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-65-56bc33a9cb59 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 39.2F.05690.9A33CB65; Thu, 11 Feb 2016 08:09:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Thu, 11 Feb 2016 08:09:28 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAADlkIAACsv+IAAJBDYAAC5fwgAAF9Un8AARBt4AAALZElD///vhAP//QAqQ Date: Thu, 11 Feb 2016 07:09:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DCE497@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCDC6C@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.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DCE497ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7ou5K4z1hBrd/yFlMXf6YxWLGhanM DkweS5b8ZPK4NaUggCmKyyYlNSezLLVI3y6BK2NK+3HmgmUJFd8P3mVrYLwS28XIySEhYCKx du1ONghbTOLCvfVANheHkMBhRolN/QegnCWMEnemnmHpYuTgYBOwkOj+pw3SICKgKvH3+2Qm kDCzgLrE1cVBIGFhAV2Ja61nmCBK9CQm7G9hhLDzJG6/uAW2iwWodfrXzWATeQV8JY79lobY tIpVYvqPxWAjOQUCJV7MdAUpZwQ67fupNWAjmQXEJW49mc8EcbKAxJI955khbFGJl4//sULY ShI/NlxigbgsX2L2ZRmQMK+AoMTJmU9YJjCKzkIyaRZC1SwkVRBhTYn1u/QhqhUlpnQ/ZIew NSRa58xlRxZfwMi+ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwxg5u+a27g3H1a8dDjAIc jEo8vBs6docJsSaWFVfmHmKU4GBWEuHd8RgoxJuSWFmVWpQfX1Sak1p8iFGag0VJnHeN8/ow IYH0xJLU7NTUgtQimCwTB6dUA+OayCi964UWk9cXKjDqrm7+r5/efKQg4UEP59UPkrZOFe+L zYvrnsy2T1xwwNr8Alvdi/Nu+uk3Wk7ZRor77mdax3OzpmBvcpXiSR+vbJaM6T/meT5eN/+B 3GWv08n2ueIZb+7q1C7QlhK5+lPk0tst/aZbz5rdWsj/qUB8esf2A2wKrS/cDiqxFGckGmox FxUnAgADboGorQIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 11 Feb 2016 07:09:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DCE497ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCllvdXIgc3VnZ2VzdGlvbiBsb29rcyBnb29kLiBJ4oCZbGwgdGFrZSBpdCBh cyBhIFdHTEMgY29tbWVudCwgYW5kIGFkZCBpdCBpbiB0aGUgcG9zdC1XR0xDIHZlcnNpb24gb2Yg dGhlIGRyYWZ0IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNocG91 bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDEwLiBoZWxtaWt1dXRhIDIwMTYg MjI6NDINClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IG1tdXNpY0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtNTVVTSUNdIERUTFMtb3Zlci1TQ1RQLCBhbnlvbmU/DQoNCg0KT24gV2VkLCBGZWIg MTAsIDIwMTYgYXQgMjo1OCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3Jv dGU6DQo+Pj4gSSB0aGluayB3ZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcgdG8gc2VjdGlvbiA3LjEg b2YgZHRscy1zZHA6DQo+Pj4NCj4+PiBJZiBEVExTIGlzIHRyYW5zbWl0dGVkIG92ZXIgYSByZWxp YWJsZSB0cmFuc3BvcnQgYW5kIGlmIERUTFMgcHJvY2VkdXJlcyBmb3IgcmV0cmFuc21pc3Npb25z IGFyZSBub3QgdXNlZCwgZm9yIGluc3RhbmNlIGFzIGRlc2NyaWJlZCBpbg0KPj4+IFJGQyA2MDgz IGZvciBEVExTIG92ZXIgU0NUUCwgdGhlbiBEVExTIGFzc29jaWF0aW9uIE1VU1QgTk9UIHNwYW4g YWNyb3NzIG11bHRpcGxlIHRyYW5zcG9ydHMuIFVzaW5nICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJp YnV0ZSB3aXRoDQo+Pj4gYW4gJ2V4aXN0aW5nJyB2YWx1ZSBpbiBjb21iaW5hdGlvbiB3aXRoIGNo YW5nZSBvZiBzdWNoIGEgcmVsaWFibGUgdHJhbnNwb3J0IHNob3VsZCBiZSB0cmVhdGVkIGFzIGFu IGVycm9yIGFuZCBEVExTIGFzc29jaWF0aW9uIE1VU1QgYmUNCj4+PiB0ZXJtaW5hdGVkLg0KPj4N Cj4+IFlvdXIgdGV4dCBhcyBzdWNoIGxvb2tzIG9rLiBCdXQsIGRvIHdlIHJlYWxseSB3YW50IHRv IGFkZCBpdCBhcyBhIGdlbmVyaWMgcmVzdHJpY3Rpb24gaW4gZHJhZnQtZHRscy1zZHA/IFNob3Vs ZG4ndCBpdCBiZQ0KPj4gc3BlY2lmaWMgZm9yIERUTFMtb3Zlci1TQ1RQIGluc3RlYWQ/IFdoYXQg aWYgc29tZW9uZSBkZWZpbmVzIERUTFMtb3Zlci08bmV3LWZhbmN5LXJlbGlhYmxlLXRyYW5zcG9y dD4gYW5kIHRoZXkgRE8gYWxsb3cgc3Bhbj8NCj4NCj4gVGhlIHJlYXNvbiBtdWx0aXBsZSBEVExT IGFzc29jaWF0aW9ucyBjYW5ub3Qgc3BhbiBhY3Jvc3Mgc2V2ZXJhbCBTQ1RQIGFzc29jaWF0aW9u IGlzIGR1ZSB0byBTQ1RQIGFzc29jaWF0aW9uIGhhbmRsaW5nIERUTFMgcGFja2V0DQo+IHJldHJh bnNtaXNzaW9uIGFuZCBEVExTIHByb2NlZHVyZXMgZm9yIHJldHJhbnNtaXNzaW9ucyBub3QgYmVp bmcgdXNlZC4gV2UgY2FuIG1ha2UgYSBnZW5lcmljIHN0YXRlbWVudCBvciBsaW1pdCB0aGlzIHRv IFJGQyA2MDgzDQo+IG9ubHksIGJ1dCBJIHRoaW5rLCBzdGF0aW5nIHRoZSByZWFzb24gd2h5IERU TFMgYXNzb2NpYXRpb24gY2Fubm90IHNwYW4gbXVsdGlwbGUgdHJhbnNwb3J0cyBpcyBpbXBvcnRh bnQuDQoNCkkgYWdyZWUuDQoNCkJ1dCwgYWdhaW4gRFRMUy1vdmVyLVNDVFAgaXMgZGVzY3JpYmVk IGluIGRyYWZ0LXNjdHAtc2RwLCBzbyBJIHRoaW5rIHN1Y2ggdGV4dCBiZWxvbmdzIHRoZXJlLg0K DQoNCkhvdyBhYm91dCBzYXlpbmcgdGhlIGZvbGxvd2luZyBpbiBkcmFmdC1kdGxzLXNkcDoNCg0K SWYgRFRMUyBpcyB0cmFuc21pdHRlZCBvdmVyIGEgdHJhbnNwb3J0IHRoYXQgcHJvaGliaXRzIHNw YW5uaW5nIG9mIERUTFMgYXNzb2NpYXRpb24gYWNyb3NzIG11bHRpcGxlIHRyYW5zcG9ydHMsIHN1 Y2ggYXMgRFRMUyBvdmVyIFNDVFAgYXMgZGVzY3JpYmVkIGluIFJGQyA2MDgzLCB0aGVuICdkdGxz LWNvbm5lY3Rpb24nIGF0dHJpYnV0ZSBNVVNUIGJlIHNldCB0byAnbmV3JyBldmVyeSB0aW1lIHRy YW5zcG9ydCBpcyBjaGFuZ2VkLg0KDQpBbmQgeW91IGNhbiBwdXQgdGhlIHByZXZpb3VzIGxhbmd1 YWdlIGluIGRyYWZ0LXNjdHAtc2RwDQoNClRoaXMgd2F5IGVhY2ggZHJhZnQgb25seSBzcGVjaWZp ZWQgdGhpbmdzIHJlbGV2YW50IHRvIGl0c2VsZi4NCg0KUmVnYXJkcywNCl9fX19fX19fX19fX18N ClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37DCE497ESESSMB209erics_ 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 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb21hbiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91ciBzdWdnZXN0aW9uIGxvb2tzIGdvb2QuIEnigJlsbCB0 YWtlIGl0IGFzIGEgV0dMQyBjb21tZW50LCBhbmQgYWRkIGl0IGluIHRoZSBwb3N0LVdHTEMgdmVy c2lvbiBvZiB0aGUgZHJhZnQgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4 LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMC4gaGVsbWlrdXV0YSAyMDE2IDIyOjQyPGJyPg0K PGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gbW11c2ljQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBEVExTLW92ZXItU0NUUCwgYW55 b25lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxMCwgMjAxNiBhdCAyOjU4IFBNLCBDaHJpc3Rl ciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsm Z3Q7IEkgdGhpbmsgd2UgY2FuIGFkZCB0aGUgZm9sbG93aW5nIHRvIHNlY3Rpb24gNy4xIG9mIGR0 bHMtc2RwOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJZiBEVExTIGlzIHRy YW5zbWl0dGVkIG92ZXIgYSByZWxpYWJsZSB0cmFuc3BvcnQgYW5kIGlmIERUTFMgcHJvY2VkdXJl cyBmb3IgcmV0cmFuc21pc3Npb25zIGFyZSBub3QgdXNlZCwgZm9yIGluc3RhbmNlIGFzIGRlc2Ny aWJlZCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyBSRkMgNjA4MyBmb3IgRFRMUyBvdmVyIFNDVFAsIHRo ZW4gRFRMUyBhc3NvY2lhdGlvbiBNVVNUIE5PVCBzcGFuIGFjcm9zcyBtdWx0aXBsZSB0cmFuc3Bv cnRzLiBVc2luZyAnZHRscy1jb25uZWN0aW9uJyBhdHRyaWJ1dGUgd2l0aDxicj4NCiZndDsmZ3Q7 Jmd0OyBhbiAnZXhpc3RpbmcnIHZhbHVlIGluIGNvbWJpbmF0aW9uIHdpdGggY2hhbmdlIG9mIHN1 Y2ggYSByZWxpYWJsZSB0cmFuc3BvcnQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYW4gZXJyb3IgYW5k IERUTFMgYXNzb2NpYXRpb24gTVVTVCBiZTxicj4NCiZndDsmZ3Q7Jmd0OyB0ZXJtaW5hdGVkLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWW91ciB0ZXh0IGFzIHN1Y2ggbG9va3Mgb2suIEJ1 dCwgZG8gd2UgcmVhbGx5IHdhbnQgdG8gYWRkIGl0IGFzIGEgZ2VuZXJpYyByZXN0cmljdGlvbiBp biBkcmFmdC1kdGxzLXNkcD8gU2hvdWxkbid0IGl0IGJlPGJyPg0KJmd0OyZndDsgc3BlY2lmaWMg Zm9yIERUTFMtb3Zlci1TQ1RQIGluc3RlYWQ/IFdoYXQgaWYgc29tZW9uZSBkZWZpbmVzIERUTFMt b3Zlci0mbHQ7bmV3LWZhbmN5LXJlbGlhYmxlLXRyYW5zcG9ydCZndDsgYW5kIHRoZXkgRE8gYWxs b3cgc3Bhbj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgcmVhc29uIG11bHRpcGxlIERUTFMgYXNz b2NpYXRpb25zIGNhbm5vdCBzcGFuIGFjcm9zcyBzZXZlcmFsIFNDVFAgYXNzb2NpYXRpb24gaXMg ZHVlIHRvIFNDVFAgYXNzb2NpYXRpb24gaGFuZGxpbmcgRFRMUyBwYWNrZXQ8YnI+DQomZ3Q7IHJl dHJhbnNtaXNzaW9uIGFuZCBEVExTIHByb2NlZHVyZXMgZm9yIHJldHJhbnNtaXNzaW9ucyBub3Qg YmVpbmcgdXNlZC4gV2UgY2FuIG1ha2UgYSBnZW5lcmljIHN0YXRlbWVudCBvciBsaW1pdCB0aGlz IHRvIFJGQyA2MDgzPGJyPg0KJmd0OyBvbmx5LCBidXQgSSB0aGluaywgc3RhdGluZyB0aGUgcmVh c29uIHdoeSBEVExTIGFzc29jaWF0aW9uIGNhbm5vdCBzcGFuIG11bHRpcGxlIHRyYW5zcG9ydHMg aXMgaW1wb3J0YW50Ljxicj4NCjxicj4NCkkgYWdyZWUuPGJyPg0KPGJyPg0KQnV0LCBhZ2FpbiBE VExTLW92ZXItU0NUUCBpcyBkZXNjcmliZWQgaW4gZHJhZnQtc2N0cC1zZHAsIHNvIEkgdGhpbmsg c3VjaCB0ZXh0IGJlbG9uZ3MgdGhlcmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dCBzYXlpbmcgdGhlIGZvbGxv d2luZyBpbiBkcmFmdC1kdGxzLXNkcDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgRFRMUyBpcyB0cmFuc21pdHRlZCBvdmVyIGEgdHJhbnNw b3J0IHRoYXQgcHJvaGliaXRzIHNwYW5uaW5nIG9mIERUTFMgYXNzb2NpYXRpb24gYWNyb3NzIG11 bHRpcGxlIHRyYW5zcG9ydHMsIHN1Y2ggYXMgRFRMUyBvdmVyIFNDVFAgYXMgZGVzY3JpYmVkIGlu IFJGQyA2MDgzLCB0aGVuICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJpYnV0ZSBNVVNUIGJlIHNldCB0 byAnbmV3JyBldmVyeSB0aW1lIHRyYW5zcG9ydA0KIGlzIGNoYW5nZWQuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB5b3UgY2Fu IHB1dCB0aGUgcHJldmlvdXMgbGFuZ3VhZ2UgaW4gZHJhZnQtc2N0cC1zZHA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3YXkgZWFjaCBk cmFmdCBvbmx5IHNwZWNpZmllZCB0aGluZ3MgcmVsZXZhbnQgdG8gaXRzZWxmLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7594FB04B1934943A5C02806D1A2204B37DCE497ESESSMB209erics_-- From nobody Thu Feb 11 05:06: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 657391B2CA9 for ; Thu, 11 Feb 2016 05:06:07 -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 RXXLyVRbGVsC for ; Thu, 11 Feb 2016 05:06:04 -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 A09A71B2C7C for ; Thu, 11 Feb 2016 05:06:03 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-4b-56bc873942d3 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.C3.20792.9378CB65; Thu, 11 Feb 2016 14:06:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 11 Feb 2016 14:06:01 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAADlkIAACsv+IAAJBDYAAC5fwgAAF9Un8AARBt4AAALZElD///vhAP//QAqQ//4csMA= Date: Thu, 11 Feb 2016 13:06:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DD0027@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCDC6C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCE497@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DCE497@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.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DD0027ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7ma5l+54wg45bphZTlz9msZhxYSqz A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyuh8mlywaTljRc/xtewNjD8WMXYxcnJICJhI fJh4gxXCFpO4cG89G4gtJHCYUeL/dyCbC8hewijx8u50li5GDg42AQuJ7n/aIDUiAqoSf79P ZgIJMwuoS1xdHAQSFhbQlbjWeoYJokRPYsL+FkYIu0ziwpITYONZgFpfzzsLFucV8JVY3rCf HWLVO1aJH0cmsIHM5BTwk3i9OwCkhhHotO+n1oDNZBYQl7j1ZD4TxMkCEkv2nGeGsEUlXj7+ B/WKksSPDZdYIOrzJf583QC1S1Di5MwnLBMYRWchGTULSdksJGWzwD7TlFi/Sx+iRFFiSvdD dghbQ6J1zlx2ZPEFjOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQIj7eCW31Y7GA8+dzzE KMDBqMTDu6Fjd5gQa2JZcWXuIUYJDmYlEV6rsj1hQrwpiZVVqUX58UWlOanFhxilOViUxHnX OK8PExJITyxJzU5NLUgtgskycXBKNTCWb5x35IrJI5twmRifpaFtxZfFl/VssFB++Fr6YbYx 54KbLD/W7ly/pfQYW5JYpPH3TU9Lw24dPDld49mFmSZrLptZrCq24+s3n1ztv+LQvXXu8/xe Tdi1cUL2DpHj6RdEDu64EfGv/VDkT2WN2ztW1NurTl68IbZ08RPmbduZbjhf/d/25n/cUSWW 4oxEQy3mouJEAOO7oF6wAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 11 Feb 2016 13:06:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DD0027ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCldoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyBuZXcgc2VjdGlvbiAzLjI6DQoN CiAgICDigJwzLjIuICBDaGFuZ2Ugb2YgTG9jYWwgVHJhbnNwb3J0IFBhcmFtZXRlcnMNCg0KICAg ICAgSWYgYW4gZW5kcG9pbnQgbW9kaWZpZXMgaXRzIGxvY2FsIHRyYW5zcG9ydCBwYXJhbWV0ZXJz IChJUCBhZGRyZXNzDQogICAgICBhbmQvb3IgcG9ydCksIGFuZCBpZiB0aGUgbW9kaWZpY2F0aW9u IHJlcXVpcmVzIGEgbmV3IERUTFMNCiAgICAgIGFzc29jaWF0aW9uLCB0aGUgZW5kcG9pbnQgTVVT VCBlaXRoZXIgY2hhbmdlIGl0cyBEVExTIHJvbGUsIGl0cw0KICAgICAgZmluZ2VycHJpbnQgdmFs dWUgYW5kL29yIHVzZSB0aGUgU0RQICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJpYnV0ZSB3aXRoDQog ICAgICBhICduZXcnIHZhbHVlIFNlY3Rpb24gNC4NCg0KICAgICAgSWYgdGhlIHVuZGVybHlpbmcg dHJhbnNwb3J0IGV4cGxpY2l0bHkgcHJvaGliaXRzIGEgRFRMUw0KICAgICAgYXNzb2NpYXRpb24g dG8gc3BhbiBtdWx0aXBsZSB0cmFuc3BvcnRzLCB0aGUgU0RQICdkdGxzLWNvbm5lY3Rpb24nDQog ICAgICBhdHRyaWJ1dGUgTVVTVCBiZSBzZXQgdG8gJ25ldycgaWYgdGhlIHRyYW5zcG9ydCBpcyBj aGFuZ2VkLiAgQW4NCiAgICAgIGV4YW1wbGUgb2Ygc3VjaCBjYXNlIGlzIHdoZW4gRFRMUyBpcyBj YXJyaWVkIG92ZXIgU0NUUCwgYXMgZGVzY3JpYmVkDQogICAgICBpbiBbUkZDNjA4M10u4oCdDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDExLiBo ZWxtaWt1dXRhIDIwMTYgOTowOQ0KVG86IFJvbWFuIFNocG91bnQNCkNjOiBtbXVzaWNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEVExTLW92ZXItU0NUUCwgYW55b25lPw0KDQpIaSBS b21hbiwNCg0KWW91ciBzdWdnZXN0aW9uIGxvb2tzIGdvb2QuIEnigJlsbCB0YWtlIGl0IGFzIGEg V0dMQyBjb21tZW50LCBhbmQgYWRkIGl0IGluIHRoZSBwb3N0LVdHTEMgdmVyc2lvbiBvZiB0aGUg ZHJhZnQgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hwb3VudCBb bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMTAuIGhlbG1pa3V1dGEgMjAxNiAyMjo0 Mg0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gRFRMUy1vdmVyLVNDVFAsIGFueW9u ZT8NCg0KDQpPbiBXZWQsIEZlYiAxMCwgMjAxNiBhdCAyOjU4IFBNLCBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+PiBJIHRoaW5rIHdlIGNhbiBhZGQgdGhlIGZvbGxv d2luZyB0byBzZWN0aW9uIDcuMSBvZiBkdGxzLXNkcDoNCj4+Pg0KPj4+IElmIERUTFMgaXMgdHJh bnNtaXR0ZWQgb3ZlciBhIHJlbGlhYmxlIHRyYW5zcG9ydCBhbmQgaWYgRFRMUyBwcm9jZWR1cmVz IGZvciByZXRyYW5zbWlzc2lvbnMgYXJlIG5vdCB1c2VkLCBmb3IgaW5zdGFuY2UgYXMgZGVzY3Jp YmVkIGluDQo+Pj4gUkZDIDYwODMgZm9yIERUTFMgb3ZlciBTQ1RQLCB0aGVuIERUTFMgYXNzb2Np YXRpb24gTVVTVCBOT1Qgc3BhbiBhY3Jvc3MgbXVsdGlwbGUgdHJhbnNwb3J0cy4gVXNpbmcgJ2R0 bHMtY29ubmVjdGlvbicgYXR0cmlidXRlIHdpdGgNCj4+PiBhbiAnZXhpc3RpbmcnIHZhbHVlIGlu IGNvbWJpbmF0aW9uIHdpdGggY2hhbmdlIG9mIHN1Y2ggYSByZWxpYWJsZSB0cmFuc3BvcnQgc2hv dWxkIGJlIHRyZWF0ZWQgYXMgYW4gZXJyb3IgYW5kIERUTFMgYXNzb2NpYXRpb24gTVVTVCBiZQ0K Pj4+IHRlcm1pbmF0ZWQuDQo+Pg0KPj4gWW91ciB0ZXh0IGFzIHN1Y2ggbG9va3Mgb2suIEJ1dCwg ZG8gd2UgcmVhbGx5IHdhbnQgdG8gYWRkIGl0IGFzIGEgZ2VuZXJpYyByZXN0cmljdGlvbiBpbiBk cmFmdC1kdGxzLXNkcD8gU2hvdWxkbid0IGl0IGJlDQo+PiBzcGVjaWZpYyBmb3IgRFRMUy1vdmVy LVNDVFAgaW5zdGVhZD8gV2hhdCBpZiBzb21lb25lIGRlZmluZXMgRFRMUy1vdmVyLTxuZXctZmFu Y3ktcmVsaWFibGUtdHJhbnNwb3J0PiBhbmQgdGhleSBETyBhbGxvdyBzcGFuPw0KPg0KPiBUaGUg cmVhc29uIG11bHRpcGxlIERUTFMgYXNzb2NpYXRpb25zIGNhbm5vdCBzcGFuIGFjcm9zcyBzZXZl cmFsIFNDVFAgYXNzb2NpYXRpb24gaXMgZHVlIHRvIFNDVFAgYXNzb2NpYXRpb24gaGFuZGxpbmcg RFRMUyBwYWNrZXQNCj4gcmV0cmFuc21pc3Npb24gYW5kIERUTFMgcHJvY2VkdXJlcyBmb3IgcmV0 cmFuc21pc3Npb25zIG5vdCBiZWluZyB1c2VkLiBXZSBjYW4gbWFrZSBhIGdlbmVyaWMgc3RhdGVt ZW50IG9yIGxpbWl0IHRoaXMgdG8gUkZDIDYwODMNCj4gb25seSwgYnV0IEkgdGhpbmssIHN0YXRp bmcgdGhlIHJlYXNvbiB3aHkgRFRMUyBhc3NvY2lhdGlvbiBjYW5ub3Qgc3BhbiBtdWx0aXBsZSB0 cmFuc3BvcnRzIGlzIGltcG9ydGFudC4NCg0KSSBhZ3JlZS4NCg0KQnV0LCBhZ2FpbiBEVExTLW92 ZXItU0NUUCBpcyBkZXNjcmliZWQgaW4gZHJhZnQtc2N0cC1zZHAsIHNvIEkgdGhpbmsgc3VjaCB0 ZXh0IGJlbG9uZ3MgdGhlcmUuDQoNCg0KSG93IGFib3V0IHNheWluZyB0aGUgZm9sbG93aW5nIGlu IGRyYWZ0LWR0bHMtc2RwOg0KDQpJZiBEVExTIGlzIHRyYW5zbWl0dGVkIG92ZXIgYSB0cmFuc3Bv cnQgdGhhdCBwcm9oaWJpdHMgc3Bhbm5pbmcgb2YgRFRMUyBhc3NvY2lhdGlvbiBhY3Jvc3MgbXVs dGlwbGUgdHJhbnNwb3J0cywgc3VjaCBhcyBEVExTIG92ZXIgU0NUUCBhcyBkZXNjcmliZWQgaW4g UkZDIDYwODMsIHRoZW4gJ2R0bHMtY29ubmVjdGlvbicgYXR0cmlidXRlIE1VU1QgYmUgc2V0IHRv ICduZXcnIGV2ZXJ5IHRpbWUgdHJhbnNwb3J0IGlzIGNoYW5nZWQuDQoNCkFuZCB5b3UgY2FuIHB1 dCB0aGUgcHJldmlvdXMgbGFuZ3VhZ2UgaW4gZHJhZnQtc2N0cC1zZHANCg0KVGhpcyB3YXkgZWFj aCBkcmFmdCBvbmx5IHNwZWNpZmllZCB0aGluZ3MgcmVsZXZhbnQgdG8gaXRzZWxmLg0KDQpSZWdh cmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37DD0027ESESSMB209erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNt IDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvbWFuLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyBuZXcgc2VjdGlvbiAzLjI6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDvigJwz LjIuJm5ic3A7IENoYW5nZSBvZiBMb2NhbCBUcmFuc3BvcnQgUGFyYW1ldGVyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0lmIGFuIGVuZHBvaW50IG1vZGlmaWVzIGl0cyBsb2NhbCB0cmFuc3BvcnQg cGFyYW1ldGVycyAoSVAgYWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO2FuZC9vciBwb3J0KSwgYW5k IGlmIHRoZSBtb2RpZmljYXRpb24gcmVxdWlyZXMgYSBuZXcgRFRMUzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw O2Fzc29jaWF0aW9uLCB0aGUgZW5kcG9pbnQgTVVTVCBlaXRoZXIgY2hhbmdlIGl0cyBEVExTIHJv bGUsIGl0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO2ZpbmdlcnByaW50IHZhbHVlIGFuZC9vciB1c2UgdGhl IFNEUCAnZHRscy1jb25uZWN0aW9uJyBhdHRyaWJ1dGUgd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO2Eg J25ldycgdmFsdWUgU2VjdGlvbiA0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0lmIHRoZSB1bmRl cmx5aW5nIHRyYW5zcG9ydCBleHBsaWNpdGx5IHByb2hpYml0cyBhIERUTFM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDthc3NvY2lhdGlvbiB0byBzcGFuIG11bHRpcGxlIHRyYW5zcG9ydHMsIHRoZSBTRFAgJ2R0 bHMtY29ubmVjdGlvbic8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDthdHRyaWJ1dGUgTVVTVCBiZSBzZXQgdG8g J25ldycgaWYgdGhlIHRyYW5zcG9ydCBpcyBjaGFuZ2VkLiZuYnNwOyBBbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwO2V4YW1wbGUgb2Ygc3VjaCBjYXNlIGlzIHdoZW4gRFRMUyBpcyBjYXJyaWVkIG92ZXIgU0NU UCwgYXMgZGVzY3JpYmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7aW4gW1JGQzYwODNdLuKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxi PlNlbnQ6PC9iPiAxMS4gaGVsbWlrdXV0YSAyMDE2IDk6MDk8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFu IFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW01NVVNJQ10gRFRMUy1vdmVyLVNDVFAsIGFueW9uZT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvbWFuLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Zb3VyIHN1Z2dlc3Rpb24gbG9va3MgZ29vZC4gSeKAmWxsIHRh a2UgaXQgYXMgYSBXR0xDIGNvbW1lbnQsIGFuZCBhZGQgaXQgaW4gdGhlIHBvc3QtV0dMQyB2ZXJz aW9uIG9mIHRoZSBkcmFmdCA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9tYW4gU2hwb3VudCBbPGEgaHJlZj0ibWFpbHRvOnJvbWFu QHRlbHVyaXguY29tIj5tYWlsdG86cm9tYW5AdGVsdXJpeC5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IDEwLiBoZWxtaWt1dXRhIDIwMTYgMjI6NDI8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVy IEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3Jn Ij5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBE VExTLW92ZXItU0NUUCwgYW55b25lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxMCwgMjAxNiBh dCAyOjU4IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgd2UgY2FuIGFkZCB0aGUgZm9sbG93aW5nIHRv IHNlY3Rpb24gNy4xIG9mIGR0bHMtc2RwOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBJZiBEVExTIGlzIHRyYW5zbWl0dGVkIG92ZXIgYSByZWxpYWJsZSB0cmFuc3BvcnQgYW5k IGlmIERUTFMgcHJvY2VkdXJlcyBmb3IgcmV0cmFuc21pc3Npb25zIGFyZSBub3QgdXNlZCwgZm9y IGluc3RhbmNlIGFzIGRlc2NyaWJlZCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyBSRkMgNjA4MyBmb3Ig RFRMUyBvdmVyIFNDVFAsIHRoZW4gRFRMUyBhc3NvY2lhdGlvbiBNVVNUIE5PVCBzcGFuIGFjcm9z cyBtdWx0aXBsZSB0cmFuc3BvcnRzLiBVc2luZyAnZHRscy1jb25uZWN0aW9uJyBhdHRyaWJ1dGUg d2l0aDxicj4NCiZndDsmZ3Q7Jmd0OyBhbiAnZXhpc3RpbmcnIHZhbHVlIGluIGNvbWJpbmF0aW9u IHdpdGggY2hhbmdlIG9mIHN1Y2ggYSByZWxpYWJsZSB0cmFuc3BvcnQgc2hvdWxkIGJlIHRyZWF0 ZWQgYXMgYW4gZXJyb3IgYW5kIERUTFMgYXNzb2NpYXRpb24gTVVTVCBiZTxicj4NCiZndDsmZ3Q7 Jmd0OyB0ZXJtaW5hdGVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWW91ciB0ZXh0IGFz IHN1Y2ggbG9va3Mgb2suIEJ1dCwgZG8gd2UgcmVhbGx5IHdhbnQgdG8gYWRkIGl0IGFzIGEgZ2Vu ZXJpYyByZXN0cmljdGlvbiBpbiBkcmFmdC1kdGxzLXNkcD8gU2hvdWxkbid0IGl0IGJlPGJyPg0K Jmd0OyZndDsgc3BlY2lmaWMgZm9yIERUTFMtb3Zlci1TQ1RQIGluc3RlYWQ/IFdoYXQgaWYgc29t ZW9uZSBkZWZpbmVzIERUTFMtb3Zlci0mbHQ7bmV3LWZhbmN5LXJlbGlhYmxlLXRyYW5zcG9ydCZn dDsgYW5kIHRoZXkgRE8gYWxsb3cgc3Bhbj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgcmVhc29u IG11bHRpcGxlIERUTFMgYXNzb2NpYXRpb25zIGNhbm5vdCBzcGFuIGFjcm9zcyBzZXZlcmFsIFND VFAgYXNzb2NpYXRpb24gaXMgZHVlIHRvIFNDVFAgYXNzb2NpYXRpb24gaGFuZGxpbmcgRFRMUyBw YWNrZXQ8YnI+DQomZ3Q7IHJldHJhbnNtaXNzaW9uIGFuZCBEVExTIHByb2NlZHVyZXMgZm9yIHJl dHJhbnNtaXNzaW9ucyBub3QgYmVpbmcgdXNlZC4gV2UgY2FuIG1ha2UgYSBnZW5lcmljIHN0YXRl bWVudCBvciBsaW1pdCB0aGlzIHRvIFJGQyA2MDgzPGJyPg0KJmd0OyBvbmx5LCBidXQgSSB0aGlu aywgc3RhdGluZyB0aGUgcmVhc29uIHdoeSBEVExTIGFzc29jaWF0aW9uIGNhbm5vdCBzcGFuIG11 bHRpcGxlIHRyYW5zcG9ydHMgaXMgaW1wb3J0YW50Ljxicj4NCjxicj4NCkkgYWdyZWUuPGJyPg0K PGJyPg0KQnV0LCBhZ2FpbiBEVExTLW92ZXItU0NUUCBpcyBkZXNjcmliZWQgaW4gZHJhZnQtc2N0 cC1zZHAsIHNvIEkgdGhpbmsgc3VjaCB0ZXh0IGJlbG9uZ3MgdGhlcmUuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91 dCBzYXlpbmcgdGhlIGZvbGxvd2luZyBpbiBkcmFmdC1kdGxzLXNkcDo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgRFRMUyBpcyB0cmFuc21p dHRlZCBvdmVyIGEgdHJhbnNwb3J0IHRoYXQgcHJvaGliaXRzIHNwYW5uaW5nIG9mIERUTFMgYXNz b2NpYXRpb24gYWNyb3NzIG11bHRpcGxlIHRyYW5zcG9ydHMsIHN1Y2ggYXMgRFRMUyBvdmVyIFND VFAgYXMgZGVzY3JpYmVkIGluIFJGQyA2MDgzLCB0aGVuICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJp YnV0ZSBNVVNUIGJlIHNldCB0byAnbmV3JyBldmVyeSB0aW1lIHRyYW5zcG9ydA0KIGlzIGNoYW5n ZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZCB5b3UgY2FuIHB1dCB0aGUgcHJldmlvdXMgbGFuZ3VhZ2UgaW4gZHJhZnQtc2N0 cC1zZHA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyB3YXkgZWFjaCBkcmFmdCBvbmx5IHNwZWNpZmllZCB0aGluZ3MgcmVsZXZhbnQgdG8g aXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37DD0027ESESSMB209erics_-- From nobody Thu Feb 11 10: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 72ED21B390C for ; Thu, 11 Feb 2016 10:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 jmRhOGqIHENw for ; Thu, 11 Feb 2016 10:46:08 -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 741D31B38E2 for ; Thu, 11 Feb 2016 10:46:08 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id 5so43199896igt.0 for ; Thu, 11 Feb 2016 10:46:08 -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=JFTZ32wV0XhVzUZBrjAPeHE5EggCOWrGiQtmgMtRzzk=; b=Am9BEcwcFgiqxXFz2+CxxHsLXvTUgs/MeoZ2xuqahtcx4xWyFpUhUKu3FtNn+vOOj9 f8tkTk4xEoixrM3eI7IRu6sUWdrmv71MA095sVo7cFzVsYCksImeQSDvY8z9mN1uFTuS QmmmOkSBqaki5dTzzvZsB/FnRBYTAKoGrmN7JjhPL+K4eu7+dn/xtrJHC01v3DxF4Kmp jhhrKEMZnbaTAr9bEJ/56iWMNbYkw1FdpurclJ7Wo80ZFmt+frX3UsDHe/MrpYJfC1I3 FRWoCUVbIlZDh3dATBR3fm5WnOW0icqEuh3sbaQoc4ClpGhdcK0/TD4BTqOcXKYPBmro axwg== 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=JFTZ32wV0XhVzUZBrjAPeHE5EggCOWrGiQtmgMtRzzk=; b=WMwh6mtop3ddhjy9QYNCEz6cmiahF4yPqYpdpflbtMv7CcRnRm2+0eS5KfDHV+H/ML GyowVRQjs4Ql6HjfOaEXJeh6UhHZRQYu67gblKNbTeDa9gRuKBcz8CjwPsEoAquoUEI9 Z2drmyd8z8gOAcSoIsVVv64H3fWbXeqrV4lzDRrj3mV9iEeQ1MsSw8RfR9mBA0CaUAbd lCaHBvH7aRW/b8C1Ui+jyqXKNWXi7t2RyQXza5CxkRoFCNflPvxOMHB4HHV87UtecQZw ERy16N54r1EAc82JKXFY1kRY3703nLlADo/GBno3IgpwrOmInXB2hIT/bJWXmybmgF+C 8kBA== X-Gm-Message-State: AG10YOQMGAFoL+P49p7fyJY9R9jmfF/ZPNtC6eeQZUvHtrboNlWmyFCIhf1Vnbjat8u/GA== X-Received: by 10.50.137.98 with SMTP id qh2mr29177igb.14.1455216367833; Thu, 11 Feb 2016 10:46:07 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by smtp.gmail.com with ESMTPSA id p8sm4651677ioe.38.2016.02.11.10.46.06 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 10:46:06 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id xg9so41352915igb.1 for ; Thu, 11 Feb 2016 10:46:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.136 with SMTP id w8mr17883584igl.96.1455216365682; Thu, 11 Feb 2016 10:46:05 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 11 Feb 2016 10:46:05 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DD0027@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCDC6C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCE497@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DD0027@ESESSMB209.ericsson.se> Date: Thu, 11 Feb 2016 13:46:05 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e011602a88c4b76052b82f641 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 11 Feb 2016 18:46:10 -0000 --089e011602a88c4b76052b82f641 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am fine with this language except it should be "address and/or port" not "IP address and/or port". Regards, _____________ Roman Shpount On Thu, Feb 11, 2016 at 8:06 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Roman, > > > > What about the following new section 3.2: > > > > =E2=80=9C3.2. Change of Local Transport Parameters > > > > If an endpoint modifies its local transport parameters (IP address > > and/or port), and if the modification requires a new DTLS > > association, the endpoint MUST either change its DTLS role, its > > fingerprint value and/or use the SDP 'dtls-connection' attribute wi= th > > a 'new' value Section 4. > > > > If the underlying transport explicitly prohibits a DTLS > > association to span multiple transports, the SDP 'dtls-connection' > > attribute MUST be set to 'new' if the transport is changed. An > > example of such case is when DTLS is carried over SCTP, as describe= d > > in [RFC6083].=E2=80=9D > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 11. helmikuuta 2016 9:09 > *To:* Roman Shpount > > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] DTLS-over-SCTP, anyone? > > > > Hi Roman, > > > > Your suggestion looks good. I=E2=80=99ll take it as a WGLC comment, and a= dd it in > the post-WGLC version of the draft :) > > > > Regards, > > > > Christer > > > > *From:* Roman Shpount [mailto:roman@telurix.com ] > *Sent:* 10. helmikuuta 2016 22:42 > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] DTLS-over-SCTP, anyone? > > > > > > On Wed, Feb 10, 2016 at 2:58 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > >>> I think we can add the following to section 7.1 of dtls-sdp: > >>> > >>> If DTLS is transmitted over a reliable transport and if DTLS > procedures for retransmissions are not used, for instance as described in > >>> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span > across multiple transports. Using 'dtls-connection' attribute with > >>> an 'existing' value in combination with change of such a reliable > transport should be treated as an error and DTLS association MUST be > >>> terminated. > >> > >> Your text as such looks ok. But, do we really want to add it as a > generic restriction in draft-dtls-sdp? Shouldn't it be > >> specific for DTLS-over-SCTP instead? What if someone defines > DTLS-over- and they DO allow span? > > > > The reason multiple DTLS associations cannot span across several SCTP > association is due to SCTP association handling DTLS packet > > retransmission and DTLS procedures for retransmissions not being used. > We can make a generic statement or limit this to RFC 6083 > > only, but I think, stating the reason why DTLS association cannot span > multiple transports is important. > > I agree. > > But, again DTLS-over-SCTP is described in draft-sctp-sdp, so I think such > text belongs there. > > > > > > How about saying the following in draft-dtls-sdp: > > > > If DTLS is transmitted over a transport that prohibits spanning of DTLS > association across multiple transports, such as DTLS over SCTP as describ= ed > in RFC 6083, then 'dtls-connection' attribute MUST be set to 'new' every > time transport is changed. > > > > And you can put the previous language in draft-sctp-sdp > > > > This way each draft only specified things relevant to itself. > > > > Regards, > > _____________ > Roman Shpount > > > --089e011602a88c4b76052b82f641 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am fine with this language except it should be "add= ress=C2=A0and/or port" not=C2=A0"IP address=C2=A0and/or port"= ;.

Regards,

_____________
Roman Shpo= unt

On Thu, Feb 11, 2016 at 8:06 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi Roman,

=C2=A0

What about= the following new section 3.2:

=C2= =A0

=C2=A0=C2= =A0 =C2=A0=E2=80=9C3.2.=C2=A0 Change of Local Transport Parameters

=C2=A0=C2= =A0

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0If an endpoint modifies its local transport para= meters (IP address

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0and/or port), and if the modification requires a new = DTLS

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0association, the endpoint MUST either change its DTLS= role, its

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0fingerprint value and/or use the SDP 'dtls-connec= tion' attribute with

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0a 'new' value Section 4.=

=C2=A0=C2= =A0

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0If the underlying transport explicitly prohibits= a DTLS

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0association to span multiple transports, the SDP '= ;dtls-connection'

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0attribute MUST be set to 'new' if the transpo= rt is changed.=C2=A0 An

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0example of such case is when DTLS is carried over SCT= P, as described

=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0in [RFC6083].=E2=80=9D

=C2= =A0

Regards,

=C2= =A0

Christer

=C2= =A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 11. helmikuuta 2016 9:09
To: Roman Shpount


Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?

=C2=A0

Hi Roman,<= u>

=C2= =A0

Your sugge= stion looks good. I=E2=80=99ll take it as a WGLC comment, and add it in the= post-WGLC version of the draft :)

=C2= =A0

Regards,

=C2= =A0

Christer

=C2= =A0

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 10. helmikuuta 2016 22:42
To: Christer Holmberg
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?

=C2=A0

=C2=A0

On Wed, Feb 10, 2016 at 2:58 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

>>> I think we can add the following to sec= tion 7.1 of dtls-sdp:
>>>
>>> If DTLS is transmitted over a reliable transport and if DTLS p= rocedures for retransmissions are not used, for instance as described in >>> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT sp= an across multiple transports. Using 'dtls-connection' attribute wi= th
>>> an 'existing' value in combination with change of such= a reliable transport should be treated as an error and DTLS association MU= ST be
>>> terminated.
>>
>> Your text as such looks ok. But, do we really want to add it as a = generic restriction in draft-dtls-sdp? Shouldn't it be
>> specific for DTLS-over-SCTP instead? What if someone defines DTLS-= over-<new-fancy-reliable-transport> and they DO allow span?
>
> The reason multiple DTLS associations cannot span across several SCTP = association is due to SCTP association handling DTLS packet
> retransmission and DTLS procedures for retransmissions not being used.= We can make a generic statement or limit this to RFC 6083
> only, but I think, stating the reason why DTLS association cannot span= multiple transports is important.

I agree.

But, again DTLS-over-SCTP is described in draft-sctp-sdp, so I think such t= ext belongs there.

=C2=A0

=C2=A0

How about saying the following in draft-dtls-sdp:=

=C2=A0

If DTLS is transmitted over a transport that prohibi= ts spanning of DTLS association across multiple transports, such as DTLS ov= er SCTP as described in RFC 6083, then 'dtls-connection' attribute = MUST be set to 'new' every time transport is changed.=C2=A0

=C2=A0

And you can put the previous language in draft-sctp-= sdp

=C2=A0

This way each draft only specified things relevant t= o itself.

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0


--089e011602a88c4b76052b82f641-- From nobody Thu Feb 11 11:47: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 793581B39A2 for ; Thu, 11 Feb 2016 11:47:00 -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 3ymCxNLx-RUr for ; Thu, 11 Feb 2016 11:46:58 -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 0760C1B3996 for ; Thu, 11 Feb 2016 11:46:56 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-03-56bce52edcde Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1C.9C.28465.E25ECB65; Thu, 11 Feb 2016 20:46:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Thu, 11 Feb 2016 20:46:01 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] DTLS-over-SCTP, anyone? Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAADlkIAACsv+IAAJBDYAAC5fwgAAF9Un8AARBt4AAALZElD///vhAP//QAqQ//4csMCABBVLgP//3q3Q Date: Thu, 11 Feb 2016 19:46:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DD082C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCDC6C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DCE497@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DD0027@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DD082CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7hK7e0z1hBvtWWlhMXf6YxWLGhanM DkweS5b8ZPK4NaUggCmKyyYlNSezLLVI3y6BK+Px8h1sBcveMlZsXfSaqYGx4zljFyMnh4SA icSq5slQtpjEhXvr2boYuTiEBA4zSiw5u5QJwlnCKPF781wgh4ODTcBCovufNkiDiICqxN/v k8HCzALqElcXB4GEhQV0Ja61nmGCKNGTmLC/hRFkjIhAE6PEi21T2EESLEC9z86fYgTp5RXw lfg0XRNi1U82iXNQx3EKBEocb13ABmIzAh33/dQasKHMAuISt57MZ4I4WkBiyZ7zzBC2qMTL x/9YIWwlicYlT1gh6vMltr19DVbPKyAocXLmE5YJjKKzkIyahaRsFpKyWWCvaUqs36UPUaIo MaX7ITuErSHROmcuO7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB8XZwy2/dHYyr XzseYhTgYFTi4TW4tSdMiDWxrLgy9xCjBAezkgiv/V2gEG9KYmVValF+fFFpTmrxIUZpDhYl cd41zuvDhATSE0tSs1NTC1KLYLJMHJxSDYwK7n9Yzr77c3V/Etu7f5/0SrV0fvdcO+THpWL0 8PCnzJM3RLgZvQxO+t5zf1OeeLwg7O77Qvnp8Y8Yb3SpVEe6TVR2kF0aw152QuvT30tqaqtt u1+ndi/PSGNwOz/1gAnDzdYlm961af1ge/8/JCf2e4fn0ifdZyfOyFE4KxwQGBhrZe24NFSJ pTgj0VCLuag4EQCpPvJGswIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone? 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, 11 Feb 2016 19:47:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DD082CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+SSBhbSBmaW5lIHdpdGggdGhpcyBsYW5ndWFnZSBleGNlcHQgaXQgc2hvdWxkIGJlICJhZGRy ZXNzIGFuZC9vciBwb3J0IiBub3QgIklQIGFkZHJlc3MgYW5kL29yID5wb3J0Ii4NCg0KQ29ycmVj dC4gSSB0aG91Z2h0IEkgaGFkIGZpeGVkIGFsbCB0aGF0LCBidXQgaXQgc2VlbXMgbGlrZSBJIGZv cmdvdCBvbmUgaW5zdGFuY2UgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQpP biBUaHUsIEZlYiAxMSwgMjAxNiBhdCA4OjA2IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20+PiB3cm90ZToNCkhpIFJvbWFuLA0KDQpXaGF0IGFib3V0IHRoZSBmb2xsb3dpbmcgbmV3 IHNlY3Rpb24gMy4yOg0KDQogICAg4oCcMy4yLiAgQ2hhbmdlIG9mIExvY2FsIFRyYW5zcG9ydCBQ YXJhbWV0ZXJzDQoNCiAgICAgIElmIGFuIGVuZHBvaW50IG1vZGlmaWVzIGl0cyBsb2NhbCB0cmFu c3BvcnQgcGFyYW1ldGVycyAoSVAgYWRkcmVzcw0KICAgICAgYW5kL29yIHBvcnQpLCBhbmQgaWYg dGhlIG1vZGlmaWNhdGlvbiByZXF1aXJlcyBhIG5ldyBEVExTDQogICAgICBhc3NvY2lhdGlvbiwg dGhlIGVuZHBvaW50IE1VU1QgZWl0aGVyIGNoYW5nZSBpdHMgRFRMUyByb2xlLCBpdHMNCiAgICAg IGZpbmdlcnByaW50IHZhbHVlIGFuZC9vciB1c2UgdGhlIFNEUCAnZHRscy1jb25uZWN0aW9uJyBh dHRyaWJ1dGUgd2l0aA0KICAgICAgYSAnbmV3JyB2YWx1ZSBTZWN0aW9uIDQuDQoNCiAgICAgIElm IHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBleHBsaWNpdGx5IHByb2hpYml0cyBhIERUTFMNCiAg ICAgIGFzc29jaWF0aW9uIHRvIHNwYW4gbXVsdGlwbGUgdHJhbnNwb3J0cywgdGhlIFNEUCAnZHRs cy1jb25uZWN0aW9uJw0KICAgICAgYXR0cmlidXRlIE1VU1QgYmUgc2V0IHRvICduZXcnIGlmIHRo ZSB0cmFuc3BvcnQgaXMgY2hhbmdlZC4gIEFuDQogICAgICBleGFtcGxlIG9mIHN1Y2ggY2FzZSBp cyB3aGVuIERUTFMgaXMgY2FycmllZCBvdmVyIFNDVFAsIGFzIGRlc2NyaWJlZA0KICAgICAgaW4g W1JGQzYwODNdLuKAnQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBtbXVzaWMgW21h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDExLiBoZWxtaWt1dXRh IDIwMTYgOTowOQ0KVG86IFJvbWFuIFNocG91bnQNCg0KQ2M6IG1tdXNpY0BpZXRmLm9yZzxtYWls dG86bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIERUTFMtb3Zlci1TQ1RQ LCBhbnlvbmU/DQoNCkhpIFJvbWFuLA0KDQpZb3VyIHN1Z2dlc3Rpb24gbG9va3MgZ29vZC4gSeKA mWxsIHRha2UgaXQgYXMgYSBXR0xDIGNvbW1lbnQsIGFuZCBhZGQgaXQgaW4gdGhlIHBvc3QtV0dM QyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9t OiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpTZW50OiAxMC4gaGVs bWlrdXV0YSAyMDE2IDIyOjQyDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBtbXVzaWNAaWV0 Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEVExT LW92ZXItU0NUUCwgYW55b25lPw0KDQoNCk9uIFdlZCwgRmViIDEwLCAyMDE2IGF0IDI6NTggUE0s IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPj4+IEkgdGhpbmsgd2Ug Y2FuIGFkZCB0aGUgZm9sbG93aW5nIHRvIHNlY3Rpb24gNy4xIG9mIGR0bHMtc2RwOg0KPj4+DQo+ Pj4gSWYgRFRMUyBpcyB0cmFuc21pdHRlZCBvdmVyIGEgcmVsaWFibGUgdHJhbnNwb3J0IGFuZCBp ZiBEVExTIHByb2NlZHVyZXMgZm9yIHJldHJhbnNtaXNzaW9ucyBhcmUgbm90IHVzZWQsIGZvciBp bnN0YW5jZSBhcyBkZXNjcmliZWQgaW4NCj4+PiBSRkMgNjA4MyBmb3IgRFRMUyBvdmVyIFNDVFAs IHRoZW4gRFRMUyBhc3NvY2lhdGlvbiBNVVNUIE5PVCBzcGFuIGFjcm9zcyBtdWx0aXBsZSB0cmFu c3BvcnRzLiBVc2luZyAnZHRscy1jb25uZWN0aW9uJyBhdHRyaWJ1dGUgd2l0aA0KPj4+IGFuICdl eGlzdGluZycgdmFsdWUgaW4gY29tYmluYXRpb24gd2l0aCBjaGFuZ2Ugb2Ygc3VjaCBhIHJlbGlh YmxlIHRyYW5zcG9ydCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhbiBlcnJvciBhbmQgRFRMUyBhc3Nv Y2lhdGlvbiBNVVNUIGJlDQo+Pj4gdGVybWluYXRlZC4NCj4+DQo+PiBZb3VyIHRleHQgYXMgc3Vj aCBsb29rcyBvay4gQnV0LCBkbyB3ZSByZWFsbHkgd2FudCB0byBhZGQgaXQgYXMgYSBnZW5lcmlj IHJlc3RyaWN0aW9uIGluIGRyYWZ0LWR0bHMtc2RwPyBTaG91bGRuJ3QgaXQgYmUNCj4+IHNwZWNp ZmljIGZvciBEVExTLW92ZXItU0NUUCBpbnN0ZWFkPyBXaGF0IGlmIHNvbWVvbmUgZGVmaW5lcyBE VExTLW92ZXItPG5ldy1mYW5jeS1yZWxpYWJsZS10cmFuc3BvcnQ+IGFuZCB0aGV5IERPIGFsbG93 IHNwYW4/DQo+DQo+IFRoZSByZWFzb24gbXVsdGlwbGUgRFRMUyBhc3NvY2lhdGlvbnMgY2Fubm90 IHNwYW4gYWNyb3NzIHNldmVyYWwgU0NUUCBhc3NvY2lhdGlvbiBpcyBkdWUgdG8gU0NUUCBhc3Nv Y2lhdGlvbiBoYW5kbGluZyBEVExTIHBhY2tldA0KPiByZXRyYW5zbWlzc2lvbiBhbmQgRFRMUyBw cm9jZWR1cmVzIGZvciByZXRyYW5zbWlzc2lvbnMgbm90IGJlaW5nIHVzZWQuIFdlIGNhbiBtYWtl IGEgZ2VuZXJpYyBzdGF0ZW1lbnQgb3IgbGltaXQgdGhpcyB0byBSRkMgNjA4Mw0KPiBvbmx5LCBi dXQgSSB0aGluaywgc3RhdGluZyB0aGUgcmVhc29uIHdoeSBEVExTIGFzc29jaWF0aW9uIGNhbm5v dCBzcGFuIG11bHRpcGxlIHRyYW5zcG9ydHMgaXMgaW1wb3J0YW50Lg0KDQpJIGFncmVlLg0KDQpC dXQsIGFnYWluIERUTFMtb3Zlci1TQ1RQIGlzIGRlc2NyaWJlZCBpbiBkcmFmdC1zY3RwLXNkcCwg c28gSSB0aGluayBzdWNoIHRleHQgYmVsb25ncyB0aGVyZS4NCg0KDQpIb3cgYWJvdXQgc2F5aW5n IHRoZSBmb2xsb3dpbmcgaW4gZHJhZnQtZHRscy1zZHA6DQoNCklmIERUTFMgaXMgdHJhbnNtaXR0 ZWQgb3ZlciBhIHRyYW5zcG9ydCB0aGF0IHByb2hpYml0cyBzcGFubmluZyBvZiBEVExTIGFzc29j aWF0aW9uIGFjcm9zcyBtdWx0aXBsZSB0cmFuc3BvcnRzLCBzdWNoIGFzIERUTFMgb3ZlciBTQ1RQ IGFzIGRlc2NyaWJlZCBpbiBSRkMgNjA4MywgdGhlbiAnZHRscy1jb25uZWN0aW9uJyBhdHRyaWJ1 dGUgTVVTVCBiZSBzZXQgdG8gJ25ldycgZXZlcnkgdGltZSB0cmFuc3BvcnQgaXMgY2hhbmdlZC4N Cg0KQW5kIHlvdSBjYW4gcHV0IHRoZSBwcmV2aW91cyBsYW5ndWFnZSBpbiBkcmFmdC1zY3RwLXNk cA0KDQpUaGlzIHdheSBlYWNoIGRyYWZ0IG9ubHkgc3BlY2lmaWVkIHRoaW5ncyByZWxldmFudCB0 byBpdHNlbGYuDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37DD082CESESSMB209erics_ 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 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+SSBhbSBmaW5lIHdpdGggdGhp cyBsYW5ndWFnZSBleGNlcHQgaXQgc2hvdWxkIGJlICZxdW90O2FkZHJlc3MmbmJzcDthbmQvb3Ig cG9ydCZxdW90OyBub3QmbmJzcDsmcXVvdDtJUCBhZGRyZXNzJm5ic3A7YW5kL29yDQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5wb3J0JnF1b3Q7LjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkNvcnJlY3QuIEkgdGhvdWdodCBJIGhhZCBmaXhlZCBhbGwgdGhhdCwgYnV0IGl0IHNlZW1zIGxp a2UgSSBmb3Jnb3Qgb25lIGluc3RhbmNlIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZl YiAxMSwgMjAxNiBhdCA4OjA2IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJGSSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFJvbWFuLDwvc3Bhbj48c3BhbiBs YW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJGSSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXQgYWJvdXQg dGhlIGZvbGxvd2luZyBuZXcgc2VjdGlvbiAzLjI6PC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZJ Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwO+KA nDMuMi4mbmJzcDsgQ2hhbmdlIG9mIExvY2FsIFRyYW5zcG9ydCBQYXJhbWV0ZXJzPC9zcGFuPjxz cGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJZiBhbiBlbmRwb2ludCBt b2RpZmllcyBpdHMgbG9jYWwgdHJhbnNwb3J0IHBhcmFtZXRlcnMgKElQIGFkZHJlc3M8L3NwYW4+ PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7YW5kL29yIHBvcnQpLCBhbmQgaWYgdGhlIG1vZGlmaWNh dGlvbiByZXF1aXJlcyBhIG5ldyBEVExTPC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO2Fz c29jaWF0aW9uLCB0aGUgZW5kcG9pbnQgTVVTVCBlaXRoZXIgY2hhbmdlIGl0cyBEVExTIHJvbGUs IGl0czwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtmaW5nZXJwcmludCB2YWx1ZSBhbmQv b3IgdXNlIHRoZSBTRFAgJ2R0bHMtY29ubmVjdGlvbicgYXR0cmlidXRlIHdpdGg8L3NwYW4+PHNw YW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7YSAnbmV3JyB2YWx1ZSBTZWN0aW9uIDQuPC9zcGFuPjxzcGFu IGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJZiB0aGUgdW5kZXJseWluZyB0 cmFuc3BvcnQgZXhwbGljaXRseSBwcm9oaWJpdHMgYSBEVExTPC9zcGFuPjxzcGFuIGxhbmc9IkZJ Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwO2Fzc29jaWF0aW9uIHRvIHNwYW4gbXVsdGlwbGUgdHJhbnNwb3J0cywgdGhlIFNE UCAnZHRscy1jb25uZWN0aW9uJzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDthdHRyaWJ1 dGUgTVVTVCBiZSBzZXQgdG8gJ25ldycgaWYgdGhlIHRyYW5zcG9ydCBpcyBjaGFuZ2VkLiZuYnNw OyBBbjwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtleGFtcGxlIG9mIHN1Y2ggY2FzZSBp cyB3aGVuIERUTFMgaXMgY2FycmllZCBvdmVyIFNDVFAsIGFzIGRlc2NyaWJlZDwvc3Bhbj48c3Bh biBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDtpbiBbUkZDNjA4M10u4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkZJ Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+ PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D aHJpc3Rlcjwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gbW11c2ljDQogW21haWx0bzo8YSBocmVmPSJtYWlsdG86 bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGVyIEhvbG1iZXJnPGJyPg0K PGI+U2VudDo8L2I+IDExLiBoZWxtaWt1dXRhIDIwMTYgOTowOTxicj4NCjxiPlRvOjwvYj4gUm9t YW4gU2hwb3VudDwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSI+PGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10g RFRMUy1vdmVyLVNDVFAsIGFueW9uZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkhpIFJvbWFuLDwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPllvdXIgc3VnZ2VzdGlvbiBsb29rcyBnb29kLiBJ4oCZbGwgdGFrZSBp dCBhcyBhIFdHTEMgY29tbWVudCwgYW5kIGFkZCBpdCBpbiB0aGUgcG9zdC1XR0xDDQogdmVyc2lv biBvZiB0aGUgZHJhZnQgOik8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRkkiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJGSSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJG SSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxzcGFu IGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFuDQogU2hwb3VudCBbPGEgaHJlZj0ibWFp bHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJvbWFuQHRlbHVy aXguY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMC4gaGVsbWlrdXV0YSAyMDE2IDIyOjQy PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIERUTFMtb3Zlci1TQ1RQLCBh bnlvbmU/PC9zcGFuPjxzcGFuIGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj5PbiBX ZWQsIEZlYiAxMCwgMjAxNiBhdCAyOjU4IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPiZndDsm Z3Q7Jmd0OyBJIHRoaW5rIHdlIGNhbiBhZGQgdGhlIGZvbGxvd2luZyB0byBzZWN0aW9uIDcuMSBv ZiBkdGxzLXNkcDo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSWYgRFRMUyBp cyB0cmFuc21pdHRlZCBvdmVyIGEgcmVsaWFibGUgdHJhbnNwb3J0IGFuZCBpZiBEVExTIHByb2Nl ZHVyZXMgZm9yIHJldHJhbnNtaXNzaW9ucyBhcmUgbm90IHVzZWQsIGZvciBpbnN0YW5jZSBhcyBk ZXNjcmliZWQgaW48YnI+DQomZ3Q7Jmd0OyZndDsgUkZDIDYwODMgZm9yIERUTFMgb3ZlciBTQ1RQ LCB0aGVuIERUTFMgYXNzb2NpYXRpb24gTVVTVCBOT1Qgc3BhbiBhY3Jvc3MgbXVsdGlwbGUgdHJh bnNwb3J0cy4gVXNpbmcgJ2R0bHMtY29ubmVjdGlvbicgYXR0cmlidXRlIHdpdGg8YnI+DQomZ3Q7 Jmd0OyZndDsgYW4gJ2V4aXN0aW5nJyB2YWx1ZSBpbiBjb21iaW5hdGlvbiB3aXRoIGNoYW5nZSBv ZiBzdWNoIGEgcmVsaWFibGUgdHJhbnNwb3J0IHNob3VsZCBiZSB0cmVhdGVkIGFzIGFuIGVycm9y IGFuZCBEVExTIGFzc29jaWF0aW9uIE1VU1QgYmU8YnI+DQomZ3Q7Jmd0OyZndDsgdGVybWluYXRl ZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFlvdXIgdGV4dCBhcyBzdWNoIGxvb2tzIG9r LiBCdXQsIGRvIHdlIHJlYWxseSB3YW50IHRvIGFkZCBpdCBhcyBhIGdlbmVyaWMgcmVzdHJpY3Rp b24gaW4gZHJhZnQtZHRscy1zZHA/IFNob3VsZG4ndCBpdCBiZTxicj4NCiZndDsmZ3Q7IHNwZWNp ZmljIGZvciBEVExTLW92ZXItU0NUUCBpbnN0ZWFkPyBXaGF0IGlmIHNvbWVvbmUgZGVmaW5lcyBE VExTLW92ZXItJmx0O25ldy1mYW5jeS1yZWxpYWJsZS10cmFuc3BvcnQmZ3Q7IGFuZCB0aGV5IERP IGFsbG93IHNwYW4/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHJlYXNvbiBtdWx0aXBsZSBEVExT IGFzc29jaWF0aW9ucyBjYW5ub3Qgc3BhbiBhY3Jvc3Mgc2V2ZXJhbCBTQ1RQIGFzc29jaWF0aW9u IGlzIGR1ZSB0byBTQ1RQIGFzc29jaWF0aW9uIGhhbmRsaW5nIERUTFMgcGFja2V0PGJyPg0KJmd0 OyByZXRyYW5zbWlzc2lvbiBhbmQgRFRMUyBwcm9jZWR1cmVzIGZvciByZXRyYW5zbWlzc2lvbnMg bm90IGJlaW5nIHVzZWQuIFdlIGNhbiBtYWtlIGEgZ2VuZXJpYyBzdGF0ZW1lbnQgb3IgbGltaXQg dGhpcyB0byBSRkMgNjA4Mzxicj4NCiZndDsgb25seSwgYnV0IEkgdGhpbmssIHN0YXRpbmcgdGhl IHJlYXNvbiB3aHkgRFRMUyBhc3NvY2lhdGlvbiBjYW5ub3Qgc3BhbiBtdWx0aXBsZSB0cmFuc3Bv cnRzIGlzIGltcG9ydGFudC48YnI+DQo8YnI+DQpJIGFncmVlLjxicj4NCjxicj4NCkJ1dCwgYWdh aW4gRFRMUy1vdmVyLVNDVFAgaXMgZGVzY3JpYmVkIGluIGRyYWZ0LXNjdHAtc2RwLCBzbyBJIHRo aW5rIHN1Y2ggdGV4dCBiZWxvbmdzIHRoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj5Ib3cg YWJvdXQgc2F5aW5nIHRoZSBmb2xsb3dpbmcgaW4gZHJhZnQtZHRscy1zZHA6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJGSSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+SWYgRFRMUyBpcyB0cmFuc21pdHRl ZCBvdmVyIGEgdHJhbnNwb3J0IHRoYXQgcHJvaGliaXRzIHNwYW5uaW5nIG9mIERUTFMgYXNzb2Np YXRpb24gYWNyb3NzIG11bHRpcGxlIHRyYW5zcG9ydHMsIHN1Y2ggYXMgRFRMUyBvdmVyIFNDVFAg YXMgZGVzY3JpYmVkIGluIFJGQyA2MDgzLA0KIHRoZW4gJ2R0bHMtY29ubmVjdGlvbicgYXR0cmli dXRlIE1VU1QgYmUgc2V0IHRvICduZXcnIGV2ZXJ5IHRpbWUgdHJhbnNwb3J0IGlzIGNoYW5nZWQu Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+QW5k IHlvdSBjYW4gcHV0IHRoZSBwcmV2aW91cyBsYW5ndWFnZSBpbiBkcmFmdC1zY3RwLXNkcDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRkkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPlRoaXMgd2F5IGVhY2gg ZHJhZnQgb25seSBzcGVjaWZpZWQgdGhpbmdzIHJlbGV2YW50IHRvIGl0c2VsZi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkZJIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkZJIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37DD082CESESSMB209erics_-- From nobody Thu Feb 11 12:52: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 20A141B3A3B; Thu, 11 Feb 2016 12:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 hihWeGkWhVbp; Thu, 11 Feb 2016 12:52:24 -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 E9FA01B3A45; Thu, 11 Feb 2016 12:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4265; q=dns/txt; s=iport; t=1455223938; x=1456433538; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=9++IoQw6abMXYNTLmYc6nFVUmZ3Wk2i8TghmH7/3r/0=; b=h2ex/f/j653n2jzzaSTKrpldjNb81vYg0Q/wblofpE7xT0aivOzyEPda rEeRV4Z4H0t+r2THuQD2McZ+hmqRBxBPCXnS7ikbs0YuuUNhhL8VjjWGG 9tH1Mo7H0uTyMeUvMsXyTZ2BG3a7uhcUcAFteKPmIU43hrmWbiq3UGIab A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQDK87xW/xbLJq1eDoN+bYhbsSsBD?= =?us-ascii?q?YFnFwqFIkoCgW0UAQEBAQEBAYEKhEEBAQEDAQEBATU2CgEFCwsOCgkWDwkDAgE?= =?us-ascii?q?CARUwBgEMBgIBAYgOCA7BNQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKENohsA?= =?us-ascii?q?QSOG4hcjVOJI4VSjj4eAQFCgypZHi6IUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="632582930" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 20:52:15 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1BKqEkM008656; Thu, 11 Feb 2016 20:52:14 GMT To: Paul Kyzivat , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "bradler >> Juergen Stoetzer-Bradler" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> From: Flemming Andreasen Message-ID: <56BCF47E.2000603@cisco.com> Date: Thu, 11 Feb 2016 15:52:14 -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: <56B8CBB5.7070507@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org 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: Thu, 11 Feb 2016 20:52:34 -0000 On 2/8/16 12:09 PM, Paul Kyzivat wrote: > On 2/8/16 11:09 AM, Flemming Andreasen wrote: >> >> >> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>> Isn't this the approach we're taking today? >>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>>> drafts are used to describe protocols that use the mechanism (i.e. >>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>> draft-ietf-clue-datachannel). >>> >>> It remains to be seen if that will be enough. E.g., there currently >>> aren't any iana considerations in >>> draft-ietf-mmusic-msrp-usage-data-channel. >>> >>> Suppose I encounter some sdp that uses msrp over a data channel, but >>> that usage is unknown to me. How do I find the spec (the reference to >>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>> >>> I would like to think that the iana registries will allow me to trace >>> back to the relevant specs. >>> >> No disagreement on that part, however having taken another look at both >> sdpneg and the msrp-usage documents, I still don't agree with your >> original request for all (existing and new) attributes to specify how >> they may or may not be used with the dcsa attribute defined by sdpneg. >> >> As Christian noted, the sub-protocol specifics are defined in individual >> documents (like msrp-usage), which calls your the parameters that are at >> least needed to be supported for that usage. Taking MSRP as an example, >> why isn't that enough, and how do you see the resulting set of >> attributes that may or may not be used with MSRP differ between use in a >> data-channel (and hence encapsulated in dcsa) or as a regular media >> stream ? > > Based on this discussion, I conclude that it should be sufficient for > this draft to say that before an attribute can be used with dcsa, such > usage must be defined somewhere. This could be either: > - as part of the definition of the attribute, OR > - as part of the definition of the protocol referenced on the m-line. > We are getting closer, but it's still not obvious to me that you cannot use an attribute with dcsa if it has not been explicitly defined for the attribute in question. Clearly, there are attributes that wouldn't make sense over data channels, just like there are attributes that don't make sense over particular media descriptions. Again, I'd like to hear from more people on this, including the authors. Thanks -- Flemming > Thanks, > Paul > >> Also, it would be good to hear from more people on this, including the >> document authors. >> >> Thanks >> >> -- Flemming >> >> >>> Thanks, >>> Paul >>> >>>> Regards, Christian >>>> >>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>> >>>>>> I'm not concerned about the IANA part. I agree that *if* we need to >>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>> should be >>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>> point is >>>>>> that there is indeed a need to explicitly speficy these >>>>>> interactions as >>>>>> opposed to relying on a more general algorithmic approach (plus the >>>>>> offerer being responsible for generating a valid offer if he >>>>>> wants to >>>>>> establish a data channel). >>>>> >>>>> Well, an obvious one is that the protocol(s) the attribute >>>>> pertains to >>>>> need to be defined to work over data channels. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> 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 Feb 11 13:00: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 98F6F1B3A6F for ; Thu, 11 Feb 2016 13:00:26 -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 ndwFTaPoRDhb for ; Thu, 11 Feb 2016 13:00:25 -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 D18D51B3A6C for ; Thu, 11 Feb 2016 13:00:21 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-02v.sys.comcast.net with comcast id H8zi1s0012Udklx0190LBB; Thu, 11 Feb 2016 21:00:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id H90L1s0073KdFy10190LB4; Thu, 11 Feb 2016 21:00:20 +0000 To: Flemming Andreasen , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "bradler >> Juergen Stoetzer-Bradler" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> From: Paul Kyzivat Message-ID: <56BCF663.7020708@alum.mit.edu> Date: Thu, 11 Feb 2016 16:00:19 -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: <56BCF47E.2000603@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=1455224420; bh=0q7nCr1/aYerlc8/DKLgl0JYt/FAjYVIAW97xwoZY/8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=C0gKpWQALXZxcu1ebJPFEd/ygSi/DSXOl15bj/lFf5+6rT4BO8gjhdHqf7HN7qoL4 oHVSW6soQ4TN/E2QLSjFJqO+RIQPsRcrDaFBeX3Haa+qdA2kn37hpoxBQL5PvEl4DD pgb0fdbY0jJLujEwvqpHpfRe5Qt9vFtIqJkL7cCapT4/EpoX16jLQmC07Opj5t6YyP 1yxmjYr80wc0xBIZ6hlk+Coyi4n7wgtlcWhnNylj4ptosJ+dZo4F8AjZ2J0xwUNZkc zp+T/omwMNalMuuxWDpEwkA0dNDG+GfZxBVdAwNIIfJH9nKh4CBjA0dRB5NAMMVkpT o2k+0CXo8PYwQ== Archived-At: Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org 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: Thu, 11 Feb 2016 21:00:26 -0000 On 2/11/16 3:52 PM, Flemming Andreasen wrote: > > > On 2/8/16 12:09 PM, Paul Kyzivat wrote: >> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>> >>> >>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>> Isn't this the approach we're taking today? >>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>> draft-ietf-clue-datachannel). >>>> >>>> It remains to be seen if that will be enough. E.g., there currently >>>> aren't any iana considerations in >>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>> >>>> Suppose I encounter some sdp that uses msrp over a data channel, but >>>> that usage is unknown to me. How do I find the spec (the reference to >>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>> >>>> I would like to think that the iana registries will allow me to trace >>>> back to the relevant specs. >>>> >>> No disagreement on that part, however having taken another look at both >>> sdpneg and the msrp-usage documents, I still don't agree with your >>> original request for all (existing and new) attributes to specify how >>> they may or may not be used with the dcsa attribute defined by sdpneg. >>> >>> As Christian noted, the sub-protocol specifics are defined in individual >>> documents (like msrp-usage), which calls your the parameters that are at >>> least needed to be supported for that usage. Taking MSRP as an example, >>> why isn't that enough, and how do you see the resulting set of >>> attributes that may or may not be used with MSRP differ between use in a >>> data-channel (and hence encapsulated in dcsa) or as a regular media >>> stream ? >> >> Based on this discussion, I conclude that it should be sufficient for >> this draft to say that before an attribute can be used with dcsa, such >> usage must be defined somewhere. This could be either: >> - as part of the definition of the attribute, OR >> - as part of the definition of the protocol referenced on the m-line. >> > We are getting closer, but it's still not obvious to me that you cannot > use an attribute with dcsa if it has not been explicitly defined for the > attribute in question. Can you give me an example? Thanks, Paul > Clearly, there are attributes that wouldn't make > sense over data channels, just like there are attributes that don't make > sense over particular media descriptions. > > Again, I'd like to hear from more people on this, including the authors. > > Thanks > > -- Flemming > > > >> Thanks, >> Paul >> >>> Also, it would be good to hear from more people on this, including the >>> document authors. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, Christian >>>>> >>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>> >>>>>>> I'm not concerned about the IANA part. I agree that *if* we need to >>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>> should be >>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>> point is >>>>>>> that there is indeed a need to explicitly speficy these >>>>>>> interactions as >>>>>>> opposed to relying on a more general algorithmic approach (plus the >>>>>>> offerer being responsible for generating a valid offer if he >>>>>>> wants to >>>>>>> establish a data channel). >>>>>> >>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>> pertains to >>>>>> need to be defined to work over data channels. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Feb 11 13:13: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 C2E751B3A8C; Thu, 11 Feb 2016 13:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 QS_JqSKvU3OY; Thu, 11 Feb 2016 13:13:39 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4B01B3A8A; Thu, 11 Feb 2016 13:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4794; q=dns/txt; s=iport; t=1455225219; x=1456434819; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5I2Bd+mgGJIUSKJZDvrcoOS59RnvhQe/gr3pCahupaU=; b=DNb4Yn43X6t/FuW4YDDQUs39dI6RK4hrN4e6Ni/aH5epin79chp/xAOQ 9JUdM+pqc8gyf0mOJPKxO1MBXpeBAqep1KcxwgB1B/PlGYOhLcNx4TTIe onYt0Luu8JrX9aFnhE7Eq05lv9drdXnu3pCNRsefSOgL7NJ08DVAqu9az Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCm+LxW/xbLJq1eDoN+bYhbsSsBD?= =?us-ascii?q?YFnFwqFIkoCgW0UAQEBAQEBAYEKhEIBAQQBAQE1NgoBEAsOCgkWDwkDAgECARU?= =?us-ascii?q?wBgEMBgIBAYgWDsE1AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ2iGwBBI4bi?= =?us-ascii?q?FyNU4kjhVKOPh4BAUKDKlkeLohTAQEB?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="649251453" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 21:13:37 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1BLDa0X014419; Thu, 11 Feb 2016 21:13:36 GMT To: Paul Kyzivat , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "bradler >> Juergen Stoetzer-Bradler" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BCF663.7020708@alum.mit.edu> From: Flemming Andreasen Message-ID: <56BCF97F.8000404@cisco.com> Date: Thu, 11 Feb 2016 16:13: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: <56BCF663.7020708@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org 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: Thu, 11 Feb 2016 21:13:50 -0000 On 2/11/16 4:00 PM, Paul Kyzivat wrote: > On 2/11/16 3:52 PM, Flemming Andreasen wrote: >> >> >> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>> >>>> >>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>> Isn't this the approach we're taking today? >>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>> draft-ietf-clue-datachannel). >>>>> >>>>> It remains to be seen if that will be enough. E.g., there currently >>>>> aren't any iana considerations in >>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>> >>>>> Suppose I encounter some sdp that uses msrp over a data channel, but >>>>> that usage is unknown to me. How do I find the spec (the reference to >>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>>> >>>>> I would like to think that the iana registries will allow me to trace >>>>> back to the relevant specs. >>>>> >>>> No disagreement on that part, however having taken another look at >>>> both >>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>> original request for all (existing and new) attributes to specify how >>>> they may or may not be used with the dcsa attribute defined by sdpneg. >>>> >>>> As Christian noted, the sub-protocol specifics are defined in >>>> individual >>>> documents (like msrp-usage), which calls your the parameters that >>>> are at >>>> least needed to be supported for that usage. Taking MSRP as an >>>> example, >>>> why isn't that enough, and how do you see the resulting set of >>>> attributes that may or may not be used with MSRP differ between use >>>> in a >>>> data-channel (and hence encapsulated in dcsa) or as a regular media >>>> stream ? >>> >>> Based on this discussion, I conclude that it should be sufficient for >>> this draft to say that before an attribute can be used with dcsa, such >>> usage must be defined somewhere. This could be either: >>> - as part of the definition of the attribute, OR >>> - as part of the definition of the protocol referenced on the m-line. >>> >> We are getting closer, but it's still not obvious to me that you cannot >> use an attribute with dcsa if it has not been explicitly defined for the >> attribute in question. > > Can you give me an example? > How about preconditions ? -- Flemming > Thanks, > Paul > >> Clearly, there are attributes that wouldn't make >> sense over data channels, just like there are attributes that don't make >> sense over particular media descriptions. >> >> Again, I'd like to hear from more people on this, including the authors. >> >> Thanks >> >> -- Flemming >> >> >> >>> Thanks, >>> Paul >>> >>>> Also, it would be good to hear from more people on this, including the >>>> document authors. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>> >>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>> need to >>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>> should be >>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>> point is >>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>> interactions as >>>>>>>> opposed to relying on a more general algorithmic approach (plus >>>>>>>> the >>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>> wants to >>>>>>>> establish a data channel). >>>>>>> >>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>> pertains to >>>>>>> need to be defined to work over data channels. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Fri Feb 12 02:18:10 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 665B41B42B8; Fri, 12 Feb 2016 02:18:09 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160212101809.8243.24992.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 02:18:09 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-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, 12 Feb 2016 10:18:09 -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 of the IETF. Title : MSRP over Data Channels Authors : Keith Drage Maridi R. Makaraju (Raju) Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-msrp-usage-data-channel-04.txt Pages : 17 Date : 2016-02-12 Abstract: This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based generic data channel negotiation framework. Two network configurations are documented: a WebRTC end- to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-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 Feb 12 02:45:27 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 99B621B432E for ; Fri, 12 Feb 2016 02:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 yCXyI7OQy9l2 for ; Fri, 12 Feb 2016 02:45:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 25D6D1B432C for ; Fri, 12 Feb 2016 02:45:21 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 1CAEB36A535E9; Fri, 12 Feb 2016 10:45:17 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1CAjIo5006805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Feb 2016 10:45:19 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1CAjHRq026861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Feb 2016 11:45:18 +0100 Received: from [149.204.68.190] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 12 Feb 2016 11:45:17 +0100 To: Flemming Andreasen , Paul Kyzivat , , "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> From: Juergen Stoetzer-Bradler Message-ID: <56BDB7BC.1060104@alcatel-lucent.com> Date: Fri, 12 Feb 2016 11:45:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BCF47E.2000603@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050500050906010000050908" X-Originating-IP: [135.239.27.38] 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, 12 Feb 2016 10:45:25 -0000 --------------ms050500050906010000050908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Flemming, Paul, The current a=3Ddcmap related text in draft-ietf-mmusic-data-channel-sdpn= eg doesn't require that the=20 'subprotocol' parameter must always be present - rather it is specified a= s an optional parameter.=20 Thus, current sdpneg text would allow to create an SDP offer for a data c= hannel, which contains one=20 a=3Ddcmap attribute and potentially multiple a=3Ddcsa attributes without = the subprotocol actually being=20 given. Based on this discussion I am wondering if the subprotocol paramet= er should actually be=20 mandatory. In the specific case of MSRP, the msrp-usage-data-channel draft says in 5= =2E1.1.1 that the dcmap=20 attribute includes the label and subprotocol parameters. The current text= could possible be made=20 more explicit by saying that the 'subprotocol=3D"MSRP"' parameter must al= ways be present. Have just submitted version 04 of the msrp-usage-data-channel draft, whic= h proposes to add=20 subprotocol identifier "MSRP" to the WebSocket Subprotocol Name registry.= This registry would then=20 associate subprotocol id "MSRP" with the msrp-usage-data-channel document= =2E There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa attrib= ute are specified. And there=20 the MSRP specific SDP attributes, which can be dcsa embedded, are describ= ed. 'setup' is an attribute, whose semantic changes when being dcsa embedded = and associated with=20 subprotocol MSRP, as compared to the meaning of an "a=3Dsetup" media leve= l attribute of a TCP/MSRP=20 m-line. Hence these semantical differences are explicitly addressed in th= e msrp-usage-data-channel=20 draft. Regarding sdpneg, I also think that the current text in sdpneg seems to b= e sufficient regarding the=20 usage of dcsa encapsulated SDP attributes as being bound to the data chan= nel's subprotocol. But as=20 the semantic of a dcsa encapsulated attribute may be subprotocol specific= (like 'setup'), I'd now=20 tend to consider the subprotocol parameter in the dcmap attribute as bein= g mandatory, as mentioned=20 above. As already discussed, the Websocket subprotocol registry would the= n refer to the document,=20 which specifies the subprotocol specific usage of dcsa encapsulated param= eters. Thanks, Juergen On 11.02.2016 21:52, Flemming Andreasen wrote: > > > On 2/8/16 12:09 PM, Paul Kyzivat wrote: >> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>> >>> >>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>> Isn't this the approach we're taking today? >>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific= >>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>> draft-ietf-clue-datachannel). >>>> >>>> It remains to be seen if that will be enough. E.g., there currently >>>> aren't any iana considerations in >>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>> >>>> Suppose I encounter some sdp that uses msrp over a data channel, but= >>>> that usage is unknown to me. How do I find the spec (the reference t= o >>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>> >>>> I would like to think that the iana registries will allow me to trac= e >>>> back to the relevant specs. >>>> >>> No disagreement on that part, however having taken another look at bo= th >>> sdpneg and the msrp-usage documents, I still don't agree with your >>> original request for all (existing and new) attributes to specify how= >>> they may or may not be used with the dcsa attribute defined by sdpneg= =2E >>> >>> As Christian noted, the sub-protocol specifics are defined in individ= ual >>> documents (like msrp-usage), which calls your the parameters that are= at >>> least needed to be supported for that usage. Taking MSRP as an exampl= e, >>> why isn't that enough, and how do you see the resulting set of >>> attributes that may or may not be used with MSRP differ between use i= n a >>> data-channel (and hence encapsulated in dcsa) or as a regular media >>> stream ? >> >> Based on this discussion, I conclude that it should be sufficient for = this draft to say that=20 >> before an attribute can be used with dcsa, such usage must be defined = somewhere. This could be=20 >> either: >> - as part of the definition of the attribute, OR >> - as part of the definition of the protocol referenced on the m-line. >> > We are getting closer, but it's still not obvious to me that you cannot= use an attribute with dcsa=20 > if it has not been explicitly defined for the attribute in question. Cl= early, there are attributes=20 > that wouldn't make sense over data channels, just like there are attrib= utes that don't make sense=20 > over particular media descriptions. > > Again, I'd like to hear from more people on this, including the authors= =2E > > Thanks > > -- Flemming > > > >> Thanks, >> Paul >> >>> Also, it would be good to hear from more people on this, including th= e >>> document authors. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, Christian >>>>> >>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>> >>>>>>> I'm not concerned about the IANA part. I agree that *if* we need = to >>>>>>> expliclty specify attribute interactions for "dcsa", then it shou= ld be >>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>> point is >>>>>>> that there is indeed a need to explicitly speficy these >>>>>>> interactions as >>>>>>> opposed to relying on a more general algorithmic approach (plus t= he >>>>>>> offerer being responsible for generating a valid offer if he want= s to >>>>>>> establish a data channel). >>>>>> >>>>>> Well, an obvious one is that the protocol(s) the attribute pertain= s to >>>>>> need to be defined to work over data channels. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> . >> > --------------ms050500050906010000050908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DF8wggTdMIIDxaADAgECAgoanQrOAAAAAAAGMA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoT DkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBSb290 IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcyOFowgYUxEzARBgoJkiaJk/IsZAEZ FgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ocmcli3LbVU6TRh +JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdfkyWAiGzVWeRI rYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38VbxMvQ+ygj Eyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+VdiUwDa ry1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsG AQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAes slr2YYl8XHzr4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5z dXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5h bGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4Bggr BgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQw OAYIKwYBBQUHMAKGLGh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQClGxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3 F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjbEhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx 4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6 rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwfRfPmwRetdnD6NC5x8aRkhr4ZNBjv YxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6/XpNOx2FyG18axeeASWtENgP vqEirM5MjwkCMIIHejCCBmKgAwIBAgIKYWH+JwAAAAFWdjANBgkqhkiG9w0BAQUFADCBhTET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVs IEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNTE4MTMwNzI0WhcNMTcwNTE3MTMwNzI0 WjBOMRAwDgYDVQQDEwdsaTYwNzYwMTowOAYJKoZIhvcNAQkBFitqdWVyZ2VuLnN0b2V0emVy LWJyYWRsZXJAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3SjiDDt1yolL0cBi5MS+Bea3hhVDSdcJ/xtfzEbTtkxo05xnMgeRTy/kNJZuR4oY j/2TE+raQenSEgROQtLgxKjxtLh9/fGEuLCyFclz9SIeIYIkZBB1NSwZKmGlJHRU5jjqSinT Hmux9chaP+TUoidoDYbfdz/uFGdPW7RP21Gxjzg9v/VC+tfc0u0idNF9Vwnkh3VgdisMf1Jf JZNINpw0ZapFKRhLEhgtXVS7tkdxxTL0uc9XtviOTSSfxgBt2MPsj0qfhsNFFO4zUO1pJiBz SBPnLt7af96oS2ZHI4Xz7zNHShDoSMMIr+7l9xgopb5qN/KMCMP9BSxxNEfphwIDAQABo4IE IDCCBBwwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmB C/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0P BAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkq hkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFEVmlcJSxtK5Cu7FZb5XUWWuKktKMB8GA1UdIwQYMBaA FNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFMoIIBSKCCAUSGgdls ZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPXVz bmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFh BggrBgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUy MEx1Y2VudCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNl bnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MDgGCCsGAQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20v UEtJL3N1YkNBLmNydDBEBggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxj YXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwNgYDVR0RBC8wLYEranVlcmdlbi5zdG9l dHplci1icmFkbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAMrtX ZAqm6NqOAYttJjvC6pL04tEKUusax1Dr6p6NfxVfUuW8ZoFXKoxHEDaYKQR9ldfnuILHN+x7 KdLeKg+NPUs7GFGwpBmJb7PRmxnIarFJbGHzpqZ9+Fhsde1uxi+y2VJcIOVaEh/JoRdHvSUQ nwT4+FcBmS6uRv68rnCkh+KeUm6A7+6dDo/9l/Zh2Hu1+HVWw5kEH/xmO170v9Xef7efxzxv BeQ644kvErDNG26LJDUtOqaKTdz9KKZXngw+2cAV/4Kc7C9xdT29Ugm8oOK/ecqBliMhBUen WphsEDjIbKJCd40RJLKb+v49EN/IJogNDd81vtehOxDw5Lus4zGCA+0wggPpAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZIm iZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0 ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+JwAAAAFWdjANBglghkgBZQMEAgEFAKCC AikwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMjEyMTA0 NTE2WjAvBgkqhkiG9w0BCQQxIgQgpE1f/vJfF4RvK6NrA7A178+T8HQqwj4vgKF5Tmx9G1Uw bAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZIm iZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRl bCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+ JwAAAAFWdjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQK Ew5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3Vi IENBAgphYf4nAAAAAVZ2MA0GCSqGSIb3DQEBAQUABIIBADwqZn0BKslKCHxIanogB6OnELJo S9EvL0VynySrmGIKKZpHG2wZdDre/J8Ex+o3nNZbEx65rTcrEJquFkhZkz1wtxiWhhYSlIK9 LSsQ+q0NaYLSS+ZRbMyzKpzDaVRVylwAQikpXj80hgzKEMh94j0tnafKIslX8MLHnKxK1sl7 w/KKNYywf89GR1JTHUtntDr9LkQAUBnrL+4dwajGbnNo6wJgG1tpJQPqUIXQn84yCxCodJaN L2VBkeV3rwmPgbK2dNN2+9HKw2TsBppIXIbV24jucdnfWGthbdC4b1FMRGBH1qIXwtUFI/AJ AgJH1cpVoGdnHeGk73SulPNOd8gAAAAAAAA= --------------ms050500050906010000050908-- From nobody Fri Feb 12 06:45: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 54B641A039C for ; Fri, 12 Feb 2016 06:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.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 fBL71bMY0-4m for ; Fri, 12 Feb 2016 06:45:09 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773F61A0397 for ; Fri, 12 Feb 2016 06:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=629; q=dns/txt; s=iport; t=1455288309; x=1456497909; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=J3EZmSBrHoYnuH7FAxKDqyJD9B4+z1BOTUhhe1SGcbA=; b=S9qiDpLl21FPPSgIo3EpAPP/U4yiRNWaAXtss7BuV+xg0eJRYsTglHX2 Gz7v/RMNk6qYIn/peJ3PVp1uU7ceB9T1Ia4WzaOB8nb/knBj+S5ZN1YVt rshUmb635Ew+ENwYJr3hWuLzv9wOy45J+R4LXkSVdy1WPoFyuHkh/sqY1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAgCS7r1W/51dJa1egzqKGqoShQ2CE?= =?us-ascii?q?wENgWeHRjgUAQEBAQEBAYEKhGsVNgo2AgUWCwILAwIBAgFLDQgBAYgWowaPW48?= =?us-ascii?q?PAQEBBwIBHXuFFotogToBBI4biFyBFIxBiSSFUo4+HgEBQoQCHohYAQEB?= X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="scan'208";a="237679999" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 14:45:08 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1CEj835021509 for ; Fri, 12 Feb 2016 14:45:08 GMT From: Flemming Andreasen To: mmusic Message-ID: <56BDEFF4.2040803@cisco.com> Date: Fri, 12 Feb 2016 09:45:08 -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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] Preparing for IETF 95 (Buenos Aires) 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, 12 Feb 2016 14:45:10 -0000 Greetings MMUSIC IETF 95 will be April 3-8 in Buenos Aires, which will be here before you know it. MMUSIC has requested a 2.5 hour meeting slot, and as always we want to ensure we take advantage of our meeting time in a productive manner that leads to forward progress. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback already. Thus, if you haven't already, now would be a good time to raise and discuss any open issues you may have in your draft(s). Thanks -- Bo & Flemming (MMUSIC co-chairs) From nobody Fri Feb 12 06:53: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 91B731A0A85 for ; Fri, 12 Feb 2016 06:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.302 X-Spam-Level: X-Spam-Status: No, score=-13.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, 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 efLkmTepvYmy for ; Fri, 12 Feb 2016 06:52:59 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C921A09CF for ; Fri, 12 Feb 2016 06:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7464; q=dns/txt; s=iport; t=1455288778; x=1456498378; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=13ZyZxMqmrZQnVyc9/eAjTFse45YZRhrkDEzi9zMK84=; b=I+kW7sxpITUQO4Fx/OYiqINaIN7hcKtguJSksXDDSBgq4uFryKakErhK IvlV7l0+ohYuyAPlpwzQSaWkiMl2rjVt+qZg1n+5mNdMyZ/wxvlm6++oh CuC/0gGzd1bf9MdXhQK+qY39Gg36pkZJQaOOT9GQP05uIuk+JdTIFiMfe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBAAp8b1W/xbLJq1eDoN+bYhbsycXC?= =?us-ascii?q?oUiSgKCAwEBAQEBAYELhEEBAQEDAQEBASAVNgoGCwsYAgIFFgsCAgkDAgECARU?= =?us-ascii?q?wBgEMBgIBAYgOCA6yUI8QAQEBAQEBAQEBAQEBAQEBAQEBARMEe4UWhDaHMoE6B?= =?us-ascii?q?Y0ndIhcjVWJJIVSjj5igylZHi6IKgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="scan'208";a="631455172" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 14:52:56 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1CEqtMC013484; Fri, 12 Feb 2016 14:52:55 GMT To: Juergen Stoetzer-Bradler , Paul Kyzivat , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> From: Flemming Andreasen Message-ID: <56BDF1C6.9080707@cisco.com> Date: Fri, 12 Feb 2016 09:52:54 -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: <56BDB7BC.1060104@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; 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, 12 Feb 2016 14:53:01 -0000 On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: > Flemming, Paul, > > The current a=dcmap related text in > draft-ietf-mmusic-data-channel-sdpneg doesn't require that the > 'subprotocol' parameter must always be present - rather it is > specified as an optional parameter. Thus, current sdpneg text would > allow to create an SDP offer for a data channel, which contains one > a=dcmap attribute and potentially multiple a=dcsa attributes without > the subprotocol actually being given. Based on this discussion I am > wondering if the subprotocol parameter should actually be mandatory. > It would probably simplify the overall SDP negotiation part, but I don't know if it would constrain the way data channels were envisioned to be used. > In the specific case of MSRP, the msrp-usage-data-channel draft says > in 5.1.1.1 that the dcmap attribute includes the label and subprotocol > parameters. The current text could possible be made more explicit by > saying that the 'subprotocol="MSRP"' parameter must always be present. > Have just submitted version 04 of the msrp-usage-data-channel draft, > which proposes to add subprotocol identifier "MSRP" to the WebSocket > Subprotocol Name registry. This registry would then associate > subprotocol id "MSRP" with the msrp-usage-data-channel document. > There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa > attribute are specified. And there the MSRP specific SDP attributes, > which can be dcsa embedded, are described. > 'setup' is an attribute, whose semantic changes when being dcsa > embedded and associated with subprotocol MSRP, as compared to the > meaning of an "a=setup" media level attribute of a TCP/MSRP m-line. > Hence these semantical differences are explicitly addressed in the > msrp-usage-data-channel draft. > > Regarding sdpneg, I also think that the current text in sdpneg seems > to be sufficient regarding the usage of dcsa encapsulated SDP > attributes as being bound to the data channel's subprotocol. But as > the semantic of a dcsa encapsulated attribute may be subprotocol > specific (like 'setup'), I'd now tend to consider the subprotocol > parameter in the dcmap attribute as being mandatory, as mentioned > above. As already discussed, the Websocket subprotocol registry would > then refer to the document, which specifies the subprotocol specific > usage of dcsa encapsulated parameters. > Ok. Going back to discussion between Paul and I, do you believe that in for an attribute to be encapsulated in dcsa, the attribute MUST have been explicitly define to support this (Paul's suggestion below) or do you believe that this is overly constraining, and if so, how shoud we relax it ? Thanks -- Flemming > Thanks, > Juergen > > > On 11.02.2016 21:52, Flemming Andreasen wrote: >> >> >> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>> >>>> >>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>> Isn't this the approach we're taking today? >>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>> draft-ietf-clue-datachannel). >>>>> >>>>> It remains to be seen if that will be enough. E.g., there currently >>>>> aren't any iana considerations in >>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>> >>>>> Suppose I encounter some sdp that uses msrp over a data channel, but >>>>> that usage is unknown to me. How do I find the spec (the reference to >>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>>> >>>>> I would like to think that the iana registries will allow me to trace >>>>> back to the relevant specs. >>>>> >>>> No disagreement on that part, however having taken another look at >>>> both >>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>> original request for all (existing and new) attributes to specify how >>>> they may or may not be used with the dcsa attribute defined by sdpneg. >>>> >>>> As Christian noted, the sub-protocol specifics are defined in >>>> individual >>>> documents (like msrp-usage), which calls your the parameters that >>>> are at >>>> least needed to be supported for that usage. Taking MSRP as an >>>> example, >>>> why isn't that enough, and how do you see the resulting set of >>>> attributes that may or may not be used with MSRP differ between use >>>> in a >>>> data-channel (and hence encapsulated in dcsa) or as a regular media >>>> stream ? >>> >>> Based on this discussion, I conclude that it should be sufficient >>> for this draft to say that before an attribute can be used with >>> dcsa, such usage must be defined somewhere. This could be either: >>> - as part of the definition of the attribute, OR >>> - as part of the definition of the protocol referenced on the m-line. >>> >> We are getting closer, but it's still not obvious to me that you >> cannot use an attribute with dcsa if it has not been explicitly >> defined for the attribute in question. Clearly, there are attributes >> that wouldn't make sense over data channels, just like there are >> attributes that don't make sense over particular media descriptions. >> >> Again, I'd like to hear from more people on this, including the authors. >> >> Thanks >> >> -- Flemming >> >> >> >>> Thanks, >>> Paul >>> >>>> Also, it would be good to hear from more people on this, including the >>>> document authors. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>> >>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>> need to >>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>> should be >>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>> point is >>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>> interactions as >>>>>>>> opposed to relying on a more general algorithmic approach (plus >>>>>>>> the >>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>> wants to >>>>>>>> establish a data channel). >>>>>>> >>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>> pertains to >>>>>>> need to be defined to work over data channels. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Fri Feb 12 08:40: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 232D41A6FA7 for ; Fri, 12 Feb 2016 08:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIC1jnoUeEg7 for ; Fri, 12 Feb 2016 08:40:47 -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 1661C1A6F98 for ; Fri, 12 Feb 2016 08:40:46 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-d9-56be0b0ded7f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0A.E6.02707.D0B0EB65; Fri, 12 Feb 2016 17:40:45 +0100 (CET) Received: from m46.nomadiclab.com (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Fri, 12 Feb 2016 17:40:44 +0100 To: Flemming Andreasen , Christer Holmberg , mmusic References: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@ESESSMB209.ericsson.se> <56B8C271.5000101@cisco.com> From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= Message-ID: <56BE0B0C.2090507@ericsson.com> Date: Fri, 12 Feb 2016 18:40:44 +0200 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: <56B8C271.5000101@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM2K7ty4v974wg5lTBSzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbFh2XnWgvscFXf+nWBuYPzH1sXIySEhYCKx fuEzJghbTOLCvfVAcS4OIYHDjBILX+5kgnDWMUp833IdrENYwFti/c/3jCC2iEC1RO+WL6wg tpBAjsSLo7fBatgEbCV+t+8Bm8oroC1xbvVxFhCbRUBVYvbCA2C9ogJpEvtn/4aqEZQ4OfMJ UA0HB6eApsT0VdEgJrOAvcSDrWUgFcwC8hLNW2czQ2xSlbj67xXjBEaBWUiaZyF0zELSsYCR eRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYEAe3PLbYAfjy+eOhxgFOBiVeHgNbu0JE2JN LCuuzD3EKMHBrCTCa9C0N0yINyWxsiq1KD++qDQntfgQozQHi5I472rn9WFCAumJJanZqakF qUUwWSYOTqkGxuANOndMn5ZMirk6/ahNWc+l/YUznpbb7NgdPevF7y0e1zeWVVR/7hOJWBt+ x+7TV/ubHy9fKvrfbsr9eEdc7hyTDeaHCtx2SjdzGK5+LSjZI9VaFCR7JIM70s7YZ14X3/17 CefvXzvyWTrbccLlhCOMkT0igvzT96mqViSdvnzT26Fw08UVvUosxRmJhlrMRcWJAIkBUpVE AgAA Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-01 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, 12 Feb 2016 16:40:49 -0000 Hi, Looks good and ready for WGLC. Cheers, Ari On 08/02/16 18:29, Flemming Andreasen wrote: > Folks, > > Please take a look at the draft and let us know if you think it is ready > (or not) for WGLC at this point. > > Thanks > > -- Flemming (MMUSIC co-chair). > > On 2/6/16 6:02 AM, Christer Holmberg wrote: >> >> Hi, >> >> Ive submitted a new version (-01) of draft-mux-exclusive. >> >> The main difference compared to the previous version is that the draft >> now defines a new SDP attribute, rtcp-mux-exclusive, to indicate >> exclusive support of, and negotiate usage of, RTP/RTCP multiplexing. >> >> There are currently no open issues in the draft, so I encourage people >> to take a look, so that we can start moving towards WGLC. >> >> 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 Fri Feb 12 08:59: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 C84F11A7000 for ; Fri, 12 Feb 2016 08:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, 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 sj9SxHiM1ea7 for ; Fri, 12 Feb 2016 08:58:59 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679E01A6FFA for ; Fri, 12 Feb 2016 08:58:59 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-10v.sys.comcast.net with comcast id HUya1s0062Ka2Q501UyyM9; Fri, 12 Feb 2016 16:58:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with comcast id HUyx1s00h3KdFy101Uyy7A; Fri, 12 Feb 2016 16:58:58 +0000 To: Juergen Stoetzer-Bradler , Flemming Andreasen , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56BE0F51.7050700@alum.mit.edu> Date: Fri, 12 Feb 2016 11:58: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: <56BDB7BC.1060104@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455296338; bh=zVYVk2sYDd1sl3B07bm7uNsZCr3WV1pAGkgtM7zkwok=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=R0RN/7cxmTyTh9ctumPOoGGVk/w86VWxz+LEI6oixgc0bY0xMq/hx/1btgirIxqI9 2ntKgAjvgwTrZGvwQqIqNcuPHTxqHZWIBqNICpqJSPg3Nrh7z3LKXip7YNEK8tm7hk q+LTs1XeJ1CizQPuCRex4Md5PXl5dsSzGT9WcMAkRKYdym62NF9IEjAgk4p2ohN7PH 849i7fBhM2ou8GxFqnQ52SWV/ZO2htWRzOky4KdEBJQ6XckcqnJv8ur5GqH5DOQaYD lk8BvVteoZCcyz+V9r+oJOt8TWXXURIY36MBnCde7UWd74Lukzv83aD/DBtUKeBa6g rAuzPjtlp6zQw== 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, 12 Feb 2016 16:59:01 -0000 Juergen, You bring up a point that perhaps needs further discussion: what does it mean when the subprotocol is not specified? IIUC there are at least a couple of reasons this might come about: 1) The protocol to be used is not standardized. There is no globally unique name for it. The two ends know what protocol to use based on context. 2) The protocol to be used on the channel is not determined via SDP negotiation. The applications want to establish the channel, and then dynamically decide what protocol to use with it. (And that protocol may change over time.) I guess that it still might be meaningful to use dcsa with (1), but there would be no way to determine by examination of the SDP whether the usage was compatible with the protocol. In this case the usage of the attributes would be "off label" - being adapted to the proprietary protocol in a way that hopefully the two ends agree. I don't see how dcsa makes much sense for (2). If you don't know what protocol will be used then how do you know what attributes to use? Thanks, Paul On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: > Flemming, Paul, > > The current a=dcmap related text in > draft-ietf-mmusic-data-channel-sdpneg doesn't require that the > 'subprotocol' parameter must always be present - rather it is specified > as an optional parameter. Thus, current sdpneg text would allow to > create an SDP offer for a data channel, which contains one a=dcmap > attribute and potentially multiple a=dcsa attributes without the > subprotocol actually being given. Based on this discussion I am > wondering if the subprotocol parameter should actually be mandatory. > > In the specific case of MSRP, the msrp-usage-data-channel draft says in > 5.1.1.1 that the dcmap attribute includes the label and subprotocol > parameters. The current text could possible be made more explicit by > saying that the 'subprotocol="MSRP"' parameter must always be present. > Have just submitted version 04 of the msrp-usage-data-channel draft, > which proposes to add subprotocol identifier "MSRP" to the WebSocket > Subprotocol Name registry. This registry would then associate > subprotocol id "MSRP" with the msrp-usage-data-channel document. > There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa > attribute are specified. And there the MSRP specific SDP attributes, > which can be dcsa embedded, are described. > 'setup' is an attribute, whose semantic changes when being dcsa embedded > and associated with subprotocol MSRP, as compared to the meaning of an > "a=setup" media level attribute of a TCP/MSRP m-line. Hence these > semantical differences are explicitly addressed in the > msrp-usage-data-channel draft. > > Regarding sdpneg, I also think that the current text in sdpneg seems to > be sufficient regarding the usage of dcsa encapsulated SDP attributes as > being bound to the data channel's subprotocol. But as the semantic of a > dcsa encapsulated attribute may be subprotocol specific (like 'setup'), > I'd now tend to consider the subprotocol parameter in the dcmap > attribute as being mandatory, as mentioned above. As already discussed, > the Websocket subprotocol registry would then refer to the document, > which specifies the subprotocol specific usage of dcsa encapsulated > parameters. > > Thanks, > Juergen > > > On 11.02.2016 21:52, Flemming Andreasen wrote: >> >> >> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>> >>>> >>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>> Isn't this the approach we're taking today? >>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>> draft-ietf-clue-datachannel). >>>>> >>>>> It remains to be seen if that will be enough. E.g., there currently >>>>> aren't any iana considerations in >>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>> >>>>> Suppose I encounter some sdp that uses msrp over a data channel, but >>>>> that usage is unknown to me. How do I find the spec (the reference to >>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>>> >>>>> I would like to think that the iana registries will allow me to trace >>>>> back to the relevant specs. >>>>> >>>> No disagreement on that part, however having taken another look at both >>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>> original request for all (existing and new) attributes to specify how >>>> they may or may not be used with the dcsa attribute defined by sdpneg. >>>> >>>> As Christian noted, the sub-protocol specifics are defined in >>>> individual >>>> documents (like msrp-usage), which calls your the parameters that >>>> are at >>>> least needed to be supported for that usage. Taking MSRP as an example, >>>> why isn't that enough, and how do you see the resulting set of >>>> attributes that may or may not be used with MSRP differ between use >>>> in a >>>> data-channel (and hence encapsulated in dcsa) or as a regular media >>>> stream ? >>> >>> Based on this discussion, I conclude that it should be sufficient for >>> this draft to say that before an attribute can be used with dcsa, >>> such usage must be defined somewhere. This could be either: >>> - as part of the definition of the attribute, OR >>> - as part of the definition of the protocol referenced on the m-line. >>> >> We are getting closer, but it's still not obvious to me that you >> cannot use an attribute with dcsa if it has not been explicitly >> defined for the attribute in question. Clearly, there are attributes >> that wouldn't make sense over data channels, just like there are >> attributes that don't make sense over particular media descriptions. >> >> Again, I'd like to hear from more people on this, including the authors. >> >> Thanks >> >> -- Flemming >> >> >> >>> Thanks, >>> Paul >>> >>>> Also, it would be good to hear from more people on this, including the >>>> document authors. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>> >>>>>>>> I'm not concerned about the IANA part. I agree that *if* we need to >>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>> should be >>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>> point is >>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>> interactions as >>>>>>>> opposed to relying on a more general algorithmic approach (plus the >>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>> wants to >>>>>>>> establish a data channel). >>>>>>> >>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>> pertains to >>>>>>> need to be defined to work over data channels. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Fri Feb 12 09:39: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 6FCB11A8715 for ; Fri, 12 Feb 2016 09:39:53 -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 Pgflz2E4lS_7 for ; Fri, 12 Feb 2016 09:39:52 -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 31BC61A7030 for ; Fri, 12 Feb 2016 09:39:52 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-03v.sys.comcast.net with comcast id HVfF1s00526dK1R01Vfrfr; Fri, 12 Feb 2016 17:39:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id HVfq1s00Y3KdFy101Vfqd3; Fri, 12 Feb 2016 17:39:51 +0000 To: Flemming Andreasen , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "bradler >> Juergen Stoetzer-Bradler" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BCF663.7020708@alum.mit.edu> <56BCF97F.8000404@cisco.com> From: Paul Kyzivat Message-ID: <56BE18E6.2050306@alum.mit.edu> Date: Fri, 12 Feb 2016 12:39:50 -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: <56BCF97F.8000404@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=1455298791; bh=EbKvpAoKTvT1HQjM6KX4Gq+3PwntWLd2hNstYUqr4ig=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BWDllmJP3Ib3LQxhWWh4Gwv7qR09ZiVaYTCb4r4Dp3zWiHYSHhf7Uf8BGBTiSaklz 0XoPimqxFDAGXHBCY4dGE6JqX2FgSLwRZA3Lz6dTfE8F5r3vfzZsjnHQx5oyTdufA1 iR84729fIQyFLM5+D+zYm0+bDGUkD6iiF16rw6hwcBfLIG2I1eFUKtFVDGl1WAO5Iz 5pkhQ6W1PjjE4q7OKZ8xa0nANgsEWae3vKdMwtc/py+DXXBNGm2dBon+v8V2m+ugfZ wx4ucpwFeDtnIt/W2Pt9RNKLrkvO3JFBBERRg+I1HThJDPj+ZjSkp/Sl+Q752RMG/v RX3A4y2SwX7cw== Archived-At: Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org 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, 12 Feb 2016 17:39:53 -0000 On 2/11/16 4:13 PM, Flemming Andreasen wrote: >>> We are getting closer, but it's still not obvious to me that you cannot >>> use an attribute with dcsa if it has not been explicitly defined for the >>> attribute in question. >> >> Can you give me an example? >> > How about preconditions ? I don't see how any of the currently defined precondition types (connectivity, qos, security) make sense at the data channel level. But all of them could make sense when applied to the overall SCTP association over which the channels run. I suppose *in theory* some hypothetical new precondition type might apply to a channel, but we have nothing suggesting that. I will grant that we could just take the position that any attribute can be used anywhere, and that the general "ignore if you don't understand" rule will prevent problems. My basic concern is that when an attribute is used in some context, that the semantics for such use are well defined, so that an independent observer can determine whether the usage is proper. Thanks, Paul From nobody Fri Feb 12 13:49: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 378DE1A905F for ; Fri, 12 Feb 2016 13:49:33 -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 byPWmzh3Aw73 for ; Fri, 12 Feb 2016 13:49:31 -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 412D61A905C for ; Fri, 12 Feb 2016 13:49:31 -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 u1CLnT9b092074 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Feb 2016 15:49:30 -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: Fri, 12 Feb 2016 15:49:29 -0600 Message-ID: <6F6B56C7-A8FD-40DD-8969-F1AB91D23669@nostrum.com> In-Reply-To: References: <20160126083201.8874.25316.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: mmusic WG 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: Fri, 12 Feb 2016 21:49:33 -0000 Thanks Suhas, I think this version is ready for IETF last call. I will = request that shortly. Thanks! Ben On 26 Jan 2016, at 2:33, Suhas Nandakumar wrote: > 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-registra= tion/ >> >> 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-regis= tration-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 >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Feb 12 14:03:24 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 6DC7B1A90A8; Fri, 12 Feb 2016 14:03:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160212220319.12900.61349.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 14:03:19 -0800 Archived-At: Cc: ben@nostrum.com, draft-ietf-mmusic-proto-iana-registration@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org Subject: [MMUSIC] Last Call: (IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 22:03:19 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Feb 14 02:48: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 33EC61B3C9A for ; Sun, 14 Feb 2016 02:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 txIOWOsXifq5 for ; Sun, 14 Feb 2016 02:48:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 287F01B3C91 for ; Sun, 14 Feb 2016 02:48:08 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 29CE87470BAA; Sun, 14 Feb 2016 10:48:04 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1EAm5ew005438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 14 Feb 2016 10:48:05 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1EAm57p004029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Feb 2016 11:48:05 +0100 Received: from [135.224.208.133] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 14 Feb 2016 11:48:04 +0100 To: EXT Flemming Andreasen , Paul Kyzivat , , "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> From: Juergen Stoetzer-Bradler Message-ID: <56C05B63.4030007@alcatel-lucent.com> Date: Sun, 14 Feb 2016 11:48:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BDF1C6.9080707@cisco.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [135.239.27.38] 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: Sun, 14 Feb 2016 10:48:13 -0000 Flemming, Regarding > It would probably simplify the overall SDP negotiation part, but I don'= t know if it would=20 > constrain the way data channels were envisioned to be used.=20 On Friday Paul mentioned in his email two potential use cases, where no s= ubprotocol identifiers=20 might be added to a data channel's dcmap attribute. In my last email I ha= dn't thought of such cases.=20 If we don't want to exclude such cases, then requiring the subprotocol id= s always to be present=20 might indeed be too restrictive. Regarding > Ok. Going back to discussion between Paul and I, do you believe that in= for an attribute to be=20 > encapsulated in dcsa, the attribute MUST have been explicitly define to= support this (Paul's=20 > suggestion below) or do you believe that this is overly constraining, a= nd if so, how shoud we=20 > relax it ?=20 I now think that the sdpneg draft might recommend SDP offerers and answer= ers to always add a=20 subprotocol identifier to a data channel's dcmap attribute if dcsa embedd= ed attributes are also=20 negotiated for the data channel's subprotocol. I also think we could expl= icitly add text to sdpneg=20 saying that subprotocol identifiers should be added to the IANA Websocket= (and in future combined=20 data channel) registry. And that this registration should be done via a d= ocument, which then=20 explicitly describes the usages and semantics of dcsa embedded subprotoco= l attributes, _if_ those=20 usages or semantics deviate from cases, where these attributes are not dc= sa encapsulated. I think=20 that in those cases, where the usage and meaning of an attribute (always = related to the data=20 channel's subprotocol) does not deviate from the non-dcsa encapsulated us= e cases, such an attribute=20 may not explicitly need to be described for data channel usage. But I thi= nk it might be helpful to=20 explicitly say so in the sdpneg draft. Somebody inspecting an SDP offer or answer, which was generated by an imp= lementation following these=20 two recommendations (and which hence contains an IANA registered subproto= col id if it contains any=20 dcsa embedded attributes), could then refer to that IANA table, would the= n find the reference to the=20 document, which defines this subprotocol id for data channel usage, and t= here could check if any of=20 the dcsa embedded attributes has a data channel specific semantic. If yes= , that specific semantic=20 would be described in that document. If such a specific semantic were not= described in that=20 document, then the default usage and semantic of the attribute would appl= y also to that data channel=20 transport case. But in that context I'd have an IANA table related question. A certain subprotocol might be defined for Websocket usage as well as for= data channel usage. MSRP=20 is already such a case, where draft-ietf-mmusic-msrp-usage-data-channel d= efines how to use MSRP over=20 data channels, and where draft-pd-dispatch-msrp-websocket defines how to = use MSRP over Websockets. Would the IANA WebSocket Subprotocol Name Registry on=20 http://www.iana.org/assignments/websocket/websocket.xml then contain two = MSRP related rows? Or just=20 one row containing references to both the Websocket and data channel docu= ments? Should we add related text to the IANA registration section of the sdpneg= draft? Thanks, Juergen On 12.02.2016 15:52, EXT Flemming Andreasen wrote: > > > On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >> Flemming, Paul, >> >> The current a=3Ddcmap related text in draft-ietf-mmusic-data-channel-s= dpneg doesn't require that=20 >> the 'subprotocol' parameter must always be present - rather it is spec= ified as an optional=20 >> parameter. Thus, current sdpneg text would allow to create an SDP offe= r for a data channel, which=20 >> contains one a=3Ddcmap attribute and potentially multiple a=3Ddcsa att= ributes without the subprotocol=20 >> actually being given. Based on this discussion I am wondering if the s= ubprotocol parameter should=20 >> actually be mandatory. >> > It would probably simplify the overall SDP negotiation part, but I don'= t know if it would=20 > constrain the way data channels were envisioned to be used. > > >> In the specific case of MSRP, the msrp-usage-data-channel draft says i= n 5.1.1.1 that the dcmap=20 >> attribute includes the label and subprotocol parameters. The current t= ext could possible be made=20 >> more explicit by saying that the 'subprotocol=3D"MSRP"' parameter must= always be present. >> Have just submitted version 04 of the msrp-usage-data-channel draft, w= hich proposes to add=20 >> subprotocol identifier "MSRP" to the WebSocket Subprotocol Name regist= ry. This registry would=20 >> then associate subprotocol id "MSRP" with the msrp-usage-data-channel = document. >> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa att= ribute are specified. And=20 >> there the MSRP specific SDP attributes, which can be dcsa embedded, ar= e described. >> 'setup' is an attribute, whose semantic changes when being dcsa embedd= ed and associated with=20 >> subprotocol MSRP, as compared to the meaning of an "a=3Dsetup" media l= evel attribute of a TCP/MSRP=20 >> m-line. Hence these semantical differences are explicitly addressed in= the=20 >> msrp-usage-data-channel draft. >> >> Regarding sdpneg, I also think that the current text in sdpneg seems t= o be sufficient regarding=20 >> the usage of dcsa encapsulated SDP attributes as being bound to the da= ta channel's subprotocol.=20 >> But as the semantic of a dcsa encapsulated attribute may be subprotoco= l specific (like 'setup'),=20 >> I'd now tend to consider the subprotocol parameter in the dcmap attrib= ute as being mandatory, as=20 >> mentioned above. As already discussed, the Websocket subprotocol regis= try would then refer to the=20 >> document, which specifies the subprotocol specific usage of dcsa encap= sulated parameters. >> > Ok. Going back to discussion between Paul and I, do you believe that in= for an attribute to be=20 > encapsulated in dcsa, the attribute MUST have been explicitly define to= support this (Paul's=20 > suggestion below) or do you believe that this is overly constraining, a= nd if so, how shoud we=20 > relax it ? > > Thanks > > -- Flemming > > >> Thanks, >> Juergen >> >> >> On 11.02.2016 21:52, Flemming Andreasen wrote: >>> >>> >>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>> >>>>> >>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>> Isn't this the approach we're taking today? >>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specif= ic >>>>>>> drafts are used to describe protocols that use the mechanism (i.e= =2E >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>> draft-ietf-clue-datachannel). >>>>>> >>>>>> It remains to be seen if that will be enough. E.g., there currentl= y >>>>>> aren't any iana considerations in >>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>> >>>>>> Suppose I encounter some sdp that uses msrp over a data channel, b= ut >>>>>> that usage is unknown to me. How do I find the spec (the reference= to >>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage= ? >>>>>> >>>>>> I would like to think that the iana registries will allow me to tr= ace >>>>>> back to the relevant specs. >>>>>> >>>>> No disagreement on that part, however having taken another look at = both >>>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>>> original request for all (existing and new) attributes to specify h= ow >>>>> they may or may not be used with the dcsa attribute defined by sdpn= eg. >>>>> >>>>> As Christian noted, the sub-protocol specifics are defined in indiv= idual >>>>> documents (like msrp-usage), which calls your the parameters that a= re at >>>>> least needed to be supported for that usage. Taking MSRP as an exam= ple, >>>>> why isn't that enough, and how do you see the resulting set of >>>>> attributes that may or may not be used with MSRP differ between use= in a >>>>> data-channel (and hence encapsulated in dcsa) or as a regular media= >>>>> stream ? >>>> >>>> Based on this discussion, I conclude that it should be sufficient fo= r this draft to say that=20 >>>> before an attribute can be used with dcsa, such usage must be define= d somewhere. This could be=20 >>>> either: >>>> - as part of the definition of the attribute, OR >>>> - as part of the definition of the protocol referenced on the m-line= =2E >>>> >>> We are getting closer, but it's still not obvious to me that you cann= ot use an attribute with=20 >>> dcsa if it has not been explicitly defined for the attribute in quest= ion. Clearly, there are=20 >>> attributes that wouldn't make sense over data channels, just like the= re are attributes that=20 >>> don't make sense over particular media descriptions. >>> >>> Again, I'd like to hear from more people on this, including the autho= rs. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> >>>> Thanks, >>>> Paul >>>> >>>>> Also, it would be good to hear from more people on this, including = the >>>>> document authors. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>> >>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we nee= d to >>>>>>>>> expliclty specify attribute interactions for "dcsa", then it sh= ould be >>>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>>> point is >>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>> interactions as >>>>>>>>> opposed to relying on a more general algorithmic approach (plus= the >>>>>>>>> offerer being responsible for generating a valid offer if he wa= nts to >>>>>>>>> establish a data channel). >>>>>>>> >>>>>>>> Well, an obvious one is that the protocol(s) the attribute perta= ins to >>>>>>>> need to be defined to work over data channels. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> From nobody Sun Feb 14 02:48: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 8D3711B3C9A for ; Sun, 14 Feb 2016 02:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 IcvTwF1SDr87 for ; Sun, 14 Feb 2016 02:48:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 277711B3C98 for ; Sun, 14 Feb 2016 02:48:52 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 86DB8857B4882; Sun, 14 Feb 2016 10:48:48 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1EAmoMF006657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 14 Feb 2016 10:48:50 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1EAmoiY004263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Feb 2016 11:48:50 +0100 Received: from [135.224.208.133] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 14 Feb 2016 11:48:49 +0100 To: EXT Paul Kyzivat , Flemming Andreasen , , "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" 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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> From: Juergen Stoetzer-Bradler Message-ID: <56C05B90.5070107@alcatel-lucent.com> Date: Sun, 14 Feb 2016 11:48:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BE0F51.7050700@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------090805020501040504070607" X-Originating-IP: [135.239.27.39] 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: Sun, 14 Feb 2016 10:48:56 -0000 --------------090805020501040504070607 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Paul, In your case 2) I would agree that the usage of dcsa embedded attributes = seems questionable. After=20 all, the dcsa attribute is defined in sdpneg as encapsulating a subprotoc= ol specific attribute. If=20 the subprotocol may dynamically change over time without further (SDP off= er/answer) negotiation,=20 then a negotiation of dcsa embedded attributes may indeed not be very hel= pful. In your case 1), I am wondering how would the SDP answerer know which sub= protocol to use for which=20 data channel, if the subprotocol id is not added to the data channel's dm= ap attribute (at least if=20 multiple data channels are negotiated)? Conceivably via some provisioning= , or via a mutual=20 understanding of a certain subprotocol to SCTP stream id mapping, or via = a certain a priori agreed=20 label usage. I hadn't thought of such cases when raising the question if = the subprotocol should=20 actually be mandatory. But such use cases would certainly go beyond a pure SDP offer/answer nego= tiation use case and I=20 would argue that such use cases would also go beyond the scope of the sdp= neg draft. I could now imagine the sdpneg draft saying that an SDP offerer should ad= d a subprotocol identifier=20 to an offered data channel's dcmap attribute, if it also adds dcsa embedd= ed subprotocol attributes.=20 And that an implementation would be on its own, if it does not follow tha= t recommendation (for=20 whatever reasons). Further, similar as for non-dcsa embedded attributes, we could explicitly= add text to the sdpneg=20 draft saying that a recipient of an an SDP offer or answer should ignore = dcsa embedded attributes=20 not only if they are completely unknown, but also if their semantics rela= ted to the subprotocol is=20 not known. (The current draft says in sec 5.2.3 that the SDP answerer "/Parses and a= pplies the SDP offer. Note=20 that the typical parser normally ignores unknown SDP attributes, which in= cludes data channel related=20 attributes./" I think we could make this clearer and explicitly refer to = dcsa embedded subprotocol=20 attributes.) Thanks, Juergen On 12.02.2016 17:58, EXT Paul Kyzivat wrote: > Juergen, > > You bring up a point that perhaps needs further discussion: what does i= t mean when the subprotocol=20 > is not specified? > > IIUC there are at least a couple of reasons this might come about: > > 1) The protocol to be used is not standardized. There is no globally un= ique name for it. The two=20 > ends know what protocol to use based on context. > > 2) The protocol to be used on the channel is not determined via SDP neg= otiation. The applications=20 > want to establish the channel, and then dynamically decide what protoco= l to use with it. (And that=20 > protocol may change over time.) > > I guess that it still might be meaningful to use dcsa with (1), but the= re would be no way to=20 > determine by examination of the SDP whether the usage was compatible wi= th the protocol. In this=20 > case the usage of the attributes would be "off label" - being adapted t= o the proprietary protocol=20 > in a way that hopefully the two ends agree. > > I don't see how dcsa makes much sense for (2). If you don't know what p= rotocol will be used then=20 > how do you know what attributes to use? > > Thanks, > Paul > > On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >> Flemming, Paul, >> >> The current a=3Ddcmap related text in >> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >> 'subprotocol' parameter must always be present - rather it is specifie= d >> as an optional parameter. Thus, current sdpneg text would allow to >> create an SDP offer for a data channel, which contains one a=3Ddcmap >> attribute and potentially multiple a=3Ddcsa attributes without the >> subprotocol actually being given. Based on this discussion I am >> wondering if the subprotocol parameter should actually be mandatory. >> >> In the specific case of MSRP, the msrp-usage-data-channel draft says i= n >> 5.1.1.1 that the dcmap attribute includes the label and subprotocol >> parameters. The current text could possible be made more explicit by >> saying that the 'subprotocol=3D"MSRP"' parameter must always be presen= t. >> Have just submitted version 04 of the msrp-usage-data-channel draft, >> which proposes to add subprotocol identifier "MSRP" to the WebSocket >> Subprotocol Name registry. This registry would then associate >> subprotocol id "MSRP" with the msrp-usage-data-channel document. >> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa >> attribute are specified. And there the MSRP specific SDP attributes, >> which can be dcsa embedded, are described. >> 'setup' is an attribute, whose semantic changes when being dcsa embedd= ed >> and associated with subprotocol MSRP, as compared to the meaning of an= >> "a=3Dsetup" media level attribute of a TCP/MSRP m-line. Hence these >> semantical differences are explicitly addressed in the >> msrp-usage-data-channel draft. >> >> Regarding sdpneg, I also think that the current text in sdpneg seems t= o >> be sufficient regarding the usage of dcsa encapsulated SDP attributes = as >> being bound to the data channel's subprotocol. But as the semantic of= a >> dcsa encapsulated attribute may be subprotocol specific (like 'setup')= , >> I'd now tend to consider the subprotocol parameter in the dcmap >> attribute as being mandatory, as mentioned above. As already discussed= , >> the Websocket subprotocol registry would then refer to the document, >> which specifies the subprotocol specific usage of dcsa encapsulated >> parameters. >> >> Thanks, >> Juergen >> >> >> On 11.02.2016 21:52, Flemming Andreasen wrote: >>> >>> >>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>> >>>>> >>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>> Isn't this the approach we're taking today? >>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specif= ic >>>>>>> drafts are used to describe protocols that use the mechanism (i.e= =2E >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>> draft-ietf-clue-datachannel). >>>>>> >>>>>> It remains to be seen if that will be enough. E.g., there currentl= y >>>>>> aren't any iana considerations in >>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>> >>>>>> Suppose I encounter some sdp that uses msrp over a data channel, b= ut >>>>>> that usage is unknown to me. How do I find the spec (the reference= to >>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage= ? >>>>>> >>>>>> I would like to think that the iana registries will allow me to tr= ace >>>>>> back to the relevant specs. >>>>>> >>>>> No disagreement on that part, however having taken another look at = both >>>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>>> original request for all (existing and new) attributes to specify h= ow >>>>> they may or may not be used with the dcsa attribute defined by sdpn= eg. >>>>> >>>>> As Christian noted, the sub-protocol specifics are defined in >>>>> individual >>>>> documents (like msrp-usage), which calls your the parameters that >>>>> are at >>>>> least needed to be supported for that usage. Taking MSRP as an exam= ple, >>>>> why isn't that enough, and how do you see the resulting set of >>>>> attributes that may or may not be used with MSRP differ between use= >>>>> in a >>>>> data-channel (and hence encapsulated in dcsa) or as a regular media= >>>>> stream ? >>>> >>>> Based on this discussion, I conclude that it should be sufficient fo= r >>>> this draft to say that before an attribute can be used with dcsa, >>>> such usage must be defined somewhere. This could be either: >>>> - as part of the definition of the attribute, OR >>>> - as part of the definition of the protocol referenced on the m-line= =2E >>>> >>> We are getting closer, but it's still not obvious to me that you >>> cannot use an attribute with dcsa if it has not been explicitly >>> defined for the attribute in question. Clearly, there are attributes >>> that wouldn't make sense over data channels, just like there are >>> attributes that don't make sense over particular media descriptions. >>> >>> Again, I'd like to hear from more people on this, including the autho= rs. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> >>>> Thanks, >>>> Paul >>>> >>>>> Also, it would be good to hear from more people on this, including = the >>>>> document authors. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>> >>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we nee= d to >>>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>>> should be >>>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>>> point is >>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>> interactions as >>>>>>>>> opposed to relying on a more general algorithmic approach (plus= the >>>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>>> wants to >>>>>>>>> establish a data channel). >>>>>>>> >>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>> pertains to >>>>>>>> need to be defined to work over data channels. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> . >>>> >>> >> >> > --------------090805020501040504070607 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Paul,

In your case 2) I would agree that the usage of dcsa embedded attributes seems questionable. After all, the dcsa attribute is defined in sdpneg as encapsulating a subprotocol specific attribute. If the subprotocol may dynamically change over time without further (SDP offer/answer) negotiation, then a negotiation of dcsa embedded attributes may indeed not be very helpful.
 
In your case 1), I am wondering how would the SDP answerer know which subprotocol to use for which data channel, if the subprotocol id is not added to the data channel's dmap attribute (at least if multiple data channels are negotiated)? Conceivably via some provisioning, or via a mutual understanding of a certain subprotocol to SCTP stream id mapping, or via a certain a priori agreed label usage. I hadn't thought of such cases when raising the question if the subprotocol should actually be mandatory.
But such use cases would certainly go beyond a pure SDP offer/answer negotiation use case and I would argue that such use cases would also go beyond the scope of the sdpneg draft.

I could now imagine the sdpneg draft saying that an SDP offerer should add a subprotocol identifier to an offered data channel's dcmap attribute, if it also adds dcsa embedded subprotocol attributes. And that an implementation would be on its own, if it does not follow that recommendation (for whatever reasons).
Further, similar as for non-dcsa embedded attributes, we could explicitly add text to the sdpneg draft saying that a recipient of an an SDP offer or answer should ignore dcsa embedded attributes not only if they are completely unknown, but also if their semantics related to the subprotocol is not known.
(The current draft says in sec 5.2.3 that the SDP answerer "Parses and applies the SDP offer.  Note that the typical parser normally ignores unknown SDP attributes, which includes data channel related attributes." I think we could make this clearer and explicitly refer to dcsa embedded subprotocol attributes.)

Thanks,
Juergen

On 12.02.2016 17:58, EXT Paul Kyzivat wrote:
Juergen,

You bring up a point that perhaps needs further discussion: what does it mean when the subprotocol is not specified?

IIUC there are at least a couple of reasons this might come about:

1) The protocol to be used is not standardized. There is no globally unique name for it. The two ends know what protocol to use based on context.

2) The protocol to be used on the channel is not determined via SDP negotiation. The applications want to establish the channel, and then dynamically decide what protocol to use with it. (And that protocol may change over time.)

I guess that it still might be meaningful to use dcsa with (1), but there would be no way to determine by examination of the SDP whether the usage was compatible with the protocol. In this case the usage of the attributes would be "off label" - being adapted to the proprietary protocol in a way that hopefully the two ends agree.

I don't see how dcsa makes much sense for (2). If you don't know what protocol will be used then how do you know what attributes to use?

    Thanks,
    Paul

On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote:
Flemming, Paul,

The current a=dcmap related text in
draft-ietf-mmusic-data-channel-sdpneg doesn't require that the
'subprotocol' parameter must always be present - rather it is specified
as an optional parameter. Thus, current sdpneg text would allow to
create an SDP offer for a data channel, which contains one a=dcmap
attribute and potentially multiple a=dcsa attributes without the
subprotocol actually being given. Based on this discussion I am
wondering if the subprotocol parameter should actually be mandatory.

In the specific case of MSRP, the msrp-usage-data-channel draft says in
5.1.1.1 that the dcmap attribute includes the label and subprotocol
parameters. The current text could possible be made more explicit by
saying that the 'subprotocol="MSRP"' parameter must always be present.
Have just submitted version 04 of the msrp-usage-data-channel draft,
which proposes to add subprotocol identifier "MSRP" to the WebSocket
Subprotocol Name registry. This registry would then associate
subprotocol id "MSRP" with the msrp-usage-data-channel document.
There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa
attribute are specified. And there the MSRP specific SDP attributes,
which can be dcsa embedded, are described.
'setup' is an attribute, whose semantic changes when being dcsa embedded
and associated with subprotocol MSRP, as compared to the meaning of an
"a=setup" media level attribute of a TCP/MSRP m-line. Hence these
semantical differences are explicitly addressed in the
msrp-usage-data-channel draft.

Regarding sdpneg, I also think that the current text in sdpneg seems to
be sufficient regarding the usage of dcsa encapsulated SDP attributes as
being bound to the data channel's subprotocol.  But as the semantic of a
dcsa encapsulated attribute may be subprotocol specific (like 'setup'),
I'd now tend to consider the subprotocol parameter in the dcmap
attribute as being mandatory, as mentioned above. As already discussed,
the Websocket subprotocol registry would then refer to the document,
which specifies the subprotocol specific usage of dcsa encapsulated
parameters.

Thanks,
Juergen


On 11.02.2016 21:52, Flemming Andreasen wrote:


On 2/8/16 12:09 PM, Paul Kyzivat wrote:
On 2/8/16 11:09 AM, Flemming Andreasen wrote:


On 2/6/16 1:44 PM, Paul Kyzivat wrote:
On 2/4/16 10:43 PM, Christian Groves wrote:
Isn't this the approach we're taking today?
draft-ietf-mmusic-data-channel-sdpneg has general text and specific
drafts are used to describe protocols that use the mechanism (i.e.
draft-ietf-mmusic-msrp-usage-data-channel &
draft-ietf-clue-datachannel).

It remains to be seen if that will be enough. E.g., there currently
aren't any iana considerations in
draft-ietf-mmusic-msrp-usage-data-channel.

Suppose I encounter some sdp that uses msrp over a data channel, but
that usage is unknown to me. How do I find the spec (the reference to
draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage?

I would like to think that the iana registries will allow me to trace
back to the relevant specs.

No disagreement on that part, however having taken another look at both
sdpneg and the msrp-usage documents, I still don't agree with your
original request for all (existing and new) attributes to specify how
they may or may not be used with the dcsa attribute defined by sdpneg.

As Christian noted, the sub-protocol specifics are defined in
individual
documents (like msrp-usage), which calls your the parameters that
are at
least needed to be supported for that usage. Taking MSRP as an example,
why isn't that enough, and how do you see the resulting set of
attributes that may or may not be used with MSRP differ between use
in a
data-channel (and hence encapsulated in dcsa) or as a regular media
stream ?

Based on this discussion, I conclude that it should be sufficient for
this draft to say that before an attribute can be used with dcsa,
such usage must be defined somewhere. This could be either:
- as part of the definition of the attribute, OR
- as part of the definition of the protocol referenced on the m-line.

We are getting closer, but it's still not obvious to me that you
cannot use an attribute with dcsa if it has not been explicitly
defined for the attribute in question. Clearly, there are attributes
that wouldn't make sense over data channels, just like there are
attributes that don't make sense over particular media descriptions.

Again, I'd like to hear from more people on this, including the authors.

Thanks

-- Flemming



    Thanks,
    Paul

Also, it would be good to hear from more people on this, including the
document authors.

Thanks

-- Flemming


    Thanks,
    Paul

Regards, Christian

On 4/02/2016 3:58 PM, Paul Kyzivat wrote:
On 2/3/16 5:42 PM, Flemming Andreasen wrote:

I'm not concerned about the IANA part. I agree that *if* we need to
expliclty specify attribute interactions for "dcsa", then it
should be
part of the IANA registry. What I am not agreeing with at this
point is
that there is indeed a need to explicitly speficy these
interactions as
opposed to relying on a more general algorithmic approach (plus the
offerer being responsible for generating a valid offer if he
wants to
establish a data channel).

Well, an obvious one is that the protocol(s) the attribute
pertains to
need to be defined to work over data channels.

    Thanks,
    Paul

_______________________________________________
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
.






--------------090805020501040504070607-- From nobody Mon Feb 15 00:38:31 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 0FA501B2F33; Mon, 15 Feb 2016 00:38: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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215083829.10181.83727.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 00:38:29 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-02.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, 15 Feb 2016 08:38: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 of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-02.txt Pages : 8 Date : 2016-02-15 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- exclusive', that can be used by an endpoint 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-02 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 Feb 15 01:02:39 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 3247C1B2FAC; Mon, 15 Feb 2016 01:02:36 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215090236.24430.60323.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 01:02:36 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-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: Mon, 15 Feb 2016 09:02:36 -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 of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-03.txt Pages : 9 Date : 2016-02-15 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- exclusive', that can be used by an endpoint 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-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 Feb 15 08:08:56 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 4A7DD1B35C6 for ; Mon, 15 Feb 2016 08:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, 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 EY09aYzOfXLU for ; Mon, 15 Feb 2016 08: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 80C701B35C2 for ; Mon, 15 Feb 2016 08:08:51 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-03v.sys.comcast.net with comcast id Jg7t1s0022TL4Rh01g8qYQ; Mon, 15 Feb 2016 16:08:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id Jg8q1s0033KdFy101g8q5A; Mon, 15 Feb 2016 16:08:50 +0000 To: Juergen Stoetzer-Bradler , Flemming Andreasen , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56C1F810.4060309@alum.mit.edu> Date: Mon, 15 Feb 2016 11:08:48 -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: <56C05B90.5070107@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455552530; bh=bhG1L/LC+mOKJcPwdPYgu9jkn2YrLInNAIf6Iz4kT1Q=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Iw144Q9K3s87I5Z0RGTq9Ze1W0dGFbdmWV7dKZUdiVwL/0mr2ElZ/zZ8gHM6bkkfM ZZGZ+lIe5iiXBJrEMHfDx/i+aalm4gsFpy4A9HV9SodjLWVIsmpHqxfKXzl7UWbhHS lCwtsUTEgsP0sPMcMwRoy3GH2+SGRt+6yv9iJ8erE+qqRcNmDI0glQbkLZc5KE/Z8C TWryi2YnrgyRlU7AvzqU7oRTGXNAyq2EosEa9HuMXXHZnDkB6rszqbsOMrTO9P9rUk +7rxYvoLBtc8SuRkdqFaM2eJSY7TJ94CZ6GAUXZUYefF8y/aTzxU0nCbzSrO6lIJGV P0kqNt8IBJRGg== 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: Mon, 15 Feb 2016 16:08:54 -0000 On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: > Paul, > > In your case 2) I would agree that the usage of dcsa embedded attributes > seems questionable. After all, the dcsa attribute is defined in sdpneg > as encapsulating a subprotocol specific attribute. If the subprotocol > may dynamically change over time without further (SDP offer/answer) > negotiation, then a negotiation of dcsa embedded attributes may indeed > not be very helpful. > > In your case 1), I am wondering how would the SDP answerer know which > subprotocol to use for which data channel, if the subprotocol id is not > added to the data channel's dmap attribute (at least if multiple data > channels are negotiated)? Conceivably via some provisioning, or via a > mutual understanding of a certain subprotocol to SCTP stream id mapping, > or via a certain a priori agreed label usage. I hadn't thought of such > cases when raising the question if the subprotocol should actually be > mandatory. IMO it could be any of those. But for this use case it seems more likely that channels will be opened dynamically rather than via SDP. I think the provision for *not* specifying the subprotocol was primarily to establish equivalence with what is possible via DCEP. One possibility is that SDP is used to specify how many channels are opened, with the understanding that each of them will use the same application-specific protocol. One possible use for dcsa with an unnamed protocol would be if the intent is to use a proprietary variant of a standard protocol, where there is still a desire to negotiate options using attributes applicable to that standard base protocol. But I'm really stretching to come up with this. > But such use cases would certainly go beyond a pure SDP offer/answer > negotiation use case and I would argue that such use cases would also go > beyond the scope of the sdpneg draft. Probably. > I could now imagine the sdpneg draft saying that an SDP offerer should > add a subprotocol identifier to an offered data channel's dcmap > attribute, if it also adds dcsa embedded subprotocol attributes. And > that an implementation would be on its own, if it does not follow that > recommendation (for whatever reasons). That could work. > Further, similar as for non-dcsa embedded attributes, we could > explicitly add text to the sdpneg draft saying that a recipient of an an > SDP offer or answer should ignore dcsa embedded attributes not only if > they are completely unknown, but also if their semantics related to the > subprotocol is not known. > (The current draft says in sec 5.2.3 that the SDP answerer "/Parses and > applies the SDP offer. Note that the typical parser normally ignores > unknown SDP attributes, which includes data channel related > attributes./" I think we could make this clearer and explicitly refer to > dcsa embedded subprotocol attributes.) Yes, that would help. Thanks, Paul > Thanks, > Juergen > > On 12.02.2016 17:58, EXT Paul Kyzivat wrote: >> Juergen, >> >> You bring up a point that perhaps needs further discussion: what does >> it mean when the subprotocol is not specified? >> >> IIUC there are at least a couple of reasons this might come about: >> >> 1) The protocol to be used is not standardized. There is no globally >> unique name for it. The two ends know what protocol to use based on >> context. >> >> 2) The protocol to be used on the channel is not determined via SDP >> negotiation. The applications want to establish the channel, and then >> dynamically decide what protocol to use with it. (And that protocol >> may change over time.) >> >> I guess that it still might be meaningful to use dcsa with (1), but >> there would be no way to determine by examination of the SDP whether >> the usage was compatible with the protocol. In this case the usage of >> the attributes would be "off label" - being adapted to the proprietary >> protocol in a way that hopefully the two ends agree. >> >> I don't see how dcsa makes much sense for (2). If you don't know what >> protocol will be used then how do you know what attributes to use? >> >> Thanks, >> Paul >> >> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>> Flemming, Paul, >>> >>> The current a=dcmap related text in >>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>> 'subprotocol' parameter must always be present - rather it is specified >>> as an optional parameter. Thus, current sdpneg text would allow to >>> create an SDP offer for a data channel, which contains one a=dcmap >>> attribute and potentially multiple a=dcsa attributes without the >>> subprotocol actually being given. Based on this discussion I am >>> wondering if the subprotocol parameter should actually be mandatory. >>> >>> In the specific case of MSRP, the msrp-usage-data-channel draft says in >>> 5.1.1.1 that the dcmap attribute includes the label and subprotocol >>> parameters. The current text could possible be made more explicit by >>> saying that the 'subprotocol="MSRP"' parameter must always be present. >>> Have just submitted version 04 of the msrp-usage-data-channel draft, >>> which proposes to add subprotocol identifier "MSRP" to the WebSocket >>> Subprotocol Name registry. This registry would then associate >>> subprotocol id "MSRP" with the msrp-usage-data-channel document. >>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa >>> attribute are specified. And there the MSRP specific SDP attributes, >>> which can be dcsa embedded, are described. >>> 'setup' is an attribute, whose semantic changes when being dcsa embedded >>> and associated with subprotocol MSRP, as compared to the meaning of an >>> "a=setup" media level attribute of a TCP/MSRP m-line. Hence these >>> semantical differences are explicitly addressed in the >>> msrp-usage-data-channel draft. >>> >>> Regarding sdpneg, I also think that the current text in sdpneg seems to >>> be sufficient regarding the usage of dcsa encapsulated SDP attributes as >>> being bound to the data channel's subprotocol. But as the semantic of a >>> dcsa encapsulated attribute may be subprotocol specific (like 'setup'), >>> I'd now tend to consider the subprotocol parameter in the dcmap >>> attribute as being mandatory, as mentioned above. As already discussed, >>> the Websocket subprotocol registry would then refer to the document, >>> which specifies the subprotocol specific usage of dcsa encapsulated >>> parameters. >>> >>> Thanks, >>> Juergen >>> >>> >>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>> >>>> >>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>> >>>>>> >>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>> Isn't this the approach we're taking today? >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific >>>>>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>> draft-ietf-clue-datachannel). >>>>>>> >>>>>>> It remains to be seen if that will be enough. E.g., there currently >>>>>>> aren't any iana considerations in >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>> >>>>>>> Suppose I encounter some sdp that uses msrp over a data channel, but >>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>> reference to >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>>>>> >>>>>>> I would like to think that the iana registries will allow me to >>>>>>> trace >>>>>>> back to the relevant specs. >>>>>>> >>>>>> No disagreement on that part, however having taken another look at >>>>>> both >>>>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>>>> original request for all (existing and new) attributes to specify how >>>>>> they may or may not be used with the dcsa attribute defined by >>>>>> sdpneg. >>>>>> >>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>> individual >>>>>> documents (like msrp-usage), which calls your the parameters that >>>>>> are at >>>>>> least needed to be supported for that usage. Taking MSRP as an >>>>>> example, >>>>>> why isn't that enough, and how do you see the resulting set of >>>>>> attributes that may or may not be used with MSRP differ between use >>>>>> in a >>>>>> data-channel (and hence encapsulated in dcsa) or as a regular media >>>>>> stream ? >>>>> >>>>> Based on this discussion, I conclude that it should be sufficient for >>>>> this draft to say that before an attribute can be used with dcsa, >>>>> such usage must be defined somewhere. This could be either: >>>>> - as part of the definition of the attribute, OR >>>>> - as part of the definition of the protocol referenced on the m-line. >>>>> >>>> We are getting closer, but it's still not obvious to me that you >>>> cannot use an attribute with dcsa if it has not been explicitly >>>> defined for the attribute in question. Clearly, there are attributes >>>> that wouldn't make sense over data channels, just like there are >>>> attributes that don't make sense over particular media descriptions. >>>> >>>> Again, I'd like to hear from more people on this, including the >>>> authors. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Also, it would be good to hear from more people on this, including >>>>>> the >>>>>> document authors. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>> >>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>>>> need to >>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>>>> should be >>>>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>>>> point is >>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>> interactions as >>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>> (plus the >>>>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>>>> wants to >>>>>>>>>> establish a data channel). >>>>>>>>> >>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>> pertains to >>>>>>>>> need to be defined to work over data channels. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 Mon Feb 15 15:41: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 9C8A51A1DBC for ; Mon, 15 Feb 2016 15:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 ovUpw374HGsc for ; Mon, 15 Feb 2016 15:41:40 -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 290ED1A1BF3 for ; Mon, 15 Feb 2016 15:41:40 -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=zAwArnuu+RlseFLHMyaQHUMOsH8K6c/V9niF5c4m/Jo=; b=f7GKK1eiMEXk4EKUJef842qIng 14p/hSE/I2sVUin1Eo76MMNWB06lYlqbiBKCcbBLsaQYgm7B4MBP3N0L9Ag6yb13CwKIdFnQjK5ne H+x6azJMzNpukDFwGtN4if9beXbbtem6iICJ/0kWTlgVN619EBNfKGWxPWaJBuFVlkQVHeH4d1QOD Q3ZdHfFO5uLm9Hd6pMz2HnTdfvZU6uosCSIBHoweeITB2KFwdXUDVBEfittZ+znLf1RkzgGAkcVuV Hafnh+d1wjLY4RdLctJiHb6VcJRjzRpBENluWDRLv60YTvwGFqC4Ovps4NUPl/JRHY2vabCwPT7U1 xmFsoECQ==; Received: from ppp118-209-170-124.lns20.mel8.internode.on.net ([118.209.170.124]:59923 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aVSlt-002OpP-Oj for mmusic@ietf.org; Tue, 16 Feb 2016 10:41:37 +1100 To: mmusic@ietf.org References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> From: Christian Groves Message-ID: <56C2622F.1020807@nteczone.com> Date: Tue, 16 Feb 2016 10:41:35 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C05B63.4030007@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Mon, 15 Feb 2016 23:41:43 -0000 Hello Juergen, Your proposal seems reasonable to me. With regards to the IANA registry for websockets I think it should be possible to add two references to the row for MSRP. It's only editing a table. Regards, Christian On 14/02/2016 9:48 PM, Juergen Stoetzer-Bradler wrote: > Flemming, > > Regarding >> It would probably simplify the overall SDP negotiation part, but I >> don't know if it would constrain the way data channels were >> envisioned to be used. > > On Friday Paul mentioned in his email two potential use cases, where > no subprotocol identifiers might be added to a data channel's dcmap > attribute. In my last email I hadn't thought of such cases. If we > don't want to exclude such cases, then requiring the subprotocol ids > always to be present might indeed be too restrictive. > > Regarding >> Ok. Going back to discussion between Paul and I, do you believe that >> in for an attribute to be encapsulated in dcsa, the attribute MUST >> have been explicitly define to support this (Paul's suggestion below) >> or do you believe that this is overly constraining, and if so, how >> shoud we relax it ? > > I now think that the sdpneg draft might recommend SDP offerers and > answerers to always add a subprotocol identifier to a data channel's > dcmap attribute if dcsa embedded attributes are also negotiated for > the data channel's subprotocol. I also think we could explicitly add > text to sdpneg saying that subprotocol identifiers should be added to > the IANA Websocket (and in future combined data channel) registry. And > that this registration should be done via a document, which then > explicitly describes the usages and semantics of dcsa embedded > subprotocol attributes, _if_ those usages or semantics deviate from > cases, where these attributes are not dcsa encapsulated. I think that > in those cases, where the usage and meaning of an attribute (always > related to the data channel's subprotocol) does not deviate from the > non-dcsa encapsulated use cases, such an attribute may not explicitly > need to be described for data channel usage. But I think it might be > helpful to explicitly say so in the sdpneg draft. > > Somebody inspecting an SDP offer or answer, which was generated by an > implementation following these two recommendations (and which hence > contains an IANA registered subprotocol id if it contains any dcsa > embedded attributes), could then refer to that IANA table, would then > find the reference to the document, which defines this subprotocol id > for data channel usage, and there could check if any of the dcsa > embedded attributes has a data channel specific semantic. If yes, that > specific semantic would be described in that document. If such a > specific semantic were not described in that document, then the > default usage and semantic of the attribute would apply also to that > data channel transport case. > > But in that context I'd have an IANA table related question. > A certain subprotocol might be defined for Websocket usage as well as > for data channel usage. MSRP is already such a case, where > draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP over > data channels, and where draft-pd-dispatch-msrp-websocket defines how > to use MSRP over Websockets. > Would the IANA WebSocket Subprotocol Name Registry on > http://www.iana.org/assignments/websocket/websocket.xml then contain > two MSRP related rows? Or just one row containing references to both > the Websocket and data channel documents? > Should we add related text to the IANA registration section of the > sdpneg draft? > > Thanks, > Juergen > > > On 12.02.2016 15:52, EXT Flemming Andreasen wrote: >> >> >> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>> Flemming, Paul, >>> >>> The current a=dcmap related text in >>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>> 'subprotocol' parameter must always be present - rather it is >>> specified as an optional parameter. Thus, current sdpneg text would >>> allow to create an SDP offer for a data channel, which contains one >>> a=dcmap attribute and potentially multiple a=dcsa attributes without >>> the subprotocol actually being given. Based on this discussion I am >>> wondering if the subprotocol parameter should actually be mandatory. >>> >> It would probably simplify the overall SDP negotiation part, but I >> don't know if it would constrain the way data channels were >> envisioned to be used. >> >> >>> In the specific case of MSRP, the msrp-usage-data-channel draft says >>> in 5.1.1.1 that the dcmap attribute includes the label and >>> subprotocol parameters. The current text could possible be made more >>> explicit by saying that the 'subprotocol="MSRP"' parameter must >>> always be present. >>> Have just submitted version 04 of the msrp-usage-data-channel draft, >>> which proposes to add subprotocol identifier "MSRP" to the WebSocket >>> Subprotocol Name registry. This registry would then associate >>> subprotocol id "MSRP" with the msrp-usage-data-channel document. >>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa >>> attribute are specified. And there the MSRP specific SDP attributes, >>> which can be dcsa embedded, are described. >>> 'setup' is an attribute, whose semantic changes when being dcsa >>> embedded and associated with subprotocol MSRP, as compared to the >>> meaning of an "a=setup" media level attribute of a TCP/MSRP m-line. >>> Hence these semantical differences are explicitly addressed in the >>> msrp-usage-data-channel draft. >>> >>> Regarding sdpneg, I also think that the current text in sdpneg seems >>> to be sufficient regarding the usage of dcsa encapsulated SDP >>> attributes as being bound to the data channel's subprotocol. But as >>> the semantic of a dcsa encapsulated attribute may be subprotocol >>> specific (like 'setup'), I'd now tend to consider the subprotocol >>> parameter in the dcmap attribute as being mandatory, as mentioned >>> above. As already discussed, the Websocket subprotocol registry >>> would then refer to the document, which specifies the subprotocol >>> specific usage of dcsa encapsulated parameters. >>> >> Ok. Going back to discussion between Paul and I, do you believe that >> in for an attribute to be encapsulated in dcsa, the attribute MUST >> have been explicitly define to support this (Paul's suggestion below) >> or do you believe that this is overly constraining, and if so, how >> shoud we relax it ? >> >> Thanks >> >> -- Flemming >> >> >>> Thanks, >>> Juergen >>> >>> >>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>> >>>> >>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>> >>>>>> >>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>> Isn't this the approach we're taking today? >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and >>>>>>>> specific >>>>>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>> draft-ietf-clue-datachannel). >>>>>>> >>>>>>> It remains to be seen if that will be enough. E.g., there currently >>>>>>> aren't any iana considerations in >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>> >>>>>>> Suppose I encounter some sdp that uses msrp over a data channel, >>>>>>> but >>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>> reference to >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>>>>> >>>>>>> I would like to think that the iana registries will allow me to >>>>>>> trace >>>>>>> back to the relevant specs. >>>>>>> >>>>>> No disagreement on that part, however having taken another look >>>>>> at both >>>>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>>>> original request for all (existing and new) attributes to specify >>>>>> how >>>>>> they may or may not be used with the dcsa attribute defined by >>>>>> sdpneg. >>>>>> >>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>> individual >>>>>> documents (like msrp-usage), which calls your the parameters that >>>>>> are at >>>>>> least needed to be supported for that usage. Taking MSRP as an >>>>>> example, >>>>>> why isn't that enough, and how do you see the resulting set of >>>>>> attributes that may or may not be used with MSRP differ between >>>>>> use in a >>>>>> data-channel (and hence encapsulated in dcsa) or as a regular media >>>>>> stream ? >>>>> >>>>> Based on this discussion, I conclude that it should be sufficient >>>>> for this draft to say that before an attribute can be used with >>>>> dcsa, such usage must be defined somewhere. This could be either: >>>>> - as part of the definition of the attribute, OR >>>>> - as part of the definition of the protocol referenced on the m-line. >>>>> >>>> We are getting closer, but it's still not obvious to me that you >>>> cannot use an attribute with dcsa if it has not been explicitly >>>> defined for the attribute in question. Clearly, there are >>>> attributes that wouldn't make sense over data channels, just like >>>> there are attributes that don't make sense over particular media >>>> descriptions. >>>> >>>> Again, I'd like to hear from more people on this, including the >>>> authors. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Also, it would be good to hear from more people on this, >>>>>> including the >>>>>> document authors. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>> >>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>>>> need to >>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>>>> should be >>>>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>>>> point is >>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>> interactions as >>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>> (plus the >>>>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>>>> wants to >>>>>>>>>> establish a data channel). >>>>>>>>> >>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>> pertains to >>>>>>>>> need to be defined to work over data channels. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Feb 16 05:02: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 4FE791A1A38 for ; Tue, 16 Feb 2016 05:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 EWbRt0pM63Du for ; Tue, 16 Feb 2016 05:02:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 75CCE1AD09C for ; Tue, 16 Feb 2016 05:02:04 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 9A67487549CC4; Tue, 16 Feb 2016 13:02:00 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1GD220r025010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Feb 2016 13:02:03 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1GD1wdU006835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Feb 2016 14:01:59 +0100 Received: from [149.204.68.190] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Feb 2016 14:01:58 +0100 To: EXT Paul Kyzivat , Juergen Stoetzer-Bradler , Flemming Andreasen , , "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> From: Juergen Stoetzer-Bradler Message-ID: <56C31DC5.80105@alcatel-lucent.com> Date: Tue, 16 Feb 2016 14:01:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C1F810.4060309@alum.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070402010006080101040907" X-Originating-IP: [135.239.27.41] 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: Tue, 16 Feb 2016 13:02:11 -0000 --------------ms070402010006080101040907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Paul, Thanks for further feedback. Fully agree now that the subprotocol paramet= er should stay optional. Will come back with with a proposal of how the sdpneg text could be enhan= ced as discussed. Thanks, Juergen On 15.02.2016 17:08, EXT Paul Kyzivat wrote: > On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: >> Paul, >> >> In your case 2) I would agree that the usage of dcsa embedded attribut= es >> seems questionable. After all, the dcsa attribute is defined in sdpneg= >> as encapsulating a subprotocol specific attribute. If the subprotocol >> may dynamically change over time without further (SDP offer/answer) >> negotiation, then a negotiation of dcsa embedded attributes may indeed= >> not be very helpful. >> >> In your case 1), I am wondering how would the SDP answerer know which >> subprotocol to use for which data channel, if the subprotocol id is no= t >> added to the data channel's dmap attribute (at least if multiple data >> channels are negotiated)? Conceivably via some provisioning, or via a >> mutual understanding of a certain subprotocol to SCTP stream id mappin= g, >> or via a certain a priori agreed label usage. I hadn't thought of such= >> cases when raising the question if the subprotocol should actually be >> mandatory. > > IMO it could be any of those. But for this use case it seems more likel= y that channels will be=20 > opened dynamically rather than via SDP. > > I think the provision for *not* specifying the subprotocol was primaril= y to establish equivalence=20 > with what is possible via DCEP. > > One possibility is that SDP is used to specify how many channels are op= ened, with the=20 > understanding that each of them will use the same application-specific = protocol. > > One possible use for dcsa with an unnamed protocol would be if the inte= nt is to use a proprietary=20 > variant of a standard protocol, where there is still a desire to negoti= ate options using=20 > attributes applicable to that standard base protocol. But I'm really st= retching to come up with this. > >> But such use cases would certainly go beyond a pure SDP offer/answer >> negotiation use case and I would argue that such use cases would also = go >> beyond the scope of the sdpneg draft. > > Probably. > >> I could now imagine the sdpneg draft saying that an SDP offerer should= >> add a subprotocol identifier to an offered data channel's dcmap >> attribute, if it also adds dcsa embedded subprotocol attributes. And >> that an implementation would be on its own, if it does not follow that= >> recommendation (for whatever reasons). > > That could work. > >> Further, similar as for non-dcsa embedded attributes, we could >> explicitly add text to the sdpneg draft saying that a recipient of an = an >> SDP offer or answer should ignore dcsa embedded attributes not only if= >> they are completely unknown, but also if their semantics related to th= e >> subprotocol is not known. >> (The current draft says in sec 5.2.3 that the SDP answerer "/Parses an= d >> applies the SDP offer. Note that the typical parser normally ignores >> unknown SDP attributes, which includes data channel related >> attributes./" I think we could make this clearer and explicitly refer = to >> dcsa embedded subprotocol attributes.) > > Yes, that would help. > > Thanks, > Paul > >> Thanks, >> Juergen >> >> On 12.02.2016 17:58, EXT Paul Kyzivat wrote: >>> Juergen, >>> >>> You bring up a point that perhaps needs further discussion: what does= >>> it mean when the subprotocol is not specified? >>> >>> IIUC there are at least a couple of reasons this might come about: >>> >>> 1) The protocol to be used is not standardized. There is no globally >>> unique name for it. The two ends know what protocol to use based on >>> context. >>> >>> 2) The protocol to be used on the channel is not determined via SDP >>> negotiation. The applications want to establish the channel, and then= >>> dynamically decide what protocol to use with it. (And that protocol >>> may change over time.) >>> >>> I guess that it still might be meaningful to use dcsa with (1), but >>> there would be no way to determine by examination of the SDP whether >>> the usage was compatible with the protocol. In this case the usage of= >>> the attributes would be "off label" - being adapted to the proprietar= y >>> protocol in a way that hopefully the two ends agree. >>> >>> I don't see how dcsa makes much sense for (2). If you don't know what= >>> protocol will be used then how do you know what attributes to use? >>> >>> Thanks, >>> Paul >>> >>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>> Flemming, Paul, >>>> >>>> The current a=3Ddcmap related text in >>>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>>> 'subprotocol' parameter must always be present - rather it is specif= ied >>>> as an optional parameter. Thus, current sdpneg text would allow to >>>> create an SDP offer for a data channel, which contains one a=3Ddcmap= >>>> attribute and potentially multiple a=3Ddcsa attributes without the >>>> subprotocol actually being given. Based on this discussion I am >>>> wondering if the subprotocol parameter should actually be mandatory.= >>>> >>>> In the specific case of MSRP, the msrp-usage-data-channel draft says= in >>>> 5.1.1.1 that the dcmap attribute includes the label and subprotocol >>>> parameters. The current text could possible be made more explicit by= >>>> saying that the 'subprotocol=3D"MSRP"' parameter must always be pres= ent. >>>> Have just submitted version 04 of the msrp-usage-data-channel draft,= >>>> which proposes to add subprotocol identifier "MSRP" to the WebSocket= >>>> Subprotocol Name registry. This registry would then associate >>>> subprotocol id "MSRP" with the msrp-usage-data-channel document. >>>> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa >>>> attribute are specified. And there the MSRP specific SDP attributes,= >>>> which can be dcsa embedded, are described. >>>> 'setup' is an attribute, whose semantic changes when being dcsa embe= dded >>>> and associated with subprotocol MSRP, as compared to the meaning of = an >>>> "a=3Dsetup" media level attribute of a TCP/MSRP m-line. Hence these >>>> semantical differences are explicitly addressed in the >>>> msrp-usage-data-channel draft. >>>> >>>> Regarding sdpneg, I also think that the current text in sdpneg seems= to >>>> be sufficient regarding the usage of dcsa encapsulated SDP attribute= s as >>>> being bound to the data channel's subprotocol. But as the semantic = of a >>>> dcsa encapsulated attribute may be subprotocol specific (like 'setup= '), >>>> I'd now tend to consider the subprotocol parameter in the dcmap >>>> attribute as being mandatory, as mentioned above. As already discuss= ed, >>>> the Websocket subprotocol registry would then refer to the document,= >>>> which specifies the subprotocol specific usage of dcsa encapsulated >>>> parameters. >>>> >>>> Thanks, >>>> Juergen >>>> >>>> >>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>> >>>>> >>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>> >>>>>>> >>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and spec= ific >>>>>>>>> drafts are used to describe protocols that use the mechanism (i= =2Ee. >>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>> >>>>>>>> It remains to be seen if that will be enough. E.g., there curren= tly >>>>>>>> aren't any iana considerations in >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>> >>>>>>>> Suppose I encounter some sdp that uses msrp over a data channel,= but >>>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>>> reference to >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usa= ge? >>>>>>>> >>>>>>>> I would like to think that the iana registries will allow me to >>>>>>>> trace >>>>>>>> back to the relevant specs. >>>>>>>> >>>>>>> No disagreement on that part, however having taken another look a= t >>>>>>> both >>>>>>> sdpneg and the msrp-usage documents, I still don't agree with you= r >>>>>>> original request for all (existing and new) attributes to specify= how >>>>>>> they may or may not be used with the dcsa attribute defined by >>>>>>> sdpneg. >>>>>>> >>>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>>> individual >>>>>>> documents (like msrp-usage), which calls your the parameters that= >>>>>>> are at >>>>>>> least needed to be supported for that usage. Taking MSRP as an >>>>>>> example, >>>>>>> why isn't that enough, and how do you see the resulting set of >>>>>>> attributes that may or may not be used with MSRP differ between u= se >>>>>>> in a >>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular med= ia >>>>>>> stream ? >>>>>> >>>>>> Based on this discussion, I conclude that it should be sufficient = for >>>>>> this draft to say that before an attribute can be used with dcsa, >>>>>> such usage must be defined somewhere. This could be either: >>>>>> - as part of the definition of the attribute, OR >>>>>> - as part of the definition of the protocol referenced on the m-li= ne. >>>>>> >>>>> We are getting closer, but it's still not obvious to me that you >>>>> cannot use an attribute with dcsa if it has not been explicitly >>>>> defined for the attribute in question. Clearly, there are attribute= s >>>>> that wouldn't make sense over data channels, just like there are >>>>> attributes that don't make sense over particular media descriptions= =2E >>>>> >>>>> Again, I'd like to hear from more people on this, including the >>>>> authors. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Also, it would be good to hear from more people on this, includin= g >>>>>>> the >>>>>>> document authors. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>> >>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>>>>> need to >>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>>>>> should be >>>>>>>>>>> part of the IANA registry. What I am not agreeing with at thi= s >>>>>>>>>>> point is >>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>> interactions as >>>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>>> (plus the >>>>>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>>>>> wants to >>>>>>>>>>> establish a data channel). >>>>>>>>>> >>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>>> pertains to >>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>> . >>>>>> >>>>> >>>> >>>> >>> >> > --------------ms070402010006080101040907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DF8wggTdMIIDxaADAgECAgoanQrOAAAAAAAGMA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoT DkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBSb290 IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcyOFowgYUxEzARBgoJkiaJk/IsZAEZ FgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ocmcli3LbVU6TRh +JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdfkyWAiGzVWeRI rYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38VbxMvQ+ygj Eyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+VdiUwDa ry1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsG AQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAes slr2YYl8XHzr4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5z dXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5h bGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4Bggr BgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQw OAYIKwYBBQUHMAKGLGh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQClGxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3 F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjbEhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx 4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6 rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwfRfPmwRetdnD6NC5x8aRkhr4ZNBjv YxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6/XpNOx2FyG18axeeASWtENgP vqEirM5MjwkCMIIHejCCBmKgAwIBAgIKYWH+JwAAAAFWdjANBgkqhkiG9w0BAQUFADCBhTET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVs IEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNTE4MTMwNzI0WhcNMTcwNTE3MTMwNzI0 WjBOMRAwDgYDVQQDEwdsaTYwNzYwMTowOAYJKoZIhvcNAQkBFitqdWVyZ2VuLnN0b2V0emVy LWJyYWRsZXJAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3SjiDDt1yolL0cBi5MS+Bea3hhVDSdcJ/xtfzEbTtkxo05xnMgeRTy/kNJZuR4oY j/2TE+raQenSEgROQtLgxKjxtLh9/fGEuLCyFclz9SIeIYIkZBB1NSwZKmGlJHRU5jjqSinT Hmux9chaP+TUoidoDYbfdz/uFGdPW7RP21Gxjzg9v/VC+tfc0u0idNF9Vwnkh3VgdisMf1Jf JZNINpw0ZapFKRhLEhgtXVS7tkdxxTL0uc9XtviOTSSfxgBt2MPsj0qfhsNFFO4zUO1pJiBz SBPnLt7af96oS2ZHI4Xz7zNHShDoSMMIr+7l9xgopb5qN/KMCMP9BSxxNEfphwIDAQABo4IE IDCCBBwwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmB C/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0P BAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkq hkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFEVmlcJSxtK5Cu7FZb5XUWWuKktKMB8GA1UdIwQYMBaA FNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFMoIIBSKCCAUSGgdls ZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPXVz bmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFh BggrBgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUy MEx1Y2VudCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNl bnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MDgGCCsGAQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20v UEtJL3N1YkNBLmNydDBEBggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxj YXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwNgYDVR0RBC8wLYEranVlcmdlbi5zdG9l dHplci1icmFkbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAMrtX ZAqm6NqOAYttJjvC6pL04tEKUusax1Dr6p6NfxVfUuW8ZoFXKoxHEDaYKQR9ldfnuILHN+x7 KdLeKg+NPUs7GFGwpBmJb7PRmxnIarFJbGHzpqZ9+Fhsde1uxi+y2VJcIOVaEh/JoRdHvSUQ nwT4+FcBmS6uRv68rnCkh+KeUm6A7+6dDo/9l/Zh2Hu1+HVWw5kEH/xmO170v9Xef7efxzxv BeQ644kvErDNG26LJDUtOqaKTdz9KKZXngw+2cAV/4Kc7C9xdT29Ugm8oOK/ecqBliMhBUen WphsEDjIbKJCd40RJLKb+v49EN/IJogNDd81vtehOxDw5Lus4zGCA+0wggPpAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZIm iZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0 ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+JwAAAAFWdjANBglghkgBZQMEAgEFAKCC AikwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMjE2MTMw MTU3WjAvBgkqhkiG9w0BCQQxIgQgMKo93+KpHCRUARVBZ/ow9pW8oSLLzlsbKUKEy9gSz4Iw bAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZIm iZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRl bCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+ JwAAAAFWdjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQK Ew5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3Vi IENBAgphYf4nAAAAAVZ2MA0GCSqGSIb3DQEBAQUABIIBADM1uhlQBav4KuyzWt7NTcrK03Mw bd0pS6xm49HsJqADJ8iPVQiFYNt18tAaBMOY92ic1pwEHfUfmMP7ywbUyH1x7+2FqiNAtl2x 1/SB2eMWI4UkatM27GDeQgWQZPF05G+UheKnMLy9YsiGOqN8GwAgxBKKdbFUS6O0v451m4qr Q3LgOb+3UrlOiMdch0sALU3YRE5hJFp3fEaQD+L6xdeOvDO804l3BawdPN3gcgLuaFIvl36p be6917pzkC5tIXF1ax/0ZoImimwhAaZGV8QJpoPdAG7Qf96W3zqU3lbYpun4VpyaFfM0Gz2s /LXslpYYrek+EqKc3fs/8b5Wc9UAAAAAAAA= --------------ms070402010006080101040907-- From nobody Tue Feb 16 05:02: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 2748D1B3419 for ; Tue, 16 Feb 2016 05:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 pWzCoLvcgaJx for ; Tue, 16 Feb 2016 05:02:49 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8E5A31B3517 for ; Tue, 16 Feb 2016 05:02:47 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A7D73B197303F for ; Tue, 16 Feb 2016 13:02:43 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1GD2jN3010148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Feb 2016 13:02:45 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1GD2HA0027197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Feb 2016 14:02:44 +0100 Received: from [149.204.68.190] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Feb 2016 14:02:28 +0100 To: References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> <56C2622F.1020807@nteczone.com> From: Juergen Stoetzer-Bradler Message-ID: <56C31DE3.3020009@alcatel-lucent.com> Date: Tue, 16 Feb 2016 14:02:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C2622F.1020807@nteczone.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080404070303020405020406" X-Originating-IP: [135.239.27.41] 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: Tue, 16 Feb 2016 13:02:53 -0000 --------------ms080404070303020405020406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Christian, Thank you for your feedback. Ok, I think then it might be helpful to add = a related sentence or two=20 to the IANA registration section of the sdpneg draft. Thanks, Juergen On 16.02.2016 00:41, EXT Christian Groves wrote: > Hello Juergen, > > Your proposal seems reasonable to me. > > With regards to the IANA registry for websockets I think it should be p= ossible to add two=20 > references to the row for MSRP. It's only editing a table. > > Regards, Christian > > On 14/02/2016 9:48 PM, Juergen Stoetzer-Bradler wrote: >> Flemming, >> >> Regarding >>> It would probably simplify the overall SDP negotiation part, but I do= n't know if it would=20 >>> constrain the way data channels were envisioned to be used.=20 >> >> On Friday Paul mentioned in his email two potential use cases, where n= o subprotocol identifiers=20 >> might be added to a data channel's dcmap attribute. In my last email I= hadn't thought of such=20 >> cases. If we don't want to exclude such cases, then requiring the subp= rotocol ids always to be=20 >> present might indeed be too restrictive. >> >> Regarding >>> Ok. Going back to discussion between Paul and I, do you believe that = in for an attribute to be=20 >>> encapsulated in dcsa, the attribute MUST have been explicitly define = to support this (Paul's=20 >>> suggestion below) or do you believe that this is overly constraining,= and if so, how shoud we=20 >>> relax it ?=20 >> >> I now think that the sdpneg draft might recommend SDP offerers and ans= werers to always add a=20 >> subprotocol identifier to a data channel's dcmap attribute if dcsa emb= edded attributes are also=20 >> negotiated for the data channel's subprotocol. I also think we could e= xplicitly add text to=20 >> sdpneg saying that subprotocol identifiers should be added to the IANA= Websocket (and in future=20 >> combined data channel) registry. And that this registration should be = done via a document, which=20 >> then explicitly describes the usages and semantics of dcsa embedded su= bprotocol attributes, _if_=20 >> those usages or semantics deviate from cases, where these attributes a= re not dcsa encapsulated. I=20 >> think that in those cases, where the usage and meaning of an attribute= (always related to the=20 >> data channel's subprotocol) does not deviate from the non-dcsa encapsu= lated use cases, such an=20 >> attribute may not explicitly need to be described for data channel usa= ge. But I think it might be=20 >> helpful to explicitly say so in the sdpneg draft. > >> >> Somebody inspecting an SDP offer or answer, which was generated by an = implementation following=20 >> these two recommendations (and which hence contains an IANA registered= subprotocol id if it=20 >> contains any dcsa embedded attributes), could then refer to that IANA = table, would then find the=20 >> reference to the document, which defines this subprotocol id for data = channel usage, and there=20 >> could check if any of the dcsa embedded attributes has a data channel = specific semantic. If yes,=20 >> that specific semantic would be described in that document. If such a = specific semantic were not=20 >> described in that document, then the default usage and semantic of the= attribute would apply also=20 >> to that data channel transport case. >> >> But in that context I'd have an IANA table related question. >> A certain subprotocol might be defined for Websocket usage as well as = for data channel usage.=20 >> MSRP is already such a case, where draft-ietf-mmusic-msrp-usage-data-c= hannel defines how to use=20 >> MSRP over data channels, and where draft-pd-dispatch-msrp-websocket de= fines how to use MSRP over=20 >> Websockets. >> Would the IANA WebSocket Subprotocol Name Registry on=20 >> http://www.iana.org/assignments/websocket/websocket.xml then contain t= wo MSRP related rows? Or=20 >> just one row containing references to both the Websocket and data chan= nel documents? >> Should we add related text to the IANA registration section of the sdp= neg draft? >> >> Thanks, >> Juergen >> >> >> On 12.02.2016 15:52, EXT Flemming Andreasen wrote: >>> >>> >>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>> Flemming, Paul, >>>> >>>> The current a=3Ddcmap related text in draft-ietf-mmusic-data-channel= -sdpneg doesn't require that=20 >>>> the 'subprotocol' parameter must always be present - rather it is sp= ecified as an optional=20 >>>> parameter. Thus, current sdpneg text would allow to create an SDP of= fer for a data channel,=20 >>>> which contains one a=3Ddcmap attribute and potentially multiple a=3D= dcsa attributes without the=20 >>>> subprotocol actually being given. Based on this discussion I am wond= ering if the subprotocol=20 >>>> parameter should actually be mandatory. >>>> >>> It would probably simplify the overall SDP negotiation part, but I do= n't know if it would=20 >>> constrain the way data channels were envisioned to be used. >>> >>> >>>> In the specific case of MSRP, the msrp-usage-data-channel draft says= in 5.1.1.1 that the dcmap=20 >>>> attribute includes the label and subprotocol parameters. The current= text could possible be=20 >>>> made more explicit by saying that the 'subprotocol=3D"MSRP"' paramet= er must always be present. >>>> Have just submitted version 04 of the msrp-usage-data-channel draft,= which proposes to add=20 >>>> subprotocol identifier "MSRP" to the WebSocket Subprotocol Name regi= stry. This registry would=20 >>>> then associate subprotocol id "MSRP" with the msrp-usage-data-channe= l document. >>>> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa a= ttribute are specified. And=20 >>>> there the MSRP specific SDP attributes, which can be dcsa embedded, = are described. >>>> 'setup' is an attribute, whose semantic changes when being dcsa embe= dded and associated with=20 >>>> subprotocol MSRP, as compared to the meaning of an "a=3Dsetup" media= level attribute of a=20 >>>> TCP/MSRP m-line. Hence these semantical differences are explicitly a= ddressed in the=20 >>>> msrp-usage-data-channel draft. >>>> >>>> Regarding sdpneg, I also think that the current text in sdpneg seems= to be sufficient regarding=20 >>>> the usage of dcsa encapsulated SDP attributes as being bound to the = data channel's subprotocol.=20 >>>> But as the semantic of a dcsa encapsulated attribute may be subproto= col specific (like=20 >>>> 'setup'), I'd now tend to consider the subprotocol parameter in the = dcmap attribute as being=20 >>>> mandatory, as mentioned above. As already discussed, the Websocket s= ubprotocol registry would=20 >>>> then refer to the document, which specifies the subprotocol specific= usage of dcsa encapsulated=20 >>>> parameters. >>>> >>> Ok. Going back to discussion between Paul and I, do you believe that = in for an attribute to be=20 >>> encapsulated in dcsa, the attribute MUST have been explicitly define = to support this (Paul's=20 >>> suggestion below) or do you believe that this is overly constraining,= and if so, how shoud we=20 >>> relax it ? >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> Thanks, >>>> Juergen >>>> >>>> >>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>> >>>>> >>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>> >>>>>>> >>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and spec= ific >>>>>>>>> drafts are used to describe protocols that use the mechanism (i= =2Ee. >>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>> >>>>>>>> It remains to be seen if that will be enough. E.g., there curren= tly >>>>>>>> aren't any iana considerations in >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>> >>>>>>>> Suppose I encounter some sdp that uses msrp over a data channel,= but >>>>>>>> that usage is unknown to me. How do I find the spec (the referen= ce to >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usa= ge? >>>>>>>> >>>>>>>> I would like to think that the iana registries will allow me to = trace >>>>>>>> back to the relevant specs. >>>>>>>> >>>>>>> No disagreement on that part, however having taken another look a= t both >>>>>>> sdpneg and the msrp-usage documents, I still don't agree with you= r >>>>>>> original request for all (existing and new) attributes to specify= how >>>>>>> they may or may not be used with the dcsa attribute defined by sd= pneg. >>>>>>> >>>>>>> As Christian noted, the sub-protocol specifics are defined in ind= ividual >>>>>>> documents (like msrp-usage), which calls your the parameters that= are at >>>>>>> least needed to be supported for that usage. Taking MSRP as an ex= ample, >>>>>>> why isn't that enough, and how do you see the resulting set of >>>>>>> attributes that may or may not be used with MSRP differ between u= se in a >>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular med= ia >>>>>>> stream ? >>>>>> >>>>>> Based on this discussion, I conclude that it should be sufficient = for this draft to say that=20 >>>>>> before an attribute can be used with dcsa, such usage must be defi= ned somewhere. This could=20 >>>>>> be either: >>>>>> - as part of the definition of the attribute, OR >>>>>> - as part of the definition of the protocol referenced on the m-li= ne. >>>>>> >>>>> We are getting closer, but it's still not obvious to me that you ca= nnot use an attribute with=20 >>>>> dcsa if it has not been explicitly defined for the attribute in que= stion. Clearly, there are=20 >>>>> attributes that wouldn't make sense over data channels, just like t= here are attributes that=20 >>>>> don't make sense over particular media descriptions. >>>>> >>>>> Again, I'd like to hear from more people on this, including the aut= hors. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Also, it would be good to hear from more people on this, includin= g the >>>>>>> document authors. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>> >>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we n= eed to >>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it = should be >>>>>>>>>>> part of the IANA registry. What I am not agreeing with at thi= s >>>>>>>>>>> point is >>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>> interactions as >>>>>>>>>>> opposed to relying on a more general algorithmic approach (pl= us the >>>>>>>>>>> offerer being responsible for generating a valid offer if he = wants to >>>>>>>>>>> establish a data channel). >>>>>>>>>> >>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute per= tains to >>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >> >> >> _______________________________________________ >> 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 > --------------ms080404070303020405020406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DF8wggTdMIIDxaADAgECAgoanQrOAAAAAAAGMA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoT DkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBSb290 IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcyOFowgYUxEzARBgoJkiaJk/IsZAEZ FgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ocmcli3LbVU6TRh +JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdfkyWAiGzVWeRI rYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38VbxMvQ+ygj Eyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+VdiUwDa ry1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsG AQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAes slr2YYl8XHzr4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5z dXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5h bGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4Bggr BgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQw OAYIKwYBBQUHMAKGLGh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQClGxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3 F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjbEhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx 4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6 rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwfRfPmwRetdnD6NC5x8aRkhr4ZNBjv YxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6/XpNOx2FyG18axeeASWtENgP vqEirM5MjwkCMIIHejCCBmKgAwIBAgIKYWH+JwAAAAFWdjANBgkqhkiG9w0BAQUFADCBhTET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVs IEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNTE4MTMwNzI0WhcNMTcwNTE3MTMwNzI0 WjBOMRAwDgYDVQQDEwdsaTYwNzYwMTowOAYJKoZIhvcNAQkBFitqdWVyZ2VuLnN0b2V0emVy LWJyYWRsZXJAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3SjiDDt1yolL0cBi5MS+Bea3hhVDSdcJ/xtfzEbTtkxo05xnMgeRTy/kNJZuR4oY j/2TE+raQenSEgROQtLgxKjxtLh9/fGEuLCyFclz9SIeIYIkZBB1NSwZKmGlJHRU5jjqSinT Hmux9chaP+TUoidoDYbfdz/uFGdPW7RP21Gxjzg9v/VC+tfc0u0idNF9Vwnkh3VgdisMf1Jf JZNINpw0ZapFKRhLEhgtXVS7tkdxxTL0uc9XtviOTSSfxgBt2MPsj0qfhsNFFO4zUO1pJiBz SBPnLt7af96oS2ZHI4Xz7zNHShDoSMMIr+7l9xgopb5qN/KMCMP9BSxxNEfphwIDAQABo4IE IDCCBBwwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmB C/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0P BAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkq hkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFEVmlcJSxtK5Cu7FZb5XUWWuKktKMB8GA1UdIwQYMBaA FNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFMoIIBSKCCAUSGgdls ZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPXVz bmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFh BggrBgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUy MEx1Y2VudCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNl bnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MDgGCCsGAQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20v UEtJL3N1YkNBLmNydDBEBggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxj YXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwNgYDVR0RBC8wLYEranVlcmdlbi5zdG9l dHplci1icmFkbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAMrtX ZAqm6NqOAYttJjvC6pL04tEKUusax1Dr6p6NfxVfUuW8ZoFXKoxHEDaYKQR9ldfnuILHN+x7 KdLeKg+NPUs7GFGwpBmJb7PRmxnIarFJbGHzpqZ9+Fhsde1uxi+y2VJcIOVaEh/JoRdHvSUQ nwT4+FcBmS6uRv68rnCkh+KeUm6A7+6dDo/9l/Zh2Hu1+HVWw5kEH/xmO170v9Xef7efxzxv BeQ644kvErDNG26LJDUtOqaKTdz9KKZXngw+2cAV/4Kc7C9xdT29Ugm8oOK/ecqBliMhBUen WphsEDjIbKJCd40RJLKb+v49EN/IJogNDd81vtehOxDw5Lus4zGCA+0wggPpAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZIm iZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0 ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+JwAAAAFWdjANBglghkgBZQMEAgEFAKCC AikwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMjE2MTMw MjI3WjAvBgkqhkiG9w0BCQQxIgQgqQrdcO7it0hTr8XP786dcBOQ1/DWLKXS+sHr7wG8mE4w bAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZIm iZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRl bCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+ JwAAAAFWdjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQK Ew5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3Vi IENBAgphYf4nAAAAAVZ2MA0GCSqGSIb3DQEBAQUABIIBACzVyY27dMRr71bPLtIZ6tUk25Qf 2bl1h50jecFZOp0Mbi4HijNRGgj5vap50pZ1yBuMo4yBs9MbUGan/JWbtnwDfnxZOXdaKomr 3pEAdrSnHlcvJBC6XQQUCGMpZmak6ZvXNlNA3vJDCvtzRZShOcbaKpNSyToUsS8WFiRNrXbP VjrO2rBIdjO0K0TR8oCdXgrXbctV6iUybPJnvgr9BiMlvOW0rr34L6aS9ll+tTNVOFESjgn1 GdOcFNlkwKlgzQVB7f9GSgGn35HkktVNmyDhDv//7HsYrb+GHj7v71M2OfjmjSLR1m7CmYsB ULCdaJxf/V601tDsNdqrj3d4cMkAAAAAAAA= --------------ms080404070303020405020406-- From nobody Tue Feb 16 05:18:25 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 20EBC1B2E59; Tue, 16 Feb 2016 05:18:19 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160216131819.26426.27249.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 05:18:19 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-26.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, 16 Feb 2016 13:18:19 -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 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-26.txt Pages : 51 Date : 2016-02-16 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-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-26 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 Feb 16 05:20: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 6DC671AD36A for ; Tue, 16 Feb 2016 05:20:51 -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 3I_yJz1NBg_L for ; Tue, 16 Feb 2016 05:20:50 -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 97F0C1A711A for ; Tue, 16 Feb 2016 05:20:49 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-9a-56c3222f2a04 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B7.C7.28465.F2223C65; Tue, 16 Feb 2016 14:20:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Tue, 16 Feb 2016 14:20:16 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-26 Thread-Index: AdFovJJgmDuP5RdQSNWsl2CxzJ/xJQ== Date: Tue, 16 Feb 2016 13:20:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DF9BDA@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DF9BDAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7iq6+0uEwgyMd+hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpRt71gKvopWXLx/m6WB8ZRwFyMnh4SAicSlc0tZIGwxiQv3 1rN1MXJxCAkcZpSY8fQuM4SzmFFi8YLZQFUcHGwCFhLd/7RBGkQE1CW+7u1hBrGFBVQlbh7/ wg4R15JY+fssO0i5iICexPw/fiBhFqCSpQdOg5XwCvhKfPzxjQnEZgTa+/3UGjCbWUBc4taT +UwQ9whILNlznhnCFpV4+fgfK4StKPHx1T5GiPp8if1HvzFDzBSUODnzCcsERqFZSEbNQlI2 C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5da sokRGBEHt/zW3cG4+rXjIUYBDkYlHt6CiENhQqyJZcWVuYcYJTiYlUR4/70CCvGmJFZWpRbl xxeV5qQWH2KU5mBREudd47w+TEggPbEkNTs1tSC1CCbLxMEp1cBoe63kZmbf4ZP7lWUefnl3 4LRA6OXlYfNTrYVMv17oDTX89+56uWFm+dfGLLHGsHefwruUF7EGKzxf//9fv4t+DP+fe7c+ hYfuK53i1HDO/6vAxbfcm7ZOOrMn8kDGwyvenr8n5IYvtLKqtSmbNKfd78yf5iU60zdG9C3o eH6x8mWVfK7jzFobJZbijERDLeai4kQAZ19MYIQCAAA= Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-26 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, 16 Feb 2016 13:20:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DF9BDAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-26) of BUNDLE. I have added text related to = exclusive RTP/RTPC mux to section 10.3 (and subsections). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37DF9BDAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new vers= ion (-26) of BUNDLE. I have added text related to exclusive RTP/RTPC mux to= section 10.3 (and subsections).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37DF9BDAESESSMB209erics_-- From nobody Tue Feb 16 07:15: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 E903B1B2AAF for ; Tue, 16 Feb 2016 07:15:29 -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 WON8gqSGkGfo for ; Tue, 16 Feb 2016 07:15:26 -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 58C9D1B2A50 for ; Tue, 16 Feb 2016 07:15:25 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-40-56c33d0ac24d Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4A.50.28465.A0D33C65; Tue, 16 Feb 2016 16:15:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Tue, 16 Feb 2016 16:15:22 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4A== Date: Tue, 16 Feb 2016 15:15:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@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.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DF9E40ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7pS6X7eEwg5UbzSymLn/MYnFt+WtW ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAlbFp5hbGgjMXGSt23V7I2MDYcYaxi5GTQ0LA ROLYjq9sELaYxIV764FsLg4hgcOMEns+z2OCcBYzSjw+1wLkcHCwCVhIdP/TBmkQEdCUmDy5 mRUkzCygLnF1cRBIWFjAQWLPk63sECWOEnNWnGODsLMkVt/bzgRiswioSjz78I4RpJVXwFfi 81EfiE1/WCQ6/i9lBanhFAiUaHuyCsxmBLrt+6k1YL3MAuISt57MZ4K4WUBiyZ7zzBC2qMTL x//AzpEQUJKYtjUNojxfouFxO1g5r4CgxMmZT1gmMIrOQjJpFpKyWUjKZoE9pimxfpc+RImi xJTuh+wQtoZE65y57MjiCxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtrBLb91dzCu fu14iFGAg1GJh7cg4lCYEGtiWXFl7iFGCQ5mJRHef6+AQrwpiZVVqUX58UWlOanFhxilOViU xHnXOK8PExJITyxJzU5NLUgtgskycXBKNTB6LFviW2f52cnuX4q5tNrTK+9DJd40F2uJvota /7Z/kwabmvqbbQlKfncPTtvKp+oh0q9ZZjJrjbuF6KV3xxdsnC7Sei4ipG3l/ZIZgvHHI/1t /zkUTbXXeSoifnhr08X/5mdkStPPL9XeE6/RpfnaumKvivoGzouH7vdkvZjzyOb2bw4R7XQl luKMREMt5qLiRACsHrdLsQIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 16 Feb 2016 15:15:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DF9E40ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIHN0aWxsIG5lZWQgdG8gY29uY2x1ZGUgdGhpcyBpc3N1ZSBiZWZvcmUgd2UgY2Fu IHNoaXAgQlVORExFLCBzbyBJ4oCZZCBsaWtlIHRvIGhlYXIgc29tZSBpbnB1dCBmcm9tIHBlb3Bs ZS4gSSBkbyBpbnRlbmQgdG8gcmVxdWVzdCBhZ2VuZGEgdGltZSB0byBkaXNjdXNzIGl0IGluIEJ1 ZW5vcyBBaXJlcywgYnV0IGlmIHdlIGNhbiBmaW5kIGEgc29sdXRpb24gYmVmb3JlIHRoYXQgdGhl cmUgd2lsbCBiZSBtb3JlIHRpbWUgZm9yIGNvb2tpZXPigKYNCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KRnJvbTogUGV0ZXIgVGhhdGNoZXIgW21haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbV0N ClNlbnQ6IDE3LiBtYXJyYXNrdXV0YSAyMDE1IDE6MDYNClRvOiBDaHJpc3RlciBIb2xtYmVyZw0K Q2M6IG1tdXNpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFF1ZXN0aW9ucyBhYm91 dCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEJVTkRMRQ0KDQoNCg0KT24gTW9uLCBOb3YgMTYsIDIwMTUg YXQgMjo1OCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwN Cg0KPj4gSSB0aGlua2luZyBtYW5kYXRpbmcgdGhlIGNhbmRpZGF0ZXMgYmUgZHVwbGljYXRlZCBp biB0aGUgYW5zd2VyIGhhcyB0aHJlZSBpc3N1ZXM6DQo+Pg0KPj4gMS4gIEl0IGNvbmZsaWN0cyB3 aXRoIHRyaWNrbGUgSUNFLg0KPj4gMi4gIEl0J3Mgc2xpZ2h0bHkgbW9yZSBjb21wbGV4IHRvIGlt cGxlbWVudCAod2UgaGF2ZSB0byBnbyBhZGQgZXh0cmEgbG9naWMgdG8gZ28gZHVwbGljYXRlIHRo ZXNlIHRoaW5ncykNCj4+IDMuICBJdCdzIGEgY29tcGxldGUgd2FzdGUgb2YgdGltZS9zcGFjZS9l ZmZvcnQuICBUaGUgcmVjaXBpZW50IG9mIHRoZXNlIGR1cGxpY2F0ZSBjYW5kaWRhdGVzIGlzIG5l dmVyIGdvaW5nIHRvIGFueXRoaW5nIHdpdGggdGhlbS4NCj4NCj4gVGhvc2UgYXJlIGFsbCBmYWly IHBvaW50cy4gSSB3aXNoIHdlJ2QgaGFkIG1vcmUgaW1wbGVtZW50YXRpb24gaW5wdXQgd2hlbiB3 ZSB3cml0ZSBvdXIgc3BlY3MuDQo+DQo+IFRoYXQncyB3aGF0IEknbSBwcm92aWRpbmcgbm93IDop LiAgV2UgY2FuIHN0aWxsIGNoYW5nZSB0aGUgc3BlYywgY2FuJ3Qgd2U/DQrigIsNClN1cmUuDQoN Ckhvd2V2ZXIsIGFzIHdlIGFyZSB0YWxraW5nIGFib3V0IGEgZGVzaWduIHdpc2UgYmlnIChpbiBt eSBvcGluaW9uKSBjaGFuZ2UsIGF0IGEgbGF0ZSBzdGFnZSwgSSdkIGxpa2UgdG8gaGVhciB3aGF0 IG90aGVyIHBlb3BsZSB0aGluay4NCg0K4oCLVGhhdCBzb3VuZHMgZmFpci4gIEknZCBsaWtlIHRv IGhlYXIgd2hhdCBvdGhlcnMgdGhpbmsgYWJvdXQgdGhpcy7igIsNCuKAiw0KDQoNCg0KPj4+QWxz byBrZWVwIGluIG1pbmQgdGhhdCwgd2hlbiBhIHN1YnNlcXVlbnQgb2ZmZXIgaXMgc2VudCwgdGhl IGJ1bmRsZS1vbmx5IGF0dHJpYnV0ZSBpcyBubyBsb25nZXIgdXNlZC4NCj4+DQrigIs+PkNhbiB5 b3UgcG9pbnQgb3V0IHdoZXJlIGluIHRoZSBkcmFmdCBpdCBzYXlzIHRoYXQ/ICBJIHRyaWVkIGZp bmRpbmcgaXQgYW5kIEkgaGFkIGEgZGlmZmljdWx0IHRpbWUgc2VlaW5nIHdoZXJlIGJ1bmRsZS1v bmx5IHdhc24ndCBhbGxvd2VkIGluIGEgcmVvZmZlci7igIsNCuKAiz4+DQo+PiBTZWN0aW9uIDgu NS4xIHNheXM6DQo+Pg0KPj4gICAgICAgICJXaGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGEgc3Vi c2VxdWVudCBvZmZlciwgaXQgTVVTVCBhc3NpZ24gdGhlDQo+PiAgICAgICBwcmV2aW91c2x5IHNl bGVjdGVkIG9mZmVyZXIgQlVORExFIGFkZHJlc3MgW1NlY3Rpb24gOC4zLjJdLCB0byBlYWNoDQo+ PiAgICAgICBidW5kbGVkICJtPSIgbGluZSAoaW5jbHVkaW5nIGFueSBidW5kbGUtb25seSAibT0i IGxpbmUpLCBleGNlcHQgaWY6Ig0KPj4NCj4+IEFuZCwgYXMgdGhlIHVzYWdlIG9mIHRoZSBhdHRy aWJ1dGUgaXMgb25seSBkZWZpbmVkIHdoZW4gdGhlIHBvcnQgdmFsdWUgaXMgemVybywgaXQgd291 bGQgbm90IHdvcmsgd2hlbiB0aGUgQlVORExFIGFkZHJlc3MgKHJlYWQ6IG5vbi16ZXJvIHBvcnQp IG11c3QgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5lLg0KPj4NCj4+IFNlY3Rpb24gNiBz YXlzOg0KPj4NCj4+ICAgIlRoZSB1c2FnZSBvZiB0aGUgJ2J1bmRsZS1vbmx5JyBhdHRyaWJ1dGUg aXMgb25seSBkZWZpbmVkIGZvciBhDQo+PiAgIGJ1bmRsZWQgIm09IiBsaW5lIHdpdGggYSB6ZXJv IHBvcnQgdmFsdWUsIHdpdGhpbiBhbiBvZmZlci4gIE90aGVyDQo+PiAgIHVzYWdlIGlzIHVuc3Bl Y2lmaWVkLiINCj4NCuKAiz4gVGhhbmtzLiAgVGhhdCB0ZXh0IHdvdWxkIGJlIG1vcmUgY2xlYXIg YXMgIndpdGggYW4gaW5pdGlhbCBvZmZlciIgaW5zdGVhZCBvZiAid2hpdGhpbiBhbiBvZmZlciIs IHNpbmNlIHRoYXQncyB3aGF0IGl0IHJlYWxseSBtZWFucyBpbiBjb25qdWN0aW9uIHdpdGggOC41 LjEuDQoNCk9rLg0KDQo+IEhvd2V2ZXIsIHRoYXQncyBwcmVjaXNlbHkgdGhlIHRleHQgdGhhdCBJ IHRoaW5rIHdlIGNvdWxkIGNoYW5nZS4gIEkgdGhpbmsgd2UgY291bGQgY2hhbmdlIHRoZSBidW5k bGUtb25seSBhdHRyaWJ1dGUgdG8NCj4gYmUgYWxsb3dlZCBpbiBhbnN3ZXJzIGFuZCBpbiBzdWJz ZXF1ZW50IG9mZmVycy4gIFRoZW4gY2xpZW50cyBjb3VsZCB1c2UgdGhlIGF0dHJpYnV0ZSBhcyBh IHdheSBvZiBhdm9pZGluZyBkdXBsaWNhdGlvbg0KPiBvZiBjYW5kaWRhdGVzIGFuZCB0aGUgY29t cGxpY2F0aW9ucyB3aXRoIHRyaWNrbGUgSUNFLuKAiw0KDQpBc3N1bWluZyB3ZSB3b3VsZCByZW1v dmUgdGhlIGR1cGxpY2F0aW9uIG9mIGNhbmRpZGF0ZXMsIEkgZG9uJ3QgdGhpbmsgdGhhdCB3b3Vs ZCByZXF1aXJlIHVzIHRvIGNoYW5nZSBhIHNlbWFudGljcyBvZiB0aGUgYXR0cmlidXRlLiBXZSBj b3VsZCBzaW1wbHkgc2F5IHRoYXQgdGhlIGNhbmRpZGF0ZXMgZG9uJ3QgbmVlZCB0byBiZSBkdXBs aWNhdGVkIGluIGJ1bmRsZWQgbS0gbGluZXMsIG5vIG1hdHRlciBpZiB0aG9zZSBtLSBsaW5lcyBh cmUgYnVuZGxlLW9ubHkgb3Igbm90Lg0KDQpUaGF0IHdvdWxkIHdvcmsgYXMgd2VsbC4NCuKAiw0K DQoNCj4+Pj4gV291bGQgeW91IHRoZW4gYWxzbyBpbiB0aGUgc3Vic2VxdWVudCBvZmZlciBvbmx5 IGFzc2lnbiBwb3NzaWJsZSBjYW5kaWRhdGVzIHRvIG9ubHkgb25lIG0tIGxpbmUgd2l0aGluIHRo ZSBidW5kbGUgZ3JvdXA/DQo+Pj4NCuKAiz4+PiBUaGF0IHNvdW5kcyBsb2dpY2FsIHRvIG1lLiAg VGhleSBhcmVuJ3QgaW5jbHVkZWQgaW4gdGhlIGZpcnN0IG9mZmVyLiAgV2h5IGFkZCB0aGVtIHRv IHN1YnNlcXVlbnQgb2ZmZXJzPyAgSXQncyBpbmNvbnNpc3RlbnQsIGFuZCBhIHdhc3RlLg0KPj4N Cj4+IFRoZW4gc29tZW9uZSBjb3VsZCBhc2s6IHdoYXQgYWJvdXQgb3RoZXIgKG5vbi1jYW5kaWRh dGUpIGF0dHJpYnV0ZXMgdGhhdCBtdXN0IGhhdmUgaWRlbnRpY2FsIHZhbHVlcyBmb3IgZWFjaCBi dW5kbGVkIG0tIGxpbmU/IFNob3VsZCB0aG9zZSBhbHNvIGJlIGFzc2lnbmVkIHRvIG9ubHkgb25l IG9mIHRoZSBtLSBsaW5lcz8NCj4NCuKAiz4gSWYgaXQncyBzb21ldGhpbmcgdW5pcXVlIHRvIHRo ZSBidW5kbGUgZ3JvdXAsIGFuZCBub3QgdGhlIG0tbGluZSwgdGhhdCBzZWVtcyByZWFzb25hYmxl IHRvIG1lLiAg4oCLDQrigIs+DQrigIs+IEJ1dCBjYW5kaWRhdGVzIGFyZSBtb3JlIHBhaW5mdWwg dGhhbiB0aG9zZSB3b3VsZCBiZSBiZWNhdXNlIG9mIHRoZSBpbnRlcmFjdGlvbnMgd2l0aCB0cmlj a2xlIElDRS4gIElmIGl0IHdlcmVuJ3QgZm9yIHRyaWNrbGUgSUNFIHRoaXMgd291bGRuJ3QgYmUg YXMgYmlnIG9mIGEgZGVhbC7igIsNCg0KQ29ycmVjdC4gV2UganVzdCBuZWVkIHRvIG1ha2UgaXQg dmVyeSBjbGVhciB3aGV0aGVyIGl0IGFwcGxpZXMgb25seSB0byBjYW5kaWRhdGUgYXR0cmlidXRl cywgb3IgdG8gYXR0cmlidXRlcyB3aXRoIGlkZW50aWNhbCB2YWx1ZXMgaW4gZ2VuZXJhbC4NCg0K Pj4+Pj4+Pj4gMi4gIElmIHRoZSBhbnN3ZXJlciBkb2VzIG5vdCBpbmNsdWRlIGFueSBjYW5kaWRh dGVzIGluIHRoZSBhbnN3ZXIgYW5kIGluc3RlYWQgdHJpY2tsZXMgdGhlbSBsYXRlciwgc2hvdWxk IGl0IHRyaWNrbGUgdGhlbQ0KPj4+Pj4+Pj4gTiB0aW1lcyAob25jZSBmb3IgZWFjaCBtLWxpbmUg aW4gdGhlIEJVTkRMRSBncm91cCkgb3IgPjEgdGltZT8gIDEgdGltZSBzZWVtcyBtdWNoIG1vcmUg cmVhc29uYWJsZSB0aGFuIE4gdGltZXMsIGJ1dA0KPj4+Pj4+Pj4gaWYgd2UgZHVwbGljYXRlIGNh bmRpZGF0ZXMgaW4gdGhlIGFuc3dlciwgYnV0IG5vdCBkdXBsaWNhdGUgdGhlbSB3aGlsZSB0cmlj a2xpbmcsIHRoYXQncyBhIGJpdCBpbmNvbnNpc3RlbnQuICBZZXQgPmFub3RoZXIgcmVhc29uIHRv IG5vdCBkdXBsaWNhdGUgaW4gdGhlIGFuc3dlciA6KS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQXNzdW1p bmcgeW91IHVzZSBTRFAgdG8gc2lnbmFsIHRoZSB0cmlja2xlZCBjYW5kaWRhdGVzLCBpdOKAmXMg dHJ1ZSB0aGF0IHlvdSB3b3VsZCBkdXBsaWNhdGUgdGhlbSwNCj4+Pj4+Pj4NCj4+Pj4+PuKAi1do YXQncyB0aGUgcmF0aW9uYWxlIGZvciB0aGF0PyAgVGhlc2UgZHVwbGljYXRlcyBwcm92aWRlIG5v IHZhbHVlLCBhbmQgaW4gdGhlIGNhc2Ugb2YgbWFueSBtLWxpbmVzIChzdWNoIGFzIGEgY29uZmVy ZW5jaW5nDQo+Pj4+Pj5zeXN0ZW0gd2l0aCBtYW55IHBhcnRpY2lwYW50cyksIHdlIGNvdWxkIGJl IHRhbGtpbmcgYWJvdXQgMzB4IHRoZSBudW1iZXIgb2YgY2FuZGlkYXRlcyBiZWluZyBzaWduYWxl ZC4NCj4+Pj4NCj4+Pj4gSSBoZWFyIHdoYXQgeW91IGFyZSBzYXlpbmcuDQo+Pj4+DQo+Pj4+IEJ1 dCwgaWYgd2Ugd291bGQgZG8gYSBjaGFuZ2UsIHdlIGFsc28gbmVlZCB0byBsb29rIGF0IHRoZSBm dWxsIHBpY3R1cmUsIGFuZCBjb25zaWRlciBzdWJzZXF1ZW50IG9mZmVycyBldGMuDQo+Pj4NCuKA iz4+PiBJIHRoaW5rIGEgc2ltcGxlIHJ1bGUgd291bGQgYmUgImlmIHlvdSBrbm93IGl0J3MgZ29p bmcgdG8gYmUgYnVuZGxlZCBvbnRvIGFub3RoZXIgbS1saW5lLCBkb24ndCBpbmNsdWRlDQo+Pj4g Y2FuZGlkYXRlcyIuICBUaGF0IHdvdWxkIGdvIGZvciBidW5kbGUtb25seSBtLWxpbmVzIGluIGFu IG9mZmVyLCBidW5kbGVkIG0tbGluZXMgaW4gYW4gYW5zd2VyLCBhbmQgYnVuZGxlZCBtLWxpbmVz IGluIGEgcmUtb2ZmZXIu4oCLDQrigIs+Pj4NCj4+IEJ1bmRsZWQgbS0gbGluZXMgaW4gYSByZS1v ZmZlciBjYW4gc3RpbGwgYmUgcmVqZWN0ZWQgYnkgdGhlIGFuc3dlcmVyLg0KPg0K4oCLPiBUaGF0 IHNvdW5kcyB0aGUgc2FtZSBhcyBhbiBpbml0aWFsIG9mZmVyLiAgSG93IGRvZXMgaXQgaW1wbHkg dGhhdCBhIHJlLW9mZmVyIG11c3QgZHVwbGljYXRlDQo+IGNhbmRpZGF0ZXMgYWNyb3NzIG0tbGlu ZXMsIGV2ZW4gd2hlbiBhbiBpbml0aWFsIG9mZmVyIGRvZXNuJ3QgbmVlZCB0bz/igIsNCuKAiw0K SW4gdGhlIGluaXRpYWwgb2ZmZXIgZWFjaCBtLSBsaW5lIGNvbnRhaW5zIGNhbmRpZGF0ZXMgKHVu aXF1ZSkuIElmIGFuIG0tIGxpbmUgaW4gdGhlIG9mZmVyIGlzIHJlamVjdGVkLCB0aGUgYW5zd2Vy ZXIgbXVzdCBzZWxlY3QgdGhlIG9mZmVyZXIgQlVORExFIGFkZHJlc3MgKGFuZCB0aGUgYXNzb2Np YXRlZCBjYW5kaWRpYXRlcykgZnJvbSBhbm90aGVyIG0tIGxpbmUuDQoNCk5vdywgaW4gYSByZS1v ZmZlciwgaWYgdGhlIG0tIGxpbmUgY29udGFpbmluZyB0aGUgY2FuZGlkYXRlcyBpcyByZWplY3Rl ZCwgdGhlIGFuc3dlcmVyIG5lZWRzIHRvIGluY2x1ZGUgaXRzIGNhbmRpZGF0ZXMgaW4gYW5vdGhl ciBtLSBsaW5lIGluIHRoZSBhbnN3ZXIuIFRoYXQncyBkb2FibGUsIGJ1dCBpdCB3b3VsZCBuZWVk IHRvIGJlIGNsZWFybHkgZG9jdW1lbnRlZC4gSW4gb3RoZXIgd29yZHM6IGl0IG5lZWRzIHRvIGJl IGNsZWFyIHRoYXQgdGhlIGNhbmRpZGF0ZXMgY2FuIG9jY3VyIGluIEFOWSBvZiB0aGUgYnVuZGxl ZCBtLSBsaW5lcywgYW5kIHRoYXQgbS0gbGluZSBtYXkgY2hhbmdlIGJldHdlZW4gb2ZmZXJzIGFu ZCBhbnN3ZXJzLg0KDQrigItTbyBhIHJ1bGUgb2YgInRoZSBjYW5kaWRhdGVzIGNhbiBiZSBpbiBh bnkgb25lIG9mIHRoZSBtLWxpbmVzLCBhbmQgaXQgZG9lc24ndCBtYXR0ZXIgd2hpY2gsIGFuZCBp dCBjYW4gY2hhbmdlIGFueSB0aW1lIi4gIFRoYXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZS4gIEl0 IGxlYXZlIHRoZSBtb3N0IGZsZXhpYmlsaXR5IHRvIHRoZSBvbmUgd3JpdGluZyB0aGUgU0RQLCBh bmQgaXQncyB2ZXJ5IGVhc3kgdG8gaW1wbGVtZW50IGZvciB0aGUgb25lIHJlYWRpbmcgdGhlIFNE UC7igIsNCg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37DF9E40ESESSMB209erics_ 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+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHN0aWxsIG5l ZWQgdG8gY29uY2x1ZGUgdGhpcyBpc3N1ZSBiZWZvcmUgd2UgY2FuIHNoaXAgQlVORExFLCBzbyBJ 4oCZZCBsaWtlIHRvIGhlYXIgc29tZSBpbnB1dCBmcm9tIHBlb3BsZS4gSSBkbyBpbnRlbmQgdG8g cmVxdWVzdCBhZ2VuZGEgdGltZQ0KIHRvIGRpc2N1c3MgaXQgaW4gQnVlbm9zIEFpcmVzLCBidXQg aWYgd2UgY2FuIGZpbmQgYSBzb2x1dGlvbiBiZWZvcmUgdGhhdCB0aGVyZSB3aWxsIGJlIG1vcmUg dGltZSBmb3IgY29va2llc+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGV0ZXIgVGhhdGNoZXIgW21haWx0bzpwdGhhdGNoZXJAZ29v Z2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNy4gbWFycmFza3V1dGEgMjAxNSAxOjA2PGJy Pg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gbW11c2ljQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQg SUNFIGNhbmRpZGF0ZXMgd2l0aCBCVU5ETEU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDE2LCAyMDE1IGF0IDI6NTgg UE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSw8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5raW5nIG1hbmRhdGluZyB0aGUgY2FuZGlk YXRlcyBiZSBkdXBsaWNhdGVkIGluIHRoZSBhbnN3ZXIgaGFzIHRocmVlIGlzc3Vlczo8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDEuJm5ic3A7IEl0IGNvbmZsaWN0cyB3aXRoIHRyaWNrbGUg SUNFLjxicj4NCiZndDsmZ3Q7IDIuJm5ic3A7IEl0J3Mgc2xpZ2h0bHkgbW9yZSBjb21wbGV4IHRv IGltcGxlbWVudCAod2UgaGF2ZSB0byBnbyBhZGQgZXh0cmEgbG9naWMgdG8gZ28gZHVwbGljYXRl IHRoZXNlIHRoaW5ncyk8YnI+DQomZ3Q7Jmd0OyAzLiZuYnNwOyBJdCdzIGEgY29tcGxldGUgd2Fz dGUgb2YgdGltZS9zcGFjZS9lZmZvcnQuJm5ic3A7IFRoZSByZWNpcGllbnQgb2YgdGhlc2UgZHVw bGljYXRlIGNhbmRpZGF0ZXMgaXMgbmV2ZXIgZ29pbmcgdG8gYW55dGhpbmcgd2l0aCB0aGVtLiAm bmJzcDs8YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0OyBUaG9zZSBhcmUgYWxsIGZhaXIgcG9pbnRz LiBJIHdpc2ggd2UnZCBoYWQgbW9yZSBpbXBsZW1lbnRhdGlvbiBpbnB1dCB3aGVuIHdlIHdyaXRl IG91ciBzcGVjcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGF0J3Mgd2hhdCBJJ20gcHJvdmlkaW5n IG5vdyA6KS4mbmJzcDsgV2UgY2FuIHN0aWxsIGNoYW5nZSB0aGUgc3BlYywgY2FuJ3Qgd2U/PGJy Pg0K4oCLPGJyPg0KU3VyZS48YnI+DQo8YnI+DQpIb3dldmVyLCBhcyB3ZSBhcmUgdGFsa2luZyBh Ym91dCBhIGRlc2lnbiB3aXNlIGJpZyAoaW4gbXkgb3BpbmlvbikgY2hhbmdlLCBhdCBhIGxhdGUg c3RhZ2UsIEknZCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlciBwZW9wbGUgdGhpbmsuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKA i1RoYXQgc291bmRzIGZhaXIuJm5ic3A7IEknZCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlcnMgdGhp bmsgYWJvdXQgdGhpcy7igIs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PGJyPg0KJmd0OyZn dDsmZ3Q7QWxzbyBrZWVwIGluIG1pbmQgdGhhdCwgd2hlbiBhIHN1YnNlcXVlbnQgb2ZmZXIgaXMg c2VudCwgdGhlIGJ1bmRsZS1vbmx5IGF0dHJpYnV0ZSBpcyBubyBsb25nZXIgdXNlZC48YnI+DQom Z3Q7Jmd0Ozxicj4NCuKAiyZndDsmZ3Q7Q2FuIHlvdSBwb2ludCBvdXQgd2hlcmUgaW4gdGhlIGRy YWZ0IGl0IHNheXMgdGhhdD8mbmJzcDsgSSB0cmllZCBmaW5kaW5nIGl0IGFuZCBJIGhhZCBhIGRp ZmZpY3VsdCB0aW1lIHNlZWluZyB3aGVyZSBidW5kbGUtb25seSB3YXNuJ3QgYWxsb3dlZCBpbiBh IHJlb2ZmZXIu4oCLPGJyPg0K4oCLJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTZWN0aW9uIDguNS4x IHNheXM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmcXVvdDtXaGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGEgc3Vic2VxdWVudCBvZmZlciwg aXQgTVVTVCBhc3NpZ24gdGhlPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJl dmlvdXNseSBzZWxlY3RlZCBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIFtTZWN0aW9uIDguMy4yXSwg dG8gZWFjaDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJ1bmRsZWQgJnF1b3Q7 bT0mcXVvdDsgbGluZSAoaW5jbHVkaW5nIGFueSBidW5kbGUtb25seSAmcXVvdDttPSZxdW90OyBs aW5lKSwgZXhjZXB0IGlmOiZxdW90Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQW5kLCBh cyB0aGUgdXNhZ2Ugb2YgdGhlIGF0dHJpYnV0ZSBpcyBvbmx5IGRlZmluZWQgd2hlbiB0aGUgcG9y dCB2YWx1ZSBpcyB6ZXJvLCBpdCB3b3VsZCBub3Qgd29yayB3aGVuIHRoZSBCVU5ETEUgYWRkcmVz cyAocmVhZDogbm9uLXplcm8gcG9ydCkgbXVzdCBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIG0tIGxp bmUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTZWN0aW9uIDYgc2F5czo8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZxdW90O1RoZSB1c2FnZSBvZiB0aGUgJ2J1 bmRsZS1vbmx5JyBhdHRyaWJ1dGUgaXMgb25seSBkZWZpbmVkIGZvciBhPGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7YnVuZGxlZCAmcXVvdDttPSZxdW90OyBsaW5lIHdpdGggYSB6ZXJvIHBvcnQg dmFsdWUsIHdpdGhpbiBhbiBvZmZlci4mbmJzcDsgT3RoZXI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDt1c2FnZSBpcyB1bnNwZWNpZmllZC4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0K4oCLJmd0OyBU aGFua3MuJm5ic3A7IFRoYXQgdGV4dCB3b3VsZCBiZSBtb3JlIGNsZWFyIGFzICZxdW90O3dpdGgg YW4gaW5pdGlhbCBvZmZlciZxdW90OyBpbnN0ZWFkIG9mICZxdW90O3doaXRoaW4gYW4gb2ZmZXIm cXVvdDssIHNpbmNlIHRoYXQncyB3aGF0IGl0IHJlYWxseSBtZWFucyBpbiBjb25qdWN0aW9uIHdp dGggOC41LjEuPGJyPg0KPGJyPg0KT2suPGJyPg0KPGJyPg0KJmd0OyBIb3dldmVyLCB0aGF0J3Mg cHJlY2lzZWx5IHRoZSB0ZXh0IHRoYXQgSSB0aGluayB3ZSBjb3VsZCBjaGFuZ2UuJm5ic3A7IEkg dGhpbmsgd2UgY291bGQgY2hhbmdlIHRoZSBidW5kbGUtb25seSBhdHRyaWJ1dGUgdG88YnI+DQom Z3Q7IGJlIGFsbG93ZWQgaW4gYW5zd2VycyBhbmQgaW4gc3Vic2VxdWVudCBvZmZlcnMuJm5ic3A7 IFRoZW4gY2xpZW50cyBjb3VsZCB1c2UgdGhlIGF0dHJpYnV0ZSBhcyBhIHdheSBvZiBhdm9pZGlu ZyBkdXBsaWNhdGlvbjxicj4NCiZndDsgb2YgY2FuZGlkYXRlcyBhbmQgdGhlIGNvbXBsaWNhdGlv bnMgd2l0aCB0cmlja2xlIElDRS7igIs8YnI+DQo8YnI+DQpBc3N1bWluZyB3ZSB3b3VsZCByZW1v dmUgdGhlIGR1cGxpY2F0aW9uIG9mIGNhbmRpZGF0ZXMsIEkgZG9uJ3QgdGhpbmsgdGhhdCB3b3Vs ZCByZXF1aXJlIHVzIHRvIGNoYW5nZSBhIHNlbWFudGljcyBvZiB0aGUgYXR0cmlidXRlLiBXZSBj b3VsZCBzaW1wbHkgc2F5IHRoYXQgdGhlIGNhbmRpZGF0ZXMgZG9uJ3QgbmVlZCB0byBiZSBkdXBs aWNhdGVkIGluIGJ1bmRsZWQgbS0gbGluZXMsIG5vIG1hdHRlciBpZiB0aG9zZSBtLSBsaW5lcyBh cmUgYnVuZGxlLW9ubHkNCiBvciBub3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhdCB3b3VsZCB3b3JrIGFzIHdlbGwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPuKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFdvdWxkIHlvdSB0 aGVuIGFsc28gaW4gdGhlIHN1YnNlcXVlbnQgb2ZmZXIgb25seSBhc3NpZ24gcG9zc2libGUgY2Fu ZGlkYXRlcyB0byBvbmx5IG9uZSBtLSBsaW5lIHdpdGhpbiB0aGUgYnVuZGxlIGdyb3VwPzxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCuKAiyZndDsmZ3Q7Jmd0OyBUaGF0IHNvdW5kcyBsb2dpY2FsIHRv IG1lLiZuYnNwOyBUaGV5IGFyZW4ndCBpbmNsdWRlZCBpbiB0aGUgZmlyc3Qgb2ZmZXIuJm5ic3A7 IFdoeSBhZGQgdGhlbSB0byBzdWJzZXF1ZW50IG9mZmVycz8mbmJzcDsgSXQncyBpbmNvbnNpc3Rl bnQsIGFuZCBhIHdhc3RlLiZuYnNwOzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlbiBz b21lb25lIGNvdWxkIGFzazogd2hhdCBhYm91dCBvdGhlciAobm9uLWNhbmRpZGF0ZSkgYXR0cmli dXRlcyB0aGF0IG11c3QgaGF2ZSBpZGVudGljYWwgdmFsdWVzIGZvciBlYWNoIGJ1bmRsZWQgbS0g bGluZT8gU2hvdWxkIHRob3NlIGFsc28gYmUgYXNzaWduZWQgdG8gb25seSBvbmUgb2YgdGhlIG0t IGxpbmVzPzxicj4NCiZndDs8YnI+DQrigIsmZ3Q7IElmIGl0J3Mgc29tZXRoaW5nIHVuaXF1ZSB0 byB0aGUgYnVuZGxlIGdyb3VwLCBhbmQgbm90IHRoZSBtLWxpbmUsIHRoYXQgc2VlbXMgcmVhc29u YWJsZSB0byBtZS4gJm5ic3A74oCLPGJyPg0K4oCLJmd0Ozxicj4NCuKAiyZndDsgQnV0IGNhbmRp ZGF0ZXMgYXJlIG1vcmUgcGFpbmZ1bCB0aGFuIHRob3NlIHdvdWxkIGJlIGJlY2F1c2Ugb2YgdGhl IGludGVyYWN0aW9ucyB3aXRoIHRyaWNrbGUgSUNFLiZuYnNwOyBJZiBpdCB3ZXJlbid0IGZvciB0 cmlja2xlIElDRSB0aGlzIHdvdWxkbid0IGJlIGFzIGJpZyBvZiBhIGRlYWwu4oCLPGJyPg0KPGJy Pg0KQ29ycmVjdC4gV2UganVzdCBuZWVkIHRvIG1ha2UgaXQgdmVyeSBjbGVhciB3aGV0aGVyIGl0 IGFwcGxpZXMgb25seSB0byBjYW5kaWRhdGUgYXR0cmlidXRlcywgb3IgdG8gYXR0cmlidXRlcyB3 aXRoIGlkZW50aWNhbCB2YWx1ZXMgaW4gZ2VuZXJhbC48YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyLiZuYnNwOyBJZiB0aGUgYW5zd2VyZXIgZG9lcyBub3QgaW5j bHVkZSBhbnkgY2FuZGlkYXRlcyBpbiB0aGUgYW5zd2VyIGFuZCBpbnN0ZWFkIHRyaWNrbGVzIHRo ZW0gbGF0ZXIsIHNob3VsZCBpdCB0cmlja2xlIHRoZW08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBOIHRpbWVzIChvbmNlIGZvciBlYWNoIG0tbGluZSBpbiB0aGUgQlVORExF IGdyb3VwKSBvciAmZ3Q7MSB0aW1lPyAmbmJzcDsxIHRpbWUgc2VlbXMgbXVjaCBtb3JlIHJlYXNv bmFibGUgdGhhbiBOIHRpbWVzLCBidXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpZiB3ZSBkdXBsaWNhdGUgY2FuZGlkYXRlcyBpbiB0aGUgYW5zd2VyLCBidXQgbm90IGR1 cGxpY2F0ZSB0aGVtIHdoaWxlIHRyaWNrbGluZywgdGhhdCdzIGEgYml0IGluY29uc2lzdGVudC4m bmJzcDsgWWV0ICZndDthbm90aGVyIHJlYXNvbiB0byBub3QgZHVwbGljYXRlIGluIHRoZSBhbnN3 ZXIgOikuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgQXNzdW1pbmcgeW91IHVzZSBTRFAgdG8gc2lnbmFsIHRoZSB0cmlj a2xlZCBjYW5kaWRhdGVzLCBpdOKAmXMgdHJ1ZSB0aGF0IHlvdSB3b3VsZCBkdXBsaWNhdGUgdGhl bSw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q74oCLV2hhdCdzIHRoZSByYXRpb25hbGUgZm9yIHRoYXQ/Jm5ic3A7IFRoZXNlIGR1 cGxpY2F0ZXMgcHJvdmlkZSBubyB2YWx1ZSwgYW5kIGluIHRoZSBjYXNlIG9mIG1hbnkgbS1saW5l cyAoc3VjaCBhcyBhIGNvbmZlcmVuY2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O3N5 c3RlbSB3aXRoIG1hbnkgcGFydGljaXBhbnRzKSwgd2UgY291bGQgYmUgdGFsa2luZyBhYm91dCAz MHggdGhlIG51bWJlciBvZiBjYW5kaWRhdGVzIGJlaW5nIHNpZ25hbGVkLiAmbmJzcDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGhlYXIgd2hhdCB5b3UgYXJl IHNheWluZy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBCdXQs IGlmIHdlIHdvdWxkIGRvIGEgY2hhbmdlLCB3ZSBhbHNvIG5lZWQgdG8gbG9vayBhdCB0aGUgZnVs bCBwaWN0dXJlLCBhbmQgY29uc2lkZXIgc3Vic2VxdWVudCBvZmZlcnMgZXRjLjxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCuKAiyZndDsmZ3Q7Jmd0OyBJIHRoaW5rIGEgc2ltcGxlIHJ1bGUgd291bGQg YmUgJnF1b3Q7aWYgeW91IGtub3cgaXQncyBnb2luZyB0byBiZSBidW5kbGVkIG9udG8gYW5vdGhl ciBtLWxpbmUsIGRvbid0IGluY2x1ZGU8YnI+DQomZ3Q7Jmd0OyZndDsgY2FuZGlkYXRlcyZxdW90 Oy4mbmJzcDsgVGhhdCB3b3VsZCBnbyBmb3IgYnVuZGxlLW9ubHkgbS1saW5lcyBpbiBhbiBvZmZl ciwgYnVuZGxlZCBtLWxpbmVzIGluIGFuIGFuc3dlciwgYW5kIGJ1bmRsZWQgbS1saW5lcyBpbiBh IHJlLW9mZmVyLuKAizxicj4NCuKAiyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEJ1bmRsZWQg bS0gbGluZXMgaW4gYSByZS1vZmZlciBjYW4gc3RpbGwgYmUgcmVqZWN0ZWQgYnkgdGhlIGFuc3dl cmVyLjxicj4NCiZndDs8YnI+DQrigIsmZ3Q7IFRoYXQgc291bmRzIHRoZSBzYW1lIGFzIGFuIGlu aXRpYWwgb2ZmZXIuJm5ic3A7IEhvdyBkb2VzIGl0IGltcGx5IHRoYXQgYSByZS1vZmZlciBtdXN0 IGR1cGxpY2F0ZTxicj4NCiZndDsgY2FuZGlkYXRlcyBhY3Jvc3MgbS1saW5lcywgZXZlbiB3aGVu IGFuIGluaXRpYWwgb2ZmZXIgZG9lc24ndCBuZWVkIHRvP+KAizxicj4NCuKAizxicj4NCkluIHRo ZSBpbml0aWFsIG9mZmVyIGVhY2ggbS0gbGluZSBjb250YWlucyBjYW5kaWRhdGVzICh1bmlxdWUp LiBJZiBhbiBtLSBsaW5lIGluIHRoZSBvZmZlciBpcyByZWplY3RlZCwgdGhlIGFuc3dlcmVyIG11 c3Qgc2VsZWN0IHRoZSBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIChhbmQgdGhlIGFzc29jaWF0ZWQg Y2FuZGlkaWF0ZXMpIGZyb20gYW5vdGhlciBtLSBsaW5lLjxicj4NCjxicj4NCk5vdywgaW4gYSBy ZS1vZmZlciwgaWYgdGhlIG0tIGxpbmUgY29udGFpbmluZyB0aGUgY2FuZGlkYXRlcyBpcyByZWpl Y3RlZCwgdGhlIGFuc3dlcmVyIG5lZWRzIHRvIGluY2x1ZGUgaXRzIGNhbmRpZGF0ZXMgaW4gYW5v dGhlciBtLSBsaW5lIGluIHRoZSBhbnN3ZXIuIFRoYXQncyBkb2FibGUsIGJ1dCBpdCB3b3VsZCBu ZWVkIHRvIGJlIGNsZWFybHkgZG9jdW1lbnRlZC4gSW4gb3RoZXIgd29yZHM6IGl0IG5lZWRzIHRv IGJlIGNsZWFyIHRoYXQgdGhlDQogY2FuZGlkYXRlcyBjYW4gb2NjdXIgaW4gQU5ZIG9mIHRoZSBi dW5kbGVkIG0tIGxpbmVzLCBhbmQgdGhhdCBtLSBsaW5lIG1heSBjaGFuZ2UgYmV0d2VlbiBvZmZl cnMgYW5kIGFuc3dlcnMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi1NvIGEgcnVsZSBvZiAmcXVv dDt0aGUgY2FuZGlkYXRlcyBjYW4gYmUgaW4gYW55IG9uZSBvZiB0aGUgbS1saW5lcywgYW5kIGl0 IGRvZXNuJ3QgbWF0dGVyIHdoaWNoLCBhbmQgaXQgY2FuIGNoYW5nZSBhbnkgdGltZSZxdW90Oy4m bmJzcDsgVGhhdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lLiZuYnNwOyBJdCBsZWF2ZSB0aGUgbW9z dCBmbGV4aWJpbGl0eSB0byB0aGUNCiBvbmUgd3JpdGluZyB0aGUgU0RQLCBhbmQgaXQncyB2ZXJ5 IGVhc3kgdG8gaW1wbGVtZW50IGZvciB0aGUgb25lIHJlYWRpbmcgdGhlIFNEUC7igIs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hy aXN0ZXImbmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37DF9E40ESESSMB209erics_-- From nobody Wed Feb 17 04:51:22 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 D05F01B395B; Wed, 17 Feb 2016 04:51:21 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217125121.19242.40885.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 04:51:21 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 12:51:22 -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 of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju (Raju) Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-data-channel-sdpneg-08.txt Pages : 38 Date : 2016-02-17 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 17 05:14: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 0DCD91B397C for ; Wed, 17 Feb 2016 05:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 y7oGJm_Ct_rw for ; Wed, 17 Feb 2016 05:14:49 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 9DDFE1B396D for ; Wed, 17 Feb 2016 05:14:48 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D6C54FF61D5ED for ; Wed, 17 Feb 2016 13:14:43 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1HDEkpE018318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Feb 2016 13:14:46 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1HDDOOY016173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Feb 2016 14:14:41 +0100 Received: from [149.204.68.190] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Feb 2016 14:12:50 +0100 To: References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> From: Juergen Stoetzer-Bradler Message-ID: <56C471D1.8010701@alcatel-lucent.com> Date: Wed, 17 Feb 2016 14:12:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C31DC5.80105@alcatel-lucent.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060308090808070600020805" X-Originating-IP: [135.239.27.40] 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: Wed, 17 Feb 2016 13:14:52 -0000 --------------ms060308090808070600020805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Paul, Christian, Flemming, Bo, Have just submitted version 08 of draft-ietf-mmusic-data-channel-sdpneg. The changes compared to version 07 are essentially as follows. * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) regarding the = relationship of=20 subprotocols and their attributes. * Two new SDP offer/answer considerations in section 5.2.5 (Various SDP= Offer/Answer Scenarios and=20 Considerations) regarding unknown subprotocol attributes or known subpro= tocol attributes, whose=20 data channel transport specific semantic is not known. * A new paragraph in section 8.1 (IANA Considerations / Subprotocol Ide= ntifiers) related to cases,=20 where a subprotocol is defined for data channel and Websocket transport. These changes should address the points discussed in this email thread. Thank you, Juergen On 16.02.2016 14:01, Juergen Stoetzer-Bradler wrote: > Paul, > > Thanks for further feedback. Fully agree now that the subprotocol param= eter should stay optional. > Will come back with with a proposal of how the sdpneg text could be enh= anced as discussed. > > Thanks, > Juergen > > On 15.02.2016 17:08, EXT Paul Kyzivat wrote: >> On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: >>> Paul, >>> >>> In your case 2) I would agree that the usage of dcsa embedded attribu= tes >>> seems questionable. After all, the dcsa attribute is defined in sdpne= g >>> as encapsulating a subprotocol specific attribute. If the subprotocol= >>> may dynamically change over time without further (SDP offer/answer) >>> negotiation, then a negotiation of dcsa embedded attributes may indee= d >>> not be very helpful. >>> >>> In your case 1), I am wondering how would the SDP answerer know which= >>> subprotocol to use for which data channel, if the subprotocol id is n= ot >>> added to the data channel's dmap attribute (at least if multiple data= >>> channels are negotiated)? Conceivably via some provisioning, or via a= >>> mutual understanding of a certain subprotocol to SCTP stream id mappi= ng, >>> or via a certain a priori agreed label usage. I hadn't thought of suc= h >>> cases when raising the question if the subprotocol should actually be= >>> mandatory. >> >> IMO it could be any of those. But for this use case it seems more like= ly that channels will be=20 >> opened dynamically rather than via SDP. >> >> I think the provision for *not* specifying the subprotocol was primari= ly to establish equivalence=20 >> with what is possible via DCEP. >> >> One possibility is that SDP is used to specify how many channels are o= pened, with the=20 >> understanding that each of them will use the same application-specific= protocol. >> >> One possible use for dcsa with an unnamed protocol would be if the int= ent is to use a proprietary=20 >> variant of a standard protocol, where there is still a desire to negot= iate options using=20 >> attributes applicable to that standard base protocol. But I'm really s= tretching to come up with=20 >> this. >> >>> But such use cases would certainly go beyond a pure SDP offer/answer >>> negotiation use case and I would argue that such use cases would also= go >>> beyond the scope of the sdpneg draft. >> >> Probably. >> >>> I could now imagine the sdpneg draft saying that an SDP offerer shoul= d >>> add a subprotocol identifier to an offered data channel's dcmap >>> attribute, if it also adds dcsa embedded subprotocol attributes. And >>> that an implementation would be on its own, if it does not follow tha= t >>> recommendation (for whatever reasons). >> >> That could work. >> >>> Further, similar as for non-dcsa embedded attributes, we could >>> explicitly add text to the sdpneg draft saying that a recipient of an= an >>> SDP offer or answer should ignore dcsa embedded attributes not only i= f >>> they are completely unknown, but also if their semantics related to t= he >>> subprotocol is not known. >>> (The current draft says in sec 5.2.3 that the SDP answerer "/Parses a= nd >>> applies the SDP offer. Note that the typical parser normally ignores= >>> unknown SDP attributes, which includes data channel related >>> attributes./" I think we could make this clearer and explicitly refer= to >>> dcsa embedded subprotocol attributes.) >> >> Yes, that would help. >> >> Thanks, >> Paul >> >>> Thanks, >>> Juergen >>> >>> On 12.02.2016 17:58, EXT Paul Kyzivat wrote: >>>> Juergen, >>>> >>>> You bring up a point that perhaps needs further discussion: what doe= s >>>> it mean when the subprotocol is not specified? >>>> >>>> IIUC there are at least a couple of reasons this might come about: >>>> >>>> 1) The protocol to be used is not standardized. There is no globally= >>>> unique name for it. The two ends know what protocol to use based on >>>> context. >>>> >>>> 2) The protocol to be used on the channel is not determined via SDP >>>> negotiation. The applications want to establish the channel, and the= n >>>> dynamically decide what protocol to use with it. (And that protocol >>>> may change over time.) >>>> >>>> I guess that it still might be meaningful to use dcsa with (1), but >>>> there would be no way to determine by examination of the SDP whether= >>>> the usage was compatible with the protocol. In this case the usage o= f >>>> the attributes would be "off label" - being adapted to the proprieta= ry >>>> protocol in a way that hopefully the two ends agree. >>>> >>>> I don't see how dcsa makes much sense for (2). If you don't know wha= t >>>> protocol will be used then how do you know what attributes to use? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>>> Flemming, Paul, >>>>> >>>>> The current a=3Ddcmap related text in >>>>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>>>> 'subprotocol' parameter must always be present - rather it is speci= fied >>>>> as an optional parameter. Thus, current sdpneg text would allow to >>>>> create an SDP offer for a data channel, which contains one a=3Ddcma= p >>>>> attribute and potentially multiple a=3Ddcsa attributes without the >>>>> subprotocol actually being given. Based on this discussion I am >>>>> wondering if the subprotocol parameter should actually be mandatory= =2E >>>>> >>>>> In the specific case of MSRP, the msrp-usage-data-channel draft say= s in >>>>> 5.1.1.1 that the dcmap attribute includes the label and subprotocol= >>>>> parameters. The current text could possible be made more explicit b= y >>>>> saying that the 'subprotocol=3D"MSRP"' parameter must always be pre= sent. >>>>> Have just submitted version 04 of the msrp-usage-data-channel draft= , >>>>> which proposes to add subprotocol identifier "MSRP" to the WebSocke= t >>>>> Subprotocol Name registry. This registry would then associate >>>>> subprotocol id "MSRP" with the msrp-usage-data-channel document. >>>>> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa >>>>> attribute are specified. And there the MSRP specific SDP attributes= , >>>>> which can be dcsa embedded, are described. >>>>> 'setup' is an attribute, whose semantic changes when being dcsa emb= edded >>>>> and associated with subprotocol MSRP, as compared to the meaning of= an >>>>> "a=3Dsetup" media level attribute of a TCP/MSRP m-line. Hence these= >>>>> semantical differences are explicitly addressed in the >>>>> msrp-usage-data-channel draft. >>>>> >>>>> Regarding sdpneg, I also think that the current text in sdpneg seem= s to >>>>> be sufficient regarding the usage of dcsa encapsulated SDP attribut= es as >>>>> being bound to the data channel's subprotocol. But as the semantic= of a >>>>> dcsa encapsulated attribute may be subprotocol specific (like 'setu= p'), >>>>> I'd now tend to consider the subprotocol parameter in the dcmap >>>>> attribute as being mandatory, as mentioned above. As already discus= sed, >>>>> the Websocket subprotocol registry would then refer to the document= , >>>>> which specifies the subprotocol specific usage of dcsa encapsulated= >>>>> parameters. >>>>> >>>>> Thanks, >>>>> Juergen >>>>> >>>>> >>>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>>> >>>>>> >>>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and spe= cific >>>>>>>>>> drafts are used to describe protocols that use the mechanism (= i.e. >>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>>> >>>>>>>>> It remains to be seen if that will be enough. E.g., there curre= ntly >>>>>>>>> aren't any iana considerations in >>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>>> >>>>>>>>> Suppose I encounter some sdp that uses msrp over a data channel= , but >>>>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>>>> reference to >>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that us= age? >>>>>>>>> >>>>>>>>> I would like to think that the iana registries will allow me to= >>>>>>>>> trace >>>>>>>>> back to the relevant specs. >>>>>>>>> >>>>>>>> No disagreement on that part, however having taken another look = at >>>>>>>> both >>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with yo= ur >>>>>>>> original request for all (existing and new) attributes to specif= y how >>>>>>>> they may or may not be used with the dcsa attribute defined by >>>>>>>> sdpneg. >>>>>>>> >>>>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>>>> individual >>>>>>>> documents (like msrp-usage), which calls your the parameters tha= t >>>>>>>> are at >>>>>>>> least needed to be supported for that usage. Taking MSRP as an >>>>>>>> example, >>>>>>>> why isn't that enough, and how do you see the resulting set of >>>>>>>> attributes that may or may not be used with MSRP differ between = use >>>>>>>> in a >>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular me= dia >>>>>>>> stream ? >>>>>>> >>>>>>> Based on this discussion, I conclude that it should be sufficient= for >>>>>>> this draft to say that before an attribute can be used with dcsa,= >>>>>>> such usage must be defined somewhere. This could be either: >>>>>>> - as part of the definition of the attribute, OR >>>>>>> - as part of the definition of the protocol referenced on the m-l= ine. >>>>>>> >>>>>> We are getting closer, but it's still not obvious to me that you >>>>>> cannot use an attribute with dcsa if it has not been explicitly >>>>>> defined for the attribute in question. Clearly, there are attribut= es >>>>>> that wouldn't make sense over data channels, just like there are >>>>>> attributes that don't make sense over particular media description= s. >>>>>> >>>>>> Again, I'd like to hear from more people on this, including the >>>>>> authors. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Also, it would be good to hear from more people on this, includi= ng >>>>>>>> the >>>>>>>> document authors. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> Regards, Christian >>>>>>>>>> >>>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>>> >>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>>>>>> need to >>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it= >>>>>>>>>>>> should be >>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at th= is >>>>>>>>>>>> point is >>>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>>> interactions as >>>>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>>>> (plus the >>>>>>>>>>>> offerer being responsible for generating a valid offer if he= >>>>>>>>>>>> wants to >>>>>>>>>>>> establish a data channel). >>>>>>>>>>> >>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>>>> pertains to >>>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>> . >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > > --------------ms060308090808070600020805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DF8wggTdMIIDxaADAgECAgoanQrOAAAAAAAGMA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoT DkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBSb290 IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcyOFowgYUxEzARBgoJkiaJk/IsZAEZ FgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ocmcli3LbVU6TRh +JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdfkyWAiGzVWeRI rYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38VbxMvQ+ygj Eyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+VdiUwDa ry1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsG AQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAes slr2YYl8XHzr4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5z dXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5h bGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4Bggr BgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQw OAYIKwYBBQUHMAKGLGh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQClGxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3 F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjbEhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx 4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6 rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwfRfPmwRetdnD6NC5x8aRkhr4ZNBjv YxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6/XpNOx2FyG18axeeASWtENgP vqEirM5MjwkCMIIHejCCBmKgAwIBAgIKYWH+JwAAAAFWdjANBgkqhkiG9w0BAQUFADCBhTET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVs IEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNTE4MTMwNzI0WhcNMTcwNTE3MTMwNzI0 WjBOMRAwDgYDVQQDEwdsaTYwNzYwMTowOAYJKoZIhvcNAQkBFitqdWVyZ2VuLnN0b2V0emVy LWJyYWRsZXJAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3SjiDDt1yolL0cBi5MS+Bea3hhVDSdcJ/xtfzEbTtkxo05xnMgeRTy/kNJZuR4oY j/2TE+raQenSEgROQtLgxKjxtLh9/fGEuLCyFclz9SIeIYIkZBB1NSwZKmGlJHRU5jjqSinT Hmux9chaP+TUoidoDYbfdz/uFGdPW7RP21Gxjzg9v/VC+tfc0u0idNF9Vwnkh3VgdisMf1Jf JZNINpw0ZapFKRhLEhgtXVS7tkdxxTL0uc9XtviOTSSfxgBt2MPsj0qfhsNFFO4zUO1pJiBz SBPnLt7af96oS2ZHI4Xz7zNHShDoSMMIr+7l9xgopb5qN/KMCMP9BSxxNEfphwIDAQABo4IE IDCCBBwwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmB C/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0P BAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkq hkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFEVmlcJSxtK5Cu7FZb5XUWWuKktKMB8GA1UdIwQYMBaA FNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFMoIIBSKCCAUSGgdls ZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPXVz bmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFh BggrBgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUy MEx1Y2VudCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNl bnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MDgGCCsGAQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20v UEtJL3N1YkNBLmNydDBEBggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxj YXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwNgYDVR0RBC8wLYEranVlcmdlbi5zdG9l dHplci1icmFkbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAMrtX ZAqm6NqOAYttJjvC6pL04tEKUusax1Dr6p6NfxVfUuW8ZoFXKoxHEDaYKQR9ldfnuILHN+x7 KdLeKg+NPUs7GFGwpBmJb7PRmxnIarFJbGHzpqZ9+Fhsde1uxi+y2VJcIOVaEh/JoRdHvSUQ nwT4+FcBmS6uRv68rnCkh+KeUm6A7+6dDo/9l/Zh2Hu1+HVWw5kEH/xmO170v9Xef7efxzxv BeQ644kvErDNG26LJDUtOqaKTdz9KKZXngw+2cAV/4Kc7C9xdT29Ugm8oOK/ecqBliMhBUen WphsEDjIbKJCd40RJLKb+v49EN/IJogNDd81vtehOxDw5Lus4zGCA+0wggPpAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZIm iZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0 ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+JwAAAAFWdjANBglghkgBZQMEAgEFAKCC AikwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMjE3MTMx MjQ5WjAvBgkqhkiG9w0BCQQxIgQgbw9qFlxW7E2aa1jF6BhXsCkxgbAOWETg8fSOr88Zrg8w bAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZIm iZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRl bCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+ JwAAAAFWdjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQK Ew5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3Vi IENBAgphYf4nAAAAAVZ2MA0GCSqGSIb3DQEBAQUABIIBAJcXJcsUmv2qYAxMSF9urZqHyKvU iVN0W9tn2/QJo4dfSMLjzyvc5fRdxhNi1dRTR2gK/KMAODgBb3EXnn+AW7I+FAFJ/WTncZO7 uXCgorI1kApXt+K/wjIg7VEqBjtM+jbd6pn6/uNjlbjvl7bc9B4waBJotQ3u5nO3Xvg273nU qxVF7jqMHN1No4jNNQrBU4vUS9L5QmyL09aB+q8lVIWCjTiSswcVw82U/BUoWa3EoaWzhReC TB5oDCT2af1hHwrML/YXMD/pNUm8d5rfAeaTzfLjEExyGmiJwBjbfEv9fu43eW95pQwLknHX qUnQBzhkel31pbxlyMTzYOyEeMcAAAAAAAA= --------------ms060308090808070600020805-- From nobody Wed Feb 17 07:27: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 673671A21B3 for ; Wed, 17 Feb 2016 07:27: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 aTWgE6kLqIpR for ; Wed, 17 Feb 2016 07:27:46 -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 C037C1A0015 for ; Wed, 17 Feb 2016 07:27:45 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-be-56c4916f54b6 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.8E.02707.F6194C65; Wed, 17 Feb 2016 16:27:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Wed, 17 Feb 2016 16:27:43 +0100 From: Christer Holmberg To: Suhas Nandakumar , Taylor Brandstetter Thread-Topic: [MMUSIC] In BUNDLE negotiation, when do "IDENTICAL" attributes need to be identical? Thread-Index: AQHRNsmvSA1qtayFrEaYqTnga3RsTp77m7WAgDUkaQA= Date: Wed, 17 Feb 2016 15:27:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E039B5@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E039B5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7oG7+xCNhBusnm1hcXvGQ1WLq8scs FjvndjA7MHvsnHWX3WPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBltP6ZwlSwr7Tiw4aiBsYV RV2MnBwSAiYSOxt+MUHYYhIX7q1n62Lk4hASOMwo0dLUzQThLGaUOPHgDXsXIwcHm4CFRPc/ bZAGEYFwiR89J9lAbGYBeYkLS9aADRIWSJbo6d3CBlGTIrHk/hImCNtKYt7uIywgNouAqkTf /+vMIDavgK9E/96nrBC7pjNKHHl/lxUkwSkQKPFywxqwIkag676fgljALCAucevJfKirBSSW 7DnPDGGLSrx8/I8VwlaSWHT7M1R9vsSedefYIJYJSpyc+YRlAqPoLCSjZiEpm4WkbBbQy8wC mhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg /B3c8ttgB+PL546HGAU4GJV4eDcUHg4TYk0sK67MPcQowcGsJMLb3XQkTIg3JbGyKrUoP76o NCe1+BCjNAeLkjjvauf1YUIC6YklqdmpqQWpRTBZJg5OqQbGtL3lJck6U3oDQhZrdV3+YB/O +/D8zYjzBW4xegc/RjgbeISltXLftVnCuLG5SVF2yrKtnY+apmZw8yTZz9HXuZHfxPTR/Wvf G9lqhfdHqr0/pXnxLlFb8++vivqpPyyz9RKOnHkScScxwuheRyTHovnTD0zOveitrvVthumq dmnDA2qvG0uVWIozEg21mIuKEwEJsRWzuwIAAA== 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: Wed, 17 Feb 2016 15:27:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E039B5ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgdGhpcyBuZWVkcyBtb3JlIGNsYXJpZmljYXRpb24uDQoNCkZvciBJREVO VElDQUwgYXR0cmlidXRlcywgdGhlcmUgaXMgdGV4dCBzYXlpbmc6DQoNCuKAnFRoZSBhdHRyaWJ1 dGUgTVVTVCBiZSByZXBlYXRlZCBhY3Jvc3MgYWxsICJtPSIgIGxpbmVzIG11bHRpcGxleGVk4oCd DQoNCkJ1dCwgd2hlbiBlLmcuIHRoZSBpbml0aWFsIFNEUCBvZmZlciBpcyBzZW50LCBubyDigJxt PeKAnSBsaW5lcyBhcmUgeWV0IG11bHRpcGxleGVkLiBUaGUgYW5zd2VyZXIgd2lsbCBkZWNpZGUg d2hpY2gg4oCcbT3igJ0gbGluZXMgYmVjb21lIG11bHRpcGxleGVkLg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBTdWhhcyBOYW5kYWt1bWFyDQpTZW50OiAxNCBKYW51YXJ5IDIwMTYg MjI6NDkNClRvOiBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPg0KQ2M6 IG1tdXNpYyBXRyA8bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEluIEJV TkRMRSBuZWdvdGlhdGlvbiwgd2hlbiBkbyAiSURFTlRJQ0FMIiBhdHRyaWJ1dGVzIG5lZWQgdG8g YmUgaWRlbnRpY2FsPw0KDQpIaSBUYXlsb3INCg0KICBBcyBhbiBvZmZlcmVyIHdoZW4gSSBhbSBv ZmZlcmluZyBCVU5ETEUsIGkgd2lsbCBhcHBseSBJREVOVElDQUwgd2hlbiBvZmZlcmluZyBmb3Ig dGhvc2UgYXR0cmlidXRlIHRoYXQgbmVlZHMgc3VjaCBhIGJlaGF2aW9yLg0KDQpTbyB5ZXMgd2Ug bmVlZCB0byBzcGVjaWZ5IHRoZSBJREVOVElDQUwgb24gZmlyc3QgcHJvcG9zYWwsIGFsc28gaW4g YW5zd2VyIGlmIHRoZSBBbnN3ZXJlciBzdXBwb3J0cyB0aGUgQlVORExFIGFuZCB0aGUgYXR0cmli dXRlIHNwZWNpZmllZCBhbmQgaW4gdGhlIHN1YnNlcXVlbnQgb2ZmZXIgYXMgd2VsbCBpZiB0aGUg QlVORExFIGdldHMgYWNjZXB0ZWQuDQoNCkFsc28gdG8gbm90ZSBhIHBhcnRpY3VsYXIgY2F0ZWdv cnkgZ2V0cyBhcHBsaWVzIGludGVybmFsbHkgKGluIHRoZSBjb2RlKSBvbmx5IGFmdGVyIHRoZSBz dWNjZXNzZnVsIE9mZmVyL0Fuc3dlciBuZWdvdGlhdGlvbi4NCg0KDQpIb3BlIHRoYXQgaGVscHMN Cg0KVGhhbmtzDQpTdWhhcw0KDQpPbiBNb24sIERlYyAxNCwgMjAxNSBhdCAzOjQ2IFBNLCBUYXls b3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPG1haWx0bzpkZWFkYmVlZkBnb29n bGUuY29tPj4gd3JvdGU6DQpJJ20gcmVmZXJyaW5nIHRvICJJREVOVElDQUwiIGFzIGRlZmluZWQg YnkgdGhpcyBkcmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzDQoNClRoZSBkZWZpbml0aW9uIGlzOg0KDQogICBB dHRyaWJ1dGVzIGFuZCB0aGVpciBhc3NvY2lhdGVkIHZhbHVlcyAoaWYgYW55KSB0aGF0IE1VU1Qg YmUNCiAgIGlkZW50aWNhbCBhY3Jvc3MgYWxsIHRoZSBtZWRpYSBkZXNjcmlwdGlvbnMgYmVpbmcg bXVsdGlwbGV4ZWQuDQoNCkhvd2V2ZXIsIGl0J3Mgbm90IGNsZWFyIHRvIG1lIGF0IHdoYXQgcG9p bnQgaW4gQlVORExFIG5lZ290aWF0aW9uIHRoaXMgcmVzdHJpY3Rpb24gc3RhcnRzIHRvIGFwcGx5 LiBJcyBpdDoNCg0KMS4gV2hlbiBhbiBvZmZlciBmaXJzdCBwcm9wb3NlcyBhIEJVTkRMRSBncm91 cA0KMi4gV2hlbiBhbiBhbnN3ZXIgYWNjZXB0cyBhIEJVTkRMRSBncm91cA0KMy4gV2hlbiBhIHN1 YnNlcXVlbnQgb2ZmZXIgaXMgbWFkZSwgd2l0aCBhbiBhbHJlYWR5LWVzdGFibGlzaGVkIEJVTkRM RSBncm91cA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37E039B5ESESSMB209erics_ 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 CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIHRoaXMgbmVlZHMg bW9yZSBjbGFyaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Rm9yIElERU5USUNBTCBhdHRyaWJ1dGVzLCB0aGVyZSBpcyB0ZXh0IHNheWluZzo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKAnFRoZSBhdHRyaWJ1dGUgTVVTVCBi ZSByZXBlYXRlZCBhY3Jvc3MgYWxsICZxdW90O209JnF1b3Q7ICZuYnNwO2xpbmVzIG11bHRpcGxl eGVk4oCdJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1dCwgd2hlbiBlLmcuIHRoZSBpbml0aWFsIFNEUCBv ZmZlciBpcyBzZW50LCBubyDigJxtPeKAnSBsaW5lcyBhcmUgeWV0IG11bHRpcGxleGVkLiBUaGUg YW5zd2VyZXIgd2lsbCBkZWNpZGUgd2hpY2gg4oCcbT3igJ0gbGluZXMgYmVjb21lIG11bHRpcGxl eGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMgW21haWx0bzpt bXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VoYXMgTmFuZGFr dW1hcjxicj4NCjxiPlNlbnQ6PC9iPiAxNCBKYW51YXJ5IDIwMTYgMjI6NDk8YnI+DQo8Yj5Ubzo8 L2I+IFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0O2RlYWRiZWVmQGdvb2dsZS5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBtbXVzaWMgV0cgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtNTVVTSUNdIEluIEJVTkRMRSBuZWdvdGlhdGlvbiwgd2hlbiBkbyAmcXVv dDtJREVOVElDQUwmcXVvdDsgYXR0cmlidXRlcyBuZWVkIHRvIGJlIGlkZW50aWNhbD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUYXlsb3I8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBBcyBhbiBvZmZlcmVyIHdoZW4g SSBhbSBvZmZlcmluZyBCVU5ETEUsIGkgd2lsbCBhcHBseSBJREVOVElDQUwgd2hlbiBvZmZlcmlu ZyBmb3IgdGhvc2UgYXR0cmlidXRlIHRoYXQgbmVlZHMgc3VjaCBhIGJlaGF2aW9yLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB5ZXMgd2Ug bmVlZCB0byBzcGVjaWZ5IHRoZSBJREVOVElDQUwgb24gZmlyc3QgcHJvcG9zYWwsIGFsc28gaW4g YW5zd2VyIGlmIHRoZSBBbnN3ZXJlciBzdXBwb3J0cyB0aGUgQlVORExFIGFuZCB0aGUgYXR0cmli dXRlIHNwZWNpZmllZCBhbmQgaW4gdGhlIHN1YnNlcXVlbnQgb2ZmZXIgYXMgd2VsbCBpZiB0aGUg QlVORExFIGdldHMgYWNjZXB0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFsc28gdG8gbm90ZSBhIHBhcnRpY3VsYXIgY2F0ZWdvcnkgZ2V0 cyBhcHBsaWVzIGludGVybmFsbHkgKGluIHRoZSBjb2RlKSBvbmx5IGFmdGVyIHRoZSBzdWNjZXNz ZnVsIE9mZmVyL0Fuc3dlciBuZWdvdGlhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3BlIHRoYXQgaGVscHM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWhhczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVjIDE0LCAy MDE1IGF0IDM6NDYgUE0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpk ZWFkYmVlZkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JJ20gcmVmZXJyaW5nIHRvICZxdW90O0lERU5USUNBTCZxdW90OyBhcyBk ZWZpbmVkIGJ5IHRoaXMgZHJhZnQ6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVz aWMtc2RwLW11eC1hdHRyaWJ1dGVzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIGRlZmluaXRpb24gaXM6Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 QXR0cmlidXRlcyBhbmQgdGhlaXIgYXNzb2NpYXRlZCB2YWx1ZXMgKGlmIGFueSkgdGhhdCBNVVNU IGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7aWRlbnRpY2FsIGFjcm9zcyBhbGwgdGhlIG1lZGlhIGRlc2NyaXB0aW9ucyBi ZWluZyBtdWx0aXBsZXhlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBpdCdzIG5vdCBjbGVhciB0byBtZSBhdCB3 aGF0IHBvaW50IGluIEJVTkRMRSBuZWdvdGlhdGlvbiB0aGlzIHJlc3RyaWN0aW9uIHN0YXJ0cyB0 byBhcHBseS4gSXMgaXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjEuIFdoZW4gYW4gb2ZmZXIgZmlyc3QgcHJvcG9zZXMgYSBCVU5ETEUgZ3Jv dXA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIu IFdoZW4gYW4gYW5zd2VyIGFjY2VwdHMgYSBCVU5ETEUgZ3JvdXA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIFdoZW4gYSBzdWJzZXF1ZW50IG9m ZmVyIGlzIG1hZGUsIHdpdGggYW4gYWxyZWFkeS1lc3RhYmxpc2hlZCBCVU5ETEUgZ3JvdXA8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37E039B5ESESSMB209erics_-- From nobody Thu Feb 18 04:19: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 9E0AF1B3BC0 for ; Thu, 18 Feb 2016 04:19:32 -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 rcR97-M7Clt3 for ; Thu, 18 Feb 2016 04:19:29 -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 437471B3AF0 for ; Thu, 18 Feb 2016 04:19:28 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-15-56c5b6ceb37d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 19.6F.02707.EC6B5C65; Thu, 18 Feb 2016 13:19:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Thu, 18 Feb 2016 13:19:25 +0100 From: Christer Holmberg To: Peter Thatcher , Suhas Nandakumar Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75ig Date: Thu, 18 Feb 2016 12:19:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DF9E40@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E061CDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7q+65bUfDDF62i1tMXf6YxeLa8tes FjvndjA7MHvsnHWX3WPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBlHD7CU7Cmg6miZ/cFtgbG LY1MXYycHBICJhLPDt5jhrDFJC7cW8/WxcjFISRwmFHiwL9HzBDOYkaJfbuOsnYxcnCwCVhI dP/TBjFFBIIlrs2xBTGZBdQlri4OAhkjLOAgsefJVnYQW0TAUWLOinNsEHaexN1dv8BsFgFV iQlvr4PV8Ar4ShyaPRtq7QFWibZHDSwgCU4BP4k5s5eANTAC3fb91Bqwm5kFxCVuPZkPdb+A xJI956HuF5V4+fgf2JUSAooSy/vlIMrzJaYfn8cCsUtQ4uTMJywTGEVnIZk0C0nZLCRls8A+ 05RYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC o+/glt8GOxhfPnc8xCjAwajEw1vw+0iYEGtiWXFl7iFGCQ5mJRHeDeuPhgnxpiRWVqUW5ccX leakFh9ilOZgURLnXe28PkxIID2xJDU7NbUgtQgmy8TBKdXAuGqC0I125pV7jYtrAt/7ywQb s+oenBB7OYqfecJnYeNpK7PO/UlKX+LXEbu+eFPFons7vSTVI+XZ1hV+DXocKMiz5kO9xioD nbNhfxu40m7lRL/6HD7fXf+BgLLu6ZcPOef4ZKuVrL/76r7k7Xn9H45+Px7lErSMcdUd2ZP/ n1xfKdarW+9+RomlOCPRUIu5qDgRAOR9jKa6AgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 18 Feb 2016 12:19:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E061CDESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KnNvdW5kcyBvZiBjcmlja2V0cyoNCg0KT2ssIHNvIGFzc3VtaW5nIHRoZSBzY29wZSBvZiB0aGlz IGNoYW5nZSB3b3VsZCBvbmx5IGJlIElDRSwgd2UgY291bGQgc2F5IHRoYXQgc2hhcmVkIElDRSBj YW5kaWRhdGVzIGRvbuKAmXQgaGF2ZSB0byBiZSBhc3NvY2lhdGVkIHdpdGggZWFjaCBtLSBsaW5l IHdpdGhpbiBhIEJVTkRMRSBncm91cCDigJMgaXTigJlzIGVub3VnaCBpZiB0aGV5IGFyZSBhc3Nv Y2lhdGVkIHdpdGggb25lIG0tIGxpbmUuDQoNClExOiBEb2VzIHRoaXMgYXBwbHkgb25seSB0byB0 aGUgU0RQIOKAmGNhbmRpZGF0ZeKAmSBhdHRyaWJ1dGUsIG9yIGFsc28gdG8gb3RoZXIgSUNFLXJl bGF0ZWQgU0RQIGF0dHJpYnV0ZXM/DQoNClEyOiBJcyBpdCBhIFJFQ09NTUVOREVEL1NIT1VMRC9N QVkvTVVTVC9NVVNUIE5PVD8NCg0KTm93LCBpZiBJIGRvbuKAmXQgaGVhciBhbnkgZmVlZGJhY2sg b24gdGhpcywgSSBhbSBOT1QgZ29pbmcgdG8gZG8gdGhlIGNoYW5nZS4gVGhvc2Ugd2hvIGFza2Vk IGZvciB0aGlzIGNoYW5nZSAob3Igb3RoZXJ3aXNlIGhhdmUgYW4gb3BpbmlvbiBvbiBpdCksIHBs ZWFzZSBzcGVhayB1cCBub3cuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogbW11 c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3Rl ciBIb2xtYmVyZw0KU2VudDogMTYuIGhlbG1pa3V1dGEgMjAxNiAxNzoxNQ0KVG86IFBldGVyIFRo YXRjaGVyDQpDYzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gUXVlc3Rp b25zIGFib3V0IElDRSBjYW5kaWRhdGVzIHdpdGggQlVORExFDQoNCkhpLA0KDQpXZSBzdGlsbCBu ZWVkIHRvIGNvbmNsdWRlIHRoaXMgaXNzdWUgYmVmb3JlIHdlIGNhbiBzaGlwIEJVTkRMRSwgc28g SeKAmWQgbGlrZSB0byBoZWFyIHNvbWUgaW5wdXQgZnJvbSBwZW9wbGUuIEkgZG8gaW50ZW5kIHRv IHJlcXVlc3QgYWdlbmRhIHRpbWUgdG8gZGlzY3VzcyBpdCBpbiBCdWVub3MgQWlyZXMsIGJ1dCBp ZiB3ZSBjYW4gZmluZCBhIHNvbHV0aW9uIGJlZm9yZSB0aGF0IHRoZXJlIHdpbGwgYmUgbW9yZSB0 aW1lIGZvciBjb29raWVz4oCmDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFBldGVy IFRoYXRjaGVyIFttYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb21dDQpTZW50OiAxNy4gbWFycmFz a3V1dGEgMjAxNSAxOjA2DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBtbXVzaWNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBRdWVzdGlv bnMgYWJvdXQgSUNFIGNhbmRpZGF0ZXMgd2l0aCBCVU5ETEUNCg0KDQoNCk9uIE1vbiwgTm92IDE2 LCAyMDE1IGF0IDI6NTggUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KSGksDQoNCj4+IEkgdGhpbmtpbmcgbWFuZGF0aW5nIHRoZSBjYW5kaWRhdGVzIGJlIGR1cGxp Y2F0ZWQgaW4gdGhlIGFuc3dlciBoYXMgdGhyZWUgaXNzdWVzOg0KPj4NCj4+IDEuICBJdCBjb25m bGljdHMgd2l0aCB0cmlja2xlIElDRS4NCj4+IDIuICBJdCdzIHNsaWdodGx5IG1vcmUgY29tcGxl eCB0byBpbXBsZW1lbnQgKHdlIGhhdmUgdG8gZ28gYWRkIGV4dHJhIGxvZ2ljIHRvIGdvIGR1cGxp Y2F0ZSB0aGVzZSB0aGluZ3MpDQo+PiAzLiAgSXQncyBhIGNvbXBsZXRlIHdhc3RlIG9mIHRpbWUv c3BhY2UvZWZmb3J0LiAgVGhlIHJlY2lwaWVudCBvZiB0aGVzZSBkdXBsaWNhdGUgY2FuZGlkYXRl cyBpcyBuZXZlciBnb2luZyB0byBhbnl0aGluZyB3aXRoIHRoZW0uDQo+DQo+IFRob3NlIGFyZSBh bGwgZmFpciBwb2ludHMuIEkgd2lzaCB3ZSdkIGhhZCBtb3JlIGltcGxlbWVudGF0aW9uIGlucHV0 IHdoZW4gd2Ugd3JpdGUgb3VyIHNwZWNzLg0KPg0KPiBUaGF0J3Mgd2hhdCBJJ20gcHJvdmlkaW5n IG5vdyA6KS4gIFdlIGNhbiBzdGlsbCBjaGFuZ2UgdGhlIHNwZWMsIGNhbid0IHdlPw0K4oCLDQpT dXJlLg0KDQpIb3dldmVyLCBhcyB3ZSBhcmUgdGFsa2luZyBhYm91dCBhIGRlc2lnbiB3aXNlIGJp ZyAoaW4gbXkgb3BpbmlvbikgY2hhbmdlLCBhdCBhIGxhdGUgc3RhZ2UsIEknZCBsaWtlIHRvIGhl YXIgd2hhdCBvdGhlciBwZW9wbGUgdGhpbmsuDQoNCuKAi1RoYXQgc291bmRzIGZhaXIuICBJJ2Qg bGlrZSB0byBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rIGFib3V0IHRoaXMu4oCLDQrigIsNCg0KDQoN Cj4+PkFsc28ga2VlcCBpbiBtaW5kIHRoYXQsIHdoZW4gYSBzdWJzZXF1ZW50IG9mZmVyIGlzIHNl bnQsIHRoZSBidW5kbGUtb25seSBhdHRyaWJ1dGUgaXMgbm8gbG9uZ2VyIHVzZWQuDQo+Pg0K4oCL Pj5DYW4geW91IHBvaW50IG91dCB3aGVyZSBpbiB0aGUgZHJhZnQgaXQgc2F5cyB0aGF0PyAgSSB0 cmllZCBmaW5kaW5nIGl0IGFuZCBJIGhhZCBhIGRpZmZpY3VsdCB0aW1lIHNlZWluZyB3aGVyZSBi dW5kbGUtb25seSB3YXNuJ3QgYWxsb3dlZCBpbiBhIHJlb2ZmZXIu4oCLDQrigIs+Pg0KPj4gU2Vj dGlvbiA4LjUuMSBzYXlzOg0KPj4NCj4+ICAgICAgICAiV2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRl cyBhIHN1YnNlcXVlbnQgb2ZmZXIsIGl0IE1VU1QgYXNzaWduIHRoZQ0KPj4gICAgICAgcHJldmlv dXNseSBzZWxlY3RlZCBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIFtTZWN0aW9uIDguMy4yXSwgdG8g ZWFjaA0KPj4gICAgICAgYnVuZGxlZCAibT0iIGxpbmUgKGluY2x1ZGluZyBhbnkgYnVuZGxlLW9u bHkgIm09IiBsaW5lKSwgZXhjZXB0IGlmOiINCj4+DQo+PiBBbmQsIGFzIHRoZSB1c2FnZSBvZiB0 aGUgYXR0cmlidXRlIGlzIG9ubHkgZGVmaW5lZCB3aGVuIHRoZSBwb3J0IHZhbHVlIGlzIHplcm8s IGl0IHdvdWxkIG5vdCB3b3JrIHdoZW4gdGhlIEJVTkRMRSBhZGRyZXNzIChyZWFkOiBub24temVy byBwb3J0KSBtdXN0IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgbS0gbGluZS4NCj4+DQo+PiBTZWN0 aW9uIDYgc2F5czoNCj4+DQo+PiAgICJUaGUgdXNhZ2Ugb2YgdGhlICdidW5kbGUtb25seScgYXR0 cmlidXRlIGlzIG9ubHkgZGVmaW5lZCBmb3IgYQ0KPj4gICBidW5kbGVkICJtPSIgbGluZSB3aXRo IGEgemVybyBwb3J0IHZhbHVlLCB3aXRoaW4gYW4gb2ZmZXIuICBPdGhlcg0KPj4gICB1c2FnZSBp cyB1bnNwZWNpZmllZC4iDQo+DQrigIs+IFRoYW5rcy4gIFRoYXQgdGV4dCB3b3VsZCBiZSBtb3Jl IGNsZWFyIGFzICJ3aXRoIGFuIGluaXRpYWwgb2ZmZXIiIGluc3RlYWQgb2YgIndoaXRoaW4gYW4g b2ZmZXIiLCBzaW5jZSB0aGF0J3Mgd2hhdCBpdCByZWFsbHkgbWVhbnMgaW4gY29uanVjdGlvbiB3 aXRoIDguNS4xLg0KDQpPay4NCg0KPiBIb3dldmVyLCB0aGF0J3MgcHJlY2lzZWx5IHRoZSB0ZXh0 IHRoYXQgSSB0aGluayB3ZSBjb3VsZCBjaGFuZ2UuICBJIHRoaW5rIHdlIGNvdWxkIGNoYW5nZSB0 aGUgYnVuZGxlLW9ubHkgYXR0cmlidXRlIHRvDQo+IGJlIGFsbG93ZWQgaW4gYW5zd2VycyBhbmQg aW4gc3Vic2VxdWVudCBvZmZlcnMuICBUaGVuIGNsaWVudHMgY291bGQgdXNlIHRoZSBhdHRyaWJ1 dGUgYXMgYSB3YXkgb2YgYXZvaWRpbmcgZHVwbGljYXRpb24NCj4gb2YgY2FuZGlkYXRlcyBhbmQg dGhlIGNvbXBsaWNhdGlvbnMgd2l0aCB0cmlja2xlIElDRS7igIsNCg0KQXNzdW1pbmcgd2Ugd291 bGQgcmVtb3ZlIHRoZSBkdXBsaWNhdGlvbiBvZiBjYW5kaWRhdGVzLCBJIGRvbid0IHRoaW5rIHRo YXQgd291bGQgcmVxdWlyZSB1cyB0byBjaGFuZ2UgYSBzZW1hbnRpY3Mgb2YgdGhlIGF0dHJpYnV0 ZS4gV2UgY291bGQgc2ltcGx5IHNheSB0aGF0IHRoZSBjYW5kaWRhdGVzIGRvbid0IG5lZWQgdG8g YmUgZHVwbGljYXRlZCBpbiBidW5kbGVkIG0tIGxpbmVzLCBubyBtYXR0ZXIgaWYgdGhvc2UgbS0g bGluZXMgYXJlIGJ1bmRsZS1vbmx5IG9yIG5vdC4NCg0KVGhhdCB3b3VsZCB3b3JrIGFzIHdlbGwu DQrigIsNCg0KDQo+Pj4+IFdvdWxkIHlvdSB0aGVuIGFsc28gaW4gdGhlIHN1YnNlcXVlbnQgb2Zm ZXIgb25seSBhc3NpZ24gcG9zc2libGUgY2FuZGlkYXRlcyB0byBvbmx5IG9uZSBtLSBsaW5lIHdp dGhpbiB0aGUgYnVuZGxlIGdyb3VwPw0KPj4+DQrigIs+Pj4gVGhhdCBzb3VuZHMgbG9naWNhbCB0 byBtZS4gIFRoZXkgYXJlbid0IGluY2x1ZGVkIGluIHRoZSBmaXJzdCBvZmZlci4gIFdoeSBhZGQg dGhlbSB0byBzdWJzZXF1ZW50IG9mZmVycz8gIEl0J3MgaW5jb25zaXN0ZW50LCBhbmQgYSB3YXN0 ZS4NCj4+DQo+PiBUaGVuIHNvbWVvbmUgY291bGQgYXNrOiB3aGF0IGFib3V0IG90aGVyIChub24t Y2FuZGlkYXRlKSBhdHRyaWJ1dGVzIHRoYXQgbXVzdCBoYXZlIGlkZW50aWNhbCB2YWx1ZXMgZm9y IGVhY2ggYnVuZGxlZCBtLSBsaW5lPyBTaG91bGQgdGhvc2UgYWxzbyBiZSBhc3NpZ25lZCB0byBv bmx5IG9uZSBvZiB0aGUgbS0gbGluZXM/DQo+DQrigIs+IElmIGl0J3Mgc29tZXRoaW5nIHVuaXF1 ZSB0byB0aGUgYnVuZGxlIGdyb3VwLCBhbmQgbm90IHRoZSBtLWxpbmUsIHRoYXQgc2VlbXMgcmVh c29uYWJsZSB0byBtZS4gIOKAiw0K4oCLPg0K4oCLPiBCdXQgY2FuZGlkYXRlcyBhcmUgbW9yZSBw YWluZnVsIHRoYW4gdGhvc2Ugd291bGQgYmUgYmVjYXVzZSBvZiB0aGUgaW50ZXJhY3Rpb25zIHdp dGggdHJpY2tsZSBJQ0UuICBJZiBpdCB3ZXJlbid0IGZvciB0cmlja2xlIElDRSB0aGlzIHdvdWxk bid0IGJlIGFzIGJpZyBvZiBhIGRlYWwu4oCLDQoNCkNvcnJlY3QuIFdlIGp1c3QgbmVlZCB0byBt YWtlIGl0IHZlcnkgY2xlYXIgd2hldGhlciBpdCBhcHBsaWVzIG9ubHkgdG8gY2FuZGlkYXRlIGF0 dHJpYnV0ZXMsIG9yIHRvIGF0dHJpYnV0ZXMgd2l0aCBpZGVudGljYWwgdmFsdWVzIGluIGdlbmVy YWwuDQoNCj4+Pj4+Pj4+IDIuICBJZiB0aGUgYW5zd2VyZXIgZG9lcyBub3QgaW5jbHVkZSBhbnkg Y2FuZGlkYXRlcyBpbiB0aGUgYW5zd2VyIGFuZCBpbnN0ZWFkIHRyaWNrbGVzIHRoZW0gbGF0ZXIs IHNob3VsZCBpdCB0cmlja2xlIHRoZW0NCj4+Pj4+Pj4+IE4gdGltZXMgKG9uY2UgZm9yIGVhY2gg bS1saW5lIGluIHRoZSBCVU5ETEUgZ3JvdXApIG9yID4xIHRpbWU/ICAxIHRpbWUgc2VlbXMgbXVj aCBtb3JlIHJlYXNvbmFibGUgdGhhbiBOIHRpbWVzLCBidXQNCj4+Pj4+Pj4+IGlmIHdlIGR1cGxp Y2F0ZSBjYW5kaWRhdGVzIGluIHRoZSBhbnN3ZXIsIGJ1dCBub3QgZHVwbGljYXRlIHRoZW0gd2hp bGUgdHJpY2tsaW5nLCB0aGF0J3MgYSBiaXQgaW5jb25zaXN0ZW50LiAgWWV0ID5hbm90aGVyIHJl YXNvbiB0byBub3QgZHVwbGljYXRlIGluIHRoZSBhbnN3ZXIgOikuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ IEFzc3VtaW5nIHlvdSB1c2UgU0RQIHRvIHNpZ25hbCB0aGUgdHJpY2tsZWQgY2FuZGlkYXRlcywg aXTigJlzIHRydWUgdGhhdCB5b3Ugd291bGQgZHVwbGljYXRlIHRoZW0sDQo+Pj4+Pj4+DQo+Pj4+ Pj7igItXaGF0J3MgdGhlIHJhdGlvbmFsZSBmb3IgdGhhdD8gIFRoZXNlIGR1cGxpY2F0ZXMgcHJv dmlkZSBubyB2YWx1ZSwgYW5kIGluIHRoZSBjYXNlIG9mIG1hbnkgbS1saW5lcyAoc3VjaCBhcyBh IGNvbmZlcmVuY2luZw0KPj4+Pj4+c3lzdGVtIHdpdGggbWFueSBwYXJ0aWNpcGFudHMpLCB3ZSBj b3VsZCBiZSB0YWxraW5nIGFib3V0IDMweCB0aGUgbnVtYmVyIG9mIGNhbmRpZGF0ZXMgYmVpbmcg c2lnbmFsZWQuDQo+Pj4+DQo+Pj4+IEkgaGVhciB3aGF0IHlvdSBhcmUgc2F5aW5nLg0KPj4+Pg0K Pj4+PiBCdXQsIGlmIHdlIHdvdWxkIGRvIGEgY2hhbmdlLCB3ZSBhbHNvIG5lZWQgdG8gbG9vayBh dCB0aGUgZnVsbCBwaWN0dXJlLCBhbmQgY29uc2lkZXIgc3Vic2VxdWVudCBvZmZlcnMgZXRjLg0K Pj4+DQrigIs+Pj4gSSB0aGluayBhIHNpbXBsZSBydWxlIHdvdWxkIGJlICJpZiB5b3Uga25vdyBp dCdzIGdvaW5nIHRvIGJlIGJ1bmRsZWQgb250byBhbm90aGVyIG0tbGluZSwgZG9uJ3QgaW5jbHVk ZQ0KPj4+IGNhbmRpZGF0ZXMiLiAgVGhhdCB3b3VsZCBnbyBmb3IgYnVuZGxlLW9ubHkgbS1saW5l cyBpbiBhbiBvZmZlciwgYnVuZGxlZCBtLWxpbmVzIGluIGFuIGFuc3dlciwgYW5kIGJ1bmRsZWQg bS1saW5lcyBpbiBhIHJlLW9mZmVyLuKAiw0K4oCLPj4+DQo+PiBCdW5kbGVkIG0tIGxpbmVzIGlu IGEgcmUtb2ZmZXIgY2FuIHN0aWxsIGJlIHJlamVjdGVkIGJ5IHRoZSBhbnN3ZXJlci4NCj4NCuKA iz4gVGhhdCBzb3VuZHMgdGhlIHNhbWUgYXMgYW4gaW5pdGlhbCBvZmZlci4gIEhvdyBkb2VzIGl0 IGltcGx5IHRoYXQgYSByZS1vZmZlciBtdXN0IGR1cGxpY2F0ZQ0KPiBjYW5kaWRhdGVzIGFjcm9z cyBtLWxpbmVzLCBldmVuIHdoZW4gYW4gaW5pdGlhbCBvZmZlciBkb2Vzbid0IG5lZWQgdG8/4oCL DQrigIsNCkluIHRoZSBpbml0aWFsIG9mZmVyIGVhY2ggbS0gbGluZSBjb250YWlucyBjYW5kaWRh dGVzICh1bmlxdWUpLiBJZiBhbiBtLSBsaW5lIGluIHRoZSBvZmZlciBpcyByZWplY3RlZCwgdGhl IGFuc3dlcmVyIG11c3Qgc2VsZWN0IHRoZSBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIChhbmQgdGhl IGFzc29jaWF0ZWQgY2FuZGlkaWF0ZXMpIGZyb20gYW5vdGhlciBtLSBsaW5lLg0KDQpOb3csIGlu IGEgcmUtb2ZmZXIsIGlmIHRoZSBtLSBsaW5lIGNvbnRhaW5pbmcgdGhlIGNhbmRpZGF0ZXMgaXMg cmVqZWN0ZWQsIHRoZSBhbnN3ZXJlciBuZWVkcyB0byBpbmNsdWRlIGl0cyBjYW5kaWRhdGVzIGlu IGFub3RoZXIgbS0gbGluZSBpbiB0aGUgYW5zd2VyLiBUaGF0J3MgZG9hYmxlLCBidXQgaXQgd291 bGQgbmVlZCB0byBiZSBjbGVhcmx5IGRvY3VtZW50ZWQuIEluIG90aGVyIHdvcmRzOiBpdCBuZWVk cyB0byBiZSBjbGVhciB0aGF0IHRoZSBjYW5kaWRhdGVzIGNhbiBvY2N1ciBpbiBBTlkgb2YgdGhl IGJ1bmRsZWQgbS0gbGluZXMsIGFuZCB0aGF0IG0tIGxpbmUgbWF5IGNoYW5nZSBiZXR3ZWVuIG9m ZmVycyBhbmQgYW5zd2Vycy4NCg0K4oCLU28gYSBydWxlIG9mICJ0aGUgY2FuZGlkYXRlcyBjYW4g YmUgaW4gYW55IG9uZSBvZiB0aGUgbS1saW5lcywgYW5kIGl0IGRvZXNuJ3QgbWF0dGVyIHdoaWNo LCBhbmQgaXQgY2FuIGNoYW5nZSBhbnkgdGltZSIuICBUaGF0IHNlZW1zIHJlYXNvbmFibGUgdG8g bWUuICBJdCBsZWF2ZSB0aGUgbW9zdCBmbGV4aWJpbGl0eSB0byB0aGUgb25lIHdyaXRpbmcgdGhl IFNEUCwgYW5kIGl0J3MgdmVyeSBlYXN5IHRvIGltcGxlbWVudCBmb3IgdGhlIG9uZSByZWFkaW5n IHRoZSBTRFAu4oCLDQoNCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37E061CDESESSMB209erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNt IDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPio8Yj5zb3VuZHMgb2YgY3JpY2tl dHM8L2I+KjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9rLCBzbyBhc3N1bWluZyB0aGUgc2NvcGUg b2YgdGhpcyBjaGFuZ2Ugd291bGQgb25seSBiZSBJQ0UsIHdlIGNvdWxkIHNheSB0aGF0IHNoYXJl ZCBJQ0UgY2FuZGlkYXRlcyBkb27igJl0IGhhdmUgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIGVhY2gg bS0gbGluZQ0KIHdpdGhpbiBhIEJVTkRMRSBncm91cCDigJMgaXTigJlzIGVub3VnaCBpZiB0aGV5 IGFyZSBhc3NvY2lhdGVkIHdpdGggb25lIG0tIGxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlExOiBEb2VzIHRoaXMgYXBwbHkgb25seSB0byB0aGUgU0RQIOKAmGNhbmRp ZGF0ZeKAmSBhdHRyaWJ1dGUsIG9yIGFsc28gdG8gb3RoZXIgSUNFLXJlbGF0ZWQgU0RQIGF0dHJp YnV0ZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlEyOiBJcyBpdCBhIFJF Q09NTUVOREVEL1NIT1VMRC9NQVkvTVVTVC9NVVNUIE5PVD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Tm93LCBpZiBJIGRvbuKAmXQgaGVhciBhbnkgZmVlZGJhY2sgb24gdGhp cywgSSBhbSBOT1QgZ29pbmcgdG8gZG8gdGhlIGNoYW5nZS4gVGhvc2Ugd2hvIGFza2VkIGZvciB0 aGlzIGNoYW5nZSAob3Igb3RoZXJ3aXNlIGhhdmUgYW4gb3BpbmlvbiBvbiBpdCksDQogcGxlYXNl IHNwZWFrIHVwIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYyBbbWFpbHRv Om1tdXNpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBI b2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiAxNi4gaGVsbWlrdXV0YSAyMDE2IDE3OjE1PGJyPg0K PGI+VG86PC9iPiBQZXRlciBUaGF0Y2hlcjxicj4NCjxiPkNjOjwvYj4gbW11c2ljQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQgSUNFIGNh bmRpZGF0ZXMgd2l0aCBCVU5ETEU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2Ugc3RpbGwgbmVlZCB0byBjb25jbHVkZSB0aGlzIGlz c3VlIGJlZm9yZSB3ZSBjYW4gc2hpcCBCVU5ETEUsIHNvIEnigJlkIGxpa2UgdG8gaGVhciBzb21l IGlucHV0IGZyb20gcGVvcGxlLiBJIGRvIGludGVuZCB0byByZXF1ZXN0IGFnZW5kYSB0aW1lDQog dG8gZGlzY3VzcyBpdCBpbiBCdWVub3MgQWlyZXMsIGJ1dCBpZiB3ZSBjYW4gZmluZCBhIHNvbHV0 aW9uIGJlZm9yZSB0aGF0IHRoZXJlIHdpbGwgYmUgbW9yZSB0aW1lIGZvciBjb29raWVz4oCmPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQ ZXRlciBUaGF0Y2hlciBbPGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIj5tYWls dG86cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE3LiBtYXJy YXNrdXV0YSAyMDE1IDE6MDY8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQg SUNFIGNhbmRpZGF0ZXMgd2l0aCBCVU5ETEU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDE2LCAyMDE1IGF0IDI6NTgg UE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSw8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5raW5nIG1hbmRhdGluZyB0aGUgY2FuZGlk YXRlcyBiZSBkdXBsaWNhdGVkIGluIHRoZSBhbnN3ZXIgaGFzIHRocmVlIGlzc3Vlczo8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDEuJm5ic3A7IEl0IGNvbmZsaWN0cyB3aXRoIHRyaWNrbGUg SUNFLjxicj4NCiZndDsmZ3Q7IDIuJm5ic3A7IEl0J3Mgc2xpZ2h0bHkgbW9yZSBjb21wbGV4IHRv IGltcGxlbWVudCAod2UgaGF2ZSB0byBnbyBhZGQgZXh0cmEgbG9naWMgdG8gZ28gZHVwbGljYXRl IHRoZXNlIHRoaW5ncyk8YnI+DQomZ3Q7Jmd0OyAzLiZuYnNwOyBJdCdzIGEgY29tcGxldGUgd2Fz dGUgb2YgdGltZS9zcGFjZS9lZmZvcnQuJm5ic3A7IFRoZSByZWNpcGllbnQgb2YgdGhlc2UgZHVw bGljYXRlIGNhbmRpZGF0ZXMgaXMgbmV2ZXIgZ29pbmcgdG8gYW55dGhpbmcgd2l0aCB0aGVtLiAm bmJzcDs8YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0OyBUaG9zZSBhcmUgYWxsIGZhaXIgcG9pbnRz LiBJIHdpc2ggd2UnZCBoYWQgbW9yZSBpbXBsZW1lbnRhdGlvbiBpbnB1dCB3aGVuIHdlIHdyaXRl IG91ciBzcGVjcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGF0J3Mgd2hhdCBJJ20gcHJvdmlkaW5n IG5vdyA6KS4mbmJzcDsgV2UgY2FuIHN0aWxsIGNoYW5nZSB0aGUgc3BlYywgY2FuJ3Qgd2U/PGJy Pg0K4oCLPGJyPg0KU3VyZS48YnI+DQo8YnI+DQpIb3dldmVyLCBhcyB3ZSBhcmUgdGFsa2luZyBh Ym91dCBhIGRlc2lnbiB3aXNlIGJpZyAoaW4gbXkgb3BpbmlvbikgY2hhbmdlLCBhdCBhIGxhdGUg c3RhZ2UsIEknZCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlciBwZW9wbGUgdGhpbmsuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKA i1RoYXQgc291bmRzIGZhaXIuJm5ic3A7IEknZCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlcnMgdGhp bmsgYWJvdXQgdGhpcy7igIs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0O0Fsc28ga2VlcCBpbiBt aW5kIHRoYXQsIHdoZW4gYSBzdWJzZXF1ZW50IG9mZmVyIGlzIHNlbnQsIHRoZSBidW5kbGUtb25s eSBhdHRyaWJ1dGUgaXMgbm8gbG9uZ2VyIHVzZWQuPGJyPg0KJmd0OyZndDs8YnI+DQrigIsmZ3Q7 Jmd0O0NhbiB5b3UgcG9pbnQgb3V0IHdoZXJlIGluIHRoZSBkcmFmdCBpdCBzYXlzIHRoYXQ/Jm5i c3A7IEkgdHJpZWQgZmluZGluZyBpdCBhbmQgSSBoYWQgYSBkaWZmaWN1bHQgdGltZSBzZWVpbmcg d2hlcmUgYnVuZGxlLW9ubHkgd2Fzbid0IGFsbG93ZWQgaW4gYSByZW9mZmVyLuKAizxicj4NCuKA iyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU2VjdGlvbiA4LjUuMSBzYXlzOjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7V2hlbiBhbiBv ZmZlcmVyIGdlbmVyYXRlcyBhIHN1YnNlcXVlbnQgb2ZmZXIsIGl0IE1VU1QgYXNzaWduIHRoZTxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByZXZpb3VzbHkgc2VsZWN0ZWQgb2Zm ZXJlciBCVU5ETEUgYWRkcmVzcyBbU2VjdGlvbiA4LjMuMl0sIHRvIGVhY2g8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBidW5kbGVkICZxdW90O209JnF1b3Q7IGxpbmUgKGluY2x1 ZGluZyBhbnkgYnVuZGxlLW9ubHkgJnF1b3Q7bT0mcXVvdDsgbGluZSksIGV4Y2VwdCBpZjomcXVv dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFuZCwgYXMgdGhlIHVzYWdlIG9mIHRoZSBh dHRyaWJ1dGUgaXMgb25seSBkZWZpbmVkIHdoZW4gdGhlIHBvcnQgdmFsdWUgaXMgemVybywgaXQg d291bGQgbm90IHdvcmsgd2hlbiB0aGUgQlVORExFIGFkZHJlc3MgKHJlYWQ6IG5vbi16ZXJvIHBv cnQpIG11c3QgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5lLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgU2VjdGlvbiA2IHNheXM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsmcXVvdDtUaGUgdXNhZ2Ugb2YgdGhlICdidW5kbGUtb25seScgYXR0cmlidXRl IGlzIG9ubHkgZGVmaW5lZCBmb3IgYTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO2J1bmRsZWQg JnF1b3Q7bT0mcXVvdDsgbGluZSB3aXRoIGEgemVybyBwb3J0IHZhbHVlLCB3aXRoaW4gYW4gb2Zm ZXIuJm5ic3A7IE90aGVyPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7dXNhZ2UgaXMgdW5zcGVj aWZpZWQuJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCuKAiyZndDsgVGhhbmtzLiZuYnNwOyBUaGF0IHRl eHQgd291bGQgYmUgbW9yZSBjbGVhciBhcyAmcXVvdDt3aXRoIGFuIGluaXRpYWwgb2ZmZXImcXVv dDsgaW5zdGVhZCBvZiAmcXVvdDt3aGl0aGluIGFuIG9mZmVyJnF1b3Q7LCBzaW5jZSB0aGF0J3Mg d2hhdCBpdCByZWFsbHkgbWVhbnMgaW4gY29uanVjdGlvbiB3aXRoIDguNS4xLjxicj4NCjxicj4N Ck9rLjxicj4NCjxicj4NCiZndDsgSG93ZXZlciwgdGhhdCdzIHByZWNpc2VseSB0aGUgdGV4dCB0 aGF0IEkgdGhpbmsgd2UgY291bGQgY2hhbmdlLiZuYnNwOyBJIHRoaW5rIHdlIGNvdWxkIGNoYW5n ZSB0aGUgYnVuZGxlLW9ubHkgYXR0cmlidXRlIHRvPGJyPg0KJmd0OyBiZSBhbGxvd2VkIGluIGFu c3dlcnMgYW5kIGluIHN1YnNlcXVlbnQgb2ZmZXJzLiZuYnNwOyBUaGVuIGNsaWVudHMgY291bGQg dXNlIHRoZSBhdHRyaWJ1dGUgYXMgYSB3YXkgb2YgYXZvaWRpbmcgZHVwbGljYXRpb248YnI+DQom Z3Q7IG9mIGNhbmRpZGF0ZXMgYW5kIHRoZSBjb21wbGljYXRpb25zIHdpdGggdHJpY2tsZSBJQ0Uu 4oCLPGJyPg0KPGJyPg0KQXNzdW1pbmcgd2Ugd291bGQgcmVtb3ZlIHRoZSBkdXBsaWNhdGlvbiBv ZiBjYW5kaWRhdGVzLCBJIGRvbid0IHRoaW5rIHRoYXQgd291bGQgcmVxdWlyZSB1cyB0byBjaGFu Z2UgYSBzZW1hbnRpY3Mgb2YgdGhlIGF0dHJpYnV0ZS4gV2UgY291bGQgc2ltcGx5IHNheSB0aGF0 IHRoZSBjYW5kaWRhdGVzIGRvbid0IG5lZWQgdG8gYmUgZHVwbGljYXRlZCBpbiBidW5kbGVkIG0t IGxpbmVzLCBubyBtYXR0ZXIgaWYgdGhvc2UgbS0gbGluZXMgYXJlIGJ1bmRsZS1vbmx5DQogb3Ig bm90LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlRoYXQgd291bGQgd29yayBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgV291bGQgeW91IHRoZW4gYWxzbyBpbiB0aGUgc3Vic2VxdWVudCBvZmZlciBvbmx5IGFz c2lnbiBwb3NzaWJsZSBjYW5kaWRhdGVzIHRvIG9ubHkgb25lIG0tIGxpbmUgd2l0aGluIHRoZSBi dW5kbGUgZ3JvdXA/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K4oCLJmd0OyZndDsmZ3Q7IFRoYXQg c291bmRzIGxvZ2ljYWwgdG8gbWUuJm5ic3A7IFRoZXkgYXJlbid0IGluY2x1ZGVkIGluIHRoZSBm aXJzdCBvZmZlci4mbmJzcDsgV2h5IGFkZCB0aGVtIHRvIHN1YnNlcXVlbnQgb2ZmZXJzPyZuYnNw OyBJdCdzIGluY29uc2lzdGVudCwgYW5kIGEgd2FzdGUuJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBUaGVuIHNvbWVvbmUgY291bGQgYXNrOiB3aGF0IGFib3V0IG90aGVyIChub24t Y2FuZGlkYXRlKSBhdHRyaWJ1dGVzIHRoYXQgbXVzdCBoYXZlIGlkZW50aWNhbCB2YWx1ZXMgZm9y IGVhY2ggYnVuZGxlZCBtLSBsaW5lPyBTaG91bGQgdGhvc2UgYWxzbyBiZSBhc3NpZ25lZCB0byBv bmx5IG9uZSBvZiB0aGUgbS0gbGluZXM/PGJyPg0KJmd0Ozxicj4NCuKAiyZndDsgSWYgaXQncyBz b21ldGhpbmcgdW5pcXVlIHRvIHRoZSBidW5kbGUgZ3JvdXAsIGFuZCBub3QgdGhlIG0tbGluZSwg dGhhdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lLiAmbmJzcDvigIs8YnI+DQrigIsmZ3Q7PGJyPg0K 4oCLJmd0OyBCdXQgY2FuZGlkYXRlcyBhcmUgbW9yZSBwYWluZnVsIHRoYW4gdGhvc2Ugd291bGQg YmUgYmVjYXVzZSBvZiB0aGUgaW50ZXJhY3Rpb25zIHdpdGggdHJpY2tsZSBJQ0UuJm5ic3A7IElm IGl0IHdlcmVuJ3QgZm9yIHRyaWNrbGUgSUNFIHRoaXMgd291bGRuJ3QgYmUgYXMgYmlnIG9mIGEg ZGVhbC7igIs8YnI+DQo8YnI+DQpDb3JyZWN0LiBXZSBqdXN0IG5lZWQgdG8gbWFrZSBpdCB2ZXJ5 IGNsZWFyIHdoZXRoZXIgaXQgYXBwbGllcyBvbmx5IHRvIGNhbmRpZGF0ZSBhdHRyaWJ1dGVzLCBv ciB0byBhdHRyaWJ1dGVzIHdpdGggaWRlbnRpY2FsIHZhbHVlcyBpbiBnZW5lcmFsLjxicj4NCjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIuJm5ic3A7IElmIHRoZSBhbnN3 ZXJlciBkb2VzIG5vdCBpbmNsdWRlIGFueSBjYW5kaWRhdGVzIGluIHRoZSBhbnN3ZXIgYW5kIGlu c3RlYWQgdHJpY2tsZXMgdGhlbSBsYXRlciwgc2hvdWxkIGl0IHRyaWNrbGUgdGhlbTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE4gdGltZXMgKG9uY2UgZm9yIGVhY2ggbS1s aW5lIGluIHRoZSBCVU5ETEUgZ3JvdXApIG9yICZndDsxIHRpbWU/ICZuYnNwOzEgdGltZSBzZWVt cyBtdWNoIG1vcmUgcmVhc29uYWJsZSB0aGFuIE4gdGltZXMsIGJ1dDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlmIHdlIGR1cGxpY2F0ZSBjYW5kaWRhdGVzIGluIHRoZSBh bnN3ZXIsIGJ1dCBub3QgZHVwbGljYXRlIHRoZW0gd2hpbGUgdHJpY2tsaW5nLCB0aGF0J3MgYSBi aXQgaW5jb25zaXN0ZW50LiZuYnNwOyBZZXQgJmd0O2Fub3RoZXIgcmVhc29uIHRvIG5vdCBkdXBs aWNhdGUgaW4gdGhlIGFuc3dlciA6KS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBc3N1bWluZyB5b3UgdXNlIFNEUCB0 byBzaWduYWwgdGhlIHRyaWNrbGVkIGNhbmRpZGF0ZXMsIGl04oCZcyB0cnVlIHRoYXQgeW91IHdv dWxkIGR1cGxpY2F0ZSB0aGVtLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDvigItXaGF0J3MgdGhlIHJhdGlvbmFsZSBmb3IgdGhh dD8mbmJzcDsgVGhlc2UgZHVwbGljYXRlcyBwcm92aWRlIG5vIHZhbHVlLCBhbmQgaW4gdGhlIGNh c2Ugb2YgbWFueSBtLWxpbmVzIChzdWNoIGFzIGEgY29uZmVyZW5jaW5nPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7c3lzdGVtIHdpdGggbWFueSBwYXJ0aWNpcGFudHMpLCB3ZSBjb3VsZCBi ZSB0YWxraW5nIGFib3V0IDMweCB0aGUgbnVtYmVyIG9mIGNhbmRpZGF0ZXMgYmVpbmcgc2lnbmFs ZWQuICZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEkg aGVhciB3aGF0IHlvdSBhcmUgc2F5aW5nLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IEJ1dCwgaWYgd2Ugd291bGQgZG8gYSBjaGFuZ2UsIHdlIGFsc28gbmVlZCB0 byBsb29rIGF0IHRoZSBmdWxsIHBpY3R1cmUsIGFuZCBjb25zaWRlciBzdWJzZXF1ZW50IG9mZmVy cyBldGMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K4oCLJmd0OyZndDsmZ3Q7IEkgdGhpbmsgYSBz aW1wbGUgcnVsZSB3b3VsZCBiZSAmcXVvdDtpZiB5b3Uga25vdyBpdCdzIGdvaW5nIHRvIGJlIGJ1 bmRsZWQgb250byBhbm90aGVyIG0tbGluZSwgZG9uJ3QgaW5jbHVkZTxicj4NCiZndDsmZ3Q7Jmd0 OyBjYW5kaWRhdGVzJnF1b3Q7LiZuYnNwOyBUaGF0IHdvdWxkIGdvIGZvciBidW5kbGUtb25seSBt LWxpbmVzIGluIGFuIG9mZmVyLCBidW5kbGVkIG0tbGluZXMgaW4gYW4gYW5zd2VyLCBhbmQgYnVu ZGxlZCBtLWxpbmVzIGluIGEgcmUtb2ZmZXIu4oCLPGJyPg0K4oCLJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgQnVuZGxlZCBtLSBsaW5lcyBpbiBhIHJlLW9mZmVyIGNhbiBzdGlsbCBiZSByZWpl Y3RlZCBieSB0aGUgYW5zd2VyZXIuPGJyPg0KJmd0Ozxicj4NCuKAiyZndDsgVGhhdCBzb3VuZHMg dGhlIHNhbWUgYXMgYW4gaW5pdGlhbCBvZmZlci4mbmJzcDsgSG93IGRvZXMgaXQgaW1wbHkgdGhh dCBhIHJlLW9mZmVyIG11c3QgZHVwbGljYXRlPGJyPg0KJmd0OyBjYW5kaWRhdGVzIGFjcm9zcyBt LWxpbmVzLCBldmVuIHdoZW4gYW4gaW5pdGlhbCBvZmZlciBkb2Vzbid0IG5lZWQgdG8/4oCLPGJy Pg0K4oCLPGJyPg0KSW4gdGhlIGluaXRpYWwgb2ZmZXIgZWFjaCBtLSBsaW5lIGNvbnRhaW5zIGNh bmRpZGF0ZXMgKHVuaXF1ZSkuIElmIGFuIG0tIGxpbmUgaW4gdGhlIG9mZmVyIGlzIHJlamVjdGVk LCB0aGUgYW5zd2VyZXIgbXVzdCBzZWxlY3QgdGhlIG9mZmVyZXIgQlVORExFIGFkZHJlc3MgKGFu ZCB0aGUgYXNzb2NpYXRlZCBjYW5kaWRpYXRlcykgZnJvbSBhbm90aGVyIG0tIGxpbmUuPGJyPg0K PGJyPg0KTm93LCBpbiBhIHJlLW9mZmVyLCBpZiB0aGUgbS0gbGluZSBjb250YWluaW5nIHRoZSBj YW5kaWRhdGVzIGlzIHJlamVjdGVkLCB0aGUgYW5zd2VyZXIgbmVlZHMgdG8gaW5jbHVkZSBpdHMg Y2FuZGlkYXRlcyBpbiBhbm90aGVyIG0tIGxpbmUgaW4gdGhlIGFuc3dlci4gVGhhdCdzIGRvYWJs ZSwgYnV0IGl0IHdvdWxkIG5lZWQgdG8gYmUgY2xlYXJseSBkb2N1bWVudGVkLiBJbiBvdGhlciB3 b3JkczogaXQgbmVlZHMgdG8gYmUgY2xlYXIgdGhhdCB0aGUNCiBjYW5kaWRhdGVzIGNhbiBvY2N1 ciBpbiBBTlkgb2YgdGhlIGJ1bmRsZWQgbS0gbGluZXMsIGFuZCB0aGF0IG0tIGxpbmUgbWF5IGNo YW5nZSBiZXR3ZWVuIG9mZmVycyBhbmQgYW5zd2Vycy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCL U28gYSBydWxlIG9mICZxdW90O3RoZSBjYW5kaWRhdGVzIGNhbiBiZSBpbiBhbnkgb25lIG9mIHRo ZSBtLWxpbmVzLCBhbmQgaXQgZG9lc24ndCBtYXR0ZXIgd2hpY2gsIGFuZCBpdCBjYW4gY2hhbmdl IGFueSB0aW1lJnF1b3Q7LiZuYnNwOyBUaGF0IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUuJm5ic3A7 IEl0IGxlYXZlIHRoZSBtb3N0IGZsZXhpYmlsaXR5IHRvIHRoZQ0KIG9uZSB3cml0aW5nIHRoZSBT RFAsIGFuZCBpdCdzIHZlcnkgZWFzeSB0byBpbXBsZW1lbnQgZm9yIHRoZSBvbmUgcmVhZGluZyB0 aGUgU0RQLuKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0 ZXImbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37E061CDESESSMB209erics_-- From nobody Thu Feb 18 08:40: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 814AA1ACE50 for ; Thu, 18 Feb 2016 08:40:41 -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 85OL6IeORtIJ for ; Thu, 18 Feb 2016 08:40:39 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E9E1ACE77 for ; Thu, 18 Feb 2016 08:40:39 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-04v.sys.comcast.net with comcast id Ksfv1s00357bBgG01sgezx; Thu, 18 Feb 2016 16:40:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-13v.sys.comcast.net with comcast id Ksge1s0013KdFy101sgeVe; Thu, 18 Feb 2016 16:40:38 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56C5F405.1020305@alum.mit.edu> Date: Thu, 18 Feb 2016 11:40:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455813638; bh=iJg/AOP9ycatjX3DgRWXgCNBsVvRDruRPvGGoNvWkLw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Iko6jNW+y0ktxvMt4PQP/b470ul4HXMCjCIcx2KmuXF0MB5hCs8BRDayhEKh+Q+1P 0Q4kOmEEEvOOkV6vOho5MNKwgfOhNlHeHRQeuWVe5o8Vj7QiE0ke2xj+4SSjy/NqUx wh/WP61kfNtHu30SKHQFa416UF8LRBuUgCaX2mqi6IJwPbeIZ98s3Aq6w/RzMuVKFP MtOVPnExnX0gyKJTuDF8O1Pe3OzX+TNlUBhlYkOP7wz8FSHXEsKFl0GUMPhE06mPcT 7Sp762SFh6nN5yoJvg6kI/MUo0zfkOf02MxT5QbtYg0xLOw+fkjjYW34MM4W7bY5h5 AS9UdK0BecYWw== Archived-At: Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 18 Feb 2016 16:40:41 -0000 On 2/18/16 7:19 AM, Christer Holmberg wrote: > **sounds of crickets** > > Ok, so assuming the scope of this change would only be ICE, we could say > that shared ICE candidates don’t have to be associated with each m- line > within a BUNDLE group – it’s enough if they are associated with one m- line. I haven't been following this discussion closely, so forgive me if I have misunderstood... I see how it might be inconvenient to redundantly provide all the candidates with each m-line. But at the least this exception will need very careful specification, or else it could lead to very confusing implementations. (For instance, different subsets of the candidates associated with different m-lines.) So if this is to be done, I think it should be quite restrictive. Perhaps either duplicate candidates with every m-line or else all the candidates with only one m-line, and no candidates with any of the other m-lines in the bundle. If in all m-lines of the offer then also in all accepted m-lines in the answer. If in only one m-line in the offer, then only in the corresponding m-line of the answer. Even then, what is to be done if the candidates are with only one of the m-lines in the offer, and the answerer wants to reject *that* m-line but accept others in the bundle? Does the answerer pick a different m-line to carry the candidates in the answer? Thanks, Paul > Q1: Does this apply only to the SDP ‘candidate’ attribute, or also to > other ICE-related SDP attributes? > > Q2: Is it a RECOMMENDED/SHOULD/MAY/MUST/MUST NOT? > > Now, if I don’t hear any feedback on this, I am NOT going to do the > change. Those who asked for this change (or otherwise have an opinion on > it), please speak up now. > > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 16. helmikuuta 2016 17:15 > *To:* Peter Thatcher > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE > > Hi, > > We still need to conclude this issue before we can ship BUNDLE, so I’d > like to hear some input from people. I do intend to request agenda time > to discuss it in Buenos Aires, but if we can find a solution before that > there will be more time for cookies… > > Regards, > > Christer > > *From:*Peter Thatcher [mailto:pthatcher@google.com] > *Sent:* 17. marraskuuta 2015 1:06 > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE > > On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg > > > wrote: > > Hi, > > >> I thinking mandating the candidates be duplicated in the answer has > three issues: > >> > >> 1. It conflicts with trickle ICE. > >> 2. It's slightly more complex to implement (we have to go add extra > logic to go duplicate these things) > >> 3. It's a complete waste of time/space/effort. The recipient of > these duplicate candidates is never going to anything with them. > > > > Those are all fair points. I wish we'd had more implementation input > when we write our specs. > > > > That's what I'm providing now :). We can still change the spec, > can't we? > ​ > Sure. > > However, as we are talking about a design wise big (in my opinion) > change, at a late stage, I'd like to hear what other people think. > > ​That sounds fair. I'd like to hear what others think about this.​ > > ​ > > > >>>Also keep in mind that, when a subsequent offer is sent, the > bundle-only attribute is no longer used. > >> > ​>>Can you point out where in the draft it says that? I tried > finding it and I had a difficult time seeing where bundle-only > wasn't allowed in a reoffer.​ > ​>> > >> Section 8.5.1 says: > >> > >> "When an offerer generates a subsequent offer, it MUST > assign the > >> previously selected offerer BUNDLE address [Section > 8.3.2], to each > >> bundled "m=" line (including any bundle-only "m=" line), > except if:" > >> > >> And, as the usage of the attribute is only defined when the port > value is zero, it would not work when the BUNDLE address (read: > non-zero port) must be associated with the m- line. > >> > >> Section 6 says: > >> > >> "The usage of the 'bundle-only' attribute is only defined for a > >> bundled "m=" line with a zero port value, within an offer. Other > >> usage is unspecified." > > > ​> Thanks. That text would be more clear as "with an initial offer" > instead of "whithin an offer", since that's what it really means in > conjuction with 8.5.1. > > Ok. > > > However, that's precisely the text that I think we could change. > I think we could change the bundle-only attribute to > > be allowed in answers and in subsequent offers. Then clients > could use the attribute as a way of avoiding duplication > > of candidates and the complications with trickle ICE.​ > > Assuming we would remove the duplication of candidates, I don't > think that would require us to change a semantics of the attribute. > We could simply say that the candidates don't need to be duplicated > in bundled m- lines, no matter if those m- lines are bundle-only or not. > > That would work as well. > > ​ > > > >>>> Would you then also in the subsequent offer only assign > possible candidates to only one m- line within the bundle group? > >>> > ​>>> That sounds logical to me. They aren't included in the first > offer. Why add them to subsequent offers? It's inconsistent, and a > waste. > >> > >> Then someone could ask: what about other (non-candidate) > attributes that must have identical values for each bundled m- line? > Should those also be assigned to only one of the m- lines? > > > ​> If it's something unique to the bundle group, and not the m-line, > that seems reasonable to me. ​ > ​> > ​> But candidates are more painful than those would be because of > the interactions with trickle ICE. If it weren't for trickle ICE > this wouldn't be as big of a deal.​ > > Correct. We just need to make it very clear whether it applies only > to candidate attributes, or to attributes with identical values in > general. > > >>>>>>>> 2. If the answerer does not include any candidates in the > answer and instead trickles them later, should it trickle them > >>>>>>>> N times (once for each m-line in the BUNDLE group) or >1 > time? 1 time seems much more reasonable than N times, but > >>>>>>>> if we duplicate candidates in the answer, but not > duplicate them while trickling, that's a bit inconsistent. Yet > >another reason to not duplicate in the answer :). > >>>>>>> > >>>>>>> Assuming you use SDP to signal the trickled candidates, > it’s true that you would duplicate them, > >>>>>>> > >>>>>>​What's the rationale for that? These duplicates provide no > value, and in the case of many m-lines (such as a conferencing > >>>>>>system with many participants), we could be talking about 30x > the number of candidates being signaled. > >>>> > >>>> I hear what you are saying. > >>>> > >>>> But, if we would do a change, we also need to look at the full > picture, and consider subsequent offers etc. > >>> > ​>>> I think a simple rule would be "if you know it's going to be > bundled onto another m-line, don't include > >>> candidates". That would go for bundle-only m-lines in an > offer, bundled m-lines in an answer, and bundled m-lines in a re-offer.​ > ​>>> > >> Bundled m- lines in a re-offer can still be rejected by the > answerer. > > > ​> That sounds the same as an initial offer. How does it imply that > a re-offer must duplicate > > candidates across m-lines, even when an initial offer doesn't > need to?​ > ​ > In the initial offer each m- line contains candidates (unique). If > an m- line in the offer is rejected, the answerer must select the > offerer BUNDLE address (and the associated candidiates) from another > m- line. > > Now, in a re-offer, if the m- line containing the candidates is > rejected, the answerer needs to include its candidates in another m- > line in the answer. That's doable, but it would need to be clearly > documented. In other words: it needs to be clear that the candidates > can occur in ANY of the bundled m- lines, and that m- line may > change between offers and answers. > > ​So a rule of "the candidates can be in any one of the m-lines, and it > doesn't matter which, and it can change any time". That seems > reasonable to me. It leave the most flexibility to the one writing the > SDP, and it's very easy to implement for the one reading the SDP.​ > > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Feb 18 10:56: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 213D41A014A for ; Thu, 18 Feb 2016 10:56: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 pLSt6KxGy08j for ; Thu, 18 Feb 2016 10:56: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 2A0BB1A90CF for ; Thu, 18 Feb 2016 10:56:05 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-9c-56c613c39b5e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E1.1C.02707.3C316C65; Thu, 18 Feb 2016 19:56:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Thu, 18 Feb 2016 19:56:02 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" , Peter Thatcher Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75iggAA8gYCAADDekA== Date: Thu, 18 Feb 2016 18:56:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> In-Reply-To: <56C5F405.1020305@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdS/ew8LEwg87PghZTlz9msVix4QCr xbXlr1kdmD3+vv/A5LFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyDnZOZi5YVlBxbK1rA+OW 3C5GTg4JAROJC81LGSFsMYkL99azdTFycQgJHGaUaLl1igXCWcwocezJRyCHg4NNwEKi+582 SIOIQJnE/RfLwZqFBRwk9jzZyg4Rd5SYs+IcG4RdJ/Fl8UywOIuAqsS00y+ZQGxeAV+JddMe MUHMX8YmMX3NcrAEp4COxITHS8CaGYEu+n5qDVicWUBc4taT+UwQlwpILNlznhnCFpV4+fgf K4StJNG45AkryJ3MApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCy rGIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjJqDW34b7GB8+dzxEKMAB6MSD2/B7yNhQqyJ ZcWVuYcYJTiYlUR4qz4fDRPiTUmsrEotyo8vKs1JLT7EKM3BoiTOu9p5fZiQQHpiSWp2ampB ahFMlomDU6qBkWWOk+lzRv3ZbWEfrRrZv7nu0lfI039vnKzjnpnC15s4//jPvcW6c58/VZ68 fkPV50+eiw8bnN5T+2pfReY2O4+5DeIr93xY03BXQeTj62btlWevTko6Zce26S5nTlSc70s/ 87L+32qGk/ofhYrFpuhYXq1lPZbbe1WgOEIwy/nyRyVBx5NWSizFGYmGWsxFxYkAFwUVzZYC AAA= Archived-At: Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 18 Feb 2016 18:56:09 -0000 SGkgUGF1bCwNCg0KPj4gT2ssIHNvIGFzc3VtaW5nIHRoZSBzY29wZSBvZiB0aGlzIGNoYW5nZSB3 b3VsZCBvbmx5IGJlIElDRSwgd2UgY291bGQgDQo+PiBzYXkgdGhhdCBzaGFyZWQgSUNFIGNhbmRp ZGF0ZXMgZG9u4oCZdCBoYXZlIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBlYWNoIA0KPj4gbS0gbGlu ZSB3aXRoaW4gYSBCVU5ETEUgZ3JvdXAg4oCTIGl04oCZcyBlbm91Z2ggaWYgdGhleSBhcmUgYXNz b2NpYXRlZCB3aXRoIG9uZSBtLSBsaW5lLg0KPg0KPiBJIGhhdmVuJ3QgYmVlbiBmb2xsb3dpbmcg dGhpcyBkaXNjdXNzaW9uIGNsb3NlbHksIHNvIGZvcmdpdmUgbWUgaWYgSSBoYXZlIG1pc3VuZGVy c3Rvb2QuLi4NCg0KRG9uJ3Qgd29ycnkgLSB0aGVyZSBoYXNuJ3QgYmVlbiBtdWNoIGRpc2N1c3Np b24gOikNCg0KPiBJIHNlZSBob3cgaXQgbWlnaHQgYmUgaW5jb252ZW5pZW50IHRvIHJlZHVuZGFu dGx5IHByb3ZpZGUgYWxsIHRoZSBjYW5kaWRhdGVzIHdpdGggZWFjaCBtLWxpbmUuIEJ1dCBhdCB0 aGUgbGVhc3QgDQo+IHRoaXMgZXhjZXB0aW9uIHdpbGwgbmVlZCB2ZXJ5IGNhcmVmdWwgc3BlY2lm aWNhdGlvbiwgb3IgZWxzZSBpdCBjb3VsZCBsZWFkIHRvIHZlcnkgY29uZnVzaW5nIGltcGxlbWVu dGF0aW9ucy4NCg0KQ29ycmVjdCwgYW5kIHRoYXQncyBvbmUgcmVhc29uIEkgc3VnZ2VzdCB0aGF0 IHdlIGxpbWl0IHRoZSBzY29wZSB0byBJQ0UsIGV2ZW50aG91Z2ggd2UgcHJvYmFibHkgY291bGQg ZG8gdGhlIHNhbWUgdGhpbmcgZm9yIGFueSBJREVOVElDQUwgYW5kIFRSQU5TUE9SVCBjYXRlZ29y eSBhdHRyaWJ1dGUuDQoNCj4gKEZvciBpbnN0YW5jZSwgZGlmZmVyZW50IHN1YnNldHMgb2YgdGhl IGNhbmRpZGF0ZXMgYXNzb2NpYXRlZCB3aXRoIGRpZmZlcmVudCBtLWxpbmVzLikNCg0KTm90ZSB0 aGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IG0tIGxpbmVzIHdpdGhpbiBhIGdpdmVuIEJVTkRMRSBn cm91cCwgd2hlcmUgdGhlIHNhbWUgc2V0IG9mIHNoYXJlZCBjYW5kaWRhdGVzIGFwcGx5IHRvIGVh Y2ggbS0gbGluZS4gVGhlcmUgd2lsbCBiZSBubyBzdWJzZXQuDQoNCj4gU28gaWYgdGhpcyBpcyB0 byBiZSBkb25lLCBJIHRoaW5rIGl0IHNob3VsZCBiZSBxdWl0ZSByZXN0cmljdGl2ZS4gDQo+IFBl cmhhcHMgZWl0aGVyIGR1cGxpY2F0ZSBjYW5kaWRhdGVzIHdpdGggZXZlcnkgbS1saW5lIG9yIGVs c2UgYWxsIHRoZSBjYW5kaWRhdGVzIHdpdGggb25seSBvbmUgbS1saW5lLCBhbmQgbm8gY2FuZGlk YXRlcyB3aXRoIGFueSBvZiB0aGUgb3RoZXIgbS1saW5lcyBpbiB0aGUgYnVuZGxlLg0KDQpXZSBj b3VsZCBlLmcuIHNheSB0aGF0IHNoYXJlZCBjYW5kaWRhdGVzIE1VU1QgYmUgcGxhY2VkIGluIHRo ZSBtLSBsaW5lIHJlcHJlc2VudGluZyB0aGUgQlVORExFIGFkZHJlc3MgKGZpcnN0IG1pZCBpbiB0 aGUgbWlkIGxpc3QpLiBUaGVuIHdlIGNhbiBlaXRoZXIgZm9yYmlkIHRoZW0gdG8gYmUgcGxhY2Vk IGVsc2V3aGVyZSwgb3Igc2F5IHRoYXQgdGhleSBjYW4gYmUgZGlzY2FyZGVkIGlmIHBsYWNlZCBl bHNld2hlcmUuIA0KDQooVW5pcXVlIGNhbmRpZGF0ZXMgbXVzdCBvYnZpb3VzbHkgYWx3YXlzIGJl IGV4cGxpY2l0bHkgcGxhY2VkIGluIHRoZSBtLSBsaW5lIHRoZXkgYmVsb25nIHRvLikNCg0KPiBJ ZiBpbiBhbGwgbS1saW5lcyBvZiB0aGUgb2ZmZXIgdGhlbiBhbHNvIGluIGFsbCBhY2NlcHRlZCBt LWxpbmVzIGluIHRoZSBhbnN3ZXIuIElmIGluIG9ubHkgb25lIG0tbGluZSBpbiB0aGUgb2ZmZXIs IHRoZW4gb25seSBpbiB0aGUgY29ycmVzcG9uZGluZyBtLWxpbmUgb2YgdGhlIGFuc3dlci4NCj4N Cj4gRXZlbiB0aGVuLCB3aGF0IGlzIHRvIGJlIGRvbmUgaWYgdGhlIGNhbmRpZGF0ZXMgYXJlIHdp dGggb25seSBvbmUgb2YgdGhlIG0tbGluZXMgaW4gdGhlIG9mZmVyLCBhbmQgdGhlIGFuc3dlcmVy IHdhbnRzIHRvIHJlamVjdCAqdGhhdCogbS1saW5lIGJ1dA0KPiBhY2NlcHQgb3RoZXJzIGluIHRo ZSBidW5kbGU/IERvZXMgdGhlIGFuc3dlcmVyIHBpY2sgYSBkaWZmZXJlbnQgbS1saW5lIHRvIGNh cnJ5IHRoZSBjYW5kaWRhdGVzIGluIHRoZSBhbnN3ZXI/DQoNCk1hbmRhdGluZyB0aGUgY2FuZGlk YXRlcyBpbiB0aGUgbS0gbGluZSByZXByZXNlbnRpbmcgdGhlIEJVTkRMRSBhZGRyZXNzIHdvdWxk IHdvcmssIGJlY2F1c2UgdGhhdCBtLSBsaW5lIGFsd2F5cyBiZWxvbmdzIHRvIHRoZSBCVU5ETEUg Z3JvdXAuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCgkNCg0KPiBRMTogRG9lcyB0aGlzIGFw cGx5IG9ubHkgdG8gdGhlIFNEUCDigJhjYW5kaWRhdGXigJkgYXR0cmlidXRlLCBvciBhbHNvIHRv IA0KPiBvdGhlciBJQ0UtcmVsYXRlZCBTRFAgYXR0cmlidXRlcz8NCj4NCj4gUTI6IElzIGl0IGEg UkVDT01NRU5ERUQvU0hPVUxEL01BWS9NVVNUL01VU1QgTk9UPw0KPg0KPiBOb3csIGlmIEkgZG9u 4oCZdCBoZWFyIGFueSBmZWVkYmFjayBvbiB0aGlzLCBJIGFtIE5PVCBnb2luZyB0byBkbyB0aGUg DQo+IGNoYW5nZS4gVGhvc2Ugd2hvIGFza2VkIGZvciB0aGlzIGNoYW5nZSAob3Igb3RoZXJ3aXNl IGhhdmUgYW4gb3BpbmlvbiANCj4gb24gaXQpLCBwbGVhc2Ugc3BlYWsgdXAgbm93Lg0KPg0KPiBS ZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPiAqRnJvbToqbW11c2ljIFttYWlsdG86bW11c2lj LWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkNocmlzdGVyIA0KPiBIb2xtYmVyZw0K PiAqU2VudDoqIDE2LiBoZWxtaWt1dXRhIDIwMTYgMTc6MTUNCj4gKlRvOiogUGV0ZXIgVGhhdGNo ZXINCj4gKkNjOiogbW11c2ljQGlldGYub3JnDQo+ICpTdWJqZWN0OiogUmU6IFtNTVVTSUNdIFF1 ZXN0aW9ucyBhYm91dCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEJVTkRMRQ0KPg0KPiBIaSwNCj4NCj4g V2Ugc3RpbGwgbmVlZCB0byBjb25jbHVkZSB0aGlzIGlzc3VlIGJlZm9yZSB3ZSBjYW4gc2hpcCBC VU5ETEUsIHNvIEnigJlkIA0KPiBsaWtlIHRvIGhlYXIgc29tZSBpbnB1dCBmcm9tIHBlb3BsZS4g SSBkbyBpbnRlbmQgdG8gcmVxdWVzdCBhZ2VuZGEgDQo+IHRpbWUgdG8gZGlzY3VzcyBpdCBpbiBC dWVub3MgQWlyZXMsIGJ1dCBpZiB3ZSBjYW4gZmluZCBhIHNvbHV0aW9uIA0KPiBiZWZvcmUgdGhh dCB0aGVyZSB3aWxsIGJlIG1vcmUgdGltZSBmb3IgY29va2llc+KApg0KPg0KPiBSZWdhcmRzLA0K Pg0KPiBDaHJpc3Rlcg0KPg0KPiAqRnJvbToqUGV0ZXIgVGhhdGNoZXIgW21haWx0bzpwdGhhdGNo ZXJAZ29vZ2xlLmNvbV0NCj4gKlNlbnQ6KiAxNy4gbWFycmFza3V1dGEgMjAxNSAxOjA2DQo+ICpU bzoqIENocmlzdGVyIEhvbG1iZXJnDQo+ICpDYzoqIG1tdXNpY0BpZXRmLm9yZyA8bWFpbHRvOm1t dXNpY0BpZXRmLm9yZz4NCj4gKlN1YmplY3Q6KiBSZTogW01NVVNJQ10gUXVlc3Rpb25zIGFib3V0 IElDRSBjYW5kaWRhdGVzIHdpdGggQlVORExFDQo+DQo+IE9uIE1vbiwgTm92IDE2LCAyMDE1IGF0 IDI6NTggUE0sIENocmlzdGVyIEhvbG1iZXJnIA0KPiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIA0KPiA8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQo+IHdy b3RlOg0KPg0KPiBIaSwNCj4NCj4gID4+IEkgdGhpbmtpbmcgbWFuZGF0aW5nIHRoZSBjYW5kaWRh dGVzIGJlIGR1cGxpY2F0ZWQgaW4gdGhlIGFuc3dlciANCj4gaGFzIHRocmVlIGlzc3VlczoNCj4g ID4+DQo+ICA+PiAxLiAgSXQgY29uZmxpY3RzIHdpdGggdHJpY2tsZSBJQ0UuDQo+ICA+PiAyLiAg SXQncyBzbGlnaHRseSBtb3JlIGNvbXBsZXggdG8gaW1wbGVtZW50ICh3ZSBoYXZlIHRvIGdvIGFk ZCANCj4gZXh0cmEgbG9naWMgdG8gZ28gZHVwbGljYXRlIHRoZXNlIHRoaW5ncykgID4+IDMuICBJ dCdzIGEgY29tcGxldGUgDQo+IHdhc3RlIG9mIHRpbWUvc3BhY2UvZWZmb3J0LiAgVGhlIHJlY2lw aWVudCBvZiB0aGVzZSBkdXBsaWNhdGUgDQo+IGNhbmRpZGF0ZXMgaXMgbmV2ZXIgZ29pbmcgdG8g YW55dGhpbmcgd2l0aCB0aGVtLg0KPiAgPg0KPiAgPiBUaG9zZSBhcmUgYWxsIGZhaXIgcG9pbnRz LiBJIHdpc2ggd2UnZCBoYWQgbW9yZSBpbXBsZW1lbnRhdGlvbiANCj4gaW5wdXQgd2hlbiB3ZSB3 cml0ZSBvdXIgc3BlY3MuDQo+ICA+DQo+ICA+IFRoYXQncyB3aGF0IEknbSBwcm92aWRpbmcgbm93 IDopLiAgV2UgY2FuIHN0aWxsIGNoYW5nZSB0aGUgc3BlYywgDQo+IGNhbid0IHdlPw0KPiDigIsN Cj4gU3VyZS4NCj4NCj4gSG93ZXZlciwgYXMgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBkZXNpZ24g d2lzZSBiaWcgKGluIG15IG9waW5pb24pIA0KPiBjaGFuZ2UsIGF0IGEgbGF0ZSBzdGFnZSwgSSdk IGxpa2UgdG8gaGVhciB3aGF0IG90aGVyIHBlb3BsZSB0aGluay4NCj4NCj4g4oCLVGhhdCBzb3Vu ZHMgZmFpci4gIEknZCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlcnMgdGhpbmsgYWJvdXQgdGhpcy7i gIsNCj4NCj4g4oCLDQo+DQo+DQo+ICAgICAgPj4+QWxzbyBrZWVwIGluIG1pbmQgdGhhdCwgd2hl biBhIHN1YnNlcXVlbnQgb2ZmZXIgaXMgc2VudCwgdGhlDQo+ICAgICBidW5kbGUtb25seSBhdHRy aWJ1dGUgaXMgbm8gbG9uZ2VyIHVzZWQuDQo+ICAgICAgPj4NCj4gICAgIOKAiz4+Q2FuIHlvdSBw b2ludCBvdXQgd2hlcmUgaW4gdGhlIGRyYWZ0IGl0IHNheXMgdGhhdD8gIEkgdHJpZWQNCj4gICAg IGZpbmRpbmcgaXQgYW5kIEkgaGFkIGEgZGlmZmljdWx0IHRpbWUgc2VlaW5nIHdoZXJlIGJ1bmRs ZS1vbmx5DQo+ICAgICB3YXNuJ3QgYWxsb3dlZCBpbiBhIHJlb2ZmZXIu4oCLDQo+ICAgICDigIs+ Pg0KPiAgICAgID4+IFNlY3Rpb24gOC41LjEgc2F5czoNCj4gICAgICA+Pg0KPiAgICAgID4+ICAg ICAgICAiV2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRlcyBhIHN1YnNlcXVlbnQgb2ZmZXIsIGl0IE1V U1QNCj4gICAgIGFzc2lnbiB0aGUNCj4gICAgICA+PiAgICAgICBwcmV2aW91c2x5IHNlbGVjdGVk IG9mZmVyZXIgQlVORExFIGFkZHJlc3MgW1NlY3Rpb24NCj4gICAgIDguMy4yXSwgdG8gZWFjaA0K PiAgICAgID4+ICAgICAgIGJ1bmRsZWQgIm09IiBsaW5lIChpbmNsdWRpbmcgYW55IGJ1bmRsZS1v bmx5ICJtPSIgbGluZSksDQo+ICAgICBleGNlcHQgaWY6Ig0KPiAgICAgID4+DQo+ICAgICAgPj4g QW5kLCBhcyB0aGUgdXNhZ2Ugb2YgdGhlIGF0dHJpYnV0ZSBpcyBvbmx5IGRlZmluZWQgd2hlbiB0 aGUgcG9ydA0KPiAgICAgdmFsdWUgaXMgemVybywgaXQgd291bGQgbm90IHdvcmsgd2hlbiB0aGUg QlVORExFIGFkZHJlc3MgKHJlYWQ6DQo+ICAgICBub24temVybyBwb3J0KSBtdXN0IGJlIGFzc29j aWF0ZWQgd2l0aCB0aGUgbS0gbGluZS4NCj4gICAgICA+Pg0KPiAgICAgID4+IFNlY3Rpb24gNiBz YXlzOg0KPiAgICAgID4+DQo+ICAgICAgPj4gICAiVGhlIHVzYWdlIG9mIHRoZSAnYnVuZGxlLW9u bHknIGF0dHJpYnV0ZSBpcyBvbmx5IGRlZmluZWQgZm9yIGENCj4gICAgICA+PiAgIGJ1bmRsZWQg Im09IiBsaW5lIHdpdGggYSB6ZXJvIHBvcnQgdmFsdWUsIHdpdGhpbiBhbiBvZmZlci4gIE90aGVy DQo+ICAgICAgPj4gICB1c2FnZSBpcyB1bnNwZWNpZmllZC4iDQo+ICAgICAgPg0KPiAgICAg4oCL PiBUaGFua3MuICBUaGF0IHRleHQgd291bGQgYmUgbW9yZSBjbGVhciBhcyAid2l0aCBhbiBpbml0 aWFsIG9mZmVyIg0KPiAgICAgaW5zdGVhZCBvZiAid2hpdGhpbiBhbiBvZmZlciIsIHNpbmNlIHRo YXQncyB3aGF0IGl0IHJlYWxseSBtZWFucyBpbg0KPiAgICAgY29uanVjdGlvbiB3aXRoIDguNS4x Lg0KPg0KPiAgICAgT2suDQo+DQo+ICAgICAgPiBIb3dldmVyLCB0aGF0J3MgcHJlY2lzZWx5IHRo ZSB0ZXh0IHRoYXQgSSB0aGluayB3ZSBjb3VsZCBjaGFuZ2UuDQo+ICAgICBJIHRoaW5rIHdlIGNv dWxkIGNoYW5nZSB0aGUgYnVuZGxlLW9ubHkgYXR0cmlidXRlIHRvDQo+ICAgICAgPiBiZSBhbGxv d2VkIGluIGFuc3dlcnMgYW5kIGluIHN1YnNlcXVlbnQgb2ZmZXJzLiAgVGhlbiBjbGllbnRzDQo+ ICAgICBjb3VsZCB1c2UgdGhlIGF0dHJpYnV0ZSBhcyBhIHdheSBvZiBhdm9pZGluZyBkdXBsaWNh dGlvbg0KPiAgICAgID4gb2YgY2FuZGlkYXRlcyBhbmQgdGhlIGNvbXBsaWNhdGlvbnMgd2l0aCB0 cmlja2xlIElDRS7igIsNCj4NCj4gICAgIEFzc3VtaW5nIHdlIHdvdWxkIHJlbW92ZSB0aGUgZHVw bGljYXRpb24gb2YgY2FuZGlkYXRlcywgSSBkb24ndA0KPiAgICAgdGhpbmsgdGhhdCB3b3VsZCBy ZXF1aXJlIHVzIHRvIGNoYW5nZSBhIHNlbWFudGljcyBvZiB0aGUgYXR0cmlidXRlLg0KPiAgICAg V2UgY291bGQgc2ltcGx5IHNheSB0aGF0IHRoZSBjYW5kaWRhdGVzIGRvbid0IG5lZWQgdG8gYmUg ZHVwbGljYXRlZA0KPiAgICAgaW4gYnVuZGxlZCBtLSBsaW5lcywgbm8gbWF0dGVyIGlmIHRob3Nl IG0tIGxpbmVzIGFyZSBidW5kbGUtb25seSBvciBub3QuDQo+DQo+IFRoYXQgd291bGQgd29yayBh cyB3ZWxsLg0KPg0KPiDigIsNCj4NCj4NCj4gICAgICA+Pj4+IFdvdWxkIHlvdSB0aGVuIGFsc28g aW4gdGhlIHN1YnNlcXVlbnQgb2ZmZXIgb25seSBhc3NpZ24NCj4gICAgIHBvc3NpYmxlIGNhbmRp ZGF0ZXMgdG8gb25seSBvbmUgbS0gbGluZSB3aXRoaW4gdGhlIGJ1bmRsZSBncm91cD8NCj4gICAg ICA+Pj4NCj4gICAgIOKAiz4+PiBUaGF0IHNvdW5kcyBsb2dpY2FsIHRvIG1lLiAgVGhleSBhcmVu J3QgaW5jbHVkZWQgaW4gdGhlIGZpcnN0DQo+ICAgICBvZmZlci4gIFdoeSBhZGQgdGhlbSB0byBz dWJzZXF1ZW50IG9mZmVycz8gIEl0J3MgaW5jb25zaXN0ZW50LCBhbmQgYQ0KPiAgICAgd2FzdGUu DQo+ICAgICAgPj4NCj4gICAgICA+PiBUaGVuIHNvbWVvbmUgY291bGQgYXNrOiB3aGF0IGFib3V0 IG90aGVyIChub24tY2FuZGlkYXRlKQ0KPiAgICAgYXR0cmlidXRlcyB0aGF0IG11c3QgaGF2ZSBp ZGVudGljYWwgdmFsdWVzIGZvciBlYWNoIGJ1bmRsZWQgbS0gbGluZT8NCj4gICAgIFNob3VsZCB0 aG9zZSBhbHNvIGJlIGFzc2lnbmVkIHRvIG9ubHkgb25lIG9mIHRoZSBtLSBsaW5lcz8NCj4gICAg ICA+DQo+ICAgICDigIs+IElmIGl0J3Mgc29tZXRoaW5nIHVuaXF1ZSB0byB0aGUgYnVuZGxlIGdy b3VwLCBhbmQgbm90IHRoZSBtLWxpbmUsDQo+ICAgICB0aGF0IHNlZW1zIHJlYXNvbmFibGUgdG8g bWUuICDigIsNCj4gICAgIOKAiz4NCj4gICAgIOKAiz4gQnV0IGNhbmRpZGF0ZXMgYXJlIG1vcmUg cGFpbmZ1bCB0aGFuIHRob3NlIHdvdWxkIGJlIGJlY2F1c2Ugb2YNCj4gICAgIHRoZSBpbnRlcmFj dGlvbnMgd2l0aCB0cmlja2xlIElDRS4gIElmIGl0IHdlcmVuJ3QgZm9yIHRyaWNrbGUgSUNFDQo+ ICAgICB0aGlzIHdvdWxkbid0IGJlIGFzIGJpZyBvZiBhIGRlYWwu4oCLDQo+DQo+ICAgICBDb3Jy ZWN0LiBXZSBqdXN0IG5lZWQgdG8gbWFrZSBpdCB2ZXJ5IGNsZWFyIHdoZXRoZXIgaXQgYXBwbGll cyBvbmx5DQo+ICAgICB0byBjYW5kaWRhdGUgYXR0cmlidXRlcywgb3IgdG8gYXR0cmlidXRlcyB3 aXRoIGlkZW50aWNhbCB2YWx1ZXMgaW4NCj4gICAgIGdlbmVyYWwuDQo+DQo+ICAgICAgPj4+Pj4+ Pj4gMi4gIElmIHRoZSBhbnN3ZXJlciBkb2VzIG5vdCBpbmNsdWRlIGFueSBjYW5kaWRhdGVzIGlu IHRoZQ0KPiAgICAgYW5zd2VyIGFuZCBpbnN0ZWFkIHRyaWNrbGVzIHRoZW0gbGF0ZXIsIHNob3Vs ZCBpdCB0cmlja2xlIHRoZW0NCj4gICAgICA+Pj4+Pj4+PiBOIHRpbWVzIChvbmNlIGZvciBlYWNo IG0tbGluZSBpbiB0aGUgQlVORExFIGdyb3VwKSBvciA+MQ0KPiAgICAgdGltZT8gIDEgdGltZSBz ZWVtcyBtdWNoIG1vcmUgcmVhc29uYWJsZSB0aGFuIE4gdGltZXMsIGJ1dA0KPiAgICAgID4+Pj4+ Pj4+IGlmIHdlIGR1cGxpY2F0ZSBjYW5kaWRhdGVzIGluIHRoZSBhbnN3ZXIsIGJ1dCBub3QNCj4g ICAgIGR1cGxpY2F0ZSB0aGVtIHdoaWxlIHRyaWNrbGluZywgdGhhdCdzIGEgYml0IGluY29uc2lz dGVudC4gIFlldA0KPiAgICAgID5hbm90aGVyIHJlYXNvbiB0byBub3QgZHVwbGljYXRlIGluIHRo ZSBhbnN3ZXIgOikuDQo+ICAgICAgPj4+Pj4+Pg0KPiAgICAgID4+Pj4+Pj4gQXNzdW1pbmcgeW91 IHVzZSBTRFAgdG8gc2lnbmFsIHRoZSB0cmlja2xlZCBjYW5kaWRhdGVzLA0KPiAgICAgaXTigJlz IHRydWUgdGhhdCB5b3Ugd291bGQgZHVwbGljYXRlIHRoZW0sDQo+ICAgICAgPj4+Pj4+Pg0KPiAg ICAgID4+Pj4+PuKAi1doYXQncyB0aGUgcmF0aW9uYWxlIGZvciB0aGF0PyAgVGhlc2UgZHVwbGlj YXRlcyBwcm92aWRlIG5vDQo+ICAgICB2YWx1ZSwgYW5kIGluIHRoZSBjYXNlIG9mIG1hbnkgbS1s aW5lcyAoc3VjaCBhcyBhIGNvbmZlcmVuY2luZw0KPiAgICAgID4+Pj4+PnN5c3RlbSB3aXRoIG1h bnkgcGFydGljaXBhbnRzKSwgd2UgY291bGQgYmUgdGFsa2luZyBhYm91dCAzMHgNCj4gICAgIHRo ZSBudW1iZXIgb2YgY2FuZGlkYXRlcyBiZWluZyBzaWduYWxlZC4NCj4gICAgICA+Pj4+DQo+ICAg ICAgPj4+PiBJIGhlYXIgd2hhdCB5b3UgYXJlIHNheWluZy4NCj4gICAgICA+Pj4+DQo+ICAgICAg Pj4+PiBCdXQsIGlmIHdlIHdvdWxkIGRvIGEgY2hhbmdlLCB3ZSBhbHNvIG5lZWQgdG8gbG9vayBh dCB0aGUgZnVsbA0KPiAgICAgcGljdHVyZSwgYW5kIGNvbnNpZGVyIHN1YnNlcXVlbnQgb2ZmZXJz IGV0Yy4NCj4gICAgICA+Pj4NCj4gICAgIOKAiz4+PiBJIHRoaW5rIGEgc2ltcGxlIHJ1bGUgd291 bGQgYmUgImlmIHlvdSBrbm93IGl0J3MgZ29pbmcgdG8gYmUNCj4gICAgIGJ1bmRsZWQgb250byBh bm90aGVyIG0tbGluZSwgZG9uJ3QgaW5jbHVkZQ0KPiAgICAgID4+PiBjYW5kaWRhdGVzIi4gIFRo YXQgd291bGQgZ28gZm9yIGJ1bmRsZS1vbmx5IG0tbGluZXMgaW4gYW4NCj4gICAgIG9mZmVyLCBi dW5kbGVkIG0tbGluZXMgaW4gYW4gYW5zd2VyLCBhbmQgYnVuZGxlZCBtLWxpbmVzIGluIGEgcmUt b2ZmZXIu4oCLDQo+ICAgICDigIs+Pj4NCj4gICAgICA+PiBCdW5kbGVkIG0tIGxpbmVzIGluIGEg cmUtb2ZmZXIgY2FuIHN0aWxsIGJlIHJlamVjdGVkIGJ5IHRoZQ0KPiAgICAgYW5zd2VyZXIuDQo+ ICAgICAgPg0KPiAgICAg4oCLPiBUaGF0IHNvdW5kcyB0aGUgc2FtZSBhcyBhbiBpbml0aWFsIG9m ZmVyLiAgSG93IGRvZXMgaXQgaW1wbHkgdGhhdA0KPiAgICAgYSByZS1vZmZlciBtdXN0IGR1cGxp Y2F0ZQ0KPiAgICAgID4gY2FuZGlkYXRlcyBhY3Jvc3MgbS1saW5lcywgZXZlbiB3aGVuIGFuIGlu aXRpYWwgb2ZmZXIgZG9lc24ndA0KPiAgICAgbmVlZCB0bz/igIsNCj4gICAgIOKAiw0KPiAgICAg SW4gdGhlIGluaXRpYWwgb2ZmZXIgZWFjaCBtLSBsaW5lIGNvbnRhaW5zIGNhbmRpZGF0ZXMgKHVu aXF1ZSkuIElmDQo+ICAgICBhbiBtLSBsaW5lIGluIHRoZSBvZmZlciBpcyByZWplY3RlZCwgdGhl IGFuc3dlcmVyIG11c3Qgc2VsZWN0IHRoZQ0KPiAgICAgb2ZmZXJlciBCVU5ETEUgYWRkcmVzcyAo YW5kIHRoZSBhc3NvY2lhdGVkIGNhbmRpZGlhdGVzKSBmcm9tIGFub3RoZXINCj4gICAgIG0tIGxp bmUuDQo+DQo+ICAgICBOb3csIGluIGEgcmUtb2ZmZXIsIGlmIHRoZSBtLSBsaW5lIGNvbnRhaW5p bmcgdGhlIGNhbmRpZGF0ZXMgaXMNCj4gICAgIHJlamVjdGVkLCB0aGUgYW5zd2VyZXIgbmVlZHMg dG8gaW5jbHVkZSBpdHMgY2FuZGlkYXRlcyBpbiBhbm90aGVyIG0tDQo+ICAgICBsaW5lIGluIHRo ZSBhbnN3ZXIuIFRoYXQncyBkb2FibGUsIGJ1dCBpdCB3b3VsZCBuZWVkIHRvIGJlIGNsZWFybHkN Cj4gICAgIGRvY3VtZW50ZWQuIEluIG90aGVyIHdvcmRzOiBpdCBuZWVkcyB0byBiZSBjbGVhciB0 aGF0IHRoZSBjYW5kaWRhdGVzDQo+ICAgICBjYW4gb2NjdXIgaW4gQU5ZIG9mIHRoZSBidW5kbGVk IG0tIGxpbmVzLCBhbmQgdGhhdCBtLSBsaW5lIG1heQ0KPiAgICAgY2hhbmdlIGJldHdlZW4gb2Zm ZXJzIGFuZCBhbnN3ZXJzLg0KPg0KPiDigItTbyBhIHJ1bGUgb2YgInRoZSBjYW5kaWRhdGVzIGNh biBiZSBpbiBhbnkgb25lIG9mIHRoZSBtLWxpbmVzLCBhbmQgaXQgDQo+IGRvZXNuJ3QgbWF0dGVy IHdoaWNoLCBhbmQgaXQgY2FuIGNoYW5nZSBhbnkgdGltZSIuICBUaGF0IHNlZW1zIA0KPiByZWFz b25hYmxlIHRvIG1lLiAgSXQgbGVhdmUgdGhlIG1vc3QgZmxleGliaWxpdHkgdG8gdGhlIG9uZSB3 cml0aW5nIA0KPiB0aGUgU0RQLCBhbmQgaXQncyB2ZXJ5IGVhc3kgdG8gaW1wbGVtZW50IGZvciB0 aGUgb25lIHJlYWRpbmcgdGhlIFNEUC7igIsNCj4NCj4NCj4gICAgIFJlZ2FyZHMsDQo+DQo+ICAg ICBDaHJpc3Rlcg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxp bmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21tdXNpYw0K From nobody Thu Feb 18 11:03: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 A7E441B3204 for ; Thu, 18 Feb 2016 11:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.307 X-Spam-Level: X-Spam-Status: No, score=-13.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 s1nRGmkEEzpb for ; Thu, 18 Feb 2016 11:03:11 -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 D897E1B31EF for ; Thu, 18 Feb 2016 11:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11265; q=dns/txt; s=iport; t=1455822190; x=1457031790; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8VqFrnb09U83TRj2szi0rDC22rT/2LDL3RC40K8cQ9Y=; b=gr7n/UqioolkQryEXlQcoi7AVAYugl3owLjddXoJBGdB7SNUu5r5SZL/ hEeDXzuEFb7CrGo0iHDW9MFvcOHeBwDBhYWEIpkRbLlA2ngTePZLazRpw E6mAi6D2+TUEznblU+uQZw6RoQfmN2RVb902jKgGnQrriO5JfxAVe3DGM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQCGFMZW/4UNJK1eDoMsUm24EIITA?= =?us-ascii?q?Q2BZyGFIkoCgWU4FAEBAQEBAQFkJ4RBAQEBAwEjFUAGCwsYAgIFFgsCAgkDAgE?= =?us-ascii?q?CAUUGAQwIAQEFiAkIDqxyjxIBAQEBAQEBAQEBAQEBAQEBARl7hReEO4QFEQGDH?= =?us-ascii?q?oE6BY0qdIhnjVqJIYVSjkceAQFCgyhZHi4Bh26BMAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,466,1449532800"; d="scan'208";a="238164553" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2016 19:03:09 +0000 Received: from [10.82.235.214] (rtp-vpn5-979.cisco.com [10.82.235.214]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u1IJ386n001263; Thu, 18 Feb 2016 19:03:08 GMT To: Juergen Stoetzer-Bradler , Paul Kyzivat , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> From: Flemming Andreasen Message-ID: <56C6156C.2070308@cisco.com> Date: Thu, 18 Feb 2016 14:03:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C05B63.4030007@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; 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: Thu, 18 Feb 2016 19:03:14 -0000 On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: > Flemming, > > Regarding >> It would probably simplify the overall SDP negotiation part, but I >> don't know if it would constrain the way data channels were >> envisioned to be used. > > On Friday Paul mentioned in his email two potential use cases, where > no subprotocol identifiers might be added to a data channel's dcmap > attribute. In my last email I hadn't thought of such cases. If we > don't want to exclude such cases, then requiring the subprotocol ids > always to be present might indeed be too restrictive. > > Regarding >> Ok. Going back to discussion between Paul and I, do you believe that >> in for an attribute to be encapsulated in dcsa, the attribute MUST >> have been explicitly define to support this (Paul's suggestion below) >> or do you believe that this is overly constraining, and if so, how >> shoud we relax it ? > > I now think that the sdpneg draft might recommend SDP offerers and > answerers to always add a subprotocol identifier to a data channel's > dcmap attribute if dcsa embedded attributes are also negotiated for > the data channel's subprotocol. I also think we could explicitly add > text to sdpneg saying that subprotocol identifiers should be added to > the IANA Websocket (and in future combined data channel) registry. And > that this registration should be done via a document, which then > explicitly describes the usages and semantics of dcsa embedded > subprotocol attributes, _if_ those usages or semantics deviate from > cases, where these attributes are not dcsa encapsulated. I think that > in those cases, where the usage and meaning of an attribute (always > related to the data channel's subprotocol) does not deviate from the > non-dcsa encapsulated use cases, such an attribute may not explicitly > need to be described for data channel usage. But I think it might be > helpful to explicitly say so in the sdpneg draft. > > Somebody inspecting an SDP offer or answer, which was generated by an > implementation following these two recommendations (and which hence > contains an IANA registered subprotocol id if it contains any dcsa > embedded attributes), could then refer to that IANA table, would then > find the reference to the document, which defines this subprotocol id > for data channel usage, and there could check if any of the dcsa > embedded attributes has a data channel specific semantic. If yes, that > specific semantic would be described in that document. If such a > specific semantic were not described in that document, then the > default usage and semantic of the attribute would apply also to that > data channel transport case. > Sounds reasonable with the caveat that you may have attributes defined for use with a particular sub-protocol outside the subprotocol draft itself (e.g. because such an attribute was either defined subsequently or its use with a specific subprotocol is defined subsequently). If so, we would need an IANA registry structure (under SDP) that for each subprotocol defines the set of attributes that have been defined with specific semantics for that subprotocol. > But in that context I'd have an IANA table related question. > A certain subprotocol might be defined for Websocket usage as well as > for data channel usage. MSRP is already such a case, where > draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP over > data channels, and where draft-pd-dispatch-msrp-websocket defines how > to use MSRP over Websockets. > Would the IANA WebSocket Subprotocol Name Registry on > http://www.iana.org/assignments/websocket/websocket.xml then contain > two MSRP related rows? Or just one row containing references to both > the Websocket and data channel documents? > Should we add related text to the IANA registration section of the > sdpneg draft? See above. Thanks -- Flemming > > Thanks, > Juergen > > > On 12.02.2016 15:52, EXT Flemming Andreasen wrote: >> >> >> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>> Flemming, Paul, >>> >>> The current a=dcmap related text in >>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>> 'subprotocol' parameter must always be present - rather it is >>> specified as an optional parameter. Thus, current sdpneg text would >>> allow to create an SDP offer for a data channel, which contains one >>> a=dcmap attribute and potentially multiple a=dcsa attributes without >>> the subprotocol actually being given. Based on this discussion I am >>> wondering if the subprotocol parameter should actually be mandatory. >>> >> It would probably simplify the overall SDP negotiation part, but I >> don't know if it would constrain the way data channels were >> envisioned to be used. >> >> >>> In the specific case of MSRP, the msrp-usage-data-channel draft says >>> in 5.1.1.1 that the dcmap attribute includes the label and >>> subprotocol parameters. The current text could possible be made more >>> explicit by saying that the 'subprotocol="MSRP"' parameter must >>> always be present. >>> Have just submitted version 04 of the msrp-usage-data-channel draft, >>> which proposes to add subprotocol identifier "MSRP" to the WebSocket >>> Subprotocol Name registry. This registry would then associate >>> subprotocol id "MSRP" with the msrp-usage-data-channel document. >>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa >>> attribute are specified. And there the MSRP specific SDP attributes, >>> which can be dcsa embedded, are described. >>> 'setup' is an attribute, whose semantic changes when being dcsa >>> embedded and associated with subprotocol MSRP, as compared to the >>> meaning of an "a=setup" media level attribute of a TCP/MSRP m-line. >>> Hence these semantical differences are explicitly addressed in the >>> msrp-usage-data-channel draft. >>> >>> Regarding sdpneg, I also think that the current text in sdpneg seems >>> to be sufficient regarding the usage of dcsa encapsulated SDP >>> attributes as being bound to the data channel's subprotocol. But as >>> the semantic of a dcsa encapsulated attribute may be subprotocol >>> specific (like 'setup'), I'd now tend to consider the subprotocol >>> parameter in the dcmap attribute as being mandatory, as mentioned >>> above. As already discussed, the Websocket subprotocol registry >>> would then refer to the document, which specifies the subprotocol >>> specific usage of dcsa encapsulated parameters. >>> >> Ok. Going back to discussion between Paul and I, do you believe that >> in for an attribute to be encapsulated in dcsa, the attribute MUST >> have been explicitly define to support this (Paul's suggestion below) >> or do you believe that this is overly constraining, and if so, how >> shoud we relax it ? >> >> Thanks >> >> -- Flemming >> >> >>> Thanks, >>> Juergen >>> >>> >>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>> >>>> >>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>> >>>>>> >>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>> Isn't this the approach we're taking today? >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and >>>>>>>> specific >>>>>>>> drafts are used to describe protocols that use the mechanism (i.e. >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>> draft-ietf-clue-datachannel). >>>>>>> >>>>>>> It remains to be seen if that will be enough. E.g., there currently >>>>>>> aren't any iana considerations in >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>> >>>>>>> Suppose I encounter some sdp that uses msrp over a data channel, >>>>>>> but >>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>> reference to >>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage? >>>>>>> >>>>>>> I would like to think that the iana registries will allow me to >>>>>>> trace >>>>>>> back to the relevant specs. >>>>>>> >>>>>> No disagreement on that part, however having taken another look >>>>>> at both >>>>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>>>> original request for all (existing and new) attributes to specify >>>>>> how >>>>>> they may or may not be used with the dcsa attribute defined by >>>>>> sdpneg. >>>>>> >>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>> individual >>>>>> documents (like msrp-usage), which calls your the parameters that >>>>>> are at >>>>>> least needed to be supported for that usage. Taking MSRP as an >>>>>> example, >>>>>> why isn't that enough, and how do you see the resulting set of >>>>>> attributes that may or may not be used with MSRP differ between >>>>>> use in a >>>>>> data-channel (and hence encapsulated in dcsa) or as a regular media >>>>>> stream ? >>>>> >>>>> Based on this discussion, I conclude that it should be sufficient >>>>> for this draft to say that before an attribute can be used with >>>>> dcsa, such usage must be defined somewhere. This could be either: >>>>> - as part of the definition of the attribute, OR >>>>> - as part of the definition of the protocol referenced on the m-line. >>>>> >>>> We are getting closer, but it's still not obvious to me that you >>>> cannot use an attribute with dcsa if it has not been explicitly >>>> defined for the attribute in question. Clearly, there are >>>> attributes that wouldn't make sense over data channels, just like >>>> there are attributes that don't make sense over particular media >>>> descriptions. >>>> >>>> Again, I'd like to hear from more people on this, including the >>>> authors. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Also, it would be good to hear from more people on this, >>>>>> including the >>>>>> document authors. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>> >>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>>>> need to >>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>>>> should be >>>>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>>>> point is >>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>> interactions as >>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>> (plus the >>>>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>>>> wants to >>>>>>>>>> establish a data channel). >>>>>>>>> >>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>> pertains to >>>>>>>>> need to be defined to work over data channels. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> > > > . > From nobody Thu Feb 18 13:47: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 83F391A8A95; Thu, 18 Feb 2016 13:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 8uDJojakNWin; Thu, 18 Feb 2016 13:47:23 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA45C1A8AEE; Thu, 18 Feb 2016 13:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=486; q=dns/txt; s=iport; t=1455832043; x=1457041643; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=KWxacQp444VyrGiIcZ++6w8JkQ/njkTxROr8ph7s0R0=; b=lc5e9QkTjvD7JL/hHknyt/LyGvUWBJVRfNF7S8Ikz7jhWSIVjQMcNqR+ 17Ni9Qlw/BOXdpUJ1+g1MMp0cezi4W5VZJfOoFZcMK7GLGqIsGXncaI6F XOj4aRBOw8a0xGFsdlX6n1opg3WcksPNUNP0XavOh0+4NmEEVXXuMX6/J 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhBwA2O8ZW/xbLJq1ehAxtswSFD4QII?= =?us-ascii?q?YVsgjcBAQEBAQFlJ4REJxVAATUCBRYLAgsDAgECAUsNCAEBiBYOrQaPEAEBAQE?= =?us-ascii?q?BAQEDAQEBAQEBARUEe4UXi3CBOgEEjh6IZ41agVyEQ4MChDiBGo5HYoQBHi4Bi?= =?us-ascii?q?R4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,467,1449532800"; d="scan'208";a="635590580" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2016 21:47:21 +0000 Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1ILlK4N012593; Thu, 18 Feb 2016 21:47:20 GMT To: mmusic From: Flemming Andreasen Message-ID: <56C63BE8.6000607@cisco.com> Date: Thu, 18 Feb 2016 16:47:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-mux-exclusive@ietf.org Subject: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-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: Thu, 18 Feb 2016 21:47:24 -0000 Greetings MMUSIC This is to announce a 2 week WGLC on the draft: https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-03.txt as Proposed Standard. Please review and provide any comments you may have on the document by Thursday, March 3, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Fri Feb 19 05:58: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 7CD0F1A8ABC for ; Fri, 19 Feb 2016 05:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 Y_Vgo90-KVS1 for ; Fri, 19 Feb 2016 05:58:48 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 8E6521A9061 for ; Fri, 19 Feb 2016 05:58:47 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id A97D65510A7AF; Fri, 19 Feb 2016 13:58:40 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1JDwgSL005382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Feb 2016 13:58:42 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1JDv60J024276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Feb 2016 14:58:28 +0100 Received: from [149.204.68.190] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Feb 2016 14:56:04 +0100 From: Juergen Stoetzer-Bradler To: EXT Flemming Andreasen , Juergen Stoetzer-Bradler , Paul Kyzivat , , "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> <56C6156C.2070308@cisco.com> Message-ID: <56C71EF3.6040208@alcatel-lucent.com> Date: Fri, 19 Feb 2016 14:56:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C6156C.2070308@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030608050406070804040204" X-Originating-IP: [135.239.27.41] 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, 19 Feb 2016 13:58:54 -0000 --------------ms030608050406070804040204 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Flemming, Regarding > Sounds reasonable with the caveat that you may have attributes defined = for use with a particular=20 > sub-protocol outside the subprotocol draft itself (e.g. because such an= attribute was either=20 > defined subsequently or its use with a specific subprotocol is defined = subsequently). If so, we=20 > would need an IANA registry structure (under SDP) that for each subprot= ocol defines the set of=20 > attributes that have been defined with specific semantics for that subp= rotocol.=20 Let's assume a future document defines how to establish MSRP sessions ove= r a transport protocol=20 unequal to TCP, TLS, or data channel, and that this document also defines= a new MSRP related=20 attribute, whose semantic is only defined for this new transport case (li= ke a maximal MSRP chunk=20 size specific for the new transport). I assume that this future document = would request to add this=20 new attribute to one of the existing IANA SDP attribute tables (assumingl= y to the "att-field (media=20 level only)" table). Let's further assume that an implementation creates an SDP offer for an M= SRP session over a data=20 channel and adds this new attribute as dcsa embedded MSRP subprotocol att= ribute (for whatever reasons). Somebody seeing and inspecting this SDP offer could use the dcmap attribu= te's subprotocol value=20 "MSRP" to get a reference to the msrp-usage-data-channel document. That d= ocument would not mention=20 that new attribute at all. The next step could then be to consult the IAN= A SDP tables, and there=20 this new attribute would be found together with a reference to this futur= e document. As assumingly this new MSRP related attribute would only be defined for t= his new transport, I think=20 this new attribute should then be ignored by the recipient of this SDP of= fer. Section 5.2.5 of most recent draft-ietf-mmusic-data-channel-sdpneg-08 now= contains two related=20 recommendations: 'SDP offer or answer has an "a=3Ddcsa" attribute, whose subprotocol attri= bute is unknown. * The receiver of such an SDP offer or answer SHOULD ignore this entir= e "a=3Ddcsa" attribute line. SDP offer or answer has an "a=3Ddcsa" attribute, whose subprotocol attrib= ute is known, but whose=20 subprotocol attribute semantic is not known for the data channel transpor= t case. * The receiver of such an SDP offer or answer SHOULD ignore this entir= e "a=3Ddcsa" attribute line.' Would these recommendations address the case you are describing? Thanks, Juergen On 18.02.2016 20:03, EXT Flemming Andreasen wrote: > > > On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: >> Flemming, >> >> Regarding >>> It would probably simplify the overall SDP negotiation part, but I do= n't know if it would=20 >>> constrain the way data channels were envisioned to be used.=20 >> >> On Friday Paul mentioned in his email two potential use cases, where n= o subprotocol identifiers=20 >> might be added to a data channel's dcmap attribute. In my last email I= hadn't thought of such=20 >> cases. If we don't want to exclude such cases, then requiring the subp= rotocol ids always to be=20 >> present might indeed be too restrictive. >> >> Regarding >>> Ok. Going back to discussion between Paul and I, do you believe that = in for an attribute to be=20 >>> encapsulated in dcsa, the attribute MUST have been explicitly define = to support this (Paul's=20 >>> suggestion below) or do you believe that this is overly constraining,= and if so, how shoud we=20 >>> relax it ?=20 >> >> I now think that the sdpneg draft might recommend SDP offerers and ans= werers to always add a=20 >> subprotocol identifier to a data channel's dcmap attribute if dcsa emb= edded attributes are also=20 >> negotiated for the data channel's subprotocol. I also think we could e= xplicitly add text to=20 >> sdpneg saying that subprotocol identifiers should be added to the IANA= Websocket (and in future=20 >> combined data channel) registry. And that this registration should be = done via a document, which=20 >> then explicitly describes the usages and semantics of dcsa embedded su= bprotocol attributes, _if_=20 >> those usages or semantics deviate from cases, where these attributes a= re not dcsa encapsulated. I=20 >> think that in those cases, where the usage and meaning of an attribute= (always related to the=20 >> data channel's subprotocol) does not deviate from the non-dcsa encapsu= lated use cases, such an=20 >> attribute may not explicitly need to be described for data channel usa= ge. But I think it might be=20 >> helpful to explicitly say so in the sdpneg draft. >> >> Somebody inspecting an SDP offer or answer, which was generated by an = implementation following=20 >> these two recommendations (and which hence contains an IANA registered= subprotocol id if it=20 >> contains any dcsa embedded attributes), could then refer to that IANA = table, would then find the=20 >> reference to the document, which defines this subprotocol id for data = channel usage, and there=20 >> could check if any of the dcsa embedded attributes has a data channel = specific semantic. If yes,=20 >> that specific semantic would be described in that document. If such a = specific semantic were not=20 >> described in that document, then the default usage and semantic of the= attribute would apply also=20 >> to that data channel transport case. >> > Sounds reasonable with the caveat that you may have attributes defined = for use with a particular=20 > sub-protocol outside the subprotocol draft itself (e.g. because such an= attribute was either=20 > defined subsequently or its use with a specific subprotocol is defined = subsequently). If so, we=20 > would need an IANA registry structure (under SDP) that for each subprot= ocol defines the set of=20 > attributes that have been defined with specific semantics for that subp= rotocol. > > >> But in that context I'd have an IANA table related question. >> A certain subprotocol might be defined for Websocket usage as well as = for data channel usage.=20 >> MSRP is already such a case, where draft-ietf-mmusic-msrp-usage-data-c= hannel defines how to use=20 >> MSRP over data channels, and where draft-pd-dispatch-msrp-websocket de= fines how to use MSRP over=20 >> Websockets. >> Would the IANA WebSocket Subprotocol Name Registry on=20 >> http://www.iana.org/assignments/websocket/websocket.xml then contain t= wo MSRP related rows? Or=20 >> just one row containing references to both the Websocket and data chan= nel documents? >> Should we add related text to the IANA registration section of the sdp= neg draft? > See above. > > Thanks > > -- Flemming >> >> Thanks, >> Juergen >> >> >> On 12.02.2016 15:52, EXT Flemming Andreasen wrote: >>> >>> >>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>> Flemming, Paul, >>>> >>>> The current a=3Ddcmap related text in draft-ietf-mmusic-data-channel= -sdpneg doesn't require that=20 >>>> the 'subprotocol' parameter must always be present - rather it is sp= ecified as an optional=20 >>>> parameter. Thus, current sdpneg text would allow to create an SDP of= fer for a data channel,=20 >>>> which contains one a=3Ddcmap attribute and potentially multiple a=3D= dcsa attributes without the=20 >>>> subprotocol actually being given. Based on this discussion I am wond= ering if the subprotocol=20 >>>> parameter should actually be mandatory. >>>> >>> It would probably simplify the overall SDP negotiation part, but I do= n't know if it would=20 >>> constrain the way data channels were envisioned to be used. >>> >>> >>>> In the specific case of MSRP, the msrp-usage-data-channel draft says= in 5.1.1.1 that the dcmap=20 >>>> attribute includes the label and subprotocol parameters. The current= text could possible be=20 >>>> made more explicit by saying that the 'subprotocol=3D"MSRP"' paramet= er must always be present. >>>> Have just submitted version 04 of the msrp-usage-data-channel draft,= which proposes to add=20 >>>> subprotocol identifier "MSRP" to the WebSocket Subprotocol Name regi= stry. This registry would=20 >>>> then associate subprotocol id "MSRP" with the msrp-usage-data-channe= l document. >>>> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa a= ttribute are specified. And=20 >>>> there the MSRP specific SDP attributes, which can be dcsa embedded, = are described. >>>> 'setup' is an attribute, whose semantic changes when being dcsa embe= dded and associated with=20 >>>> subprotocol MSRP, as compared to the meaning of an "a=3Dsetup" media= level attribute of a=20 >>>> TCP/MSRP m-line. Hence these semantical differences are explicitly a= ddressed in the=20 >>>> msrp-usage-data-channel draft. >>>> >>>> Regarding sdpneg, I also think that the current text in sdpneg seems= to be sufficient regarding=20 >>>> the usage of dcsa encapsulated SDP attributes as being bound to the = data channel's subprotocol.=20 >>>> But as the semantic of a dcsa encapsulated attribute may be subproto= col specific (like=20 >>>> 'setup'), I'd now tend to consider the subprotocol parameter in the = dcmap attribute as being=20 >>>> mandatory, as mentioned above. As already discussed, the Websocket s= ubprotocol registry would=20 >>>> then refer to the document, which specifies the subprotocol specific= usage of dcsa encapsulated=20 >>>> parameters. >>>> >>> Ok. Going back to discussion between Paul and I, do you believe that = in for an attribute to be=20 >>> encapsulated in dcsa, the attribute MUST have been explicitly define = to support this (Paul's=20 >>> suggestion below) or do you believe that this is overly constraining,= and if so, how shoud we=20 >>> relax it ? >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>>> Thanks, >>>> Juergen >>>> >>>> >>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>> >>>>> >>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>> >>>>>>> >>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and spec= ific >>>>>>>>> drafts are used to describe protocols that use the mechanism (i= =2Ee. >>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>> >>>>>>>> It remains to be seen if that will be enough. E.g., there curren= tly >>>>>>>> aren't any iana considerations in >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>> >>>>>>>> Suppose I encounter some sdp that uses msrp over a data channel,= but >>>>>>>> that usage is unknown to me. How do I find the spec (the referen= ce to >>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usa= ge? >>>>>>>> >>>>>>>> I would like to think that the iana registries will allow me to = trace >>>>>>>> back to the relevant specs. >>>>>>>> >>>>>>> No disagreement on that part, however having taken another look a= t both >>>>>>> sdpneg and the msrp-usage documents, I still don't agree with you= r >>>>>>> original request for all (existing and new) attributes to specify= how >>>>>>> they may or may not be used with the dcsa attribute defined by sd= pneg. >>>>>>> >>>>>>> As Christian noted, the sub-protocol specifics are defined in ind= ividual >>>>>>> documents (like msrp-usage), which calls your the parameters that= are at >>>>>>> least needed to be supported for that usage. Taking MSRP as an ex= ample, >>>>>>> why isn't that enough, and how do you see the resulting set of >>>>>>> attributes that may or may not be used with MSRP differ between u= se in a >>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular med= ia >>>>>>> stream ? >>>>>> >>>>>> Based on this discussion, I conclude that it should be sufficient = for this draft to say that=20 >>>>>> before an attribute can be used with dcsa, such usage must be defi= ned somewhere. This could=20 >>>>>> be either: >>>>>> - as part of the definition of the attribute, OR >>>>>> - as part of the definition of the protocol referenced on the m-li= ne. >>>>>> >>>>> We are getting closer, but it's still not obvious to me that you ca= nnot use an attribute with=20 >>>>> dcsa if it has not been explicitly defined for the attribute in que= stion. Clearly, there are=20 >>>>> attributes that wouldn't make sense over data channels, just like t= here are attributes that=20 >>>>> don't make sense over particular media descriptions. >>>>> >>>>> Again, I'd like to hear from more people on this, including the aut= hors. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Also, it would be good to hear from more people on this, includin= g the >>>>>>> document authors. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>> >>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we n= eed to >>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it = should be >>>>>>>>>>> part of the IANA registry. What I am not agreeing with at thi= s >>>>>>>>>>> point is >>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>> interactions as >>>>>>>>>>> opposed to relying on a more general algorithmic approach (pl= us the >>>>>>>>>>> offerer being responsible for generating a valid offer if he = wants to >>>>>>>>>>> establish a data channel). >>>>>>>>>> >>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute per= tains to >>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >> >> >> . >> > --------------ms030608050406070804040204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DF8wggTdMIIDxaADAgECAgoanQrOAAAAAAAGMA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoT DkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBSb290 IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcyOFowgYUxEzARBgoJkiaJk/IsZAEZ FgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ocmcli3LbVU6TRh +JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdfkyWAiGzVWeRI rYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38VbxMvQ+ygj Eyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+VdiUwDa ry1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsG AQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAes slr2YYl8XHzr4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5z dXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5h bGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4Bggr BgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQw OAYIKwYBBQUHMAKGLGh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQClGxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3 F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjbEhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx 4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6 rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwfRfPmwRetdnD6NC5x8aRkhr4ZNBjv YxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6/XpNOx2FyG18axeeASWtENgP vqEirM5MjwkCMIIHejCCBmKgAwIBAgIKYWH+JwAAAAFWdjANBgkqhkiG9w0BAQUFADCBhTET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVs IEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNTE4MTMwNzI0WhcNMTcwNTE3MTMwNzI0 WjBOMRAwDgYDVQQDEwdsaTYwNzYwMTowOAYJKoZIhvcNAQkBFitqdWVyZ2VuLnN0b2V0emVy LWJyYWRsZXJAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3SjiDDt1yolL0cBi5MS+Bea3hhVDSdcJ/xtfzEbTtkxo05xnMgeRTy/kNJZuR4oY j/2TE+raQenSEgROQtLgxKjxtLh9/fGEuLCyFclz9SIeIYIkZBB1NSwZKmGlJHRU5jjqSinT Hmux9chaP+TUoidoDYbfdz/uFGdPW7RP21Gxjzg9v/VC+tfc0u0idNF9Vwnkh3VgdisMf1Jf JZNINpw0ZapFKRhLEhgtXVS7tkdxxTL0uc9XtviOTSSfxgBt2MPsj0qfhsNFFO4zUO1pJiBz SBPnLt7af96oS2ZHI4Xz7zNHShDoSMMIr+7l9xgopb5qN/KMCMP9BSxxNEfphwIDAQABo4IE IDCCBBwwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmB C/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0P BAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkq hkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFEVmlcJSxtK5Cu7FZb5XUWWuKktKMB8GA1UdIwQYMBaA FNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFMoIIBSKCCAUSGgdls ZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPXVz bmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFh BggrBgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUy MEx1Y2VudCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNl bnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MDgGCCsGAQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20v UEtJL3N1YkNBLmNydDBEBggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxj YXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwNgYDVR0RBC8wLYEranVlcmdlbi5zdG9l dHplci1icmFkbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAMrtX ZAqm6NqOAYttJjvC6pL04tEKUusax1Dr6p6NfxVfUuW8ZoFXKoxHEDaYKQR9ldfnuILHN+x7 KdLeKg+NPUs7GFGwpBmJb7PRmxnIarFJbGHzpqZ9+Fhsde1uxi+y2VJcIOVaEh/JoRdHvSUQ nwT4+FcBmS6uRv68rnCkh+KeUm6A7+6dDo/9l/Zh2Hu1+HVWw5kEH/xmO170v9Xef7efxzxv BeQ644kvErDNG26LJDUtOqaKTdz9KKZXngw+2cAV/4Kc7C9xdT29Ugm8oOK/ecqBliMhBUen WphsEDjIbKJCd40RJLKb+v49EN/IJogNDd81vtehOxDw5Lus4zGCA+0wggPpAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZIm iZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0 ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+JwAAAAFWdjANBglghkgBZQMEAgEFAKCC AikwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMjE5MTM1 NjAzWjAvBgkqhkiG9w0BCQQxIgQgMq9eIBjdB5VVQYtlWY1eKU8S/ilaRARhmy75+Vf0xjIw bAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZIm iZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRl bCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+ JwAAAAFWdjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQK Ew5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3Vi IENBAgphYf4nAAAAAVZ2MA0GCSqGSIb3DQEBAQUABIIBAAbjnxfBz+LlV1sUidT45knqoypJ rgxmbCvgIUjfL09vsmAVmROEpOwqdIRLohVWpQvunpPVs0RqEkxQ3MEIomg2WPbvTcSfi3og SCaWUYX1T7hNKOpyT7rjGe9wP0fx6tzPSQ/jU1DiD5+RcNU7x8xkJBbFzyfyR6F6hBVd3zxN Kn7d3/QTNmhd38vykmow8mBH22B4HX8U8hgisQlaU87l/0bxHlffmxrziALIt6to/bA2P+Pm YnXvNr6LIUTkZAElGN7ZUWb9CO7N3XU4DcLYjr2rgEUfqqAnGRghf0uAzsxAhXmKCoHno4F/ 6EcOvglDzkffCYPgD4cP22On9M4AAAAAAAA= --------------ms030608050406070804040204-- From nobody Fri Feb 19 07:35: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 2A1161B31EC; Fri, 19 Feb 2016 07:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 HL5lmz-mfCBL; Fri, 19 Feb 2016 07:35:11 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AD81B31D7; Fri, 19 Feb 2016 07:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1989; q=dns/txt; s=iport; t=1455896111; x=1457105711; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tf9d8iLMfdu33gDv7G75RrAZzSz/YPJFQV+lFG7wyW8=; b=GYZPVVLWfamxNiN4qgD/5QADqN3tN9oxam3MndfgG5F9ndz2RQzjgkYw DFzzFRTcXgEpwemsb1OhzEJscBi2eoQFtKmdeGC4wFtMDCvYmnZjQcX2K aAvZOWYbw8c2nIFfd8MOLnKZUynAPhzCpxX8Yjshnu5vHTFb6CQuQY+qA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgCiNcdW/4sNJK1egzpSbQa6PwENg?= =?us-ascii?q?WgXCoUiRQECAQECgVQ4FAEBAQEBAQFkJ4RCAQEEAQEBawsQAgEIRicLJQIEAQ0?= =?us-ascii?q?FiBoOu3gBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIpNiG8FjWKJJQGNXYFchEOHO?= =?us-ascii?q?oEajkcBHgEBQoNkagGHPn0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,471,1449532800"; d="scan'208";a="239478734" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2016 15:35:10 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1JFZAhe002919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 15:35:10 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 19 Feb 2016 09:35:09 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Fri, 19 Feb 2016 09:35:09 -0600 From: "Charles Eckel (eckelcu)" To: mmusic , "draft-ietf-mmusic-dtls-sdp@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJdl8Jv9AbyFUKy2Bc+d5nItJ80Cy6A Date: Fri, 19 Feb 2016 15:35:09 +0000 Message-ID: References: <56B4CDCF.4080100@cisco.com> In-Reply-To: <56B4CDCF.4080100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.99.198] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Flemming Andreasen \(fandreas\)" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:35:13 -0000 I reviewed the draft and have some minor comments. 1) Section 1, the second paragraph is redundant and can be removed. It is well stated with additional content in the paragraph that immediately follows. 2) Section 3.1 s/following to the procedures/following the procedures 3) Section 3.2 and 3.3 OLD: "the endpoint MUST either change its DTLS role, its fingerprint value and/or use=B2 NEW: "the endpoint MUST change its DTLS role, change its fingerprint value, and/or use"=20 4) Section 5.1 OLD: "e.g. regarding usage of usage specific SDP attributes etc=B2 NEW: =B3e.g. regarding usage of specific SDP attributes=B2 5) Section 5.1 s/and needs/and need s/or whether a previous/or a previous 6) Section 5.1 OLD: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] when negotiating a DTLS association.=B2 NEW: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] within the same =B3m=3D=B3 line in which they are negotiating a DTLS association.=B2 7) Section 5.3 s/receives and offer/receives an offer s/towards the the offerer/towards the offerer 8) Section 11 IANA considerations to be updated as Paul already noted. Cheers, Charles On 2/5/16, 8:29 AM, "mmusic on behalf of Flemming Andreasen (fandreas)" wrote: >Greetings MMUSIC > >This is to announce a 2 week WGLC on the draft: > > https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-06.txt > >as Proposed Standard. Please review and provide any comments you may >have on the document by Friday, February 19, 2016. Comments should be >sent to the document authors and the MMUSIC WG list. If you review the >document but do not have any comments, please send a note to that effect >as well. > >Thanks > >-- Flemming (MMUSIC co-chair) > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Feb 19 08:03:23 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 964841B2DF6 for ; Fri, 19 Feb 2016 08:03:21 -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 FLhBh6CoRjB7 for ; Fri, 19 Feb 2016 08:03:19 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD091B2A0C for ; Fri, 19 Feb 2016 08:03:11 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-08v.sys.comcast.net with comcast id LG2g1s0032Bo0NV01G3Aa9; Fri, 19 Feb 2016 16:03:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id LG3A1s0013KdFy101G3A1d; Fri, 19 Feb 2016 16:03:10 +0000 To: Christer Holmberg , "mmusic@ietf.org" , Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56C73CBD.5070407@alum.mit.edu> Date: Fri, 19 Feb 2016 11:03:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455897790; bh=ACpLDJ0KtjEoc3TKRXolcCVjnu54BxptwnDDjCoiazk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=sR749tdflWtdg6fJuW4KxpLVL+7rCO+70w+ssMgeTw3rCXylsQBaFgboR2QpnrTLQ lTuYlpK5uS2dPtdZz1Gwnj9obPh87KMv3CKG2RLSKadD0fA7vBhCaI4Wm70Uil++6Q Z6M+XYszaezOZCmCQbJ0v5sVTi77Cg1l8cPExiFSQ76ZQinYViFA1y1/zmsEExO8tG aX5fu14Yke7/BFgbDUzycfRFCws01RI0z2k3BNz9g9sZfGOD7xFPsV0Wc55lmkfvyH K0ed8toKisMKONGsJbLg66AZb25K8mi/L6+e8TlOpo/mluZ5OFbW9z49Np+TBqSadR O74m38VCvVt/A== Archived-At: Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 19 Feb 2016 16:03:21 -0000 WFM On 2/18/16 1:56 PM, Christer Holmberg wrote: > Hi Paul, > >>> Ok, so assuming the scope of this change would only be ICE, we could >>> say that shared ICE candidates don’t have to be associated with each >>> m- line within a BUNDLE group – it’s enough if they are associated with one m- line. >> >> I haven't been following this discussion closely, so forgive me if I have misunderstood... > > Don't worry - there hasn't been much discussion :) > >> I see how it might be inconvenient to redundantly provide all the candidates with each m-line. But at the least >> this exception will need very careful specification, or else it could lead to very confusing implementations. > > Correct, and that's one reason I suggest that we limit the scope to ICE, eventhough we probably could do the same thing for any IDENTICAL and TRANSPORT category attribute. > >> (For instance, different subsets of the candidates associated with different m-lines.) > > Note that we are talking about m- lines within a given BUNDLE group, where the same set of shared candidates apply to each m- line. There will be no subset. > >> So if this is to be done, I think it should be quite restrictive. >> Perhaps either duplicate candidates with every m-line or else all the candidates with only one m-line, and no candidates with any of the other m-lines in the bundle. > > We could e.g. say that shared candidates MUST be placed in the m- line representing the BUNDLE address (first mid in the mid list). Then we can either forbid them to be placed elsewhere, or say that they can be discarded if placed elsewhere. > > (Unique candidates must obviously always be explicitly placed in the m- line they belong to.) > >> If in all m-lines of the offer then also in all accepted m-lines in the answer. If in only one m-line in the offer, then only in the corresponding m-line of the answer. >> >> Even then, what is to be done if the candidates are with only one of the m-lines in the offer, and the answerer wants to reject *that* m-line but >> accept others in the bundle? Does the answerer pick a different m-line to carry the candidates in the answer? > > Mandating the candidates in the m- line representing the BUNDLE address would work, because that m- line always belongs to the BUNDLE group. > > Regards, > > Christer > > > >> Q1: Does this apply only to the SDP ‘candidate’ attribute, or also to >> other ICE-related SDP attributes? >> >> Q2: Is it a RECOMMENDED/SHOULD/MAY/MUST/MUST NOT? >> >> Now, if I don’t hear any feedback on this, I am NOT going to do the >> change. Those who asked for this change (or otherwise have an opinion >> on it), please speak up now. >> >> Regards, >> >> Christer >> >> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer >> Holmberg >> *Sent:* 16. helmikuuta 2016 17:15 >> *To:* Peter Thatcher >> *Cc:* mmusic@ietf.org >> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE >> >> Hi, >> >> We still need to conclude this issue before we can ship BUNDLE, so I’d >> like to hear some input from people. I do intend to request agenda >> time to discuss it in Buenos Aires, but if we can find a solution >> before that there will be more time for cookies… >> >> Regards, >> >> Christer >> >> *From:*Peter Thatcher [mailto:pthatcher@google.com] >> *Sent:* 17. marraskuuta 2015 1:06 >> *To:* Christer Holmberg >> *Cc:* mmusic@ietf.org >> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE >> >> On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg >> > > >> wrote: >> >> Hi, >> >> >> I thinking mandating the candidates be duplicated in the answer >> has three issues: >> >> >> >> 1. It conflicts with trickle ICE. >> >> 2. It's slightly more complex to implement (we have to go add >> extra logic to go duplicate these things) >> 3. It's a complete >> waste of time/space/effort. The recipient of these duplicate >> candidates is never going to anything with them. >> > >> > Those are all fair points. I wish we'd had more implementation >> input when we write our specs. >> > >> > That's what I'm providing now :). We can still change the spec, >> can't we? >> ​ >> Sure. >> >> However, as we are talking about a design wise big (in my opinion) >> change, at a late stage, I'd like to hear what other people think. >> >> ​That sounds fair. I'd like to hear what others think about this.​ >> >> ​ >> >> >> >>>Also keep in mind that, when a subsequent offer is sent, the >> bundle-only attribute is no longer used. >> >> >> ​>>Can you point out where in the draft it says that? I tried >> finding it and I had a difficult time seeing where bundle-only >> wasn't allowed in a reoffer.​ >> ​>> >> >> Section 8.5.1 says: >> >> >> >> "When an offerer generates a subsequent offer, it MUST >> assign the >> >> previously selected offerer BUNDLE address [Section >> 8.3.2], to each >> >> bundled "m=" line (including any bundle-only "m=" line), >> except if:" >> >> >> >> And, as the usage of the attribute is only defined when the port >> value is zero, it would not work when the BUNDLE address (read: >> non-zero port) must be associated with the m- line. >> >> >> >> Section 6 says: >> >> >> >> "The usage of the 'bundle-only' attribute is only defined for a >> >> bundled "m=" line with a zero port value, within an offer. Other >> >> usage is unspecified." >> > >> ​> Thanks. That text would be more clear as "with an initial offer" >> instead of "whithin an offer", since that's what it really means in >> conjuction with 8.5.1. >> >> Ok. >> >> > However, that's precisely the text that I think we could change. >> I think we could change the bundle-only attribute to >> > be allowed in answers and in subsequent offers. Then clients >> could use the attribute as a way of avoiding duplication >> > of candidates and the complications with trickle ICE.​ >> >> Assuming we would remove the duplication of candidates, I don't >> think that would require us to change a semantics of the attribute. >> We could simply say that the candidates don't need to be duplicated >> in bundled m- lines, no matter if those m- lines are bundle-only or not. >> >> That would work as well. >> >> ​ >> >> >> >>>> Would you then also in the subsequent offer only assign >> possible candidates to only one m- line within the bundle group? >> >>> >> ​>>> That sounds logical to me. They aren't included in the first >> offer. Why add them to subsequent offers? It's inconsistent, and a >> waste. >> >> >> >> Then someone could ask: what about other (non-candidate) >> attributes that must have identical values for each bundled m- line? >> Should those also be assigned to only one of the m- lines? >> > >> ​> If it's something unique to the bundle group, and not the m-line, >> that seems reasonable to me. ​ >> ​> >> ​> But candidates are more painful than those would be because of >> the interactions with trickle ICE. If it weren't for trickle ICE >> this wouldn't be as big of a deal.​ >> >> Correct. We just need to make it very clear whether it applies only >> to candidate attributes, or to attributes with identical values in >> general. >> >> >>>>>>>> 2. If the answerer does not include any candidates in the >> answer and instead trickles them later, should it trickle them >> >>>>>>>> N times (once for each m-line in the BUNDLE group) or >1 >> time? 1 time seems much more reasonable than N times, but >> >>>>>>>> if we duplicate candidates in the answer, but not >> duplicate them while trickling, that's a bit inconsistent. Yet >> >another reason to not duplicate in the answer :). >> >>>>>>> >> >>>>>>> Assuming you use SDP to signal the trickled candidates, >> it’s true that you would duplicate them, >> >>>>>>> >> >>>>>>​What's the rationale for that? These duplicates provide no >> value, and in the case of many m-lines (such as a conferencing >> >>>>>>system with many participants), we could be talking about 30x >> the number of candidates being signaled. >> >>>> >> >>>> I hear what you are saying. >> >>>> >> >>>> But, if we would do a change, we also need to look at the full >> picture, and consider subsequent offers etc. >> >>> >> ​>>> I think a simple rule would be "if you know it's going to be >> bundled onto another m-line, don't include >> >>> candidates". That would go for bundle-only m-lines in an >> offer, bundled m-lines in an answer, and bundled m-lines in a re-offer.​ >> ​>>> >> >> Bundled m- lines in a re-offer can still be rejected by the >> answerer. >> > >> ​> That sounds the same as an initial offer. How does it imply that >> a re-offer must duplicate >> > candidates across m-lines, even when an initial offer doesn't >> need to?​ >> ​ >> In the initial offer each m- line contains candidates (unique). If >> an m- line in the offer is rejected, the answerer must select the >> offerer BUNDLE address (and the associated candidiates) from another >> m- line. >> >> Now, in a re-offer, if the m- line containing the candidates is >> rejected, the answerer needs to include its candidates in another m- >> line in the answer. That's doable, but it would need to be clearly >> documented. In other words: it needs to be clear that the candidates >> can occur in ANY of the bundled m- lines, and that m- line may >> change between offers and answers. >> >> ​So a rule of "the candidates can be in any one of the m-lines, and it >> doesn't matter which, and it can change any time". That seems >> reasonable to me. It leave the most flexibility to the one writing >> the SDP, and it's very easy to implement for the one reading the SDP.​ >> >> >> 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 Fri Feb 19 08:42: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 8CBD61ACE0E for ; Fri, 19 Feb 2016 08:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, 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 25HBXZPswPFs for ; Fri, 19 Feb 2016 08:42:22 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577611AC3F0 for ; Fri, 19 Feb 2016 08:42:22 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-08v.sys.comcast.net with comcast id LGhX1s00L26dK1R01GiMFH; Fri, 19 Feb 2016 16:42:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id LGiL1s00Q3KdFy101GiMiz; Fri, 19 Feb 2016 16:42:21 +0000 To: mmusic@ietf.org References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56C745EB.6060605@alum.mit.edu> Date: Fri, 19 Feb 2016 11:42:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C471D1.8010701@alcatel-lucent.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=1455900141; bh=2jKe3efIWgWl8pmuZO5TdsQvDHBGkqL7pG8ORcgHDzc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=l++9s2LUqGIbcOfGWSU+8bh2glU3fiFauDjFaAP/MalZ5v0Hbnd+FHCf3v6rcwdFT 8PM9oeYsfJSyu2BPuU23OKd9vLKrBoW6Q/LgkSlkUBh1l06E+Azqh9E4He0njRWk5a FVXNcgeMLMbjcLWsFEVaJNfms9tycrMYTY4ohggpy6Ep1KQLW6WJWGsuWakymDFGGA mIPcFban4UwLroSv2GUc3pUTGbMawvsWJ1dFCtCWoyQsGi1NzDZzmiXaGLeSw0u7nF /MUBOYkHos7+X19TOg0Arda7QgWxwgBhmrxFNKcqhX5YmLrwMVvtNz353M04LlN9Vw tVrR6rov+RpXg== 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, 19 Feb 2016 16:42:25 -0000 On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: > Hi Paul, Christian, Flemming, Bo, > > Have just submitted version 08 of draft-ietf-mmusic-data-channel-sdpneg. > The changes compared to version 07 are essentially as follows. > > * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) regarding the > relationship of subprotocols and their attributes. > * Two new SDP offer/answer considerations in section 5.2.5 (Various > SDP Offer/Answer Scenarios and Considerations) regarding unknown > subprotocol attributes or known subprotocol attributes, whose data > channel transport specific semantic is not known. > * A new paragraph in section 8.1 (IANA Considerations / Subprotocol > Identifiers) related to cases, where a subprotocol is defined for data > channel and Websocket transport. > > These changes should address the points discussed in this email thread. This is an improvement. But I think things could still be made clearer. Consider the following addition to 5.1.2.1: 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. A data channel specific usage of a subprotocol attribute is expected to be specified in the same document, which registers the subprotocol's identifier for data channel usage as described in Section 8.1. This text makes sense when there is a clear distinction between subprotocol and protocol. Unfortunately, the way SDP has evolved there is no such clear distinction in many cases, such as RTP over UDP or TCP, etc. Those are combined into a single protocol value. While that can usually be parsed apart at slashes, there isn't good terminology for it. My point is that when I read the above, I don't know how it applies to, say, RTP attributes. Or does it only apply for attributes that are clearly defined for a *sub*protocol? I think this is primarily that we lack well defined vocabulary for all of this. But I think it would be too much to expect this draft to *solve* the vocabulary problem. In lieu of doing so, maybe it would be sufficient to give some concrete examples, even if they have to be hypothetical ones. Thanks, Paul > Thank you, > Juergen > > > On 16.02.2016 14:01, Juergen Stoetzer-Bradler wrote: >> Paul, >> >> Thanks for further feedback. Fully agree now that the subprotocol >> parameter should stay optional. >> Will come back with with a proposal of how the sdpneg text could be >> enhanced as discussed. >> >> Thanks, >> Juergen >> >> On 15.02.2016 17:08, EXT Paul Kyzivat wrote: >>> On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: >>>> Paul, >>>> >>>> In your case 2) I would agree that the usage of dcsa embedded >>>> attributes >>>> seems questionable. After all, the dcsa attribute is defined in sdpneg >>>> as encapsulating a subprotocol specific attribute. If the subprotocol >>>> may dynamically change over time without further (SDP offer/answer) >>>> negotiation, then a negotiation of dcsa embedded attributes may indeed >>>> not be very helpful. >>>> >>>> In your case 1), I am wondering how would the SDP answerer know which >>>> subprotocol to use for which data channel, if the subprotocol id is not >>>> added to the data channel's dmap attribute (at least if multiple data >>>> channels are negotiated)? Conceivably via some provisioning, or via a >>>> mutual understanding of a certain subprotocol to SCTP stream id >>>> mapping, >>>> or via a certain a priori agreed label usage. I hadn't thought of such >>>> cases when raising the question if the subprotocol should actually be >>>> mandatory. >>> >>> IMO it could be any of those. But for this use case it seems more >>> likely that channels will be opened dynamically rather than via SDP. >>> >>> I think the provision for *not* specifying the subprotocol was >>> primarily to establish equivalence with what is possible via DCEP. >>> >>> One possibility is that SDP is used to specify how many channels are >>> opened, with the understanding that each of them will use the same >>> application-specific protocol. >>> >>> One possible use for dcsa with an unnamed protocol would be if the >>> intent is to use a proprietary variant of a standard protocol, where >>> there is still a desire to negotiate options using attributes >>> applicable to that standard base protocol. But I'm really stretching >>> to come up with this. >>> >>>> But such use cases would certainly go beyond a pure SDP offer/answer >>>> negotiation use case and I would argue that such use cases would >>>> also go >>>> beyond the scope of the sdpneg draft. >>> >>> Probably. >>> >>>> I could now imagine the sdpneg draft saying that an SDP offerer should >>>> add a subprotocol identifier to an offered data channel's dcmap >>>> attribute, if it also adds dcsa embedded subprotocol attributes. And >>>> that an implementation would be on its own, if it does not follow that >>>> recommendation (for whatever reasons). >>> >>> That could work. >>> >>>> Further, similar as for non-dcsa embedded attributes, we could >>>> explicitly add text to the sdpneg draft saying that a recipient of >>>> an an >>>> SDP offer or answer should ignore dcsa embedded attributes not only if >>>> they are completely unknown, but also if their semantics related to the >>>> subprotocol is not known. >>>> (The current draft says in sec 5.2.3 that the SDP answerer "/Parses and >>>> applies the SDP offer. Note that the typical parser normally ignores >>>> unknown SDP attributes, which includes data channel related >>>> attributes./" I think we could make this clearer and explicitly >>>> refer to >>>> dcsa embedded subprotocol attributes.) >>> >>> Yes, that would help. >>> >>> Thanks, >>> Paul >>> >>>> Thanks, >>>> Juergen >>>> >>>> On 12.02.2016 17:58, EXT Paul Kyzivat wrote: >>>>> Juergen, >>>>> >>>>> You bring up a point that perhaps needs further discussion: what does >>>>> it mean when the subprotocol is not specified? >>>>> >>>>> IIUC there are at least a couple of reasons this might come about: >>>>> >>>>> 1) The protocol to be used is not standardized. There is no globally >>>>> unique name for it. The two ends know what protocol to use based on >>>>> context. >>>>> >>>>> 2) The protocol to be used on the channel is not determined via SDP >>>>> negotiation. The applications want to establish the channel, and then >>>>> dynamically decide what protocol to use with it. (And that protocol >>>>> may change over time.) >>>>> >>>>> I guess that it still might be meaningful to use dcsa with (1), but >>>>> there would be no way to determine by examination of the SDP whether >>>>> the usage was compatible with the protocol. In this case the usage of >>>>> the attributes would be "off label" - being adapted to the proprietary >>>>> protocol in a way that hopefully the two ends agree. >>>>> >>>>> I don't see how dcsa makes much sense for (2). If you don't know what >>>>> protocol will be used then how do you know what attributes to use? >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>>>> Flemming, Paul, >>>>>> >>>>>> The current a=dcmap related text in >>>>>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>>>>> 'subprotocol' parameter must always be present - rather it is >>>>>> specified >>>>>> as an optional parameter. Thus, current sdpneg text would allow to >>>>>> create an SDP offer for a data channel, which contains one a=dcmap >>>>>> attribute and potentially multiple a=dcsa attributes without the >>>>>> subprotocol actually being given. Based on this discussion I am >>>>>> wondering if the subprotocol parameter should actually be mandatory. >>>>>> >>>>>> In the specific case of MSRP, the msrp-usage-data-channel draft >>>>>> says in >>>>>> 5.1.1.1 that the dcmap attribute includes the label and subprotocol >>>>>> parameters. The current text could possible be made more explicit by >>>>>> saying that the 'subprotocol="MSRP"' parameter must always be >>>>>> present. >>>>>> Have just submitted version 04 of the msrp-usage-data-channel draft, >>>>>> which proposes to add subprotocol identifier "MSRP" to the WebSocket >>>>>> Subprotocol Name registry. This registry would then associate >>>>>> subprotocol id "MSRP" with the msrp-usage-data-channel document. >>>>>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa >>>>>> attribute are specified. And there the MSRP specific SDP attributes, >>>>>> which can be dcsa embedded, are described. >>>>>> 'setup' is an attribute, whose semantic changes when being dcsa >>>>>> embedded >>>>>> and associated with subprotocol MSRP, as compared to the meaning >>>>>> of an >>>>>> "a=setup" media level attribute of a TCP/MSRP m-line. Hence these >>>>>> semantical differences are explicitly addressed in the >>>>>> msrp-usage-data-channel draft. >>>>>> >>>>>> Regarding sdpneg, I also think that the current text in sdpneg >>>>>> seems to >>>>>> be sufficient regarding the usage of dcsa encapsulated SDP >>>>>> attributes as >>>>>> being bound to the data channel's subprotocol. But as the >>>>>> semantic of a >>>>>> dcsa encapsulated attribute may be subprotocol specific (like >>>>>> 'setup'), >>>>>> I'd now tend to consider the subprotocol parameter in the dcmap >>>>>> attribute as being mandatory, as mentioned above. As already >>>>>> discussed, >>>>>> the Websocket subprotocol registry would then refer to the document, >>>>>> which specifies the subprotocol specific usage of dcsa encapsulated >>>>>> parameters. >>>>>> >>>>>> Thanks, >>>>>> Juergen >>>>>> >>>>>> >>>>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>>>> >>>>>>> >>>>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and >>>>>>>>>>> specific >>>>>>>>>>> drafts are used to describe protocols that use the mechanism >>>>>>>>>>> (i.e. >>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>>>> >>>>>>>>>> It remains to be seen if that will be enough. E.g., there >>>>>>>>>> currently >>>>>>>>>> aren't any iana considerations in >>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>>>> >>>>>>>>>> Suppose I encounter some sdp that uses msrp over a data >>>>>>>>>> channel, but >>>>>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>>>>> reference to >>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that >>>>>>>>>> usage? >>>>>>>>>> >>>>>>>>>> I would like to think that the iana registries will allow me to >>>>>>>>>> trace >>>>>>>>>> back to the relevant specs. >>>>>>>>>> >>>>>>>>> No disagreement on that part, however having taken another look at >>>>>>>>> both >>>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>>>>>>> original request for all (existing and new) attributes to >>>>>>>>> specify how >>>>>>>>> they may or may not be used with the dcsa attribute defined by >>>>>>>>> sdpneg. >>>>>>>>> >>>>>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>>>>> individual >>>>>>>>> documents (like msrp-usage), which calls your the parameters that >>>>>>>>> are at >>>>>>>>> least needed to be supported for that usage. Taking MSRP as an >>>>>>>>> example, >>>>>>>>> why isn't that enough, and how do you see the resulting set of >>>>>>>>> attributes that may or may not be used with MSRP differ between >>>>>>>>> use >>>>>>>>> in a >>>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular >>>>>>>>> media >>>>>>>>> stream ? >>>>>>>> >>>>>>>> Based on this discussion, I conclude that it should be >>>>>>>> sufficient for >>>>>>>> this draft to say that before an attribute can be used with dcsa, >>>>>>>> such usage must be defined somewhere. This could be either: >>>>>>>> - as part of the definition of the attribute, OR >>>>>>>> - as part of the definition of the protocol referenced on the >>>>>>>> m-line. >>>>>>>> >>>>>>> We are getting closer, but it's still not obvious to me that you >>>>>>> cannot use an attribute with dcsa if it has not been explicitly >>>>>>> defined for the attribute in question. Clearly, there are attributes >>>>>>> that wouldn't make sense over data channels, just like there are >>>>>>> attributes that don't make sense over particular media descriptions. >>>>>>> >>>>>>> Again, I'd like to hear from more people on this, including the >>>>>>> authors. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Also, it would be good to hear from more people on this, including >>>>>>>>> the >>>>>>>>> document authors. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- Flemming >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>>> Regards, Christian >>>>>>>>>>> >>>>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>>>>>>> need to >>>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it >>>>>>>>>>>>> should be >>>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>>>>>>> point is >>>>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>>>> interactions as >>>>>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>>>>> (plus the >>>>>>>>>>>>> offerer being responsible for generating a valid offer if he >>>>>>>>>>>>> wants to >>>>>>>>>>>>> establish a data channel). >>>>>>>>>>>> >>>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>>>>> pertains to >>>>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Paul >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 Fri Feb 19 09:03: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 5D2DC1B32C5 for ; Fri, 19 Feb 2016 09:03:16 -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 lvRVeR12gQ6q for ; Fri, 19 Feb 2016 09:03:10 -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 145DC1B32B8 for ; Fri, 19 Feb 2016 09:03:09 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-5d-56c74accc85f Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FE.B3.02707.CCA47C65; Fri, 19 Feb 2016 18:03:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 18:03:07 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" , Peter Thatcher Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75iggAA8gYCAADDekIABVv+AgAAhj0A= Date: Fri, 19 Feb 2016 17:03:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E0B695@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <56C73CBD.5070407@alum.mit.edu> In-Reply-To: <56C73CBD.5070407@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbFdV/eM1/Ewg4U3hCymLn/MYrFiwwFW i2vLX7M6MHv8ff+ByWPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBlvOnqYC9YUFGxa3s7awPj lNIuRg4OCQETic5vYV2MnECmmMSFe+vZuhi5OIQEDjNKTD73jhXCWcwosebeGWaQBjYBC4nu f9ogDSICZRL3XyxnBLGFBRwk9jzZyg4Rd5SYs+Ic2CARgS5GiSMbNrOA9LIIqEoc+Z4JUsMr 4Cuxe98/sF4hgR52id6/OiAlnAI6EiunOIOEGYHu+X5qDROIzSwgLnHryXwmiDsFJJbsOc8M YYtKvHz8jxXCVpJoXPKEFWQMs4CmxPpd+hCtihJTuh+yQ2wVlDg58wnLBEbRWUimzkLomIWk YxaSjgWMLKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAiPm4JbfBjsYXz53PMQowMGoxMP7 wedYmBBrYllxZe4hRgkOZiUR3vdGx8OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8652Xh8mJJCe WJKanZpakFoEk2Xi4JRqYNwRf/fg2QMNRUF2EwU/n78du9nseuiDZ6c/iJgypPznm5bpMO1Q GcOdrJ2Fb639vkyZP6/C782Ot3KCX12v3YxinfjN3GLSGyf7jJNTcjYtDtN51qKaP3Hf4u+q AZoLo6Znn+TwFvFRaz3HMqNuacROq1szCxhsnp2qmd3IeGKCAm/GvA3qlxSVWIozEg21mIuK EwHWCuJ5lAIAAA== Archived-At: Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 19 Feb 2016 17:03:16 -0000 UGV0ZXI/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQg W21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdIA0KU2VudDogMTkgRmVicnVhcnkgMjAxNiAx ODowMw0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+OyBtbXVzaWNAaWV0Zi5vcmc7IFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNv bT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQgSUNFIGNhbmRpZGF0ZXMg d2l0aCBCVU5ETEUNCg0KV0ZNDQoNCk9uIDIvMTgvMTYgMTo1NiBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgd3JvdGU6DQo+IEhpIFBhdWwsDQo+DQo+Pj4gT2ssIHNvIGFzc3VtaW5nIHRoZSBzY29wZSBv ZiB0aGlzIGNoYW5nZSB3b3VsZCBvbmx5IGJlIElDRSwgd2UgY291bGQgDQo+Pj4gc2F5IHRoYXQg c2hhcmVkIElDRSBjYW5kaWRhdGVzIGRvbuKAmXQgaGF2ZSB0byBiZSBhc3NvY2lhdGVkIHdpdGgg ZWFjaA0KPj4+IG0tIGxpbmUgd2l0aGluIGEgQlVORExFIGdyb3VwIOKAkyBpdOKAmXMgZW5vdWdo IGlmIHRoZXkgYXJlIGFzc29jaWF0ZWQgd2l0aCBvbmUgbS0gbGluZS4NCj4+DQo+PiBJIGhhdmVu J3QgYmVlbiBmb2xsb3dpbmcgdGhpcyBkaXNjdXNzaW9uIGNsb3NlbHksIHNvIGZvcmdpdmUgbWUg aWYgSSBoYXZlIG1pc3VuZGVyc3Rvb2QuLi4NCj4NCj4gRG9uJ3Qgd29ycnkgLSB0aGVyZSBoYXNu J3QgYmVlbiBtdWNoIGRpc2N1c3Npb24gOikNCj4NCj4+IEkgc2VlIGhvdyBpdCBtaWdodCBiZSBp bmNvbnZlbmllbnQgdG8gcmVkdW5kYW50bHkgcHJvdmlkZSBhbGwgdGhlIA0KPj4gY2FuZGlkYXRl cyB3aXRoIGVhY2ggbS1saW5lLiBCdXQgYXQgdGhlIGxlYXN0IHRoaXMgZXhjZXB0aW9uIHdpbGwg bmVlZCB2ZXJ5IGNhcmVmdWwgc3BlY2lmaWNhdGlvbiwgb3IgZWxzZSBpdCBjb3VsZCBsZWFkIHRv IHZlcnkgY29uZnVzaW5nIGltcGxlbWVudGF0aW9ucy4NCj4NCj4gQ29ycmVjdCwgYW5kIHRoYXQn cyBvbmUgcmVhc29uIEkgc3VnZ2VzdCB0aGF0IHdlIGxpbWl0IHRoZSBzY29wZSB0byBJQ0UsIGV2 ZW50aG91Z2ggd2UgcHJvYmFibHkgY291bGQgZG8gdGhlIHNhbWUgdGhpbmcgZm9yIGFueSBJREVO VElDQUwgYW5kIFRSQU5TUE9SVCBjYXRlZ29yeSBhdHRyaWJ1dGUuDQo+DQo+PiAoRm9yIGluc3Rh bmNlLCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0aGUgY2FuZGlkYXRlcyBhc3NvY2lhdGVkIHdpdGgg DQo+PiBkaWZmZXJlbnQgbS1saW5lcy4pDQo+DQo+IE5vdGUgdGhhdCB3ZSBhcmUgdGFsa2luZyBh Ym91dCBtLSBsaW5lcyB3aXRoaW4gYSBnaXZlbiBCVU5ETEUgZ3JvdXAsIHdoZXJlIHRoZSBzYW1l IHNldCBvZiBzaGFyZWQgY2FuZGlkYXRlcyBhcHBseSB0byBlYWNoIG0tIGxpbmUuIFRoZXJlIHdp bGwgYmUgbm8gc3Vic2V0Lg0KPg0KPj4gU28gaWYgdGhpcyBpcyB0byBiZSBkb25lLCBJIHRoaW5r IGl0IHNob3VsZCBiZSBxdWl0ZSByZXN0cmljdGl2ZS4NCj4+IFBlcmhhcHMgZWl0aGVyIGR1cGxp Y2F0ZSBjYW5kaWRhdGVzIHdpdGggZXZlcnkgbS1saW5lIG9yIGVsc2UgYWxsIHRoZSBjYW5kaWRh dGVzIHdpdGggb25seSBvbmUgbS1saW5lLCBhbmQgbm8gY2FuZGlkYXRlcyB3aXRoIGFueSBvZiB0 aGUgb3RoZXIgbS1saW5lcyBpbiB0aGUgYnVuZGxlLg0KPg0KPiBXZSBjb3VsZCBlLmcuIHNheSB0 aGF0IHNoYXJlZCBjYW5kaWRhdGVzIE1VU1QgYmUgcGxhY2VkIGluIHRoZSBtLSBsaW5lIHJlcHJl c2VudGluZyB0aGUgQlVORExFIGFkZHJlc3MgKGZpcnN0IG1pZCBpbiB0aGUgbWlkIGxpc3QpLiBU aGVuIHdlIGNhbiBlaXRoZXIgZm9yYmlkIHRoZW0gdG8gYmUgcGxhY2VkIGVsc2V3aGVyZSwgb3Ig c2F5IHRoYXQgdGhleSBjYW4gYmUgZGlzY2FyZGVkIGlmIHBsYWNlZCBlbHNld2hlcmUuDQo+DQo+ IChVbmlxdWUgY2FuZGlkYXRlcyBtdXN0IG9idmlvdXNseSBhbHdheXMgYmUgZXhwbGljaXRseSBw bGFjZWQgaW4gdGhlIA0KPiBtLSBsaW5lIHRoZXkgYmVsb25nIHRvLikNCj4NCj4+IElmIGluIGFs bCBtLWxpbmVzIG9mIHRoZSBvZmZlciB0aGVuIGFsc28gaW4gYWxsIGFjY2VwdGVkIG0tbGluZXMg aW4gdGhlIGFuc3dlci4gSWYgaW4gb25seSBvbmUgbS1saW5lIGluIHRoZSBvZmZlciwgdGhlbiBv bmx5IGluIHRoZSBjb3JyZXNwb25kaW5nIG0tbGluZSBvZiB0aGUgYW5zd2VyLg0KPj4NCj4+IEV2 ZW4gdGhlbiwgd2hhdCBpcyB0byBiZSBkb25lIGlmIHRoZSBjYW5kaWRhdGVzIGFyZSB3aXRoIG9u bHkgb25lIG9mIA0KPj4gdGhlIG0tbGluZXMgaW4gdGhlIG9mZmVyLCBhbmQgdGhlIGFuc3dlcmVy IHdhbnRzIHRvIHJlamVjdCAqdGhhdCogbS1saW5lIGJ1dCBhY2NlcHQgb3RoZXJzIGluIHRoZSBi dW5kbGU/IERvZXMgdGhlIGFuc3dlcmVyIHBpY2sgYSBkaWZmZXJlbnQgbS1saW5lIHRvIGNhcnJ5 IHRoZSBjYW5kaWRhdGVzIGluIHRoZSBhbnN3ZXI/DQo+DQo+IE1hbmRhdGluZyB0aGUgY2FuZGlk YXRlcyBpbiB0aGUgbS0gbGluZSByZXByZXNlbnRpbmcgdGhlIEJVTkRMRSBhZGRyZXNzIHdvdWxk IHdvcmssIGJlY2F1c2UgdGhhdCBtLSBsaW5lIGFsd2F5cyBiZWxvbmdzIHRvIHRoZSBCVU5ETEUg Z3JvdXAuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+IAkNCj4NCj4+IFExOiBE b2VzIHRoaXMgYXBwbHkgb25seSB0byB0aGUgU0RQIOKAmGNhbmRpZGF0ZeKAmSBhdHRyaWJ1dGUs IG9yIGFsc28gdG8gDQo+PiBvdGhlciBJQ0UtcmVsYXRlZCBTRFAgYXR0cmlidXRlcz8NCj4+DQo+ PiBRMjogSXMgaXQgYSBSRUNPTU1FTkRFRC9TSE9VTEQvTUFZL01VU1QvTVVTVCBOT1Q/DQo+Pg0K Pj4gTm93LCBpZiBJIGRvbuKAmXQgaGVhciBhbnkgZmVlZGJhY2sgb24gdGhpcywgSSBhbSBOT1Qg Z29pbmcgdG8gZG8gdGhlIA0KPj4gY2hhbmdlLiBUaG9zZSB3aG8gYXNrZWQgZm9yIHRoaXMgY2hh bmdlIChvciBvdGhlcndpc2UgaGF2ZSBhbiBvcGluaW9uIA0KPj4gb24gaXQpLCBwbGVhc2Ugc3Bl YWsgdXAgbm93Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+PiAqRnJv bToqbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2Yg DQo+PiAqQ2hyaXN0ZXIgSG9sbWJlcmcNCj4+ICpTZW50OiogMTYuIGhlbG1pa3V1dGEgMjAxNiAx NzoxNQ0KPj4gKlRvOiogUGV0ZXIgVGhhdGNoZXINCj4+ICpDYzoqIG1tdXNpY0BpZXRmLm9yZw0K Pj4gKlN1YmplY3Q6KiBSZTogW01NVVNJQ10gUXVlc3Rpb25zIGFib3V0IElDRSBjYW5kaWRhdGVz IHdpdGggQlVORExFDQo+Pg0KPj4gSGksDQo+Pg0KPj4gV2Ugc3RpbGwgbmVlZCB0byBjb25jbHVk ZSB0aGlzIGlzc3VlIGJlZm9yZSB3ZSBjYW4gc2hpcCBCVU5ETEUsIHNvIA0KPj4gSeKAmWQgbGlr ZSB0byBoZWFyIHNvbWUgaW5wdXQgZnJvbSBwZW9wbGUuIEkgZG8gaW50ZW5kIHRvIHJlcXVlc3Qg DQo+PiBhZ2VuZGEgdGltZSB0byBkaXNjdXNzIGl0IGluIEJ1ZW5vcyBBaXJlcywgYnV0IGlmIHdl IGNhbiBmaW5kIGEgDQo+PiBzb2x1dGlvbiBiZWZvcmUgdGhhdCB0aGVyZSB3aWxsIGJlIG1vcmUg dGltZSBmb3IgY29va2llc+KApg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+ DQo+PiAqRnJvbToqUGV0ZXIgVGhhdGNoZXIgW21haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbV0N Cj4+ICpTZW50OiogMTcuIG1hcnJhc2t1dXRhIDIwMTUgMTowNg0KPj4gKlRvOiogQ2hyaXN0ZXIg SG9sbWJlcmcNCj4+ICpDYzoqIG1tdXNpY0BpZXRmLm9yZyA8bWFpbHRvOm1tdXNpY0BpZXRmLm9y Zz4NCj4+ICpTdWJqZWN0OiogUmU6IFtNTVVTSUNdIFF1ZXN0aW9ucyBhYm91dCBJQ0UgY2FuZGlk YXRlcyB3aXRoIEJVTkRMRQ0KPj4NCj4+IE9uIE1vbiwgTm92IDE2LCAyMDE1IGF0IDI6NTggUE0s IENocmlzdGVyIEhvbG1iZXJnIA0KPj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSAN Cj4+IDxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCj4+IHdyb3RlOg0K Pj4NCj4+IEhpLA0KPj4NCj4+ICAgPj4gSSB0aGlua2luZyBtYW5kYXRpbmcgdGhlIGNhbmRpZGF0 ZXMgYmUgZHVwbGljYXRlZCBpbiB0aGUgYW5zd2VyIA0KPj4gaGFzIHRocmVlIGlzc3VlczoNCj4+ ICAgPj4NCj4+ICAgPj4gMS4gIEl0IGNvbmZsaWN0cyB3aXRoIHRyaWNrbGUgSUNFLg0KPj4gICA+ PiAyLiAgSXQncyBzbGlnaHRseSBtb3JlIGNvbXBsZXggdG8gaW1wbGVtZW50ICh3ZSBoYXZlIHRv IGdvIGFkZCANCj4+IGV4dHJhIGxvZ2ljIHRvIGdvIGR1cGxpY2F0ZSB0aGVzZSB0aGluZ3MpICA+ PiAzLiAgSXQncyBhIGNvbXBsZXRlIA0KPj4gd2FzdGUgb2YgdGltZS9zcGFjZS9lZmZvcnQuICBU aGUgcmVjaXBpZW50IG9mIHRoZXNlIGR1cGxpY2F0ZSANCj4+IGNhbmRpZGF0ZXMgaXMgbmV2ZXIg Z29pbmcgdG8gYW55dGhpbmcgd2l0aCB0aGVtLg0KPj4gICA+DQo+PiAgID4gVGhvc2UgYXJlIGFs bCBmYWlyIHBvaW50cy4gSSB3aXNoIHdlJ2QgaGFkIG1vcmUgaW1wbGVtZW50YXRpb24gDQo+PiBp bnB1dCB3aGVuIHdlIHdyaXRlIG91ciBzcGVjcy4NCj4+ICAgPg0KPj4gICA+IFRoYXQncyB3aGF0 IEknbSBwcm92aWRpbmcgbm93IDopLiAgV2UgY2FuIHN0aWxsIGNoYW5nZSB0aGUgc3BlYywgDQo+ PiBjYW4ndCB3ZT8NCj4+IOKAiw0KPj4gU3VyZS4NCj4+DQo+PiBIb3dldmVyLCBhcyB3ZSBhcmUg dGFsa2luZyBhYm91dCBhIGRlc2lnbiB3aXNlIGJpZyAoaW4gbXkgb3BpbmlvbikgDQo+PiBjaGFu Z2UsIGF0IGEgbGF0ZSBzdGFnZSwgSSdkIGxpa2UgdG8gaGVhciB3aGF0IG90aGVyIHBlb3BsZSB0 aGluay4NCj4+DQo+PiDigItUaGF0IHNvdW5kcyBmYWlyLiAgSSdkIGxpa2UgdG8gaGVhciB3aGF0 IG90aGVycyB0aGluayBhYm91dCB0aGlzLuKAiw0KPj4NCj4+IOKAiw0KPj4NCj4+DQo+PiAgICAg ICA+Pj5BbHNvIGtlZXAgaW4gbWluZCB0aGF0LCB3aGVuIGEgc3Vic2VxdWVudCBvZmZlciBpcyBz ZW50LCB0aGUNCj4+ICAgICAgYnVuZGxlLW9ubHkgYXR0cmlidXRlIGlzIG5vIGxvbmdlciB1c2Vk Lg0KPj4gICAgICAgPj4NCj4+ICAgICAg4oCLPj5DYW4geW91IHBvaW50IG91dCB3aGVyZSBpbiB0 aGUgZHJhZnQgaXQgc2F5cyB0aGF0PyAgSSB0cmllZA0KPj4gICAgICBmaW5kaW5nIGl0IGFuZCBJ IGhhZCBhIGRpZmZpY3VsdCB0aW1lIHNlZWluZyB3aGVyZSBidW5kbGUtb25seQ0KPj4gICAgICB3 YXNuJ3QgYWxsb3dlZCBpbiBhIHJlb2ZmZXIu4oCLDQo+PiAgICAgIOKAiz4+DQo+PiAgICAgICA+ PiBTZWN0aW9uIDguNS4xIHNheXM6DQo+PiAgICAgICA+Pg0KPj4gICAgICAgPj4gICAgICAgICJX aGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGEgc3Vic2VxdWVudCBvZmZlciwgaXQgTVVTVA0KPj4g ICAgICBhc3NpZ24gdGhlDQo+PiAgICAgICA+PiAgICAgICBwcmV2aW91c2x5IHNlbGVjdGVkIG9m ZmVyZXIgQlVORExFIGFkZHJlc3MgW1NlY3Rpb24NCj4+ICAgICAgOC4zLjJdLCB0byBlYWNoDQo+ PiAgICAgICA+PiAgICAgICBidW5kbGVkICJtPSIgbGluZSAoaW5jbHVkaW5nIGFueSBidW5kbGUt b25seSAibT0iIGxpbmUpLA0KPj4gICAgICBleGNlcHQgaWY6Ig0KPj4gICAgICAgPj4NCj4+ICAg ICAgID4+IEFuZCwgYXMgdGhlIHVzYWdlIG9mIHRoZSBhdHRyaWJ1dGUgaXMgb25seSBkZWZpbmVk IHdoZW4gdGhlIHBvcnQNCj4+ICAgICAgdmFsdWUgaXMgemVybywgaXQgd291bGQgbm90IHdvcmsg d2hlbiB0aGUgQlVORExFIGFkZHJlc3MgKHJlYWQ6DQo+PiAgICAgIG5vbi16ZXJvIHBvcnQpIG11 c3QgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5lLg0KPj4gICAgICAgPj4NCj4+ICAgICAg ID4+IFNlY3Rpb24gNiBzYXlzOg0KPj4gICAgICAgPj4NCj4+ICAgICAgID4+ICAgIlRoZSB1c2Fn ZSBvZiB0aGUgJ2J1bmRsZS1vbmx5JyBhdHRyaWJ1dGUgaXMgb25seSBkZWZpbmVkIGZvciBhDQo+ PiAgICAgICA+PiAgIGJ1bmRsZWQgIm09IiBsaW5lIHdpdGggYSB6ZXJvIHBvcnQgdmFsdWUsIHdp dGhpbiBhbiBvZmZlci4gIE90aGVyDQo+PiAgICAgICA+PiAgIHVzYWdlIGlzIHVuc3BlY2lmaWVk LiINCj4+ICAgICAgID4NCj4+ICAgICAg4oCLPiBUaGFua3MuICBUaGF0IHRleHQgd291bGQgYmUg bW9yZSBjbGVhciBhcyAid2l0aCBhbiBpbml0aWFsIG9mZmVyIg0KPj4gICAgICBpbnN0ZWFkIG9m ICJ3aGl0aGluIGFuIG9mZmVyIiwgc2luY2UgdGhhdCdzIHdoYXQgaXQgcmVhbGx5IG1lYW5zIGlu DQo+PiAgICAgIGNvbmp1Y3Rpb24gd2l0aCA4LjUuMS4NCj4+DQo+PiAgICAgIE9rLg0KPj4NCj4+ ICAgICAgID4gSG93ZXZlciwgdGhhdCdzIHByZWNpc2VseSB0aGUgdGV4dCB0aGF0IEkgdGhpbmsg d2UgY291bGQgY2hhbmdlLg0KPj4gICAgICBJIHRoaW5rIHdlIGNvdWxkIGNoYW5nZSB0aGUgYnVu ZGxlLW9ubHkgYXR0cmlidXRlIHRvDQo+PiAgICAgICA+IGJlIGFsbG93ZWQgaW4gYW5zd2VycyBh bmQgaW4gc3Vic2VxdWVudCBvZmZlcnMuICBUaGVuIGNsaWVudHMNCj4+ICAgICAgY291bGQgdXNl IHRoZSBhdHRyaWJ1dGUgYXMgYSB3YXkgb2YgYXZvaWRpbmcgZHVwbGljYXRpb24NCj4+ICAgICAg ID4gb2YgY2FuZGlkYXRlcyBhbmQgdGhlIGNvbXBsaWNhdGlvbnMgd2l0aCB0cmlja2xlIElDRS7i gIsNCj4+DQo+PiAgICAgIEFzc3VtaW5nIHdlIHdvdWxkIHJlbW92ZSB0aGUgZHVwbGljYXRpb24g b2YgY2FuZGlkYXRlcywgSSBkb24ndA0KPj4gICAgICB0aGluayB0aGF0IHdvdWxkIHJlcXVpcmUg dXMgdG8gY2hhbmdlIGEgc2VtYW50aWNzIG9mIHRoZSBhdHRyaWJ1dGUuDQo+PiAgICAgIFdlIGNv dWxkIHNpbXBseSBzYXkgdGhhdCB0aGUgY2FuZGlkYXRlcyBkb24ndCBuZWVkIHRvIGJlIGR1cGxp Y2F0ZWQNCj4+ICAgICAgaW4gYnVuZGxlZCBtLSBsaW5lcywgbm8gbWF0dGVyIGlmIHRob3NlIG0t IGxpbmVzIGFyZSBidW5kbGUtb25seSBvciBub3QuDQo+Pg0KPj4gVGhhdCB3b3VsZCB3b3JrIGFz IHdlbGwuDQo+Pg0KPj4g4oCLDQo+Pg0KPj4NCj4+ICAgICAgID4+Pj4gV291bGQgeW91IHRoZW4g YWxzbyBpbiB0aGUgc3Vic2VxdWVudCBvZmZlciBvbmx5IGFzc2lnbg0KPj4gICAgICBwb3NzaWJs ZSBjYW5kaWRhdGVzIHRvIG9ubHkgb25lIG0tIGxpbmUgd2l0aGluIHRoZSBidW5kbGUgZ3JvdXA/ DQo+PiAgICAgICA+Pj4NCj4+ICAgICAg4oCLPj4+IFRoYXQgc291bmRzIGxvZ2ljYWwgdG8gbWUu ICBUaGV5IGFyZW4ndCBpbmNsdWRlZCBpbiB0aGUgZmlyc3QNCj4+ICAgICAgb2ZmZXIuICBXaHkg YWRkIHRoZW0gdG8gc3Vic2VxdWVudCBvZmZlcnM/ICBJdCdzIGluY29uc2lzdGVudCwgYW5kIGEN Cj4+ICAgICAgd2FzdGUuDQo+PiAgICAgICA+Pg0KPj4gICAgICAgPj4gVGhlbiBzb21lb25lIGNv dWxkIGFzazogd2hhdCBhYm91dCBvdGhlciAobm9uLWNhbmRpZGF0ZSkNCj4+ICAgICAgYXR0cmli dXRlcyB0aGF0IG11c3QgaGF2ZSBpZGVudGljYWwgdmFsdWVzIGZvciBlYWNoIGJ1bmRsZWQgbS0g bGluZT8NCj4+ICAgICAgU2hvdWxkIHRob3NlIGFsc28gYmUgYXNzaWduZWQgdG8gb25seSBvbmUg b2YgdGhlIG0tIGxpbmVzPw0KPj4gICAgICAgPg0KPj4gICAgICDigIs+IElmIGl0J3Mgc29tZXRo aW5nIHVuaXF1ZSB0byB0aGUgYnVuZGxlIGdyb3VwLCBhbmQgbm90IHRoZSBtLWxpbmUsDQo+PiAg ICAgIHRoYXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZS4gIOKAiw0KPj4gICAgICDigIs+DQo+PiAg ICAgIOKAiz4gQnV0IGNhbmRpZGF0ZXMgYXJlIG1vcmUgcGFpbmZ1bCB0aGFuIHRob3NlIHdvdWxk IGJlIGJlY2F1c2Ugb2YNCj4+ICAgICAgdGhlIGludGVyYWN0aW9ucyB3aXRoIHRyaWNrbGUgSUNF LiAgSWYgaXQgd2VyZW4ndCBmb3IgdHJpY2tsZSBJQ0UNCj4+ICAgICAgdGhpcyB3b3VsZG4ndCBi ZSBhcyBiaWcgb2YgYSBkZWFsLuKAiw0KPj4NCj4+ICAgICAgQ29ycmVjdC4gV2UganVzdCBuZWVk IHRvIG1ha2UgaXQgdmVyeSBjbGVhciB3aGV0aGVyIGl0IGFwcGxpZXMgb25seQ0KPj4gICAgICB0 byBjYW5kaWRhdGUgYXR0cmlidXRlcywgb3IgdG8gYXR0cmlidXRlcyB3aXRoIGlkZW50aWNhbCB2 YWx1ZXMgaW4NCj4+ICAgICAgZ2VuZXJhbC4NCj4+DQo+PiAgICAgICA+Pj4+Pj4+PiAyLiAgSWYg dGhlIGFuc3dlcmVyIGRvZXMgbm90IGluY2x1ZGUgYW55IGNhbmRpZGF0ZXMgaW4gdGhlDQo+PiAg ICAgIGFuc3dlciBhbmQgaW5zdGVhZCB0cmlja2xlcyB0aGVtIGxhdGVyLCBzaG91bGQgaXQgdHJp Y2tsZSB0aGVtDQo+PiAgICAgICA+Pj4+Pj4+PiBOIHRpbWVzIChvbmNlIGZvciBlYWNoIG0tbGlu ZSBpbiB0aGUgQlVORExFIGdyb3VwKSBvciA+MQ0KPj4gICAgICB0aW1lPyAgMSB0aW1lIHNlZW1z IG11Y2ggbW9yZSByZWFzb25hYmxlIHRoYW4gTiB0aW1lcywgYnV0DQo+PiAgICAgICA+Pj4+Pj4+ PiBpZiB3ZSBkdXBsaWNhdGUgY2FuZGlkYXRlcyBpbiB0aGUgYW5zd2VyLCBidXQgbm90DQo+PiAg ICAgIGR1cGxpY2F0ZSB0aGVtIHdoaWxlIHRyaWNrbGluZywgdGhhdCdzIGEgYml0IGluY29uc2lz dGVudC4gIFlldA0KPj4gICAgICAgPmFub3RoZXIgcmVhc29uIHRvIG5vdCBkdXBsaWNhdGUgaW4g dGhlIGFuc3dlciA6KS4NCj4+ICAgICAgID4+Pj4+Pj4NCj4+ICAgICAgID4+Pj4+Pj4gQXNzdW1p bmcgeW91IHVzZSBTRFAgdG8gc2lnbmFsIHRoZSB0cmlja2xlZCBjYW5kaWRhdGVzLA0KPj4gICAg ICBpdOKAmXMgdHJ1ZSB0aGF0IHlvdSB3b3VsZCBkdXBsaWNhdGUgdGhlbSwNCj4+ICAgICAgID4+ Pj4+Pj4NCj4+ICAgICAgID4+Pj4+PuKAi1doYXQncyB0aGUgcmF0aW9uYWxlIGZvciB0aGF0PyAg VGhlc2UgZHVwbGljYXRlcyBwcm92aWRlIG5vDQo+PiAgICAgIHZhbHVlLCBhbmQgaW4gdGhlIGNh c2Ugb2YgbWFueSBtLWxpbmVzIChzdWNoIGFzIGEgY29uZmVyZW5jaW5nDQo+PiAgICAgICA+Pj4+ Pj5zeXN0ZW0gd2l0aCBtYW55IHBhcnRpY2lwYW50cyksIHdlIGNvdWxkIGJlIHRhbGtpbmcgYWJv dXQgMzB4DQo+PiAgICAgIHRoZSBudW1iZXIgb2YgY2FuZGlkYXRlcyBiZWluZyBzaWduYWxlZC4N Cj4+ICAgICAgID4+Pj4NCj4+ICAgICAgID4+Pj4gSSBoZWFyIHdoYXQgeW91IGFyZSBzYXlpbmcu DQo+PiAgICAgICA+Pj4+DQo+PiAgICAgICA+Pj4+IEJ1dCwgaWYgd2Ugd291bGQgZG8gYSBjaGFu Z2UsIHdlIGFsc28gbmVlZCB0byBsb29rIGF0IHRoZSBmdWxsDQo+PiAgICAgIHBpY3R1cmUsIGFu ZCBjb25zaWRlciBzdWJzZXF1ZW50IG9mZmVycyBldGMuDQo+PiAgICAgICA+Pj4NCj4+ICAgICAg 4oCLPj4+IEkgdGhpbmsgYSBzaW1wbGUgcnVsZSB3b3VsZCBiZSAiaWYgeW91IGtub3cgaXQncyBn b2luZyB0byBiZQ0KPj4gICAgICBidW5kbGVkIG9udG8gYW5vdGhlciBtLWxpbmUsIGRvbid0IGlu Y2x1ZGUNCj4+ICAgICAgID4+PiBjYW5kaWRhdGVzIi4gIFRoYXQgd291bGQgZ28gZm9yIGJ1bmRs ZS1vbmx5IG0tbGluZXMgaW4gYW4NCj4+ICAgICAgb2ZmZXIsIGJ1bmRsZWQgbS1saW5lcyBpbiBh biBhbnN3ZXIsIGFuZCBidW5kbGVkIG0tbGluZXMgaW4gYSByZS1vZmZlci7igIsNCj4+ICAgICAg 4oCLPj4+DQo+PiAgICAgICA+PiBCdW5kbGVkIG0tIGxpbmVzIGluIGEgcmUtb2ZmZXIgY2FuIHN0 aWxsIGJlIHJlamVjdGVkIGJ5IHRoZQ0KPj4gICAgICBhbnN3ZXJlci4NCj4+ICAgICAgID4NCj4+ ICAgICAg4oCLPiBUaGF0IHNvdW5kcyB0aGUgc2FtZSBhcyBhbiBpbml0aWFsIG9mZmVyLiAgSG93 IGRvZXMgaXQgaW1wbHkgdGhhdA0KPj4gICAgICBhIHJlLW9mZmVyIG11c3QgZHVwbGljYXRlDQo+ PiAgICAgICA+IGNhbmRpZGF0ZXMgYWNyb3NzIG0tbGluZXMsIGV2ZW4gd2hlbiBhbiBpbml0aWFs IG9mZmVyIGRvZXNuJ3QNCj4+ICAgICAgbmVlZCB0bz/igIsNCj4+ICAgICAg4oCLDQo+PiAgICAg IEluIHRoZSBpbml0aWFsIG9mZmVyIGVhY2ggbS0gbGluZSBjb250YWlucyBjYW5kaWRhdGVzICh1 bmlxdWUpLiBJZg0KPj4gICAgICBhbiBtLSBsaW5lIGluIHRoZSBvZmZlciBpcyByZWplY3RlZCwg dGhlIGFuc3dlcmVyIG11c3Qgc2VsZWN0IHRoZQ0KPj4gICAgICBvZmZlcmVyIEJVTkRMRSBhZGRy ZXNzIChhbmQgdGhlIGFzc29jaWF0ZWQgY2FuZGlkaWF0ZXMpIGZyb20gYW5vdGhlcg0KPj4gICAg ICBtLSBsaW5lLg0KPj4NCj4+ICAgICAgTm93LCBpbiBhIHJlLW9mZmVyLCBpZiB0aGUgbS0gbGlu ZSBjb250YWluaW5nIHRoZSBjYW5kaWRhdGVzIGlzDQo+PiAgICAgIHJlamVjdGVkLCB0aGUgYW5z d2VyZXIgbmVlZHMgdG8gaW5jbHVkZSBpdHMgY2FuZGlkYXRlcyBpbiBhbm90aGVyIG0tDQo+PiAg ICAgIGxpbmUgaW4gdGhlIGFuc3dlci4gVGhhdCdzIGRvYWJsZSwgYnV0IGl0IHdvdWxkIG5lZWQg dG8gYmUgY2xlYXJseQ0KPj4gICAgICBkb2N1bWVudGVkLiBJbiBvdGhlciB3b3JkczogaXQgbmVl ZHMgdG8gYmUgY2xlYXIgdGhhdCB0aGUgY2FuZGlkYXRlcw0KPj4gICAgICBjYW4gb2NjdXIgaW4g QU5ZIG9mIHRoZSBidW5kbGVkIG0tIGxpbmVzLCBhbmQgdGhhdCBtLSBsaW5lIG1heQ0KPj4gICAg ICBjaGFuZ2UgYmV0d2VlbiBvZmZlcnMgYW5kIGFuc3dlcnMuDQo+Pg0KPj4g4oCLU28gYSBydWxl IG9mICJ0aGUgY2FuZGlkYXRlcyBjYW4gYmUgaW4gYW55IG9uZSBvZiB0aGUgbS1saW5lcywgYW5k IA0KPj4gaXQgZG9lc24ndCBtYXR0ZXIgd2hpY2gsIGFuZCBpdCBjYW4gY2hhbmdlIGFueSB0aW1l Ii4gIFRoYXQgc2VlbXMgDQo+PiByZWFzb25hYmxlIHRvIG1lLiAgSXQgbGVhdmUgdGhlIG1vc3Qg ZmxleGliaWxpdHkgdG8gdGhlIG9uZSB3cml0aW5nIA0KPj4gdGhlIFNEUCwgYW5kIGl0J3MgdmVy eSBlYXN5IHRvIGltcGxlbWVudCBmb3IgdGhlIG9uZSByZWFkaW5nIHRoZSANCj4+IFNEUC7igIsN Cj4+DQo+Pg0KPj4gICAgICBSZWdhcmRzLA0KPj4NCj4+ICAgICAgQ2hyaXN0ZXINCj4+DQo+Pg0K Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+Pg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0 DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYw0KPg0KDQo= From nobody Fri Feb 19 09:24: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 4A36B1B330B for ; Fri, 19 Feb 2016 09:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.307 X-Spam-Level: X-Spam-Status: No, score=-13.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 P5Eh9tmvrpdR for ; Fri, 19 Feb 2016 09:24:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E143C1B3309 for ; Fri, 19 Feb 2016 09:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15116; q=dns/txt; s=iport; t=1455902688; x=1457112288; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8Ft+0UMIeM16g+h1tw+a+ji60C8wPanB1clBkXhgNQM=; b=frWLQoiJZeLHBBg9ai1dmFN2IBadIGg0+rhqnZeKmW718ytOBpzxdTZD cAzvnlNBnjbb1IH/Jttvx5X+zcxIxfxNEurIo8QNXypL+PTP3Ow9jV4UR f6ppMnci1okGJaiumEnSqRXEh1T+n7fH7t6GjwOAdbz2ijK8l6Bv0uWUi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLBQAKT8dW/5ldJa1eDoMsUm24MoIhg?= =?us-ascii?q?WghhSJKAoFWORMBAQEBAQEBZCeEQQEBAQMBIxVABgsLGAICBRYLAgIJAwIBAgF?= =?us-ascii?q?FBgEMCAEBBYgJCA6sTo8KAQEBAQEBAQEBAQEBAQEBAQEZe4UXhDuEBREBgx6BO?= =?us-ascii?q?gWNKnSIaY1eiSGFUo5IIgI+gylZHi4BhwqBMQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,471,1449532800"; d="scan'208";a="75040655" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2016 17:24:47 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1JHOkoF000360; Fri, 19 Feb 2016 17:24:46 GMT To: Juergen Stoetzer-Bradler , Paul Kyzivat , mmusic@ietf.org, "DRAGE, Keith (Keith)" , "Makaraju, Maridi Raju (Raju)" References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> <56C6156C.2070308@cisco.com> <56C71EF3.6040208@alcatel-lucent.com> From: Flemming Andreasen Message-ID: <56C74FDE.4040902@cisco.com> Date: Fri, 19 Feb 2016 12:24:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C71EF3.6040208@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; 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, 19 Feb 2016 17:24:52 -0000 On 2/19/16 8:56 AM, Juergen Stoetzer-Bradler wrote: > Flemming, > > Regarding >> Sounds reasonable with the caveat that you may have attributes >> defined for use with a particular sub-protocol outside the >> subprotocol draft itself (e.g. because such an attribute was either >> defined subsequently or its use with a specific subprotocol is >> defined subsequently). If so, we would need an IANA registry >> structure (under SDP) that for each subprotocol defines the set of >> attributes that have been defined with specific semantics for that >> subprotocol. > > Let's assume a future document defines how to establish MSRP sessions > over a transport protocol unequal to TCP, TLS, or data channel, and > that this document also defines a new MSRP related attribute, whose > semantic is only defined for this new transport case (like a maximal > MSRP chunk size specific for the new transport). I assume that this > future document would request to add this new attribute to one of the > existing IANA SDP attribute tables (assumingly to the "att-field > (media level only)" table). So far so good, however the case I had in mind is one where the new attribute would apply to one or more existing subprotocols . > Let's further assume that an implementation creates an SDP offer for > an MSRP session over a data channel and adds this new attribute as > dcsa embedded MSRP subprotocol attribute (for whatever reasons). > > Somebody seeing and inspecting this SDP offer could use the dcmap > attribute's subprotocol value "MSRP" to get a reference to the > msrp-usage-data-channel document. That document would not mention that > new attribute at all. The next step could then be to consult the IANA > SDP tables, and there this new attribute would be found together with > a reference to this future document. > As assumingly this new MSRP related attribute would only be defined > for this new transport, While that is certainly a valid use case, I wasn't thinking of restricting it to that and hence the request for an actual sub-registry for each of these subprotocols to register attributes that can be used with each of them (some attributes may apply to multiple). > I think this new attribute should then be ignored by the recipient of > this SDP offer. > Section 5.2.5 of most recent draft-ietf-mmusic-data-channel-sdpneg-08 > now contains two related recommendations: > > 'SDP offer or answer has an "a=dcsa" attribute, whose subprotocol > attribute is unknown. > * The receiver of such an SDP offer or answer SHOULD ignore this > entire "a=dcsa" attribute line. > > SDP offer or answer has an "a=dcsa" attribute, whose subprotocol > attribute is known, but whose subprotocol attribute semantic is not > known for the data channel transport case. > * The receiver of such an SDP offer or answer SHOULD ignore this > entire "a=dcsa" attribute line.' > > Would these recommendations address the case you are describing? > They only address the case(s) partally per the above. Thanks -- Flemming > Thanks, > Juergen > > > > On 18.02.2016 20:03, EXT Flemming Andreasen wrote: >> >> >> On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: >>> Flemming, >>> >>> Regarding >>>> It would probably simplify the overall SDP negotiation part, but I >>>> don't know if it would constrain the way data channels were >>>> envisioned to be used. >>> >>> On Friday Paul mentioned in his email two potential use cases, where >>> no subprotocol identifiers might be added to a data channel's dcmap >>> attribute. In my last email I hadn't thought of such cases. If we >>> don't want to exclude such cases, then requiring the subprotocol ids >>> always to be present might indeed be too restrictive. >>> >>> Regarding >>>> Ok. Going back to discussion between Paul and I, do you believe >>>> that in for an attribute to be encapsulated in dcsa, the attribute >>>> MUST have been explicitly define to support this (Paul's suggestion >>>> below) or do you believe that this is overly constraining, and if >>>> so, how shoud we relax it ? >>> >>> I now think that the sdpneg draft might recommend SDP offerers and >>> answerers to always add a subprotocol identifier to a data channel's >>> dcmap attribute if dcsa embedded attributes are also negotiated for >>> the data channel's subprotocol. I also think we could explicitly add >>> text to sdpneg saying that subprotocol identifiers should be added >>> to the IANA Websocket (and in future combined data channel) >>> registry. And that this registration should be done via a document, >>> which then explicitly describes the usages and semantics of dcsa >>> embedded subprotocol attributes, _if_ those usages or semantics >>> deviate from cases, where these attributes are not dcsa >>> encapsulated. I think that in those cases, where the usage and >>> meaning of an attribute (always related to the data channel's >>> subprotocol) does not deviate from the non-dcsa encapsulated use >>> cases, such an attribute may not explicitly need to be described for >>> data channel usage. But I think it might be helpful to explicitly >>> say so in the sdpneg draft. >>> >>> Somebody inspecting an SDP offer or answer, which was generated by >>> an implementation following these two recommendations (and which >>> hence contains an IANA registered subprotocol id if it contains any >>> dcsa embedded attributes), could then refer to that IANA table, >>> would then find the reference to the document, which defines this >>> subprotocol id for data channel usage, and there could check if any >>> of the dcsa embedded attributes has a data channel specific >>> semantic. If yes, that specific semantic would be described in that >>> document. If such a specific semantic were not described in that >>> document, then the default usage and semantic of the attribute would >>> apply also to that data channel transport case. >>> >> Sounds reasonable with the caveat that you may have attributes >> defined for use with a particular sub-protocol outside the >> subprotocol draft itself (e.g. because such an attribute was either >> defined subsequently or its use with a specific subprotocol is >> defined subsequently). If so, we would need an IANA registry >> structure (under SDP) that for each subprotocol defines the set of >> attributes that have been defined with specific semantics for that >> subprotocol. >> >> >>> But in that context I'd have an IANA table related question. >>> A certain subprotocol might be defined for Websocket usage as well >>> as for data channel usage. MSRP is already such a case, where >>> draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP >>> over data channels, and where draft-pd-dispatch-msrp-websocket >>> defines how to use MSRP over Websockets. >>> Would the IANA WebSocket Subprotocol Name Registry on >>> http://www.iana.org/assignments/websocket/websocket.xml then contain >>> two MSRP related rows? Or just one row containing references to both >>> the Websocket and data channel documents? >>> Should we add related text to the IANA registration section of the >>> sdpneg draft? >> See above. >> >> Thanks >> >> -- Flemming >>> >>> Thanks, >>> Juergen >>> >>> >>> On 12.02.2016 15:52, EXT Flemming Andreasen wrote: >>>> >>>> >>>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>>> Flemming, Paul, >>>>> >>>>> The current a=dcmap related text in >>>>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>>>> 'subprotocol' parameter must always be present - rather it is >>>>> specified as an optional parameter. Thus, current sdpneg text >>>>> would allow to create an SDP offer for a data channel, which >>>>> contains one a=dcmap attribute and potentially multiple a=dcsa >>>>> attributes without the subprotocol actually being given. Based on >>>>> this discussion I am wondering if the subprotocol parameter should >>>>> actually be mandatory. >>>>> >>>> It would probably simplify the overall SDP negotiation part, but I >>>> don't know if it would constrain the way data channels were >>>> envisioned to be used. >>>> >>>> >>>>> In the specific case of MSRP, the msrp-usage-data-channel draft >>>>> says in 5.1.1.1 that the dcmap attribute includes the label and >>>>> subprotocol parameters. The current text could possible be made >>>>> more explicit by saying that the 'subprotocol="MSRP"' parameter >>>>> must always be present. >>>>> Have just submitted version 04 of the msrp-usage-data-channel >>>>> draft, which proposes to add subprotocol identifier "MSRP" to the >>>>> WebSocket Subprotocol Name registry. This registry would then >>>>> associate subprotocol id "MSRP" with the msrp-usage-data-channel >>>>> document. >>>>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa >>>>> attribute are specified. And there the MSRP specific SDP >>>>> attributes, which can be dcsa embedded, are described. >>>>> 'setup' is an attribute, whose semantic changes when being dcsa >>>>> embedded and associated with subprotocol MSRP, as compared to the >>>>> meaning of an "a=setup" media level attribute of a TCP/MSRP >>>>> m-line. Hence these semantical differences are explicitly >>>>> addressed in the msrp-usage-data-channel draft. >>>>> >>>>> Regarding sdpneg, I also think that the current text in sdpneg >>>>> seems to be sufficient regarding the usage of dcsa encapsulated >>>>> SDP attributes as being bound to the data channel's subprotocol. >>>>> But as the semantic of a dcsa encapsulated attribute may be >>>>> subprotocol specific (like 'setup'), I'd now tend to consider the >>>>> subprotocol parameter in the dcmap attribute as being mandatory, >>>>> as mentioned above. As already discussed, the Websocket >>>>> subprotocol registry would then refer to the document, which >>>>> specifies the subprotocol specific usage of dcsa encapsulated >>>>> parameters. >>>>> >>>> Ok. Going back to discussion between Paul and I, do you believe >>>> that in for an attribute to be encapsulated in dcsa, the attribute >>>> MUST have been explicitly define to support this (Paul's suggestion >>>> below) or do you believe that this is overly constraining, and if >>>> so, how shoud we relax it ? >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> >>>>> Thanks, >>>>> Juergen >>>>> >>>>> >>>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>>> >>>>>> >>>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and >>>>>>>>>> specific >>>>>>>>>> drafts are used to describe protocols that use the mechanism >>>>>>>>>> (i.e. >>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>>> >>>>>>>>> It remains to be seen if that will be enough. E.g., there >>>>>>>>> currently >>>>>>>>> aren't any iana considerations in >>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>>> >>>>>>>>> Suppose I encounter some sdp that uses msrp over a data >>>>>>>>> channel, but >>>>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>>>> reference to >>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that >>>>>>>>> usage? >>>>>>>>> >>>>>>>>> I would like to think that the iana registries will allow me >>>>>>>>> to trace >>>>>>>>> back to the relevant specs. >>>>>>>>> >>>>>>>> No disagreement on that part, however having taken another look >>>>>>>> at both >>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with your >>>>>>>> original request for all (existing and new) attributes to >>>>>>>> specify how >>>>>>>> they may or may not be used with the dcsa attribute defined by >>>>>>>> sdpneg. >>>>>>>> >>>>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>>>> individual >>>>>>>> documents (like msrp-usage), which calls your the parameters >>>>>>>> that are at >>>>>>>> least needed to be supported for that usage. Taking MSRP as an >>>>>>>> example, >>>>>>>> why isn't that enough, and how do you see the resulting set of >>>>>>>> attributes that may or may not be used with MSRP differ between >>>>>>>> use in a >>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular >>>>>>>> media >>>>>>>> stream ? >>>>>>> >>>>>>> Based on this discussion, I conclude that it should be >>>>>>> sufficient for this draft to say that before an attribute can be >>>>>>> used with dcsa, such usage must be defined somewhere. This could >>>>>>> be either: >>>>>>> - as part of the definition of the attribute, OR >>>>>>> - as part of the definition of the protocol referenced on the >>>>>>> m-line. >>>>>>> >>>>>> We are getting closer, but it's still not obvious to me that you >>>>>> cannot use an attribute with dcsa if it has not been explicitly >>>>>> defined for the attribute in question. Clearly, there are >>>>>> attributes that wouldn't make sense over data channels, just like >>>>>> there are attributes that don't make sense over particular media >>>>>> descriptions. >>>>>> >>>>>> Again, I'd like to hear from more people on this, including the >>>>>> authors. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Also, it would be good to hear from more people on this, >>>>>>>> including the >>>>>>>> document authors. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> Regards, Christian >>>>>>>>>> >>>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>>> >>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we >>>>>>>>>>>> need to >>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then >>>>>>>>>>>> it should be >>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at this >>>>>>>>>>>> point is >>>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>>> interactions as >>>>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>>>> (plus the >>>>>>>>>>>> offerer being responsible for generating a valid offer if >>>>>>>>>>>> he wants to >>>>>>>>>>>> establish a data channel). >>>>>>>>>>> >>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>>>> pertains to >>>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>> >>> >>> . >>> >> > > From nobody Fri Feb 19 09:31: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 4EEFB1B3330; Fri, 19 Feb 2016 09:31:43 -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 43S4blbeQmar; Fri, 19 Feb 2016 09:31:41 -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 717171B3336; Fri, 19 Feb 2016 09:31:08 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-74-56c7515ae6b4 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 57.FF.15637.A5157C65; Fri, 19 Feb 2016 18:31:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 18:31:05 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , mmusic , "draft-ietf-mmusic-dtls-sdp@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ8zhRKAgAAxKN8= Date: Fri, 19 Feb 2016 17:31:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E0B707@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E0B707ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7k25U4PEwg+4NKhb/J85ntdg06wub xfsLuhZTlz9mcWDxmPJ7I6vHkiU/mQKYorhsUlJzMstSi/TtErgyXtw8w1Zw1Lniw/1ZzA2M Fyy7GDk5JARMJC7d280CYYtJXLi3nq2LkYtDSOAwo8SjpqmsEM5iRonpXeuBHA4ONgELie5/ 2iANIgKzGCXmTKwCsZmBwl8XzwIbJCxgL/Hv/gc2iBoHiU03rjFC2FYSXTsPgNksAqoSU5fu YAexeQV8JXZsvQ4WFxLwlji86DITiM0poC9x+utdsBpGoOO+n1rDBLFLXKLpy0pWiKMFJJbs Oc8MYYtKvHz8jxWiJl9i+pNORoj5ghInZz5hmcAoMgtJ+ywkZbOQlEHEDSS+vL8NZWtLLFv4 mhnC1pfofn+aCVl8ASP7KkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzASDu45bfqDsbLbxwP MQpwMCrx8H7wORYmxJpYVlyZe4hRgoNZSYT3vdHxMCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 a5zXhwkJpCeWpGanphakFsFkmTg4pRoYgz4KV3rMNvH5fTKESyyUv0bwk/GynalPbio87vKI 7d9ZfmvdmoZO/fsFjx5ImsUsNtlza9XBB+cP3PhSMNna+GnqxdsP3uoY8yw+efxl1MkZq07e /3r32LRXSuscUmQ87e8aBe98J5qamsG82Wnf8wzG0m+HND4ZL1g/m2tBpeLBIu8+/+1LfJRY ijMSDbWYi4oTAeHJdMWwAgAA Archived-At: Cc: "Flemming Andreasen \(fandreas\)" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:31:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E0B707ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Charles, Thanks for your comments! I will implement all but 6) as suggested. Regarding 6), it is not forbidden to use the 'connection' attribute in the = m- line if it is used for something else than the DTLS connection. The subs= equent paragraph gives an example of SCTP usage with DTLS. But, I can combine the paragraphs, and modify: "This specification does not define the usage of the SDP 'connection' attri= bute [ref] for negotiating a DTLS connection. However, the attribute MAY be= used if the DTLS connection is used together with another protocol, e.g. S= CTP or TCP, for which the usage of the attribute has been defined." Regards, Christer Sent from my Windows Phone ________________________________ From: Charles Eckel (eckelcu) Sent: =FD19/=FD02/=FD2016 17:35 To: mmusic; draft-ietf-mmusic-dtls-sdp@ietf.org Cc: Flemming Andreasen (fandreas) Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt I reviewed the draft and have some minor comments. 1) Section 1, the second paragraph is redundant and can be removed. It is well stated with additional content in the paragraph that immediately follows. 2) Section 3.1 s/following to the procedures/following the procedures 3) Section 3.2 and 3.3 OLD: "the endpoint MUST either change its DTLS role, its fingerprint value and/or use=B2 NEW: "the endpoint MUST change its DTLS role, change its fingerprint value, and/or use" 4) Section 5.1 OLD: "e.g. regarding usage of usage specific SDP attributes etc=B2 NEW: =B3e.g. regarding usage of specific SDP attributes=B2 5) Section 5.1 s/and needs/and need s/or whether a previous/or a previous 6) Section 5.1 OLD: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] when negotiating a DTLS association.=B2 NEW: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] within the same =B3m=3D=B3 line in which they are negotiating a DTLS association.=B2 7) Section 5.3 s/receives and offer/receives an offer s/towards the the offerer/towards the offerer 8) Section 11 IANA considerations to be updated as Paul already noted. Cheers, Charles On 2/5/16, 8:29 AM, "mmusic on behalf of Flemming Andreasen (fandreas)" wrote: >Greetings MMUSIC > >This is to announce a 2 week WGLC on the draft: > > https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-06.txt > >as Proposed Standard. Please review and provide any comments you may >have on the document by Friday, February 19, 2016. Comments should be >sent to the document authors and the MMUSIC WG list. If you review the >document but do not have any comments, please send a note to that effect >as well. > >Thanks > >-- Flemming (MMUSIC co-chair) > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B37E0B707ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Charles,
Thanks for your comments! I will implement all but 6) as suggested.

Regarding 6), it is not forbidden to use the 'connection' attribute in the = m- line if it is used for something else than the DTLS connection. The subs= equent paragraph gives an example of SCTP usage with DTLS.

But, I can combine the paragraphs, and modify:

"This specification does not define the usage of the SDP 'connection' = attribute [ref] for negotiating a DTLS connection. However, the attribute M= AY be used if the DTLS connection is used together with another protocol, e= .g. SCTP or TCP, for which the usage of the attribute has been defined."

Regards,

Christer

Sent from my Windows Phone
From: Charles Eckel (eckelcu)
Sent: =FD19= /=FD02/=FD2016 17:35
To: mmusic; draft-ietf-mmusic-dt= ls-sdp@ietf.org
Cc: Flemming Andreasen (fandreas) Subject: Re: [= MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

I reviewed the draft and have some minor comments.=

1) Section 1, the second paragraph is redundant and can be removed. It is well stated with additional content in the paragraph that immediately
follows.

2) Section 3.1
s/following to the procedures/following the procedures

3) Section 3.2 and 3.3
OLD: "the endpoint MUST either change its DTLS role, its fingerprint v= alue
and/or use=B2
NEW: "the endpoint MUST change its DTLS role, change its fingerprint value, and/or use"

4) Section 5.1
OLD: "e.g. regarding usage of usage specific SDP attributes etc=B2
NEW: =B3e.g. regarding usage of specific SDP attributes=B2

5) Section 5.1
s/and needs/and need
s/or whether a previous/or a previous

6) Section 5.1
OLD: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145] = when
   negotiating a DTLS association.=B2
NEW: "Endpoints MUST NOT use the SDP 'connection' attribute [RFC4145]<= br> within the same =B3m=3D=B3 line in which they are negotiating a DTLS
association.=B2

7) Section 5.3
s/receives and offer/receives an offer
s/towards the the offerer/towards the offerer

8) Section 11
IANA considerations to be updated as Paul already noted.

Cheers,
Charles


On 2/5/16, 8:29 AM, "mmusic on behalf of Flemming Andreasen (fandreas)= "
<mmusic-bounces@ietf.org on behalf of fandreas@cisco.com> wrote:

>Greetings MMUSIC
>
>This is to announce a 2 week WGLC on the  draft:
>
>      https://www.ietf.org/id/draft-ietf-mmusic-dtl= s-sdp-06.txt
>
>as Proposed Standard. Please review and provide any comments you may >have on the document by Friday, February 19, 2016. Comments should be >sent to the document authors and the MMUSIC WG list. If you review the<= br> >document but do not have any comments, please send a note to that effec= t
>as well.
>
>Thanks
>
>-- Flemming (MMUSIC co-chair)
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ie= tf.org/mailman/listinfo/mmusic

 --_000_7594FB04B1934943A5C02806D1A2204B37E0B707ESESSMB209erics_-- From nobody Fri Feb 19 09:48: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 2B8FB1B3374; Fri, 19 Feb 2016 09:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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.006, 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 Ye6ZO2VHZT2W; Fri, 19 Feb 2016 09:48:30 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C081B336C; Fri, 19 Feb 2016 09:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14948; q=dns/txt; s=iport; t=1455904109; x=1457113709; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LmK6uXlqcVlXjP9wQjmIp5tLP4BhW6LPQ51ECMVtGyc=; b=KdF9hAcmKLAbMPQU+7rKGq2KUGcLVzj9AgHtiAOM4thiKYdsaiPp/HvQ DgCSH5xbAqE0NWDweNljR5Cynkw4Uv/DIyJZgaYsCRSpeXn4AmW9xVxeD rnosylr4BEip3qYTcCE/Sw0ytBBVLXaTuNjzZ3cP9KKW/308fxOQv7V70 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgDSVMdW/4gNJK1egm5MUm0Guj8BD?= =?us-ascii?q?YFoFwEJhSJKAhyBOjgUAQEBAQEBAWQnhEEBAQEEAQEBKkELEAIBCBEDAQEBKAU?= =?us-ascii?q?CAiULFAMBBQgCBAENBYgaDo9VnQsGjw4BAQEBAQEBAQEBAQEBAQEBAQEBAQERB?= =?us-ascii?q?IpNhEsKDYJNgUAFlwcBjV2BXIRDhzqBGo5HAR4BAUKDZGoBhz59AQEB?= X-IronPort-AV: E=Sophos;i="5.22,471,1449532800"; d="scan'208,217";a="240331777" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2016 17:48:28 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1JHmSb7023854 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 17:48:28 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 19 Feb 2016 11:48:27 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Fri, 19 Feb 2016 11:48:28 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , mmusic , "draft-ietf-mmusic-dtls-sdp@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJdl8Jv9AbyFUKy2Bc+d5nItJ80Cy6AgAAPoYCAABWjAA== Date: Fri, 19 Feb 2016 17:48:28 +0000 Message-ID: References: <56B4CDCF.4080100@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E0B707@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E0B707@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.99.198] Content-Type: multipart/alternative; boundary="_000_D2ED13B7677FAeckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Flemming Andreasen \(fandreas\)" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:48:32 -0000 --_000_D2ED13B7677FAeckelcuciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLiBUaGFua3MgQ2hyaXN0ZXIuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KRnJv bTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkRhdGU6IEZyaWRheSwgRmVicnVh cnkgMTksIDIwMTYgYXQgNjozMSBQTQ0KVG86IENoYXJsZXMgRWNrZWwgPGVja2VsY3VAY2lzY28u Y29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzpt bXVzaWNAaWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+ PiwgImRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LW1tdXNpYy1kdGxzLXNkcEBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcEBp ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHBAaWV0Zi5vcmc+Pg0KQ2M6 ICJGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSIgPGZhbmRyZWFzQGNpc2NvLmNvbTxtYWls dG86ZmFuZHJlYXNAY2lzY28uY29tPj4NClN1YmplY3Q6IFJFOiBbTU1VU0lDXSBXR0xDIG9uIGRy YWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTA2LnR4dA0KDQpIaSBDaGFybGVzLA0KDQpUaGFua3Mg Zm9yIHlvdXIgY29tbWVudHMhIEkgd2lsbCBpbXBsZW1lbnQgYWxsIGJ1dCA2KSBhcyBzdWdnZXN0 ZWQuDQoNClJlZ2FyZGluZyA2KSwgaXQgaXMgbm90IGZvcmJpZGRlbiB0byB1c2UgdGhlICdjb25u ZWN0aW9uJyBhdHRyaWJ1dGUgaW4gdGhlIG0tIGxpbmUgaWYgaXQgaXMgdXNlZCBmb3Igc29tZXRo aW5nIGVsc2UgdGhhbiB0aGUgRFRMUyBjb25uZWN0aW9uLiBUaGUgc3Vic2VxdWVudCBwYXJhZ3Jh cGggZ2l2ZXMgYW4gZXhhbXBsZSBvZiBTQ1RQIHVzYWdlIHdpdGggRFRMUy4NCg0KQnV0LCBJIGNh biBjb21iaW5lIHRoZSBwYXJhZ3JhcGhzLCBhbmQgbW9kaWZ5Og0KDQoiVGhpcyBzcGVjaWZpY2F0 aW9uIGRvZXMgbm90IGRlZmluZSB0aGUgdXNhZ2Ugb2YgdGhlIFNEUCAnY29ubmVjdGlvbicgYXR0 cmlidXRlIFtyZWZdIGZvciBuZWdvdGlhdGluZyBhIERUTFMgY29ubmVjdGlvbi4gSG93ZXZlciwg dGhlIGF0dHJpYnV0ZSBNQVkgYmUgdXNlZCBpZiB0aGUgRFRMUyBjb25uZWN0aW9uIGlzIHVzZWQg dG9nZXRoZXIgd2l0aCBhbm90aGVyIHByb3RvY29sLCBlLmcuIFNDVFAgb3IgVENQLCBmb3Igd2hp Y2ggdGhlIHVzYWdlIG9mIHRoZSBhdHRyaWJ1dGUgaGFzIGJlZW4gZGVmaW5lZC4iDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSk8bWFp bHRvOmVja2VsY3VAY2lzY28uY29tPg0KU2VudDogMTkvMDIvMjAxNiAxNzozNQ0KVG86IG1tdXNp YzxtYWlsdG86bW11c2ljQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHBAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwQGlldGYub3JnPg0KQ2M6IEZs ZW1taW5nIEFuZHJlYXNlbiAoZmFuZHJlYXMpPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+DQpT dWJqZWN0OiBSZTogW01NVVNJQ10gV0dMQyBvbiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0w Ni50eHQNCg0KSSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgc29tZSBtaW5vciBjb21tZW50 cy4NCg0KMSkgU2VjdGlvbiAxLCB0aGUgc2Vjb25kIHBhcmFncmFwaCBpcyByZWR1bmRhbnQgYW5k IGNhbiBiZSByZW1vdmVkLiBJdCBpcw0Kd2VsbCBzdGF0ZWQgd2l0aCBhZGRpdGlvbmFsIGNvbnRl bnQgaW4gdGhlIHBhcmFncmFwaCB0aGF0IGltbWVkaWF0ZWx5DQpmb2xsb3dzLg0KDQoyKSBTZWN0 aW9uIDMuMQ0Kcy9mb2xsb3dpbmcgdG8gdGhlIHByb2NlZHVyZXMvZm9sbG93aW5nIHRoZSBwcm9j ZWR1cmVzDQoNCjMpIFNlY3Rpb24gMy4yIGFuZCAzLjMNCk9MRDogInRoZSBlbmRwb2ludCBNVVNU IGVpdGhlciBjaGFuZ2UgaXRzIERUTFMgcm9sZSwgaXRzIGZpbmdlcnByaW50IHZhbHVlDQphbmQv b3IgdXNlqfcNCk5FVzogInRoZSBlbmRwb2ludCBNVVNUIGNoYW5nZSBpdHMgRFRMUyByb2xlLCBj aGFuZ2UgaXRzIGZpbmdlcnByaW50DQp2YWx1ZSwgYW5kL29yIHVzZSINCg0KNCkgU2VjdGlvbiA1 LjENCk9MRDogImUuZy4gcmVnYXJkaW5nIHVzYWdlIG9mIHVzYWdlIHNwZWNpZmljIFNEUCBhdHRy aWJ1dGVzIGV0Y6n3DQpORVc6IKn4ZS5nLiByZWdhcmRpbmcgdXNhZ2Ugb2Ygc3BlY2lmaWMgU0RQ IGF0dHJpYnV0ZXOp9w0KDQo1KSBTZWN0aW9uIDUuMQ0Kcy9hbmQgbmVlZHMvYW5kIG5lZWQNCnMv b3Igd2hldGhlciBhIHByZXZpb3VzL29yIGEgcHJldmlvdXMNCg0KNikgU2VjdGlvbiA1LjENCk9M RDogIkVuZHBvaW50cyBNVVNUIE5PVCB1c2UgdGhlIFNEUCAnY29ubmVjdGlvbicgYXR0cmlidXRl IFtSRkM0MTQ1XSB3aGVuDQogICBuZWdvdGlhdGluZyBhIERUTFMgYXNzb2NpYXRpb24uqfcNCk5F VzogIkVuZHBvaW50cyBNVVNUIE5PVCB1c2UgdGhlIFNEUCAnY29ubmVjdGlvbicgYXR0cmlidXRl IFtSRkM0MTQ1XQ0Kd2l0aGluIHRoZSBzYW1lIKn4bT2p+CBsaW5lIGluIHdoaWNoIHRoZXkgYXJl IG5lZ290aWF0aW5nIGEgRFRMUw0KYXNzb2NpYXRpb24uqfcNCg0KNykgU2VjdGlvbiA1LjMNCnMv cmVjZWl2ZXMgYW5kIG9mZmVyL3JlY2VpdmVzIGFuIG9mZmVyDQpzL3Rvd2FyZHMgdGhlIHRoZSBv ZmZlcmVyL3Rvd2FyZHMgdGhlIG9mZmVyZXINCg0KOCkgU2VjdGlvbiAxMQ0KSUFOQSBjb25zaWRl cmF0aW9ucyB0byBiZSB1cGRhdGVkIGFzIFBhdWwgYWxyZWFkeSBub3RlZC4NCg0KQ2hlZXJzLA0K Q2hhcmxlcw0KDQoNCk9uIDIvNS8xNiwgODoyOSBBTSwgIm1tdXNpYyBvbiBiZWhhbGYgb2YgRmxl bW1pbmcgQW5kcmVhc2VuIChmYW5kcmVhcykiDQo8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgZmFuZHJlYXNAY2lzY28u Y29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PiB3cm90ZToNCg0KPkdyZWV0aW5ncyBNTVVT SUMNCj4NCj5UaGlzIGlzIHRvIGFubm91bmNlIGEgMiB3ZWVrIFdHTEMgb24gdGhlICBkcmFmdDoN Cj4NCj4gICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW1tdXNpYy1kdGxz LXNkcC0wNi50eHQNCj4NCj5hcyBQcm9wb3NlZCBTdGFuZGFyZC4gUGxlYXNlIHJldmlldyBhbmQg cHJvdmlkZSBhbnkgY29tbWVudHMgeW91IG1heQ0KPmhhdmUgb24gdGhlIGRvY3VtZW50IGJ5IEZy aWRheSwgRmVicnVhcnkgMTksIDIwMTYuIENvbW1lbnRzIHNob3VsZCBiZQ0KPnNlbnQgdG8gdGhl IGRvY3VtZW50IGF1dGhvcnMgYW5kIHRoZSBNTVVTSUMgV0cgbGlzdC4gSWYgeW91IHJldmlldyB0 aGUNCj5kb2N1bWVudCBidXQgZG8gbm90IGhhdmUgYW55IGNvbW1lbnRzLCBwbGVhc2Ugc2VuZCBh IG5vdGUgdG8gdGhhdCBlZmZlY3QNCj5hcyB3ZWxsLg0KPg0KPlRoYW5rcw0KPg0KPi0tIEZsZW1t aW5nIChNTVVTSUMgY28tY2hhaXIpDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+bW11c2ljQGlldGYub3Jn PG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCg0K --_000_D2ED13B7677FAeckelcuciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: <409FCDDB4837D64EAE3649339FC8E8C2@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTZweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+V29ya3MgZm9y IG1lLiBUaGFua3MgQ2hyaXN0ZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVl cnMsPC9kaXY+DQo8ZGl2PkNoYXJsZXM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1C T1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9U VE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1U T1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5H LVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+ Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIEZlYnJ1 YXJ5IDE5LCAyMDE2IGF0IDY6MzEgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj5DaGFybGVzIEVja2VsICZsdDs8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBj aXNjby5jb20iPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHBAaWV0Zi5vcmciPmRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHBAaWV0Zi5vcmciPmRyYWZ0LWlldGYtbW11 c2ljLWR0bHMtc2RwQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDtGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+ZmFuZHJlYXNAY2lz Y28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVj dDogPC9zcGFuPlJFOiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2Rw LTA2LnR4dDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4N CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZl ciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUg eyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAw MDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij5IaSBD aGFybGVzLDxicj4NCjxicj4NClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyEgSSB3aWxsIGltcGxl bWVudCBhbGwgYnV0IDYpIGFzIHN1Z2dlc3RlZC48YnI+DQo8YnI+DQpSZWdhcmRpbmcgNiksIGl0 IGlzIG5vdCBmb3JiaWRkZW4gdG8gdXNlIHRoZSAnY29ubmVjdGlvbicgYXR0cmlidXRlIGluIHRo ZSBtLSBsaW5lIGlmIGl0IGlzIHVzZWQgZm9yIHNvbWV0aGluZyBlbHNlIHRoYW4gdGhlIERUTFMg Y29ubmVjdGlvbi4gVGhlIHN1YnNlcXVlbnQgcGFyYWdyYXBoIGdpdmVzIGFuIGV4YW1wbGUgb2Yg U0NUUCB1c2FnZSB3aXRoIERUTFMuPGJyPg0KPGJyPg0KQnV0LCBJIGNhbiBjb21iaW5lIHRoZSBw YXJhZ3JhcGhzLCBhbmQgbW9kaWZ5Ojxicj4NCjxicj4NCiZxdW90O1RoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBkZWZpbmUgdGhlIHVzYWdlIG9mIHRoZSBTRFAgJ2Nvbm5lY3Rpb24nIGF0dHJp YnV0ZSBbcmVmXSBmb3IgbmVnb3RpYXRpbmcgYSBEVExTIGNvbm5lY3Rpb24uIEhvd2V2ZXIsIHRo ZSBhdHRyaWJ1dGUgTUFZIGJlIHVzZWQgaWYgdGhlIERUTFMgY29ubmVjdGlvbiBpcyB1c2VkIHRv Z2V0aGVyIHdpdGggYW5vdGhlciBwcm90b2NvbCwgZS5nLiBTQ1RQIG9yIFRDUCwgZm9yIHdoaWNo IHRoZSB1c2FnZQ0KIG9mIHRoZSBhdHRyaWJ1dGUgaGFzIGJlZW4gZGVmaW5lZC4mcXVvdDs8YnI+ DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9t IG15IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmVj a2VsY3VAY2lzY28uY29tIj5DaGFybGVzIEVja2VsIChlY2tlbGN1KTwvYT48L3NwYW4+PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjEx cHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjE5LzAyLzIwMTYgMTc6MzU8 L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsg Zm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlRvOg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWM8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwQGlldGYub3JnIj5kcmFmdC1pZXRmLW1tdXNpYy1kdGxz LXNkcEBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkNjOg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tIj5GbGVtbWluZyBB bmRyZWFzZW4gKGZhbmRyZWFzKTwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQi PlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjsgZm9udC1zaXplOjExcHQiPlJlOiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11 c2ljLWR0bHMtc2RwLTA2LnR4dDwvc3Bhbj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPkkgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIHNvbWUgbWlub3IgY29tbWVu dHMuPGJyPg0KPGJyPg0KMSkgU2VjdGlvbiAxLCB0aGUgc2Vjb25kIHBhcmFncmFwaCBpcyByZWR1 bmRhbnQgYW5kIGNhbiBiZSByZW1vdmVkLiBJdCBpczxicj4NCndlbGwgc3RhdGVkIHdpdGggYWRk aXRpb25hbCBjb250ZW50IGluIHRoZSBwYXJhZ3JhcGggdGhhdCBpbW1lZGlhdGVseTxicj4NCmZv bGxvd3MuPGJyPg0KPGJyPg0KMikgU2VjdGlvbiAzLjE8YnI+DQpzL2ZvbGxvd2luZyB0byB0aGUg cHJvY2VkdXJlcy9mb2xsb3dpbmcgdGhlIHByb2NlZHVyZXM8YnI+DQo8YnI+DQozKSBTZWN0aW9u IDMuMiBhbmQgMy4zPGJyPg0KT0xEOiAmcXVvdDt0aGUgZW5kcG9pbnQgTVVTVCBlaXRoZXIgY2hh bmdlIGl0cyBEVExTIHJvbGUsIGl0cyBmaW5nZXJwcmludCB2YWx1ZTxicj4NCmFuZC9vciB1c2Wp 9zxicj4NCk5FVzogJnF1b3Q7dGhlIGVuZHBvaW50IE1VU1QgY2hhbmdlIGl0cyBEVExTIHJvbGUs IGNoYW5nZSBpdHMgZmluZ2VycHJpbnQ8YnI+DQp2YWx1ZSwgYW5kL29yIHVzZSZxdW90OyA8YnI+ DQo8YnI+DQo0KSBTZWN0aW9uIDUuMTxicj4NCk9MRDogJnF1b3Q7ZS5nLiByZWdhcmRpbmcgdXNh Z2Ugb2YgdXNhZ2Ugc3BlY2lmaWMgU0RQIGF0dHJpYnV0ZXMgZXRjqfc8YnI+DQpORVc6IKn4ZS5n LiByZWdhcmRpbmcgdXNhZ2Ugb2Ygc3BlY2lmaWMgU0RQIGF0dHJpYnV0ZXOp9zxicj4NCjxicj4N CjUpIFNlY3Rpb24gNS4xPGJyPg0Kcy9hbmQgbmVlZHMvYW5kIG5lZWQ8YnI+DQpzL29yIHdoZXRo ZXIgYSBwcmV2aW91cy9vciBhIHByZXZpb3VzPGJyPg0KPGJyPg0KNikgU2VjdGlvbiA1LjE8YnI+ DQpPTEQ6ICZxdW90O0VuZHBvaW50cyBNVVNUIE5PVCB1c2UgdGhlIFNEUCAnY29ubmVjdGlvbicg YXR0cmlidXRlIFtSRkM0MTQ1XSB3aGVuPGJyPg0KJm5ic3A7Jm5ic3A7IG5lZ290aWF0aW5nIGEg RFRMUyBhc3NvY2lhdGlvbi6p9zxicj4NCk5FVzogJnF1b3Q7RW5kcG9pbnRzIE1VU1QgTk9UIHVz ZSB0aGUgU0RQICdjb25uZWN0aW9uJyBhdHRyaWJ1dGUgW1JGQzQxNDVdPGJyPg0Kd2l0aGluIHRo ZSBzYW1lIKn4bT2p+CBsaW5lIGluIHdoaWNoIHRoZXkgYXJlIG5lZ290aWF0aW5nIGEgRFRMUzxi cj4NCmFzc29jaWF0aW9uLqn3PGJyPg0KPGJyPg0KNykgU2VjdGlvbiA1LjM8YnI+DQpzL3JlY2Vp dmVzIGFuZCBvZmZlci9yZWNlaXZlcyBhbiBvZmZlcjxicj4NCnMvdG93YXJkcyB0aGUgdGhlIG9m ZmVyZXIvdG93YXJkcyB0aGUgb2ZmZXJlcjxicj4NCjxicj4NCjgpIFNlY3Rpb24gMTE8YnI+DQpJ QU5BIGNvbnNpZGVyYXRpb25zIHRvIGJlIHVwZGF0ZWQgYXMgUGF1bCBhbHJlYWR5IG5vdGVkLjxi cj4NCjxicj4NCkNoZWVycyw8YnI+DQpDaGFybGVzPGJyPg0KPGJyPg0KPGJyPg0KT24gMi81LzE2 LCA4OjI5IEFNLCAmcXVvdDttbXVzaWMgb24gYmVoYWxmIG9mIEZsZW1taW5nIEFuZHJlYXNlbiAo ZmFuZHJlYXMpJnF1b3Q7PGJyPg0KJmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZyI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJl Zj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+ZmFuZHJlYXNAY2lzY28uY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KPGJyPg0KJmd0O0dyZWV0aW5ncyBNTVVTSUM8YnI+DQomZ3Q7PGJyPg0KJmd0 O1RoaXMgaXMgdG8gYW5ub3VuY2UgYSAyIHdlZWsgV0dMQyBvbiB0aGUmbmJzcDsgZHJhZnQ6PGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMDYudHh0 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0wNi50 eHQ8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDthcyBQcm9wb3NlZCBTdGFuZGFyZC4gUGxlYXNlIHJl dmlldyBhbmQgcHJvdmlkZSBhbnkgY29tbWVudHMgeW91IG1heTxicj4NCiZndDtoYXZlIG9uIHRo ZSBkb2N1bWVudCBieSBGcmlkYXksIEZlYnJ1YXJ5IDE5LCAyMDE2LiBDb21tZW50cyBzaG91bGQg YmU8YnI+DQomZ3Q7c2VudCB0byB0aGUgZG9jdW1lbnQgYXV0aG9ycyBhbmQgdGhlIE1NVVNJQyBX RyBsaXN0LiBJZiB5b3UgcmV2aWV3IHRoZTxicj4NCiZndDtkb2N1bWVudCBidXQgZG8gbm90IGhh dmUgYW55IGNvbW1lbnRzLCBwbGVhc2Ugc2VuZCBhIG5vdGUgdG8gdGhhdCBlZmZlY3Q8YnI+DQom Z3Q7YXMgd2VsbC48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYW5rczxicj4NCiZndDs8YnI+DQomZ3Q7 LS0gRmxlbW1pbmcgKE1NVVNJQyBjby1jaGFpcik8YnI+DQomZ3Q7PGJyPg0KJmd0O19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O21tdXNpYyBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11 c2ljQGlldGYub3JnPC9hPjxicj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWM8L2E+PGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D2ED13B7677FAeckelcuciscocom_-- From nobody Fri Feb 19 14:28: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 098D41ACD36; Fri, 19 Feb 2016 14:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 khulUcg_wrvc; Fri, 19 Feb 2016 14:28:25 -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 BCC561A92BC; Fri, 19 Feb 2016 14:28: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 u1JMSOCs035129 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Feb 2016 16:28:25 -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-sdp-mux-attributes.all@ietf.org, "mmusic WG" Date: Fri, 19 Feb 2016 16:28:24 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sdp-mux-attributes-12 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, 19 Feb 2016 22:28:28 -0000 Hi, Here is my AD evaluation of draft-ietf-mmusic-sdp-mux-attributes-12. I would like at least the substantive section to be discussed before going to IETF last call. Thanks! Ben. ---------- # Substantive # - This is very long and detailed. Are the authors and chairs comfortable that all sections have had sufficient review? -4.0: It would be helpful to add a paragraph describing how these semantic groupings map to the categories. -4.2: I recommend choosing a category name that is not a 2119 keyword. Maybe something like "not mux-able" or "unsafe"? -4.3: Please don't use a 2119 keyword as part of the definition of a category. This creates sort of a circular dependency; that is attributes are in this category because they MUST be identical; but they MUST be identical because they are in this category. I suggest describing the category descriptively, and adding a separate sentence to say "Attributes in the IDENTICAL category MUST be identical across all media descriptions." -4.6: >"This in turn MAY place constraints on what constitutes a valid configuration from a multiplexing point of view, e.g. because some attributes MUST be IDENTICAL (see Section 14 for further details)." It seems like it would make sense to state that last sentence more strongly. Does it make sense to say something along the lines of "inherited attributes MUST be coherent."? -4.9: "For the purposes of implementations it is advised to consider "NOT RECOMMENDED" as the category when multiplexing these attributes." So why not have them in the NOT RECOMMENDED category, with an explanation that they have not been sufficiently analyzed? Or if you want to keep a separate category, you can say something like :"Attributes in the TBD category SHOULD NOT be multiplexed." -5.8 and 5.9: The last paragraph of 5.8 seems redundant with section 5.9. -5.8, last paragraph: "Hence multiplexing MUST NOT be performed even in this alternate scenario." seems to contradict the category selection of "NOT RECOMMENDED" (but see previous comment about not using 2119 keywords in a category title.) -5.14 Do you really expect to see such an "early mechanism" be multiplexed? -5.24, last paragraph: "it is recommended to consult the document defining the attribute." I assume one should _always_ refer to the specification of an SDP attribute before trying to mux it. But that doc is not going to explain muxing issues, is it? -5.26: -"Support of this extension is OPTIONAL." Please don't use 2119 keywords to describe existing requirements from other docs, unless in direct quotes. -Note: As stated, this is untrue. MSRP has the built in ability to share multiple sessions across the same transport connection. But I think your point is that there is no specification about how to demux MSRP from among _other_ protocols. The MUST in the last sentence does not seem appropriate. You can't really create a 2119 level requirement for people to do work in the future. I suggest s/"MUST be revisited"/"could be revisited" -5.28: Same comments as for 5.26. - 5.39: I’m not a zrtp expert, but it seems like it might be more complicated than this. Section 8 of 6189 says “The a=zrtp-hash attribute can only be included in the SDP at the media level since Hello messages sent in different media streams will have unique hashes.” I wonder if this shouldn't be “identical”? -5.40: I'm surprised that the comedia attributes are not "transport" -5.42: See previous comments about MUST level requirements for doing future work. (I think this recurs for some or all TBD sections.) -5.45: 6193 is an ISE stream RFC. Does anyone actually use in a context where muxing matters? - 5.57: See comments from 5.26 -15.1: - Is there no need for a spec for any newly registered categories? - 2nd to last paragraph: "This seems vague for a MUST. Do you expect the registration of a new category to change the categories already assigned to existing SDP parameters? Is it possible that a new category only applies to some new SDP parameters?" - Last paragraph: 4566 procedures apply to what? The text just said new categories are first-come-first server. I don’t think 4566 set policies for how to change mux categories. -15.2.1: How do you expect the table to look after adding this RFC to the references? Will this RFC be added to the entries in the MUX column? -16: - Do the assumptions for things like “fingerprint” and the zrtp hash not have security considerations since they force multiple media streams to share the same security associations? (Maybe that is covered by bundle?) - 2nd paragraph: There are more than one srtp keying mechanism—is this assumed true for all of them? # Editorial # - xml2rfc reports some outdated references. Are those intentional? - The abstract is more detailed than needed. The point is to describe the purpose of the draft. The second paragraph pretty much accomplishes that. - Please include table numbers. - 1: - First paragraph: s/"This would for e.g."/This would, for example," s/"has made necessary to understand"/"has made it necessary to understand" - 2nd paragraph: "Generic future-proof framework" - This seems excessive--can we just call it a framework? -3: - 1st paragraph, first sentence: Convoluted sentence. Can it be simplified? -4: - first and second bullet example lists are each missing "and". -4.2, first paragraph: Sentence fragment. (same for several category descriptions.) -4.4, first sentence: Spurious comma. -4.6, last paragraph: "In the above example, the category IDENTICAL is inherited for the cpar encapsulated rtcp-mux attribute." "For" doesn't seem like the right proposition. Is the category inherited "from" the cpar? "by" the cpar? -5 and subsections: Is there any method to the ordering? They aren't in RFC order. It might make sense to group by the nature of the attributes, but if that is the case here it's not explained. -5.4, note: "... due to inability in meeting the right resource reservations requested." I can't parse that clause. Does it mean "inability to meet the resource reservation request"? "Inability to determine the correct resource reservation request"? -5.8, last paragraph: - "None of this is standardized yet and it wouldn’t work as explained. " Does this mean that it has been explained why it wouldn't work? Or do you mean the way it is explained wouldn't work? -5.9: -s/"[RFC6773] document specifies"/"[RFC6773] specifies" - last paragraph: s/"can or cannot"/"may or may not" -5.13, table: "Specific RTP extension document MUST be referred" I don’t understand what that means. If you mean to say “refer to specific document”, that shouldn’t use MUST. -5.22, table: "document needs to be referred" (several repetitions) I'm not sure what this means. Should it say "Refer to the specific document"? -5.27, table: If the "MUST be globally unique" requirement refers to and existing requirment from 4583, please avoid 2119 language. -5.55: "... to be referred ..." I suggest "Refer to...." -6.3: "not clearly defined offer/answer usage" I'm not sure what is meant here. (Also, why is this not TBD or NOT RECOMMENDED?) -14.2.1, last paragraph: Do I understand this correctly to mean that the answerer can always fall back to a “common-to-all” config even if the offerer offered additional independent configs? -14.3: s/"...extends capability..."/"...extends the capability..." -14.3.1: "which MUST be followed here as well." If bundle-negotiation already requires identical pt values, isn’t this MUST redundant to that one? 14.3.2: I suspect that first MAY is a statement of fact, not a new requirement. -15, paragraph starting with "The IANA is requested to...": This sentence seems to belong with the next paragraph. From nobody Fri Feb 19 20:30:41 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 2663A1B39C4 for ; Fri, 19 Feb 2016 20:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6c8gY7XBmZm for ; Fri, 19 Feb 2016 20:30:36 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D88461B39C1 for ; Fri, 19 Feb 2016 20:30:36 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u1K4TTc8045024 for ; Fri, 19 Feb 2016 23:30:36 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 215hyqxmfs-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 19 Feb 2016 23:30:36 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1K4UZG0026761 for ; Fri, 19 Feb 2016 23:30:35 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1K4URsd026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 19 Feb 2016 23:30:28 -0500 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Sat, 20 Feb 2016 04:30:12 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.77]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 23:30:12 -0500 From: "DOLLY, MARTIN C" To: mmusic WG Thread-Topic: Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMA== Date: Sat, 20 Feb 2016 04:30:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.217.62] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615E419C0MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-20_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602200070 Archived-At: Cc: "LEWIS, DAVID G" , "SCHLEIN, EDWARD" Subject: [MMUSIC] Offer/Answer PT Questions 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, 20 Feb 2016 04:30:39 -0000 --_000_E42CCDDA6722744CB241677169E8365615E419C0MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello O/A lovers, Section 8.3.2 of RFC 3264 says the following: "However, in the case of RTP, the mapping from a particular dynamic payl= oad type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session." Now, assume the following case: 1. Alice sends an Offer, with the following PT values: PT 100: AMR-WB(mode-set=3D2) PT 111: AMR-WB(mode-set=3D2, OA) PT 0: PCMU 2. Bob sends the associated Answer: PT 100: AMR-WB (mode-set=3D2) PT 0: PCMU 3. Later Bob sends the following subsequent Offer: PT 111: AMR(mode-set=3D0,2,5,7) QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the subsequent= Offer, as Alice used PT 111 for AMR-WG in the initial Offer? In other word= s, does the pt-value-must-only-refer-to-a-specific-payload-for-the-stream-w= ithin-the-session text in section 8.3.2 apply to user A only, or to *all* u= sers within the session? QUESTION 2: Assuming the text applies to all users, is it allowed to re-u= se a PT value for the same codec, but for a different CODEC CONFIGURATION? = The text only talks about codec. Now, I agree that the easiest way to avoid trouble is simply to make sure P= T values aren't re-used by any party. But, the text still needs to be clear= , because this is causing problems in real deployments. Regards, Martin --_000_E42CCDDA6722744CB241677169E8365615E419C0MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello O/A lovers,

 

Section 8.3.2 of RFC 3264 says the following:

 

   “However, in the case of RTP, the= mapping from a particular dynamic payload type

   number to a particular codec within tha= t media stream MUST NOT change

   for the duration of a session.  Fo= r example, if A generates an offer

   with G.711 assigned to dynamic payload = type number 46, payload type

   number 46 MUST refer to G.711 from that= point forward in any offers

   or answers for that media stream within= the session.”

 

Now, assume the following case:

 

1.      Alice sends an Offer, with the following PT values:=

 

PT 100: AMR-WB(mode-set= =3D2)

PT 111: AMR-WB(mode-set= =3D2, OA)

PT 0: PCMU

 

2.      Bob sends the associated Answer:

 

PT 100: AMR-WB (mode-set= =3D2)

PT 0: PCMU

 

3.      Later Bob sends the following subsequent Offer:

 

PT 111: AMR(mode-set=3D0= ,2,5,7)

 

 

QUESTION 1: Is it allowed for Bob to offer PT 111 fo= r AMR in the subsequent Offer, as Alice used PT 111 for AMR-WG in the initi= al Offer? In other words, does the pt-value-must-only-refer-to-a-specific-p= ayload-for-the-stream-within-the-session text in section 8.3.2 apply to user A only, or to *all* users withi= n the session?

 

QUESTION 2:   Assuming the text applies to= all users, is it allowed to re-use a PT value for the same codec, but for = a different CODEC CONFIGURATION? The text only talks about codec.

 

Now, I agree that the easiest way to avoid trouble i= s simply to make sure PT values aren’t re-used by any party. But, the= text still needs to be clear, because this is causing problems in real dep= loyments.

 

Regards,

 

Martin

--_000_E42CCDDA6722744CB241677169E8365615E419C0MISOUT7MSGUSRDB_-- From nobody Sat Feb 20 00: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 DD8491A00C3 for ; Sat, 20 Feb 2016 00:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 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.006, 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 FvkXX5rEdcMX for ; Sat, 20 Feb 2016 00:09:03 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 F02D61A00BF for ; Sat, 20 Feb 2016 00:09:02 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id jq7so128220233obb.0 for ; Sat, 20 Feb 2016 00:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9ikcz6dXZF1rHZiGV0WGB3eeEUPGQLcWrG0MLpCEzeU=; b=jO1PDPsMqbpO/ByXWCu13DaZd3t/AnPboRgasrpjM+pzRtNwFfWmTVLQaMCKBAhSMO 8TM6ruRZh7uSzi4pi8uE/Bjbk8fn1G0J1tDtGHLczPTdg9xULMVHp/Xl657zXmuUG0uU bmK+aMrovzHJxSSgZBhmnjpcD9FIRqYxxarJGPXZCBjtYzpxzsIlilnS2OzQy2TTRkcy yhPnxy//kaeoqYjKxTKLRl5f9u8xthh7dHru4kzw2t1Iul2Y13+340lKIHanYixUlLfn 8WERcW5QUqtgM9Nega5/RLKiuOlG/ja7pvYtDliFv7e8UFU2J7fpiEwp0uwjan4bYo09 +TVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9ikcz6dXZF1rHZiGV0WGB3eeEUPGQLcWrG0MLpCEzeU=; b=Lwj/aCXAp1vuAjFPl0U6H2lZfVbFbXo38VJq5wJwv7j3egRns8kw7uPH/tSIbP0j0x 0jiF2Oly0ZXk9LRT5rsq1cNKqqWYWDqyTSPIDRvD33DJ39UebZxvYWBDePHYL03PuDcj kMrnCu6lgQNn0IxyvGrnBb9jsfHCPyhjMekyAa50IZEChO4SUSNWDBFC+SV6FGMFwG8I Ampqq+KLYGFl0YdvFWuTB7b/wAQRFc/liG6Umh51HFDIbfon8OZ3W6Q2/+HpzW9XMyY9 hf28zua3MJAc5l3tiBHHFO6UkVLnwwJ6ZWJ2bJeFsJJqbVL+QeQVt55ceqyycc89hw4Y B7Kg== X-Gm-Message-State: AG10YOQT6nMCCyY5LSW4Vmvfma9mhhSLjG33ZzDPXsW16iyRi7HLrvYE/uyTy3EtyWDKGa7czCWOSFMkyh8E+NSn X-Received: by 10.60.138.67 with SMTP id qo3mr14685734oeb.80.1455955742097; Sat, 20 Feb 2016 00:09:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.104.75 with HTTP; Sat, 20 Feb 2016 00:08:22 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Sat, 20 Feb 2016 00:08:22 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b2e465ad1558d052c2f1c12 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 20 Feb 2016 08:09:07 -0000 --047d7b2e465ad1558d052c2f1c12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 18, 2016 at 10:56 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Paul, > > >> Ok, so assuming the scope of this change would only be ICE, we could > >> say that shared ICE candidates don=E2=80=99t have to be associated wit= h each > >> m- line within a BUNDLE group =E2=80=93 it=E2=80=99s enough if they ar= e associated with > one m- line. > > > > I haven't been following this discussion closely, so forgive me if I > have misunderstood... > > Don't worry - there hasn't been much discussion :) > > > I see how it might be inconvenient to redundantly provide all the > candidates with each m-line. But at the least > > this exception will need very careful specification, or else it could > lead to very confusing implementations. > > Correct, and that's one reason I suggest that we limit the scope to ICE, > eventhough we probably could do the same thing for any IDENTICAL and > TRANSPORT category attribute. > =E2=80=8BWhile it would be nice to remove any duplication, the duplication = is particularly painful for ICE candidates, because there can be a lot of them, and because they change without any offer/answer action (thanks to trickle ICE). =E2=80=8B So if we just covered that candidates, we'd be get= ting most of the value. > > > (For instance, different subsets of the candidates associated with > different m-lines.) > > Note that we are talking about m- lines within a given BUNDLE group, wher= e > the same set of shared candidates apply to each m- line. There will be no > subset. > > > So if this is to be done, I think it should be quite restrictive. > > Perhaps either duplicate candidates with every m-line or else all the > candidates with only one m-line, and no candidates with any of the other > m-lines in the bundle. > > We could e.g. say that shared candidates MUST be placed in the m- line > representing the BUNDLE address (first mid in the mid list). Then we can > either forbid them to be placed elsewhere, or say that they can be > discarded if placed elsewhere. > > (Unique candidates must obviously always be explicitly placed in the m- > line they belong to.) > > > If in all m-lines of the offer then also in all accepted m-lines in the > answer. If in only one m-line in the offer, then only in the correspondin= g > m-line of the answer. > > > > Even then, what is to be done if the candidates are with only one of th= e > m-lines in the offer, and the answerer wants to reject *that* m-line but > > accept others in the bundle? Does the answerer pick a different m-line > to carry the candidates in the answer? > > Mandating the candidates in the m- line representing the BUNDLE address > would work, because that m- line always belongs to the BUNDLE group. > > Just allowing the candidates to only be in the m-line representing the BUNDLE is exactly what I was asking for. If you further *mandate* it, I can't complain. Sounds good to me. > Regards, > > Christer > > > > > Q1: Does this apply only to the SDP =E2=80=98candidate=E2=80=99 attribu= te, or also to > > other ICE-related SDP attributes? > > > > Q2: Is it a RECOMMENDED/SHOULD/MAY/MUST/MUST NOT? > > > > Now, if I don=E2=80=99t hear any feedback on this, I am NOT going to do= the > > change. Those who asked for this change (or otherwise have an opinion > > on it), please speak up now. > > > > Regards, > > > > Christer > > > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > > Holmberg > > *Sent:* 16. helmikuuta 2016 17:15 > > *To:* Peter Thatcher > > *Cc:* mmusic@ietf.org > > *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE > > > > Hi, > > > > We still need to conclude this issue before we can ship BUNDLE, so I=E2= =80=99d > > like to hear some input from people. I do intend to request agenda > > time to discuss it in Buenos Aires, but if we can find a solution > > before that there will be more time for cookies=E2=80=A6 > > > > Regards, > > > > Christer > > > > *From:*Peter Thatcher [mailto:pthatcher@google.com] > > *Sent:* 17. marraskuuta 2015 1:06 > > *To:* Christer Holmberg > > *Cc:* mmusic@ietf.org > > *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE > > > > On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg > > > > > > wrote: > > > > Hi, > > > > >> I thinking mandating the candidates be duplicated in the answer > > has three issues: > > >> > > >> 1. It conflicts with trickle ICE. > > >> 2. It's slightly more complex to implement (we have to go add > > extra logic to go duplicate these things) >> 3. It's a complete > > waste of time/space/effort. The recipient of these duplicate > > candidates is never going to anything with them. > > > > > > Those are all fair points. I wish we'd had more implementation > > input when we write our specs. > > > > > > That's what I'm providing now :). We can still change the spec, > > can't we? > > =E2=80=8B > > Sure. > > > > However, as we are talking about a design wise big (in my opinion) > > change, at a late stage, I'd like to hear what other people think. > > > > =E2=80=8BThat sounds fair. I'd like to hear what others think about th= is.=E2=80=8B > > > > =E2=80=8B > > > > > > >>>Also keep in mind that, when a subsequent offer is sent, the > > bundle-only attribute is no longer used. > > >> > > =E2=80=8B>>Can you point out where in the draft it says that? I tr= ied > > finding it and I had a difficult time seeing where bundle-only > > wasn't allowed in a reoffer.=E2=80=8B > > =E2=80=8B>> > > >> Section 8.5.1 says: > > >> > > >> "When an offerer generates a subsequent offer, it MUST > > assign the > > >> previously selected offerer BUNDLE address [Section > > 8.3.2], to each > > >> bundled "m=3D" line (including any bundle-only "m=3D" lin= e), > > except if:" > > >> > > >> And, as the usage of the attribute is only defined when the por= t > > value is zero, it would not work when the BUNDLE address (read: > > non-zero port) must be associated with the m- line. > > >> > > >> Section 6 says: > > >> > > >> "The usage of the 'bundle-only' attribute is only defined for= a > > >> bundled "m=3D" line with a zero port value, within an offer. > Other > > >> usage is unspecified." > > > > > =E2=80=8B> Thanks. That text would be more clear as "with an initi= al offer" > > instead of "whithin an offer", since that's what it really means in > > conjuction with 8.5.1. > > > > Ok. > > > > > However, that's precisely the text that I think we could change. > > I think we could change the bundle-only attribute to > > > be allowed in answers and in subsequent offers. Then clients > > could use the attribute as a way of avoiding duplication > > > of candidates and the complications with trickle ICE.=E2=80=8B > > > > Assuming we would remove the duplication of candidates, I don't > > think that would require us to change a semantics of the attribute. > > We could simply say that the candidates don't need to be duplicated > > in bundled m- lines, no matter if those m- lines are bundle-only or > not. > > > > That would work as well. > > > > =E2=80=8B > > > > > > >>>> Would you then also in the subsequent offer only assign > > possible candidates to only one m- line within the bundle group? > > >>> > > =E2=80=8B>>> That sounds logical to me. They aren't included in th= e first > > offer. Why add them to subsequent offers? It's inconsistent, and = a > > waste. > > >> > > >> Then someone could ask: what about other (non-candidate) > > attributes that must have identical values for each bundled m- line= ? > > Should those also be assigned to only one of the m- lines? > > > > > =E2=80=8B> If it's something unique to the bundle group, and not th= e m-line, > > that seems reasonable to me. =E2=80=8B > > =E2=80=8B> > > =E2=80=8B> But candidates are more painful than those would be beca= use of > > the interactions with trickle ICE. If it weren't for trickle ICE > > this wouldn't be as big of a deal.=E2=80=8B > > > > Correct. We just need to make it very clear whether it applies only > > to candidate attributes, or to attributes with identical values in > > general. > > > > >>>>>>>> 2. If the answerer does not include any candidates in th= e > > answer and instead trickles them later, should it trickle them > > >>>>>>>> N times (once for each m-line in the BUNDLE group) or >1 > > time? 1 time seems much more reasonable than N times, but > > >>>>>>>> if we duplicate candidates in the answer, but not > > duplicate them while trickling, that's a bit inconsistent. Yet > > >another reason to not duplicate in the answer :). > > >>>>>>> > > >>>>>>> Assuming you use SDP to signal the trickled candidates, > > it=E2=80=99s true that you would duplicate them, > > >>>>>>> > > >>>>>>=E2=80=8BWhat's the rationale for that? These duplicates pr= ovide no > > value, and in the case of many m-lines (such as a conferencing > > >>>>>>system with many participants), we could be talking about 30= x > > the number of candidates being signaled. > > >>>> > > >>>> I hear what you are saying. > > >>>> > > >>>> But, if we would do a change, we also need to look at the ful= l > > picture, and consider subsequent offers etc. > > >>> > > =E2=80=8B>>> I think a simple rule would be "if you know it's going= to be > > bundled onto another m-line, don't include > > >>> candidates". That would go for bundle-only m-lines in an > > offer, bundled m-lines in an answer, and bundled m-lines in a > re-offer.=E2=80=8B > > =E2=80=8B>>> > > >> Bundled m- lines in a re-offer can still be rejected by the > > answerer. > > > > > =E2=80=8B> That sounds the same as an initial offer. How does it i= mply that > > a re-offer must duplicate > > > candidates across m-lines, even when an initial offer doesn't > > need to?=E2=80=8B > > =E2=80=8B > > In the initial offer each m- line contains candidates (unique). If > > an m- line in the offer is rejected, the answerer must select the > > offerer BUNDLE address (and the associated candidiates) from anothe= r > > m- line. > > > > Now, in a re-offer, if the m- line containing the candidates is > > rejected, the answerer needs to include its candidates in another m= - > > line in the answer. That's doable, but it would need to be clearly > > documented. In other words: it needs to be clear that the candidate= s > > can occur in ANY of the bundled m- lines, and that m- line may > > change between offers and answers. > > > > =E2=80=8BSo a rule of "the candidates can be in any one of the m-lines,= and it > > doesn't matter which, and it can change any time". That seems > > reasonable to me. It leave the most flexibility to the one writing > > the SDP, and it's very easy to implement for the one reading the SDP.= =E2=80=8B > > > > > > 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 > --047d7b2e465ad1558d052c2f1c12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 18, 2016 at 10:56 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Paul,

>> Ok, so assuming the scope of this change would only be ICE, we cou= ld
>> say that shared ICE candidates don=E2=80=99t have to be associated= with each
>> m- line within a BUNDLE group =E2=80=93 it=E2=80=99s enough if the= y are associated with one m- line.
>
> I haven't been following this discussion closely, so forgive me if= I have misunderstood...

Don't worry - there hasn't been much discussion :)

> I see how it might be inconvenient to redundantly provide all the cand= idates with each m-line. But at the least
> this exception will need very careful specification, or else it could = lead to very confusing implementations.

Correct, and that's one reason I suggest that we limit the scope= to ICE, eventhough we probably could do the same thing for any IDENTICAL a= nd TRANSPORT category attribute.

=E2= =80=8BWhile it would be nice to remove any duplication, the duplication is = particularly painful for ICE candidates, because there can be a lot of them= , and because they change without any offer/answer action (thanks to trickl= e ICE). =E2=80=8B =C2=A0So if we just covered that candidates, we'd be = getting most of the value.
=C2=A0

> (For instance, different subsets of the candidates associated with dif= ferent m-lines.)

Note that we are talking about m- lines within a given BUNDLE group,= where the same set of shared candidates apply to each m- line. There will = be no subset.

> So if this is to be done, I think it should be quite restrictive.
> Perhaps either duplicate candidates with every m-line or else all the = candidates with only one m-line, and no candidates with any of the other m-= lines in the bundle.

We could e.g. say that shared candidates MUST be placed in the m- li= ne representing the BUNDLE address (first mid in the mid list). Then we can= either forbid them to be placed elsewhere, or say that they can be discard= ed if placed elsewhere.

(Unique candidates must obviously always be explicitly placed in the m- lin= e they belong to.)

> If in all m-lines of the offer then also in all accepted m-lines in th= e answer. If in only one m-line in the offer, then only in the correspondin= g m-line of the answer.
>
> Even then, what is to be done if the candidates are with only one of t= he m-lines in the offer, and the answerer wants to reject *that* m-line but=
> accept others in the bundle? Does the answerer pick a different m-line= to carry the candidates in the answer?

Mandating the candidates in the m- line representing the BUNDLE addr= ess would work, because that m- line always belongs to the BUNDLE group.

Just allowing the candidates to onl= y be in the m-line representing the BUNDLE is exactly what I was asking for= .=C2=A0 If you further *mandate* it, I can't complain.=C2=A0 Sounds goo= d to me.

=C2=A0
Regards,

Christer



> Q1: Does this apply only to the SDP =E2=80=98candidate=E2=80=99 attrib= ute, or also to
> other ICE-related SDP attributes?
>
> Q2: Is it a RECOMMENDED/SHOULD/MAY/MUST/MUST NOT?
>
> Now, if I don=E2=80=99t hear any feedback on this, I am NOT going to d= o the
> change. Those who asked for this change (or otherwise have an opinion<= br> > on it), please speak up now.
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:mmusi= c-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 16. helmikuuta 2016 17:15
> *To:* Peter Thatcher
> *Cc:* mmusic@ietf.org
> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> Hi,
>
> We still need to conclude this issue before we can ship BUNDLE, so I= =E2=80=99d
> like to hear some input from people. I do intend to request agenda
> time to discuss it in Buenos Aires, but if we can find a solution
> before that there will be more time for cookies=E2=80=A6
>
> Regards,
>
> Christer
>
> *From:*Peter Thatcher [mailto:= pthatcher@google.com]
> *Sent:* 17. marraskuuta 2015 1:06
> *To:* Christer Holmberg
> *Cc:* mmusic@ietf.org <mailt= o:mmusic@ietf.org>
> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg
> <christer.holmber= g@ericsson.com
> <mailto:christer.= holmberg@ericsson.com>>
> wrote:
>
> Hi,
>
>=C2=A0 >> I thinking mandating the candidates be duplicated in th= e answer
> has three issues:
>=C2=A0 >>
>=C2=A0 >> 1.=C2=A0 It conflicts with trickle ICE.
>=C2=A0 >> 2.=C2=A0 It's slightly more complex to implement (w= e have to go add
> extra logic to go duplicate these things)=C2=A0 >> 3.=C2=A0 It&#= 39;s a complete
> waste of time/space/effort.=C2=A0 The recipient of these duplicate
> candidates is never going to anything with them.
>=C2=A0 >
>=C2=A0 > Those are all fair points. I wish we'd had more impleme= ntation
> input when we write our specs.
>=C2=A0 >
>=C2=A0 > That's what I'm providing now :).=C2=A0 We can stil= l change the spec,
> can't we?
> =E2=80=8B
> Sure.
>
> However, as we are talking about a design wise big (in my opinion)
> change, at a late stage, I'd like to hear what other people think.=
>
> =E2=80=8BThat sounds fair.=C2=A0 I'd like to hear what others thin= k about this.=E2=80=8B
>
> =E2=80=8B
>
>
>=C2=A0 =C2=A0 =C2=A0 >>>Also keep in mind that, when a subsequ= ent offer is sent, the
>=C2=A0 =C2=A0 =C2=A0bundle-only attribute is no longer used.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B>>Can you point out where in the dra= ft it says that?=C2=A0 I tried
>=C2=A0 =C2=A0 =C2=A0finding it and I had a difficult time seeing where = bundle-only
>=C2=A0 =C2=A0 =C2=A0wasn't allowed in a reoffer.=E2=80=8B
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B>>
>=C2=A0 =C2=A0 =C2=A0 >> Section 8.5.1 says:
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "When an = offerer generates a subsequent offer, it MUST
>=C2=A0 =C2=A0 =C2=A0assign the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0previously sele= cted offerer BUNDLE address [Section
>=C2=A0 =C2=A0 =C2=A08.3.2], to each
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0bundled "m= =3D" line (including any bundle-only "m=3D" line),
>=C2=A0 =C2=A0 =C2=A0except if:"
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> And, as the usage of the attribute is onl= y defined when the port
>=C2=A0 =C2=A0 =C2=A0value is zero, it would not work when the BUNDLE ad= dress (read:
>=C2=A0 =C2=A0 =C2=A0non-zero port) must be associated with the m- line.=
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Section 6 says:
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0"The usage of the 'b= undle-only' attribute is only defined for a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0bundled "m=3D" line= with a zero port value, within an offer.=C2=A0 Other
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0usage is unspecified." >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B> Thanks.=C2=A0 That text would be more= clear as "with an initial offer"
>=C2=A0 =C2=A0 =C2=A0instead of "whithin an offer", since that= 's what it really means in
>=C2=A0 =C2=A0 =C2=A0conjuction with 8.5.1.
>
>=C2=A0 =C2=A0 =C2=A0Ok.
>
>=C2=A0 =C2=A0 =C2=A0 > However, that's precisely the text that I= think we could change.
>=C2=A0 =C2=A0 =C2=A0I think we could change the bundle-only attribute t= o
>=C2=A0 =C2=A0 =C2=A0 > be allowed in answers and in subsequent offer= s.=C2=A0 Then clients
>=C2=A0 =C2=A0 =C2=A0could use the attribute as a way of avoiding duplic= ation
>=C2=A0 =C2=A0 =C2=A0 > of candidates and the complications with tric= kle ICE.=E2=80=8B
>
>=C2=A0 =C2=A0 =C2=A0Assuming we would remove the duplication of candida= tes, I don't
>=C2=A0 =C2=A0 =C2=A0think that would require us to change a semantics o= f the attribute.
>=C2=A0 =C2=A0 =C2=A0We could simply say that the candidates don't n= eed to be duplicated
>=C2=A0 =C2=A0 =C2=A0in bundled m- lines, no matter if those m- lines ar= e bundle-only or not.
>
> That would work as well.
>
> =E2=80=8B
>
>
>=C2=A0 =C2=A0 =C2=A0 >>>> Would you then also in the subseq= uent offer only assign
>=C2=A0 =C2=A0 =C2=A0possible candidates to only one m- line within the = bundle group?
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B>>> That sounds logical to me.=C2= =A0 They aren't included in the first
>=C2=A0 =C2=A0 =C2=A0offer.=C2=A0 Why add them to subsequent offers?=C2= =A0 It's inconsistent, and a
>=C2=A0 =C2=A0 =C2=A0waste.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Then someone could ask: what about other = (non-candidate)
>=C2=A0 =C2=A0 =C2=A0attributes that must have identical values for each= bundled m- line?
>=C2=A0 =C2=A0 =C2=A0Should those also be assigned to only one of the m-= lines?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B> If it's something unique to the b= undle group, and not the m-line,
>=C2=A0 =C2=A0 =C2=A0that seems reasonable to me.=C2=A0 =E2=80=8B
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B>
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B> But candidates are more painful than = those would be because of
>=C2=A0 =C2=A0 =C2=A0the interactions with trickle ICE.=C2=A0 If it were= n't for trickle ICE
>=C2=A0 =C2=A0 =C2=A0this wouldn't be as big of a deal.=E2=80=8B
>
>=C2=A0 =C2=A0 =C2=A0Correct. We just need to make it very clear whether= it applies only
>=C2=A0 =C2=A0 =C2=A0to candidate attributes, or to attributes with iden= tical values in
>=C2=A0 =C2=A0 =C2=A0general.
>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>> 2.=C2=A0 If the a= nswerer does not include any candidates in the
>=C2=A0 =C2=A0 =C2=A0answer and instead trickles them later, should it t= rickle them
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>> N times (once for= each m-line in the BUNDLE group) or >1
>=C2=A0 =C2=A0 =C2=A0time?=C2=A0 1 time seems much more reasonable than = N times, but
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>> if we duplicate c= andidates in the answer, but not
>=C2=A0 =C2=A0 =C2=A0duplicate them while trickling, that's a bit in= consistent.=C2=A0 Yet
>=C2=A0 =C2=A0 =C2=A0 >another reason to not duplicate in the answer = :).
>=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>> Assuming you use SDP = to signal the trickled candidates,
>=C2=A0 =C2=A0 =C2=A0it=E2=80=99s true that you would duplicate them, >=C2=A0 =C2=A0 =C2=A0 >>>>>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>>>=E2=80=8BWhat's the ra= tionale for that?=C2=A0 These duplicates provide no
>=C2=A0 =C2=A0 =C2=A0value, and in the case of many m-lines (such as a c= onferencing
>=C2=A0 =C2=A0 =C2=A0 >>>>>>system with many participa= nts), we could be talking about 30x
>=C2=A0 =C2=A0 =C2=A0the number of candidates being signaled.
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> I hear what you are saying.
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> But, if we would do a change, we = also need to look at the full
>=C2=A0 =C2=A0 =C2=A0picture, and consider subsequent offers etc.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B>>> I think a simple rule would b= e "if you know it's going to be
>=C2=A0 =C2=A0 =C2=A0bundled onto another m-line, don't include
>=C2=A0 =C2=A0 =C2=A0 >>> candidates".=C2=A0 That would go= for bundle-only m-lines in an
>=C2=A0 =C2=A0 =C2=A0offer, bundled m-lines in an answer, and bundled m-= lines in a re-offer.=E2=80=8B
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B>>>
>=C2=A0 =C2=A0 =C2=A0 >> Bundled m- lines in a re-offer can still = be rejected by the
>=C2=A0 =C2=A0 =C2=A0answerer.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B> That sounds the same as an initial of= fer.=C2=A0 How does it imply that
>=C2=A0 =C2=A0 =C2=A0a re-offer must duplicate
>=C2=A0 =C2=A0 =C2=A0 > candidates across m-lines, even when an initi= al offer doesn't
>=C2=A0 =C2=A0 =C2=A0need to?=E2=80=8B
>=C2=A0 =C2=A0 =C2=A0=E2=80=8B
>=C2=A0 =C2=A0 =C2=A0In the initial offer each m- line contains candidat= es (unique). If
>=C2=A0 =C2=A0 =C2=A0an m- line in the offer is rejected, the answerer m= ust select the
>=C2=A0 =C2=A0 =C2=A0offerer BUNDLE address (and the associated candidia= tes) from another
>=C2=A0 =C2=A0 =C2=A0m- line.
>
>=C2=A0 =C2=A0 =C2=A0Now, in a re-offer, if the m- line containing the c= andidates is
>=C2=A0 =C2=A0 =C2=A0rejected, the answerer needs to include its candida= tes in another m-
>=C2=A0 =C2=A0 =C2=A0line in the answer. That's doable, but it would= need to be clearly
>=C2=A0 =C2=A0 =C2=A0documented. In other words: it needs to be clear th= at the candidates
>=C2=A0 =C2=A0 =C2=A0can occur in ANY of the bundled m- lines, and that = m- line may
>=C2=A0 =C2=A0 =C2=A0change between offers and answers.
>
> =E2=80=8BSo a rule of "the candidates can be in any one of the m-= lines, and it
> doesn't matter which, and it can change any time".=C2=A0 That= seems
> reasonable to me.=C2=A0 It leave the most flexibility to the one writi= ng
> the SDP, and it's very easy to implement for the one reading the S= DP.=E2=80=8B
>
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0Christer
>
>
>
> _______________________________________________
> 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

--047d7b2e465ad1558d052c2f1c12-- From nobody Sat Feb 20 09:17: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 000D71A9124 for ; Sat, 20 Feb 2016 09:16:59 -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 igFY1Vvpauyz for ; Sat, 20 Feb 2016 09:16:58 -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 8910F1A8747 for ; Sat, 20 Feb 2016 09:16:56 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with comcast id LhGn1s00327uzMh01hGv9Q; Sat, 20 Feb 2016 17:16:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with comcast id LhGv1s00H3KdFy101hGvjV; Sat, 20 Feb 2016 17:16:55 +0000 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: <56C89F86.7020401@alum.mit.edu> Date: Sat, 20 Feb 2016 12:16:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: 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=1455988615; bh=/xWzx2Dtwp4HFWDjWQMPZb1eCLKW99K38+9mYB/YHKI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UtkBdWA5jYQGvDYZCCJGbqEEQMTks2Ch2eWPypzLb4rpTBnn+TW6cpmYdyXwwNUDl Gtx6pLm1USXLoWUBwzFQa43LkUzCfKqwe36uF/6IYeXUs99kBaKxm0/VJ0lFKdH0KT VSV5rdFQ1L117PqRQh3vTsLsY4ChwAEpNU3gzpooixQMywAgLQl6gYz5nLrgeR98ik QjYEv0onDC4JlxZ4TnwohZLYniSAvXl5I5Z/KawIGp+sveMabAguKi1379fv7iavOw HWiPA2v20WfOLsBg27KpXw/B6azauaCcVmwb735+sYilnEctkDYcdyXWo7aWGubH6t YWI/RdrZDQE9A== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 20 Feb 2016 17:17:00 -0000 On 2/19/16 11:30 PM, DOLLY, MARTIN C wrote: > Hello O/A lovers, > > Section 8.3.2 of RFC 3264 says the following: > > However, in the case of RTP, the mapping from a particular dynamic > payload type > > number to a particular codec within that media stream MUST NOT change > > for the duration of a session. For example, if A generates an offer > > with G.711 assigned to dynamic payload type number 46, payload type > > number 46 MUST refer to G.711 from that point forward in any offers > > or answers for that media stream within the session. As you know, this area is not well defined. > Now, assume the following case: > > 1.Alice sends an Offer, with the following PT values: > > PT 100: AMR-WB(mode-set=2) > > PT 111: AMR-WB(mode-set=2, OA) > > PT 0: PCMU > > 2.Bob sends the associated Answer: > > PT 100: AMR-WB (mode-set=2) > > PT 0: PCMU At this point, I think there is an open question of whether the "must not change" even applies for a PT that was offered but not accepted in the answer. One might argue that the real point of the requirement is that it can't be reused once there might be packets in flight using it. But that isn't true in this case. So IMO it is uncharted territory. > 3.Later Bob sends the following subsequent Offer: > > PT 111: AMR(mode-set=0,2,5,7) You mean the new offer no longer mentions 0 and 100, only 111 with this new mapping? (Though I don't think the answer to that affects your questions.) > QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the > subsequent Offer, as Alice used PT 111 for AMR-WG in the initial Offer? > In other words, does the > pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-the-session > text in section 8.3.2 apply to user A only, or to **all** users within > the session? While it is *recommended* that the answer use the same PT as the offer for a given codec configuration, that isn't *required*. The answer may accept the codec from the offer using a different PT. So, in the first answer Bob *could* have accepted the offer for AMR-WB(mode-set=2, OA) using some other PT (say 112). If so, when Bob subsequently sent an offer reusing the same codecs it would have used 100, 112, and 0. (111 would not have been used.) In that case it seems like Bob would be free to use 111 for something else. Alice, in her answer, would be free to map it to a different PT in order to avoid a clash with 111 on her end. All of that seems equally applicable in your example, where Bob never accepted AMR-WB(mode-set=2, OA). > QUESTION 2: Assuming the text applies to all users, is it allowed to > re-use a PT value for the same codec, but for a different CODEC > CONFIGURATION? The text only talks about codec. I think use of "codec" was just sloppy, and that it always meant codec configuration. > Now, I agree that the easiest way to avoid trouble is simply to make > sure PT values arent re-used by any party. But, the text still needs to > be clear, because this is causing problems in real deployments. Agree. The spec is far from clear on this subject. A starting point for clarifying it to ascertain as best we can the original intent. But then we also need to try to understand common practice. Where this has been unclear there may well be conflicting interpretations in the wild. *Somebody* is likely to be negatively affected by whatever decision we come to. Thanks, Paul P.S. Martin: maybe you have found a subject where we can agree. From nobody Sat Feb 20 09:58:24 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 D52211ACE06 for ; Sat, 20 Feb 2016 09:58:22 -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 l-CdUCnaa2dC for ; Sat, 20 Feb 2016 09:58:20 -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 39EB71ACE05 for ; Sat, 20 Feb 2016 09:58:19 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-7a-56c8a9394f1d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.30.02707.939A8C65; Sat, 20 Feb 2016 18:58:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Sat, 20 Feb 2016 18:57:34 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75iggAA8gYCAADDekIACZK0AgACy7bA= Date: Sat, 20 Feb 2016 17:57:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@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+NgFprIIsWRmVeSWpSXmKPExsUyM2K7iq7lyhNhBm/+CllMXf6YxWLFhgOs FteWv2Z1YPb4+/4Dk8eCTaUeS5b8ZApgjuKySUnNySxLLdK3S+DK+HvqEEvBv6KKA49WsTUw thR0MXJySAiYSHx+dJoNwhaTuHBvPZDNxSEkcJhR4sH/uewQzmJGibs79jB3MXJwsAlYSHT/ 0wZpEBHQlJg8uZkVxGYW8JV4ueALM4gtLOAgsefJVnaIGkeJOSvOgQ0VEehilFhy/yJYA4uA qsSap0/BGniBmo/dvwe1bCO7xOMlh5hAEpwCgRJnb1xgBLEZgc77fmoNE8Q2cYlbT+YzQZwt ILFkz3lmCFtU4uXjf6wQtpLEiu2XGEGOZga6dP0ufYhWRYkp3Q/ZIfYKSpyc+YRlAqPYLCRT ZyF0zELSMQtJxwJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgRF1cMtvgx2ML587HmIU 4GBU4uE1SDseJsSaWFZcmXuIUYKDWUmEN2PiiTAh3pTEyqrUovz4otKc1OJDjNIcLErivKud 14cJCaQnlqRmp6YWpBbBZJk4OKUaGNdOd3zYV/GM+dhuoVD5W9+yb53Z3mzgfoY/tjioqN7m 2Sn9++f+nfdTO9u448/vMLtoNkZZiwc+pm/0SrL++PpO3vQ9UUJn/lzhsn8q9wp3LhVxYBbT qY9o+2STurJHWG8jm893R8s1VY9XPYw3yed9xiwcaiTdbn1TtX7qxBW2Or/jelcyKbEUZyQa ajEXFScCAF/AkjikAgAA Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 20 Feb 2016 17:58:23 -0000 SGkgUGV0ZXIsDQoNCj4+PiBJIHNlZSBob3cgaXQgbWlnaHQgYmUgaW5jb252ZW5pZW50IHRvIHJl ZHVuZGFudGx5IHByb3ZpZGUgYWxsIHRoZSBjYW5kaWRhdGVzIHdpdGggZWFjaCBtLWxpbmUuIEJ1 dCBhdCB0aGUgbGVhc3QNCj4+PiB0aGlzIGV4Y2VwdGlvbiB3aWxsIG5lZWQgdmVyeSBjYXJlZnVs IHNwZWNpZmljYXRpb24sIG9yIGVsc2UgaXQgY291bGQgbGVhZCB0byB2ZXJ5IGNvbmZ1c2luZyBp bXBsZW1lbnRhdGlvbnMuDQo+Pg0KPj4gQ29ycmVjdCwgYW5kIHRoYXQncyBvbmUgcmVhc29uIEkg c3VnZ2VzdCB0aGF0IHdlIGxpbWl0IHRoZSBzY29wZSB0byBJQ0UsIGV2ZW50aG91Z2ggd2UgcHJv YmFibHkgDQo+PiBjb3VsZCBkbyB0aGUgc2FtZSB0aGluZyBmb3IgYW55IElERU5USUNBTCBhbmQg VFJBTlNQT1JUIGNhdGVnb3J5IGF0dHJpYnV0ZS4NCj4NCuKAiz4gV2hpbGUgaXQgd291bGQgYmUg bmljZSB0byByZW1vdmUgYW55IGR1cGxpY2F0aW9uLCB0aGUgZHVwbGljYXRpb24gaXMgcGFydGlj dWxhcmx5IHBhaW5mdWwgZm9yIElDRSBjYW5kaWRhdGVzLCBiZWNhdXNlIA0KPiB0aGVyZSBjYW4g YmUgYSBsb3Qgb2YgdGhlbSwgYW5kIGJlY2F1c2UgdGhleSBjaGFuZ2Ugd2l0aG91dCBhbnkgb2Zm ZXIvYW5zd2VyIGFjdGlvbiAodGhhbmtzIHRvIHRyaWNrbGUgSUNFKS4g4oCLIMKgDQo+IFNvIGlm IHdlIGp1c3QgY292ZXJlZCB0aGF0IGNhbmRpZGF0ZXMsIHdlJ2QgYmUgZ2V0dGluZyBtb3N0IG9m IHRoZSB2YWx1ZS4NCsKgDQpBc3N1bWluZyB0aGUgc2NvcGUgaXMgSUNFLCBzaG91bGRuJ3QgdGhl IHNhbWUgc3RpbGwgYXBwbHkgYWxzbyB0byBvdGhlciBJQ0UgcmVsYXRlZCBhdHRyaWJ1dGVzPyBJ IGFzc3VtZSB0aGUgdmFsdWVzIGZvciB0aGUgInJlbW90ZS1jYW5kaWRhdGVzIiwgICJpY2UtbGl0 ZSIsICJpY2UtbWlzbWF0Y2giLCAiaWNlLXVmcmFnIiwgImljZS1wd2QiLCAiaWNlLXBhY2luZyIg YW5kICJpY2Utb3B0aW9ucyIgYXR0cmlidXRlcyB3aWxsIGJlIGlkZW50aWNhbCB3aXRoaW4gYSBC VU5ETEUgZ3JvdXAsIHNvLi4uDQoNCi4uLg0KDQo+PiBJZiBpbiBhbGwgbS1saW5lcyBvZiB0aGUg b2ZmZXIgdGhlbiBhbHNvIGluIGFsbCBhY2NlcHRlZCBtLWxpbmVzIGluIHRoZSBhbnN3ZXIuIElm IGluIG9ubHkgb25lIG0tbGluZSBpbiB0aGUgb2ZmZXIsIHRoZW4gb25seSBpbiB0aGUgY29ycmVz cG9uZGluZyBtLWxpbmUgb2YgdGhlIGFuc3dlci4NCj4+DQo+PiBFdmVuIHRoZW4sIHdoYXQgaXMg dG8gYmUgZG9uZSBpZiB0aGUgY2FuZGlkYXRlcyBhcmUgd2l0aCBvbmx5IG9uZSBvZiB0aGUgbS1s aW5lcyBpbiB0aGUgb2ZmZXIsIGFuZCB0aGUgYW5zd2VyZXIgd2FudHMgdG8gcmVqZWN0ICp0aGF0 KiBtLWxpbmUgYnV0DQo+PiBhY2NlcHQgb3RoZXJzIGluIHRoZSBidW5kbGU/IERvZXMgdGhlIGFu c3dlcmVyIHBpY2sgYSBkaWZmZXJlbnQgbS1saW5lIHRvIGNhcnJ5IHRoZSBjYW5kaWRhdGVzIGlu IHRoZSBhbnN3ZXI/DQo+DQo+IE1hbmRhdGluZyB0aGUgY2FuZGlkYXRlcyBpbiB0aGUgbS0gbGlu ZSByZXByZXNlbnRpbmcgdGhlIEJVTkRMRSBhZGRyZXNzIHdvdWxkIHdvcmssIGJlY2F1c2UgdGhh dCBtLSBsaW5lIGFsd2F5cyBiZWxvbmdzIHRvIHRoZSBCVU5ETEUgZ3JvdXAuDQo+DQo+IEp1c3Qg YWxsb3dpbmcgdGhlIGNhbmRpZGF0ZXMgdG8gb25seSBiZSBpbiB0aGUgbS1saW5lIHJlcHJlc2Vu dGluZyB0aGUgQlVORExFIGlzIGV4YWN0bHkgd2hhdCBJIHdhcyBhc2tpbmcgZm9yLsKgIElmIHlv dSBmdXJ0aGVyICptYW5kYXRlKiBpdCwgSSBjYW4ndCBjb21wbGFpbi7CoCBTb3VuZHMgZ29vZCB0 byBtZS4NCg0KVW5sZXNzIHNvbWVvbmUgb2JqZWN0cywgKm9ubHkqIGFsbG93aW5nIGluIHRoZSBt LSBsaW5lIHJlcHJlc2VudGluZyB0aGUgQlVORExFIGFkZHJlc3MgbWFrZXMgdGhpbmdzIGVhc2ll ciA6KQ0KDQooT2YgY291cnNlLCBhIGdvb2QgaW1wbGVtZW50YXRpb24gc2hvdWxkIHN0aWxsIGJl IGFibGUgdG8gaGFuZGxlIGEgY2FzZSB3aGVuIGl0IHJlY2VpdmVzIGFuIG9mZmVyL2Fuc3dlciB3 aXRoIHRoZSBjYW5kaWRhdGVzIGluIG11bHRpcGxlIG0tIGxpbmVzIHdpdGhpbiB0aGUgQlVORExF IGdyb3VwLikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo+ IFExOiBEb2VzIHRoaXMgYXBwbHkgb25seSB0byB0aGUgU0RQIOKAmGNhbmRpZGF0ZeKAmSBhdHRy aWJ1dGUsIG9yIGFsc28gdG8NCj4gb3RoZXIgSUNFLXJlbGF0ZWQgU0RQIGF0dHJpYnV0ZXM/DQo+ DQo+IFEyOiBJcyBpdCBhIFJFQ09NTUVOREVEL1NIT1VMRC9NQVkvTVVTVC9NVVNUIE5PVD8NCj4N Cj4gTm93LCBpZiBJIGRvbuKAmXQgaGVhciBhbnkgZmVlZGJhY2sgb24gdGhpcywgSSBhbSBOT1Qg Z29pbmcgdG8gZG8gdGhlDQo+IGNoYW5nZS4gVGhvc2Ugd2hvIGFza2VkIGZvciB0aGlzIGNoYW5n ZSAob3Igb3RoZXJ3aXNlIGhhdmUgYW4gb3Bpbmlvbg0KPiBvbiBpdCksIHBsZWFzZSBzcGVhayB1 cCBub3cuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+ICpGcm9tOiptbXVzaWMg W21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqQ2hyaXN0ZXIN Cj4gSG9sbWJlcmcNCj4gKlNlbnQ6KiAxNi4gaGVsbWlrdXV0YSAyMDE2IDE3OjE1DQo+ICpUbzoq IFBldGVyIFRoYXRjaGVyDQo+ICpDYzoqIG1tdXNpY0BpZXRmLm9yZw0KPiAqU3ViamVjdDoqIFJl OiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQgSUNFIGNhbmRpZGF0ZXMgd2l0aCBCVU5ETEUNCj4N Cj4gSGksDQo+DQo+IFdlIHN0aWxsIG5lZWQgdG8gY29uY2x1ZGUgdGhpcyBpc3N1ZSBiZWZvcmUg d2UgY2FuIHNoaXAgQlVORExFLCBzbyBJ4oCZZA0KPiBsaWtlIHRvIGhlYXIgc29tZSBpbnB1dCBm cm9tIHBlb3BsZS4gSSBkbyBpbnRlbmQgdG8gcmVxdWVzdCBhZ2VuZGENCj4gdGltZSB0byBkaXNj dXNzIGl0IGluIEJ1ZW5vcyBBaXJlcywgYnV0IGlmIHdlIGNhbiBmaW5kIGEgc29sdXRpb24NCj4g YmVmb3JlIHRoYXQgdGhlcmUgd2lsbCBiZSBtb3JlIHRpbWUgZm9yIGNvb2tpZXPigKYNCj4NCj4g UmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gKkZyb206KlBldGVyIFRoYXRjaGVyIFttYWls dG86cHRoYXRjaGVyQGdvb2dsZS5jb21dDQo+ICpTZW50OiogMTcuIG1hcnJhc2t1dXRhIDIwMTUg MTowNg0KPiAqVG86KiBDaHJpc3RlciBIb2xtYmVyZw0KPiAqQ2M6KiBtbXVzaWNAaWV0Zi5vcmcg PG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQo+ICpTdWJqZWN0OiogUmU6IFtNTVVTSUNdIFF1ZXN0 aW9ucyBhYm91dCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEJVTkRMRQ0KPg0KPiBPbiBNb24sIE5vdiAx NiwgMjAxNSBhdCAyOjU4IFBNLCBDaHJpc3RlciBIb2xtYmVyZw0KPiA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tDQo+IDxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pj4NCj4gd3JvdGU6DQo+DQo+IEhpLA0KPg0KPsKgID4+IEkgdGhpbmtpbmcgbWFuZGF0aW5nIHRo ZSBjYW5kaWRhdGVzIGJlIGR1cGxpY2F0ZWQgaW4gdGhlIGFuc3dlcg0KPiBoYXMgdGhyZWUgaXNz dWVzOg0KPsKgID4+DQo+wqAgPj4gMS7CoCBJdCBjb25mbGljdHMgd2l0aCB0cmlja2xlIElDRS4N Cj7CoCA+PiAyLsKgIEl0J3Mgc2xpZ2h0bHkgbW9yZSBjb21wbGV4IHRvIGltcGxlbWVudCAod2Ug aGF2ZSB0byBnbyBhZGQNCj4gZXh0cmEgbG9naWMgdG8gZ28gZHVwbGljYXRlIHRoZXNlIHRoaW5n cynCoCA+PiAzLsKgIEl0J3MgYSBjb21wbGV0ZQ0KPiB3YXN0ZSBvZiB0aW1lL3NwYWNlL2VmZm9y dC7CoCBUaGUgcmVjaXBpZW50IG9mIHRoZXNlIGR1cGxpY2F0ZQ0KPiBjYW5kaWRhdGVzIGlzIG5l dmVyIGdvaW5nIHRvIGFueXRoaW5nIHdpdGggdGhlbS4NCj7CoCA+DQo+wqAgPiBUaG9zZSBhcmUg YWxsIGZhaXIgcG9pbnRzLiBJIHdpc2ggd2UnZCBoYWQgbW9yZSBpbXBsZW1lbnRhdGlvbg0KPiBp bnB1dCB3aGVuIHdlIHdyaXRlIG91ciBzcGVjcy4NCj7CoCA+DQo+wqAgPiBUaGF0J3Mgd2hhdCBJ J20gcHJvdmlkaW5nIG5vdyA6KS7CoCBXZSBjYW4gc3RpbGwgY2hhbmdlIHRoZSBzcGVjLA0KPiBj YW4ndCB3ZT8NCj4g4oCLDQo+IFN1cmUuDQo+DQo+IEhvd2V2ZXIsIGFzIHdlIGFyZSB0YWxraW5n IGFib3V0IGEgZGVzaWduIHdpc2UgYmlnIChpbiBteSBvcGluaW9uKQ0KPiBjaGFuZ2UsIGF0IGEg bGF0ZSBzdGFnZSwgSSdkIGxpa2UgdG8gaGVhciB3aGF0IG90aGVyIHBlb3BsZSB0aGluay4NCj4N Cj4g4oCLVGhhdCBzb3VuZHMgZmFpci7CoCBJJ2QgbGlrZSB0byBoZWFyIHdoYXQgb3RoZXJzIHRo aW5rIGFib3V0IHRoaXMu4oCLDQo+DQo+IOKAiw0KPg0KPg0KPsKgIMKgIMKgID4+PkFsc28ga2Vl cCBpbiBtaW5kIHRoYXQsIHdoZW4gYSBzdWJzZXF1ZW50IG9mZmVyIGlzIHNlbnQsIHRoZQ0KPsKg IMKgIMKgYnVuZGxlLW9ubHkgYXR0cmlidXRlIGlzIG5vIGxvbmdlciB1c2VkLg0KPsKgIMKgIMKg ID4+DQo+wqAgwqAgwqDigIs+PkNhbiB5b3UgcG9pbnQgb3V0IHdoZXJlIGluIHRoZSBkcmFmdCBp dCBzYXlzIHRoYXQ/wqAgSSB0cmllZA0KPsKgIMKgIMKgZmluZGluZyBpdCBhbmQgSSBoYWQgYSBk aWZmaWN1bHQgdGltZSBzZWVpbmcgd2hlcmUgYnVuZGxlLW9ubHkNCj7CoCDCoCDCoHdhc24ndCBh bGxvd2VkIGluIGEgcmVvZmZlci7igIsNCj7CoCDCoCDCoOKAiz4+DQo+wqAgwqAgwqAgPj4gU2Vj dGlvbiA4LjUuMSBzYXlzOg0KPsKgIMKgIMKgID4+DQo+wqAgwqAgwqAgPj7CoCDCoCDCoCDCoCAi V2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRlcyBhIHN1YnNlcXVlbnQgb2ZmZXIsIGl0IE1VU1QNCj7C oCDCoCDCoGFzc2lnbiB0aGUNCj7CoCDCoCDCoCA+PsKgIMKgIMKgIMKgcHJldmlvdXNseSBzZWxl Y3RlZCBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIFtTZWN0aW9uDQo+wqAgwqAgwqA4LjMuMl0sIHRv IGVhY2gNCj7CoCDCoCDCoCA+PsKgIMKgIMKgIMKgYnVuZGxlZCAibT0iIGxpbmUgKGluY2x1ZGlu ZyBhbnkgYnVuZGxlLW9ubHkgIm09IiBsaW5lKSwNCj7CoCDCoCDCoGV4Y2VwdCBpZjoiDQo+wqAg wqAgwqAgPj4NCj7CoCDCoCDCoCA+PiBBbmQsIGFzIHRoZSB1c2FnZSBvZiB0aGUgYXR0cmlidXRl IGlzIG9ubHkgZGVmaW5lZCB3aGVuIHRoZSBwb3J0DQo+wqAgwqAgwqB2YWx1ZSBpcyB6ZXJvLCBp dCB3b3VsZCBub3Qgd29yayB3aGVuIHRoZSBCVU5ETEUgYWRkcmVzcyAocmVhZDoNCj7CoCDCoCDC oG5vbi16ZXJvIHBvcnQpIG11c3QgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5lLg0KPsKg IMKgIMKgID4+DQo+wqAgwqAgwqAgPj4gU2VjdGlvbiA2IHNheXM6DQo+wqAgwqAgwqAgPj4NCj7C oCDCoCDCoCA+PsKgIMKgIlRoZSB1c2FnZSBvZiB0aGUgJ2J1bmRsZS1vbmx5JyBhdHRyaWJ1dGUg aXMgb25seSBkZWZpbmVkIGZvciBhDQo+wqAgwqAgwqAgPj7CoCDCoGJ1bmRsZWQgIm09IiBsaW5l IHdpdGggYSB6ZXJvIHBvcnQgdmFsdWUsIHdpdGhpbiBhbiBvZmZlci7CoCBPdGhlcg0KPsKgIMKg IMKgID4+wqAgwqB1c2FnZSBpcyB1bnNwZWNpZmllZC4iDQo+wqAgwqAgwqAgPg0KPsKgIMKgIMKg 4oCLPiBUaGFua3MuwqAgVGhhdCB0ZXh0IHdvdWxkIGJlIG1vcmUgY2xlYXIgYXMgIndpdGggYW4g aW5pdGlhbCBvZmZlciINCj7CoCDCoCDCoGluc3RlYWQgb2YgIndoaXRoaW4gYW4gb2ZmZXIiLCBz aW5jZSB0aGF0J3Mgd2hhdCBpdCByZWFsbHkgbWVhbnMgaW4NCj7CoCDCoCDCoGNvbmp1Y3Rpb24g d2l0aCA4LjUuMS4NCj4NCj7CoCDCoCDCoE9rLg0KPg0KPsKgIMKgIMKgID4gSG93ZXZlciwgdGhh dCdzIHByZWNpc2VseSB0aGUgdGV4dCB0aGF0IEkgdGhpbmsgd2UgY291bGQgY2hhbmdlLg0KPsKg IMKgIMKgSSB0aGluayB3ZSBjb3VsZCBjaGFuZ2UgdGhlIGJ1bmRsZS1vbmx5IGF0dHJpYnV0ZSB0 bw0KPsKgIMKgIMKgID4gYmUgYWxsb3dlZCBpbiBhbnN3ZXJzIGFuZCBpbiBzdWJzZXF1ZW50IG9m ZmVycy7CoCBUaGVuIGNsaWVudHMNCj7CoCDCoCDCoGNvdWxkIHVzZSB0aGUgYXR0cmlidXRlIGFz IGEgd2F5IG9mIGF2b2lkaW5nIGR1cGxpY2F0aW9uDQo+wqAgwqAgwqAgPiBvZiBjYW5kaWRhdGVz IGFuZCB0aGUgY29tcGxpY2F0aW9ucyB3aXRoIHRyaWNrbGUgSUNFLuKAiw0KPg0KPsKgIMKgIMKg QXNzdW1pbmcgd2Ugd291bGQgcmVtb3ZlIHRoZSBkdXBsaWNhdGlvbiBvZiBjYW5kaWRhdGVzLCBJ IGRvbid0DQo+wqAgwqAgwqB0aGluayB0aGF0IHdvdWxkIHJlcXVpcmUgdXMgdG8gY2hhbmdlIGEg c2VtYW50aWNzIG9mIHRoZSBhdHRyaWJ1dGUuDQo+wqAgwqAgwqBXZSBjb3VsZCBzaW1wbHkgc2F5 IHRoYXQgdGhlIGNhbmRpZGF0ZXMgZG9uJ3QgbmVlZCB0byBiZSBkdXBsaWNhdGVkDQo+wqAgwqAg wqBpbiBidW5kbGVkIG0tIGxpbmVzLCBubyBtYXR0ZXIgaWYgdGhvc2UgbS0gbGluZXMgYXJlIGJ1 bmRsZS1vbmx5IG9yIG5vdC4NCj4NCj4gVGhhdCB3b3VsZCB3b3JrIGFzIHdlbGwuDQo+DQo+IOKA iw0KPg0KPg0KPsKgIMKgIMKgID4+Pj4gV291bGQgeW91IHRoZW4gYWxzbyBpbiB0aGUgc3Vic2Vx dWVudCBvZmZlciBvbmx5IGFzc2lnbg0KPsKgIMKgIMKgcG9zc2libGUgY2FuZGlkYXRlcyB0byBv bmx5IG9uZSBtLSBsaW5lIHdpdGhpbiB0aGUgYnVuZGxlIGdyb3VwPw0KPsKgIMKgIMKgID4+Pg0K PsKgIMKgIMKg4oCLPj4+IFRoYXQgc291bmRzIGxvZ2ljYWwgdG8gbWUuwqAgVGhleSBhcmVuJ3Qg aW5jbHVkZWQgaW4gdGhlIGZpcnN0DQo+wqAgwqAgwqBvZmZlci7CoCBXaHkgYWRkIHRoZW0gdG8g c3Vic2VxdWVudCBvZmZlcnM/wqAgSXQncyBpbmNvbnNpc3RlbnQsIGFuZCBhDQo+wqAgwqAgwqB3 YXN0ZS4NCj7CoCDCoCDCoCA+Pg0KPsKgIMKgIMKgID4+IFRoZW4gc29tZW9uZSBjb3VsZCBhc2s6 IHdoYXQgYWJvdXQgb3RoZXIgKG5vbi1jYW5kaWRhdGUpDQo+wqAgwqAgwqBhdHRyaWJ1dGVzIHRo YXQgbXVzdCBoYXZlIGlkZW50aWNhbCB2YWx1ZXMgZm9yIGVhY2ggYnVuZGxlZCBtLSBsaW5lPw0K PsKgIMKgIMKgU2hvdWxkIHRob3NlIGFsc28gYmUgYXNzaWduZWQgdG8gb25seSBvbmUgb2YgdGhl IG0tIGxpbmVzPw0KPsKgIMKgIMKgID4NCj7CoCDCoCDCoOKAiz4gSWYgaXQncyBzb21ldGhpbmcg dW5pcXVlIHRvIHRoZSBidW5kbGUgZ3JvdXAsIGFuZCBub3QgdGhlIG0tbGluZSwNCj7CoCDCoCDC oHRoYXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZS7CoCDigIsNCj7CoCDCoCDCoOKAiz4NCj7CoCDC oCDCoOKAiz4gQnV0IGNhbmRpZGF0ZXMgYXJlIG1vcmUgcGFpbmZ1bCB0aGFuIHRob3NlIHdvdWxk IGJlIGJlY2F1c2Ugb2YNCj7CoCDCoCDCoHRoZSBpbnRlcmFjdGlvbnMgd2l0aCB0cmlja2xlIElD RS7CoCBJZiBpdCB3ZXJlbid0IGZvciB0cmlja2xlIElDRQ0KPsKgIMKgIMKgdGhpcyB3b3VsZG4n dCBiZSBhcyBiaWcgb2YgYSBkZWFsLuKAiw0KPg0KPsKgIMKgIMKgQ29ycmVjdC4gV2UganVzdCBu ZWVkIHRvIG1ha2UgaXQgdmVyeSBjbGVhciB3aGV0aGVyIGl0IGFwcGxpZXMgb25seQ0KPsKgIMKg IMKgdG8gY2FuZGlkYXRlIGF0dHJpYnV0ZXMsIG9yIHRvIGF0dHJpYnV0ZXMgd2l0aCBpZGVudGlj YWwgdmFsdWVzIGluDQo+wqAgwqAgwqBnZW5lcmFsLg0KPg0KPsKgIMKgIMKgID4+Pj4+Pj4+IDIu wqAgSWYgdGhlIGFuc3dlcmVyIGRvZXMgbm90IGluY2x1ZGUgYW55IGNhbmRpZGF0ZXMgaW4gdGhl DQo+wqAgwqAgwqBhbnN3ZXIgYW5kIGluc3RlYWQgdHJpY2tsZXMgdGhlbSBsYXRlciwgc2hvdWxk IGl0IHRyaWNrbGUgdGhlbQ0KPsKgIMKgIMKgID4+Pj4+Pj4+IE4gdGltZXMgKG9uY2UgZm9yIGVh Y2ggbS1saW5lIGluIHRoZSBCVU5ETEUgZ3JvdXApIG9yID4xDQo+wqAgwqAgwqB0aW1lP8KgIDEg dGltZSBzZWVtcyBtdWNoIG1vcmUgcmVhc29uYWJsZSB0aGFuIE4gdGltZXMsIGJ1dA0KPsKgIMKg IMKgID4+Pj4+Pj4+IGlmIHdlIGR1cGxpY2F0ZSBjYW5kaWRhdGVzIGluIHRoZSBhbnN3ZXIsIGJ1 dCBub3QNCj7CoCDCoCDCoGR1cGxpY2F0ZSB0aGVtIHdoaWxlIHRyaWNrbGluZywgdGhhdCdzIGEg Yml0IGluY29uc2lzdGVudC7CoCBZZXQNCj7CoCDCoCDCoCA+YW5vdGhlciByZWFzb24gdG8gbm90 IGR1cGxpY2F0ZSBpbiB0aGUgYW5zd2VyIDopLg0KPsKgIMKgIMKgID4+Pj4+Pj4NCj7CoCDCoCDC oCA+Pj4+Pj4+IEFzc3VtaW5nIHlvdSB1c2UgU0RQIHRvIHNpZ25hbCB0aGUgdHJpY2tsZWQgY2Fu ZGlkYXRlcywNCj7CoCDCoCDCoGl04oCZcyB0cnVlIHRoYXQgeW91IHdvdWxkIGR1cGxpY2F0ZSB0 aGVtLA0KPsKgIMKgIMKgID4+Pj4+Pj4NCj7CoCDCoCDCoCA+Pj4+Pj7igItXaGF0J3MgdGhlIHJh dGlvbmFsZSBmb3IgdGhhdD/CoCBUaGVzZSBkdXBsaWNhdGVzIHByb3ZpZGUgbm8NCj7CoCDCoCDC oHZhbHVlLCBhbmQgaW4gdGhlIGNhc2Ugb2YgbWFueSBtLWxpbmVzIChzdWNoIGFzIGEgY29uZmVy ZW5jaW5nDQo+wqAgwqAgwqAgPj4+Pj4+c3lzdGVtIHdpdGggbWFueSBwYXJ0aWNpcGFudHMpLCB3 ZSBjb3VsZCBiZSB0YWxraW5nIGFib3V0IDMweA0KPsKgIMKgIMKgdGhlIG51bWJlciBvZiBjYW5k aWRhdGVzIGJlaW5nIHNpZ25hbGVkLg0KPsKgIMKgIMKgID4+Pj4NCj7CoCDCoCDCoCA+Pj4+IEkg aGVhciB3aGF0IHlvdSBhcmUgc2F5aW5nLg0KPsKgIMKgIMKgID4+Pj4NCj7CoCDCoCDCoCA+Pj4+ IEJ1dCwgaWYgd2Ugd291bGQgZG8gYSBjaGFuZ2UsIHdlIGFsc28gbmVlZCB0byBsb29rIGF0IHRo ZSBmdWxsDQo+wqAgwqAgwqBwaWN0dXJlLCBhbmQgY29uc2lkZXIgc3Vic2VxdWVudCBvZmZlcnMg ZXRjLg0KPsKgIMKgIMKgID4+Pg0KPsKgIMKgIMKg4oCLPj4+IEkgdGhpbmsgYSBzaW1wbGUgcnVs ZSB3b3VsZCBiZSAiaWYgeW91IGtub3cgaXQncyBnb2luZyB0byBiZQ0KPsKgIMKgIMKgYnVuZGxl ZCBvbnRvIGFub3RoZXIgbS1saW5lLCBkb24ndCBpbmNsdWRlDQo+wqAgwqAgwqAgPj4+IGNhbmRp ZGF0ZXMiLsKgIFRoYXQgd291bGQgZ28gZm9yIGJ1bmRsZS1vbmx5IG0tbGluZXMgaW4gYW4NCj7C oCDCoCDCoG9mZmVyLCBidW5kbGVkIG0tbGluZXMgaW4gYW4gYW5zd2VyLCBhbmQgYnVuZGxlZCBt LWxpbmVzIGluIGEgcmUtb2ZmZXIu4oCLDQo+wqAgwqAgwqDigIs+Pj4NCj7CoCDCoCDCoCA+PiBC dW5kbGVkIG0tIGxpbmVzIGluIGEgcmUtb2ZmZXIgY2FuIHN0aWxsIGJlIHJlamVjdGVkIGJ5IHRo ZQ0KPsKgIMKgIMKgYW5zd2VyZXIuDQo+wqAgwqAgwqAgPg0KPsKgIMKgIMKg4oCLPiBUaGF0IHNv dW5kcyB0aGUgc2FtZSBhcyBhbiBpbml0aWFsIG9mZmVyLsKgIEhvdyBkb2VzIGl0IGltcGx5IHRo YXQNCj7CoCDCoCDCoGEgcmUtb2ZmZXIgbXVzdCBkdXBsaWNhdGUNCj7CoCDCoCDCoCA+IGNhbmRp ZGF0ZXMgYWNyb3NzIG0tbGluZXMsIGV2ZW4gd2hlbiBhbiBpbml0aWFsIG9mZmVyIGRvZXNuJ3QN Cj7CoCDCoCDCoG5lZWQgdG8/4oCLDQo+wqAgwqAgwqDigIsNCj7CoCDCoCDCoEluIHRoZSBpbml0 aWFsIG9mZmVyIGVhY2ggbS0gbGluZSBjb250YWlucyBjYW5kaWRhdGVzICh1bmlxdWUpLiBJZg0K PsKgIMKgIMKgYW4gbS0gbGluZSBpbiB0aGUgb2ZmZXIgaXMgcmVqZWN0ZWQsIHRoZSBhbnN3ZXJl ciBtdXN0IHNlbGVjdCB0aGUNCj7CoCDCoCDCoG9mZmVyZXIgQlVORExFIGFkZHJlc3MgKGFuZCB0 aGUgYXNzb2NpYXRlZCBjYW5kaWRpYXRlcykgZnJvbSBhbm90aGVyDQo+wqAgwqAgwqBtLSBsaW5l Lg0KPg0KPsKgIMKgIMKgTm93LCBpbiBhIHJlLW9mZmVyLCBpZiB0aGUgbS0gbGluZSBjb250YWlu aW5nIHRoZSBjYW5kaWRhdGVzIGlzDQo+wqAgwqAgwqByZWplY3RlZCwgdGhlIGFuc3dlcmVyIG5l ZWRzIHRvIGluY2x1ZGUgaXRzIGNhbmRpZGF0ZXMgaW4gYW5vdGhlciBtLQ0KPsKgIMKgIMKgbGlu ZSBpbiB0aGUgYW5zd2VyLiBUaGF0J3MgZG9hYmxlLCBidXQgaXQgd291bGQgbmVlZCB0byBiZSBj bGVhcmx5DQo+wqAgwqAgwqBkb2N1bWVudGVkLiBJbiBvdGhlciB3b3JkczogaXQgbmVlZHMgdG8g YmUgY2xlYXIgdGhhdCB0aGUgY2FuZGlkYXRlcw0KPsKgIMKgIMKgY2FuIG9jY3VyIGluIEFOWSBv ZiB0aGUgYnVuZGxlZCBtLSBsaW5lcywgYW5kIHRoYXQgbS0gbGluZSBtYXkNCj7CoCDCoCDCoGNo YW5nZSBiZXR3ZWVuIG9mZmVycyBhbmQgYW5zd2Vycy4NCj4NCj4g4oCLU28gYSBydWxlIG9mICJ0 aGUgY2FuZGlkYXRlcyBjYW4gYmUgaW4gYW55IG9uZSBvZiB0aGUgbS1saW5lcywgYW5kIGl0DQo+ IGRvZXNuJ3QgbWF0dGVyIHdoaWNoLCBhbmQgaXQgY2FuIGNoYW5nZSBhbnkgdGltZSIuwqAgVGhh dCBzZWVtcw0KPiByZWFzb25hYmxlIHRvIG1lLsKgIEl0IGxlYXZlIHRoZSBtb3N0IGZsZXhpYmls aXR5IHRvIHRoZSBvbmUgd3JpdGluZw0KPiB0aGUgU0RQLCBhbmQgaXQncyB2ZXJ5IGVhc3kgdG8g aW1wbGVtZW50IGZvciB0aGUgb25lIHJlYWRpbmcgdGhlIFNEUC7igIsNCj4NCj4NCj7CoCDCoCDC oFJlZ2FyZHMsDQo+DQo+wqAgwqAgwqBDaHJpc3Rlcg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0 DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= From nobody Sat Feb 20 22:21: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 A94091A1F1D for ; Sat, 20 Feb 2016 22:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 7LSG8PC1KgL4 for ; Sat, 20 Feb 2016 22:21:12 -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 38FF21A00DF for ; Sat, 20 Feb 2016 22:21:12 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id l127so148055972iof.3 for ; Sat, 20 Feb 2016 22:21:12 -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=qm1hXuJls+UF4wbaG0Teis0eaUcSy3dxIMV3ZfFVC+g=; b=qviW8vYH9au8dL1NULpE2yeUSKmjus6XG2fKZ03e9+ePIJA2k9jUiolsLVHa5CjX02 roslxg3uWT4C1blqf41L1gQ0Xq3svrgkCRM4UdzjBxXJ2ImhXJQZdS49/Rp3o80ZYcEx IPa2KMdLrppGknYD9DQl1uDWtFDXzwOvD0ezt4Z0xy4lsy4UVQ061OvxyoosEsxPr0fj y5Ks6IAb2aVUr8NSnZEnDMQTsmFPVmA2B62yTwm9TlrKpw6cFPjYAnBIiAZzMWqpCdoX DVSuGfKcIarsvj+2Zko4nHn6QwIvIg+muMO4wiKhzRgb+2GR0NLtnC6fmZPFhAAm0Y+y le3A== 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=qm1hXuJls+UF4wbaG0Teis0eaUcSy3dxIMV3ZfFVC+g=; b=V0yzbq4jRSmSWAwmUt5VUPm9/aCfA0qkMrsC9VWFbr++32YUmMhsM0CxAI2ZQHAIUy v479KKr0bPBoHBn3/De7OjkDDeHlbi6qYG0/Fq5UyBmzYW7xZuBvTBU8lZ46uQEipjpU Gych9cUHMRbNBrr6Tb6MMmDKwm1evacCV5NR8FB3aUOdJPWw889XLL7SQ0XBwGp7RD9+ S25zYfea/+RGmRD3BOaoRQeleKV0/o8RLdiy0ncAIYnnRncgmZ15hHOWV0Dr1ec1R0hh cxRP+Pg2d+8srw5z/IwkuXvXGNIdBUocyKph1G7WASGMSdnulsMQ5H8YF1hA8Elvug4x sy/Q== X-Gm-Message-State: AG10YORBCmNwbQ0or8TouNXftzRmd4MTDH+EamQZVhqQAjXpX8LHu8j31/+V45DgOW8xOw== X-Received: by 10.107.136.159 with SMTP id s31mr22634867ioi.155.1456035671542; Sat, 20 Feb 2016 22:21:11 -0800 (PST) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id 83sm9153820ioi.25.2016.02.20.22.21.09 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Feb 2016 22:21:09 -0800 (PST) Received: by mail-io0-f181.google.com with SMTP id l127so148055505iof.3 for ; Sat, 20 Feb 2016 22:21:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr22946146iod.145.1456035669119; Sat, 20 Feb 2016 22:21:09 -0800 (PST) Received: by 10.36.105.77 with HTTP; Sat, 20 Feb 2016 22:21:09 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> Date: Sun, 21 Feb 2016 01:21:09 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113ece60d69edd052c41b8b2 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 21 Feb 2016 06:21:13 -0000 --001a113ece60d69edd052c41b8b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >> Correct, and that's one reason I suggest that we limit the scope to > ICE, eventhough we probably > >> could do the same thing for any IDENTICAL and TRANSPORT category > attribute. > > > =E2=80=8B> While it would be nice to remove any duplication, the duplicat= ion is > particularly painful for ICE candidates, because > > there can be a lot of them, and because they change without any > offer/answer action (thanks to trickle ICE). =E2=80=8B > > So if we just covered that candidates, we'd be getting most of the valu= e. > > Assuming the scope is ICE, shouldn't the same still apply also to other > ICE related attributes? I assume the values for the "remote-candidates", > "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", "ice-pacing" and > "ice-options" attributes will be identical within a BUNDLE group, so... > "ice-lite" and "ice-options" are session level only candidates, so they should not be in the m=3D line BUNDLE or any other type. The same logic tha= t applies to ICe candidates should apply to other media level ICE SDP attributes or things will break Regards, _____________ Roman Shpount --001a113ece60d69edd052c41b8b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:
>> Correct, and that's one reas= on I suggest that we limit the scope to ICE, eventhough we probably
>> could do the same thing for any IDENTICAL and TRANSPORT category a= ttribute.
>
=E2=80=8B> While it would be nice to remove any duplication, the duplica= tion is particularly painful for ICE candidates, because
> there can be a lot of them, and because they change without any offer/= answer action (thanks to trickle ICE). =E2=80=8B =C2=A0
> So if we just covered that candidates, we'd be getting most of the= value.
=C2=A0
Assuming the scope is ICE, shouldn't the same still apply also to other= ICE related attributes? I assume the values for the "remote-candidate= s",=C2=A0 "ice-lite", "ice-mismatch", "ice-uf= rag", "ice-pwd", "ice-pacing" and "ice-option= s" attributes will be identical within a BUNDLE group, so...

"ice-lite" and "ice-options"= are session level only candidates, so they should not be in the m=3D line = BUNDLE or any other type. The same logic that applies to ICe candidates sho= uld apply to other media level ICE SDP attributes or things will break
<= /div>

Regards,
= _____________
Roman Shpount
=C2=A0
--001a113ece60d69edd052c41b8b2-- From nobody Sun Feb 21 02: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 5131E1A1A13 for ; Sun, 21 Feb 2016 02:12:36 -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 oIPRsnR_AtnK for ; Sun, 21 Feb 2016 02:12: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 B50671A03A3 for ; Sun, 21 Feb 2016 02:12:33 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-06-56c98d8e3ee6 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 23.84.20792.E8D89C65; Sun, 21 Feb 2016 11:12:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Sun, 21 Feb 2016 11:12:30 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75iggAA8gYCAADDekIACZK0AgACy7bCAAMFzgIAAUWfN Date: Sun, 21 Feb 2016 10:12:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E24284@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E24284ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7rm5f78kwgzXvzSymLn/MYrFiwwFW i2vLX7NazLgwldmBxePv+w9MHgs2lXosWfKTyePWlIIAligum5TUnMyy1CJ9uwSujP+vVzIV zLKtmLXqNWsD4x7rLkZODgkBE4kDFxawQdhiEhfurQeyuTiEBA4zSrTcO8oC4SxmlHjXv4W5 i5GDg03AQqL7nzZIg4iAqsTf75OZQGxmgTKJ45P3sYLYwgIOEnuebGWHqHGUmLPiHNhQEYFp jBJtDy4xgiRYgJqn3NzJAjKTV8BXYueLRIhduzgktj07C9bMKRAo8WjJRTCbEei676fWQC0T l2j6spIV4moBiSV7zjND2KISLx//Y4WoyZd4db4VrJdXQFDi5MwnLBMYRWYhaZ+FpGwWkrJZ QCcxC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxcW56UZGeqlFmcnFxfl5enmp JZsYgbF3cMtvqx2MB587HmIU4GBU4uE1SDseJsSaWFZcmXuIUYKDWUmE93HXyTAh3pTEyqrU ovz4otKc1OJDjNIcLErivGuc14cJCaQnlqRmp6YWpBbBZJk4OKUaGLkSWKbPDf243vbBjrWz 33hXOQnePGK/5P+ZJ2vt5rcb7ttTHnS5dGf1S7E2tamC8tmqb6/Y5bzhdz9lJ3/xRzTvp4zb cuURTy4+3Fy0NEahoOvVtJR0vlXPS4MPNRtv3D9n+Wz7zf7ztB7FbGO7nbfDQuvixY7julqX dx1+wO1a9YjnhO/OwkwlluKMREMt5qLiRAAVAb/iuQIAAA== Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 21 Feb 2016 10:12:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E24284ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCkkgZGlkbid0IGNoZWNrIHdoZXRoZXIgc29tZSBvZiB0aGUgSUNFIGF0dHJp YnV0ZXMgd2VyZSBzZXNzaW9uLWxldmVsLCBidXQgSSBhZ3JlZSB3aXRoIHdoYXQgeW91IHNheTog dGhlIHNhbWUgcnVsZSBzaG91bGQgYXBwbHkgdG8gYWxsIG1lZGlhLWxldmVsIElDRSBhdHRyaWJ1 dGVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9u ZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJvbWFuIFNocG91bnQ8 bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPg0KU2VudDog4oCOMjEv4oCOMDIv4oCOMjAxNiAwODoy MQ0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20+DQpDYzogUGV0ZXIgVGhhdGNoZXI8bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPjsg bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+OyBQYXVsIEt5eml2YXQ8bWFp bHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBRdWVzdGlv bnMgYWJvdXQgSUNFIGNhbmRpZGF0ZXMgd2l0aCBCVU5ETEUNCg0KT24gU2F0LCBGZWIgMjAsIDIw MTYgYXQgMTI6NTcgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K Pj4gQ29ycmVjdCwgYW5kIHRoYXQncyBvbmUgcmVhc29uIEkgc3VnZ2VzdCB0aGF0IHdlIGxpbWl0 IHRoZSBzY29wZSB0byBJQ0UsIGV2ZW50aG91Z2ggd2UgcHJvYmFibHkNCj4+IGNvdWxkIGRvIHRo ZSBzYW1lIHRoaW5nIGZvciBhbnkgSURFTlRJQ0FMIGFuZCBUUkFOU1BPUlQgY2F0ZWdvcnkgYXR0 cmlidXRlLg0KPg0K4oCLPiBXaGlsZSBpdCB3b3VsZCBiZSBuaWNlIHRvIHJlbW92ZSBhbnkgZHVw bGljYXRpb24sIHRoZSBkdXBsaWNhdGlvbiBpcyBwYXJ0aWN1bGFybHkgcGFpbmZ1bCBmb3IgSUNF IGNhbmRpZGF0ZXMsIGJlY2F1c2UNCj4gdGhlcmUgY2FuIGJlIGEgbG90IG9mIHRoZW0sIGFuZCBi ZWNhdXNlIHRoZXkgY2hhbmdlIHdpdGhvdXQgYW55IG9mZmVyL2Fuc3dlciBhY3Rpb24gKHRoYW5r cyB0byB0cmlja2xlIElDRSkuIOKAiw0KPiBTbyBpZiB3ZSBqdXN0IGNvdmVyZWQgdGhhdCBjYW5k aWRhdGVzLCB3ZSdkIGJlIGdldHRpbmcgbW9zdCBvZiB0aGUgdmFsdWUuDQoNCkFzc3VtaW5nIHRo ZSBzY29wZSBpcyBJQ0UsIHNob3VsZG4ndCB0aGUgc2FtZSBzdGlsbCBhcHBseSBhbHNvIHRvIG90 aGVyIElDRSByZWxhdGVkIGF0dHJpYnV0ZXM/IEkgYXNzdW1lIHRoZSB2YWx1ZXMgZm9yIHRoZSAi cmVtb3RlLWNhbmRpZGF0ZXMiLCAgImljZS1saXRlIiwgImljZS1taXNtYXRjaCIsICJpY2UtdWZy YWciLCAiaWNlLXB3ZCIsICJpY2UtcGFjaW5nIiBhbmQgImljZS1vcHRpb25zIiBhdHRyaWJ1dGVz IHdpbGwgYmUgaWRlbnRpY2FsIHdpdGhpbiBhIEJVTkRMRSBncm91cCwgc28uLi4NCg0KImljZS1s aXRlIiBhbmQgImljZS1vcHRpb25zIiBhcmUgc2Vzc2lvbiBsZXZlbCBvbmx5IGNhbmRpZGF0ZXMs IHNvIHRoZXkgc2hvdWxkIG5vdCBiZSBpbiB0aGUgbT0gbGluZSBCVU5ETEUgb3IgYW55IG90aGVy IHR5cGUuIFRoZSBzYW1lIGxvZ2ljIHRoYXQgYXBwbGllcyB0byBJQ2UgY2FuZGlkYXRlcyBzaG91 bGQgYXBwbHkgdG8gb3RoZXIgbWVkaWEgbGV2ZWwgSUNFIFNEUCBhdHRyaWJ1dGVzIG9yIHRoaW5n cyB3aWxsIGJyZWFrDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoN Cg== --_000_7594FB04B1934943A5C02806D1A2204B37E24284ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPkhp IFJvbWFuLDxicj4NCjxicj4NCkkgZGlkbid0IGNoZWNrIHdoZXRoZXIgc29tZSBvZiB0aGUgSUNF IGF0dHJpYnV0ZXMgd2VyZSBzZXNzaW9uLWxldmVsLCBidXQgSSBhZ3JlZSB3aXRoIHdoYXQgeW91 IHNheTogdGhlIHNhbWUgcnVsZSBzaG91bGQgYXBwbHkgdG8gYWxsIG1lZGlhLWxldmVsIElDRSBh dHRyaWJ1dGVzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8 YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj4NCjxocj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5Gcm9tOg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBo cmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPlJvbWFuIFNocG91bnQ8L2E+PC9zcGFuPjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5TZW50Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij7igI4yMS/igI4wMi/i gI4yMDE2IDA4OjIxPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5UbzoNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Q2hy aXN0ZXIgSG9sbWJlcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5DYzoN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIj5QZXRlciBU aGF0Y2hlcjwvYT47DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0 Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij4NClBhdWwg S3l6aXZhdDwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQiPlJlOiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQgSUNFIGNhbmRpZGF0ZXMgd2l0 aCBCVU5ETEU8L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfc2ln bmF0dXJlIj5PbiBTYXQsIEZlYiAyMCwgMjAxNiBhdCAxMjo1NyBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBib3JkZXIt bGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFk ZGluZy1sZWZ0OjFleCI+DQomZ3Q7Jmd0OyBDb3JyZWN0LCBhbmQgdGhhdCdzIG9uZSByZWFzb24g SSBzdWdnZXN0IHRoYXQgd2UgbGltaXQgdGhlIHNjb3BlIHRvIElDRSwgZXZlbnRob3VnaCB3ZSBw cm9iYWJseTxicj4NCiZndDsmZ3Q7IGNvdWxkIGRvIHRoZSBzYW1lIHRoaW5nIGZvciBhbnkgSURF TlRJQ0FMIGFuZCBUUkFOU1BPUlQgY2F0ZWdvcnkgYXR0cmlidXRlLjxicj4NCiZndDs8YnI+DQri gIsmZ3Q7IFdoaWxlIGl0IHdvdWxkIGJlIG5pY2UgdG8gcmVtb3ZlIGFueSBkdXBsaWNhdGlvbiwg dGhlIGR1cGxpY2F0aW9uIGlzIHBhcnRpY3VsYXJseSBwYWluZnVsIGZvciBJQ0UgY2FuZGlkYXRl cywgYmVjYXVzZTxicj4NCiZndDsgdGhlcmUgY2FuIGJlIGEgbG90IG9mIHRoZW0sIGFuZCBiZWNh dXNlIHRoZXkgY2hhbmdlIHdpdGhvdXQgYW55IG9mZmVyL2Fuc3dlciBhY3Rpb24gKHRoYW5rcyB0 byB0cmlja2xlIElDRSkuIOKAiyAmbmJzcDs8YnI+DQomZ3Q7IFNvIGlmIHdlIGp1c3QgY292ZXJl ZCB0aGF0IGNhbmRpZGF0ZXMsIHdlJ2QgYmUgZ2V0dGluZyBtb3N0IG9mIHRoZSB2YWx1ZS48YnI+ DQombmJzcDs8YnI+DQpBc3N1bWluZyB0aGUgc2NvcGUgaXMgSUNFLCBzaG91bGRuJ3QgdGhlIHNh bWUgc3RpbGwgYXBwbHkgYWxzbyB0byBvdGhlciBJQ0UgcmVsYXRlZCBhdHRyaWJ1dGVzPyBJIGFz c3VtZSB0aGUgdmFsdWVzIGZvciB0aGUgJnF1b3Q7cmVtb3RlLWNhbmRpZGF0ZXMmcXVvdDssJm5i c3A7ICZxdW90O2ljZS1saXRlJnF1b3Q7LCAmcXVvdDtpY2UtbWlzbWF0Y2gmcXVvdDssICZxdW90 O2ljZS11ZnJhZyZxdW90OywgJnF1b3Q7aWNlLXB3ZCZxdW90OywgJnF1b3Q7aWNlLXBhY2luZyZx dW90OyBhbmQgJnF1b3Q7aWNlLW9wdGlvbnMmcXVvdDsgYXR0cmlidXRlcyB3aWxsIGJlIGlkZW50 aWNhbA0KIHdpdGhpbiBhIEJVTkRMRSBncm91cCwgc28uLi48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mcXVvdDtpY2UtbGl0ZSZxdW90OyBhbmQgJnF1b3Q7aWNl LW9wdGlvbnMmcXVvdDsgYXJlIHNlc3Npb24gbGV2ZWwgb25seSBjYW5kaWRhdGVzLCBzbyB0aGV5 IHNob3VsZCBub3QgYmUgaW4gdGhlIG09IGxpbmUgQlVORExFIG9yIGFueSBvdGhlciB0eXBlLiBU aGUgc2FtZSBsb2dpYyB0aGF0IGFwcGxpZXMgdG8gSUNlIGNhbmRpZGF0ZXMgc2hvdWxkIGFwcGx5 IHRvIG90aGVyIG1lZGlhIGxldmVsIElDRSBTRFAgYXR0cmlidXRlcyBvciB0aGluZ3Mgd2lsbCBi cmVhazxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4N CjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPl9fX19fX19fX19fX188YnI+DQpS b21hbiBTaHBvdW50PC9kaXY+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37E24284ESESSMB209erics_-- From nobody Sun Feb 21 11:25: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 D0AF21A9083; Sun, 21 Feb 2016 11:24:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160221192459.14326.9884.idtracker@ietfa.amsl.com> Date: Sun, 21 Feb 2016 11:24:59 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:25:00 -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 of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-07.txt Pages : 22 Date : 2016-02-21 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 21 11:26: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 4641F1A6F33; Sun, 21 Feb 2016 11:26:28 -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 Z74WnJzwGw1j; Sun, 21 Feb 2016 11:26:26 -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 211AD1A6FB2; Sun, 21 Feb 2016 11:26:25 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-ec-56ca0f605a07 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 15.0E.02707.06F0AC65; Sun, 21 Feb 2016 20:26:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Sun, 21 Feb 2016 20:26:23 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-dtls-sdp-07 Thread-Index: AdFs3blNepl6vLZrR5us7i3JWzoW7Q== Date: Sun, 21 Feb 2016 19:26:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E25706@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_7594FB04B1934943A5C02806D1A2204B37E25706ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdRjeB/1SYwc5b/Bbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyfrSeYi1oFq24ee8+cwPjXaEuRk4OCQETiRN/3jJD 2GISF+6tZ+ti5OIQEjjMKHFzVQsThLOYUWLjkV2sXYwcHGwCFhLd/7RBGkQE1CW+7u0Ba2YW MJV4+GoNI0iJsIClRG+7CkSJnUTPqadsELaexLnW92DlLAKqEt8b/rOA2LwCvhIXDq9gBbEZ gW74fmoNE8RIcYlbT+YzQdwmILFkz3moO0UlXj7+xwphK0ms2H4JbC2zQL7EpQn1ECMFJU7O fMIygVF4FpJJsxCqZiGpgijRkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFiflphsZ 6aUWZSYXF+fn6eWllmxiBMbLwS2/DXYwvnzueIhRgINRiYfXgPNUmBBrYllxZe4hRgkOZiUR 3raLJ8OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8652Xh8mJJCeWJKanZpakFoEk2Xi4JRqYExJ n8tl55PPO3VOj/5HszbT+ZoVnyPkwmazvO47x+nTvSDSuOD6d6OKkreviuc4/V7y7uq7rX4G B3fN3X+N/16s24TEfTJmuaqRLimlyVd3nvc4MWmH707/Q8vz5v9S4kgs/np3TaTgxZcCYZm8 s3Z6XblzYufrr2vC22pW79c5wN7jemdp8B0lluKMREMt5qLiRACRb1ajkwIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:26:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E25706ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on comments and feedback received, I've submitted a new version (-07)= of draft-ietf-mmusic-dtls-sdp. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37E25706ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on comments and feedback received, I’ve = submitted a new version (-07) of draft-ietf-mmusic-dtls-sdp.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E25706ESESSMB209erics_-- From nobody Sun Feb 21 11:34: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 8B27E1A89F9; Sun, 21 Feb 2016 11:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 Id2fNProOarA; Sun, 21 Feb 2016 11:34:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15DFA1A88C7; Sun, 21 Feb 2016 11:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=850; q=dns/txt; s=iport; t=1456083289; x=1457292889; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XTbxMnIg4gsWoAr8xXgcJ3LKdGBN24DhJ4naZeG86Hc=; b=JQ2vIOO58Hspfy3dCiqgC+wQN32B7D0matqda56KM0ef1OKvYk5i1fKl Gfm94j8LDTTPnnhB+vsFt1uDABZlccxfwDRk9sf91rz+UnjTh1iTq/1Hb TVpJaG1ZoK343NlAYJK5jpYEkzpEfBX8ooYT4MCeDqRHMeweqKKDjPaLY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgCwEMpW/5xdJa1egzpSbQazJociA?= =?us-ascii?q?Q2BaBcKhSJKAhyBBjgUAQEBAQEBAWQnhEEBAQEDAQEBASAROgsFCwIBCBgCAiY?= =?us-ascii?q?CAgIlCxUQAQEEDgWIEggOrFuOKwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4UXg?= =?us-ascii?q?W2CToQzgwIrgQ8FlwcBjV2BXI0XhXKIVgEeAQFCg2Rqh1l9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,482,1449532800"; d="scan'208";a="78932776" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2016 19:34:49 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1LJYnXF007615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2016 19:34:49 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 21 Feb 2016 13:34:48 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Sun, 21 Feb 2016 13:34:48 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 Thread-Index: AdFs3blNepl6vLZrR5us7i3JWzoW7QAM31mA Date: Sun, 21 Feb 2016 19:34:48 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37E25706@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E25706@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.226.195] Content-Type: text/plain; charset="utf-8" Content-ID: <4E7FDE41609CEE42880D1DC065ABE8E6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:34:51 -0000 SGkgQ2hyaXN0ZXIgLSANCg0KVGhlIHByb3Bvc2VkIGNoYW5nZXMgbG9vayBnb29kLiAgVGhhbmtz IGZvciBtYWtpbmcgdGhlbS4NCg0KT25lIG1pbm9yIGNvbW1lbnQ6IENvbnNpZGVyaW5nIHRoZSBw cm9wb3NlZCB1cGRhdGUgdG8gUkZDIDczNDUsIEkgdGhpbmsgdGhlcmUgbmVlZHMgdG8gYmUgYSBu b3JtYXRpdmUgcmVmZXJlbmNlIHRvIGl0Lg0KDQpDaGVlcnMsDQoNCkdvbnphbG8NCg0KDQo+IE9u IEZlYiAyMSwgMjAxNiwgYXQgMjoyNiBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gIA0KPiBCYXNlZCBvbiBj b21tZW50cyBhbmQgZmVlZGJhY2sgcmVjZWl2ZWQsIEnigJl2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVy c2lvbiAoLTA3KSBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC4NCj4gIA0KPiBSZWdhcmRz LA0KPiAgDQo+IENocmlzdGVyDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gbW11c2ljQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== From nobody Sun Feb 21 11:39: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 946B41A90BC; Sun, 21 Feb 2016 11:39:24 -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 N-UYTXJHO7Ua; Sun, 21 Feb 2016 11:39:23 -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 C20651A90BA; Sun, 21 Feb 2016 11:39:22 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-62-56ca1268f7db Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6D.34.28465.8621AC65; Sun, 21 Feb 2016 20:39:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Sun, 21 Feb 2016 20:39:20 +0100 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 Thread-Index: AdFs3blNepl6vLZrR5us7i3JWzoW7QAM31mAAAxwCOA= Date: Sun, 21 Feb 2016 19:39:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E25784@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E25706@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+NgFupmkeLIzCtJLcpLzFFi42KZGbHdQzdT6FSYwcUVTBZzp/hZnN+5nsli 6vLHLA7MHlN+b2T1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxtQV61kLHrFXrOyYxdTAeIK9i5GT Q0LARGJ5+wVWCFtM4sK99WxdjFwcQgKHGSU6J9xghHAWM0rM/rOWuYuRg4NNwEKi+582SIOI gLnEnt8tbCA2s0CMxN0D/WCDhAXcJHomvGCDqHGX2PuwmwXCtpL4c+4cM4jNIqAq0TJtGSOI zSvgK/H3wxyoXQ2MEhdav4IlOAVsJS7vmApmMwJd9/3UGiaIZeISt57MZ4K4WkBiyZ7zzBC2 qMTLx/+gvlGSWLH9EiPIzcwCmhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYxWYhmToLoWMWko5Z SDoWMLKsYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMooNbfuvuYFz92vEQowAHoxIPrwHn qTAh1sSy4srcQ4wSHMxKIrxtF0+GCfGmJFZWpRblxxeV5qQWH2KU5mBREudd47w+TEggPbEk NTs1tSC1CCbLxMEp1cCYMEUrkaHe4tqZ/5veH+z8f6DX7OMNfp+6eEf2abJzXr2O6a0yttIS jjrX4PdqY/2i1z3h4eez9h/xkk/Y7KEcqmF18qU0781pH1RT2o3XiCq4caZPLntmF8/iJ8p2 50D9nufZU9L/pn6NWWPPO58hraLLr2qjUvXvn9tPztu6TutwmNvCJ9+UWIozEg21mIuKEwGm A+h7ngIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:39:24 -0000 SGksDQoNCj5UaGUgcHJvcG9zZWQgY2hhbmdlcyBsb29rIGdvb2QuICBUaGFua3MgZm9yIG1ha2lu ZyB0aGVtLg0KPg0KPk9uZSBtaW5vciBjb21tZW50OiBDb25zaWRlcmluZyB0aGUgcHJvcG9zZWQg dXBkYXRlIHRvIFJGQyA3MzQ1LCBJIHRoaW5rIHRoZXJlIG5lZWRzIHRvIGJlIGEgPm5vcm1hdGl2 ZSByZWZlcmVuY2UgdG8gaXQuDQoNCkkgdGhvdWdodCBJIGRpZCB0aGF0LCBidXQgbm93IEkgc2Vl IEkgYWRkZWQgYSByZWZlcmVuY2UgdG8gUkZDIDczMTUgYnkgbWlzdGFrZS4gSSdsbCBmaXggdGhh dC4NCg0KVGhhbmtzIQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KPiBPbiBGZWIgMjEs IDIwMTYsIGF0IDI6MjYgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+ICANCj4gQmFzZWQgb24gY29tbWVudHMg YW5kIGZlZWRiYWNrIHJlY2VpdmVkLCBJ4oCZdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0w Nykgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuDQo+ICANCj4gUmVnYXJkcywNCj4gIA0K PiBDaHJpc3Rlcg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= From nobody Sun Feb 21 11:43:04 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 009381A9115; Sun, 21 Feb 2016 11:43:03 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160221194302.30855.91185.idtracker@ietfa.amsl.com> Date: Sun, 21 Feb 2016 11:43:02 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:43:03 -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 of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-08.txt Pages : 22 Date : 2016-02-21 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 21 11:45:20 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 EA7781A916C; Sun, 21 Feb 2016 11:45:18 -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 Gc2y-rHnXDBA; Sun, 21 Feb 2016 11:45:17 -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 95ACC1A03ED; Sun, 21 Feb 2016 11:45:16 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-31-56ca13cae022 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.94.28465.AC31AC65; Sun, 21 Feb 2016 20:45:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Sun, 21 Feb 2016 20:45:14 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-dtls-sdp-08 Thread-Index: AdFs4GL+uWEttVraT1m7F3qFa8KFdQ== Date: Sun, 21 Feb 2016 19:45:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E25863@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_7594FB04B1934943A5C02806D1A2204B37E25863ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdTPeU8Kkwg64d5hbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgylj25xFZwXLGi6dcR9gbGn7JdjBwcEgImEhc2RHUx cgKZYhIX7q1n62Lk4hASOMwo8eT0D1YIZzGjxP29B5lAGtgELCS6/2mDNIgIqEt83dvDDGIz C5hKPHy1hhHEFhawlNj3bwU7RI2dxM6Pa1ggbD2JcztbmEHGsAioSmx+WwIS5hXwlej5uB+s lRHohu+n1jBBjBSXuPVkPhPEbQISS/acZ4awRSVePv7HCmErSazYfokRoj5f4smGGawQMwUl Ts58wjKBUXgWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWF+em GxnrpRZlJhcX5+fp5aWWbGIERszBLb91dzCufu14iFGAg1GJh9eA81SYEGtiWXFl7iFGCQ5m JRHetosnw4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzrnFeHyYkkJ5YkpqdmlqQWgSTZeLglGpg VFGzX73svKNcLVNGnFug8alfDN8eeM8qvXYyZX9U+5vg0xM43dm4Am1/HG1lW+m4Krjldo7g ekXjz9fsjP6E3G7bslD/wtHdodKenZmLl2Rxxu5piJ5xgrEp++jXk1IFJm82pDy3k/S3fam+ rcUw5teSVMeUpzI3Ph3snLyQPzRDf0JgSAqnEktxRqKhFnNRcSIAPQ9IN5QCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-08 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, 21 Feb 2016 19:45:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E25863ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And now version-08, based on the reference nit found by Gonzalo. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 21 February 2016 21:26 To: mmusic@ietf.org Cc: mmusic-chairs@ietf.org Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 Hi, Based on comments and feedback received, I've submitted a new version (-07)= of draft-ietf-mmusic-dtls-sdp. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37E25863ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And now version-08, ba= sed on the reference nit found by Gonzalo.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 21 February 2016 21:26
To: mmusic@ietf.org
Cc: mmusic-chairs@ietf.org
Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07

 

Hi,

 

Based on comments and feedback received, I’ve = submitted a new version (-07) of draft-ietf-mmusic-dtls-sdp.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E25863ESESSMB209erics_-- From nobody Sun Feb 21 13:54: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 3BA6C1B2CAA; Sun, 21 Feb 2016 13:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 oSGDTxmUPlxJ; Sun, 21 Feb 2016 13:54:00 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8A61B2CA8; Sun, 21 Feb 2016 13:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1029; q=dns/txt; s=iport; t=1456091640; x=1457301240; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=N/nIH9YnZkFrrO3jdIUuL4YBpKH4r6CIw9jenh/NtVE=; b=bLTSxd+PLxsr2p+WLcdWbbvgUxoqSSQwwXaYLkN8sfHsNs2B3YsGhwLm 5PtrD8E7dHn97f9eqU6IXmlpCxLdDdEbz/CMeRzPLoWYVD819PtdlDUFU lDl/OYZDGUsc7KGzoicgYK9ESPzaO/emUmfQsdDYWsg+OJHTlhKZxkavB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgAbMcpW/4wNJK1dgzpSbbpOAQ2Ba?= =?us-ascii?q?BcKhSJKAoEkOBQBAQEBAQEBZCeEQgEBBAEBATU2CgEQCxgJFg8JAwIBAgEVMAY?= =?us-ascii?q?NBgIBAYgWDrMqAQEBAQEBAQEBAQEBAQEBAQEBARMEhhKEO4hvAQSOHohpjV6BX?= =?us-ascii?q?IRDgwKEOIEahXKIVx4BAUKCAxmBZh4uAYhVAQEB?= X-IronPort-AV: E=Sophos;i="5.22,482,1449532800"; d="scan'208";a="75363555" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2016 21:54:00 +0000 Received: from [10.24.69.165] ([10.24.69.165]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1LLrw9J006908; Sun, 21 Feb 2016 21:53:59 GMT To: mmusic References: <56B4CDCF.4080100@cisco.com> From: Flemming Andreasen Message-ID: <56CA320D.9050306@cisco.com> Date: Sun, 21 Feb 2016 16:54:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56B4CDCF.4080100@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-dtls-sdp@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 21:54:02 -0000 The WGLC has ended and Christer has already submitted an update to address the comments received. We did not see a lot of review indications from the group though, so if you did review the draft but did not have any comments, we would appreciate hearing from you. Thanks -- Flemming (MMUSIC co-chair) On 2/5/16 11:29 AM, Flemming Andreasen wrote: > Greetings MMUSIC > > This is to announce a 2 week WGLC on the draft: > > https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-06.txt > > as Proposed Standard. Please review and provide any comments you may > have on the document by Friday, February 19, 2016. Comments should be > sent to the document authors and the MMUSIC WG list. If you review the > document but do not have any comments, please send a note to that > effect as well. > > Thanks > > -- Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Mon Feb 22 01:00: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 34F051B2C32; Mon, 22 Feb 2016 01:00:32 -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 yBNSqcgF6klk; Mon, 22 Feb 2016 01:00: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 A7DE41B2C30; Mon, 22 Feb 2016 01:00:28 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-a9-56cace2b2a83 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.1E.28465.B2ECAC65; Mon, 22 Feb 2016 10:00:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 10:00:26 +0100 From: Christer Holmberg To: "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: Confusion with references to RFC 5245 and draft-5245bis Thread-Index: AdFtT2VzhFsiwYbeT3qr3Botxh76Rg== Date: Mon, 22 Feb 2016 09:00:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E2D311@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_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ma72uVNhBpu3iFhMXf6YxWLtv3Z2 ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlzFq1gqlghnbF8Y7/bA2Md1W7GDk5JARMJBa/Xc4I YYtJXLi3ng3EFhI4zCjxe7dDFyMXkL2YUaLn0VmWLkYODjYBC4nuf9ogNSICPhJff91jBwkL CzhIzDkBFXaV+H79OwuErSexbMp6sPEsAqoS+6e2soGU8wr4SqxujQUJMwJt/X5qDROIzSwg LnHryXwmiGsEJJbsOc8MYYtKvHz8jxXCVpJYsf0SI0R9vkTbiR6wVbwCghInZz5hmcAoNAvJ qFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uLc9ONjPVSizKTi4vz 8/TyUks2MQLj4uCW37o7GFe/djzEKMDBqMTDa8B5KkyINbGsuDL3EKMEB7OSCO/Wo0Ah3pTE yqrUovz4otKc1OJDjNIcLErivGuc14cJCaQnlqRmp6YWpBbBZJk4OKUaGKUqmBWqhG9Mmn3L wHzfv4aNgiKC8WH6ytOnrEuSObxCKDcr4VREYkjFXr014jnuce5RiipRWxk/PpSOyO818F+T cqVq7mTfU1NMdvse+X3mZPfVDvHsKAUvMxWdII+7Uf6nKhq+/J9ktyT5ppvgwYXOd3ceqhI7 dyQvNKfkyf3tD0Nj3zUfUmIpzkg01GIuKk4EADM1jrOHAgAA Archived-At: Subject: [MMUSIC] Confusion with references to RFC 5245 and draft-5245bis 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, 22 Feb 2016 09:00:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Sorry for the cross-posting, but this applies to both MMUSIC and RTCWEB) Hi, draft-bundle currently references RFC 5245. draft-bundle also references draft-ice-sip-sdp, which references draft-5245= bis. draft-bundle also references draft-trickle-ice-sip, which references RFC 52= 45 JSEP references RFC 5245. JSEP also references draft-bundle. My intention is to update the reference in draft-bundle to draft-5245bis - = and I REALLY think we should do the same thing in draft-trickle-ice-sip and= draft-jsep. Otherwise we will end up with references (explicit or implicit= ) to both RFC 5245 and draft-5245bis all over, which could end up being REA= LLY confusing. I KNOW the reason people want to reference RFC 5245, is because they don't = want to create a dependency on draft-5245bis. Well, I think we REALLY shall= create such dependency, and then make sure we get draft-5245bis ready (mor= e on that in a separate draft). Regards, Christer So, my intention is to reference draft-5245bis also in BUNDLE. --_000_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Sorry for the cross-posting, but this applies to bo= th MMUSIC and RTCWEB)

 

Hi,

 

draft-bundle currently references RFC 5245.

 

draft-bundle also references draft-ice-sip-sdp, whic= h references draft-5245bis.

 

draft-bundle also references draft-trickle-ice-sip, = which references RFC 5245

 

JSEP references RFC 5245.

 

JSEP also references draft-bundle.

 

My intention is to update the reference in draft-bun= dle to draft-5245bis – and I REALLY think we should do the same thing= in draft-trickle-ice-sip and draft-jsep. Otherwise we will end up with ref= erences (explicit or implicit) to both RFC 5245 and draft-5245bis all over, which could end up being REALLY confusing= .

 

I KNOW the reason people want to reference RFC 5245,= is because they don’t want to create a dependency on draft-5245bis. = Well, I think we REALLY shall create such dependency, and then make sure we= get draft-5245bis ready (more on that in a separate draft).

 

Regards,

 

Christer

 

 

 

 

 

 

So, my intention is to reference draft-5245bis also = in BUNDLE.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_-- From nobody Mon Feb 22 02:10: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 3F0201B2F80 for ; Mon, 22 Feb 2016 02:10:09 -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 wLhG4RaJB9-E for ; Mon, 22 Feb 2016 02:10:05 -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 9BF471ACD8E for ; Mon, 22 Feb 2016 02:10:04 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-d1-56cade7a781d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.4C.15637.A7EDAC65; Mon, 22 Feb 2016 11:10:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 11:10:02 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text Thread-Index: AdFtWOeeQ/zW0OtpRAOrN5PglHqZIw== Date: Mon, 22 Feb 2016 10:10:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3054E@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_7594FB04B1934943A5C02806D1A2204B37E3054EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7qG7VvVNhBn8aDC2mLn/MYrFiwwFW i2vLX7NazLgwldmBxePv+w9MHgs2lXosWfKTyePWlIIAligum5TUnMyy1CJ9uwSujMfHfjEX 3DnAVLF+wSTWBsY1O5i6GDk5JARMJBaves8OYYtJXLi3nq2LkYtDSOAwo8SH5fOYQRJCAosZ JY6tkOhi5OBgE7CQ6P6nDRIWEVCX+Lq3hxmknllgPaNEZ9smRpCEsECwxPXuzWwQRSESi6ef Zoaw9SQWTToFVsMioCqxee9jMJtXwFfi7ep5YEcwAh3x/dQasOOYBcQlbj2ZD3WogMSSPeeZ IWxRiZeP/7FC2EoSaw9vZ4Goz5c4fG0bK8RMQYmTM5+wTGAUnoVk1CwkZbOQlM0Ceo1ZQFNi /S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjLKD W36r7mC8/MbxEKMAB6MSD68B56kwIdbEsuLK3EOMEhzMSiK8W48ChXhTEiurUovy44tKc1KL DzFKc7AoifOucV4fJiSQnliSmp2aWpBaBJNl4uCUamBMNP9cNWvZtbrYXe3JMrvMzvHG39c6 8Lt31rQW7amNnw6H6j+UZZ/To/k7oWTbR/Ga9x421yZskXCJF9o/YWVJ/snbCl3Vpy9vOuDV brB/u9AXu4vv+QyZXdvVZEpmuYvIGqj72zLrcTglC14IPtVutd4lr8DHYfUTa9Y/HYuVP3WY ZxnsWK7EUpyRaKjFXFScCABVrrL9rgIAAA== Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , Paul Kyzivat Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text 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, 22 Feb 2016 10:10:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E3054EESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzc3VtaW5nIHdlIHdpbGwgb25seSBhc3NvY2lhdGVkIElDRSBjYW5kaWRhdGVzIHRv IHRoZSDigJxtPeKAnSBsaW5lIGFzc29jaWF0ZWQgd2l0aCB0aGUgb2ZmZXJlci9hbnN3ZXJlciBC VU5ETEUtdGFnLCBiZWxvdyBpcyBhIGZpcnN0IHN1Z2dlc3RlZCBvZiBtb2RpZmllZCDigJhJQ0Ug Q29uc2lkZXJhdGlvbnPigJkgdGV4dDoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KMTEu ICBJQ0UgQ29uc2lkZXJhdGlvbnMNCg0KMTEuMS4gIEdlbmVyYWwNCg0KICAgVGhpcyBzZWN0aW9u IGRlc2NyaWJlcyBob3cgdG8gdXNlIHRoZSBCVU5ETEUgZ3JvdXBpbmcgZXh0ZW5zaW9uDQogICB0 b2dldGhlciB3aXRoIHRoZSBJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudCAo SUNFKQ0KICAgbWVjaGFuaXNtIFtSRkM1MjQ1XS4NCg0KICAgVGhlIGdlbmVyaWMgcHJvY2VkdXJl cyBmb3IgbmVnb3RpYXRpbmcgdXNhZ2Ugb2YgSUNFIHVzaW5nIFNEUCwNCiAgIGRlZmluZWQgaW4g W0ktRC5pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcF0sIGFsc28gYXBwbHkgdG8gdXNhZ2Ugb2YgSUNF DQogICB3aXRoIEJVTkRMRSwgd2l0aCB0aGUgZm9sbG93aW5nIGV4Y2VwdGlvbnM6DQoNCiAgIG8g IFdoZW4gQlVORExFIGFkZHJlc3NlcyBmb3IgYSBCVU5ETEUgZ3JvdXAgaGF2ZSBiZWVuIHNlbGVj dGVkIGZvcg0KICAgICAgYm90aCBlbmRwb2ludHMsIElDRSBjb25uZWN0aXZpdHkgY2hlY2tzIGFu ZCBrZWVwLWFsaXZlcyBvbmx5IG5lZWQNCiAgICAgIHRvIGJlIHBlcmZvcm1lZCBmb3IgdGhlIHdo b2xlIEJVTkRMRSBncm91cCwgaW5zdGVhZCBvZiBwZXIgYnVuZGxlZA0KICAgICAgIm09IiBsaW5l Lg0KDQogICBvICBBbW9uZyBidW5kbGVkICJtPSIgbGluZXMgd2l0aCB3aGljaCB0aGUgb2ZmZXJl ciBoYXMgYXNzb2NpYXRlZCBhDQogICAgICBzaGFyZWQgYWRkcmVzcywgdGhlIG9mZmVyZXIgb25s eSBhc3NvY2lhdGVzIElDRS1yZWxhdGVkIG1lZGlhLQ0KICAgICAgbGV2ZWwgU0RQIGF0dHJpYnV0 ZXMgd2l0aCB0aGUgIm09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAgICAgIG9mZmVyZXIg QlVORExFLXRhZy4NCg0KICAgbyAgQW1vbmcgYnVuZGxlZCAibT0iIGxpbmVzIHdpdGggd2hpY2gg dGhlIGFuc3dlcmVyIGhhcyBhc3NvY2lhdGVkIGENCiAgICAgIHNoYXJlZCBhZGRyZXNzLCB0aGUg YW5zd2VyZXIgb25seSBhc3NvY2lhdGVzIElDRS1yZWxhdGVkIG1lZGlhLQ0KICAgICAgbGV2ZWwg U0RQIGF0dHJpYnV0ZXMgd2l0aCB0aGUgIm09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAg ICAgIGFuc3dlcmVyIEJVTkRMRS10YWcuDQoNCiAgIFN1cHBvcnQgYW5kIHVzYWdlIG9mIElDRSBt ZWNoYW5pc20gdG9nZXRoZXIgd2l0aCB0aGUgQlVORExFIGV4dGVuc2lvbg0KICAgaXMgT1BUSU9O QUwuDQoNCjExLjIuICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCg0KMTEuMi4xLiAgR2Vu ZXJhbA0KDQogICBXaGVuIGFuIG9mZmVyZXIgYXNzb2NpYXRlcyBhIHVuaXF1ZSBhZGRyZXNzIHdp dGggYSBidW5kbGVkICJtPSIgbGluZQ0KICAgKGV4Y2x1ZGluZyBhbnkgYnVuZGxlLW9ubHkgIm09 IiBsaW5lKSwgaXQgTVVTVCBhbHNvIGFzc29jaWF0ZSB1bmlxdWUNCiAgIElDRSBjYW5kaWRhdGVz IHRvIHRoZSAibT0iIGxpbmUsIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbg0KICAgW0kt RC5pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcF0uDQoNCiAgIEFuIG9mZmVyZXIgTVVTVCBOT1QgYXNz b2NpYXRlIElDRSBjYW5kaWRhdGVzIHdpdGggYSBidW5kbGUtb25seSAibT0iDQogICBsaW5lIHdp dGggYSB6ZXJvIHBvcnQgdmFsdWUuDQoNCiAgIE5PVEU6IFRoZSBidW5kbGUtb25seSAibT0iIGxp bmUsIGlmIGFjY2VwdGVkIGJ5IHRoZSBhbnN3ZXJlciwgd2lsbA0KICAgaW5oZXJpdCB0aGUgY2Fu ZGlkYXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIHNlbGVjdGVkIG9mZmVyZXIgQlVORExFDQogICBh ZGRyZXNzLiAgQW4gYW5zd2VyZXIgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IEJVTkRMRSB3b3VsZCBu b3QgYWNjZXB0IGENCiAgIGJ1bmRsZS1vbmx5ICJtPSIgbGluZS4NCg0KICAgV2hlbiBhbiBvZmZl cmVyIG9yIGFuc3dlcmVyIGFzc29jaWF0ZXMgYSBzaGFyZWQgYWRkcmVzcyAoaS5lLiBhDQogICBw cmV2aW91c2x5IHNlbGVjdGVkIEJVTkRMRSBhZGRyZXNzKSB3aXRoIG9uZSBvciBtb3JlIGJ1bmRs ZWQgIm09Ig0KICAgbGluZXMsIHRoZSBvZmZlcmVyIChvciBhbnN3ZXJlcikgTVVTVCBvbmx5IGFz c29jaWF0ZSBTRFAgJ2NhbmRpZGF0ZScNCiAgIGF0dHJpYnV0ZXMgd2l0aCB0aGUgIm09IiBsaW5l IGFzc29jaWF0ZWQgd2l0aCB0aGUgb2ZmZXJlciBCVU5ETEUtdGFnDQogICAob3IgdGhlIGFuc3dl cmVyIEJVTkRMRS10YWcpIGFkZHJlc3MpLiAgVGhlIG9mZmVyZXIgb3IgYW5zd2VyZXIgTVVTVA0K ICAgTk9UIGFzc29jaWF0ZSAnY2FuZGlkaWF0ZScgYXR0cmlidXRlcyB3aXRoIGFueSBvdGhlciBi dW5kbGVkICJtPSINCiAgIGxpbmUgdG8gd2hpY2ggdGhlIG9mZmVyZXIgKG9yIGFuc3dlcmVyKSBh c3NvY2lhdGVzIGEgc2hhcmVkIGFkZHJlc3MuDQogICBUaGlzIGFsc28gYXBwbHkgdG8gYW55IG90 aGVyIElDRS1yZWxhdGVkIG1lZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGUuDQoNCiAgIE5PVEU6IFRo ZSBmb2xsb3dpbmcgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0ZXMgYXJlDQog ICBkZWZpbmVkIGluIFtJLUQuaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHBdOiAnY2FuZGlkaWF0ZScs ICdyZW1vdGUtDQogICBjYW5kaWRhdGVzJywgJ2ljZS1taXNtYXRjaCcsICdpY2UtdWZyYWcnLCAn aWNlLXB3ZCcsIGFuZCAnaWNlLQ0KICAgcGFjaW5nJy4NCg0KMTEuMi4yLiAgR2VuZXJhdGluZyB0 aGUgSW5pdGlhbCBTRFAgT2ZmZXINCg0KICAgV2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRlcyBhbiBp bml0aWFsIG9mZmVyLCBpdCBhc3NvY2lhdGVzIHVuaXF1ZSBJQ0UNCiAgIGNhbmRpZGF0ZXMgd2l0 aCB0aGUgYnVuZGxlZCAibT0iIGxpbmVzLCBhY2NvcmRpbmcgdG8gU2VjdGlvbiAxMS4yLjEuDQoN CjExLjIuMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXINCg0KICAgV2hlbiBhbiBhbnN3ZXJl ciBnZW5lcmF0ZXMgYW4gYW5zd2VyIHRoYXQgY29udGFpbnMgYSBCVU5ETEUgZ3JvdXAsDQogICB0 aGUgYW5zd2VyZXIgTVVTVCBvbmx5IGFzc29jaWF0ZSBTRFAgJ2NhbmRpZGF0ZScgYXR0cmlidXRl cyAoYW5kDQogICBvdGhlciBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcykg d2l0aCB0aGUgIm09IiBsaW5lDQogICBhc3NvY2lhdGVkIHdpdGggdGhlIGFuc3dlcmVyIEJVTkRM RS10YWcuDQoNCjExLjIuNC4gIE9mZmVyZXIgUHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFuc3dlcg0K DQogICBXaGVuIGFuIG9mZmVyZXIgcmVjZWl2ZXMgYW4gYW5zd2VyLCBpZiB0aGUgYW5zd2VyZXIg c3VwcG9ydHMgYW5kIHVzZXMNCiAgIHRoZSBJQ0UgbWVjaGFuaXNtIGFuZCB0aGUgQlVORExFIGV4 dGVuc2lvbiwgdGhlIG9mZmVyZXIgTVVTVA0KICAgYXNzb2NpYXRlIHRoZSBzYW1lIElDRSBjYW5k aWRhdGVzLCBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZQ0KICAgcmVwcmVzZW50aW5nIHRo ZSBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIChzZWxlY3RlZCBieSB0aGUgYW5zd2VyZXIpLA0KICAg d2l0aCBlYWNoIGJ1bmRsZWQgIm09IiBsaW5lLg0KDQoxMS4yLjUuICBNb2RpZnlpbmcgdGhlIFNl c3Npb24NCg0KICAgV2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRlcyBhIHN1YnNlcXVlbnQgb2ZmZXIs IGl0IGFzc29jaWF0ZXMgdW5pcXVlIG9yDQogICBzaGFyZWQgSUNFIGNhbmRpZGF0ZXMgd2l0aCB0 aGUgYnVuZGxlZCAibT0iIGxpbmVzLCBhY2NvcmRpbmcgdG8NCiAgIChTZWN0aW9uIDExLjIuMSku DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K RnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMjEgRmVicnVhcnkgMjAxNiAxMjoxMg0KVG86IFJv bWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KQ2M6IFBhdWwgS3l6aXZhdCA8cGt5eml2 YXRAYWx1bS5taXQuZWR1PjsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10g UXVlc3Rpb25zIGFib3V0IElDRSBjYW5kaWRhdGVzIHdpdGggQlVORExFDQoNCkhpIFJvbWFuLA0K DQpJIGRpZG4ndCBjaGVjayB3aGV0aGVyIHNvbWUgb2YgdGhlIElDRSBhdHRyaWJ1dGVzIHdlcmUg c2Vzc2lvbi1sZXZlbCwgYnV0IEkgYWdyZWUgd2l0aCB3aGF0IHlvdSBzYXk6IHRoZSBzYW1lIHJ1 bGUgc2hvdWxkIGFwcGx5IHRvIGFsbCBtZWRpYS1sZXZlbCBJQ0UgYXR0cmlidXRlcy4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBSb21hbiBTaHBvdW50PG1haWx0bzpyb21h bkB0ZWx1cml4LmNvbT4NClNlbnQ6IOKAjjIxL+KAjjAyL+KAjjIwMTYgMDg6MjENClRvOiBDaHJp c3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6 IFBldGVyIFRoYXRjaGVyPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT47IG1tdXNpY0BpZXRm Lm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPjsgUGF1bCBLeXppdmF0PG1haWx0bzpwa3l6aXZh dEBhbHVtLm1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gUXVlc3Rpb25zIGFib3V0IElD RSBjYW5kaWRhdGVzIHdpdGggQlVORExFDQpPbiBTYXQsIEZlYiAyMCwgMjAxNiBhdCAxMjo1NyBQ TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+PiBDb3JyZWN0LCBh bmQgdGhhdCdzIG9uZSByZWFzb24gSSBzdWdnZXN0IHRoYXQgd2UgbGltaXQgdGhlIHNjb3BlIHRv IElDRSwgZXZlbnRob3VnaCB3ZSBwcm9iYWJseQ0KPj4gY291bGQgZG8gdGhlIHNhbWUgdGhpbmcg Zm9yIGFueSBJREVOVElDQUwgYW5kIFRSQU5TUE9SVCBjYXRlZ29yeSBhdHRyaWJ1dGUuDQo+DQri gIs+IFdoaWxlIGl0IHdvdWxkIGJlIG5pY2UgdG8gcmVtb3ZlIGFueSBkdXBsaWNhdGlvbiwgdGhl IGR1cGxpY2F0aW9uIGlzIHBhcnRpY3VsYXJseSBwYWluZnVsIGZvciBJQ0UgY2FuZGlkYXRlcywg YmVjYXVzZQ0KPiB0aGVyZSBjYW4gYmUgYSBsb3Qgb2YgdGhlbSwgYW5kIGJlY2F1c2UgdGhleSBj aGFuZ2Ugd2l0aG91dCBhbnkgb2ZmZXIvYW5zd2VyIGFjdGlvbiAodGhhbmtzIHRvIHRyaWNrbGUg SUNFKS4g4oCLDQo+IFNvIGlmIHdlIGp1c3QgY292ZXJlZCB0aGF0IGNhbmRpZGF0ZXMsIHdlJ2Qg YmUgZ2V0dGluZyBtb3N0IG9mIHRoZSB2YWx1ZS4NCg0KQXNzdW1pbmcgdGhlIHNjb3BlIGlzIElD RSwgc2hvdWxkbid0IHRoZSBzYW1lIHN0aWxsIGFwcGx5IGFsc28gdG8gb3RoZXIgSUNFIHJlbGF0 ZWQgYXR0cmlidXRlcz8gSSBhc3N1bWUgdGhlIHZhbHVlcyBmb3IgdGhlICJyZW1vdGUtY2FuZGlk YXRlcyIsICAiaWNlLWxpdGUiLCAiaWNlLW1pc21hdGNoIiwgImljZS11ZnJhZyIsICJpY2UtcHdk IiwgImljZS1wYWNpbmciIGFuZCAiaWNlLW9wdGlvbnMiIGF0dHJpYnV0ZXMgd2lsbCBiZSBpZGVu dGljYWwgd2l0aGluIGEgQlVORExFIGdyb3VwLCBzby4uLg0KDQoiaWNlLWxpdGUiIGFuZCAiaWNl LW9wdGlvbnMiIGFyZSBzZXNzaW9uIGxldmVsIG9ubHkgY2FuZGlkYXRlcywgc28gdGhleSBzaG91 bGQgbm90IGJlIGluIHRoZSBtPSBsaW5lIEJVTkRMRSBvciBhbnkgb3RoZXIgdHlwZS4gVGhlIHNh bWUgbG9naWMgdGhhdCBhcHBsaWVzIHRvIElDZSBjYW5kaWRhdGVzIHNob3VsZCBhcHBseSB0byBv dGhlciBtZWRpYSBsZXZlbCBJQ0UgU0RQIGF0dHJpYnV0ZXMgb3IgdGhpbmdzIHdpbGwgYnJlYWsN Cg0KUmVnYXJkcywNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37E3054EESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Bc3N1bWluZyB3ZSB3aWxsIG9ubHkgYXNzb2Np YXRlZCBJQ0UgY2FuZGlkYXRlcyB0byB0aGUg4oCcbT3igJ0gbGluZSBhc3NvY2lhdGVkIHdpdGgg dGhlIG9mZmVyZXIvYW5zd2VyZXIgQlVORExFLXRhZywgYmVsb3cgaXMgYSBmaXJzdA0KIHN1Z2dl c3RlZCBvZiBtb2RpZmllZCDigJhJQ0UgQ29uc2lkZXJhdGlvbnPigJkgdGV4dDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xMS4mbmJzcDsg SUNFIENvbnNpZGVyYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xMS4xLiZuYnNwOyBHZW5lcmFsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhp cyBzZWN0aW9uIGRlc2NyaWJlcyBob3cgdG8gdXNlIHRoZSBCVU5ETEUgZ3JvdXBpbmcgZXh0ZW5z aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyB0b2dldGhlciB3aXRoIHRoZSBJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkg RXN0YWJsaXNobWVudCAoSUNFKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtIFtSRkM1MjQ1XS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBUaGUgZ2VuZXJpYyBwcm9jZWR1cmVzIGZvciBuZWdvdGlhdGluZyB1c2FnZSBvZiBJ Q0UgdXNpbmcgU0RQLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZGVmaW5lZCBpbiBbSS1ELmlldGYtbW11c2ljLWljZS1z aXAtc2RwXSwgYWxzbyBhcHBseSB0byB1c2FnZSBvZiBJQ0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdpdGggQlVORExF LCB3aXRoIHRoZSBmb2xsb3dpbmcgZXhjZXB0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFdo ZW4gQlVORExFIGFkZHJlc3NlcyBmb3IgYSBCVU5ETEUgZ3JvdXAgaGF2ZSBiZWVuIHNlbGVjdGVk IGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm90aCBlbmRwb2ludHMsIElDRSBjb25u ZWN0aXZpdHkgY2hlY2tzIGFuZCBrZWVwLWFsaXZlcyBvbmx5IG5lZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRvIGJlIHBlcmZvcm1lZCBmb3IgdGhlIHdob2xlIEJVTkRMRSBncm91cCwg aW5zdGVhZCBvZiBwZXIgYnVuZGxlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 bT0mcXVvdDsgbGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvICZuYnNwO0Ftb25nIGJ1bmRsZWQgJnF1b3Q7 bT0mcXVvdDsgbGluZXMgd2l0aCB3aGljaCB0aGUgb2ZmZXJlciBoYXMgYXNzb2NpYXRlZCBhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaGFyZWQgYWRkcmVzcywgdGhlIG9mZmVyZXIgb25s eSBhc3NvY2lhdGVzIElDRS1yZWxhdGVkIG1lZGlhLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbGV2ZWwgU0RQIGF0dHJpYnV0ZXMgd2l0aCB0aGUgJnF1b3Q7bT0mcXVvdDsgbGluZSBhc3Nv Y2lhdGVkIHdpdGggdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZmZlcmVyIEJVTkRM RS10YWcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBbW9uZyBidW5kbGVkICZxdW90O209JnF1b3Q7 IGxpbmVzIHdpdGggd2hpY2ggdGhlIGFuc3dlcmVyIGhhcyBhc3NvY2lhdGVkIGE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNoYXJlZCBhZGRyZXNzLCB0aGUgYW5zd2VyZXIgb25seSBhc3Nv Y2lhdGVzIElDRS1yZWxhdGVkIG1lZGlhLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGV2 ZWwgU0RQIGF0dHJpYnV0ZXMgd2l0aCB0aGUgJnF1b3Q7bT0mcXVvdDsgbGluZSBhc3NvY2lhdGVk IHdpdGggdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbnN3ZXJlciBCVU5ETEUtdGFn LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IFN1cHBvcnQgYW5kIHVzYWdlIG9mIElDRSBtZWNoYW5pc20gdG9nZXRo ZXIgd2l0aCB0aGUgQlVORExFIGV4dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaXMgT1BUSU9OQUwuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xMS4y LiZuYnNwOyBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjExLjIuMS4mbmJzcDsgR2VuZXJh bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gYW4gb2ZmZXJlciBhc3NvY2lhdGVzIGEgdW5pcXVlIGFkZHJl c3Mgd2l0aCBhIGJ1bmRsZWQgJnF1b3Q7bT0mcXVvdDsgbGluZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgKGV4Y2x1ZGlu ZyBhbnkgYnVuZGxlLW9ubHkgJnF1b3Q7bT0mcXVvdDsgbGluZSksIGl0IE1VU1QgYWxzbyBhc3Nv Y2lhdGUgdW5pcXVlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJQ0UgY2FuZGlkYXRlcyB0byB0aGUgJnF1b3Q7bT0mcXVv dDsgbGluZSwgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzIGluPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBbSS1ELmll dGYtbW11c2ljLWljZS1zaXAtc2RwXS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBbiBvZmZlcmVyIE1VU1QgTk9U IGFzc29jaWF0ZSBJQ0UgY2FuZGlkYXRlcyB3aXRoIGEgYnVuZGxlLW9ubHkgJnF1b3Q7bT0mcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IGxpbmUgd2l0aCBhIHplcm8gcG9ydCB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBO T1RFOiBUaGUgYnVuZGxlLW9ubHkgJnF1b3Q7bT0mcXVvdDsgbGluZSwgaWYgYWNjZXB0ZWQgYnkg dGhlIGFuc3dlcmVyLCB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpbmhlcml0IHRoZSBjYW5kaWRhdGVzIGFzc29j aWF0ZWQgd2l0aCB0aGUgc2VsZWN0ZWQgb2ZmZXJlciBCVU5ETEU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3Mu Jm5ic3A7IEFuIGFuc3dlcmVyIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBCVU5ETEUgd291bGQgbm90 IGFjY2VwdCBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBidW5kbGUtb25seSAmcXVvdDttPSZxdW90OyBsaW5lLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IFdoZW4gYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBhc3NvY2lhdGVzIGEgc2hhcmVk IGFkZHJlc3MgKGkuZS4gYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcHJldmlvdXNseSBzZWxlY3RlZCBCVU5ETEUgYWRk cmVzcykgd2l0aCBvbmUgb3IgbW9yZSBidW5kbGVkICZxdW90O209JnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBs aW5lcywgdGhlIG9mZmVyZXIgKG9yIGFuc3dlcmVyKSBNVVNUIG9ubHkgYXNzb2NpYXRlIFNEUCAn Y2FuZGlkYXRlJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYXR0cmlidXRlcyB3aXRoIHRoZSAmcXVvdDttPSZxdW90OyBs aW5lIGFzc29jaWF0ZWQgd2l0aCB0aGUgb2ZmZXJlciBCVU5ETEUtdGFnPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAob3Ig dGhlIGFuc3dlcmVyIEJVTkRMRS10YWcpIGFkZHJlc3MpLiZuYnNwOyBUaGUgb2ZmZXJlciBvciBh bnN3ZXJlciBNVVNUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBOT1QgYXNzb2NpYXRlICdjYW5kaWRpYXRlJyBhdHRyaWJ1 dGVzIHdpdGggYW55IG90aGVyIGJ1bmRsZWQgJnF1b3Q7bT0mcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGxpbmUg dG8gd2hpY2ggdGhlIG9mZmVyZXIgKG9yIGFuc3dlcmVyKSBhc3NvY2lhdGVzIGEgc2hhcmVkIGFk ZHJlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBUaGlzIGFsc28gYXBwbHkgdG8gYW55IG90aGVyIElDRS1yZWxhdGVk IG1lZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTk9URTogVGhlIGZvbGxv d2luZyBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyBhcmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IGRlZmluZWQgaW4gW0ktRC5pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcF06ICdjYW5kaWRpYXRlJywg J3JlbW90ZS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IGNhbmRpZGF0ZXMnLCAnaWNlLW1pc21hdGNoJywgJ2ljZS11ZnJh ZycsICdpY2UtcHdkJywgYW5kICdpY2UtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwYWNpbmcnLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTEuMi4yLiZuYnNw OyBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gYW4g b2ZmZXJlciBnZW5lcmF0ZXMgYW4gaW5pdGlhbCBvZmZlciwgaXQgYXNzb2NpYXRlcyB1bmlxdWUg SUNFPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBjYW5kaWRhdGVzIHdpdGggdGhlIGJ1bmRsZWQgJnF1b3Q7bT0mcXVvdDsg bGluZXMsIGFjY29yZGluZyB0byBTZWN0aW9uIDExLjIuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjExLjIuMy4mbmJzcDsgR2VuZXJh dGluZyB0aGUgU0RQIEFuc3dlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gYW4gYW5zd2VyZXIgZ2VuZXJh dGVzIGFuIGFuc3dlciB0aGF0IGNvbnRhaW5zIGEgQlVORExFIGdyb3VwLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhl IGFuc3dlcmVyIE1VU1Qgb25seSBhc3NvY2lhdGUgU0RQICdjYW5kaWRhdGUnIGF0dHJpYnV0ZXMg KGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgb3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0 ZXMpIHdpdGggdGhlICZxdW90O209JnF1b3Q7IGxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFzc29jaWF0ZWQgd2l0 aCB0aGUgYW5zd2VyZXIgQlVORExFLXRhZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjExLjIuNC4mbmJzcDsgT2ZmZXJlciBQcm9jZXNz aW5nIG9mIHRoZSBTRFAgQW5zd2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2hlbiBhbiBvZmZlcmVyIHJlY2Vp dmVzIGFuIGFuc3dlciwgaWYgdGhlIGFuc3dlcmVyIHN1cHBvcnRzIGFuZCB1c2VzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyB0aGUgSUNFIG1lY2hhbmlzbSBhbmQgdGhlIEJVTkRMRSBleHRlbnNpb24sIHRoZSBvZmZlcmVy IE1VU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IGFzc29jaWF0ZSB0aGUgc2FtZSBJQ0UgY2FuZGlkYXRlcywgYXNzb2Np YXRlZCB3aXRoIHRoZSAmcXVvdDttPSZxdW90OyBsaW5lPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyByZXByZXNlbnRpbmcg dGhlIG9mZmVyZXIgQlVORExFIGFkZHJlc3MgKHNlbGVjdGVkIGJ5IHRoZSBhbnN3ZXJlciksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyB3aXRoIGVhY2ggYnVuZGxlZCAmcXVvdDttPSZxdW90OyBsaW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTEuMi41LiZu YnNwOyBNb2RpZnlpbmcgdGhlIFNlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXaGVuIGFuIG9mZmVyZXIg Z2VuZXJhdGVzIGEgc3Vic2VxdWVudCBvZmZlciwgaXQgYXNzb2NpYXRlcyB1bmlxdWUgb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IHNoYXJlZCBJQ0UgY2FuZGlkYXRlcyB3aXRoIHRoZSBidW5kbGVkICZxdW90O209JnF1 b3Q7IGxpbmVzLCBhY2NvcmRpbmcgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IChTZWN0aW9uIDExLjIuMSkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gMjEgRmVicnVhcnkgMjAx NiAxMjoxMjxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0 LmVkdSZndDs7IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJ Q10gUXVlc3Rpb25zIGFib3V0IElDRSBjYW5kaWRhdGVzIHdpdGggQlVORExFPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkhpIFJvbWFuLDxicj4NCjxicj4NCkkgZGlkbid0IGNoZWNrIHdoZXRoZXIgc29t ZSBvZiB0aGUgSUNFIGF0dHJpYnV0ZXMgd2VyZSBzZXNzaW9uLWxldmVsLCBidXQgSSBhZ3JlZSB3 aXRoIHdoYXQgeW91IHNheTogdGhlIHNhbWUgcnVsZSBzaG91bGQgYXBwbHkgdG8gYWxsIG1lZGlh LWxldmVsIElDRSBhdHRyaWJ1dGVzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hy aXN0ZXI8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjMiIHdp ZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tIj5Sb21hbiBTaHBvdW50PC9hPjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNl bnQ6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igI4yMS/igI4wMi/igI4yMDE2IDA4OjIx PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5D aHJpc3RlciBIb2xtYmVyZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DYzog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29v Z2xlLmNvbSI+UGV0ZXIgVGhhdGNoZXI8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0u bWl0LmVkdSI+DQpQYXVsIEt5eml2YXQ8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+U3ViamVjdDogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmU6IFtNTVVTSUNdIFF1 ZXN0aW9ucyBhYm91dCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEJVTkRMRTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBTYXQsIEZlYiAyMCwgMjAxNiBhdCAxMjo1NyBQTSwgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7IENvcnJlY3QsIGFuZCB0aGF0J3Mgb25l IHJlYXNvbiBJIHN1Z2dlc3QgdGhhdCB3ZSBsaW1pdCB0aGUgc2NvcGUgdG8gSUNFLCBldmVudGhv dWdoIHdlIHByb2JhYmx5PGJyPg0KJmd0OyZndDsgY291bGQgZG8gdGhlIHNhbWUgdGhpbmcgZm9y IGFueSBJREVOVElDQUwgYW5kIFRSQU5TUE9SVCBjYXRlZ29yeSBhdHRyaWJ1dGUuPGJyPg0KJmd0 Ozxicj4NCuKAiyZndDsgV2hpbGUgaXQgd291bGQgYmUgbmljZSB0byByZW1vdmUgYW55IGR1cGxp Y2F0aW9uLCB0aGUgZHVwbGljYXRpb24gaXMgcGFydGljdWxhcmx5IHBhaW5mdWwgZm9yIElDRSBj YW5kaWRhdGVzLCBiZWNhdXNlPGJyPg0KJmd0OyB0aGVyZSBjYW4gYmUgYSBsb3Qgb2YgdGhlbSwg YW5kIGJlY2F1c2UgdGhleSBjaGFuZ2Ugd2l0aG91dCBhbnkgb2ZmZXIvYW5zd2VyIGFjdGlvbiAo dGhhbmtzIHRvIHRyaWNrbGUgSUNFKS4g4oCLICZuYnNwOzxicj4NCiZndDsgU28gaWYgd2UganVz dCBjb3ZlcmVkIHRoYXQgY2FuZGlkYXRlcywgd2UnZCBiZSBnZXR0aW5nIG1vc3Qgb2YgdGhlIHZh bHVlLjxicj4NCiZuYnNwOzxicj4NCkFzc3VtaW5nIHRoZSBzY29wZSBpcyBJQ0UsIHNob3VsZG4n dCB0aGUgc2FtZSBzdGlsbCBhcHBseSBhbHNvIHRvIG90aGVyIElDRSByZWxhdGVkIGF0dHJpYnV0 ZXM/IEkgYXNzdW1lIHRoZSB2YWx1ZXMgZm9yIHRoZSAmcXVvdDtyZW1vdGUtY2FuZGlkYXRlcyZx dW90OywmbmJzcDsgJnF1b3Q7aWNlLWxpdGUmcXVvdDssICZxdW90O2ljZS1taXNtYXRjaCZxdW90 OywgJnF1b3Q7aWNlLXVmcmFnJnF1b3Q7LCAmcXVvdDtpY2UtcHdkJnF1b3Q7LCAmcXVvdDtpY2Ut cGFjaW5nJnF1b3Q7IGFuZCAmcXVvdDtpY2Utb3B0aW9ucyZxdW90OyBhdHRyaWJ1dGVzIHdpbGwg YmUgaWRlbnRpY2FsDQogd2l0aGluIGEgQlVORExFIGdyb3VwLCBzby4uLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7aWNl LWxpdGUmcXVvdDsgYW5kICZxdW90O2ljZS1vcHRpb25zJnF1b3Q7IGFyZSBzZXNzaW9uIGxldmVs IG9ubHkgY2FuZGlkYXRlcywgc28gdGhleSBzaG91bGQgbm90IGJlIGluIHRoZSBtPSBsaW5lIEJV TkRMRSBvciBhbnkgb3RoZXIgdHlwZS4gVGhlIHNhbWUgbG9naWMgdGhhdCBhcHBsaWVzIHRvIElD ZSBjYW5kaWRhdGVzIHNob3VsZCBhcHBseSB0byBvdGhlciBtZWRpYSBsZXZlbCBJQ0UgU0RQIGF0 dHJpYnV0ZXMgb3IgdGhpbmdzDQogd2lsbCBicmVhazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+ DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37E3054EESESSMB209erics_-- From nobody Mon Feb 22 11:16:41 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 DF79F1B2C01 for ; Mon, 22 Feb 2016 11:16:39 -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 GGsbON00DVEm for ; Mon, 22 Feb 2016 11:16:36 -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 CFD671ACDF9 for ; Mon, 22 Feb 2016 11:16:35 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-41-56cb5e91fbe4 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 74.D8.15637.19E5BC65; Mon, 22 Feb 2016 20:16:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 20:16:33 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lA= Date: Mon, 22 Feb 2016 19:16:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> In-Reply-To: <56C89F86.7020401@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7q+6kuNNhBkcWc1lMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG/5p2xoKv6hV/V21ibGBcId/FyMkhIWAi cXzvU0YIW0ziwr31bF2MXBxCAocZJTqm3mCBcBYzSlx//wIow8HBJmAh0f1PG6RBRMBX4tnj 22wgtrCAvsT7RUfYIeIGEntfHoCyrST273gEVsMioCpx7X0/C4jNC9Q749cCRpCRQgLVEreX BICEOQV0JGa1HgdrZQS65/upNUwgNrOAuMStJ/OZIO4UkFiy5zwzhC0q8fLxP1YIW0micckT Voh6HYkFuz+xQdjaEssWvmaGWCsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspN NzLWSy3KTC4uzs/Ty0st2cQIjJKDW36r7mC8/MbxEKMAB6MSD++GqNNhQqyJZcWVuYcYJTiY lUR4U2OAQrwpiZVVqUX58UWlOanFhxilOViUxHnXOK8PExJITyxJzU5NLUgtgskycXBKNTB6 z85sWfnsjFw1d6rx6zshlxZXLX/9aqnND9Wr546c/VI+yapF+9CChMjPM9LWxGV5L/yxdqUP 2+bLlqyx3PMe9HMcuSn+6XTtMQZ1xkjrpf15q98x38q6f+r6X2NRRi3LC4E7FWMfOUlMP5Ce Vuvzds4SmbeN845xTt6yol+d7XVf8mzFn4K3lFiKMxINtZiLihMBoJbJ0o4CAAA= Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 19:16:40 -0000 Hi, I had a talk with Martin about this, suggesting we put this in front of the= collective wisdom of MMUSIC, so I'll jump in. >> Section 8.3.2 of RFC 3264 says the following: >> >> "However, in the case of RTP, the mapping from a particular=20 >> dynamic payload type number to a particular codec within that media = stream MUST NOT=20 >> change for the duration of a session. For example, if A generates a= n offer >> with G.711 assigned to dynamic payload type number 46, payload type >> number 46 MUST refer to G.711 from that point forward in any offers >> or answers for that media stream within the session." > > As you know, this area is not well defined. > >> Now, assume the following case: >> >> 1.Alice sends an Offer, with the following PT values: >> >> PT 100: AMR-WB(mode-set=3D2) >> >> PT 111: AMR-WB(mode-set=3D2, OA) >> >> PT 0: PCMU >> >> 2.Bob sends the associated Answer: >> >> PT 100: AMR-WB (mode-set=3D2) >> >> PT 0: PCMU > > At this point, I think there is an open question of whether the "must not= change" even applies for a PT that was offered but not accepted in the ans= wer. Correct. That is one issue. If it *does* apply, the answerer would have to = remember everything that has been offered by the remote endpoint within the= session, even if it was not accepted in the answer. (Now, once could claim that there is no such thing as "accepting" a codec, = and that technically the answerer is allowed to send whatever was offered, = eventhough it most of the time wouldn't work in reality: endpoint will rese= rve resources for the codecs both parties indicate support for.) > One might argue that the real point of the requirement is that it can't b= e reused once there might be packets in flight using it. But that isn't tru= e in this case. So IMO it is uncharted territory. And it is not even a special case: offers including more codecs than the co= rresponding answer is more or less the norm, at least when we take codec co= nfigurations into consideration :) >> 3.Later Bob sends the following subsequent Offer: >> >> PT 111: AMR(mode-set=3D0,2,5,7) > > You mean the new offer no longer mentions 0 and 100, only 111 with this n= ew mapping? (Though I don't think the answer to that affects your > questions.) The new offer may have included 0 and 100 too, I don't remember. But, as yo= u say, it does not affect the question. The question is whether Bob can use= 111 for something else than Alice previously used it for. >> QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the=20 >> subsequent Offer, as Alice used PT 111 for AMR-WG in the initial Offer? >> In other words, does the >> pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-t >> he-session text in section 8.3.2 apply to user A only, or to **all**=20 >> users within the session? > > While it is *recommended* that the answer use the same PT as the offer fo= r a given codec configuration, that isn't *required*. The answer may accept= the codec from the offer using a different PT. Assuming Bob is allowed to offer 111, then I assume Alice would not be allo= wed to answer with 111, as Alice previously offered 111 for something else = - eventhough Bob did not "accept" it. > So, in the first answer Bob *could* have accepted the offer for AMR-WB(mo= de-set=3D2, OA) using some other PT (say 112). If so, when=20 > Bob subsequently sent an offer reusing the same codecs it would have used= 100, 112, and 0. (111 would not have been used.) In that case=20 > it seems like Bob would be free to use 111 for something else. Alice, in = her answer, would be free to map it to a different PT in order to avoid a c= lash with 111 on her end. >=20 > All of that seems equally applicable in your example, where Bob never acc= epted AMR-WB(mode-set=3D2, OA). Correct.=20 >> QUESTION 2: Assuming the text applies to all users, is it allowed to >> re-use a PT value for the same codec, but for a different CODEC=20 >> CONFIGURATION? The text only talks about codec. > > I think use of "codec" was just sloppy, and that it always meant codec co= nfiguration. I would probably agree with that, but it should be clarified. >> Now, I agree that the easiest way to avoid trouble is simply to make=20 >> sure PT values aren't re-used by any party. But, the text still needs=20 >> to be clear, because this is causing problems in real deployments. > > Agree. > > The spec is far from clear on this subject. A starting point for clarifyi= ng it to ascertain as best we can the original > intent.=20 What is the original intent? :) > But then we also need to try to understand common practice. Where this ha= s been unclear there may well=20 > be conflicting interpretations in the wild.=20 > *Somebody* is likely to be negatively affected by whatever decision we co= me to. It is always much easier to get things fixed when the specification is clea= r on who is wrong and who is right :) Regards, Christer From nobody Mon Feb 22 11:29: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 5DF761B2AD5 for ; Mon, 22 Feb 2016 11:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 fDWmdMfeVKUU for ; Mon, 22 Feb 2016 11:29:26 -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 DC2691A6FBC for ; Mon, 22 Feb 2016 11:29:25 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id z135so188965568iof.0 for ; Mon, 22 Feb 2016 11:29:25 -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=OIdif3aqTSVklzWR7lKjysBXkquMq6cm77NZBRpfCCI=; b=1z7mFdvz1FcXATT2bATGfJEXC1/jDbJgf9vN/2PpO6OnIfhUI4QGMQFlpmGAeeArxu J0PCy/1GofdE9jNVNXCkd3lxRpJze+2TFWzN3rU9QkZzqt0QCsroc/YxzznPbvlQXGUc fW8ZTK8+r0MiE0XrJPcXfd5IdQuDXja7FUfNdqnQM7KRA6VXwfZ0mmhzLrZOVvK2O8Bh BJIAKvtsXqpWYDVigNpIcUs+3/qmIMzXH4A3HyePEteVihwGHboqEE6eODHBYpx1mKHf mV9v3NpZFVwbeo1eTO8Vg+RSDTV3Imt5Z3ABolMZ9Uk/v/ZJCNYlkGmpXl4errnX/7HK QOjg== 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=OIdif3aqTSVklzWR7lKjysBXkquMq6cm77NZBRpfCCI=; b=EW2pMR22B8SLxGosdO6KYA9+8MxLxyJ93mNc7sQZRJ2GvXYgs9Qz6AzNH9DOiaZ86/ uN+ZUj9otpkApSLUPPW9/5PTmdzjY+rxG2/AtkN104JuX40XcbrZ+cpmcf2xa5yGPbb0 2bLMtGqwbm9sW77cQJFTS+vrI9hFrMxI6HZ6+CW9XfeMgydkC9ezmQI7+G+15XURCNga i4SoVDaGOTQOny2k4fu1mE/UEkMaa6rKB+hw/9qDLLxa8+E2a64TaCfxFQ29huSBoZOH CRa0yRfcoHPowuUtvfeNBv91F2Rwd+TAA3fPIEIhfHFHRCrypbFGewY+PEsBsTidtCAc etAA== X-Gm-Message-State: AG10YOSRCIyxPnf+4024EKdi1sPMQtCrZkBJPpS2p3VBnMiLLOZZCSD9BowZzaH6CiR5Hw== X-Received: by 10.107.19.213 with SMTP id 82mr31092684iot.6.1456169365258; Mon, 22 Feb 2016 11:29:25 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id t2sm9796154igs.3.2016.02.22.11.29.23 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 11:29:24 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id y8so94584734igp.0 for ; Mon, 22 Feb 2016 11:29:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr4242685igh.2.1456169363410; Mon, 22 Feb 2016 11:29:23 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 22 Feb 2016 11:29:23 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E3054E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E3054E@ESESSMB209.ericsson.se> Date: Mon, 22 Feb 2016 14:29:23 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bdca2eca399c3052c60d950 Archived-At: Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text 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, 22 Feb 2016 19:29:28 -0000 --047d7bdca2eca399c3052c60d950 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 22, 2016 at 5:10 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Assuming we will only associated ICE candidates to the =E2=80=9Cm=3D=E2= =80=9D line > associated with the offerer/answerer BUNDLE-tag, below is a first suggest= ed > of modified =E2=80=98ICE Considerations=E2=80=99 text: > > > > ----------------------- > > > > 11. ICE Considerations > > > > 11.1. General > > > > This section describes how to use the BUNDLE grouping extension > > together with the Interactive Connectivity Establishment (ICE) > > mechanism [RFC5245]. > > > > The generic procedures for negotiating usage of ICE using SDP, > > defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE > > with BUNDLE, with the following exceptions: > > > > o When BUNDLE addresses for a BUNDLE group have been selected for > > both endpoints, ICE connectivity checks and keep-alives only need > > to be performed for the whole BUNDLE group, instead of per bundled > > "m=3D" line. > > > > o Among bundled "m=3D" lines with which the offerer has associated a > > shared address, the offerer only associates ICE-related media- > > level SDP attributes with the "m=3D" line associated with the > > offerer BUNDLE-tag. > > > > o Among bundled "m=3D" lines with which the answerer has associated a > > shared address, the answerer only associates ICE-related media- > > level SDP attributes with the "m=3D" line associated with the > > answerer BUNDLE-tag. > > > > Support and usage of ICE mechanism together with the BUNDLE extension > > is OPTIONAL. > > > > 11.2. SDP Offer/Answer Procedures > > > > 11.2.1. General > > > > When an offerer associates a unique address with a bundled "m=3D" line > > (excluding any bundle-only "m=3D" line), it MUST also associate unique > > ICE candidates to the "m=3D" line, according to the procedures in > > [I-D.ietf-mmusic-ice-sip-sdp]. > > > > An offerer MUST NOT associate ICE candidates with a bundle-only "m=3D" > > line with a zero port value. > > > > NOTE: The bundle-only "m=3D" line, if accepted by the answerer, will > > inherit the candidates associated with the selected offerer BUNDLE > > address. An answerer that does not support BUNDLE would not accept a > > bundle-only "m=3D" line. > > > > When an offerer or answerer associates a shared address (i.e. a > > previously selected BUNDLE address) with one or more bundled "m=3D" > > lines, the offerer (or answerer) MUST only associate SDP 'candidate' > > attributes with the "m=3D" line associated with the offerer BUNDLE-tag > > (or the answerer BUNDLE-tag) address). The offerer or answerer MUST > > NOT associate 'candidiate' attributes with any other bundled "m=3D" > > line to which the offerer (or answerer) associates a shared address. > > This also apply to any other ICE-related media-level SDP attribute. > > > > NOTE: The following ICE-related media-level SDP attributes are > > defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- > > candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- > > pacing'. > > > > 11.2.2. Generating the Initial SDP Offer > > > > When an offerer generates an initial offer, it associates unique ICE > > candidates with the bundled "m=3D" lines, according to Section 11.2.1. > > > > 11.2.3. Generating the SDP Answer > > > > When an answerer generates an answer that contains a BUNDLE group, > > the answerer MUST only associate SDP 'candidate' attributes (and > > other ICE-related media-level SDP attributes) with the "m=3D" line > > associated with the answerer BUNDLE-tag. > > > > 11.2.4. Offerer Processing of the SDP Answer > > > > When an offerer receives an answer, if the answerer supports and uses > > the ICE mechanism and the BUNDLE extension, the offerer MUST > > associate the same ICE candidates, associated with the "m=3D" line > > representing the offerer BUNDLE address (selected by the answerer), > > with each bundled "m=3D" line. > > > > 11.2.5. Modifying the Session > > > > When an offerer generates a subsequent offer, it associates unique or > > shared ICE candidates with the bundled "m=3D" lines, according to > > (Section 11.2.1). > > > I am not 100% sure about what exactly is meant by ICE candidate being associated with an m=3D line. Does this mean ICE candidate is created for this m=3D line and "candidate" SDP attribute is included in this m=3D line? Overall the text is good, but I would explicitly replace "ICE candidates" with "ICE candidates or any other ICE-related media-level SDP attributes" to avoid any potential confusion. This will also make the phrase "This also apply to any other ICE-related media-level SDP attribute" unnecessary. _____________ Roman Shpount --047d7bdca2eca399c3052c60d950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 22, 2016 at 5:10 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Assuming we will only associated ICE candida= tes to the =E2=80=9Cm=3D=E2=80=9D line associated with the offerer/answerer= BUNDLE-tag, below is a first suggested of modified =E2=80=98ICE Considerations=E2=80=99 text:

=C2=A0

-----------------------=

=C2=A0

11.=C2=A0 ICE Considerations

=C2=A0

11.1.=C2=A0 General

=C2=A0

=C2=A0=C2=A0 This section describes how to use the BUNDLE grou= ping extension

=C2=A0=C2=A0 together with the Interactive Connectivity Establ= ishment (ICE)

=C2=A0=C2=A0 mechanism [RFC5245].

=C2=A0

=C2=A0=C2=A0 The generic procedures for negotiating usage of I= CE using SDP,

=C2=A0=C2=A0 defined in [I-D.ietf-mmusic-ice-sip-sdp], also ap= ply to usage of ICE

=C2=A0=C2=A0 with BUNDLE, with the following exceptions:

=C2=A0

=C2=A0=C2=A0 o=C2=A0 When BUNDLE addresses for a BUNDLE group = have been selected for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 both endpoints, ICE connectivit= y checks and keep-alives only need

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to be performed for the whole B= UNDLE group, instead of per bundled

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "m=3D" line.

=C2=A0

=C2=A0=C2=A0 o =C2=A0Among bundled "m=3D" lines with= which the offerer has associated a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 shared address, the offerer onl= y associates ICE-related media-

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 level SDP attributes with the &= quot;m=3D" line associated with the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 offerer BUNDLE-tag.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Among bundled "m=3D" lines with= which the answerer has associated a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 shared address, the answerer on= ly associates ICE-related media-

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 level SDP attributes with the &= quot;m=3D" line associated with the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 answerer BUNDLE-tag.<= /u>

=C2=A0

=C2=A0=C2=A0 Support and usage of ICE mechanism together with = the BUNDLE extension

=C2=A0=C2=A0 is OPTIONAL.

=C2=A0

11.2.=C2=A0 SDP Offer/Answer Procedures

=C2=A0

11.2.1.=C2=A0 General

=C2=A0

=C2=A0=C2=A0 When an offerer associates a unique address with = a bundled "m=3D" line

=C2=A0=C2=A0 (excluding any bundle-only "m=3D" line)= , it MUST also associate unique

=C2=A0=C2=A0 ICE candidates to the "m=3D" line, acco= rding to the procedures in

=C2=A0=C2=A0 [I-D.ietf-mmusic-ice-sip-sdp].

=C2=A0

=C2=A0=C2=A0 An offerer MUST NOT associate ICE candidates with= a bundle-only "m=3D"

=C2=A0=C2=A0 line with a zero port value.=

=C2=A0

=C2=A0=C2=A0 NOTE: The bundle-only "m=3D" line, if a= ccepted by the answerer, will

=C2=A0=C2=A0 inherit the candidates associated with the select= ed offerer BUNDLE

=C2=A0=C2=A0 address.=C2=A0 An answerer that does not support = BUNDLE would not accept a

=C2=A0=C2=A0 bundle-only "m=3D" line.<= /span>

=C2=A0

=C2=A0=C2=A0 When an offerer or answerer associates a shared a= ddress (i.e. a

=C2=A0=C2=A0 previously selected BUNDLE address) with one or m= ore bundled "m=3D"

=C2=A0=C2=A0 lines, the offerer (or answerer) MUST only associ= ate SDP 'candidate'

=C2=A0=C2=A0 attributes with the "m=3D" line associa= ted with the offerer BUNDLE-tag

=C2=A0=C2=A0 (or the answerer BUNDLE-tag) address).=C2=A0 The = offerer or answerer MUST

=C2=A0=C2=A0 NOT associate 'candidiate' attributes wit= h any other bundled "m=3D"

=C2=A0=C2=A0 line to which the offerer (or answerer) associate= s a shared address.

=C2=A0=C2=A0 This also apply to any other ICE-related media-le= vel SDP attribute.

=C2=A0

=C2=A0=C2=A0 NOTE: The following ICE-related media-level SDP a= ttributes are

=C2=A0=C2=A0 defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'ca= ndidiate', 'remote-

=C2=A0=C2=A0 candidates', 'ice-mismatch', 'ice= -ufrag', 'ice-pwd', and 'ice-

=C2=A0=C2=A0 pacing'.

=C2=A0

11.2.2.=C2=A0 Generating the Initial SDP Offer

=C2=A0

=C2=A0=C2=A0 When an offerer generates an initial offer, it as= sociates unique ICE

=C2=A0=C2=A0 candidates with the bundled "m=3D" line= s, according to Section 11.2.1.

=C2=A0

11.2.3.=C2=A0 Generating the SDP Answer

=C2=A0

=C2=A0=C2=A0 When an answerer generates an answer that contain= s a BUNDLE group,

=C2=A0=C2=A0 the answerer MUST only associate SDP 'candida= te' attributes (and

=C2=A0=C2=A0 other ICE-related media-level SDP attributes) wit= h the "m=3D" line

=C2=A0=C2=A0 associated with the answerer BUNDLE-tag.

=C2=A0

11.2.4.=C2=A0 Offerer Processing of the SDP Answer

=C2=A0

=C2=A0=C2=A0 When an offerer receives an answer, if the answer= er supports and uses

=C2=A0=C2=A0 the ICE mechanism and the BUNDLE extension, the o= fferer MUST

=C2=A0=C2=A0 associate the same ICE candidates, associated wit= h the "m=3D" line

=C2=A0=C2=A0 representing the offerer BUNDLE address (selected= by the answerer),

=C2=A0=C2=A0 with each bundled "m=3D" line.

=C2=A0

11.2.5.=C2=A0 Modifying the Session

=C2=A0

=C2=A0=C2=A0 When an offerer generates a subsequent offer, it = associates unique or

=C2=A0=C2=A0 shared ICE candidates with the bundled "m=3D= " lines, according to

=C2=A0=C2=A0 (Section 11.2.1).



I am= not 100% sure about what exactly is meant by ICE candidate being associate= d with an m=3D line. Does this mean ICE candidate is created for this m=3D = line and "candidate" SDP attribute is included in this m=3D line?=

Overall the text is good, but I = would explicitly replace "ICE candidates" with "ICE candidat= es or any other ICE-related media-level SDP attributes" to avoid any p= otential confusion. This will also make the phrase "This also apply to= any other ICE-related media-level SDP attribute" unnecessary.
_____________
Rom= an Shpount
=C2=A0
--047d7bdca2eca399c3052c60d950-- From nobody Mon Feb 22 11:52:41 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 7A78B1A016C for ; Mon, 22 Feb 2016 11:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 luiPFUROhqJn for ; Mon, 22 Feb 2016 11:52:39 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 CE3DD1A0151 for ; Mon, 22 Feb 2016 11:52:38 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id z135so189691478iof.0 for ; Mon, 22 Feb 2016 11:52:38 -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=qNX4+SLmPdLcjLZqwkZLSixN8afgvQVpYVtgaY1uNJc=; b=ZXF6vcXT6TtIhQwIjWlCEukRVeSchXn/QfOeXdoMpbcHFk3jwB1W9i6d4yReZ/uHVo 4iOSDBMjP9aRgq0n2rIQ/pkX4vHJWFuVqYA7a9NdcrzVH30nzVlC3S5f0JEbgpCbq+aq mJA3+Y+d+Wfq1MVbrSO18B76o9+z5s2Xp1Q2M+4Kx5KA5yQhXwPlycO8+xy+2fBdRvBl cVu+hsaxpAgWCED77qhPRQkXuM+1N+3XE5jpDnQlNLcfBeLu4oO8v4bAzyBM0k4hrzZ6 BpTLaqKBWQPtiJG337AfO0Q5JNBrqtTQ7ho9Ni6D7SefhOkhOWpqdgf9fGaDJkbGd76T THoQ== 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=qNX4+SLmPdLcjLZqwkZLSixN8afgvQVpYVtgaY1uNJc=; b=T8ShrDdoeWiz/7GEWY48N6OimvPzSL/zok7Aw6uwQpfItfUoCgcQM58I62GSU2rB8W WzBK3RoCThROh6fM5GCgfgt4LHHIuYlHsdoc5xjOnEjLzv0EUjy0CXTP6QxjCCHnH5pr zCqN4sU6fSU8iS8FE3sKtDNRYxUITVGrmcuXJYdQKw4CZRtBifeHw8dh+V90X4gj5X0N XrVQYlaVCIxOWHxESdaTqDJWsz8gYXRBW2Du0isxFg6/FJdPSuXKgAIeLMeIwLpsW5gd QvI2UYszOE6lAK7NSHOJPj4g44ue37R3V7oZvzigV62jHpnTwnr8qseQ7YHXlLUcjjqV cjTg== X-Gm-Message-State: AG10YOQCyqmngoW/lkl8tcNGwdv1uHynt5mHmQMnV4/LEZvV9ZZfoTMXHRpbr5m/bFq02Q== X-Received: by 10.107.11.231 with SMTP id 100mr28683741iol.165.1456170758229; Mon, 22 Feb 2016 11:52:38 -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 l9sm9824507igx.4.2016.02.22.11.52.36 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 11:52:36 -0800 (PST) Received: by mail-io0-f173.google.com with SMTP id l127so188964857iof.3 for ; Mon, 22 Feb 2016 11:52:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr30877386iod.145.1456170756155; Mon, 22 Feb 2016 11:52:36 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 22 Feb 2016 11:52:36 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> Date: Mon, 22 Feb 2016 14:52:36 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113ece60a73585052c612c93 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 19:52:40 -0000 --001a113ece60a73585052c612c93 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 22, 2016 at 2:16 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >> Section 8.3.2 of RFC 3264 says the following: > >> > >> "However, in the case of RTP, the mapping from a particular > >> dynamic payload type number to a particular codec within that media > stream MUST NOT > >> change for the duration of a session. For example, if A generates > an offer > >> with G.711 assigned to dynamic payload type number 46, payload type > >> number 46 MUST refer to G.711 from that point forward in any offers > >> or answers for that media stream within the session." > One thing that bothered me here is that PT cannot be reused for the duration of the session. It is probably safe to reuse the PT after session modification if PT is no longer used. I always felt that dynamic PT reuse criteria were much stricter then realistically possible or needed. > >> Now, assume the following case: > >> > >> 1.Alice sends an Offer, with the following PT values: > >> > >> PT 100: AMR-WB(mode-set=2) > >> > >> PT 111: AMR-WB(mode-set=2, OA) > >> > >> PT 0: PCMU > >> > >> 2.Bob sends the associated Answer: > >> > >> PT 100: AMR-WB (mode-set=2) > >> > >> PT 0: PCMU > > > > At this point, I think there is an open question of whether the "must > not change" even applies for a PT that was offered but not accepted in the > answer. > >> 3.Later Bob sends the following subsequent Offer: > >> > >> PT 111: AMR(mode-set=0,2,5,7) > > > > You mean the new offer no longer mentions 0 and 100, only 111 with this > new mapping? (Though I don't think the answer to that affects your > > questions.) > I think the most important criteria here is that there should be no ambiguity regarding how an RTP packet with particular PT should be decoded. If it is guaranteed that there are no packets sent between Alice and Bob with PT 111 over some reasonable time interval (couple of network round trip times), then PT 111 can be safely reused. If, in this scenario Bob's end point knows that it was not sending anything with payload 111 recently, then it can safely reuse this payload. Alice could not be sending anything with payload 111 since Bob did not accept it previously. On the other hand, Bob must not reuse PT 100 for, let's say, CN, since there are packets with this payload in flight and this will create decoding ambiguity. To conclude, an end point should be able to safely reuse any PT that it is not currently accepting or was not sending or accepting for at least a few network round trip intervals. Regards, ______________ Roman Shpount --001a113ece60a73585052c612c93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 22, 2016 at 2:1= 6 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
>> Section 8.3.2 o= f RFC 3264 says the following:
>>
>>=C2=A0 =C2=A0 =C2=A0"However, in the case of RTP, the mapping = from a particular
>>=C2=A0 =C2=A0 =C2=A0dynamic payload type number to a particular cod= ec within that media stream MUST NOT
>>=C2=A0 =C2=A0 =C2=A0change for the duration of a session.=C2=A0 For= example, if A generates an offer
>>=C2=A0 =C2=A0 =C2=A0with G.711 assigned to dynamic payload type num= ber 46, payload type
>>=C2=A0 =C2=A0 =C2=A0number 46 MUST refer to G.711 from that point f= orward in any offers
>>=C2=A0 =C2=A0 or answers for that media stream within the session.&= quot;

One thing that bothered me here i= s that PT cannot be reused for the duration of the session. It is probably = safe to reuse the PT after session modification if PT is no longer used. I = always felt that dynamic PT reuse criteria were much stricter then realisti= cally possible or needed.=C2=A0
=C2=A0
>> Now, assume the following case:
>>
>> 1.Alice sends an Offer, with the following PT values:
>>
>> PT 100: AMR-WB(mode-set=3D2)
>>
>> PT 111: AMR-WB(mode-set=3D2, OA)
>>
>> PT 0: PCMU
>>
>> 2.Bob sends the associated Answer:
>>
>> PT 100: AMR-WB (mode-set=3D2)
>>
>> PT 0: PCMU
>
> At this point, I think there is an open question of whether the "= must not change" even applies for a PT that was offered but not accept= ed in the answer.
>> 3.Later Bob sends the following subsequent Of= fer:
>>
>> PT 111: AMR(mode-set=3D0,2,5,7)
>
> You mean the new offer no longer mentions 0 and 100, only 111 with thi= s new mapping? (Though I don't think the answer to that affects your > questions.)

I think the most impor= tant criteria here is that there should be no ambiguity regarding how an RT= P packet with particular PT should be decoded. If it is guaranteed that the= re are no packets sent between Alice and Bob with PT 111 over some reasonab= le time interval (couple of network round trip times), then PT 111 can be s= afely reused. If, in this scenario Bob's end point knows that it was no= t sending anything with payload 111 recently, then it can safely reuse this= payload. Alice could not be sending anything with payload 111 since Bob di= d not accept it previously. On the other hand, Bob must not reuse PT 100 fo= r, let's say, CN, since there are packets with this payload in flight a= nd this will create decoding ambiguity. To conclude, an end point should be= able to safely reuse any PT that it is not currently accepting or was not = sending or accepting for at least a few network round trip intervals.
=

Regards,
______________
Roman Shpou= nt=C2=A0
--001a113ece60a73585052c612c93-- From nobody Mon Feb 22 12:09: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 41D451A036B for ; Mon, 22 Feb 2016 12:09: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 8fEzwo4oNPO7 for ; Mon, 22 Feb 2016 12:09:54 -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 4BE681A01A8 for ; Mon, 22 Feb 2016 12:09:53 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-2d-56cb6b0f868e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.69.02707.F0B6BC65; Mon, 22 Feb 2016 21:09:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 21:09:50 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text Thread-Index: AdFtWOeeQ/zW0OtpRAOrN5PglHqZIwARgwCAAAN2fGA= Date: Mon, 22 Feb 2016 20:09:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E35F30@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E3054E@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E35F30ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2J7uC5/9ukwg/tfxC2mLn/MYrFiwwFW i2vLX7NazLgwldmBxePv+w9MHgs2lXosWfKTyePWlIIAligum5TUnMyy1CJ9uwSujJ7dF9gK 3p1hqni55C1jA+OUI0xdjJwcEgImEitnnWSBsMUkLtxbz9bFyMUhJHCYUeLYo8tMEM5iRold l+8xdjFycLAJWEh0/9MGaRARUJX4+30yWA2zwEZGid99j1lBEsICwRLXuzezQRSFSCyefpoZ pFdEwEpi7ht+kDALUO/0XV8YQWxeAV+J9w/2MUPsmsIoMfvhVLDrOAUCJe70t4DZjEDXfT+1 BsxmFhCXuPVkPtQHAhJL9pxnhrBFJV4+/scKYStJNC55wgqyl1kgX+LXFCWIXYISJ2c+YZnA KDoLyaRZCFWzkFRBhDUl1u/Sh6hWlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4qTcdCMjvdSi zOTi4vw8vbzUkk2MwJg8uOW3wQ7Gl88dDzEKcDAq8fBuiDodJsSaWFZcmXuIUYKDWUmENzUG KMSbklhZlVqUH19UmpNafIhRmoNFSZx3tfP6MCGB9MSS1OzU1ILUIpgsEwenVAPj2proA2sn rT2Z/ER8U/mMpm96ZSllZ/smr1st1/ZI4Eeuw8+kgP7Kg8JTBYSrF3zPkVi5cvKyY0yPbHTe fTEovXc5Y7+UwZS+ZK2v15dtP3CkbUmQD+fOJIWzpcZZt1c0VC2O+PIiO+xSXdF73m83Bf/f crTnf91xo7B82UI/gxmM129/XXxDVYmlOCPRUIu5qDgRAEVhNLjFAgAA Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text 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, 22 Feb 2016 20:09:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E35F30ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCk15IGludGVudGlvbiB3YXMgdG8gcmVwbGFjZSDigJxJQ0UgY2FuZGlkYXRl c+KAnSB3aXRoIOKAnFNEUCDigJhjYW5kaWRhdGXigJkgYXR0cmlidXRlc+KAnSB3aGVuIHJlbGF0 ZWQgdG8gbT0gbGluZXMuIFNlZW1zIGxpa2UgSSBmb3Jnb3QgYWJvdXQgaXQgb25jZSBJIGdvdCBw YXN0IHRoZSBHZW5lcmFsIHNlY3Rpb27igKYgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K RnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMjIg RmVicnVhcnkgMjAxNiAyMToyOQ0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogbW11c2ljQGlldGYub3JnOyBQYXVsIEt5eml2YXQgPHBr eXppdmF0QGFsdW0ubWl0LmVkdT47IFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNv bT47IEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPg0KU3ViamVjdDogUmU6 IFtNTVVTSUNdIFF1ZXN0aW9ucyBhYm91dCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEJVTkRMRSAtIHN1 Z2dlc3RlZCB0ZXh0DQoNCk9uIE1vbiwgRmViIDIyLCAyMDE2IGF0IDU6MTAgQU0sIENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KQXNzdW1pbmcgd2Ugd2lsbCBvbmx5IGFz c29jaWF0ZWQgSUNFIGNhbmRpZGF0ZXMgdG8gdGhlIOKAnG094oCdIGxpbmUgYXNzb2NpYXRlZCB3 aXRoIHRoZSBvZmZlcmVyL2Fuc3dlcmVyIEJVTkRMRS10YWcsIGJlbG93IGlzIGEgZmlyc3Qgc3Vn Z2VzdGVkIG9mIG1vZGlmaWVkIOKAmElDRSBDb25zaWRlcmF0aW9uc+KAmSB0ZXh0Og0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoxMS4gIElDRSBDb25zaWRlcmF0aW9ucw0KDQoxMS4xLiAg R2VuZXJhbA0KDQogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGhvdyB0byB1c2UgdGhlIEJVTkRM RSBncm91cGluZyBleHRlbnNpb24NCiAgIHRvZ2V0aGVyIHdpdGggdGhlIEludGVyYWN0aXZlIENv bm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0UpDQogICBtZWNoYW5pc20gW1JGQzUyNDVdLg0K DQogICBUaGUgZ2VuZXJpYyBwcm9jZWR1cmVzIGZvciBuZWdvdGlhdGluZyB1c2FnZSBvZiBJQ0Ug dXNpbmcgU0RQLA0KICAgZGVmaW5lZCBpbiBbSS1ELmlldGYtbW11c2ljLWljZS1zaXAtc2RwXSwg YWxzbyBhcHBseSB0byB1c2FnZSBvZiBJQ0UNCiAgIHdpdGggQlVORExFLCB3aXRoIHRoZSBmb2xs b3dpbmcgZXhjZXB0aW9uczoNCg0KICAgbyAgV2hlbiBCVU5ETEUgYWRkcmVzc2VzIGZvciBhIEJV TkRMRSBncm91cCBoYXZlIGJlZW4gc2VsZWN0ZWQgZm9yDQogICAgICBib3RoIGVuZHBvaW50cywg SUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgYW5kIGtlZXAtYWxpdmVzIG9ubHkgbmVlZA0KICAgICAg dG8gYmUgcGVyZm9ybWVkIGZvciB0aGUgd2hvbGUgQlVORExFIGdyb3VwLCBpbnN0ZWFkIG9mIHBl ciBidW5kbGVkDQogICAgICAibT0iIGxpbmUuDQoNCiAgIG8gIEFtb25nIGJ1bmRsZWQgIm09IiBs aW5lcyB3aXRoIHdoaWNoIHRoZSBvZmZlcmVyIGhhcyBhc3NvY2lhdGVkIGENCiAgICAgIHNoYXJl ZCBhZGRyZXNzLCB0aGUgb2ZmZXJlciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJlbGF0ZWQgbWVkaWEt DQogICAgICBsZXZlbCBTRFAgYXR0cmlidXRlcyB3aXRoIHRoZSAibT0iIGxpbmUgYXNzb2NpYXRl ZCB3aXRoIHRoZQ0KICAgICAgb2ZmZXJlciBCVU5ETEUtdGFnLg0KDQogICBvICBBbW9uZyBidW5k bGVkICJtPSIgbGluZXMgd2l0aCB3aGljaCB0aGUgYW5zd2VyZXIgaGFzIGFzc29jaWF0ZWQgYQ0K ICAgICAgc2hhcmVkIGFkZHJlc3MsIHRoZSBhbnN3ZXJlciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJl bGF0ZWQgbWVkaWEtDQogICAgICBsZXZlbCBTRFAgYXR0cmlidXRlcyB3aXRoIHRoZSAibT0iIGxp bmUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgICAgYW5zd2VyZXIgQlVORExFLXRhZy4NCg0KICAg U3VwcG9ydCBhbmQgdXNhZ2Ugb2YgSUNFIG1lY2hhbmlzbSB0b2dldGhlciB3aXRoIHRoZSBCVU5E TEUgZXh0ZW5zaW9uDQogICBpcyBPUFRJT05BTC4NCg0KMTEuMi4gIFNEUCBPZmZlci9BbnN3ZXIg UHJvY2VkdXJlcw0KDQoxMS4yLjEuICBHZW5lcmFsDQoNCiAgIFdoZW4gYW4gb2ZmZXJlciBhc3Nv Y2lhdGVzIGEgdW5pcXVlIGFkZHJlc3Mgd2l0aCBhIGJ1bmRsZWQgIm09IiBsaW5lDQogICAoZXhj bHVkaW5nIGFueSBidW5kbGUtb25seSAibT0iIGxpbmUpLCBpdCBNVVNUIGFsc28gYXNzb2NpYXRl IHVuaXF1ZQ0KICAgSUNFIGNhbmRpZGF0ZXMgdG8gdGhlICJtPSIgbGluZSwgYWNjb3JkaW5nIHRv IHRoZSBwcm9jZWR1cmVzIGluDQogICBbSS1ELmlldGYtbW11c2ljLWljZS1zaXAtc2RwXS4NCg0K ICAgQW4gb2ZmZXJlciBNVVNUIE5PVCBhc3NvY2lhdGUgSUNFIGNhbmRpZGF0ZXMgd2l0aCBhIGJ1 bmRsZS1vbmx5ICJtPSINCiAgIGxpbmUgd2l0aCBhIHplcm8gcG9ydCB2YWx1ZS4NCg0KICAgTk9U RTogVGhlIGJ1bmRsZS1vbmx5ICJtPSIgbGluZSwgaWYgYWNjZXB0ZWQgYnkgdGhlIGFuc3dlcmVy LCB3aWxsDQogICBpbmhlcml0IHRoZSBjYW5kaWRhdGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2Vs ZWN0ZWQgb2ZmZXJlciBCVU5ETEUNCiAgIGFkZHJlc3MuICBBbiBhbnN3ZXJlciB0aGF0IGRvZXMg bm90IHN1cHBvcnQgQlVORExFIHdvdWxkIG5vdCBhY2NlcHQgYQ0KICAgYnVuZGxlLW9ubHkgIm09 IiBsaW5lLg0KDQogICBXaGVuIGFuIG9mZmVyZXIgb3IgYW5zd2VyZXIgYXNzb2NpYXRlcyBhIHNo YXJlZCBhZGRyZXNzIChpLmUuIGENCiAgIHByZXZpb3VzbHkgc2VsZWN0ZWQgQlVORExFIGFkZHJl c3MpIHdpdGggb25lIG9yIG1vcmUgYnVuZGxlZCAibT0iDQogICBsaW5lcywgdGhlIG9mZmVyZXIg KG9yIGFuc3dlcmVyKSBNVVNUIG9ubHkgYXNzb2NpYXRlIFNEUCAnY2FuZGlkYXRlJw0KICAgYXR0 cmlidXRlcyB3aXRoIHRoZSAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBvZmZlcmVyIEJV TkRMRS10YWcNCiAgIChvciB0aGUgYW5zd2VyZXIgQlVORExFLXRhZykgYWRkcmVzcykuICBUaGUg b2ZmZXJlciBvciBhbnN3ZXJlciBNVVNUDQogICBOT1QgYXNzb2NpYXRlICdjYW5kaWRpYXRlJyBh dHRyaWJ1dGVzIHdpdGggYW55IG90aGVyIGJ1bmRsZWQgIm09Ig0KICAgbGluZSB0byB3aGljaCB0 aGUgb2ZmZXJlciAob3IgYW5zd2VyZXIpIGFzc29jaWF0ZXMgYSBzaGFyZWQgYWRkcmVzcy4NCiAg IFRoaXMgYWxzbyBhcHBseSB0byBhbnkgb3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQ IGF0dHJpYnV0ZS4NCg0KICAgTk9URTogVGhlIGZvbGxvd2luZyBJQ0UtcmVsYXRlZCBtZWRpYS1s ZXZlbCBTRFAgYXR0cmlidXRlcyBhcmUNCiAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLW1tdXNpYy1p Y2Utc2lwLXNkcF06ICdjYW5kaWRpYXRlJywgJ3JlbW90ZS0NCiAgIGNhbmRpZGF0ZXMnLCAnaWNl LW1pc21hdGNoJywgJ2ljZS11ZnJhZycsICdpY2UtcHdkJywgYW5kICdpY2UtDQogICBwYWNpbmcn Lg0KDQoxMS4yLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcg0KDQogICBXaGVu IGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGFuIGluaXRpYWwgb2ZmZXIsIGl0IGFzc29jaWF0ZXMgdW5p cXVlIElDRQ0KICAgY2FuZGlkYXRlcyB3aXRoIHRoZSBidW5kbGVkICJtPSIgbGluZXMsIGFjY29y ZGluZyB0byBTZWN0aW9uIDExLjIuMS4NCg0KMTEuMi4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFu c3dlcg0KDQogICBXaGVuIGFuIGFuc3dlcmVyIGdlbmVyYXRlcyBhbiBhbnN3ZXIgdGhhdCBjb250 YWlucyBhIEJVTkRMRSBncm91cCwNCiAgIHRoZSBhbnN3ZXJlciBNVVNUIG9ubHkgYXNzb2NpYXRl IFNEUCAnY2FuZGlkYXRlJyBhdHRyaWJ1dGVzIChhbmQNCiAgIG90aGVyIElDRS1yZWxhdGVkIG1l ZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGVzKSB3aXRoIHRoZSAibT0iIGxpbmUNCiAgIGFzc29jaWF0 ZWQgd2l0aCB0aGUgYW5zd2VyZXIgQlVORExFLXRhZy4NCg0KMTEuMi40LiAgT2ZmZXJlciBQcm9j ZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2VyDQoNCiAgIFdoZW4gYW4gb2ZmZXJlciByZWNlaXZlcyBh biBhbnN3ZXIsIGlmIHRoZSBhbnN3ZXJlciBzdXBwb3J0cyBhbmQgdXNlcw0KICAgdGhlIElDRSBt ZWNoYW5pc20gYW5kIHRoZSBCVU5ETEUgZXh0ZW5zaW9uLCB0aGUgb2ZmZXJlciBNVVNUDQogICBh c3NvY2lhdGUgdGhlIHNhbWUgSUNFIGNhbmRpZGF0ZXMsIGFzc29jaWF0ZWQgd2l0aCB0aGUgIm09 IiBsaW5lDQogICByZXByZXNlbnRpbmcgdGhlIG9mZmVyZXIgQlVORExFIGFkZHJlc3MgKHNlbGVj dGVkIGJ5IHRoZSBhbnN3ZXJlciksDQogICB3aXRoIGVhY2ggYnVuZGxlZCAibT0iIGxpbmUuDQoN CjExLjIuNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KDQogICBXaGVuIGFuIG9mZmVyZXIgZ2Vu ZXJhdGVzIGEgc3Vic2VxdWVudCBvZmZlciwgaXQgYXNzb2NpYXRlcyB1bmlxdWUgb3INCiAgIHNo YXJlZCBJQ0UgY2FuZGlkYXRlcyB3aXRoIHRoZSBidW5kbGVkICJtPSIgbGluZXMsIGFjY29yZGlu ZyB0bw0KICAgKFNlY3Rpb24gMTEuMi4xKS4NCg0KDQpJIGFtIG5vdCAxMDAlIHN1cmUgYWJvdXQg d2hhdCBleGFjdGx5IGlzIG1lYW50IGJ5IElDRSBjYW5kaWRhdGUgYmVpbmcgYXNzb2NpYXRlZCB3 aXRoIGFuIG09IGxpbmUuIERvZXMgdGhpcyBtZWFuIElDRSBjYW5kaWRhdGUgaXMgY3JlYXRlZCBm b3IgdGhpcyBtPSBsaW5lIGFuZCAiY2FuZGlkYXRlIiBTRFAgYXR0cmlidXRlIGlzIGluY2x1ZGVk IGluIHRoaXMgbT0gbGluZT8NCg0KT3ZlcmFsbCB0aGUgdGV4dCBpcyBnb29kLCBidXQgSSB3b3Vs ZCBleHBsaWNpdGx5IHJlcGxhY2UgIklDRSBjYW5kaWRhdGVzIiB3aXRoICJJQ0UgY2FuZGlkYXRl cyBvciBhbnkgb3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0ZXMiIHRv IGF2b2lkIGFueSBwb3RlbnRpYWwgY29uZnVzaW9uLiBUaGlzIHdpbGwgYWxzbyBtYWtlIHRoZSBw aHJhc2UgIlRoaXMgYWxzbyBhcHBseSB0byBhbnkgb3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2 ZWwgU0RQIGF0dHJpYnV0ZSIgdW5uZWNlc3NhcnkuDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBv dW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37E35F30ESESSMB209erics_ 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 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk15IGludGVudGlvbiB3YXMgdG8gcmVwbGFj ZSDigJxJQ0UgY2FuZGlkYXRlc+KAnSB3aXRoIOKAnFNEUCDigJhjYW5kaWRhdGXigJkgYXR0cmli dXRlc+KAnSB3aGVuIHJlbGF0ZWQgdG8gbT0gbGluZXMuIFNlZW1zIGxpa2UgSSBmb3Jnb3QgYWJv dXQNCiBpdCBvbmNlIEkgZ290IHBhc3QgdGhlIEdlbmVyYWwgc2VjdGlvbuKApiA6KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IDIyIEZlYnJ1YXJ5IDIwMTYgMjE6Mjk8YnI+DQo8Yj5Ubzo8L2I+IENo cmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBtbXVzaWNAaWV0Zi5vcmc7IFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRA YWx1bS5taXQuZWR1Jmd0OzsgUGV0ZXIgVGhhdGNoZXIgJmx0O3B0aGF0Y2hlckBnb29nbGUuY29t Jmd0OzsgQXJpIEtlcsOkbmVuICZsdDthcmkua2VyYW5lbkBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQgSUNFIGNhbmRpZGF0 ZXMgd2l0aCBCVU5ETEUgLSBzdWdnZXN0ZWQgdGV4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDIyLCAyMDE2IGF0 IDU6MTAgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFzc3VtaW5nIHdlIHdpbGwgb25seSBh c3NvY2lhdGVkIElDRSBjYW5kaWRhdGVzIHRvIHRoZSDigJxtPeKAnSBsaW5lIGFzc29jaWF0ZWQg d2l0aCB0aGUgb2ZmZXJlci9hbnN3ZXJlcg0KIEJVTkRMRS10YWcsIGJlbG93IGlzIGEgZmlyc3Qg c3VnZ2VzdGVkIG9mIG1vZGlmaWVkIOKAmElDRSBDb25zaWRlcmF0aW9uc+KAmSB0ZXh0Ojwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTEuJm5ic3A7IElDRSBDb25zaWRl cmF0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjExLjEuJm5ic3A7IEdlbmVyYWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhpcyBz ZWN0aW9uIGRlc2NyaWJlcyBob3cgdG8gdXNlIHRoZSBCVU5ETEUgZ3JvdXBpbmcgZXh0ZW5zaW9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHRvZ2V0aGVyIHdpdGggdGhlIEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBF c3RhYmxpc2htZW50IChJQ0UpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1lY2hhbmlzbSBbUkZDNTI0NV0uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IFRoZSBnZW5lcmljIHByb2NlZHVyZXMgZm9yIG5lZ290aWF0aW5nIHVzYWdl IG9mIElDRSB1c2luZyBTRFAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGRlZmluZWQgaW4gW0ktRC5pZXRmLW1tdXNp Yy1pY2Utc2lwLXNkcF0sIGFsc28gYXBwbHkgdG8gdXNhZ2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdp dGggQlVORExFLCB3aXRoIHRoZSBmb2xsb3dpbmcgZXhjZXB0aW9uczo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgbyZuYnNwOyBXaGVuIEJVTkRMRSBhZGRyZXNzZXMgZm9yIGEgQlVORExFIGdyb3VwIGhhdmUg YmVlbiBzZWxlY3RlZCBmb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm90aCBlbmRw b2ludHMsIElDRSBjb25uZWN0aXZpdHkgY2hlY2tzIGFuZCBrZWVwLWFsaXZlcyBvbmx5IG5lZWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gYmUgcGVyZm9ybWVkIGZvciB0aGUgd2hv bGUgQlVORExFIGdyb3VwLCBpbnN0ZWFkIG9mIHBlciBidW5kbGVkPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O209JnF1b3Q7IGxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG8gJm5i c3A7QW1vbmcgYnVuZGxlZCAmcXVvdDttPSZxdW90OyBsaW5lcyB3aXRoIHdoaWNoIHRoZSBvZmZl cmVyIGhhcyBhc3NvY2lhdGVkIGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hhcmVk IGFkZHJlc3MsIHRoZSBvZmZlcmVyIG9ubHkgYXNzb2NpYXRlcyBJQ0UtcmVsYXRlZCBtZWRpYS08 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGV2ZWwgU0RQIGF0dHJpYnV0ZXMgd2l0aCB0 aGUgJnF1b3Q7bT0mcXVvdDsgbGluZSBhc3NvY2lhdGVkIHdpdGggdGhlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG9mZmVyZXIgQlVORExFLXRhZy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbyZu YnNwOyBBbW9uZyBidW5kbGVkICZxdW90O209JnF1b3Q7IGxpbmVzIHdpdGggd2hpY2ggdGhlIGFu c3dlcmVyIGhhcyBhc3NvY2lhdGVkIGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hh cmVkIGFkZHJlc3MsIHRoZSBhbnN3ZXJlciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJlbGF0ZWQgbWVk aWEtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxldmVsIFNEUCBhdHRyaWJ1dGVzIHdp dGggdGhlICZxdW90O209JnF1b3Q7IGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhbnN3ZXJlciBCVU5ETEUtdGFnLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBTdXBwb3J0IGFuZCB1c2FnZSBvZiBJQ0UgbWVjaGFuaXNtIHRvZ2V0aGVyIHdpdGggdGhlIEJV TkRMRSBleHRlbnNpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaXMgT1BUSU9OQUwuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTEuMi4mbmJzcDsg U0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTEuMi4xLiZuYnNwOyBHZW5lcmFsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gYW4gb2ZmZXJlciBhc3NvY2lhdGVzIGEgdW5pcXVlIGFkZHJl c3Mgd2l0aCBhIGJ1bmRsZWQgJnF1b3Q7bT0mcXVvdDsgbGluZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAoZXhjbHVk aW5nIGFueSBidW5kbGUtb25seSAmcXVvdDttPSZxdW90OyBsaW5lKSwgaXQgTVVTVCBhbHNvIGFz c29jaWF0ZSB1bmlxdWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSUNFIGNhbmRpZGF0ZXMgdG8gdGhlICZxdW90O209 JnF1b3Q7IGxpbmUsIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBb SS1ELmlldGYtbW11c2ljLWljZS1zaXAtc2RwXS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQW4gb2ZmZXJl ciBNVVNUIE5PVCBhc3NvY2lhdGUgSUNFIGNhbmRpZGF0ZXMgd2l0aCBhIGJ1bmRsZS1vbmx5ICZx dW90O209JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGxpbmUgd2l0aCBhIHplcm8gcG9ydCB2YWx1ZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgTk9URTogVGhlIGJ1bmRsZS1vbmx5ICZxdW90O209JnF1b3Q7IGxpbmUs IGlmIGFjY2VwdGVkIGJ5IHRoZSBhbnN3ZXJlciwgd2lsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpbmhlcml0IHRo ZSBjYW5kaWRhdGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2VsZWN0ZWQgb2ZmZXJlciBCVU5ETEU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgYWRkcmVzcy4mbmJzcDsgQW4gYW5zd2VyZXIgdGhhdCBkb2VzIG5vdCBzdXBw b3J0IEJVTkRMRSB3b3VsZCBub3QgYWNjZXB0IGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYnVuZGxlLW9ubHkgJnF1 b3Q7bT0mcXVvdDsgbGluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2hlbiBhbiBvZmZlcmVyIG9yIGFu c3dlcmVyIGFzc29jaWF0ZXMgYSBzaGFyZWQgYWRkcmVzcyAoaS5lLiBhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBy ZXZpb3VzbHkgc2VsZWN0ZWQgQlVORExFIGFkZHJlc3MpIHdpdGggb25lIG9yIG1vcmUgYnVuZGxl ZCAmcXVvdDttPSZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBsaW5lcywgdGhlIG9mZmVyZXIgKG9yIGFuc3dl cmVyKSBNVVNUIG9ubHkgYXNzb2NpYXRlIFNEUCAnY2FuZGlkYXRlJzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhdHRy aWJ1dGVzIHdpdGggdGhlICZxdW90O209JnF1b3Q7IGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBv ZmZlcmVyIEJVTkRMRS10YWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgKG9yIHRoZSBhbnN3ZXJlciBCVU5ETEUtdGFn KSBhZGRyZXNzKS4mbmJzcDsgVGhlIG9mZmVyZXIgb3IgYW5zd2VyZXIgTVVTVDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBOT1QgYXNzb2NpYXRlICdjYW5kaWRpYXRlJyBhdHRyaWJ1dGVzIHdpdGggYW55IG90aGVyIGJ1 bmRsZWQgJnF1b3Q7bT0mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbGluZSB0byB3aGljaCB0aGUgb2ZmZXJl ciAob3IgYW5zd2VyZXIpIGFzc29jaWF0ZXMgYSBzaGFyZWQgYWRkcmVzcy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg VGhpcyBhbHNvIGFwcGx5IHRvIGFueSBvdGhlciBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAg YXR0cmlidXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBOT1RFOiBUaGUgZm9sbG93aW5nIElDRS1yZWxh dGVkIG1lZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGVzIGFyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBkZWZpbmVkIGlu IFtJLUQuaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHBdOiAnY2FuZGlkaWF0ZScsICdyZW1vdGUtPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IGNhbmRpZGF0ZXMnLCAnaWNlLW1pc21hdGNoJywgJ2ljZS11ZnJhZycsICdpY2Ut cHdkJywgYW5kICdpY2UtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBhY2luZycuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTEuMi4yLiZuYnNwOyBH ZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXaGVuIGFu IG9mZmVyZXIgZ2VuZXJhdGVzIGFuIGluaXRpYWwgb2ZmZXIsIGl0IGFzc29jaWF0ZXMgdW5pcXVl IElDRTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGVzIHdpdGggdGhlIGJ1bmRsZWQgJnF1b3Q7bT0mcXVv dDsgbGluZXMsIGFjY29yZGluZyB0byBTZWN0aW9uIDExLjIuMS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xMS4yLjMuJm5ic3A7 IEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2hlbiBhbiBhbnN3 ZXJlciBnZW5lcmF0ZXMgYW4gYW5zd2VyIHRoYXQgY29udGFpbnMgYSBCVU5ETEUgZ3JvdXAsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IHRoZSBhbnN3ZXJlciBNVVNUIG9ubHkgYXNzb2NpYXRlIFNEUCAnY2FuZGlkYXRl JyBhdHRyaWJ1dGVzIChhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2 ZWwgU0RQIGF0dHJpYnV0ZXMpIHdpdGggdGhlICZxdW90O209JnF1b3Q7IGxpbmU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgYXNzb2NpYXRlZCB3aXRoIHRoZSBhbnN3ZXJlciBCVU5ETEUtdGFnLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjExLjIuNC4m bmJzcDsgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2VyPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IFdoZW4gYW4gb2ZmZXJlciByZWNlaXZlcyBhbiBhbnN3ZXIsIGlmIHRoZSBhbnN3ZXJlciBz dXBwb3J0cyBhbmQgdXNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUgSUNFIG1lY2hhbmlzbSBhbmQgdGhlIEJV TkRMRSBleHRlbnNpb24sIHRoZSBvZmZlcmVyIE1VU1Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYXNzb2NpYXRlIHRo ZSBzYW1lIElDRSBjYW5kaWRhdGVzLCBhc3NvY2lhdGVkIHdpdGggdGhlICZxdW90O209JnF1b3Q7 IGxpbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgcmVwcmVzZW50aW5nIHRoZSBvZmZlcmVyIEJVTkRMRSBhZGRyZXNz IChzZWxlY3RlZCBieSB0aGUgYW5zd2VyZXIpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aXRoIGVhY2ggYnVuZGxl ZCAmcXVvdDttPSZxdW90OyBsaW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjExLjIuNS4mbmJzcDsgTW9kaWZ5aW5nIHRoZSBT ZXNzaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gYW4gb2ZmZXJlciBnZW5lcmF0ZXMgYSBzdWJz ZXF1ZW50IG9mZmVyLCBpdCBhc3NvY2lhdGVzIHVuaXF1ZSBvcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzaGFyZWQg SUNFIGNhbmRpZGF0ZXMgd2l0aCB0aGUgYnVuZGxlZCAmcXVvdDttPSZxdW90OyBsaW5lcywgYWNj b3JkaW5nIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IChTZWN0aW9uIDExLjIuMSkuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90 IDEwMCUgc3VyZSBhYm91dCB3aGF0IGV4YWN0bHkgaXMgbWVhbnQgYnkgSUNFIGNhbmRpZGF0ZSBi ZWluZyBhc3NvY2lhdGVkIHdpdGggYW4gbT0gbGluZS4gRG9lcyB0aGlzIG1lYW4gSUNFIGNhbmRp ZGF0ZSBpcyBjcmVhdGVkIGZvciB0aGlzIG09IGxpbmUgYW5kICZxdW90O2NhbmRpZGF0ZSZxdW90 OyBTRFAgYXR0cmlidXRlIGlzIGluY2x1ZGVkIGluIHRoaXMgbT0gbGluZT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdmVyYWxsIHRoZSB0ZXh0IGlzIGdv b2QsIGJ1dCBJIHdvdWxkIGV4cGxpY2l0bHkgcmVwbGFjZSAmcXVvdDtJQ0UgY2FuZGlkYXRlcyZx dW90OyB3aXRoICZxdW90O0lDRSBjYW5kaWRhdGVzIG9yIGFueSBvdGhlciBJQ0UtcmVsYXRlZCBt ZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyZxdW90OyB0byBhdm9pZCBhbnkgcG90ZW50aWFsIGNv bmZ1c2lvbi4gVGhpcyB3aWxsIGFsc28gbWFrZSB0aGUgcGhyYXNlICZxdW90O1RoaXMgYWxzbyBh cHBseSB0byBhbnkNCiBvdGhlciBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRl JnF1b3Q7IHVubmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37E35F30ESESSMB209erics_-- From nobody Mon Feb 22 12:14: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 53BFF1A1A4A for ; Mon, 22 Feb 2016 12:14:08 -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 ytDnXTwYsb5q for ; Mon, 22 Feb 2016 12:14:06 -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 28FA31A0030 for ; Mon, 22 Feb 2016 12:14:06 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-07v.sys.comcast.net with comcast id MYCa1s0012XD5SV01YE5YG; Mon, 22 Feb 2016 20:14:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id MYE41s00H3KdFy101YE4Je; Mon, 22 Feb 2016 20:14:05 +0000 To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B37E3054E@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CB6C0B.1020209@alum.mit.edu> Date: Mon, 22 Feb 2016 15:14:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456172045; bh=ay3VPsaw65E8H9fKdyx0WzA/JXrzuY2yCJKTM1N+AP8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=g4FABDU/trU2aj5TTfk2CqwWjRSjyKbnUU3rSY6rAzyCB8PhXgROUGtGAcp9CpGla V1R6FJEnWFzSdTSDx7xtcEFXrt9p155PHy1nflaimZ3JQJXHZnu7GEbzfAcf8czEL/ eRgL4+7o0j5ARCUbYYiO72iNQIGDHO2RpUxoFmHFhKotuHbjejnbHUYe9R1YmmbCPR 8Ds3EusXnxlSnxBPOZ7trBNdJ5rYbZq2ulusDnAnCiAuIc1frfPqFMoS+8YMSYCdnn cp/RRYW12054Gln+grNfgPHTm2CvcP0MpiUE99+S5uBDmYRUjhBtTmLS178KJGjzGE 0QpEE75uDDzYQ== Archived-At: Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text 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, 22 Feb 2016 20:14:08 -0000 Christer, [I'm replying to Christer, not Roman. For some reason I can't find Christer's original message in my email.] This generally seems good to me. I noticed one thing: While I understand the intent, you are using "associate", "associates" or "associated" in multiple ways, that may be confusing to some readers. E.g.: o Among bundled "m=" lines with which the offerer has associated a shared address, the offerer only associates ICE-related media- level SDP attributes with the "m=" line associated with the offerer BUNDLE-tag. ... NOTE: The bundle-only "m=" line, if accepted by the answerer, will inherit the candidates associated with the selected offerer BUNDLE address. An answerer that does not support BUNDLE would not accept a bundle-only "m=" line. ... When an offerer or answerer associates a shared address (i.e. a previously selected BUNDLE address) with one or more bundled "m=" lines, the offerer (or answerer) MUST only associate SDP 'candidate' attributes with the "m=" line associated with the offerer BUNDLE-tag (or the answerer BUNDLE-tag) address). The offerer or answerer MUST NOT associate 'candidiate' attributes with any other bundled "m=" line to which the offerer (or answerer) associates a shared address. ... When an offerer receives an answer, if the answerer supports and uses the ICE mechanism and the BUNDLE extension, the offerer MUST associate the same ICE candidates, associated with the "m=" line representing the offerer BUNDLE address (selected by the answerer), with each bundled "m=" line. So, which one of these things is not like the others? (This is a game we play with kids. Do they do it in Sweden too?) In most cases this is talking about where you put things in the SDP. But the last one above isn't that - it is about the implementation taking data from the answer and using it to update internal data structures. I don't have a specific suggestion for improving it. But I think it would be good to use someting other that "associate" in this case. I *think* it is the only place where it is used this way. Thanks, Paul On 2/22/16 2:29 PM, Roman Shpount wrote: > On Mon, Feb 22, 2016 at 5:10 AM, Christer Holmberg > > > wrote: > > Assuming we will only associated ICE candidates to the “m=” line > associated with the offerer/answerer BUNDLE-tag, below is a first > suggested of modified ‘ICE Considerations’ text: > > __ __ > > -----------------------____ > > __ __ > > 11. ICE Considerations____ > > __ __ > > 11.1. General____ > > __ __ > > This section describes how to use the BUNDLE grouping extension____ > > together with the Interactive Connectivity Establishment (ICE)____ > > mechanism [RFC5245].____ > > __ __ > > The generic procedures for negotiating usage of ICE using SDP,____ > > defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of > ICE____ > > with BUNDLE, with the following exceptions:____ > > __ __ > > o When BUNDLE addresses for a BUNDLE group have been selected > for____ > > both endpoints, ICE connectivity checks and keep-alives only > need____ > > to be performed for the whole BUNDLE group, instead of per > bundled____ > > "m=" line.____ > > __ __ > > o Among bundled "m=" lines with which the offerer has > associated a____ > > shared address, the offerer only associates ICE-related > media-____ > > level SDP attributes with the "m=" line associated with the____ > > offerer BUNDLE-tag.____ > > __ __ > > o Among bundled "m=" lines with which the answerer has > associated a____ > > shared address, the answerer only associates ICE-related > media-____ > > level SDP attributes with the "m=" line associated with the____ > > answerer BUNDLE-tag.____ > > __ __ > > Support and usage of ICE mechanism together with the BUNDLE > extension____ > > is OPTIONAL.____ > > __ __ > > 11.2. SDP Offer/Answer Procedures____ > > __ __ > > 11.2.1. General____ > > __ __ > > When an offerer associates a unique address with a bundled "m=" > line____ > > (excluding any bundle-only "m=" line), it MUST also associate > unique____ > > ICE candidates to the "m=" line, according to the procedures in____ > > [I-D.ietf-mmusic-ice-sip-sdp].____ > > __ __ > > An offerer MUST NOT associate ICE candidates with a bundle-only > "m="____ > > line with a zero port value.____ > > __ __ > > NOTE: The bundle-only "m=" line, if accepted by the answerer, > will____ > > inherit the candidates associated with the selected offerer > BUNDLE____ > > address. An answerer that does not support BUNDLE would not > accept a____ > > bundle-only "m=" line.____ > > __ __ > > When an offerer or answerer associates a shared address (i.e. a____ > > previously selected BUNDLE address) with one or more bundled > "m="____ > > lines, the offerer (or answerer) MUST only associate SDP > 'candidate'____ > > attributes with the "m=" line associated with the offerer > BUNDLE-tag____ > > (or the answerer BUNDLE-tag) address). The offerer or answerer > MUST____ > > NOT associate 'candidiate' attributes with any other bundled > "m="____ > > line to which the offerer (or answerer) associates a shared > address.____ > > This also apply to any other ICE-related media-level SDP > attribute.____ > > __ __ > > NOTE: The following ICE-related media-level SDP attributes are____ > > defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote-____ > > candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-____ > > pacing'.____ > > __ __ > > 11.2.2. Generating the Initial SDP Offer____ > > __ __ > > When an offerer generates an initial offer, it associates unique > ICE____ > > candidates with the bundled "m=" lines, according to Section > 11.2.1.____ > > __ __ > > 11.2.3. Generating the SDP Answer____ > > __ __ > > When an answerer generates an answer that contains a BUNDLE > group,____ > > the answerer MUST only associate SDP 'candidate' attributes (and____ > > other ICE-related media-level SDP attributes) with the "m=" line____ > > associated with the answerer BUNDLE-tag.____ > > __ __ > > 11.2.4. Offerer Processing of the SDP Answer____ > > __ __ > > When an offerer receives an answer, if the answerer supports and > uses____ > > the ICE mechanism and the BUNDLE extension, the offerer MUST____ > > associate the same ICE candidates, associated with the "m=" line____ > > representing the offerer BUNDLE address (selected by the > answerer),____ > > with each bundled "m=" line.____ > > __ __ > > 11.2.5. Modifying the Session____ > > __ __ > > When an offerer generates a subsequent offer, it associates > unique or____ > > shared ICE candidates with the bundled "m=" lines, according to____ > > (Section 11.2.1).____ > > > > I am not 100% sure about what exactly is meant by ICE candidate being > associated with an m= line. Does this mean ICE candidate is created for > this m= line and "candidate" SDP attribute is included in this m= line? > > Overall the text is good, but I would explicitly replace "ICE > candidates" with "ICE candidates or any other ICE-related media-level > SDP attributes" to avoid any potential confusion. This will also make > the phrase "This also apply to any other ICE-related media-level SDP > attribute" unnecessary. > _____________ > Roman Shpount From nobody Mon Feb 22 12:18: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 C3FA21A1A6D for ; Mon, 22 Feb 2016 12:18:30 -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 efYHTxmzsrd2 for ; Mon, 22 Feb 2016 12:18:28 -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 E8DB01A1A4A for ; Mon, 22 Feb 2016 12:18:27 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-14-56cb6d126bfb Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.0A.02707.21D6BC65; Mon, 22 Feb 2016 21:18:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 21:18:24 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text Thread-Index: AdFtWOeeQ/zW0OtpRAOrN5PglHqZIwARgwCAAAGPWoAAAi4CAA== Date: Mon, 22 Feb 2016 20:18:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E35FDF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E3054E@ESESSMB209.ericsson.se> <56CB6C0B.1020209@alum.mit.edu> In-Reply-To: <56CB6C0B.1020209@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7iq5Q7ukwg6MbBSymLn/MYrFiwwFW i2vLX7NazLgwldmBxePv+w9MHgs2lXosWfKTyePWlIIAligum5TUnMyy1CJ9uwSujEkfHrEU /Eqs+Db1FUsD4474LkZODgkBE4l9X2axQdhiEhfurQeyuTiEBA4zSvzefJkdwlnMKPF63VWW LkYODjYBC4nuf9ogDSIC3hIT5q8Ga2YW6GaUaP8vAGILCwRLXO/ezAZREyKxePppZgjbSaK5 o4kdxGYRUJXoX/0YrIZXwFfi1t7nrBC7tjFKtLY+YwFJcAroSMxd+YcRxGYEuu77qTVMEMvE JW49mc8EcbWAxJI955khbFGJl4//sULYShKNS56wgtzMLKApsX6XPkSrosSU7ofsEHsFJU7O fMIygVFsFpKpsxA6ZiHpmIWkYwEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwAg7uOW3 wQ7Gl88dDzEKcDAq8fBuiDodJsSaWFZcmXuIUYKDWUmENzUGKMSbklhZlVqUH19UmpNafIhR moNFSZx3tfP6MCGB9MSS1OzU1ILUIpgsEwenVANj3p/1hQIfd786uuHTySvfA8u2RT94y5fU rJh2nlUnTsl5wpMFscdeczA5xmyZ/F3YKM7a+LqH4bI9BV/uca77+yEsdUlB84Vg04lH5YUS t1vyse1lF12erM/wN1/jaOR+VdtVu5yENf3MpCQzjNbei05lVvt6zfeRjfyUxs5ne6ZsP/P0 /ubbSizFGYmGWsxFxYkAbopGPqwCAAA= Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text 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, 22 Feb 2016 20:18:31 -0000 SGkgUGF1bCwNCg0KSSBhbSB0cnlpbmcgdG8gZm9sbG93IHRoZSBzYW1lIHN0eWxlIGFzIEJVTkRM RSBpbiBnZW5lcmFsLiBZZXMsIEkga25vdyBpdCdzIG1lc3N5LCBhbmQgSSd2ZSBsb3N0IGNvdW50 IG9mIHRoZSBudW1iZXIgb2YgdGltZXMgSSd2ZSBoYWQgdG8gcmUtd3JpdGUgZXZlcnl0aGluZywg YnV0IEkgYW0gbm90IGdvaW5nIHRvIGRvIGl0IGFnYWluLiANCg0KTm93LCBJIGRpZCBwdXQgdG9n ZXRoZXIgdGhlIG5ldyBJQ0UgdGV4dCByYXRoZXIgcXVpY2tseSwgc28gdGhlcmUgbWF5IGJlIHNv bWUgbWlzdGFrZXMsIHRob3VnaC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFs dW0ubWl0LmVkdV0gDQpTZW50OiAyMiBGZWJydWFyeSAyMDE2IDIyOjE0DQpUbzogUm9tYW4gU2hw b3VudCA8cm9tYW5AdGVsdXJpeC5jb20+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IG1tdXNpY0BpZXRmLm9yZzsgUGV0ZXIgVGhhdGNoZXIg PHB0aGF0Y2hlckBnb29nbGUuY29tPjsgQXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nv bi5jb20+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gUXVlc3Rpb25zIGFib3V0IElDRSBjYW5kaWRh dGVzIHdpdGggQlVORExFIC0gc3VnZ2VzdGVkIHRleHQNCg0KQ2hyaXN0ZXIsDQoNCltJJ20gcmVw bHlpbmcgdG8gQ2hyaXN0ZXIsIG5vdCBSb21hbi4gRm9yIHNvbWUgcmVhc29uIEkgY2FuJ3QgZmlu ZCBDaHJpc3RlcidzIG9yaWdpbmFsIG1lc3NhZ2UgaW4gbXkgZW1haWwuXQ0KDQpUaGlzIGdlbmVy YWxseSBzZWVtcyBnb29kIHRvIG1lLiBJIG5vdGljZWQgb25lIHRoaW5nOg0KDQpXaGlsZSBJIHVu ZGVyc3RhbmQgdGhlIGludGVudCwgeW91IGFyZSB1c2luZyAiYXNzb2NpYXRlIiwgImFzc29jaWF0 ZXMiIA0Kb3IgImFzc29jaWF0ZWQiIGluIG11bHRpcGxlIHdheXMsIHRoYXQgbWF5IGJlIGNvbmZ1 c2luZyB0byBzb21lIHJlYWRlcnMuIA0KRS5nLjoNCg0KICAgIG8gIEFtb25nIGJ1bmRsZWQgIm09 IiBsaW5lcyB3aXRoIHdoaWNoIHRoZSBvZmZlcmVyIGhhcyBhc3NvY2lhdGVkIGENCiAgICAgICBz aGFyZWQgYWRkcmVzcywgdGhlIG9mZmVyZXIgb25seSBhc3NvY2lhdGVzIElDRS1yZWxhdGVkIG1l ZGlhLQ0KICAgICAgIGxldmVsIFNEUCBhdHRyaWJ1dGVzIHdpdGggdGhlICJtPSIgbGluZSBhc3Nv Y2lhdGVkIHdpdGggdGhlDQogICAgICAgb2ZmZXJlciBCVU5ETEUtdGFnLg0KLi4uDQogICAgTk9U RTogVGhlIGJ1bmRsZS1vbmx5ICJtPSIgbGluZSwgaWYgYWNjZXB0ZWQgYnkgdGhlIGFuc3dlcmVy LCB3aWxsDQogICAgaW5oZXJpdCB0aGUgY2FuZGlkYXRlcyBhc3NvY2lhdGVkIHdpdGggdGhlIHNl bGVjdGVkIG9mZmVyZXIgQlVORExFDQogICAgYWRkcmVzcy4gIEFuIGFuc3dlcmVyIHRoYXQgZG9l cyBub3Qgc3VwcG9ydCBCVU5ETEUgd291bGQgbm90IGFjY2VwdCBhDQogICAgYnVuZGxlLW9ubHkg Im09IiBsaW5lLg0KLi4uDQogICAgV2hlbiBhbiBvZmZlcmVyIG9yIGFuc3dlcmVyIGFzc29jaWF0 ZXMgYSBzaGFyZWQgYWRkcmVzcyAoaS5lLiBhDQogICAgcHJldmlvdXNseSBzZWxlY3RlZCBCVU5E TEUgYWRkcmVzcykgd2l0aCBvbmUgb3IgbW9yZSBidW5kbGVkICJtPSINCiAgICBsaW5lcywgdGhl IG9mZmVyZXIgKG9yIGFuc3dlcmVyKSBNVVNUIG9ubHkgYXNzb2NpYXRlIFNEUCAnY2FuZGlkYXRl Jw0KICAgIGF0dHJpYnV0ZXMgd2l0aCB0aGUgIm09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aCB0aGUg b2ZmZXJlciBCVU5ETEUtdGFnDQogICAgKG9yIHRoZSBhbnN3ZXJlciBCVU5ETEUtdGFnKSBhZGRy ZXNzKS4gIFRoZSBvZmZlcmVyIG9yIGFuc3dlcmVyIE1VU1QNCiAgICBOT1QgYXNzb2NpYXRlICdj YW5kaWRpYXRlJyBhdHRyaWJ1dGVzIHdpdGggYW55IG90aGVyIGJ1bmRsZWQgIm09Ig0KICAgIGxp bmUgdG8gd2hpY2ggdGhlIG9mZmVyZXIgKG9yIGFuc3dlcmVyKSBhc3NvY2lhdGVzIGEgc2hhcmVk IGFkZHJlc3MuDQouLi4NCiAgICBXaGVuIGFuIG9mZmVyZXIgcmVjZWl2ZXMgYW4gYW5zd2VyLCBp ZiB0aGUgYW5zd2VyZXIgc3VwcG9ydHMgYW5kIHVzZXMNCiAgICB0aGUgSUNFIG1lY2hhbmlzbSBh bmQgdGhlIEJVTkRMRSBleHRlbnNpb24sIHRoZSBvZmZlcmVyIE1VU1QNCiAgICBhc3NvY2lhdGUg dGhlIHNhbWUgSUNFIGNhbmRpZGF0ZXMsIGFzc29jaWF0ZWQgd2l0aCB0aGUgIm09IiBsaW5lDQog ICAgcmVwcmVzZW50aW5nIHRoZSBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIChzZWxlY3RlZCBieSB0 aGUgYW5zd2VyZXIpLA0KICAgIHdpdGggZWFjaCBidW5kbGVkICJtPSIgbGluZS4NCg0KU28sIHdo aWNoIG9uZSBvZiB0aGVzZSB0aGluZ3MgaXMgbm90IGxpa2UgdGhlIG90aGVycz8gKFRoaXMgaXMg YSBnYW1lIHdlIHBsYXkgd2l0aCBraWRzLiBEbyB0aGV5IGRvIGl0IGluIFN3ZWRlbiB0b28/KQ0K DQpJbiBtb3N0IGNhc2VzIHRoaXMgaXMgdGFsa2luZyBhYm91dCB3aGVyZSB5b3UgcHV0IHRoaW5n cyBpbiB0aGUgU0RQLiBCdXQgdGhlIGxhc3Qgb25lIGFib3ZlIGlzbid0IHRoYXQgLSBpdCBpcyBh Ym91dCB0aGUgaW1wbGVtZW50YXRpb24gdGFraW5nIGRhdGEgZnJvbSB0aGUgYW5zd2VyIGFuZCB1 c2luZyBpdCB0byB1cGRhdGUgaW50ZXJuYWwgZGF0YSBzdHJ1Y3R1cmVzLg0KDQpJIGRvbid0IGhh dmUgYSBzcGVjaWZpYyBzdWdnZXN0aW9uIGZvciBpbXByb3ZpbmcgaXQuIEJ1dCBJIHRoaW5rIGl0 IHdvdWxkIGJlIGdvb2QgdG8gdXNlIHNvbWV0aW5nIG90aGVyIHRoYXQgImFzc29jaWF0ZSIgaW4g dGhpcyBjYXNlLiBJDQoqdGhpbmsqIGl0IGlzIHRoZSBvbmx5IHBsYWNlIHdoZXJlIGl0IGlzIHVz ZWQgdGhpcyB3YXkuDQoNCglUaGFua3MsDQoJUGF1bA0KDQoNCk9uIDIvMjIvMTYgMjoyOSBQTSwg Um9tYW4gU2hwb3VudCB3cm90ZToNCj4gT24gTW9uLCBGZWIgMjIsIDIwMTYgYXQgNToxMCBBTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgDQo+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20gDQo+ IDxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCj4gd3JvdGU6DQo+DQo+ ICAgICBBc3N1bWluZyB3ZSB3aWxsIG9ubHkgYXNzb2NpYXRlZCBJQ0UgY2FuZGlkYXRlcyB0byB0 aGUg4oCcbT3igJ0gbGluZQ0KPiAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBvZmZlcmVyL2Fuc3dl cmVyIEJVTkRMRS10YWcsIGJlbG93IGlzIGEgZmlyc3QNCj4gICAgIHN1Z2dlc3RlZCBvZiBtb2Rp ZmllZCDigJhJQ0UgQ29uc2lkZXJhdGlvbnPigJkgdGV4dDoNCj4NCj4gICAgIF9fIF9fDQo+DQo+ ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLV9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAg ICAxMS4gIElDRSBDb25zaWRlcmF0aW9uc19fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAx MS4xLiAgR2VuZXJhbF9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAgICAgVGhpcyBzZWN0 aW9uIGRlc2NyaWJlcyBob3cgdG8gdXNlIHRoZSBCVU5ETEUgZ3JvdXBpbmcgDQo+IGV4dGVuc2lv bl9fX18NCj4NCj4gICAgICAgICB0b2dldGhlciB3aXRoIHRoZSBJbnRlcmFjdGl2ZSBDb25uZWN0 aXZpdHkgRXN0YWJsaXNobWVudCANCj4gKElDRSlfX19fDQo+DQo+ICAgICAgICAgbWVjaGFuaXNt IFtSRkM1MjQ1XS5fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgICAgIFRoZSBnZW5lcmlj IHByb2NlZHVyZXMgZm9yIG5lZ290aWF0aW5nIHVzYWdlIG9mIElDRSB1c2luZyANCj4gU0RQLF9f X18NCj4NCj4gICAgICAgICBkZWZpbmVkIGluIFtJLUQuaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHBd LCBhbHNvIGFwcGx5IHRvIHVzYWdlIG9mDQo+ICAgICBJQ0VfX19fDQo+DQo+ICAgICAgICAgd2l0 aCBCVU5ETEUsIHdpdGggdGhlIGZvbGxvd2luZyBleGNlcHRpb25zOl9fX18NCj4NCj4gICAgIF9f IF9fDQo+DQo+ICAgICAgICAgbyAgV2hlbiBCVU5ETEUgYWRkcmVzc2VzIGZvciBhIEJVTkRMRSBn cm91cCBoYXZlIGJlZW4gc2VsZWN0ZWQNCj4gICAgIGZvcl9fX18NCj4NCj4gICAgICAgICAgICBi b3RoIGVuZHBvaW50cywgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgYW5kIGtlZXAtYWxpdmVzIG9u bHkNCj4gICAgIG5lZWRfX19fDQo+DQo+ICAgICAgICAgICAgdG8gYmUgcGVyZm9ybWVkIGZvciB0 aGUgd2hvbGUgQlVORExFIGdyb3VwLCBpbnN0ZWFkIG9mIHBlcg0KPiAgICAgYnVuZGxlZF9fX18N Cj4NCj4gICAgICAgICAgICAibT0iIGxpbmUuX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAg ICAgICBvICBBbW9uZyBidW5kbGVkICJtPSIgbGluZXMgd2l0aCB3aGljaCB0aGUgb2ZmZXJlciBo YXMNCj4gICAgIGFzc29jaWF0ZWQgYV9fX18NCj4NCj4gICAgICAgICAgICBzaGFyZWQgYWRkcmVz cywgdGhlIG9mZmVyZXIgb25seSBhc3NvY2lhdGVzIElDRS1yZWxhdGVkDQo+ICAgICBtZWRpYS1f X19fDQo+DQo+ICAgICAgICAgICAgbGV2ZWwgU0RQIGF0dHJpYnV0ZXMgd2l0aCB0aGUgIm09IiBs aW5lIGFzc29jaWF0ZWQgd2l0aCANCj4gdGhlX19fXw0KPg0KPiAgICAgICAgICAgIG9mZmVyZXIg QlVORExFLXRhZy5fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgICAgIG8gIEFtb25nIGJ1 bmRsZWQgIm09IiBsaW5lcyB3aXRoIHdoaWNoIHRoZSBhbnN3ZXJlciBoYXMNCj4gICAgIGFzc29j aWF0ZWQgYV9fX18NCj4NCj4gICAgICAgICAgICBzaGFyZWQgYWRkcmVzcywgdGhlIGFuc3dlcmVy IG9ubHkgYXNzb2NpYXRlcyBJQ0UtcmVsYXRlZA0KPiAgICAgbWVkaWEtX19fXw0KPg0KPiAgICAg ICAgICAgIGxldmVsIFNEUCBhdHRyaWJ1dGVzIHdpdGggdGhlICJtPSIgbGluZSBhc3NvY2lhdGVk IHdpdGggDQo+IHRoZV9fX18NCj4NCj4gICAgICAgICAgICBhbnN3ZXJlciBCVU5ETEUtdGFnLl9f X18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAgICAgU3VwcG9ydCBhbmQgdXNhZ2Ugb2YgSUNF IG1lY2hhbmlzbSB0b2dldGhlciB3aXRoIHRoZSBCVU5ETEUNCj4gICAgIGV4dGVuc2lvbl9fX18N Cj4NCj4gICAgICAgICBpcyBPUFRJT05BTC5fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAg MTEuMi4gIFNEUCBPZmZlci9BbnN3ZXIgUHJvY2VkdXJlc19fX18NCj4NCj4gICAgIF9fIF9fDQo+ DQo+ICAgICAxMS4yLjEuICBHZW5lcmFsX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAgICAg ICBXaGVuIGFuIG9mZmVyZXIgYXNzb2NpYXRlcyBhIHVuaXF1ZSBhZGRyZXNzIHdpdGggYSBidW5k bGVkICJtPSINCj4gICAgIGxpbmVfX19fDQo+DQo+ICAgICAgICAgKGV4Y2x1ZGluZyBhbnkgYnVu ZGxlLW9ubHkgIm09IiBsaW5lKSwgaXQgTVVTVCBhbHNvIGFzc29jaWF0ZQ0KPiAgICAgdW5pcXVl X19fXw0KPg0KPiAgICAgICAgIElDRSBjYW5kaWRhdGVzIHRvIHRoZSAibT0iIGxpbmUsIGFjY29y ZGluZyB0byB0aGUgcHJvY2VkdXJlcyANCj4gaW5fX19fDQo+DQo+ICAgICAgICAgW0ktRC5pZXRm LW1tdXNpYy1pY2Utc2lwLXNkcF0uX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAgICAgICBB biBvZmZlcmVyIE1VU1QgTk9UIGFzc29jaWF0ZSBJQ0UgY2FuZGlkYXRlcyB3aXRoIGEgYnVuZGxl LW9ubHkNCj4gICAgICJtPSJfX19fDQo+DQo+ICAgICAgICAgbGluZSB3aXRoIGEgemVybyBwb3J0 IHZhbHVlLl9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAgICAgTk9URTogVGhlIGJ1bmRs ZS1vbmx5ICJtPSIgbGluZSwgaWYgYWNjZXB0ZWQgYnkgdGhlIGFuc3dlcmVyLA0KPiAgICAgd2ls bF9fX18NCj4NCj4gICAgICAgICBpbmhlcml0IHRoZSBjYW5kaWRhdGVzIGFzc29jaWF0ZWQgd2l0 aCB0aGUgc2VsZWN0ZWQgb2ZmZXJlcg0KPiAgICAgQlVORExFX19fXw0KPg0KPiAgICAgICAgIGFk ZHJlc3MuICBBbiBhbnN3ZXJlciB0aGF0IGRvZXMgbm90IHN1cHBvcnQgQlVORExFIHdvdWxkIG5v dA0KPiAgICAgYWNjZXB0IGFfX19fDQo+DQo+ICAgICAgICAgYnVuZGxlLW9ubHkgIm09IiBsaW5l Ll9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAgICAgV2hlbiBhbiBvZmZlcmVyIG9yIGFu c3dlcmVyIGFzc29jaWF0ZXMgYSBzaGFyZWQgYWRkcmVzcyAoaS5lLiANCj4gYV9fX18NCj4NCj4g ICAgICAgICBwcmV2aW91c2x5IHNlbGVjdGVkIEJVTkRMRSBhZGRyZXNzKSB3aXRoIG9uZSBvciBt b3JlIGJ1bmRsZWQNCj4gICAgICJtPSJfX19fDQo+DQo+ICAgICAgICAgbGluZXMsIHRoZSBvZmZl cmVyIChvciBhbnN3ZXJlcikgTVVTVCBvbmx5IGFzc29jaWF0ZSBTRFANCj4gICAgICdjYW5kaWRh dGUnX19fXw0KPg0KPiAgICAgICAgIGF0dHJpYnV0ZXMgd2l0aCB0aGUgIm09IiBsaW5lIGFzc29j aWF0ZWQgd2l0aCB0aGUgb2ZmZXJlcg0KPiAgICAgQlVORExFLXRhZ19fX18NCj4NCj4gICAgICAg ICAob3IgdGhlIGFuc3dlcmVyIEJVTkRMRS10YWcpIGFkZHJlc3MpLiAgVGhlIG9mZmVyZXIgb3Ig YW5zd2VyZXINCj4gICAgIE1VU1RfX19fDQo+DQo+ICAgICAgICAgTk9UIGFzc29jaWF0ZSAnY2Fu ZGlkaWF0ZScgYXR0cmlidXRlcyB3aXRoIGFueSBvdGhlciBidW5kbGVkDQo+ICAgICAibT0iX19f Xw0KPg0KPiAgICAgICAgIGxpbmUgdG8gd2hpY2ggdGhlIG9mZmVyZXIgKG9yIGFuc3dlcmVyKSBh c3NvY2lhdGVzIGEgc2hhcmVkDQo+ICAgICBhZGRyZXNzLl9fX18NCj4NCj4gICAgICAgICBUaGlz IGFsc28gYXBwbHkgdG8gYW55IG90aGVyIElDRS1yZWxhdGVkIG1lZGlhLWxldmVsIFNEUA0KPiAg ICAgYXR0cmlidXRlLl9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAgICAgTk9URTogVGhl IGZvbGxvd2luZyBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyANCj4gYXJl X19fXw0KPg0KPiAgICAgICAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLW1tdXNpYy1pY2Utc2lwLXNk cF06ICdjYW5kaWRpYXRlJywgDQo+ICdyZW1vdGUtX19fXw0KPg0KPiAgICAgICAgIGNhbmRpZGF0 ZXMnLCAnaWNlLW1pc21hdGNoJywgJ2ljZS11ZnJhZycsICdpY2UtcHdkJywgYW5kIA0KPiAnaWNl LV9fX18NCj4NCj4gICAgICAgICBwYWNpbmcnLl9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAg ICAxMS4yLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcl9fX18NCj4NCj4gICAg IF9fIF9fDQo+DQo+ICAgICAgICAgV2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRlcyBhbiBpbml0aWFs IG9mZmVyLCBpdCBhc3NvY2lhdGVzIHVuaXF1ZQ0KPiAgICAgSUNFX19fXw0KPg0KPiAgICAgICAg IGNhbmRpZGF0ZXMgd2l0aCB0aGUgYnVuZGxlZCAibT0iIGxpbmVzLCBhY2NvcmRpbmcgdG8gU2Vj dGlvbg0KPiAgICAgMTEuMi4xLl9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAxMS4yLjMu ICBHZW5lcmF0aW5nIHRoZSBTRFAgQW5zd2VyX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAg ICAgICBXaGVuIGFuIGFuc3dlcmVyIGdlbmVyYXRlcyBhbiBhbnN3ZXIgdGhhdCBjb250YWlucyBh IEJVTkRMRQ0KPiAgICAgZ3JvdXAsX19fXw0KPg0KPiAgICAgICAgIHRoZSBhbnN3ZXJlciBNVVNU IG9ubHkgYXNzb2NpYXRlIFNEUCAnY2FuZGlkYXRlJyBhdHRyaWJ1dGVzIA0KPiAoYW5kX19fXw0K Pg0KPiAgICAgICAgIG90aGVyIElDRS1yZWxhdGVkIG1lZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGVz KSB3aXRoIHRoZSAibT0iIA0KPiBsaW5lX19fXw0KPg0KPiAgICAgICAgIGFzc29jaWF0ZWQgd2l0 aCB0aGUgYW5zd2VyZXIgQlVORExFLXRhZy5fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAg MTEuMi40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2VyX19fXw0KPg0KPiAg ICAgX18gX18NCj4NCj4gICAgICAgICBXaGVuIGFuIG9mZmVyZXIgcmVjZWl2ZXMgYW4gYW5zd2Vy LCBpZiB0aGUgYW5zd2VyZXIgc3VwcG9ydHMgYW5kDQo+ICAgICB1c2VzX19fXw0KPg0KPiAgICAg ICAgIHRoZSBJQ0UgbWVjaGFuaXNtIGFuZCB0aGUgQlVORExFIGV4dGVuc2lvbiwgdGhlIG9mZmVy ZXIgDQo+IE1VU1RfX19fDQo+DQo+ICAgICAgICAgYXNzb2NpYXRlIHRoZSBzYW1lIElDRSBjYW5k aWRhdGVzLCBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgDQo+IGxpbmVfX19fDQo+DQo+ICAgICAg ICAgcmVwcmVzZW50aW5nIHRoZSBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIChzZWxlY3RlZCBieSB0 aGUNCj4gICAgIGFuc3dlcmVyKSxfX19fDQo+DQo+ICAgICAgICAgd2l0aCBlYWNoIGJ1bmRsZWQg Im09IiBsaW5lLl9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAxMS4yLjUuICBNb2RpZnlp bmcgdGhlIFNlc3Npb25fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgICAgIFdoZW4gYW4g b2ZmZXJlciBnZW5lcmF0ZXMgYSBzdWJzZXF1ZW50IG9mZmVyLCBpdCBhc3NvY2lhdGVzDQo+ICAg ICB1bmlxdWUgb3JfX19fDQo+DQo+ICAgICAgICAgc2hhcmVkIElDRSBjYW5kaWRhdGVzIHdpdGgg dGhlIGJ1bmRsZWQgIm09IiBsaW5lcywgYWNjb3JkaW5nIA0KPiB0b19fX18NCj4NCj4gICAgICAg ICAoU2VjdGlvbiAxMS4yLjEpLl9fX18NCj4NCj4NCj4NCj4gSSBhbSBub3QgMTAwJSBzdXJlIGFi b3V0IHdoYXQgZXhhY3RseSBpcyBtZWFudCBieSBJQ0UgY2FuZGlkYXRlIGJlaW5nIA0KPiBhc3Nv Y2lhdGVkIHdpdGggYW4gbT0gbGluZS4gRG9lcyB0aGlzIG1lYW4gSUNFIGNhbmRpZGF0ZSBpcyBj cmVhdGVkIA0KPiBmb3IgdGhpcyBtPSBsaW5lIGFuZCAiY2FuZGlkYXRlIiBTRFAgYXR0cmlidXRl IGlzIGluY2x1ZGVkIGluIHRoaXMgbT0gbGluZT8NCj4NCj4gT3ZlcmFsbCB0aGUgdGV4dCBpcyBn b29kLCBidXQgSSB3b3VsZCBleHBsaWNpdGx5IHJlcGxhY2UgIklDRSANCj4gY2FuZGlkYXRlcyIg d2l0aCAiSUNFIGNhbmRpZGF0ZXMgb3IgYW55IG90aGVyIElDRS1yZWxhdGVkIG1lZGlhLWxldmVs IA0KPiBTRFAgYXR0cmlidXRlcyIgdG8gYXZvaWQgYW55IHBvdGVudGlhbCBjb25mdXNpb24uIFRo aXMgd2lsbCBhbHNvIG1ha2UgDQo+IHRoZSBwaHJhc2UgIlRoaXMgYWxzbyBhcHBseSB0byBhbnkg b3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQIA0KPiBhdHRyaWJ1dGUiIHVubmVjZXNz YXJ5Lg0KPiBfX19fX19fX19fX19fDQo+IFJvbWFuIFNocG91bnQNCg0K From nobody Mon Feb 22 12:21: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 337E41A0158 for ; Mon, 22 Feb 2016 12:21:14 -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 w6Y-MHNpfX7z for ; Mon, 22 Feb 2016 12:21:13 -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 4E44A1A00E3 for ; Mon, 22 Feb 2016 12:21:13 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-04v.sys.comcast.net with comcast id MYJP1s00L2LrikM01YMC43; Mon, 22 Feb 2016 20:21:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id MYMB1s00R3KdFy101YMCQJ; Mon, 22 Feb 2016 20:21:12 +0000 To: mmusic@ietf.org References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CB6DB6.30802@alum.mit.edu> Date: Mon, 22 Feb 2016 15:21:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: 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=1456172472; bh=wcz+j2MeCdLXqclGjnz1Cd83WonW7RISkeskAe+NB0E=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fvInr1Pln+j5wj+QVo3VJcSNlQgpbgrXmwCmedLvX9Pt4LCz4/7YUNXaz5kawzBbq +muAEBW/nKUJHjEIx+gUryVwhsoVnuQy3lB9FkjRUjzF0LpIrmnyNL/xIYx4zGySjG kefF3JsZLhLKCRSWtkIlKfg+geJAGJtBoXJsJi7B8DbMSkxhB3xZRtKkYaII8GZo1e NJwP/Luw9D7lbuEoxgkRfFvmQyaCQuUDv9nLYvXFKGO/ATCf5rM/dlTvSwzJsJu9fz 9tqThS5QlfwwadJaypNbA0D6YoqU+UiF3TwQHTUVhcYIA81zyhQu9NNwyDnxLce7rp vOsr2WsANKxpQ== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 20:21:14 -0000 On 2/22/16 2:52 PM, Roman Shpount wrote: > One thing that bothered me here is that PT cannot be reused for the > duration of the session. It is probably safe to reuse the PT after > session modification if PT is no longer used. I always felt that dynamic > PT reuse criteria were much stricter then realistically possible or needed. ... > I think the most important criteria here is that there should be no > ambiguity regarding how an RTP packet with particular PT should be > decoded. If it is guaranteed that there are no packets sent between > Alice and Bob with PT 111 over some reasonable time interval (couple of > network round trip times), then PT 111 can be safely reused. If, in this > scenario Bob's end point knows that it was not sending anything with > payload 111 recently, then it can safely reuse this payload. Alice could > not be sending anything with payload 111 since Bob did not accept it > previously. On the other hand, Bob must not reuse PT 100 for, let's say, > CN, since there are packets with this payload in flight and this will > create decoding ambiguity. To conclude, an end point should be able to > safely reuse any PT that it is not currently accepting or was not > sending or accepting for at least a few network round trip intervals. I agree that this is how it *should* be. I don't know if we can change this safely or not. It seems likely to me that some implementations might be freaked out by this. It is worth discussion. There are cases where it really isn't feasible to meet the current requirement. In particular, when a transfer is done via 3pcc the transferee won't know the history of past PT usage. So I expect in cases such cases the rule is commonly broken. Coming up with clear rules for when PTs can be recycled could be a challenge. Thanks, Paul From nobody Mon Feb 22 12:24: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 BC7821A1AFB for ; Mon, 22 Feb 2016 12:24:53 -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 CZthK3Flvt74 for ; Mon, 22 Feb 2016 12:24:52 -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 C22421A1ADF for ; Mon, 22 Feb 2016 12:24:51 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-02v.sys.comcast.net with comcast id MYQi1s00D2GyhjZ01YQrCh; Mon, 22 Feb 2016 20:24:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id MYQq1s00C3KdFy101YQqTF; Mon, 22 Feb 2016 20:24:51 +0000 To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37E3054E@ESESSMB209.ericsson.se> <56CB6C0B.1020209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35FDF@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CB6E91.6080506@alum.mit.edu> Date: Mon, 22 Feb 2016 15:24:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E35FDF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456172691; bh=H3WswSBWHr17YsSuQ8EttJJ2IsYgvVDQ6kX9BGDUQSs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AbImjNGXcgC1q60ec7k0z0deglsGxcaxFMqqosZBieVlKiLH15lfgtTdgn8qwN0Bh U//hBKSkerQVsQI5/aF94fVNvOM7RfJHc6haj/XWdHeEKGYW0J4bzVHCAB16994Rp8 uzkgqw/t9K3hmUwQH8bYg64DMoD8uXh4TmIHKlP+yqK1uEEJ7RZDJSjdkvj7NvFAMZ 2i9pY4gLfUrLg3RZXJ7EtUaJ55Y6GxLDe9t2k7ObdJG9GR76YCvH+E1ZmtT7OEcMAQ P4AKCPK0SgDGRQKXVqv7PCvr2MxvCr7of8UPC9Qi6xzvQe5UEbilb2D3yJtMQkjfXH ScTD4Ir7cijsQ== Archived-At: Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text 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, 22 Feb 2016 20:24:54 -0000 On 2/22/16 3:18 PM, Christer Holmberg wrote: > Hi Paul, > > I am trying to follow the same style as BUNDLE in general. Yes, I know it's messy, and I've lost count of the number of times I've had to re-write everything, but I am not going to do it again. Yes, I understand, and appreciate how difficult it has been to get something that everyone can understand and agree with. > Now, I did put together the new ICE text rather quickly, so there may be some mistakes, though. I *think* it is only the one place that is problematic, and I think it is in new text. And since it is the one that has different meaning than the others, changing the wording for it shouldn't disrupt anything else. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 22 February 2016 22:14 > To: Roman Shpount ; Christer Holmberg > Cc: mmusic@ietf.org; Peter Thatcher ; Ari Keränen > Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text > > Christer, > > [I'm replying to Christer, not Roman. For some reason I can't find Christer's original message in my email.] > > This generally seems good to me. I noticed one thing: > > While I understand the intent, you are using "associate", "associates" > or "associated" in multiple ways, that may be confusing to some readers. > E.g.: > > o Among bundled "m=" lines with which the offerer has associated a > shared address, the offerer only associates ICE-related media- > level SDP attributes with the "m=" line associated with the > offerer BUNDLE-tag. > ... > NOTE: The bundle-only "m=" line, if accepted by the answerer, will > inherit the candidates associated with the selected offerer BUNDLE > address. An answerer that does not support BUNDLE would not accept a > bundle-only "m=" line. > ... > When an offerer or answerer associates a shared address (i.e. a > previously selected BUNDLE address) with one or more bundled "m=" > lines, the offerer (or answerer) MUST only associate SDP 'candidate' > attributes with the "m=" line associated with the offerer BUNDLE-tag > (or the answerer BUNDLE-tag) address). The offerer or answerer MUST > NOT associate 'candidiate' attributes with any other bundled "m=" > line to which the offerer (or answerer) associates a shared address. > ... > When an offerer receives an answer, if the answerer supports and uses > the ICE mechanism and the BUNDLE extension, the offerer MUST > associate the same ICE candidates, associated with the "m=" line > representing the offerer BUNDLE address (selected by the answerer), > with each bundled "m=" line. > > So, which one of these things is not like the others? (This is a game we play with kids. Do they do it in Sweden too?) > > In most cases this is talking about where you put things in the SDP. But the last one above isn't that - it is about the implementation taking data from the answer and using it to update internal data structures. > > I don't have a specific suggestion for improving it. But I think it would be good to use someting other that "associate" in this case. I > *think* it is the only place where it is used this way. > > Thanks, > Paul > > > On 2/22/16 2:29 PM, Roman Shpount wrote: >> On Mon, Feb 22, 2016 at 5:10 AM, Christer Holmberg >> > > >> wrote: >> >> Assuming we will only associated ICE candidates to the “m=” line >> associated with the offerer/answerer BUNDLE-tag, below is a first >> suggested of modified ‘ICE Considerations’ text: >> >> __ __ >> >> -----------------------____ >> >> __ __ >> >> 11. ICE Considerations____ >> >> __ __ >> >> 11.1. General____ >> >> __ __ >> >> This section describes how to use the BUNDLE grouping >> extension____ >> >> together with the Interactive Connectivity Establishment >> (ICE)____ >> >> mechanism [RFC5245].____ >> >> __ __ >> >> The generic procedures for negotiating usage of ICE using >> SDP,____ >> >> defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of >> ICE____ >> >> with BUNDLE, with the following exceptions:____ >> >> __ __ >> >> o When BUNDLE addresses for a BUNDLE group have been selected >> for____ >> >> both endpoints, ICE connectivity checks and keep-alives only >> need____ >> >> to be performed for the whole BUNDLE group, instead of per >> bundled____ >> >> "m=" line.____ >> >> __ __ >> >> o Among bundled "m=" lines with which the offerer has >> associated a____ >> >> shared address, the offerer only associates ICE-related >> media-____ >> >> level SDP attributes with the "m=" line associated with >> the____ >> >> offerer BUNDLE-tag.____ >> >> __ __ >> >> o Among bundled "m=" lines with which the answerer has >> associated a____ >> >> shared address, the answerer only associates ICE-related >> media-____ >> >> level SDP attributes with the "m=" line associated with >> the____ >> >> answerer BUNDLE-tag.____ >> >> __ __ >> >> Support and usage of ICE mechanism together with the BUNDLE >> extension____ >> >> is OPTIONAL.____ >> >> __ __ >> >> 11.2. SDP Offer/Answer Procedures____ >> >> __ __ >> >> 11.2.1. General____ >> >> __ __ >> >> When an offerer associates a unique address with a bundled "m=" >> line____ >> >> (excluding any bundle-only "m=" line), it MUST also associate >> unique____ >> >> ICE candidates to the "m=" line, according to the procedures >> in____ >> >> [I-D.ietf-mmusic-ice-sip-sdp].____ >> >> __ __ >> >> An offerer MUST NOT associate ICE candidates with a bundle-only >> "m="____ >> >> line with a zero port value.____ >> >> __ __ >> >> NOTE: The bundle-only "m=" line, if accepted by the answerer, >> will____ >> >> inherit the candidates associated with the selected offerer >> BUNDLE____ >> >> address. An answerer that does not support BUNDLE would not >> accept a____ >> >> bundle-only "m=" line.____ >> >> __ __ >> >> When an offerer or answerer associates a shared address (i.e. >> a____ >> >> previously selected BUNDLE address) with one or more bundled >> "m="____ >> >> lines, the offerer (or answerer) MUST only associate SDP >> 'candidate'____ >> >> attributes with the "m=" line associated with the offerer >> BUNDLE-tag____ >> >> (or the answerer BUNDLE-tag) address). The offerer or answerer >> MUST____ >> >> NOT associate 'candidiate' attributes with any other bundled >> "m="____ >> >> line to which the offerer (or answerer) associates a shared >> address.____ >> >> This also apply to any other ICE-related media-level SDP >> attribute.____ >> >> __ __ >> >> NOTE: The following ICE-related media-level SDP attributes >> are____ >> >> defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', >> 'remote-____ >> >> candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and >> 'ice-____ >> >> pacing'.____ >> >> __ __ >> >> 11.2.2. Generating the Initial SDP Offer____ >> >> __ __ >> >> When an offerer generates an initial offer, it associates unique >> ICE____ >> >> candidates with the bundled "m=" lines, according to Section >> 11.2.1.____ >> >> __ __ >> >> 11.2.3. Generating the SDP Answer____ >> >> __ __ >> >> When an answerer generates an answer that contains a BUNDLE >> group,____ >> >> the answerer MUST only associate SDP 'candidate' attributes >> (and____ >> >> other ICE-related media-level SDP attributes) with the "m=" >> line____ >> >> associated with the answerer BUNDLE-tag.____ >> >> __ __ >> >> 11.2.4. Offerer Processing of the SDP Answer____ >> >> __ __ >> >> When an offerer receives an answer, if the answerer supports and >> uses____ >> >> the ICE mechanism and the BUNDLE extension, the offerer >> MUST____ >> >> associate the same ICE candidates, associated with the "m=" >> line____ >> >> representing the offerer BUNDLE address (selected by the >> answerer),____ >> >> with each bundled "m=" line.____ >> >> __ __ >> >> 11.2.5. Modifying the Session____ >> >> __ __ >> >> When an offerer generates a subsequent offer, it associates >> unique or____ >> >> shared ICE candidates with the bundled "m=" lines, according >> to____ >> >> (Section 11.2.1).____ >> >> >> >> I am not 100% sure about what exactly is meant by ICE candidate being >> associated with an m= line. Does this mean ICE candidate is created >> for this m= line and "candidate" SDP attribute is included in this m= line? >> >> Overall the text is good, but I would explicitly replace "ICE >> candidates" with "ICE candidates or any other ICE-related media-level >> SDP attributes" to avoid any potential confusion. This will also make >> the phrase "This also apply to any other ICE-related media-level SDP >> attribute" unnecessary. >> _____________ >> Roman Shpount > From nobody Mon Feb 22 12:42:35 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 7B21A1A1EFA for ; Mon, 22 Feb 2016 12:42:34 -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 Z-E5Jul8kE3D for ; Mon, 22 Feb 2016 12:42:33 -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 866F41A1EF1 for ; Mon, 22 Feb 2016 12:42:32 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-f4-56cb72b6052c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.11.28465.6B27BC65; Mon, 22 Feb 2016 21:42:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 21:42:29 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAAB/sA///p1yA= Date: Mon, 22 Feb 2016 20:42:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> In-Reply-To: <56CB6DB6.30802@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ru62otNhBjd2S1hMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG1Q83WQo2C1Q8mPiMpYGxgbeLkZNDQsBE 4vb/d2wQtpjEhXvrgWwuDiGBw4wSD1Z9AksICSxmlJgzNaGLkYODTcBCovufNkhYRMBX4tnj 22AlwgL6Eu8XHWGHiBtI7H15AMr2k1izswfMZhFQlZj5fA8riM0L1Hth53NmiF3LmCQ2HvgO luAU0JKYsv4YI4jNCHTQ91NrmEBsZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2kkTjkies EPU6Egt2Q9zPLKAtsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbR4tTi4tx0 I2O91KLM5OLi/Dy9vNSSTYzAODm45bfuDsbVrx0PMQpwMCrx8G6IOh0mxJpYVlyZe4hRgoNZ SYQ3NQYoxJuSWFmVWpQfX1Sak1p8iFGag0VJnHeN8/owIYH0xJLU7NTUgtQimCwTB6dUA2PI L2ltZd6Fe5u7Z+mJRAZEBPr8rlUPD2HefvLJ2YuF3YJTD077HnlbOfy9+b7gxv+TJ1wIW15t vVaVS0Xkicy0jtbNZ4/OmSeXeW3GLPVtazIUy3jkDd9eFzJ582FVw+GbR9t0mRt/xykcUY25 uizyIddH6fQjBWdZZM3Fw/Yf7f2x/iTHx81KLMUZiYZazEXFiQBxgatljwIAAA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 20:42:34 -0000 Hi, >> One thing that bothered me here is that PT cannot be reused for the=20 >> duration of the session. It is probably safe to reuse the PT after=20 >> session modification if PT is no longer used. I always felt that=20 >> dynamic PT reuse criteria were much stricter then realistically possible= or needed. >... >> I think the most important criteria here is that there should be no=20 >> ambiguity regarding how an RTP packet with particular PT should be=20 >> decoded. If it is guaranteed that there are no packets sent between=20 >> Alice and Bob with PT 111 over some reasonable time interval (couple=20 >> of network round trip times), then PT 111 can be safely reused. If, in=20 >> this scenario Bob's end point knows that it was not sending anything=20 >> with payload 111 recently, then it can safely reuse this payload.=20 >> Alice could not be sending anything with payload 111 since Bob did not=20 >> accept it previously. On the other hand, Bob must not reuse PT 100=20 >> for, let's say, CN, since there are packets with this payload in=20 >> flight and this will create decoding ambiguity. To conclude, an end=20 >> point should be able to safely reuse any PT that it is not currently=20 >> accepting or was not sending or accepting for at least a few network rou= nd trip intervals. > > I agree that this is how it *should* be. I don't know if we can change th= is safely or not. It seems likely to me that=20 > some implementations might be freaked out by this. It is worth discussion= . > > There are cases where it really isn't feasible to meet the current requir= ement. In particular, when a transfer is=20 > done via 3pcc the transferee won't know the history of past PT usage. So = I expect in cases such cases the rule is commonly broken. > > Coming up with clear rules for when PTs can be recycled could be a challe= nge. Well, I think we have to try, because these kind of issues keep causing pro= blems. The fact that something may freak about because we fix it is not a reason f= or not fixing it :) Regards, Christer From nobody Mon Feb 22 13:12: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 772D81A8768 for ; Mon, 22 Feb 2016 13:12:32 -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 E7ygqOhgLziK for ; Mon, 22 Feb 2016 13:12:31 -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 0C2CC1A876B for ; Mon, 22 Feb 2016 13:12:30 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-03v.sys.comcast.net with comcast id MZCC1s00A2Qkjl901ZCVYM; Mon, 22 Feb 2016 21:12:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id MZCV1s0053KdFy101ZCVYF; Mon, 22 Feb 2016 21:12:29 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CB79BB.9080906@alum.mit.edu> Date: Mon, 22 Feb 2016 16:12:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E36086@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=1456175549; bh=Jsrq8tV9vVISNKnpF37QP1IpiIrW6CBCVTh6VP4F7ig=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hJd/Oqfsyjx6BJaEu/KFBA6ynOfTfRfVQJgMVqpoXS+KWZHkx5MTkTrSnXTtOH1qB mlC3wnjJmAAcCZaxlDx3LdsJCFglci0a66JqzkD9nyMF/DP9uXzMR8SuLHJkC5aBsK BCUugDxbI8wdTQRAEGb1H65zjpHDCjCTzytA3lnZlSyioAZ9k1x5S9D1hVynYWBBMb 3pZl31O6JZZpclwtXT0O2L1v7nGMPtIPpmxXBH5Jo8HRSKXD0ZxDL8vzZLWaxRfQuo 9U1uyLsYjq1ZuZ6HI2AnRWYz+k2jUvF1v0QvAiDHZKibrhxoyplU9dpS4FRbN/EbTB GPNpz1lnV53aA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 21:12:32 -0000 On 2/22/16 3:42 PM, Christer Holmberg wrote: > Hi, > >>> One thing that bothered me here is that PT cannot be reused for the >>> duration of the session. It is probably safe to reuse the PT after >>> session modification if PT is no longer used. I always felt that >>> dynamic PT reuse criteria were much stricter then realistically possible or needed. >> ... >>> I think the most important criteria here is that there should be no >>> ambiguity regarding how an RTP packet with particular PT should be >>> decoded. If it is guaranteed that there are no packets sent between >>> Alice and Bob with PT 111 over some reasonable time interval (couple >>> of network round trip times), then PT 111 can be safely reused. If, in >>> this scenario Bob's end point knows that it was not sending anything >>> with payload 111 recently, then it can safely reuse this payload. >>> Alice could not be sending anything with payload 111 since Bob did not >>> accept it previously. On the other hand, Bob must not reuse PT 100 >>> for, let's say, CN, since there are packets with this payload in >>> flight and this will create decoding ambiguity. To conclude, an end >>> point should be able to safely reuse any PT that it is not currently >>> accepting or was not sending or accepting for at least a few network round trip intervals. >> >> I agree that this is how it *should* be. I don't know if we can change this safely or not. It seems likely to me that >> some implementations might be freaked out by this. It is worth discussion. >> >> There are cases where it really isn't feasible to meet the current requirement. In particular, when a transfer is >> done via 3pcc the transferee won't know the history of past PT usage. So I expect in cases such cases the rule is commonly broken. >> >> Coming up with clear rules for when PTs can be recycled could be a challenge. > > Well, I think we have to try, because these kind of issues keep causing problems. > > The fact that something may freak about because we fix it is not a reason for not fixing it :) I would like to see it fixed. Where there are ambiguities we have to accept that there will be winners and losers. (We hopefully aim for more winners than losers.) It is a little different when there is no ambiguity but we think that the spec was excessively stringent. Implementations that were following the clear but strict rules have some justification for being miffed if we make a change that breaks them. OTOH, when the current definition breaks a common use case, leading to common violation of the spec, then we have good justification for a change. Bottom line is that any "fix" needs to be thoroughly discussed and reviewed. IMO the right place to do that is sipcore. But we need to determine if there is support for working on the fix. (You and I and Martin constitute some interest.) We *could* take it through dispatch. Another possibility is to file an errata about it. Thanks, Paul From nobody Mon Feb 22 13:17: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 7BF9F1A8847 for ; Mon, 22 Feb 2016 13:17:52 -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 44Nkd43eSeSQ for ; Mon, 22 Feb 2016 13:17:51 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69B61A8846 for ; Mon, 22 Feb 2016 13:17:51 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-04v.sys.comcast.net with comcast id MZH91s0054yXVJQ01ZHrVz; Mon, 22 Feb 2016 21:17:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-06v.sys.comcast.net with comcast id MZHq1s00F3KdFy101ZHqlo; Mon, 22 Feb 2016 21:17:51 +0000 To: mmusic@ietf.org References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> <56CB79BB.9080906@alum.mit.edu> From: Paul Kyzivat Message-ID: <56CB7AFD.1050604@alum.mit.edu> Date: Mon, 22 Feb 2016 16:17:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CB79BB.9080906@alum.mit.edu> 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=1456175871; bh=oDCEPZw/qudTgsHYBjIuCfrfB+ss5cS/77NXs0l/cbQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=nGMa31Li7aPMaoWneP5ujk2xDkIgfGMAhyXfoN5Bc9KM+KQDq6ai8e+m2QJTBef8R I0HLZrIy36/im+/PXX7O12fYWd125LlGzkDoNxqHo0FNWRG3iiRmlP6PL3wpIOtqvi rkB00RU7ffpEz/oknkuD0QkOPZY6lVQTS+GkNIk87JAHRMtCSOFm2e9JJQw+BatoZc 5spyRNkzIA94TPW1wKphza1pkpLPB2P2QfXGoxumtFMvlptaS+skMXlpDqtSLt0ly0 699aOcMN5zEPxJsMTmBPhltujnfZo7DLfgf1ccMUqtexqNav5fV6y1ttRwBiD25Dds 5SFivDNwaKZhg== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 21:17:52 -0000 On 2/22/16 4:12 PM, Paul Kyzivat wrote: > IMO the right place to do that is sipcore. Duh - that was stupid. Of course MMUSIC is the home of 3264. Sorry, Paul From nobody Mon Feb 22 14:02: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 35A241A9175 for ; Mon, 22 Feb 2016 14:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 m-4gu-zlxpoY for ; Mon, 22 Feb 2016 14:01:58 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 208271A88DC for ; Mon, 22 Feb 2016 14:01:58 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id 5so92334750igt.0 for ; Mon, 22 Feb 2016 14:01:58 -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=TJXEMl3kUV78EhXkyY1mBld7kCq3sjXJFgLrdhNqOKQ=; b=T3WNwHqqEG4ChlblSQmA5TM94V+UhaRqlSB6/Z08yqzu8wmoH4PH/5HwQacVmXCJKj nqCjcrgjR2/auCGOZwEaPM57E6RTmwTIBuvZPZQnMmxHPHQHt2i/43T0CPrgkWiAY1lw QORLVebRhrKsZg+oACnmp2/ZxuW3xicPYNRR+FZvStZLUbwCEXAm2NIi3co8oe8zw3nA snOK9ZdRKD9OyQoP6ilmlnlab/V4ufYV1V0x7+HUlQuZE10H+vkybi48BYFCkAd+68NA gkiomWgwl4yVw5oEZqpT0GkuHm0AV5AxdDuPKr9O23h1saZNyBSyt+XpJSklABsTempI MG0Q== 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=TJXEMl3kUV78EhXkyY1mBld7kCq3sjXJFgLrdhNqOKQ=; b=G89Ey5yya6h0asK1OEIVXnCiPTGSeOB+SKhY4aTgV++ax0CIGYMeMcIVr2pXbTkOqm rBOyPqSSqipYIX1n4J6nVdGRgafIWgX2EY+RstQahKbtWVvycY1Q8cSBj8DjHODc1hhk 0XunzldB4dubWIAFzgDky62us02DBmOhw57Awn3qK88tRQzJLL8W7Mznr0UY129efzO6 g7UOq7Ud/h77Lb7zI5qSLxf62BaHx8lEZKPKY5e3X7+4D0hQMzJu+F4Il3g72xdt552Q Sru0766vYXqhSvClhMfHPlKctWPMluDf6CXj5yjUviQ2xA62plCkE1kJZ43r2TGap5UP Ziyw== X-Gm-Message-State: AG10YOSHwyVkmUpqeqNCVkGPT2vuubALBRkwMEZeKiLxagnOSn8MuCzor5wWBDigRQO3RA== X-Received: by 10.50.85.6 with SMTP id d6mr12661280igz.41.1456178517362; Mon, 22 Feb 2016 14:01:57 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id ei2sm9994697igc.11.2016.02.22.14.01.55 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 14:01:55 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id y8so97718011igp.0 for ; Mon, 22 Feb 2016 14:01:55 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.194 with SMTP id y2mr6379115igl.96.1456178515258; Mon, 22 Feb 2016 14:01:55 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 22 Feb 2016 14:01:55 -0800 (PST) In-Reply-To: <56CB79BB.9080906@alum.mit.edu> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> <56CB79BB.9080906@alum.mit.edu> Date: Mon, 22 Feb 2016 17:01:55 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bfea0b621bf81052c62fb81 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 22:01:59 -0000 --047d7bfea0b621bf81052c62fb81 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 22, 2016 at 4:12 PM, Paul Kyzivat wrote: > OTOH, when the current definition breaks a common use case, leading to > common violation of the spec, then we have good justification for a change. > > I think you have mentioned before that 3rd party call control cannot possibly track all the PT for the session which causes common violation for the spec. Is this justification enough? _____________ Roman Shpount --047d7bfea0b621bf81052c62fb81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 22, 2016 at 4:1= 2 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
OTOH, when the current definition breaks a common use case, leadin= g to common violation of the spec, then we have good justification for a ch= ange.


I think you have mentioned before that= 3rd party call control cannot possibly track all the PT for the session wh= ich causes common violation for the spec. Is this justification enough?
_____________
Roman Shpount
<= /div>
=C2=A0
--047d7bfea0b621bf81052c62fb81-- From nobody Mon Feb 22 14:43: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 2EF361AC416 for ; Mon, 22 Feb 2016 14:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52Hm_PApdx1I for ; Mon, 22 Feb 2016 14:43:22 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 8A13A1AC415 for ; Mon, 22 Feb 2016 14:43:22 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u1MMY8Ac044146; Mon, 22 Feb 2016 17:43:18 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 216n07p5km-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Feb 2016 17:43:17 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1MMhGxt009133; Mon, 22 Feb 2016 17:43:16 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1MMhAEh009050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Feb 2016 17:43:13 -0500 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 22 Feb 2016 22:43:05 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.77]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 17:43:05 -0500 From: "DOLLY, MARTIN C" To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAlR48AAGjC9oAAAUJQAAAA/2gAAAC+cAAABlmFYA== Date: Mon, 22 Feb 2016 22:43:04 +0000 Message-ID: References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.225.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602220249 Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 22:43:24 -0000 Paul, I agree with Christer, this needs to be fixed. We are doing interop testing= with other carriers for VoIP interconnection, and this is a major issue. Fixing this would help accelerate VoIP interconnection. Regards, Martin -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Monday, February 22, 2016 3:42 PM To: Paul Kyzivat ; mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions Hi, >> One thing that bothered me here is that PT cannot be reused for the=20 >> duration of the session. It is probably safe to reuse the PT after=20 >> session modification if PT is no longer used. I always felt that=20 >> dynamic PT reuse criteria were much stricter then realistically possible= or needed. >... >> I think the most important criteria here is that there should be no=20 >> ambiguity regarding how an RTP packet with particular PT should be=20 >> decoded. If it is guaranteed that there are no packets sent between=20 >> Alice and Bob with PT 111 over some reasonable time interval (couple=20 >> of network round trip times), then PT 111 can be safely reused. If,=20 >> in this scenario Bob's end point knows that it was not sending=20 >> anything with payload 111 recently, then it can safely reuse this payloa= d. >> Alice could not be sending anything with payload 111 since Bob did=20 >> not accept it previously. On the other hand, Bob must not reuse PT=20 >> 100 for, let's say, CN, since there are packets with this payload in=20 >> flight and this will create decoding ambiguity. To conclude, an end=20 >> point should be able to safely reuse any PT that it is not currently=20 >> accepting or was not sending or accepting for at least a few network rou= nd trip intervals. > > I agree that this is how it *should* be. I don't know if we can change=20 > this safely or not. It seems likely to me that some implementations might= be freaked out by this. It is worth discussion. > > There are cases where it really isn't feasible to meet the current=20 > requirement. In particular, when a transfer is done via 3pcc the transfer= ee won't know the history of past PT usage. So I expect in cases such cases= the rule is commonly broken. > > Coming up with clear rules for when PTs can be recycled could be a challe= nge. Well, I think we have to try, because these kind of issues keep causing pro= blems. The fact that something may freak about because we fix it is not a reason f= or not fixing it :) Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Feb 22 15:01: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 DB1251A88C5 for ; Mon, 22 Feb 2016 15:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 hePSkzr5yDkB for ; Mon, 22 Feb 2016 15:01:42 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001: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 EAB6A1A8861 for ; Mon, 22 Feb 2016 15:01:41 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id hb3so87895792igb.0 for ; Mon, 22 Feb 2016 15:01:41 -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=g/KD9I8c5V6BFl7vcpUg+0WgBfhY9/O/wnpJvkJj2og=; b=yVz2DovORD+vKeGbiRpNa/z4OLj5BuD2HYl3/kfdAS8Rs7/gh1cukA6dcUm4UmYnsb cGSUENCA2Xu7AxZANoNtV6zbI9H5KJM87UgWJ/zTobxy8JwUUqyZL942WuSLKMbhtKg3 F4U63qLbWLtnnE04RkS2PEjcc7p+g5JLk5JDdL1FWyWAel8+/bNBW4qKpWVoBLlc+WLm yLpLYOZGDUyECnNxjD/H4C7JwGySoG63RH6jjMfVUwWnMQUM1Gb11hFvmG21jNoBHLfq RZrdtpaUmRggs6CRSpVcOLN/WclS+2TVt4rfcScnOeNB39NE8AzkxoobfV5cJNDpi4wm z8KA== 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=g/KD9I8c5V6BFl7vcpUg+0WgBfhY9/O/wnpJvkJj2og=; b=QQNa1jubr6Rzy45sghTvH9g1UjGe+V4XxP1TKQC2+f3+6l8PxgbTfqbk6FgOF9kgsi uAkHMNrsUbUwnrzt42B6QqnAMQ7Wc8//bhFtzmlgWHWarg8oqOPDr//HQFqOmDEET1o+ HNXmrP0uVLVM/EowbuhFRR8QOMcSwWE+kjLgNYYyRDlS6dxTmnwftm3mnLJo3Np/7IZJ 0dJgx4PLt5KSTEidFNe2PTc1RIZJ8Kvm/uvZJvYmrqc20tv6mtyzFceXBA2RNSupmCnj F6oKAxKH57EOK6c7jr2c4asNgbCZ2Ca3nu2SnVr0LLAVjlOqjD0/ceA+Co99rOZFaSun mf4w== X-Gm-Message-State: AG10YOQlLK2zjPJ0S3cZj7L43TgTdeET4JDSk5L4CMD7WcCnTQfDXTzwCq0Rrgh/r819sA== X-Received: by 10.50.1.109 with SMTP id 13mr14575677igl.34.1456182101409; Mon, 22 Feb 2016 15:01:41 -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 n3sm10106114igr.17.2016.02.22.15.01.39 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 15:01:40 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id g6so98769723igt.1 for ; Mon, 22 Feb 2016 15:01:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.194 with SMTP id y2mr6634325igl.96.1456182099583; Mon, 22 Feb 2016 15:01:39 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 22 Feb 2016 15:01:39 -0800 (PST) In-Reply-To: References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> Date: Mon, 22 Feb 2016 18:01:39 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=047d7bfea0b6c62ca2052c63d035 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 23:01:43 -0000 --047d7bfea0b6c62ca2052c63d035 Content-Type: text/plain; charset=UTF-8 Marin, Can you provide any more details about how exactly things are failing and potentially what equipment is affected? I believe part of the effort in fixing this issue would be trying to determine who will be negatively affected by the fix and how to minimize the disruption. _____________ Roman Shpount --047d7bfea0b6c62ca2052c63d035 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Marin,

Can you provide any more details= about how exactly things are failing and potentially what equipment is aff= ected?

I= believe part of the effort in fixing this issue would be trying to determi= ne who will be negatively affected by the fix and how to minimize the disru= ption.
_____________Roman Shpount

--047d7bfea0b6c62ca2052c63d035-- From nobody Mon Feb 22 15:10: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 E721F1ACF08 for ; Mon, 22 Feb 2016 15:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpUr6j1LtQEZ for ; Mon, 22 Feb 2016 15:10:46 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E58AD1ACEC9 for ; Mon, 22 Feb 2016 15:10:46 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u1MNA2v6020602; Mon, 22 Feb 2016 18:10:42 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 216nr4e21v-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Feb 2016 18:10:42 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1MNAeHY005857; Mon, 22 Feb 2016 18:10:41 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1MNAXdS005778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Feb 2016 18:10:35 -0500 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 22 Feb 2016 23:10:22 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.77]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 18:10:22 -0500 From: "DOLLY, MARTIN C" To: Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAlR48AAGjC9oAAAUJQAAAA/2gAAAC+cAAABlmFYP//9BeAgABR7EA= Date: Mon, 22 Feb 2016 23:10:21 +0000 Message-ID: References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@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: [135.70.225.11] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615E45E5DMISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602220254 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 23:10:49 -0000 --_000_E42CCDDA6722744CB241677169E8365615E45E5DMISOUT7MSGUSRDB_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9tYW4sDQoNCk15IGluaXRpYWwgZW1haWwgaWxsdXN0cmF0ZWQgYSBmYWlsdXJlIGNhc2UuDQoN Ck5EQSBwcmV2ZW50cyBtZSBmcm9tIGFuc3dlcmluZyB0aGUgZXF1aXBtZW50IHF1ZXN0aW9uLg0K DQpSZWdhcmRzLA0KDQpNYXJ0aW4NCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFu QHRlbHVyaXguY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyMiwgMjAxNiA2OjAyIFBNDQpU bzogRE9MTFksIE1BUlRJTiBDIDxtZDMxMzVAYXR0LmNvbT4NCkNjOiBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgUGF1bCBLeXppdmF0IDxwa3l6aXZh dEBhbHVtLm1pdC5lZHU+OyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBP ZmZlci9BbnN3ZXIgUFQgUXVlc3Rpb25zDQoNCk1hcmluLA0KDQpDYW4geW91IHByb3ZpZGUgYW55 IG1vcmUgZGV0YWlscyBhYm91dCBob3cgZXhhY3RseSB0aGluZ3MgYXJlIGZhaWxpbmcgYW5kIHBv dGVudGlhbGx5IHdoYXQgZXF1aXBtZW50IGlzIGFmZmVjdGVkPw0KDQpJIGJlbGlldmUgcGFydCBv ZiB0aGUgZWZmb3J0IGluIGZpeGluZyB0aGlzIGlzc3VlIHdvdWxkIGJlIHRyeWluZyB0byBkZXRl cm1pbmUgd2hvIHdpbGwgYmUgbmVnYXRpdmVseSBhZmZlY3RlZCBieSB0aGUgZml4IGFuZCBob3cg dG8gbWluaW1pemUgdGhlIGRpc3J1cHRpb24uDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50 DQoNCg== --_000_E42CCDDA6722744CB241677169E8365615E45E5DMISOUT7MSGUSRDB_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9tYW4sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NeSBpbml0aWFsIGVtYWlsIGlsbHVzdHJh dGVkIGEgZmFpbHVyZSBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+TkRBIHByZXZlbnRzIG1lIGZyb20gYW5zd2VyaW5nIHRoZSBlcXVpcG1lbnQgcXVlc3Rp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFydGluPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDY6MDIgUE08YnI+DQo8Yj5Ubzo8L2I+IERP TExZLCBNQVJUSU4gQyAmbHQ7bWQzMTM1QGF0dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OzsgUGF1 bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7OyBtbXVzaWNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIE9mZmVyL0Fuc3dlciBQVCBRdWVzdGlv bnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJpbiw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcHJvdmlkZSBhbnkg bW9yZSBkZXRhaWxzIGFib3V0IGhvdyBleGFjdGx5IHRoaW5ncyBhcmUgZmFpbGluZyBhbmQgcG90 ZW50aWFsbHkgd2hhdCBlcXVpcG1lbnQgaXMgYWZmZWN0ZWQ/PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgcGFydCBvZiB0aGUgZWZmb3J0IGlu IGZpeGluZyB0aGlzIGlzc3VlIHdvdWxkIGJlIHRyeWluZyB0byBkZXRlcm1pbmUgd2hvIHdpbGwg YmUgbmVnYXRpdmVseSBhZmZlY3RlZCBieSB0aGUgZml4IGFuZCBob3cgdG8gbWluaW1pemUgdGhl IGRpc3J1cHRpb24uPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_E42CCDDA6722744CB241677169E8365615E45E5DMISOUT7MSGUSRDB_-- From nobody Mon Feb 22 15:21:56 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 852FD1B2D8D for ; Mon, 22 Feb 2016 15:21:49 -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 d1PsHhm3gar7 for ; Mon, 22 Feb 2016 15:21:47 -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 BC2251B2BE5 for ; Mon, 22 Feb 2016 15:21:47 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-07v.sys.comcast.net with comcast id MbMY1s0012LrikM01bMmXs; Mon, 22 Feb 2016 23:21:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id MbMm1s0063KdFy101bMmzV; Mon, 22 Feb 2016 23:21:46 +0000 To: "DOLLY, MARTIN C" , Christer Holmberg , "mmusic@ietf.org" References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CB9809.3040103@alum.mit.edu> Date: Mon, 22 Feb 2016 18:21:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: 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=1456183306; bh=3OJ4zv+5fiGG2i+x/B3ZfX/wZlXTn39T4bVhDHyHTV8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pCQCZ/tGqjywIuPL2FbTNwdO6ihLzaigVicMlDL38yV2dEkcLuMO0NveDPyfV7D5s v3vVw2QUNmzbXctLxy49lT7pkIOqDxHfldoOTqgxHCrVCu4mwKOOpjxVMmGtF4A57s Ia0RyKAOYVxvOIjkQQQI4o9dUkVpsFaNM1/X6PobZFR4xU53psOt4Q64a2ZagW5HiM mmI+2H+xeTDN7VI9B1Av0RYOibK1qbDFQee8B7iGVoqeE9FgsvdUJmpLlkVjuOJ6/R TKtEUdxrjINRjw9wZ3PVLswykBmkV+1tzBEcIcAf7qghMd2J/XV4sRN44S5WlUul+I eKl5hY7ZWpSpw== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 23:21:49 -0000 On 2/22/16 5:43 PM, DOLLY, MARTIN C wrote: > Paul, > > I agree with Christer, this needs to be fixed. We are doing interop testing with other carriers for VoIP interconnection, and this is a major issue. As I said, I also think fixing this would be a good thing. I'm not the chair, so it isn't my call. Key is to round up a critical mass to work-on/review this, and flush out any with concerns about such a change. IMO this will at least require a work item and a draft. Thanks, Paul > Fixing this would help accelerate VoIP interconnection. > > Regards, > > Martin > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Monday, February 22, 2016 3:42 PM > To: Paul Kyzivat ; mmusic@ietf.org > Subject: Re: [MMUSIC] Offer/Answer PT Questions > > Hi, > >>> One thing that bothered me here is that PT cannot be reused for the >>> duration of the session. It is probably safe to reuse the PT after >>> session modification if PT is no longer used. I always felt that >>> dynamic PT reuse criteria were much stricter then realistically possible or needed. >> ... >>> I think the most important criteria here is that there should be no >>> ambiguity regarding how an RTP packet with particular PT should be >>> decoded. If it is guaranteed that there are no packets sent between >>> Alice and Bob with PT 111 over some reasonable time interval (couple >>> of network round trip times), then PT 111 can be safely reused. If, >>> in this scenario Bob's end point knows that it was not sending >>> anything with payload 111 recently, then it can safely reuse this payload. >>> Alice could not be sending anything with payload 111 since Bob did >>> not accept it previously. On the other hand, Bob must not reuse PT >>> 100 for, let's say, CN, since there are packets with this payload in >>> flight and this will create decoding ambiguity. To conclude, an end >>> point should be able to safely reuse any PT that it is not currently >>> accepting or was not sending or accepting for at least a few network round trip intervals. >> >> I agree that this is how it *should* be. I don't know if we can change >> this safely or not. It seems likely to me that some implementations might be freaked out by this. It is worth discussion. >> >> There are cases where it really isn't feasible to meet the current >> requirement. In particular, when a transfer is done via 3pcc the transferee won't know the history of past PT usage. So I expect in cases such cases the rule is commonly broken. >> >> Coming up with clear rules for when PTs can be recycled could be a challenge. > > Well, I think we have to try, because these kind of issues keep causing problems. > > The fact that something may freak about because we fix it is not a reason for not fixing it :) > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Feb 22 15:23: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 01B311B2DC9 for ; Mon, 22 Feb 2016 15:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 nIWOwMDTt2q7 for ; Mon, 22 Feb 2016 15:23:30 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 D97C71B2DAB for ; Mon, 22 Feb 2016 15:23:29 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id g6so99111037igt.1 for ; Mon, 22 Feb 2016 15:23:29 -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=ZgvETM6ke5je+4DUZlJX2yTHuRP1aNmd8S9jgG6ofEA=; b=1+rhqzkOdo2ZHOhvvVxwyCokhvydQ69i143SyokF+ZSJUw6xZR3vdaWr/7zuc47y1V Ll6TW1ks0Otfnyrve2JXJ3hxcLQVSAIXbGLL6P0jjCSHE5L/gx49ghLUfDmGIPlz/tfw kVoKfAHRjSOvgut42+y4V6Z9O/lu2QiGZnaNG2qfAwkChKHX1E6+B8qGcjbg1KD1fWDu d9oH4bQP3F6Bodn8080NoGIcMdm7YiRSlAY1dnMHlHFa76RzwtRJoFobb82XpzqdiP0L 0iqo/e4XQJc9ymC/VmUwYQa8B6+EkNx/RB+hoc2xb2pXLvwdPIZ/E48AxO/svwb7Ynn5 LDgQ== 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=ZgvETM6ke5je+4DUZlJX2yTHuRP1aNmd8S9jgG6ofEA=; b=arjap8tGsWcAAihdFOPbdN5xB+sBKinR3Gkz8uMLzVWcZUT6UhsYO9ujU3RvcIsAJn c/V7DJ6RM5RO9DWQB4id3iXuh6Yl3yGLOTauz5oRZEql8pTztbNWWLdjNllT/bkB/HUC 6ujdNymDJUDx71L2G9VX2fzO3JhvByFQZ2/5dMlwr9RvcNulSqveuVo9VtIhdrGqXyv9 IF04ztENcNQMQvNQrJ2XvNeWUEvyH7Y/cg4QO8jBe+iqrC1vzxCaECZOuiHZjDw1B4V8 sdqVECEy8NjJT6SdLEktwR+OVpDCAeNHhDll8stU7c+9rhojmmBg25kmV4mMXFc7f/xI ZTew== X-Gm-Message-State: AG10YOQfbMPf+q0r7kjbSeB/ma3Eo2e8PyxwS4HBMW7BW2AXBj9/x8qWrFKbS6NkXrsFSg== X-Received: by 10.50.50.144 with SMTP id c16mr5005843igo.75.1456183409250; Mon, 22 Feb 2016 15:23:29 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by smtp.gmail.com with ESMTPSA id mu8sm10132270igb.16.2016.02.22.15.23.28 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 15:23:28 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id g6so99110535igt.1 for ; Mon, 22 Feb 2016 15:23:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr5284021igh.2.1456183407653; Mon, 22 Feb 2016 15:23:27 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 22 Feb 2016 15:23:27 -0800 (PST) In-Reply-To: References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> Date: Mon, 22 Feb 2016 18:23:27 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=047d7bdca2ecbdc3a2052c641e4a Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 23:23:31 -0000 --047d7bdca2ecbdc3a2052c641e4a Content-Type: text/plain; charset=UTF-8 On Mon, Feb 22, 2016 at 6:10 PM, DOLLY, MARTIN C wrote: > My initial email illustrated a failure case. > What exactly is happening after Bob send a re-INVITE with PT 111: AMR(mode-set=0,2,5,7)? Do you get an error response back or does some other failure occurs? NDA prevents me from answering the equipment question. > > > This is understandable. Any information you can provide about how this issue affects real world deployments would be helpful. Regards, _____________ Roman Shpount --047d7bdca2ecbdc3a2052c641e4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 22, 2016 at 6:10 PM, DOLLY, MARTIN C <= ;md3135@att.com>= wrote:

My initial email illustrated a failure case.=


What exactly is hap= pening after Bob send a re-INVITE with=C2=A0PT 111: AMR(mode-set=3D0,2,5,7)? Do you get an error res= ponse back or does some other failure occurs?

NDA prevents me from answering the equipment ques= tion.



This = is understandable. Any information you can provide about how this issue aff= ects real world deployments would be helpful.

Rega= rds,
_____________
Roman Shpoun= t
=C2=A0
--047d7bdca2ecbdc3a2052c641e4a-- From nobody Mon Feb 22 20:13: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 EBD131A1B25; Mon, 22 Feb 2016 20:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-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 u6BHFtHtnjOF; Mon, 22 Feb 2016 20:13:08 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6691A1B11; Mon, 22 Feb 2016 20:13:08 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 37A0F41454; Mon, 22 Feb 2016 21:17:52 -0700 (MST) To: Christer Holmberg , Roman Shpount 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> <7594FB04B1934943A5C02806D1A2204B37D4FCFD@ESESSMB209.ericsson.se> From: Peter Saint-Andre Message-ID: <56CBDC52.2020200@stpeter.im> Date: Mon, 22 Feb 2016 21:13:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D4FCFD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "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: Tue, 23 Feb 2016 04:13:09 -0000 On 1/20/16 1:12 PM, Christer Holmberg wrote: > Another, more administrative issue, is that we also would need to get this change into JSEP and trickle ICE. Unless I remember wrong, both of those specs currently references RFC 5245. draft-ietf-ice-trickle references icebis. > -----Original Message----- > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 20 January 2016 22:10 > To: Roman Shpount > Cc: Ari Keränen ; mmusic@ietf.org; Marc Petit-Huguenin ; ice@ietf.org; 🔓Dan Wing ; snandaku@cisco.com > Subject: Re: [Ice] [MMUSIC] SDP rtcp attribute with trickle ICE > > Hi Roman, > >>> 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? > > I am not sure we need to say anything about mux. > > When reading your text again, I now agree that it covers my case. I just hope it is clear enough :) > > Perhaps, in the trickle ICE document, we could have a note somewhere clarifying that the RTCP candidate is not used when the RTP port is 9. We removed all of the SDP-related text from draft-ietf-ice-trickle because we were supposed to write a trickle-sdp or trickle-sip specification. Right now we don't have that text about the RTP port in draft-ietf-ice-trickle... Peter From nobody Tue Feb 23 00:21: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 128D41A892E; Tue, 23 Feb 2016 00:21:56 -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 sDovv0dcU9QY; Tue, 23 Feb 2016 00:21:54 -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 AD9D91A6F6D; Tue, 23 Feb 2016 00:21:53 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-8c-56cc169fbf44 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E1.AF.15637.F961CC65; Tue, 23 Feb 2016 09:21:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 09:21:30 +0100 From: Christer Holmberg To: Peter Saint-Andre , Roman Shpount Thread-Topic: [Ice] [MMUSIC] SDP rtcp attribute with trickle ICE Thread-Index: AQHRbfCBy6kW0xkla0e/dxDRHc8GdZ85SebA Date: Tue, 23 Feb 2016 08:21:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E388FC@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> <7594FB04B1934943A5C02806D1A2204B37D4FCFD@ESESSMB209.ericsson.se> <56CBDC52.2020200@stpeter.im> In-Reply-To: <56CBDC52.2020200@stpeter.im> 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+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7iu58sTNhBm2/zC0uXnvIZPHtQq3F 2uM3GS2mLn/MYjHjwlRmi8UH7rNaHNvTz+zA7jHl90ZWjyVLfjJ5HD99ndVj7p4XzB63phQE sEZx2aSk5mSWpRbp2yVwZXxY94C54IVYxa0rZxkbGOeIdTFyckgImEhcvvWCGcIWk7hwbz1b FyMXh5DAYUaJvce3MUE4ixklJr+bCpTh4GATsJDo/qcN0iAi4Ctxsm87M0gNs0A/k0T31PeM IAlhAXuJcz+fsUIUOUjM+3OQDcI2krh78Q5YDYuAqsT8xplMIDYv0KDl206wg9hCAivZJc7+ BKvnFNCS2HfjKtgcRqDrvp9aA1bPLCAucevJfCaIqwUkluw5D/WBqMTLx/9YIWwliRXbLzGC 3MwsoCmxfpc+RKuixJTuh+wQawUlTs58wjKBUWwWkqmzEDpmIemYhaRjASPLKkbR4tTipNx0 I2O91KLM5OLi/Dy9vNSSTYzASDy45bfqDsbLbxwPMQpwMCrx8G6IOh0mxJpYVlyZe4hRgoNZ SYTXge9MmBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeNc7rw4QE0hNLUrNTUwtSi2CyTBycUg2M zqcuhW9iDKrjUptvmRzKkD1V8/Ap+ZDZWnfZ5ByceLWmfypxTvlZEuQbHnJi/rqcpB+vWv48 17ujmbNlwmG9ILtUU55buvJdWRan83SjnPtnOK6vzW666KZhzGi66vwn38TgfCG75tdyJaUn pj2rXNmy1+IBe/qMtd7O/yJPb1/BJXb2xh0lluKMREMt5qLiRADsmQkcwAIAAA== 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: Tue, 23 Feb 2016 08:21:56 -0000 SGksDQoNCj4+IEFub3RoZXIsIG1vcmUgYWRtaW5pc3RyYXRpdmUgaXNzdWUsIGlzIHRoYXQgd2Ug YWxzbyB3b3VsZCBuZWVkIHRvIGdldCB0aGlzIGNoYW5nZSBpbnRvIEpTRVAgYW5kIHRyaWNrbGUg SUNFLiBVbmxlc3MgSSByZW1lbWJlciB3cm9uZywgYm90aCBvZiB0aG9zZSBzcGVjcyBjdXJyZW50 bHkgcmVmZXJlbmNlcyBSRkMgNTI0NS4NCj4NCj4gZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSByZWZl cmVuY2VzIGljZWJpcy4NCg0KU29ycnksIEkgbWVhbiBkcmFmdC1pZXRmLW1tdXNpYy10cmlja2xl LWljZS1zaXAuDQoNCi4uLi53aGljaCBvZiBjb3Vyc2UgcmVmZXJlbmNlcyBkcmFmdC1pZXRmLWlj ZS10cmlja2xlLCBhbmQgdGhlcmVmb3IgaW1wbGljaXRseSA1MjQ1YmlzIDopDQoNClNvLCB1bmxl c3Mgc29tZW9uZSBoYXMgYSB0ZWNobmljYWwgcmVhc29uIHdoeSBKU0VQLCB0cmlja2xlLWljZS1z aXAgZXRjIHNob3VsZCByZWZlcmVuY2UgUkZDIDUyNDUsIEkgcmVhbGx5IHRoaW5rIHdlIHNob3Vs ZCBjaGFuZ2UgYW5kIHJlZmVyZW5jZSA1MjQ1YmlzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEljZSBbbWFpbHRvOmljZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gU2VudDog MjAgSmFudWFyeSAyMDE2IDIyOjEwDQo+IFRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbT4NCj4gQ2M6IEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPjsgbW11 c2ljQGlldGYub3JnOyBNYXJjIA0KPiBQZXRpdC1IdWd1ZW5pbiA8bWFyY0BwZXRpdC1odWd1ZW5p bi5vcmc+OyBpY2VAaWV0Zi5vcmc7IPCflJNEYW4gV2luZyANCj4gPGR3aW5nQGNpc2NvLmNvbT47 IHNuYW5kYWt1QGNpc2NvLmNvbQ0KPiBTdWJqZWN0OiBSZTogW0ljZV0gW01NVVNJQ10gU0RQIHJ0 Y3AgYXR0cmlidXRlIHdpdGggdHJpY2tsZSBJQ0UNCj4NCj4gSGkgUm9tYW4sDQo+DQo+Pj4gWW91 ciBzdWdnZXN0ZWQgdGV4dCBsb29rcyBvaywgYnV0IGl0IGRvZXMgbm90IHNvbHZlIG15IGlzc3Vl IDopIEkgDQo+Pj4gdGhpbmsgaXQgc2hvdWxkIGJlIGNsZWFyIHRoYXQsIGlmIHRoZXJlIGlzIG5v IFJUQ1AgY2FuZGlkYXRlLCB0aGUgc3BlYyBkb2VzIG5vdCBkZWZpbmUgdXNhZ2Ugb2YgdGhlIFNE UCBydGNwIGF0dHJpYnV0ZS4NCj4+DQo+PiBXZWxsLCBpbiBteSBwcm9wb3NlZCB0ZXh0ICJpZiBS VENQIGNhbmRpZGF0ZSBpcyBwcmVzZW50IGFuZCBub3QgZXF1YWwgDQo+PiB0byB0aGUgc2FtZSBh ZGRyZXNzIGFuZCB0aGUgbmV4dCBoaWdoZXIgcG9ydCBudW1iZXIgb2YgdGhlIFJUUCBjYW5kaWRh dGUsIHRoZSBhZ2VudCBNVVNUIGVuY29kZSB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9 cnRjcCBhdHRyaWJ1dGUiLg0KPj4gRG8geW91IGFsc28gd2FudCB0ZXh0IHNheWluZyB0aGF0IGE9 cnRjcCBhdHRyaWJ1dGUgTVVTVCBub3QgYmUgcHJlc2VudCBvZiBubyBSVENQIGNhbmRpZGF0ZXMg YXJlIHByZXNlbnQgYW5kIHJ0Y3AtbXV4IGlzIG5vdCB1c2VkPw0KPg0KPiBJIGFtIG5vdCBzdXJl IHdlIG5lZWQgdG8gc2F5IGFueXRoaW5nIGFib3V0IG11eC4NCj4NCj4gV2hlbiByZWFkaW5nIHlv dXIgdGV4dCBhZ2FpbiwgSSBub3cgYWdyZWUgdGhhdCBpdCBjb3ZlcnMgbXkgY2FzZS4gSSANCj4g anVzdCBob3BlIGl0IGlzIGNsZWFyIGVub3VnaCA6KQ0KPg0KPiBQZXJoYXBzLCBpbiB0aGUgdHJp Y2tsZSBJQ0UgZG9jdW1lbnQsIHdlIGNvdWxkIGhhdmUgYSBub3RlIHNvbWV3aGVyZSBjbGFyaWZ5 aW5nIHRoYXQgdGhlIFJUQ1AgY2FuZGlkYXRlIGlzIG5vdCB1c2VkIHdoZW4gdGhlIFJUUCBwb3J0 IGlzIDkuDQoNCldlIHJlbW92ZWQgYWxsIG9mIHRoZSBTRFAtcmVsYXRlZCB0ZXh0IGZyb20gZHJh ZnQtaWV0Zi1pY2UtdHJpY2tsZSBiZWNhdXNlIHdlIHdlcmUgc3VwcG9zZWQgdG8gd3JpdGUgYSB0 cmlja2xlLXNkcCBvciB0cmlja2xlLXNpcCBzcGVjaWZpY2F0aW9uLiBSaWdodCBub3cgd2UgZG9u J3QgaGF2ZSB0aGF0IHRleHQgYWJvdXQgdGhlIFJUUCBwb3J0IGluIGRyYWZ0LWlldGYtaWNlLXRy aWNrbGUuLi4NCg0KUGV0ZXINCg0KDQo= From nobody Tue Feb 23 02:29: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 8F9441B416F for ; Tue, 23 Feb 2016 02:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 YWavw3RzrG3f for ; Tue, 23 Feb 2016 02:29:36 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5431B416E for ; Tue, 23 Feb 2016 02:29:36 -0800 (PST) Received: from [130.209.247.112] (port=51991 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aYADk-00056o-25; Tue, 23 Feb 2016 10:29:33 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_DA40CA53-019F-45EF-BE26-4B6DF4CE0A19" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Tue, 23 Feb 2016 10:29:28 +0000 Message-Id: <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 10:29:38 -0000 --Apple-Mail=_DA40CA53-019F-45EF-BE26-4B6DF4CE0A19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Feb 2016, at 19:52, Roman Shpount wrote: =E2=80=A6 > One thing that bothered me here is that PT cannot be reused for the = duration of the session. It is probably safe to reuse the PT after = session modification if PT is no longer used. I always felt that dynamic = PT reuse criteria were much stricter then realistically possible or = needed.=20 =E2=80=A6 > I think the most important criteria here is that there should be no = ambiguity regarding how an RTP packet with particular PT should be = decoded. If it is guaranteed that there are no packets sent between = Alice and Bob with PT 111 over some reasonable time interval (couple of = network round trip times), then PT 111 can be safely reused. If, in this = scenario Bob's end point knows that it was not sending anything with = payload 111 recently, then it can safely reuse this payload. Alice could = not be sending anything with payload 111 since Bob did not accept it = previously. On the other hand, Bob must not reuse PT 100 for, let's say, = CN, since there are packets with this payload in flight and this will = create decoding ambiguity. To conclude, an end point should be able to = safely reuse any PT that it is not currently accepting or was not = sending or accepting for at least a few network round trip intervals. No objection in principle, but it=E2=80=99s not as simple as =E2=80=9Ca = few network RTTs=E2=80=9D: No ambiguity in decoding means that the packets need to have been played = out, so the codec state for that PT can be discarded. Some systems can = have large (multi-second) playout buffers.=20 Any packets referring to the old PT also need to be gone. Formats like = RFC 6354 allow large offsets between streams, referenced by PT (the = example in Section 5 has a 5.1 second offset).=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_DA40CA53-019F-45EF-BE26-4B6DF4CE0A19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 22 Feb 2016, at 19:52, Roman Shpount <roman@telurix.com> = wrote:
=E2=80=A6
One = thing that bothered me here is that PT cannot be reused for the duration = of the session. It is probably safe to reuse the PT after session = modification if PT is no longer used. I always felt that dynamic PT = reuse criteria were much stricter then realistically possible or = needed. 
=E2=80=A6
I think the most important = criteria here is that there should be no ambiguity regarding how an RTP = packet with particular PT should be decoded. If it is guaranteed that = there are no packets sent between Alice and Bob with PT 111 over some = reasonable time interval (couple of network round trip times), then PT = 111 can be safely reused. If, in this scenario Bob's end point knows = that it was not sending anything with payload 111 recently, then it can = safely reuse this payload. Alice could not be sending anything with = payload 111 since Bob did not accept it previously. On the other hand, = Bob must not reuse PT 100 for, let's say, CN, since there are packets = with this payload in flight and this will create decoding ambiguity. To = conclude, an end point should be able to safely reuse any PT that it is = not currently accepting or was not sending or accepting for at least a = few network round trip = intervals.

No objection in principle, but it=E2=80=99s not as = simple as =E2=80=9Ca few network RTTs=E2=80=9D:

No ambiguity in decoding means that the packets = need to have been played out, so the codec state for that PT can be = discarded. Some systems can have large (multi-second) playout = buffers. 

Any packets referring = to the old PT also need to be gone. Formats like RFC 6354 allow = large offsets between streams, referenced by PT (the example in Section = 5 has a 5.1 second offset). 



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



= --Apple-Mail=_DA40CA53-019F-45EF-BE26-4B6DF4CE0A19-- From nobody Tue Feb 23 04:10: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 462CA1B310D for ; Tue, 23 Feb 2016 04:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLyiE3_g8J2j for ; Tue, 23 Feb 2016 04:10:45 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A89151B4292 for ; Tue, 23 Feb 2016 04:04:28 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9C1386C136328; Tue, 23 Feb 2016 12:04:24 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1NC4Oie018945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Feb 2016 12:04:24 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1NC40S7014155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Feb 2016 13:04:22 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.98]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 23 Feb 2016 13:04:12 +0100 From: "Drage, Keith (Nokia - GB)" To: EXT Colin Perkins , Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAA9P4A///VdXA= Date: Tue, 23 Feb 2016 12:04:12 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE903FF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> In-Reply-To: <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADE903FFFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 12:10:50 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADE903FFFR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IGhlcmUgd2UgYXJlIGRpc2N1c3Npbmcgb2ZmZXIgLyBhbnN3ZXIsIGJ1dCB3 ZSBtdXN0IGFsc28gcmVtZW1iZXIgdGhhdCBhbnkgcnVsZXMgbXVzdCBiZSBjb25zaXN0ZW50IHdp dGggZGVjbGFyYXRpdmUgdXNhZ2VzIG9mIFNEUC4NCg0KSXQgbWF5IGFsc28gYmUgdGhhdCBzb21l IG9mIHRob3NlIGRlY2xhcmF0aXZlIHJ1bGVzIGFyZSBhbHNvIGluaGVyaXRlZCBieSBvZmZlciBh bnN3ZXIsIHN1Y2ggYXMgdGhlIGFuc3dlciB0byB0aGUgcXVlc3Rpb24gYXMgdG8gd2hldGhlciB0 aGUgcmVxdWlyZW1lbnQgdG8gcmVtZW1iZXIgcGF5bG9hZCB0eXBlIHVzYWdlIChhbmQgd2hldGhl ciB0aGFuIGFwcGxpZXMgdG8gYm90aCBvZmZlcnMgYW5kIGFuc3dlcnMsIG9yIGluZGVwZW5kZW50 bHkgdG8gZWFjaCkuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KRnJvbTogbW11c2ljIFttYWlsdG86 bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFWFQgQ29saW4gUGVya2lucw0K U2VudDogMjMgRmVicnVhcnkgMjAxNiAxMDoyOQ0KVG86IFJvbWFuIFNocG91bnQNCkNjOiBtbXVz aWNAaWV0Zi5vcmc7IFBhdWwgS3l6aXZhdDsgQ2hyaXN0ZXIgSG9sbWJlcmcNClN1YmplY3Q6IFJl OiBbTU1VU0lDXSBPZmZlci9BbnN3ZXIgUFQgUXVlc3Rpb25zDQoNCk9uIDIyIEZlYiAyMDE2LCBh dCAxOTo1MiwgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRl bHVyaXguY29tPj4gd3JvdGU6DQrigKYNCg0KT25lIHRoaW5nIHRoYXQgYm90aGVyZWQgbWUgaGVy ZSBpcyB0aGF0IFBUIGNhbm5vdCBiZSByZXVzZWQgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgc2Vz c2lvbi4gSXQgaXMgcHJvYmFibHkgc2FmZSB0byByZXVzZSB0aGUgUFQgYWZ0ZXIgc2Vzc2lvbiBt b2RpZmljYXRpb24gaWYgUFQgaXMgbm8gbG9uZ2VyIHVzZWQuIEkgYWx3YXlzIGZlbHQgdGhhdCBk eW5hbWljIFBUIHJldXNlIGNyaXRlcmlhIHdlcmUgbXVjaCBzdHJpY3RlciB0aGVuIHJlYWxpc3Rp Y2FsbHkgcG9zc2libGUgb3IgbmVlZGVkLg0K4oCmDQoNCkkgdGhpbmsgdGhlIG1vc3QgaW1wb3J0 YW50IGNyaXRlcmlhIGhlcmUgaXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgbm8gYW1iaWd1aXR5IHJl Z2FyZGluZyBob3cgYW4gUlRQIHBhY2tldCB3aXRoIHBhcnRpY3VsYXIgUFQgc2hvdWxkIGJlIGRl Y29kZWQuIElmIGl0IGlzIGd1YXJhbnRlZWQgdGhhdCB0aGVyZSBhcmUgbm8gcGFja2V0cyBzZW50 IGJldHdlZW4gQWxpY2UgYW5kIEJvYiB3aXRoIFBUIDExMSBvdmVyIHNvbWUgcmVhc29uYWJsZSB0 aW1lIGludGVydmFsIChjb3VwbGUgb2YgbmV0d29yayByb3VuZCB0cmlwIHRpbWVzKSwgdGhlbiBQ VCAxMTEgY2FuIGJlIHNhZmVseSByZXVzZWQuIElmLCBpbiB0aGlzIHNjZW5hcmlvIEJvYidzIGVu ZCBwb2ludCBrbm93cyB0aGF0IGl0IHdhcyBub3Qgc2VuZGluZyBhbnl0aGluZyB3aXRoIHBheWxv YWQgMTExIHJlY2VudGx5LCB0aGVuIGl0IGNhbiBzYWZlbHkgcmV1c2UgdGhpcyBwYXlsb2FkLiBB bGljZSBjb3VsZCBub3QgYmUgc2VuZGluZyBhbnl0aGluZyB3aXRoIHBheWxvYWQgMTExIHNpbmNl IEJvYiBkaWQgbm90IGFjY2VwdCBpdCBwcmV2aW91c2x5LiBPbiB0aGUgb3RoZXIgaGFuZCwgQm9i IG11c3Qgbm90IHJldXNlIFBUIDEwMCBmb3IsIGxldCdzIHNheSwgQ04sIHNpbmNlIHRoZXJlIGFy ZSBwYWNrZXRzIHdpdGggdGhpcyBwYXlsb2FkIGluIGZsaWdodCBhbmQgdGhpcyB3aWxsIGNyZWF0 ZSBkZWNvZGluZyBhbWJpZ3VpdHkuIFRvIGNvbmNsdWRlLCBhbiBlbmQgcG9pbnQgc2hvdWxkIGJl IGFibGUgdG8gc2FmZWx5IHJldXNlIGFueSBQVCB0aGF0IGl0IGlzIG5vdCBjdXJyZW50bHkgYWNj ZXB0aW5nIG9yIHdhcyBub3Qgc2VuZGluZyBvciBhY2NlcHRpbmcgZm9yIGF0IGxlYXN0IGEgZmV3 IG5ldHdvcmsgcm91bmQgdHJpcCBpbnRlcnZhbHMuDQoNCk5vIG9iamVjdGlvbiBpbiBwcmluY2lw bGUsIGJ1dCBpdOKAmXMgbm90IGFzIHNpbXBsZSBhcyDigJxhIGZldyBuZXR3b3JrIFJUVHPigJ06 DQpObyBhbWJpZ3VpdHkgaW4gZGVjb2RpbmcgbWVhbnMgdGhhdCB0aGUgcGFja2V0cyBuZWVkIHRv IGhhdmUgYmVlbiBwbGF5ZWQgb3V0LCBzbyB0aGUgY29kZWMgc3RhdGUgZm9yIHRoYXQgUFQgY2Fu IGJlIGRpc2NhcmRlZC4gU29tZSBzeXN0ZW1zIGNhbiBoYXZlIGxhcmdlIChtdWx0aS1zZWNvbmQp IHBsYXlvdXQgYnVmZmVycy4NCg0KQW55IHBhY2tldHMgcmVmZXJyaW5nIHRvIHRoZSBvbGQgUFQg YWxzbyBuZWVkIHRvIGJlIGdvbmUuIEZvcm1hdHMgbGlrZSBSRkMgNjM1NCBhbGxvdyBsYXJnZSBv ZmZzZXRzIGJldHdlZW4gc3RyZWFtcywgcmVmZXJlbmNlZCBieSBQVCAodGhlIGV4YW1wbGUgaW4g U2VjdGlvbiA1IGhhcyBhIDUuMSBzZWNvbmQgb2Zmc2V0KS4NCg0KDQoNCi0tDQpDb2xpbiBQZXJr aW5zDQpodHRwczovL2NzcGVya2lucy5vcmcvDQoNCg0KDQo= --_000_949EF20990823C4C85C18D59AA11AD8BADE903FFFR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTHVjaWRhIFNhbnMg VHlwZXdyaXRlciI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBoZXJlIHdlIGFyZSBkaXNjdXNz aW5nIG9mZmVyIC8gYW5zd2VyLCBidXQgd2UgbXVzdCBhbHNvIHJlbWVtYmVyIHRoYXQgYW55IHJ1 bGVzIG11c3QgYmUgY29uc2lzdGVudCB3aXRoIGRlY2xhcmF0aXZlIHVzYWdlcyBvZiBTRFAuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JdCBtYXkgYWxzbyBiZSB0aGF0IHNvbWUgb2YgdGhvc2UgZGVjbGFyYXRpdmUgcnVs ZXMgYXJlIGFsc28gaW5oZXJpdGVkIGJ5IG9mZmVyIGFuc3dlciwgc3VjaCBhcyB0aGUgYW5zd2Vy IHRvIHRoZSBxdWVzdGlvbiBhcyB0byB3aGV0aGVyIHRoZSByZXF1aXJlbWVudCB0bw0KIHJlbWVt YmVyIHBheWxvYWQgdHlwZSB1c2FnZSAoYW5kIHdoZXRoZXIgdGhhbiBhcHBsaWVzIHRvIGJvdGgg b2ZmZXJzIGFuZCBhbnN3ZXJzLCBvciBpbmRlcGVuZGVudGx5IHRvIGVhY2gpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+S2VpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtbXVzaWMgW21haWx0 bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RVhUIENvbGlu IFBlcmtpbnM8YnI+DQo8Yj5TZW50OjwvYj4gMjMgRmVicnVhcnkgMjAxNiAxMDoyOTxicj4NCjxi PlRvOjwvYj4gUm9tYW4gU2hwb3VudDxicj4NCjxiPkNjOjwvYj4gbW11c2ljQGlldGYub3JnOyBQ YXVsIEt5eml2YXQ7IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb TU1VU0lDXSBPZmZlci9BbnN3ZXIgUFQgUXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIyIEZlYiAyMDE2LCBh dCAxOTo1MiwgUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igKY8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T25lIHRoaW5nIHRoYXQgYm90aGVyZWQgbWUgaGVyZSBpcyB0aGF0IFBU IGNhbm5vdCBiZSByZXVzZWQgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgc2Vzc2lvbi4gSXQgaXMg cHJvYmFibHkgc2FmZSB0byByZXVzZSB0aGUgUFQgYWZ0ZXIgc2Vzc2lvbiBtb2RpZmljYXRpb24g aWYgUFQgaXMgbm8gbG9uZ2VyIHVzZWQuIEkgYWx3YXlzIGZlbHQgdGhhdCBkeW5hbWljIFBUIHJl dXNlIGNyaXRlcmlhIHdlcmUgbXVjaA0KIHN0cmljdGVyIHRoZW4gcmVhbGlzdGljYWxseSBwb3Nz aWJsZSBvciBuZWVkZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCmPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIG1vc3QgaW1wb3J0YW50IGNyaXRlcmlhIGhlcmUg aXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgbm8gYW1iaWd1aXR5IHJlZ2FyZGluZyBob3cgYW4gUlRQ IHBhY2tldCB3aXRoIHBhcnRpY3VsYXIgUFQgc2hvdWxkIGJlIGRlY29kZWQuIElmIGl0IGlzIGd1 YXJhbnRlZWQgdGhhdCB0aGVyZSBhcmUgbm8gcGFja2V0cyBzZW50IGJldHdlZW4gQWxpY2UgYW5k IEJvYiB3aXRoIFBUIDExMSBvdmVyIHNvbWUNCiByZWFzb25hYmxlIHRpbWUgaW50ZXJ2YWwgKGNv dXBsZSBvZiBuZXR3b3JrIHJvdW5kIHRyaXAgdGltZXMpLCB0aGVuIFBUIDExMSBjYW4gYmUgc2Fm ZWx5IHJldXNlZC4gSWYsIGluIHRoaXMgc2NlbmFyaW8gQm9iJ3MgZW5kIHBvaW50IGtub3dzIHRo YXQgaXQgd2FzIG5vdCBzZW5kaW5nIGFueXRoaW5nIHdpdGggcGF5bG9hZCAxMTEgcmVjZW50bHks IHRoZW4gaXQgY2FuIHNhZmVseSByZXVzZSB0aGlzIHBheWxvYWQuIEFsaWNlIGNvdWxkIG5vdCBi ZQ0KIHNlbmRpbmcgYW55dGhpbmcgd2l0aCBwYXlsb2FkIDExMSBzaW5jZSBCb2IgZGlkIG5vdCBh Y2NlcHQgaXQgcHJldmlvdXNseS4gT24gdGhlIG90aGVyIGhhbmQsIEJvYiBtdXN0IG5vdCByZXVz ZSBQVCAxMDAgZm9yLCBsZXQncyBzYXksIENOLCBzaW5jZSB0aGVyZSBhcmUgcGFja2V0cyB3aXRo IHRoaXMgcGF5bG9hZCBpbiBmbGlnaHQgYW5kIHRoaXMgd2lsbCBjcmVhdGUgZGVjb2RpbmcgYW1i aWd1aXR5LiBUbyBjb25jbHVkZSwgYW4gZW5kIHBvaW50DQogc2hvdWxkIGJlIGFibGUgdG8gc2Fm ZWx5IHJldXNlIGFueSBQVCB0aGF0IGl0IGlzIG5vdCBjdXJyZW50bHkgYWNjZXB0aW5nIG9yIHdh cyBub3Qgc2VuZGluZyBvciBhY2NlcHRpbmcgZm9yIGF0IGxlYXN0IGEgZmV3IG5ldHdvcmsgcm91 bmQgdHJpcCBpbnRlcnZhbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPk5vIG9iamVjdGlvbiBpbiBwcmluY2lwbGUsIGJ1dCBpdOKAmXMgbm90IGFz IHNpbXBsZSBhcyDigJxhIGZldyBuZXR3b3JrIFJUVHPigJ06PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBhbWJpZ3VpdHkgaW4gZGVjb2Rpbmcg bWVhbnMgdGhhdCB0aGUgcGFja2V0cyBuZWVkIHRvIGhhdmUgYmVlbiBwbGF5ZWQgb3V0LCBzbyB0 aGUgY29kZWMgc3RhdGUgZm9yIHRoYXQgUFQgY2FuIGJlIGRpc2NhcmRlZC4gU29tZSBzeXN0ZW1z IGNhbiBoYXZlIGxhcmdlIChtdWx0aS1zZWNvbmQpIHBsYXlvdXQgYnVmZmVycy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55IHBh Y2tldHMgcmVmZXJyaW5nIHRvIHRoZSBvbGQgUFQgYWxzbyBuZWVkIHRvIGJlIGdvbmUuIEZvcm1h dHMgbGlrZSZuYnNwO1JGQyA2MzU0IGFsbG93IGxhcmdlIG9mZnNldHMgYmV0d2VlbiBzdHJlYW1z LCByZWZlcmVuY2VkIGJ5IFBUICh0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIDUgaGFzIGEgNS4xIHNl Y29uZCBvZmZzZXQpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXImcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIFNhbnMgVHlwZXdyaXRlciZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXImcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNvbGluIFBlcmtpbnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXImcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vY3NwZXJr aW5zLm9yZy8iPmh0dHBzOi8vY3NwZXJraW5zLm9yZy88L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgU2FucyBUeXBld3JpdGVyJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_949EF20990823C4C85C18D59AA11AD8BADE903FFFR712WXCHMBA11z_-- From nobody Tue Feb 23 04:11: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 396491A9064 for ; Tue, 23 Feb 2016 04:11:45 -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 wLbNiFiczeaR for ; Tue, 23 Feb 2016 04:11:43 -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 DC1B71A00FF for ; Tue, 23 Feb 2016 04:11:42 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-6a-56cc4c7c4df9 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0B.A0.15637.C7C4CC65; Tue, 23 Feb 2016 13:11:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 13:11:40 +0100 From: Christer Holmberg To: Roman Shpount , "DOLLY, MARTIN C" Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAAB/sA///p1yCAAD3OAIAABTKA//8UCXA= Date: Tue, 23 Feb 2016 12:11:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3A048@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E3A048ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7sW6tz5kwgx+tbBaHHjxlt5i6/DGL xYoNB1gtZlyYyuzA4vH3/Qcmj5f9cxg9liz5yeRxa0pBAEsUl01Kak5mWWqRvl0CV8a32dNY C27ZV/S1/mBrYPxi28XIySEhYCIxb/INdghbTOLCvfVsXYxcHEIChxkl7hyfyQLhLGaUWLPh N2MXIwcHm4CFRPc/bZAGEQFPiT9b5rGA2MwCvhIvF3xhBrGFBfQl3i86wg5RYyCx9+UBKDtJ omXiHkYQm0VAVeLNo/9gvbxAvU/6j4PFhQQaWSRW7eAGsTkFAiVez9sOFmcEOu77qTVMELvE JW49mc8EcbSAxJI955khbFGJl4//sULYShKLbn+Gqs+X6P/8gglil6DEyZlPWCYwis5CMmoW krJZSMpmAX3MLKApsX6XPkSJosSU7ofsELaGROucuezI4gsY2VcxihanFiflphsZ66UWZSYX F+fn6eWllmxiBMbkwS2/VXcwXn7jeIhRgINRiYd3Q9TpMCHWxLLiytxDjBIczEoivNd1zoQJ 8aYkVlalFuXHF5XmpBYfYpTmYFES513jvD5MSCA9sSQ1OzW1ILUIJsvEwSnVwNiUvu8ac1wb Q/q36BXlz7dXlckF+O+54vZQavF3M5kdv98ab3sz/4uxjHo1g+Y/doMPN6rOz2lwSFE8XyLJ tP7SF5YQb9733nN0y+//aH3lsvLEW5fcnJfTNkWcCOsvOui3viHh4qFqb5GW/RUal6sYdR5y LLuo+HiuBbPu/dcFk+xMUg6sy1NiKc5INNRiLipOBAB6mYqxxQIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 12:11:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E3A048ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5DYW4geW91IHByb3ZpZGUgYW55IG1vcmUgZGV0YWlscyBhYm91dCBob3cgZXhhY3Rs eSB0aGluZ3MgYXJlIGZhaWxpbmcgYW5kIHBvdGVudGlhbGx5IHdoYXQgZXF1aXBtZW50IGlzIGFm ZmVjdGVkPw0KDQpUaGUgdXBkYXRlZCBvZmZlciBpcyByZWplY3RlZCAod2l0aCBhIDQ4OCByZXNw b25zZSBjb2RlLCBhZmFpaykuDQoNCj5JIGJlbGlldmUgcGFydCBvZiB0aGUgZWZmb3J0IGluIGZp eGluZyB0aGlzIGlzc3VlIHdvdWxkIGJlIHRyeWluZyB0byBkZXRlcm1pbmUgd2hvIHdpbGwgYmUg bmVnYXRpdmVseSBhZmZlY3RlZCBieSB0aGUgZml4IGFuZCBob3cgdG8gbWluaW1pemUgdGhlIGRp c3J1cHRpb24uDQoNCkluIHRoaXMgcGFydGljdWxhciBjYXNlLCBvbmUgcGFydCB3aWxsIG9idmlv dXNseSBiZSDigJxuZWdhdGl2ZWx5IGFmZmVjdGVk4oCdIChyZWFkOiB3aWxsIGhhdmUgdG8gdXBk YXRlIHRoZWlyIGNvZGUpLiBCdXQsIGFzIGxvbmcgYXMgdGhlIHJ1bGVzIGFyZSB1bmNsZWFyLCBh bmQgZGlmZmVyZW50IHBhcnRpZXMgaGF2ZSBkaWZmZXJlbnQgb3BpbmlvbnMgb24gd2hvIGlzIHJp Z2h0IGFuZCB3aG8gaXQgd3JvbmcsIG5vYm9keSB3aWxsIHVwZGF0ZSB0aGVpciBjb2RlLiBUaGF0 4oCZcyBwZXJoYXBzIGdvb2QgZm9yIHRoZSBTQkMgdmVuZG9ycywgYmVjYXVzZSB0aGUgb25seSBz b2x1dGlvbiBtYXkgYmUgZGVwbG95aW5nIGFuIFNCQyDigJMganVzdCBmb3IgZml4aW5nIHRoZSBQ VCB2YWx1ZXMoISkuDQoNCkJ1dCwgaW4gdGhlIGxvbmcgdGVybSwgaGF2aW5nIGNsZWFyIHByb2Nl ZHVyZXMgaXMgZ29vZCBmb3IgZXZlcnlvbmUgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K DQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37E3A048ESESSMB209erics_ 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 b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0NhbiB5b3Ug cHJvdmlkZSBhbnkgbW9yZSBkZXRhaWxzIGFib3V0IGhvdyBleGFjdGx5IHRoaW5ncyBhcmUgZmFp bGluZyBhbmQgcG90ZW50aWFsbHkgd2hhdCBlcXVpcG1lbnQgaXMgYWZmZWN0ZWQ/PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB1cGRhdGVkIG9mZmVy IGlzIHJlamVjdGVkICh3aXRoIGEgNDg4IHJlc3BvbnNlIGNvZGUsIGFmYWlrKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0O0kgYmVsaWV2ZSBwYXJ0IG9mIHRoZSBlZmZvcnQgaW4gZml4aW5nIHRoaXMgaXNz dWUgd291bGQgYmUgdHJ5aW5nIHRvIGRldGVybWluZSB3aG8gd2lsbCBiZSBuZWdhdGl2ZWx5IGFm ZmVjdGVkIGJ5IHRoZSBmaXggYW5kIGhvdyB0byBtaW5pbWl6ZSB0aGUgZGlzcnVwdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIG9uZSBwYXJ0IHdpbGwgb2J2aW91 c2x5IGJlIOKAnG5lZ2F0aXZlbHkgYWZmZWN0ZWTigJ0gKHJlYWQ6IHdpbGwgaGF2ZSB0byB1cGRh dGUgdGhlaXIgY29kZSkuIEJ1dCwgYXMgbG9uZyBhcyB0aGUgcnVsZXMgYXJlIHVuY2xlYXIsIGFu ZCBkaWZmZXJlbnQgcGFydGllcw0KIGhhdmUgZGlmZmVyZW50IG9waW5pb25zIG9uIHdobyBpcyBy aWdodCBhbmQgd2hvIGl0IHdyb25nLCBub2JvZHkgd2lsbCB1cGRhdGUgdGhlaXIgY29kZS4gVGhh dOKAmXMgcGVyaGFwcyBnb29kIGZvciB0aGUgU0JDIHZlbmRvcnMsIGJlY2F1c2UgdGhlIG9ubHkg c29sdXRpb24gbWF5IGJlIGRlcGxveWluZyBhbiBTQkMg4oCTIGp1c3QgZm9yIGZpeGluZyB0aGUg UFQgdmFsdWVzKCEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CdXQsIGluIHRoZSBsb25nIHRlcm0sIGhhdmlu ZyBjbGVhciBwcm9jZWR1cmVzIGlzIGdvb2QgZm9yIGV2ZXJ5b25lIDopPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3Vu dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37E3A048ESESSMB209erics_-- From nobody Tue Feb 23 05:29: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 27CAE1B2CD0 for ; Tue, 23 Feb 2016 05:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 g5XkFmcfXtzX for ; Tue, 23 Feb 2016 05:29:04 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 309181B2CC7 for ; Tue, 23 Feb 2016 05:29:04 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id AF9DDE79FFEE7; Tue, 23 Feb 2016 13:28:59 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1NDT1kv015002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Feb 2016 13:29:02 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1NDT1qm030169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Feb 2016 14:29:01 +0100 Received: from [149.204.68.190] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Feb 2016 14:29:00 +0100 References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> <56C6156C.2070308@cisco.com> <56C71EF3.6040208@alcatel-lucent.com> <56C74FDE.4040902@cisco.com> From: Juergen Stoetzer-Bradler To: Flemming Andreasen , Paul Kyzivat , DRAGE Keith , "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" Message-ID: <56CC5E9B.5060307@alcatel-lucent.com> Date: Tue, 23 Feb 2016 14:28:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C74FDE.4040902@cisco.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [135.239.27.40] 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: Tue, 23 Feb 2016 13:29:10 -0000 Flemming, Thanks for further feedback. Regarding your comments: > So far so good, however the case I had in mind is one where the new att= ribute would apply to one=20 > or more existing subprotocols. and > While that is certainly a valid use case, I wasn't thinking of restrict= ing it to that and hence=20 > the request for an actual sub-registry for each of these subprotocols t= o register attributes that=20 > can be used with each of them (some attributes may apply to multiple). = Ok, as per my understanding such a new attribute would be introduced in a= (let's assume) future=20 document. I think that such a future document should describe the new att= ribute's semantic with=20 respect to all protocols for which it is intended to be used. And if one = of these protocols can be=20 transported over data channels, and if the new attribute's meaning then a= lso has data channel=20 specific aspects, this future document should also describe those aspects= =2E If this new attribute is=20 then added to the IANA SDP attribute registry (presumably as media level = only or media and session=20 level attribute), then this document could be found when searching for th= e new attribute. I am not yet sure I fully understand how such subprotocol specific regist= ries could be used. Right=20 now there are already drafts describing MSRP, BFCP and T.140 as data chan= nel subprotocols. Do you=20 think IANA registry tables for each of these subprotocols should be creat= ed (and in future for any=20 further protocol, which might be used as data channel subprotocol)? Where then a new attribute might be listed in multiple of these subprotoc= ol specific registries,=20 depending on which subprotocol it might be used for? And all already existing attributes, which might also be used for a data = channel subprotocol - do=20 you think that these should also be added to such subprotocol specific re= gistry tables? Coming back to MSRP as an example - RFC 5547 defines several file transfe= r related attributes.=20 Conceivably, a future document could define another file transfer protoco= l unequal to MSRP (and=20 based on data channel transport, or based on a transport protocol unequal= to data channel). And that=20 potential future document might then describe how (some of) the file tran= sfer related SDP attributes=20 might be re-used for this new file transfer protocol. Would you then expe= ct these file transfer=20 related SDP attributes to be added to such a new registry associated with= the new file transfer=20 protocol? Also if data channel transport of this potential new file trans= fer protocol were not=20 defined in that assumed future document? Right now I'm not sure if this topic is only data channel specific. E.g. = the a=3Dsetup attribute was=20 originally introduced in RFC 4145 for TCP connection negotiation. Later o= n, this attribute was=20 reused for TLS connection negotiation (RFC 4572) and DTLS association neg= otiation (RFC 5763,=20 draft-ietf-mmusic-sctp-sdp, draft-ietf-mmusic-dtls-sdp). As far as I see = the IANA SDP parameters=20 registry for the a=3Dsetup attribute only refers to RFC 4145. And the two= sctp-sdp and dtls-sdp drafts=20 don't seem to request updating this registry. However, all these document= s have setup attribute=20 related texts describing the extended semantics of the setup attribute. Somebody seeing an SDP offer like the UDP/DTLS/SCTP related one in sectio= n 13.1 of=20 draft-ietf-mmusic-sctp-sdp-15, when looking for the setup attribute's usa= ge in this SDP offer and=20 when therefore searching the related reference in the IANA SDP attribute = registry, would only find=20 the reference to RFC 4145. However, he/she could look up the UDP/DTLS/SCT= P m-line proto value in the=20 IANA SDP proto registry, and there would find the reference to the future= RFC of=20 draft-ietf-mmusic-sctp-sdp, where the semantic of the setup attribute wit= hin this SDP offer instance=20 is specified. Somebody seeing an SDP offer like the DTLS-SRTP related one in section 7.= 1 of RFC 5763, again when=20 trying to find the semantic of the setup attribute in this SDP offer, wou= ld similarly find the=20 reference to RFC 4145. When searching the proto registry for UDP/TLS/RTP/= SAVP he/she would find the=20 reference to RFC 5764. RFC 5764 does not mention the setup attribute at a= ll, but RFC 5763 does and=20 describes its usage in the DTLS-SRTP case. [But then it might not be clea= r if this setup attribute=20 is used in the original sense of RFCs 5763 / 5764, or with the modified s= emantic described in=20 draft-ietf-mmusic-dtls-sdp (which excludes value 'holdconn').] In these cases, do you think that subprotocol (TLS and DTLS as "subprotoc= ols" of TCP and UDP)=20 specific sub-registries should be created? And if yes, how do you envisio= n those would be used? Thanks, Juergen On 19.02.2016 18:24, EXT Flemming Andreasen wrote: > > > On 2/19/16 8:56 AM, Juergen Stoetzer-Bradler wrote: >> Flemming, >> >> Regarding >>> Sounds reasonable with the caveat that you may have attributes define= d for use with a particular=20 >>> sub-protocol outside the subprotocol draft itself (e.g. because such = an attribute was either=20 >>> defined subsequently or its use with a specific subprotocol is define= d subsequently). If so, we=20 >>> would need an IANA registry structure (under SDP) that for each subpr= otocol defines the set of=20 >>> attributes that have been defined with specific semantics for that su= bprotocol.=20 >> >> Let's assume a future document defines how to establish MSRP sessions = over a transport protocol=20 >> unequal to TCP, TLS, or data channel, and that this document also defi= nes a new MSRP related=20 >> attribute, whose semantic is only defined for this new transport case = (like a maximal MSRP chunk=20 >> size specific for the new transport). I assume that this future docume= nt would request to add=20 >> this new attribute to one of the existing IANA SDP attribute tables (a= ssumingly to the "att-field=20 >> (media level only)" table). > So far so good, however the case I had in mind is one where the new att= ribute would apply to one=20 > or more existing subprotocols . >> Let's further assume that an implementation creates an SDP offer for a= n MSRP session over a data=20 >> channel and adds this new attribute as dcsa embedded MSRP subprotocol = attribute (for whatever=20 >> reasons). >> >> Somebody seeing and inspecting this SDP offer could use the dcmap attr= ibute's subprotocol value=20 >> "MSRP" to get a reference to the msrp-usage-data-channel document. Tha= t document would not=20 >> mention that new attribute at all. The next step could then be to cons= ult the IANA SDP tables,=20 >> and there this new attribute would be found together with a reference = to this future document. >> As assumingly this new MSRP related attribute would only be defined fo= r this new transport, > While that is certainly a valid use case, I wasn't thinking of restrict= ing it to that and hence=20 > the request for an actual sub-registry for each of these subprotocols t= o register attributes that=20 > can be used with each of them (some attributes may apply to multiple). > >> I think this new attribute should then be ignored by the recipient of = this SDP offer. >> Section 5.2.5 of most recent draft-ietf-mmusic-data-channel-sdpneg-08 = now contains two related=20 >> recommendations: >> >> 'SDP offer or answer has an "a=3Ddcsa" attribute, whose subprotocol at= tribute is unknown. >> * The receiver of such an SDP offer or answer SHOULD ignore this ent= ire "a=3Ddcsa" attribute line. >> >> SDP offer or answer has an "a=3Ddcsa" attribute, whose subprotocol att= ribute is known, but whose=20 >> subprotocol attribute semantic is not known for the data channel trans= port case. >> * The receiver of such an SDP offer or answer SHOULD ignore this ent= ire "a=3Ddcsa" attribute line.' >> >> Would these recommendations address the case you are describing? >> > They only address the case(s) partally per the above. > > Thanks > > -- Flemming > > >> Thanks, >> Juergen >> >> >> >> On 18.02.2016 20:03, EXT Flemming Andreasen wrote: >>> >>> >>> On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: >>>> Flemming, >>>> >>>> Regarding >>>>> It would probably simplify the overall SDP negotiation part, but I = don't know if it would=20 >>>>> constrain the way data channels were envisioned to be used.=20 >>>> >>>> On Friday Paul mentioned in his email two potential use cases, where= no subprotocol identifiers=20 >>>> might be added to a data channel's dcmap attribute. In my last email= I hadn't thought of such=20 >>>> cases. If we don't want to exclude such cases, then requiring the su= bprotocol ids always to be=20 >>>> present might indeed be too restrictive. >>>> >>>> Regarding >>>>> Ok. Going back to discussion between Paul and I, do you believe tha= t in for an attribute to be=20 >>>>> encapsulated in dcsa, the attribute MUST have been explicitly defin= e to support this (Paul's=20 >>>>> suggestion below) or do you believe that this is overly constrainin= g, and if so, how shoud we=20 >>>>> relax it ?=20 >>>> >>>> I now think that the sdpneg draft might recommend SDP offerers and a= nswerers to always add a=20 >>>> subprotocol identifier to a data channel's dcmap attribute if dcsa e= mbedded attributes are also=20 >>>> negotiated for the data channel's subprotocol. I also think we could= explicitly add text to=20 >>>> sdpneg saying that subprotocol identifiers should be added to the IA= NA Websocket (and in future=20 >>>> combined data channel) registry. And that this registration should b= e done via a document,=20 >>>> which then explicitly describes the usages and semantics of dcsa emb= edded subprotocol=20 >>>> attributes, _if_ those usages or semantics deviate from cases, where= these attributes are not=20 >>>> dcsa encapsulated. I think that in those cases, where the usage and = meaning of an attribute=20 >>>> (always related to the data channel's subprotocol) does not deviate = from the non-dcsa=20 >>>> encapsulated use cases, such an attribute may not explicitly need to= be described for data=20 >>>> channel usage. But I think it might be helpful to explicitly say so = in the sdpneg draft. >>>> >>>> Somebody inspecting an SDP offer or answer, which was generated by a= n implementation following=20 >>>> these two recommendations (and which hence contains an IANA register= ed subprotocol id if it=20 >>>> contains any dcsa embedded attributes), could then refer to that IAN= A table, would then find=20 >>>> the reference to the document, which defines this subprotocol id for= data channel usage, and=20 >>>> there could check if any of the dcsa embedded attributes has a data = channel specific semantic.=20 >>>> If yes, that specific semantic would be described in that document. = If such a specific semantic=20 >>>> were not described in that document, then the default usage and sema= ntic of the attribute would=20 >>>> apply also to that data channel transport case. >>>> >>> Sounds reasonable with the caveat that you may have attributes define= d for use with a particular=20 >>> sub-protocol outside the subprotocol draft itself (e.g. because such = an attribute was either=20 >>> defined subsequently or its use with a specific subprotocol is define= d subsequently). If so, we=20 >>> would need an IANA registry structure (under SDP) that for each subpr= otocol defines the set of=20 >>> attributes that have been defined with specific semantics for that su= bprotocol. >>> >>> >>>> But in that context I'd have an IANA table related question. >>>> A certain subprotocol might be defined for Websocket usage as well a= s for data channel usage.=20 >>>> MSRP is already such a case, where draft-ietf-mmusic-msrp-usage-data= -channel defines how to use=20 >>>> MSRP over data channels, and where draft-pd-dispatch-msrp-websocket = defines how to use MSRP=20 >>>> over Websockets. >>>> Would the IANA WebSocket Subprotocol Name Registry on=20 >>>> http://www.iana.org/assignments/websocket/websocket.xml then contain= two MSRP related rows? Or=20 >>>> just one row containing references to both the Websocket and data ch= annel documents? >>>> Should we add related text to the IANA registration section of the s= dpneg draft? >>> See above. >>> >>> Thanks >>> >>> -- Flemming >>>> >>>> Thanks, >>>> Juergen >>>> >>>> >>>> On 12.02.2016 15:52, EXT Flemming Andreasen wrote: >>>>> >>>>> >>>>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>>>> Flemming, Paul, >>>>>> >>>>>> The current a=3Ddcmap related text in draft-ietf-mmusic-data-chann= el-sdpneg doesn't require=20 >>>>>> that the 'subprotocol' parameter must always be present - rather i= t is specified as an=20 >>>>>> optional parameter. Thus, current sdpneg text would allow to creat= e an SDP offer for a data=20 >>>>>> channel, which contains one a=3Ddcmap attribute and potentially mu= ltiple a=3Ddcsa attributes=20 >>>>>> without the subprotocol actually being given. Based on this discus= sion I am wondering if the=20 >>>>>> subprotocol parameter should actually be mandatory. >>>>>> >>>>> It would probably simplify the overall SDP negotiation part, but I = don't know if it would=20 >>>>> constrain the way data channels were envisioned to be used. >>>>> >>>>> >>>>>> In the specific case of MSRP, the msrp-usage-data-channel draft sa= ys in 5.1.1.1 that the=20 >>>>>> dcmap attribute includes the label and subprotocol parameters. The= current text could=20 >>>>>> possible be made more explicit by saying that the 'subprotocol=3D"= MSRP"' parameter must always=20 >>>>>> be present. >>>>>> Have just submitted version 04 of the msrp-usage-data-channel draf= t, which proposes to add=20 >>>>>> subprotocol identifier "MSRP" to the WebSocket Subprotocol Name re= gistry. This registry would=20 >>>>>> then associate subprotocol id "MSRP" with the msrp-usage-data-chan= nel document. >>>>>> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcsa= attribute are specified. And=20 >>>>>> there the MSRP specific SDP attributes, which can be dcsa embedded= , are described. >>>>>> 'setup' is an attribute, whose semantic changes when being dcsa em= bedded and associated with=20 >>>>>> subprotocol MSRP, as compared to the meaning of an "a=3Dsetup" med= ia level attribute of a=20 >>>>>> TCP/MSRP m-line. Hence these semantical differences are explicitly= addressed in the=20 >>>>>> msrp-usage-data-channel draft. >>>>>> >>>>>> Regarding sdpneg, I also think that the current text in sdpneg see= ms to be sufficient=20 >>>>>> regarding the usage of dcsa encapsulated SDP attributes as being b= ound to the data channel's=20 >>>>>> subprotocol. But as the semantic of a dcsa encapsulated attribute = may be subprotocol specific=20 >>>>>> (like 'setup'), I'd now tend to consider the subprotocol parameter= in the dcmap attribute as=20 >>>>>> being mandatory, as mentioned above. As already discussed, the Web= socket subprotocol registry=20 >>>>>> would then refer to the document, which specifies the subprotocol = specific usage of dcsa=20 >>>>>> encapsulated parameters. >>>>>> >>>>> Ok. Going back to discussion between Paul and I, do you believe tha= t in for an attribute to be=20 >>>>> encapsulated in dcsa, the attribute MUST have been explicitly defin= e to support this (Paul's=20 >>>>> suggestion below) or do you believe that this is overly constrainin= g, and if so, how shoud we=20 >>>>> relax it ? >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>>> Thanks, >>>>>> Juergen >>>>>> >>>>>> >>>>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>>>> >>>>>>> >>>>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and sp= ecific >>>>>>>>>>> drafts are used to describe protocols that use the mechanism = (i.e. >>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>>>> >>>>>>>>>> It remains to be seen if that will be enough. E.g., there curr= ently >>>>>>>>>> aren't any iana considerations in >>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>>>> >>>>>>>>>> Suppose I encounter some sdp that uses msrp over a data channe= l, but >>>>>>>>>> that usage is unknown to me. How do I find the spec (the refer= ence to >>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that u= sage? >>>>>>>>>> >>>>>>>>>> I would like to think that the iana registries will allow me t= o trace >>>>>>>>>> back to the relevant specs. >>>>>>>>>> >>>>>>>>> No disagreement on that part, however having taken another look= at both >>>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with y= our >>>>>>>>> original request for all (existing and new) attributes to speci= fy how >>>>>>>>> they may or may not be used with the dcsa attribute defined by = sdpneg. >>>>>>>>> >>>>>>>>> As Christian noted, the sub-protocol specifics are defined in i= ndividual >>>>>>>>> documents (like msrp-usage), which calls your the parameters th= at are at >>>>>>>>> least needed to be supported for that usage. Taking MSRP as an = example, >>>>>>>>> why isn't that enough, and how do you see the resulting set of >>>>>>>>> attributes that may or may not be used with MSRP differ between= use in a >>>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular m= edia >>>>>>>>> stream ? >>>>>>>> >>>>>>>> Based on this discussion, I conclude that it should be sufficien= t for this draft to say=20 >>>>>>>> that before an attribute can be used with dcsa, such usage must = be defined somewhere. This=20 >>>>>>>> could be either: >>>>>>>> - as part of the definition of the attribute, OR >>>>>>>> - as part of the definition of the protocol referenced on the m-= line. >>>>>>>> >>>>>>> We are getting closer, but it's still not obvious to me that you = cannot use an attribute=20 >>>>>>> with dcsa if it has not been explicitly defined for the attribute= in question. Clearly,=20 >>>>>>> there are attributes that wouldn't make sense over data channels,= just like there are=20 >>>>>>> attributes that don't make sense over particular media descriptio= ns. >>>>>>> >>>>>>> Again, I'd like to hear from more people on this, including the a= uthors. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Also, it would be good to hear from more people on this, includ= ing the >>>>>>>>> document authors. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- Flemming >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>>> Regards, Christian >>>>>>>>>>> >>>>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we= need to >>>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then i= t should be >>>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at t= his >>>>>>>>>>>>> point is >>>>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>>>> interactions as >>>>>>>>>>>>> opposed to relying on a more general algorithmic approach (= plus the >>>>>>>>>>>>> offerer being responsible for generating a valid offer if h= e wants to >>>>>>>>>>>>> establish a data channel). >>>>>>>>>>>> >>>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute p= ertains to >>>>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Paul >>>>>>>>>>>> From nobody Tue Feb 23 05:29: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 F3EFF1B2CCB for ; Tue, 23 Feb 2016 05:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, 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 xuMcJCGa72fZ for ; Tue, 23 Feb 2016 05:29:50 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 1FDD81B2CC8 for ; Tue, 23 Feb 2016 05:29:50 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 03445122E8A69 for ; Tue, 23 Feb 2016 13:29:46 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1NDTmhX031354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 23 Feb 2016 13:29:48 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1NDTdTC017564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Feb 2016 14:29:47 +0100 Received: from [149.204.68.190] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Feb 2016 14:29:43 +0100 References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> From: Juergen Stoetzer-Bradler To: "mmusic@ietf.org" Message-ID: <56CC5EC6.2030402@alcatel-lucent.com> Date: Tue, 23 Feb 2016 14:29:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C745EB.6060605@alum.mit.edu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [135.239.27.41] 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: Tue, 23 Feb 2016 13:29:54 -0000 Hi Paul, Thanks for your feedback to the updates in version 08. Please find my remarks inserted below your comments. Thanks, Juergen On 19.02.2016 17:42, EXT Paul Kyzivat wrote: > On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >> Hi Paul, Christian, Flemming, Bo, >> >> Have just submitted version 08 of draft-ietf-mmusic-data-channel-sdpne= g. >> The changes compared to version 07 are essentially as follows. >> >> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) regarding t= he >> relationship of subprotocols and their attributes. >> * Two new SDP offer/answer considerations in section 5.2.5 (Various >> SDP Offer/Answer Scenarios and Considerations) regarding unknown >> subprotocol attributes or known subprotocol attributes, whose data >> channel transport specific semantic is not known. >> * A new paragraph in section 8.1 (IANA Considerations / Subprotocol >> Identifiers) related to cases, where a subprotocol is defined for data= >> channel and Websocket transport. >> >> These changes should address the points discussed in this email thread= =2E > > This is an improvement. But I think things could still be made clearer.= > > Consider the following addition to 5.1.2.1: > > It is assumed that in general the usages of subprotocol related medi= a > 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=3Ddcsa" 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 expecte= d > to be described for the data channel transport. A data channel > specific usage of a subprotocol attribute is expected to be specifie= d > in the same document, which registers the subprotocol's identifier > for data channel usage as described in Section 8.1. > > This text makes sense when there is a clear distinction between subprot= ocol and protocol.=20 > Unfortunately, the way SDP has evolved there is no such clear distincti= on in many cases, such as=20 > RTP over UDP or TCP, etc. Those are combined into a single protocol val= ue. While that can usually=20 > be parsed apart at slashes, there isn't good terminology for it. > > My point is that when I read the above, I don't know how it applies to,= say, RTP attributes. Or=20 > does it only apply for attributes that are clearly defined for a *sub*p= rotocol? > > I think this is primarily that we lack well defined vocabulary for all = of this. But I think it=20 > would be too much to expect this draft to *solve* the vocabulary proble= m. In lieu of doing so,=20 > maybe it would be sufficient to give some concrete examples, even if th= ey have to be hypothetical=20 > ones. [Juergen] Agree that it would be helpful to have more precise definitions= of the differences of the=20 terms protocol and subprotocol, especially when those terms are used outs= ide the scope of data=20 channels (or Websockets). When only focusing on data channels the notion = of a "subprotocol" seems to=20 be clearer - at least draft-ietf-rtcweb-data-protocol explicitly refers t= o the "WebSocket=20 Subprotocol Name Registry" when specifying DCEP's "Protocol" parameter. (= But=20 draft-ietf-rtcweb-data-channel does not define what a data channel's "sub= protocol" is.) So far the=20 sdpneg draft relatively informally starts using the term "subprotocol" in= the introduction and there=20 refers to Websocket "subprotocols". Perhaps we should add the term "subpr= otocol" to the list of used=20 terminology in section 3. The sdpneg document, together with the data channel subprotocol specific = document (which defines the=20 value of the a=3Ddcmap attribute's "subprotocol" parameter), should certa= inly give clear guidance on=20 how to interpret SDP offers or answers like e.g.: m=3Dapplication 10001 UDP/DTLS/SCTP webrtc-datachannel c=3DIN IP4 10.10.10.1 a=3Dmax-message-size:100000 a=3Dsctp-port:5000 ... a=3Ddcmap:0 subprotocol=3D"MSRP" a=3Ddcsa:0 accept-types:message/cpim text/plain a=3Ddcsa:0 framerate:... a=3Ddcsa:0 lang:... An implementation receiving such an offer would need to decide what to do= with the dcsa embedded=20 framerate and lang attributes. Or, someone implementing MSRP over data ch= annel based services may=20 need to decide whether or not to use these attributes, and if yes, how. (I am using these two attributes just as hypothetical examples - don't wa= nt to suggest that those=20 may indeed be used for MSRP over data channel transport). The msrp-usage-data-channel document doesn't mention these two attributes= =2E When looking at the IANA=20 SDP attribute registry tables, I would find both attributes specified in = RFC 4566. There,=20 "framerate" is explicitly said to be defined only "for video media". Just= to be sure I could=20 additionally have a look at the MSRP specifying documents, RFC 4975 and R= FC 4976, but there would=20 not find any text at all related to "framerate". So this case seems prett= y clear and I would=20 therefore conclude that the "framerate" attribute should not be used for = MSRP, and that a receiver=20 of such an offer or answer should ignore it. When looking at the definition of the "lang" attribute in RFC 4566 I woul= d not see any explicit hint=20 of what protocols this attribute might be used with, especially if "lang"= could be used when=20 negotiating an MSRP session. When then looking at RFC 4975 I would indeed= find "lang" - but not as=20 SDP attribute, rather as XML tag parameter within an example MSRP message= payload. Thus, the case of=20 the "lang" attribute might not be as unambiguous as the one with the "fra= merate" attribute, but here=20 too I think the typical choice would be to ignore that attribute when rec= eiving such an offer or=20 answer. It seems to me that the two new "ignore" rules in section 5.2.5 of sdpneg= -08 may also be applied in=20 these cases. Admittedly, these examples may seem a bit far-fetched, but would those go= into the direction you had=20 in mind? > > Thanks, > Paul > >> Thank you, >> Juergen >> >> >> On 16.02.2016 14:01, Juergen Stoetzer-Bradler wrote: >>> Paul, >>> >>> Thanks for further feedback. Fully agree now that the subprotocol >>> parameter should stay optional. >>> Will come back with with a proposal of how the sdpneg text could be >>> enhanced as discussed. >>> >>> Thanks, >>> Juergen >>> >>> On 15.02.2016 17:08, EXT Paul Kyzivat wrote: >>>> On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote: >>>>> Paul, >>>>> >>>>> In your case 2) I would agree that the usage of dcsa embedded >>>>> attributes >>>>> seems questionable. After all, the dcsa attribute is defined in sdp= neg >>>>> as encapsulating a subprotocol specific attribute. If the subprotoc= ol >>>>> may dynamically change over time without further (SDP offer/answer)= >>>>> negotiation, then a negotiation of dcsa embedded attributes may ind= eed >>>>> not be very helpful. >>>>> >>>>> In your case 1), I am wondering how would the SDP answerer know whi= ch >>>>> subprotocol to use for which data channel, if the subprotocol id is= not >>>>> added to the data channel's dmap attribute (at least if multiple da= ta >>>>> channels are negotiated)? Conceivably via some provisioning, or via= a >>>>> mutual understanding of a certain subprotocol to SCTP stream id >>>>> mapping, >>>>> or via a certain a priori agreed label usage. I hadn't thought of s= uch >>>>> cases when raising the question if the subprotocol should actually = be >>>>> mandatory. >>>> >>>> IMO it could be any of those. But for this use case it seems more >>>> likely that channels will be opened dynamically rather than via SDP.= >>>> >>>> I think the provision for *not* specifying the subprotocol was >>>> primarily to establish equivalence with what is possible via DCEP. >>>> >>>> One possibility is that SDP is used to specify how many channels are= >>>> opened, with the understanding that each of them will use the same >>>> application-specific protocol. >>>> >>>> One possible use for dcsa with an unnamed protocol would be if the >>>> intent is to use a proprietary variant of a standard protocol, where= >>>> there is still a desire to negotiate options using attributes >>>> applicable to that standard base protocol. But I'm really stretching= >>>> to come up with this. >>>> >>>>> But such use cases would certainly go beyond a pure SDP offer/answe= r >>>>> negotiation use case and I would argue that such use cases would >>>>> also go >>>>> beyond the scope of the sdpneg draft. >>>> >>>> Probably. >>>> >>>>> I could now imagine the sdpneg draft saying that an SDP offerer sho= uld >>>>> add a subprotocol identifier to an offered data channel's dcmap >>>>> attribute, if it also adds dcsa embedded subprotocol attributes. An= d >>>>> that an implementation would be on its own, if it does not follow t= hat >>>>> recommendation (for whatever reasons). >>>> >>>> That could work. >>>> >>>>> Further, similar as for non-dcsa embedded attributes, we could >>>>> explicitly add text to the sdpneg draft saying that a recipient of >>>>> an an >>>>> SDP offer or answer should ignore dcsa embedded attributes not only= if >>>>> they are completely unknown, but also if their semantics related to= the >>>>> subprotocol is not known. >>>>> (The current draft says in sec 5.2.3 that the SDP answerer "/Parses= and >>>>> applies the SDP offer. Note that the typical parser normally ignor= es >>>>> unknown SDP attributes, which includes data channel related >>>>> attributes./" I think we could make this clearer and explicitly >>>>> refer to >>>>> dcsa embedded subprotocol attributes.) >>>> >>>> Yes, that would help. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Thanks, >>>>> Juergen >>>>> >>>>> On 12.02.2016 17:58, EXT Paul Kyzivat wrote: >>>>>> Juergen, >>>>>> >>>>>> You bring up a point that perhaps needs further discussion: what d= oes >>>>>> it mean when the subprotocol is not specified? >>>>>> >>>>>> IIUC there are at least a couple of reasons this might come about:= >>>>>> >>>>>> 1) The protocol to be used is not standardized. There is no global= ly >>>>>> unique name for it. The two ends know what protocol to use based o= n >>>>>> context. >>>>>> >>>>>> 2) The protocol to be used on the channel is not determined via SD= P >>>>>> negotiation. The applications want to establish the channel, and t= hen >>>>>> dynamically decide what protocol to use with it. (And that protoco= l >>>>>> may change over time.) >>>>>> >>>>>> I guess that it still might be meaningful to use dcsa with (1), bu= t >>>>>> there would be no way to determine by examination of the SDP wheth= er >>>>>> the usage was compatible with the protocol. In this case the usage= of >>>>>> the attributes would be "off label" - being adapted to the proprie= tary >>>>>> protocol in a way that hopefully the two ends agree. >>>>>> >>>>>> I don't see how dcsa makes much sense for (2). If you don't know w= hat >>>>>> protocol will be used then how do you know what attributes to use?= >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote: >>>>>>> Flemming, Paul, >>>>>>> >>>>>>> The current a=3Ddcmap related text in >>>>>>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the >>>>>>> 'subprotocol' parameter must always be present - rather it is >>>>>>> specified >>>>>>> as an optional parameter. Thus, current sdpneg text would allow t= o >>>>>>> create an SDP offer for a data channel, which contains one a=3Ddc= map >>>>>>> attribute and potentially multiple a=3Ddcsa attributes without th= e >>>>>>> subprotocol actually being given. Based on this discussion I am >>>>>>> wondering if the subprotocol parameter should actually be mandato= ry. >>>>>>> >>>>>>> In the specific case of MSRP, the msrp-usage-data-channel draft >>>>>>> says in >>>>>>> 5.1.1.1 that the dcmap attribute includes the label and subprotoc= ol >>>>>>> parameters. The current text could possible be made more explicit= by >>>>>>> saying that the 'subprotocol=3D"MSRP"' parameter must always be >>>>>>> present. >>>>>>> Have just submitted version 04 of the msrp-usage-data-channel dra= ft, >>>>>>> which proposes to add subprotocol identifier "MSRP" to the WebSoc= ket >>>>>>> Subprotocol Name registry. This registry would then associate >>>>>>> subprotocol id "MSRP" with the msrp-usage-data-channel document. >>>>>>> There, in section 5.1.1.2 the MSRP specific usages of the a=3Ddcs= a >>>>>>> attribute are specified. And there the MSRP specific SDP attribut= es, >>>>>>> which can be dcsa embedded, are described. >>>>>>> 'setup' is an attribute, whose semantic changes when being dcsa >>>>>>> embedded >>>>>>> and associated with subprotocol MSRP, as compared to the meaning >>>>>>> of an >>>>>>> "a=3Dsetup" media level attribute of a TCP/MSRP m-line. Hence the= se >>>>>>> semantical differences are explicitly addressed in the >>>>>>> msrp-usage-data-channel draft. >>>>>>> >>>>>>> Regarding sdpneg, I also think that the current text in sdpneg >>>>>>> seems to >>>>>>> be sufficient regarding the usage of dcsa encapsulated SDP >>>>>>> attributes as >>>>>>> being bound to the data channel's subprotocol. But as the >>>>>>> semantic of a >>>>>>> dcsa encapsulated attribute may be subprotocol specific (like >>>>>>> 'setup'), >>>>>>> I'd now tend to consider the subprotocol parameter in the dcmap >>>>>>> attribute as being mandatory, as mentioned above. As already >>>>>>> discussed, >>>>>>> the Websocket subprotocol registry would then refer to the docume= nt, >>>>>>> which specifies the subprotocol specific usage of dcsa encapsulat= ed >>>>>>> parameters. >>>>>>> >>>>>>> Thanks, >>>>>>> Juergen >>>>>>> >>>>>>> >>>>>>> On 11.02.2016 21:52, Flemming Andreasen wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote: >>>>>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote: >>>>>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote: >>>>>>>>>>>> Isn't this the approach we're taking today? >>>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and >>>>>>>>>>>> specific >>>>>>>>>>>> drafts are used to describe protocols that use the mechanism= >>>>>>>>>>>> (i.e. >>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel & >>>>>>>>>>>> draft-ietf-clue-datachannel). >>>>>>>>>>> >>>>>>>>>>> It remains to be seen if that will be enough. E.g., there >>>>>>>>>>> currently >>>>>>>>>>> aren't any iana considerations in >>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel. >>>>>>>>>>> >>>>>>>>>>> Suppose I encounter some sdp that uses msrp over a data >>>>>>>>>>> channel, but >>>>>>>>>>> that usage is unknown to me. How do I find the spec (the >>>>>>>>>>> reference to >>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that >>>>>>>>>>> usage? >>>>>>>>>>> >>>>>>>>>>> I would like to think that the iana registries will allow me = to >>>>>>>>>>> trace >>>>>>>>>>> back to the relevant specs. >>>>>>>>>>> >>>>>>>>>> No disagreement on that part, however having taken another loo= k at >>>>>>>>>> both >>>>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with = your >>>>>>>>>> original request for all (existing and new) attributes to >>>>>>>>>> specify how >>>>>>>>>> they may or may not be used with the dcsa attribute defined by= >>>>>>>>>> sdpneg. >>>>>>>>>> >>>>>>>>>> As Christian noted, the sub-protocol specifics are defined in >>>>>>>>>> individual >>>>>>>>>> documents (like msrp-usage), which calls your the parameters t= hat >>>>>>>>>> are at >>>>>>>>>> least needed to be supported for that usage. Taking MSRP as an= >>>>>>>>>> example, >>>>>>>>>> why isn't that enough, and how do you see the resulting set of= >>>>>>>>>> attributes that may or may not be used with MSRP differ betwee= n >>>>>>>>>> use >>>>>>>>>> in a >>>>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular >>>>>>>>>> media >>>>>>>>>> stream ? >>>>>>>>> >>>>>>>>> Based on this discussion, I conclude that it should be >>>>>>>>> sufficient for >>>>>>>>> this draft to say that before an attribute can be used with dcs= a, >>>>>>>>> such usage must be defined somewhere. This could be either: >>>>>>>>> - as part of the definition of the attribute, OR >>>>>>>>> - as part of the definition of the protocol referenced on the >>>>>>>>> m-line. >>>>>>>>> >>>>>>>> We are getting closer, but it's still not obvious to me that you= >>>>>>>> cannot use an attribute with dcsa if it has not been explicitly >>>>>>>> defined for the attribute in question. Clearly, there are attrib= utes >>>>>>>> that wouldn't make sense over data channels, just like there are= >>>>>>>> attributes that don't make sense over particular media descripti= ons. >>>>>>>> >>>>>>>> Again, I'd like to hear from more people on this, including the >>>>>>>> authors. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> Also, it would be good to hear from more people on this, inclu= ding >>>>>>>>>> the >>>>>>>>>> document authors. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> -- Flemming >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>>> Regards, Christian >>>>>>>>>>>> >>>>>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote: >>>>>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* w= e >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then = it >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at = this >>>>>>>>>>>>>> point is >>>>>>>>>>>>>> that there is indeed a need to explicitly speficy these >>>>>>>>>>>>>> interactions as >>>>>>>>>>>>>> opposed to relying on a more general algorithmic approach >>>>>>>>>>>>>> (plus the >>>>>>>>>>>>>> offerer being responsible for generating a valid offer if = he >>>>>>>>>>>>>> wants to >>>>>>>>>>>>>> establish a data channel). >>>>>>>>>>>>> >>>>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute >>>>>>>>>>>>> pertains to >>>>>>>>>>>>> need to be defined to work over data channels. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Paul >>>>>>>>>>>>> From nobody Tue Feb 23 07:21: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 545E11B32C2; Tue, 23 Feb 2016 07:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 M-WxRT5J7pl8; Tue, 23 Feb 2016 07:21:00 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949411B33BD; Tue, 23 Feb 2016 07:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1332; q=dns/txt; s=iport; t=1456240859; x=1457450459; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V3ctrSd/jtoPgLKDu+eYl8CwttVH4+qI+kHR+FeAgOk=; b=NeG5zjhJSLUl9KYWzD0C8wl1F9Ne75SlxXkjCydON48d81Sf1Cq1NjyB L/FsEnmlr9y94nj1I7I8nUnHuyCrFSqRzflCBXl1ysELPmmB87CytHmxX 55/GMjbOcIN2uv0Jyzbpsm+wgEO0Cy+hab5LgQfkcRAlJLLFOZcSUnkWa w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgABeMxW/5tdJa1egzpSbQa6YwENg?= =?us-ascii?q?WYXCoUiSgIcgSY4FAEBAQEBAQFkJ4RBAQEBAwEBAQEgEToLBQsCAQgYAgImAgI?= =?us-ascii?q?CJQsVEAEBBA4FiBMIDq1mjmkBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHuFF4Fsg?= =?us-ascii?q?k6EM4MCK4EPBZJzhBQBjV2BXI0VhXKIVgEeAQFCggMZgUhqhzx9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,489,1449532800"; d="scan'208";a="240085872" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2016 15:20:58 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1NFKw8r022738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 15:20:58 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 09:20:57 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 09:20:57 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 Thread-Index: AdFs3blNepl6vLZrR5us7i3JWzoW7Q== Date: Tue, 23 Feb 2016 15:20:57 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37E25706@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E25784@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E25784@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.214.65] Content-Type: text/plain; charset="utf-8" Content-ID: <25B5CF53AFBCB54F8E7EB0AB78EFDCC7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 15:21:01 -0000 SEkgQ2hyaXN0ZXIgLSANCg0KSSBoYXZlIHJlLXJldmlld2VkIC0wOCBhbmQgaXQgYWRkcmVzc2Vz IGFsbCBteSBjb25jZXJucy4gIA0KDQpUaGFua3MuDQoNCkdvbnphbG8NCg0KDQo+IE9uIEZlYiAy MSwgMjAxNiwgYXQgMTE6MzkgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPj4gVGhlIHByb3Bvc2VkIGNo YW5nZXMgbG9vayBnb29kLiAgVGhhbmtzIGZvciBtYWtpbmcgdGhlbS4NCj4+IA0KPj4gT25lIG1p bm9yIGNvbW1lbnQ6IENvbnNpZGVyaW5nIHRoZSBwcm9wb3NlZCB1cGRhdGUgdG8gUkZDIDczNDUs IEkgdGhpbmsgdGhlcmUgbmVlZHMgdG8gYmUgYSA+bm9ybWF0aXZlIHJlZmVyZW5jZSB0byBpdC4N Cj4gDQo+IEkgdGhvdWdodCBJIGRpZCB0aGF0LCBidXQgbm93IEkgc2VlIEkgYWRkZWQgYSByZWZl cmVuY2UgdG8gUkZDIDczMTUgYnkgbWlzdGFrZS4gSSdsbCBmaXggdGhhdC4NCj4gDQo+IFRoYW5r cyENCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPj4gT24gRmVi IDIxLCAyMDE2LCBhdCAyOjI2IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IA0KPj4gSGksDQo+PiANCj4+IEJhc2VkIG9uIGNv bW1lbnRzIGFuZCBmZWVkYmFjayByZWNlaXZlZCwgSeKAmXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJz aW9uICgtMDcpIG9mIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLg0KPj4gDQo+PiBSZWdhcmRz LA0KPj4gDQo+PiBDaHJpc3Rlcg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+IG1tdXNpY0BpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4gDQoN Cg== From nobody Tue Feb 23 07:37: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 5CF3C1A8822 for ; Tue, 23 Feb 2016 07:37:16 -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 Je_45nxu7IDv for ; Tue, 23 Feb 2016 07:37:14 -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 BA2581A01E7 for ; Tue, 23 Feb 2016 07:37:14 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-12v.sys.comcast.net with comcast id Mrd11s00427uzMh01rdDk9; Tue, 23 Feb 2016 15:37:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with comcast id MrdC1s00R3KdFy101rdDiQ; Tue, 23 Feb 2016 15:37:13 +0000 To: "Drage, Keith (Nokia - GB)" , EXT Colin Perkins , Roman Shpount References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <949EF20990823C4C85C18D59AA11AD8BADE903FF@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56CC7CA8.4050309@alum.mit.edu> Date: Tue, 23 Feb 2016 10:37:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE903FF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456241833; bh=Bu2tmWBkaSSSKuj3Y7Udo8ogXl8wvrBmuHW7WXZ4hyQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=VBxRZcZH15/6iRl1a1a1DGyKVfOQ2vR/+jI85BcGNJY0YVo9MbAO36gfKEQhVy6Dz f11OcK1LwowkScP9j8/nqRIH0xDLKh0jaLzO+8g3zRQUDTBEixAchtiBTisud6LPN4 aCQ8lB0BqJobkc1/C9ISuAKVaOUBkA9IEmvHcafYTAf2fU2PsKVJYZh/Zd8qLsEWnU ABzV6bxvYtqsIx9BRxSqjMMEqRTRraTSvPoI92iy52gRhdauZ6osKZ5clFRoDBVpI+ TcYe1FS8nfUpIGpIPWFLutI6U/L6kYDvx/hMvdqc1DvYiIjliHktTwEfQha6WAhH1m YrklcRlR4wZBw== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 15:37:16 -0000 On 2/23/16 7:04 AM, Drage, Keith (Nokia - GB) wrote: > I agree that here we are discussing offer / answer, but we must also > remember that any rules must be consistent with declarative usages of SDP. > > It may also be that some of those declarative rules are also inherited > by offer answer, such as the answer to the question as to whether the > requirement to remember payload type usage (and whether than applies to > both offers and answers, or independently to each). I don't understand your point. ISTM that none of this discussion is relevant to declarative usage - why should there ever be any need to retain history or remain consistent with it in the declarative case? Thanks, Paul > Regards > > Keith > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *EXT Colin > Perkins > *Sent:* 23 February 2016 10:29 > *To:* Roman Shpount > *Cc:* mmusic@ietf.org; Paul Kyzivat; Christer Holmberg > *Subject:* Re: [MMUSIC] Offer/Answer PT Questions > > On 22 Feb 2016, at 19:52, Roman Shpount > wrote: > > … > > One thing that bothered me here is that PT cannot be reused for the > duration of the session. It is probably safe to reuse the PT after > session modification if PT is no longer used. I always felt that dynamic > PT reuse criteria were much stricter then realistically possible or needed. > > … > > I think the most important criteria here is that there should be no > ambiguity regarding how an RTP packet with particular PT should be > decoded. If it is guaranteed that there are no packets sent between > Alice and Bob with PT 111 over some reasonable time interval (couple of > network round trip times), then PT 111 can be safely reused. If, in this > scenario Bob's end point knows that it was not sending anything with > payload 111 recently, then it can safely reuse this payload. Alice could > not be sending anything with payload 111 since Bob did not accept it > previously. On the other hand, Bob must not reuse PT 100 for, let's say, > CN, since there are packets with this payload in flight and this will > create decoding ambiguity. To conclude, an end point should be able to > safely reuse any PT that it is not currently accepting or was not > sending or accepting for at least a few network round trip intervals. > > No objection in principle, but it’s not as simple as “a few network RTTs”: > > No ambiguity in decoding means that the packets need to have been played > out, so the codec state for that PT can be discarded. Some systems can > have large (multi-second) playout buffers. > > Any packets referring to the old PT also need to be gone. Formats > like RFC 6354 allow large offsets between streams, referenced by PT (the > example in Section 5 has a 5.1 second offset). > > -- > > Colin Perkins > > https://csperkins.org/ > From nobody Tue Feb 23 07:44: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 D53A11B3287 for ; Tue, 23 Feb 2016 07:44:43 -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 xG88HbWq8lum for ; Tue, 23 Feb 2016 07:44:43 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7711B2FFD for ; Tue, 23 Feb 2016 07:44:42 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-10v.sys.comcast.net with comcast id MrjN1s0052EPM3101rkiGd; Tue, 23 Feb 2016 15:44:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id Mrkh1s00D3KdFy101rkhyR; Tue, 23 Feb 2016 15:44:42 +0000 To: Colin Perkins , Roman Shpount References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> From: Paul Kyzivat Message-ID: <56CC7E68.4040103@alum.mit.edu> Date: Tue, 23 Feb 2016 10:44:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456242282; bh=iAQvXDL7Zj8G0jpM1hfMBuVlc6h3JwzjVRSXnmEizek=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ui/Eg65lb6yBt+T2KZEaONIkUmW3YohspjtmBi5tI+yth3nNZy3QwGpDhPtXXgqIG 48YuG4AjmdXAxxAzKw8CsWNzhqqtbBBZjlj5ATFUPm1uGb5pTIQRKuiY6LGX/PHaaq xuMEb+MrSv3DhfZOSstcZ3LPJ6E0RBRFExaIKiWm+iDdUMEfpGGDghdZG6AvTdRWbL pSnSu3qIe810w6WNEtjkuAJaks0E4tsVMj2wTbxRMh+R1xWd8yzkwXYoqa8iLbxFjn kt610Q+ejFk5WfQpOIjKsvAQH26RNVyKuRKWif9CUDTRSC4LZQ1vW8TFlX6w2fAJWF L5za9dgpjWgJA== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 15:44:44 -0000 On 2/23/16 5:29 AM, Colin Perkins wrote: > No objection in principle, but it’s not as simple as “a few network RTTs”: > > No ambiguity in decoding means that the packets need to have been played > out, so the codec state for that PT can be discarded. Some systems can > have large (multi-second) playout buffers. > > Any packets referring to the old PT also need to be gone. Formats > like RFC 6354 allow large offsets between streams, referenced by PT (the > example in Section 5 has a 5.1 second offset). Thanks for the insight. It helps to ground the discussion. I'm also interested in hearing if there might be *other* reasons behind the rules as they are written. The advantage of the current rule is that it is easy to explain, and is sufficient to deal with the problem you describe above. Unfortunately it is also difficult/impossible to comply with in some cases. If we are to replace it, we need to find something else to replace it with. Would it be possible to instead make a rule that a PT can't be reused until there are no active streams using it? (That any that were initiated have been terminated.) Note: I don't know RTP well enough to be confident that this even makes sense. Thanks, Paul From nobody Tue Feb 23 08:25:20 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 722841B35AE for ; Tue, 23 Feb 2016 08:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 3-IyfQAshSW7 for ; Tue, 23 Feb 2016 08:25:17 -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 35E371B35AA for ; Tue, 23 Feb 2016 08:25:17 -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 u1NGP9k3056727 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 23 Feb 2016 10:25:09 -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: "Paul Kyzivat" Date: Tue, 23 Feb 2016 10:25:09 -0600 Message-ID: <5B524A9A-E10D-4DBB-B6D8-66939FB0F8EC@nostrum.com> In-Reply-To: <56CB79BB.9080906@alum.mit.edu> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> <56CB79BB.9080906@alum.mit.edu> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 16:25:19 -0000 Jumping in on one point: On 22 Feb 2016, at 15:12, Paul Kyzivat wrote: [...] > Another possibility is to file an errata about it. >From the conversation so far, this doesn't seem like errata material to me. Ben. From nobody Tue Feb 23 10:04: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 8360B1B3A74 for ; Tue, 23 Feb 2016 10:04:24 -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_21=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 FWfan6CCXqla for ; Tue, 23 Feb 2016 10:04:23 -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 76E1F1B3A6D for ; Tue, 23 Feb 2016 10:04:22 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-8b-56cc9f24d738 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.E2.28465.42F9CC65; Tue, 23 Feb 2016 19:04:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 19:04:19 +0100 From: Christer Holmberg To: Paul Kyzivat , Colin Perkins , Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAA9P4AgABYEQD//8mqgA== Date: Tue, 23 Feb 2016 18:04:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <56CC7E68.4040103@alum.mit.edu> In-Reply-To: <56CC7E68.4040103@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7sa7K/DNhBu9PKVosf3mC0WLq8scs Fis2HGC1mHFhKrMDi8ff9x+YPKbdv8/msWTJTyaPW1MKAliiuGxSUnMyy1KL9O0SuDLenTjL XtAnWLGx5QNLA+MVgS5GTg4JAROJOy+/s0LYYhIX7q1nA7GFBA4zSlz/y9XFyAVkL2aU2NKy iqmLkYODTcBCovufNogpIlAgsedqPIjJLKAucXVxEEinsIC+xPtFR9hBbBEBA4m9Lw+wQ1SH Sfw95wsSZhFQlfjw4DATiM0r4CuxdeZZJohF95kkZm84xQiS4BTQkfjwczaYzQh02fdTa8Aa mAXEJW49mc8EcbGAxJI955khbFGJl4//QX2iJLHo9mcmiNM0Jdbv0odoVZSY0v2QHWKvoMTJ mU9YJjCKzUIydRZCxywkHbOQdCxgZFnFKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhbB7f8 1t3BuPq14yFGAQ5GJR7eDVGnw4RYE8uKK3MPMUpwMCuJ8M7qORMmxJuSWFmVWpQfX1Sak1p8 iFGag0VJnHeN8/owIYH0xJLU7NTUgtQimCwTB6dUA6P4/vq9afV3dC28VOX+xCTxSjPKCbCH zdp2fRvv1t8BU1sYX4rXfp+qkN/xz31RsgJjSZFz7uIvgZ+dfgqrN5wOXhdxTGF3tn8Tm/iL p8ldHVreF7uPtgaanwuUnJ6gdevI/sCDogLZ1qkPGpr+8l7sXCQYLTi/QmWeCwfnu6B/z4OC 78f9VGIpzkg01GIuKk4EALyFbiGpAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 18:04:24 -0000 SGksDQoNCj4+IE5vIG9iamVjdGlvbiBpbiBwcmluY2lwbGUsIGJ1dCBpdOKAmXMgbm90IGFzIHNp bXBsZSBhcyDigJxhIGZldyBuZXR3b3JrIFJUVHPigJ06DQo+Pg0KPj4gTm8gYW1iaWd1aXR5IGlu IGRlY29kaW5nIG1lYW5zIHRoYXQgdGhlIHBhY2tldHMgbmVlZCB0byBoYXZlIGJlZW4gDQo+PiBw bGF5ZWQgb3V0LCBzbyB0aGUgY29kZWMgc3RhdGUgZm9yIHRoYXQgUFQgY2FuIGJlIGRpc2NhcmRl ZC4gU29tZSANCj4+IHN5c3RlbXMgY2FuIGhhdmUgbGFyZ2UgKG11bHRpLXNlY29uZCkgcGxheW91 dCBidWZmZXJzLg0KPj4NCj4+IEFueSBwYWNrZXRzIHJlZmVycmluZyB0byB0aGUgb2xkIFBUIGFs c28gbmVlZCB0byBiZSBnb25lLiBGb3JtYXRzIGxpa2UgDQo+PiBSRkMgNjM1NCBhbGxvdyBsYXJn ZSBvZmZzZXRzIGJldHdlZW4gc3RyZWFtcywgcmVmZXJlbmNlZCBieSBQVCAodGhlIA0KPj4gZXhh bXBsZSBpbiBTZWN0aW9uIDUgaGFzIGEgNS4xIHNlY29uZCBvZmZzZXQpLg0KPg0KPiBUaGFua3Mg Zm9yIHRoZSBpbnNpZ2h0LiBJdCBoZWxwcyB0byBncm91bmQgdGhlIGRpc2N1c3Npb24uDQo+DQo+ IEknbSBhbHNvIGludGVyZXN0ZWQgaW4gaGVhcmluZyBpZiB0aGVyZSBtaWdodCBiZSAqb3RoZXIq IHJlYXNvbnMgYmVoaW5kIHRoZSBydWxlcyBhcyB0aGV5IGFyZSB3cml0dGVuLg0KPg0KPiBUaGUg YWR2YW50YWdlIG9mIHRoZSBjdXJyZW50IHJ1bGUgaXMgdGhhdCBpdCBpcyBlYXN5IHRvIGV4cGxh aW4sIGFuZCBpcyBzdWZmaWNpZW50IHRvIGRlYWwgd2l0aCB0aGUgcHJvYmxlbSB5b3UgZGVzY3Jp YmUgDQo+IGFib3ZlLiBVbmZvcnR1bmF0ZWx5IGl0IGlzIGFsc28gZGlmZmljdWx0L2ltcG9zc2li bGUgdG8gY29tcGx5IHdpdGggaW4gc29tZSBjYXNlcy4gSWYgd2UgYXJlIHRvIHJlcGxhY2UgaXQs IHdlIG5lZWQgdG8gZmluZCANCj4gc29tZXRoaW5nIGVsc2UgdG8gcmVwbGFjZSBpdCB3aXRoLg0K DQpUaGUgY3VycmVudCBydWxlIG1heSBiZSBlYXN5IHRvIHVuZGVyc3RhbmQsIGJ1dCBpdCdzIGRp ZmZpY3VsdCB0byB1bmRlcnN0YW5kIC0gYW5kIHRoYXQncyB3aGF0IHRyaWdnZXJlZCB0aGlzIGRp c2N1c3Npb24gOikNCg0KU28sIHdoaWxlIHdlIGNhbiBkaXNjdXNzIHBvc3NpYmxlIHJ1bGVzL2d1 aWRlbGluZXMgb24gd2hlbiBhIFBUIHZhbHVlIGNhbiBiZSB1c2VkLCBJIHN0aWxsIHRoaW5rIHdl IG5lZWQgdG8gYW5zd2VyIHRoZSBmaXJzdCBxdWVzdGlvbjoNCg0KLSBJZiBBbGljZSBhbGxvY2F0 ZXMgUFQ9WCBmb3IgY29kZWMgMSwgaXMgQm9iIGFsbG93ZWQgdG8gYWxsb2NhdGUgUFQ9WCBmb3Ig Y29kZWMgMiB3aXRoaW4gdGhlIHNhbWUgc2Vzc2lvbj8gVGhlIGN1cnJlbnQgdGV4dCBpcyB1bmNs ZWFyIG9uIHRoYXQsIGFuZCBJIHRoaW5rIHRoYXQgaXMgdGhlIGZpcnN0IHF1ZXN0aW9uIHdlIG5l ZWQgdG8gc29ydCBvdXQuDQoNCkFmdGVyIHRoYXQsIHdlIGNhbiBkaXNjdXNzIHdoZXRoZXIgZS5n LiBBbGljZSBhdCBzb21lIHBvaW50IGNhbiBhbGxvY2F0ZSBQVD1YIGZvciBjb2RlYyAzLCBhbmQg d2hhdCB0aGUgY3JpdGVyaWEgZm9yIHRoYXQgaXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg== From nobody Tue Feb 23 10:22: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 A7AAE1B3F0D for ; Tue, 23 Feb 2016 10:22:08 -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_21=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 0FBmukXrMLGw for ; Tue, 23 Feb 2016 10:22:07 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 54D431B3F05 for ; Tue, 23 Feb 2016 10:22:07 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id 9so224196485iom.1 for ; Tue, 23 Feb 2016 10:22: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=8WBH1o0JTuuNv/4IJ16qCdQq+bRYOrC2qURsbWm3Zsk=; b=lk4tJ4Y7xPrNVx8TpgXuGGLagSrngCYm6Q/IWIDw1PtP+yRYgwNIlzbvqDZU31uMW+ fQLmQTyvqbhMDoS83TpN7vZSZntttkE8Brfshdflk6Q+149jXFp9V452ikwynNkD9jD0 oFqpQOJ7LQ1VWtqAcJDC6H57+sm90ZaZgd2m5wDcwq/N5EFj81n6aBdKIhGIM4JFzGgO T7L/lkfuBwAcFPt9LgR8PuPmyhqmvX+MW+9reTHfcYA05XPh3Ykb1vnJLdJlh7vyJ5Nh n0TEFrrj/LLE5L7I9CLC6w7KKEojkHAU74PzXIERyWLVw6PYRqBz0wPueJLYHJdfXJpd sSwQ== 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=8WBH1o0JTuuNv/4IJ16qCdQq+bRYOrC2qURsbWm3Zsk=; b=HuA2pWoFQI7IATbsw4DCV4UJaJxjDyJFQYfOD1GltXLiJiYurakpNnD2TpdxBPRpBv xWBo4l1Z9EAh6GGM/aq0p73lNMAq2j9cKIqfdWGvnXrYqx1owmTlRbMAXBXwRYAh6j1x O7MHZVzwHI/LfMRh5C1Azk5u7s+n8w18Abg0rOjY/8Hkf9TI6W8sK/TByEZfxjUKBGKd MTm8CsJ1vhx/cm4Tafy6K5Pbv2uiNsX558aT+lDsRow+KjDSZNp+A6lHPdsDJj3E1k8t kixgzwgudZZiV7+jZ0xNia/KozE9KZXeG9vjbiFAWdych7Q4P0VmxM/WBq2VkTlTckw6 QpGw== X-Gm-Message-State: AG10YOThiP7oHwKUFJ7fNKJcH62Nr0bRzbJjC5DDObAE1xf268VJvTOHfWaz2LimTbRgOg== X-Received: by 10.107.185.214 with SMTP id j205mr36164832iof.111.1456251726755; Tue, 23 Feb 2016 10:22:06 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com. [209.85.213.175]) by smtp.gmail.com with ESMTPSA id m3sm13938267ioe.2.2016.02.23.10.22.04 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 10:22:05 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id g6so117809146igt.1 for ; Tue, 23 Feb 2016 10:22:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.194 with SMTP id y2mr11113811igl.96.1456251724415; Tue, 23 Feb 2016 10:22:04 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 23 Feb 2016 10:22:04 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <56CC7E68.4040103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> Date: Tue, 23 Feb 2016 13:22:04 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bfea0b6bcd592052c7406d7 Archived-At: Cc: Colin Perkins , Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 18:22:08 -0000 --047d7bfea0b6bcd592052c7406d7 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 23, 2016 at 1:04 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > The current rule may be easy to understand, but it's difficult to > understand - and that's what triggered this discussion :) > > So, while we can discuss possible rules/guidelines on when a PT value can > be used, I still think we need to answer the first question: > > - If Alice allocates PT=X for codec 1, is Bob allowed to allocate PT=X for > codec 2 within the same session? The current text is unclear on that, and I > think that is the first question we need to sort out. > > After that, we can discuss whether e.g. Alice at some point can allocate > PT=X for codec 3, and what the criteria for that is. > As far as I can see there are 3 question/clarifications that are required: 1. PT is allocated per codec profile (codec and all associated parameters), not codec. For instance, if end point uses PT=100 for SILK/8000, it cannot reuse it for SILK/16000 2. Is PT blocked from each direction independently or both directions at the same time. For instance if A sent an offer with PT=100, but B never sent an offer or an answer with PT=100, can B sent an offer with PT=100? 3. PT reuse in sessions such as one triggered by 3pcc where it would be impossible to enforce PT from ever being reused. Regards, _____________ Roman Shpount --047d7bfea0b6bcd592052c7406d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 23, 2016 at 1:04 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
The current rule may be easy to understan= d, but it's difficult to understand - and that's what triggered thi= s discussion :)

So, while we can discuss possible rules/guidelines on when a PT value can b= e used, I still think we need to answer the first question:

- If Alice allocates PT=3DX for codec 1, is Bob allowed to allocate PT=3DX = for codec 2 within the same session? The current text is unclear on that, a= nd I think that is the first question we need to sort out.

After that, we can discuss whether e.g. Alice at some point can allocate PT= =3DX for codec 3, and what the criteria for that is.
<= br>
As far as I can see there are 3 question/clarifications that = are required:

1. PT is allocated per codec profile= (codec and all associated parameters), not codec. For instance, if end poi= nt uses PT=3D100 for SILK/8000, it cannot reuse it for SILK/16000

2. Is PT blocked from each direction independently or both = directions at the same time. For instance if A sent an offer with PT=3D100,= but B never sent an offer or an answer with PT=3D100, can B sent an offer = with PT=3D100?

3. PT reuse in sessions such as one= triggered by 3pcc where it would be impossible to enforce PT from ever bei= ng reused.

Regards,
_____________
Roman Shpount
=C2=A0
--047d7bfea0b6bcd592052c7406d7-- From nobody Tue Feb 23 10:26: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 211071B3FD0 for ; Tue, 23 Feb 2016 10:26:51 -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 eoDZRU0cAPBg for ; Tue, 23 Feb 2016 10:26: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 213D61B3E8A for ; Tue, 23 Feb 2016 10:26:48 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-ff-56cca46613a8 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 77.65.28465.664ACC65; Tue, 23 Feb 2016 19:26:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 19:26:45 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions - 3pcc Thread-Index: AdFuZ4ej9iohhK9JSpeiMIbDRhdiOQ== Date: Tue, 23 Feb 2016 18:26:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3C851@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_7594FB04B1934943A5C02806D1A2204B37E3C851ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7rm76kjNhBv0nOCyWvzzBaDF1+WMW ixUbDrBazLgwldmBxePv+w9MHtPu32fzWLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBkNP7ex FOwyrDi6/zZrA2OLQRcjJ4eEgInE2i/z2SBsMYkL99YD2VwcQgKHGSV6FzYxQziLGSUmnL7L 2sXIwcEmYCHR/U8bpEFEQFXi7/fJTCA2s0CRxJb//1lAbGEBM4lJf3awQNSYS8ycd4kJwtaT mD1nI5jNAtT7a/VDZhCbV8BX4s2thYwgNiPQEd9PrYGaKS5x68l8JojjBCSW7DnPDGGLSrx8 /I8VwlaSWHT7M1R9vsSCnplMEDMFJU7OfMIygVF4FpJRs5CUzUJSNgvoM2YBTYn1u/QhShQl pnQ/ZIewNSRa58xlRxZfwMi+ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwxg5u+a27g3H1 a8dDjAIcjEo8vBuiTocJsSaWFVfmHmKU4GBWEuGd1XMmTIg3JbGyKrUoP76oNCe1+BCjNAeL kjjvGuf1YUIC6YklqdmpqQWpRTBZJg5OqQbGKRvceX/OrAhJ+n7mr6Fxaelv/strP2Xmna8/ x7Ct1V37+7UfK3gnnL7OxHpN1KTh067wq4ePFKX4NTSzzbmyvdeQwcCIpVI2MPiZlT4Ll97n NBMG3hbWaxyJ8xd+mfimOUoosbNNKYGtrmX69Qfzyv+v1Xjz8WtL/LkX1384tkwvTPDPKjdR YinOSDTUYi4qTgQAeF3txK0CAAA= Archived-At: Cc: Colin Perkins , Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - 3pcc 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, 23 Feb 2016 18:26:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E3C851ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCuKApi4NCg0KPiAzLiBQVCByZXVzZSBpbiBzZXNzaW9ucyBzdWNoIGFzIG9uZSB0cmln Z2VyZWQgYnkgM3BjYyB3aGVyZSBpdCB3b3VsZCBiZSBpbXBvc3NpYmxlIHRvIGVuZm9yY2UgUFQg ZnJvbSBldmVyIGJlaW5nIHJldXNlZC4NCg0KQXNzdW1pbmcgeW91IGFyZSB0YWxraW5nIGFib3V0 IHRoZSAzcGNjIGNhc2Ugd2hlcmUgYW4gZW1wdHkgU0lQIChyZS0pSU5WSVRFIHJlcXVlc3QgdHJp Z2dlcnMgYW4gb2ZmZXIgaW4gdGhlIFNJUCByZXNwb25zZSwgdGhlIChyZS0pSU5WSVRFIGNvdWxk IGFsd2F5cyBjb250YWluIGluZm9ybWF0aW9uICjigJxkZWNsYXJhdGl2ZSBTRFDigJ0sIGlmIHlv dSBsaWtlKSBhYm91dCB3aGF0IFBUL2NvZGVjIG1hcHBpbmdzIGFyZSBjdXJyZW50bHkgYXZhaWxh YmxlIGluIHRoZSBzZXNzaW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37E3C851ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFy Z2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls 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 LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKApi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDMuIFBU IHJldXNlIGluIHNlc3Npb25zIHN1Y2ggYXMgb25lIHRyaWdnZXJlZCBieSAzcGNjIHdoZXJlIGl0 IHdvdWxkIGJlIGltcG9zc2libGUgdG8gZW5mb3JjZSBQVCBmcm9tIGV2ZXIgYmVpbmcgcmV1c2Vk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkFzc3VtaW5nIHlvdSBhcmUgdGFsa2luZyBhYm91dCB0aGUgM3BjYyBjYXNlIHdo ZXJlIGFuIGVtcHR5IFNJUCAocmUtKUlOVklURSByZXF1ZXN0IHRyaWdnZXJzIGFuIG9mZmVyIGlu IHRoZSBTSVAgcmVzcG9uc2UsIHRoZSAocmUtKUlOVklURSBjb3VsZCBhbHdheXMgY29udGFpbiBp bmZvcm1hdGlvbg0KICjigJxkZWNsYXJhdGl2ZSBTRFDigJ0sIGlmIHlvdSBsaWtlKSBhYm91dCB3 aGF0IFBUL2NvZGVjIG1hcHBpbmdzIGFyZSBjdXJyZW50bHkgYXZhaWxhYmxlIGluIHRoZSBzZXNz aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37E3C851ESESSMB209erics_-- From nobody Tue Feb 23 10:30: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 7BC5E1B40BC for ; Tue, 23 Feb 2016 10:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 qJYGPc03zOIq for ; Tue, 23 Feb 2016 10:29:58 -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 EFF8D1B40A4 for ; Tue, 23 Feb 2016 10:29:47 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id g6so117975631igt.1 for ; Tue, 23 Feb 2016 10:29:47 -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; bh=LS97xJ0VSyyF45vT5oW4XeLKv0sJvvwVRcVgRl0ysaE=; b=cTLKn3bKn9Vg0EOYJ7sB+IHhOpLJLz2YucOWJz+lIiTY67cKcY25CGH9iQ8gzffyIb ZRDrlRGvyNDM2EaDp4b09JO/twwMSPGQh2D8DwcVLOmlg7kh+/foz3Q5Pgv2LaJoWsvj Pu+HxQf0wSBtre2nmX8Srub8QN8/+luF9cCFOSukUQ6IIQf+nq3TubxueWwNzHQuwsxX SFpGKpYPR8LJ36/xsSJ1DuLkzFtWSByRC2M+Xh1uRR66iRAsnfnCG5glNHHHfiZynre2 9+KOjajrsmMeQhfvojC6j8asr47kRr1ET3gnSLBN+VtysC76mBMoqIj5+VYDEOyUHNPL qgvA== 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; bh=LS97xJ0VSyyF45vT5oW4XeLKv0sJvvwVRcVgRl0ysaE=; b=FT42plhOf8rai7WoAUev4asGo+e6hERGKBDlVEtDWqwDvHSdveHopXq0Qdt8kdGsuE youNSRCvzSLPbXgseEI0KPgsaKck0G/NPKybLx8YVzkhSwTEqH0Jgrpt8MmMTVytwH/7 1vVgrLMZP3Odb6WtiWdu7/m3KRvuGuvNd6A/cu65AkLgmExbGRWskJ8FtrAhL+rpEjep ntv2E/tyxOPiwDN54X6iUWwGs3W3NVyb1ZTIgeNP/AXjXJPQRduaetZm2Ci4jDLODeMS kV3pj5Bq2RSTOta7Q8DaqkcbpHxZ5whMKBB2mb0yRe/KB88Wnckz9Ld6FBzlRomMjRJS yVhQ== X-Gm-Message-State: AG10YOSsw3MDnlYGiDuNJq8UZTRgU4Be5QfmDWLhKu2a9++noCZEkjQZ1d0VApQlBcxFeA== X-Received: by 10.50.43.133 with SMTP id w5mr17510233igl.80.1456252187429; Tue, 23 Feb 2016 10:29:47 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id pk7sm11669179igb.17.2016.02.23.10.29.45 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 10:29:46 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id z8so14359108ige.0 for ; Tue, 23 Feb 2016 10:29:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.28.48 with SMTP id y16mr18887235igg.2.1456252185451; Tue, 23 Feb 2016 10:29:45 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 23 Feb 2016 10:29:45 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E3C851@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E3C851@ESESSMB209.ericsson.se> Date: Tue, 23 Feb 2016 13:29:45 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0158b36037aa47052c742207 Archived-At: Cc: Colin Perkins , Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - 3pcc 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, 23 Feb 2016 18:29:59 -0000 --089e0158b36037aa47052c742207 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 23, 2016 at 1:26 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > 3. PT reuse in sessions such as one triggered by 3pcc where it would be > impossible to enforce PT from ever being reused. > > > > Assuming you are talking about the 3pcc case where an empty SIP > (re-)INVITE request triggers an offer in the SIP response, the (re-)INVIT= E > could always contain information (=E2=80=9Cdeclarative SDP=E2=80=9D, if y= ou like) about > what PT/codec mappings are currently available in the session. > > > 3pcc can be used to connect two existing sessions. This means empty SIP re-INVITE should carry the information about the existing PT in the session. I am not aware of any specification that proposes a mechanism to do this. _____________ Roman Shpount --089e0158b36037aa47052c742207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 23, 2016 at 1:26 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

> 3. PT reuse in sessions such as one triggered b= y 3pcc where it would be impossible to enforce PT from ever being reused.

=C2=A0

Assuming you are talking about the 3pcc case where an empty SIP (= re-)INVITE request triggers an offer in the SIP response, the (re-)INVITE c= ould always contain information (=E2=80=9Cdeclarative SDP=E2=80=9D, if you like) about what PT/codec mappi= ngs are currently available in the session.



3pcc can be used to connect two existing sessions.= This means empty SIP re-INVITE should carry the information about the exis= ting PT in the session. I am not aware of any specification that proposes a= mechanism to do this.
___________= __
Roman Shpount
=C2=A0
--089e0158b36037aa47052c742207-- From nobody Tue Feb 23 11:01: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 6F8F81A885B for ; Tue, 23 Feb 2016 11:01: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_21=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 vJGXVrQzAeRH for ; Tue, 23 Feb 2016 11:01:57 -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 443181A1B6D for ; Tue, 23 Feb 2016 11:01:57 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with comcast id Mv0F1s0052N9P4d01v1wvq; Tue, 23 Feb 2016 19:01:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id Mv1w1s0013KdFy101v1wqr; Tue, 23 Feb 2016 19:01:56 +0000 To: mmusic@ietf.org References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <56CC7E68.4040103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CCACA3.4030007@alum.mit.edu> Date: Tue, 23 Feb 2016 14:01:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: 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=1456254116; bh=LeJ3B0qCt2UEkiyFkPui81/Nvy787nuV2nfJO97IlcI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gkjL1lgKS8V0+1bDQNloxmjsRg0YvGB5YXa52vNa7dw9tQGOSTCa4K4TSqOtZ07IB 1DXSOPyoTwfNRtD6fOwyMKnn5XQyjd+j/3zZT2NrbaFRVIU4U2soxow7qKD6qPCS8M mbuFW17okymh+R9/W9MTuDRia3N44uJu6dNFPOoTB6udGp5pWRDPakhG+XMfhhlAuY 2LSGk+T/gkGJCCAZ1dmWRhdkZ35aCwHoeZUtoVaGcHvrjLW2TkC4uEvR1OOosIADqM jxG7tJ2ZGRvQYgCrxP5bWzUV7HwlSjrZwNamXR2vIWtW5mh0RrSaXh7UpGb74w/p1X pwpIsVyjtyokA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 19:01:58 -0000 On 2/23/16 1:22 PM, Roman Shpount wrote: > On Tue, Feb 23, 2016 at 1:04 PM, Christer Holmberg > > > wrote: > > The current rule may be easy to understand, but it's difficult to > understand - and that's what triggered this discussion :) > > So, while we can discuss possible rules/guidelines on when a PT > value can be used, I still think we need to answer the first question: > > - If Alice allocates PT=X for codec 1, is Bob allowed to allocate > PT=X for codec 2 within the same session? The current text is > unclear on that, and I think that is the first question we need to > sort out. > > After that, we can discuss whether e.g. Alice at some point can > allocate PT=X for codec 3, and what the criteria for that is. > > > As far as I can see there are 3 question/clarifications that are required: > > 1. PT is allocated per codec profile (codec and all associated > parameters), not codec. For instance, if end point uses PT=100 for > SILK/8000, it cannot reuse it for SILK/16000 > > 2. Is PT blocked from each direction independently or both directions at > the same time. For instance if A sent an offer with PT=100, but B never > sent an offer or an answer with PT=100, can B sent an offer with PT=100? > > 3. PT reuse in sessions such as one triggered by 3pcc where it would be > impossible to enforce PT from ever being reused. Note that in general the 3pcc case has other issues besides PT reuse. It is only "simple" if we assume that everybody is using only a single audio session. If we get beyond that there is the matter of matching the number of m-lines and their media types. So it may be that we should separate it from the others. Thanks, Paul From nobody Tue Feb 23 11:02: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 0C12C1A8896 for ; Tue, 23 Feb 2016 11:02:30 -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 Uqe_8lVqw3ng for ; Tue, 23 Feb 2016 11:02:29 -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 41C031A8892 for ; Tue, 23 Feb 2016 11:02:29 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with comcast id Muyp1s0052XD5SV01v2USA; Tue, 23 Feb 2016 19:02:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id Mv2T1s00F3KdFy101v2TLR; Tue, 23 Feb 2016 19:02:28 +0000 To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B37E3C851@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CCACC3.6090709@alum.mit.edu> Date: Tue, 23 Feb 2016 14:02:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456254148; bh=/MCvUYe76lmdr4f57bhag+Bpf3Wk07dzrhsHTy0Iy1E=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=a7qDyJ++IOKu7Hm4ql1N3ZarDd3oniuBRwDi9U12tHv+0hNHTZM99hy5z8oaadJhc hCMe3+oGzw2yPjhWMPlXk4vYdfu/bG/jupRTgLEilVMAFKOqVUUyI/pu13IMAX8dhh UC9yNKeYyTHcb5b2Wp69tQjz7E5p0+QGtWHvTrDHZhBRnR5CQGdzWO60MGOI49PYjM l6/gkqmox+H/ySjajXYo/4K59j48aI/YiDJGUj8UmOIRRAD2FkDJD2PxP4EVUjMFZ+ aS9J0Rdf2sJeAIX4UPM0bdmKEVvjn3tQYaCPZrz0THpWRXyN7xUloGiPQ+S4UCFV9b BLOOtcbZYwiWA== Archived-At: Cc: Colin Perkins , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - 3pcc 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, 23 Feb 2016 19:02:30 -0000 On 2/23/16 1:29 PM, Roman Shpount wrote: > On Tue, Feb 23, 2016 at 1:26 PM, Christer Holmberg > > > wrote: > > > 3. PT reuse in sessions such as one triggered by 3pcc where it > would be impossible to enforce PT from ever being reused. > > __ > > __ __ > > Assuming you are talking about the 3pcc case where an empty SIP > (re-)INVITE request triggers an offer in the SIP response, the > (re-)INVITE could always contain information (“declarative SDP”, if > you like) about what PT/codec mappings are currently available in > the session. ____ > > > > 3pcc can be used to connect two existing sessions. This means empty SIP > re-INVITE should carry the information about the existing PT in the > session. I am not aware of any specification that proposes a mechanism > to do this. Yes - there is no existing mechanism to deliver this "declarative SDP" so that it is understood to not be an offer. Thanks, Paul From nobody Tue Feb 23 11:14: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 761511A9046 for ; Tue, 23 Feb 2016 11:14:05 -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 1-Picxmj2MUN for ; Tue, 23 Feb 2016 11:14:02 -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 892671A8AF5 for ; Tue, 23 Feb 2016 11:14:01 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-60-56ccaf77fa40 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.AE.15637.77FACC65; Tue, 23 Feb 2016 20:13:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 20:13:15 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text episode II Thread-Index: AdFubhZJutt6f+meQmuux+xz3PmWZQ== Date: Tue, 23 Feb 2016 19:13:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3C98E@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-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbE9RLd8/Zkwg4V71SymLn/MYrFiwwFW i2vLX7NazLgwldmBxePv+w9MHgs2lXosWfKTyePWlIIAligum5TUnMyy1CJ9uwSujH/X1jEW 3JrLWHHo9E62BsYrMxm7GDk5JARMJDb+PQxli0lcuLeerYuRi0NI4DCjxJG3B6GcxYwSbetb gRwODjYBC4nuf9ogDSIC3hIT5q9mA7GZBboZJdr/C4CUCAvESUz5GQlREi9xvOcyK4StJ/Hl 6xN2EJtFQFViz8ltYHt5BXwlztxYyAJiMwLd8P3UGiaIkeISt57MZ4K4TUBiyZ7zzBC2qMTL x/9YIWwliUW3PzOBrGUW0JRYv0sfolVRYkr3Q3aI8YISJ2c+YZnAKDILydRZCB2zkHTMQtKx gJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgxBzc8lt1B+PlN46HGAU4GJV4eDdEnQ4T Yk0sK67MPcQowcGsJMI7q+dMmBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeNc7rw4QE0hNLUrNT UwtSi2CyTBycUg2Mmg9Edn+Md5BdGJXNFZivEpgXz3H/B+e5QD413iMfYx+snJTVuHBLWNSR y69uaU8UyJH42LPlqN98E2aJxmNFHe+6L4gudClo//FqZ7P5h+JNb36aq17hX5GZOyHkVLLH pP36leI3b060YVA6rNz/xsD5hlpH7fXqpP/mr9Smnvc947w2+HWqEktxRqKhFnNRcSIAlN0C f5QCAAA= Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text episode II 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, 23 Feb 2016 19:14:05 -0000 TmV3IHRyeS4uLg0KDQooTm90ZSB0aGF0IEkgaGF2ZSBhbHNvIHJlcGxhY2VkIHRoZSByZWZlcmVu Y2UgdG8gUkZDIDUyNDUgd2l0aCBhIHJlZmVyZW5jZSB0byBkcmFmdC01MjQ1YmlzKQ0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KMTEuICBJQ0UgQ29uc2lkZXJhdGlvbnMNCg0KMTEuMS4gIEdl bmVyYWwNCg0KICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBob3cgdG8gdXNlIHRoZSBCVU5ETEUg Z3JvdXBpbmcgZXh0ZW5zaW9uDQogICB0b2dldGhlciB3aXRoIHRoZSBJbnRlcmFjdGl2ZSBDb25u ZWN0aXZpdHkgRXN0YWJsaXNobWVudCAoSUNFKQ0KICAgbWVjaGFuaXNtIFtJLUQuaWV0Zi1pY2Ut cmZjNTI0NWJpc10uDQoNCiAgIFRoZSBnZW5lcmljIHByb2NlZHVyZXMgZm9yIG5lZ290aWF0aW5n IHVzYWdlIG9mIElDRSB1c2luZyBTRFAsDQogICBkZWZpbmVkIGluIFtJLUQuaWV0Zi1tbXVzaWMt aWNlLXNpcC1zZHBdLCBhbHNvIGFwcGx5IHRvIHVzYWdlIG9mIElDRQ0KICAgd2l0aCBCVU5ETEUs IHdpdGggdGhlIGZvbGxvd2luZyBleGNlcHRpb25zOg0KDQogICBvICBXaGVuIEJVTkRMRSBhZGRy ZXNzZXMgZm9yIGEgQlVORExFIGdyb3VwIGhhdmUgYmVlbiBzZWxlY3RlZCBmb3INCiAgICAgIGJv dGggZW5kcG9pbnRzLCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBhbmQga2VlcC1hbGl2ZXMgb25s eSBuZWVkDQogICAgICB0byBiZSBwZXJmb3JtZWQgZm9yIHRoZSB3aG9sZSBCVU5ETEUgZ3JvdXAs IGluc3RlYWQgb2YgcGVyIGJ1bmRsZWQNCiAgICAgICJtPSIgbGluZS4NCg0KICAgbyAgQW1vbmcg YnVuZGxlZCAibT0iIGxpbmVzIHdpdGggd2hpY2ggdGhlIG9mZmVyZXIgaGFzIGFzc29jaWF0ZWQg YQ0KICAgICAgc2hhcmVkIGFkZHJlc3MsIHRoZSBvZmZlcmVyIG9ubHkgYXNzb2NpYXRlcyBJQ0Ut cmVsYXRlZCBtZWRpYS0NCiAgICAgIGxldmVsIFNEUCBhdHRyaWJ1dGVzIHdpdGggdGhlICJtPSIg bGluZSBhc3NvY2lhdGVkIHdpdGggdGhlDQogICAgICBvZmZlcmVyIEJVTkRMRS10YWcuDQoNCiAg IG8gIEFtb25nIGJ1bmRsZWQgIm09IiBsaW5lcyB3aXRoIHdoaWNoIHRoZSBhbnN3ZXJlciBoYXMg YXNzb2NpYXRlZCBhDQogICAgICBzaGFyZWQgYWRkcmVzcywgdGhlIGFuc3dlcmVyIG9ubHkgYXNz b2NpYXRlcyBJQ0UtcmVsYXRlZCBtZWRpYS0NCiAgICAgIGxldmVsIFNEUCBhdHRyaWJ1dGVzIHdp dGggdGhlICJtPSIgbGluZSBhc3NvY2lhdGVkIHdpdGggdGhlDQogICAgICBhbnN3ZXJlciBCVU5E TEUtdGFnLg0KDQogICBTdXBwb3J0IGFuZCB1c2FnZSBvZiBJQ0UgbWVjaGFuaXNtIHRvZ2V0aGVy IHdpdGggdGhlIEJVTkRMRSBleHRlbnNpb24NCiAgIGlzIE9QVElPTkFMLg0KDQoxMS4yLiAgU0RQ IE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzDQoNCjExLjIuMS4gIEdlbmVyYWwNCg0KICAgV2hlbiBh biBvZmZlcmVyIGFzc29jaWF0ZXMgYSB1bmlxdWUgYWRkcmVzcyB3aXRoIGEgYnVuZGxlZCAibT0i IGxpbmUNCiAgIChleGNsdWRpbmcgYW55IGJ1bmRsZS1vbmx5ICJtPSIgbGluZSksIHRoZSBvZmZl cmVyIE1VU1QgYXNzb2NpYXRlIFNEUA0KICAgJ2NhbmRpZGF0ZScgYXR0cmlidXRlcyAoYW5kIG90 aGVyIGFwcGxpY2FibGUgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwNCiAgIFNEUCBhdHRyaWJ1dGVz KSwgY29udGFpbmluZyB1bmlxdWUgSUNFIHByb3BlcnRpZXMgKGNhbmRpZGF0ZXMgZXRjKSwNCiAg IHdpdGggdGhlICJtPSIgbGluZSwgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzIGluDQogICBb SS1ELmlldGYtbW11c2ljLWljZS1zaXAtc2RwXS4NCg0KICAgV2hlbiBhbiBvZmZlcmVyIGFzc29j aWF0ZXMgYSBzaGFyZWQgYWRkcmVzcyB3aXRoIGEgYnVuZGxlZCAibT0iDQogICBsaW5lcywgaWYg dGhlICJtPSIgbGluZSBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIG9mZmVyZXIgQlVORExFLXRhZywN CiAgIHRoZSBvZmZlcmVyIE1VU1QgYXNzb2NpYXRlIFNEUCAnY2FuZGlkYXRlJyBhdHRyaWJ1dGVz IChhbmQgb3RoZXINCiAgIGFwcGxpY2FibGUgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQIGF0 dHJpYnV0ZXMpLCBjb250YWluaW5nIHNoYXJlZA0KICAgSUNFIHByb3BlcnRpZXMsIHdpdGggdGhl ICJtPSIgbGluZS4gIElmIHRoZSAibT0iIGxpbmUgaXMgbm90DQogICBhc3NvY2lhdGVkIHdpdGgg dGhlIG9mZmVyZXIgQlVORExFLXRhZywgdGhlIG9mZmVyZXIgTVVTVCBOT1QNCiAgIGFzc29jaWF0 ZSBJQ0UtcmVsYXRlZCBTRFAgYXR0cmlidXRlcyB3aXRoIHRoZSAibT0iIGxpbmUuDQoNCiAgIFdo ZW4gYW4gYW5zd2VyZXIgYXNzb2NpYXRlcyBhIHNoYXJlZCBhZGRyZXNzIHdpdGggYSBidW5kbGVk ICJtPSINCiAgIGxpbmVzLCBpZiB0aGUgIm09IiBsaW5lIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUg YW5zd2VyZXIgQlVORExFLXRhZywNCiAgIHRoZSBhbnN3ZXJlciBNVVNUIGFzc29jaWF0ZSBTRFAg J2NhbmRpZGF0ZScgYXR0cmlidXRlcyAoYW5kIG90aGVyDQogICBhcHBsaWNhYmxlIElDRS1yZWxh dGVkIG1lZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGVzKSwgY29udGFpbmluZyBzaGFyZWQNCiAgIElD RSBwcm9wZXJ0aWVzLCB3aXRoIHRoZSAibT0iIGxpbmUuICBJZiB0aGUgIm09IiBsaW5lIGlzIG5v dA0KICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBhbnN3ZXJlciBCVU5ETEUtdGFnLCB0aGUgYW5zd2Vy ZXIgTVVTVCBOT1QNCiAgIGFzc29jaWF0ZSBJQ0UtcmVsYXRlZCBTRFAgYXR0cmlidXRlcyB3aXRo IHRoZSAibT0iIGxpbmUuDQoNCiAgIE5PVEU6IEFzIGJ1bmRsZWQgIm09IiBsaW5lcyBhc3NvY2lh dGVkIHdpdGggYSBzaGFyZWQgYWRkcmVzcyB3aWxsDQogICBzaGFyZSB0aGUgc2FtZSBJQ0UgcHJv cGVydGllcywgdGhlcmUgaXMgbm8gbmVlZCB0byBhc3NvY2lhdGVkIElDRS0NCiAgIHJlbGF0ZWQg bWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0ZXMgd2l0aCBlYWNoICJtPSIgbGluZS4NCg0KICAgTk9U RTogVGhlIGZvbGxvd2luZyBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyBh cmUNCiAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcF06ICdjYW5kaWRp YXRlJywgJ3JlbW90ZS0NCiAgIGNhbmRpZGF0ZXMnLCAnaWNlLW1pc21hdGNoJywgJ2ljZS11ZnJh ZycsICdpY2UtcHdkJywgYW5kICdpY2UtDQogICBwYWNpbmcnLg0KDQoxMS4yLjIuICBHZW5lcmF0 aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcg0KDQogICBXaGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVz IGFuIGluaXRpYWwgb2ZmZXIsIHRoZSBvZmZlcmVyIE1VU1QNCiAgIGFzc29jaWF0ZSBJQ0UtcmVs YXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyB3aXRoIGVhY2ggYnVuZGxlZA0KICAgIm09 IiBsaW5lLCBhY2NvcmRpbmcgdG8gW1NlY3Rpb24gMTEuMi4xXS4NCg0KMTEuMi4zLiAgR2VuZXJh dGluZyB0aGUgU0RQIEFuc3dlcg0KDQogICBXaGVuIGFuIGFuc3dlcmVyIGdlbmVyYXRlcyBhbiBh bnN3ZXIgdGhhdCBjb250YWlucyBhIEJVTkRMRSBncm91cCwNCiAgIHRoZSBhbnN3ZXJlciBNVVNU IGFzc29jaWF0ZWQgSUNFLXJlbGF0ZWQgU0RQIGF0dHJpYnV0ZXMgd2l0aCB0aGUgIm09Ig0KICAg bGluZSBhc3NvY2lhdGVkIHdpdGggdGhlIGFuc3dlcmVyIEJVTkRMRS10YWcsIGFjY29yZGluZyB0 bw0KICAgW1NlY3Rpb24gMTEuMi4xXS4NCg0KMTEuMi40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9m IHRoZSBTRFAgQW5zd2VyDQoNCiAgIFdoZW4gYW4gb2ZmZXJlciByZWNlaXZlcyBhbiBhbnN3ZXIs IGlmIHRoZSBhbnN3ZXJlciBzdXBwb3J0cyBhbmQgdXNlcw0KICAgdGhlIElDRSBtZWNoYW5pc20g YW5kIHRoZSBCVU5ETEUgZXh0ZW5zaW9uLCB0aGUgb2ZmZXJlciBNVVNUDQogICBhc3NvY2lhdGUg dGhlIElDRSBwcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgb2ZmZXJlciBCVU5ETEUNCiAg IGFkZHJlc3MsIHNlbGVjdGVkIGJ5IHRoZSBhbnN3ZXJlciBbU2VjdGlvbiA4LjMuMl0sIHdpdGgg ZWFjaCBidW5kbGVkDQogICAibT0iIGxpbmUuDQoNCjExLjIuNS4gIE1vZGlmeWluZyB0aGUgU2Vz c2lvbg0KDQogICBXaGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGEgc3Vic2VxdWVudCBvZmZlciwg aXQgTVVTVCBhc3NvY2lhdGVkDQogICB1bmlxdWUgb3Igc2hhcmVkIElDRSBwcm9wZXJ0aWVzIHRv IG9uZSBvciBtb3JlIGJ1bmRsZWQgIm09IiBsaW5lcywNCiAgIGFjY29yZGluZyB0byBbU2VjdGlv biAxMS4yLjFdLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCBbbWFp bHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0gDQpTZW50OiAyMiBGZWJydWFyeSAyMDE2IDIyOjI1 DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47 IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KQ2M6IG1tdXNpY0BpZXRmLm9yZzsg UGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBnb29nbGUuY29tPjsgQXJpIEtlcsOkbmVuIDxhcmku a2VyYW5lbkBlcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gUXVlc3Rpb25zIGFi b3V0IElDRSBjYW5kaWRhdGVzIHdpdGggQlVORExFIC0gc3VnZ2VzdGVkIHRleHQNCg0KT24gMi8y Mi8xNiAzOjE4IFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSGkgUGF1bCwNCj4NCj4g SSBhbSB0cnlpbmcgdG8gZm9sbG93IHRoZSBzYW1lIHN0eWxlIGFzIEJVTkRMRSBpbiBnZW5lcmFs LiBZZXMsIEkga25vdyBpdCdzIG1lc3N5LCBhbmQgSSd2ZSBsb3N0IGNvdW50IG9mIHRoZSBudW1i ZXIgb2YgdGltZXMgSSd2ZSBoYWQgdG8gcmUtd3JpdGUgZXZlcnl0aGluZywgYnV0IEkgYW0gbm90 IGdvaW5nIHRvIGRvIGl0IGFnYWluLg0KDQpZZXMsIEkgdW5kZXJzdGFuZCwgYW5kIGFwcHJlY2lh dGUgaG93IGRpZmZpY3VsdCBpdCBoYXMgYmVlbiB0byBnZXQgc29tZXRoaW5nIHRoYXQgZXZlcnlv bmUgY2FuIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGguDQoNCj4gTm93LCBJIGRpZCBwdXQgdG9n ZXRoZXIgdGhlIG5ldyBJQ0UgdGV4dCByYXRoZXIgcXVpY2tseSwgc28gdGhlcmUgbWF5IGJlIHNv bWUgbWlzdGFrZXMsIHRob3VnaC4NCg0KSSAqdGhpbmsqIGl0IGlzIG9ubHkgdGhlIG9uZSBwbGFj ZSB0aGF0IGlzIHByb2JsZW1hdGljLCBhbmQgSSB0aGluayBpdCBpcyBpbiBuZXcgdGV4dC4gQW5k IHNpbmNlIGl0IGlzIHRoZSBvbmUgdGhhdCBoYXMgZGlmZmVyZW50IG1lYW5pbmcgdGhhbiB0aGUg b3RoZXJzLCBjaGFuZ2luZyB0aGUgd29yZGluZyBmb3IgaXQgc2hvdWxkbid0IGRpc3J1cHQgYW55 dGhpbmcgZWxzZS4NCg0KCVRoYW5rcywNCglQYXVsDQoNCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0 ZXINCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBLeXppdmF0 IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XQ0KPiBTZW50OiAyMiBGZWJydWFyeSAyMDE2 IDIyOjE0DQo+IFRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT47IENocmlzdGVy IEhvbG1iZXJnIA0KPiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPiBDYzogbW11 c2ljQGlldGYub3JnOyBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb20+OyBBcmkg DQo+IEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+DQo+IFN1YmplY3Q6IFJlOiBb TU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQgSUNFIGNhbmRpZGF0ZXMgd2l0aCBCVU5ETEUgLSANCj4g c3VnZ2VzdGVkIHRleHQNCj4NCj4gQ2hyaXN0ZXIsDQo+DQo+IFtJJ20gcmVwbHlpbmcgdG8gQ2hy aXN0ZXIsIG5vdCBSb21hbi4gRm9yIHNvbWUgcmVhc29uIEkgY2FuJ3QgZmluZCANCj4gQ2hyaXN0 ZXIncyBvcmlnaW5hbCBtZXNzYWdlIGluIG15IGVtYWlsLl0NCj4NCj4gVGhpcyBnZW5lcmFsbHkg c2VlbXMgZ29vZCB0byBtZS4gSSBub3RpY2VkIG9uZSB0aGluZzoNCj4NCj4gV2hpbGUgSSB1bmRl cnN0YW5kIHRoZSBpbnRlbnQsIHlvdSBhcmUgdXNpbmcgImFzc29jaWF0ZSIsICJhc3NvY2lhdGVz Ig0KPiBvciAiYXNzb2NpYXRlZCIgaW4gbXVsdGlwbGUgd2F5cywgdGhhdCBtYXkgYmUgY29uZnVz aW5nIHRvIHNvbWUgcmVhZGVycy4NCj4gRS5nLjoNCj4NCj4gICAgICBvICBBbW9uZyBidW5kbGVk ICJtPSIgbGluZXMgd2l0aCB3aGljaCB0aGUgb2ZmZXJlciBoYXMgYXNzb2NpYXRlZCBhDQo+ICAg ICAgICAgc2hhcmVkIGFkZHJlc3MsIHRoZSBvZmZlcmVyIG9ubHkgYXNzb2NpYXRlcyBJQ0UtcmVs YXRlZCBtZWRpYS0NCj4gICAgICAgICBsZXZlbCBTRFAgYXR0cmlidXRlcyB3aXRoIHRoZSAibT0i IGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiAgICAgICAgIG9mZmVyZXIgQlVORExFLXRhZy4N Cj4gLi4uDQo+ICAgICAgTk9URTogVGhlIGJ1bmRsZS1vbmx5ICJtPSIgbGluZSwgaWYgYWNjZXB0 ZWQgYnkgdGhlIGFuc3dlcmVyLCB3aWxsDQo+ICAgICAgaW5oZXJpdCB0aGUgY2FuZGlkYXRlcyBh c3NvY2lhdGVkIHdpdGggdGhlIHNlbGVjdGVkIG9mZmVyZXIgQlVORExFDQo+ICAgICAgYWRkcmVz cy4gIEFuIGFuc3dlcmVyIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBCVU5ETEUgd291bGQgbm90IGFj Y2VwdCBhDQo+ICAgICAgYnVuZGxlLW9ubHkgIm09IiBsaW5lLg0KPiAuLi4NCj4gICAgICBXaGVu IGFuIG9mZmVyZXIgb3IgYW5zd2VyZXIgYXNzb2NpYXRlcyBhIHNoYXJlZCBhZGRyZXNzIChpLmUu IGENCj4gICAgICBwcmV2aW91c2x5IHNlbGVjdGVkIEJVTkRMRSBhZGRyZXNzKSB3aXRoIG9uZSBv ciBtb3JlIGJ1bmRsZWQgIm09Ig0KPiAgICAgIGxpbmVzLCB0aGUgb2ZmZXJlciAob3IgYW5zd2Vy ZXIpIE1VU1Qgb25seSBhc3NvY2lhdGUgU0RQICdjYW5kaWRhdGUnDQo+ICAgICAgYXR0cmlidXRl cyB3aXRoIHRoZSAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBvZmZlcmVyIEJVTkRMRS10 YWcNCj4gICAgICAob3IgdGhlIGFuc3dlcmVyIEJVTkRMRS10YWcpIGFkZHJlc3MpLiAgVGhlIG9m ZmVyZXIgb3IgYW5zd2VyZXIgTVVTVA0KPiAgICAgIE5PVCBhc3NvY2lhdGUgJ2NhbmRpZGlhdGUn IGF0dHJpYnV0ZXMgd2l0aCBhbnkgb3RoZXIgYnVuZGxlZCAibT0iDQo+ICAgICAgbGluZSB0byB3 aGljaCB0aGUgb2ZmZXJlciAob3IgYW5zd2VyZXIpIGFzc29jaWF0ZXMgYSBzaGFyZWQgYWRkcmVz cy4NCj4gLi4uDQo+ICAgICAgV2hlbiBhbiBvZmZlcmVyIHJlY2VpdmVzIGFuIGFuc3dlciwgaWYg dGhlIGFuc3dlcmVyIHN1cHBvcnRzIGFuZCB1c2VzDQo+ICAgICAgdGhlIElDRSBtZWNoYW5pc20g YW5kIHRoZSBCVU5ETEUgZXh0ZW5zaW9uLCB0aGUgb2ZmZXJlciBNVVNUDQo+ICAgICAgYXNzb2Np YXRlIHRoZSBzYW1lIElDRSBjYW5kaWRhdGVzLCBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGlu ZQ0KPiAgICAgIHJlcHJlc2VudGluZyB0aGUgb2ZmZXJlciBCVU5ETEUgYWRkcmVzcyAoc2VsZWN0 ZWQgYnkgdGhlIGFuc3dlcmVyKSwNCj4gICAgICB3aXRoIGVhY2ggYnVuZGxlZCAibT0iIGxpbmUu DQo+DQo+IFNvLCB3aGljaCBvbmUgb2YgdGhlc2UgdGhpbmdzIGlzIG5vdCBsaWtlIHRoZSBvdGhl cnM/IChUaGlzIGlzIGEgZ2FtZSANCj4gd2UgcGxheSB3aXRoIGtpZHMuIERvIHRoZXkgZG8gaXQg aW4gU3dlZGVuIHRvbz8pDQo+DQo+IEluIG1vc3QgY2FzZXMgdGhpcyBpcyB0YWxraW5nIGFib3V0 IHdoZXJlIHlvdSBwdXQgdGhpbmdzIGluIHRoZSBTRFAuIEJ1dCB0aGUgbGFzdCBvbmUgYWJvdmUg aXNuJ3QgdGhhdCAtIGl0IGlzIGFib3V0IHRoZSBpbXBsZW1lbnRhdGlvbiB0YWtpbmcgZGF0YSBm cm9tIHRoZSBhbnN3ZXIgYW5kIHVzaW5nIGl0IHRvIHVwZGF0ZSBpbnRlcm5hbCBkYXRhIHN0cnVj dHVyZXMuDQo+DQo+IEkgZG9uJ3QgaGF2ZSBhIHNwZWNpZmljIHN1Z2dlc3Rpb24gZm9yIGltcHJv dmluZyBpdC4gQnV0IEkgdGhpbmsgaXQgDQo+IHdvdWxkIGJlIGdvb2QgdG8gdXNlIHNvbWV0aW5n IG90aGVyIHRoYXQgImFzc29jaWF0ZSIgaW4gdGhpcyBjYXNlLiBJDQo+ICp0aGluayogaXQgaXMg dGhlIG9ubHkgcGxhY2Ugd2hlcmUgaXQgaXMgdXNlZCB0aGlzIHdheS4NCj4NCj4gCVRoYW5rcywN Cj4gCVBhdWwNCj4NCj4NCj4gT24gMi8yMi8xNiAyOjI5IFBNLCBSb21hbiBTaHBvdW50IHdyb3Rl Og0KPj4gT24gTW9uLCBGZWIgMjIsIDIwMTYgYXQgNToxMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg DQo+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIA0KPj4gPG1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KPj4gd3JvdGU6DQo+Pg0KPj4gICAgICBBc3N1bWlu ZyB3ZSB3aWxsIG9ubHkgYXNzb2NpYXRlZCBJQ0UgY2FuZGlkYXRlcyB0byB0aGUg4oCcbT3igJ0g bGluZQ0KPj4gICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIG9mZmVyZXIvYW5zd2VyZXIgQlVORExF LXRhZywgYmVsb3cgaXMgYSBmaXJzdA0KPj4gICAgICBzdWdnZXN0ZWQgb2YgbW9kaWZpZWQg4oCY SUNFIENvbnNpZGVyYXRpb25z4oCZIHRleHQ6DQo+Pg0KPj4gICAgICBfXyBfXw0KPj4NCj4+ICAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1fX19fDQo+Pg0KPj4gICAgICBfXyBfXw0KPj4NCj4+ ICAgICAgMTEuICBJQ0UgQ29uc2lkZXJhdGlvbnNfX19fDQo+Pg0KPj4gICAgICBfXyBfXw0KPj4N Cj4+ICAgICAgMTEuMS4gIEdlbmVyYWxfX19fDQo+Pg0KPj4gICAgICBfXyBfXw0KPj4NCj4+ICAg ICAgICAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaG93IHRvIHVzZSB0aGUgQlVORExFIGdyb3Vw aW5nIA0KPj4gZXh0ZW5zaW9uX19fXw0KPj4NCj4+ICAgICAgICAgIHRvZ2V0aGVyIHdpdGggdGhl IEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IA0KPj4gKElDRSlfX19fDQo+ Pg0KPj4gICAgICAgICAgbWVjaGFuaXNtIFtSRkM1MjQ1XS5fX19fDQo+Pg0KPj4gICAgICBfXyBf Xw0KPj4NCj4+ICAgICAgICAgIFRoZSBnZW5lcmljIHByb2NlZHVyZXMgZm9yIG5lZ290aWF0aW5n IHVzYWdlIG9mIElDRSB1c2luZyANCj4+IFNEUCxfX19fDQo+Pg0KPj4gICAgICAgICAgZGVmaW5l ZCBpbiBbSS1ELmlldGYtbW11c2ljLWljZS1zaXAtc2RwXSwgYWxzbyBhcHBseSB0byB1c2FnZSBv Zg0KPj4gICAgICBJQ0VfX19fDQo+Pg0KPj4gICAgICAgICAgd2l0aCBCVU5ETEUsIHdpdGggdGhl IGZvbGxvd2luZyBleGNlcHRpb25zOl9fX18NCj4+DQo+PiAgICAgIF9fIF9fDQo+Pg0KPj4gICAg ICAgICAgbyAgV2hlbiBCVU5ETEUgYWRkcmVzc2VzIGZvciBhIEJVTkRMRSBncm91cCBoYXZlIGJl ZW4gc2VsZWN0ZWQNCj4+ICAgICAgZm9yX19fXw0KPj4NCj4+ICAgICAgICAgICAgIGJvdGggZW5k cG9pbnRzLCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBhbmQga2VlcC1hbGl2ZXMgb25seQ0KPj4g ICAgICBuZWVkX19fXw0KPj4NCj4+ICAgICAgICAgICAgIHRvIGJlIHBlcmZvcm1lZCBmb3IgdGhl IHdob2xlIEJVTkRMRSBncm91cCwgaW5zdGVhZCBvZiBwZXINCj4+ICAgICAgYnVuZGxlZF9fX18N Cj4+DQo+PiAgICAgICAgICAgICAibT0iIGxpbmUuX19fXw0KPj4NCj4+ICAgICAgX18gX18NCj4+ DQo+PiAgICAgICAgICBvICBBbW9uZyBidW5kbGVkICJtPSIgbGluZXMgd2l0aCB3aGljaCB0aGUg b2ZmZXJlciBoYXMNCj4+ICAgICAgYXNzb2NpYXRlZCBhX19fXw0KPj4NCj4+ICAgICAgICAgICAg IHNoYXJlZCBhZGRyZXNzLCB0aGUgb2ZmZXJlciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJlbGF0ZWQN Cj4+ICAgICAgbWVkaWEtX19fXw0KPj4NCj4+ICAgICAgICAgICAgIGxldmVsIFNEUCBhdHRyaWJ1 dGVzIHdpdGggdGhlICJtPSIgbGluZSBhc3NvY2lhdGVkIHdpdGggDQo+PiB0aGVfX19fDQo+Pg0K Pj4gICAgICAgICAgICAgb2ZmZXJlciBCVU5ETEUtdGFnLl9fX18NCj4+DQo+PiAgICAgIF9fIF9f DQo+Pg0KPj4gICAgICAgICAgbyAgQW1vbmcgYnVuZGxlZCAibT0iIGxpbmVzIHdpdGggd2hpY2gg dGhlIGFuc3dlcmVyIGhhcw0KPj4gICAgICBhc3NvY2lhdGVkIGFfX19fDQo+Pg0KPj4gICAgICAg ICAgICAgc2hhcmVkIGFkZHJlc3MsIHRoZSBhbnN3ZXJlciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJl bGF0ZWQNCj4+ICAgICAgbWVkaWEtX19fXw0KPj4NCj4+ICAgICAgICAgICAgIGxldmVsIFNEUCBh dHRyaWJ1dGVzIHdpdGggdGhlICJtPSIgbGluZSBhc3NvY2lhdGVkIHdpdGggDQo+PiB0aGVfX19f DQo+Pg0KPj4gICAgICAgICAgICAgYW5zd2VyZXIgQlVORExFLXRhZy5fX19fDQo+Pg0KPj4gICAg ICBfXyBfXw0KPj4NCj4+ICAgICAgICAgIFN1cHBvcnQgYW5kIHVzYWdlIG9mIElDRSBtZWNoYW5p c20gdG9nZXRoZXIgd2l0aCB0aGUgQlVORExFDQo+PiAgICAgIGV4dGVuc2lvbl9fX18NCj4+DQo+ PiAgICAgICAgICBpcyBPUFRJT05BTC5fX19fDQo+Pg0KPj4gICAgICBfXyBfXw0KPj4NCj4+ICAg ICAgMTEuMi4gIFNEUCBPZmZlci9BbnN3ZXIgUHJvY2VkdXJlc19fX18NCj4+DQo+PiAgICAgIF9f IF9fDQo+Pg0KPj4gICAgICAxMS4yLjEuICBHZW5lcmFsX19fXw0KPj4NCj4+ICAgICAgX18gX18N Cj4+DQo+PiAgICAgICAgICBXaGVuIGFuIG9mZmVyZXIgYXNzb2NpYXRlcyBhIHVuaXF1ZSBhZGRy ZXNzIHdpdGggYSBidW5kbGVkICJtPSINCj4+ICAgICAgbGluZV9fX18NCj4+DQo+PiAgICAgICAg ICAoZXhjbHVkaW5nIGFueSBidW5kbGUtb25seSAibT0iIGxpbmUpLCBpdCBNVVNUIGFsc28gYXNz b2NpYXRlDQo+PiAgICAgIHVuaXF1ZV9fX18NCj4+DQo+PiAgICAgICAgICBJQ0UgY2FuZGlkYXRl cyB0byB0aGUgIm09IiBsaW5lLCBhY2NvcmRpbmcgdG8gdGhlIHByb2NlZHVyZXMgDQo+PiBpbl9f X18NCj4+DQo+PiAgICAgICAgICBbSS1ELmlldGYtbW11c2ljLWljZS1zaXAtc2RwXS5fX19fDQo+ Pg0KPj4gICAgICBfXyBfXw0KPj4NCj4+ICAgICAgICAgIEFuIG9mZmVyZXIgTVVTVCBOT1QgYXNz b2NpYXRlIElDRSBjYW5kaWRhdGVzIHdpdGggYSBidW5kbGUtb25seQ0KPj4gICAgICAibT0iX19f Xw0KPj4NCj4+ICAgICAgICAgIGxpbmUgd2l0aCBhIHplcm8gcG9ydCB2YWx1ZS5fX19fDQo+Pg0K Pj4gICAgICBfXyBfXw0KPj4NCj4+ICAgICAgICAgIE5PVEU6IFRoZSBidW5kbGUtb25seSAibT0i IGxpbmUsIGlmIGFjY2VwdGVkIGJ5IHRoZSBhbnN3ZXJlciwNCj4+ICAgICAgd2lsbF9fX18NCj4+ DQo+PiAgICAgICAgICBpbmhlcml0IHRoZSBjYW5kaWRhdGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUg c2VsZWN0ZWQgb2ZmZXJlcg0KPj4gICAgICBCVU5ETEVfX19fDQo+Pg0KPj4gICAgICAgICAgYWRk cmVzcy4gIEFuIGFuc3dlcmVyIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBCVU5ETEUgd291bGQgbm90 DQo+PiAgICAgIGFjY2VwdCBhX19fXw0KPj4NCj4+ICAgICAgICAgIGJ1bmRsZS1vbmx5ICJtPSIg bGluZS5fX19fDQo+Pg0KPj4gICAgICBfXyBfXw0KPj4NCj4+ICAgICAgICAgIFdoZW4gYW4gb2Zm ZXJlciBvciBhbnN3ZXJlciBhc3NvY2lhdGVzIGEgc2hhcmVkIGFkZHJlc3MgKGkuZS4NCj4+IGFf X19fDQo+Pg0KPj4gICAgICAgICAgcHJldmlvdXNseSBzZWxlY3RlZCBCVU5ETEUgYWRkcmVzcykg d2l0aCBvbmUgb3IgbW9yZSBidW5kbGVkDQo+PiAgICAgICJtPSJfX19fDQo+Pg0KPj4gICAgICAg ICAgbGluZXMsIHRoZSBvZmZlcmVyIChvciBhbnN3ZXJlcikgTVVTVCBvbmx5IGFzc29jaWF0ZSBT RFANCj4+ICAgICAgJ2NhbmRpZGF0ZSdfX19fDQo+Pg0KPj4gICAgICAgICAgYXR0cmlidXRlcyB3 aXRoIHRoZSAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBvZmZlcmVyDQo+PiAgICAgIEJV TkRMRS10YWdfX19fDQo+Pg0KPj4gICAgICAgICAgKG9yIHRoZSBhbnN3ZXJlciBCVU5ETEUtdGFn KSBhZGRyZXNzKS4gIFRoZSBvZmZlcmVyIG9yIGFuc3dlcmVyDQo+PiAgICAgIE1VU1RfX19fDQo+ Pg0KPj4gICAgICAgICAgTk9UIGFzc29jaWF0ZSAnY2FuZGlkaWF0ZScgYXR0cmlidXRlcyB3aXRo IGFueSBvdGhlciBidW5kbGVkDQo+PiAgICAgICJtPSJfX19fDQo+Pg0KPj4gICAgICAgICAgbGlu ZSB0byB3aGljaCB0aGUgb2ZmZXJlciAob3IgYW5zd2VyZXIpIGFzc29jaWF0ZXMgYSBzaGFyZWQN Cj4+ICAgICAgYWRkcmVzcy5fX19fDQo+Pg0KPj4gICAgICAgICAgVGhpcyBhbHNvIGFwcGx5IHRv IGFueSBvdGhlciBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFANCj4+ICAgICAgYXR0cmlidXRl Ll9fX18NCj4+DQo+PiAgICAgIF9fIF9fDQo+Pg0KPj4gICAgICAgICAgTk9URTogVGhlIGZvbGxv d2luZyBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyANCj4+IGFyZV9fX18N Cj4+DQo+PiAgICAgICAgICBkZWZpbmVkIGluIFtJLUQuaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHBd OiAnY2FuZGlkaWF0ZScsIA0KPj4gJ3JlbW90ZS1fX19fDQo+Pg0KPj4gICAgICAgICAgY2FuZGlk YXRlcycsICdpY2UtbWlzbWF0Y2gnLCAnaWNlLXVmcmFnJywgJ2ljZS1wd2QnLCBhbmQgDQo+PiAn aWNlLV9fX18NCj4+DQo+PiAgICAgICAgICBwYWNpbmcnLl9fX18NCj4+DQo+PiAgICAgIF9fIF9f DQo+Pg0KPj4gICAgICAxMS4yLjIuICBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcl9f X18NCj4+DQo+PiAgICAgIF9fIF9fDQo+Pg0KPj4gICAgICAgICAgV2hlbiBhbiBvZmZlcmVyIGdl bmVyYXRlcyBhbiBpbml0aWFsIG9mZmVyLCBpdCBhc3NvY2lhdGVzIHVuaXF1ZQ0KPj4gICAgICBJ Q0VfX19fDQo+Pg0KPj4gICAgICAgICAgY2FuZGlkYXRlcyB3aXRoIHRoZSBidW5kbGVkICJtPSIg bGluZXMsIGFjY29yZGluZyB0byBTZWN0aW9uDQo+PiAgICAgIDExLjIuMS5fX19fDQo+Pg0KPj4g ICAgICBfXyBfXw0KPj4NCj4+ICAgICAgMTEuMi4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dl cl9fX18NCj4+DQo+PiAgICAgIF9fIF9fDQo+Pg0KPj4gICAgICAgICAgV2hlbiBhbiBhbnN3ZXJl ciBnZW5lcmF0ZXMgYW4gYW5zd2VyIHRoYXQgY29udGFpbnMgYSBCVU5ETEUNCj4+ICAgICAgZ3Jv dXAsX19fXw0KPj4NCj4+ICAgICAgICAgIHRoZSBhbnN3ZXJlciBNVVNUIG9ubHkgYXNzb2NpYXRl IFNEUCAnY2FuZGlkYXRlJyBhdHRyaWJ1dGVzIA0KPj4gKGFuZF9fX18NCj4+DQo+PiAgICAgICAg ICBvdGhlciBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcykgd2l0aCB0aGUg Im09Ig0KPj4gbGluZV9fX18NCj4+DQo+PiAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIGFu c3dlcmVyIEJVTkRMRS10YWcuX19fXw0KPj4NCj4+ICAgICAgX18gX18NCj4+DQo+PiAgICAgIDEx LjIuNC4gIE9mZmVyZXIgUHJvY2Vzc2luZyBvZiB0aGUgU0RQIEFuc3dlcl9fX18NCj4+DQo+PiAg ICAgIF9fIF9fDQo+Pg0KPj4gICAgICAgICAgV2hlbiBhbiBvZmZlcmVyIHJlY2VpdmVzIGFuIGFu c3dlciwgaWYgdGhlIGFuc3dlcmVyIHN1cHBvcnRzIGFuZA0KPj4gICAgICB1c2VzX19fXw0KPj4N Cj4+ICAgICAgICAgIHRoZSBJQ0UgbWVjaGFuaXNtIGFuZCB0aGUgQlVORExFIGV4dGVuc2lvbiwg dGhlIG9mZmVyZXIgDQo+PiBNVVNUX19fXw0KPj4NCj4+ICAgICAgICAgIGFzc29jaWF0ZSB0aGUg c2FtZSBJQ0UgY2FuZGlkYXRlcywgYXNzb2NpYXRlZCB3aXRoIHRoZSAibT0iDQo+PiBsaW5lX19f Xw0KPj4NCj4+ICAgICAgICAgIHJlcHJlc2VudGluZyB0aGUgb2ZmZXJlciBCVU5ETEUgYWRkcmVz cyAoc2VsZWN0ZWQgYnkgdGhlDQo+PiAgICAgIGFuc3dlcmVyKSxfX19fDQo+Pg0KPj4gICAgICAg ICAgd2l0aCBlYWNoIGJ1bmRsZWQgIm09IiBsaW5lLl9fX18NCj4+DQo+PiAgICAgIF9fIF9fDQo+ Pg0KPj4gICAgICAxMS4yLjUuICBNb2RpZnlpbmcgdGhlIFNlc3Npb25fX19fDQo+Pg0KPj4gICAg ICBfXyBfXw0KPj4NCj4+ICAgICAgICAgIFdoZW4gYW4gb2ZmZXJlciBnZW5lcmF0ZXMgYSBzdWJz ZXF1ZW50IG9mZmVyLCBpdCBhc3NvY2lhdGVzDQo+PiAgICAgIHVuaXF1ZSBvcl9fX18NCj4+DQo+ PiAgICAgICAgICBzaGFyZWQgSUNFIGNhbmRpZGF0ZXMgd2l0aCB0aGUgYnVuZGxlZCAibT0iIGxp bmVzLCBhY2NvcmRpbmcgDQo+PiB0b19fX18NCj4+DQo+PiAgICAgICAgICAoU2VjdGlvbiAxMS4y LjEpLl9fX18NCj4+DQo+Pg0KPj4NCj4+IEkgYW0gbm90IDEwMCUgc3VyZSBhYm91dCB3aGF0IGV4 YWN0bHkgaXMgbWVhbnQgYnkgSUNFIGNhbmRpZGF0ZSBiZWluZyANCj4+IGFzc29jaWF0ZWQgd2l0 aCBhbiBtPSBsaW5lLiBEb2VzIHRoaXMgbWVhbiBJQ0UgY2FuZGlkYXRlIGlzIGNyZWF0ZWQgDQo+ PiBmb3IgdGhpcyBtPSBsaW5lIGFuZCAiY2FuZGlkYXRlIiBTRFAgYXR0cmlidXRlIGlzIGluY2x1 ZGVkIGluIHRoaXMgbT0gbGluZT8NCj4+DQo+PiBPdmVyYWxsIHRoZSB0ZXh0IGlzIGdvb2QsIGJ1 dCBJIHdvdWxkIGV4cGxpY2l0bHkgcmVwbGFjZSAiSUNFIA0KPj4gY2FuZGlkYXRlcyIgd2l0aCAi SUNFIGNhbmRpZGF0ZXMgb3IgYW55IG90aGVyIElDRS1yZWxhdGVkIG1lZGlhLWxldmVsIA0KPj4g U0RQIGF0dHJpYnV0ZXMiIHRvIGF2b2lkIGFueSBwb3RlbnRpYWwgY29uZnVzaW9uLiBUaGlzIHdp bGwgYWxzbyBtYWtlIA0KPj4gdGhlIHBocmFzZSAiVGhpcyBhbHNvIGFwcGx5IHRvIGFueSBvdGhl ciBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgDQo+PiBhdHRyaWJ1dGUiIHVubmVjZXNzYXJ5 Lg0KPj4gX19fX19fX19fX19fXw0KPj4gUm9tYW4gU2hwb3VudA0KPg0KDQo= From nobody Tue Feb 23 11:19: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 294041A92F2 for ; Tue, 23 Feb 2016 11:19:33 -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 5T2s0NRnOY7v for ; Tue, 23 Feb 2016 11:19:32 -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 A32521A92E4 for ; Tue, 23 Feb 2016 11:19:31 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-8d-56ccb0c1c063 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5B.15.20792.1C0BCC65; Tue, 23 Feb 2016 20:19:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 20:19:29 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions - 3pcc Thread-Index: AdFuZ4ej9iohhK9JSpeiMIbDRhdiOf//8IOAgAAJI4D//+vnAA== Date: Tue, 23 Feb 2016 19:19:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3C9D6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E3C851@ESESSMB209.ericsson.se> <56CCACC3.6090709@alum.mit.edu> In-Reply-To: <56CCACC3.6090709@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7lu7BDWfCDNpXGFosf3mC0WLq8scs Fis2HGC1mHFhKrMDi8ff9x+YPKbdv8/msWTJTyaPW1MKAliiuGxSUnMyy1KL9O0SuDJWnv3L XLCPu2JOzzLWBsYZ3F2MnBwSAiYSD/qPs0PYYhIX7q1n62Lk4hASOMwo0b/7EBOEs5hR4lpb C1AVBwebgIVE9z9tkAYRAW+JCfNXs4HYzAJeEssXTWMGsYUFzCQm/dnBAlFjLjFz3iUmCNtJ 4tGb+WBxFgFVibUHm8DqeQV8JWYsPsQCsWsbo8T+Hz/BLuIU0JGY2XoRrIgR6Lrvp9YwQSwT l7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwphK0ksuv2ZCeRmZgFNifW79CFaFSWmdD9kh9grKHFy 5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbYwS2/ rXYwHnzueIhRgINRiYd3Q9TpMCHWxLLiytxDjBIczEoivLN6zoQJ8aYkVlalFuXHF5XmpBYf YpTmYFES513jvD5MSCA9sSQ1OzW1ILUIJsvEwSnVwJio27JLJlS6i3/LjH0eGlPD/manbpGq W/83a+Xm2plvrt11/j5vhtvCIw/+yZSwuQWltjcLLFPm+5h7SJTh7acbUwRLn642N9zSvN/v dt/czoMfNmeue8UvnFzYMi9+7akvH/YaL8qoZU6fe6mFTfzaS3YZT8/+Ip6bdtPveaQZhO36 fnOz9iklluKMREMt5qLiRAB3eVCWrQIAAA== Archived-At: Cc: Colin Perkins , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - 3pcc 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, 23 Feb 2016 19:19:33 -0000 SGksDQoNCj4+ICAgMy4gUFQgcmV1c2UgaW4gc2Vzc2lvbnMgc3VjaCBhcyBvbmUgdHJpZ2dlcmVk IGJ5IDNwY2Mgd2hlcmUgaXQNCj4+ICAgICB3b3VsZCBiZSBpbXBvc3NpYmxlIHRvIGVuZm9yY2Ug UFQgZnJvbSBldmVyIGJlaW5nIHJldXNlZC4NCj4+DQo+PiAgICAgX18NCj4+DQo+PiAgICAgX18g X18NCj4+DQo+PiAgICAgQXNzdW1pbmcgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSAzcGNjIGNh c2Ugd2hlcmUgYW4gZW1wdHkgU0lQDQo+PiAgICAgKHJlLSlJTlZJVEUgcmVxdWVzdCB0cmlnZ2Vy cyBhbiBvZmZlciBpbiB0aGUgU0lQIHJlc3BvbnNlLCB0aGUNCj4+ICAgICAocmUtKUlOVklURSBj b3VsZCBhbHdheXMgY29udGFpbiBpbmZvcm1hdGlvbiAo4oCcZGVjbGFyYXRpdmUgU0RQ4oCdLCBp Zg0KPj4gICAgIHlvdSBsaWtlKSBhYm91dCB3aGF0IFBUL2NvZGVjIG1hcHBpbmdzIGFyZSBjdXJy ZW50bHkgYXZhaWxhYmxlIGluDQo+PiAgICAgdGhlIHNlc3Npb24uIF9fX18NCj4+DQo+Pg0KPj4N Cj4+IDNwY2MgY2FuIGJlIHVzZWQgdG8gY29ubmVjdCB0d28gZXhpc3Rpbmcgc2Vzc2lvbnMuIFRo aXMgbWVhbnMgZW1wdHkgDQo+PiBTSVAgcmUtSU5WSVRFIHNob3VsZCBjYXJyeSB0aGUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIGV4aXN0aW5nIFBUIGluIA0KPj4gdGhlIHNlc3Npb24uIEkgYW0gbm90 IGF3YXJlIG9mIGFueSBzcGVjaWZpY2F0aW9uIHRoYXQgcHJvcG9zZXMgYSANCj4+IG1lY2hhbmlz bSB0byBkbyB0aGlzLg0KPg0KPiBZZXMgLSB0aGVyZSBpcyBubyBleGlzdGluZyBtZWNoYW5pc20g dG8gZGVsaXZlciB0aGlzICJkZWNsYXJhdGl2ZSBTRFAiIA0KPiBzbyB0aGF0IGl0IGlzIHVuZGVy c3Rvb2QgdG8gbm90IGJlIGFuIG9mZmVyLg0KDQpUaGF0IGlzIG9uZSByZWFzb24gd2UgYXR0ZW5k IElFVEYgLSB0byBkZWZpbmUgbWVjaGFuaXNtcyB3aGVuIG5vbmUgZXhpc3RzIDopDQoNCkkgZ3Vl c3MgaXQgd291bGRuJ3QgZXZlbiBoYXZlIHRvIGJlIFNEUC4gSXQgY291bGQgZS5nLiBiZSBKU09O LCB0aGF0IHdlIGFsbCBsb3ZlLiANCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Tue Feb 23 11:40:22 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 0EFB91ACE61 for ; Tue, 23 Feb 2016 11:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 SUqCtO_Ks3zJ for ; Tue, 23 Feb 2016 11:40:19 -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 AEC6A1AC410 for ; Tue, 23 Feb 2016 11:40:19 -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 u1NJeCvY073956 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 23 Feb 2016 13:40:13 -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: "Paul Kyzivat" Date: Tue, 23 Feb 2016 13:40:11 -0600 Message-ID: <2C0F03C9-819E-43BD-92B0-2C127516333F@nostrum.com> In-Reply-To: <5B524A9A-E10D-4DBB-B6D8-66939FB0F8EC@nostrum.com> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se> <56CB79BB.9080906@alum.mit.edu> <5B524A9A-E10D-4DBB-B6D8-66939FB0F8EC@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 23 Feb 2016 19:40:21 -0000 On 23 Feb 2016, at 10:25, Ben Campbell wrote: > Jumping in on one point: > > On 22 Feb 2016, at 15:12, Paul Kyzivat wrote: > > [...] > >> Another possibility is to file an errata about it. > >> From the conversation so far, this doesn't seem like errata material >> to me. Oops, messed up the quotes. The sentence starting with "From the converation..." was mine. Ben. From nobody Tue Feb 23 12:17: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 C70121B2E01 for ; Tue, 23 Feb 2016 12:17:50 -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 8xM_hVYhAWKU for ; Tue, 23 Feb 2016 12:17:49 -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 273AB1B2E00 for ; Tue, 23 Feb 2016 12:17:49 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-01v.sys.comcast.net with comcast id MwHc1s00229Cfhx01wHo7Z; Tue, 23 Feb 2016 20:17:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id MwHn1s00J3KdFy101wHo6A; Tue, 23 Feb 2016 20:17:48 +0000 References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> To: IETF MMUSIC WG From: Paul Kyzivat Message-ID: <56CCBE6A.7090709@alum.mit.edu> Date: Tue, 23 Feb 2016 15:17:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E389BF@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=1456258668; bh=D/GVA/nAmfY5u24dp0T9oNCHJxKYyF499o12zAiA/Tg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ivIM/CjC8sbYTYK+U5kMKL2gayVdmJvzm+RFUCge0RY4Q4R+7x/Y15ZEz22bxNdSy 7rdQNwQMYNDwHld2DX7JQV2FkHzbmxR017j1M+SRCTai2tYbHjAs4QA1CiSEC5g5hk xymv1bbhJs5QMxuimtV/rXEQKg/YeSuZuaJvD9zbwPa2cka4T06sDDF/k1L/saacgG oWd6nN8cjI52DBMgfxAs2zIQcrOjgPzpkifiu9B+jIZhZf08elHC6e/7tnxRgAs7yR ta4wmEpZ6F3QIZo3Bwook7erapYR+dL9zFlHtPxc/wPNyPoFzhS5rFayS/4HkhOL1D DmNf/o8FeFuJA== Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:17:50 -0000 I went through the full draft (-08) again, not just the diffs. I found a few things: * Intro: Reading the intro I would jump to the conclusion that the primary reason for this draft is to define the way for explicitly signaling a new association. While this is important, I don't think it is *the* reason. Rather, IIUC, the reason is to centralize DTLS negotiation procedures for many protocols that require it. * Section 3.1: The third bullet is: o The establishment of a new DTLS association is explicitly signaled; ISTM that this isn't quite right. I think it should say: o The desire/intent to establish of a new DTLS association is explicitly signaled; * Section 4: A 'dtls-connection' attribute value of 'new' indicates that a new DTLS association MUST be established. A 'dtls-connection' attribute value of 'existing' indicates that a new DTLS association MUST NOT be established. The 2nd sentence above isn't entirely true. It is contradicted by section 5.3: ... or if the answerer receives an offer that contains an 'dtls-connection' attribute with an 'existing' value and the answerer determines (based on the criteria for establishing a new DTLS association) that a new DTLS association is to be established, the answerer MUST insert a 'new' value in the associated answer. IMO 5.3 must prevail here, because the answerer may not agree that there is an existing connection to reuse. So the working in section 4 should change. How about: ... A 'dtls-connection' attribute value of 'existing' indicates a preference to reuse an existing association. * Section 5.1: The certificate received during the DTLS handshake MUST match the fingerprint received in the SDP "fingerprint" attribute. If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. ... This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case? * Section 5.3: If the offer specified 'existing' but the answerer changes to 'new', should the setup attribute settings remain as they had been? (Which then determines which end sends the ClientHello message.) What should be done if the offer doesn't contain a setup attribute? * Section 9.2 (NEW TEXT) The far endpoint (answerer) may now establish a DTLS association with the offerer. Alternately, it can indicate in its answer that the offerer is to initiate the TLS association. ... Why does this first say DTLS and then use TLS? IIUC they should both be DTLS. That is all I found. I think it is almost done. Thanks, Paul > On 2/5/16 11:29 AM, Flemming Andreasen wrote: >> Greetings MMUSIC >> >> This is to announce a 2 week WGLC on the draft: >> >> https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-06.txt >> >> as Proposed Standard. Please review and provide any comments you may >> have on the document by Friday, February 19, 2016. Comments should be >> sent to the document authors and the MMUSIC WG list. If you review the >> document but do not have any comments, please send a note to that >> effect as well. >> >> Thanks >> >> -- Flemming (MMUSIC co-chair) >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > From nobody Tue Feb 23 13:15:41 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 83FFB1B3275 for ; Tue, 23 Feb 2016 13:15:39 -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 o-a7b9s0Gfoc for ; Tue, 23 Feb 2016 13:15:36 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1BE1B326D for ; Tue, 23 Feb 2016 13:15:36 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-09v.sys.comcast.net with comcast id MxEl1s0042TL4Rh01xFbyY; Tue, 23 Feb 2016 21:15:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id MxFb1s0053KdFy101xFbJM; Tue, 23 Feb 2016 21:15:35 +0000 To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37E3C98E@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CCCBF6.9080905@alum.mit.edu> Date: Tue, 23 Feb 2016 16:15:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E3C98E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456262135; bh=+t6VdoVyGFArPeds/FP4F/1GBt+zXPzZrBoCEucPVy0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UdN3FPPD7LiApaFaG0UIMYTRQGbQVNyhfNysgB/1Zx5xAunsTUFD/jlfj0UTm2CkP /55b5RuvOwcAvCWDO6W/cfcrVD0x6R6XAtMg1Qczo+ugyikUUZ1LCRVrWIEoPYZ3gd r0DZp9JrvzcIdxxegqLY6gNa32CrdX0LwnthsIBlS1FyG4ofE7kEqH4kdysnzM36Qs L6lKj+CBmGL8z9xGP0TsLpQp0Z+G8lV5PkiBmxkUHm0VMz3qo5L6x8/zItMfqx0Pr0 LTZv+c71qQUolnFJnkRZoca16xNDUgM4mX7lnehZ7s8w93nM+n9XIaJsZ9tkc2TlzU tKVezqJ0jtS4w== Archived-At: Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text episode II 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, 23 Feb 2016 21:15:39 -0000 Looks ok to me. Nit: multiple places use 'a bundled "m=" lines'. That doesn't read right. I think it should be just 'bundled "m=" lines'. Thanks, Paul On 2/23/16 2:13 PM, Christer Holmberg wrote: > New try... > > (Note that I have also replaced the reference to RFC 5245 with a reference to draft-5245bis) > > --------------------- > > 11. ICE Considerations > > 11.1. General > > This section describes how to use the BUNDLE grouping extension > together with the Interactive Connectivity Establishment (ICE) > mechanism [I-D.ietf-ice-rfc5245bis]. > > The generic procedures for negotiating usage of ICE using SDP, > defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE > with BUNDLE, with the following exceptions: > > o When BUNDLE addresses for a BUNDLE group have been selected for > both endpoints, ICE connectivity checks and keep-alives only need > to be performed for the whole BUNDLE group, instead of per bundled > "m=" line. > > o Among bundled "m=" lines with which the offerer has associated a > shared address, the offerer only associates ICE-related media- > level SDP attributes with the "m=" line associated with the > offerer BUNDLE-tag. > > o Among bundled "m=" lines with which the answerer has associated a > shared address, the answerer only associates ICE-related media- > level SDP attributes with the "m=" line associated with the > answerer BUNDLE-tag. > > Support and usage of ICE mechanism together with the BUNDLE extension > is OPTIONAL. > > 11.2. SDP Offer/Answer Procedures > > 11.2.1. General > > When an offerer associates a unique address with a bundled "m=" line > (excluding any bundle-only "m=" line), the offerer MUST associate SDP > 'candidate' attributes (and other applicable ICE-related media-level > SDP attributes), containing unique ICE properties (candidates etc), > with the "m=" line, according to the procedures in > [I-D.ietf-mmusic-ice-sip-sdp]. > > When an offerer associates a shared address with a bundled "m=" > lines, if the "m=" line is associated with the offerer BUNDLE-tag, > the offerer MUST associate SDP 'candidate' attributes (and other > applicable ICE-related media-level SDP attributes), containing shared > ICE properties, with the "m=" line. If the "m=" line is not > associated with the offerer BUNDLE-tag, the offerer MUST NOT > associate ICE-related SDP attributes with the "m=" line. > > When an answerer associates a shared address with a bundled "m=" > lines, if the "m=" line is associated with the answerer BUNDLE-tag, > the answerer MUST associate SDP 'candidate' attributes (and other > applicable ICE-related media-level SDP attributes), containing shared > ICE properties, with the "m=" line. If the "m=" line is not > associated with the answerer BUNDLE-tag, the answerer MUST NOT > associate ICE-related SDP attributes with the "m=" line. > > NOTE: As bundled "m=" lines associated with a shared address will > share the same ICE properties, there is no need to associated ICE- > related media-level SDP attributes with each "m=" line. > > NOTE: The following ICE-related media-level SDP attributes are > defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- > candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- > pacing'. > > 11.2.2. Generating the Initial SDP Offer > > When an offerer generates an initial offer, the offerer MUST > associate ICE-related media-level SDP attributes with each bundled > "m=" line, according to [Section 11.2.1]. > > 11.2.3. Generating the SDP Answer > > When an answerer generates an answer that contains a BUNDLE group, > the answerer MUST associated ICE-related SDP attributes with the "m=" > line associated with the answerer BUNDLE-tag, according to > [Section 11.2.1]. > > 11.2.4. Offerer Processing of the SDP Answer > > When an offerer receives an answer, if the answerer supports and uses > the ICE mechanism and the BUNDLE extension, the offerer MUST > associate the ICE properties associated with the offerer BUNDLE > address, selected by the answerer [Section 8.3.2], with each bundled > "m=" line. > > 11.2.5. Modifying the Session > > When an offerer generates a subsequent offer, it MUST associated > unique or shared ICE properties to one or more bundled "m=" lines, > according to [Section 11.2.1]. > > --------------------- > > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 22 February 2016 22:25 > To: Christer Holmberg ; Roman Shpount > Cc: mmusic@ietf.org; Peter Thatcher ; Ari Keränen > Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text > > On 2/22/16 3:18 PM, Christer Holmberg wrote: >> Hi Paul, >> >> I am trying to follow the same style as BUNDLE in general. Yes, I know it's messy, and I've lost count of the number of times I've had to re-write everything, but I am not going to do it again. > > Yes, I understand, and appreciate how difficult it has been to get something that everyone can understand and agree with. > >> Now, I did put together the new ICE text rather quickly, so there may be some mistakes, though. > > I *think* it is only the one place that is problematic, and I think it is in new text. And since it is the one that has different meaning than the others, changing the wording for it shouldn't disrupt anything else. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 22 February 2016 22:14 >> To: Roman Shpount ; Christer Holmberg >> >> Cc: mmusic@ietf.org; Peter Thatcher ; Ari >> Keränen >> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - >> suggested text >> >> Christer, >> >> [I'm replying to Christer, not Roman. For some reason I can't find >> Christer's original message in my email.] >> >> This generally seems good to me. I noticed one thing: >> >> While I understand the intent, you are using "associate", "associates" >> or "associated" in multiple ways, that may be confusing to some readers. >> E.g.: >> >> o Among bundled "m=" lines with which the offerer has associated a >> shared address, the offerer only associates ICE-related media- >> level SDP attributes with the "m=" line associated with the >> offerer BUNDLE-tag. >> ... >> NOTE: The bundle-only "m=" line, if accepted by the answerer, will >> inherit the candidates associated with the selected offerer BUNDLE >> address. An answerer that does not support BUNDLE would not accept a >> bundle-only "m=" line. >> ... >> When an offerer or answerer associates a shared address (i.e. a >> previously selected BUNDLE address) with one or more bundled "m=" >> lines, the offerer (or answerer) MUST only associate SDP 'candidate' >> attributes with the "m=" line associated with the offerer BUNDLE-tag >> (or the answerer BUNDLE-tag) address). The offerer or answerer MUST >> NOT associate 'candidiate' attributes with any other bundled "m=" >> line to which the offerer (or answerer) associates a shared address. >> ... >> When an offerer receives an answer, if the answerer supports and uses >> the ICE mechanism and the BUNDLE extension, the offerer MUST >> associate the same ICE candidates, associated with the "m=" line >> representing the offerer BUNDLE address (selected by the answerer), >> with each bundled "m=" line. >> >> So, which one of these things is not like the others? (This is a game >> we play with kids. Do they do it in Sweden too?) >> >> In most cases this is talking about where you put things in the SDP. But the last one above isn't that - it is about the implementation taking data from the answer and using it to update internal data structures. >> >> I don't have a specific suggestion for improving it. But I think it >> would be good to use someting other that "associate" in this case. I >> *think* it is the only place where it is used this way. >> >> Thanks, >> Paul >> >> >> On 2/22/16 2:29 PM, Roman Shpount wrote: >>> On Mon, Feb 22, 2016 at 5:10 AM, Christer Holmberg >>> >> > >>> wrote: >>> >>> Assuming we will only associated ICE candidates to the “m=” line >>> associated with the offerer/answerer BUNDLE-tag, below is a first >>> suggested of modified ‘ICE Considerations’ text: >>> >>> __ __ >>> >>> -----------------------____ >>> >>> __ __ >>> >>> 11. ICE Considerations____ >>> >>> __ __ >>> >>> 11.1. General____ >>> >>> __ __ >>> >>> This section describes how to use the BUNDLE grouping >>> extension____ >>> >>> together with the Interactive Connectivity Establishment >>> (ICE)____ >>> >>> mechanism [RFC5245].____ >>> >>> __ __ >>> >>> The generic procedures for negotiating usage of ICE using >>> SDP,____ >>> >>> defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of >>> ICE____ >>> >>> with BUNDLE, with the following exceptions:____ >>> >>> __ __ >>> >>> o When BUNDLE addresses for a BUNDLE group have been selected >>> for____ >>> >>> both endpoints, ICE connectivity checks and keep-alives only >>> need____ >>> >>> to be performed for the whole BUNDLE group, instead of per >>> bundled____ >>> >>> "m=" line.____ >>> >>> __ __ >>> >>> o Among bundled "m=" lines with which the offerer has >>> associated a____ >>> >>> shared address, the offerer only associates ICE-related >>> media-____ >>> >>> level SDP attributes with the "m=" line associated with >>> the____ >>> >>> offerer BUNDLE-tag.____ >>> >>> __ __ >>> >>> o Among bundled "m=" lines with which the answerer has >>> associated a____ >>> >>> shared address, the answerer only associates ICE-related >>> media-____ >>> >>> level SDP attributes with the "m=" line associated with >>> the____ >>> >>> answerer BUNDLE-tag.____ >>> >>> __ __ >>> >>> Support and usage of ICE mechanism together with the BUNDLE >>> extension____ >>> >>> is OPTIONAL.____ >>> >>> __ __ >>> >>> 11.2. SDP Offer/Answer Procedures____ >>> >>> __ __ >>> >>> 11.2.1. General____ >>> >>> __ __ >>> >>> When an offerer associates a unique address with a bundled "m=" >>> line____ >>> >>> (excluding any bundle-only "m=" line), it MUST also associate >>> unique____ >>> >>> ICE candidates to the "m=" line, according to the procedures >>> in____ >>> >>> [I-D.ietf-mmusic-ice-sip-sdp].____ >>> >>> __ __ >>> >>> An offerer MUST NOT associate ICE candidates with a bundle-only >>> "m="____ >>> >>> line with a zero port value.____ >>> >>> __ __ >>> >>> NOTE: The bundle-only "m=" line, if accepted by the answerer, >>> will____ >>> >>> inherit the candidates associated with the selected offerer >>> BUNDLE____ >>> >>> address. An answerer that does not support BUNDLE would not >>> accept a____ >>> >>> bundle-only "m=" line.____ >>> >>> __ __ >>> >>> When an offerer or answerer associates a shared address (i.e. >>> a____ >>> >>> previously selected BUNDLE address) with one or more bundled >>> "m="____ >>> >>> lines, the offerer (or answerer) MUST only associate SDP >>> 'candidate'____ >>> >>> attributes with the "m=" line associated with the offerer >>> BUNDLE-tag____ >>> >>> (or the answerer BUNDLE-tag) address). The offerer or answerer >>> MUST____ >>> >>> NOT associate 'candidiate' attributes with any other bundled >>> "m="____ >>> >>> line to which the offerer (or answerer) associates a shared >>> address.____ >>> >>> This also apply to any other ICE-related media-level SDP >>> attribute.____ >>> >>> __ __ >>> >>> NOTE: The following ICE-related media-level SDP attributes >>> are____ >>> >>> defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', >>> 'remote-____ >>> >>> candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and >>> 'ice-____ >>> >>> pacing'.____ >>> >>> __ __ >>> >>> 11.2.2. Generating the Initial SDP Offer____ >>> >>> __ __ >>> >>> When an offerer generates an initial offer, it associates unique >>> ICE____ >>> >>> candidates with the bundled "m=" lines, according to Section >>> 11.2.1.____ >>> >>> __ __ >>> >>> 11.2.3. Generating the SDP Answer____ >>> >>> __ __ >>> >>> When an answerer generates an answer that contains a BUNDLE >>> group,____ >>> >>> the answerer MUST only associate SDP 'candidate' attributes >>> (and____ >>> >>> other ICE-related media-level SDP attributes) with the "m=" >>> line____ >>> >>> associated with the answerer BUNDLE-tag.____ >>> >>> __ __ >>> >>> 11.2.4. Offerer Processing of the SDP Answer____ >>> >>> __ __ >>> >>> When an offerer receives an answer, if the answerer supports and >>> uses____ >>> >>> the ICE mechanism and the BUNDLE extension, the offerer >>> MUST____ >>> >>> associate the same ICE candidates, associated with the "m=" >>> line____ >>> >>> representing the offerer BUNDLE address (selected by the >>> answerer),____ >>> >>> with each bundled "m=" line.____ >>> >>> __ __ >>> >>> 11.2.5. Modifying the Session____ >>> >>> __ __ >>> >>> When an offerer generates a subsequent offer, it associates >>> unique or____ >>> >>> shared ICE candidates with the bundled "m=" lines, according >>> to____ >>> >>> (Section 11.2.1).____ >>> >>> >>> >>> I am not 100% sure about what exactly is meant by ICE candidate being >>> associated with an m= line. Does this mean ICE candidate is created >>> for this m= line and "candidate" SDP attribute is included in this m= line? >>> >>> Overall the text is good, but I would explicitly replace "ICE >>> candidates" with "ICE candidates or any other ICE-related media-level >>> SDP attributes" to avoid any potential confusion. This will also make >>> the phrase "This also apply to any other ICE-related media-level SDP >>> attribute" unnecessary. >>> _____________ >>> Roman Shpount >> > From nobody Tue Feb 23 13:18: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 AD9611B2E31 for ; Mon, 22 Feb 2016 15:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-5, 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 WV_hLiq4WRW9 for ; Mon, 22 Feb 2016 15:29:29 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 8B3F71B2E2B for ; Mon, 22 Feb 2016 15:29:29 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 86AA76CCB9504; Mon, 22 Feb 2016 23:29:24 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u1MNTRVh000923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 23:29:28 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u1MNTOi1001410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Feb 2016 23:29:24 GMT Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.189]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 22 Feb 2016 18:29:24 -0500 From: "Makaraju, Raju (Nokia - US)" To: "md3135@att.com" , "christer.holmberg@ericsson.com" , "pkyzivat@alum.mit.edu" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAAB/sA///p1yCAAKJkAP//uSBv Date: Mon, 22 Feb 2016 23:29:24 +0000 Message-ID: <000f424c.6bc92f9b4284d924@alcatel-lucent.com> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <56CB6DB6.30802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_000f424c6bc92f9b4284d924alcatellucentcom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 23 Feb 2016 13:18:14 -0800 Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 22 Feb 2016 23:29:31 -0000 --_000_000f424c6bc92f9b4284d924alcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for fixing it to allow unambigous payload reuse. Thanks Christer, for bringing it up. BR Raju ------ Original message------ From: DOLLY, MARTIN C Date: Mon, Feb 22, 2016 4:43 PM To: Christer Holmberg;Paul Kyzivat;mmusic@ietf.org; Subject:Re: [MMUSIC] Offer/Answer PT Questions Paul, I agree with Christer, this needs to be fixed. We are doing interop testing= with other carriers for VoIP interconnection, and this is a major issue. Fixing this would help accelerate VoIP interconnection. Regards, Martin -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Monday, February 22, 2016 3:42 PM To: Paul Kyzivat ; mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions Hi, >> One thing that bothered me here is that PT cannot be reused for the >> duration of the session. It is probably safe to reuse the PT after >> session modification if PT is no longer used. I always felt that >> dynamic PT reuse criteria were much stricter then realistically possible= or needed. >... >> I think the most important criteria here is that there should be no >> ambiguity regarding how an RTP packet with particular PT should be >> decoded. If it is guaranteed that there are no packets sent between >> Alice and Bob with PT 111 over some reasonable time interval (couple >> of network round trip times), then PT 111 can be safely reused. If, >> in this scenario Bob's end point knows that it was not sending >> anything with payload 111 recently, then it can safely reuse this payloa= d. >> Alice could not be sending anything with payload 111 since Bob did >> not accept it previously. On the other hand, Bob must not reuse PT >> 100 for, let's say, CN, since there are packets with this payload in >> flight and this will create decoding ambiguity. To conclude, an end >> point should be able to safely reuse any PT that it is not currently >> accepting or was not sending or accepting for at least a few network rou= nd trip intervals. > > I agree that this is how it *should* be. I don't know if we can change > this safely or not. It seems likely to me that some implementations might= be freaked out by this. It is worth discussion. > > There are cases where it really isn't feasible to meet the current > requirement. In particular, when a transfer is done via 3pcc the transfer= ee won't know the history of past PT usage. So I expect in cases such cases= the rule is commonly broken. > > Coming up with clear rules for when PTs can be recycled could be a challe= nge. Well, I think we have to try, because these kind of issues keep causing pro= blems. The fact that something may freak about because we fix it is not a reason f= or not fixing it :) 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_000f424c6bc92f9b4284d924alcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for fixing it= to allow unambigous payload reuse.

Thanks Christer, for= bringing it up.


BR

Raju


------ Original mes= sage------

From: DOLLY,= MARTIN C

Date: Mon, F= eb 22, 2016 4:43 PM

To: Christer= Holmberg;Paul Kyzivat;mmusic@ietf.org;

Subject:Re: = [MMUSIC] Offer/Answer PT Questions


Paul,

I agree with Christer, this needs to be fixed. We are doing interop testing= with other carriers for VoIP interconnection, and this is  a major is= sue.

Fixing this would help accelerate VoIP interconnection.

Regards,

Martin

-----Original Message-----
From: mmusic [mailto:mmusic-boun= ces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, February 22, 2016 3:42 PM
To: Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org
Subject: Re: [MMUSIC] Offer/Answer PT Questions

Hi,

>> One thing that bothered me here is that PT cannot be reused for th= e
>> duration of the session. It is probably safe to reuse the PT after=
>> session modification if PT is no longer used. I always felt that <= br> >> dynamic PT reuse criteria were much stricter then realistically po= ssible or needed.
>...
>> I think the most important criteria here is that there should be n= o
>> ambiguity regarding how an RTP packet with particular PT should be=
>> decoded. If it is guaranteed that there are no packets sent betwee= n
>> Alice and Bob with PT 111 over some reasonable time interval (coup= le
>> of network round trip times), then PT 111 can be safely reused. If= ,
>> in this scenario Bob's end point knows that it was not sending >> anything with payload 111 recently, then it can safely reuse this = payload.
>> Alice could not be sending anything with payload 111 since Bob did=
>> not accept it previously. On the other hand, Bob must not reuse PT=
>> 100 for, let's say, CN, since there are packets with this payload = in
>> flight and this will create decoding ambiguity. To conclude, an en= d
>> point should be able to safely reuse any PT that it is not current= ly
>> accepting or was not sending or accepting for at least a few netwo= rk round trip intervals.
>
> I agree that this is how it *should* be. I don't know if we can change=
> this safely or not. It seems likely to me that some implementations mi= ght be freaked out by this. It is worth discussion.
>
> There are cases where it really isn't feasible to meet the current > requirement. In particular, when a transfer is done via 3pcc the trans= feree won't know the history of past PT usage. So I expect in cases such ca= ses the rule is commonly broken.
>
> Coming up with clear rules for when PTs can be recycled could be a cha= llenge.

Well, I think we have to try, because these kind of issues keep causing pro= blems.

The fact that something may freak about because we fix it is not a reason f= or not fixing it :)

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_000f424c6bc92f9b4284d924alcatellucentcom_-- From nobody Tue Feb 23 13:26: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 B39121B31E6 for ; Tue, 23 Feb 2016 13:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, 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 HX_yLwKz-rzH for ; Tue, 23 Feb 2016 13:26:10 -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 0ABC21B2EF6 for ; Tue, 23 Feb 2016 13:26:09 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-06v.sys.comcast.net with comcast id MxRx1s0022Ka2Q501xS9Yj; Tue, 23 Feb 2016 21:26:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with comcast id MxS81s00Q3KdFy101xS83r; Tue, 23 Feb 2016 21:26:09 +0000 To: mmusic@ietf.org References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56CCCE6F.9040106@alum.mit.edu> Date: Tue, 23 Feb 2016 16:26:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CC5EC6.2030402@alcatel-lucent.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=1456262769; bh=9H03bK3bglLWIZmAChYexMayLEgh6YVpSoDqOwvRp7k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ija6N8BZnh/lOnEtGTtPNYQfkIuyMPsgYeitVIwClJih/UGAB/3x9N9KUhpx1r/91 HGDvtP6jjLq+N/kXo7m/fdLNXyuV3z0P5y1atJPhktp4djHqMmcofwnTSfQx99K2v1 aFO6h1fmXv4S04qNLmC1n2t0Qmt0vXWQZf56BUNmAnBCG7Vp+piz/1UDzrCQmbQESE XggN/zK1jk87kUh5UPpHmekBFTQP9BNkaJNSAyZNFIGyQLZ3tr9XEFdFPE/c+a7t35 MJ/Iqa3PM4TlKTMipBu6ERce19COftrQ7gaYKBQ7i7Y4fZg+nrhTbrdEv6d+n2LeJm HOl8AGviL3WlQ== 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: Tue, 23 Feb 2016 21:26:11 -0000 Hi Juergen, See response at end. On 2/23/16 8:29 AM, Juergen Stoetzer-Bradler wrote: > Hi Paul, > > Thanks for your feedback to the updates in version 08. > Please find my remarks inserted below your comments. > > Thanks, > Juergen > > > On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>> Hi Paul, Christian, Flemming, Bo, >>> >>> Have just submitted version 08 of draft-ietf-mmusic-data-channel-sdpneg. >>> The changes compared to version 07 are essentially as follows. >>> >>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) regarding the >>> relationship of subprotocols and their attributes. >>> * Two new SDP offer/answer considerations in section 5.2.5 (Various >>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>> subprotocol attributes or known subprotocol attributes, whose data >>> channel transport specific semantic is not known. >>> * A new paragraph in section 8.1 (IANA Considerations / Subprotocol >>> Identifiers) related to cases, where a subprotocol is defined for data >>> channel and Websocket transport. >>> >>> These changes should address the points discussed in this email thread. >> >> This is an improvement. But I think things could still be made clearer. >> >> Consider the following addition to 5.1.2.1: >> >> 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. A data channel >> specific usage of a subprotocol attribute is expected to be specified >> in the same document, which registers the subprotocol's identifier >> for data channel usage as described in Section 8.1. >> >> This text makes sense when there is a clear distinction between >> subprotocol and protocol. Unfortunately, the way SDP has evolved there >> is no such clear distinction in many cases, such as RTP over UDP or >> TCP, etc. Those are combined into a single protocol value. While that >> can usually be parsed apart at slashes, there isn't good terminology >> for it. >> >> My point is that when I read the above, I don't know how it applies >> to, say, RTP attributes. Or does it only apply for attributes that are >> clearly defined for a *sub*protocol? >> >> I think this is primarily that we lack well defined vocabulary for all >> of this. But I think it would be too much to expect this draft to >> *solve* the vocabulary problem. In lieu of doing so, maybe it would be >> sufficient to give some concrete examples, even if they have to be >> hypothetical ones. > > [Juergen] Agree that it would be helpful to have more precise > definitions of the differences of the terms protocol and subprotocol, > especially when those terms are used outside the scope of data channels > (or Websockets). When only focusing on data channels the notion of a > "subprotocol" seems to be clearer - at least > draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket > Subprotocol Name Registry" when specifying DCEP's "Protocol" parameter. > (But draft-ietf-rtcweb-data-channel does not define what a data > channel's "subprotocol" is.) So far the sdpneg draft relatively > informally starts using the term "subprotocol" in the introduction and > there refers to Websocket "subprotocols". Perhaps we should add the term > "subprotocol" to the list of used terminology in section 3. > > The sdpneg document, together with the data channel subprotocol specific > document (which defines the value of the a=dcmap attribute's > "subprotocol" parameter), should certainly give clear guidance on how to > interpret SDP offers or answers like e.g.: > > m=application 10001 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 10.10.10.1 > a=max-message-size:100000 > a=sctp-port:5000 > ... > a=dcmap:0 subprotocol="MSRP" > a=dcsa:0 accept-types:message/cpim text/plain > a=dcsa:0 framerate:... > a=dcsa:0 lang:... > > An implementation receiving such an offer would need to decide what to > do with the dcsa embedded framerate and lang attributes. Or, someone > implementing MSRP over data channel based services may need to decide > whether or not to use these attributes, and if yes, how. > (I am using these two attributes just as hypothetical examples - don't > want to suggest that those may indeed be used for MSRP over data channel > transport). > > The msrp-usage-data-channel document doesn't mention these two > attributes. When looking at the IANA SDP attribute registry tables, I > would find both attributes specified in RFC 4566. There, "framerate" is > explicitly said to be defined only "for video media". Just to be sure I > could additionally have a look at the MSRP specifying documents, RFC > 4975 and RFC 4976, but there would not find any text at all related to > "framerate". So this case seems pretty clear and I would therefore > conclude that the "framerate" attribute should not be used for MSRP, and > that a receiver of such an offer or answer should ignore it. > > When looking at the definition of the "lang" attribute in RFC 4566 I > would not see any explicit hint of what protocols this attribute might > be used with, especially if "lang" could be used when negotiating an > MSRP session. When then looking at RFC 4975 I would indeed find "lang" - > but not as SDP attribute, rather as XML tag parameter within an example > MSRP message payload. Thus, the case of the "lang" attribute might not > be as unambiguous as the one with the "framerate" attribute, but here > too I think the typical choice would be to ignore that attribute when > receiving such an offer or answer. > It seems to me that the two new "ignore" rules in section 5.2.5 of > sdpneg-08 may also be applied in these cases. > > Admittedly, these examples may seem a bit far-fetched, but would those > go into the direction you had in mind? Yes. Note that using examples is just me grasping at straws, since a real solution looks like to big a problem for this draft to tackle by itself. I am entirely open to other ideas for how to deal with this. Thanks, Paul From nobody Wed Feb 24 00:07: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 E040E1B3542 for ; Wed, 24 Feb 2016 00:07:36 -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 fk_NNvifOB1L for ; Wed, 24 Feb 2016 00:07: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 E17461B3724 for ; Wed, 24 Feb 2016 00:07:32 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-30-56cd64c25fc6 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EC.FD.20792.2C46DC65; Wed, 24 Feb 2016 09:07:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 09:07:04 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text episode II Thread-Index: AdFubhZJutt6f+meQmuux+xz3PmWZQACN0oAABjZ2OA= Date: Wed, 24 Feb 2016 08:07:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3E15A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E3C98E@ESESSMB209.ericsson.se> <56CCCBF6.9080905@alum.mit.edu> In-Reply-To: <56CCCBF6.9080905@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7iu6hlLNhBncuGFhMXf6YxWLFhgOs FteWv2a1mHFhKrMDi8ff9x+YPBZsKvVYsuQnk8etKQUBLFFcNimpOZllqUX6dglcGS+3CRYs W8FY8ebSevYGxj+LGbsYOTkkBEwkHl7cywxhi0lcuLeerYuRi0NI4DCjRE/PaUYIZzGjRMfd ZqAqDg42AQuJ7n/aIA0iAt4SE+avZgOxmQW6GSXa/wuAlAgLxElM+RkJURIvcbznMiuEbSUx 9eNPsL0sAqoSyy/uZQQp5xXwlZj/KAAkLCSQL/Fy8Qawck4BHYnrZ/vApjMCnfb91BomiE3i EreezGeCOFlAYsme81Dni0q8fPyPFcJWkmhc8oQVZDyzgKbE+l36EK2KElO6H7KD2LwCghIn Zz5hmcAoNgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmB0Hdzy 22oH48HnjocYBTgYlXh4C56cCRNiTSwrrsw9xCjBwawkwhvodDZMiDclsbIqtSg/vqg0J7X4 EKM0B4uSOO8a5/VhQgLpiSWp2ampBalFMFkmDk6pBsYVmQHK111FOZ4zz2Et+pUvL656vefM Z+VYtpC/YZxTn873yD125NGD8EVWX8N2hs9x7v/15/svy/6Wl0Yfjq8Q/Sske6zh4B/HI7X+ yZeNJjcpP+o1OHA36TNjaZHkn+0JnJM+KLRor5rzxol50sZVqx/ozJrQvfPs9ttxp9pDYp1b Gc3LH19TYinOSDTUYi4qTgQA/uY7xKoCAAA= Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text episode II 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, 24 Feb 2016 08:07:37 -0000 SGksDQoNCj5Mb29rcyBvayB0byBtZS4NCj4NCj5OaXQ6IG11bHRpcGxlIHBsYWNlcyB1c2UgJ2Eg YnVuZGxlZCAibT0iIGxpbmVzJy4gVGhhdCBkb2Vzbid0IHJlYWQgcmlnaHQuIEkgdGhpbmsgaXQg c2hvdWxkIGJlIGp1c3QgJ2J1bmRsZWQgIm09IiBsaW5lcycuDQoNCkNvcnJlY3QuDQoNClRoYW5r cyENCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAyLzIzLzE2IDI6MTMgUE0sIENocmlz dGVyIEhvbG1iZXJnIHdyb3RlOg0KPiBOZXcgdHJ5Li4uDQo+DQo+IChOb3RlIHRoYXQgSSBoYXZl IGFsc28gcmVwbGFjZWQgdGhlIHJlZmVyZW5jZSB0byBSRkMgNTI0NSB3aXRoIGEgDQo+IHJlZmVy ZW5jZSB0byBkcmFmdC01MjQ1YmlzKQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4g MTEuICBJQ0UgQ29uc2lkZXJhdGlvbnMNCj4NCj4gMTEuMS4gIEdlbmVyYWwNCj4NCj4gICAgIFRo aXMgc2VjdGlvbiBkZXNjcmliZXMgaG93IHRvIHVzZSB0aGUgQlVORExFIGdyb3VwaW5nIGV4dGVu c2lvbg0KPiAgICAgdG9nZXRoZXIgd2l0aCB0aGUgSW50ZXJhY3RpdmUgQ29ubmVjdGl2aXR5IEVz dGFibGlzaG1lbnQgKElDRSkNCj4gICAgIG1lY2hhbmlzbSBbSS1ELmlldGYtaWNlLXJmYzUyNDVi aXNdLg0KPg0KPiAgICAgVGhlIGdlbmVyaWMgcHJvY2VkdXJlcyBmb3IgbmVnb3RpYXRpbmcgdXNh Z2Ugb2YgSUNFIHVzaW5nIFNEUCwNCj4gICAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLW1tdXNpYy1p Y2Utc2lwLXNkcF0sIGFsc28gYXBwbHkgdG8gdXNhZ2Ugb2YgSUNFDQo+ICAgICB3aXRoIEJVTkRM RSwgd2l0aCB0aGUgZm9sbG93aW5nIGV4Y2VwdGlvbnM6DQo+DQo+ICAgICBvICBXaGVuIEJVTkRM RSBhZGRyZXNzZXMgZm9yIGEgQlVORExFIGdyb3VwIGhhdmUgYmVlbiBzZWxlY3RlZCBmb3INCj4g ICAgICAgIGJvdGggZW5kcG9pbnRzLCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBhbmQga2VlcC1h bGl2ZXMgb25seSBuZWVkDQo+ICAgICAgICB0byBiZSBwZXJmb3JtZWQgZm9yIHRoZSB3aG9sZSBC VU5ETEUgZ3JvdXAsIGluc3RlYWQgb2YgcGVyIGJ1bmRsZWQNCj4gICAgICAgICJtPSIgbGluZS4N Cj4NCj4gICAgIG8gIEFtb25nIGJ1bmRsZWQgIm09IiBsaW5lcyB3aXRoIHdoaWNoIHRoZSBvZmZl cmVyIGhhcyBhc3NvY2lhdGVkIGENCj4gICAgICAgIHNoYXJlZCBhZGRyZXNzLCB0aGUgb2ZmZXJl ciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJlbGF0ZWQgbWVkaWEtDQo+ICAgICAgICBsZXZlbCBTRFAg YXR0cmlidXRlcyB3aXRoIHRoZSAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiAgICAg ICAgb2ZmZXJlciBCVU5ETEUtdGFnLg0KPg0KPiAgICAgbyAgQW1vbmcgYnVuZGxlZCAibT0iIGxp bmVzIHdpdGggd2hpY2ggdGhlIGFuc3dlcmVyIGhhcyBhc3NvY2lhdGVkIGENCj4gICAgICAgIHNo YXJlZCBhZGRyZXNzLCB0aGUgYW5zd2VyZXIgb25seSBhc3NvY2lhdGVzIElDRS1yZWxhdGVkIG1l ZGlhLQ0KPiAgICAgICAgbGV2ZWwgU0RQIGF0dHJpYnV0ZXMgd2l0aCB0aGUgIm09IiBsaW5lIGFz c29jaWF0ZWQgd2l0aCB0aGUNCj4gICAgICAgIGFuc3dlcmVyIEJVTkRMRS10YWcuDQo+DQo+ICAg ICBTdXBwb3J0IGFuZCB1c2FnZSBvZiBJQ0UgbWVjaGFuaXNtIHRvZ2V0aGVyIHdpdGggdGhlIEJV TkRMRSBleHRlbnNpb24NCj4gICAgIGlzIE9QVElPTkFMLg0KPg0KPiAxMS4yLiAgU0RQIE9mZmVy L0Fuc3dlciBQcm9jZWR1cmVzDQo+DQo+IDExLjIuMS4gIEdlbmVyYWwNCj4NCj4gICAgIFdoZW4g YW4gb2ZmZXJlciBhc3NvY2lhdGVzIGEgdW5pcXVlIGFkZHJlc3Mgd2l0aCBhIGJ1bmRsZWQgIm09 IiBsaW5lDQo+ICAgICAoZXhjbHVkaW5nIGFueSBidW5kbGUtb25seSAibT0iIGxpbmUpLCB0aGUg b2ZmZXJlciBNVVNUIGFzc29jaWF0ZSBTRFANCj4gICAgICdjYW5kaWRhdGUnIGF0dHJpYnV0ZXMg KGFuZCBvdGhlciBhcHBsaWNhYmxlIElDRS1yZWxhdGVkIG1lZGlhLWxldmVsDQo+ICAgICBTRFAg YXR0cmlidXRlcyksIGNvbnRhaW5pbmcgdW5pcXVlIElDRSBwcm9wZXJ0aWVzIChjYW5kaWRhdGVz IGV0YyksDQo+ICAgICB3aXRoIHRoZSAibT0iIGxpbmUsIGFjY29yZGluZyB0byB0aGUgcHJvY2Vk dXJlcyBpbg0KPiAgICAgW0ktRC5pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcF0uDQo+DQo+ICAgICBX aGVuIGFuIG9mZmVyZXIgYXNzb2NpYXRlcyBhIHNoYXJlZCBhZGRyZXNzIHdpdGggYSBidW5kbGVk ICJtPSINCj4gICAgIGxpbmVzLCBpZiB0aGUgIm09IiBsaW5lIGlzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgb2ZmZXJlciBCVU5ETEUtdGFnLA0KPiAgICAgdGhlIG9mZmVyZXIgTVVTVCBhc3NvY2lhdGUg U0RQICdjYW5kaWRhdGUnIGF0dHJpYnV0ZXMgKGFuZCBvdGhlcg0KPiAgICAgYXBwbGljYWJsZSBJ Q0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyksIGNvbnRhaW5pbmcgc2hhcmVk DQo+ICAgICBJQ0UgcHJvcGVydGllcywgd2l0aCB0aGUgIm09IiBsaW5lLiAgSWYgdGhlICJtPSIg bGluZSBpcyBub3QNCj4gICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgb2ZmZXJlciBCVU5ETEUtdGFn LCB0aGUgb2ZmZXJlciBNVVNUIE5PVA0KPiAgICAgYXNzb2NpYXRlIElDRS1yZWxhdGVkIFNEUCBh dHRyaWJ1dGVzIHdpdGggdGhlICJtPSIgbGluZS4NCj4NCj4gICAgIFdoZW4gYW4gYW5zd2VyZXIg YXNzb2NpYXRlcyBhIHNoYXJlZCBhZGRyZXNzIHdpdGggYSBidW5kbGVkICJtPSINCj4gICAgIGxp bmVzLCBpZiB0aGUgIm09IiBsaW5lIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgYW5zd2VyZXIgQlVO RExFLXRhZywNCj4gICAgIHRoZSBhbnN3ZXJlciBNVVNUIGFzc29jaWF0ZSBTRFAgJ2NhbmRpZGF0 ZScgYXR0cmlidXRlcyAoYW5kIG90aGVyDQo+ICAgICBhcHBsaWNhYmxlIElDRS1yZWxhdGVkIG1l ZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGVzKSwgY29udGFpbmluZyBzaGFyZWQNCj4gICAgIElDRSBw cm9wZXJ0aWVzLCB3aXRoIHRoZSAibT0iIGxpbmUuICBJZiB0aGUgIm09IiBsaW5lIGlzIG5vdA0K PiAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBhbnN3ZXJlciBCVU5ETEUtdGFnLCB0aGUgYW5zd2Vy ZXIgTVVTVCBOT1QNCj4gICAgIGFzc29jaWF0ZSBJQ0UtcmVsYXRlZCBTRFAgYXR0cmlidXRlcyB3 aXRoIHRoZSAibT0iIGxpbmUuDQo+DQo+ICAgICBOT1RFOiBBcyBidW5kbGVkICJtPSIgbGluZXMg YXNzb2NpYXRlZCB3aXRoIGEgc2hhcmVkIGFkZHJlc3Mgd2lsbA0KPiAgICAgc2hhcmUgdGhlIHNh bWUgSUNFIHByb3BlcnRpZXMsIHRoZXJlIGlzIG5vIG5lZWQgdG8gYXNzb2NpYXRlZCBJQ0UtDQo+ ICAgICByZWxhdGVkIG1lZGlhLWxldmVsIFNEUCBhdHRyaWJ1dGVzIHdpdGggZWFjaCAibT0iIGxp bmUuDQo+DQo+ICAgICBOT1RFOiBUaGUgZm9sbG93aW5nIElDRS1yZWxhdGVkIG1lZGlhLWxldmVs IFNEUCBhdHRyaWJ1dGVzIGFyZQ0KPiAgICAgZGVmaW5lZCBpbiBbSS1ELmlldGYtbW11c2ljLWlj ZS1zaXAtc2RwXTogJ2NhbmRpZGlhdGUnLCAncmVtb3RlLQ0KPiAgICAgY2FuZGlkYXRlcycsICdp Y2UtbWlzbWF0Y2gnLCAnaWNlLXVmcmFnJywgJ2ljZS1wd2QnLCBhbmQgJ2ljZS0NCj4gICAgIHBh Y2luZycuDQo+DQo+IDExLjIuMi4gIEdlbmVyYXRpbmcgdGhlIEluaXRpYWwgU0RQIE9mZmVyDQo+ DQo+ICAgICBXaGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGFuIGluaXRpYWwgb2ZmZXIsIHRoZSBv ZmZlcmVyIE1VU1QNCj4gICAgIGFzc29jaWF0ZSBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAg YXR0cmlidXRlcyB3aXRoIGVhY2ggYnVuZGxlZA0KPiAgICAgIm09IiBsaW5lLCBhY2NvcmRpbmcg dG8gW1NlY3Rpb24gMTEuMi4xXS4NCj4NCj4gMTEuMi4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFu c3dlcg0KPg0KPiAgICAgV2hlbiBhbiBhbnN3ZXJlciBnZW5lcmF0ZXMgYW4gYW5zd2VyIHRoYXQg Y29udGFpbnMgYSBCVU5ETEUgZ3JvdXAsDQo+ICAgICB0aGUgYW5zd2VyZXIgTVVTVCBhc3NvY2lh dGVkIElDRS1yZWxhdGVkIFNEUCBhdHRyaWJ1dGVzIHdpdGggdGhlICJtPSINCj4gICAgIGxpbmUg YXNzb2NpYXRlZCB3aXRoIHRoZSBhbnN3ZXJlciBCVU5ETEUtdGFnLCBhY2NvcmRpbmcgdG8NCj4g ICAgIFtTZWN0aW9uIDExLjIuMV0uDQo+DQo+IDExLjIuNC4gIE9mZmVyZXIgUHJvY2Vzc2luZyBv ZiB0aGUgU0RQIEFuc3dlcg0KPg0KPiAgICAgV2hlbiBhbiBvZmZlcmVyIHJlY2VpdmVzIGFuIGFu c3dlciwgaWYgdGhlIGFuc3dlcmVyIHN1cHBvcnRzIGFuZCB1c2VzDQo+ICAgICB0aGUgSUNFIG1l Y2hhbmlzbSBhbmQgdGhlIEJVTkRMRSBleHRlbnNpb24sIHRoZSBvZmZlcmVyIE1VU1QNCj4gICAg IGFzc29jaWF0ZSB0aGUgSUNFIHByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBvZmZlcmVy IEJVTkRMRQ0KPiAgICAgYWRkcmVzcywgc2VsZWN0ZWQgYnkgdGhlIGFuc3dlcmVyIFtTZWN0aW9u IDguMy4yXSwgd2l0aCBlYWNoIGJ1bmRsZWQNCj4gICAgICJtPSIgbGluZS4NCj4NCj4gMTEuMi41 LiAgTW9kaWZ5aW5nIHRoZSBTZXNzaW9uDQo+DQo+ICAgICBXaGVuIGFuIG9mZmVyZXIgZ2VuZXJh dGVzIGEgc3Vic2VxdWVudCBvZmZlciwgaXQgTVVTVCBhc3NvY2lhdGVkDQo+ICAgICB1bmlxdWUg b3Igc2hhcmVkIElDRSBwcm9wZXJ0aWVzIHRvIG9uZSBvciBtb3JlIGJ1bmRsZWQgIm09IiBsaW5l cywNCj4gICAgIGFjY29yZGluZyB0byBbU2VjdGlvbiAxMS4yLjFdLg0KPg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRA YWx1bS5taXQuZWR1XQ0KPiBTZW50OiAyMiBGZWJydWFyeSAyMDE2IDIyOjI1DQo+IFRvOiBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgUm9tYW4gU2hw b3VudCANCj4gPHJvbWFuQHRlbHVyaXguY29tPg0KPiBDYzogbW11c2ljQGlldGYub3JnOyBQZXRl ciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb20+OyBBcmkgDQo+IEtlcsOkbmVuIDxhcmku a2VyYW5lbkBlcmljc3Nvbi5jb20+DQo+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBRdWVzdGlvbnMg YWJvdXQgSUNFIGNhbmRpZGF0ZXMgd2l0aCBCVU5ETEUgLSANCj4gc3VnZ2VzdGVkIHRleHQNCj4N Cj4gT24gMi8yMi8xNiAzOjE4IFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+IEhpIFBh dWwsDQo+Pg0KPj4gSSBhbSB0cnlpbmcgdG8gZm9sbG93IHRoZSBzYW1lIHN0eWxlIGFzIEJVTkRM RSBpbiBnZW5lcmFsLiBZZXMsIEkga25vdyBpdCdzIG1lc3N5LCBhbmQgSSd2ZSBsb3N0IGNvdW50 IG9mIHRoZSBudW1iZXIgb2YgdGltZXMgSSd2ZSBoYWQgdG8gcmUtd3JpdGUgZXZlcnl0aGluZywg YnV0IEkgYW0gbm90IGdvaW5nIHRvIGRvIGl0IGFnYWluLg0KPg0KPiBZZXMsIEkgdW5kZXJzdGFu ZCwgYW5kIGFwcHJlY2lhdGUgaG93IGRpZmZpY3VsdCBpdCBoYXMgYmVlbiB0byBnZXQgc29tZXRo aW5nIHRoYXQgZXZlcnlvbmUgY2FuIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGguDQo+DQo+PiBO b3csIEkgZGlkIHB1dCB0b2dldGhlciB0aGUgbmV3IElDRSB0ZXh0IHJhdGhlciBxdWlja2x5LCBz byB0aGVyZSBtYXkgYmUgc29tZSBtaXN0YWtlcywgdGhvdWdoLg0KPg0KPiBJICp0aGluayogaXQg aXMgb25seSB0aGUgb25lIHBsYWNlIHRoYXQgaXMgcHJvYmxlbWF0aWMsIGFuZCBJIHRoaW5rIGl0 IGlzIGluIG5ldyB0ZXh0LiBBbmQgc2luY2UgaXQgaXMgdGhlIG9uZSB0aGF0IGhhcyBkaWZmZXJl bnQgbWVhbmluZyB0aGFuIHRoZSBvdGhlcnMsIGNoYW5naW5nIHRoZSB3b3JkaW5nIGZvciBpdCBz aG91bGRuJ3QgZGlzcnVwdCBhbnl0aGluZyBlbHNlLg0KPg0KPiAJVGhhbmtzLA0KPiAJUGF1bA0K Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBhbHVtLm1p dC5lZHVdDQo+PiBTZW50OiAyMiBGZWJydWFyeSAyMDE2IDIyOjE0DQo+PiBUbzogUm9tYW4gU2hw b3VudCA8cm9tYW5AdGVsdXJpeC5jb20+OyBDaHJpc3RlciBIb2xtYmVyZyANCj4+IDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+PiBDYzogbW11c2ljQGlldGYub3JnOyBQZXRlciBU aGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb20+OyBBcmkgDQo+PiBLZXLDpG5lbiA8YXJpLmtl cmFuZW5AZXJpY3Nzb24uY29tPg0KPj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIFF1ZXN0aW9ucyBh Ym91dCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEJVTkRMRSAtIA0KPj4gc3VnZ2VzdGVkIHRleHQNCj4+ DQo+PiBDaHJpc3RlciwNCj4+DQo+PiBbSSdtIHJlcGx5aW5nIHRvIENocmlzdGVyLCBub3QgUm9t YW4uIEZvciBzb21lIHJlYXNvbiBJIGNhbid0IGZpbmQgDQo+PiBDaHJpc3RlcidzIG9yaWdpbmFs IG1lc3NhZ2UgaW4gbXkgZW1haWwuXQ0KPj4NCj4+IFRoaXMgZ2VuZXJhbGx5IHNlZW1zIGdvb2Qg dG8gbWUuIEkgbm90aWNlZCBvbmUgdGhpbmc6DQo+Pg0KPj4gV2hpbGUgSSB1bmRlcnN0YW5kIHRo ZSBpbnRlbnQsIHlvdSBhcmUgdXNpbmcgImFzc29jaWF0ZSIsICJhc3NvY2lhdGVzIg0KPj4gb3Ig ImFzc29jaWF0ZWQiIGluIG11bHRpcGxlIHdheXMsIHRoYXQgbWF5IGJlIGNvbmZ1c2luZyB0byBz b21lIHJlYWRlcnMuDQo+PiBFLmcuOg0KPj4NCj4+ICAgICAgIG8gIEFtb25nIGJ1bmRsZWQgIm09 IiBsaW5lcyB3aXRoIHdoaWNoIHRoZSBvZmZlcmVyIGhhcyBhc3NvY2lhdGVkIGENCj4+ICAgICAg ICAgIHNoYXJlZCBhZGRyZXNzLCB0aGUgb2ZmZXJlciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJlbGF0 ZWQgbWVkaWEtDQo+PiAgICAgICAgICBsZXZlbCBTRFAgYXR0cmlidXRlcyB3aXRoIHRoZSAibT0i IGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPj4gICAgICAgICAgb2ZmZXJlciBCVU5ETEUtdGFn Lg0KPj4gLi4uDQo+PiAgICAgICBOT1RFOiBUaGUgYnVuZGxlLW9ubHkgIm09IiBsaW5lLCBpZiBh Y2NlcHRlZCBieSB0aGUgYW5zd2VyZXIsIHdpbGwNCj4+ICAgICAgIGluaGVyaXQgdGhlIGNhbmRp ZGF0ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzZWxlY3RlZCBvZmZlcmVyIEJVTkRMRQ0KPj4gICAg ICAgYWRkcmVzcy4gIEFuIGFuc3dlcmVyIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBCVU5ETEUgd291 bGQgbm90IGFjY2VwdCBhDQo+PiAgICAgICBidW5kbGUtb25seSAibT0iIGxpbmUuDQo+PiAuLi4N Cj4+ICAgICAgIFdoZW4gYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBhc3NvY2lhdGVzIGEgc2hhcmVk IGFkZHJlc3MgKGkuZS4gYQ0KPj4gICAgICAgcHJldmlvdXNseSBzZWxlY3RlZCBCVU5ETEUgYWRk cmVzcykgd2l0aCBvbmUgb3IgbW9yZSBidW5kbGVkICJtPSINCj4+ICAgICAgIGxpbmVzLCB0aGUg b2ZmZXJlciAob3IgYW5zd2VyZXIpIE1VU1Qgb25seSBhc3NvY2lhdGUgU0RQICdjYW5kaWRhdGUn DQo+PiAgICAgICBhdHRyaWJ1dGVzIHdpdGggdGhlICJtPSIgbGluZSBhc3NvY2lhdGVkIHdpdGgg dGhlIG9mZmVyZXIgQlVORExFLXRhZw0KPj4gICAgICAgKG9yIHRoZSBhbnN3ZXJlciBCVU5ETEUt dGFnKSBhZGRyZXNzKS4gIFRoZSBvZmZlcmVyIG9yIGFuc3dlcmVyIE1VU1QNCj4+ICAgICAgIE5P VCBhc3NvY2lhdGUgJ2NhbmRpZGlhdGUnIGF0dHJpYnV0ZXMgd2l0aCBhbnkgb3RoZXIgYnVuZGxl ZCAibT0iDQo+PiAgICAgICBsaW5lIHRvIHdoaWNoIHRoZSBvZmZlcmVyIChvciBhbnN3ZXJlcikg YXNzb2NpYXRlcyBhIHNoYXJlZCBhZGRyZXNzLg0KPj4gLi4uDQo+PiAgICAgICBXaGVuIGFuIG9m ZmVyZXIgcmVjZWl2ZXMgYW4gYW5zd2VyLCBpZiB0aGUgYW5zd2VyZXIgc3VwcG9ydHMgYW5kIHVz ZXMNCj4+ICAgICAgIHRoZSBJQ0UgbWVjaGFuaXNtIGFuZCB0aGUgQlVORExFIGV4dGVuc2lvbiwg dGhlIG9mZmVyZXIgTVVTVA0KPj4gICAgICAgYXNzb2NpYXRlIHRoZSBzYW1lIElDRSBjYW5kaWRh dGVzLCBhc3NvY2lhdGVkIHdpdGggdGhlICJtPSIgbGluZQ0KPj4gICAgICAgcmVwcmVzZW50aW5n IHRoZSBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIChzZWxlY3RlZCBieSB0aGUgYW5zd2VyZXIpLA0K Pj4gICAgICAgd2l0aCBlYWNoIGJ1bmRsZWQgIm09IiBsaW5lLg0KPj4NCj4+IFNvLCB3aGljaCBv bmUgb2YgdGhlc2UgdGhpbmdzIGlzIG5vdCBsaWtlIHRoZSBvdGhlcnM/IChUaGlzIGlzIGEgZ2Ft ZSANCj4+IHdlIHBsYXkgd2l0aCBraWRzLiBEbyB0aGV5IGRvIGl0IGluIFN3ZWRlbiB0b28/KQ0K Pj4NCj4+IEluIG1vc3QgY2FzZXMgdGhpcyBpcyB0YWxraW5nIGFib3V0IHdoZXJlIHlvdSBwdXQg dGhpbmdzIGluIHRoZSBTRFAuIEJ1dCB0aGUgbGFzdCBvbmUgYWJvdmUgaXNuJ3QgdGhhdCAtIGl0 IGlzIGFib3V0IHRoZSBpbXBsZW1lbnRhdGlvbiB0YWtpbmcgZGF0YSBmcm9tIHRoZSBhbnN3ZXIg YW5kIHVzaW5nIGl0IHRvIHVwZGF0ZSBpbnRlcm5hbCBkYXRhIHN0cnVjdHVyZXMuDQo+Pg0KPj4g SSBkb24ndCBoYXZlIGEgc3BlY2lmaWMgc3VnZ2VzdGlvbiBmb3IgaW1wcm92aW5nIGl0LiBCdXQg SSB0aGluayBpdCANCj4+IHdvdWxkIGJlIGdvb2QgdG8gdXNlIHNvbWV0aW5nIG90aGVyIHRoYXQg ImFzc29jaWF0ZSIgaW4gdGhpcyBjYXNlLiBJDQo+PiAqdGhpbmsqIGl0IGlzIHRoZSBvbmx5IHBs YWNlIHdoZXJlIGl0IGlzIHVzZWQgdGhpcyB3YXkuDQo+Pg0KPj4gCVRoYW5rcywNCj4+IAlQYXVs DQo+Pg0KPj4NCj4+IE9uIDIvMjIvMTYgMjoyOSBQTSwgUm9tYW4gU2hwb3VudCB3cm90ZToNCj4+ PiBPbiBNb24sIEZlYiAyMiwgMjAxNiBhdCA1OjEwIEFNLCBDaHJpc3RlciBIb2xtYmVyZyANCj4+ PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIA0KPj4+IDxtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCj4+PiB3cm90ZToNCj4+Pg0KPj4+ICAgICAgIEFzc3Vt aW5nIHdlIHdpbGwgb25seSBhc3NvY2lhdGVkIElDRSBjYW5kaWRhdGVzIHRvIHRoZSDigJxtPeKA nSBsaW5lDQo+Pj4gICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBvZmZlcmVyL2Fuc3dlcmVyIEJV TkRMRS10YWcsIGJlbG93IGlzIGEgZmlyc3QNCj4+PiAgICAgICBzdWdnZXN0ZWQgb2YgbW9kaWZp ZWQg4oCYSUNFIENvbnNpZGVyYXRpb25z4oCZIHRleHQ6DQo+Pj4NCj4+PiAgICAgICBfXyBfXw0K Pj4+DQo+Pj4gICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1fX19fDQo+Pj4NCj4+PiAgICAg ICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgMTEuICBJQ0UgQ29uc2lkZXJhdGlvbnNfX19fDQo+Pj4N Cj4+PiAgICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgMTEuMS4gIEdlbmVyYWxfX19fDQo+Pj4N Cj4+PiAgICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgICAgIFRoaXMgc2VjdGlvbiBkZXNjcmli ZXMgaG93IHRvIHVzZSB0aGUgQlVORExFIGdyb3VwaW5nIA0KPj4+IGV4dGVuc2lvbl9fX18NCj4+ Pg0KPj4+ICAgICAgICAgICB0b2dldGhlciB3aXRoIHRoZSBJbnRlcmFjdGl2ZSBDb25uZWN0aXZp dHkgRXN0YWJsaXNobWVudCANCj4+PiAoSUNFKV9fX18NCj4+Pg0KPj4+ICAgICAgICAgICBtZWNo YW5pc20gW1JGQzUyNDVdLl9fX18NCj4+Pg0KPj4+ICAgICAgIF9fIF9fDQo+Pj4NCj4+PiAgICAg ICAgICAgVGhlIGdlbmVyaWMgcHJvY2VkdXJlcyBmb3IgbmVnb3RpYXRpbmcgdXNhZ2Ugb2YgSUNF IHVzaW5nIA0KPj4+IFNEUCxfX19fDQo+Pj4NCj4+PiAgICAgICAgICAgZGVmaW5lZCBpbiBbSS1E LmlldGYtbW11c2ljLWljZS1zaXAtc2RwXSwgYWxzbyBhcHBseSB0byB1c2FnZSBvZg0KPj4+ICAg ICAgIElDRV9fX18NCj4+Pg0KPj4+ICAgICAgICAgICB3aXRoIEJVTkRMRSwgd2l0aCB0aGUgZm9s bG93aW5nIGV4Y2VwdGlvbnM6X19fXw0KPj4+DQo+Pj4gICAgICAgX18gX18NCj4+Pg0KPj4+ICAg ICAgICAgICBvICBXaGVuIEJVTkRMRSBhZGRyZXNzZXMgZm9yIGEgQlVORExFIGdyb3VwIGhhdmUg YmVlbiBzZWxlY3RlZA0KPj4+ICAgICAgIGZvcl9fX18NCj4+Pg0KPj4+ICAgICAgICAgICAgICBi b3RoIGVuZHBvaW50cywgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgYW5kIGtlZXAtYWxpdmVzIG9u bHkNCj4+PiAgICAgICBuZWVkX19fXw0KPj4+DQo+Pj4gICAgICAgICAgICAgIHRvIGJlIHBlcmZv cm1lZCBmb3IgdGhlIHdob2xlIEJVTkRMRSBncm91cCwgaW5zdGVhZCBvZiBwZXINCj4+PiAgICAg ICBidW5kbGVkX19fXw0KPj4+DQo+Pj4gICAgICAgICAgICAgICJtPSIgbGluZS5fX19fDQo+Pj4N Cj4+PiAgICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgICAgIG8gIEFtb25nIGJ1bmRsZWQgIm09 IiBsaW5lcyB3aXRoIHdoaWNoIHRoZSBvZmZlcmVyIGhhcw0KPj4+ICAgICAgIGFzc29jaWF0ZWQg YV9fX18NCj4+Pg0KPj4+ICAgICAgICAgICAgICBzaGFyZWQgYWRkcmVzcywgdGhlIG9mZmVyZXIg b25seSBhc3NvY2lhdGVzIElDRS1yZWxhdGVkDQo+Pj4gICAgICAgbWVkaWEtX19fXw0KPj4+DQo+ Pj4gICAgICAgICAgICAgIGxldmVsIFNEUCBhdHRyaWJ1dGVzIHdpdGggdGhlICJtPSIgbGluZSBh c3NvY2lhdGVkIHdpdGggDQo+Pj4gdGhlX19fXw0KPj4+DQo+Pj4gICAgICAgICAgICAgIG9mZmVy ZXIgQlVORExFLXRhZy5fX19fDQo+Pj4NCj4+PiAgICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAg ICAgIG8gIEFtb25nIGJ1bmRsZWQgIm09IiBsaW5lcyB3aXRoIHdoaWNoIHRoZSBhbnN3ZXJlciBo YXMNCj4+PiAgICAgICBhc3NvY2lhdGVkIGFfX19fDQo+Pj4NCj4+PiAgICAgICAgICAgICAgc2hh cmVkIGFkZHJlc3MsIHRoZSBhbnN3ZXJlciBvbmx5IGFzc29jaWF0ZXMgSUNFLXJlbGF0ZWQNCj4+ PiAgICAgICBtZWRpYS1fX19fDQo+Pj4NCj4+PiAgICAgICAgICAgICAgbGV2ZWwgU0RQIGF0dHJp YnV0ZXMgd2l0aCB0aGUgIm09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aCANCj4+PiB0aGVfX19fDQo+ Pj4NCj4+PiAgICAgICAgICAgICAgYW5zd2VyZXIgQlVORExFLXRhZy5fX19fDQo+Pj4NCj4+PiAg ICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgICAgIFN1cHBvcnQgYW5kIHVzYWdlIG9mIElDRSBt ZWNoYW5pc20gdG9nZXRoZXIgd2l0aCB0aGUgQlVORExFDQo+Pj4gICAgICAgZXh0ZW5zaW9uX19f Xw0KPj4+DQo+Pj4gICAgICAgICAgIGlzIE9QVElPTkFMLl9fX18NCj4+Pg0KPj4+ICAgICAgIF9f IF9fDQo+Pj4NCj4+PiAgICAgICAxMS4yLiAgU0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzX19f Xw0KPj4+DQo+Pj4gICAgICAgX18gX18NCj4+Pg0KPj4+ICAgICAgIDExLjIuMS4gIEdlbmVyYWxf X19fDQo+Pj4NCj4+PiAgICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgICAgIFdoZW4gYW4gb2Zm ZXJlciBhc3NvY2lhdGVzIGEgdW5pcXVlIGFkZHJlc3Mgd2l0aCBhIGJ1bmRsZWQgIm09Ig0KPj4+ ICAgICAgIGxpbmVfX19fDQo+Pj4NCj4+PiAgICAgICAgICAgKGV4Y2x1ZGluZyBhbnkgYnVuZGxl LW9ubHkgIm09IiBsaW5lKSwgaXQgTVVTVCBhbHNvIGFzc29jaWF0ZQ0KPj4+ICAgICAgIHVuaXF1 ZV9fX18NCj4+Pg0KPj4+ICAgICAgICAgICBJQ0UgY2FuZGlkYXRlcyB0byB0aGUgIm09IiBsaW5l LCBhY2NvcmRpbmcgdG8gdGhlIA0KPj4+IHByb2NlZHVyZXMgaW5fX19fDQo+Pj4NCj4+PiAgICAg ICAgICAgW0ktRC5pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcF0uX19fXw0KPj4+DQo+Pj4gICAgICAg X18gX18NCj4+Pg0KPj4+ICAgICAgICAgICBBbiBvZmZlcmVyIE1VU1QgTk9UIGFzc29jaWF0ZSBJ Q0UgY2FuZGlkYXRlcyB3aXRoIGEgYnVuZGxlLW9ubHkNCj4+PiAgICAgICAibT0iX19fXw0KPj4+ DQo+Pj4gICAgICAgICAgIGxpbmUgd2l0aCBhIHplcm8gcG9ydCB2YWx1ZS5fX19fDQo+Pj4NCj4+ PiAgICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgICAgIE5PVEU6IFRoZSBidW5kbGUtb25seSAi bT0iIGxpbmUsIGlmIGFjY2VwdGVkIGJ5IHRoZSBhbnN3ZXJlciwNCj4+PiAgICAgICB3aWxsX19f Xw0KPj4+DQo+Pj4gICAgICAgICAgIGluaGVyaXQgdGhlIGNhbmRpZGF0ZXMgYXNzb2NpYXRlZCB3 aXRoIHRoZSBzZWxlY3RlZCBvZmZlcmVyDQo+Pj4gICAgICAgQlVORExFX19fXw0KPj4+DQo+Pj4g ICAgICAgICAgIGFkZHJlc3MuICBBbiBhbnN3ZXJlciB0aGF0IGRvZXMgbm90IHN1cHBvcnQgQlVO RExFIHdvdWxkIG5vdA0KPj4+ICAgICAgIGFjY2VwdCBhX19fXw0KPj4+DQo+Pj4gICAgICAgICAg IGJ1bmRsZS1vbmx5ICJtPSIgbGluZS5fX19fDQo+Pj4NCj4+PiAgICAgICBfXyBfXw0KPj4+DQo+ Pj4gICAgICAgICAgIFdoZW4gYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBhc3NvY2lhdGVzIGEgc2hh cmVkIGFkZHJlc3MgKGkuZS4NCj4+PiBhX19fXw0KPj4+DQo+Pj4gICAgICAgICAgIHByZXZpb3Vz bHkgc2VsZWN0ZWQgQlVORExFIGFkZHJlc3MpIHdpdGggb25lIG9yIG1vcmUgYnVuZGxlZA0KPj4+ ICAgICAgICJtPSJfX19fDQo+Pj4NCj4+PiAgICAgICAgICAgbGluZXMsIHRoZSBvZmZlcmVyIChv ciBhbnN3ZXJlcikgTVVTVCBvbmx5IGFzc29jaWF0ZSBTRFANCj4+PiAgICAgICAnY2FuZGlkYXRl J19fX18NCj4+Pg0KPj4+ICAgICAgICAgICBhdHRyaWJ1dGVzIHdpdGggdGhlICJtPSIgbGluZSBh c3NvY2lhdGVkIHdpdGggdGhlIG9mZmVyZXINCj4+PiAgICAgICBCVU5ETEUtdGFnX19fXw0KPj4+ DQo+Pj4gICAgICAgICAgIChvciB0aGUgYW5zd2VyZXIgQlVORExFLXRhZykgYWRkcmVzcykuICBU aGUgb2ZmZXJlciBvciBhbnN3ZXJlcg0KPj4+ICAgICAgIE1VU1RfX19fDQo+Pj4NCj4+PiAgICAg ICAgICAgTk9UIGFzc29jaWF0ZSAnY2FuZGlkaWF0ZScgYXR0cmlidXRlcyB3aXRoIGFueSBvdGhl ciBidW5kbGVkDQo+Pj4gICAgICAgIm09Il9fX18NCj4+Pg0KPj4+ICAgICAgICAgICBsaW5lIHRv IHdoaWNoIHRoZSBvZmZlcmVyIChvciBhbnN3ZXJlcikgYXNzb2NpYXRlcyBhIHNoYXJlZA0KPj4+ ICAgICAgIGFkZHJlc3MuX19fXw0KPj4+DQo+Pj4gICAgICAgICAgIFRoaXMgYWxzbyBhcHBseSB0 byBhbnkgb3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQDQo+Pj4gICAgICAgYXR0cmli dXRlLl9fX18NCj4+Pg0KPj4+ICAgICAgIF9fIF9fDQo+Pj4NCj4+PiAgICAgICAgICAgTk9URTog VGhlIGZvbGxvd2luZyBJQ0UtcmVsYXRlZCBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlcyANCj4+ PiBhcmVfX19fDQo+Pj4NCj4+PiAgICAgICAgICAgZGVmaW5lZCBpbiBbSS1ELmlldGYtbW11c2lj LWljZS1zaXAtc2RwXTogJ2NhbmRpZGlhdGUnLCANCj4+PiAncmVtb3RlLV9fX18NCj4+Pg0KPj4+ ICAgICAgICAgICBjYW5kaWRhdGVzJywgJ2ljZS1taXNtYXRjaCcsICdpY2UtdWZyYWcnLCAnaWNl LXB3ZCcsIGFuZCANCj4+PiAnaWNlLV9fX18NCj4+Pg0KPj4+ICAgICAgICAgICBwYWNpbmcnLl9f X18NCj4+Pg0KPj4+ICAgICAgIF9fIF9fDQo+Pj4NCj4+PiAgICAgICAxMS4yLjIuICBHZW5lcmF0 aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcl9fX18NCj4+Pg0KPj4+ICAgICAgIF9fIF9fDQo+Pj4N Cj4+PiAgICAgICAgICAgV2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRlcyBhbiBpbml0aWFsIG9mZmVy LCBpdCBhc3NvY2lhdGVzIHVuaXF1ZQ0KPj4+ICAgICAgIElDRV9fX18NCj4+Pg0KPj4+ICAgICAg ICAgICBjYW5kaWRhdGVzIHdpdGggdGhlIGJ1bmRsZWQgIm09IiBsaW5lcywgYWNjb3JkaW5nIHRv IFNlY3Rpb24NCj4+PiAgICAgICAxMS4yLjEuX19fXw0KPj4+DQo+Pj4gICAgICAgX18gX18NCj4+ Pg0KPj4+ICAgICAgIDExLjIuMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXJfX19fDQo+Pj4N Cj4+PiAgICAgICBfXyBfXw0KPj4+DQo+Pj4gICAgICAgICAgIFdoZW4gYW4gYW5zd2VyZXIgZ2Vu ZXJhdGVzIGFuIGFuc3dlciB0aGF0IGNvbnRhaW5zIGEgQlVORExFDQo+Pj4gICAgICAgZ3JvdXAs X19fXw0KPj4+DQo+Pj4gICAgICAgICAgIHRoZSBhbnN3ZXJlciBNVVNUIG9ubHkgYXNzb2NpYXRl IFNEUCAnY2FuZGlkYXRlJyANCj4+PiBhdHRyaWJ1dGVzIChhbmRfX19fDQo+Pj4NCj4+PiAgICAg ICAgICAgb3RoZXIgSUNFLXJlbGF0ZWQgbWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0ZXMpIHdpdGgg dGhlICJtPSINCj4+PiBsaW5lX19fXw0KPj4+DQo+Pj4gICAgICAgICAgIGFzc29jaWF0ZWQgd2l0 aCB0aGUgYW5zd2VyZXIgQlVORExFLXRhZy5fX19fDQo+Pj4NCj4+PiAgICAgICBfXyBfXw0KPj4+ DQo+Pj4gICAgICAgMTEuMi40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2Vy X19fXw0KPj4+DQo+Pj4gICAgICAgX18gX18NCj4+Pg0KPj4+ICAgICAgICAgICBXaGVuIGFuIG9m ZmVyZXIgcmVjZWl2ZXMgYW4gYW5zd2VyLCBpZiB0aGUgYW5zd2VyZXIgc3VwcG9ydHMgYW5kDQo+ Pj4gICAgICAgdXNlc19fX18NCj4+Pg0KPj4+ICAgICAgICAgICB0aGUgSUNFIG1lY2hhbmlzbSBh bmQgdGhlIEJVTkRMRSBleHRlbnNpb24sIHRoZSBvZmZlcmVyIA0KPj4+IE1VU1RfX19fDQo+Pj4N Cj4+PiAgICAgICAgICAgYXNzb2NpYXRlIHRoZSBzYW1lIElDRSBjYW5kaWRhdGVzLCBhc3NvY2lh dGVkIHdpdGggdGhlICJtPSINCj4+PiBsaW5lX19fXw0KPj4+DQo+Pj4gICAgICAgICAgIHJlcHJl c2VudGluZyB0aGUgb2ZmZXJlciBCVU5ETEUgYWRkcmVzcyAoc2VsZWN0ZWQgYnkgdGhlDQo+Pj4g ICAgICAgYW5zd2VyZXIpLF9fX18NCj4+Pg0KPj4+ICAgICAgICAgICB3aXRoIGVhY2ggYnVuZGxl ZCAibT0iIGxpbmUuX19fXw0KPj4+DQo+Pj4gICAgICAgX18gX18NCj4+Pg0KPj4+ICAgICAgIDEx LjIuNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbl9fX18NCj4+Pg0KPj4+ICAgICAgIF9fIF9fDQo+ Pj4NCj4+PiAgICAgICAgICAgV2hlbiBhbiBvZmZlcmVyIGdlbmVyYXRlcyBhIHN1YnNlcXVlbnQg b2ZmZXIsIGl0IGFzc29jaWF0ZXMNCj4+PiAgICAgICB1bmlxdWUgb3JfX19fDQo+Pj4NCj4+PiAg ICAgICAgICAgc2hhcmVkIElDRSBjYW5kaWRhdGVzIHdpdGggdGhlIGJ1bmRsZWQgIm09IiBsaW5l cywgDQo+Pj4gYWNjb3JkaW5nIHRvX19fXw0KPj4+DQo+Pj4gICAgICAgICAgIChTZWN0aW9uIDEx LjIuMSkuX19fXw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IEkgYW0gbm90IDEwMCUgc3VyZSBhYm91dCB3 aGF0IGV4YWN0bHkgaXMgbWVhbnQgYnkgSUNFIGNhbmRpZGF0ZSANCj4+PiBiZWluZyBhc3NvY2lh dGVkIHdpdGggYW4gbT0gbGluZS4gRG9lcyB0aGlzIG1lYW4gSUNFIGNhbmRpZGF0ZSBpcyANCj4+ PiBjcmVhdGVkIGZvciB0aGlzIG09IGxpbmUgYW5kICJjYW5kaWRhdGUiIFNEUCBhdHRyaWJ1dGUg aXMgaW5jbHVkZWQgaW4gdGhpcyBtPSBsaW5lPw0KPj4+DQo+Pj4gT3ZlcmFsbCB0aGUgdGV4dCBp cyBnb29kLCBidXQgSSB3b3VsZCBleHBsaWNpdGx5IHJlcGxhY2UgIklDRSANCj4+PiBjYW5kaWRh dGVzIiB3aXRoICJJQ0UgY2FuZGlkYXRlcyBvciBhbnkgb3RoZXIgSUNFLXJlbGF0ZWQgDQo+Pj4g bWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0ZXMiIHRvIGF2b2lkIGFueSBwb3RlbnRpYWwgY29uZnVz aW9uLiBUaGlzIA0KPj4+IHdpbGwgYWxzbyBtYWtlIHRoZSBwaHJhc2UgIlRoaXMgYWxzbyBhcHBs eSB0byBhbnkgb3RoZXIgSUNFLXJlbGF0ZWQgDQo+Pj4gbWVkaWEtbGV2ZWwgU0RQIGF0dHJpYnV0 ZSIgdW5uZWNlc3NhcnkuDQo+Pj4gX19fX19fX19fX19fXw0KPj4+IFJvbWFuIFNocG91bnQNCj4+ DQo+DQoNCg== From nobody Wed Feb 24 00:19:38 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 E09511B4265; Wed, 24 Feb 2016 00:19: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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160224081934.16695.97978.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 00:19:34 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-27.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 08:19: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 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-27.txt Pages : 52 Date : 2016-02-24 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-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 24 00:25: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 2A2F31B390B; Wed, 24 Feb 2016 00:25:46 -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 qEMooEC0msNc; Wed, 24 Feb 2016 00:25:44 -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 A9D9A1B47EB; Wed, 24 Feb 2016 00:25:43 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-5e-56cd6905fc4d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B7.51.20792.5096DC65; Wed, 24 Feb 2016 09:25:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 09:25:41 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-27 Thread-Index: AdFu3DWidGFHa45JRmCvhsEwIPx10g== Date: Wed, 24 Feb 2016 08:25:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3E26D@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E3E26DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdVJc182yYQcNRG4vzO9czWUxd/pjF 4try16wOzB4LNpV6LFnykymAKYrLJiU1J7MstUjfLoEr4/TmD8wFJ8wqNq66yt7A+Ea/i5GT Q0LAROL05JfsELaYxIV769m6GLk4hAQOM0pcfbmNCcJZzCjR/uoxSxcjBwebgIVE9z9tkAYR AXWJr3t7mEFsZoE4iX1r21hAbGEBVYllvZ2MIOUiAloSG/ZqQ5h6EgtbJEFMFqCKAz/5QIp5 BXwlpvxoZgWxGYEu+H5qDRPEQHGJW0/mM0FcJiCxZM95ZghbVOLl43+sELaSROOSJ6wQ9fkS G1q/sEDMFJQ4OfMJywRG4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRf xShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYQQe3/LbawXjwueMhRgEORiUe3oInZ8KEWBPL iitzDzFKcDArifDapZ0NE+JNSaysSi3Kjy8qzUktPsQozcGiJM67xnl9mJBAemJJanZqakFq EUyWiYNTqoGxkt1v+2y/ZceOT8njPn68oE24Pbq2W4Z3XuvpSdYTeRZM+PooYavAm5eO53aq 87GaXPGz3ZrK5HshQkRk4ZF2a55HH3R63Rnvcv9TbHHpv+DhcynsftNHniPsqZ/0Xp65KL18 LtePG1e2pHvyvupvn371TXxZn+u1fUV7Ja7nTbf5ktL+hu2QEktxRqKhFnNRcSIAwB/nB5wC AAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: BUNDLE-27 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, 24 Feb 2016 08:25:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E3E26DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-27) of BUNDLE. The major technical changes are: - Reference to RFC 5245 replaced with reference to draft-5245bis. - ICE-related SDP attributes only associated with m=3D line associ= ated with the BUNDLE-tag (when a shared address is associated with the "m= =3D" line). Unless we want to look into applying the new "ICE attribute rule" also to o= ther types of SDP attributes, I think we are done. Keep in mind that we are in WGLC mode, so unless there are any issues raise= d I intend to request that the chairs move the document forward. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37E3E26DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-27) of BUNDLE.<= o:p>

 

The major technical changes are:

 

-     &= nbsp;    Reference to RFC 5245 replaced with reference to dr= aft-5245bis.

-     &= nbsp;    ICE-related SDP attributes only associated with m= =3D line associated with the BUNDLE-tag (when a shared address is associate= d with the “m=3D” line).

 

Unless we want to look into applying the new “= ICE attribute rule” also to other types of SDP attributes, I think we= are done.

 

Keep in mind that we are in WGLC mode, so unless the= re are any issues raised I intend to request that the chairs move the docum= ent forward.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E3E26DESESSMB209erics_-- From nobody Wed Feb 24 01:04: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 5FDBB1B48A4 for ; Wed, 24 Feb 2016 01:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhAYf1khV1C1 for ; Wed, 24 Feb 2016 01:04:08 -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 1E9EB1B489F for ; Wed, 24 Feb 2016 01:04:07 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-8a-56cd7206ccd1 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.3F.28465.6027DC65; Wed, 24 Feb 2016 10:04:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 10:04:05 +0100 From: Christer Holmberg To: Paul Kyzivat , IETF MMUSIC WG Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9A Date: Wed, 24 Feb 2016 09:04:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> In-Reply-To: <56CCBE6A.7090709@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7hy5b0dkwg60PRC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj13XfggnqFRNn7WFtYDwj18XIySEhYCLx 8uQUZghbTOLCvfVsXYxcHEIChxklVm/7zgqSEBJYzCix6BqQzcHBJmAh0f1PGyQsIuAlceLv aTYQW1jAXuLf/Q9sEHEHiU03rjFC2G4Sr85dZAGxWQRUJSZum8gGMoZXwFei4ZU8xKrVjBJL l04Gq+cU0JE4e+8v2BxGoHu+n1rDBGIzC4hL3HoynwniTgGJJXvOQ90sKvHy8T9WCFtJonHJ E1aIeh2JBbs/sUHY2hLLFr4Gq+cVEJQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYX 56YbGeulFmUmFxfn5+nlpZZsYgTGyMEtv3V3MK5+7XiIUYCDUYmHt+DJmTAh1sSy4srcQ4wS HMxKIrx2aWfDhHhTEiurUovy44tKc1KLDzFKc7AoifOucV4fJiSQnliSmp2aWpBaBJNl4uCU amCMdtH4VNPJ/mXG8izplD8l4VxbeQ59nVZodWafgkSTQfaF91q9Qb90l+54cMRa+WVxw+0L EYpKSeusF/F92VQeJzfFuLpWnpuD75inbEHGat479f7Jf+cujtxkvX9dvt5hmUlcn6188q9z SF6f6b1/QRhv77pXh1cz/1yYOOHDkzdG2rMeWbQosRRnJBpqMRcVJwIAz8JKC40CAAA= Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 09:04:10 -0000 Hi Paul, Once again, thank you for a good review. See inline. >I went through the full draft (-08) again, not just the diffs. I found a f= ew things: > >* Intro: > > Reading the intro I would jump to the conclusion that the primary reason = for this draft is to define the way for=20 > explicitly signaling a new association. While this is important, I don't = think it is *the* reason.=20 > Rather, IIUC, the reason is to centralize DTLS negotiation procedures for= many protocols that require it. We tried to cover that in the first paragraph of the Introduction, but I gu= ess some additional text could be added. E.g.: "[RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. [RFC7345] defines SDP Offer/Answer procedures for UDPTL-DTLS. This specification defines general Offer/Answer procedures for DTLS. Other specifications, defining specific DTLS usages, can then reference this specification, in= order to ensure that the DTLS aspects are common among all usages. Having common procedures is essential when multiple usages share the same DTLS association [referene-to-BUNDLE]." -------------------- > * Section 3.1: > > The third bullet is: > > o The establishment of a new DTLS association is explicitly > signaled; > > ISTM that this isn't quite right. I think it should say: > > o The desire/intent to establish of a new DTLS association is > explicitly signaled; I'll look into that, but your suggestion seems ok. -------------------- >* Section 4: > > A 'dtls-connection' attribute value of 'new' indicates that a new > DTLS association MUST be established. A 'dtls-connection' attribute > value of 'existing' indicates that a new DTLS association MUST NOT be > established. > > The 2nd sentence above isn't entirely true. It is contradicted by section= 5.3: > > ... or if the answerer receives > an offer that contains an 'dtls-connection' attribute with an > 'existing' value and the answerer determines (based on the criteria > for establishing a new DTLS association) that a new DTLS association > is to be established, the answerer MUST insert a 'new' value in the > associated answer. > > IMO 5.3 must prevail here, because the answerer may not agree that there = is an existing connection to reuse. So the working in section 4 should chan= ge. How about: > > ... A 'dtls-connection' attribute > value of 'existing' indicates a preference to reuse an existing > association. I'll look into that, but your suggestion seems ok. -------------------- >* Section 5.1: > > The certificate received during the DTLS handshake MUST match the > fingerprint received in the SDP "fingerprint" attribute. If the > fingerprint does not match the hashed certificate, then the endpoint > MUST tear down the media session immediately. ... > > This talks about *the* fingerprint. But, IIUC, multiple fingerprints may = be supplied. What is the required processing in that case? We try to clarify that in section 3.4, which says: "It is possible to associate multiple SDP fingerprint attribute values to an 'm-' line. If any of the attribute values associated with an 'm-' line are removed, or if any new attribute values are added, it is considered a fingerprint value change." -------------------- >* Section 5.3: > >If the offer specified 'existing' but the answerer changes to 'new', shoul= d the setup attribute settings remain as they had been? (Which then determi= nes which end sends the ClientHello message.) Not sure I understand. If a new DTLS association is to be established, shou= ldn't it be allowed to re-negotiate the roles (read: change the value of th= e 'setup' attribute)? >What should be done if the offer doesn't contain a setup attribute? We assume the default value, which is "active" (RFC 4145). The text says that the setup value is included "according to the procedures= in [RFC4145]", but we could always include a note saying what the default = value is. -------------------- > * Section 9.2 (NEW TEXT) > > The far endpoint (answerer) may now establish a DTLS association with > the offerer. Alternately, it can indicate in its answer that the > offerer is to initiate the TLS association. ... > > Why does this first say DTLS and then use TLS? IIUC they should both be D= TLS. Correct. -------------------- NEW COMMMENT: In addition, I noticed that the document uses "DTLS connection" terminology= in a few places, while the intention is to use "DTLS association" (which i= s also used in the RFCs we update). The question is whether the name of the SDP attribute should still be "dtls= -connection", or whether we should change it to "dtls-association". My pers= onal preference would be to keep the "dtls-connection" name, but I can live= with both. Regards, Christer From nobody Wed Feb 24 02:38: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 992E61A21AD for ; Wed, 24 Feb 2016 02:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6] 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 z6BONO_I3jxr for ; Wed, 24 Feb 2016 02:38:13 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D45E1A21AB for ; Wed, 24 Feb 2016 02:38:13 -0800 (PST) Received: from [82.132.237.202] (port=61714 helo=[172.20.10.3]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aYWpd-0007Bt-2g; Wed, 24 Feb 2016 10:38:09 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> Date: Wed, 24 Feb 2016 10:37:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7C0829C0-0BA2-482B-91FD-9A3ED97977E7@csperkins.org> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <56CC7E68.4040103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 10:38:14 -0000 > On 23 Feb 2016, at 18:04, Christer Holmberg = wrote: >=20 > Hi, >=20 >>> No objection in principle, but it=E2=80=99s not as simple as =E2=80=9C= a few network RTTs=E2=80=9D: >>>=20 >>> No ambiguity in decoding means that the packets need to have been=20 >>> played out, so the codec state for that PT can be discarded. Some=20 >>> systems can have large (multi-second) playout buffers. >>>=20 >>> Any packets referring to the old PT also need to be gone. Formats = like=20 >>> RFC 6354 allow large offsets between streams, referenced by PT (the=20= >>> example in Section 5 has a 5.1 second offset). >>=20 >> Thanks for the insight. It helps to ground the discussion. >>=20 >> I'm also interested in hearing if there might be *other* reasons = behind the rules as they are written. >>=20 >> The advantage of the current rule is that it is easy to explain, and = is sufficient to deal with the problem you describe=20 >> above. Unfortunately it is also difficult/impossible to comply with = in some cases. If we are to replace it, we need to find=20 >> something else to replace it with. >=20 > The current rule may be easy to understand, but it's difficult to = understand - and that's what triggered this discussion :) >=20 > So, while we can discuss possible rules/guidelines on when a PT value = can be used, I still think we need to answer the first question: >=20 > - If Alice allocates PT=3DX for codec 1, is Bob allowed to allocate = PT=3DX for codec 2 within the same session? The current text is unclear = on that, and I think that is the first question we need to sort out. RFC 3551 (the RTP/AVP profile), section 3, top of page 7, says:=20 mechanisms for defining dynamic payload type bindings have been specified in the Session Description Protocol (SDP) and in other protocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestamp clock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the number space limitation is avoided. I always interpreted that as RTP payload types being per RTP session, = not per SSRC. That may, or may not, be consistent with the SDP = specifications. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Wed Feb 24 03:08: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 7E8491A87CA for ; Wed, 24 Feb 2016 03:08:44 -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_21=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 nFOgMl7J-Ugl for ; Wed, 24 Feb 2016 03:08: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 7A0B91A87C5 for ; Wed, 24 Feb 2016 03:08:42 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-aa-56cd8f380cab Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.45.28465.83F8DC65; Wed, 24 Feb 2016 12:08:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 12:08:39 +0100 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAA9P4AgABYEQD//8mqgIABcvuA///pTZA= Date: Wed, 24 Feb 2016 11:08:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3F63F@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <56CC7E68.4040103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> <7C0829C0-0BA2-482B-91FD-9A3ED97977E7@csperkins.org> In-Reply-To: <7C0829C0-0BA2-482B-91FD-9A3ED97977E7@csperkins.org> 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+NgFprFIsWRmVeSWpSXmKPExsUyM2J7uK5F/9kwg/XPlSyWvzzBaDF1+WMW ixUbDrBazLgwldmBxePv+w9MHtPu32fzWLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBnft61k K1inXvHh5xT2BsY1al2MnBwSAiYSi36tY4OwxSQu3FsPZHNxCAkcZpT4P+MsC4SzmFFi++d9 jF2MHBxsAhYS3f+0QRpEBFQldhz/xwhiMwsUSTRMuQ42SFhAX+L9oiPsEDUGEntfHoCykyTW 3m5hBrFZgHoPLl0KVs8r4Ctx/tIUdohdt5glNu45zgKS4BRwlGjZugqsmRHouu+n1jBBLBOX uPVkPhPE1QISS/acZ4awRSVePv7HCmErSTQuecIKcjOzgKbE+l36EK2KElO6H7JD7BWUODnz CcsERrFZSKbOQuiYhaRjFpKOBYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECY+zglt+6 OxhXv3Y8xCjAwajEw1vw5EyYEGtiWXFl7iFGCQ5mJRFextKzYUK8KYmVValF+fFFpTmpxYcY pTlYlMR51zivDxMSSE8sSc1OTS1ILYLJMnFwSjUwVi+5ccYktLng7ZSbc+1mc3/6e8Q1+1uA vuc2456Dwgx/7FZ/bSjI3r/Td9LjdbfTn4dP9GmY5fN6MZfRSxFOowXc8b1bNJqSP7FXKYT2 BYkGrDn9809rZeT2c5+fJRj0rnXayyuguyvwxq+YfAvOhNdKZmuOCIWkpp+J3/h5Y/uSD3PC q4yqlViKMxINtZiLihMBG+rAya0CAAA= Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 11:08:44 -0000 SGkgQ29saW4sDQoNCj4+Pj4gTm8gb2JqZWN0aW9uIGluIHByaW5jaXBsZSwgYnV0IGl04oCZcyBu b3QgYXMgc2ltcGxlIGFzIOKAnGEgZmV3IG5ldHdvcmsgUlRUc+KAnToNCj4+Pj4gDQo+Pj4+IE5v IGFtYmlndWl0eSBpbiBkZWNvZGluZyBtZWFucyB0aGF0IHRoZSBwYWNrZXRzIG5lZWQgdG8gaGF2 ZSBiZWVuIA0KPj4+PiBwbGF5ZWQgb3V0LCBzbyB0aGUgY29kZWMgc3RhdGUgZm9yIHRoYXQgUFQg Y2FuIGJlIGRpc2NhcmRlZC4gU29tZSANCj4+Pj4gc3lzdGVtcyBjYW4gaGF2ZSBsYXJnZSAobXVs dGktc2Vjb25kKSBwbGF5b3V0IGJ1ZmZlcnMuDQo+Pj4+IA0KPj4+PiBBbnkgcGFja2V0cyByZWZl cnJpbmcgdG8gdGhlIG9sZCBQVCBhbHNvIG5lZWQgdG8gYmUgZ29uZS4gRm9ybWF0cyANCj4+Pj4g bGlrZSBSRkMgNjM1NCBhbGxvdyBsYXJnZSBvZmZzZXRzIGJldHdlZW4gc3RyZWFtcywgcmVmZXJl bmNlZCBieSBQVCANCj4+Pj4gKHRoZSBleGFtcGxlIGluIFNlY3Rpb24gNSBoYXMgYSA1LjEgc2Vj b25kIG9mZnNldCkuDQo+Pj4gDQo+Pj4gVGhhbmtzIGZvciB0aGUgaW5zaWdodC4gSXQgaGVscHMg dG8gZ3JvdW5kIHRoZSBkaXNjdXNzaW9uLg0KPj4+IA0KPj4+IEknbSBhbHNvIGludGVyZXN0ZWQg aW4gaGVhcmluZyBpZiB0aGVyZSBtaWdodCBiZSAqb3RoZXIqIHJlYXNvbnMgYmVoaW5kIHRoZSBy dWxlcyBhcyB0aGV5IGFyZSB3cml0dGVuLg0KPj4+IA0KPj4+IFRoZSBhZHZhbnRhZ2Ugb2YgdGhl IGN1cnJlbnQgcnVsZSBpcyB0aGF0IGl0IGlzIGVhc3kgdG8gZXhwbGFpbiwgYW5kIA0KPj4+IGlz IHN1ZmZpY2llbnQgdG8gZGVhbCB3aXRoIHRoZSBwcm9ibGVtIHlvdSBkZXNjcmliZSBhYm92ZS4g DQo+Pj4gVW5mb3J0dW5hdGVseSBpdCBpcyBhbHNvIGRpZmZpY3VsdC9pbXBvc3NpYmxlIHRvIGNv bXBseSB3aXRoIGluIHNvbWUgY2FzZXMuIElmIHdlIGFyZSB0byByZXBsYWNlIGl0LCB3ZSBuZWVk IHRvIGZpbmQgc29tZXRoaW5nIGVsc2UgdG8gcmVwbGFjZSBpdCB3aXRoLg0KPj4gDQo+PiBUaGUg Y3VycmVudCBydWxlIG1heSBiZSBlYXN5IHRvIHVuZGVyc3RhbmQsIGJ1dCBpdCdzIGRpZmZpY3Vs dCB0byANCj4+IHVuZGVyc3RhbmQgLSBhbmQgdGhhdCdzIHdoYXQgdHJpZ2dlcmVkIHRoaXMgZGlz Y3Vzc2lvbiA6KQ0KPj4gDQo+PiBTbywgd2hpbGUgd2UgY2FuIGRpc2N1c3MgcG9zc2libGUgcnVs ZXMvZ3VpZGVsaW5lcyBvbiB3aGVuIGEgUFQgdmFsdWUgY2FuIGJlIHVzZWQsIEkgc3RpbGwgdGhp bmsgd2UgbmVlZCB0byBhbnN3ZXIgdGhlIGZpcnN0IHF1ZXN0aW9uOg0KPj4gDQo+PiAtIElmIEFs aWNlIGFsbG9jYXRlcyBQVD1YIGZvciBjb2RlYyAxLCBpcyBCb2IgYWxsb3dlZCB0byBhbGxvY2F0 ZSBQVD1YIGZvciBjb2RlYyAyIHdpdGhpbiB0aGUgc2FtZSBzZXNzaW9uPyBUaGUgY3VycmVudCAN Cj4+IHRleHQgaXMgdW5jbGVhciBvbiB0aGF0LCBhbmQgSSB0aGluayB0aGF0IGlzIHRoZSBmaXJz dCBxdWVzdGlvbiB3ZSBuZWVkIHRvIHNvcnQgb3V0Lg0KPg0KPiBSRkMgMzU1MSAodGhlIFJUUC9B VlAgcHJvZmlsZSksIHNlY3Rpb24gMywgdG9wIG9mIHBhZ2UgNywgc2F5czogDQo+DQo+ICAgbWVj aGFuaXNtcyBmb3IgZGVmaW5pbmcgZHluYW1pYyBwYXlsb2FkIHR5cGUgYmluZGluZ3MgaGF2ZSBi ZWVuDQo+ICAgc3BlY2lmaWVkIGluIHRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChT RFApIGFuZCBpbiBvdGhlcg0KPiAgIHByb3RvY29scyBzdWNoIGFzIElUVS1UIFJlY29tbWVuZGF0 aW9uIEguMzIzL0guMjQ1LiAgVGhlc2UgbWVjaGFuaXNtcw0KPiAgIGFzc29jaWF0ZSB0aGUgcmVn aXN0ZXJlZCBuYW1lIG9mIHRoZSBlbmNvZGluZy9wYXlsb2FkIGZvcm1hdCwgYWxvbmcNCj4gICB3 aXRoIGFueSBhZGRpdGlvbmFsIHJlcXVpcmVkIHBhcmFtZXRlcnMsIHN1Y2ggYXMgdGhlIFJUUCB0 aW1lc3RhbXANCj4gICBjbG9jayByYXRlIGFuZCBudW1iZXIgb2YgY2hhbm5lbHMsIHdpdGggYSBw YXlsb2FkIHR5cGUgbnVtYmVyLiAgVGhpcw0KPiAgIGFzc29jaWF0aW9uIGlzIGVmZmVjdGl2ZSBv bmx5IGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIFJUUCBzZXNzaW9uIGluDQo+ICAgd2hpY2ggdGhl IGR5bmFtaWMgcGF5bG9hZCB0eXBlIGJpbmRpbmcgaXMgbWFkZS4gIFRoaXMgYXNzb2NpYXRpb24N Cj4gICBhcHBsaWVzIG9ubHkgdG8gdGhlIFJUUCBzZXNzaW9uIGZvciB3aGljaCBpdCBpcyBtYWRl LCB0aHVzIHRoZQ0KPiAgIG51bWJlcnMgY2FuIGJlIHJlLXVzZWQgZm9yIGRpZmZlcmVudCBlbmNv ZGluZ3MgaW4gZGlmZmVyZW50IHNlc3Npb25zDQo+ICAgc28gdGhlIG51bWJlciBzcGFjZSBsaW1p dGF0aW9uIGlzIGF2b2lkZWQuDQo+DQo+DQo+IEkgYWx3YXlzIGludGVycHJldGVkIHRoYXQgYXMg UlRQIHBheWxvYWQgdHlwZXMgYmVpbmcgcGVyIFJUUCBzZXNzaW9uLCBub3QgcGVyIFNTUkMuIFRo YXQgbWF5LCBvciBtYXkgbm90LCBiZSBjb25zaXN0ZW50IHdpdGggdGhlIFNEUCBzcGVjaWZpY2F0 aW9ucy4NCg0KUTE6IFRoZW4gbXkgbmV4dCBxdWVzdGlvbiBpczogd2hlbiBpcyB0aGUgQklORElO RyBjcmVhdGVkPyBJcyBhIGJpbmRpbmcgY3JlYXRlZCBvbmNlIGEgdXNlciBoYXMgaW5kaWNhdGVk IChpbiBhbiBvZmZlciBvciBhbnN3ZXIpIGEgUFQvY29kZWMgbWFwcGluZyAtIG5vIG1hdHRlciBp ZiB0aGUgb3RoZXIgZW5kcG9pbnQgd2lsbCB1c2UgdGhlIHNhbWUgY29kZWMgdG8gYmVnaW4gd2l0 aCwgb3IgUFQgdmFsdWUgZm9yIHRoYXQgY29kZWM/DQoNCkV4YW1wbGUgIzE6DQotLS0tLS0tLS0t LS0tLS0tDQoNCkFsaWNlIG9mZmVyczoNCg0KUFQgMTAwOiAoQU1SLVdCKQ0KUFQgMTExOiAoVlA4 KQ0KDQpCb2IgYW5zd2VyczoNCg0KUFQgMTExOiAoVlA4KQ0KDQpRMjogTm93LCBldmVudGhvdWdo IGRpZCBub3QgaW5kaWNhdGUgc3VwcG9ydCBvZiBBTVItV1IsIHRoZSBCSU5ESU5HIGJldHdlZW4g UFQgMTAwIGFuZCBBTVItV1IgaGFzIHN0aWxsIGJlZW4gY3JlYXRlZCwgYW5kIG5laXRoZXIgQWxp Y2Ugb3IgQm9iIGlzIGFsbG93ZWQgdG8gcmUtdXNlIFBUIDEwMCBmb3IgYW55dGhpbmcgZWxzZSB3 aXRoaW4gdGhlIHNlc3Npb24/DQoNCg0KRXhhbXBsZSAjMjoNCi0tLS0tLS0tLS0tLS0tLS0NCg0K QWxpY2Ugb2ZmZXJzOg0KDQpQVCAxMDA6IChBTVItV0IpDQoNCkJvYiBhbnN3ZXJzOg0KDQpQVCAx MTE6IChBTVItV0IpDQoNCg0KUTM6IE5vdywgdHdvIGJpbmRpbmdzIGhhdmUgYmVlbiBjcmVhdGVk OiBvbmUgYmluZGluZyBiZXR3ZWVuIFBUIDEwMCBhbmQgQU1SLVdCLCBhbmQgb25lIGJpbmRpbmcg YmV0d2VlbiBQVCAxMTEgYW5kIEFNUi1XQi4gQWZ0ZXIgdGhpcywgbmVpdGhlciBBbGljZSBvciBC b2IgaXMgYWxsb3dlZCB0byByZS11c2UgUFQgMTAwIG9yIFBUIDExMSBmb3IgYW55dGhpbmcgZWxz ZSB3aXRoaW4gdGhlIHNlc3Npb24/DQoNClE0OiBIT1dFVkVSLCBldmVuIGlmIEJvYiBpbmRpY2F0 ZWQgUFQgMTExIGFuZCBBTVItV0IsIEkgYXNzdW1lIEJvYiB3b3VsZCBzdGlsbCBiZSBhbGxvd2Vk IHRvIGluZGljYXRlIFBUIDEwMCBhbmQgQU1SLVdCLCBhcyBpdCBkb2VzIG5vdCBjb25mbGljdCB3 aXRoIHRoZSBleGlzdGluZyBiaW5kaW5nPw0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K DQoNCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Wed Feb 24 09:14: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 2C4371B394A for ; Wed, 24 Feb 2016 09:14:42 -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 NwGb3P_8H2tR for ; Wed, 24 Feb 2016 09:14:40 -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 A62791B38EB for ; Wed, 24 Feb 2016 09:14:37 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-02v.sys.comcast.net with comcast id NHDW1s0092JGN3p01HEcKx; Wed, 24 Feb 2016 17:14:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id NHEc1s00K3KdFy101HEcmV; Wed, 24 Feb 2016 17:14:36 +0000 To: mmusic@ietf.org References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CDE4FB.6090002@alum.mit.edu> Date: Wed, 24 Feb 2016 12:14:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E3E3AB@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=1456334076; bh=PtL9X+q06phz+xxg9Fch2f2CBcpTEGw0VtI3EDtWlKo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UGM4OLuo6JsuJhutOpfpMKSVnHZqXHvwPy/d/yvqj/akx8HOi/Jz0sv/pxTQQUU6u nkwtKhYpHgIme/9drV/W21KGuss/5lXUd5NqiHG5/V43YDZu3cbagPwvW4XO3S0Au6 O5xTijP69Z8J5SZ/ARpE4XbTRAHcM1abK6Qs8luD3RCraMJNy2+ajQclwhSfJDpmGB J6BINMvPXlfOkDOhWPcObvAAoCi6vlvrbcLCos33h32CfLvqMPaVi/v7STtyAH0PRY /MhSHetRyUzEwEBoYGmI0SiytL+Wlbs1+eGnNBpxcYIOQzZGd8P79Zm6oWAcgOzX7l CZhMlFXVLE8UA== Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 17:14:42 -0000 On 2/24/16 4:04 AM, Christer Holmberg wrote: > Hi Paul, > > Once again, thank you for a good review. See inline. > >> I went through the full draft (-08) again, not just the diffs. I found a few things: >> >> * Intro: >> >> Reading the intro I would jump to the conclusion that the primary reason for this draft is to define the way for >> explicitly signaling a new association. While this is important, I don't think it is *the* reason. >> Rather, IIUC, the reason is to centralize DTLS negotiation procedures for many protocols that require it. > > We tried to cover that in the first paragraph of the Introduction, but I guess some additional text could be added. E.g.: > > "[RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. [RFC7345] > defines SDP Offer/Answer procedures for UDPTL-DTLS. This specification > defines general Offer/Answer procedures for DTLS. Other specifications, > defining specific DTLS usages, can then reference this specification, in order > to ensure that the DTLS aspects are common among all usages. Having > common procedures is essential when multiple usages share the same > DTLS association [referene-to-BUNDLE]." WFM > -------------------- > >> * Section 3.1: >> >> The third bullet is: >> >> o The establishment of a new DTLS association is explicitly >> signaled; >> >> ISTM that this isn't quite right. I think it should say: >> >> o The desire/intent to establish of a new DTLS association is >> explicitly signaled; > > I'll look into that, but your suggestion seems ok. > > -------------------- > >> * Section 4: >> >> A 'dtls-connection' attribute value of 'new' indicates that a new >> DTLS association MUST be established. A 'dtls-connection' attribute >> value of 'existing' indicates that a new DTLS association MUST NOT be >> established. >> >> The 2nd sentence above isn't entirely true. It is contradicted by section 5.3: >> >> ... or if the answerer receives >> an offer that contains an 'dtls-connection' attribute with an >> 'existing' value and the answerer determines (based on the criteria >> for establishing a new DTLS association) that a new DTLS association >> is to be established, the answerer MUST insert a 'new' value in the >> associated answer. >> >> IMO 5.3 must prevail here, because the answerer may not agree that there is an existing connection to reuse. So the working in section 4 should change. How about: >> >> ... A 'dtls-connection' attribute >> value of 'existing' indicates a preference to reuse an existing >> association. > > I'll look into that, but your suggestion seems ok. > > -------------------- > >> * Section 5.1: >> >> The certificate received during the DTLS handshake MUST match the >> fingerprint received in the SDP "fingerprint" attribute. If the >> fingerprint does not match the hashed certificate, then the endpoint >> MUST tear down the media session immediately. ... >> >> This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case? > > We try to clarify that in section 3.4, which says: > > "It is possible to associate multiple SDP fingerprint attribute values > to an 'm-' line. If any of the attribute values associated with an > 'm-' line are removed, or if any new attribute values are added, it > is considered a fingerprint value change." Right. But AFAIK that is the only place it is mentioned. At the least, most places that reference "the fingerprint" should acknowledge that there may be more than one. And *someplace* needs to say what the semantics of use are when there is more than one. (Maybe it is defined in one of the references?) Am I correct in assuming that providing multiple fingerprints is for the convenience of the recipient, who can then pick the one that it prefers to verify? >> * Section 5.3: >> >> If the offer specified 'existing' but the answerer changes to 'new', should the setup attribute settings remain as they had been? (Which then determines which end sends the ClientHello message.) > > Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed to re-negotiate the roles (read: change the value of the 'setup' attribute)? The problem is that the offerer specified "existing", and so followed the rules for doing that. So it had to use the last negotiated setup value. But the answerer has decided to switch to "new". At this point there are limits on what it can do - there can't be a full negotiation. If the offer contained "active" or "passive" then the answerer is stuck with what was previously negotiated. If the offer contained "actpass" then maybe the answerer could choose either "active" or "passive" independent of what was previously negotiated. I think this needs to be explained and clarified as to what is allowed. >> What should be done if the offer doesn't contain a setup attribute? > > We assume the default value, which is "active" (RFC 4145). > > The text says that the setup value is included "according to the procedures in [RFC4145]", but we could always include a note saying what the default value is. OK. I didn't check 4145. > -------------------- > >> * Section 9.2 (NEW TEXT) >> >> The far endpoint (answerer) may now establish a DTLS association with >> the offerer. Alternately, it can indicate in its answer that the >> offerer is to initiate the TLS association. ... >> >> Why does this first say DTLS and then use TLS? IIUC they should both be DTLS. > > Correct. > > -------------------- > > NEW COMMMENT: > > In addition, I noticed that the document uses "DTLS connection" terminology in a few places, while the intention is to use "DTLS association" (which is also used in the RFCs we update). > > The question is whether the name of the SDP attribute should still be "dtls-connection", or whether we should change it to "dtls-association". My personal preference would be to keep the "dtls-connection" name, but I can live with both. On one hand using dtls-connection draws parallels with 'connection', which might be good. On the other hand the parallels aren't complete, so maybe changing it would emphasize that it *isn't* the same. And then it is rather last in the process to be making this change. I guess I'm neutral on this. Thanks, Paul From nobody Wed Feb 24 09:15: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 E57B01B3961 for ; Wed, 24 Feb 2016 09:15:31 -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 3eg1_12Tddid for ; Wed, 24 Feb 2016 09:15:31 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE051B395E for ; Wed, 24 Feb 2016 09:15:30 -0800 (PST) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-10v.sys.comcast.net with comcast id NHFG1s00G5E3ZMc01HFWtL; Wed, 24 Feb 2016 17:15:30 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-18v.sys.comcast.net with comcast id NHFV1s0061nMCLR01HFVxw; Wed, 24 Feb 2016 17:15:30 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u1OHFTxM003886; Wed, 24 Feb 2016 12:15:29 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1OHFTr1003883; Wed, 24 Feb 2016 12:15:29 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 24 Feb 2016 12:15:29 -0500 Message-ID: <878u2ayqq6.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456334130; bh=4bbpHs9GIebjONn45nNmcXST8QkjxhiNagxUDj26DsI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=j+sqG0j1JLjUFk1q5X8ZQg8v3dbpJlbb1V54b9+CYrXTxwjqiPOGUC5dBL+3nFc9U JU3uwvVjEIjobQHEc+tnGHI7hnHss3OD17vjyFHMvH4ExXZIqaAaYrLl55UNepC5UC sAMeDVew3pYZWU5cScwIxKiwRHxNv6qtXyop/KAQvWdCGtpgCoSQIBPJeoA6dgkjdt bPesr+7CXux/hqHuVmF0iV0WNaWT4I0QIWUABSXWvFs4th6aeHwyAH+ZntYc3hpqu6 HOjmP4ksd3C/jzHR1HpEurSyuqoIoJKfKZBZB7EwdG1dTtvUWprrYCi/5uqxxXfdEl p5YdRtys13Hfg== Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 17:15:32 -0000 Roman Shpount writes: > As far as I can see there are 3 question/clarifications that are required: > > 1. PT is allocated per codec profile (codec and all associated parameters), > not codec. For instance, if end point uses PT=100 for SILK/8000, it cannot > reuse it for SILK/16000 > > 2. Is PT blocked from each direction independently or both directions at > the same time. For instance if A sent an offer with PT=100, but B never > sent an offer or an answer with PT=100, can B sent an offer with PT=100? > > 3. PT reuse in sessions such as one triggered by 3pcc where it would be > impossible to enforce PT from ever being reused. Thanks for writing a clear list of the issues! I think it is important that we provide a formal clarification of these points, as they've been discussed again and again, though people have a general consensus on the correct answers. My understanding is that the answer to 1 has always been understood to be that the PT identifies the entire codec profile. My understanding is that the answer to 2 has always been understood to be that the PT number spaces in each direction are independent. For instance, RFC 3264 section 5.1 notes Different payload type numbers may be needed in each direction because of interoperability concerns with H.323. My understanding is that PT reuse has always been formally forbidden but that implementations should tolerate PT reuse by the other endpoint and should process reused PTs "as you'd expect" as long as all packets containing the old use of the PT were gone from "the system" before the reuse is specified. And it has been understood that this limitation is not well defined. Personally, I'd like to see a clean solution to this problem, as I had to wrestle with it when I wrote RFC 7088 section 2.8 (music-on-hold), which discusses the problem. One amelioration is that the sender uses the PTs specified in the SDP that was sent to it by the receiver, and that SDP also includes the address to which the RTP is to be sent. So in simple cases, as long as the sender updates the PTs it is sending at the same time as it updates the destination address of the RTP, then the receiver can never be confused regarding the meaning of PTs it receives. -- Any packets using the old PT definition have been sent to a different address. This may break down if there is an RTP gateway in the middle, and while the ultimate destination of the RTP is different, the sender is always given the same destination address in the rewritten SDP that it is sent. But such a gateway has problems knowing which destination to forward the RTP to. What do people at sip-implementors say about this? Dale From nobody Wed Feb 24 09:27:57 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 CAA211B3A0C for ; Wed, 24 Feb 2016 09:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 3whD-JEhXJuX for ; Wed, 24 Feb 2016 09:27:54 -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 28AE31B39FE for ; Wed, 24 Feb 2016 09:27:53 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 9so50209465iom.1 for ; Wed, 24 Feb 2016 09:27:53 -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=6wmbmZHH0llAE5P7wiawu1oPAG9TqGVsWWVxGnhmHsA=; b=LsjcZunBY8LNz/sRcxdOxmNgDOXq4lXEU4SbSC61nnkSCgrUKd9ySh7xbT+lB/ivyE MaZp0H/s/zcpVxFdlVZvhdQuBLYRnK/jx8d1AJVqoIhsQxlPcKh6K0Tdwp2OS+bQKFiD IgYqSF2jA6kIFtCNzpfCDX08IDpremgosdRZNXsbdNn5J1YgNUSU0J8IgJZFtOBoiz7m T/bL5YtPGb7yxcp+0/cyeNA+tkdkTihvibe/8vYPf0wtOex1R3r/VgEtUpZJo7i2lpy7 HMmnVpre1xXHn7BQrpGK40X6i4+wiEi4qI1Gg3aXpZeeKRS979c31y8Ay+pj+c7iF5b5 LBdQ== 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=6wmbmZHH0llAE5P7wiawu1oPAG9TqGVsWWVxGnhmHsA=; b=M0rzqGCiibaCNu35exJBJUnIOYgvkZM6DIdqd6tMJjpK0gz3eW308v8Y5UtQ/cBhAn oEytFHSX52castaF9Ynexmt0C4scbBWz1Rk+5DFdzvvFKGyZ6P56rNROjSg+Kce7Ok5u gEAwo3FgLapWGZGKOKSftJcGPOvBZE5dhPG0dpE09sbqmcv+Zj5H2JY+aM5fQd2fXA22 Wo4UsILKT3orlrlwlJKMIH+mRZqh5w3lyH8pHMqYcLL1iPwb6vhohtYuSZJx1C3MeHQZ bYm/J/X80GyZzZFmeBVxpZchP38oUvJclwwfj5S3B6LG3mY5FF87o8mNf4ENsY8R+qmb bo2w== X-Gm-Message-State: AG10YOT1U0dUQGO/Xh3wtHYmQhRvy7lOzYiJZZv2tR8CBqEe/bvC2ZO+Z3jyDXOEV6aPoQ== X-Received: by 10.107.164.145 with SMTP id d17mr37958952ioj.112.1456334851380; Wed, 24 Feb 2016 09:27:31 -0800 (PST) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id 90sm1647244iod.12.2016.02.24.09.27.30 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 09:27:30 -0800 (PST) Received: by mail-io0-f169.google.com with SMTP id z135so53890386iof.0 for ; Wed, 24 Feb 2016 09:27:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr40721397iod.145.1456334842610; Wed, 24 Feb 2016 09:27:22 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 24 Feb 2016 09:27:22 -0800 (PST) In-Reply-To: <878u2ayqq6.fsf@hobgoblin.ariadne.com> References: <878u2ayqq6.fsf@hobgoblin.ariadne.com> Date: Wed, 24 Feb 2016 12:27:22 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" , Martin Dolly Content-Type: multipart/alternative; boundary=001a113ece60f7cfbc052c8760f5 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 17:27:56 -0000 --001a113ece60f7cfbc052c8760f5 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 24, 2016 at 12:15 PM, Dale R. Worley wrote: > Roman Shpount writes: > > 2. Is PT blocked from each direction independently or both directions at > > the same time. For instance if A sent an offer with PT=100, but B never > > sent an offer or an answer with PT=100, can B sent an offer with PT=100? > > My understanding is that the answer to 2 has always been understood to > be that the PT number spaces in each direction are independent. For > instance, RFC 3264 section 5.1 notes > > Different payload type numbers may be needed in each direction > because of interoperability concerns with H.323. > > Based on this, the answer to original question is that if 1.Alice sends an Offer, with the following PT values: PT 100: AMR-WB(mode-set=2) PT 111: AMR-WB(mode-set=2, OA) PT 0: PCMU 2.Bob sends the associated Answer: PT 100: AMR-WB (mode-set=2) PT 0: PCMU 3.Later Bob sends the following subsequent Offer: PT 111: AMR(mode-set=0,2,5,7) This offer should be accepted. PT is each direction is independent and Bob is allowed to reuse it. The complication here is that Alice will not be allowed to reuse PT 111 for AMR(mode-set=0,2,5,7) in the answer. Alice will need to pick a different PT for AMR(mode-set=0,2,5,7), if it is supported and end points will use asymmetric payload types. _____________ Roman Shpount --001a113ece60f7cfbc052c8760f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 24, 2016 at 12:= 15 PM, Dale R. Worley <worley@ariadne.com> wrote:
Roman Shpount <roman@telurix.com> writes:
> 2. Is PT blocked from eac= h direction independently or both directions at
> the same time. For instance if A sent an offer with PT=3D100, but B ne= ver
> sent an offer or an answer with PT=3D100, can B sent an offer with PT= =3D100?

My understanding is that the answer to 2 has always been understood to
be that the PT number spaces in each direction are independent.=C2=A0 For instance, RFC 3264 section 5.1 notes

=C2=A0 =C2=A0 =C2=A0 Different payload type numbers may be needed in each d= irection
=C2=A0 =C2=A0 =C2=A0 because of interoperability concerns with H.323.

Based on this, the answer to original qu= estion is that if

1.Alice sends an Offer, with the foll= owing PT values:

PT 100: AMR-WB(mode-set=3D2)
PT 111: AMR-WB(mode= -set=3D2, OA)
PT 0: PCMU

2.Bob s= ends the associated Answer:

PT 100: AMR-WB (mode-set=3D2)
PT 0: P= CMU

3.Later Bob sends the following subsequent Offer:
PT 111: AMR= (mode-set=3D0,2,5,7)

This offer should be accepted. PT is each direction is ind= ependent and Bob is allowed to reuse it.
The complication here is that Alice will= not be allowed to reuse PT 111 for=C2=A0AMR(mode-set=3D0,2,5,7) in the ans= wer. Alice will need to pick a different PT for=C2=A0AMR(mode-set=3D0,2,5,7= ), if it is supported and end points will use asymmetric payload types.
=
_____________
Roman Shpount
--001a113ece60f7cfbc052c8760f5-- From nobody Wed Feb 24 09:35: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 5B7551B3A63 for ; Wed, 24 Feb 2016 09:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 9Wt_h1G6hGI2 for ; Wed, 24 Feb 2016 09:35:30 -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 3B7531B3A77 for ; Wed, 24 Feb 2016 09:35:30 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id l127so53798219iof.3 for ; Wed, 24 Feb 2016 09:35:30 -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=UCVukTqOQDOCrGskg3fzJGKXyuarcVt01vk0C/SrdX8=; b=m3QFJd9n3ONktBIdXGZ7/uqKiA5ReiO9XMycwSovtwNPn0416Un1Qrla+9HzzS5Gfg gU7SAC0rUp6uw2ResRfAeZCQ0D70HR/EWYPGJEdmMBPsPNwQ4uzrsjKiYihpayHfG3qn qxHOa/fj14d7G5/tFOAZBf6x0Zpa8mKmJ4P08pDtnGR0iqD/dy2S3dYxgKRcUfEAx3i+ JpEFA8MAuKeXJKZyfozu13ps4zx2yYa5wvJAExdd0i/9LZkJfeJ+DBWvxIn7pxqQ4mxP CBicEYI3ZgB2Br2hGAWQ2EABxeuEEKkj+SF0n6gMJg/QB6zJgDi/lQ65VfgLnoEMEZBf KQoQ== 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=UCVukTqOQDOCrGskg3fzJGKXyuarcVt01vk0C/SrdX8=; b=TY+H4/wLFKa7wkNIG4CNDZM7W+ykOEXe1H0j8fMOYNuuUl7tCeJDbhHKj0wq2yYrXg OcxsraYR5swSpqnTSruJdJ3JPyMFjsFoTqX1kcvjF2VH7eh+P1aULDQBhmc9oxZryrrY M7GYD2ACOXf/Fjijaya+hktXqQ4IHUeSEtRkCCH7XpUe3BCh+zr2tZ5ZRcKSh2f9BH9A tYQnz17+/q8wWqtz9PFqxrRCzj+VqO+p2zugdcvTd0CYVVgsJETcTV1lUya+rvMTucMH I8PQdGC2DrdFGABRrDVNDhLehWX7+j6Q3AaggDwEqe3pi+8QBPuX2gcgfYxLHQKwhKS8 Djmw== X-Gm-Message-State: AG10YOSFoqJolQJPI2p1jR5D7Zs09QAIpUxAFG5NLabKwg6Z+i+jkvgRxo2MPUhuCIzrXw== X-Received: by 10.107.138.203 with SMTP id c72mr43781475ioj.107.1456335321137; Wed, 24 Feb 2016 09:35:21 -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 qa4sm1643733igb.14.2016.02.24.09.35.20 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 09:35:20 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id z135so54390069iof.0 for ; Wed, 24 Feb 2016 09:35:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.159.7 with SMTP id wy7mr23025523igb.24.1456335315132; Wed, 24 Feb 2016 09:35:15 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 24 Feb 2016 09:35:14 -0800 (PST) In-Reply-To: <878u2ayqq6.fsf@hobgoblin.ariadne.com> References: <878u2ayqq6.fsf@hobgoblin.ariadne.com> Date: Wed, 24 Feb 2016 12:35:14 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a1136a72e21f213052c877db1 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 17:35:31 -0000 --001a1136a72e21f213052c877db1 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 24, 2016 at 12:15 PM, Dale R. Worley wrote: > This may break down if there is an RTP gateway in the middle, and while > the ultimate destination of the RTP is different, the sender is always > given the same destination address in the rewritten SDP that it is sent. > But such a gateway has problems knowing which destination to forward the > RTP to. > > What do people at sip-implementors say about this? > Speaking with an implementer hat on, based on the interop that I have conducted for audio based networks, most of them ignore the MUST NOT reuse PT rule. You routinely see PT changed or reused. To deal with this, if implementation is robust remote address change, SSRC change, or payload type change causes codec re-initialization based on the codec parameters in the latest SDP send by this end point. Such change is triggered by the packets after the jitter buffer, so all the packets using the previous codec profile for the particular PT should be processed and out of the system. If any of those packet do arrive late, they will be discarded either by jitter buffer as late packets or based on some sort of probation counter which starts on unexpected SSRC, remote address, or payload change. Regards, _____________ Roman Shpount --001a1136a72e21f213052c877db1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 24, 2016 at 12:15 PM, Dale R. Worley <= ;worley@ariadne.com= > wrote:
This may break down if there is an RTP gateway in the middle, and wh= ile
the ultimate destination of the RTP is different, the sender is always
given the same destination address in the rewritten SDP that it is sent. But such a gateway has problems knowing which destination to forward the RTP to.

What do people at sip-implementors say about this?
Speaking with an implementer hat on, based on the interop that = I have conducted for audio based networks, most of them ignore the MUST NOT= reuse PT rule. You routinely see PT changed or reused.

To deal with this, if implementation is robust remote address change,= SSRC change, or payload type change causes codec re-initialization based o= n the codec parameters in the latest SDP send by this end point. Such chang= e is triggered by the packets after the jitter buffer, so all the packets u= sing the previous codec profile for the particular PT should be processed a= nd out of the system. If any of those packet do arrive late, they will be d= iscarded either by jitter buffer as late packets or based on some sort of p= robation counter which starts on unexpected SSRC, remote address, or payloa= d change.

Regards,
_____________
Roman Shpount
=C2=A0
--001a1136a72e21f213052c877db1-- From nobody Wed Feb 24 09:55: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 817B11B3AD9 for ; Wed, 24 Feb 2016 09:55:47 -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_21=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 rZB0slGc-S8w for ; Wed, 24 Feb 2016 09:55:44 -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 A8B2B1B3B1A for ; Wed, 24 Feb 2016 09:55:44 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-04v.sys.comcast.net with comcast id NHua1s0032GyhjZ01Hvjr5; Wed, 24 Feb 2016 17:55:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id NHvi1s00P3KdFy101Hvj89; Wed, 24 Feb 2016 17:55:43 +0000 To: Christer Holmberg , Colin Perkins References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <56CC7E68.4040103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> <7C0829C0-0BA2-482B-91FD-9A3ED97977E7@csperkins.org> <7594FB04B1934943A5C02806D1A2204B37E3F63F@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CDEE9D.2050708@alum.mit.edu> Date: Wed, 24 Feb 2016 12:55:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E3F63F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456336543; bh=6CHn7Wsbg9o2qFw7cwpIW7tP2bqFwqzLGd72an7Kgy4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gEnZ6ib8S+EUuRCKhZSGbfYwT2cXR2SHzkROa6g0I07WFUOVodd7lTtsg0m6OIITp WtZsKFgtaDJTI7fycjz0qLmIFzUkzAKtWZ4e0e+unZLYShZ08Uf8KmSK5DBSfFHsbL eAn0UUI5QTtQFu2xrgq4ESsLnqzoN3c2REwIusDj+6++Vp5PR204I/SaBHf2/ey2w5 DXUTPOZasvA3pylEkT8WsUhj3zDp+MKjxJPhjuFwYPlb5RgN3rhNu0NSvZTq9jC9JB TM8RaBdXX9/VGqseAX0TAihJCzKB7q/CYD+vIg7E2wh9rZfRKzunB0BTBBHA6kSkhl bYjWB/sqFIutQ== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 17:55:48 -0000 Christer, See inline. On 2/24/16 6:08 AM, Christer Holmberg wrote: > Hi Colin, > >>>>> No objection in principle, but it’s not as simple as “a few network RTTs”: >>>>> >>>>> No ambiguity in decoding means that the packets need to have been >>>>> played out, so the codec state for that PT can be discarded. Some >>>>> systems can have large (multi-second) playout buffers. >>>>> >>>>> Any packets referring to the old PT also need to be gone. Formats >>>>> like RFC 6354 allow large offsets between streams, referenced by PT >>>>> (the example in Section 5 has a 5.1 second offset). >>>> >>>> Thanks for the insight. It helps to ground the discussion. >>>> >>>> I'm also interested in hearing if there might be *other* reasons behind the rules as they are written. >>>> >>>> The advantage of the current rule is that it is easy to explain, and >>>> is sufficient to deal with the problem you describe above. >>>> Unfortunately it is also difficult/impossible to comply with in some cases. If we are to replace it, we need to find something else to replace it with. >>> >>> The current rule may be easy to understand, but it's difficult to >>> understand - and that's what triggered this discussion :) >>> >>> So, while we can discuss possible rules/guidelines on when a PT value can be used, I still think we need to answer the first question: >>> >>> - If Alice allocates PT=X for codec 1, is Bob allowed to allocate PT=X for codec 2 within the same session? The current >>> text is unclear on that, and I think that is the first question we need to sort out. >> >> RFC 3551 (the RTP/AVP profile), section 3, top of page 7, says: >> >> mechanisms for defining dynamic payload type bindings have been >> specified in the Session Description Protocol (SDP) and in other >> protocols such as ITU-T Recommendation H.323/H.245. These mechanisms >> associate the registered name of the encoding/payload format, along >> with any additional required parameters, such as the RTP timestamp >> clock rate and number of channels, with a payload type number. This >> association is effective only for the duration of the RTP session in >> which the dynamic payload type binding is made. This association >> applies only to the RTP session for which it is made, thus the >> numbers can be re-used for different encodings in different sessions >> so the number space limitation is avoided. >> >> >> I always interpreted that as RTP payload types being per RTP session, not per SSRC. That may, or may not, be consistent with the SDP specifications. > > Q1: Then my next question is: when is the BINDING created? Is a binding created once a user has indicated (in an offer or answer) a PT/codec mapping - no matter if the other endpoint will use the same codec to begin with, or PT value for that codec? I agree this is an important question. The way 3264 was written it seems to mostly imply that the O/A is *negotiating* two-way usage of codecs rather than *declaring* independent usage of codecs in each direction. That made sense for a long time when usage focused on single stream audio. But it sometimes seems to waffle on that and subsequently, IIUC, has been interpreted to be more flexible than that. This has become much more important with multi-stream usage, such as webrtc and clue. I have the impression that initially it was expected that the same PT would be used on both ends. Later that got clarified so that the answerer can use a different PT than the offerer for the same codec configuration. With that, I think it is necessary that the PT reuse rule be applied independently on each end. In your questions below I'm assuming sendrecv applies to all the m-lines. (the other cases need to be analyzed separately.) > Example #1: > ---------------- > > Alice offers: > > PT 100: (AMR-WB) > PT 111: (VP8) > > Bob answers: > > PT 111: (VP8) > > Q2: Now, eventhough did not indicate support of AMR-WR, the BINDING between PT 100 and AMR-WR has still been created, and neither Alice or Bob is allowed to re-use PT 100 for anything else within the session? As noted above, I think bindings must be managed independently for each end. PT 100 is locked in on Alice's end, because Bob is allowed to send to it even though he didn't mention it in the answer. Alice can't use it for some other codec because Bob might have packets in flight that could then be misunderstood by Alice. But Alice is forbidden from sending PT 111 to Bob. So if Bob subsequently offers PT 111 with some other coded and Alice starts sending to it there can be no ambiguity about what is being received. So it seems ok to allow *that*. > Example #2: > ---------------- > > Alice offers: > > PT 100: (AMR-WB) > > Bob answers: > > PT 111: (AMR-WB) > > > Q3: Now, two bindings have been created: one binding between PT 100 and AMR-WB, and one binding between PT 111 and AMR-WB. After this, neither Alice or Bob is allowed to re-use PT 100 or PT 111 for anything else within the session? As I noted above, I think it must be the case that the bindings are managed independently on each end. > Q4: HOWEVER, even if Bob indicated PT 111 and AMR-WB, I assume Bob would still be allowed to indicate PT 100 and AMR-WB, as it does not conflict with the existing binding? Yes. It is explicitly allowed (I forget where) to map the same codec config to more than one PT (on the same end). (It isn't clear to me *why* one would do that.) Thanks, Paul From nobody Wed Feb 24 12:26: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 4A5851A8A68 for ; Wed, 24 Feb 2016 12:26:33 -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 2rAqA-2T_Q7S for ; Wed, 24 Feb 2016 12:26:31 -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 1626E1B3EDE for ; Wed, 24 Feb 2016 12:26:30 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-01-56ce11f44aa3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F7.A0.20792.4F11EC65; Wed, 24 Feb 2016 21:26:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 21:26:28 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsA== Date: Wed, 24 Feb 2016 20:26:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> In-Reply-To: <56CDE4FB.6090002@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ve5XwXNhBncXMFlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG+hn7GAv6lSqWPrjP3sD4V6qLkYNDQsBE YsqnxC5GTiBTTOLCvfVsXYxcHEIChxklmlo2sEA4ixklfl3sYQZpYBOwkOj+pw3SICLgK/Hs 8W02EFtYwF7i3/0PbBBxB4lNN64xQthhEkseTmIFsVkEVCXW7m1nB7F5gXofNTUwQcyfyCQx ZftBsGZOAR2JEy+XghUxAl30/dQaJhCbWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4StJNG4 5AkrRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYX 56YbGemlFmUmFxfn5+nlpZZsYgTGycEtv612MB587niIUYCDUYmHd8Pfs2FCrIllxZW5hxgl OJiVRHjXc5wLE+JNSaysSi3Kjy8qzUktPsQozcGiJM67xnl9mJBAemJJanZqakFqEUyWiYNT qoFRqjBU68vL9d+ZFWOeiF/+Y5HyfPKmMJO/M4I2fvxY7HfXZO9hYaeNlVvMNBOP5e6vVeBO ucs64SqH6+515073qebO4zP1PPlxKgtD4ty5IhwME+rmLl26L3barC0y95KP1Kn7N+782/N+ m9258/xMJZobszYsEEu4O6GFT3QX8+Sc/lzOW/+ElViKMxINtZiLihMBYAbCZI8CAAA= Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:26:33 -0000 Hi, ... -------------------- >>> * Section 5.1: >>> >>> The certificate received during the DTLS handshake MUST match the >>> fingerprint received in the SDP "fingerprint" attribute. If the >>> fingerprint does not match the hashed certificate, then the endpoin= t >>> MUST tear down the media session immediately. ... >>> >>> This talks about *the* fingerprint. But, IIUC, multiple fingerprints ma= y be supplied. What is the required processing in that case? >> >> We try to clarify that in section 3.4, which says: >> >> "It is possible to associate multiple SDP fingerprint attribute valu= es >> to an 'm-' line. If any of the attribute values associated with an >> 'm-' line are removed, or if any new attribute values are added, it >> is considered a fingerprint value change." > > Right. But AFAIK that is the only place it is mentioned. At the least, mo= st places that reference "the fingerprint"=20 > should acknowledge that there may be more than one. I guess we could use "one or more SDP 'fingerprint' attributes" terminology= instead of "an SDP 'fingerprint' attribute". > And *someplace* needs to say what the semantics of use are when there is = more than one. (Maybe it is defined in one=20 > of the references?) Am I correct in assuming that providing multiple fing= erprints is for the convenience of the > recipient, who can then pick the one that it prefers to verify? I don't think the semantics are defined anywhere, unless it is defined in s= ome RTCWEB document... I remember that it was agreed at some point that mul= tiple fingerprints were allowed, but I am not sure whether anything was wri= tten down in a specificaiton... In my opinion, the semantics belong to RFC 4572. -------------------- >>> * Section 5.3: >>> >>> If the offer specified 'existing' but the answerer changes to 'new',=20 >>> should the setup attribute settings remain as they had been? (Which=20 >>> then determines which end sends the ClientHello message.) >> >> Not sure I understand. If a new DTLS association is to be established, s= houldn't it be allowed=20 >> to re-negotiate the roles (read: change the value of the 'setup' attribu= te)? >> >> The problem is that the offerer specified "existing", and so followed th= e rules for doing that. So it had=20 >> to use the last negotiated setup value. But the answerer has decided to = switch to "new". At this point=20 >> there are limits on what it can do - there can't be a full negotiation. > > If the offer contained "active" or "passive" then the answerer is stuck w= ith what was previously negotiated. If the=20 > offer contained "actpass" then maybe the answerer could choose either "ac= tive" or "passive" independent of what=20 > was previously negotiated. I think this needs to be explained and clarifi= ed as to what is allowed. Ok, now I understand. The text does say that the 'setup' attribute must be set according to RFC 4= 572, so I think that covers what values are allowed. But, perhaps we could add a note, saying that if the answerer is not able t= o able to select a 'setup' value that reflects it capabilities, it must rej= ect the m- line. That of course also applies to the handling of the initial= offer. -------------------- NEW COMMMENT: >> In addition, I noticed that the document uses "DTLS connection" terminol= ogy in a few places, while the=20 >> intention is to use "DTLS association" (which is also used in the RFCs w= e update). >> >> The question is whether the name of the SDP attribute should still be "d= tls-connection", or whether we=20 >> should change it to "dtls-association". My personal preference would be = to keep the "dtls-connection" name, but I can live with both. > > On one hand using dtls-connection draws parallels with 'connection', whic= h might be good. Yes - that is exactly the reason why my preference is 'dtls-connection' :) > On the other hand the parallels aren't complete, so maybe changing it wou= ld emphasize that it *isn't* the same. Well, 'DTLS connection' is used in some specifications... > And then it is rather last in the process to be making this change. > > I guess I'm neutral on this. So, unless someone objects, I'll keep it as it is. Regards, Christer From nobody Wed Feb 24 12:36: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 129881B3F7F for ; Wed, 24 Feb 2016 12:36:52 -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 Jd-j-0_-JSDg for ; Wed, 24 Feb 2016 12:36:51 -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 813311B3F72 for ; Wed, 24 Feb 2016 12:36:49 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-05v.sys.comcast.net with comcast id NLbd1s0032Bo0NV01Lco0H; Wed, 24 Feb 2016 20:36:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id NLcn1s00Z3KdFy101LcnLg; Wed, 24 Feb 2016 20:36:48 +0000 References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> To: Jonathan Lennox From: Paul Kyzivat Message-ID: <56CE145F.5090903@alum.mit.edu> Date: Wed, 24 Feb 2016 15:36:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E400B7@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=1456346208; bh=Ae71YiZy+RDEPaMlLFORczIScWVDgBWDXZjWCdP/kOo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BwL7V3EnS9BeCTXa2JTRJArJ6OavKQG7JQwUaOjpiODmIsEaG6Daa8/IZ0iCT7XiH +s+j/UxlnzRJcfxTkaotPc192e+cAbwraK/XMqILLM6SIZ2KLvVejWiOBoiTvFRQlJ tDbF1nscmxqwiPvwDVw+bvPpBv6JxFOTOAzV6uhtDlaNOLuMrPYo4uBTLMoM9n5nse 1CHGH2l4sFqB0DIZ5hJIC1PD+lX+YwAec7zTkmrCbZu5T0DvaauOpj/ewVZ6CgeMWq 8cwLQCK6j89ABbEu+1jzdwzm+eudjb9U66PZIbnM283KoQ8tSS5xwFqxBVyUZ93tub 4XWJOTwI6mn3Q== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:36:52 -0000 Jonathan, Can you (as the author of RFC4572) explain the use of multiple fingerprints? The dtls-sdp draft talks about the possibility of multiple fingerprints, but I can find no explanation of the semantics of that. Thanks, Paul On 2/24/16 3:26 PM, Christer Holmberg wrote: >>>> * Section 5.1: >>>> >>>> The certificate received during the DTLS handshake MUST match the >>>> fingerprint received in the SDP "fingerprint" attribute. If the >>>> fingerprint does not match the hashed certificate, then the endpoint >>>> MUST tear down the media session immediately. ... >>>> >>>> This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case? >>> >>> We try to clarify that in section 3.4, which says: >>> >>> "It is possible to associate multiple SDP fingerprint attribute values >>> to an 'm-' line. If any of the attribute values associated with an >>> 'm-' line are removed, or if any new attribute values are added, it >>> is considered a fingerprint value change." >> >> Right. But AFAIK that is the only place it is mentioned. At the least, most places that reference "the fingerprint" >> should acknowledge that there may be more than one. > > I guess we could use "one or more SDP 'fingerprint' attributes" terminology instead of "an SDP 'fingerprint' attribute". > >> And *someplace* needs to say what the semantics of use are when there is more than one. (Maybe it is defined in one >> of the references?) Am I correct in assuming that providing multiple fingerprints is for the convenience of the >> recipient, who can then pick the one that it prefers to verify? > > I don't think the semantics are defined anywhere, unless it is defined in some RTCWEB document... I remember that it was agreed at some point that multiple fingerprints were allowed, but I am not sure whether anything was written down in a specificaiton... > > In my opinion, the semantics belong to RFC 4572. From nobody Wed Feb 24 12:44: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 5EADC1B4011 for ; Wed, 24 Feb 2016 12:44:41 -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 SLWutgLkB6CD for ; Wed, 24 Feb 2016 12:44:38 -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 1F5CF1B3FF6 for ; Wed, 24 Feb 2016 12:44:25 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-c8-56ce16274539 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.64.28465.7261EC65; Wed, 24 Feb 2016 21:44:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 21:43:47 +0100 From: Christer Holmberg To: Paul Kyzivat , Jonathan Lennox , "Eric Rescorla (ekr@rtfm.com)" , "Martin Thomson (martin.thomson@gmail.com)" , "Justin Uberti (juberti@google.com)" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsP//9/iAgAASgkA= Date: Wed, 24 Feb 2016 20:43:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> In-Reply-To: <56CE145F.5090903@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7ma6G2Lkwg84P3BYrXp9jt9i/+Dyz xdapQhbXzvxjtJi6/DGLxYoNB1gd2Dz+vv/A5LFz1l12jwWbSj2WLPnJ5DH5cRuzR9uzO+wB bFFcNimpOZllqUX6dglcGdevKxb8Fa5ovN3F3sD4gb+LkZNDQsBEomn/YSYIW0ziwr31bF2M XBxCAocZJXYdP80O4SxmlHj8ZjZzFyMHB5uAhUT3P22QuIhAG5PEs57nTCBxZgF1iauLg0AG CQvYS/y7/4ENxBYRcJDYdOMaI4SdJLGyaSULiM0ioCoxc8ItMJtXwFfi6ayHULu+M0nc+7UR bCangI7EwpncIDWMQMd9P7UG7FBmAXGJW0/mQx0tILFkz3lmCFtU4uXjf6wQtpJE45InrBD1 OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSs l1qUmVxcnJ+nl5dasokRGIkHt/zW3cG4+rXjIUYBDkYlHt4Nf8+GCbEmlhVX5h5ilOBgVhLh Xc9xLkyINyWxsiq1KD++qDQntfgQozQHi5I47xrn9WFCAumJJanZqakFqUUwWSYOTqkGxpmz /yhkBmT/4EyZepHTalqVRsoXrbWz5cyveZZr+DnPDHwlyn7bJ2xDcGAO67/420pqWnkMmyxq 2w6JCrN7xcYLBj/49qyr0epDobN9tLOAmE/kYbetZwWfq6//dZjr9Z1PyWoz3DTXqL9eEVIn orR3s0qS2werTwvXfulYs/C/9q8w9uU+SizFGYmGWsxFxYkAIbdpBcACAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:44:41 -0000 Adding Ekr, Martin and Justin, because I think they (or, at least some of t= hem :) were behind the idea of allowing multiple fingerprints. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 24 February 2016 22:37 To: Jonathan Lennox Cc: Christer Holmberg ; mmusic@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Jonathan, Can you (as the author of RFC4572) explain the use of multiple fingerprints= ? The dtls-sdp draft talks about the possibility of multiple fingerprints, = but I can find no explanation of the semantics of that. Thanks, Paul On 2/24/16 3:26 PM, Christer Holmberg wrote: >>>> * Section 5.1: >>>> >>>> The certificate received during the DTLS handshake MUST match the >>>> fingerprint received in the SDP "fingerprint" attribute. If the >>>> fingerprint does not match the hashed certificate, then the endpo= int >>>> MUST tear down the media session immediately. ... >>>> >>>> This talks about *the* fingerprint. But, IIUC, multiple fingerprints m= ay be supplied. What is the required processing in that case? >>> >>> We try to clarify that in section 3.4, which says: >>> >>> "It is possible to associate multiple SDP fingerprint attribute va= lues >>> to an 'm-' line. If any of the attribute values associated with a= n >>> 'm-' line are removed, or if any new attribute values are added, i= t >>> is considered a fingerprint value change." >> >> Right. But AFAIK that is the only place it is mentioned. At the least, m= ost places that reference "the fingerprint" >> should acknowledge that there may be more than one. > > I guess we could use "one or more SDP 'fingerprint' attributes" terminolo= gy instead of "an SDP 'fingerprint' attribute". > >> And *someplace* needs to say what the semantics of use are when there=20 >> is more than one. (Maybe it is defined in one of the references?) Am=20 >> I correct in assuming that providing multiple fingerprints is for the co= nvenience of the recipient, who can then pick the one that it prefers to ve= rify? > > I don't think the semantics are defined anywhere, unless it is defined in= some RTCWEB document... I remember that it was agreed at some point that m= ultiple fingerprints were allowed, but I am not sure whether anything was w= ritten down in a specificaiton... > > In my opinion, the semantics belong to RFC 4572. From nobody Wed Feb 24 12:48: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 D5A121B3FD3 for ; Wed, 24 Feb 2016 12:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 fYOAFtZJW9WF for ; Wed, 24 Feb 2016 12:48: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 93DA31B3F6D for ; Wed, 24 Feb 2016 12:48:08 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id z135so66536236iof.0 for ; Wed, 24 Feb 2016 12:48:08 -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=LyijGFIbFB0uaxkQGn77eFT7ZQtvbB+IFD0vy7SCToI=; b=zRWODBaeQG9XeEy9rcMOq7MaLyWI1YaeIm5D0JjN2ENk+xXkajrVm86Zxi+rctcL3h o+zgiTbdI8xRzfgnyTFbrn6yeLs+s1SEOo62Y5i2ECM9RFFkpk2lWRbhn7ilfaeM53+c v/DiLzPVTLPCMoTPzlyfgEe+Ep60CJ0HNyzs9D2NCMSCq+TtTwz/AWdYopBCMhxHmVIs vcKBrJq9OcYHx2GgBM1IhEOZSBUoiPwUkMkXYD8BVspMztI7N2XWWJGZDkDoeqeWqKmV fZkxWK42NVZTty61LcxoMxqtSscn6oah/rPySac+384Jts0+EsCPUBnRDu2Bp8zJ0N8A JFng== 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=LyijGFIbFB0uaxkQGn77eFT7ZQtvbB+IFD0vy7SCToI=; b=ZJ9admnydFXgbEq1iQY3Zya8WRKn+8UaSWKswKgt6p0nFaKMVDC8nu9tGRtUIn/Aci B9DRq4AJuw0kdPprt8XvuTffbxy46xgK74mhCOp9pYW8vcbf3431CEE0UZI6qb8IRIlx ljwbIBxR1L6VdjYxUhGUNPE8o4fgqh+WfnJQpBm+1Vi0neyMZKoEMmyd1up1Df0neYcL IxP16VVg4XQgciMk70HyY5Wz8yTi/KLtujyp+YcR8cp6Om/coG10xXivgJ+hEHiWBe2t UEKp0KYEJDtF3t5ZFanCz4kENQYkt1Mj0+BCNR5x4yh13cu07ySx1ZcBx/eTmVcIMggr NOlw== X-Gm-Message-State: AG10YOQQkiNAPV5JdmY0qFro6Mc5jjgbquISYpd+mzgEGXS9AABToMFTYgeFqY7R//8Qdg== X-Received: by 10.107.135.150 with SMTP id r22mr38586185ioi.92.1456346888064; Wed, 24 Feb 2016 12:48:08 -0800 (PST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id l11sm1963715iol.17.2016.02.24.12.48.06 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 12:48:06 -0800 (PST) Received: by mail-io0-f172.google.com with SMTP id g203so65744711iof.2 for ; Wed, 24 Feb 2016 12:48:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.28.48 with SMTP id y16mr24006801igg.2.1456346886075; Wed, 24 Feb 2016 12:48:06 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 24 Feb 2016 12:48:05 -0800 (PST) In-Reply-To: <56CE145F.5090903@alum.mit.edu> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> Date: Wed, 24 Feb 2016 15:48:05 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0158b360d07c26052c8a2e9d Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:48:10 -0000 --089e0158b360d07c26052c8a2e9d Content-Type: text/plain; charset=UTF-8 On Wed, Feb 24, 2016 at 3:36 PM, Paul Kyzivat wrote: > Can you (as the author of RFC4572) explain the use of multiple > fingerprints? The dtls-sdp draft talks about the possibility of multiple > fingerprints, but I can find no explanation of the semantics of that. > I think the original explanation was that TLS (or DTLS) session is terminated if none of the fingerprints matched. In other words, at least one fingerprint MUSt match for the session to be established, One of the use cases is when RTP and RTCP DTLS flows are using different certificates. In this case two fingerprint attributes will be added to SDP m= line. When separate DTLS associations are established for RTP and RTCP, each of these association will match one of the fingerprints and fail to match the other. Another use case is to generate an offer that will work with remote end points that support different certificate signature algorithms. For instance when transitioning from SHA-1 to SHA-256 two certificates would be created by the origination end point and fingerprints for both will be included. When DTLS association is negotiated, it will establish which certificate signature algorithm is supported by both parties and use the appropriate certificate. Once again, only one of the fingerprints will match. _____________ Roman Shpount --089e0158b360d07c26052c8a2e9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 24, 2016 at 3:36 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
Can you (as the author of RFC4572) explain the use of multiple fi= ngerprints? The dtls-sdp draft talks about the possibility of multiple fing= erprints, but I can find no explanation of the semantics of that.

I think the original explanation was that TLS (o= r DTLS) session is terminated if none of the fingerprints matched. In other= words, at least one fingerprint MUSt match for the session to be establish= ed,

One of the use cases is when RTP and RTCP DTLS= flows are using different certificates. In this case two fingerprint attri= butes will be added to SDP m=3D line. When separate DTLS associations are e= stablished for RTP and RTCP, each of these association will match one of th= e fingerprints and fail to match the other.

Anothe= r use case is to generate an offer that will work with remote end points th= at support different certificate signature algorithms. For instance when tr= ansitioning from SHA-1 to SHA-256 two certificates would be created by the = origination end point and fingerprints for both will be included. When DTLS= association is negotiated, it will establish which certificate signature a= lgorithm is supported by both parties and use the appropriate certificate. = Once again, only one of the fingerprints will match.
_____________
Roman Shpount
=C2=A0<= /div>
--089e0158b360d07c26052c8a2e9d-- From nobody Wed Feb 24 12:48:35 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 2565B1B3FD6 for ; Wed, 24 Feb 2016 12:48: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 YIn34vhkdJl0 for ; Wed, 24 Feb 2016 12:48:31 -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 583091B403A for ; Wed, 24 Feb 2016 12:48:25 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-04v.sys.comcast.net with comcast id NLnX1s0082GyhjZ01LoQGa; Wed, 24 Feb 2016 20:48:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id NLoQ1s0023KdFy101LoQSq; Wed, 24 Feb 2016 20:48:24 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CE1717.1060703@alum.mit.edu> Date: Wed, 24 Feb 2016 15:48:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E400B7@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=1456346904; bh=5GyI74A9Hsu0OJ3DFdHiqm3NSZQ/whpQAjY/axfVBw8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=v2EhOossisZC8+03uyqp640hv1+3YqU7EY4a6mRka4PpVODSIMzlwZWb4ct5NFxeZ aF6UOOpPMZG66gZVLub/u9ycCnlororIV24rB1f1Jg4t2s6v/8urF+em/s1qJst70J QnSc5hi34mHG9rgcBpYDHKKMQLxS77R4HgVOEONlPZAkJt9+tjuXtYJ930gUceflzZ eN7YFKy2Oh/3pWPENVG/Ts8sunyY+lmgadDPRHp+dpX8yLAd3EYCXedn79q+MbILsP 818bw8G+6Iohf+QtFDVIg0klwODm3gQoRcNMbKhHyOBpi/av4nURxiThTrgxd02sE6 1DO8ULuo5gpWg== Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:48:33 -0000 Christer, On 2/24/16 3:26 PM, Christer Holmberg wrote: > Hi, > > ... > > -------------------- > >>>> * Section 5.1: >>>> >>>> The certificate received during the DTLS handshake MUST match the >>>> fingerprint received in the SDP "fingerprint" attribute. If the >>>> fingerprint does not match the hashed certificate, then the endpoint >>>> MUST tear down the media session immediately. ... >>>> >>>> This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case? >>> >>> We try to clarify that in section 3.4, which says: >>> >>> "It is possible to associate multiple SDP fingerprint attribute values >>> to an 'm-' line. If any of the attribute values associated with an >>> 'm-' line are removed, or if any new attribute values are added, it >>> is considered a fingerprint value change." >> >> Right. But AFAIK that is the only place it is mentioned. At the least, most places that reference "the fingerprint" >> should acknowledge that there may be more than one. > > I guess we could use "one or more SDP 'fingerprint' attributes" terminology instead of "an SDP 'fingerprint' attribute". That would work. But maybe this should wait for clarification on the use of multiple fingerprints. >> And *someplace* needs to say what the semantics of use are when there is more than one. (Maybe it is defined in one >> of the references?) Am I correct in assuming that providing multiple fingerprints is for the convenience of the >> recipient, who can then pick the one that it prefers to verify? > > I don't think the semantics are defined anywhere, unless it is defined in some RTCWEB document... I remember that it was agreed at some point that multiple fingerprints were allowed, but I am not sure whether anything was written down in a specificaiton... > > In my opinion, the semantics belong to RFC 4572. I sent a separate reply on this, asking Jonathan to comment. > -------------------- > >>>> * Section 5.3: >>>> >>>> If the offer specified 'existing' but the answerer changes to 'new', >>>> should the setup attribute settings remain as they had been? (Which >>>> then determines which end sends the ClientHello message.) >>> >>> Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed >>> to re-negotiate the roles (read: change the value of the 'setup' attribute)? >>> >>> The problem is that the offerer specified "existing", and so followed the rules for doing that. So it had >>> to use the last negotiated setup value. But the answerer has decided to switch to "new". At this point >>> there are limits on what it can do - there can't be a full negotiation. >> >> If the offer contained "active" or "passive" then the answerer is stuck with what was previously negotiated. If the >> offer contained "actpass" then maybe the answerer could choose either "active" or "passive" independent of what >> was previously negotiated. I think this needs to be explained and clarified as to what is allowed. > > Ok, now I understand. > > The text does say that the 'setup' attribute must be set according to RFC 4572, so I think that covers what values are allowed. Now that we have discussed it, I agree that this is sufficient. > But, perhaps we could add a note, saying that if the answerer is not able to able to select a 'setup' value that reflects it capabilities, it must reject the m- line. That of course also applies to the handling of the initial offer. Yes. I'm not sure if this is needed. When setup is used with TCP/SCTP there may be cases where passive can't be supported, because incoming connection requests are blocked. (That was one of the reasons for negotiating this.) But I don't think that holds for DTLS if the transport has already been established. So AFAIK nothing should prevent either end from taking either role. So it might not need to be mentioned. Thanks, Paul From nobody Wed Feb 24 13:01: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 402DD1AD05E; Wed, 24 Feb 2016 13:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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.006, 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 WAD9Ol6Zukf7; Wed, 24 Feb 2016 13:01:09 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3B81B3ED9; Wed, 24 Feb 2016 13:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6814; q=dns/txt; s=iport; t=1456347665; x=1457557265; h=from:to:cc:subject:date:message-id:mime-version; bh=2oxT3UAUYHk4EdDMCBFpSpGWz3N0D8LuKpDK8KR/fxU=; b=SHroUVEkhLVjS9ASv4DZLF2ZzqchME4ImoGU/sCBGyGdrawNwuSa82jG uwBwNsNl6A6RtL+0aGD2yjmAlnCIZbSXBjNDCAOhAA/LCXghqboHMGFuM QK5oKxrg/E7EW8LF4qnL7pVR4ovwoXKXNiOQdhMEXLC8VIluebmAo9I9u U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgAtGc5W/4QNJK1egm5MUm0GuFSCE?= =?us-ascii?q?wENgWaGDgKBSTgUAQEBAQEBAWQnhEEBAQEELUwSAQgRAwEBASg5FAkKBAENBYg?= =?us-ascii?q?fvWMBAQEBAQEBAQEBAQEBAQEBAQEBAQEVikyEVRaEBAWIMYUxiSUBjV6OdI5IA?= =?us-ascii?q?R4BAUKDZGqGY30BAQE?= X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208,217";a="241306751" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2016 21:01:05 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1OL157Q011313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 21:01:05 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 15:01:04 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 15:01:04 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-08 Thread-Index: AQHRb0Z53CBPc4pqXEuuYiz3ZMxx+g== Date: Wed, 24 Feb 2016 21:01:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.40] Content-Type: multipart/alternative; boundary="_000_D2F359CC67B86eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-08 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, 24 Feb 2016 21:01:12 -0000 --_000_D2F359CC67B86eckelcuciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm fine with how this addressed my comments. Thanks Christer. Cheers, Charles From: mmusic > on b= ehalf of Christer Holmberg > Date: Sunday, February 21, 2016 at 11:45 AM To: "mmusic@ietf.org" > Cc: "mmusic-chairs@ietf.org" > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-08 And now version-08, based on the reference nit found by Gonzalo. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 21 February 2016 21:26 To: mmusic@ietf.org Cc: mmusic-chairs@ietf.org Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07 Hi, Based on comments and feedback received, I've submitted a new version (-07)= of draft-ietf-mmusic-dtls-sdp. Regards, Christer --_000_D2F359CC67B86eckelcuciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <56B9B0A533E60E4C8FD9E1717E5CCAAA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I’m fine with how this addressed my comments. Thanks Christer.

Cheers,
Charles

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Sunday, February 21, 2016 at = 11:45 AM
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
Subject: [MMUSIC] Draft new version= : draft-ietf-mmusic-dtls-sdp-08

And now version-08, ba= sed on the reference nit found by Gonzalo.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 21 February 2016 21:26
To: mmusic@ietf.org
Cc: mmusic-chairs@ietf.org=
Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-07

 

Hi,

 

Based on comments and feedback received, I’ve = submitted a new version (-07) of draft-ietf-mmusic-dtls-sdp.

 

Regards,

 

Christer

 --_000_D2F359CC67B86eckelcuciscocom_-- From nobody Wed Feb 24 13:12: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 447DF1ACDDD for ; Wed, 24 Feb 2016 13:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 D8C2gr_Dyqsk for ; Wed, 24 Feb 2016 13:12:11 -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 945081A8AEA for ; Wed, 24 Feb 2016 13:12:11 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g203so67158977iof.2 for ; Wed, 24 Feb 2016 13:12: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=HmW21XEUZqaKe8Wbx8HITDr3fT3Kvt+wRg3JSSAh5ss=; b=hXncqP1dRvmI0jFDFkVWic5NZ+xI6zqOMoGP27xCuxPBdYvHUBazzTLs9fanFwCcR/ W3GcAJ0pxavp6e/kRFP08PwZ28uxKS/sYO/yyTzeGjq1T8x1QCh8n3m0I1jDlTUYcX0h MrHDjqwxY4D5/05MlVe4wAdSq83LBh34PuuclboCB8wRXVw3J7JZ/TOkDfuQANPWGUZo UWCnaiECoZeAn244KSXDgusWW2v+5GOenVznnozYi6AXVtyOUTahHhGga0aULfxu3Dfq 7jbMHSgIhPzFHeT93+C5KoU0894qQ/fTYZeZLjg3KoufxlRE7IFeHrnTlRb0Ym5aXy/R QE2g== 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=HmW21XEUZqaKe8Wbx8HITDr3fT3Kvt+wRg3JSSAh5ss=; b=Q1SLJAXFhRJhoW6FYRylXRK4fY+PmCnJQ2Ogrg7EQoSs0B8rYRh1v9xdpoFVjsUtOc EUdk5ml/va47Enp01jLEOc9h2h5IiXfW+ChITnJ1QIqWRQ/KX4wtSqArfIrQzzaPKx+E 4tlCjOrWG++KEf01rTH3bHm4b9nnRtVs2elD3dpg7xCq+GGs4t9oW4wXSBNIMt+B1LZQ ZazEKn7ho3UCI+Hk7iXop6ydM1T1glMCFTiK0nq6aUKsWj488gczJ93NlnAJh7Bc2XNt zCSsGhW5DT6j9VvSD7NLz8NEJORyaMZCsAPG31pQw6+IOfbLTtDubeP63Tiagmn5p6Zb 2C/w== X-Gm-Message-State: AG10YOTOY7rUg6PQFHw7NFHhaRz8QYilm/J1CJ+ooNllI2pv9vmK+FOo2N4ilmpetGjCFEqYD0O2x+jMJqNqNA== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr29127959iop.100.1456348330969; Wed, 24 Feb 2016 13:12:10 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 13:12:10 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> Date: Wed, 24 Feb 2016 13:12:10 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:12:13 -0000 On 24 February 2016 at 12:43, Christer Holmberg wrote: > Adding Ekr, Martin and Justin, because I think they (or, at least some of them :) were behind the idea of allowing multiple fingerprints. https://tools.ietf.org/html/draft-thomson-mmusic-fingerprint-00 is an old take on the problem, it contains an explanation of what I think the intent was. From nobody Wed Feb 24 13:12: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 84A541B2FF3 for ; Wed, 24 Feb 2016 13:12:37 -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 A5nZZKH7p0eh for ; Wed, 24 Feb 2016 13:12:36 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3900B1B3844 for ; Wed, 24 Feb 2016 13:12:32 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-07v.sys.comcast.net with comcast id NMCW1s00A57bBgG01MCXgm; Wed, 24 Feb 2016 21:12:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-13v.sys.comcast.net with comcast id NMCW1s0083KdFy101MCWMh; Wed, 24 Feb 2016 21:12:30 +0000 To: mmusic@ietf.org References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> From: Paul Kyzivat Message-ID: <56CE1CBD.70504@alum.mit.edu> Date: Wed, 24 Feb 2016 16:12:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: 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=1456348351; bh=Vp1XaMbvA+OmQ7TVlcuZwg3dFuCbbSo323ei1bQrCfw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Uc1aEfaPOOGMijzx2aCq5ELB8Pl+OsU1BfeBpj7r4W38lzRUo12PTqVOExbgz5Kl8 xlQNbA98su6waw1xvf6r0m8LDYcuqIk13OInsNbLhRbOMThv7y4vX0ER3QMRw1EQtZ 9tYBwo2M7G5U6eWiDOtHzh2Hv68HAH9Mwmmm7kfV9fvRLQbVvtdo5an+lH+PdaJaRA uHkpi33t7vYt+RqZjkR/HRHDvf21yyelJWrNZAVba7zmEpSJ/CQBkXLPgrLK0S1f9P L0w/csmFcwizTB69IMZ27rxG7R0LXYH36HQ+pDc36MzYOZIpQ/P89Agkt414kU93E+ o4fvceZtBZBoQ== Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:12:37 -0000 On 2/24/16 3:48 PM, Roman Shpount wrote: > On Wed, Feb 24, 2016 at 3:36 PM, Paul Kyzivat > wrote: > > Can you (as the author of RFC4572) explain the use of multiple > fingerprints? The dtls-sdp draft talks about the possibility of > multiple fingerprints, but I can find no explanation of the > semantics of that. > > > I think the original explanation was that TLS (or DTLS) session is > terminated if none of the fingerprints matched. In other words, at least > one fingerprint MUSt match for the session to be established, > > One of the use cases is when RTP and RTCP DTLS flows are using different > certificates. In this case two fingerprint attributes will be added to > SDP m= line. When separate DTLS associations are established for RTP and > RTCP, each of these association will match one of the fingerprints and > fail to match the other. Where is that explained? > Another use case is to generate an offer that will work with remote end > points that support different certificate signature algorithms. For > instance when transitioning from SHA-1 to SHA-256 two certificates would > be created by the origination end point and fingerprints for both will > be included. When DTLS association is negotiated, it will establish > which certificate signature algorithm is supported by both parties and > use the appropriate certificate. Once again, only one of the > fingerprints will match. But rfc4572 says: A certificate fingerprint MUST be computed using the same one-way hash function as is used in the certificate's signature algorithm. (This ensures that the security properties required for the certificate also apply for the fingerprint. It also guarantees that the fingerprint will be usable by the other endpoint, so long as the certificate itself is.) That seems to exclude creating fingerprints with multiple algorithms, or any need to do so. Looking deeper, I find OLD TEXT (from 7345) that talks about multiple fingerprints, for differing cipher suites. So I guess in that case multiple certificates will also be presented, with a fingerprint for each, and it is only necessary to verify one of them. But the NEW TEXT removes all of this, changing it to refer to *this* draft. But equivalent text isn't present in this draft!!! Thanks, Paul From nobody Wed Feb 24 13:22: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 163241B2EE0 for ; Wed, 24 Feb 2016 13:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 pvZJyWHG9sxo for ; Wed, 24 Feb 2016 13:22:04 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 CDA121A8A68 for ; Wed, 24 Feb 2016 13:22:03 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id y8so129355igp.1 for ; Wed, 24 Feb 2016 13:22: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 :cc:content-type; bh=+Bp+1HzxFaw8JIO7QAW16btQfOjMX4ukFpezrWQ7Ni0=; b=Co+ByyKYcfy7NIlbQJlH/5Gyyk7YossF8IRKss7d1eJmTx8N+p05edDpBd2dPrqRvy 0cITbMEnYOdDacegGDMzqUGLTYT1MtLFeWSgaVtwEcgeffp5w+GXJ2YbjBJZlAi/DHFQ rqmEUt9S8kys5S+szODpejXmNmEfHkcXfnITMC04d0FHY31obA+JRsyhGotnlgxpgDPb XTmPnSMTTK7u6wYdimIzvnVDR68OSFws+Fogp+N60dDrEyXRLanV8NAhCX1njU0KHDWr 3a7FL9dRbIN9XSA3zS28X7tEhvMJhmDif24Qq0TDdSFwNX6aPw2P6yRHtty57c6rSwas YAAA== 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=+Bp+1HzxFaw8JIO7QAW16btQfOjMX4ukFpezrWQ7Ni0=; b=J+h5QFRgJU0lLtdKt9R6+2x6CWzYWg2VW0ran3KToMz6k5/W1r4smp1GN2ErZVquRx CyQoDTfQtx8NEQ+Ha9anyom6TZIMIXu9OPUbmNoZxyURYP/+QYZdWyfRx2ZSRZsVmpiN Oiubj3FFVBt2DQrQ/FAwvC7qLTzFSQfmHSYAHupEtn+Vu0GJvCzDRGimypRmG9sBpeu7 wkj6r8GA2tOg0sAFEDxxYtuHUtJ45k39pEmw/87nEbnrE9mvP1AVrB4D1azMnaX1NtVa 2VK0g697JloIN2fwpQc5DfnA3WOaEkkR75N/qJWL9cP8gZ4T4pAYaQwRVkfxh+u9cMC6 F1sQ== X-Gm-Message-State: AG10YOT4JrDr2cho9N88Ao+XDD0m/BC0KtG7vM7sXz4fE24AqpThSedRoyEAvuP41Plp+A== X-Received: by 10.50.66.203 with SMTP id h11mr68937igt.72.1456348923239; Wed, 24 Feb 2016 13:22:03 -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 ys7sm15881igb.21.2016.02.24.13.22.01 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 13:22:01 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id y8so128641igp.1 for ; Wed, 24 Feb 2016 13:22:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.109.196 with SMTP id hu4mr21997igb.24.1456348921194; Wed, 24 Feb 2016 13:22:01 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 24 Feb 2016 13:22:01 -0800 (PST) In-Reply-To: <56CE1CBD.70504@alum.mit.edu> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <56CE1CBD.70504@alum.mit.edu> Date: Wed, 24 Feb 2016 16:22:01 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e011605a21e0305052c8aa8bf Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:22:05 -0000 --089e011605a21e0305052c8aa8bf Content-Type: text/plain; charset=UTF-8 On Wed, Feb 24, 2016 at 4:12 PM, Paul Kyzivat wrote: > > But rfc4572 says: > > A certificate fingerprint MUST be computed using the same one-way > hash function as is used in the certificate's signature algorithm. > (This ensures that the security properties required for the > certificate also apply for the fingerprint. It also guarantees that > the fingerprint will be usable by the other endpoint, so long as the > certificate itself is.) > > That seems to exclude creating fingerprints with multiple algorithms, or > any need to do so. > > Looking deeper, I find OLD TEXT (from 7345) that talks about multiple > fingerprints, for differing cipher suites. So I guess in that case multiple > certificates will also be presented, with a fingerprint for each, and it is > only necessary to verify one of them. > > But the NEW TEXT removes all of this, changing it to refer to *this* > draft. But equivalent text isn't present in this draft!!! > I was talking about using multiple fingerprints to offer multiple cipher suites. I am not sure what draft this is present in, but this is what EKR explained to me in on the list. Can you send the reference to this OLD TEXT you mentioned so that it can be added to this draft? Thank You, _____________ Roman Shpount --089e011605a21e0305052c8aa8bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 24, 2016 at 4:12 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

 But rfc4572 says:

=C2=A0 =C2=A0A certificate fingerprint MUST be computed using the same one-= way
=C2=A0 =C2=A0hash function as is used in the certificate's signature al= gorithm.
=C2=A0 =C2=A0(This ensures that the security properties required for the =C2=A0 =C2=A0certificate also apply for the fingerprint.=C2=A0 It also guar= antees that
=C2=A0 =C2=A0the fingerprint will be usable by the other endpoint, so long = as the
=C2=A0 =C2=A0certificate itself is.)

That seems to exclude creating fingerprints with multiple algorithms, or an= y need to do so.

Looking deeper, I find OLD TEXT (from 7345) that talks about multiple finge= rprints, for differing cipher suites. So I guess in that case multiple cert= ificates will also be presented, with a fingerprint for each, and it is onl= y necessary to verify one of them.

But the NEW TEXT removes all of this, changing it to refer to *this* draft.= But equivalent text isn't present in this draft!!!

I was talking about using multiple fingerprints to offer m= ultiple cipher suites. I am not sure what draft this is present in, but thi= s is what EKR explained to me in on the list.

Can = you send the reference to this OLD TEXT you mentioned so that it can be add= ed to this draft?

Thank You,
_____________
Roman Shpount
=C2=A0<= /div>
--089e011605a21e0305052c8aa8bf-- From nobody Wed Feb 24 13:47: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 4C3DA1A0015 for ; Wed, 24 Feb 2016 13:47:15 -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 nf3oMgnCyAKf for ; Wed, 24 Feb 2016 13:47:13 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C1A1A8742 for ; Wed, 24 Feb 2016 13:47:13 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-08v.sys.comcast.net with comcast id NMmg1s00229Cfhx01MnCnP; Wed, 24 Feb 2016 21:47:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id NMnB1s00F3KdFy101MnBfR; Wed, 24 Feb 2016 21:47:12 +0000 To: Martin Thomson , Christer Holmberg References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CE24DE.6090300@alum.mit.edu> Date: Wed, 24 Feb 2016 16:47:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.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=1456350432; bh=jxfBsED+pOeWf+KGAIIngPNe20emDrMCzxj/lTQjjCw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=TLIsaM9G8yMaZ5mkBGLUmZTP+R3L3Aq5xmM7tNY5Ga2SNrRLqN3Ff7i2lxAgxna46 cJ9lgg4+XO/sJw2+5mtziZyJMSa9QekRXSWwPoIJOEa93fjfhjprFH1jxQ5oi0I5bj EIZ7DKq1wl4NvMCRUEb2wv+tEP9guj6S3vPb3KDKsBreQTf4+/7JTlT3uPh8gpSxT8 IxDMkX6/Z/GXnyRKJ6S30Yg0CdKjRZYFYJgKUgl4i32HmpDHWBmEYYFQInvCtAGyBJ zeT+FiQiajMJM2ET+FKoCUUSUayscou+28coGI5JIDbou0Pu/6em8e7E1e6BAbSKH5 y8r0HIS2wG/HA== Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:47:15 -0000 On 2/24/16 4:12 PM, Martin Thomson wrote: > On 24 February 2016 at 12:43, Christer Holmberg > wrote: >> Adding Ekr, Martin and Justin, because I think they (or, at least some of them :) were behind the idea of allowing multiple fingerprints. > > > https://tools.ietf.org/html/draft-thomson-mmusic-fingerprint-00 is an > old take on the problem, it contains an explanation of what I think > the intent was. > I can't say I fully understand it, or its implications. But it does look like it might have been the basis of the text under discussion. But I gather this never ended up in any active draft/rfc. If we are going to make normative references to multiple fingerprints we need some place authoritative to reference for the details. Thanks, Paul From nobody Wed Feb 24 13:51: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 874AD1B2D0D for ; Wed, 24 Feb 2016 13:50:59 -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 jfzog2WQO14v for ; Wed, 24 Feb 2016 13:50:58 -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 7C0861B325D for ; Wed, 24 Feb 2016 13:50:58 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with comcast id NMpA1s00C2GyhjZ01Mqxnk; Wed, 24 Feb 2016 21:50:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id NMqx1s0043KdFy101Mqxgi; Wed, 24 Feb 2016 21:50:57 +0000 To: Roman Shpount References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <56CE1CBD.70504@alum.mit.edu> From: Paul Kyzivat Message-ID: <56CE25BF.7010201@alum.mit.edu> Date: Wed, 24 Feb 2016 16:50:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.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=1456350657; bh=f1wfXwNthPXvv2lDKpcHWBjxsIHqGUfbvHLa5Svx3no=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=nrHAAUd8PSeXFeAMOUDjiO9F9hJImUK1BCmKn7Y6IsfteUUuQ/py/LjFo4R02S7cX Y2eSisVj9G+3cuRecIyLpho3OO11cGb1/FfBZdioQIRWT+Gemkoab9GjawkdHCUO0a awmsoW/8TbbVl1YXyhqPyHI21dBwQQnQUBgcJf5P6TBsw/1ZKBfsaCYqgdlfc3K59Q eP+Iz2Dgiiu3TR4EEhvnzmZ7zNetZpo6Svtqdn5nDj41nH4jhQmiDpIFQre0DsnKF8 OyN8RZVogA4zQAlALknhiitoM6juZnP6lSQcvs6XQg8CIQ4hbIFlAIaIJvqt2xCpnu joVNkf9OeWWjw== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:50:59 -0000 On 2/24/16 4:22 PM, Roman Shpount wrote: > On Wed, Feb 24, 2016 at 4:12 PM, Paul Kyzivat > wrote: > > > But rfc4572 says: > > A certificate fingerprint MUST be computed using the same one-way > hash function as is used in the certificate's signature algorithm. > (This ensures that the security properties required for the > certificate also apply for the fingerprint. It also guarantees that > the fingerprint will be usable by the other endpoint, so long as the > certificate itself is.) > > That seems to exclude creating fingerprints with multiple > algorithms, or any need to do so. > > Looking deeper, I find OLD TEXT (from 7345) that talks about > multiple fingerprints, for differing cipher suites. So I guess in > that case multiple certificates will also be presented, with a > fingerprint for each, and it is only necessary to verify one of them. > > But the NEW TEXT removes all of this, changing it to refer to *this* > draft. But equivalent text isn't present in this draft!!! > > > I was talking about using multiple fingerprints to offer multiple cipher > suites. I am not sure what draft this is present in, but this is what > EKR explained to me in on the list. As noted above, this text is in 7345. But the updates to 7345 that are present in dtls-sdp (section 9.3) *remove* that text! > Can you send the reference to this OLD TEXT you mentioned so that it can > be added to this draft? Section 9.3 of dtls-sdp. Thanks, Paul From nobody Wed Feb 24 13:58: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 B40331B2F67 for ; Wed, 24 Feb 2016 13:58:31 -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 aq4RfgLMkkDN for ; Wed, 24 Feb 2016 13:58:30 -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 2E20B1B2C4A for ; Wed, 24 Feb 2016 13:58:30 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-ac-56ce278429ad Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.17.15637.4872EC65; Wed, 24 Feb 2016 22:58:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 22:58:27 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsP//9/iAgAADKICAAAbRgIAAAqqAgAAIE4CAABJT8A== Date: Wed, 24 Feb 2016 21:58:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4044F@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <56CE1CBD.70504@alum.mit.edu> <56CE25BF.7010201@alum.mit.edu> In-Reply-To: <56CE25BF.7010201@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdQrdF/VyYQf9TAYupyx+zWKzYcIDV YsaFqcwOzB5/339g8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZm+/XF1zjrJj8OrSBcTN7 FyMnh4SAicTNFfOgbDGJC/fWs3UxcnEICRxmlNh+7ygjhLOYUWLavytADgcHm4CFRPc/bZAG EQFviQnzV7OBhJkF1CWuLg4CCQsL2Ev8u/+BDaLEQWLTjWuMEHadxMP+3Uwg5SwCqhLzF6WB hHkFfCW+HjnHCmILCRxnkXjXbwlSwimgIzHnajFImBHosu+n1jCB2MwC4hK3nsxngrhYQGLJ nvPMELaoxMvH/1ghbCWJxiVPWCHqdSQW7P7EBmFrSyxb+JoZYq2gxMmZT1gmMIrNQjJ2FpKW WUhaZiFpWcDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMI4ObvmtuoPx8hvHQ4wCHIxK PLwb/p4NE2JNLCuuzD3EKMHBrCTC2612LkyINyWxsiq1KD++qDQntfgQozQHi5I47xrn9WFC AumJJanZqakFqUUwWSYOTqkGRjO3tc8m5k52qdebGTPLxyGQ0Vb9w52ZWxg4n206fnl9wX6B Q1+Uz2xljlaeUvzspqWm7EPFnwp7H++qNU/Snhxu4vssqfXahXvaJsvmvdbcWpGzMlv4re3V 0PtmgoX/ZP9Mrw2tevDxOcvczUWvw2u3iKXc6O95nczavkY7Okq2okHZxXDJUSWW4oxEQy3m ouJEAJBpsNSfAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:58:31 -0000 Hi, ... >> Looking deeper, I find OLD TEXT (from 7345) that talks about >> multiple fingerprints, for differing cipher suites. So I guess in >> that case multiple certificates will also be presented, with a >> fingerprint for each, and it is only necessary to verify one of them= . >> >> But the NEW TEXT removes all of this, changing it to refer to *this* >> draft. But equivalent text isn't present in this draft!!! >> >> >> I was talking about using multiple fingerprints to offer multiple=20 >> cipher suites. I am not sure what draft this is present in, but this=20 >> is what EKR explained to me in on the list. > > As noted above, this text is in 7345. But the updates to 7345 that are pr= esent in dtls-sdp (section 9.3) *remove* that text! > >> Can you send the reference to this OLD TEXT you mentioned so that it=20 >> can be added to this draft? > > Section 9.3 of dtls-sdp. Maybe I'm just tired, but I don't find it, so could you please copy the par= t of the old text in section 9.3 that talks about multiple fingerprints? The intention has not been to remove anything, only to move common parts fr= om 7345 into draft-dtls-sdp. Thanks! Regards, Christer From nobody Wed Feb 24 14:02: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 437B41A009F for ; Wed, 24 Feb 2016 14:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_111=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 xT_l7dXvBar2 for ; Wed, 24 Feb 2016 14:01:58 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 494761A1A54 for ; Wed, 24 Feb 2016 14:01:55 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id xg9so785697igb.1 for ; Wed, 24 Feb 2016 14:01: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; bh=t/yGQ/d8q5+isMr7oAZHyR4sOYM16nLdv7ornHjs+us=; b=f6HFiIet6ywY37Ob6Ps96lMlKuyNn6netLkGF8RUQ7to2Ak6R35VRR3jq9v+4m49Ri REXwJOur4ecjv/PM4goEboZb5BCxUK7XiyBfB3vB68PnNKw0l0FPapIQCGxIvXZowPzs krA0hRMmP++dW7YGe7v1xg2nRx5wOt1Pfx3x2OTFTKAJ6Sq4KOON+zUyzTW382SHYuCm Kq+s8cghDMTpNDMPMeBBi3XYKRk/Qs6ges4ucpCNVIYSKbAA0pIT9VDbi0PxHblU9wDk /p6TasBppWfcmQZyfk//tB01CIs88osF0Xe/eTM5UeSU5sClvBfp0N4YIl/kxfQBB0Z0 yk+Q== 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; bh=t/yGQ/d8q5+isMr7oAZHyR4sOYM16nLdv7ornHjs+us=; b=eK6imupObBBcKii1ULFJnyHtfG3+wd5ASnsrQvIcep5VOBuoOWdijBhYyxBrf6Hzqs H5hBdiOkVDYEAXwrUP6ZMcSshNMTXXnlFXNVMem1t4EWShZIStx7myJ17s0zdsx6Suc9 mw66wxQmYeQDM5Vvoxn83DgkqFckSFAmls1OzK7MoR+HItX2l/eIEfxFDJbOTSRxtXrc 3d9SVS7I/xo7C/qyc19yKmLePBhMAvHZkSimoaGA4LuK3p/JXnsYDfDg/o5AC5uXJk3j vNy3IpTVSu2exuY5w3AmAkp+P9pDN//1IFGt5E5iqUyVmxPaoAVH3U6bOznq+inDuCgt R/aA== X-Gm-Message-State: AG10YOTjBPEAf+F7E2OzWf2igjHGKtyux6xu6Z2FqUhZcM7mw9lDTsphsC/QhkaZogKW/opNT1QK69YvYa9PCg== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr52546igh.94.1456351314697; Wed, 24 Feb 2016 14:01:54 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 14:01:54 -0800 (PST) In-Reply-To: <56CE24DE.6090300@alum.mit.edu> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> Date: Wed, 24 Feb 2016 14:01:54 -0800 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 22:01:59 -0000 On 24 February 2016 at 13:47, Paul Kyzivat wrote: > If we are going to make normative references to multiple fingerprints we > need some place authoritative to reference for the details. I recommend judicious use of copy and paste. Feel free to steal text that I wrote. FWIW, my reading of 4572 is that it permits multiple fingerprints: one for each certificate that might be used. Its failing is that a) it doesn't allow for hash agility, and b) it's unclear, perhaps in the extreme. However, I see this: Endpoints MUST support SHA-256 for generating and verifying the fingerprint value associated with the DTLS association. The use of SHA-256 is preferred. Which doesn't mention that this requires an update of 4572. And this: The certificate received during the DTLS handshake MUST match the fingerprint received in the SDP "fingerprint" attribute. Which should say '*a* fingerprint', to allow for there being multiple. And this: [...] In addition, the offerer MUST insert an SDP 'setup' attribute according to the procedures in [RFC4145], and an SDP 'fingerprint' attribute according to the procedures in [RFC4572], in the offer. Which doesn't deal with multiple certificates. I also see: The subjectAltName is not an important component of the certificate verification. Which is true but insufficient; the text can simply say that the certificate is only a receptacle for a public key and authentication is tied to an a=fingerprint line in the SDP. And this: This offer includes, as part of the SDP payload, the fingerprint of the certificate that the endpoint wants to use. The endpoint SHOULD Which should be plural fingerprint*s*. The pattern repeats throughout. From nobody Wed Feb 24 14:13: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 3182D1B383D for ; Wed, 24 Feb 2016 14:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 G9Ssj33cXGUZ for ; Wed, 24 Feb 2016 14:13:49 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 D09CE1B338E for ; Wed, 24 Feb 2016 14:13:48 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 5BC73C68007FF; Wed, 24 Feb 2016 22:13:43 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1OMDksO024267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2016 22:13:46 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1OMDj0M001345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Feb 2016 23:13:45 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.98]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 24 Feb 2016 23:13:45 +0100 From: "Drage, Keith (Nokia - GB)" To: EXT Paul Kyzivat , EXT Colin Perkins , Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAA9P4A///VdXCAAICGAP/97qPQ Date: Wed, 24 Feb 2016 22:13:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE926CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <949EF20990823C4C85C18D59AA11AD8BADE903FF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56CC7CA8.4050309@alum.mit.edu> In-Reply-To: <56CC7CA8.4050309@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 22:13:55 -0000 SW4gZGVjbGFyYXRpdmUgdXNhZ2UgYSBzZXNzaW9uIHN0aWxsIGV4aXN0cyAoaXQgaXMgc3RpbGwg dGhlIHNlc3Npb24gZGVzY3JpcHRpb24gcHJvdG9jb2wsIGFuZCB0aGUgc2Vzc2lvbiBhbm5vdW5j ZW1lbnQgcHJvdG9jb2wpIGFuZCB0aGVyZWZvcmUgdGhlcmUgbXVzdCBiZSBhIHNldCBvZiBydWxl cyBmb3IgdGhlIHJldXNlIG9yIG5vbi1yZXVzZSBvZiBwYXlsb2FkIHR5cGVzLiANCg0KQWxsIEkg YW0gc2F5aW5nIGlzIHRoYXQgd2UgbXVzdCBub3QgZ2V0IGNhcnJpZWQgd2F5IGFuZCBkZWZpbmVk IGEgc2V0IG9mIHJ1bGVzIHRoYXQgYXJlIGluY29uc2lzdGVudCBiZXR3ZWVuIHRoZSB0d28uIFJh dGhlciBvbmUgc2hvdWxkIGJlIGEgc3Vic2V0IG9mIHRoZSBvdGhlci4NCg0KS2VpdGgNCg0KDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRVhUIFBhdWwgS3l6aXZhdCBb bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0gDQpTZW50OiAyMyBGZWJydWFyeSAyMDE2IDE1 OjM3DQpUbzogRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgRVhUIENvbGluIFBlcmtpbnM7IFJv bWFuIFNocG91bnQNCkNjOiBtbXVzaWNAaWV0Zi5vcmc7IENocmlzdGVyIEhvbG1iZXJnDQpTdWJq ZWN0OiBSZTogW01NVVNJQ10gT2ZmZXIvQW5zd2VyIFBUIFF1ZXN0aW9ucw0KDQpPbiAyLzIzLzE2 IDc6MDQgQU0sIERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgd3JvdGU6DQo+IEkgYWdyZWUgdGhh dCBoZXJlIHdlIGFyZSBkaXNjdXNzaW5nIG9mZmVyIC8gYW5zd2VyLCBidXQgd2UgbXVzdCBhbHNv IA0KPiByZW1lbWJlciB0aGF0IGFueSBydWxlcyBtdXN0IGJlIGNvbnNpc3RlbnQgd2l0aCBkZWNs YXJhdGl2ZSB1c2FnZXMgb2YgU0RQLg0KPg0KPiBJdCBtYXkgYWxzbyBiZSB0aGF0IHNvbWUgb2Yg dGhvc2UgZGVjbGFyYXRpdmUgcnVsZXMgYXJlIGFsc28gaW5oZXJpdGVkIA0KPiBieSBvZmZlciBh bnN3ZXIsIHN1Y2ggYXMgdGhlIGFuc3dlciB0byB0aGUgcXVlc3Rpb24gYXMgdG8gd2hldGhlciB0 aGUgDQo+IHJlcXVpcmVtZW50IHRvIHJlbWVtYmVyIHBheWxvYWQgdHlwZSB1c2FnZSAoYW5kIHdo ZXRoZXIgdGhhbiBhcHBsaWVzIA0KPiB0byBib3RoIG9mZmVycyBhbmQgYW5zd2Vycywgb3IgaW5k ZXBlbmRlbnRseSB0byBlYWNoKS4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuIElT VE0gdGhhdCBub25lIG9mIHRoaXMgZGlzY3Vzc2lvbiBpcyByZWxldmFudCB0byBkZWNsYXJhdGl2 ZSB1c2FnZSAtIHdoeSBzaG91bGQgdGhlcmUgZXZlciBiZSBhbnkgbmVlZCB0byByZXRhaW4gaGlz dG9yeSBvciByZW1haW4gY29uc2lzdGVudCB3aXRoIGl0IGluIHRoZSBkZWNsYXJhdGl2ZSBjYXNl Pw0KDQoJVGhhbmtzLA0KCVBhdWwNCg0KPiBSZWdhcmRzDQo+DQo+IEtlaXRoDQo+DQo+ICpGcm9t OiptbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAq RVhUIA0KPiBDb2xpbiBQZXJraW5zDQo+ICpTZW50OiogMjMgRmVicnVhcnkgMjAxNiAxMDoyOQ0K PiAqVG86KiBSb21hbiBTaHBvdW50DQo+ICpDYzoqIG1tdXNpY0BpZXRmLm9yZzsgUGF1bCBLeXpp dmF0OyBDaHJpc3RlciBIb2xtYmVyZw0KPiAqU3ViamVjdDoqIFJlOiBbTU1VU0lDXSBPZmZlci9B bnN3ZXIgUFQgUXVlc3Rpb25zDQo+DQo+ICAgICBPbiAyMiBGZWIgMjAxNiwgYXQgMTk6NTIsIFJv bWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tDQo+ICAgICA8bWFpbHRvOnJvbWFuQHRlbHVy aXguY29tPj4gd3JvdGU6DQo+DQo+IOKApg0KPg0KPiBPbmUgdGhpbmcgdGhhdCBib3RoZXJlZCBt ZSBoZXJlIGlzIHRoYXQgUFQgY2Fubm90IGJlIHJldXNlZCBmb3IgdGhlIA0KPiBkdXJhdGlvbiBv ZiB0aGUgc2Vzc2lvbi4gSXQgaXMgcHJvYmFibHkgc2FmZSB0byByZXVzZSB0aGUgUFQgYWZ0ZXIg DQo+IHNlc3Npb24gbW9kaWZpY2F0aW9uIGlmIFBUIGlzIG5vIGxvbmdlciB1c2VkLiBJIGFsd2F5 cyBmZWx0IHRoYXQgDQo+IGR5bmFtaWMgUFQgcmV1c2UgY3JpdGVyaWEgd2VyZSBtdWNoIHN0cmlj dGVyIHRoZW4gcmVhbGlzdGljYWxseSBwb3NzaWJsZSBvciBuZWVkZWQuDQo+DQo+IOKApg0KPg0K PiBJIHRoaW5rIHRoZSBtb3N0IGltcG9ydGFudCBjcml0ZXJpYSBoZXJlIGlzIHRoYXQgdGhlcmUg c2hvdWxkIGJlIG5vIA0KPiBhbWJpZ3VpdHkgcmVnYXJkaW5nIGhvdyBhbiBSVFAgcGFja2V0IHdp dGggcGFydGljdWxhciBQVCBzaG91bGQgYmUgDQo+IGRlY29kZWQuIElmIGl0IGlzIGd1YXJhbnRl ZWQgdGhhdCB0aGVyZSBhcmUgbm8gcGFja2V0cyBzZW50IGJldHdlZW4gDQo+IEFsaWNlIGFuZCBC b2Igd2l0aCBQVCAxMTEgb3ZlciBzb21lIHJlYXNvbmFibGUgdGltZSBpbnRlcnZhbCAoY291cGxl IA0KPiBvZiBuZXR3b3JrIHJvdW5kIHRyaXAgdGltZXMpLCB0aGVuIFBUIDExMSBjYW4gYmUgc2Fm ZWx5IHJldXNlZC4gSWYsIGluIA0KPiB0aGlzIHNjZW5hcmlvIEJvYidzIGVuZCBwb2ludCBrbm93 cyB0aGF0IGl0IHdhcyBub3Qgc2VuZGluZyBhbnl0aGluZyANCj4gd2l0aCBwYXlsb2FkIDExMSBy ZWNlbnRseSwgdGhlbiBpdCBjYW4gc2FmZWx5IHJldXNlIHRoaXMgcGF5bG9hZC4gDQo+IEFsaWNl IGNvdWxkIG5vdCBiZSBzZW5kaW5nIGFueXRoaW5nIHdpdGggcGF5bG9hZCAxMTEgc2luY2UgQm9i IGRpZCBub3QgDQo+IGFjY2VwdCBpdCBwcmV2aW91c2x5LiBPbiB0aGUgb3RoZXIgaGFuZCwgQm9i IG11c3Qgbm90IHJldXNlIFBUIDEwMCANCj4gZm9yLCBsZXQncyBzYXksIENOLCBzaW5jZSB0aGVy ZSBhcmUgcGFja2V0cyB3aXRoIHRoaXMgcGF5bG9hZCBpbiANCj4gZmxpZ2h0IGFuZCB0aGlzIHdp bGwgY3JlYXRlIGRlY29kaW5nIGFtYmlndWl0eS4gVG8gY29uY2x1ZGUsIGFuIGVuZCANCj4gcG9p bnQgc2hvdWxkIGJlIGFibGUgdG8gc2FmZWx5IHJldXNlIGFueSBQVCB0aGF0IGl0IGlzIG5vdCBj dXJyZW50bHkgDQo+IGFjY2VwdGluZyBvciB3YXMgbm90IHNlbmRpbmcgb3IgYWNjZXB0aW5nIGZv ciBhdCBsZWFzdCBhIGZldyBuZXR3b3JrIHJvdW5kIHRyaXAgaW50ZXJ2YWxzLg0KPg0KPiBObyBv YmplY3Rpb24gaW4gcHJpbmNpcGxlLCBidXQgaXTigJlzIG5vdCBhcyBzaW1wbGUgYXMg4oCcYSBm ZXcgbmV0d29yayBSVFRz4oCdOg0KPg0KPiBObyBhbWJpZ3VpdHkgaW4gZGVjb2RpbmcgbWVhbnMg dGhhdCB0aGUgcGFja2V0cyBuZWVkIHRvIGhhdmUgYmVlbiANCj4gcGxheWVkIG91dCwgc28gdGhl IGNvZGVjIHN0YXRlIGZvciB0aGF0IFBUIGNhbiBiZSBkaXNjYXJkZWQuIFNvbWUgDQo+IHN5c3Rl bXMgY2FuIGhhdmUgbGFyZ2UgKG11bHRpLXNlY29uZCkgcGxheW91dCBidWZmZXJzLg0KPg0KPiBB bnkgcGFja2V0cyByZWZlcnJpbmcgdG8gdGhlIG9sZCBQVCBhbHNvIG5lZWQgdG8gYmUgZ29uZS4g Rm9ybWF0cyBsaWtlIA0KPiBSRkMgNjM1NCBhbGxvdyBsYXJnZSBvZmZzZXRzIGJldHdlZW4gc3Ry ZWFtcywgcmVmZXJlbmNlZCBieSBQVCAodGhlIA0KPiBleGFtcGxlIGluIFNlY3Rpb24gNSBoYXMg YSA1LjEgc2Vjb25kIG9mZnNldCkuDQo+DQo+IC0tDQo+DQo+IENvbGluIFBlcmtpbnMNCj4NCj4g aHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPg0KDQo= From nobody Wed Feb 24 14:46:35 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 D31A21A0217 for ; Wed, 24 Feb 2016 14:46:32 -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_111=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 uINV9ddEDQFN for ; Wed, 24 Feb 2016 14:46:31 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1501A00C6 for ; Wed, 24 Feb 2016 14:46:31 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-08v.sys.comcast.net with comcast id NNmW1s0042S2Q5R01NmW8K; Wed, 24 Feb 2016 22:46:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id NNmV1s00R3KdFy101NmVnN; Wed, 24 Feb 2016 22:46:30 +0000 To: Martin Thomson References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> From: Paul Kyzivat Message-ID: <56CE32C4.3040001@alum.mit.edu> Date: Wed, 24 Feb 2016 17:46:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.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=1456353990; bh=fudqQo7879MNbCMV2ypVUaG+5rWMNW6tcrLuMMKjVW8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ez5jQl/DZIhYfIuhT5K95kMGS8TXDzgBvOaVicyTKrwcoJNaz3tR1bOIs56SZZVo3 siAMY2/FequCKnNaev07JOhQeJgUqBHadRphjhUfco7NRzDXK/B8J/Ksax2bXYi6qD MSo9ObIpNvIqGH7TRZ04GisM1cgJA+PUp9fYHpqLj7fo9rS6v0zJ6Z3IPnksvXNiNK XlPseIYFpSuOeZuIbKFdpx32YMMC6xEb4VSClkJblRHtBc0dPmEtwLe5HgwayIQqSZ EpftVK7CwERA7uK8W0uk/WlD3NbBv+5W04JP5Zsm50GSDHQi5XuDlL+HxpGI6hj6iK zhhUpZUGRIPUw== Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 22:46:33 -0000 On 2/24/16 5:01 PM, Martin Thomson wrote: > On 24 February 2016 at 13:47, Paul Kyzivat wrote: >> If we are going to make normative references to multiple fingerprints we >> need some place authoritative to reference for the details. > > I recommend judicious use of copy and paste. Feel free to steal text > that I wrote. First I think it is necessary to decide which document needs this. Then the copy/paste can proceed. If it belongs in the body of dtls-sdp then I guess it is straightforward to proceed. If it is in one of the documents that dtls-sdp updates (5763 or 7345) then I guess the changes can still be tucked into sdp-dtls. If it requires something else then it may get more messy. > FWIW, my reading of 4572 is that it permits multiple fingerprints: one > for each certificate that might be used. It doesn't say there *can't* be multiple fingerprints. But I see nothing obvious that suggests that is a possibility. There is a lot of usage of "the fingerprint" in the text. If it is intended, then ISTM that more explanation is needed. > Its failing is that a) it > doesn't allow for hash agility, and b) it's unclear, perhaps in the > extreme. Yup. > However, I see this: > > Endpoints MUST support SHA-256 for generating and verifying the > fingerprint value associated with the DTLS association. The use of > SHA-256 is preferred. > > Which doesn't mention that this requires an update of 4572. rfc7345 has some similar (not identical) text about this. It is unclear to me if that overrides 4572, or supplements it. Then dtls-sdp updates 7345, removing that text, and replacing it it with a reference to itself. Then again similar text is included in section 4.1. After all those changes I don't know where we stand. But none of those places are clear about multiple fingerprints. And I don't know which of them ought to be authoritative about that subject. I don't know what the fix is. I only know there is a problem. Thanks, Paul > And this: > > The certificate received during the DTLS handshake MUST match the > fingerprint received in the SDP "fingerprint" attribute. > > Which should say '*a* fingerprint', to allow for there being multiple. > > And this: > > [...] In addition, the offerer > MUST insert an SDP 'setup' attribute according to the procedures in > [RFC4145], and an SDP 'fingerprint' attribute according to the > procedures in [RFC4572], in the offer. > > Which doesn't deal with multiple certificates. > > I also see: > > The > subjectAltName is not an important component of the certificate > verification. > > Which is true but insufficient; the text can simply say that the > certificate is only a receptacle for a public key and authentication > is tied to an a=fingerprint line in the SDP. > > And this: > > This offer includes, as part of the SDP payload, the fingerprint of > the certificate that the endpoint wants to use. The endpoint SHOULD > > Which should be plural fingerprint*s*. > > The pattern repeats throughout. > From nobody Wed Feb 24 14:50: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 95D6F1A1AA3 for ; Wed, 24 Feb 2016 14:50:09 -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 hLcbzP0psQqo for ; Wed, 24 Feb 2016 14:50:08 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6C81A1AA2 for ; Wed, 24 Feb 2016 14:50:08 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-10v.sys.comcast.net with comcast id NNpw1s00526dK1R01Nq7tQ; Wed, 24 Feb 2016 22:50:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id NNq71s0023KdFy101Nq7vy; Wed, 24 Feb 2016 22:50:07 +0000 To: Christer Holmberg , Roman Shpount References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <56CE1CBD.70504@alum.mit.edu> <56CE25BF.7010201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4044F@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CE339D.60509@alum.mit.edu> Date: Wed, 24 Feb 2016 17:50:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4044F@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=1456354207; bh=KTLdjug7S2Qr10l8oZusf429gnsEgWngCX1C2IJhI8I=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=lZW/69v5SZOOJ3pKvPcsBAu7yW/n9yVwWle9Xx1nxhFPURWO3iLuLB2RGTkqEbJqr T+DcAKwmLvr5Df036S+NJ2hfxMw5TbjifKu5nIfx2TAfszAneyjdVMdCTRMHy1zm3A lL5UX13664pQqEHS1IvTb2aGdKTP54Cz66JJddZ3hx7C961K1yKkNc5RNEeUSwuN1r 4dqR89dSZEavWX1JcUXyd2dbzaoTZ+DVYoeyPxvst6fkX9LXMgS3BWdEeq/dSASguD YsWoQHeJd9IVfXiQcgMO1mGSsxapsq0zAUJK7sTQW/GfbGWHu0XNtTwfKRxivYbGLI 2sEnma4TSy8XQ== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 22:50:09 -0000 On 2/24/16 4:58 PM, Christer Holmberg wrote: > Hi, > > ... > >>> Looking deeper, I find OLD TEXT (from 7345) that talks about >>> multiple fingerprints, for differing cipher suites. So I guess in >>> that case multiple certificates will also be presented, with a >>> fingerprint for each, and it is only necessary to verify one of them. >>> >>> But the NEW TEXT removes all of this, changing it to refer to *this* >>> draft. But equivalent text isn't present in this draft!!! >>> >>> >>> I was talking about using multiple fingerprints to offer multiple >>> cipher suites. I am not sure what draft this is present in, but this >>> is what EKR explained to me in on the list. >> >> As noted above, this text is in 7345. But the updates to 7345 that are present in dtls-sdp (section 9.3) *remove* that text! >> >>> Can you send the reference to this OLD TEXT you mentioned so that it >>> can be added to this draft? >> >> Section 9.3 of dtls-sdp. > > Maybe I'm just tired, but I don't find it, so could you please copy the part of the old text in section 9.3 that talks about multiple fingerprints? > > The intention has not been to remove anything, only to move common parts from 7345 into draft-dtls-sdp. Please see my reply to Martin. Note that I am also getting confused now. There are two many documents that reference, override, and update one another. Bottom line is I can't find any explanation for multiple fingerprints or the hash agility that Martin is looking for. I don't think I am competent to propose a fix for this. Thanks, Paul From nobody Wed Feb 24 14:54: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 34A9E1A1B21 for ; Wed, 24 Feb 2016 14:54:09 -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 gl3jgeF2b0Ul for ; Wed, 24 Feb 2016 14:54:07 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E911A1B1C for ; Wed, 24 Feb 2016 14:54:07 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-11v.sys.comcast.net with comcast id NNtb1s0022Bo0NV01Nu64R; Wed, 24 Feb 2016 22:54:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id NNu61s00G3KdFy101Nu6C4; Wed, 24 Feb 2016 22:54:06 +0000 To: mmusic@ietf.org References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <949EF20990823C4C85C18D59AA11AD8BADE903FF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56CC7CA8.4050309@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADE926CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56CE348E.1080600@alum.mit.edu> Date: Wed, 24 Feb 2016 17:54:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE926CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456354446; bh=9W3TeKkNCu9J5wAQ/Yyi3sZu0ifcnagf6gdQGteUsfE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mMgdrolgz2altA2/KiBH9drXK4JSzNlsc5KotTcVv4hShG+cTGUJz4pQ2pDCA5TCk vPLY1GQWFqUvjGiVH07obBBwO2bLcM8n1kVOfmSy8YlwSHwK3Y4NLO6Ayk8YjPhGHl qVIiONNHch0zCOmq+A5/WPJDadfRkvLDWPI/i6/SWrqz4es4y/us3gMDUfOUllVziI E8yVSdy2R6562dQG2jkT0JIGtf4B0Dqsgy9nvPm5KN0DqaKid15CSbAnyxBiqvr3JP Q8Z9RKyi8jYFd2JSsDywxjbcpGmFklzUQjEG/izMFh27oegGJ+HrSxGbIRfZ61YazM n209Zbwq76cEg== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 24 Feb 2016 22:54:09 -0000 On 2/24/16 5:13 PM, Drage, Keith (Nokia - GB) wrote: > In declarative usage a session still exists (it is still the session description protocol, and the session announcement protocol) and therefore there must be a set of rules for the reuse or non-reuse of payload types. > > All I am saying is that we must not get carried way and defined a set of rules that are inconsistent between the two. Rather one should be a subset of the other. I have never tried to understand the declarative use (other than in OPTIONS, which clearly *isn't* describing a session.) It is my impression that SAP hasn't been used for a very long time. If somebody who understands and cares about it would like to help then maybe we can see that we don't break that. Thanks, Paul > Keith > > > > > > -----Original Message----- > From: EXT Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 23 February 2016 15:37 > To: Drage, Keith (Nokia - GB); EXT Colin Perkins; Roman Shpount > Cc: mmusic@ietf.org; Christer Holmberg > Subject: Re: [MMUSIC] Offer/Answer PT Questions > > On 2/23/16 7:04 AM, Drage, Keith (Nokia - GB) wrote: >> I agree that here we are discussing offer / answer, but we must also >> remember that any rules must be consistent with declarative usages of SDP. >> >> It may also be that some of those declarative rules are also inherited >> by offer answer, such as the answer to the question as to whether the >> requirement to remember payload type usage (and whether than applies >> to both offers and answers, or independently to each). > > I don't understand your point. ISTM that none of this discussion is relevant to declarative usage - why should there ever be any need to retain history or remain consistent with it in the declarative case? > > Thanks, > Paul > >> Regards >> >> Keith >> >> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *EXT >> Colin Perkins >> *Sent:* 23 February 2016 10:29 >> *To:* Roman Shpount >> *Cc:* mmusic@ietf.org; Paul Kyzivat; Christer Holmberg >> *Subject:* Re: [MMUSIC] Offer/Answer PT Questions >> >> On 22 Feb 2016, at 19:52, Roman Shpount > > wrote: >> >> … >> >> One thing that bothered me here is that PT cannot be reused for the >> duration of the session. It is probably safe to reuse the PT after >> session modification if PT is no longer used. I always felt that >> dynamic PT reuse criteria were much stricter then realistically possible or needed. >> >> … >> >> I think the most important criteria here is that there should be no >> ambiguity regarding how an RTP packet with particular PT should be >> decoded. If it is guaranteed that there are no packets sent between >> Alice and Bob with PT 111 over some reasonable time interval (couple >> of network round trip times), then PT 111 can be safely reused. If, in >> this scenario Bob's end point knows that it was not sending anything >> with payload 111 recently, then it can safely reuse this payload. >> Alice could not be sending anything with payload 111 since Bob did not >> accept it previously. On the other hand, Bob must not reuse PT 100 >> for, let's say, CN, since there are packets with this payload in >> flight and this will create decoding ambiguity. To conclude, an end >> point should be able to safely reuse any PT that it is not currently >> accepting or was not sending or accepting for at least a few network round trip intervals. >> >> No objection in principle, but it’s not as simple as “a few network RTTs”: >> >> No ambiguity in decoding means that the packets need to have been >> played out, so the codec state for that PT can be discarded. Some >> systems can have large (multi-second) playout buffers. >> >> Any packets referring to the old PT also need to be gone. Formats like >> RFC 6354 allow large offsets between streams, referenced by PT (the >> example in Section 5 has a 5.1 second offset). >> >> -- >> >> Colin Perkins >> >> https://csperkins.org/ >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Feb 24 15:14: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 3EBD11A7020 for ; Wed, 24 Feb 2016 15:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 a7mwGzfPSg68 for ; Wed, 24 Feb 2016 15:14:05 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 037B01A7008 for ; Wed, 24 Feb 2016 15:14:04 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id xg9so1876738igb.1 for ; Wed, 24 Feb 2016 15:14:04 -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; bh=hoRhcH0kHahBM6VzyLVu372MScg9b1+FV0xuRc+BXb8=; b=h9lUGvfggso5s270xAtm4c2EmM674eM8cFqQGx/erNdmq/S3bhIHx6ngY74iFpH+y8 /lqmofa0IUwlQhI9NiXUKKLQGjAoLJn2gz/aI+5T8AiHQkUtHEffTemQlSMT0shWZzLk cp0gz0P8kt/oQusFWcTXJWYTCMu4Zo64+wi6CopteIKUK9i8MpNzFIEKeoWQp9CN++EZ hmh+ciwl4YMFWGslTajq+9B2mK7FpJAkppPPv/S8G/oleFh5R2TfYZQGFjWxkdV1rURC tV4R0MbWUINazCjmiiveN3U80yJMzdiOcVvdu3MIX89iQn6RWxkesWlVk8OM2/gzOmqZ 3TsQ== 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; bh=hoRhcH0kHahBM6VzyLVu372MScg9b1+FV0xuRc+BXb8=; b=TWenAZPV/WxtzCjTPvzBcp5xebAFaTOvxNLOi2JqAW4POajbSgxJLzhljycyRZ3OR7 w+S1Cb0AiWibQ6AZpD9xnwHUJHUPzpDEHt0bjisGJa+of2XneC1chVXBkJX7uLPEFtH3 uspkq2jU5E+m4NJVL6WVyJRavIWu3cHRQvRo7Kcpv79wAuw4+uUa3ll90nO39YXNR6So FavWWwrPxGwx/t2InYPHgrAdSOfOjjjnCyt1x+DBqZNFdXcuy1HFTt+ovn2EFgUbXX7W laPvKejVYcgkw8vsaLgRL8qUCMgA4bk7rRu8DrAKOVLkbmHqmscwzy1dV8fy4D7xO8NM 5T4A== X-Gm-Message-State: AG10YORYN9n+xc6jbCNW1Gjmxqi9GveWkkaAt3lxMCCFSnJWE6eQA1c+rPqTEEAhWuXPVbWIZywg5MOzJ5y0PA== MIME-Version: 1.0 X-Received: by 10.50.20.73 with SMTP id l9mr145738ige.58.1456355644065; Wed, 24 Feb 2016 15:14:04 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 15:14:03 -0800 (PST) In-Reply-To: <56CE339D.60509@alum.mit.edu> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <56CE1CBD.70504@alum.mit.edu> <56CE25BF.7010201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4044F@ESESSMB209.ericsson.se> <56CE339D.60509@alum.mit.edu> Date: Wed, 24 Feb 2016 15:14:03 -0800 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 23:14:06 -0000 On 24 February 2016 at 14:50, Paul Kyzivat wrote: > Bottom line is I can't find any explanation for multiple fingerprints or the > hash agility that Martin is looking for. To be clear, hash agility is a feature. I'm OK with not having that feature. As far as the rest of this goes, I think that dtls-sdp can address the multiple certificates thing easily, but it appears that it would be easier as an editorial exercise, followed by working group review, than it would be to sort it out on the list. From nobody Wed Feb 24 15:48: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 5906D1A9092 for ; Wed, 24 Feb 2016 15:48:44 -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_111=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 pXybQxrugCts for ; Wed, 24 Feb 2016 15:48:43 -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 96ED71A90A7 for ; Wed, 24 Feb 2016 15:48:42 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-f1-56ce41571eed Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.83.20792.7514EC65; Thu, 25 Feb 2016 00:48:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 00:48:27 +0100 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsP//9/iAgAASgkD///dgAIAACcgAgAAEHgCAACp6gA== Date: Wed, 24 Feb 2016 23:48:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4061F@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2J7lG6447kwg5ZDBhYrXp9jt9i/+Dyz xdapQhbXzvxjtJi6/DGLxYoNB1gd2Dz+vv/A5LFz1l12jwWbSj2WLPnJ5DH5cRuzR9uzO+wB bFFcNimpOZllqUX6dglcGU1fOlkL/ghWLFy2mqmB8YBgFyMnh4SAiURD/yo2CFtM4sK99UA2 F4eQwGFGiauTX7FAOIsZJaad2sraxcjBwSZgIdH9TxukQUQgVKLt4j5GkBpmgd2MEu3bH4FN Ehawl/h3/wMbRJGDxKYb1xgh7DqJf/tOM4PYLAKqElffPQCr4RXwlTh/+QbU5tcsEksWXAUr 4hQIlHj3pwusmRHovO+n1jCB2MwC4hK3nsxngjhbQGLJnvPMELaoxMvH/1ghbCWJRbc/M4Ec zSygKbF+lz5Eq6LElO6H7BB7BSVOznzCMoFRbBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OLi3HQj I73Uoszk4uL8PL281JJNjMBYPLjlt9UOxoPPHQ8xCnAwKvHwbvh7NkyINbGsuDL3EKMEB7OS CK+2w7kwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxrnNeHCQmkJ5akZqemFqQWwWSZODilGhhr d1k8mHaF/5GWeJr7/+8vUoKyM2pFdjrum87WsX9+VnXBZXdR+X8+yldm1Fwwnv/h6TLmw3nL H+3/F5uRvrKI+cq2xw/uHTmmE9Qz6epEs2rt6QvzmM3XOG/VW5osVbjqNVdIUUh/ZMX/fm0H c9Z73q6GvsyP/55b82KJpdANLeGFS4743M9VYinOSDTUYi4qTgQAakVs9sECAAA= Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 23:48:44 -0000 SGkgTWFydGluLA0KDQouLi4NCg0KPiBIb3dldmVyLCBJIHNlZSB0aGlzOg0KPg0KPiAgIEVuZHBv aW50cyBNVVNUIHN1cHBvcnQgU0hBLTI1NiBmb3IgZ2VuZXJhdGluZyBhbmQgdmVyaWZ5aW5nIHRo ZQ0KPiAgIGZpbmdlcnByaW50IHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgRFRMUyBhc3NvY2lh dGlvbi4gIFRoZSB1c2Ugb2YNCj4gICBTSEEtMjU2IGlzIHByZWZlcnJlZC4NCj4NCj4gV2hpY2gg ZG9lc24ndCBtZW50aW9uIHRoYXQgdGhpcyByZXF1aXJlcyBhbiB1cGRhdGUgb2YgNDU3Mi4NCg0K SSBkbyBhZ3JlZSB0aGF0IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gbWFuZGF0ZSBzdXBwb3J0IG9m IHRoZSBzYW1lIGNpcGhlcnMgZm9yIGJvdGggVExTIGFuZCBEVExTIChhc3N1bWluZyB0aGF0IGlz IHRoZSByZWFzb24geW91IHRoaW5rIGFuIDQ1NzIgdXBkYXRlIGlzIG5lZWRlZCksIGJ1dCBJIHdv bmRlciB3aGV0aGVyIHN1Y2ggY2hhbmdlIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhpcyBkcmFm dC4gIEhhdmluZyBzYWlkIHRoYXQsIHRob3VnaCwgSSBoYXZlIG5vIHByb2JsZW0gbWFraW5nIHN1 Y2ggdXBkYXRlIGluIGRyYWZ0LWR0bHMtc2RwLCBpZiBwZW9wbGUgdGhpbmsgd2Ugc2hvdWxkIGRv IGl0Li4uIDopDQoNCihUaGUgYmFja2dyb3VuZCB0byBtYW5kYXRpbmcgc3VwcG9ydCBvZiBTSEEt MjU2IHdhcyB3aGVuIHdlIGRpZCBSRkMgNzM0NS4gVGhlIHNlY3VyaXR5IGZvbGtzIHJlcXVpcmVk IGl0IGR1cmluZyB0aGUgSUVTRyByZXZpZXcuKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiBB bmQgdGhpczoNCj4NCj4gICBUaGUgY2VydGlmaWNhdGUgcmVjZWl2ZWQgZHVyaW5nIHRoZSBEVExT IGhhbmRzaGFrZSBNVVNUIG1hdGNoIHRoZQ0KPiAgIGZpbmdlcnByaW50IHJlY2VpdmVkIGluIHRo ZSBTRFAgImZpbmdlcnByaW50IiBhdHRyaWJ1dGUuDQo+DQo+IFdoaWNoIHNob3VsZCBzYXkgJyph KiBmaW5nZXJwcmludCcsIHRvIGFsbG93IGZvciB0aGVyZSBiZWluZyBtdWx0aXBsZS4NCg0KQ29y cmVjdC4gSW4gYW4gZWFybGllciByZXBseSBJIHRvbGQgUGF1bCBJIHdvdWxkIG1vZGlmeSB0aGUg dGV4dCB0byBtYWtlIHN1cmUgaXQgYWxsb3dzIG11bHRpcGxlIGF0dHJpYnV0ZXMuIFRoaXMgYWxz byBhcHBsaWVzIHRvIHlvdXIgc3Vic2VxdWVudCBjb21tZW50cyBvbiB0aGUgc2FtZSBpc3N1ZS4N Cg0KSG93ZXZlciwgUGF1bCBpcyBhbHNvIGxvb2tpbmcgZm9yIHRoZSBzZW1hbnRpY3Mgb2YgdXNp bmcgbXVsdGlwbGUgZmluZ2VycHJpbnRzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiBJIGFs c28gc2VlOg0KPg0KPiAgIFRoZSBzdWJqZWN0QWx0TmFtZSBpcyBub3QgYW4gaW1wb3J0YW50IGNv bXBvbmVudCBvZiB0aGUgY2VydGlmaWNhdGUNCj4gICB2ZXJpZmljYXRpb24uDQo+DQo+IFdoaWNo IGlzIHRydWUgYnV0IGluc3VmZmljaWVudDsgdGhlIHRleHQgY2FuIHNpbXBseSBzYXkgdGhhdCB0 aGUgY2VydGlmaWNhdGUgaXMgb25seSBhIHJlY2VwdGFjbGUgZm9yIGEgcHVibGljIGtleSBhbmQg YXV0aGVudGljYXRpb24gaXMgdGllZCB0byBhbiBhPWZpbmdlcnByaW50IGxpbmUgaW4gdGhlIFNE UC4NCg0KQ291bGQgeW91IHN1Z2dlc3QgdGhlIGV4YWN0IHRleHQgY2hhbmdlPw0KDQpUaGFua3Mh DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Wed Feb 24 15:53: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 8F0D81A914A for ; Wed, 24 Feb 2016 15:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dux2ZNy7Cm65 for ; Wed, 24 Feb 2016 15:53: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 6C1381A9134 for ; Wed, 24 Feb 2016 15:53:09 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-40-56ce42638952 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3E.F3.20792.3624EC65; Thu, 25 Feb 2016 00:53:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 00:52:22 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsP//9/iAgAADKICAAAbRgIAAAqqAgAAIE4CAABJT8P///jWAgAAhUwA= Date: Wed, 24 Feb 2016 23:52:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E40674@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <56CE1CBD.70504@alum.mit.edu> <56CE25BF.7010201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4044F@ESESSMB209.ericsson.se> <56CE339D.60509@alum.mit.edu> In-Reply-To: <56CE339D.60509@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+NgFprIIsWRmVeSWpSXmKPExsUyM2J7lG6y07kwg6/rdSymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlrFjXwlTQxlZx8cw55gbG 5yxdjJwcEgImEn+2v2GHsMUkLtxbz9bFyMUhJHCYUWL2iX5GCGcxo8T8i/tZuxg5ONgELCS6 /2mDNIgIeEtMmL+aDSTMLKAucXVxEEhYWMBe4t/9D2wQJQ4Sm25cY4SwuxgldrZ4gNgsAqoS k9t/gt3AK+ArcaLxHNTe1awSsx88ZgVJcApoSSz5t5EJxGYEOu77qTVgNrOAuMStJ/OZII4W kFiy5zwzhC0q8fLxP1YIW0li0e3PUPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsL ScssJC2zkLQsYGRZxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYUQe3/LbawXjwueMhRgEO RiUe3g1/z4YJsSaWFVfmHmKU4GBWEuFd4nAuTIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvGuf1 YUIC6YklqdmpqQWpRTBZJg5OqQbGDcpRPJKzTr93K1jH9vHJIckn8vs5gt61nHkTvFp8ybdc gedFMdwcfDmFb5VqhcLL5flrNkrWftcITDR4/Cbwy/rVW6/fk3iWIZTt38qr7GSeIMQyd/mB i/mJkbu2BalmmN57vW1pQHbFs0b+foMVkXE7RWZ+4LYT+uZ1ycFwbrBfGP+V4ulKLMUZiYZa zEXFiQDmQszkpAIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 23:53:10 -0000 Hi Paul, ... > Note that I am also getting confused now. There are two many documents th= at reference, override, and update one=20 > another. Bottom line is I can't find any explanation for multiple fingerp= rints or the hash agility that Martin is looking for. The important text to read is draft-dtls-sdp. The changes in the other RFCs= is to remove common procedures which have been added to draft-dtls-sdp, an= d to reference to draft-dtls-sdp for those common procedures. But, I still don't find any text in 7345 that talks about multiple fingerpr= ints :) ANYWAY, there is no need to argue about that - if we have text desc= ribing the semantics of multiple fingerprints we should instead discuss whe= re we'll put it. Regards, Christer From nobody Wed Feb 24 15:54: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 8D9E21A9239 for ; Wed, 24 Feb 2016 15:54:12 -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 yOfK0-LGHsA0 for ; Wed, 24 Feb 2016 15:54:11 -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 0264E1A914A for ; Wed, 24 Feb 2016 15:54:10 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-a2-56ce42a14bd1 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9E.C5.28465.1A24EC65; Thu, 25 Feb 2016 00:54:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 00:54:08 +0100 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsP//9/iAgAADKICAAAbRgIAAAqqAgAAIE4CAABJT8P///jWAgAAGsoCAABu6cA== Date: Wed, 24 Feb 2016 23:54:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E406AF@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <56CE1CBD.70504@alum.mit.edu> <56CE25BF.7010201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4044F@ESESSMB209.ericsson.se> <56CE339D.60509@alum.mit.edu> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7se5Cp3NhBkfu81pcO/OP0WLq8scs Fis2HGC1mHFhKrMDi8ff9x+YPHbOusvusWTJTyaPW1MKAliiuGxSUnMyy1KL9O0SuDKuXzjJ XvCDteLKi5XsDYxPWLsYOTkkBEwkji6dxARhi0lcuLeerYuRi0NI4DCjxLZjx5ggnMWMEpOv rgXKcHCwCVhIdP/TBmkQEQiVaLu4jxHEZhbwkmiYvZ0NxBYWsJf4d/8DG0SNg8SmG9cYQeaI CExilFj85ANYA4uAqsT7VT3MIDavgK/E7sXroJZ9YpV4da6PHSTBKRAo8eDiPLAiRqDzvp9a wwSxTVzi1pP5UGcLSCzZc54ZwhaVePn4H9RrShKLbn9mAjmaWUBTYv0ufYhWRYkp3Q/ZIfYK Spyc+YRlAqPYLCRTZyF0zELSMQtJxwJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF2 cMtv3R2Mq187HmIU4GBU4uHd8PdsmBBrYllxZe4hRgkOZiUR3iUO58KEeFMSK6tSi/Lji0pz UosPMUpzsCiJ865xXh8mJJCeWJKanZpakFoEk2Xi4JRqYFzL7fCW+95Rxi26un53y7yLtVzf R7u5WSx+Y9TxLuHwRcfi/46fCplrZO4eT/ZfuDtdXV3w0vLiuBTBgrO7KyyWKJ2r2dC3qNbJ U+75/YJ/3frV13ON9bcWvVf//O2+9D2j3ZObixI7jRUUvZRvOP9esWR77jlhzqNnDbRWNrls kNtz9n5NkRJLcUaioRZzUXEiADbnjCuuAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 23:54:12 -0000 SGksDQoNCi4uLg0KDQo+IEFzIGZhciBhcyB0aGUgcmVzdCBvZiB0aGlzIGdvZXMsIEkgdGhpbmsg dGhhdCBkdGxzLXNkcCBjYW4gYWRkcmVzcyB0aGUgbXVsdGlwbGUgY2VydGlmaWNhdGVzIHRoaW5n IGVhc2lseSwgYnV0IGl0IGFwcGVhcnMgdGhhdCANCj4gaXQgd291bGQgYmUgZWFzaWVyIGFzIGFu IGVkaXRvcmlhbCBleGVyY2lzZSwgZm9sbG93ZWQgYnkgd29ya2luZyBncm91cCByZXZpZXcsIHRo YW4gaXQgd291bGQgYmUgdG8gc29ydCBpdCBvdXQgb24gdGhlIGxpc3QuDQoNCkkgd2lsbCB1cGRh dGUgdGhlIHByb2NlZHVyZXMsIHNvIHRoYXQgdGhleSBhbGxvdyB1c2FnZSBvZiBtdWx0aXBsZSBm aW5nZXJwcmludHMuDQoNCkJ1dCwgdGhlIFNFTUFOVENJUyBvZiB1c2luZyBtdWx0aXBsZSBmaW5n ZXJwcmludHMgYmVsb25nIGluIDQ1NzIsIGluIG15IG9waW5pb24uIFdlIGNhbiBmb3Igc3VyZSB1 cGRhdGUgNDU3MiB3aXRoaW4gZHJhZnQtZHRscy1zZHAsIG9uY2Ugd2UgYWdyZWUgb24gc3VjaCBz ZW1hbnRpY3MgdGV4dC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Wed Feb 24 16:24: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 882A11A87EA for ; Wed, 24 Feb 2016 16:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, 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 g_59LvexzmIf for ; Wed, 24 Feb 2016 16:24:40 -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 8E4131A8961 for ; Wed, 24 Feb 2016 16:24:40 -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=irxfQVTSY3r+CrtTjv523Y3Z8l22Yr5tjVvB6U0/9XI=; b=Vn18P+JITtlZkmLMQV8mvW5tM1 P6w5eiXrnDqTVIPvGdo+FdYkyCTyRPQvlZkb96yqdwofTaxN39CPX3e7gNUDi4Rct//HMXCg4z6SZ gyvkkxEDEvDnbeQL95K+mR0bVZ0yd3nbk7ccnO1LA/e5i+pMyoWSODM2DVx/gqnC2C7ohxPjSIqN1 mE4SuEUr0gX7hSZqkal0+ZuEtvve4Y3seXG2w1exju36cc3geXdJlowRXroeLJDWr6oIPyggqIPGG pbGIlN0WBSyRKJsiTOiBogluM3pv27nXk/dkeeRG7jd7VrvcP8ps9tqHZ6/4kh/zM/ho8/tfhA+A2 GtThTJ1g==; Received: from ppp118-209-85-108.lns20.mel4.internode.on.net ([118.209.85.108]:50690 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aYjjR-001nSZ-W5 for mmusic@ietf.org; Thu, 25 Feb 2016 11:24:38 +1100 To: mmusic@ietf.org References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> From: Christian Groves Message-ID: <56CE49C1.2020605@nteczone.com> Date: Thu, 25 Feb 2016 11:24:33 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CCCE6F.9040106@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Thu, 25 Feb 2016 00:24:43 -0000 Hello Juergen and Paul, Please see at end. Regards, Christian On 24/02/2016 8:26 AM, Paul Kyzivat wrote: > ..snip.. >> >> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>> Hi Paul, Christian, Flemming, Bo, >>>> >>>> Have just submitted version 08 of >>>> draft-ietf-mmusic-data-channel-sdpneg. >>>> The changes compared to version 07 are essentially as follows. >>>> >>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>> regarding the >>>> relationship of subprotocols and their attributes. >>>> * Two new SDP offer/answer considerations in section 5.2.5 (Various >>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>> subprotocol attributes or known subprotocol attributes, whose data >>>> channel transport specific semantic is not known. >>>> * A new paragraph in section 8.1 (IANA Considerations / Subprotocol >>>> Identifiers) related to cases, where a subprotocol is defined for data >>>> channel and Websocket transport. >>>> >>>> These changes should address the points discussed in this email >>>> thread. >>> >>> This is an improvement. But I think things could still be made clearer. >>> >>> Consider the following addition to 5.1.2.1: >>> >>> 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. A data channel >>> specific usage of a subprotocol attribute is expected to be >>> specified >>> in the same document, which registers the subprotocol's identifier >>> for data channel usage as described in Section 8.1. >>> >>> This text makes sense when there is a clear distinction between >>> subprotocol and protocol. Unfortunately, the way SDP has evolved there >>> is no such clear distinction in many cases, such as RTP over UDP or >>> TCP, etc. Those are combined into a single protocol value. While that >>> can usually be parsed apart at slashes, there isn't good terminology >>> for it. >>> >>> My point is that when I read the above, I don't know how it applies >>> to, say, RTP attributes. Or does it only apply for attributes that are >>> clearly defined for a *sub*protocol? >>> >>> I think this is primarily that we lack well defined vocabulary for all >>> of this. But I think it would be too much to expect this draft to >>> *solve* the vocabulary problem. In lieu of doing so, maybe it would be >>> sufficient to give some concrete examples, even if they have to be >>> hypothetical ones. >> >> [Juergen] Agree that it would be helpful to have more precise >> definitions of the differences of the terms protocol and subprotocol, >> especially when those terms are used outside the scope of data channels >> (or Websockets). When only focusing on data channels the notion of a >> "subprotocol" seems to be clearer - at least >> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >> Subprotocol Name Registry" when specifying DCEP's "Protocol" parameter. >> (But draft-ietf-rtcweb-data-channel does not define what a data >> channel's "subprotocol" is.) So far the sdpneg draft relatively >> informally starts using the term "subprotocol" in the introduction and >> there refers to Websocket "subprotocols". Perhaps we should add the term >> "subprotocol" to the list of used terminology in section 3. >> >> The sdpneg document, together with the data channel subprotocol specific >> document (which defines the value of the a=dcmap attribute's >> "subprotocol" parameter), should certainly give clear guidance on how to >> interpret SDP offers or answers like e.g.: >> >> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >> c=IN IP4 10.10.10.1 >> a=max-message-size:100000 >> a=sctp-port:5000 >> ... >> a=dcmap:0 subprotocol="MSRP" >> a=dcsa:0 accept-types:message/cpim text/plain >> a=dcsa:0 framerate:... >> a=dcsa:0 lang:... >> >> An implementation receiving such an offer would need to decide what to >> do with the dcsa embedded framerate and lang attributes. Or, someone >> implementing MSRP over data channel based services may need to decide >> whether or not to use these attributes, and if yes, how. >> (I am using these two attributes just as hypothetical examples - don't >> want to suggest that those may indeed be used for MSRP over data channel >> transport). >> >> The msrp-usage-data-channel document doesn't mention these two >> attributes. When looking at the IANA SDP attribute registry tables, I >> would find both attributes specified in RFC 4566. There, "framerate" is >> explicitly said to be defined only "for video media". Just to be sure I >> could additionally have a look at the MSRP specifying documents, RFC >> 4975 and RFC 4976, but there would not find any text at all related to >> "framerate". So this case seems pretty clear and I would therefore >> conclude that the "framerate" attribute should not be used for MSRP, and >> that a receiver of such an offer or answer should ignore it. >> >> When looking at the definition of the "lang" attribute in RFC 4566 I >> would not see any explicit hint of what protocols this attribute might >> be used with, especially if "lang" could be used when negotiating an >> MSRP session. When then looking at RFC 4975 I would indeed find "lang" - >> but not as SDP attribute, rather as XML tag parameter within an example >> MSRP message payload. Thus, the case of the "lang" attribute might not >> be as unambiguous as the one with the "framerate" attribute, but here >> too I think the typical choice would be to ignore that attribute when >> receiving such an offer or answer. >> It seems to me that the two new "ignore" rules in section 5.2.5 of >> sdpneg-08 may also be applied in these cases. >> >> Admittedly, these examples may seem a bit far-fetched, but would those >> go into the direction you had in mind? > > Yes. Note that using examples is just me grasping at straws, since a > real solution looks like to big a problem for this draft to tackle by > itself. I am entirely open to other ideas for how to deal with this. [CNG] I don't see what the example buys? I don't see that the behaviour is any different between using additional attributes in the datachannel vs. the non data channel case. E.g. for c=IN IP4 10.10.10.1 m=message 7394 TCP/MSRP * a=accept-types:message/cpim text/plain text/html a=lang:.... a=framerate:... The ignore behaviour would be the same. In the above example the attributes are scoped by the m= line. In the data channel case the attributes are scoped by the relevant a=dcmap: line. Regards, Christian > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Feb 24 20:05: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 CD7E21A900A for ; Wed, 24 Feb 2016 20:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_111=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 QBTiJURLS_Wm for ; Wed, 24 Feb 2016 20:05:02 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001: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 A140C1A924A for ; Wed, 24 Feb 2016 20:05:02 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id z8so5646812ige.0 for ; Wed, 24 Feb 2016 20:05: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; bh=MgzLjfrbtujTimtgiUuKGSL5wushnOq10nekGF9f4iI=; b=zxejwuS9NUbaU8mCzligCCkruRmRb9hr0zPcLnhdHoyfltzQiDmj+B9Fm5opCguQpp pgV1oxP5YCEQUHZoPLyEax9LnUErIE+DmmJR3xvMG1s7co0AvGGsCxx0RsZkWjASEoEI t/eNUUx8CkPUBDeuKPvmWN5k+D8Kmy8TzWFXOWntmJxEjPFTcvmeiV/4sVDVtnHKpIMa QpwaSy9It70vPKVEWDp2zrtGf9JnhvS+Tsmbu6+nVy/8g1Q0YOnfVOTVYqgJWVCO3Fed mFyviAzkWWu8v0anokREbdxB69LSuBubn7AoMrOIKY1lzbURXHMPYqne8M9XKOjK/GBx Rpgw== 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; bh=MgzLjfrbtujTimtgiUuKGSL5wushnOq10nekGF9f4iI=; b=ZOVb4nUp3F6ywFQ8Z6N6VeLP//VPNJmhBM7zftAKnZWEUbrPvLBzIKJ/u7g3coXQtE RdsCsZgYfq0rL1eLI60g5v96Po9hr1TOYx9CJmX13BA0h6FllfLymEIfd9uBUMGiXQol n6NTp2J7eB5DPQa4/R5TFpOn0OhuMrmrctMPfiJeygCXBsDkixhJ/9pt7x5R0Ahz5z0g MfrTKwH2Y6gHYHzPJGNsgZpeMzVIsvgo6OkATstFRv0EpCD/5+7HEgzs+IN8tDQxB1to KQncacLDLmB7AaL+byyg7eCip722qUIcYGzk02OH7Ei6xg+nrbqAHh46wSdpmVML9ZXZ GNdw== X-Gm-Message-State: AG10YORR54b8ibvY7p6yR1Q/GqhGSExgkNlvAUoebCT9kFCWeOPmiNelNPy1CbkwIFuFYUOTWDTj5tbPEAnw3Q== MIME-Version: 1.0 X-Received: by 10.50.60.34 with SMTP id e2mr1075769igr.77.1456373101968; Wed, 24 Feb 2016 20:05:01 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 20:05:01 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4061F@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4061F@ESESSMB209.ericsson.se> Date: Wed, 24 Feb 2016 20:05:01 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 04:05:04 -0000 On 24 February 2016 at 15:48, Christer Holmberg wrote: > the text can simply say that the certificate is only a receptacle for a public key and authentication is tied to an a=fingerprint line in the SDP. > > Could you suggest the exact text change? See above. From nobody Wed Feb 24 22:53: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 3E9E61B2EDA for ; Wed, 24 Feb 2016 22:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 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.006, 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 qE8B6y_im0DT for ; Wed, 24 Feb 2016 22:53:42 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 BD78C1B2ED6 for ; Wed, 24 Feb 2016 22:53:42 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id ts10so40978483obc.1 for ; Wed, 24 Feb 2016 22:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=udG82Hk9XHwvhwWwBYM20usMNKqYcH4bubMdM/ueHwA=; b=S26eBwld4ns9Cp1K+t+E5YctvXAgCA05w3GA7WMvIKewX0di00FNlD8MTAE/ybcNXx NVHa13UvELzzE/kheqEeMc6Spz3oTQ8NMeEbuqy7odWqRFJyetgYWbnhd/69VUwHq6WS wH4Jm3J4t5a+z6XBJc9FEwvlVpKU/Eene5y1uql+PPEgEmXvW7JiEYCynqKAQ/y5y3Ie IO5snzQakkoiHo6FmH33NGUOUvJCX2mko6SurQgfjM9gEY45kspuu5xDw/GeTiE3xDTY woiV+/LhbgXjYQvcIH9w5danO4h9g+YqdJAs0jUgIoTrZzw9DE68F8wI8hkyCdqAkKZg QuoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=udG82Hk9XHwvhwWwBYM20usMNKqYcH4bubMdM/ueHwA=; b=FK1gUzkt5p0NXouiNlXkAsfMVzvfiwyuU0mWQSfw0KV46rZxbaHJNMyCAzxIZZtWyS 3w6IgB96EAwwYN+CEUqrwGKdeU5UttROIzAZIpAx53z158g8xw74qAbT5+J/5FzmCwYZ E5KsBBflT/XmlFYOkKaRppOyd1khJryzF66/NKzg36oxUo9CuBFVZpaqsTjD4FqmWS+q GMdBt11xn7JExYVoonq1mxldxekHPNR9FpMdpVmfpmMQrcDSC8rQOZj0NIpYSMOo53i7 KitPDg/dMwQnH4iuNlIneFaEYN7n+1V8KDWK6VGR0S1hGCR14LSS493BrFH8mcjGdiP7 pBfg== X-Gm-Message-State: AG10YOQcBcg/oN+Us8PTt+K0SEcdhS8Pi51BVbcBrEC5YLQQWN/zNOf85oxgIZ/4emGR4tPqt4RsQEI80gF5Oz2D X-Received: by 10.182.86.33 with SMTP id m1mr35627325obz.48.1456383222114; Wed, 24 Feb 2016 22:53:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.104.75 with HTTP; Wed, 24 Feb 2016 22:53:02 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E24284@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E24284@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Wed, 24 Feb 2016 22:53:02 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0149ce669cc3e8052c92a485 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 25 Feb 2016 06:53:44 -0000 --089e0149ce669cc3e8052c92a485 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That makes sense to me. On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Roman, > > I didn't check whether some of the ICE attributes were session-level, but > I agree with what you say: the same rule should apply to all media-level > ICE attributes. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Roman Shpount > Sent: =E2=80=8E21/=E2=80=8E02/=E2=80=8E2016 08:21 > To: Christer Holmberg > Cc: Peter Thatcher ; mmusic@ietf.org; Paul Kyzivat > > Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE > > On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >> Correct, and that's one reason I suggest that we limit the scope to >> ICE, eventhough we probably >> >> could do the same thing for any IDENTICAL and TRANSPORT category >> attribute. >> > >> =E2=80=8B> While it would be nice to remove any duplication, the duplica= tion is >> particularly painful for ICE candidates, because >> > there can be a lot of them, and because they change without any >> offer/answer action (thanks to trickle ICE). =E2=80=8B >> > So if we just covered that candidates, we'd be getting most of the >> value. >> >> Assuming the scope is ICE, shouldn't the same still apply also to other >> ICE related attributes? I assume the values for the "remote-candidates", >> "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", "ice-pacing" and >> "ice-options" attributes will be identical within a BUNDLE group, so... >> > > "ice-lite" and "ice-options" are session level only candidates, so they > should not be in the m=3D line BUNDLE or any other type. The same logic t= hat > applies to ICe candidates should apply to other media level ICE SDP > attributes or things will break > > Regards, > _____________ > Roman Shpount > > --089e0149ce669cc3e8052c92a485 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That makes sense to me.<= br>

On= Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
Hi Roman,

I didn't check whether some of the ICE attributes were session-level, b= ut I agree with what you say: the same rule should apply to all media-level= ICE attributes.

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount Sent: =E2=80= =8E21/=E2=80=8E02/=E2=80=8E2016 08:21
To: Christer Holm= berg
Cc: Peter Thatcher; mmusic@ietf.org; <= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank"> Paul Kyzivat
Subject: Re: [M= MUSIC] Questions about ICE candidates with BUNDLE

On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg <chr= ister.holmberg@ericsson.com> wrote:
>> Correct, and that's one reason I suggest that we limit the sco= pe to ICE, eventhough we probably
>> could do the same thing for any IDENTICAL and TRANSPORT category a= ttribute.
>
=E2=80=8B> While it would be nice to remove any duplication, the duplica= tion is particularly painful for ICE candidates, because
> there can be a lot of them, and because they change without any offer/= answer action (thanks to trickle ICE). =E2=80=8B =C2=A0
> So if we just covered that candidates, we'd be getting most of the= value.
=C2=A0
Assuming the scope is ICE, shouldn't the same still apply also to other= ICE related attributes? I assume the values for the "remote-candidate= s",=C2=A0 "ice-lite", "ice-mismatch", "ice-uf= rag", "ice-pwd", "ice-pacing" and "ice-option= s" attributes will be identical within a BUNDLE group, so...

"ice-lite" and "ice-options" are session level onl= y candidates, so they should not be in the m=3D line BUNDLE or any other ty= pe. The same logic that applies to ICe candidates should apply to other med= ia level ICE SDP attributes or things will break

Regards,
_____________
Roman Shpount
=C2=A0

--089e0149ce669cc3e8052c92a485-- From nobody Thu Feb 25 01:38: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 9763F1A88FA for ; Thu, 25 Feb 2016 01:38:37 -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_111=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 D3HUGQSyqWy2 for ; Thu, 25 Feb 2016 01:38:36 -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 1380A1A889F for ; Thu, 25 Feb 2016 01:38:35 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-c9-56cecb9a6dcf Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.79.15637.A9BCEC65; Thu, 25 Feb 2016 10:38:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 10:38:33 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt - altSubjectName Thread-Index: AdFvrzAFSQUZkavrSmmyb2DxIrHQUg== Date: Thu, 25 Feb 2016 09:38:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4116F@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7oO6s0+fCDP79ELRY8focu8X+xeeZ LbZOFbK4duYfo8XU5Y9ZLFZsOMDqwObx9/0HJo+ds+6yeyzYVOqxZMlPJo/Jj9uYPdqe3WEP YIvisklJzcksSy3St0vgypi14TJ7wQXOikefVzE2MG7g7GLk5JAQMJG4e28qK4QtJnHh3nq2 LkYuDiGBw4wSXY1/mSGcxYwSJ+9sYOli5OBgE7CQ6P6nDdIgIqArsejsA3aQGmaBx4wS79fc BasRFgiSeN9fCmKKCARLPH2sA1GuJzG1eQY7SJhFQFViyuQckDCvgK9Ew93TYCcwAp3w/dQa JhCbWUBc4taT+UwQpwlILNlznhnCFpV4+fgf1MlKEo1LnrCCjGQW0JRYv0sfolVRYkr3Q3aI 8YISJ2c+YZnAKDILydRZCB2zkHTMQtKxgJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg TB3c8lt1B+PlN46HGAU4GJV4eDf8PRsmxJpYVlyZe4hRgoNZSYTXcu+5MCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8a5zXhwkJpCeWpGanphakFsFkmTg4pRoYYy9cqfVqbr2o9PpTr/vRm43t YX4tky7e0Ni1543oWY0kz//nTxoYX5b8GnvyyQH21CZFrbXLf9lMCOG7mhpxmOf/0mm3QrQ+ fT0kyHzbKM5za3eIw41n2YzXV26bZ+EpxP1ifsSL7j1rdsXGvuWfl2qRcuOkJuP/ngWHc2cK 1gtJ6T/+pLfZSImlOCPRUIu5qDgRAGx8sYClAgAA Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt - altSubjectName 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, 25 Feb 2016 09:38:37 -0000 SGkgTWFydGluLA0KDQo+Pj4gSSBhbHNvIHNlZToNCj4+Pg0KPj4+ICAgVGhlICBzdWJqZWN0QWx0 TmFtZSBpcyBub3QgYW4gaW1wb3J0YW50IGNvbXBvbmVudCBvZiB0aGUgY2VydGlmaWNhdGUNCj4+ PiAgIHZlcmlmaWNhdGlvbi4NCj4+Pg0KPj4+IHRoZSB0ZXh0IGNhbiBzaW1wbHkgc2F5IHRoYXQg dGhlIGNlcnRpZmljYXRlIGlzIG9ubHkgYSByZWNlcHRhY2xlIGZvciBhIHB1YmxpYyBrZXkgYW5k IGF1dGhlbnRpY2F0aW9uIGlzID4+PnRpZWQgdG8gYW4gYT1maW5nZXJwcmludCBsaW5lIGluIHRo ZSBTRFAuDQo+Pg0KPj4gQ291bGQgeW91IHN1Z2dlc3QgdGhlIGV4YWN0IHRleHQgY2hhbmdlPw0K Pg0KPiBTZWUgYWJvdmUuDQoNCkNvdWxkIHdlIHNpbXBseSByZW1vdmUgdGhlIHNlbnRlbmNlPyBU aGUgc2VudGVuY2UgYmVmb3JlIHNheXMgcHJldHR5IG11Y2ggd2hhdCB5b3Ugc3VnZ2VzdCwgZG9l c24ndCBpdD8NCg0KICAiSWYgc2VsZi1zaWduZWQgY2VydGlmaWNhdGVzIGFyZSB1c2VkLCB0aGUg Y29udGVudCBvZiB0aGUNCiAgIHN1YmplY3RBbHROYW1lIGF0dHJpYnV0ZSBpbnNpZGUgdGhlIGNl cnRpZmljYXRlIE1BWSB1c2UgdGhlIHVuaWZvcm0NCiAgIHJlc291cmNlIGlkZW50aWZpZXIgKFVS SSkgb2YgdGhlIHVzZXIuICBUaGlzIGlzIHVzZWZ1bCBmb3IgZGVidWdnaW5nDQogICBwdXJwb3Nl cyBvbmx5IGFuZCBpcyBub3QgcmVxdWlyZWQgdG8gYmluZCB0aGUgY2VydGlmaWNhdGUgdG8gb25l IG9mDQogICB0aGUgY29tbXVuaWNhdGlvbiBlbmRwb2ludHMuICBUaGUgaW50ZWdyaXR5IG9mIHRo ZSBjZXJ0aWZpY2F0ZSBpcw0KICAgZW5zdXJlZCB0aHJvdWdoIHRoZSBmaW5nZXJwcmludCBhdHRy aWJ1dGUgaW4gdGhlIFNEUC4iDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyIA0K From nobody Thu Feb 25 01:51: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 69B881A89FD for ; Thu, 25 Feb 2016 01:51:51 -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 SzI7sSZ6-3Hk for ; Thu, 25 Feb 2016 01:51: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 ED8801A89ED for ; Thu, 25 Feb 2016 01:51:48 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-02-56ceceb38f44 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.F1.28465.3BECEC65; Thu, 25 Feb 2016 10:51:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 10:51:46 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Aligning RFC 4572 and draft-dtls-sdp regarding preferred SHA cipher? Thread-Index: AdFvsW9lhpl7PLOcTkaFsOGhrABCdw== Date: Thu, 25 Feb 2016 09:51:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E411AC@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E411ACESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7uu7mc+fCDF6f5Le4duYfo8XU5Y9Z LFZsOMBqMePCVGYHFo+/7z8weeycdZfdY8mSn0wet6YUBLBEcdmkpOZklqUW6dslcGWs+fmM qeCCScXDOVsYGxhP6nYxcnJICJhIbJ52mwnCFpO4cG89WxcjF4eQwGFGife3PrNCOIsZJbZt +cvexcjBwSZgIdH9TxukQURAXeLr3h5mEJtZYBGjxM03wSC2sICvxKNvf1khakIkmm89YYKw 9SQuPToKFmcRUJX4cqaNHcTmBaqf/rqbDcRmBDri+6k1TBAzxSVuPZkPdZyAxJI955khbFGJ l4//sULYShKNS56wQtTnS7y5eAdqpqDEyZlPWCYwCs9CMmoWkrJZSMog4joSC3Z/YoOwtSWW LXzNDGOfOfCYCVl8ASP7KkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAKDu45bfuDsbVrx0P MQpwMCrx8G74ezZMiDWxrLgy9xCjBAezkghv0OlzYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 1zivDxMSSE8sSc1OTS1ILYLJMnFwSjUwBntF2/z6/G+TXX2zGtcEzW0vBO/fKczxy33wiulg pvjlsJJrsv9Pbjp4rk+8XWyr8pLiJSenf/Pb3Ge2sODfpbPT67RqL1yO2XfSuWjOKpcnk+4o 5KeebX80J/Ir08FpJRsCQ1q6L4otWqIR4bRY0SUw4vlUy/dm0T9fymwvkJdaltF4/qlLkBJL cUaioRZzUXEiAJ8Wj7muAgAA Archived-At: Cc: "pkyzivat@alum.mit.edu" Subject: [MMUSIC] Aligning RFC 4572 and draft-dtls-sdp regarding preferred SHA cipher? 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, 25 Feb 2016 09:51:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E411ACESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC 4572 (tls-sdp) contains the following text: "Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the defined hash functions are 'SHA-1' [= 11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-51= 2' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred." Draft-dtls-sdp contains the following text: "Endpoints MUST support SHA-256 for generating and verifying the fingerprin= t value associated with the DTLS association. The use of SHA-2= 56 is preferred." I.e. for TLS SHA-1 is preferred, and for DTLS SHA-256 is preferred. Martin suggested (I assume) that we should update RFC 4572, to make SHA-256= preferred also for TLS. Assuming we do the update, I guess the updated 4572 text would say: "Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the defined hash functions are 'SHA-1' [= 11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-51= 2' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-256' preferred." Q1: Do people agree to updating the preferred cipher in 4572? Q3: IF(Q1) Should the update be done within draft-dtls-sdp, or shoul= d we create a separate draft/milestone for it? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37E411ACESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC 4572 (tls-sdp) contains the following text:=

 

“Following RFC 32= 79 [7] as updated by RFC

         &nb= sp;    4055 [9], therefore, the defined hash functions are '= SHA-1' [11]

         &nb= sp;    [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11],= 'SHA-512' [11],

         &nb= sp;    'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred.&#= 8221;

 

Draft-dtls-sdp contains the following text:

 

“Endpoints MUST s= upport SHA-256 for generating and verifying the fingerprint

         &nb= sp;     value associated with the DTLS association. The= use of SHA-256 is preferred.”

 

I.e. for TLS SHA-1 is preferred, and for DTLS SHA-25= 6 is preferred.

 

Martin suggested (I assume) that we should update RF= C 4572, to make SHA-256 preferred also for TLS.

 

Assuming we do the update, I guess the updated 4572 = text would say:

 

“Following RFC 32= 79 [7] as updated by RFC

         &nb= sp;    4055 [9], therefore, the defined hash functions are '= SHA-1' [11]

         &nb= sp;    [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11],= 'SHA-512' [11],

         &nb= sp;    'MD5' [12], and 'MD2' [13], with 'SHA-256' preferred.= ”

 

 

Q1:        Do peo= ple agree to updating the preferred cipher in 4572?

 

Q3:        IF(Q1)= Should the update be done within draft-dtls-sdp, or should we create a sep= arate draft/milestone for it?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E411ACESESSMB209erics_-- From nobody Thu Feb 25 02:06: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 85FF91A8981 for ; Thu, 25 Feb 2016 02:06:57 -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 HA2o2Sv5QNVc for ; Thu, 25 Feb 2016 02:06:56 -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 AA8321A8912 for ; Thu, 25 Feb 2016 02:06:55 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-a3-56ced23d1f09 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2B.A1.20792.D32DEC65; Thu, 25 Feb 2016 11:06:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 11:06:06 +0100 From: Christer Holmberg To: Roman Shpount , "Dale R. Worley" , Martin Dolly Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AQHRbyb1iZ+JG67LRQCl2lgEejcpMJ87YisAgAElpjA= Date: Thu, 25 Feb 2016 10:06:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E41317@ESESSMB209.ericsson.se> References: <878u2ayqq6.fsf@hobgoblin.ariadne.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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7ga7tpXNhBg+2mFkcevCU3WLq8scs FjMuTGW2eHmizIHFY/L+r8weL/vnMHosWfKTyePWlIIAligum5TUnMyy1CJ9uwSujH/7tzEW nBCpuNeym72BsUWki5GTQ0LARGLXrTY2CFtM4sK99UA2F4eQwGFGiXsfD0M5ixklbv/YwNjF yMHBJmAh0f1PG6RBRCBX4ue/XcwgYWYBdYmri4NAwsIC+hLvFx1hhygxkNj78gCUbSWx9F4b C4jNIqAqsWzjVLA4r4CvxOtt98FsIYEDjBLvtwaA2JwCgRLz23vB6hmBbvt+ag0TiM0sIC5x 68l8JoibBSSW7DnPDGGLSrx8/I8VwlaSaFzyhBXiNE2J9bv0IVoVJaZ0P4RaKyhxcuYTlgmM YrOQTJ2F0DELSccsJB0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG18Etv612MB58 7niIUYCDUYmHd8Pfs2FCrIllxZW5hxglOJiVRHiDTp8LE+JNSaysSi3Kjy8qzUktPsQozcGi JM67xnl9mJBAemJJanZqakFqEUyWiYNTqoFR6tTTFm/17LzCibxJJ66sZVecqV3r5fEk7P8n 1+1qmk6XOFZ2MFo8kDcKivSTU99hFOtwSZb/6ds/KUKzngnkvZBhOe2dZOX6ZMMFrei3n392 ZsksOvnuTmD4t41Bhk8LCx0X6+YK+TXF3/+xeXe/7LaGS4lzZxk8br0Qc0K3+988Q1UzCQ4l luKMREMt5qLiRABfMSPTqgIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 25 Feb 2016 10:06:57 -0000 SGkgUm9tYW4sDQoNCj4+PiAyLiBJcyBQVCBibG9ja2VkIGZyb20gZWFjaCBkaXJlY3Rpb24gaW5k ZXBlbmRlbnRseSBvciBib3RoIGRpcmVjdGlvbnMgYXQNCj4+PiB0aGUgc2FtZSB0aW1lLiBGb3Ig aW5zdGFuY2UgaWYgQSBzZW50IGFuIG9mZmVyIHdpdGggUFQ9MTAwLCBidXQgQiBuZXZlcg0KPj4+ IHNlbnQgYW4gb2ZmZXIgb3IgYW4gYW5zd2VyIHdpdGggUFQ9MTAwLCBjYW4gQiBzZW50IGFuIG9m ZmVyIHdpdGggUFQ9MTAwPw0KPj4+DQo+Pk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgYW5z d2VyIHRvIDIgaGFzIGFsd2F5cyBiZWVuIHVuZGVyc3Rvb2QgdG8NCj4+YmUgdGhhdCB0aGUgUFQg bnVtYmVyIHNwYWNlcyBpbiBlYWNoIGRpcmVjdGlvbiBhcmUgaW5kZXBlbmRlbnQuwqAgRm9yDQo+ Pmluc3RhbmNlLCBSRkMgMzI2NCBzZWN0aW9uIDUuMSBub3Rlcw0KPj4NCj4+wqAgwqAgwqAgRGlm ZmVyZW50IHBheWxvYWQgdHlwZSBudW1iZXJzIG1heSBiZSBuZWVkZWQgaW4gZWFjaCBkaXJlY3Rp b24NCj4+wqAgwqAgwqAgYmVjYXVzZSBvZiBpbnRlcm9wZXJhYmlsaXR5IGNvbmNlcm5zIHdpdGgg SC4zMjMuDQo+DQo+IEJhc2VkIG9uIHRoaXMsIHRoZSBhbnN3ZXIgdG8gb3JpZ2luYWwgcXVlc3Rp b24gaXMgdGhhdCBpZg0KPg0KPiAxLkFsaWNlIHNlbmRzIGFuIE9mZmVyLCB3aXRoIHRoZSBmb2xs b3dpbmcgUFQgdmFsdWVzOg0KPg0KPiBQVCAxMDA6IEFNUi1XQihtb2RlLXNldD0yKQ0KPiBQVCAx MTE6IEFNUi1XQihtb2RlLXNldD0yLCBPQSkNCj4gUFQgMDogUENNVQ0KPiAyLkJvYiBzZW5kcyB0 aGUgYXNzb2NpYXRlZCBBbnN3ZXI6DQo+DQo+IFBUIDEwMDogQU1SLVdCIChtb2RlLXNldD0yKQ0K PiBQVCAwOiBQQ01VDQo+DQo+IDMuTGF0ZXIgQm9iIHNlbmRzIHRoZSBmb2xsb3dpbmcgc3Vic2Vx dWVudCBPZmZlcjoNCj4gUFQgMTExOiBBTVIobW9kZS1zZXQ9MCwyLDUsNykNCj4NCj4gVGhpcyBv ZmZlciBzaG91bGQgYmUgYWNjZXB0ZWQuIFBUIGlzIGVhY2ggZGlyZWN0aW9uIGlzIGluZGVwZW5k ZW50IGFuZCBCb2IgaXMgYWxsb3dlZCB0byByZXVzZSBpdC4NCg0KTm90IG5lY2Vzc2FyaWx5LiBF dmVuIGlmIFBUIGlzIHBlciBkaXJlY3Rpb24gaXMgYWxsb3dlZCBhcyBzdWNoLCB3ZSBzdGlsbCBu ZWVkIHRvIGNsYXJpZnkgd2hldGhlciB0aGUgc2FtZSBQVC9jb2RlYyBiaW5kaW5nIGlzIHBlciBk aXJlY3Rpb24sIG9yIHdoZXRoZXIgaXQgYXBwbGllcyB0byB0aGUgd2hvbGUgc2Vzc2lvbi4gDQoN Cj4gVGhlIGNvbXBsaWNhdGlvbiBoZXJlIGlzIHRoYXQgQWxpY2Ugd2lsbCBub3QgYmUgYWxsb3dl ZCB0byByZXVzZSBQVCAxMTEgZm9ywqBBTVIobW9kZS1zZXQ9MCwyLDUsNykgaW4gdGhlIGFuc3dl ci4gQWxpY2Ugd2lsbCBuZWVkIHRvIHBpY2sgYQ0KPiBkaWZmZXJlbnQgUFQgZm9ywqBBTVIobW9k ZS1zZXQ9MCwyLDUsNyksIGlmIGl0IGlzIHN1cHBvcnRlZCBhbmQgZW5kIHBvaW50cyB3aWxsIHVz ZSBhc3ltbWV0cmljIHBheWxvYWQgdHlwZXMuDQoNClNvLCB5b3UgYXJlIHNheWluZyB0aGF0IEFs aWNlIGlzIG5vdCBhbGxvd2VkIHRvIHJldXNlIGEgUFQgdmFsdWUgdGhhdCBBbGljZSBoYXMgcHJl dmlvdXNseSB1c2VkIGZvciBhbm90aGVyIFBUL2NvZGVjIGJpbmRpbmcgLSBubyBtYXR0ZXIgaWYg Qm9iIHN1cHBvcnRlZCB0aGUgY29kZWMgb3Igbm90Pw0KDQpGb3IgZXhhbXBsZTogYXNzdW1lIEFs aWNlIG9mZmVyZWQgUFQgMTExOiBWUDgsIGJ1dCBCb2IgZGlkIG5vdCBpbmNsdWRlIFZQOCBpbiB0 aGUgYW5zd2VyLiBUaGVuIEJvYiBvZmZlcnMgUFQgMTExOkFNUi4gTm93LCBBbGljZSBpcyBub3Qg YWxsb3dlZCB0byB1c2UgUFQgMTExIGZvciBBTVIsIHNpbmNlIEFsaWNlIHByZXZpb3VzbHkgdXNl ZCBpdCBmb3IgVlA4Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Thu Feb 25 02:08:56 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 07EA01A8A47 for ; Thu, 25 Feb 2016 02:08:55 -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 UYnR1RuB_OmS for ; Thu, 25 Feb 2016 02:08: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 EDAC21A8A52 for ; Thu, 25 Feb 2016 02:08:50 -0800 (PST) X-AuditID: c1b4fb30-f79f66d000000729-db-56cec5692c3e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.D2.01833.965CEC65; Thu, 25 Feb 2016 10:12:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 10:12:09 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAA9P4A///VdXCAAICGAP/97qPQgAQdwwD//0NkYA== Date: Thu, 25 Feb 2016 09:12:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E41020@ESESSMB209.ericsson.se> References: <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <949EF20990823C4C85C18D59AA11AD8BADE903FF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56CC7CA8.4050309@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADE926CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56CE348E.1080600@alum.mit.edu> In-Reply-To: <56CE348E.1080600@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7qG7m0XNhBkcmGVhMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG2/4bTAUvzCtWHXnP3MC4wayLkZNDQsBE YltDOzuELSZx4d56ti5GLg4hgcOMEnMPzmCFcBYzShy8Oh0ow8HBJmAh0f1PG6RBRMBX4tnj 22wgtrCAvsT7RUfYIeIGEntfHoCysyT6p34Dq2ERUJV41HKXBWQML1Dv5RXpEOOXs0icudDJ ClLDKaAj8ffXWbB6RqCDvp9awwRiMwuIS9x6Mp8J4lABiSV7zjND2KISLx//Y4WwlSQalzxh BZnPLKApsX6XPkSrosSU7odg5/AKCEqcnPmEZQKj6CwkU2chdMxC0jELSccCRpZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIExcnDLb4MdjC+fOx5iFOBgVOLh3fD3bJgQa2JZcWXuIUYJ DmYlEV7LvefChHhTEiurUovy44tKc1KLDzFKc7AoifOudl4fJiSQnliSmp2aWpBaBJNl4uCU amCc/Mv0s8qXU0/Zv2z6qtPqG8SrbiT9ro7v9ZEdL47/Ef94Mmh6yZon52atir/kpsmdlfvv 5ctfj4w5HTq3arc/PLl/u6DhhJQfez4f1d1+xzNfri5/kuPNhT9DjJTLpiqtu3i0uFXdsWGz TIatYY1g0/aLEzbe+vw0gN+ggy98Qnq+5Tb9khv3lViKMxINtZiLihMBymPA9I0CAAA= Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 25 Feb 2016 10:08:55 -0000 SGksDQoNCkkgaGF2ZSB0byBzYXkgdGhhdCBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGNvbm5lY3Rp b24gd2l0aCBkZWNsYXJhdGl2ZSB1c2UgZWl0aGVyLg0KDQpGaXJzdCwgZGVjbGFyYXRpdmUgdXNl IGlzIG5vdCBhIG5lZ290aWF0aW9uIC0gdGhlcmUgaXMgbm8gb2ZmZXIgYW5kIGFuc3dlci4NCg0K U2Vjb25kLCBpZiBJIHNlbmQgYSBkZWNsYXJhdGl2ZSBTRFAgbm93LCBhbmQgYSBzZWNvbmQgb25l IGxhdGVyLCB0aGVyZSBhcmUgbm8gcnVsZXMgc2F5aW5nIHRoYXQgdGhlIHNlY29uZCBvbmUgaGFz IHRvIGJlIGRlcGVuZGVudCBvbiB0aGUgZmlyc3Qgb25lLiBUaGUgbnVtYmVyIG9mIG0tIGxpbmVz IGNhbiBiZSBkaWZmZXJlbnQsIHByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5l cyBjYW4gYmUgZGlmZmVyZW50LCBQVC9jb2RlYyBtYXBwaW5ncyBjYW4gYmUgZGlmZmVyZW50LiBF dGMgZXRjIGV0YyBldGMuDQoNCldlIGFyZSBub3QgdHJ5aW5nIHRvIGNoYW5nZSB0aGUgYmFzaWMg U0RQIHNlbWFudGljcyAtIHdlIGFyZSB0cnlpbmcgdG8gY2xhcmlmeSB0aGUgc2VtYW50aWNzIGFu ZCBydWxlcyBhc3NvY2lhdGVkIHdpdGggT2ZmZXIvQW5zd2VyLg0KDQpSZWdhcmRzLA0KDQpDaHJp c3RlciANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1tdXNpYyBbbWFpbHRv Om1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBLeXppdmF0DQpTZW50 OiAyNSBGZWJydWFyeSAyMDE2IDAwOjU0DQpUbzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW01NVVNJQ10gT2ZmZXIvQW5zd2VyIFBUIFF1ZXN0aW9ucw0KDQpPbiAyLzI0LzE2IDU6MTMg UE0sIERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgd3JvdGU6DQo+IEluIGRlY2xhcmF0aXZlIHVz YWdlIGEgc2Vzc2lvbiBzdGlsbCBleGlzdHMgKGl0IGlzIHN0aWxsIHRoZSBzZXNzaW9uIGRlc2Ny aXB0aW9uIHByb3RvY29sLCBhbmQgdGhlIHNlc3Npb24gYW5ub3VuY2VtZW50IHByb3RvY29sKSBh bmQgdGhlcmVmb3JlIHRoZXJlIG11c3QgYmUgYSBzZXQgb2YgcnVsZXMgZm9yIHRoZSByZXVzZSBv ciBub24tcmV1c2Ugb2YgcGF5bG9hZCB0eXBlcy4NCj4NCj4gQWxsIEkgYW0gc2F5aW5nIGlzIHRo YXQgd2UgbXVzdCBub3QgZ2V0IGNhcnJpZWQgd2F5IGFuZCBkZWZpbmVkIGEgc2V0IG9mIHJ1bGVz IHRoYXQgYXJlIGluY29uc2lzdGVudCBiZXR3ZWVuIHRoZSB0d28uIFJhdGhlciBvbmUgc2hvdWxk IGJlIGEgc3Vic2V0IG9mIHRoZSBvdGhlci4NCg0KSSBoYXZlIG5ldmVyIHRyaWVkIHRvIHVuZGVy c3RhbmQgdGhlIGRlY2xhcmF0aXZlIHVzZSAob3RoZXIgdGhhbiBpbiBPUFRJT05TLCB3aGljaCBj bGVhcmx5ICppc24ndCogZGVzY3JpYmluZyBhIHNlc3Npb24uKSBJdCBpcyBteSBpbXByZXNzaW9u IHRoYXQgU0FQIGhhc24ndCBiZWVuIHVzZWQgZm9yIGEgdmVyeSBsb25nIHRpbWUuDQoNCklmIHNv bWVib2R5IHdobyB1bmRlcnN0YW5kcyBhbmQgY2FyZXMgYWJvdXQgaXQgd291bGQgbGlrZSB0byBo ZWxwIHRoZW4gbWF5YmUgd2UgY2FuIHNlZSB0aGF0IHdlIGRvbid0IGJyZWFrIHRoYXQuDQoNCglU aGFua3MsDQoJUGF1bA0KDQoNCj4gS2VpdGgNCj4NCj4NCj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRVhUIFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0 QGFsdW0ubWl0LmVkdV0NCj4gU2VudDogMjMgRmVicnVhcnkgMjAxNiAxNTozNw0KPiBUbzogRHJh Z2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgRVhUIENvbGluIFBlcmtpbnM7IFJvbWFuIFNocG91bnQN Cj4gQ2M6IG1tdXNpY0BpZXRmLm9yZzsgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gU3ViamVjdDogUmU6 IFtNTVVTSUNdIE9mZmVyL0Fuc3dlciBQVCBRdWVzdGlvbnMNCj4NCj4gT24gMi8yMy8xNiA3OjA0 IEFNLCBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpIHdyb3RlOg0KPj4gSSBhZ3JlZSB0aGF0IGhl cmUgd2UgYXJlIGRpc2N1c3Npbmcgb2ZmZXIgLyBhbnN3ZXIsIGJ1dCB3ZSBtdXN0IGFsc28gDQo+ PiByZW1lbWJlciB0aGF0IGFueSBydWxlcyBtdXN0IGJlIGNvbnNpc3RlbnQgd2l0aCBkZWNsYXJh dGl2ZSB1c2FnZXMgb2YgU0RQLg0KPj4NCj4+IEl0IG1heSBhbHNvIGJlIHRoYXQgc29tZSBvZiB0 aG9zZSBkZWNsYXJhdGl2ZSBydWxlcyBhcmUgYWxzbyANCj4+IGluaGVyaXRlZCBieSBvZmZlciBh bnN3ZXIsIHN1Y2ggYXMgdGhlIGFuc3dlciB0byB0aGUgcXVlc3Rpb24gYXMgdG8gDQo+PiB3aGV0 aGVyIHRoZSByZXF1aXJlbWVudCB0byByZW1lbWJlciBwYXlsb2FkIHR5cGUgdXNhZ2UgKGFuZCB3 aGV0aGVyIA0KPj4gdGhhbiBhcHBsaWVzIHRvIGJvdGggb2ZmZXJzIGFuZCBhbnN3ZXJzLCBvciBp bmRlcGVuZGVudGx5IHRvIGVhY2gpLg0KPg0KPiBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBwb2lu dC4gSVNUTSB0aGF0IG5vbmUgb2YgdGhpcyBkaXNjdXNzaW9uIGlzIHJlbGV2YW50IHRvIGRlY2xh cmF0aXZlIHVzYWdlIC0gd2h5IHNob3VsZCB0aGVyZSBldmVyIGJlIGFueSBuZWVkIHRvIHJldGFp biBoaXN0b3J5IG9yIHJlbWFpbiBjb25zaXN0ZW50IHdpdGggaXQgaW4gdGhlIGRlY2xhcmF0aXZl IGNhc2U/DQo+DQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+DQo+PiBSZWdhcmRzDQo+Pg0KPj4gS2Vp dGgNCj4+DQo+PiAqRnJvbToqbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd ICpPbiBCZWhhbGYgT2YgKkVYVCANCj4+IENvbGluIFBlcmtpbnMNCj4+ICpTZW50OiogMjMgRmVi cnVhcnkgMjAxNiAxMDoyOQ0KPj4gKlRvOiogUm9tYW4gU2hwb3VudA0KPj4gKkNjOiogbW11c2lj QGlldGYub3JnOyBQYXVsIEt5eml2YXQ7IENocmlzdGVyIEhvbG1iZXJnDQo+PiAqU3ViamVjdDoq IFJlOiBbTU1VU0lDXSBPZmZlci9BbnN3ZXIgUFQgUXVlc3Rpb25zDQo+Pg0KPj4gICAgICBPbiAy MiBGZWIgMjAxNiwgYXQgMTk6NTIsIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tDQo+ PiAgICAgIDxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCj4+DQo+PiDigKYNCj4+ DQo+PiBPbmUgdGhpbmcgdGhhdCBib3RoZXJlZCBtZSBoZXJlIGlzIHRoYXQgUFQgY2Fubm90IGJl IHJldXNlZCBmb3IgdGhlIA0KPj4gZHVyYXRpb24gb2YgdGhlIHNlc3Npb24uIEl0IGlzIHByb2Jh Ymx5IHNhZmUgdG8gcmV1c2UgdGhlIFBUIGFmdGVyIA0KPj4gc2Vzc2lvbiBtb2RpZmljYXRpb24g aWYgUFQgaXMgbm8gbG9uZ2VyIHVzZWQuIEkgYWx3YXlzIGZlbHQgdGhhdCANCj4+IGR5bmFtaWMg UFQgcmV1c2UgY3JpdGVyaWEgd2VyZSBtdWNoIHN0cmljdGVyIHRoZW4gcmVhbGlzdGljYWxseSBw b3NzaWJsZSBvciBuZWVkZWQuDQo+Pg0KPj4g4oCmDQo+Pg0KPj4gSSB0aGluayB0aGUgbW9zdCBp bXBvcnRhbnQgY3JpdGVyaWEgaGVyZSBpcyB0aGF0IHRoZXJlIHNob3VsZCBiZSBubyANCj4+IGFt YmlndWl0eSByZWdhcmRpbmcgaG93IGFuIFJUUCBwYWNrZXQgd2l0aCBwYXJ0aWN1bGFyIFBUIHNo b3VsZCBiZSANCj4+IGRlY29kZWQuIElmIGl0IGlzIGd1YXJhbnRlZWQgdGhhdCB0aGVyZSBhcmUg bm8gcGFja2V0cyBzZW50IGJldHdlZW4gDQo+PiBBbGljZSBhbmQgQm9iIHdpdGggUFQgMTExIG92 ZXIgc29tZSByZWFzb25hYmxlIHRpbWUgaW50ZXJ2YWwgKGNvdXBsZSANCj4+IG9mIG5ldHdvcmsg cm91bmQgdHJpcCB0aW1lcyksIHRoZW4gUFQgMTExIGNhbiBiZSBzYWZlbHkgcmV1c2VkLiBJZiwg DQo+PiBpbiB0aGlzIHNjZW5hcmlvIEJvYidzIGVuZCBwb2ludCBrbm93cyB0aGF0IGl0IHdhcyBu b3Qgc2VuZGluZyANCj4+IGFueXRoaW5nIHdpdGggcGF5bG9hZCAxMTEgcmVjZW50bHksIHRoZW4g aXQgY2FuIHNhZmVseSByZXVzZSB0aGlzIHBheWxvYWQuDQo+PiBBbGljZSBjb3VsZCBub3QgYmUg c2VuZGluZyBhbnl0aGluZyB3aXRoIHBheWxvYWQgMTExIHNpbmNlIEJvYiBkaWQgDQo+PiBub3Qg YWNjZXB0IGl0IHByZXZpb3VzbHkuIE9uIHRoZSBvdGhlciBoYW5kLCBCb2IgbXVzdCBub3QgcmV1 c2UgUFQgDQo+PiAxMDAgZm9yLCBsZXQncyBzYXksIENOLCBzaW5jZSB0aGVyZSBhcmUgcGFja2V0 cyB3aXRoIHRoaXMgcGF5bG9hZCBpbiANCj4+IGZsaWdodCBhbmQgdGhpcyB3aWxsIGNyZWF0ZSBk ZWNvZGluZyBhbWJpZ3VpdHkuIFRvIGNvbmNsdWRlLCBhbiBlbmQgDQo+PiBwb2ludCBzaG91bGQg YmUgYWJsZSB0byBzYWZlbHkgcmV1c2UgYW55IFBUIHRoYXQgaXQgaXMgbm90IGN1cnJlbnRseSAN Cj4+IGFjY2VwdGluZyBvciB3YXMgbm90IHNlbmRpbmcgb3IgYWNjZXB0aW5nIGZvciBhdCBsZWFz dCBhIGZldyBuZXR3b3JrIHJvdW5kIHRyaXAgaW50ZXJ2YWxzLg0KPj4NCj4+IE5vIG9iamVjdGlv biBpbiBwcmluY2lwbGUsIGJ1dCBpdOKAmXMgbm90IGFzIHNpbXBsZSBhcyDigJxhIGZldyBuZXR3 b3JrIFJUVHPigJ06DQo+Pg0KPj4gTm8gYW1iaWd1aXR5IGluIGRlY29kaW5nIG1lYW5zIHRoYXQg dGhlIHBhY2tldHMgbmVlZCB0byBoYXZlIGJlZW4gDQo+PiBwbGF5ZWQgb3V0LCBzbyB0aGUgY29k ZWMgc3RhdGUgZm9yIHRoYXQgUFQgY2FuIGJlIGRpc2NhcmRlZC4gU29tZSANCj4+IHN5c3RlbXMg Y2FuIGhhdmUgbGFyZ2UgKG11bHRpLXNlY29uZCkgcGxheW91dCBidWZmZXJzLg0KPj4NCj4+IEFu eSBwYWNrZXRzIHJlZmVycmluZyB0byB0aGUgb2xkIFBUIGFsc28gbmVlZCB0byBiZSBnb25lLiBG b3JtYXRzIA0KPj4gbGlrZSBSRkMgNjM1NCBhbGxvdyBsYXJnZSBvZmZzZXRzIGJldHdlZW4gc3Ry ZWFtcywgcmVmZXJlbmNlZCBieSBQVCANCj4+ICh0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIDUgaGFz IGEgNS4xIHNlY29uZCBvZmZzZXQpLg0KPj4NCj4+IC0tDQo+Pg0KPj4gQ29saW4gUGVya2lucw0K Pj4NCj4+IGh0dHBzOi8vY3NwZXJraW5zLm9yZy8NCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4g bW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW11c2ljDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo= From nobody Thu Feb 25 02: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 A6A571A6F67 for ; Thu, 25 Feb 2016 02:58:05 -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 O_RPBp8_u0HG for ; Thu, 25 Feb 2016 02:58:03 -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 E9DCE1A90CE for ; Thu, 25 Feb 2016 02:57:33 -0800 (PST) X-AuditID: c1b4fb30-f79f66d000000729-af-56cec45a0424 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.E1.01833.A54CEC65; Thu, 25 Feb 2016 10:07:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 10:07:38 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75iggAA8gYCAADDekIACZK0AgACy7bCAAMFzgIAAUWfNgAYA1QCAADZUAA== Date: Thu, 25 Feb 2016 09:07:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E40FC1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E24284@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E40FC1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7vW70kXNhBvNeM1lMXf6YxWLFhgOs FteWv2a1mHFhKrMDi8ff9x+YPBZsKvVYsuQnk8etKQUBLFFcNimpOZllqUX6dglcGZuut7EV vKqt2L3kCVsD446qLkZODgkBE4k9Xz+xQdhiEhfurQeyuTiEBA4zShw49JoFwlnMKNE/6wlQ hoODTcBCovufNkiDiICmxOTJzawgNrNAkUTTgs0sILawgIPEnidb2SFqHCXmrDgHNlREYBmj xOLvm1hB5rAIqEpcPCUIUsMr4Cvx4kYjI8Su45wSa2/8AhvKKRAosXzdbiYQmxHouu+n1jBB LBOXuPVkPhPE1QISS/acZ4awRSVePv7HCmErSTQueQJ1XL7EpxXnWSCWCUqcnPmEZQKj6Cwk o2YhKZuFpGwW0KnMQH+u36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFSbnpRkZ6qUWZ ycXF+Xl6eaklmxiBMXlwy2+DHYwvnzseYhTgYFTi4d3w92yYEGtiWXFl7iFGCQ5mJRFey73n woR4UxIrq1KL8uOLSnNSiw8xSnOwKInzrnZeHyYkkJ5YkpqdmlqQWgSTZeLglGpg9M47X/r/ wPwnm/I3/4lqmvTaoLyuizOXsTj/YWS/u6nW8ddJdz1rCoNvVj0/90k0xbM7Uo7f6sqHtbvO zF1q62z1ZOJ6pvhfAl0JXUvNT3nrrWbnUmjP3uCUcenil6jiqVZlujWNjr/P7mLwcjeesSxH 3FhRw+tSikKSx3J3v7PMv5mNTr1VYinOSDTUYi4qTgQAzMdHs8UCAAA= Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 25 Feb 2016 10:58:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E40FC1ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGV0ZXIsDQoNCkkgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0yNykgb2YgQlVORExFIGEg ZmV3IGRheXMgYWdvLiBDb3VsZCB5b3UgdGFrZSBhIGxvb2sgYXQgdGhlIElDRSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uLCBhbmQgc2F5IHdoZXRoZXIgeW91IGFyZSBvayB3aXRoIHRoZSB0ZXh0Pw0K DQpUaGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFBldGVyIFRoYXRjaGVy IFttYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb21dDQpTZW50OiAyNSBGZWJydWFyeSAyMDE2IDA4 OjUzDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4NCkNjOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT47IG1tdXNpY0BpZXRmLm9y ZzsgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW01N VVNJQ10gUXVlc3Rpb25zIGFib3V0IElDRSBjYW5kaWRhdGVzIHdpdGggQlVORExFDQoNClRoYXQg bWFrZXMgc2Vuc2UgdG8gbWUuDQoNCk9uIFN1biwgRmViIDIxLCAyMDE2IGF0IDI6MTIgQU0sIENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgUm9tYW4sDQoNCkkgZGlk bid0IGNoZWNrIHdoZXRoZXIgc29tZSBvZiB0aGUgSUNFIGF0dHJpYnV0ZXMgd2VyZSBzZXNzaW9u LWxldmVsLCBidXQgSSBhZ3JlZSB3aXRoIHdoYXQgeW91IHNheTogdGhlIHNhbWUgcnVsZSBzaG91 bGQgYXBwbHkgdG8gYWxsIG1lZGlhLWxldmVsIElDRSBhdHRyaWJ1dGVzLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IFJvbWFuIFNocG91bnQ8bWFpbHRvOnJvbWFuQHRlbHVy aXguY29tPg0KU2VudDog4oCOMjEv4oCOMDIv4oCOMjAxNiAwODoyMQ0KVG86IENocmlzdGVyIEhv bG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogUGV0ZXIg VGhhdGNoZXI8bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPjsgbW11c2ljQGlldGYub3JnPG1h aWx0bzptbXVzaWNAaWV0Zi5vcmc+OyBQYXVsIEt5eml2YXQ8bWFpbHRvOnBreXppdmF0QGFsdW0u bWl0LmVkdT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBRdWVzdGlvbnMgYWJvdXQgSUNFIGNhbmRp ZGF0ZXMgd2l0aCBCVU5ETEUNCk9uIFNhdCwgRmViIDIwLCAyMDE2IGF0IDEyOjU3IFBNLCBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+IENvcnJlY3QsIGFuZCB0aGF0 J3Mgb25lIHJlYXNvbiBJIHN1Z2dlc3QgdGhhdCB3ZSBsaW1pdCB0aGUgc2NvcGUgdG8gSUNFLCBl dmVudGhvdWdoIHdlIHByb2JhYmx5DQo+PiBjb3VsZCBkbyB0aGUgc2FtZSB0aGluZyBmb3IgYW55 IElERU5USUNBTCBhbmQgVFJBTlNQT1JUIGNhdGVnb3J5IGF0dHJpYnV0ZS4NCj4NCuKAiz4gV2hp bGUgaXQgd291bGQgYmUgbmljZSB0byByZW1vdmUgYW55IGR1cGxpY2F0aW9uLCB0aGUgZHVwbGlj YXRpb24gaXMgcGFydGljdWxhcmx5IHBhaW5mdWwgZm9yIElDRSBjYW5kaWRhdGVzLCBiZWNhdXNl DQo+IHRoZXJlIGNhbiBiZSBhIGxvdCBvZiB0aGVtLCBhbmQgYmVjYXVzZSB0aGV5IGNoYW5nZSB3 aXRob3V0IGFueSBvZmZlci9hbnN3ZXIgYWN0aW9uICh0aGFua3MgdG8gdHJpY2tsZSBJQ0UpLiDi gIsNCj4gU28gaWYgd2UganVzdCBjb3ZlcmVkIHRoYXQgY2FuZGlkYXRlcywgd2UnZCBiZSBnZXR0 aW5nIG1vc3Qgb2YgdGhlIHZhbHVlLg0KDQpBc3N1bWluZyB0aGUgc2NvcGUgaXMgSUNFLCBzaG91 bGRuJ3QgdGhlIHNhbWUgc3RpbGwgYXBwbHkgYWxzbyB0byBvdGhlciBJQ0UgcmVsYXRlZCBhdHRy aWJ1dGVzPyBJIGFzc3VtZSB0aGUgdmFsdWVzIGZvciB0aGUgInJlbW90ZS1jYW5kaWRhdGVzIiwg ICJpY2UtbGl0ZSIsICJpY2UtbWlzbWF0Y2giLCAiaWNlLXVmcmFnIiwgImljZS1wd2QiLCAiaWNl LXBhY2luZyIgYW5kICJpY2Utb3B0aW9ucyIgYXR0cmlidXRlcyB3aWxsIGJlIGlkZW50aWNhbCB3 aXRoaW4gYSBCVU5ETEUgZ3JvdXAsIHNvLi4uDQoNCiJpY2UtbGl0ZSIgYW5kICJpY2Utb3B0aW9u cyIgYXJlIHNlc3Npb24gbGV2ZWwgb25seSBjYW5kaWRhdGVzLCBzbyB0aGV5IHNob3VsZCBub3Qg YmUgaW4gdGhlIG09IGxpbmUgQlVORExFIG9yIGFueSBvdGhlciB0eXBlLiBUaGUgc2FtZSBsb2dp YyB0aGF0IGFwcGxpZXMgdG8gSUNlIGNhbmRpZGF0ZXMgc2hvdWxkIGFwcGx5IHRvIG90aGVyIG1l ZGlhIGxldmVsIElDRSBTRFAgYXR0cmlidXRlcyBvciB0aGluZ3Mgd2lsbCBicmVhaw0KDQpSZWdh cmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37E40FC1ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkg UGV0ZXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHN1Ym1pdHRl ZCBhIG5ldyB2ZXJzaW9uICgtMjcpIG9mIEJVTkRMRSBhIGZldyBkYXlzIGFnby4gQ291bGQgeW91 IHRha2UgYSBsb29rIGF0IHRoZSBJQ0UgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgYW5kIHNheSB3 aGV0aGVyDQogeW91IGFyZSBvayB3aXRoIHRoZSB0ZXh0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUGV0ZXIgVGhhdGNo ZXIgW21haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNSBG ZWJydWFyeSAyMDE2IDA4OjUzPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9tYW4g U2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7OyBtbXVzaWNAaWV0Zi5vcmc7IFBhdWwg S3l6aXZhdCAmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW01NVVNJQ10gUXVlc3Rpb25zIGFib3V0IElDRSBjYW5kaWRhdGVzIHdpdGggQlVORExF PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCBt YWtlcyBzZW5zZSB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgRmViIDIxLCAyMDE2IGF0IDI6MTIgQU0sIENo cmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBSb21hbiw8 YnI+DQo8YnI+DQpJIGRpZG4ndCBjaGVjayB3aGV0aGVyIHNvbWUgb2YgdGhlIElDRSBhdHRyaWJ1 dGVzIHdlcmUgc2Vzc2lvbi1sZXZlbCwgYnV0IEkgYWdyZWUgd2l0aCB3aGF0IHlvdSBzYXk6IHRo ZSBzYW1lIHJ1bGUgc2hvdWxkIGFwcGx5IHRvIGFsbCBtZWRpYS1sZXZlbCBJQ0UgYXR0cmlidXRl cy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2Vu dCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9 InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNl bnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PlJvbWFuIFNocG91bnQ8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAjjIxL+KAjjAyL+KAjjIwMTYgMDg6MjE8L3Nw YW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5DaHJpc3RlciBIb2xtYmVyZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5DYzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpw dGhhdGNoZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlBldGVyIFRoYXRjaGVyPC9hPjsN CjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJn ZXQ9Il9ibGFuayI+DQpQYXVsIEt5eml2YXQ8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+U3ViamVjdDogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmU6IFtNTVVTSUNd IFF1ZXN0aW9ucyBhYm91dCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEJVTkRMRTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgRmViIDIwLCAyMDE2IGF0IDEy OjU3IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsgQ29ycmVj dCwgYW5kIHRoYXQncyBvbmUgcmVhc29uIEkgc3VnZ2VzdCB0aGF0IHdlIGxpbWl0IHRoZSBzY29w ZSB0byBJQ0UsIGV2ZW50aG91Z2ggd2UgcHJvYmFibHk8YnI+DQomZ3Q7Jmd0OyBjb3VsZCBkbyB0 aGUgc2FtZSB0aGluZyBmb3IgYW55IElERU5USUNBTCBhbmQgVFJBTlNQT1JUIGNhdGVnb3J5IGF0 dHJpYnV0ZS48YnI+DQomZ3Q7PGJyPg0K4oCLJmd0OyBXaGlsZSBpdCB3b3VsZCBiZSBuaWNlIHRv IHJlbW92ZSBhbnkgZHVwbGljYXRpb24sIHRoZSBkdXBsaWNhdGlvbiBpcyBwYXJ0aWN1bGFybHkg cGFpbmZ1bCBmb3IgSUNFIGNhbmRpZGF0ZXMsIGJlY2F1c2U8YnI+DQomZ3Q7IHRoZXJlIGNhbiBi ZSBhIGxvdCBvZiB0aGVtLCBhbmQgYmVjYXVzZSB0aGV5IGNoYW5nZSB3aXRob3V0IGFueSBvZmZl ci9hbnN3ZXIgYWN0aW9uICh0aGFua3MgdG8gdHJpY2tsZSBJQ0UpLiDigIsgJm5ic3A7PGJyPg0K Jmd0OyBTbyBpZiB3ZSBqdXN0IGNvdmVyZWQgdGhhdCBjYW5kaWRhdGVzLCB3ZSdkIGJlIGdldHRp bmcgbW9zdCBvZiB0aGUgdmFsdWUuPGJyPg0KJm5ic3A7PGJyPg0KQXNzdW1pbmcgdGhlIHNjb3Bl IGlzIElDRSwgc2hvdWxkbid0IHRoZSBzYW1lIHN0aWxsIGFwcGx5IGFsc28gdG8gb3RoZXIgSUNF IHJlbGF0ZWQgYXR0cmlidXRlcz8gSSBhc3N1bWUgdGhlIHZhbHVlcyBmb3IgdGhlICZxdW90O3Jl bW90ZS1jYW5kaWRhdGVzJnF1b3Q7LCZuYnNwOyAmcXVvdDtpY2UtbGl0ZSZxdW90OywgJnF1b3Q7 aWNlLW1pc21hdGNoJnF1b3Q7LCAmcXVvdDtpY2UtdWZyYWcmcXVvdDssICZxdW90O2ljZS1wd2Qm cXVvdDssICZxdW90O2ljZS1wYWNpbmcmcXVvdDsgYW5kICZxdW90O2ljZS1vcHRpb25zJnF1b3Q7 IGF0dHJpYnV0ZXMgd2lsbCBiZSBpZGVudGljYWwNCiB3aXRoaW4gYSBCVU5ETEUgZ3JvdXAsIHNv Li4uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mcXVvdDtpY2UtbGl0ZSZxdW90OyBhbmQgJnF1b3Q7aWNlLW9wdGlvbnMmcXVvdDsg YXJlIHNlc3Npb24gbGV2ZWwgb25seSBjYW5kaWRhdGVzLCBzbyB0aGV5IHNob3VsZCBub3QgYmUg aW4gdGhlIG09IGxpbmUgQlVORExFIG9yIGFueSBvdGhlciB0eXBlLiBUaGUgc2FtZSBsb2dpYyB0 aGF0IGFwcGxpZXMgdG8gSUNlIGNhbmRpZGF0ZXMgc2hvdWxkIGFwcGx5IHRvIG90aGVyIG1lZGlh IGxldmVsIElDRSBTRFAgYXR0cmlidXRlcyBvciB0aGluZ3MNCiB3aWxsIGJyZWFrPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37E40FC1ESESSMB209erics_-- From nobody Thu Feb 25 06:17: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 316E11ACD8D for ; Thu, 25 Feb 2016 06:17:36 -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 iYiTv5A1soMX for ; Thu, 25 Feb 2016 06:17:34 -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 9A8CC1ACE42 for ; Thu, 25 Feb 2016 06:17:32 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-8a-56cf0cfa2865 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2D.E3.15637.AFC0FC65; Thu, 25 Feb 2016 15:17:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 15:17:12 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813w== Date: Thu, 25 Feb 2016 14:17:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E425AB@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM2J7lO4vnvNhBr23lSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO5jExgL7vFVLHq0i7GBcQ1fFyMnh4SAicTxTc1MELaYxIV7 69m6GLk4hAQOM0o0vP/EBOEsZpSY/n4BSxcjBwebgIVE9z9tkAYRAXWJr3t7mEFsYQF7ienP HjNBxB0kbm/9xQ5h60l0NW1gBLFZBFQlttz5wAYyhlfAV+LFD7AwI9De76fWgLUyC4hL3Hoy H+oeAYkle84zQ9iiEi8f/2OFsJUk1h7eDnYNs4CmxPpd+hCtihJTuh+CbeUVEJQ4OfMJywRG 4VlIps5C6JiFpGMWko4FjCyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKD++CW36o7GC+/ cTzEKMDBqMTDu+Hv2TAh1sSy4srcQ4wSHMxKIrzyXOfDhHhTEiurUovy44tKc1KLDzFKc7Ao ifOucV4fJiSQnliSmp2aWpBaBJNl4uCUamAMOfXvYdemJ6sKHf8qrZ+aHJYxZfm5l1kf2U/c jlDeLiskfufRxBVsWiXFC9Q8vgZZr5ftNGbRkW9fLLbKQ5JNYcN9zbTpd/MEo4+wczy0SBZp CVRiqip0WMb2d5d3lNO76x8yOzg2lqziLbszq5DRfUlGcXSFucovo8UfIo4dV5q4c+3Bwjwl luKMREMt5qLiRAAQ3vF2agIAAA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 14:17:36 -0000 SGksDQoNCkkgcHV0IHRvZ2V0aGVyIHNvbWUgdGV4dDoNCg0KIlRoZSBzY29wZSBvZiBhIG1hcHBp bmcgZnJvbSBhIHBhcnRpY3VsYXIgZHluYW1pYyBwYXlsb2FkIHR5cGUgbnVtYmVyIHRvIGEgY29k ZWMgDQoob3IgY29kZWMgY29uZmlndXJhdGlvbikgaXMgZm9yIGEgZ2l2ZW4gUlRQIG1lZGlhIGZs b3cgZGlyZWN0aW9uIHdpdGhpbiBhIHNlc3Npb24uIA0KVGhlIHNhbWUgZHluYW1pYyBwYXlsb2Fk IHR5cGUgbnVtYmVyIGNhbiBiZSBtYXBwZWQgdG8gYW5vdGhlciBjb2RlYyBpbiBhbm90aGVyIFJU UCANCm1lZGlhIGZsb3cgZGlyZWN0aW9uIHdpdGhpbiB0aGUgc2FtZSBzZXNzaW9uLiBUaGUgbWFw cGluZyBNVVNUIE5PVCBjaGFuZ2UgdG8gYSBkaWZmZXJlbnQNCmNvZGVkIChvciBjb2RlZCBjb25m aWd1cmF0aW9uKSBmb3IgdGhlIGR1cmF0aW9uIG9mIGEgc2Vzc2lvbi4gRXZlbnRob3VnaCBub3Qg cmVjb21tZW5kZWQsIA0KZm9yIGEgZ2l2ZW4gZGlyZWN0aW9uLCBtdWx0aXBsZSBkeW5hbWljIHBh eWxvYWQgdHlwZSBudW1iZXJzIGNhbiBiZSBtYXBwZWQgdG8gdGhlIA0Kc2FtZSBjb2RlYyAob3Ig Y29kZWMgY29uZmlndXJhdGlvbikuIA0KDQpOb3RlIHRoYXQgYSBtYXBwaW5nIGhhcyBiZWVuIGNy ZWF0ZWQgb25jZSBhbiBlbmRwb2ludA0KaGFzIHNlbnQgYW5kIG9mZmVyIG9yIGFuc3dlciwgZGVz Y3JpYmluZyB0aGUgbWFwcGluZyBmb3IgYSBnaXZlbiBkaXJlY3Rpb24uIEV2ZW4gaWYgdGhlDQpv ZmZlciBvciBhbnN3ZXIgaXMgcmVqZWN0ZWQgb3IgZGlzY2FyZGVkLCBvciBpZiBSVFAgbWVkaWEg YXNzb2NpYXRlZCB3aXRoIHRoZSBtYXBwaW5nIGlzIG5ldmVyDQpzZW50LCB0aGUgbWFwcGluZyBN VVNUIE5PVCBjaGFuZ2UgZm9yIHRoZSBnaXZlbiBkaXJlY3Rpb24gd2l0aGluIHRoZSBzZXNzaW9u Lg0KDQpXaXRoaW4gYW4gb2ZmZXIgb3IgYW5zd2VyLCB0aGUgbWFwcGluZyBpcyBmb3IgdGhlIFJU UCBtZWRpYSBmbG93IGRpcmVjdGlvbiB0b3dhcmRzIHRoZSBvZmZlcmVyL2Fuc3dlcmVyLA0KdW5s ZXNzIHRoZSBtZWRpYSBmbG93IGlzIGluZGljYXRlZCBhcyAnc2VuZG9ubHknIGluIHdoaWNoIGNh c2UgdGhlIG1hcHBpbmcgaXMgZm9yIHRoZSBtZWRpYSBmbG93IGRpcmVjdGlvbg0KZnJvbSB0aGUg b2ZmZXJlci9hbnN3ZXJlci4iDQoNCk5vdGUgdGhhdCB0aGUgdGV4dCBwcm9iYWJseSBuZWVkcyBz b21lIGZpbmUgdHVuaW5nLCBidXQgcGxlYXNlIHRha2UgYSBsb29rIGFuZCBzZWUgd2hldGhlciB5 b3UgYXJlIG9rIHdpdGggdGhlIGFwcHJvYWNoLCBhbmQgd2hldGhlciB5b3UgdGhpbmsgdGhlIHRl eHQgY292ZXJzIHRoZSBpc3N1ZXMgd2UndmUgZGlzY292ZXJlZC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0K From nobody Thu Feb 25 06:29:20 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 6F4F71ACE71 for ; Thu, 25 Feb 2016 06:29:19 -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 2tHLTjpLrifQ for ; Thu, 25 Feb 2016 06:29:16 -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 33D221ACEB3 for ; Thu, 25 Feb 2016 06:29:16 -0800 (PST) X-AuditID: c1b4fb30-f79ec6d000002212-49-56cf0fba6529 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.28.08722.ABF0FC65; Thu, 25 Feb 2016 15:29:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 15:29:14 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAAq3CQ Date: Thu, 25 Feb 2016 14:29:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E436B1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E425AB@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7lu4u/vNhBvtuy1lMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGccbelgKNghV7Hzzkq2B8QlfFyMnh4SAicSdy3fZIGwxiQv3 1gPZXBxCAocZJea07mSBcBYzSqz7eRgow8HBJmAh0f1PG6RBREBd4uveHmYQW1jAXmL6s8dM EHEHidtbf7FD2EYSZ/a+ZQGxWQRUJf60rwer4RXwlfj4eBpYXAjI3t/yngVkPKeAn8TeWYIg YUage76fWgNWziwgLnHryXwmiDsFJJbsOc8MYYtKvHz8jxXCVpJYe3g7C0S9jsSC3Z/YIGxt iWULXzNDrBWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp 5aWWbGIERsTBLb8NdjC+fO54iFGAg1GJh3fD37NhQqyJZcWVuYcYJTiYlUR45bnOhwnxpiRW VqUW5ccXleakFh9ilOZgURLnXe28PkxIID2xJDU7NbUgtQgmy8TBKdXAWJRu3s/fsEqjconN RwWXd58P1nVJlxeFFid0dE2fy1JVsf/Pjmo9yQ6lup0dsmmTps9S47pYzOOeK8T63sPw4Z0/ XGmWJ13eGm4pC1Kr2LfXovDn1yQv75+vjk/fp39iawDv9TU3ub6cqtWX2nUoMaWuSUTK8ja7 /N8T92rZ5ujYvTmYmN+oxFKckWioxVxUnAgAwMOzaoQCAAA= Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 14:29:19 -0000 And, just to clarify: the idea is that this text would update the existing = text in Section 8.3.2 of RFC 3264 says the following: "However, in the case of RTP, the mapping from a particular dynamic payl= oad type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session."=20 -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 25 February 2016 16:17 To: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal Hi, I put together some text: "The scope of a mapping from a particular dynamic payload type number to a = codec (or codec configuration) is for a given RTP media flow direction with= in a session.=20 The same dynamic payload type number can be mapped to another codec in anot= her RTP media flow direction within the same session. The mapping MUST NOT = change to a different coded (or coded configuration) for the duration of a = session. Eventhough not recommended, for a given direction, multiple dynami= c payload type numbers can be mapped to the same codec (or codec configurat= ion).=20 Note that a mapping has been created once an endpoint has sent and offer or= answer, describing the mapping for a given direction. Even if the offer or= answer is rejected or discarded, or if RTP media associated with the mappi= ng is never sent, the mapping MUST NOT change for the given direction withi= n the session. Within an offer or answer, the mapping is for the RTP media flow direction = towards the offerer/answerer, unless the media flow is indicated as 'sendon= ly' in which case the mapping is for the media flow direction from the offe= rer/answerer." Note that the text probably needs some fine tuning, but please take a look = and see whether you are ok with the approach, and whether you think the tex= t covers the issues we've discovered. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Feb 25 06:45: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 667B61AD0CB for ; Thu, 25 Feb 2016 06:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 du9waBoeW2ZH for ; Thu, 25 Feb 2016 06:45:41 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 89AC91AD0C5 for ; Thu, 25 Feb 2016 06:45:41 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DC7668B5B4925; Thu, 25 Feb 2016 14:45:33 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1PEjXMV018285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Feb 2016 14:45:35 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1PEj3kb029163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Feb 2016 15:45:32 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.33]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 25 Feb 2016 15:45:14 +0100 From: "Schwarz, Albrecht (Nokia - DE)" To: EXT Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAAq3CQAAA8G+A= Date: Thu, 25 Feb 2016 14:45:13 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1ACE19D2B87@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E436B1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E436B1@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 14:45:43 -0000 Comment to used RTP terminology: Should be tightly coupled to RFC 7656 in my understanding. We got know an a= greed RTP terminology with that RFC. Replacements in text: =3D> "session" =3D "RTP session" (RFC 7656, =A7 2.2.2) =3D> "media stream" =3D "(media) source stream" (RFC 7656, =A7 2.1.5) ??? With regards to notion "RTP media flow direction": =3D "RTP media flow" is identified by the 2-tuple {SSRC, PT}, i.e. represen= ts a subflow component of an "RTP stream" (given by SSRC; RFC 7656, =A7 2.1= .10) If this is the aimed semantic of an RTP media flow, then attribute "directi= on" might be obsolete because an "RTP stream" is inherently unidirectional = (from RTP source towards RTP sink). Regards, Albrecht -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christer Hol= mberg Sent: Donnerstag, 25. Februar 2016 15:29 To: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal And, just to clarify: the idea is that this text would update the existing = text in Section 8.3.2 of RFC 3264 says the following: "However, in the case of RTP, the mapping from a particular dynamic payl= oad type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session."=20 -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 25 February 2016 16:17 To: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal Hi, I put together some text: "The scope of a mapping from a particular dynamic payload type number to a = codec (or codec configuration) is for a given RTP media flow direction with= in a session.=20 The same dynamic payload type number can be mapped to another codec in anot= her RTP media flow direction within the same session. The mapping MUST NOT = change to a different coded (or coded configuration) for the duration of a = session. Eventhough not recommended, for a given direction, multiple dynami= c payload type numbers can be mapped to the same codec (or codec configurat= ion).=20 Note that a mapping has been created once an endpoint has sent and offer or= answer, describing the mapping for a given direction. Even if the offer or= answer is rejected or discarded, or if RTP media associated with the mappi= ng is never sent, the mapping MUST NOT change for the given direction withi= n the session. Within an offer or answer, the mapping is for the RTP media flow direction = towards the offerer/answerer, unless the media flow is indicated as 'sendon= ly' in which case the mapping is for the media flow direction from the offe= rer/answerer." Note that the text probably needs some fine tuning, but please take a look = and see whether you are ok with the approach, and whether you think the tex= t covers the issues we've discovered. 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 Thu Feb 25 07:10: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 1D5AA1B2A12 for ; Thu, 25 Feb 2016 07:10:32 -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 9XabEcB1oi5S for ; Thu, 25 Feb 2016 07:10:30 -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 BA0121B2A0B for ; Thu, 25 Feb 2016 07:10:29 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-5c-56cf1961b1d4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.5D.15637.1691FC65; Thu, 25 Feb 2016 16:10:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 16:10:25 +0100 From: Christer Holmberg To: "Schwarz, Albrecht (Nokia - DE)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAAq3CQAAA8G+AAATC+MA== Date: Thu, 25 Feb 2016 15:10:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E43893@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E436B1@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19D2B87@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACE19D2B87@FR711WXCHMBA03.zeu.alcatel-lucent.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7qG6i5Pkwg+4nmhYfz/cwW0xd/pjF gcljyZKfTB53b11iCmCK4rJJSc3JLEst0rdL4MrY/WoCa8EluYr575ezNTD+lOhi5OSQEDCR +N24kgXCFpO4cG89WxcjF4eQwGFGic3bOlkgnMWMEv+2PwByODjYBCwkuv9pgzSICGRIrNpz jRXEFhawl5j+7DETRNxB4vbWX+wQtpPE3UPvwGwWAVWJK53TwGxeAV+JLx1fWSHmP2GU2Hj8 NCPIfE6BWIn/l/JAahiBDvp+ag3YTGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQtpLEiu2X GCHq9SRuTJ3CBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk3 3chYL7UoM7m4OD9PLy+1ZBMjME4ObvmtuoPx8hvHQ4wCHIxKPLwb/p4NE2JNLCuuzD3EKMHB rCTCKyp0PkyINyWxsiq1KD++qDQntfgQozQHi5I47xrn9WFCAumJJanZqakFqUUwWSYOTqkG Rv2pHG4LAv4UMpUtq/LbpC2m9mjuCbfFMmwT0+9u5fJdVHhP4cm5VfXzGiWEF0zaqLrlEV/r r60Rn9vqZ3646FcjJKi2R2iG1U9F84ebhGXknZeUHL07dZX2/7ldW1k33Ph3Ucdo/8xTS8Mn Nc6++fW6Qsa/4q3+bw0ddRjTznHlB726dV+Vq0WJpTgj0VCLuag4EQD1a7MNjwIAAA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 15:10:32 -0000 Hi Albrecht, Thanks for the input. We also need to look at what terminology is used else= where in 3264. I didn't check that when writing the text. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Nokia - DE) [mailto:albrecht.schwarz@nokia.com]=20 Sent: 25 February 2016 16:45 To: Christer Holmberg ; mmusic@ietf.org Subject: RE: [MMUSIC] Offer/Answer PT Questions - text proposal Comment to used RTP terminology: Should be tightly coupled to RFC 7656 in my understanding. We got know an a= greed RTP terminology with that RFC. Replacements in text: =3D> "session" =3D "RTP session" (RFC 7656, =A7 2.2.2) =3D> "media stream" = =3D "(media) source stream" (RFC 7656, =A7 2.1.5) ??? With regards to notion "RTP media flow direction": =3D "RTP media flow" is identified by the 2-tuple {SSRC, PT}, i.e. represen= ts a subflow component of an "RTP stream" (given by SSRC; RFC 7656, =A7 2.1= .10) If this is the aimed semantic of an RTP media flow, then attribute "di= rection" might be obsolete because an "RTP stream" is inherently unidirecti= onal (from RTP source towards RTP sink). Regards, Albrecht -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christer Hol= mberg Sent: Donnerstag, 25. Februar 2016 15:29 To: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal And, just to clarify: the idea is that this text would update the existing = text in Section 8.3.2 of RFC 3264 says the following: "However, in the case of RTP, the mapping from a particular dynamic payl= oad type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session."=20 -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 25 February 2016 16:17 To: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal Hi, I put together some text: "The scope of a mapping from a particular dynamic payload type number to a = codec (or codec configuration) is for a given RTP media flow direction with= in a session.=20 The same dynamic payload type number can be mapped to another codec in anot= her RTP media flow direction within the same session. The mapping MUST NOT = change to a different coded (or coded configuration) for the duration of a = session. Eventhough not recommended, for a given direction, multiple dynami= c payload type numbers can be mapped to the same codec (or codec configurat= ion).=20 Note that a mapping has been created once an endpoint has sent and offer or= answer, describing the mapping for a given direction. Even if the offer or= answer is rejected or discarded, or if RTP media associated with the mappi= ng is never sent, the mapping MUST NOT change for the given direction withi= n the session. Within an offer or answer, the mapping is for the RTP media flow direction = towards the offerer/answerer, unless the media flow is indicated as 'sendon= ly' in which case the mapping is for the media flow direction from the offe= rer/answerer." Note that the text probably needs some fine tuning, but please take a look = and see whether you are ok with the approach, and whether you think the tex= t covers the issues we've discovered. 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 Thu Feb 25 07:41: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 C66C11B2B07 for ; Thu, 25 Feb 2016 07:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 QvRVzDlkvRC7 for ; Thu, 25 Feb 2016 07:41:26 -0800 (PST) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F415C1B2ABC for ; Thu, 25 Feb 2016 07:41:25 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1PFfKWM018560; Thu, 25 Feb 2016 10:41:20 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 214cqcvwvk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Feb 2016 10:41:19 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 25 Feb 2016 09:41:19 -0600 From: Jonathan Lennox To: Martin Thomson Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRb0MX6bWTp5bg6UyLiWt52o6bVp88DisAgAAH8ACAAAnHAIAABB4AgAEoAAA= Date: Thu, 25 Feb 2016 15:41:18 +0000 Message-ID: <0EF1AF5F-3AB7-4251-A2C7-C3EF423E917E@vidyo.com> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-25_05:2016-02-25,2016-02-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602250221 Archived-At: Cc: mmusic , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 15:41:26 -0000 SSBjYW4gY2VydGFpbmx5IGFncmVlIHRoYXQgNDU3MiBjb3VsZCB1c2UgYW4gdXBkYXRlLiBJIGRp ZG7igJl0IGNvbXBsZXRlbHkgdW5kZXJzdGFuZCB3aGF0IEkgd2FzIGRvaW5nIHdoZW4gSSB3cm90 ZSBpdDsgaW4gcGFydGljdWxhciwgdGhlIGlkZWEgdGhhdCB0aGUgY2VydGlmaWNhdGUgd2FzIGp1 c3QgYSByZXBvc2l0b3J5IGZvciB0aGUgcHVibGljIGtleSB3YXNu4oCZdCBzb21ldGhpbmcgSSBo YWQgY29tcGxldGVseSBncmFzcGVkLCBhbmQgdGhlIGhhc2ggYWdpbGl0eSB3YXMgY29uZnVzZWQu DQoNCj4gT24gRmViIDI0LCAyMDE2LCBhdCA1OjAxIFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDI0IEZlYnJ1YXJ5IDIwMTYgYXQg MTM6NDcsIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4+IElm IHdlIGFyZSBnb2luZyB0byBtYWtlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIG11bHRpcGxlIGZp bmdlcnByaW50cyB3ZQ0KPj4gbmVlZCBzb21lIHBsYWNlIGF1dGhvcml0YXRpdmUgdG8gcmVmZXJl bmNlIGZvciB0aGUgZGV0YWlscy4NCj4gDQo+IEkgcmVjb21tZW5kIGp1ZGljaW91cyB1c2Ugb2Yg Y29weSBhbmQgcGFzdGUuICBGZWVsIGZyZWUgdG8gc3RlYWwgdGV4dA0KPiB0aGF0IEkgd3JvdGUu DQo+IA0KPiBGV0lXLCBteSByZWFkaW5nIG9mIDQ1NzIgaXMgdGhhdCBpdCBwZXJtaXRzIG11bHRp cGxlIGZpbmdlcnByaW50czogb25lDQo+IGZvciBlYWNoIGNlcnRpZmljYXRlIHRoYXQgbWlnaHQg YmUgdXNlZC4gIEl0cyBmYWlsaW5nIGlzIHRoYXQgYSkgaXQNCj4gZG9lc24ndCBhbGxvdyBmb3Ig aGFzaCBhZ2lsaXR5LCBhbmQgYikgaXQncyB1bmNsZWFyLCBwZXJoYXBzIGluIHRoZQ0KPiBleHRy ZW1lLg0KPiANCj4gSG93ZXZlciwgSSBzZWUgdGhpczoNCj4gDQo+ICAgRW5kcG9pbnRzIE1VU1Qg c3VwcG9ydCBTSEEtMjU2IGZvciBnZW5lcmF0aW5nIGFuZCB2ZXJpZnlpbmcgdGhlDQo+ICAgZmlu Z2VycHJpbnQgdmFsdWUgYXNzb2NpYXRlZCB3aXRoIHRoZSBEVExTIGFzc29jaWF0aW9uLiAgVGhl IHVzZSBvZg0KPiAgIFNIQS0yNTYgaXMgcHJlZmVycmVkLg0KPiANCj4gV2hpY2ggZG9lc24ndCBt ZW50aW9uIHRoYXQgdGhpcyByZXF1aXJlcyBhbiB1cGRhdGUgb2YgNDU3Mi4NCj4gDQo+IEFuZCB0 aGlzOg0KPiANCj4gICBUaGUgY2VydGlmaWNhdGUgcmVjZWl2ZWQgZHVyaW5nIHRoZSBEVExTIGhh bmRzaGFrZSBNVVNUIG1hdGNoIHRoZQ0KPiAgIGZpbmdlcnByaW50IHJlY2VpdmVkIGluIHRoZSBT RFAgImZpbmdlcnByaW50IiBhdHRyaWJ1dGUuDQo+IA0KPiBXaGljaCBzaG91bGQgc2F5ICcqYSog ZmluZ2VycHJpbnQnLCB0byBhbGxvdyBmb3IgdGhlcmUgYmVpbmcgbXVsdGlwbGUuDQo+IA0KPiBB bmQgdGhpczoNCj4gDQo+ICAgWy4uLl0gIEluIGFkZGl0aW9uLCB0aGUgb2ZmZXJlcg0KPiAgIE1V U1QgaW5zZXJ0IGFuIFNEUCAnc2V0dXAnIGF0dHJpYnV0ZSBhY2NvcmRpbmcgdG8gdGhlIHByb2Nl ZHVyZXMgaW4NCj4gICBbUkZDNDE0NV0sIGFuZCBhbiBTRFAgJ2ZpbmdlcnByaW50JyBhdHRyaWJ1 dGUgYWNjb3JkaW5nIHRvIHRoZQ0KPiAgIHByb2NlZHVyZXMgaW4gW1JGQzQ1NzJdLCBpbiB0aGUg b2ZmZXIuDQo+IA0KPiBXaGljaCBkb2Vzbid0IGRlYWwgd2l0aCBtdWx0aXBsZSBjZXJ0aWZpY2F0 ZXMuDQo+IA0KPiBJIGFsc28gc2VlOg0KPiANCj4gICBUaGUNCj4gICBzdWJqZWN0QWx0TmFtZSBp cyBub3QgYW4gaW1wb3J0YW50IGNvbXBvbmVudCBvZiB0aGUgY2VydGlmaWNhdGUNCj4gICB2ZXJp ZmljYXRpb24uDQo+IA0KPiBXaGljaCBpcyB0cnVlIGJ1dCBpbnN1ZmZpY2llbnQ7IHRoZSB0ZXh0 IGNhbiBzaW1wbHkgc2F5IHRoYXQgdGhlDQo+IGNlcnRpZmljYXRlIGlzIG9ubHkgYSByZWNlcHRh Y2xlIGZvciBhIHB1YmxpYyBrZXkgYW5kIGF1dGhlbnRpY2F0aW9uDQo+IGlzIHRpZWQgdG8gYW4g YT1maW5nZXJwcmludCBsaW5lIGluIHRoZSBTRFAuDQo+IA0KPiBBbmQgdGhpczoNCj4gDQo+ICAg VGhpcyBvZmZlciBpbmNsdWRlcywgYXMgcGFydCBvZiB0aGUgU0RQIHBheWxvYWQsIHRoZSBmaW5n ZXJwcmludCBvZg0KPiAgIHRoZSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBlbmRwb2ludCB3YW50cyB0 byB1c2UuICBUaGUgZW5kcG9pbnQgU0hPVUxEDQo+IA0KPiBXaGljaCBzaG91bGQgYmUgcGx1cmFs IGZpbmdlcnByaW50KnMqLg0KPiANCj4gVGhlIHBhdHRlcm4gcmVwZWF0cyB0aHJvdWdob3V0Lg0K DQo= From nobody Thu Feb 25 09:36:22 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 7A7C71B2EB9 for ; Thu, 25 Feb 2016 09:36:20 -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 HoYg0jzhpsQ4 for ; Thu, 25 Feb 2016 09:36:19 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9AE1B2ED8 for ; Thu, 25 Feb 2016 09:36:15 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with comcast id Nhbk1s0022XD5SV01hcEY3; Thu, 25 Feb 2016 17:36:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id NhcD1s00K3KdFy101hcDog; Thu, 25 Feb 2016 17:36:14 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CF3BD9.7080307@alum.mit.edu> Date: Thu, 25 Feb 2016 12:37:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E425AB@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=1456421774; bh=A0/jhlT+YGZPehuWqFMrKGI12G7Ixv1i1GA6WqB5K1U=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kfhoKJOEGAO+CQ9DLlXm82hz7jWWhHjxX5nmXcfkzQJmcmcpbi5TC4x/WnL8KuQKb /Tx0uiqOSd1ueYneC+lfq8ylpzn0XKBdhXxcdaxavJnhre+JQdBB7gdZTvMtF73H3N IUnu1sgLkG7rgolqtE75vWB3PqeXSEho1+BO+xbnNw6sggYaTe9TMBLu4Lv+r1QGjV iJMYrB2h0kCRmIMC3zdMFlJJq1sA6w3yoLusI5HT1iw/Td1AnJY59WteygMEMfkZEF /ZdEedSwS2QImsukw8ROINfK35x1VzGwPUysvN3CmmPvHqumrBgxKaJMPqpyIrSF8U B8LcXI9Pcv9gQ== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 17:36:20 -0000 On 2/25/16 9:17 AM, Christer Holmberg wrote: > Hi, > > I put together some text: > > "The scope of a mapping from a particular dynamic payload type number to a codec > (or codec configuration) is for a given RTP media flow direction within a session. Albrecht raised the question of terminology and of whether "RTP media flow direction" is the right term. I think the concept is specific to O/A. In 7656 terms I think it applies to all RTP streams with a particular PT flowing in a single direction between two participants in one RTP Session. > The same dynamic payload type number can be mapped to another codec in another RTP > media flow direction within the same session. The mapping MUST NOT change to a different > coded (or coded configuration) for the duration of a session. Eventhough not recommended, > for a given direction, multiple dynamic payload type numbers can be mapped to the > same codec (or codec configuration). > > Note that a mapping has been created once an endpoint > has sent and offer or answer, describing the mapping for a given direction. Even if the > offer or answer is rejected or discarded, or if RTP media associated with the mapping is never > sent, the mapping MUST NOT change for the given direction within the session. The paragraph above seems overly strict. Surely it should not be necessary to retain the mapping if the entire offer is rejected. (There isn't any way to reject an answer.) Similarly, if the m-line is rejected (port zero) ISTM that all bindings could be forgotten. (I guess in this case the RTP Session ends so "within the session" covers it.) > Within an offer or answer, the mapping is for the RTP media flow direction towards the offerer/answerer, > unless the media flow is indicated as 'sendonly' in which case the mapping is for the media flow direction > from the offerer/answerer." ISTM that no bindings should be created for sendonly m-lines. (AFAIK the PT mentioned in a sendonly offer/answer never appears on the wire in RTP/RTCP.) OTOH, as a session is modified (by additional O/As), bindings need to be retained even if sendonly is sometimes used. Thanks, Paul > Note that the text probably needs some fine tuning, but please take a look and see whether you are ok with the approach, and whether you think the text covers the issues we've discovered. > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Feb 25 10:12: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 0DE801B2F64 for ; Thu, 25 Feb 2016 10:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 YxMPmswfBgI2 for ; Thu, 25 Feb 2016 10:12:29 -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 EECD41B2F6B for ; Thu, 25 Feb 2016 10:12:13 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id l127so96738655iof.3 for ; Thu, 25 Feb 2016 10:12:13 -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; bh=xQrjJGPJdFwWbhqX2oJ1kUpK/E61yXW3kwtp7yRxbIY=; b=eJbWxmLc6SqFUJzhXdz58sXQen6QNbjMksJgbDDlK1KcQDfenT7jwtHCIWgPju/Lz/ GviqvtYbb16huoBne3D/wM1zDwv6HX+LCyiVzvZ6qz7uMi6yT6QPmle6ZYLtzB358CEb /TJL8Pw9Sblf8CU6j6ugqdD7ROpgTJmqeoJP7fOXFqZwjVgMo7OdJx5nCp7CJNQomTST EPXApaUFjzLMd7K7xoBNwbeb9URDIB9dOKQrracTRaszD886thLzD8103Q5MvPpLDXUf a4Hnt2EeFEks9nHWiH5n6S7UvtVw/PGBNkkn3MpRINJySsXuVukXsi7vebmtsyzBEPPc n5iA== 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; bh=xQrjJGPJdFwWbhqX2oJ1kUpK/E61yXW3kwtp7yRxbIY=; b=NmZ+JKTfMpfyU7H+iqIXi2VbJ8xeCuYRor2Aa8nWmUjlv7eID6VRpVpF80eUkbTGmI 224Xl918I5GH8bTYk9IbVVVA5ZK5f37zE9Ga4+M2j0Y2Q0gxl11hj1UtQF3lVtI4O6to 094Y+hrQG1IDnPcqBnxlarPhhWtXd62I8xwfVhW21KvqW2j+WZd4CSqLSy/ETPZRuuEW HuBElgTzLb9F8RTXFnw46Oqq+1j81PtcO3YNCacqok+2r/eMp9nuEGGnq0d5clpXtVt8 L5UB2EviHDo+D7nr5hMxzqC0jVG58aJntHXK2QRDaIHsAy9HH18VEw86VIl/S+uSJAH0 qfRw== X-Gm-Message-State: AG10YORAuNMhayQ0GgvnJyo6zTmmjmSyGilDEClS6BtizNNzj3YRtlZd8oOIlHX6SyVFQA== X-Received: by 10.107.135.156 with SMTP id r28mr4366115ioi.40.1456423933420; Thu, 25 Feb 2016 10:12:13 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id f14sm3677891ioi.20.2016.02.25.10.12.11 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 10:12:12 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id xg9so18730492igb.1 for ; Thu, 25 Feb 2016 10:12:11 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr54828igh.2.1456423931238; Thu, 25 Feb 2016 10:12:11 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 10:12:11 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 13:12:11 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bdca2ec106660052c9c1fcd Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 18:12:30 -0000 --047d7bdca2ec106660052c9c1fcd Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 9:17 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > "The scope of a mapping from a particular dynamic payload type number to a > codec > (or codec configuration) is for a given RTP media flow direction within a > session. > The same dynamic payload type number can be mapped to another codec in > another RTP > media flow direction within the same session. The mapping MUST NOT change > to a different > coded (or coded configuration) for the duration of a session. Eventhough > not recommended, > for a given direction, multiple dynamic payload type numbers can be mapped > to the > same codec (or codec configuration). > I think MUST NOT is too strict for this rule and SHOULD NOT should be sufficient. In current implementation this rule is often ignored. The worst thing that can happen is a small media disruption, but with the careful implementation, even that will not occur in most use cases. _____________ Roman Shpount --047d7bdca2ec106660052c9c1fcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 25, 2016 at 9:1= 7 AM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
"The scope of a mapping from a pa= rticular dynamic payload type number to a codec
(or codec configuration) is for a given RTP media flow direction within a s= ession.
The same dynamic payload type number can be mapped to another codec in anot= her RTP
media flow direction within the same session. The mapping MUST NOT change t= o a different
coded (or coded configuration) for the duration of a session. Eventhough no= t recommended,
for a given direction, multiple dynamic payload type numbers can be mapped = to the
same codec (or codec configuration).

I = think MUST NOT is too strict for this rule and SHOULD NOT should be suffici= ent. In current implementation this rule is often ignored. The worst thing = that can happen is a small media disruption, but with the careful implement= ation, even that will not occur in most use cases.
_____________
Roman Shpount
=C2=A0
--047d7bdca2ec106660052c9c1fcd-- From nobody Thu Feb 25 10:23: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 798D91B2F44 for ; Thu, 25 Feb 2016 10:23:42 -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 R3W5OZCPV38o for ; Thu, 25 Feb 2016 10:23:41 -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 C6FDC1B3061 for ; Thu, 25 Feb 2016 10:23:37 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-14-56cf46a71dfd Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.47.20792.7A64FC65; Thu, 25 Feb 2016 19:23:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 19:23:35 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAGXyWAAAJjojA= Date: Thu, 25 Feb 2016 18:23:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E44148@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdQne52/kwg0/fDC2mLn/MYjHjwlRm ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAldGz+wJbwT7uip2XNzA1MM7g7mLk5JAQMJGY +W46C4QtJnHh3nq2LkYuDiGBw4wS8+8vgHIWM0qs/HkTyOHgYBOwkOj+pw3SICKgKvH3+2Qm kDCzgLrE1cVBIGFhAXuJ6c8eM0GUOEjc3vqLHcK2kpiw5AgbiM0C1Hrn/Wowm1fAV2LKjatg 9UICUxglJrUEgozkFAiUmHUzEyTMCHTa91NrwEqYBcQlbj2ZzwRxsoDEkj3nmSFsUYmXj/+x QthKEmsPb2eBuExTYv0ufYhWRYkp3Q/ZIbYKSpyc+YRlAqPYLCRTZyF0zELSMQtJxwJGllWM osWpxcW56UZGeqlFmcnFxfl5enmpJZsYgVFzcMtvqx2MB587HmIU4GBU4uHd8PdsmBBrYllx Ze4hRgkOZiUR3otG58OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ865xXh8mJJCeWJKanZpakFoE k2Xi4JRqYKystvPgme/rnCbw6NKt1vDwBOflzivfhFZGJwgoNEZzZPyaZhnBsyBuxr8YFo0J rN0smqJPddfX/z67oaflYML5K3s7xcyqN7hxiq1imfxkodwmlsdte5f3bt/yW2/S4w8ldyZM fX72JtevSPOix6aeX+6fesiY4/ls7+VCxQkRxw9tlt27wFaJpTgj0VCLuag4EQADc8/KlgIA AA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 18:23:42 -0000 SGksDQoNCj4+IlRoZSBzY29wZSBvZiBhIG1hcHBpbmcgZnJvbSBhIHBhcnRpY3VsYXIgZHluYW1p YyBwYXlsb2FkIHR5cGUgbnVtYmVyIHRvIGEgY29kZWMNCj4+KG9yIGNvZGVjIGNvbmZpZ3VyYXRp b24pIGlzIGZvciBhIGdpdmVuIFJUUCBtZWRpYSBmbG93IGRpcmVjdGlvbiB3aXRoaW4gYSBzZXNz aW9uLg0KPj5UaGUgc2FtZSBkeW5hbWljIHBheWxvYWQgdHlwZSBudW1iZXIgY2FuIGJlIG1hcHBl ZCB0byBhbm90aGVyIGNvZGVjIGluIGFub3RoZXIgUlRQDQo+Pm1lZGlhIGZsb3cgZGlyZWN0aW9u IHdpdGhpbiB0aGUgc2FtZSBzZXNzaW9uLiBUaGUgbWFwcGluZyBNVVNUIE5PVCBjaGFuZ2UgdG8g YSBkaWZmZXJlbnQNCj4+Y29kZWQgKG9yIGNvZGVkIGNvbmZpZ3VyYXRpb24pIGZvciB0aGUgZHVy YXRpb24gb2YgYSBzZXNzaW9uLiBFdmVudGhvdWdoIG5vdCByZWNvbW1lbmRlZCwNCj4+Zm9yIGEg Z2l2ZW4gZGlyZWN0aW9uLCBtdWx0aXBsZSBkeW5hbWljIHBheWxvYWQgdHlwZSBudW1iZXJzIGNh biBiZSBtYXBwZWQgdG8gdGhlDQo+PnNhbWUgY29kZWMgKG9yIGNvZGVjIGNvbmZpZ3VyYXRpb24p Lg0KPg0KPiBJIHRoaW5rIE1VU1QgTk9UIGlzIHRvbyBzdHJpY3QgZm9yIHRoaXMgcnVsZSBhbmQg U0hPVUxEIE5PVCBzaG91bGQgYmUgc3VmZmljaWVudC4gSW4gY3VycmVudCBpbXBsZW1lbnRhdGlv biB0aGlzIA0KPiBydWxlIGlzIG9mdGVuIGlnbm9yZWQuIFRoZSB3b3JzdCB0aGluZyB0aGF0IGNh biBoYXBwZW4gaXMgYSBzbWFsbCBtZWRpYSBkaXNydXB0aW9uLCBidXQgd2l0aCB0aGUgY2FyZWZ1 bCANCj4gaW1wbGVtZW50YXRpb24sIGV2ZW4gdGhhdCB3aWxsIG5vdCBvY2N1ciBpbiBtb3N0IHVz ZSBjYXNlcy4NCg0KVGhlcmUgbWF5IGFsc28gYmUgaW1wbGVtZW50YXRpb25zIHRoYXQgRE8gaW1w bGVtZW50IHRoZSBydWxlLiBTSE9VTEQgTk9UIG1lYW5zIHRoYXQgZW5kcG9pbnRzIGhhdmUgdG8g YmUgcHJlcGFyZWQgdG8gaGFuZGxlIGl0Lg0KDQpJcyB0aGVyZSByZWFsbHkgYSByZWFzb24gd2h5 IHdlIHNob3VsZCBhbGxvdyBpdD8gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Thu Feb 25 10:33: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 4C4221B30A7 for ; Thu, 25 Feb 2016 10:33: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, 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 s-lv_VyM6fIq for ; Thu, 25 Feb 2016 10:33:46 -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 0C96E1B30A0 for ; Thu, 25 Feb 2016 10:33:45 -0800 (PST) X-AuditID: c1b4fb30-f79ec6d000002212-a7-56cf4908035d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.D8.08722.8094FC65; Thu, 25 Feb 2016 19:33:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 19:32:37 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAFKOeAAAO6B7A= Date: Thu, 25 Feb 2016 18:32:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4418E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF3BD9.7080307@alum.mit.edu> In-Reply-To: <56CF3BD9.7080307@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+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7mS6H5/kwg0n/hC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujYcZK1oIDUhUTFrk3MM4R7WLk5JAQMJHY dWEpG4QtJnHh3nogm4tDSOAwo8SVdQ3sEM5iRom5d48wdjFycLAJWEh0/9MGaRAR8JV49vg2 WLOwgL3E9GePmSDiDhK3t/5ih7CtJM5/n8QMYrMIqEq8ONPIBDKGF6h37xojkLCQQL7E6SNn WEFsTgEdiSs3/oO1MgLd8/3UGrCRzALiEreezGeCuFNAYsme88wQtqjEy8f/WCFsJYm1h7ez QNTrSCzY/YkNwtaWWLbwNVg9r4CgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk3 3chIL7UoM7m4OD9PLy+1ZBMjMEYObvltsIPx5XPHQ4wCHIxKPLwb/p4NE2JNLCuuzD3EKMHB rCTCe9HofJgQb0piZVVqUX58UWlOavEhRmkOFiVx3tXO68OEBNITS1KzU1MLUotgskwcnFIN jCktYWLbGHITTeNe6exTq9e7rNoa0SLcqKrsP0vk9FTTnAXar27OnW0h5OYrzayqr5lxi/m2 kvme5Uuu161SlGzN/6nUY7SrUDn74aEHj3QTnHvnrEninyG/9sQktesdVi7yzBPFUiv6VIqt +bbMOc5/7kfM+9u3tPtrEzoiu4rbmrUSFRWUWIozEg21mIuKEwGuKLdejQIAAA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 18:33:48 -0000 Hi, >> "The scope of a mapping from a particular dynamic payload type number=20 >> to a codec (or codec configuration) is for a given RTP media flow direct= ion within a session. > > Albrecht raised the question of terminology and of whether "RTP media flo= w direction" is the right term. I think the concept > is specific to O/A. In 7656 terms I think it applies to all RTP streams w= ith a particular PT flowing in a single direction between=20 > two participants in one RTP Session. We need to look whether there is existing terminology in 3264, in which cas= e we should use that (or update every instance of the terminology within 32= 64...) >> The same dynamic payload type number can be mapped to another codec in=20 >> another RTP media flow direction within the same session. The mapping=20 >> MUST NOT change to a different coded (or coded configuration) for the=20 >> duration of a session. Eventhough not recommended, for a given=20 >> direction, multiple dynamic payload type numbers can be mapped to the sa= me codec (or codec configuration). >> >> Note that a mapping has been created once an endpoint has sent and=20 >> offer or answer, describing the mapping for a given direction. Even if=20 >> the offer or answer is rejected or discarded, or if RTP media=20 >> associated with the mapping is never sent, the mapping MUST NOT change f= or the given direction within the session. > > The paragraph above seems overly strict. Surely it should not be necessar= y to retain the mapping if the entire offer is rejected. (There isn't any w= ay to reject an answer.) Sometimes strict is good :) But, I'm not religious about it, as long as the= text is clear on when the mapping has been created. > Similarly, if the m-line is rejected (port zero) ISTM that all bindings c= ould be forgotten. (I guess in this case the RTP Session ends so "within th= e session" covers it.) What if an m- line is disabled, using port zero in an *offer*, and later ta= ken back in use? Are the previous mappings still valid? In my opinion they = are. >> Within an offer or answer, the mapping is for the RTP media flow=20 >> direction towards the offerer/answerer, unless the media flow is=20 >> indicated as 'sendonly' in which case the mapping is for the media flow = direction from the offerer/answerer." > > ISTM that no bindings should be created for sendonly m-lines. (AFAIK the = PT mentioned in a sendonly offer/answer never appears on the wire in > RTP/RTCP.) So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply = with PT 111:PCMU? Both are associated with the same media flow direction, a= s the offer was sendonly. Regards, Christer OTOH, as a session is modified (by additional O/As), bindings need to be re= tained even if sendonly is sometimes used. Thanks, Paul > Note that the text probably needs some fine tuning, but please take a loo= k and see whether you are ok with the approach, and whether you think the t= ext covers the issues we've discovered. > > 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 Thu Feb 25 10:41: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 2E4711B30B7 for ; Thu, 25 Feb 2016 10:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 2pHAnbuKh9ad for ; Thu, 25 Feb 2016 10:41:43 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 B99D91B30EC for ; Thu, 25 Feb 2016 10:41:37 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id g6so21388526igt.1 for ; Thu, 25 Feb 2016 10:41: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; bh=a/RobMxzX9pfysFWTvRBakiBZ4sF//bLpPqfM63LqXM=; b=svrrE+QU5Gps8GD87r8nV5e8HXZl6esUCH+3bn2C+/H0voBG6VLk/BDRWYZ9cKKIlC GbmxrcR6/xaxG80sY8AcSOr/dOngMHjULBC1+2XolbiSdopW7OOa2jyH2LnENSqfhIKT Y1T4XuYxi8Ks9SpdKPtOlyE+Z+0oX0vzichvz8+3e3TE9xP49EOk53Aglzr2tNxeDXRi pidlCPlDnLJp4KLi8BVlustXyuu7D7FF0M5v3KLLqLwEt/D3zq7ThPrDPp1XYfhq5TSA t3DqW2UQ/cu/IV6k7c+g9rXooYzgUBHYGQp0AQp/50iyNCgRootk4NLnvlvlLMlEVlRG zbLw== 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; bh=a/RobMxzX9pfysFWTvRBakiBZ4sF//bLpPqfM63LqXM=; b=jnEpgVLngoxdBF0QvFkbCumUbfQOouLtrL4I2ViUlxn8339VXuFZZfkLT7rioV1MKr GxY0HjKG5AS5BoV3Ye6RnenJ8H/y/k2pQL6Kw9AmR1mzIEW0YIZ6NBRLvse50L//83l3 ONKp8x7LQDT19kXfPY3EICYMzvQj76a8FdXhxcKaadz7p5na5MrKtsb1XkQXFqiU4NEO gm0/teH0DWhXdT6a7V00smqwXE3YAIaFRKBHrXdhPPKZ+S1zGhpGEJjLsMmhoV7uvjTH JSobB1FJv9KzAGfCGW7v1NU83Vfw+eA2QAW54xLan19rZ0Kxx4caOQXPB0DpRsggbdbg eLOg== X-Gm-Message-State: AG10YOTdzaDhfu8TcqQQh8jwzzY9cMa2AhMCcBN96MB4EK5yZ94dOpWL4wpOaC02/c7tGA== X-Received: by 10.50.85.14 with SMTP id d14mr110627igz.49.1456425697096; Thu, 25 Feb 2016 10:41:37 -0800 (PST) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id qt2sm1734179igb.18.2016.02.25.10.41.35 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 10:41:36 -0800 (PST) Received: by mail-io0-f177.google.com with SMTP id l127so97619043iof.3 for ; Thu, 25 Feb 2016 10:41:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr4065172ioe.38.1456425695501; Thu, 25 Feb 2016 10:41:35 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 10:41:35 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E44148@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44148@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 13:41:35 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b47238eb5e052c9c88c4 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 18:41:44 -0000 --001a1140b47238eb5e052c9c88c4 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 1:23 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >>"The scope of a mapping from a particular dynamic payload type number to > a codec > >>(or codec configuration) is for a given RTP media flow direction within > a session. > >>The same dynamic payload type number can be mapped to another codec in > another RTP > >>media flow direction within the same session. The mapping MUST NOT > change to a different > >>coded (or coded configuration) for the duration of a session. Eventhough > not recommended, > >>for a given direction, multiple dynamic payload type numbers can be > mapped to the > >>same codec (or codec configuration). > > > > I think MUST NOT is too strict for this rule and SHOULD NOT should be > sufficient. In current implementation this > > rule is often ignored. The worst thing that can happen is a small media > disruption, but with the careful > > implementation, even that will not occur in most use cases. > > There may also be implementations that DO implement the rule. SHOULD NOT > means that endpoints have to be prepared to handle it. > I guess what I am trying to say is these implementations really should not be enforcing this rule. There is no technical reason for strict enforcement and this will break things during the interop. > Is there really a reason why we should allow it? > It is impossible to implement 3pcc with this rule in place. _____________ Roman Shpount --001a1140b47238eb5e052c9c88c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 25, 2016 at 1:2= 3 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
>>"The sco= pe of a mapping from a particular dynamic payload type number to a codec >>(or codec configuration) is for a given RTP media flow direction wi= thin a session.
>>The same dynamic payload type number can be mapped to another codec= in another RTP
>>media flow direction within the same session. The mapping MUST NOT = change to a different
>>coded (or coded configuration) for the duration of a session. Event= hough not recommended,
>>for a given direction, multiple dynamic payload type numbers can be= mapped to the
>>same codec (or codec configuration).
>
> I think MUST NOT is too strict for this rule and SHOULD NOT should be = sufficient. In current implementation this
> rule is often ignored. The worst thing that can happen is a small medi= a disruption, but with the careful
> implementation, even that will not occur in most use cases.

There may also be implementations that DO implement the rule. SHOULD= NOT means that endpoints have to be prepared to handle it.

I guess what I am trying to say is these implementatio= ns really should not be enforcing this rule. There is no technical reason f= or strict enforcement and this will break things during the interop.
<= div>=C2=A0
Is there really a reason why we should all= ow it?

It is impossible to implement 3p= cc with this rule in place.=C2=A0
= _____________
Roman Shpount
=C2=A0
--001a1140b47238eb5e052c9c88c4-- From nobody Thu Feb 25 10:45: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 E98E91B3110 for ; Thu, 25 Feb 2016 10:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 Jfpb4mv5JISa for ; Thu, 25 Feb 2016 10:45:06 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 E5C0E1B310C for ; Thu, 25 Feb 2016 10:45:05 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id g6so21458530igt.1 for ; Thu, 25 Feb 2016 10:45:05 -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; bh=EIjf/yVXqYW+LJIeaxtDhSAj8txbsJgoZlHGMlfh2so=; b=cglTZSVBHRmXaN3GBkO4OoYle+jhRF730usxb+b9kc8/U5u5QNwIjVUS1tm0WcjMzK SwEx+0FrntcbXAYRCuw+umGUtSOa54ABP95z0d+XOBnEVVkUFQLBga38uW2NryJN4Y/M /gmJFY7u4LaYi1SS1w9xhwbaJQctFccIENG2gQyiGZ4hpqCKCnVIP3bQYnPEHYzppWN6 Vjfhmy40kKplb49a+EWB8FtR0lmsDJTtDPB5271qjXhqPSNj7zIh6pcYf5LVW8wgVyu0 CX571xHj3q69eQAxjqEztVM6rFFYhpZe9HHKfv8KaBn5Zgh/hw/S8t9NcPt/ePU1rPMH UjWQ== 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; bh=EIjf/yVXqYW+LJIeaxtDhSAj8txbsJgoZlHGMlfh2so=; b=j/vyD1SwgbDbFt2xhoIOt1mrCfQMS96dStTbo3sk2rRTy8Co8HpWZ4GYkoiGU5qnp6 //jOxpi2gDCu5w2jnBFfiJwOB1+8JjzgRGiu7ES3BFMxIAPtG1Zh1kF1Ss0kt7+uoZnE GlsJE6Zp+7OSwcGgbDp4cWUNm9TJQhUK0e2CxBV4pMGZXwIeXZbMxMpC1Veide/w+5Mh +MljG5bMX8S90mvh/oBnSuvLl+W9MYw8HyjuOfCfAiZ4ERZ6mRIGetcGtI4gFQBjrrY3 Pbd+zkeYWASUKSZYHGaCLdncf+T8tEnVYdg9n8CfPwHMvkUsEgaibo4wn5powOpoHuzc 7EnA== X-Gm-Message-State: AG10YOSoS4gvcOITtR6gICePS6TeCXWDWKWbnOqXQ0k1WIZhwGz8R9rln/fdMZc9cJ9nhw== X-Received: by 10.50.155.5 with SMTP id vs5mr104860igb.83.1456425905401; Thu, 25 Feb 2016 10:45:05 -0800 (PST) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id qa4sm1759503igb.14.2016.02.25.10.45.03 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 10:45:03 -0800 (PST) Received: by mail-io0-f176.google.com with SMTP id l127so97719270iof.3 for ; Thu, 25 Feb 2016 10:45:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr4077585ioe.38.1456425903379; Thu, 25 Feb 2016 10:45:03 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 10:45:03 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4418E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF3BD9.7080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4418E@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 13:45:03 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b4729cde08052c9c9421 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 18:45:08 -0000 --001a1140b4729cde08052c9c9421 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 1:32 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply > with PT 111:PCMU? Both are associated with the same media flow direction, > as the offer was sendonly. > These PT are not associated with the same flow direction. Each end point lists PTs it is willing to receive. The end point which is sending the sendonly offer has no idea what the other end point is willing to receive and their PT preferences. The PT in sendonly are in the direction to sendonly end point, They are simply placeholders and will not be used. _____________ Roman Shpount --001a1140b4729cde08052c9c9421 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 25, 2016 at 1:32 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
So, I send you a sendonly offer with PT 1= 11:VP8, it is ok for you to reply with PT 111:PCMU? Both are associated wit= h the same media flow direction, as the offer was sendonly.

These PT are not associated with the same flow directi= on. Each end point lists PTs it is willing to receive. The end point which = is sending the sendonly offer has no idea what the other end point is willi= ng to receive and their PT preferences. The PT in sendonly are in the direc= tion to sendonly end point, They are simply placeholders and will not be us= ed.=C2=A0
_____________
Roman S= hpount
=C2=A0
--001a1140b4729cde08052c9c9421-- From nobody Thu Feb 25 10:50:20 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 6CFA71B3148 for ; Thu, 25 Feb 2016 10:50:19 -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 LUQcsnEQwpFW for ; Thu, 25 Feb 2016 10:50:18 -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 E0C3F1B3111 for ; Thu, 25 Feb 2016 10:50:17 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-6f-56cf4ce784f1 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4B.48.15637.7EC4FC65; Thu, 25 Feb 2016 19:50:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 19:50:15 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAGXyWAAAJjojD///UZgP//7SsA Date: Thu, 25 Feb 2016 18:50:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E44253@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44148@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdRfe5z/kwg2kLzC2mLn/MYjHjwlRm ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAldHQtYupoE+g4smBE2wNjDf4uxg5OSQETCR+ rT3LCGGLSVy4t56ti5GLQ0jgMKPEhKkrWCGcxYwSv87dZupi5OBgE7CQ6P6nDdIgIqAq8ff7 ZLAws4C6xNXFQSBhYQF7ienPHjNBlDhI3N76ix3CdpP4vLedFcRmAWq9duknWA2vgK/E/Obr zBCr5jNJ3J22hw0kwSkQKHHuSgtYAyPQcd9PrQFrYBYQl7j1ZD4TxNECEkv2nGeGsEUlXj7+ xwphK0msPbydBeI2TYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F0DELSccsJB0LGFlW MYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgRGzsEtv1V3MF5+43iIUYCDUYmHd8Pfs2FCrIll xZW5hxglOJiVRHjDvM6HCfGmJFZWpRblxxeV5qQWH2KU5mBREudd47w+TEggPbEkNTs1tSC1 CCbLxMEp1cBoqtl5YfYnuzUrph7xc1r2Yk+C4+2YYmP79lfzP5pG3raaULK68F+hwGnnqZ4m 1WKWZ1n7Qu/3TvWp89Ot0Y46zLHMuujMwilV70/W/n2229A/SqBrV+NO5oePw7X9HsRnvJX6 uGtdqSOL5u01F17FLCy6wbLwV6XxwiQnweU7C2U1Pl/TKrupxFKckWioxVxUnAgAqdO1bJgC AAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 18:50:19 -0000 SGksDQoNCj4+PiJUaGUgc2NvcGUgb2YgYSBtYXBwaW5nIGZyb20gYSBwYXJ0aWN1bGFyIGR5bmFt aWMgcGF5bG9hZCB0eXBlIG51bWJlciB0byBhIGNvZGVjDQo+Pj4ob3IgY29kZWMgY29uZmlndXJh dGlvbikgaXMgZm9yIGEgZ2l2ZW4gUlRQIG1lZGlhIGZsb3cgZGlyZWN0aW9uIHdpdGhpbiBhIHNl c3Npb24uDQo+Pj5UaGUgc2FtZSBkeW5hbWljIHBheWxvYWQgdHlwZSBudW1iZXIgY2FuIGJlIG1h cHBlZCB0byBhbm90aGVyIGNvZGVjIGluIGFub3RoZXIgUlRQDQo+Pj5tZWRpYSBmbG93IGRpcmVj dGlvbiB3aXRoaW4gdGhlIHNhbWUgc2Vzc2lvbi4gVGhlIG1hcHBpbmcgTVVTVCBOT1QgY2hhbmdl IHRvIGEgZGlmZmVyZW50DQo+Pj5jb2RlZCAob3IgY29kZWQgY29uZmlndXJhdGlvbikgZm9yIHRo ZSBkdXJhdGlvbiBvZiBhIHNlc3Npb24uIEV2ZW50aG91Z2ggbm90IHJlY29tbWVuZGVkLA0KPj4+ Zm9yIGEgZ2l2ZW4gZGlyZWN0aW9uLCBtdWx0aXBsZSBkeW5hbWljIHBheWxvYWQgdHlwZSBudW1i ZXJzIGNhbiBiZSBtYXBwZWQgdG8gdGhlDQo+Pj5zYW1lIGNvZGVjIChvciBjb2RlYyBjb25maWd1 cmF0aW9uKS4NCj4+Pg0KPj4+IEkgdGhpbmsgTVVTVCBOT1QgaXMgdG9vIHN0cmljdCBmb3IgdGhp cyBydWxlIGFuZCBTSE9VTEQgTk9UIHNob3VsZCBiZSBzdWZmaWNpZW50LiBJbiBjdXJyZW50IGlt cGxlbWVudGF0aW9uIHRoaXMNCj4+PiBydWxlIGlzIG9mdGVuIGlnbm9yZWQuIFRoZSB3b3JzdCB0 aGluZyB0aGF0IGNhbiBoYXBwZW4gaXMgYSBzbWFsbCBtZWRpYSBkaXNydXB0aW9uLCBidXQgd2l0 aCB0aGUgY2FyZWZ1bA0KPj4+IGltcGxlbWVudGF0aW9uLCBldmVuIHRoYXQgd2lsbCBub3Qgb2Nj dXIgaW4gbW9zdCB1c2UgY2FzZXMuDQo+Pg0KPj4gVGhlcmUgbWF5IGFsc28gYmUgaW1wbGVtZW50 YXRpb25zIHRoYXQgRE8gaW1wbGVtZW50IHRoZSBydWxlLiBTSE9VTEQgTk9UIG1lYW5zIHRoYXQg ZW5kcG9pbnRzIGhhdmUgdG8gYmUgcHJlcGFyZWQgdG8gaGFuZGxlIGl0Lg0KPg0KPiBJIGd1ZXNz IHdoYXQgSSBhbSB0cnlpbmcgdG8gc2F5IGlzIHRoZXNlIGltcGxlbWVudGF0aW9ucyByZWFsbHkg c2hvdWxkIG5vdCBiZSBlbmZvcmNpbmcgdGhpcyBydWxlLiBUaGVyZSBpcyBubyB0ZWNobmljYWwg cmVhc29uIGZvciBzdHJpY3QgZW5mb3JjZW1lbnQgYW5kIHRoaXMgd2lsbCBicmVhayB0aGluZ3Mg ZHVyaW5nIHRoZSBpbnRlcm9wLg0KPg0KPj4gSXMgdGhlcmUgcmVhbGx5IGEgcmVhc29uIHdoeSB3 ZSBzaG91bGQgYWxsb3cgaXQ/DQo+DQo+IEl0IGlzIGltcG9zc2libGUgdG8gaW1wbGVtZW50IDNw Y2Mgd2l0aCB0aGlzIHJ1bGUgaW4gcGxhY2UuwqANCg0KSW4gdGhhdCBjYXNlLCBtYXliZSBzaG91 bGQgYWxsb3cgaXQgT05MWSB3aGVuIGFuIGVuZHBvaW50IGRvZXMgbm90IGhhdmUgYW55IGtub3ds ZWRnZSBhYm91dCB0aGUgbWFwcGluZ3MsIGFuZCBnaXZlIDNwY2MgYXMgYW4gZXhhbXBsZS4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Thu Feb 25 10:51:48 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 158CC1B30FD for ; Thu, 25 Feb 2016 10:51:47 -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 u4oL2DFuVHfw for ; Thu, 25 Feb 2016 10:51:46 -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 D0F781B2D00 for ; Thu, 25 Feb 2016 10:51:45 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-1b-56cf4d3f8237 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.68.15637.F3D4FC65; Thu, 25 Feb 2016 19:51:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 19:51:43 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAFKOeAAAO6B7D///UQgP//7YNg Date: Thu, 25 Feb 2016 18:51:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E44296@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF3BD9.7080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4418E@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbE9XNfB93yYwdxVXBZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgy5i60KljHXrHngHgD4xT2 LkZODgkBE4m9zbdZIWwxiQv31rN1MXJxCAkcZpT4eO4nlLOYUeJlyxuWLkYODjYBC4nuf9og DSICqhJ/v09mArGZBXwlXi74wgxiCwvYS0x/9pgJosZB4vbWX+wgrSICbhL3rkWDhFmAWp/P 3McIYvMCtW45ep0JYtUvRokH8yaB9XIKBEp8v/KQBcRmBDru+6k1ULvEJW49mc8EcbSAxJI9 55khbFGJl4//QT2jJLH28Hawk5kFNCXW79KHaFWUmNL9kB1ir6DEyZlPWCYwis1CMnUWQscs JB2zkHQsYGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYSQe3/FbdwXj5jeMhRgEORiUe 3g1/z4YJsSaWFVfmHmKU4GBWEuEN8zofJsSbklhZlVqUH19UmpNafIhRmoNFSZx3jfP6MCGB 9MSS1OzU1ILUIpgsEwenVAOjQcF13Wtn9t55WqL6OId9Q/6fhg1u7U+96nvetMS7TI6YYCjb O22WhVnvk4NfGIKYnNeeyDmowb1SjOXYYfX3/L13bi51OnLpnqntvnR785JVictW74j+t3FV xrUn8v949u2T/rs5+GaHKtO3c3I/1zpk8hzWuWVdrfzB6sHzbTENry2u/lm4WImlOCPRUIu5 qDgRAI5K9zqgAgAA Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 18:51:47 -0000 SGksDQoNCj4+IFNvLCBJIHNlbmQgeW91IGEgc2VuZG9ubHkgb2ZmZXIgd2l0aCBQVCAxMTE6VlA4 LCBpdCBpcyBvayBmb3IgeW91IHRvIHJlcGx5IHdpdGggUFQgMTExOlBDTVU/IEJvdGggYXJlIGFz c29jaWF0ZWQNCj4+IHdpdGggdGhlIHNhbWUgbWVkaWEgZmxvdyBkaXJlY3Rpb24sIGFzIHRoZSBv ZmZlciB3YXMgc2VuZG9ubHkuDQo+DQo+IFRoZXNlIFBUIGFyZSBub3QgYXNzb2NpYXRlZCB3aXRo IHRoZSBzYW1lIGZsb3cgZGlyZWN0aW9uLiBFYWNoIGVuZCBwb2ludCBsaXN0cyBQVHMgaXQgaXMg d2lsbGluZyB0byByZWNlaXZlLiBUaGUgZW5kDQo+IHBvaW50IHdoaWNoIGlzIHNlbmRpbmcgdGhl IHNlbmRvbmx5IG9mZmVyIGhhcyBubyBpZGVhIHdoYXQgdGhlIG90aGVyIGVuZCBwb2ludCBpcyB3 aWxsaW5nIHRvIHJlY2VpdmUgYW5kIHRoZWlyIFBUIA0KPiBwcmVmZXJlbmNlcy4gVGhlIFBUIGlu IHNlbmRvbmx5IGFyZSBpbiB0aGUgZGlyZWN0aW9uIHRvIHNlbmRvbmx5IGVuZCBwb2ludCwgVGhl eSBhcmUgc2ltcGx5IHBsYWNlaG9sZGVycyBhbmQgd2lsbCBub3QgYmUgdXNlZC7CoA0KDQpJZiBz bywgd2Ugc2hvdWxkIGVpdGhlciBleHBsaWNpdGx5IHNwZWNpZnkgaXQsIG9yIHJlZmVyZW5jZSB0 byB3aGVyZSBpdCBpcyBhbHJlYWR5IHNwZWNpZmllZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0K From nobody Thu Feb 25 10:57: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 7E6FF1B3124 for ; Thu, 25 Feb 2016 10:57:13 -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_111=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 puUcVPws5Bd7 for ; Thu, 25 Feb 2016 10:57:11 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 C13F31B3174 for ; Thu, 25 Feb 2016 10:57:11 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id y8so21299961igp.0 for ; Thu, 25 Feb 2016 10:57:11 -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; bh=OvnHL+UARRX5su+lIl9XwS/LHIHYadVXNy7DW/oKOv0=; b=ezaldoQe1zDOgUwjWPrfeMsdP7X2oZltgsY1NmT2C0zzZUtluxxibfUpq3FCgLCsVN tECm6o/wufXCtfDIqaGPHRM5xwUnjSyx3NJvWAu6/Pohk3b5F0LUTZL3WXZO2Kv1KV1T 8IsVssnYm08Wxd7wJozJ/0QMso/Zb3hUVVxrTByC8vK2blg8lMzk+QrjcOvKxGvLlqA7 tsT8R/i1y4EVatqc0F8W34bp7sDIiOosXiCd5y1LYyyuQL2/RuWrUGcOXro7NzYX/N/q 5DE/gf1YfuWTPCX6QY5cQ2+e6AMT1vpp6rEPK4i4YIilNlQHrzpK9O3OL7WjqW1azOSi WTnA== 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; bh=OvnHL+UARRX5su+lIl9XwS/LHIHYadVXNy7DW/oKOv0=; b=F1njDV7LZ5FUycnh8k4L20qQJq8Zu7nIdH1wW8qjiP2ROgJzm1fGX0/f3t/4oZw/JP pUiM3whcRBObBQQkkbSAY5h4Gj5IBRTAyezf/s7zgF68K+aoY17i82hzFSZ9RYHMeWTR xOq4KCMrChaB4HKEYE5FsQyN4jRyWO0rvXrb9L/jBa3nO7kDmiy5bMuI92pNsZ7FcFOJ QS7eWq1yK/8daNXRegiNgvGzhecEx4cNlCmbVIXU55+Yoj7PYb3zmMBH7P7DQcGR41oX miyKOYqLeXj4SM713ygriwCMq3WK/nupqjjQATwt5tPMuSMhkGnluIdbJGSW5pMjF68a pRXQ== X-Gm-Message-State: AG10YORsuKrKDTeaBSGyy/cxVKH9VAteG30NSqWctYtfIx9c4Zarf8revKcoQ6d5DAxMFQ== X-Received: by 10.50.36.37 with SMTP id n5mr226276igj.48.1456426631244; Thu, 25 Feb 2016 10:57:11 -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 vf11sm1758871igb.20.2016.02.25.10.57.08 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 10:57:08 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id z135so99025858iof.0 for ; Thu, 25 Feb 2016 10:57:08 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr4539393iod.145.1456426628091; Thu, 25 Feb 2016 10:57:08 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 10:57:07 -0800 (PST) In-Reply-To: <0EF1AF5F-3AB7-4251-A2C7-C3EF423E917E@vidyo.com> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> <0EF1AF5F-3AB7-4251-A2C7-C3EF423E917E@vidyo.com> Date: Thu, 25 Feb 2016 13:57:07 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a113ece60cf1bb2052c9cbfd8 Archived-At: Cc: mmusic , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 18:57:13 -0000 --001a113ece60cf1bb2052c9cbfd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are two options possible here: 1. Make current draft-ietf-mmusic-dtls-sdp draft update 4572 and cover TLS as well, essentially making it draft-ietf-mmusic-tls-and-dtls-sdp 2. Limit the scope of draft-ietf-mmusic-dtls-sdp to DTLS only. Completely define how setup and fingerprint attributes are used there for DTLS only. Let some future draft update RFC 4572. What is the preference here given that either option will require another major edit for draft-ietf-mmusic-dtls-sdp? Regards, _____________ Roman Shpount On Thu, Feb 25, 2016 at 10:41 AM, Jonathan Lennox wrote: > I can certainly agree that 4572 could use an update. I didn=E2=80=99t com= pletely > understand what I was doing when I wrote it; in particular, the idea that > the certificate was just a repository for the public key wasn=E2=80=99t s= omething I > had completely grasped, and the hash agility was confused. > > > On Feb 24, 2016, at 5:01 PM, Martin Thomson > wrote: > > > > On 24 February 2016 at 13:47, Paul Kyzivat > wrote: > >> If we are going to make normative references to multiple fingerprints = we > >> need some place authoritative to reference for the details. > > > > I recommend judicious use of copy and paste. Feel free to steal text > > that I wrote. > > > > FWIW, my reading of 4572 is that it permits multiple fingerprints: one > > for each certificate that might be used. Its failing is that a) it > > doesn't allow for hash agility, and b) it's unclear, perhaps in the > > extreme. > > > > However, I see this: > > > > Endpoints MUST support SHA-256 for generating and verifying the > > fingerprint value associated with the DTLS association. The use of > > SHA-256 is preferred. > > > > Which doesn't mention that this requires an update of 4572. > > > > And this: > > > > The certificate received during the DTLS handshake MUST match the > > fingerprint received in the SDP "fingerprint" attribute. > > > > Which should say '*a* fingerprint', to allow for there being multiple. > > > > And this: > > > > [...] In addition, the offerer > > MUST insert an SDP 'setup' attribute according to the procedures in > > [RFC4145], and an SDP 'fingerprint' attribute according to the > > procedures in [RFC4572], in the offer. > > > > Which doesn't deal with multiple certificates. > > > > I also see: > > > > The > > subjectAltName is not an important component of the certificate > > verification. > > > > Which is true but insufficient; the text can simply say that the > > certificate is only a receptacle for a public key and authentication > > is tied to an a=3Dfingerprint line in the SDP. > > > > And this: > > > > This offer includes, as part of the SDP payload, the fingerprint of > > the certificate that the endpoint wants to use. The endpoint SHOULD > > > > Which should be plural fingerprint*s*. > > > > The pattern repeats throughout. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113ece60cf1bb2052c9cbfd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There are two options possible here:

1. Make= current draft-ietf-mmusic-dtls-sdp draft update 4572 and cover TLS as well= , essentially making it draft-ietf-mmusic-tls-and-dtls-sdp

2. Limit the scope of draft-ietf-mmusic-dtls-sdp to DTLS only. Completel= y define how setup and fingerprint attributes are used there for DTLS only.= Let some future draft update RFC 4572.

What is th= e preference here given that either option will require another major edit = for draft-ietf-mmusic-dtls-sdp?

Regards,

_____________
Roman Shpount

On Thu, Feb 25, 2016 at 10:41 AM, Jonathan L= ennox <jonathan@vidyo.com> wrote:
I can certainly agree that 4572 could use an update. I didn=E2=80= =99t completely understand what I was doing when I wrote it; in particular,= the idea that the certificate was just a repository for the public key was= n=E2=80=99t something I had completely grasped, and the hash agility was co= nfused.

> On Feb 24, 2016, at 5:01 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> On 24 February 2016 at 13:47, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> If we are going to make normative references to multiple fingerpri= nts we
>> need some place authoritative to reference for the details.
>
> I recommend judicious use of copy and paste.=C2=A0 Feel free to steal = text
> that I wrote.
>
> FWIW, my reading of 4572 is that it permits multiple fingerprints: one=
> for each certificate that might be used.=C2=A0 Its failing is that a) = it
> doesn't allow for hash agility, and b) it's unclear, perhaps i= n the
> extreme.
>
> However, I see this:
>
>=C2=A0 =C2=A0Endpoints MUST support SHA-256 for generating and verifyin= g the
>=C2=A0 =C2=A0fingerprint value associated with the DTLS association.=C2= =A0 The use of
>=C2=A0 =C2=A0SHA-256 is preferred.
>
> Which doesn't mention that this requires an update of 4572.
>
> And this:
>
>=C2=A0 =C2=A0The certificate received during the DTLS handshake MUST ma= tch the
>=C2=A0 =C2=A0fingerprint received in the SDP "fingerprint" at= tribute.
>
> Which should say '*a* fingerprint', to allow for there being m= ultiple.
>
> And this:
>
>=C2=A0 =C2=A0[...]=C2=A0 In addition, the offerer
>=C2=A0 =C2=A0MUST insert an SDP 'setup' attribute according to = the procedures in
>=C2=A0 =C2=A0[RFC4145], and an SDP 'fingerprint' attribute acco= rding to the
>=C2=A0 =C2=A0procedures in [RFC4572], in the offer.
>
> Which doesn't deal with multiple certificates.
>
> I also see:
>
>=C2=A0 =C2=A0The
>=C2=A0 =C2=A0subjectAltName is not an important component of the certif= icate
>=C2=A0 =C2=A0verification.
>
> Which is true but insufficient; the text can simply say that the
> certificate is only a receptacle for a public key and authentication > is tied to an a=3Dfingerprint line in the SDP.
>
> And this:
>
>=C2=A0 =C2=A0This offer includes, as part of the SDP payload, the finge= rprint of
>=C2=A0 =C2=A0the certificate that the endpoint wants to use.=C2=A0 The = endpoint SHOULD
>
> Which should be plural fingerprint*s*.
>
> The pattern repeats throughout.

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

--001a113ece60cf1bb2052c9cbfd8-- From nobody Thu Feb 25 11:00: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 8C7981B319F for ; Thu, 25 Feb 2016 11:00:32 -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_111=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 uZjAurxcaTMq for ; Thu, 25 Feb 2016 11:00:30 -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 64A8F1B31A4 for ; Thu, 25 Feb 2016 11:00:22 -0800 (PST) X-AuditID: c1b4fb30-f79ec6d000002212-78-56cf4f447bdb Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F7.DA.08722.44F4FC65; Thu, 25 Feb 2016 20:00:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 19:59:09 +0100 From: Christer Holmberg To: Roman Shpount , Jonathan Lennox Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsP//9/iAgAASgkD///dgAIAACcgAgAAEHgCAASf+AIAANraAgAARRXA= Date: Thu, 25 Feb 2016 18:59:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E442FF@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> <0EF1AF5F-3AB7-4251-A2C7-C3EF423E917E@vidyo.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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E442FFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7ma6L//kwgylftCz2Lz7PbHHtzD9G i6nLH7NYrNhwgNVixoWpzA6sHn/ff2Dy2DnrLrvHkiU/mTxuTSnwaHt2hz2ANYrLJiU1J7Ms tUjfLoEr48HnFuaCZY2MFbuWrGFrYHxR28XIySEhYCLxYOZ+NghbTOLCvfVANheHkMBhRomn fSdZIJzFjBI/lnxm7GLk4GATsJDo/qcN0iAi4C1xZmcvM4jNLFAoMfntPkYQW1jAXuLf/Q9s EDUOEptuXGMEmSMi0MUo8WTbZnaQBIuAqsTUi2vBmnkFfCV2ndnLDLHsKavE8Z2Xwbo5BQIl HjYuB2tgBDrv+6k1TBDbxCVuPZnPBHG2gMSSPeeZIWxRiZeP/7FC2EoSaw9vZwE5mlkgX+LB ngiIXYISJ2c+YZnAKDoLyaRZCFWzkFRBhDUl1u/Sh6hWlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG 0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwEg9uOW3wQ7Gl88dDzEKcDAq8fBu+Hs2TIg1say4 MvcQowQHs5IIb5jX+TAh3pTEyqrUovz4otKc1OJDjNIcLErivKud14cJCaQnlqRmp6YWpBbB ZJk4OKUaGKv8z7HOu7V6qrXJncS6ZXrztmq9Wrexatny9WfldlbGXmO+WMp6/kjug34/l1Na vrZHep3OdgSX7J90T6SJoVzl6r+AOKGjsYtnqRh7Ot12/XCm6mD4t1OCJ9dZ+3cqby/113fI 3qv5LMPAYYWd0MsQoylzHLdF3E56/ElSVn4p0/HQSMmik0osxRmJhlrMRcWJAEkx0xHQAgAA Archived-At: Cc: mmusic , Paul Kyzivat Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:00:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E442FFESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 My4gV3JpdGUgYSBzZXBhcmF0ZSBkcmFmdCB0aGF0IHVwZGF0ZXMgNDU3Mi4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tXQ0KU2VudDogMjUgRmVicnVhcnkgMjAxNiAyMDo1Nw0KVG86IEpvbmF0aGFuIExlbm5veCA8 am9uYXRoYW5AdmlkeW8uY29tPg0KQ2M6IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20+OyBtbXVzaWMgPG1tdXNpY0BpZXRmLm9yZz47IFBhdWwgS3l6aXZhdCA8cGt5eml2 YXRAYWx1bS5taXQuZWR1PjsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11 c2ljLWR0bHMtc2RwLTA2LnR4dA0KDQpUaGVyZSBhcmUgdHdvIG9wdGlvbnMgcG9zc2libGUgaGVy ZToNCg0KMS4gTWFrZSBjdXJyZW50IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIGRyYWZ0IHVw ZGF0ZSA0NTcyIGFuZCBjb3ZlciBUTFMgYXMgd2VsbCwgZXNzZW50aWFsbHkgbWFraW5nIGl0IGRy YWZ0LWlldGYtbW11c2ljLXRscy1hbmQtZHRscy1zZHANCg0KMi4gTGltaXQgdGhlIHNjb3BlIG9m IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHRvIERUTFMgb25seS4gQ29tcGxldGVseSBkZWZp bmUgaG93IHNldHVwIGFuZCBmaW5nZXJwcmludCBhdHRyaWJ1dGVzIGFyZSB1c2VkIHRoZXJlIGZv ciBEVExTIG9ubHkuIExldCBzb21lIGZ1dHVyZSBkcmFmdCB1cGRhdGUgUkZDIDQ1NzIuDQoNCldo YXQgaXMgdGhlIHByZWZlcmVuY2UgaGVyZSBnaXZlbiB0aGF0IGVpdGhlciBvcHRpb24gd2lsbCBy ZXF1aXJlIGFub3RoZXIgbWFqb3IgZWRpdCBmb3IgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHA/ DQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVGh1LCBG ZWIgMjUsIDIwMTYgYXQgMTA6NDEgQU0sIEpvbmF0aGFuIExlbm5veCA8am9uYXRoYW5AdmlkeW8u Y29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToNCkkgY2FuIGNlcnRhaW5seSBh Z3JlZSB0aGF0IDQ1NzIgY291bGQgdXNlIGFuIHVwZGF0ZS4gSSBkaWRu4oCZdCBjb21wbGV0ZWx5 IHVuZGVyc3RhbmQgd2hhdCBJIHdhcyBkb2luZyB3aGVuIEkgd3JvdGUgaXQ7IGluIHBhcnRpY3Vs YXIsIHRoZSBpZGVhIHRoYXQgdGhlIGNlcnRpZmljYXRlIHdhcyBqdXN0IGEgcmVwb3NpdG9yeSBm b3IgdGhlIHB1YmxpYyBrZXkgd2FzbuKAmXQgc29tZXRoaW5nIEkgaGFkIGNvbXBsZXRlbHkgZ3Jh c3BlZCwgYW5kIHRoZSBoYXNoIGFnaWxpdHkgd2FzIGNvbmZ1c2VkLg0KDQo+IE9uIEZlYiAyNCwg MjAxNiwgYXQgNTowMSBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IE9uIDI0IEZl YnJ1YXJ5IDIwMTYgYXQgMTM6NDcsIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1 PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCj4+IElmIHdlIGFyZSBnb2lu ZyB0byBtYWtlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIG11bHRpcGxlIGZpbmdlcnByaW50cyB3 ZQ0KPj4gbmVlZCBzb21lIHBsYWNlIGF1dGhvcml0YXRpdmUgdG8gcmVmZXJlbmNlIGZvciB0aGUg ZGV0YWlscy4NCj4NCj4gSSByZWNvbW1lbmQganVkaWNpb3VzIHVzZSBvZiBjb3B5IGFuZCBwYXN0 ZS4gIEZlZWwgZnJlZSB0byBzdGVhbCB0ZXh0DQo+IHRoYXQgSSB3cm90ZS4NCj4NCj4gRldJVywg bXkgcmVhZGluZyBvZiA0NTcyIGlzIHRoYXQgaXQgcGVybWl0cyBtdWx0aXBsZSBmaW5nZXJwcmlu dHM6IG9uZQ0KPiBmb3IgZWFjaCBjZXJ0aWZpY2F0ZSB0aGF0IG1pZ2h0IGJlIHVzZWQuICBJdHMg ZmFpbGluZyBpcyB0aGF0IGEpIGl0DQo+IGRvZXNuJ3QgYWxsb3cgZm9yIGhhc2ggYWdpbGl0eSwg YW5kIGIpIGl0J3MgdW5jbGVhciwgcGVyaGFwcyBpbiB0aGUNCj4gZXh0cmVtZS4NCj4NCj4gSG93 ZXZlciwgSSBzZWUgdGhpczoNCj4NCj4gICBFbmRwb2ludHMgTVVTVCBzdXBwb3J0IFNIQS0yNTYg Zm9yIGdlbmVyYXRpbmcgYW5kIHZlcmlmeWluZyB0aGUNCj4gICBmaW5nZXJwcmludCB2YWx1ZSBh c3NvY2lhdGVkIHdpdGggdGhlIERUTFMgYXNzb2NpYXRpb24uICBUaGUgdXNlIG9mDQo+ICAgU0hB LTI1NiBpcyBwcmVmZXJyZWQuDQo+DQo+IFdoaWNoIGRvZXNuJ3QgbWVudGlvbiB0aGF0IHRoaXMg cmVxdWlyZXMgYW4gdXBkYXRlIG9mIDQ1NzIuDQo+DQo+IEFuZCB0aGlzOg0KPg0KPiAgIFRoZSBj ZXJ0aWZpY2F0ZSByZWNlaXZlZCBkdXJpbmcgdGhlIERUTFMgaGFuZHNoYWtlIE1VU1QgbWF0Y2gg dGhlDQo+ICAgZmluZ2VycHJpbnQgcmVjZWl2ZWQgaW4gdGhlIFNEUCAiZmluZ2VycHJpbnQiIGF0 dHJpYnV0ZS4NCj4NCj4gV2hpY2ggc2hvdWxkIHNheSAnKmEqIGZpbmdlcnByaW50JywgdG8gYWxs b3cgZm9yIHRoZXJlIGJlaW5nIG11bHRpcGxlLg0KPg0KPiBBbmQgdGhpczoNCj4NCj4gICBbLi4u XSAgSW4gYWRkaXRpb24sIHRoZSBvZmZlcmVyDQo+ICAgTVVTVCBpbnNlcnQgYW4gU0RQICdzZXR1 cCcgYXR0cmlidXRlIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbg0KPiAgIFtSRkM0MTQ1 XSwgYW5kIGFuIFNEUCAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZSBhY2NvcmRpbmcgdG8gdGhlDQo+ ICAgcHJvY2VkdXJlcyBpbiBbUkZDNDU3Ml0sIGluIHRoZSBvZmZlci4NCj4NCj4gV2hpY2ggZG9l c24ndCBkZWFsIHdpdGggbXVsdGlwbGUgY2VydGlmaWNhdGVzLg0KPg0KPiBJIGFsc28gc2VlOg0K Pg0KPiAgIFRoZQ0KPiAgIHN1YmplY3RBbHROYW1lIGlzIG5vdCBhbiBpbXBvcnRhbnQgY29tcG9u ZW50IG9mIHRoZSBjZXJ0aWZpY2F0ZQ0KPiAgIHZlcmlmaWNhdGlvbi4NCj4NCj4gV2hpY2ggaXMg dHJ1ZSBidXQgaW5zdWZmaWNpZW50OyB0aGUgdGV4dCBjYW4gc2ltcGx5IHNheSB0aGF0IHRoZQ0K PiBjZXJ0aWZpY2F0ZSBpcyBvbmx5IGEgcmVjZXB0YWNsZSBmb3IgYSBwdWJsaWMga2V5IGFuZCBh dXRoZW50aWNhdGlvbg0KPiBpcyB0aWVkIHRvIGFuIGE9ZmluZ2VycHJpbnQgbGluZSBpbiB0aGUg U0RQLg0KPg0KPiBBbmQgdGhpczoNCj4NCj4gICBUaGlzIG9mZmVyIGluY2x1ZGVzLCBhcyBwYXJ0 IG9mIHRoZSBTRFAgcGF5bG9hZCwgdGhlIGZpbmdlcnByaW50IG9mDQo+ICAgdGhlIGNlcnRpZmlj YXRlIHRoYXQgdGhlIGVuZHBvaW50IHdhbnRzIHRvIHVzZS4gIFRoZSBlbmRwb2ludCBTSE9VTEQN Cj4NCj4gV2hpY2ggc2hvdWxkIGJlIHBsdXJhbCBmaW5nZXJwcmludCpzKi4NCj4NCj4gVGhlIHBh dHRlcm4gcmVwZWF0cyB0aHJvdWdob3V0Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3Jn PG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21tdXNpYw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37E442FFESESSMB209erics_ 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 cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4zLiBXcml0ZSBhIHNlcGFyYXRl IGRyYWZ0IHRoYXQgdXBkYXRlcyA0NTcyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3Vu dCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI1IEZlYnJ1 YXJ5IDIwMTYgMjA6NTc8YnI+DQo8Yj5Ubzo8L2I+IEpvbmF0aGFuIExlbm5veCAmbHQ7am9uYXRo YW5AdmlkeW8uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRp bi50aG9tc29uQGdtYWlsLmNvbSZndDs7IG1tdXNpYyAmbHQ7bW11c2ljQGlldGYub3JnJmd0Ozsg UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7OyBDaHJpc3RlciBIb2xt YmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW01NVVNJQ10gV0dMQyBvbiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0w Ni50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgdHdv IG9wdGlvbnMgcG9zc2libGUgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+MS4gTWFrZSBjdXJyZW50IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIGRyYWZ0IHVw ZGF0ZSA0NTcyIGFuZCBjb3ZlciBUTFMgYXMgd2VsbCwgZXNzZW50aWFsbHkgbWFraW5nIGl0IGRy YWZ0LWlldGYtbW11c2ljLXRscy1hbmQtZHRscy1zZHA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIExpbWl0IHRoZSBzY29wZSBvZiBkcmFmdC1pZXRmLW1t dXNpYy1kdGxzLXNkcCB0byBEVExTIG9ubHkuIENvbXBsZXRlbHkgZGVmaW5lIGhvdyBzZXR1cCBh bmQgZmluZ2VycHJpbnQgYXR0cmlidXRlcyBhcmUgdXNlZCB0aGVyZSBmb3IgRFRMUyBvbmx5LiBM ZXQgc29tZSBmdXR1cmUgZHJhZnQgdXBkYXRlIFJGQyA0NTcyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGlzIHRoZSBwcmVmZXJlbmNl IGhlcmUgZ2l2ZW4gdGhhdCBlaXRoZXIgb3B0aW9uIHdpbGwgcmVxdWlyZSBhbm90aGVyIG1ham9y IGVkaXQgZm9yIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9 ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiAyNSwgMjAxNiBhdCAxMDo0MSBB TSwgSm9uYXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29t IiB0YXJnZXQ9Il9ibGFuayI+am9uYXRoYW5AdmlkeW8uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW4gY2VydGFp bmx5IGFncmVlIHRoYXQgNDU3MiBjb3VsZCB1c2UgYW4gdXBkYXRlLiBJIGRpZG7igJl0IGNvbXBs ZXRlbHkgdW5kZXJzdGFuZCB3aGF0IEkgd2FzIGRvaW5nIHdoZW4gSSB3cm90ZSBpdDsgaW4gcGFy dGljdWxhciwgdGhlIGlkZWEgdGhhdCB0aGUgY2VydGlmaWNhdGUgd2FzIGp1c3QgYSByZXBvc2l0 b3J5IGZvciB0aGUgcHVibGljIGtleSB3YXNu4oCZdCBzb21ldGhpbmcgSSBoYWQgY29tcGxldGVs eQ0KIGdyYXNwZWQsIGFuZCB0aGUgaGFzaCBhZ2lsaXR5IHdhcyBjb25mdXNlZC48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyBPbiBG ZWIgMjQsIDIwMTYsIGF0IDU6MDEgUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWls dG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAyNCBGZWJydWFyeSAyMDE2IGF0IDEz OjQ3LCBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5l ZHUiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7IElm IHdlIGFyZSBnb2luZyB0byBtYWtlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIG11bHRpcGxlIGZp bmdlcnByaW50cyB3ZTxicj4NCiZndDsmZ3Q7IG5lZWQgc29tZSBwbGFjZSBhdXRob3JpdGF0aXZl IHRvIHJlZmVyZW5jZSBmb3IgdGhlIGRldGFpbHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSByZWNv bW1lbmQganVkaWNpb3VzIHVzZSBvZiBjb3B5IGFuZCBwYXN0ZS4mbmJzcDsgRmVlbCBmcmVlIHRv IHN0ZWFsIHRleHQ8YnI+DQomZ3Q7IHRoYXQgSSB3cm90ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBG V0lXLCBteSByZWFkaW5nIG9mIDQ1NzIgaXMgdGhhdCBpdCBwZXJtaXRzIG11bHRpcGxlIGZpbmdl cnByaW50czogb25lPGJyPg0KJmd0OyBmb3IgZWFjaCBjZXJ0aWZpY2F0ZSB0aGF0IG1pZ2h0IGJl IHVzZWQuJm5ic3A7IEl0cyBmYWlsaW5nIGlzIHRoYXQgYSkgaXQ8YnI+DQomZ3Q7IGRvZXNuJ3Qg YWxsb3cgZm9yIGhhc2ggYWdpbGl0eSwgYW5kIGIpIGl0J3MgdW5jbGVhciwgcGVyaGFwcyBpbiB0 aGU8YnI+DQomZ3Q7IGV4dHJlbWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSG93ZXZlciwgSSBzZWUg dGhpczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtFbmRwb2ludHMgTVVTVCBzdXBw b3J0IFNIQS0yNTYgZm9yIGdlbmVyYXRpbmcgYW5kIHZlcmlmeWluZyB0aGU8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO2ZpbmdlcnByaW50IHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgRFRMUyBhc3Nv Y2lhdGlvbi4mbmJzcDsgVGhlIHVzZSBvZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7U0hBLTI1NiBp cyBwcmVmZXJyZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hpY2ggZG9lc24ndCBtZW50aW9uIHRo YXQgdGhpcyByZXF1aXJlcyBhbiB1cGRhdGUgb2YgNDU3Mi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBB bmQgdGhpczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtUaGUgY2VydGlmaWNhdGUg cmVjZWl2ZWQgZHVyaW5nIHRoZSBEVExTIGhhbmRzaGFrZSBNVVNUIG1hdGNoIHRoZTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ZmluZ2VycHJpbnQgcmVjZWl2ZWQgaW4gdGhlIFNEUCAmcXVvdDtmaW5n ZXJwcmludCZxdW90OyBhdHRyaWJ1dGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hpY2ggc2hvdWxk IHNheSAnKmEqIGZpbmdlcnByaW50JywgdG8gYWxsb3cgZm9yIHRoZXJlIGJlaW5nIG11bHRpcGxl Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEFuZCB0aGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwO1suLi5dJm5ic3A7IEluIGFkZGl0aW9uLCB0aGUgb2ZmZXJlcjxicj4NCiZndDsmbmJz cDsgJm5ic3A7TVVTVCBpbnNlcnQgYW4gU0RQICdzZXR1cCcgYXR0cmlidXRlIGFjY29yZGluZyB0 byB0aGUgcHJvY2VkdXJlcyBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7W1JGQzQxNDVdLCBhbmQg YW4gU0RQICdmaW5nZXJwcmludCcgYXR0cmlidXRlIGFjY29yZGluZyB0byB0aGU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwO3Byb2NlZHVyZXMgaW4gW1JGQzQ1NzJdLCBpbiB0aGUgb2ZmZXIuPGJyPg0K Jmd0Ozxicj4NCiZndDsgV2hpY2ggZG9lc24ndCBkZWFsIHdpdGggbXVsdGlwbGUgY2VydGlmaWNh dGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYWxzbyBzZWU6PGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7VGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtzdWJqZWN0QWx0TmFtZSBpcyBu b3QgYW4gaW1wb3J0YW50IGNvbXBvbmVudCBvZiB0aGUgY2VydGlmaWNhdGU8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO3ZlcmlmaWNhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGljaCBpcyB0cnVl IGJ1dCBpbnN1ZmZpY2llbnQ7IHRoZSB0ZXh0IGNhbiBzaW1wbHkgc2F5IHRoYXQgdGhlPGJyPg0K Jmd0OyBjZXJ0aWZpY2F0ZSBpcyBvbmx5IGEgcmVjZXB0YWNsZSBmb3IgYSBwdWJsaWMga2V5IGFu ZCBhdXRoZW50aWNhdGlvbjxicj4NCiZndDsgaXMgdGllZCB0byBhbiBhPWZpbmdlcnByaW50IGxp bmUgaW4gdGhlIFNEUC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbmQgdGhpczo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDtUaGlzIG9mZmVyIGluY2x1ZGVzLCBhcyBwYXJ0IG9mIHRoZSBT RFAgcGF5bG9hZCwgdGhlIGZpbmdlcnByaW50IG9mPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt0aGUg Y2VydGlmaWNhdGUgdGhhdCB0aGUgZW5kcG9pbnQgd2FudHMgdG8gdXNlLiZuYnNwOyBUaGUgZW5k cG9pbnQgU0hPVUxEPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hpY2ggc2hvdWxkIGJlIHBsdXJhbCBm aW5nZXJwcmludCpzKi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgcGF0dGVybiByZXBlYXRzIHRo cm91Z2hvdXQuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Om1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37E442FFESESSMB209erics_-- From nobody Thu Feb 25 11:06: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 CA7231B3146 for ; Thu, 25 Feb 2016 11:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 tEEQyRIt5GtN for ; Thu, 25 Feb 2016 11:06:51 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 ACE301A00E0 for ; Thu, 25 Feb 2016 11:06:51 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 9so93403211iom.1 for ; Thu, 25 Feb 2016 11:06:51 -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; bh=/2/H8fJvN+IeDI0LHL3pgu3pXL0qU8XcuD6kXppGb3I=; b=qNif0Ucv4KX4Hry+ExI1h8S0Z8gWP66aZUJwUZcSaCrclXAi836SQGpiKtBLQqXaNr vcH+ysCHz094Wat1/qymF2FMKtAjRqB7BF6SoPCK4r3swyef/M2TkBdqWnEzT2RS1Nmk gEs9lnf3Hg564vn/anZPqebkGb5XPc5KW6W1ylXdgFenz3hr3TiX4y4b3JD8+6Nj0Peu 1L3XNRVC7RezItp3wRZkLmPHFzbFIppPA+m0OSfsA2AVCaWtc2ilX3Shas3GtuJIC2G/ LocXK34nVy7GlTgbPL83kXwe1oiigpueR1u4e2r1Ir87l/ib4QLtfti7MvHD+yLbmcXa vcBg== 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; bh=/2/H8fJvN+IeDI0LHL3pgu3pXL0qU8XcuD6kXppGb3I=; b=QEdi38mJ91XJFcfGGcDWgBAI03DDjpyzNdNVmLVWhhg46Dw33TeaJ4EY94rwmWNLTv 7X7Zd6d6fgR950mL7fLJ6PfInT6A1xyNZdLVXGbmATtz95drxR1SRFJfg8epBU9/CqwX C7q4ayhcyhwkP9twDoobcs7EwgziX/jYRTIECCNOKfx6hmdTrBQTHY8yXKuQcXLuhpGv py0CeUcZChszgWPr4EphVkhMHNW9/3wrw6ELZLHucmGlUswktdmBaU6V6UOwgY21EsCU VGQstChCzby7XIV3gRfWqZCvHshOxHkYEllNAaN8g6Jjmm4gKyJOysHYQyb86T74mudL mTiw== X-Gm-Message-State: AG10YOSZHF/nLvbUcI9yhG9qO/hZIfdA9y7w0VdmboqGTshmTR8dbMdlalz0vGsjHqDAcg== X-Received: by 10.107.136.200 with SMTP id s69mr4538456ioi.120.1456427211130; Thu, 25 Feb 2016 11:06:51 -0800 (PST) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id s38sm3774154ioe.33.2016.02.25.11.06.49 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 11:06:49 -0800 (PST) Received: by mail-io0-f171.google.com with SMTP id l127so98367710iof.3 for ; Thu, 25 Feb 2016 11:06:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.12.226 with SMTP id 95mr4712770iom.70.1456427209163; Thu, 25 Feb 2016 11:06:49 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 11:06:49 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E44296@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF3BD9.7080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4418E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44296@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 14:06:49 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113f8f8e7191c5052c9ce2af Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 19:06:53 -0000 --001a113f8f8e7191c5052c9ce2af Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 1:51 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >> So, I send you a sendonly offer with PT 111:VP8, it is ok for you to > reply with PT 111:PCMU? Both are associated > >> with the same media flow direction, as the offer was sendonly. > > > > These PT are not associated with the same flow direction. Each end point > lists PTs it is willing to receive. The end > > point which is sending the sendonly offer has no idea what the other end > point is willing to receive and their PT > > preferences. The PT in sendonly are in the direction to sendonly end > point, They are simply placeholders and will not be used. > > If so, we should either explicitly specify it, or reference to where it is > already specified. > We will probably need to clarify how asymmetric PT in each direction work with offer/answer. There is a lot of confusion regarding this issue as well. _____________ Roman Shpount --001a113f8f8e7191c5052c9ce2af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 25, 2016 at 1:51 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
>> So, I send you = a sendonly offer with PT 111:VP8, it is ok for you to reply with PT 111:PCM= U? Both are associated
>> with the same media flow direction, as the offer was sendonly.
>
> These PT are not associated with the same flow direction. Each end poi= nt lists PTs it is willing to receive. The end
> point which is sending the sendonly offer has no idea what the other e= nd point is willing to receive and their PT
> preferences. The PT in sendonly are in the direction to sendonly end p= oint, They are simply placeholders and will not be used.=C2=A0

If so, we should either explicitly specify it, or reference to where= it is already specified.

We will proba= bly need to clarify how asymmetric PT in each direction work with offer/ans= wer. There is a lot of confusion regarding this issue as well.
_____________
Roman Shpount
=C2=A0
--001a113f8f8e7191c5052c9ce2af-- From nobody Thu Feb 25 11:12: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 684611B31CA for ; Thu, 25 Feb 2016 11:12:51 -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 1D3Vas5wPThu for ; Thu, 25 Feb 2016 11:12: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 A0AEC1B31C4 for ; Thu, 25 Feb 2016 11:12:49 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-26-56cf522f1dc8 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 04.8B.20792.F225FC65; Thu, 25 Feb 2016 20:12:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 20:12:47 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder Thread-Index: AdFwAB30Yfghq8MmS6WAxjOJMso47A== Date: Thu, 25 Feb 2016 19:12:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4436F@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_7594FB04B1934943A5C02806D1A2204B37E4436FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7hK5+0PkwgwnztSymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlXGv6wVrwy6Bi4bNXrA2M R/S7GDk5JARMJP5N/MIIYYtJXLi3nq2LkYtDSOAwo8THP6tZIJzFjBJTTh1h6mLk4GATsJDo /qcN0iAioCrx9/tkJhCbWcBX4uWCL8wgtrCAt0Tvw4WMEDU+Es8u7mOFsPUk7m1qBathAep9 /ek9G4jNC9Q7Z+VVsHpGoCO+n1oDNVNc4taT+UwQxwlILNlznhnCFpV4+fgfK4StJLH28HYW iPp8iW39z1kgZgpKnJz5hGUCo/AsJKNmISmbhaRsFtBnzAKaEut36UOUKEpM6X7IDmFrSLTO mcuOLL6AkX0Vo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmA8Hdzy22oH48HnjocYBTgYlXh4 N/w9GybEmlhWXJl7iFGCg1lJhDfM63yYEG9KYmVValF+fFFpTmrxIUZpDhYlcd41zuvDhATS E0tSs1NTC1KLYLJMHJxSDYwTDrLf3zGR9feioAtrFK6+Xx7D7hApwfataN8kTuaW2zdFkjQC Mmv2ry69KH3fRdfE6Mj2ZyETN/lofrtvKebn1FsUd6ypgc3U5mqWsXDS4Y5jT/cpTNV3qb3B ulHX5MORJH6HST6/rRo+NO1n0Yx4Nf+Sk3PyhhM9wXNPLv4You0jazJfL0OJpTgj0VCLuag4 EQAa8WC2owIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder 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, 25 Feb 2016 19:12:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E4436FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgY3JlYXRlZCBhIEdpdEh1YiByZXBvLCBhbmQgYWRkZWQgYW4gaW5pdGlhbCB2ZXJz aW9uIG9mIGEgZHJhZnQsIGNvbnRhaW5pbmcgbXkgaW5pdGlhbGx5IHN1Z2dlc3RlZCB0ZXh0IG1v ZGlmaWNhdGlvbi4gV2XigJlsbCB1cGRhdGUgaXQgYXMgd2UgbW92ZSBhbG9uZywgYW5kIHN1Ym1p dCB0aGUgZHJhZnQgd2hlbi9pZiB0aGUgY29tbXVuaXR5IGFncmVlcyB0aGF0IGlzIHNvbWV0aGlu ZyB3ZSBzaG91bGQgZG8uDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1vYS1wdA0K DQooTk9URTogSXTigJlzIGEgcGVyc29uYWwgcmVwbykNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0K --_000_7594FB04B1934943A5C02806D1A2204B37E4436FESESSMB209erics_ 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 LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgY3JlYXRlZCBhIEdpdEh1YiByZXBvLCBhbmQgYWRk ZWQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEgZHJhZnQsIGNvbnRhaW5pbmcgbXkgaW5pdGlhbGx5 IHN1Z2dlc3RlZCB0ZXh0IG1vZGlmaWNhdGlvbi4gV2XigJlsbCB1cGRhdGUNCiBpdCBhcyB3ZSBt b3ZlIGFsb25nLCBhbmQgc3VibWl0IHRoZSBkcmFmdCB3aGVuL2lmIHRoZSBjb21tdW5pdHkgYWdy ZWVzIHRoYXQgaXMgc29tZXRoaW5nIHdlIHNob3VsZCBkby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFm dC1vYS1wdCI+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LW9hLXB0PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+KE5PVEU6IEl04oCZcyBhIHBlcnNvbmFs IHJlcG8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37E4436FESESSMB209erics_-- From nobody Thu Feb 25 11:18: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 0C5071B3228 for ; Thu, 25 Feb 2016 11:18:46 -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_111=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 NObxPK3k0pR2 for ; Thu, 25 Feb 2016 11:18:43 -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 66C1A1B3220 for ; Thu, 25 Feb 2016 11:18:42 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-a6-56cf539023a1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.EA.15637.0935FC65; Thu, 25 Feb 2016 20:18:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 20:18:40 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount , Jonathan Lennox Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRYDJWlchfH5W0vky7ZrpRmrhLnJ83E66AgAJUQ1CAALVrAIAA3K9AgACCd4CAAECHsP//9/iAgAASgkD///dgAIAACcgAgAAEHgCAASf+AIAANraAgAARRXCAAAQ+YA== Date: Thu, 25 Feb 2016 19:18:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E443A4@ESESSMB209.ericsson.se> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> <0EF1AF5F-3AB7-4251-A2C7-C3EF423E917E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37E442FF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E442FF@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_7594FB04B1934943A5C02806D1A2204B37E443A4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7n+6E4PNhBhOXa1vsX3ye2WLq8scs Fis2HGC1mHFhKrMDi8ff9x+YPJYs+cnkcWtKgUfbszvsASxRXDYpqTmZZalF+nYJXBkHLu9m LnhwhbHi36m1jA2ME84zdjFyckgImEgs2rCIDcIWk7hwbz2QzcUhJHCYUaLv8xtGCGcxo8Tf JevZuxg5ONgELCS6/2mDxEUEGhklnrVeYAXpZhZwktj/4TUziC0sYC/x7/4HsKkiAg4Sm25c Y4SwJzFKfJpUA2KzCKhKnNnwDqyeV8BX4viMyawQy1aySdy8MpkJJMEp4CfRN2M6O4jNCHTe 91NrmCCWiUvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUk1h7ezgJRny/RuGcSG8QyQYmTM5+w TGAUnYVk1CwkZbOQlM0C+plZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspN NzLWSy3KTC4uzs/Ty0st2cQIjM2DW36r7mC8/MbxEKMAB6MSD++Gv2fDhFgTy4orcw8xSnAw K4nwhnmdDxPiTUmsrEotyo8vKs1JLT7EKM3BoiTOu8Z5fZiQQHpiSWp2ampBahFMlomDU6qB UXOafmXbj2m5h7d+tL1x+3xP3tnGxw9FL9/Y+0/P51zQC7Y1X7w75qguTj/xeuU8u1lbTjMe /bL/V57Ql/lnni/WOHHx/L2qXaxsqy6pfDz0+3JEf8jnIw/9byXoaXo+8X2hsP/Lu4mFJ1yq p7D7zjkyw1rx8d7lkmWfmBf7r/+W0vYk0V4hL7tJiaU4I9FQi7moOBEAF4mp0ckCAAA= Archived-At: Cc: mmusic , Paul Kyzivat Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:18:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E443A4ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClBlcnNvbmFsbHksIEkgaGF2ZSBubyBwcm9ibGVtIHVwZGF0aW5nIFJGQyA0NTcyIHdp dGhpbiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCwgZGVwZW5kaW5nIG9uIGhvdyBiaWcgdGhl IHVwZGF0ZSB3b3VsZCBiZS4NCg0KVGhlIGN1cnJlbnRseSBpZGVudGlmaWVkIHBvdGVudGlhbCB1 cGRhdGVzIGFyZToNCg0KDQoxKSAgICAgIERlZmluZSB0aGUgc2VtYW50aWNzIG9mIGFzc29jaWF0 aW5nIG11bHRpcGxlIFNEUCDigJhmaW5nZXJwcmludOKAmSBhdHRyaWJ1dGVzIHdpdGggYW4g4oCc bT3igJ0gbGluZS4NCg0KMikgICAgICBVcGRhdGUgdGhlIHByZWZlcnJlZCBjaXBoZXIgc3VpdGUg aW4gb3JkZXIgdG8gYWxpZ24gd2l0aCBEVExTIChTSEEtMSAtPiBTSEEtMjU2KS4NCg0KUmVnYXJk aW5nIDEpLCBJ4oCZZCBiZSBoYXBweSBpZiBzb21lb25lIGNvdWxkIGNvbW1pdCB0byBwcm92aWRp bmcgdGV4dCAoZXZlbiBpZiBpdCBpcyBzaW1wbHkgY29weWluZyBzb21ldGhpbmcgZnJvbSBNYXJ0 aW7igJlzIGRyYWZ0KS4gQWxzbywgaXMgaXQgZW5vdWdoIHRvIHVwZGF0ZSBzZWN0aW9uIDUgb2Yg UkZDIDQ1NzIsIG9yIGRvIHdlIG5lZWQgdG8gdXBkYXRlIHNvbWUgb3RoZXIgc2VjdGlvbnMgdG9v Pw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAy NSBGZWJydWFyeSAyMDE2IDIwOjU5DQpUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5j b20+OyBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbT4NCkNjOiBtbXVzaWMgPG1t dXNpY0BpZXRmLm9yZz47IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KU3Vi amVjdDogUmU6IFtNTVVTSUNdIFdHTEMgb24gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMDYu dHh0DQoNCjMuIFdyaXRlIGEgc2VwYXJhdGUgZHJhZnQgdGhhdCB1cGRhdGVzIDQ1NzIuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0 ZWx1cml4LmNvbV0NClNlbnQ6IDI1IEZlYnJ1YXJ5IDIwMTYgMjA6NTcNClRvOiBKb25hdGhhbiBM ZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPj4NCkNj OiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20+PjsgbW11c2ljIDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Y0BpZXRmLm9yZz4+OyBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86 cGt5eml2YXRAYWx1bS5taXQuZWR1Pj47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+ DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gV0dMQyBvbiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNk cC0wNi50eHQNCg0KVGhlcmUgYXJlIHR3byBvcHRpb25zIHBvc3NpYmxlIGhlcmU6DQoNCjEuIE1h a2UgY3VycmVudCBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCBkcmFmdCB1cGRhdGUgNDU3MiBh bmQgY292ZXIgVExTIGFzIHdlbGwsIGVzc2VudGlhbGx5IG1ha2luZyBpdCBkcmFmdC1pZXRmLW1t dXNpYy10bHMtYW5kLWR0bHMtc2RwDQoNCjIuIExpbWl0IHRoZSBzY29wZSBvZiBkcmFmdC1pZXRm LW1tdXNpYy1kdGxzLXNkcCB0byBEVExTIG9ubHkuIENvbXBsZXRlbHkgZGVmaW5lIGhvdyBzZXR1 cCBhbmQgZmluZ2VycHJpbnQgYXR0cmlidXRlcyBhcmUgdXNlZCB0aGVyZSBmb3IgRFRMUyBvbmx5 LiBMZXQgc29tZSBmdXR1cmUgZHJhZnQgdXBkYXRlIFJGQyA0NTcyLg0KDQpXaGF0IGlzIHRoZSBw cmVmZXJlbmNlIGhlcmUgZ2l2ZW4gdGhhdCBlaXRoZXIgb3B0aW9uIHdpbGwgcmVxdWlyZSBhbm90 aGVyIG1ham9yIGVkaXQgZm9yIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwPw0KDQpSZWdhcmRz LA0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFRodSwgRmViIDI1LCAyMDE2 IGF0IDEwOjQxIEFNLCBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86 am9uYXRoYW5AdmlkeW8uY29tPj4gd3JvdGU6DQpJIGNhbiBjZXJ0YWlubHkgYWdyZWUgdGhhdCA0 NTcyIGNvdWxkIHVzZSBhbiB1cGRhdGUuIEkgZGlkbuKAmXQgY29tcGxldGVseSB1bmRlcnN0YW5k IHdoYXQgSSB3YXMgZG9pbmcgd2hlbiBJIHdyb3RlIGl0OyBpbiBwYXJ0aWN1bGFyLCB0aGUgaWRl YSB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSB3YXMganVzdCBhIHJlcG9zaXRvcnkgZm9yIHRoZSBwdWJs aWMga2V5IHdhc27igJl0IHNvbWV0aGluZyBJIGhhZCBjb21wbGV0ZWx5IGdyYXNwZWQsIGFuZCB0 aGUgaGFzaCBhZ2lsaXR5IHdhcyBjb25mdXNlZC4NCg0KPiBPbiBGZWIgMjQsIDIwMTYsIGF0IDU6 MDEgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0KPiBPbiAyNCBGZWJydWFyeSAyMDE2 IGF0IDEzOjQ3LCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5 eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQo+PiBJZiB3ZSBhcmUgZ29pbmcgdG8gbWFrZSBu b3JtYXRpdmUgcmVmZXJlbmNlcyB0byBtdWx0aXBsZSBmaW5nZXJwcmludHMgd2UNCj4+IG5lZWQg c29tZSBwbGFjZSBhdXRob3JpdGF0aXZlIHRvIHJlZmVyZW5jZSBmb3IgdGhlIGRldGFpbHMuDQo+ DQo+IEkgcmVjb21tZW5kIGp1ZGljaW91cyB1c2Ugb2YgY29weSBhbmQgcGFzdGUuICBGZWVsIGZy ZWUgdG8gc3RlYWwgdGV4dA0KPiB0aGF0IEkgd3JvdGUuDQo+DQo+IEZXSVcsIG15IHJlYWRpbmcg b2YgNDU3MiBpcyB0aGF0IGl0IHBlcm1pdHMgbXVsdGlwbGUgZmluZ2VycHJpbnRzOiBvbmUNCj4g Zm9yIGVhY2ggY2VydGlmaWNhdGUgdGhhdCBtaWdodCBiZSB1c2VkLiAgSXRzIGZhaWxpbmcgaXMg dGhhdCBhKSBpdA0KPiBkb2Vzbid0IGFsbG93IGZvciBoYXNoIGFnaWxpdHksIGFuZCBiKSBpdCdz IHVuY2xlYXIsIHBlcmhhcHMgaW4gdGhlDQo+IGV4dHJlbWUuDQo+DQo+IEhvd2V2ZXIsIEkgc2Vl IHRoaXM6DQo+DQo+ICAgRW5kcG9pbnRzIE1VU1Qgc3VwcG9ydCBTSEEtMjU2IGZvciBnZW5lcmF0 aW5nIGFuZCB2ZXJpZnlpbmcgdGhlDQo+ICAgZmluZ2VycHJpbnQgdmFsdWUgYXNzb2NpYXRlZCB3 aXRoIHRoZSBEVExTIGFzc29jaWF0aW9uLiAgVGhlIHVzZSBvZg0KPiAgIFNIQS0yNTYgaXMgcHJl ZmVycmVkLg0KPg0KPiBXaGljaCBkb2Vzbid0IG1lbnRpb24gdGhhdCB0aGlzIHJlcXVpcmVzIGFu IHVwZGF0ZSBvZiA0NTcyLg0KPg0KPiBBbmQgdGhpczoNCj4NCj4gICBUaGUgY2VydGlmaWNhdGUg cmVjZWl2ZWQgZHVyaW5nIHRoZSBEVExTIGhhbmRzaGFrZSBNVVNUIG1hdGNoIHRoZQ0KPiAgIGZp bmdlcnByaW50IHJlY2VpdmVkIGluIHRoZSBTRFAgImZpbmdlcnByaW50IiBhdHRyaWJ1dGUuDQo+ DQo+IFdoaWNoIHNob3VsZCBzYXkgJyphKiBmaW5nZXJwcmludCcsIHRvIGFsbG93IGZvciB0aGVy ZSBiZWluZyBtdWx0aXBsZS4NCj4NCj4gQW5kIHRoaXM6DQo+DQo+ICAgWy4uLl0gIEluIGFkZGl0 aW9uLCB0aGUgb2ZmZXJlcg0KPiAgIE1VU1QgaW5zZXJ0IGFuIFNEUCAnc2V0dXAnIGF0dHJpYnV0 ZSBhY2NvcmRpbmcgdG8gdGhlIHByb2NlZHVyZXMgaW4NCj4gICBbUkZDNDE0NV0sIGFuZCBhbiBT RFAgJ2ZpbmdlcnByaW50JyBhdHRyaWJ1dGUgYWNjb3JkaW5nIHRvIHRoZQ0KPiAgIHByb2NlZHVy ZXMgaW4gW1JGQzQ1NzJdLCBpbiB0aGUgb2ZmZXIuDQo+DQo+IFdoaWNoIGRvZXNuJ3QgZGVhbCB3 aXRoIG11bHRpcGxlIGNlcnRpZmljYXRlcy4NCj4NCj4gSSBhbHNvIHNlZToNCj4NCj4gICBUaGUN Cj4gICBzdWJqZWN0QWx0TmFtZSBpcyBub3QgYW4gaW1wb3J0YW50IGNvbXBvbmVudCBvZiB0aGUg Y2VydGlmaWNhdGUNCj4gICB2ZXJpZmljYXRpb24uDQo+DQo+IFdoaWNoIGlzIHRydWUgYnV0IGlu c3VmZmljaWVudDsgdGhlIHRleHQgY2FuIHNpbXBseSBzYXkgdGhhdCB0aGUNCj4gY2VydGlmaWNh dGUgaXMgb25seSBhIHJlY2VwdGFjbGUgZm9yIGEgcHVibGljIGtleSBhbmQgYXV0aGVudGljYXRp b24NCj4gaXMgdGllZCB0byBhbiBhPWZpbmdlcnByaW50IGxpbmUgaW4gdGhlIFNEUC4NCj4NCj4g QW5kIHRoaXM6DQo+DQo+ICAgVGhpcyBvZmZlciBpbmNsdWRlcywgYXMgcGFydCBvZiB0aGUgU0RQ IHBheWxvYWQsIHRoZSBmaW5nZXJwcmludCBvZg0KPiAgIHRoZSBjZXJ0aWZpY2F0ZSB0aGF0IHRo ZSBlbmRwb2ludCB3YW50cyB0byB1c2UuICBUaGUgZW5kcG9pbnQgU0hPVUxEDQo+DQo+IFdoaWNo IHNob3VsZCBiZSBwbHVyYWwgZmluZ2VycHJpbnQqcyouDQo+DQo+IFRoZSBwYXR0ZXJuIHJlcGVh dHMgdGhyb3VnaG91dC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37E443A4ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTExMzAy NTU0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTU5 NzUyMTA0IDEzNDgwNzU2OSAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1Nzcg MTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1H QiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+UGVyc29uYWxseSwgSSBoYXZlIG5vIHByb2JsZW0gdXBkYXRpbmcgUkZDIDQ1 NzIgd2l0aGluIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLCBkZXBlbmRpbmcgb24gaG93IGJp ZyB0aGUgdXBkYXRlIHdvdWxkIGJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+VGhlIGN1cnJlbnRseSBpZGVudGlmaWVkIHBvdGVudGlhbCB1cGRhdGVzIGFyZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5EZWZpbmUgdGhlIHNlbWFudGlj cyBvZiBhc3NvY2lhdGluZyBtdWx0aXBsZSBTRFAg4oCYZmluZ2VycHJpbnTigJkgYXR0cmlidXRl cyB3aXRoIGFuIOKAnG094oCdIGxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5VcGRhdGUgdGhlIHByZWZlcnJlZCBjaXBoZXIgc3VpdGUgaW4gb3JkZXIg dG8gYWxpZ24gd2l0aCBEVExTIChTSEEtMSAtJmd0OyBTSEEtMjU2KS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZGluZyAxKSwgSeKAmWQgYmUgaGFwcHkgaWYg c29tZW9uZSBjb3VsZCBjb21taXQgdG8gcHJvdmlkaW5nIHRleHQgKGV2ZW4gaWYgaXQgaXMgc2lt cGx5IGNvcHlpbmcgc29tZXRoaW5nIGZyb20gTWFydGlu4oCZcyBkcmFmdCkuDQogQWxzbywgaXMg aXQgZW5vdWdoIHRvIHVwZGF0ZSBzZWN0aW9uIDUgb2YgUkZDIDQ1NzIsIG9yIGRvIHdlIG5lZWQg dG8gdXBkYXRlIHNvbWUgb3RoZXIgc2VjdGlvbnMgdG9vPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4N CjxiPlNlbnQ6PC9iPiAyNSBGZWJydWFyeSAyMDE2IDIwOjU5PGJyPg0KPGI+VG86PC9iPiBSb21h biBTaHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs7IEpvbmF0aGFuIExlbm5veCAmbHQ7 am9uYXRoYW5AdmlkeW8uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbW11c2ljICZsdDttbXVzaWNA aWV0Zi5vcmcmZ3Q7OyBQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVkdSZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIFdHTEMgb24gZHJhZnQtaWV0Zi1tbXVz aWMtZHRscy1zZHAtMDYudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjMuIFdyaXRlIGEgc2VwYXJhdGUgZHJhZnQgdGhhdCB1cGRhdGVzIDQ1NzIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50 IFs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPm1haWx0bzpyb21hbkB0ZWx1cml4 LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjUgRmVicnVhcnkgMjAxNiAyMDo1Nzxicj4N CjxiPlRvOjwvYj4gSm9uYXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5A dmlkeW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFy dGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20i Pm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBtbXVzaWMgJmx0OzxhIGhyZWY9Im1h aWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBQYXVsIEt5eml2 YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiPnBreXppdmF0QGFs dW0ubWl0LmVkdTwvYT4mZ3Q7OyBDaHJpc3RlciBIb2xtYmVyZw0KICZsdDs8YSBocmVmPSJtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gV0dMQyBv biBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0wNi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgdHdvIG9wdGlvbnMgcG9zc2libGUgaGVyZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gTWFrZSBjdXJyZW50IGRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwIGRyYWZ0IHVwZGF0ZSA0NTcyIGFuZCBjb3ZlciBUTFMgYXMg d2VsbCwgZXNzZW50aWFsbHkgbWFraW5nIGl0IGRyYWZ0LWlldGYtbW11c2ljLXRscy1hbmQtZHRs cy1zZHA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIExp bWl0IHRoZSBzY29wZSBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCB0byBEVExTIG9ubHku IENvbXBsZXRlbHkgZGVmaW5lIGhvdyBzZXR1cCBhbmQgZmluZ2VycHJpbnQgYXR0cmlidXRlcyBh cmUgdXNlZCB0aGVyZSBmb3IgRFRMUyBvbmx5LiBMZXQgc29tZSBmdXR1cmUgZHJhZnQgdXBkYXRl IFJGQyA0NTcyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGF0IGlzIHRoZSBwcmVmZXJlbmNlIGhlcmUgZ2l2ZW4gdGhhdCBlaXRoZXIgb3B0 aW9uIHdpbGwgcmVxdWlyZSBhbm90aGVyIG1ham9yIGVkaXQgZm9yIGRyYWZ0LWlldGYtbW11c2lj LWR0bHMtc2RwPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFu IFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIEZlYiAyNSwgMjAxNiBhdCAxMDo0MSBBTSwgSm9uYXRoYW4gTGVubm94ICZsdDs8YSBo cmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIiB0YXJnZXQ9Il9ibGFuayI+am9uYXRoYW5A dmlkeW8uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg Y2FuIGNlcnRhaW5seSBhZ3JlZSB0aGF0IDQ1NzIgY291bGQgdXNlIGFuIHVwZGF0ZS4gSSBkaWRu 4oCZdCBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgd2hhdCBJIHdhcyBkb2luZyB3aGVuIEkgd3JvdGUg aXQ7IGluIHBhcnRpY3VsYXIsIHRoZSBpZGVhIHRoYXQgdGhlIGNlcnRpZmljYXRlIHdhcyBqdXN0 IGEgcmVwb3NpdG9yeSBmb3IgdGhlIHB1YmxpYyBrZXkgd2FzbuKAmXQgc29tZXRoaW5nIEkgaGFk IGNvbXBsZXRlbHkNCiBncmFzcGVkLCBhbmQgdGhlIGhhc2ggYWdpbGl0eSB3YXMgY29uZnVzZWQu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CiZndDsgT24gRmViIDI0LCAyMDE2LCBhdCA1OjAxIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25AZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMjQgRmVicnVhcnkg MjAxNiBhdCAxMzo0NywgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRA YWx1bS5taXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7Jmd0OyBJZiB3ZSBhcmUgZ29pbmcgdG8gbWFrZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBt dWx0aXBsZSBmaW5nZXJwcmludHMgd2U8YnI+DQomZ3Q7Jmd0OyBuZWVkIHNvbWUgcGxhY2UgYXV0 aG9yaXRhdGl2ZSB0byByZWZlcmVuY2UgZm9yIHRoZSBkZXRhaWxzLjxicj4NCiZndDs8YnI+DQom Z3Q7IEkgcmVjb21tZW5kIGp1ZGljaW91cyB1c2Ugb2YgY29weSBhbmQgcGFzdGUuJm5ic3A7IEZl ZWwgZnJlZSB0byBzdGVhbCB0ZXh0PGJyPg0KJmd0OyB0aGF0IEkgd3JvdGUuPGJyPg0KJmd0Ozxi cj4NCiZndDsgRldJVywgbXkgcmVhZGluZyBvZiA0NTcyIGlzIHRoYXQgaXQgcGVybWl0cyBtdWx0 aXBsZSBmaW5nZXJwcmludHM6IG9uZTxicj4NCiZndDsgZm9yIGVhY2ggY2VydGlmaWNhdGUgdGhh dCBtaWdodCBiZSB1c2VkLiZuYnNwOyBJdHMgZmFpbGluZyBpcyB0aGF0IGEpIGl0PGJyPg0KJmd0 OyBkb2Vzbid0IGFsbG93IGZvciBoYXNoIGFnaWxpdHksIGFuZCBiKSBpdCdzIHVuY2xlYXIsIHBl cmhhcHMgaW4gdGhlPGJyPg0KJmd0OyBleHRyZW1lLjxicj4NCiZndDs8YnI+DQomZ3Q7IEhvd2V2 ZXIsIEkgc2VlIHRoaXM6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7RW5kcG9pbnRz IE1VU1Qgc3VwcG9ydCBTSEEtMjU2IGZvciBnZW5lcmF0aW5nIGFuZCB2ZXJpZnlpbmcgdGhlPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDtmaW5nZXJwcmludCB2YWx1ZSBhc3NvY2lhdGVkIHdpdGggdGhl IERUTFMgYXNzb2NpYXRpb24uJm5ic3A7IFRoZSB1c2Ugb2Y8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw O1NIQS0yNTYgaXMgcHJlZmVycmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdoaWNoIGRvZXNuJ3Qg bWVudGlvbiB0aGF0IHRoaXMgcmVxdWlyZXMgYW4gdXBkYXRlIG9mIDQ1NzIuPGJyPg0KJmd0Ozxi cj4NCiZndDsgQW5kIHRoaXM6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7VGhlIGNl cnRpZmljYXRlIHJlY2VpdmVkIGR1cmluZyB0aGUgRFRMUyBoYW5kc2hha2UgTVVTVCBtYXRjaCB0 aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2ZpbmdlcnByaW50IHJlY2VpdmVkIGluIHRoZSBTRFAg JnF1b3Q7ZmluZ2VycHJpbnQmcXVvdDsgYXR0cmlidXRlLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdo aWNoIHNob3VsZCBzYXkgJyphKiBmaW5nZXJwcmludCcsIHRvIGFsbG93IGZvciB0aGVyZSBiZWlu ZyBtdWx0aXBsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbmQgdGhpczo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDtbLi4uXSZuYnNwOyBJbiBhZGRpdGlvbiwgdGhlIG9mZmVyZXI8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwO01VU1QgaW5zZXJ0IGFuIFNEUCAnc2V0dXAnIGF0dHJpYnV0ZSBh Y2NvcmRpbmcgdG8gdGhlIHByb2NlZHVyZXMgaW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1tSRkM0 MTQ1XSwgYW5kIGFuIFNEUCAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZSBhY2NvcmRpbmcgdG8gdGhl PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtwcm9jZWR1cmVzIGluIFtSRkM0NTcyXSwgaW4gdGhlIG9m ZmVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdoaWNoIGRvZXNuJ3QgZGVhbCB3aXRoIG11bHRpcGxl IGNlcnRpZmljYXRlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFsc28gc2VlOjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1RoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7c3ViamVjdEFs dE5hbWUgaXMgbm90IGFuIGltcG9ydGFudCBjb21wb25lbnQgb2YgdGhlIGNlcnRpZmljYXRlPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDt2ZXJpZmljYXRpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hp Y2ggaXMgdHJ1ZSBidXQgaW5zdWZmaWNpZW50OyB0aGUgdGV4dCBjYW4gc2ltcGx5IHNheSB0aGF0 IHRoZTxicj4NCiZndDsgY2VydGlmaWNhdGUgaXMgb25seSBhIHJlY2VwdGFjbGUgZm9yIGEgcHVi bGljIGtleSBhbmQgYXV0aGVudGljYXRpb248YnI+DQomZ3Q7IGlzIHRpZWQgdG8gYW4gYT1maW5n ZXJwcmludCBsaW5lIGluIHRoZSBTRFAuPGJyPg0KJmd0Ozxicj4NCiZndDsgQW5kIHRoaXM6PGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7VGhpcyBvZmZlciBpbmNsdWRlcywgYXMgcGFy dCBvZiB0aGUgU0RQIHBheWxvYWQsIHRoZSBmaW5nZXJwcmludCBvZjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7dGhlIGNlcnRpZmljYXRlIHRoYXQgdGhlIGVuZHBvaW50IHdhbnRzIHRvIHVzZS4mbmJz cDsgVGhlIGVuZHBvaW50IFNIT1VMRDxicj4NCiZndDs8YnI+DQomZ3Q7IFdoaWNoIHNob3VsZCBi ZSBwbHVyYWwgZmluZ2VycHJpbnQqcyouPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHBhdHRlcm4g cmVwZWF0cyB0aHJvdWdob3V0Ljxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37E443A4ESESSMB209erics_-- From nobody Thu Feb 25 11:19: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 ECEC81B3218 for ; Thu, 25 Feb 2016 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 jg_fHaksUkSQ for ; Thu, 25 Feb 2016 11:19: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 D05B41B3229 for ; Thu, 25 Feb 2016 11:19:53 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id g203so98944734iof.2 for ; Thu, 25 Feb 2016 11:19:53 -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; bh=LarGx5J/6LJjgJjxbwnZHHlBF4yFQZ01Yv8LFGBX3bc=; b=ShmWq5pKSsEzv1hDeq6yq8iy646F36Kxz1UGrB/f+QuZNKnngtaNVlGCrsYmwgR7mb IUhXFZziSc5UozvmPUSV7GOe0MJJzeSFKTiyQkgwg1gcfqpGQ+oMLzWNxr349zswae/J uhSn4Cr5tW0YLIGXXVz9IXZUvy+tViygEjKVyEp+pn6B6ICOUyX/m78a4z6N/cP+Jv32 5JFozMX4pmMEdNp5XFH1Iq/gpV6I6OIKh7Vc00Tvk6TlYTfI+Ndykgaev88XxnDUpdSL un3LsWrwsnKVgBQvGu8NUxDSiZQI4d9KeoRSc7Np6OiD3/cvtpK+4c0TNo7SOLIMlf0Y GdyA== 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; bh=LarGx5J/6LJjgJjxbwnZHHlBF4yFQZ01Yv8LFGBX3bc=; b=SMmMdamIayAHhAS4BRxitGE6a+kHtD0xZG6svv3xg5v2WPmW/kiBm9x71d15mWCLWl AgTzlFUbwWHCwaMdZPUQNHNn3PnCxQpgg8dmKOV6HyKcf4LJ5Kls/fqBr4s0tM122Cau 0rjnOaKvdTzmOf86NbleGkpIesEfq4syGX4TOOMeOCYw+t37p3ojxbynU2lxixauKIpA zyzm7jCL8nSUE4TSFUXopOgIUbzBJ7vBK+mmiLswPAnCVuBIACSTatgsXVw/cOsopBX5 D68fm11K24mXVEyOx6bNpGCeGROzV/Hti+I+S+SZ8YPbJ+7VJ/nmfxI5/W3SPwyOWSa/ XW/w== X-Gm-Message-State: AG10YOSuN8xIVG6DG1UhBav1e5AvONYK4USIG7fkQO7u61D5B8pIe/ElhYgMvt5F+UO+pA== X-Received: by 10.107.6.82 with SMTP id 79mr4415774iog.72.1456427993326; Thu, 25 Feb 2016 11:19:53 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id h83sm3819159iod.4.2016.02.25.11.19.51 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 11:19:52 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id 9so93797295iom.1 for ; Thu, 25 Feb 2016 11:19:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr4647106iod.145.1456427991291; Thu, 25 Feb 2016 11:19:51 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 11:19:51 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E41317@ESESSMB209.ericsson.se> References: <878u2ayqq6.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B37E41317@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 14:19:51 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113ece600fe298052c9d11f9 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions 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, 25 Feb 2016 19:19:57 -0000 --001a113ece600fe298052c9d11f9 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 5:06 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Not necessarily. Even if PT is per direction is allowed as such, we still > need to clarify whether the same PT/codec binding is per direction, or > whether it applies to the whole session. > Yes, this needs to be clarified, but general consensus is that each direction is independent. > > The complication here is that Alice will not be allowed to reuse PT 111 > for AMR(mode-set=0,2,5,7) in the answer. Alice will need to pick a > > different PT for AMR(mode-set=0,2,5,7), if it is supported and end > points will use asymmetric payload types. > > So, you are saying that Alice is not allowed to reuse a PT value that > Alice has previously used for another PT/codec binding - no matter if Bob > supported the codec or not? > > For example: assume Alice offered PT 111: VP8, but Bob did not include VP8 > in the answer. Then Bob offers PT 111:AMR. Now, Alice is not allowed to use > PT 111 for AMR, since Alice previously used it for VP8. > This is exactly what I am saying. The fact that Bob did not include VP8 in the answer does not mean it is not sending VP8 to Alice. Because of this Alice is not allowed to use PT 111 for AMR since there can be VP8 media in flight with PT 111. What I am trying to highlight here that if an end point is reusing a PT which was used in one direction only, it is forcing asymmetric PT assignment. This, of cause, breaks the SHOULD from section 6.1 in RFC 3264: In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Regards, _____________ Roman Shpount --001a113ece600fe298052c9d11f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 25, 2016 at 5:06 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Not necessarily. Even if PT is per direct= ion is allowed as such, we still need to clarify whether the same PT/codec = binding is per direction, or whether it applies to the whole session.

Yes, this needs to be clarified, but general= consensus is that each direction is independent.
=C2=A0
> The complication here is that Alice wil= l not be allowed to reuse PT 111 for=C2=A0AMR(mode-set=3D0,2,5,7) in the an= swer. Alice will need to pick a
> different PT for=C2=A0AMR(mode-set=3D0,2,5,7), if it is supported and = end points will use asymmetric payload types.

So, you are saying that Alice is not allowed to reuse a PT value tha= t Alice has previously used for another PT/codec binding - no matter if Bob= supported the codec or not?

For example: assume Alice offered PT 111: VP8, but Bob did not include VP8 = in the answer. Then Bob offers PT 111:AMR. Now, Alice is not allowed to use= PT 111 for AMR, since Alice previously used it for VP8.

This is exactly what I am saying. The fact that Bob did n= ot include VP8 in the answer does not mean it is not sending VP8 to Alice. = Because of this Alice is not allowed to use PT 111 for AMR since there can = be VP8 media in flight with PT 111.

What I am tryi= ng to highlight here that if an end point is reusing a PT which was used in= one direction only, it=C2=A0is forcing asymmetric PT assignment. This, of = cause, breaks the SHOULD from section 6.1 in RFC 3264:

<= /div>
In the case of RTP, if= a particular codec was referenced with a
specific payload type number in = the offer, that same payload type
number SHOULD be used for that codec in = the answer.

Regards,
_____________Roman Shpount
=C2=A0
--001a113ece600fe298052c9d11f9-- From nobody Thu Feb 25 11:23: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 D36191B327D for ; Thu, 25 Feb 2016 11:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 97j9tzw0aTYV for ; Thu, 25 Feb 2016 11:23:32 -0800 (PST) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC59E1B3285 for ; Thu, 25 Feb 2016 11:23:31 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1PJMitl002570; Thu, 25 Feb 2016 14:23:26 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 214cqcw2s3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Feb 2016 14:23:26 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 25 Feb 2016 13:23:25 -0600 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt Thread-Index: AQHRb0MX6bWTp5bg6UyLiWt52o6bVp88DisAgAAH8ACAAAnHAIAABB4AgAEoAACAADa0gIAAAJGAgAAFc4CAAAFWAA== Date: Thu, 25 Feb 2016 19:23:24 +0000 Message-ID: <8C8A7D25-BFB2-488C-B335-7FC531A68EF8@vidyo.com> References: <56B4CDCF.4080100@cisco.com> <56CA320D.9050306@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E389BF@ESESSMB209.ericsson.se> <56CCBE6A.7090709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3E3AB@ESESSMB209.ericsson.se> <56CDE4FB.6090002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E400B7@ESESSMB209.ericsson.se> <56CE145F.5090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4013D@ESESSMB209.ericsson.se> <56CE24DE.6090300@alum.mit.edu> <0EF1AF5F-3AB7-4251-A2C7-C3EF423E917E@vidyo.com> <7594FB04B1934943A5C02806D1A2204B37E442FF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E443A4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E443A4@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_8C8A7D25BFB2488CB3357FC531A68EF8vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-25_08:2016-02-25,2016-02-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602250248 Archived-At: Cc: Paul Kyzivat , mmusic Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:23:35 -0000 --_000_8C8A7D25BFB2488CB3357FC531A68EF8vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBGZWIgMjUsIDIwMTYsIGF0IDI6MTggUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KUGVyc29uYWxseSwgSSBoYXZlIG5vIHByb2JsZW0gdXBk YXRpbmcgUkZDIDQ1NzIgd2l0aGluIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLCBkZXBlbmRp bmcgb24gaG93IGJpZyB0aGUgdXBkYXRlIHdvdWxkIGJlLg0KDQpUaGUgY3VycmVudGx5IGlkZW50 aWZpZWQgcG90ZW50aWFsIHVwZGF0ZXMgYXJlOg0KDQoxKSAgICAgIERlZmluZSB0aGUgc2VtYW50 aWNzIG9mIGFzc29jaWF0aW5nIG11bHRpcGxlIFNEUCDigJhmaW5nZXJwcmludOKAmSBhdHRyaWJ1 dGVzIHdpdGggYW4g4oCcbT3igJ0gbGluZS4NCjIpICAgICAgVXBkYXRlIHRoZSBwcmVmZXJyZWQg Y2lwaGVyIHN1aXRlIGluIG9yZGVyIHRvIGFsaWduIHdpdGggRFRMUyAoU0hBLTEgLT4gU0hBLTI1 NikuDQoNCkFub3RoZXIgcG90ZW50aWFsIHVwZGF0ZSB3b3VsZCBiZSB0byByZW1vdmUgKG9yIHJl bGF4KSB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUgZmluZ2VycHJpbnQgdXNlIHRoZSBzYW1lIGhh c2ggYWxnb3JpdGhtIGFzIHRoZSBjZXJ0aWZpY2F0ZS4gIFRoaXMgc2VlbXMgbGlrZSBhIG5lY2Vz c2FyeSBjb3JvbGxhcnkgdG8gMSksIGJ1dCBpcyBhbHNvIHVzZWZ1bCBvbiBpdHMgb3duLg0KDQpS ZWdhcmRpbmcgMSksIEnigJlkIGJlIGhhcHB5IGlmIHNvbWVvbmUgY291bGQgY29tbWl0IHRvIHBy b3ZpZGluZyB0ZXh0IChldmVuIGlmIGl0IGlzIHNpbXBseSBjb3B5aW5nIHNvbWV0aGluZyBmcm9t IE1hcnRpbuKAmXMgZHJhZnQpLiBBbHNvLCBpcyBpdCBlbm91Z2ggdG8gdXBkYXRlIHNlY3Rpb24g NSBvZiBSRkMgNDU3Miwgb3IgZG8gd2UgbmVlZCB0byB1cGRhdGUgc29tZSBvdGhlciBzZWN0aW9u cyB0b28/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1t dXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNl bnQ6IDI1IEZlYnJ1YXJ5IDIwMTYgMjA6NTkNClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1 cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PjsgSm9uYXRoYW4gTGVubm94IDxqb25h dGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT4+DQpDYzogbW11c2ljIDxt bXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+OyBQYXVsIEt5eml2YXQgPHBr eXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4NClN1Ympl Y3Q6IFJlOiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTA2LnR4 dA0KDQozLiBXcml0ZSBhIHNlcGFyYXRlIGRyYWZ0IHRoYXQgdXBkYXRlcyA0NTcyLg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVs dXJpeC5jb21dDQpTZW50OiAyNSBGZWJydWFyeSAyMDE2IDIwOjU3DQpUbzogSm9uYXRoYW4gTGVu bm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT4+DQpDYzog TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tPj47IG1tdXNpYyA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNA aWV0Zi5vcmc+PjsgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBr eXppdmF0QGFsdW0ubWl0LmVkdT4+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0K U3ViamVjdDogUmU6IFtNTVVTSUNdIFdHTEMgb24gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAt MDYudHh0DQoNClRoZXJlIGFyZSB0d28gb3B0aW9ucyBwb3NzaWJsZSBoZXJlOg0KDQoxLiBNYWtl IGN1cnJlbnQgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgZHJhZnQgdXBkYXRlIDQ1NzIgYW5k IGNvdmVyIFRMUyBhcyB3ZWxsLCBlc3NlbnRpYWxseSBtYWtpbmcgaXQgZHJhZnQtaWV0Zi1tbXVz aWMtdGxzLWFuZC1kdGxzLXNkcA0KDQoyLiBMaW1pdCB0aGUgc2NvcGUgb2YgZHJhZnQtaWV0Zi1t bXVzaWMtZHRscy1zZHAgdG8gRFRMUyBvbmx5LiBDb21wbGV0ZWx5IGRlZmluZSBob3cgc2V0dXAg YW5kIGZpbmdlcnByaW50IGF0dHJpYnV0ZXMgYXJlIHVzZWQgdGhlcmUgZm9yIERUTFMgb25seS4g TGV0IHNvbWUgZnV0dXJlIGRyYWZ0IHVwZGF0ZSBSRkMgNDU3Mi4NCg0KV2hhdCBpcyB0aGUgcHJl ZmVyZW5jZSBoZXJlIGdpdmVuIHRoYXQgZWl0aGVyIG9wdGlvbiB3aWxsIHJlcXVpcmUgYW5vdGhl ciBtYWpvciBlZGl0IGZvciBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcD8NCg0KUmVnYXJkcywN Cg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBUaHUsIEZlYiAyNSwgMjAxNiBh dCAxMDo0MSBBTSwgSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpv bmF0aGFuQHZpZHlvLmNvbT4+IHdyb3RlOg0KSSBjYW4gY2VydGFpbmx5IGFncmVlIHRoYXQgNDU3 MiBjb3VsZCB1c2UgYW4gdXBkYXRlLiBJIGRpZG7igJl0IGNvbXBsZXRlbHkgdW5kZXJzdGFuZCB3 aGF0IEkgd2FzIGRvaW5nIHdoZW4gSSB3cm90ZSBpdDsgaW4gcGFydGljdWxhciwgdGhlIGlkZWEg dGhhdCB0aGUgY2VydGlmaWNhdGUgd2FzIGp1c3QgYSByZXBvc2l0b3J5IGZvciB0aGUgcHVibGlj IGtleSB3YXNu4oCZdCBzb21ldGhpbmcgSSBoYWQgY29tcGxldGVseSBncmFzcGVkLCBhbmQgdGhl IGhhc2ggYWdpbGl0eSB3YXMgY29uZnVzZWQuDQoNCj4gT24gRmViIDI0LCAyMDE2LCBhdCA1OjAx IFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gT24gMjQgRmVicnVhcnkgMjAxNiBh dCAxMzo0NywgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXpp dmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KPj4gSWYgd2UgYXJlIGdvaW5nIHRvIG1ha2Ugbm9y bWF0aXZlIHJlZmVyZW5jZXMgdG8gbXVsdGlwbGUgZmluZ2VycHJpbnRzIHdlDQo+PiBuZWVkIHNv bWUgcGxhY2UgYXV0aG9yaXRhdGl2ZSB0byByZWZlcmVuY2UgZm9yIHRoZSBkZXRhaWxzLg0KPg0K PiBJIHJlY29tbWVuZCBqdWRpY2lvdXMgdXNlIG9mIGNvcHkgYW5kIHBhc3RlLiAgRmVlbCBmcmVl IHRvIHN0ZWFsIHRleHQNCj4gdGhhdCBJIHdyb3RlLg0KPg0KPiBGV0lXLCBteSByZWFkaW5nIG9m IDQ1NzIgaXMgdGhhdCBpdCBwZXJtaXRzIG11bHRpcGxlIGZpbmdlcnByaW50czogb25lDQo+IGZv ciBlYWNoIGNlcnRpZmljYXRlIHRoYXQgbWlnaHQgYmUgdXNlZC4gIEl0cyBmYWlsaW5nIGlzIHRo YXQgYSkgaXQNCj4gZG9lc24ndCBhbGxvdyBmb3IgaGFzaCBhZ2lsaXR5LCBhbmQgYikgaXQncyB1 bmNsZWFyLCBwZXJoYXBzIGluIHRoZQ0KPiBleHRyZW1lLg0KPg0KPiBIb3dldmVyLCBJIHNlZSB0 aGlzOg0KPg0KPiAgIEVuZHBvaW50cyBNVVNUIHN1cHBvcnQgU0hBLTI1NiBmb3IgZ2VuZXJhdGlu ZyBhbmQgdmVyaWZ5aW5nIHRoZQ0KPiAgIGZpbmdlcnByaW50IHZhbHVlIGFzc29jaWF0ZWQgd2l0 aCB0aGUgRFRMUyBhc3NvY2lhdGlvbi4gIFRoZSB1c2Ugb2YNCj4gICBTSEEtMjU2IGlzIHByZWZl cnJlZC4NCj4NCj4gV2hpY2ggZG9lc24ndCBtZW50aW9uIHRoYXQgdGhpcyByZXF1aXJlcyBhbiB1 cGRhdGUgb2YgNDU3Mi4NCj4NCj4gQW5kIHRoaXM6DQo+DQo+ICAgVGhlIGNlcnRpZmljYXRlIHJl Y2VpdmVkIGR1cmluZyB0aGUgRFRMUyBoYW5kc2hha2UgTVVTVCBtYXRjaCB0aGUNCj4gICBmaW5n ZXJwcmludCByZWNlaXZlZCBpbiB0aGUgU0RQICJmaW5nZXJwcmludCIgYXR0cmlidXRlLg0KPg0K PiBXaGljaCBzaG91bGQgc2F5ICcqYSogZmluZ2VycHJpbnQnLCB0byBhbGxvdyBmb3IgdGhlcmUg YmVpbmcgbXVsdGlwbGUuDQo+DQo+IEFuZCB0aGlzOg0KPg0KPiAgIFsuLi5dICBJbiBhZGRpdGlv biwgdGhlIG9mZmVyZXINCj4gICBNVVNUIGluc2VydCBhbiBTRFAgJ3NldHVwJyBhdHRyaWJ1dGUg YWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzIGluDQo+ICAgW1JGQzQxNDVdLCBhbmQgYW4gU0RQ ICdmaW5nZXJwcmludCcgYXR0cmlidXRlIGFjY29yZGluZyB0byB0aGUNCj4gICBwcm9jZWR1cmVz IGluIFtSRkM0NTcyXSwgaW4gdGhlIG9mZmVyLg0KPg0KPiBXaGljaCBkb2Vzbid0IGRlYWwgd2l0 aCBtdWx0aXBsZSBjZXJ0aWZpY2F0ZXMuDQo+DQo+IEkgYWxzbyBzZWU6DQo+DQo+ICAgVGhlDQo+ ICAgc3ViamVjdEFsdE5hbWUgaXMgbm90IGFuIGltcG9ydGFudCBjb21wb25lbnQgb2YgdGhlIGNl cnRpZmljYXRlDQo+ICAgdmVyaWZpY2F0aW9uLg0KPg0KPiBXaGljaCBpcyB0cnVlIGJ1dCBpbnN1 ZmZpY2llbnQ7IHRoZSB0ZXh0IGNhbiBzaW1wbHkgc2F5IHRoYXQgdGhlDQo+IGNlcnRpZmljYXRl IGlzIG9ubHkgYSByZWNlcHRhY2xlIGZvciBhIHB1YmxpYyBrZXkgYW5kIGF1dGhlbnRpY2F0aW9u DQo+IGlzIHRpZWQgdG8gYW4gYT1maW5nZXJwcmludCBsaW5lIGluIHRoZSBTRFAuDQo+DQo+IEFu ZCB0aGlzOg0KPg0KPiAgIFRoaXMgb2ZmZXIgaW5jbHVkZXMsIGFzIHBhcnQgb2YgdGhlIFNEUCBw YXlsb2FkLCB0aGUgZmluZ2VycHJpbnQgb2YNCj4gICB0aGUgY2VydGlmaWNhdGUgdGhhdCB0aGUg ZW5kcG9pbnQgd2FudHMgdG8gdXNlLiAgVGhlIGVuZHBvaW50IFNIT1VMRA0KPg0KPiBXaGljaCBz aG91bGQgYmUgcGx1cmFsIGZpbmdlcnByaW50KnMqLg0KPg0KPiBUaGUgcGF0dGVybiByZXBlYXRz IHRocm91Z2hvdXQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Y0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj DQoNCg== --_000_8C8A7D25BFB2488CB3357FC531A68EF8vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIg MjUsIDIwMTYsIGF0IDI6MTggUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+SGksPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5i c3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlBlcnNv bmFsbHksIEkgaGF2ZSBubyBwcm9ibGVtIHVwZGF0aW5nIFJGQyA0NTcyIHdpdGhpbiBkcmFmdC1p ZXRmLW1tdXNpYy1kdGxzLXNkcCwgZGVwZW5kaW5nIG9uIGhvdyBiaWcgdGhlIHVwZGF0ZSB3b3Vs ZCBiZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+VGhlIGN1cnJlbnRseSBpZGVudGlmaWVkIHBvdGVudGlhbCB1cGRhdGVz IGFyZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyB0ZXh0LWluZGVudDogLTE4cHQ7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjEp PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyIgY2xhc3M9IiI+RGVmaW5lDQogdGhlIHNlbWFudGljcyBvZiBhc3NvY2lhdGluZyBtdWx0aXBs ZSBTRFAg4oCYZmluZ2VycHJpbnTigJkgYXR0cmlidXRlcyB3aXRoIGFuIOKAnG094oCdIGxpbmUu PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyB0ZXh0LWluZGVudDogLTE4cHQ7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjIpPHNw YW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+VXBkYXRlDQogdGhlIHByZWZlcnJlZCBjaXBoZXIgc3VpdGUgaW4gb3JkZXIgdG8g YWxpZ24gd2l0aCBEVExTIChTSEEtMSAtJmd0OyBTSEEtMjU2KS48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj5Bbm90aGVyIHBv dGVudGlhbCB1cGRhdGUgd291bGQgYmUgdG8gcmVtb3ZlIChvciByZWxheCkgdGhlIHJlcXVpcmVt ZW50IHRoYXQgdGhlIGZpbmdlcnByaW50IHVzZSB0aGUgc2FtZSBoYXNoIGFsZ29yaXRobSBhcyB0 aGUgY2VydGlmaWNhdGUuICZuYnNwO1RoaXMgc2VlbXMgbGlrZSBhIG5lY2Vzc2FyeSBjb3JvbGxh cnkgdG8gMSksIGJ1dCBpcyBhbHNvIHVzZWZ1bCBvbiBpdHMgb3duLjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ UmVnYXJkaW5nIDEpLCBJ4oCZZCBiZSBoYXBweSBpZiBzb21lb25lIGNvdWxkIGNvbW1pdCB0byBw cm92aWRpbmcgdGV4dCAoZXZlbiBpZiBpdCBpcyBzaW1wbHkgY29weWluZyBzb21ldGhpbmcgZnJv bSBNYXJ0aW7igJlzIGRyYWZ0KS4gQWxzbywgaXMgaXQgZW5vdWdoIHRvIHVwZGF0ZQ0KIHNlY3Rp b24gNSBvZiBSRkMgNDU3Miwgb3IgZG8gd2UgbmVlZCB0byB1cGRhdGUgc29tZSBvdGhlciBzZWN0 aW9ucyB0b28/PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPlJlZ2FyZHMsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkNocmlzdGVyPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPGEgbmFtZT0iX01haWxFbmRDb21wb3NlIiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9hPjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBu b25lOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRlci10b3Atd2lk dGg6IDFwdDsgcGFkZGluZzogM3B0IDBjbSAwY207IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pm1tdXNpYyBbPGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWls dG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Q2hyaXN0ZXIgSG9s bWJlcmc8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MjUgRmVicnVhcnkgMjAxNiAyMDo1OTxi ciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJvbWFuQHRlbHVyaXguY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7OyBKb25hdGhh biBMZW5ub3ggJmx0OzxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmpvbmF0 aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tbXVzaWMgJmx0 OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT4m Z3Q7OyBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5l ZHUiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNs YXNzPSIiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlJlOiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2Rw LTA2LnR4dDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNz PSIiPjMuIFdyaXRlIGEgc2VwYXJhdGUgZHJhZnQgdGhhdCB1cGRhdGVzIDQ1NzIuPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIi PlJlZ2FyZHMsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPkNocmlzdGVyPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Um9tYW4gU2hwb3VudA0KIFs8YSBocmVmPSJtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPm1haWx0bzpyb21hbkB0ZWx1cml4LmNvbTwvYT5dPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj4yNSBGZWJydWFyeSAyMDE2IDIwOjU3PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5K b25hdGhhbiBMZW5ub3ggJmx0OzxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIi PmpvbmF0aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6 PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NYXJ0 aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDs7IG1tdXNpYyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bW11c2ljQGlldGYub3JnPC9hPiZndDs7DQogUGF1 bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiBzdHls ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5w a3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0OzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhy ZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJlOiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTA2LnR4dDxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NClRoZXJlIGFyZSB0d28gb3B0aW9ucyBwb3NzaWJsZSBoZXJlOjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQoxLiBNYWtlIGN1cnJlbnQgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgZHJhZnQgdXBkYXRl IDQ1NzIgYW5kIGNvdmVyIFRMUyBhcyB3ZWxsLCBlc3NlbnRpYWxseSBtYWtpbmcgaXQgZHJhZnQt aWV0Zi1tbXVzaWMtdGxzLWFuZC1kdGxzLXNkcDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K Mi4gTGltaXQgdGhlIHNjb3BlIG9mIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHRvIERUTFMg b25seS4gQ29tcGxldGVseSBkZWZpbmUgaG93IHNldHVwIGFuZCBmaW5nZXJwcmludCBhdHRyaWJ1 dGVzIGFyZSB1c2VkIHRoZXJlIGZvciBEVExTIG9ubHkuIExldCBzb21lIGZ1dHVyZSBkcmFmdCB1 cGRhdGUgUkZDIDQ1NzIuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCldoYXQg aXMgdGhlIHByZWZlcmVuY2UgaGVyZSBnaXZlbiB0aGF0IGVpdGhlciBvcHRpb24gd2lsbCByZXF1 aXJlIGFub3RoZXIgbWFqb3IgZWRpdCBmb3IgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHA/PG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClJlZ2FyZHMsPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGVhcj0iYWxsIiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQpfX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KUm9tYW4gU2hwb3VudDxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCk9uIFRodSwgRmViIDI1LCAyMDE2IGF0IDEwOjQxIEFNLCBKb25hdGhhbiBMZW5ub3gg Jmx0OzxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iIHRhcmdldD0iX2JsYW5rIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29s aWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0LXdp ZHRoOiAxcHQ7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDZwdDsgbWFyZ2luOiA1cHQgMGNtIDVwdCA0 LjhwdDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCkkgY2FuIGNlcnRhaW5seSBhZ3JlZSB0aGF0IDQ1NzIgY291bGQgdXNlIGFuIHVw ZGF0ZS4gSSBkaWRu4oCZdCBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgd2hhdCBJIHdhcyBkb2luZyB3 aGVuIEkgd3JvdGUgaXQ7IGluIHBhcnRpY3VsYXIsIHRoZSBpZGVhIHRoYXQgdGhlIGNlcnRpZmlj YXRlIHdhcyBqdXN0IGEgcmVwb3NpdG9yeSBmb3IgdGhlIHB1YmxpYyBrZXkgd2FzbuKAmXQgc29t ZXRoaW5nIEkgaGFkIGNvbXBsZXRlbHkgZ3Jhc3BlZCwgYW5kIHRoZSBoYXNoDQogYWdpbGl0eSB3 YXMgY29uZnVzZWQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDsgT24gRmViIDI0LCAyMDE2LCBhdCA1OjAxIFBNLCBN YXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi Pg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgT24gMjQgRmVicnVhcnkgMjAxNiBhdCAxMzo0Nywg UGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyBJZiB3ZSBhcmUgZ29pbmcgdG8gbWFrZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBtdWx0 aXBsZSBmaW5nZXJwcmludHMgd2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBuZWVkIHNvbWUgcGxh Y2UgYXV0aG9yaXRhdGl2ZSB0byByZWZlcmVuY2UgZm9yIHRoZSBkZXRhaWxzLjxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEkgcmVjb21tZW5kIGp1ZGljaW91cyB1c2Ugb2Yg Y29weSBhbmQgcGFzdGUuJm5ic3A7IEZlZWwgZnJlZSB0byBzdGVhbCB0ZXh0PGJyIGNsYXNzPSIi Pg0KJmd0OyB0aGF0IEkgd3JvdGUuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZn dDsgRldJVywgbXkgcmVhZGluZyBvZiA0NTcyIGlzIHRoYXQgaXQgcGVybWl0cyBtdWx0aXBsZSBm aW5nZXJwcmludHM6IG9uZTxiciBjbGFzcz0iIj4NCiZndDsgZm9yIGVhY2ggY2VydGlmaWNhdGUg dGhhdCBtaWdodCBiZSB1c2VkLiZuYnNwOyBJdHMgZmFpbGluZyBpcyB0aGF0IGEpIGl0PGJyIGNs YXNzPSIiPg0KJmd0OyBkb2Vzbid0IGFsbG93IGZvciBoYXNoIGFnaWxpdHksIGFuZCBiKSBpdCdz IHVuY2xlYXIsIHBlcmhhcHMgaW4gdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyBleHRyZW1lLjxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEhvd2V2ZXIsIEkgc2VlIHRoaXM6PGJy IGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7RW5kcG9pbnRz IE1VU1Qgc3VwcG9ydCBTSEEtMjU2IGZvciBnZW5lcmF0aW5nIGFuZCB2ZXJpZnlpbmcgdGhlPGJy IGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDtmaW5nZXJwcmludCB2YWx1ZSBhc3NvY2lhdGVk IHdpdGggdGhlIERUTFMgYXNzb2NpYXRpb24uJm5ic3A7IFRoZSB1c2Ugb2Y8YnIgY2xhc3M9IiI+ DQomZ3Q7Jm5ic3A7ICZuYnNwO1NIQS0yNTYgaXMgcHJlZmVycmVkLjxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFdoaWNoIGRvZXNuJ3QgbWVudGlvbiB0aGF0IHRoaXMgcmVx dWlyZXMgYW4gdXBkYXRlIG9mIDQ1NzIuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4N CiZndDsgQW5kIHRoaXM6PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJz cDsgJm5ic3A7VGhlIGNlcnRpZmljYXRlIHJlY2VpdmVkIGR1cmluZyB0aGUgRFRMUyBoYW5kc2hh a2UgTVVTVCBtYXRjaCB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2ZpbmdlcnBy aW50IHJlY2VpdmVkIGluIHRoZSBTRFAgJnF1b3Q7ZmluZ2VycHJpbnQmcXVvdDsgYXR0cmlidXRl LjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFdoaWNoIHNob3VsZCBzYXkg JyphKiBmaW5nZXJwcmludCcsIHRvIGFsbG93IGZvciB0aGVyZSBiZWluZyBtdWx0aXBsZS48YnIg Y2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBBbmQgdGhpczo8YnIgY2xhc3M9IiI+ DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDtbLi4uXSZuYnNwOyBJbiBhZGRp dGlvbiwgdGhlIG9mZmVyZXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwO01VU1QgaW5z ZXJ0IGFuIFNEUCAnc2V0dXAnIGF0dHJpYnV0ZSBhY2NvcmRpbmcgdG8gdGhlIHByb2NlZHVyZXMg aW48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1tSRkM0MTQ1XSwgYW5kIGFuIFNEUCAn ZmluZ2VycHJpbnQnIGF0dHJpYnV0ZSBhY2NvcmRpbmcgdG8gdGhlPGJyIGNsYXNzPSIiPg0KJmd0 OyZuYnNwOyAmbmJzcDtwcm9jZWR1cmVzIGluIFtSRkM0NTcyXSwgaW4gdGhlIG9mZmVyLjxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFdoaWNoIGRvZXNuJ3QgZGVhbCB3aXRo IG11bHRpcGxlIGNlcnRpZmljYXRlcy48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyBJIGFsc28gc2VlOjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwO1RoZTxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7c3ViamVjdEFsdE5h bWUgaXMgbm90IGFuIGltcG9ydGFudCBjb21wb25lbnQgb2YgdGhlIGNlcnRpZmljYXRlPGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDt2ZXJpZmljYXRpb24uPGJyIGNsYXNzPSIiPg0KJmd0 OzxiciBjbGFzcz0iIj4NCiZndDsgV2hpY2ggaXMgdHJ1ZSBidXQgaW5zdWZmaWNpZW50OyB0aGUg dGV4dCBjYW4gc2ltcGx5IHNheSB0aGF0IHRoZTxiciBjbGFzcz0iIj4NCiZndDsgY2VydGlmaWNh dGUgaXMgb25seSBhIHJlY2VwdGFjbGUgZm9yIGEgcHVibGljIGtleSBhbmQgYXV0aGVudGljYXRp b248YnIgY2xhc3M9IiI+DQomZ3Q7IGlzIHRpZWQgdG8gYW4gYT1maW5nZXJwcmludCBsaW5lIGlu IHRoZSBTRFAuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgQW5kIHRoaXM6 PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7VGhpcyBv ZmZlciBpbmNsdWRlcywgYXMgcGFydCBvZiB0aGUgU0RQIHBheWxvYWQsIHRoZSBmaW5nZXJwcmlu dCBvZjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7dGhlIGNlcnRpZmljYXRlIHRoYXQg dGhlIGVuZHBvaW50IHdhbnRzIHRvIHVzZS4mbmJzcDsgVGhlIGVuZHBvaW50IFNIT1VMRDxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFdoaWNoIHNob3VsZCBiZSBwbHVyYWwg ZmluZ2VycHJpbnQqcyouPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVGhl IHBhdHRlcm4gcmVwZWF0cyB0aHJvdWdob3V0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KbW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0 PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj PC9hPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_8C8A7D25BFB2488CB3357FC531A68EF8vidyocom_-- From nobody Thu Feb 25 11:27:48 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 22F891B32AE for ; Thu, 25 Feb 2016 11:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 VfGFoUGyHR7O for ; Thu, 25 Feb 2016 11:27:45 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 B6D5F1B32B1 for ; Thu, 25 Feb 2016 11:27:45 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id 9so94026218iom.1 for ; Thu, 25 Feb 2016 11:27:45 -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; bh=fjUbgl392KBM2SBaMD4YjR2l3s8C8CnzsWR4ZkQITjI=; b=ddRD+77O2MMib1AqX8UzBADGC9OOeLp8oHVMg+IYpn9vxhP8MDxXTmzsMSaGGVZ48y qQhrExocHQyjgsRuTEBKmrtxbZKPmLTy53rzVwLTOzHaD/i8z4BdfUT5e9799zTWZ8L5 /gQQ6j8QG053zsq5l6CmelNYMisZz1L2PDGiv+ggGs/9o10gIAnC3Coun1z9dYtF89N3 9b9ttic/DXjzmRb83MFxL8g1Sahawz23ARWICO6d6t2Sjn91sI7Ipv1vyVIrUpNwD3WP A2rLXJouj6gT3CFH+Cwe1fuIov95PTTkQ/XPs8FYM95Az6jQ03YEThmHGf0ijZPr4VNN OsmA== 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; bh=fjUbgl392KBM2SBaMD4YjR2l3s8C8CnzsWR4ZkQITjI=; b=hXGeq+6HNwUTVvw3LVL6HGYdisFZnqkvmpztHmQeki/CGe5pE85XvtU5lIt7tWmdVH i/kRsuBFM6Hl0vewBhV2S0J7pGbggHPBryQMW19RTrMC3d2G0qkecwtnG8ZEtkE+5rxG p4NTnn7Y2KApD+S/Z2my3vsIE9CZuEw1awrR/DxgQZEWpaphV8H5QEV8t0LefeWDxeBg lfh4uMhbNSPZiD9+D3m503Cbx/U+hvP2EBiKQilycbxacyTjNx0fbEFd7YB7o8O4gp2k G7TWDne98RZ59+OT9M8Cr2E0C+QmnRk8+gf9iE1Lar6fdgV5YIMR6DlqdbcoUhKkKJli GeCw== X-Gm-Message-State: AG10YOQKEr96zg8I1PXNTm3sxXzzrpoxsgfsK1L9V043jWGyLMJq4EppTwHVeecu7R+c0g== X-Received: by 10.107.170.79 with SMTP id t76mr5593910ioe.71.1456428465084; Thu, 25 Feb 2016 11:27:45 -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 p8sm1831828iga.10.2016.02.25.11.27.43 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 11:27:43 -0800 (PST) Received: by mail-io0-f180.google.com with SMTP id g203so99170165iof.2 for ; Thu, 25 Feb 2016 11:27:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr4246404ioe.38.1456428463064; Thu, 25 Feb 2016 11:27:43 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 11:27:43 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E411AC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E411AC@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 14:27:43 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b4722e926a052c9d2dbc Archived-At: Cc: "mmusic@ietf.org" , "pkyzivat@alum.mit.edu" Subject: Re: [MMUSIC] Aligning RFC 4572 and draft-dtls-sdp regarding preferred SHA cipher? 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, 25 Feb 2016 19:27:47 -0000 --001a1140b4722e926a052c9d2dbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 25, 2016 at 4:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > RFC 4572 (tls-sdp) contains the following text: > > > > =E2=80=9CFollowing RFC 3279 [7] as updated by RFC > > 4055 [9], therefore, the defined hash functions are 'SHA-1' > [11] > > [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], > 'SHA-512' [11], > > 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred.=E2=80= =9D > > > > Draft-dtls-sdp contains the following text: > > > > =E2=80=9CEndpoints MUST support SHA-256 for generating and verifying the > fingerprint > > value associated with the DTLS association. The use of > SHA-256 is preferred.=E2=80=9D > > > > I.e. for TLS SHA-1 is preferred, and for DTLS SHA-256 is preferred. > > > > Martin suggested (I assume) that we should update RFC 4572, to make > SHA-256 preferred also for TLS. > > > > Assuming we do the update, I guess the updated 4572 text would say: > > > > =E2=80=9CFollowing RFC 3279 [7] as updated by RFC > > 4055 [9], therefore, the defined hash functions are 'SHA-1' > [11] > > [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], > 'SHA-512' [11], > > 'MD5' [12], and 'MD2' [13], with 'SHA-256' preferred.=E2=80= =9D > > > > > > Q1: Do people agree to updating the preferred cipher in 4572? > > > > Q3: IF(Q1) Should the update be done within draft-dtls-sdp, or > should we create a separate draft/milestone for it? > > > I think the has function preference should be updated in 4572. I would prefer a separate draft for RFC 4572 update. There are enough issues with RFC 4572, including handling of multiple fingerprints, that justify a complete rewrite of TLS SDP negotiation procedures. If it would be decided that RFC 4572 should be updated in draft-dtls-sdp (not my preference), I would prefer to extend the draft to cover SDP for DTLS and TLS, so that it obsoletes RFC 4572 instead of patching it. Regards, _____________ Roman Shpount --001a1140b4722e926a052c9d2dbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 25, 2016 at 4:51 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

RFC 4572 (tls-sdp) contains the following text:
<= /p>

=C2=A0

=E2=80=9CFollowing RFC 32= 79 [7] as updated by RFC

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 4055 [9], therefore, the defined hash functions are &= #39;SHA-1' [11]

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [19], 'SHA-224' [11], 'SHA-256' [11],= 'SHA-384' [11], 'SHA-512' [11],

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 'MD5' [12], and 'MD2' [13], with '= ;SHA-1' preferred.=E2=80=9D

=C2=A0

Draft-dtls-sdp contains the following text:

=C2=A0

=E2=80=9CEndpoints MUST s= upport SHA-256 for generating and verifying the fingerprint

=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=A0value associated with the DTLS association. The= use of SHA-256 is preferred.=E2=80=9D

=C2=A0

I.e. for TLS SHA-1 is preferred, and for DTLS SHA-25= 6 is preferred.

=C2=A0

Martin suggested (I assume) that we should update RF= C 4572, to make SHA-256 preferred also for TLS.

=C2=A0

Assuming we do the update, I guess the updated 4572 = text would say:

=C2=A0

=E2=80=9CFollowing RFC 32= 79 [7] as updated by RFC

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 4055 [9], therefore, the defined hash functions are &= #39;SHA-1' [11]

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [19], 'SHA-224' [11], 'SHA-256' [11],= 'SHA-384' [11], 'SHA-512' [11],

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 'MD5' [12], and 'MD2' [13], with '= ;SHA-256' preferred.=E2=80=9D

=C2=A0

=C2=A0

Q1:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do peo= ple agree to updating the preferred cipher in 4572?

=C2=A0

Q3:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IF(Q1)= Should the update be done within draft-dtls-sdp, or should we create a sep= arate draft/milestone for it?



I think the has function preference should be updated in 4572. I would pre= fer a separate draft for RFC 4572 update. There are enough issues with RFC = 4572, including handling of multiple fingerprints, that justify a complete = rewrite of TLS SDP negotiation procedures. If it would be decided that RFC = 4572 should be updated in draft-dtls-sdp (not my preference), I would prefe= r to extend the draft to cover SDP for DTLS and TLS, so that it obsoletes R= FC 4572 instead of patching it.=C2=A0

Regards,
_____________
Roman Shpount=
=C2=A0
--001a1140b4722e926a052c9d2dbc-- From nobody Thu Feb 25 11:31:30 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 A81791B327D for ; Thu, 25 Feb 2016 11:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 pU4h62kXkfrQ for ; Thu, 25 Feb 2016 11:31:27 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 6ACAC1B2A8F for ; Thu, 25 Feb 2016 11:31:27 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id y8so20817553igp.1 for ; Thu, 25 Feb 2016 11:31:27 -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; bh=c/r+Td3xgtmdsZfTW+rKmbvsobz0VsDmr4vtZb7n4Qk=; b=GIQI2bprGYBBzLxx5cy0gSchNgzI6ySpC1/ysdXndShE/w3jq6Dir/wNRduWng239z KzW1gimRQhRHHj+c8zYfJSH5to+infR0kfAYxDR8Z+0Ge78EahsojX0jm9SsjCCP2k/+ EAQZAhFq3pSctm4Q/tKxPd5idjk3RWZn0AeWMaML8HFq1vIo0mWK9zyzKVN0r5WGQ90H q8FCH89ZUZR1ByZ5WJgDgPLNPsQ7rPxRT2thbyi56yTUkBn5qm4xB0Ok76kPTpul9GfB CDwYVJaMSBCWBCQaBSt+vsyZKL6hUU1Dqi1+bzIu+J1g4y5eplubRaToU6le78WDoEQq /+/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; bh=c/r+Td3xgtmdsZfTW+rKmbvsobz0VsDmr4vtZb7n4Qk=; b=lhvtvUwkNGT6+9c/ZorZC97T1OirdwK+jRp+l8i0uAc3ALs4Qu/vLxH82HFeAxxAyA Hcr7+F/ZdJ6o+NrDoZRcjYjylBOx1ikiCMu7Q79uKnUjl7oLdPmmQGeoN+p49JiV3Woq SYGPJ+khE+qn9mFWffCPAHVl99J19IS6AMCvjpEO+w9/hAcqxQFV+6Z3kb+/LePIEYGc tenyrFi2b8vfTp2pBRtFIYq0F9YLI1mpn5907g1Ew9EQ+HCl9OhVxElqBBHWCsFbn+yA uja+McW++JmGEewz90/klVqfGYXChN57/mszqKmIEc96Um+49HaOxGAkYAcpUBFlS0Rh lbVQ== X-Gm-Message-State: AG10YOSrv20AmW1w82rGrCrSKS0ViqBkYMPfxETpYZKn3aEgTMCBd2OUOG8EHn5nt0iELg== X-Received: by 10.50.73.161 with SMTP id m1mr373806igv.48.1456428686766; Thu, 25 Feb 2016 11:31:26 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id m3sm3843578ioe.2.2016.02.25.11.31.25 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 11:31:25 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id z135so100039454iof.0 for ; Thu, 25 Feb 2016 11:31:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr4259262ioe.38.1456428684743; Thu, 25 Feb 2016 11:31:24 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 11:31:24 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4436F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E4436F@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 14:31:24 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1140b472651e30052c9d3acc Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder 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, 25 Feb 2016 19:31:28 -0000 --001a1140b472651e30052c9d3acc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Should we consider this an update to RFC 3264 or a new draft which updates PT only? Regards, _____________ Roman Shpount On Thu, Feb 25, 2016 at 2:12 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I created a GitHub repo, and added an initial version of a draft, > containing my initially suggested text modification. We=E2=80=99ll update= it as we > move along, and submit the draft when/if the community agrees that is > something we should do. > > > > https://github.com/cdh4u/draft-oa-pt > > > > (NOTE: It=E2=80=99s a personal repo) > > > > Regards, > > > > Christer > > > --001a1140b472651e30052c9d3acc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Should we consider this an update to RFC 3264 or a new dra= ft which updates PT only?

Regards,

__________= ___
Roman Shpount

On Thu, Feb 25, 2016 at 2:12 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

I created a GitHub repo, and added an= initial version of a draft, containing my initially suggested text modific= ation. We=E2=80=99ll update it as we move along, and submit the draft when/if the community agrees tha= t is something we should do.

=C2=A0

https://github.com/cdh4u/draft-oa-pt

=C2=A0

(NOTE: It=E2=80=99s a personal repo)<= u>

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0


--001a1140b472651e30052c9d3acc-- From nobody Thu Feb 25 11:57: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 E63241B3394 for ; Thu, 25 Feb 2016 11:57: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, 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 WKnQNCyL9S0G for ; Thu, 25 Feb 2016 11:57:30 -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 A66021B338E for ; Thu, 25 Feb 2016 11:57:29 -0800 (PST) X-AuditID: c1b4fb30-f79ec6d000002212-d4-56cf5ca7931a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.3F.08722.7AC5FC65; Thu, 25 Feb 2016 20:57:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 20:57:27 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder Thread-Index: AdFwAB30Yfghq8MmS6WAxjOJMso47P//9ToA///pHeA= Date: Thu, 25 Feb 2016 19:57:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E44467@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E4436F@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_7594FB04B1934943A5C02806D1A2204B37E44467ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7ru7ymPNhBp0TNCymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlPJ6qV3AgtOLszwusDYxT grsYOTkkBEwkzvzdwgZhi0lcuLceyObiEBI4zCjR+Ww2C4SzmFFi06+3jF2MHBxsAhYS3f+0 QRpEBFQl/n6fzARiMwv4Srxc8IUZxBYW8JbofbiQEaLGR+LZxX2sELaVxLqfF8HqWYB6F1/c DraYF6j39psd7BC7pjBKvF7fBtbMKRAosWD6BrAiRqDrvp9aA7VMXOLWk/lMEFcLSCzZc54Z whaVePn4HyuErSSx9vB2Foj6fIm1m/YyQywTlDg58wnLBEbRWUhGzUJSNgtJ2Sygl5kFNCXW 79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzA+Du4 5bfBDsaXzx0PMQpwMCrx8G74ezZMiDWxrLgy9xCjBAezkgjvydDzYUK8KYmVValF+fFFpTmp xYcYpTlYlMR5VzuvDxMSSE8sSc1OTS1ILYLJMnFwSjUw+kqqP/thF7g/dlOGuMzhQiaJ/S5H w1d1vJr1kckouGZGR0ppTJJ9ZkzNDyaFO0tV2e+vX79j2boi1mDP86vVI6Lqu6fo7rlatrx0 16E7uWlprZ02PrGbjD7za7Ewb57fyLNJkaX17qGWPDPzf0aWIvaZtwRXnv4b/64/2Wh2zYQ5 xyoe9O1QYinOSDTUYi4qTgQARi+SBrsCAAA= Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder 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, 25 Feb 2016 19:57:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E44467ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5TaG91bGQgd2UgY29uc2lkZXIgdGhpcyBhbiB1cGRhdGUgdG8gUkZDIDMyNjQgb3Ig YSBuZXcgZHJhZnQgd2hpY2ggdXBkYXRlcyBQVCBvbmx5Pw0KDQpXZWxsLCBQVCBpcyB3aGF0IHN0 YXJ0ZWQgdGhlIGRpc2N1c3Npb24gOikNCg0KRG8geW91IGhhdmUgYSBsaXN0IG9mIG90aGVyIHRo aW5ncyB5b3UgdGhpbmsgbmVlZHMgYW4gdXBkYXRlPw0KDQpPYnZpb3VzbHksIGlmIHRoZXJlIGFy ZSBsb3RzIG9mIHVwZGF0ZXMsIHdlIG5lZWQgdG8gc3RhcnQgY29uc2lkZXJpbmcgYSBiaXPigKYN Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX18NCk9uIFRodSwgRmViIDI1LCAyMDE2IGF0IDI6 MTIgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkkg Y3JlYXRlZCBhIEdpdEh1YiByZXBvLCBhbmQgYWRkZWQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEg ZHJhZnQsIGNvbnRhaW5pbmcgbXkgaW5pdGlhbGx5IHN1Z2dlc3RlZCB0ZXh0IG1vZGlmaWNhdGlv bi4gV2XigJlsbCB1cGRhdGUgaXQgYXMgd2UgbW92ZSBhbG9uZywgYW5kIHN1Ym1pdCB0aGUgZHJh ZnQgd2hlbi9pZiB0aGUgY29tbXVuaXR5IGFncmVlcyB0aGF0IGlzIHNvbWV0aGluZyB3ZSBzaG91 bGQgZG8uDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1vYS1wdA0KDQooTk9URTog SXTigJlzIGEgcGVyc29uYWwgcmVwbykNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37E44467ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+U2hvdWxkIHdlIGNv bnNpZGVyIHRoaXMgYW4gdXBkYXRlIHRvIFJGQyAzMjY0IG9yIGEgbmV3IGRyYWZ0IHdoaWNoIHVw ZGF0ZXMgUFQgb25seT88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldl bGwsIFBUIGlzIHdoYXQgc3RhcnRlZCB0aGUgZGlzY3Vzc2lvbiA6KTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RG8geW91IGhhdmUgYSBsaXN0IG9mIG90aGVyIHRo aW5ncyB5b3UgdGhpbmsgbmVlZHMgYW4gdXBkYXRlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+T2J2aW91c2x5LCBpZiB0aGVyZSBhcmUgbG90cyBvZiB1cGRhdGVz LCB3ZSBuZWVkIHRvIHN0YXJ0IGNvbnNpZGVyaW5nIGEgYmlz4oCmPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBGZWIgMjUsIDIwMTYgYXQgMjoxMiBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRh cmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgY3JlYXRlZCBhIEdpdEh1YiBy ZXBvLCBhbmQgYWRkZWQgYW4gaW5pdGlhbCB2ZXJzaW9uIG9mIGEgZHJhZnQsIGNvbnRhaW5pbmcg bXkgaW5pdGlhbGx5IHN1Z2dlc3RlZA0KIHRleHQgbW9kaWZpY2F0aW9uLiBXZeKAmWxsIHVwZGF0 ZSBpdCBhcyB3ZSBtb3ZlIGFsb25nLCBhbmQgc3VibWl0IHRoZSBkcmFmdCB3aGVuL2lmIHRoZSBj b21tdW5pdHkgYWdyZWVzIHRoYXQgaXMgc29tZXRoaW5nIHdlIHNob3VsZCBkby48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vY2RoNHUvZHJhZnQtb2EtcHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1 Yi5jb20vY2RoNHUvZHJhZnQtb2EtcHQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+KE5PVEU6IEl04oCZcyBhIHBlcnNvbmFsIHJlcG8pPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37E44467ESESSMB209erics_-- From nobody Thu Feb 25 12:02: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 1813D1B33D6 for ; Thu, 25 Feb 2016 12:02:01 -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 6dMK9-uiY555 for ; Thu, 25 Feb 2016 12:01:59 -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 00BD31B3469 for ; Thu, 25 Feb 2016 12:01:19 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-d7-56cf5d8d767a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 19.15.28465.D8D5FC65; Thu, 25 Feb 2016 21:01:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 21:01:17 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: Aligning RFC 4572 and draft-dtls-sdp regarding preferred SHA cipher? Thread-Index: AQHRcAKbCMtOTN/OL0exiSX7tCPD3589Lb7A Date: Thu, 25 Feb 2016 20:01:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E44499@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E411AC@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_7594FB04B1934943A5C02806D1A2204B37E44499ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7q25v7PkwgyUNJhbXzvxjtJi6/DGL xYoNB1gtZlyYyuzA4vH3/Qcmj52z7rJ7LFnyk8nj1pSCAJYoLpuU1JzMstQifbsEroyLG9cy FnS0MVa87v7E3sC4p4mxi5GDQ0LAROLVX54uRk4gU0ziwr31bF2MXBxCAocZJXY83s0OkhAS WMwocfadA0g9m4CFRPc/bZCwiICqxN/vk5lA6pkFljBK/Nu2kAUkISwQLLFj/X1miKIQieZb T5ggbCOJW1MOs4HYLEDNc2YfYAWxeQV8Jd5+OcsKsXgKo8SMbY/BijgFAiUeLTgLZjMCXff9 1BqwQcwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbCWJtYe3s0DU50v8WPWcBWKZoMTJmU9Y JjCKzkIyahaSsllIymYB/cwsoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzGKFqcWF+em GxnrpRZlJhcX5+fp5aWWbGIExuXBLb91dzCufu14iFGAg1GJh3fD37NhQqyJZcWVuYcYJTiY lUR4T4aeDxPiTUmsrEotyo8vKs1JLT7EKM3BoiTOu8Z5fZiQQHpiSWp2ampBahFMlomDU6qB UXgtj+7Sa12TJ1kUNVcsrDo6/d3BSWqmrR6P5Vc+/fbfK3Txehm2y3u/Tbh7XHsC6wyl1N2J f0/l9E9fUir44eYUf7+480//Hrnq2hb2pebvWp0Yjduiu5V2n7DRzG6svL5356VpZ2bFn/jb uOjCbIVePgvj42eEFNxYree06Db5hsjNrttlMkGJpTgj0VCLuag4EQCLCbeLxwIAAA== Archived-At: Cc: "mmusic@ietf.org" , "pkyzivat@alum.mit.edu" Subject: Re: [MMUSIC] Aligning RFC 4572 and draft-dtls-sdp regarding preferred SHA cipher? 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, 25 Feb 2016 20:02:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E44499ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIHdlIHRoaW5rIHRoZSB1cGRhdGUgdG8gNDU3MiB3aWxsIGJlIG1vcmUgdGhhbiDi gJxhIGZldyBzZW50ZW5jZXPigJ0sIEkgYWdyZWUgd2Ugc2hvdWxkIHByb2JhYmx5IGhhdmUgYSBz ZXBhcmF0ZSBkcmFmdC4gV2UgYXJlIGFscmVhZHkgdXBkYXRpbmcgdHdvIFJGQ3MgaW4gZHJhZnQt ZHRscy1zZHAsIHNv4oCmDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNo cG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDI1IEZlYnJ1YXJ5IDIwMTYg MjE6MjgNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPg0KQ2M6IG1tdXNpY0BpZXRmLm9yZzsgTWFydGluIFRob21zb24gKG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbSkgPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IHBreXppdmF0QGFsdW0ubWl0 LmVkdQ0KU3ViamVjdDogUmU6IEFsaWduaW5nIFJGQyA0NTcyIGFuZCBkcmFmdC1kdGxzLXNkcCBy ZWdhcmRpbmcgcHJlZmVycmVkIFNIQSBjaXBoZXI/DQoNCk9uIFRodSwgRmViIDI1LCAyMDE2IGF0 IDQ6NTEgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KUkZDIDQ1 NzIgKHRscy1zZHApIGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0K4oCcRm9sbG93aW5n IFJGQyAzMjc5IFs3XSBhcyB1cGRhdGVkIGJ5IFJGQw0KICAgICAgICAgICAgICA0MDU1IFs5XSwg dGhlcmVmb3JlLCB0aGUgZGVmaW5lZCBoYXNoIGZ1bmN0aW9ucyBhcmUgJ1NIQS0xJyBbMTFdDQog ICAgICAgICAgICAgIFsxOV0sICdTSEEtMjI0JyBbMTFdLCAnU0hBLTI1NicgWzExXSwgJ1NIQS0z ODQnIFsxMV0sICdTSEEtNTEyJyBbMTFdLA0KICAgICAgICAgICAgICAnTUQ1JyBbMTJdLCBhbmQg J01EMicgWzEzXSwgd2l0aCAnU0hBLTEnIHByZWZlcnJlZC7igJ0NCg0KRHJhZnQtZHRscy1zZHAg Y29udGFpbnMgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQrigJxFbmRwb2ludHMgTVVTVCBzdXBwb3J0 IFNIQS0yNTYgZm9yIGdlbmVyYXRpbmcgYW5kIHZlcmlmeWluZyB0aGUgZmluZ2VycHJpbnQNCiAg ICAgICAgICAgICAgIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgRFRMUyBhc3NvY2lhdGlvbi4g VGhlIHVzZSBvZiBTSEEtMjU2IGlzIHByZWZlcnJlZC7igJ0NCg0KSS5lLiBmb3IgVExTIFNIQS0x IGlzIHByZWZlcnJlZCwgYW5kIGZvciBEVExTIFNIQS0yNTYgaXMgcHJlZmVycmVkLg0KDQpNYXJ0 aW4gc3VnZ2VzdGVkIChJIGFzc3VtZSkgdGhhdCB3ZSBzaG91bGQgdXBkYXRlIFJGQyA0NTcyLCB0 byBtYWtlIFNIQS0yNTYgcHJlZmVycmVkIGFsc28gZm9yIFRMUy4NCg0KQXNzdW1pbmcgd2UgZG8g dGhlIHVwZGF0ZSwgSSBndWVzcyB0aGUgdXBkYXRlZCA0NTcyIHRleHQgd291bGQgc2F5Og0KDQri gJxGb2xsb3dpbmcgUkZDIDMyNzkgWzddIGFzIHVwZGF0ZWQgYnkgUkZDDQogICAgICAgICAgICAg IDQwNTUgWzldLCB0aGVyZWZvcmUsIHRoZSBkZWZpbmVkIGhhc2ggZnVuY3Rpb25zIGFyZSAnU0hB LTEnIFsxMV0NCiAgICAgICAgICAgICAgWzE5XSwgJ1NIQS0yMjQnIFsxMV0sICdTSEEtMjU2JyBb MTFdLCAnU0hBLTM4NCcgWzExXSwgJ1NIQS01MTInIFsxMV0sDQogICAgICAgICAgICAgICdNRDUn IFsxMl0sIGFuZCAnTUQyJyBbMTNdLCB3aXRoICdTSEEtMjU2JyBwcmVmZXJyZWQu4oCdDQoNCg0K UTE6ICAgICAgICBEbyBwZW9wbGUgYWdyZWUgdG8gdXBkYXRpbmcgdGhlIHByZWZlcnJlZCBjaXBo ZXIgaW4gNDU3Mj8NCg0KUTM6ICAgICAgICBJRihRMSkgU2hvdWxkIHRoZSB1cGRhdGUgYmUgZG9u ZSB3aXRoaW4gZHJhZnQtZHRscy1zZHAsIG9yIHNob3VsZCB3ZSBjcmVhdGUgYSBzZXBhcmF0ZSBk cmFmdC9taWxlc3RvbmUgZm9yIGl0Pw0KDQoNCkkgdGhpbmsgdGhlIGhhcyBmdW5jdGlvbiBwcmVm ZXJlbmNlIHNob3VsZCBiZSB1cGRhdGVkIGluIDQ1NzIuIEkgd291bGQgcHJlZmVyIGEgc2VwYXJh dGUgZHJhZnQgZm9yIFJGQyA0NTcyIHVwZGF0ZS4gVGhlcmUgYXJlIGVub3VnaCBpc3N1ZXMgd2l0 aCBSRkMgNDU3MiwgaW5jbHVkaW5nIGhhbmRsaW5nIG9mIG11bHRpcGxlIGZpbmdlcnByaW50cywg dGhhdCBqdXN0aWZ5IGEgY29tcGxldGUgcmV3cml0ZSBvZiBUTFMgU0RQIG5lZ290aWF0aW9uIHBy b2NlZHVyZXMuIElmIGl0IHdvdWxkIGJlIGRlY2lkZWQgdGhhdCBSRkMgNDU3MiBzaG91bGQgYmUg dXBkYXRlZCBpbiBkcmFmdC1kdGxzLXNkcCAobm90IG15IHByZWZlcmVuY2UpLCBJIHdvdWxkIHBy ZWZlciB0byBleHRlbmQgdGhlIGRyYWZ0IHRvIGNvdmVyIFNEUCBmb3IgRFRMUyBhbmQgVExTLCBz byB0aGF0IGl0IG9ic29sZXRlcyBSRkMgNDU3MiBpbnN0ZWFkIG9mIHBhdGNoaW5nIGl0Lg0KDQpS ZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37E44499ESESSMB209erics_ 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 LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHdlIHRoaW5rIHRoZSB1cGRhdGUgdG8gNDU3MiB3 aWxsIGJlIG1vcmUgdGhhbiDigJxhIGZldyBzZW50ZW5jZXPigJ0sIEkgYWdyZWUgd2Ugc2hvdWxk IHByb2JhYmx5IGhhdmUgYSBzZXBhcmF0ZSBkcmFmdC4gV2UgYXJlIGFscmVhZHkNCiB1cGRhdGlu ZyB0d28gUkZDcyBpbiBkcmFmdC1kdGxzLXNkcCwgc2/igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJv bWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiAyNSBGZWJydWFyeSAyMDE2IDIxOjI4PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g bW11c2ljQGlldGYub3JnOyBNYXJ0aW4gVGhvbXNvbiAobWFydGluLnRob21zb25AZ21haWwuY29t KSAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgcGt5eml2YXRAYWx1bS5taXQuZWR1 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBbGlnbmluZyBSRkMgNDU3MiBhbmQgZHJhZnQtZHRs cy1zZHAgcmVnYXJkaW5nIHByZWZlcnJlZCBTSEEgY2lwaGVyPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRmViIDI1LCAy MDE2IGF0IDQ6NTEgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+UkZDIDQ1NzIgKHRscy1zZHApIGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgdGV4dDo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6MzYuMHB0Ij4NCuKAnEZvbGxv d2luZyBSRkMgMzI3OSBbN10gYXMgdXBkYXRlZCBieSBSRkM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0MDU1IFs5XSwgdGhlcmVmb3JlLCB0 aGUgZGVmaW5lZCBoYXNoIGZ1bmN0aW9ucyBhcmUgJ1NIQS0xJyBbMTFdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzE5XSwgJ1NIQS0yMjQn IFsxMV0sICdTSEEtMjU2JyBbMTFdLCAnU0hBLTM4NCcgWzExXSwgJ1NIQS01MTInIFsxMV0sPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJ01E NScgWzEyXSwgYW5kICdNRDInIFsxM10sIHdpdGggJ1NIQS0xJyBwcmVmZXJyZWQu4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5EcmFmdC1kdGxzLXNkcCBjb250YWlucyB0aGUgZm9sbG93 aW5nIHRleHQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjM2LjBwdCI+ DQrigJxFbmRwb2ludHMgTVVTVCBzdXBwb3J0IFNIQS0yNTYgZm9yIGdlbmVyYXRpbmcgYW5kIHZl cmlmeWluZyB0aGUgZmluZ2VycHJpbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDt2YWx1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIERU TFMgYXNzb2NpYXRpb24uIFRoZSB1c2Ugb2YgU0hBLTI1NiBpcyBwcmVmZXJyZWQu4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JLmUuIGZvciBUTFMgU0hBLTEgaXMgcHJlZmVycmVkLCBh bmQgZm9yIERUTFMgU0hBLTI1NiBpcyBwcmVmZXJyZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5NYXJ0aW4gc3VnZ2VzdGVkIChJIGFzc3VtZSkgdGhhdCB3ZSBzaG91bGQgdXBkYXRlIFJG QyA0NTcyLCB0byBtYWtlIFNIQS0yNTYgcHJlZmVycmVkIGFsc28gZm9yIFRMUy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFzc3VtaW5nIHdlIGRvIHRoZSB1cGRhdGUsIEkgZ3Vlc3MgdGhl IHVwZGF0ZWQgNDU3MiB0ZXh0IHdvdWxkIHNheTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1pbmRlbnQ6MzYuMHB0Ij4NCuKAnEZvbGxvd2luZyBSRkMgMzI3OSBbN10gYXMgdXBkYXRl ZCBieSBSRkM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA0MDU1IFs5XSwgdGhlcmVmb3JlLCB0aGUgZGVmaW5lZCBoYXNoIGZ1bmN0aW9ucyBh cmUgJ1NIQS0xJyBbMTFdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgWzE5XSwgJ1NIQS0yMjQnIFsxMV0sICdTSEEtMjU2JyBbMTFdLCAnU0hB LTM4NCcgWzExXSwgJ1NIQS01MTInIFsxMV0sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJ01ENScgWzEyXSwgYW5kICdNRDInIFsxM10sIHdp dGggJ1NIQS0yNTYnIHByZWZlcnJlZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5RMTombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRG8gcGVvcGxlIGFncmVlIHRvIHVwZGF0 aW5nIHRoZSBwcmVmZXJyZWQgY2lwaGVyIGluIDQ1NzI/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5RMzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSUYoUTEp IFNob3VsZCB0aGUgdXBkYXRlIGJlIGRvbmUgd2l0aGluIGRyYWZ0LWR0bHMtc2RwLCBvciBzaG91 bGQgd2UgY3JlYXRlIGEgc2VwYXJhdGUgZHJhZnQvbWlsZXN0b25lIGZvciBpdD88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSB0aGluayB0aGUgaGFzIGZ1bmN0aW9uIHByZWZlcmVuY2Ugc2hvdWxkIGJlIHVwZGF0ZWQgaW4g NDU3Mi4gSSB3b3VsZCBwcmVmZXIgYSBzZXBhcmF0ZSBkcmFmdCBmb3IgUkZDIDQ1NzIgdXBkYXRl LiBUaGVyZSBhcmUgZW5vdWdoIGlzc3VlcyB3aXRoIFJGQyA0NTcyLCBpbmNsdWRpbmcgaGFuZGxp bmcgb2YgbXVsdGlwbGUgZmluZ2VycHJpbnRzLCB0aGF0IGp1c3RpZnkgYSBjb21wbGV0ZSByZXdy aXRlIG9mIFRMUw0KIFNEUCBuZWdvdGlhdGlvbiBwcm9jZWR1cmVzLiBJZiBpdCB3b3VsZCBiZSBk ZWNpZGVkIHRoYXQgUkZDIDQ1NzIgc2hvdWxkIGJlIHVwZGF0ZWQgaW4gZHJhZnQtZHRscy1zZHAg KG5vdCBteSBwcmVmZXJlbmNlKSwgSSB3b3VsZCBwcmVmZXIgdG8gZXh0ZW5kIHRoZSBkcmFmdCB0 byBjb3ZlciBTRFAgZm9yIERUTFMgYW5kIFRMUywgc28gdGhhdCBpdCBvYnNvbGV0ZXMgUkZDIDQ1 NzIgaW5zdGVhZCBvZiBwYXRjaGluZyBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb21hbiBT aHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37E44499ESESSMB209erics_-- From nobody Thu Feb 25 12:43: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 9E7C91B34FA for ; Thu, 25 Feb 2016 12:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 0KHP_SDSurBo for ; Thu, 25 Feb 2016 12:43:06 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 3E38E1B34F7 for ; Thu, 25 Feb 2016 12:43:06 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id z135so102096610iof.0 for ; Thu, 25 Feb 2016 12:43:06 -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; bh=2wQaBimxYriZN2Kj6SUG5pDzfM4/UEtB0jHD3J5AYN8=; b=I0LptIZTpZ/BFx9+g3NrvHXdH35MjJq7XSYsC62W2mCrFTvjYw4GhlvpOmQJqYvD5F nkuNjbUKoq9nISj+7pX7YMENSglPW5QTbrVJ5rDpvvdIMHiqhkEZzO08gBhkCqC1oC89 nzUPvqyD2DulDnrpEHcUD4WrW5vZruVQlgHG1TU5ci6+NvBgyDcB+gUD9Kudy2QW9t2l dBtEs/5W9yvyEBhNX7c8v7xdSgyDkoroEKOZ6WKIHY0TzCuZ2F0Xl+suODm28Rwgjpxd x2/ozrB0rsR6AlHq4x8WeuZYsC8r3WiA2P61+UOxuaVzPHVZOO1fdGEPBf1VbohZlShC YZnQ== 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; bh=2wQaBimxYriZN2Kj6SUG5pDzfM4/UEtB0jHD3J5AYN8=; b=JxnE3JBKMbPBdQ5UblEOgQu19hr221hhaBZaggPIpGeV0vnXT3qFUeo+ibh17Zjw3Z OYWYBbL/iVbRzNG4QFjbjUOKmJNNlg6Pz2IcTBXLfCS5w8sLktoFjtVlTD8/s2YrRWrf ttwQSszW61c1hf4zYmGWgZHSV74IA0dphReZxBCXc/ri0DqSQ1Ki4KJsA88vIUtU+QUG ItPxD21/FOEn95yO5NRO9JomRSHJWMzKO7j6yXzvlmbGE6FdWAHYmP02sOclR3uBs2S4 HM5g6pJ7z+P6ho1DCPbFRCeSs4oM1anvPc40ydd09lqMNjb5/Qz5U/lOWeGhUyzUTxCD ye5g== X-Gm-Message-State: AG10YOS1S2e/4iSlA1dP9akHAWLyER6ddTW+/ga3L7QA8kYulYSeotH39h4sExzOs0Yfcg== X-Received: by 10.107.198.14 with SMTP id w14mr4867468iof.83.1456432985726; Thu, 25 Feb 2016 12:43:05 -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 n5sm1935538iga.15.2016.02.25.12.43.03 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 12:43:03 -0800 (PST) Received: by mail-io0-f178.google.com with SMTP id g203so101325262iof.2 for ; Thu, 25 Feb 2016 12:43:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr4985830iod.145.1456432983191; Thu, 25 Feb 2016 12:43:03 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 12:43:03 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E44467@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E4436F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44467@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 15:43:03 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113ece609a3c64052c9e3a67 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder 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, 25 Feb 2016 20:43:07 -0000 --001a113ece609a3c64052c9e3a67 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 2:57 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >Should we consider this an update to RFC 3264 or a new draft which > updates PT only? > > > > Well, PT is what started the discussion :) > > Do you have a list of other things you think needs an update? > > > I wanted to clarify the asymmetric PT usage, including things like usage of PT in sendonly streams. _____________ Roman Shpount --001a113ece609a3c64052c9e3a67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 25, 2016 at 2:5= 7 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:

>Shou= ld we consider this an update to RFC 3264 or a new draft which updates PT o= nly?

=C2=A0

Well, PT is what started the discussion :)

Do you have a list of other things you think= needs an update?


I wanted to clarify the asymmetric PT usage, including things = like usage of PT in sendonly streams.
_____________
Roman Shpount
=C2=A0
=
--001a113ece609a3c64052c9e3a67-- From nobody Thu Feb 25 12:51:22 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 B18281B2E21 for ; Thu, 25 Feb 2016 12:51:19 -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 LVySyArVAlpq for ; Thu, 25 Feb 2016 12:51:18 -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 85C4E1A90C7 for ; Thu, 25 Feb 2016 12:51:18 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with comcast id Nkr41s0082Fh1PH01krH64; Thu, 25 Feb 2016 20:51:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id NkrH1s0013KdFy101krHeD; Thu, 25 Feb 2016 20:51:17 +0000 To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF3BD9.7080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4418E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44296@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CF6944.2040103@alum.mit.edu> Date: Thu, 25 Feb 2016 15:51:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.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=1456433477; bh=WN4ufIswvaw+GdraOrsvyCdAtzFahMgtbcM6mQY37Us=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=OMe+lysEbA4vAiuKkuqNFUi+z64APdKQ5fzOdpXY3XtITNsLs//kodZXYIDVym12u wHMsZao89wzmGGCvE8YJ9NqjKGuao/kNO2OSIj1AGm+xnpiAouaw+2622Y68Z8KgvP jptAzEFE2rZGKEuJtHWRCSV9ABiE6nBWTEww3xnMIcvhcVs2VOEApQBh3KRMqUJgIC tJsLhuS4bnODqN4HthdSpWQJEUlCs2WFrZz9BXerIPRwqHsqJ1E0nAPJcvrnwtZfVL gNasCb4GIK+w/3HA5Gdq7uif8Nefvu1yKaw8TaSwJLcJPSagfA1dEzr7tvkk795AMT e7RydFYvCICWg== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 20:51:19 -0000 On 2/25/16 2:06 PM, Roman Shpount wrote: > On Thu, Feb 25, 2016 at 1:51 PM, Christer Holmberg > > > wrote: > > >> So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply with PT 111:PCMU? Both are associated > >> with the same media flow direction, as the offer was sendonly. > > > > These PT are not associated with the same flow direction. Each end point lists PTs it is willing to receive. The end > > point which is sending the sendonly offer has no idea what the other end point is willing to receive and their PT > > preferences. The PT in sendonly are in the direction to sendonly end point, They are simply placeholders and will not be used. > > If so, we should either explicitly specify it, or reference to where > it is already specified. > > > We will probably need to clarify how asymmetric PT in each direction > work with offer/answer. There is a lot of confusion regarding this issue > as well. I agree it would be a good idea to do that. Thanks, Paul From nobody Thu Feb 25 13:03: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 3ACB21B3542 for ; Thu, 25 Feb 2016 13:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 T2hGuxKKDo_Y for ; Thu, 25 Feb 2016 13:03:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711671B350C for ; Thu, 25 Feb 2016 13:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1431; q=dns/txt; s=iport; t=1456434180; x=1457643780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=24INW1XXts4J4U9/MvpIJ19go3V1ig40tAQzIE8iPa8=; b=c1ySrJ7ZlhFHOMqV45CWS/4YDsCxvF79fq3ZWb2ztraGh7TD3U+eRU/w DK8mWdw1alTB+m+gAoc7ScKNapWP1gclFP03QSfq29NT/pwoGx/vdfeR2 jBjpXorfYmEzXdhFa1oxodnAXaro1p4zXvP5T+wjanU8n6Dd3A3YkI36E A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgBia89W/5xdJa1eDoMsUm0GujcBD?= =?us-ascii?q?YFmFwqFIkoCgUM4FAEBAQEBAQFkJ4RBAQEBAwEBAQE3NAsFCwIBCA4KHgkHJws?= =?us-ascii?q?UEQIEDgWIFwgOvHgBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYSgWyCToQzgy2BD?= =?us-ascii?q?wWSc4QVAY1ejnRcjWwBHgEBQoMpO2qHGn4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="80456220" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2016 21:02:59 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1PL2xlA002290 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Feb 2016 21:02:59 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 15:02:58 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Thu, 25 Feb 2016 15:02:58 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wAT0/6AAAHs7oAAAG8qgAAAO5uAAACHAYAAA6XbAAAAaJsA Date: Thu, 25 Feb 2016 21:02:58 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF3BD9.7080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4418E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44296@ESESSMB209.ericsson.se> <56CF6944.2040103@alum.mit.edu> In-Reply-To: <56CF6944.2040103@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.22.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D6322F8C9FB474EA84642881F9263D0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 21:03:02 -0000 > On Feb 25, 2016, at 12:51 PM, Paul Kyzivat wrote: >=20 > On 2/25/16 2:06 PM, Roman Shpount wrote: >> On Thu, Feb 25, 2016 at 1:51 PM, Christer Holmberg >> > >> wrote: >>=20 >> >> So, I send you a sendonly offer with PT 111:VP8, it is ok for you = to reply with PT 111:PCMU? Both are associated >> >> with the same media flow direction, as the offer was sendonly. >> > >> > These PT are not associated with the same flow direction. Each end = point lists PTs it is willing to receive. The end >> > point which is sending the sendonly offer has no idea what the othe= r end point is willing to receive and their PT >> > preferences. The PT in sendonly are in the direction to sendonly en= d point, They are simply placeholders and will not be used. >>=20 >> If so, we should either explicitly specify it, or reference to where >> it is already specified. >>=20 >>=20 >> We will probably need to clarify how asymmetric PT in each direction >> work with offer/answer. There is a lot of confusion regarding this issue >> as well. >=20 > I agree it would be a good idea to do that. I do as well. -G >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Feb 25 13:08: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 CE9E31B3562 for ; Thu, 25 Feb 2016 13:08:03 -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 iqeZpAT67-WW for ; Thu, 25 Feb 2016 13:08:02 -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 3318D1B3560 for ; Thu, 25 Feb 2016 13:08:02 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-07v.sys.comcast.net with comcast id Nl6Z1s0032Fh1PH01l81bL; Thu, 25 Feb 2016 21:08:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id Nl801s00S3KdFy101l81Ha; Thu, 25 Feb 2016 21:08:01 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF3BD9.7080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4418E@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CF6D2F.30302@alum.mit.edu> Date: Thu, 25 Feb 2016 16:07:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4418E@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=1456434481; bh=hnm6TRayi5fnO3mmgVIEcLfRDIocgr/BYUT6XDnQQZI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AOzTVg2xAEOLFYaQ85IwC0eNJyndp52c6Ga1Apgphq2tC1EOKh73TJjrHwvRrZ4PT quMr6CTVE0A2DpnXBUJI+J7AC6dkUj3P/0jmB/MH5uA6XZaxBklIJNOgazkh48HhmR /iEf2B1x5n/7XmSE6DYXNncQY6uCwV4qe+aRFl0MKjQs5AlVJKi5YHbThaBsgpyhtM KmMWQBuZRNigARUsXjZKU0oR0Om8PxGQLkhUp2hALev1Y9KMVoKhtZ7VN36eazoXoX 2LJgO9TdYywWC5nnnPVW4nHaNREkKw54JuCJ24jBT/jHBHy9PFl9CZpRB4gfbRiYYK onCfPX8x0C7UA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 21:08:04 -0000 On 2/25/16 1:32 PM, Christer Holmberg wrote: > Hi, > >>> "The scope of a mapping from a particular dynamic payload type number >>> to a codec (or codec configuration) is for a given RTP media flow direction within a session. >> >> Albrecht raised the question of terminology and of whether "RTP media flow direction" is the right term. I think the concept >> is specific to O/A. In 7656 terms I think it applies to all RTP streams with a particular PT flowing in a single direction between >> two participants in one RTP Session. > > We need to look whether there is existing terminology in 3264, in which case we should use that (or update every instance of the terminology within 3264...) Sounds good. >>> The same dynamic payload type number can be mapped to another codec in >>> another RTP media flow direction within the same session. The mapping >>> MUST NOT change to a different coded (or coded configuration) for the >>> duration of a session. Eventhough not recommended, for a given >>> direction, multiple dynamic payload type numbers can be mapped to the same codec (or codec configuration). >>> >>> Note that a mapping has been created once an endpoint has sent and >>> offer or answer, describing the mapping for a given direction. Even if >>> the offer or answer is rejected or discarded, or if RTP media >>> associated with the mapping is never sent, the mapping MUST NOT change for the given direction within the session. >> >> The paragraph above seems overly strict. Surely it should not be necessary to retain the mapping if the entire offer is rejected. (There isn't any way to reject an answer.) > > Sometimes strict is good :) But, I'm not religious about it, as long as the text is clear on when the mapping has been created. I agree about being clear. IMO we should try not to impose unnecessary restrictions. But if being a little stricter than necessary greatly simplifies the rules then it is worth considering. >> Similarly, if the m-line is rejected (port zero) ISTM that all bindings could be forgotten. (I guess in this case the RTP Session ends so "within the session" covers it.) > > What if an m- line is disabled, using port zero in an *offer*, and later taken back in use? Are the previous mappings still valid? In my opinion they are. Once you have used port zero the RTP session is *gone*. If you then recycle the m-line with a valid addr/port you are establishing a *new* RTP session, so the old bindings are gone and you start building a new set. >>> Within an offer or answer, the mapping is for the RTP media flow >>> direction towards the offerer/answerer, unless the media flow is >>> indicated as 'sendonly' in which case the mapping is for the media flow direction from the offerer/answerer." >> >> ISTM that no bindings should be created for sendonly m-lines. (AFAIK the PT mentioned in a sendonly offer/answer never appears on the wire in >> RTP/RTCP.) > > So, I send you a sendonly offer with PT 111:VP8, it is ok for you to reply with PT 111:PCMU? Both are associated with the same media flow direction, as the offer was sendonly. The following from 3264 applies in this case: For streams marked as recvonly in the answer, the "m=" line MUST contain at least one media format the answerer is willing to receive with from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to receive. So if you *only* offered PT 111:VP8, then the answer MUST include VP8. (Preferably with PT 111, but it could be some other PT.) It could *also* include PCMU. So PT 110:VP8, PT 111:PCMU would be valid. If I can't accept VP8, then I guess I have to either reject the m-line or else reject the offer. IMO the MUST is too restrictive. It ought to be SHOULD. But changing that is a separate issue. Thanks, Paul > Regards, > > Christer > > > > OTOH, as a session is modified (by additional O/As), bindings need to be retained even if sendonly is sometimes used. > > Thanks, > Paul > >> Note that the text probably needs some fine tuning, but please take a look and see whether you are ok with the approach, and whether you think the text covers the issues we've discovered. >> >> 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 Thu Feb 25 13:15: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 0DBC31B3579 for ; Thu, 25 Feb 2016 13:15:06 -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 7fm816zUdGEV for ; Thu, 25 Feb 2016 13:15:05 -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 D91201B3576 for ; Thu, 25 Feb 2016 13:15:04 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-12v.sys.comcast.net with comcast id NlDh1s0072XD5SV01lF4xY; Thu, 25 Feb 2016 21:15:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id NlF31s00E3KdFy101lF3SA; Thu, 25 Feb 2016 21:15:03 +0000 To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37E4436F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44467@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CF6ED6.5040201@alum.mit.edu> Date: Thu, 25 Feb 2016 16:15:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E44467@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456434904; bh=MrkBXr0/bpAqDemSz5AT7As7xIkquq2norFLUGsn2Vg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SMPybS5qeweLMzZZueBCxq0N5BgqqX3sD3fUsoN1LW7+ybBFha/vaqpHjnDEPiywt O6eEVxA5uvTbcu68t8s9BOeIJisYYFWiWHU1mdeOg1l3FgD1wXZ76r7J2EzE0AVWb3 rqf4/C5OEKxIv+me52jcyPs+OLFZ16HQaTNGI6vjLNwTntm/T5+l1KnOEp0S8NakDs YwdcGDwMqTumznCLGKZm6tUr5lakBNNgzWbJkWb/YDGHQANAgmc8Wh83wKAurTSjQU e2UKLgLi3k8iHorEuFRhRsKULE5bK+PARxVpu5KXr8FL4QzNUByoPMP//xw9Ka5F+G 8sXdvCJFN7sqw== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder 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, 25 Feb 2016 21:15:06 -0000 I think it is worth *considering* doing a 3264bis. Surely it could use it. OTOH it will open Pandora's box and probably become a relatively big project. (But I think not as big as 4566bis, and certainly not as big as 3261bis would be.) So maybe we just float the question to the wg: *if* we were to do a 3264bis, what things need to be fixed? And of those, how many would be clarifications vs. those that would be functional changes? Thanks, Paul On 2/25/16 2:57 PM, Christer Holmberg wrote: > Hi, > >>Should we consider this an update to RFC 3264 or a new draft which > updates PT only? > > Well, PT is what started the discussion :) > > Do you have a list of other things you think needs an update? > > Obviously, if there are lots of updates, we need to start considering a bis… > > Regards, > > Christer > > __ > > On Thu, Feb 25, 2016 at 2:12 PM, Christer Holmberg > > > wrote: > > Hi, > > I created a GitHub repo, and added an initial version of a draft, > containing my initially suggested text modification. We’ll update it > as we move along, and submit the draft when/if the community agrees > that is something we should do. > > https://github.com/cdh4u/draft-oa-pt > > (NOTE: It’s a personal repo) > > Regards, > > Christer > From nobody Thu Feb 25 13:18: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 D20D41B3582 for ; Thu, 25 Feb 2016 13:18:06 -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 eKzXtp9BoLTw for ; Thu, 25 Feb 2016 13:18:06 -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 6A42B1B3578 for ; Thu, 25 Feb 2016 13:18:04 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-02v.sys.comcast.net with comcast id NlHs1s0092Bo0NV01lJ3tu; Thu, 25 Feb 2016 21:18:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id NlJ31s0033KdFy101lJ3bG; Thu, 25 Feb 2016 21:18:03 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37E4436F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E44467@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CF6F89.5060102@alum.mit.edu> Date: Thu, 25 Feb 2016 16:18:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: 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=1456435083; bh=keTtut9mu/u9/wq4+GEqy1BRk4VdBvT5SxaNte6jWDs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Wx4KrbRFhX3Il3W4M5fbYcGrNghY1nw81hrCretjEfcc55u8QgbKHB3yY3S4M5kBb xLJ4O8l0AW0fxaCW4YfObFZFy4MxQW1Y6e3/5KekZ2jUm67myP5sH2TWfYHs5agMoy IF0lVUIA4dHA/hxhr8X1FLooxWf1OlC+RTSKHgLFihK2fdDwCJraZinSdvoHyw36Z9 9PibAd4mp5H1dpLggaMZJrtFnDukIzoZPwhGUE/inLYjUgGyjBYmhPwaalxQdFI+ij N00nx8nTNnhJ/r0ElURozptWJkc2kltaM2HVoujXxo3/RXrIeQPL1grNNEiVVPYRgN zKdyqty02SJ1Q== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - GitHub draft place holder 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, 25 Feb 2016 21:18:07 -0000 On 2/25/16 3:43 PM, Roman Shpount wrote: > > On Thu, Feb 25, 2016 at 2:57 PM, Christer Holmberg > > > wrote: > > >Should we consider this an update to RFC 3264 or a new draft which > updates PT only? > > __ > > __ __ > > Well, PT is what started the discussion :)____ > > Do you have a list of other things you think needs an update? > > > > I wanted to clarify the asymmetric PT usage, including things like usage > of PT in sendonly streams. Yes. A *lot* of things came up in both webrtc and clue. But they are mostly general issues due to multiple media streams per RTP session. And when you have those you end up with asymmetric cases. Thanks, Paul From nobody Thu Feb 25 13:39: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 BAFC81B353D for ; Thu, 25 Feb 2016 13:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=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 yXgy-7WKGfgF for ; Thu, 25 Feb 2016 13:38:58 -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 D35991B35BC for ; Thu, 25 Feb 2016 13:38:57 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-12v.sys.comcast.net with comcast id NleE1s0042S2Q5R01lex9t; Thu, 25 Feb 2016 21:38:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id Nlew1s00F3KdFy101lewCv; Thu, 25 Feb 2016 21:38:57 +0000 To: mmusic@ietf.org References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> From: Paul Kyzivat Message-ID: <56CF7470.10706@alum.mit.edu> Date: Thu, 25 Feb 2016 16:38:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CE49C1.2020605@nteczone.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=1456436337; bh=x0wlSwoTaV17I6MQBcx5eQ2d73P4lmsg/vekMwRWFGk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LtJHfoZZJZuZqBXkPXuoc9XgtguEYtsMgZKiaDN89zZ5LFTU97Lh26KNG5zJ2xVn4 MkDqEJabpMHN+uzoxDbzFhFqksc6aXqZ4s1eVZPiBWgk+2jQUA2ZoZdadJzhCUVv0q LADNLXF1FJknpW/OTzYPBxUXTOT9GHgVKsfcK8PmEry13Yt5dtQ9grZNleQd1i1aNl 8jgsniKkzoBP+fLt9hYi5+/fXnEz+bo5VYh9tek2ZAd9aMmYZeqCyZpuC6COhlq1Gx dgmhh0BxN2S6s8mc47ZVAU+SzstTtSo2ArNuQXEmhAJR16CSkhLBhXJqnJMGV662th HglG1mSem/EhA== 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: Thu, 25 Feb 2016 21:39:00 -0000 On 2/24/16 7:24 PM, Christian Groves wrote: > Hello Juergen and Paul, > > Please see at end. > > Regards, Christian > > On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >> ..snip.. >>> >>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>> Hi Paul, Christian, Flemming, Bo, >>>>> >>>>> Have just submitted version 08 of >>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>> The changes compared to version 07 are essentially as follows. >>>>> >>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>> regarding the >>>>> relationship of subprotocols and their attributes. >>>>> * Two new SDP offer/answer considerations in section 5.2.5 (Various >>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>> channel transport specific semantic is not known. >>>>> * A new paragraph in section 8.1 (IANA Considerations / Subprotocol >>>>> Identifiers) related to cases, where a subprotocol is defined for data >>>>> channel and Websocket transport. >>>>> >>>>> These changes should address the points discussed in this email >>>>> thread. >>>> >>>> This is an improvement. But I think things could still be made clearer. >>>> >>>> Consider the following addition to 5.1.2.1: >>>> >>>> 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. A data channel >>>> specific usage of a subprotocol attribute is expected to be >>>> specified >>>> in the same document, which registers the subprotocol's identifier >>>> for data channel usage as described in Section 8.1. >>>> >>>> This text makes sense when there is a clear distinction between >>>> subprotocol and protocol. Unfortunately, the way SDP has evolved there >>>> is no such clear distinction in many cases, such as RTP over UDP or >>>> TCP, etc. Those are combined into a single protocol value. While that >>>> can usually be parsed apart at slashes, there isn't good terminology >>>> for it. >>>> >>>> My point is that when I read the above, I don't know how it applies >>>> to, say, RTP attributes. Or does it only apply for attributes that are >>>> clearly defined for a *sub*protocol? >>>> >>>> I think this is primarily that we lack well defined vocabulary for all >>>> of this. But I think it would be too much to expect this draft to >>>> *solve* the vocabulary problem. In lieu of doing so, maybe it would be >>>> sufficient to give some concrete examples, even if they have to be >>>> hypothetical ones. >>> >>> [Juergen] Agree that it would be helpful to have more precise >>> definitions of the differences of the terms protocol and subprotocol, >>> especially when those terms are used outside the scope of data channels >>> (or Websockets). When only focusing on data channels the notion of a >>> "subprotocol" seems to be clearer - at least >>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>> Subprotocol Name Registry" when specifying DCEP's "Protocol" parameter. >>> (But draft-ietf-rtcweb-data-channel does not define what a data >>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>> informally starts using the term "subprotocol" in the introduction and >>> there refers to Websocket "subprotocols". Perhaps we should add the term >>> "subprotocol" to the list of used terminology in section 3. >>> >>> The sdpneg document, together with the data channel subprotocol specific >>> document (which defines the value of the a=dcmap attribute's >>> "subprotocol" parameter), should certainly give clear guidance on how to >>> interpret SDP offers or answers like e.g.: >>> >>> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >>> c=IN IP4 10.10.10.1 >>> a=max-message-size:100000 >>> a=sctp-port:5000 >>> ... >>> a=dcmap:0 subprotocol="MSRP" >>> a=dcsa:0 accept-types:message/cpim text/plain >>> a=dcsa:0 framerate:... >>> a=dcsa:0 lang:... >>> >>> An implementation receiving such an offer would need to decide what to >>> do with the dcsa embedded framerate and lang attributes. Or, someone >>> implementing MSRP over data channel based services may need to decide >>> whether or not to use these attributes, and if yes, how. >>> (I am using these two attributes just as hypothetical examples - don't >>> want to suggest that those may indeed be used for MSRP over data channel >>> transport). >>> >>> The msrp-usage-data-channel document doesn't mention these two >>> attributes. When looking at the IANA SDP attribute registry tables, I >>> would find both attributes specified in RFC 4566. There, "framerate" is >>> explicitly said to be defined only "for video media". Just to be sure I >>> could additionally have a look at the MSRP specifying documents, RFC >>> 4975 and RFC 4976, but there would not find any text at all related to >>> "framerate". So this case seems pretty clear and I would therefore >>> conclude that the "framerate" attribute should not be used for MSRP, and >>> that a receiver of such an offer or answer should ignore it. >>> >>> When looking at the definition of the "lang" attribute in RFC 4566 I >>> would not see any explicit hint of what protocols this attribute might >>> be used with, especially if "lang" could be used when negotiating an >>> MSRP session. When then looking at RFC 4975 I would indeed find "lang" - >>> but not as SDP attribute, rather as XML tag parameter within an example >>> MSRP message payload. Thus, the case of the "lang" attribute might not >>> be as unambiguous as the one with the "framerate" attribute, but here >>> too I think the typical choice would be to ignore that attribute when >>> receiving such an offer or answer. >>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>> sdpneg-08 may also be applied in these cases. >>> >>> Admittedly, these examples may seem a bit far-fetched, but would those >>> go into the direction you had in mind? >> >> Yes. Note that using examples is just me grasping at straws, since a >> real solution looks like to big a problem for this draft to tackle by >> itself. I am entirely open to other ideas for how to deal with this. > [CNG] I don't see what the example buys? I don't see that the behaviour > is any different between using additional attributes in the datachannel > vs. the non data channel case. E.g. for > > c=IN IP4 10.10.10.1 > m=message 7394 TCP/MSRP * > a=accept-types:message/cpim text/plain text/html > a=lang:.... > a=framerate:... > The ignore behaviour would be the same. > In the above example the attributes are scoped by the m= line. In the > data channel case the attributes are scoped by the relevant a=dcmap: line. My concern is that SDP has no notion of subprotocol, even though in practice it shows up lots of places. It only has a notion of the protocol field in the m-line. Beyond that a *convention* has developed to denote a layering within the protocol through use of "/". AFAIK this isn't formally written down anywhere. So, in principle we could define an RTP sub-protocol for use over a data channel. And then we could talk about using the attributes that apply to RTP in dcsa for a channel using RTP. But note there is no formal definition of the *protocol*s where RTP attributes are relevant. A lot of the very old stuff was just sloppy. To be fair, it was probably good enough for the cases in front of them at the time, and they weren't yet in a position to foresee how things would evolve. It is just another example of how old stuff rots and has to be refreshed from time to time. But I don't think *this* draft is the place to fix it. So, in lieu of doing that I'm just looking for some way to clarify things. Thanks, Paul From nobody Thu Feb 25 15:09: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 318D71B3762 for ; Thu, 25 Feb 2016 15:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, 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 2X3E_BjX7aCs for ; Thu, 25 Feb 2016 15:09:45 -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 D91831B375A for ; Thu, 25 Feb 2016 15:09:44 -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=sovBX/+NGdWk9/NdoS1YOWyXThlqc7+bVnMQzWA5P/U=; b=PhniVcip3dz+hi1TQVOMFvyMOT FWGcY8CNUIlOD8R9pUhlbtsF96JcSUgUwLFSAB1X82nVR5/Obno7TPzdAcl1IUNSiZc6cmqwgbtbv D0S/gg7wKbR212M2AYSNFtytKOhumMY7dnfrx4ZeJ+Tlf+h77o0/phMXJs+suQzhENGLJJJm8BOcG 1jTvAHrHQFRchsPhllyaPW5RVGeuvjtuTnI/T1y/Uij0wxX6n6HvgnO87VCjkMrN2LCcZWEB1XmE0 G0XshpkSw6q62zm1kU6uRk2EN/MOVABbyqDRVH4fF9NOE4Ph/BdvKi83YbzdgDOfCEaxw6i2Ntrs5 AakElCKw==; Received: from ppp118-209-133-128.lns20.mel8.internode.on.net ([118.209.133.128]:50450 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aZ52U-003l3Q-5I for mmusic@ietf.org; Fri, 26 Feb 2016 10:09:42 +1100 To: mmusic@ietf.org References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> From: Christian Groves Message-ID: <56CF89B0.3080103@nteczone.com> Date: Fri, 26 Feb 2016 10:09:36 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CF7470.10706@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Thu, 25 Feb 2016 23:09:48 -0000 Hello Paul, How about an update to draft-ietf-mmusic-rfc4566bis clause 5.14 (or 8.2.2)? This is the document that defines the PROTO field in the first place. Regards, Christian On 26/02/2016 8:38 AM, Paul Kyzivat wrote: > On 2/24/16 7:24 PM, Christian Groves wrote: >> Hello Juergen and Paul, >> >> Please see at end. >> >> Regards, Christian >> >> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>> ..snip.. >>>> >>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>> >>>>>> Have just submitted version 08 of >>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>> The changes compared to version 07 are essentially as follows. >>>>>> >>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>> regarding the >>>>>> relationship of subprotocols and their attributes. >>>>>> * Two new SDP offer/answer considerations in section 5.2.5 >>>>>> (Various >>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>>> channel transport specific semantic is not known. >>>>>> * A new paragraph in section 8.1 (IANA Considerations / >>>>>> Subprotocol >>>>>> Identifiers) related to cases, where a subprotocol is defined for >>>>>> data >>>>>> channel and Websocket transport. >>>>>> >>>>>> These changes should address the points discussed in this email >>>>>> thread. >>>>> >>>>> This is an improvement. But I think things could still be made >>>>> clearer. >>>>> >>>>> Consider the following addition to 5.1.2.1: >>>>> >>>>> 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. A data channel >>>>> specific usage of a subprotocol attribute is expected to be >>>>> specified >>>>> in the same document, which registers the subprotocol's identifier >>>>> for data channel usage as described in Section 8.1. >>>>> >>>>> This text makes sense when there is a clear distinction between >>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved >>>>> there >>>>> is no such clear distinction in many cases, such as RTP over UDP or >>>>> TCP, etc. Those are combined into a single protocol value. While that >>>>> can usually be parsed apart at slashes, there isn't good terminology >>>>> for it. >>>>> >>>>> My point is that when I read the above, I don't know how it applies >>>>> to, say, RTP attributes. Or does it only apply for attributes that >>>>> are >>>>> clearly defined for a *sub*protocol? >>>>> >>>>> I think this is primarily that we lack well defined vocabulary for >>>>> all >>>>> of this. But I think it would be too much to expect this draft to >>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it >>>>> would be >>>>> sufficient to give some concrete examples, even if they have to be >>>>> hypothetical ones. >>>> >>>> [Juergen] Agree that it would be helpful to have more precise >>>> definitions of the differences of the terms protocol and subprotocol, >>>> especially when those terms are used outside the scope of data >>>> channels >>>> (or Websockets). When only focusing on data channels the notion of a >>>> "subprotocol" seems to be clearer - at least >>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" >>>> parameter. >>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>> informally starts using the term "subprotocol" in the introduction and >>>> there refers to Websocket "subprotocols". Perhaps we should add the >>>> term >>>> "subprotocol" to the list of used terminology in section 3. >>>> >>>> The sdpneg document, together with the data channel subprotocol >>>> specific >>>> document (which defines the value of the a=dcmap attribute's >>>> "subprotocol" parameter), should certainly give clear guidance on >>>> how to >>>> interpret SDP offers or answers like e.g.: >>>> >>>> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >>>> c=IN IP4 10.10.10.1 >>>> a=max-message-size:100000 >>>> a=sctp-port:5000 >>>> ... >>>> a=dcmap:0 subprotocol="MSRP" >>>> a=dcsa:0 accept-types:message/cpim text/plain >>>> a=dcsa:0 framerate:... >>>> a=dcsa:0 lang:... >>>> >>>> An implementation receiving such an offer would need to decide what to >>>> do with the dcsa embedded framerate and lang attributes. Or, someone >>>> implementing MSRP over data channel based services may need to decide >>>> whether or not to use these attributes, and if yes, how. >>>> (I am using these two attributes just as hypothetical examples - don't >>>> want to suggest that those may indeed be used for MSRP over data >>>> channel >>>> transport). >>>> >>>> The msrp-usage-data-channel document doesn't mention these two >>>> attributes. When looking at the IANA SDP attribute registry tables, I >>>> would find both attributes specified in RFC 4566. There, >>>> "framerate" is >>>> explicitly said to be defined only "for video media". Just to be >>>> sure I >>>> could additionally have a look at the MSRP specifying documents, RFC >>>> 4975 and RFC 4976, but there would not find any text at all related to >>>> "framerate". So this case seems pretty clear and I would therefore >>>> conclude that the "framerate" attribute should not be used for >>>> MSRP, and >>>> that a receiver of such an offer or answer should ignore it. >>>> >>>> When looking at the definition of the "lang" attribute in RFC 4566 I >>>> would not see any explicit hint of what protocols this attribute might >>>> be used with, especially if "lang" could be used when negotiating an >>>> MSRP session. When then looking at RFC 4975 I would indeed find >>>> "lang" - >>>> but not as SDP attribute, rather as XML tag parameter within an >>>> example >>>> MSRP message payload. Thus, the case of the "lang" attribute might not >>>> be as unambiguous as the one with the "framerate" attribute, but here >>>> too I think the typical choice would be to ignore that attribute when >>>> receiving such an offer or answer. >>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>> sdpneg-08 may also be applied in these cases. >>>> >>>> Admittedly, these examples may seem a bit far-fetched, but would those >>>> go into the direction you had in mind? >>> >>> Yes. Note that using examples is just me grasping at straws, since a >>> real solution looks like to big a problem for this draft to tackle by >>> itself. I am entirely open to other ideas for how to deal with this. >> [CNG] I don't see what the example buys? I don't see that the behaviour >> is any different between using additional attributes in the datachannel >> vs. the non data channel case. E.g. for >> >> c=IN IP4 10.10.10.1 >> m=message 7394 TCP/MSRP * >> a=accept-types:message/cpim text/plain text/html >> a=lang:.... >> a=framerate:... >> The ignore behaviour would be the same. >> In the above example the attributes are scoped by the m= line. In the >> data channel case the attributes are scoped by the relevant a=dcmap: >> line. > > My concern is that SDP has no notion of subprotocol, even though in > practice it shows up lots of places. It only has a notion of the > protocol field in the m-line. Beyond that a *convention* has developed > to denote a layering within the protocol through use of "/". AFAIK > this isn't formally written down anywhere. > > So, in principle we could define an RTP sub-protocol for use over a > data channel. And then we could talk about using the attributes that > apply to RTP in dcsa for a channel using RTP. But note there is no > formal definition of the *protocol*s where RTP attributes are relevant. > > A lot of the very old stuff was just sloppy. To be fair, it was > probably good enough for the cases in front of them at the time, and > they weren't yet in a position to foresee how things would evolve. It > is just another example of how old stuff rots and has to be refreshed > from time to time. > > But I don't think *this* draft is the place to fix it. So, in lieu of > doing that I'm just looking for some way to clarify things. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Feb 25 15:19: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 23D911B377F; Thu, 25 Feb 2016 15:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 PpnNEFmZ_xaR; Thu, 25 Feb 2016 15:19:22 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B2B1B3779; Thu, 25 Feb 2016 15:19:22 -0800 (PST) Received: from [81.187.2.149] (port=46745 helo=[192.168.0.86]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aZ5Bn-00016q-Pm; Thu, 25 Feb 2016 23:19:20 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> Date: Thu, 25 Feb 2016 23:19:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic@ietf.org" , IETF AVTCore WG Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 23:19:28 -0000 Hi, > On 25 Feb 2016, at 14:17, Christer Holmberg = wrote: >=20 > Hi, >=20 > I put together some text: >=20 > "The scope of a mapping from a particular dynamic payload type number = to a codec=20 > (or codec configuration) is for a given RTP media flow direction = within a session.=20 I think this conflicts with various RTP-related RFCs and drafts, = although whether this conflict causes practical problems is unclear. RFC = 3551 indicates that the binding between RTP payload type and RTP payload = format is per RTP session, not per sender within an RTP session: mechanisms for defining dynamic payload type bindings have been specified in the Session Description Protocol (SDP) and in other protocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestamp clock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the number space limitation is avoided. (note: reuse in different sessions, not different participants within a = session) and: Session participants agree through mechanisms beyond the scope of this specification on the set of payload types allowed in a given session.=20 which is again, agree the set of PTs for a session, not per participant. RFC 3550 is unclear, and defers to RFC 3551, but suggests the payload = type mapping is per RTP session: RTP media type: An RTP media type is the collection of payload types which can be carried within a single RTP session. The RTP Profile assigns RTP media types to RTP payload types. draft-ietf-avtcore-multi-media-rtp-session-13 (currently in the RFC = Editor queue) says, in Section 7: Establishing a single RTP session using multiple media types requires signalling. This signalling has to: 1. ensure that any participant in the RTP session is aware that this is an RTP session with multiple media types; 2. ensure that the payload types in use in the RTP session are using unique values, with no overlap between the media types; draft-ietf-rtcweb-rtp-usage-25 says, in section 4.3: A single RTP payload type number MUST NOT be assigned to different RTP payload formats, or different configurations of the same RTP payload format, within a single RTP session (note that the "m=3D" = lines in an SDP bundle group [I-D.ietf-mmusic-sdp-bundle-negotiation] form a single RTP session). Finally, the allowable RTP payload type numbers depend on the RTCP = packet types used in the session, since use of certain RTCP packet types = prevents use of some RTP payload types when RTP and RTCP multiplexing is = used. The allowable RTCP packet types are signalled per RTP session, = also suggesting that the mapping is per session.=20 > The same dynamic payload type number can be mapped to another codec in = another RTP=20 > media flow direction within the same session. The mapping MUST NOT = change to a different > coded (or coded configuration) for the duration of a session. = Eventhough not recommended,=20 > for a given direction, multiple dynamic payload type numbers can be = mapped to the=20 > same codec (or codec configuration).=20 >=20 > Note that a mapping has been created once an endpoint > has sent and offer or answer, describing the mapping for a given = direction. Even if the > offer or answer is rejected or discarded, or if RTP media associated = with the mapping is never > sent, the mapping MUST NOT change for the given direction within the = session. >=20 > Within an offer or answer, the mapping is for the RTP media flow = direction towards the offerer/answerer, > unless the media flow is indicated as 'sendonly' in which case the = mapping is for the media flow direction > from the offerer/answerer." >=20 > Note that the text probably needs some fine tuning, but please take a = look and see whether you are ok with the approach, and whether you think = the text covers the issues we've discovered. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ From nobody Thu Feb 25 15:44: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 002B61B37D7 for ; Thu, 25 Feb 2016 15:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=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 QZT8JBTR1d4y for ; Thu, 25 Feb 2016 15:44:25 -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 74FB71B37DA for ; Thu, 25 Feb 2016 15:44:25 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-01v.sys.comcast.net with comcast id Nnju1s0092D5gil01nkQSF; Thu, 25 Feb 2016 23:44:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-06v.sys.comcast.net with comcast id NnkQ1s0013KdFy101nkQKu; Thu, 25 Feb 2016 23:44:24 +0000 To: mmusic@ietf.org References: <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> <56CF89B0.3080103@nteczone.com> From: Paul Kyzivat Message-ID: <56CF91D6.8030504@alum.mit.edu> Date: Thu, 25 Feb 2016 18:44:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CF89B0.3080103@nteczone.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=1456443864; bh=2VOX6Wt5Frl62K4FRlA2W1ErIy1AagHVHHu2yRQJz6s=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=YLVmGm1va2uY5aCb1HUQKjmzCFr1TEPsemxCFqPFKclRDRcoAc4jlNRppZpQ68rDy nAYyw+TKHYDq4IbUsrGvNq5HT/qXYPmLkTxlpXzy03Lk2X92Q8DuIbwNmP+UKmfUFR U/qLAKe1lyKUUcMwH2ey3z3JaTZvGgWSGoisa7q2xIX1trhiMMrCejjcpnTurtoi+W lNs9AZE7uZp25uO8seD4J2dmBfh19XmUGG0bqmQbXeHaX13CFTe0GPly7VHxdaGDpK xuQcCE7RV61IW0suGV0g91UUOe76v+cT5N6WfX9NyirzKrRahAK1QlAaGjwFA9wqGu e46xNVvlVv7mw== 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: Thu, 25 Feb 2016 23:44:28 -0000 On 2/25/16 6:09 PM, Christian Groves wrote: > Hello Paul, > > How about an update to draft-ietf-mmusic-rfc4566bis clause 5.14 (or > 8.2.2)? This is the document that defines the PROTO field in the first > place. That would be good, and possible since the bis is still in progress. The hard part is figuring out what it should say! For instance, consider UDP/DTLS/SCTP: what is the sub-protocol? Is it SCTP, or DTLS/SCTP? Or both? Is DTLS a sub-protocol? And note that this is somewhat confusing, since in typical protocol stack diagrams the sub-protocol is at the *top* and is considered to run at a higher level in the "stack". Of course this is all just a matter of definition. But I expect there might be a lot of opinions on it. Thanks, Paul > Regards, Christian > > On 26/02/2016 8:38 AM, Paul Kyzivat wrote: >> On 2/24/16 7:24 PM, Christian Groves wrote: >>> Hello Juergen and Paul, >>> >>> Please see at end. >>> >>> Regards, Christian >>> >>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>>> ..snip.. >>>>> >>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>>> >>>>>>> Have just submitted version 08 of >>>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>>> The changes compared to version 07 are essentially as follows. >>>>>>> >>>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>>> regarding the >>>>>>> relationship of subprotocols and their attributes. >>>>>>> * Two new SDP offer/answer considerations in section 5.2.5 >>>>>>> (Various >>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>>>> channel transport specific semantic is not known. >>>>>>> * A new paragraph in section 8.1 (IANA Considerations / >>>>>>> Subprotocol >>>>>>> Identifiers) related to cases, where a subprotocol is defined for >>>>>>> data >>>>>>> channel and Websocket transport. >>>>>>> >>>>>>> These changes should address the points discussed in this email >>>>>>> thread. >>>>>> >>>>>> This is an improvement. But I think things could still be made >>>>>> clearer. >>>>>> >>>>>> Consider the following addition to 5.1.2.1: >>>>>> >>>>>> 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. A data channel >>>>>> specific usage of a subprotocol attribute is expected to be >>>>>> specified >>>>>> in the same document, which registers the subprotocol's identifier >>>>>> for data channel usage as described in Section 8.1. >>>>>> >>>>>> This text makes sense when there is a clear distinction between >>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved >>>>>> there >>>>>> is no such clear distinction in many cases, such as RTP over UDP or >>>>>> TCP, etc. Those are combined into a single protocol value. While that >>>>>> can usually be parsed apart at slashes, there isn't good terminology >>>>>> for it. >>>>>> >>>>>> My point is that when I read the above, I don't know how it applies >>>>>> to, say, RTP attributes. Or does it only apply for attributes that >>>>>> are >>>>>> clearly defined for a *sub*protocol? >>>>>> >>>>>> I think this is primarily that we lack well defined vocabulary for >>>>>> all >>>>>> of this. But I think it would be too much to expect this draft to >>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it >>>>>> would be >>>>>> sufficient to give some concrete examples, even if they have to be >>>>>> hypothetical ones. >>>>> >>>>> [Juergen] Agree that it would be helpful to have more precise >>>>> definitions of the differences of the terms protocol and subprotocol, >>>>> especially when those terms are used outside the scope of data >>>>> channels >>>>> (or Websockets). When only focusing on data channels the notion of a >>>>> "subprotocol" seems to be clearer - at least >>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" >>>>> parameter. >>>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>>> informally starts using the term "subprotocol" in the introduction and >>>>> there refers to Websocket "subprotocols". Perhaps we should add the >>>>> term >>>>> "subprotocol" to the list of used terminology in section 3. >>>>> >>>>> The sdpneg document, together with the data channel subprotocol >>>>> specific >>>>> document (which defines the value of the a=dcmap attribute's >>>>> "subprotocol" parameter), should certainly give clear guidance on >>>>> how to >>>>> interpret SDP offers or answers like e.g.: >>>>> >>>>> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >>>>> c=IN IP4 10.10.10.1 >>>>> a=max-message-size:100000 >>>>> a=sctp-port:5000 >>>>> ... >>>>> a=dcmap:0 subprotocol="MSRP" >>>>> a=dcsa:0 accept-types:message/cpim text/plain >>>>> a=dcsa:0 framerate:... >>>>> a=dcsa:0 lang:... >>>>> >>>>> An implementation receiving such an offer would need to decide what to >>>>> do with the dcsa embedded framerate and lang attributes. Or, someone >>>>> implementing MSRP over data channel based services may need to decide >>>>> whether or not to use these attributes, and if yes, how. >>>>> (I am using these two attributes just as hypothetical examples - don't >>>>> want to suggest that those may indeed be used for MSRP over data >>>>> channel >>>>> transport). >>>>> >>>>> The msrp-usage-data-channel document doesn't mention these two >>>>> attributes. When looking at the IANA SDP attribute registry tables, I >>>>> would find both attributes specified in RFC 4566. There, >>>>> "framerate" is >>>>> explicitly said to be defined only "for video media". Just to be >>>>> sure I >>>>> could additionally have a look at the MSRP specifying documents, RFC >>>>> 4975 and RFC 4976, but there would not find any text at all related to >>>>> "framerate". So this case seems pretty clear and I would therefore >>>>> conclude that the "framerate" attribute should not be used for >>>>> MSRP, and >>>>> that a receiver of such an offer or answer should ignore it. >>>>> >>>>> When looking at the definition of the "lang" attribute in RFC 4566 I >>>>> would not see any explicit hint of what protocols this attribute might >>>>> be used with, especially if "lang" could be used when negotiating an >>>>> MSRP session. When then looking at RFC 4975 I would indeed find >>>>> "lang" - >>>>> but not as SDP attribute, rather as XML tag parameter within an >>>>> example >>>>> MSRP message payload. Thus, the case of the "lang" attribute might not >>>>> be as unambiguous as the one with the "framerate" attribute, but here >>>>> too I think the typical choice would be to ignore that attribute when >>>>> receiving such an offer or answer. >>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>>> sdpneg-08 may also be applied in these cases. >>>>> >>>>> Admittedly, these examples may seem a bit far-fetched, but would those >>>>> go into the direction you had in mind? >>>> >>>> Yes. Note that using examples is just me grasping at straws, since a >>>> real solution looks like to big a problem for this draft to tackle by >>>> itself. I am entirely open to other ideas for how to deal with this. >>> [CNG] I don't see what the example buys? I don't see that the behaviour >>> is any different between using additional attributes in the datachannel >>> vs. the non data channel case. E.g. for >>> >>> c=IN IP4 10.10.10.1 >>> m=message 7394 TCP/MSRP * >>> a=accept-types:message/cpim text/plain text/html >>> a=lang:.... >>> a=framerate:... >>> The ignore behaviour would be the same. >>> In the above example the attributes are scoped by the m= line. In the >>> data channel case the attributes are scoped by the relevant a=dcmap: >>> line. >> >> My concern is that SDP has no notion of subprotocol, even though in >> practice it shows up lots of places. It only has a notion of the >> protocol field in the m-line. Beyond that a *convention* has developed >> to denote a layering within the protocol through use of "/". AFAIK >> this isn't formally written down anywhere. >> >> So, in principle we could define an RTP sub-protocol for use over a >> data channel. And then we could talk about using the attributes that >> apply to RTP in dcsa for a channel using RTP. But note there is no >> formal definition of the *protocol*s where RTP attributes are relevant. >> >> A lot of the very old stuff was just sloppy. To be fair, it was >> probably good enough for the cases in front of them at the time, and >> they weren't yet in a position to foresee how things would evolve. It >> is just another example of how old stuff rots and has to be refreshed >> from time to time. >> >> But I don't think *this* draft is the place to fix it. So, in lieu of >> doing that I'm just looking for some way to clarify things. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 Feb 25 15:54: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 BDB341B382A for ; Thu, 25 Feb 2016 15:54:06 -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 O8n8MkXCwcYc for ; Thu, 25 Feb 2016 15:54:05 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85701B382F for ; Thu, 25 Feb 2016 15:53:37 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-09v.sys.comcast.net with comcast id Nnt01s0032VvR6D01ntdXW; Thu, 25 Feb 2016 23:53:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id Nntc1s00S3KdFy101ntdg2; Thu, 25 Feb 2016 23:53:37 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56CF9400.2020002@alum.mit.edu> Date: Thu, 25 Feb 2016 18:53:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: 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=1456444417; bh=CEnofRL1aT6DxU18A2Y0OCWxJwSnCUgyM3JjHryaoT4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=wEjmpazfoRcTaxOYjmgrK6f9uCJrqq0FO2Qo2Mh5J9F2Gip7gD2fv4m7O7HnjnC7O IuDQDudnH7KDyF6II+GWHBuHXIwyYGXn5dzoTYTGVONZXQrLD2pbaG4DqbIJVS6U/F ERfoKoE3+b1Pc5wvso4hY8d0TPebTJm6Obw+GUNR3k7enPTE1QQsfA0zgloAPm64PV BWKetDmwqsmH5sE3WAhce3hgG4RdaUB4tFn/Hf/xTyBF1H5juP+yojgzxYGutQaPp2 kmRAE8qWSfR7eVV3pwdj2RvP1Udsdcc/0mn0O88lKVMxQNt43E9FkDVTmcTJ1KRUxu I16JqkQ/2CbiA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 25 Feb 2016 23:54:06 -0000 On 2/25/16 6:19 PM, Colin Perkins wrote: > Hi, > >> On 25 Feb 2016, at 14:17, Christer Holmberg wrote: >> >> Hi, >> >> I put together some text: >> >> "The scope of a mapping from a particular dynamic payload type number to a codec >> (or codec configuration) is for a given RTP media flow direction within a session. > > I think this conflicts with various RTP-related RFCs and drafts, although whether this conflict causes practical problems is unclear. RFC 3551 indicates that the binding between RTP payload type and RTP payload format is per RTP session, not per sender within an RTP session: > > mechanisms for defining dynamic payload type bindings have been > specified in the Session Description Protocol (SDP) and in other > protocols such as ITU-T Recommendation H.323/H.245. These mechanisms > associate the registered name of the encoding/payload format, along > with any additional required parameters, such as the RTP timestamp > clock rate and number of channels, with a payload type number. This > association is effective only for the duration of the RTP session in > which the dynamic payload type binding is made. This association > applies only to the RTP session for which it is made, thus the > numbers can be re-used for different encodings in different sessions > so the number space limitation is avoided. > > (note: reuse in different sessions, not different participants within a session) and: Does a sendrecv m-line established via O/A create one or two RTP sessions? If one, then it seems this conflicts with 3264 allowing the two ends to use different PTs for the same codec configuration. It always seemed to me that the original intent was to require the same PT number on both ends (perhaps because of what you quote), and that allowing the two ends to be different was an afterthought. If so, it may be that rfc3551 should have been updated. Is there any *technical* difficulty when the two ends use different PTs? (E.g. does it screw up rtcp reports?) We are starting to get to the meat of the issue. The question is: what needs to be fixed? Thanks, Paul From nobody Thu Feb 25 18:18: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 A56D31A7025 for ; Thu, 25 Feb 2016 18:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 dQZ23x-qaSWG for ; Thu, 25 Feb 2016 18:18:49 -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 7D1FF1A7023 for ; Thu, 25 Feb 2016 18:18:49 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id y8so28534701igp.0 for ; Thu, 25 Feb 2016 18:18:49 -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; bh=Xcid7eSLJmaNZUkoIiGYkqb2kzXdLo9QNn9Q5TiRL6w=; b=CO5D/BSvgB6HBM+xlMiFfeOI2R/4OH1v/2k5pp0W43plW8wu2fAFErs726JAHKRqbU az0VE9LaW5YsAeDxrOBroJAa6NThPKYs349QtJGMjvjmzYbJkPBg8OAJP1PB3EbYvy8F su96AsStLibivoH3+2jG+AOLW8kx410JW1fXGuWyfhTEUSBNNT7VgpRIphE9DhBhgQzS IYDgAe1s0zFqV6Rn3I33mqi65sK7z1d3XYL5EqL8mR6iGbUN8tlTuhFAzfOPL2jBTkC7 fDDEH7m1lki1viTTb93bfCGiczDfIBsfo+9fToYqMlbkgGR99vERHBG9hryOuAH9WQQI e2YA== 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; bh=Xcid7eSLJmaNZUkoIiGYkqb2kzXdLo9QNn9Q5TiRL6w=; b=GD5dZ1vy8JDzg6qetm6QbvjwOqM4K/84IUrCP8SZzg9xYImj/93/Y/WCKckgDEjw6M Q8MRgX1Uy3oY+weB53pCfawsDcAL5yx/qSNcKqD0TN5+YnM+hI+v8lN1Zvqw6xXaLq8f bVXBkcd+kuhvP8Syc8KbAbxtova2JOPyOWemJdFKiHIPa84mCItF7mwPT6RIgKTE08Fn vC3S1CdkROy9lbI38b6jsseM07atwtFlXKvSNXwj1NgWsLDdyhGCROwF7sPYzZEl6Jl1 LIWgZIP6LAjBEcwu72KQFkodfer+990D0qn6fwaxeqNGZBoaPJdzHFKWdYxVHBB8ioOO htTA== X-Gm-Message-State: AD7BkJKp5tUemw1KxbPlc/GxY/mCsxPtkApnoFPpioMNQ6hB/aH0nz+kqlH9w49sXc3qfoNXjkUvlX3IIYfKPA== MIME-Version: 1.0 X-Received: by 10.50.180.35 with SMTP id dl3mr538311igc.94.1456453128850; Thu, 25 Feb 2016 18:18:48 -0800 (PST) Received: by 10.36.53.79 with HTTP; Thu, 25 Feb 2016 18:18:48 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4116F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E4116F@ESESSMB209.ericsson.se> Date: Fri, 26 Feb 2016 13:18:48 +1100 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt - altSubjectName 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, 26 Feb 2016 02:18:50 -0000 On 25 February 2016 at 20:38, Christer Holmberg wrote: > Could we simply remove the sentence? The sentence before says pretty much what you suggest, doesn't it? YEp. From nobody Thu Feb 25 23:26: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 9680C1ACDC3; Thu, 25 Feb 2016 23:26:08 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226072608.27887.91763.idtracker@ietfa.amsl.com> Date: Thu, 25 Feb 2016 23:26:08 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 07:26:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-09.txt Pages : 23 Date : 2016-02-25 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 25 23:29: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 DCA661ACDCB; Thu, 25 Feb 2016 23:29:52 -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 J6yaTyZ7GAs1; Thu, 25 Feb 2016 23:29:51 -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 AFCF21ACDC7; Thu, 25 Feb 2016 23:29:50 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-f4-56cffeec0d88 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 94.FA.28465.CEEFFC65; Fri, 26 Feb 2016 08:29:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 08:29:48 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-dtls-sdp-09 Thread-Index: AdFwZztYg0twwL1AR4qDbJGareGECw== Date: Fri, 26 Feb 2016 07:29:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E45EA2@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E45EA2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2J7oO6bf+fDDFbeVLO4duYfo8X5neuZ LKYuf8xisWLDAVYHFo+/7z8weeycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGVuvf2ApWCxV 0T3rLGsDY7d4FyMnh4SAicTxyfOZIWwxiQv31rN1MXJxCAkcZpS48GI/WEJIYDGjxJe/JV2M HBxsAhYS3f+0QcIiAuoSX/f2MIPUMwtsYpQ4vnUvWL2wgKVE964+JogiO4lF7y9C2XoSz26s YQGxWQRUJV78PcMEMpNXwFfi3VIlkDAj0A3fT60BK2cWEJe49WQ+E8RtAhJL9pyHulNU4uXj f6wQtpJE45InrBD1+RLHOiBqeAUEJU7OfMIygVF4FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzh a2YY+8yBx0zI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbWwS2/dXcwrn7teIhR gINRiYf3w/fzYUKsiWXFlbmHGCU4mJVEeLn+AoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzrnFe HyYkkJ5YkpqdmlqQWgSTZeLglGpgVA1oFArRP/vg5xq5m/qi/n2JFZMfH/OZ/nZGybMTXxov W/4rnCqWOUVkxb8bj3cvbVCSurzlgJJcOXPkrG1W66+ze3GkfrRa2n5M2Wlu3Pm6h6ILRNj+ HggozL637zDrmRdSjMtPnhHfKrpy/aRviXNU/mf8nKGZNXVzvYDJEre8yrD6vfKWGUosxRmJ hlrMRcWJACjIlgapAgAA Archived-At: Cc: "mmusic-chairs@ietf.org" , "pkyzivat@alum.mit.edu" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09 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, 26 Feb 2016 07:29:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E45EA2ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments given by Paul and Martin, and the mail discussion reg= arding updating RFC 4572, I've submitted a new version of draft-dtls-sdp-09= . The O/A section now allows usage of multiple 'fingerprint' attributes. The draft does NOT update RFC 4572. My parsing of the outcome was that any = updates will be done in a separate draft. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37E45EA2ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the comments given by Paul and Martin, and = the mail discussion regarding updating RFC 4572, I’ve submitted a new= version of draft-dtls-sdp-09.

 

The O/A section now allows usage of multiple ‘= fingerprint’ attributes.

 

The draft does NOT update RFC 4572. My parsing of th= e outcome was that any updates will be done in a separate draft.=

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E45EA2ESESSMB209erics_-- From nobody Fri Feb 26 00:31: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 508D81A21BC for ; Fri, 26 Feb 2016 00:31:11 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226083111.26531.81561.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 00:31:11 -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: Fri, 26 Feb 2016 08:31:11 -0000 Changed milestone "Submit Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP as Proposed Standard", added draft-ietf-mmusic-mux-exclusive to milestone, removed draft-holmberg-mmusic-mux-exclusive from milestone. URL: https://datatracker.ietf.org/wg/mmusic/charter/ From nobody Fri Feb 26 01:39:57 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 1FC2C1A1A4B for ; Fri, 26 Feb 2016 01:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-5ApX8eD9vF for ; Fri, 26 Feb 2016 01:39:53 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2341A1A45 for ; Fri, 26 Feb 2016 01:39:53 -0800 (PST) Received: from [81.187.2.149] (port=46251 helo=[192.168.0.86]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aZEsI-0003FA-0j; Fri, 26 Feb 2016 09:39:51 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56CF9400.2020002@alum.mit.edu> Date: Fri, 26 Feb 2016 09:39:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 09:39:56 -0000 > On 25 Feb 2016, at 23:53, Paul Kyzivat wrote: >=20 > On 2/25/16 6:19 PM, Colin Perkins wrote: >> Hi, >>=20 >>> On 25 Feb 2016, at 14:17, Christer Holmberg = wrote: >>>=20 >>> Hi, >>>=20 >>> I put together some text: >>>=20 >>> "The scope of a mapping from a particular dynamic payload type = number to a codec >>> (or codec configuration) is for a given RTP media flow direction = within a session. >>=20 >> I think this conflicts with various RTP-related RFCs and drafts, = although whether this conflict causes practical problems is unclear. RFC = 3551 indicates that the binding between RTP payload type and RTP payload = format is per RTP session, not per sender within an RTP session: >>=20 >> mechanisms for defining dynamic payload type bindings have been >> specified in the Session Description Protocol (SDP) and in other >> protocols such as ITU-T Recommendation H.323/H.245. These = mechanisms >> associate the registered name of the encoding/payload format, = along >> with any additional required parameters, such as the RTP timestamp >> clock rate and number of channels, with a payload type number. = This >> association is effective only for the duration of the RTP session = in >> which the dynamic payload type binding is made. This association >> applies only to the RTP session for which it is made, thus the >> numbers can be re-used for different encodings in different = sessions >> so the number space limitation is avoided. >>=20 >> (note: reuse in different sessions, not different participants within = a session) and: >=20 > Does a sendrecv m-line established via O/A create one or two RTP = sessions? One, since RTP sessions are defined by shared SSRC space, not = directionality of media. > If one, then it seems this conflicts with 3264 allowing the two ends = to use different PTs for the same codec configuration. That depends exactly what 3264 allows: if the two ends use different = payload types to refer to the same codec, that=E2=80=99s okay; but if = the two ends use the same payload type to refer to different codecs, = that problematic. > It always seemed to me that the original intent was to require the = same PT number on both ends (perhaps because of what you quote), and = that allowing the two ends to be different was an afterthought. If so, = it may be that rfc3551 should have been updated. >=20 > Is there any *technical* difficulty when the two ends use different = PTs? (E.g. does it screw up rtcp reports?) Using different payload types to refer to the same codec is wasteful, = but not harmful. Allowing different senders to use the same payload type to refer to = different codecs is problematic. It makes the payload type to codec = mapping depend on the SSRC, but SSRCs can change without signalling.=20 > We are starting to get to the meat of the issue. The question is: what = needs to be fixed? >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ From nobody Fri Feb 26 01: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 B11BA1A1B0E for ; Fri, 26 Feb 2016 01:44:19 -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 dP96wAkAZTGY for ; Fri, 26 Feb 2016 01:44:18 -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 742161A1AAE for ; Fri, 26 Feb 2016 01:44:17 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-d2-56d01e6e2d14 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.05.28465.E6E10D65; Fri, 26 Feb 2016 10:44:15 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.142]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 10:44:08 +0100 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Thread-Topic: MMUSIC agenda requests for IETF #95 Thread-Index: AdFweJDNoDEfTUsBQhaSpFSZx63gbw== Date: Fri, 26 Feb 2016 09:44:08 +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_BBE9739C2C302046BD34B42713A1E2A22E9CF813ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7nG6+3IUwg+cr+C2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDMfehkLmoMr/t7bzN7AOM+ji5GTQ0LAROLfzLUsELaYxIV7 69m6GLk4hAQOM0rserIDLCEksIRRYupTLxCbTUBDYv6Ou4wgtoiAgcTslTPAbGEBHYkfk9+w QsQNJW4umwZVoydxccMnJhCbRUBVYsa0RjCbV8BX4tHjXcwgNqOArMT97/fAdjELiEvcejKf CeIgAYkle84zQ9iiEi8f/wOazwFkK0os75eDKM+X+PzqNiPESEGJkzOfsExgFJqFZNIsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eakl mxiBEXFwy2/dHYyrXzseYhTgYFTi4f3w/XyYEGtiWXFl7iFGCQ5mJRFerr9AId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rxrnNeHCQmkJ5akZqemFqQWwWSZODilGhi7DLs5piw4oDqBNddCwOTn /AVdPXanA3fwa0dePMdl/mhjUnK4Tqhkve/Oqss1N57Jad4+NW1u9ZlIibnfD83hOW6mdsTG dun2BrFFXFOsFuz++lkn/Rvf7fMuD+bXT+opWe6w9Okap4NmC+uMIs6V+hjqMGQ0XHXa5jfv r0b77BVvBLMTLnxVYinOSDTUYi4qTgQArYj4EoQCAAA= Archived-At: Subject: [MMUSIC] MMUSIC agenda requests for IETF #95 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, 26 Feb 2016 09:44:19 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E9CF813ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings IETF95 in Buenos Aires is approaching and the MMUSIC WG will be having one = 2.5 hour meeting this time. Draft submission and initial WG agendas are bot= h due March 21st, so this is an early, friendly reminder to let the chairs = know if you have anything you would like to get on the agenda. As usual, we want to ensure we take advantage of our meeting time in a prod= uctive manner. This means that we want presenters to come prepared to discu= ss open issues that have already been raised on the mailing list and ideall= y received some feedback already. Priority will be given to drafts that gat= her attention and discussion on the mailing list prior to the meeting. We a= lso aim to give adequate time for drafts holding progress elsewhere. To fac= ilitate this, please specify in your agenda request e-mail the following: - name of the draft and the presenter - how much time you would like - outline of major open issues; what needs to be discussed at the = meeting - dependencies to your draft (if any) Thanks Bo & Flemming (MMUSIC co-chairs) --_000_BBE9739C2C302046BD34B42713A1E2A22E9CF813ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings

 

IETF95 in Buenos Aires is approaching and the MMU= SIC WG will be having one 2.5 hour meeting this time. Draft submission and = initial WG agendas are both due March 21st, so this is an early,= friendly reminder to let the chairs know if you have anything you would like to get on the agenda.<= /p>

 

As usual, we want to ensure we take advantage of = our meeting time in a productive manner. This means that we want presenters= to come prepared to discuss open issues that have already been raised on t= he mailing list and ideally received some feedback already. Priority will be given to drafts that gather attent= ion and discussion on the mailing list prior to the meeting. We also aim to= give adequate time for drafts holding progress elsewhere. To facilitate th= is, please specify in your agenda request e-mail the following:

 

-       = ;   name of the draft and the presenter

 

-       = ;   how much time you would like

 

-       = ;   outline of major open issues; what needs to be disc= ussed at the meeting

 

-       = ;   dependencies to your draft (if any)

 

Thanks

 

     Bo & Flemming (MMUSI= C co-chairs)

 

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E9CF813ESESSMB105erics_-- From nobody Fri Feb 26 02:18: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 D2F081A870B for ; Fri, 26 Feb 2016 02:17:58 -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 50WFDFYrftRt for ; Fri, 26 Feb 2016 02:17:53 -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 4EF991A86F0 for ; Fri, 26 Feb 2016 02:17:53 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-55-56d0264ffeb5 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.3A.20792.F4620D65; Fri, 26 Feb 2016 11:17:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 11:17:50 +0100 From: Christer Holmberg To: Colin Perkins , Paul Kyzivat Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wARGIiAAAEzHQAAFHhLgAADSidw Date: Fri, 26 Feb 2016 10:17:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4637F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> 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+NgFupnkeLIzCtJLcpLzFFi42KZGbFdUddf7UKYwfN2SYvlL08wWkxd/pjF YsWGA6wOzB5/339g8ph2/z6bx5IlP5kCmKO4bFJSczLLUov07RK4Mq70fGAsmCBe8fZfM2MD 4xGxLkZODgkBE4mHq7ayQthiEhfurWfrYuTiEBI4zCjRfOUeK4SzmFHi8uobjF2MHBxsAhYS 3f+0QRpEBLwl+jecYQcJMwuoS1xdHAQSFhawl5j+7DETRImDxO2tv9ghbDeJ+43TWEBsFgFV ibnL1oHt5RXwlWiZcIMJYtVdRom9558wgczkFHCUOHlcEaSGEei276fWgM1kFhCXuPVkPhPE zQISS/acZ4awRSVePv4H9YuSxNrD21kgTtOUWL9LH6JVUWJK90N2iLWCEidnPmGZwCg2C8nU WQgds5B0zELSsYCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYDQd3PLbagfjweeOhxgF OBiVeHg/fD8fJsSaWFZcmXuIUYKDWUmEl+svUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvGuf1 YUIC6YklqdmpqQWpRTBZJg5OqQZG3RXn94f8rmESWn196qIbVsfNzKYKPbr9e/asKXMMmL+Z OrtKnFfa2RLsHKm2Uffd5xPL777gf3es3qdebNaurUoq2Wx7950odDS8Eie6i/fAzN0ube57 D3fG7XV5duXXFYsYoaxP+8NXPgucctl/YYXQJO2dLFlt1vHnLsYsY9K8Gr6voDi+RImlOCPR UIu5qDgRAJw1CKOiAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 10:17:59 -0000 SGksDQoNCj4+Pj4gSSBwdXQgdG9nZXRoZXIgc29tZSB0ZXh0Og0KPj4+PiANCj4+Pj4gIlRoZSBz Y29wZSBvZiBhIG1hcHBpbmcgZnJvbSBhIHBhcnRpY3VsYXIgZHluYW1pYyBwYXlsb2FkIHR5cGUg DQo+Pj4+IG51bWJlciB0byBhIGNvZGVjIChvciBjb2RlYyBjb25maWd1cmF0aW9uKSBpcyBmb3Ig YSBnaXZlbiBSVFAgbWVkaWEgZmxvdyBkaXJlY3Rpb24gd2l0aGluIGEgc2Vzc2lvbi4NCj4+PiAN Cj4+PiBJIHRoaW5rIHRoaXMgY29uZmxpY3RzIHdpdGggdmFyaW91cyBSVFAtcmVsYXRlZCBSRkNz IGFuZCBkcmFmdHMsIGFsdGhvdWdoIHdoZXRoZXIgdGhpcyBjb25mbGljdCBjYXVzZXMgcHJhY3Rp Y2FsIA0KPj4+IHByb2JsZW1zIGlzIHVuY2xlYXIuIFJGQyAzNTUxIGluZGljYXRlcyB0aGF0IHRo ZSBiaW5kaW5nIGJldHdlZW4gUlRQIHBheWxvYWQgdHlwZSBhbmQgUlRQIHBheWxvYWQgZm9ybWF0 IGlzIHBlciANCj4+PiBSVFAgc2Vzc2lvbiwgbm90IHBlciBzZW5kZXIgd2l0aGluIGFuIFJUUCBz ZXNzaW9uOg0KPj4+IA0KPj4+ICAgIG1lY2hhbmlzbXMgZm9yIGRlZmluaW5nIGR5bmFtaWMgcGF5 bG9hZCB0eXBlIGJpbmRpbmdzIGhhdmUgYmVlbg0KPj4+ICAgIHNwZWNpZmllZCBpbiB0aGUgU2Vz c2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBhbmQgaW4gb3RoZXINCj4+PiAgICBwcm90 b2NvbHMgc3VjaCBhcyBJVFUtVCBSZWNvbW1lbmRhdGlvbiBILjMyMy9ILjI0NS4gIFRoZXNlIG1l Y2hhbmlzbXMNCj4+PiAgICBhc3NvY2lhdGUgdGhlIHJlZ2lzdGVyZWQgbmFtZSBvZiB0aGUgZW5j b2RpbmcvcGF5bG9hZCBmb3JtYXQsIGFsb25nDQo+Pj4gICAgd2l0aCBhbnkgYWRkaXRpb25hbCBy ZXF1aXJlZCBwYXJhbWV0ZXJzLCBzdWNoIGFzIHRoZSBSVFAgdGltZXN0YW1wDQo+Pj4gICAgY2xv Y2sgcmF0ZSBhbmQgbnVtYmVyIG9mIGNoYW5uZWxzLCB3aXRoIGEgcGF5bG9hZCB0eXBlIG51bWJl ci4gIFRoaXMNCj4+PiAgICBhc3NvY2lhdGlvbiBpcyBlZmZlY3RpdmUgb25seSBmb3IgdGhlIGR1 cmF0aW9uIG9mIHRoZSBSVFAgc2Vzc2lvbiBpbg0KPj4+ICAgIHdoaWNoIHRoZSBkeW5hbWljIHBh eWxvYWQgdHlwZSBiaW5kaW5nIGlzIG1hZGUuICBUaGlzIGFzc29jaWF0aW9uDQo+Pj4gICAgYXBw bGllcyBvbmx5IHRvIHRoZSBSVFAgc2Vzc2lvbiBmb3Igd2hpY2ggaXQgaXMgbWFkZSwgdGh1cyB0 aGUNCj4+PiAgICBudW1iZXJzIGNhbiBiZSByZS11c2VkIGZvciBkaWZmZXJlbnQgZW5jb2Rpbmdz IGluIGRpZmZlcmVudCBzZXNzaW9ucw0KPj4+ICAgIHNvIHRoZSBudW1iZXIgc3BhY2UgbGltaXRh dGlvbiBpcyBhdm9pZGVkLg0KPj4+IA0KPj4+IChub3RlOiByZXVzZSBpbiBkaWZmZXJlbnQgc2Vz c2lvbnMsIG5vdCBkaWZmZXJlbnQgcGFydGljaXBhbnRzIHdpdGhpbiBhIHNlc3Npb24pIGFuZDoN Cj4gDQo+IERvZXMgYSBzZW5kcmVjdiBtLWxpbmUgZXN0YWJsaXNoZWQgdmlhIE8vQSBjcmVhdGUg b25lIG9yIHR3byBSVFAgc2Vzc2lvbnM/DQoNCk9uZSwgc2luY2UgUlRQIHNlc3Npb25zIGFyZSBk ZWZpbmVkIGJ5IHNoYXJlZCBTU1JDIHNwYWNlLCBub3QgZGlyZWN0aW9uYWxpdHkgb2YgbWVkaWEu DQoNCj4+IElmIG9uZSwgdGhlbiBpdCBzZWVtcyB0aGlzIGNvbmZsaWN0cyB3aXRoIDMyNjQgYWxs b3dpbmcgdGhlIHR3byBlbmRzIHRvIHVzZSBkaWZmZXJlbnQgUFRzIGZvciB0aGUgc2FtZSBjb2Rl YyBjb25maWd1cmF0aW9uLg0KPg0KPiBUaGF0IGRlcGVuZHMgZXhhY3RseSB3aGF0IDMyNjQgYWxs b3dzOiBpZiB0aGUgdHdvIGVuZHMgdXNlIGRpZmZlcmVudCBwYXlsb2FkIHR5cGVzIHRvIHJlZmVy IHRvIHRoZSBzYW1lIGNvZGVjLCB0aGF04oCZcyBva2F5OyBidXQgaWYgDQo+IHRoZSB0d28gZW5k cyB1c2UgdGhlIHNhbWUgcGF5bG9hZCB0eXBlIHRvIHJlZmVyIHRvIGRpZmZlcmVudCBjb2RlY3Ms IHRoYXQgcHJvYmxlbWF0aWMuDQoNCkZyb20gYSAzMjY0IHBlcnNwZWN0aXZlLCAidXNlIiBkb2Vz bid0IGF1dG9tYXRpY2FsbHkgbWVhbiB0aGF0IHRoZSBQVCBpcyBldmVyIHNlbnQgb24gdGhlIHdp cmUgLSBpdCBvbmx5IG1lYW5zIHRoYXQgYSBQVC9jb2RlYyBtYXBwaW5nIGhhcyBiZWVuIGluZGlj YXRlZCBpbiBhbiBvZmZlciBvciBhbnN3ZXIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Fri Feb 26 06:18: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 61ABA1B2C71 for ; Fri, 26 Feb 2016 06:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5, 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 ULcoGVS1FjSy for ; Fri, 26 Feb 2016 06:17:58 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 E06D41B2C61 for ; Fri, 26 Feb 2016 06:17:57 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7F6F2314DF04B for ; Fri, 26 Feb 2016 14:17:53 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1QEHt4C018354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 26 Feb 2016 14:17:55 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1QEHaRp032134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Feb 2016 15:17:55 +0100 Received: from [149.204.68.190] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Feb 2016 15:17:49 +0100 References: <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> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> From: Juergen Stoetzer-Bradler To: "mmusic@ietf.org" Message-ID: <56D05E8D.5080306@alcatel-lucent.com> Date: Fri, 26 Feb 2016 15:17:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CF7470.10706@alum.mit.edu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [135.239.27.41] 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, 26 Feb 2016 14:18:02 -0000 Hello Paul, Christian, Would propose to add following definition of term "subprotocol" to the te= rminology section 3 of the=20 sdpneg draft: Data channel subprotocol: The application protocol which is transported over a single data channel. Data channel subprotocol messages are sent as data channel payload over an established data= channel. If an SDP offer/answer exchange is used as specified in this document to negotiate the establishment of data channels, corresponding data channel properties, associated data channel subprotocols and data channel subprotocol properties, then the dat= a channel subprotocols may be identified by the values of the "subprotocol" parameters of the SDP "a=3Ddcmap" attributes as described in Section 5.1.1.5. Within this document the term "data= channel subprotocol" is often abbreviated as just "subprotocol". This text could explicitly narrow down the notion of "subprotocol" within= the data channel SDP=20 offer/answer context and might especially be helpful distinguishing it fr= om the usages of=20 "subprotocol" in the Websocket RFC 6455 (where the term "subprotocol" was= taken from, but where it=20 does not seem to be formally defined). This text may certainly not be hel= pful in more general=20 non-data channel contexts. But it might help to clarify that every occurr= ence of of the term=20 "subprotocol" in the sdpneg draft refers to the application protocol whic= h (typically but not=20 necessarily) is identified via the a=3Ddcmap's "subprotocol" parameter. Would such an explicit definition be helpful from your point of view? Thanks, Juergen On 25.02.2016 22:38, EXT Paul Kyzivat wrote: > On 2/24/16 7:24 PM, Christian Groves wrote: >> Hello Juergen and Paul, >> >> Please see at end. >> >> Regards, Christian >> >> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>> ..snip.. >>>> >>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>> >>>>>> Have just submitted version 08 of >>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>> The changes compared to version 07 are essentially as follows. >>>>>> >>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>> regarding the >>>>>> relationship of subprotocols and their attributes. >>>>>> * Two new SDP offer/answer considerations in section 5.2.5 (Vari= ous >>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>> subprotocol attributes or known subprotocol attributes, whose data= >>>>>> channel transport specific semantic is not known. >>>>>> * A new paragraph in section 8.1 (IANA Considerations / Subproto= col >>>>>> Identifiers) related to cases, where a subprotocol is defined for = data >>>>>> channel and Websocket transport. >>>>>> >>>>>> These changes should address the points discussed in this email >>>>>> thread. >>>>> >>>>> This is an improvement. But I think things could still be made clea= rer. >>>>> >>>>> Consider the following addition to 5.1.2.1: >>>>> >>>>> It is assumed that in general the usages of subprotocol related >>>>> media >>>>> level attributes are independent from the subprotocol's transpor= t >>>>> protocol. Such transport protocol independent subprotocol relat= ed >>>>> attributes are used in the same way as defined in the original >>>>> subprotocol specification, also if the subprotocol is transporte= d >>>>> over a data channel and if the attribute is correspondingly embe= dded >>>>> in a "a=3Ddcsa" attribute. >>>>> >>>>> There may be cases, where the usage of a subprotocol related med= ia >>>>> 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. A data channel >>>>> specific usage of a subprotocol attribute is expected to be >>>>> specified >>>>> in the same document, which registers the subprotocol's identifi= er >>>>> for data channel usage as described in Section 8.1. >>>>> >>>>> This text makes sense when there is a clear distinction between >>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved th= ere >>>>> is no such clear distinction in many cases, such as RTP over UDP or= >>>>> TCP, etc. Those are combined into a single protocol value. While th= at >>>>> can usually be parsed apart at slashes, there isn't good terminolog= y >>>>> for it. >>>>> >>>>> My point is that when I read the above, I don't know how it applies= >>>>> to, say, RTP attributes. Or does it only apply for attributes that = are >>>>> clearly defined for a *sub*protocol? >>>>> >>>>> I think this is primarily that we lack well defined vocabulary for = all >>>>> of this. But I think it would be too much to expect this draft to >>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it would= be >>>>> sufficient to give some concrete examples, even if they have to be >>>>> hypothetical ones. >>>> >>>> [Juergen] Agree that it would be helpful to have more precise >>>> definitions of the differences of the terms protocol and subprotocol= , >>>> especially when those terms are used outside the scope of data chann= els >>>> (or Websockets). When only focusing on data channels the notion of a= >>>> "subprotocol" seems to be clearer - at least >>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" paramet= er. >>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>> informally starts using the term "subprotocol" in the introduction a= nd >>>> there refers to Websocket "subprotocols". Perhaps we should add the = term >>>> "subprotocol" to the list of used terminology in section 3. >>>> >>>> The sdpneg document, together with the data channel subprotocol spec= ific >>>> document (which defines the value of the a=3Ddcmap attribute's >>>> "subprotocol" parameter), should certainly give clear guidance on ho= w to >>>> interpret SDP offers or answers like e.g.: >>>> >>>> m=3Dapplication 10001 UDP/DTLS/SCTP webrtc-datachannel >>>> c=3DIN IP4 10.10.10.1 >>>> a=3Dmax-message-size:100000 >>>> a=3Dsctp-port:5000 >>>> ... >>>> a=3Ddcmap:0 subprotocol=3D"MSRP" >>>> a=3Ddcsa:0 accept-types:message/cpim text/plain >>>> a=3Ddcsa:0 framerate:... >>>> a=3Ddcsa:0 lang:... >>>> >>>> An implementation receiving such an offer would need to decide what = to >>>> do with the dcsa embedded framerate and lang attributes. Or, someone= >>>> implementing MSRP over data channel based services may need to decid= e >>>> whether or not to use these attributes, and if yes, how. >>>> (I am using these two attributes just as hypothetical examples - don= 't >>>> want to suggest that those may indeed be used for MSRP over data cha= nnel >>>> transport). >>>> >>>> The msrp-usage-data-channel document doesn't mention these two >>>> attributes. When looking at the IANA SDP attribute registry tables, = I >>>> would find both attributes specified in RFC 4566. There, "framerate"= is >>>> explicitly said to be defined only "for video media". Just to be sur= e I >>>> could additionally have a look at the MSRP specifying documents, RFC= >>>> 4975 and RFC 4976, but there would not find any text at all related = to >>>> "framerate". So this case seems pretty clear and I would therefore >>>> conclude that the "framerate" attribute should not be used for MSRP,= and >>>> that a receiver of such an offer or answer should ignore it. >>>> >>>> When looking at the definition of the "lang" attribute in RFC 4566 I= >>>> would not see any explicit hint of what protocols this attribute mig= ht >>>> be used with, especially if "lang" could be used when negotiating an= >>>> MSRP session. When then looking at RFC 4975 I would indeed find "lan= g" - >>>> but not as SDP attribute, rather as XML tag parameter within an exam= ple >>>> MSRP message payload. Thus, the case of the "lang" attribute might n= ot >>>> be as unambiguous as the one with the "framerate" attribute, but her= e >>>> too I think the typical choice would be to ignore that attribute whe= n >>>> receiving such an offer or answer. >>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>> sdpneg-08 may also be applied in these cases. >>>> >>>> Admittedly, these examples may seem a bit far-fetched, but would tho= se >>>> go into the direction you had in mind? >>> >>> Yes. Note that using examples is just me grasping at straws, since a >>> real solution looks like to big a problem for this draft to tackle by= >>> itself. I am entirely open to other ideas for how to deal with this. >> [CNG] I don't see what the example buys? I don't see that the behaviou= r >> is any different between using additional attributes in the datachanne= l >> vs. the non data channel case. E.g. for >> >> c=3DIN IP4 10.10.10.1 >> m=3Dmessage 7394 TCP/MSRP * >> a=3Daccept-types:message/cpim text/plain text/html >> a=3Dlang:.... >> a=3Dframerate:... >> The ignore behaviour would be the same. >> In the above example the attributes are scoped by the m=3D line. In th= e >> data channel case the attributes are scoped by the relevant a=3Ddcmap:= line. > > My concern is that SDP has no notion of subprotocol, even though in pra= ctice it shows up lots of=20 > places. It only has a notion of the protocol field in the m-line. Beyon= d that a *convention* has=20 > developed to denote a layering within the protocol through use of "/". = AFAIK this isn't formally=20 > written down anywhere. > > So, in principle we could define an RTP sub-protocol for use over a dat= a channel. And then we=20 > could talk about using the attributes that apply to RTP in dcsa for a c= hannel using RTP. But note=20 > there is no formal definition of the *protocol*s where RTP attributes a= re relevant. > > A lot of the very old stuff was just sloppy. To be fair, it was probabl= y good enough for the cases=20 > in front of them at the time, and they weren't yet in a position to for= esee how things would=20 > evolve. It is just another example of how old stuff rots and has to be = refreshed from time to time. > > But I don't think *this* draft is the place to fix it. So, in lieu of d= oing that I'm just looking=20 > for some way to clarify things. > > Thanks, > Paul > From nobody Fri Feb 26 07:53: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 EDD0E1A92BC for ; Fri, 26 Feb 2016 07:53:28 -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 XOYOTOl2LaVs for ; Fri, 26 Feb 2016 07:53:27 -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 1E2121A92BA for ; Fri, 26 Feb 2016 07:53:26 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-07v.sys.comcast.net with comcast id P3tN1s0052Bo0NV013tSak; Fri, 26 Feb 2016 15:53:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id P3tR1s00K3KdFy1013tRu3; Fri, 26 Feb 2016 15:53:26 +0000 To: Colin Perkins References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> From: Paul Kyzivat Message-ID: <56D074F4.2080401@alum.mit.edu> Date: Fri, 26 Feb 2016 10:53:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456502006; bh=IkDY+AScsSvUe5kBfb3r79E5h9lGfNeqd2KZ7sSgHTA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ELpa8dT8LWsuLHEEbK3zFLYF9ApdIOfI0tJJrdPAjifczkM8YcM9YPLrotkTyfepG v5jDDq5o6LoWevG2jkeF87/7+j94pTP73IJK+7KSWJ7KC5yi/syTKSGa00e3vJxb+e zw3vNj9SphYRhVxVoZqWkim4z/b+8M44uFstJML9MRRBfbLPOQsKaeNlAvagbSrExx 4aH+q+wsGoy3kCHp+SjhgN4b00U6TvH1VYXSRBGMbWzOcAVku+rnOpQ/GDSFKjlJKa Gdge+qMnIE/hyoVF5rCYjkw2NEDERd9v+3xLif/S8uGnNWRdzYN9kOCFcNHcv53IMo Yxc/w1JNZLxBQ== Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 15:53:29 -0000 Colin, Thanks for the clarifications. My knowledge of RTP is scant. (I'm gradually learning through osmosis.) More inline. On 2/26/16 4:39 AM, Colin Perkins wrote: >> On 25 Feb 2016, at 23:53, Paul Kyzivat wrote: >> >> On 2/25/16 6:19 PM, Colin Perkins wrote: >>> Hi, >>> >>>> On 25 Feb 2016, at 14:17, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>> I put together some text: >>>> >>>> "The scope of a mapping from a particular dynamic payload type number to a codec >>>> (or codec configuration) is for a given RTP media flow direction within a session. >>> >>> I think this conflicts with various RTP-related RFCs and drafts, although whether this conflict causes practical problems is unclear. RFC 3551 indicates that the binding between RTP payload type and RTP payload format is per RTP session, not per sender within an RTP session: >>> >>> mechanisms for defining dynamic payload type bindings have been >>> specified in the Session Description Protocol (SDP) and in other >>> protocols such as ITU-T Recommendation H.323/H.245. These mechanisms >>> associate the registered name of the encoding/payload format, along >>> with any additional required parameters, such as the RTP timestamp >>> clock rate and number of channels, with a payload type number. This >>> association is effective only for the duration of the RTP session in >>> which the dynamic payload type binding is made. This association >>> applies only to the RTP session for which it is made, thus the >>> numbers can be re-used for different encodings in different sessions >>> so the number space limitation is avoided. >>> >>> (note: reuse in different sessions, not different participants within a session) and: >> >> Does a sendrecv m-line established via O/A create one or two RTP sessions? > > One, since RTP sessions are defined by shared SSRC space, not directionality of media. OK. I thought that would be the answer, but was just checking. >> If one, then it seems this conflicts with 3264 allowing the two ends to use different PTs for the same codec configuration. > > That depends exactly what 3264 allows: if the two ends use different payload types to refer to the same codec, that’s okay; but if the two ends use the same payload type to refer to different codecs, that problematic. OK. That helps clarify what needs to be done. So it means that we have to say that the appearance of a PT in an offer or answer binds it to the corresponding codec configuration for the duration of the RTP session. An answerer can still choose to use a different PT for the same codec configuration. But he can't use a PT that has already been bound. Can we require a sender to honor the preference of the recipient in this regard? (For two-participant sessions - the kind we are usually setting up with O/A.) But an important point to this is that this binding is scoped by the RTP session, not the SIP (or O/A) session. So when the RTP session changes (because the addr/port changes at one of the ends) then old bindings no longer need to be preserved. And *that* solves the 3pcc problem, since in the 3pcc cases that matter the RTP session will change. As a side question, how do the predefined PTs fit into this? My guess is that the predefined PTs are *not* implicitly bound. They still must be bound by appearing in an offer or answer. And then they are only bound to their default codec configuration if there is no explicit rtpmap for the PT. ISTM this is starting to be clarified. But I think it is going to take quite a bit of careful writing to properly specify this. Thanks, Paul >> It always seemed to me that the original intent was to require the same PT number on both ends (perhaps because of what you quote), and that allowing the two ends to be different was an afterthought. If so, it may be that rfc3551 should have been updated. >> >> Is there any *technical* difficulty when the two ends use different PTs? (E.g. does it screw up rtcp reports?) > > Using different payload types to refer to the same codec is wasteful, but not harmful. > > Allowing different senders to use the same payload type to refer to different codecs is problematic. It makes the payload type to codec mapping depend on the SSRC, but SSRCs can change without signalling. > >> We are starting to get to the meat of the issue. The question is: what needs to be fixed? >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > From nobody Fri Feb 26 08:04:23 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 0DC261AC3C7 for ; Fri, 26 Feb 2016 08:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 c5BCeGKEG9Cr for ; Fri, 26 Feb 2016 08:04:14 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02671AC3C5 for ; Fri, 26 Feb 2016 08:04:14 -0800 (PST) Received: from [130.209.247.112] (port=52435 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aZKsE-0004sM-4E; Fri, 26 Feb 2016 16:04:10 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56D074F4.2080401@alum.mit.edu> Date: Fri, 26 Feb 2016 16:04:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 16:04:22 -0000 > On 26 Feb 2016, at 15:53, Paul Kyzivat wrote: >=20 > Colin, >=20 > Thanks for the clarifications. My knowledge of RTP is scant. (I'm = gradually learning through osmosis.) >=20 > More inline. >=20 > On 2/26/16 4:39 AM, Colin Perkins wrote: >>> On 25 Feb 2016, at 23:53, Paul Kyzivat = wrote: >>>=20 >>> On 2/25/16 6:19 PM, Colin Perkins wrote: >>>> Hi, >>>>=20 >>>>> On 25 Feb 2016, at 14:17, Christer Holmberg = wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I put together some text: >>>>>=20 >>>>> "The scope of a mapping from a particular dynamic payload type = number to a codec >>>>> (or codec configuration) is for a given RTP media flow direction = within a session. >>>>=20 >>>> I think this conflicts with various RTP-related RFCs and drafts, = although whether this conflict causes practical problems is unclear. RFC = 3551 indicates that the binding between RTP payload type and RTP payload = format is per RTP session, not per sender within an RTP session: >>>>=20 >>>> mechanisms for defining dynamic payload type bindings have been >>>> specified in the Session Description Protocol (SDP) and in other >>>> protocols such as ITU-T Recommendation H.323/H.245. These = mechanisms >>>> associate the registered name of the encoding/payload format, = along >>>> with any additional required parameters, such as the RTP = timestamp >>>> clock rate and number of channels, with a payload type number. = This >>>> association is effective only for the duration of the RTP = session in >>>> which the dynamic payload type binding is made. This = association >>>> applies only to the RTP session for which it is made, thus the >>>> numbers can be re-used for different encodings in different = sessions >>>> so the number space limitation is avoided. >>>>=20 >>>> (note: reuse in different sessions, not different participants = within a session) and: >>>=20 >>> Does a sendrecv m-line established via O/A create one or two RTP = sessions? >>=20 >> One, since RTP sessions are defined by shared SSRC space, not = directionality of media. >=20 > OK. I thought that would be the answer, but was just checking. >=20 >>> If one, then it seems this conflicts with 3264 allowing the two ends = to use different PTs for the same codec configuration. >>=20 >> That depends exactly what 3264 allows: if the two ends use different = payload types to refer to the same codec, that=E2=80=99s okay; but if = the two ends use the same payload type to refer to different codecs, = that problematic. >=20 > OK. That helps clarify what needs to be done. >=20 > So it means that we have to say that the appearance of a PT in an = offer or answer binds it to the corresponding codec configuration for = the duration of the RTP session. An answerer can still choose to use a = different PT for the same codec configuration. But he can=E2=80=99t use = a PT that has already been bound. Yes. > Can we require a sender to honor the preference of the recipient in = this regard? (For two-participant sessions - the kind we are usually = setting up with O/A.) That=E2=80=99s one for the signalling to decide. > But an important point to this is that this binding is scoped by the = RTP session, not the SIP (or O/A) session. So when the RTP session = changes (because the addr/port changes at one of the ends) then old = bindings no longer need to be preserved. >=20 > And *that* solves the 3pcc problem, since in the 3pcc cases that = matter the RTP session will change. Perhaps, but remember that an RTP session is defined by a shared SSRC = space, not by the addresses or ports used, so it depends how 3PCC moves = the addresses.=20 > As a side question, how do the predefined PTs fit into this? My guess = is that the predefined PTs are *not* implicitly bound. They still must = be bound by appearing in an offer or answer. And then they are only = bound to their default codec configuration if there is no explicit = rtpmap for the PT. The use is defined by the signalled RTP profile. If an RTP/AVP-derived = profile is used, the text in RFC 3551 applies: This profile reserves payload type numbers in the range 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound to new encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamic payload types. i.e., the fact that the m=3D line says RTP/AVP implies that the default = static payload type mappings are valid, unless over-ridden by an = a=3Drtpmap: line. > ISTM this is starting to be clarified. But I think it is going to take = quite a bit of careful writing to properly specify this. Right. Cheers, Colin --=20 Colin Perkins https://csperkins.org/ From nobody Fri Feb 26 08:28: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 42A161ACD7E for ; Fri, 26 Feb 2016 08:28:30 -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 hdflDKnradXN for ; Fri, 26 Feb 2016 08:28:28 -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 C8F891ACCFB for ; Fri, 26 Feb 2016 08:28:28 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-05v.sys.comcast.net with comcast id P4Th1s00E2JGN3p014UTcf; Fri, 26 Feb 2016 16:28:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id P4UT1s0043KdFy1014UTaA; Fri, 26 Feb 2016 16:28:27 +0000 To: Colin Perkins References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> From: Paul Kyzivat Message-ID: <56D07D29.2030500@alum.mit.edu> Date: Fri, 26 Feb 2016 11:28:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456504107; bh=MC4skMyBIWxOTcez8Cs63JliQIh/+6HUlYvQr4rk+Pc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Lig40fiDfRbY5YKFORjsRHEm6XY7B5qqA+AsES/+bRgSC1jJBiKWlxTa2EOCaNJNV OUwtwxMszaOZBX6c3E/MtlRvKNrCY2k/jMpHkBnfbd+ztQeaienYQEnIo2nLSQAhXO 93wznnqQcV1Smh2yxvej+GxsAaaTW1SiJUKzIqZturDNkVPya9oVyvyEsCFxjvwWZX CUEX72GvgyDu4Q5XoZPq8hwY1GuW2EgF3GWS/qH1rZIE4HGrZhMCsuUzi/Lmt25agg hj/KsbzN70crrnwABvegq3znz/boTPnY5wxx4WDh+nu/qrIlQv1ihfWVcTlMdMBD/b QJJJC3eV2eqmA== Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 16:28:30 -0000 On 2/26/16 11:04 AM, Colin Perkins wrote: >> So it means that we have to say that the appearance of a PT in an offer or answer binds it to the corresponding codec configuration for the duration of the RTP session. An answerer can still choose to use a different PT for the same codec configuration. But he can’t use a PT that has already been bound. > > Yes. > >> Can we require a sender to honor the preference of the recipient in this regard? (For two-participant sessions - the kind we are usually setting up with O/A.) > > That’s one for the signalling to decide. Would it be ok for us to say that a sender of RTP in a RTP session established using O/A MUST only use bindings specified in the most recent offer or answer from that recipient? >> But an important point to this is that this binding is scoped by the RTP session, not the SIP (or O/A) session. So when the RTP session changes (because the addr/port changes at one of the ends) then old bindings no longer need to be preserved. >> >> And *that* solves the 3pcc problem, since in the 3pcc cases that matter the RTP session will change. > > Perhaps, but remember that an RTP session is defined by a shared SSRC space, not by the addresses or ports used, so it depends how 3PCC moves the addresses. OK. Then we need more words. ISTM that at least for unicast O/A, each time an addr/port changes we establish a new SSRC space. There might be exceptions to this. For instance a mixer in a star configuration. In principle that could be used to bring another participant into a preexisting RTP session. But the only way I can see that could work in practice is for the mixer to send the first offer, and to enumerate all of the existing PT mappings. And of course the new participant won't be aware of existing SSRCs in use either. Again, I think this is going to be hard to specify. A *lot* more needs to be said than is currently in 3264. (And multicast O/A is a whole separate question. I don't even want to *think* about that right now.) >> As a side question, how do the predefined PTs fit into this? My guess is that the predefined PTs are *not* implicitly bound. They still must be bound by appearing in an offer or answer. And then they are only bound to their default codec configuration if there is no explicit rtpmap for the PT. > > The use is defined by the signalled RTP profile. If an RTP/AVP-derived profile is used, the text in RFC 3551 applies: > > This profile reserves payload type numbers in the range 96-127 > exclusively for dynamic assignment. Applications SHOULD first use > values in this range for dynamic payload types. Those applications > which need to define more than 32 dynamic payload types MAY bind > codes below 96, in which case it is RECOMMENDED that unassigned > payload type numbers be used first. However, the statically assigned > payload types are default bindings and MAY be dynamically bound to > new encodings if needed. Redefining payload types below 96 may cause > incorrect operation if an attempt is made to join a session without > obtaining session description information that defines the dynamic > payload types. > > i.e., the fact that the m= line says RTP/AVP implies that the default static payload type mappings are valid, unless over-ridden by an a=rtpmap: line. I *think* what you said confirms what I was guessing. Thanks, Paul From nobody Fri Feb 26 09:04: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 50C691B2A24 for ; Fri, 26 Feb 2016 09:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 B8r5AZ94r7qg for ; Fri, 26 Feb 2016 09:04:10 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 A3BAA1B2A2B for ; Fri, 26 Feb 2016 09:04:05 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id y8so39700430igp.1 for ; Fri, 26 Feb 2016 09:04:05 -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; bh=TfrSxp1zbE8Yn6GAocsEZpwp2YsSEOSmg8deFEg15G8=; b=mYn5rVzzICkoaRGQXdpP5GtmAGQ6ilp4OZxFfaRoiBUNcHqI/4TcVlLM/KD964r7cC ZD5Aic6QFgLVraZzMMtheYRi6BYy2TwlECbsjsFKwRwfm+IvFYS0/0O31DJ6yFGSeTvg RMoujpcnVRQjmbZ5XLaVJdduZz/RvLZzJMYQFHJcO50GBYktRnlLYFSFyH/UcMzlAJj2 4XjIxvFvGwTPH+KBS0Qn9srAK/f2qDjM/dMouBUIwi6IPRAnu5Z8TE5jZYPzOlK0mIG/ ysCrLfA+2Z7+e0S3ETaZ+DgUwvrT39f29SwrO4nBh8jrIO21gqpEMZDAzd9dFy8QVmvp nahw== 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; bh=TfrSxp1zbE8Yn6GAocsEZpwp2YsSEOSmg8deFEg15G8=; b=jVs5fhOkSQ0UAhs7lLn/7Z6oHPaTmXkLTKDKqmq5WMSOVNIAMu6/aY4Bi2pjc+C90e bCkVl4ijojxUlD83RjNBRG9LGxDt9vGVts5w7MvUEn8oCVsCk5d6Pe5bpmQOmrmjdVQb EG0ohYeMI4dBBArPUj6nbh2G31+RZXOY2K1OSSO/8/C9yEwxm0MQu20BwuFiMnlOKM2C Nxoqy1opGbETPNOsnqGKpG2baMrcHw3an4Pb3oj3cWjJgdZuw3KCmwoiSLNhZLvkypfR xAuH6YCloKCJS0mWoRGZaoRFBQDIzCOCwkrRw5ZbghFwJ3tQ1m+JDwdYW8XLEs+xJnO1 coLw== X-Gm-Message-State: AD7BkJLEYr+wnUP4DRmzxoOjwEShLSZnaKnY3fs6vYFRmrugIixabxwTbuX1Igvjis4Vmw== X-Received: by 10.50.43.133 with SMTP id w5mr3850613igl.47.1456506245020; Fri, 26 Feb 2016 09:04:05 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by smtp.gmail.com with ESMTPSA id hv3sm1643612igb.13.2016.02.26.09.04.02 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 09:04:03 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id g6so42756980igt.1 for ; Fri, 26 Feb 2016 09:04:02 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.194 with SMTP id y2mr3788654igl.96.1456506242468; Fri, 26 Feb 2016 09:04:02 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 09:04:02 -0800 (PST) In-Reply-To: <56D07D29.2030500@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> Date: Fri, 26 Feb 2016 12:04:02 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bfea0b6321734052caf49bc Archived-At: Cc: Colin Perkins , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:04:11 -0000 --047d7bfea0b6321734052caf49bc Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 11:28 AM, Paul Kyzivat wrote: > Would it be ok for us to say that a sender of RTP in a RTP session > established using O/A MUST only use bindings specified in the most recent > offer or answer from that recipient? Unfortunately this is not that simple. For instance if end point sends an offer but have not received the answer. It does not know if the offer is accepted yet, so it does not know if old RTP or new RTP session is used. Another complication is that offer/answer does not always establishes a new RTP session. For instance, when SIP session timer is used with INVITE, INVITE with the same SDP as the latest SDP sent by this end point is often sent and the same answer as before is received. In this case same SSRCs are reused and RTP typically flows unaffected. The rules that I follow in my implementations (and this might only work for audio/video) are as follows: 1. Any offer sent by an end point is compatible with the last accepted offer/answer. This offer is reusing the same PT for the same codec profiles from the offer/answer exchange. If there are two PT for the same codec profile, local PT is used for this codec profile. Any codec profile added is not using any PT from the last offer/answer exchange. 2. Any answer is generated to use the same PT as the offer received, even if they conflict 3. Whenever SSRC or PT changes, new jitter buffer is started. This jitter buffer has a probation period which validates that several valid packet are received in sequence. Once packets in jitter buffer are validated, new codec instance is initialized based on the combination of the last negotiated offer/answer and, if exists, the outstanding offer. There are some extra provisions to provide smooth switch over from playback of existing RTP stream to the new one. This obviously disregards the MUST NOT reuse PT rule, but is quite robust and works well in practice. Regards, _____________ Roman Shpount --047d7bfea0b6321734052caf49bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 26, 2016 = at 11:28 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:=
Would it be ok = for us to say that a sender of RTP in a RTP session established using O/A M= UST only use bindings specified in the most recent offer or answer from tha= t recipient?

Unfortunately this is not that= simple. For instance if end point sends an offer but have not received the= answer. It does not know if the offer is accepted yet, so it does not know= if old RTP or new RTP session is used.

Another co= mplication is that offer/answer does not always establishes a new RTP sessi= on. For instance, when SIP session timer is used with INVITE, INVITE with t= he same SDP as the latest SDP sent by this end point is often sent and the = same answer as before is received. In this case same SSRCs are reused and R= TP typically flows unaffected.

The rules that I fo= llow in my implementations (and this might only work for audio/video) are a= s follows:

1. Any offer sent by an end point is co= mpatible with the last accepted offer/answer. This offer is reusing the sam= e PT for the same codec profiles from the offer/answer exchange. If there a= re two PT for the same codec profile, local PT is used for this codec profi= le. Any codec profile added is not using any PT from the last offer/answer = exchange.

2. Any answer is generated to use the sa= me PT as the offer received, even if they conflict

3. Whenever SSRC or PT changes, new jitter buffer is started. This jitter = buffer has a probation period which validates that several valid packet are= received in sequence. Once packets in jitter buffer are validated, new cod= ec instance is initialized based on the combination of the last negotiated = offer/answer and, if exists, the outstanding offer. There are some extra pr= ovisions to provide smooth switch over from playback of existing RTP stream= to the new one.

This obviously disregards the MUS= T NOT reuse PT rule, but is quite robust and works well in practice.
<= div>
Regards,
_____________
Roman Shpount
=C2=A0
--047d7bfea0b6321734052caf49bc-- From nobody Fri Feb 26 09:07: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 7E5DC1B2A38 for ; Fri, 26 Feb 2016 09:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 bFTx1Zxvk6EQ for ; Fri, 26 Feb 2016 09:07:00 -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 D37A81B2A30 for ; Fri, 26 Feb 2016 09:06:59 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id 9so123673291iom.1 for ; Fri, 26 Feb 2016 09:06: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; bh=fmlnhryer8rtsjHO+/tfQhFywUp4ODBGyU8P2TpBvkQ=; b=MYYAW2jSLre8+a/Jb9JXT/mRUCgbyTU+1AYxMypUBwkq372NiFq5WbK9TrG+RkRvVq UZGSV4Q5xZpd7/KvmD4d2+hutW+5ECFE4XaoflURCPlO9QtQyNFt1NhkpUrLfXkPMo1X O7ip2C2nbqlHHCpnWDVWx0283mCwIwAiICywlvLvaOnT4mvw1KBHlTmyMzCq9NwfLjf7 najhav1LSmUxfTi8Vf6SZC99GoeOaEIRBdM3+W5S8aTT9RaHS+dH44Z1B2kMKpp4eRpd SM+F2O4oM52qKfPGXSU05c3fe21LBWAUsBLPvV0jJA3USDS02aI08iWc0QWbL636tIBm aCPw== 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; bh=fmlnhryer8rtsjHO+/tfQhFywUp4ODBGyU8P2TpBvkQ=; b=L+/bgq0hiuEBrlJcIm+ggFRyHgGcbSi2GmgBfkI24ZafTgC6ZJf+hzIC6WL8wMc7q2 +4aYClWzFqahcrO+JQVerwgqiE5P+fg5xkb34ukDICl1TfwjXr7tweVqNDoo8QyDpxHl xZDJ21qRevk0NYWrbKM3fuDJw6VrCv7eD8bdt3ULhyGn0CK+nD7mWTZ3myfp8HkN5uOx rwN0rZAtZeAmyPSVPjvQ3UMcarSx8lGX5MockX04dzo4l5iU9ke6vaACpIx5mQwTKkHq CDtkBjBH/S6Tmrm/KN7iOf2mBip3o89z8J+xOSBQd94XICcgwnBmkOktEQYhJn3/5iGp q94A== X-Gm-Message-State: AG10YOQzc5UM90OL8L/cpQPK5aYJvRfOL5xsvJLMyMf9edce8e1S6b86K5i4TgXNwwYeuw== X-Received: by 10.107.38.78 with SMTP id m75mr9407677iom.15.1456506419314; Fri, 26 Feb 2016 09:06:59 -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 n3sm1658352igr.17.2016.02.26.09.06.57 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 09:06:57 -0800 (PST) Received: by mail-io0-f180.google.com with SMTP id g203so128331690iof.2 for ; Fri, 26 Feb 2016 09:06:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr9422519iod.145.1456506417199; Fri, 26 Feb 2016 09:06:57 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 09:06:57 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> Date: Fri, 26 Feb 2016 12:06:57 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Colin Perkins Content-Type: multipart/alternative; boundary=001a113ece609c4e91052caf53ab Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:07:04 -0000 --001a113ece609c4e91052caf53ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins wrote: > That depends exactly what 3264 allows: if the two ends use different > payload types to refer to the same codec, that=E2=80=99s okay; but if the= two ends > use the same payload type to refer to different codecs, that problematic. > Why is using the same PT to refer to different codecs is problematic? Can you point out any potential problems that this will cause from RTP perspective? Regards, _____________ Roman Shpount --001a113ece609c4e91052caf53ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins <<= a href=3D"mailto:csp@csperkins.org" target=3D"_blank">csp@csperkins.org= > wrote:
That depends exactly what 3264 allows: if the two ends use different pay= load types to refer to the same codec, that=E2=80=99s okay; but if the two = ends use the same payload type to refer to different codecs, that problemat= ic.

Why is using the same PT to refer t= o different codecs is problematic? Can you point out any potential problems= that this will cause from RTP perspective?

Regard= s,
_____________
Roman Shpount<= /div>
=C2=A0
--001a113ece609c4e91052caf53ab-- From nobody Fri Feb 26 09:20: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 2D16B1B2AFC for ; Fri, 26 Feb 2016 09:20:39 -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 jEOAOwx65Mvj for ; Fri, 26 Feb 2016 09:20:37 -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 BFA3D1B2AF5 for ; Fri, 26 Feb 2016 09:20:37 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-12v.sys.comcast.net with comcast id P5Ku1s0012LrikM015Ld8v; Fri, 26 Feb 2016 17:20:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id P5Lc1s0013KdFy1015Lcas; Fri, 26 Feb 2016 17:20:36 +0000 To: Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> From: Paul Kyzivat Message-ID: <56D08962.3060006@alum.mit.edu> Date: Fri, 26 Feb 2016 12:20:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.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=1456507237; bh=iTtPQV5e9y5JPR/XoPzFCaHV3ukmwkmen5yA710MHUo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pWQI/sijVXEZYcAdyGdj8evKUmeYnIBidkMBnoKr4N+024LwYFzHMdalIUs02DTlZ TXMp1aWxcM4uQPFeaNuuXYdMZ59/dl02upSrCJMV0LqqeGG4caz/aLgxsfCLrpJzkN JaTGBoT3d94GiBmo9Ogxn0EnuQ5AYa8v3nYFIQFQwCYR31SdlHpUMvMVwSxdNnoYMp t+4OKudaUgnsXCLNjdfY9Ce1u548wfTg1tttCuOpbJUo8t9poaNfayaCPDAuN6MrM4 /RE0F+jVtqE3uGgs1rcR6RjVDkoB7WykEd/u5u5BeQYN+TfJHNJJOU+9rtwCspHVqz WPDPdX3RYQsgQ== Archived-At: Cc: Colin Perkins , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:20:39 -0000 On 2/26/16 12:04 PM, Roman Shpount wrote: > On Fri, Feb 26, 2016 at 11:28 AM, Paul Kyzivat > wrote: > > Would it be ok for us to say that a sender of RTP in a RTP session > established using O/A MUST only use bindings specified in the most > recent offer or answer from that recipient? > > > Unfortunately this is not that simple. For instance if end point sends > an offer but have not received the answer. It does not know if the offer > is accepted yet, so it does not know if old RTP or new RTP session is used. Yes. But it is using the PTs specified by the *other* end, not its own end. And those can be used as soon as received. It doesn't matter if an offer it has send was accepted. If it has sent a new offer, but not yet received an answer to it, then what I proposed means it is still sending in accord to the last offer/answer that it *received*. (This may need some tweaking to deal with what to do *after* a re-offer has been sent and rejected.) > Another complication is that offer/answer does not always establishes a > new RTP session. For instance, when SIP session timer is used with > INVITE, INVITE with the same SDP as the latest SDP sent by this end > point is often sent and the same answer as before is received. In this > case same SSRCs are reused and RTP typically flows unaffected. The session remains, and so the PT bindings remain. But the O/A rules are negotiating which of those are to be used going forward. If the new offer no longer mentions some PTs that were previously bound, then it is saying that it doesn't want to receive them any more. It is becoming clear to me that it will be necessary to define PT bindings - what they are, when they are established, when they are forgotten, and the scope within which they live. Each participant will need to know these bindings, and they must agree on them, except for well defined signaling delays. I guess this is a lot like an RTP session, except that it is tied to O/A signaling. Thanks, Paul > The rules that I follow in my implementations (and this might only work > for audio/video) are as follows: > > 1. Any offer sent by an end point is compatible with the last accepted > offer/answer. This offer is reusing the same PT for the same codec > profiles from the offer/answer exchange. If there are two PT for the > same codec profile, local PT is used for this codec profile. Any codec > profile added is not using any PT from the last offer/answer exchange. > > 2. Any answer is generated to use the same PT as the offer received, > even if they conflict > > 3. Whenever SSRC or PT changes, new jitter buffer is started. This > jitter buffer has a probation period which validates that several valid > packet are received in sequence. Once packets in jitter buffer are > validated, new codec instance is initialized based on the combination of > the last negotiated offer/answer and, if exists, the outstanding offer. > There are some extra provisions to provide smooth switch over from > playback of existing RTP stream to the new one. > > This obviously disregards the MUST NOT reuse PT rule, but is quite > robust and works well in practice. > > Regards, > _____________ > Roman Shpount From nobody Fri Feb 26 09:34: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 72C091A1BB1 for ; Fri, 26 Feb 2016 09:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 nHalhEMf26Mm for ; Fri, 26 Feb 2016 09:34:21 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE5A1B2BC3 for ; Fri, 26 Feb 2016 09:34:21 -0800 (PST) Received: from [130.209.247.112] (port=53336 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aZMHT-0007UW-6w; Fri, 26 Feb 2016 17:34:19 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_20474B34-9418-4DCC-9D0D-8424DAD2A337" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Fri, 26 Feb 2016 17:34:18 +0000 Message-Id: <7BD08FA0-DEC4-4FCF-8A23-2043079C0C46@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> To: Roman Shpount X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:34:23 -0000 --Apple-Mail=_20474B34-9418-4DCC-9D0D-8424DAD2A337 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Feb 2016, at 17:06, Roman Shpount wrote: >=20 > On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins > wrote: > That depends exactly what 3264 allows: if the two ends use different = payload types to refer to the same codec, that=E2=80=99s okay; but if = the two ends use the same payload type to refer to different codecs, = that problematic. >=20 > Why is using the same PT to refer to different codecs is problematic? = Can you point out any potential problems that this will cause from RTP = perspective? If I receive a packet with payload type X, how do I know which of the = codecs it refers to? You=E2=80=99d have to make the PT mapping per SSRC, but the SSRCs can = change without signalling, so that doesn=E2=80=99t help unless you = somehow label the RTP stream with a header extension that says what = payload type space it=E2=80=99s using.=20 The entire point of the PT is that it uniquely identifies a codec = configuration. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_20474B34-9418-4DCC-9D0D-8424DAD2A337 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Feb 2016, at 17:06, Roman Shpount <roman@telurix.com> = wrote:

On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins = <csp@csperkins.org> wrote:
That depends exactly what 3264 allows: if = the two ends use different payload types to refer to the same codec, = that=E2=80=99s okay; but if the two ends use the same payload type to = refer to different codecs, that problematic.

Why is using the same PT to refer to different codecs is = problematic? Can you point out any potential problems that this will = cause from RTP = perspective?

If I receive a packet with payload type X, how do = I know which of the codecs it refers to?

You=E2=80=99d have to make the PT mapping per = SSRC, but the SSRCs can change without signalling, so that doesn=E2=80=99t= help unless you somehow label the RTP stream with a header extension = that says what payload type space it=E2=80=99s using. 

The entire point of the PT is that it uniquely identifies a = codec configuration.

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



= --Apple-Mail=_20474B34-9418-4DCC-9D0D-8424DAD2A337-- From nobody Fri Feb 26 09:40: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 DC6EB1B2BCD for ; Fri, 26 Feb 2016 09:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 VlAEjg6Hh9Lj for ; Fri, 26 Feb 2016 09:40:33 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 8D4D51B2BC8 for ; Fri, 26 Feb 2016 09:40:33 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id y8so42705425igp.0 for ; Fri, 26 Feb 2016 09:40: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; bh=3c3MzcBME7bS1+pUuwP//y0abKFvSbC52EKMwmn7C3g=; b=Z82LWJ/HwQlGtfYV6mGilGdOCOoZgf8xfUbWk1ohNpgWfBD2Jy1BZon0AE2MVqMvkF sQ3x+sCNaCXFsh9cTZFNnMVfOe/zC3gclwnc15CuczEur/UYwHN0LIZYxq1NsUA+Lyuq NdZr30SO0HfhtEA5g8HLo44dokRZbsySPO721U9SiplYR48s68NUlvLgLj2Utd8Z6WVH VteyuC4NbCXalnoXcgyoNEqldn+LUqz8PfQza218usBxkwUmlRhieYvtS4+egQuMthyz NE4mdEPpwGt638SKevn2Vux1EFB+cPgs8Rz04FZUr50/RiuwaZ/3NZhfI3KY0tzRkhe0 tAyw== 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; bh=3c3MzcBME7bS1+pUuwP//y0abKFvSbC52EKMwmn7C3g=; b=eH1EB9ihgQ1z4sUc4T+fsxDDiwHWPUNgys784q6qMtFPZiaecFCLaPtkrGFkVoN7AS xT7mu+81NfYB1DWf4rbBmEYyt6rj9DWv94BjBWISJI20PkQLnwvnZ7ECq3Gp48YwMTJ5 c/EHh/dlQsq56i6TNYXb/23crUdWWidXHFVm/BpYKuQ05+K0OksKvV1dK4oW+r/lJ0em /oZD+dsU4wX6i8cGzosm7QTgoL5hIC/7f4vuQ+HELPEneee+ghmf/cyPqCvsHT58wd7F aIF+tf4azTN7ClM7CivFgxk/YB9PQIvf6UPhMXVZiHsnIKwkxN29VqyAYRibI+mqkmwr 3Q4Q== X-Gm-Message-State: AD7BkJLMnJQnZ7oJpKgvv16Exmkb99NtQvXwLi7TQnBK/FOyDOfZwkFGxNOhOEpPPxfkLQ== X-Received: by 10.51.17.34 with SMTP id gb2mr3950343igd.13.1456508433038; Fri, 26 Feb 2016 09:40:33 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id o12sm1400734igi.4.2016.02.26.09.40.31 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 09:40:31 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id 9so124643754iom.1 for ; Fri, 26 Feb 2016 09:40:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr8595861ioe.38.1456508430684; Fri, 26 Feb 2016 09:40:30 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 09:40:30 -0800 (PST) In-Reply-To: <7BD08FA0-DEC4-4FCF-8A23-2043079C0C46@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <7BD08FA0-DEC4-4FCF-8A23-2043079C0C46@csperkins.org> Date: Fri, 26 Feb 2016 12:40:30 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Colin Perkins Content-Type: multipart/alternative; boundary=001a1140b4729fa0f7052cafcb8e Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:40:35 -0000 --001a1140b4729fa0f7052cafcb8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 26, 2016 at 12:34 PM, Colin Perkins wrote: > > On 26 Feb 2016, at 17:06, Roman Shpount wrote: > > On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins wrote: > >> That depends exactly what 3264 allows: if the two ends use different >> payload types to refer to the same codec, that=E2=80=99s okay; but if th= e two ends >> use the same payload type to refer to different codecs, that problematic= . >> > > Why is using the same PT to refer to different codecs is problematic? Can > you point out any potential problems that this will cause from RTP > perspective? > > > If I receive a packet with payload type X, how do I know which of the > codecs it refers to? > > You=E2=80=99d have to make the PT mapping per SSRC, but the SSRCs can cha= nge > without signalling, so that doesn=E2=80=99t help unless you somehow label= the RTP > stream with a header extension that says what payload type space it=E2=80= =99s > using. > > The entire point of the PT is that it uniquely identifies a codec > configuration. > Why does PT needs to be unique in both directions (entire RTP session) vs unique in each direction? Having a unique PT in each direction is enough to unambiguously decode the packet. SSRC might change but the packet flow direction is well known when the packet is received. P.S. I am, of cause, talking about unicast sessions only. _____________ Roman Shpount --001a1140b4729fa0f7052cafcb8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 26, 2016 at 12:34 PM, Colin Perkins <= csp@csperkins.org> wrote:


O= n Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins <csp@csperkins.org> wrote:
Tha= t depends exactly what 3264 allows: if the two ends use different payload t= ypes to refer to the same codec, that=E2=80=99s okay; but if the two ends u= se the same payload type to refer to different codecs, that problematic.

Why is using the same PT to refer to diff= erent codecs is problematic? Can you point out any potential problems that = this will cause from RTP perspective?

If I receive a packet with payload type X, how d= o I know which of the codecs it refers to?

You=E2= =80=99d have to make the PT mapping per SSRC, but the SSRCs can change with= out signalling, so that doesn=E2=80=99t help unless you somehow label the R= TP stream with a header extension that says what payload type space it=E2= =80=99s using.=C2=A0

The entire point of the PT is that= it uniquely identifies a codec configuration.

<= /div>
Why does PT needs to be unique in both directions (entire RTP ses= sion) vs unique in each direction? Having a unique PT in each direction is = enough to unambiguously decode the packet. SSRC might change but the packet= flow direction is well known when the packet is received.

P.S. I am, of cause, talking about unicast sessions only.
_____________
Roman Shpount
=
=C2=A0
--001a1140b4729fa0f7052cafcb8e-- From nobody Fri Feb 26 09:42:24 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 0E7661B2BD4 for ; Fri, 26 Feb 2016 09:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 75EdvZ6OaDHt for ; Fri, 26 Feb 2016 09:42:20 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5312A1B2BD6 for ; Fri, 26 Feb 2016 09:42:20 -0800 (PST) Received: from [130.209.247.112] (port=53376 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aZMPA-0008UP-7P; Fri, 26 Feb 2016 17:42:16 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_FAEF43C1-7AD4-40DA-A2BE-0319FBCE1C1A" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Fri, 26 Feb 2016 17:42:15 +0000 Message-Id: <0B916011-8889-480D-9890-65336341D534@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <7BD08FA0-DEC4-4FCF-8A23-2043079C0C46@csperkins.org> To: Roman Shpount X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:42:22 -0000 --Apple-Mail=_FAEF43C1-7AD4-40DA-A2BE-0319FBCE1C1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Feb 2016, at 17:40, Roman Shpount wrote: >=20 > On Fri, Feb 26, 2016 at 12:34 PM, Colin Perkins > wrote: >=20 >> On 26 Feb 2016, at 17:06, Roman Shpount > wrote: >>=20 >> On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins > wrote: >> That depends exactly what 3264 allows: if the two ends use different = payload types to refer to the same codec, that=E2=80=99s okay; but if = the two ends use the same payload type to refer to different codecs, = that problematic. >>=20 >> Why is using the same PT to refer to different codecs is problematic? = Can you point out any potential problems that this will cause from RTP = perspective? >=20 > If I receive a packet with payload type X, how do I know which of the = codecs it refers to? >=20 > You=E2=80=99d have to make the PT mapping per SSRC, but the SSRCs can = change without signalling, so that doesn=E2=80=99t help unless you = somehow label the RTP stream with a header extension that says what = payload type space it=E2=80=99s using.=20 >=20 > The entire point of the PT is that it uniquely identifies a codec = configuration. >=20 > Why does PT needs to be unique in both directions (entire RTP session) = vs unique in each direction? Having a unique PT in each direction is = enough to unambiguously decode the packet. SSRC might change but the = packet flow direction is well known when the packet is received. Because there might be more than one participant in the session. > P.S. I am, of cause, talking about unicast sessions only. So am I. Unicast !=3D only two participants.=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_FAEF43C1-7AD4-40DA-A2BE-0319FBCE1C1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Feb 2016, at 17:40, Roman Shpount <roman@telurix.com> = wrote:

On Fri, Feb 26, 2016 at 12:34 PM, Colin = Perkins <csp@csperkins.org> wrote:

On 26 Feb 2016, at 17:06, Roman = Shpount <roman@telurix.com> wrote:

On Fri, Feb 26, 2016 at 4:39 AM, Colin = Perkins <csp@csperkins.org> wrote:
That depends exactly what 3264 allows: if = the two ends use different payload types to refer to the same codec, = that=E2=80=99s okay; but if the two ends use the same payload type to = refer to different codecs, that problematic.

Why is using the same PT to refer to different codecs is = problematic? Can you point out any potential problems that this will = cause from RTP = perspective?

If I receive a packet with = payload type X, how do I know which of the codecs it refers = to?

You=E2=80=99= d have to make the PT mapping per SSRC, but the SSRCs can change without = signalling, so that doesn=E2=80=99t help unless you somehow label the = RTP stream with a header extension that says what payload type space = it=E2=80=99s using. 

The = entire point of the PT is that it uniquely identifies a codec = configuration.

Why does PT needs to be unique in both directions (entire = RTP session) vs unique in each direction? Having a unique PT in each = direction is enough to unambiguously decode the packet. SSRC might = change but the packet flow direction is well known when the packet is = received.

Because there might be more than one participant in the = session.

P.S. I = am, of cause, talking about unicast sessions = only.

So am I. Unicast !=3D only two = participants. 


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



= --Apple-Mail=_FAEF43C1-7AD4-40DA-A2BE-0319FBCE1C1A-- From nobody Fri Feb 26 09:46: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 007871B2C2C for ; Fri, 26 Feb 2016 09:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=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 KHhr9f8IKG9O for ; Fri, 26 Feb 2016 09:46:05 -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 1B90B1B2C32 for ; Fri, 26 Feb 2016 09:46:02 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with comcast id P5kj1s00629Cfhx015m29v; Fri, 26 Feb 2016 17:46:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id P5m11s00V3KdFy1015m1hd; Fri, 26 Feb 2016 17:46:02 +0000 To: mmusic@ietf.org References: <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> <56D05E8D.5080306@alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56D08F58.1040709@alum.mit.edu> Date: Fri, 26 Feb 2016 12:46:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D05E8D.5080306@alcatel-lucent.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=1456508762; bh=rxnqjW178BHn5j6kjul+wcsbV3aV7O/fuV+xs0FntHg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=FDaH1Zv6CZmOqfVGMoedYLBZtmlSZ5VU5OuwG6wdFhKdQE5AapM5jM5NMV2yfqyyz 3ktuIQGO2MtSarKlLGt5xcnRHfiT4byIXJidQhpJznSdr0YNzmdJNBmaLz/Txxph5w cRJ12JsY9FspgAg8Ft+jiaWGt71L1kixznwJ3meEEO4JBxUE2cUUg72+peufl55FHz usBqkkbQE7wSw9MEv9Q+7Hak44LKevowWjHEkDmB4bbckDCsJRme1VQeQXKnjdzDAk AyigcwH7P84ChL40FMWcKgfrqcoT8u6d/2fR4+YOh+AUcP5Pa4xHRTqSlbQKFNnlLs /QctJbtW672Ag== 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, 26 Feb 2016 17:46:08 -0000 Hi, On 2/26/16 9:17 AM, Juergen Stoetzer-Bradler wrote: > Hello Paul, Christian, > > Would propose to add following definition of term "subprotocol" to the > terminology section 3 of the sdpneg draft: > > Data channel subprotocol: The application protocol which is > transported over a single data channel. Data channel subprotocol > messages are sent as data channel payload over an established data > channel. If an SDP offer/answer exchange is used as specified in > this document to negotiate the establishment of data channels, > corresponding data channel properties, associated data channel > subprotocols and data channel subprotocol properties, then the data > channel subprotocols may be identified by the values of the > "subprotocol" parameters of the SDP "a=dcmap" attributes as > described in Section 5.1.1.5. Within this document the term "data > channel subprotocol" is often abbreviated as just "subprotocol". > > This text could explicitly narrow down the notion of "subprotocol" > within the data channel SDP offer/answer context and might especially be > helpful distinguishing it from the usages of "subprotocol" in the > Websocket RFC 6455 (where the term "subprotocol" was taken from, but > where it does not seem to be formally defined). This text may certainly > not be helpful in more general non-data channel contexts. But it might > help to clarify that every occurrence of of the term "subprotocol" in > the sdpneg draft refers to the application protocol which (typically but > not necessarily) is identified via the a=dcmap's "subprotocol" parameter. > > Would such an explicit definition be helpful from your point of view? It might *help*, but it doesn't get at the main problem I see. The question is how does this sub-protocol relate the the proto field used in m-lines? But not to the proto of the m-line for data channel. My point is that many sdp attributes were designed to be used with particular proto fields. For instance, with RTP/AVP, RTP/AVPF, TCP/RTP/AVP, RTP/SAVP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, RTP/SAVPF, UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF, DCCP/TLS/RTP/SAVPF, ... In general they are described as being applicable to RTP. But what is RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a super-protocol (of AVP, AVPF, SAVP, SAVPF)? If we wanted to define use of RTP over a data channel, what sub-protocol(s) would we have to define? I *think* we would have to define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted to support over a data channel. And then how would we do it, and where would we specify which attributes could be used with dcsa? Would we have to update the documents that define those attributes? ISTM there are similar (though not so complex) issues for pretty much any attribute that we might want to reuse over a data channel. Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the websocket/datachannel registry. And then that document might say that any sdp attribute designed to be used with protos */(each of these subprotocols) may also be used in dcsa for a channel using these protocols. Thanks, Paul > Thanks, > Juergen > > > On 25.02.2016 22:38, EXT Paul Kyzivat wrote: >> On 2/24/16 7:24 PM, Christian Groves wrote: >>> Hello Juergen and Paul, >>> >>> Please see at end. >>> >>> Regards, Christian >>> >>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>>> ..snip.. >>>>> >>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>>> >>>>>>> Have just submitted version 08 of >>>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>>> The changes compared to version 07 are essentially as follows. >>>>>>> >>>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>>> regarding the >>>>>>> relationship of subprotocols and their attributes. >>>>>>> * Two new SDP offer/answer considerations in section 5.2.5 >>>>>>> (Various >>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>>>> channel transport specific semantic is not known. >>>>>>> * A new paragraph in section 8.1 (IANA Considerations / >>>>>>> Subprotocol >>>>>>> Identifiers) related to cases, where a subprotocol is defined for >>>>>>> data >>>>>>> channel and Websocket transport. >>>>>>> >>>>>>> These changes should address the points discussed in this email >>>>>>> thread. >>>>>> >>>>>> This is an improvement. But I think things could still be made >>>>>> clearer. >>>>>> >>>>>> Consider the following addition to 5.1.2.1: >>>>>> >>>>>> 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. A data channel >>>>>> specific usage of a subprotocol attribute is expected to be >>>>>> specified >>>>>> in the same document, which registers the subprotocol's identifier >>>>>> for data channel usage as described in Section 8.1. >>>>>> >>>>>> This text makes sense when there is a clear distinction between >>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved >>>>>> there >>>>>> is no such clear distinction in many cases, such as RTP over UDP or >>>>>> TCP, etc. Those are combined into a single protocol value. While that >>>>>> can usually be parsed apart at slashes, there isn't good terminology >>>>>> for it. >>>>>> >>>>>> My point is that when I read the above, I don't know how it applies >>>>>> to, say, RTP attributes. Or does it only apply for attributes that >>>>>> are >>>>>> clearly defined for a *sub*protocol? >>>>>> >>>>>> I think this is primarily that we lack well defined vocabulary for >>>>>> all >>>>>> of this. But I think it would be too much to expect this draft to >>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it >>>>>> would be >>>>>> sufficient to give some concrete examples, even if they have to be >>>>>> hypothetical ones. >>>>> >>>>> [Juergen] Agree that it would be helpful to have more precise >>>>> definitions of the differences of the terms protocol and subprotocol, >>>>> especially when those terms are used outside the scope of data >>>>> channels >>>>> (or Websockets). When only focusing on data channels the notion of a >>>>> "subprotocol" seems to be clearer - at least >>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" >>>>> parameter. >>>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>>> informally starts using the term "subprotocol" in the introduction and >>>>> there refers to Websocket "subprotocols". Perhaps we should add the >>>>> term >>>>> "subprotocol" to the list of used terminology in section 3. >>>>> >>>>> The sdpneg document, together with the data channel subprotocol >>>>> specific >>>>> document (which defines the value of the a=dcmap attribute's >>>>> "subprotocol" parameter), should certainly give clear guidance on >>>>> how to >>>>> interpret SDP offers or answers like e.g.: >>>>> >>>>> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >>>>> c=IN IP4 10.10.10.1 >>>>> a=max-message-size:100000 >>>>> a=sctp-port:5000 >>>>> ... >>>>> a=dcmap:0 subprotocol="MSRP" >>>>> a=dcsa:0 accept-types:message/cpim text/plain >>>>> a=dcsa:0 framerate:... >>>>> a=dcsa:0 lang:... >>>>> >>>>> An implementation receiving such an offer would need to decide what to >>>>> do with the dcsa embedded framerate and lang attributes. Or, someone >>>>> implementing MSRP over data channel based services may need to decide >>>>> whether or not to use these attributes, and if yes, how. >>>>> (I am using these two attributes just as hypothetical examples - don't >>>>> want to suggest that those may indeed be used for MSRP over data >>>>> channel >>>>> transport). >>>>> >>>>> The msrp-usage-data-channel document doesn't mention these two >>>>> attributes. When looking at the IANA SDP attribute registry tables, I >>>>> would find both attributes specified in RFC 4566. There, >>>>> "framerate" is >>>>> explicitly said to be defined only "for video media". Just to be >>>>> sure I >>>>> could additionally have a look at the MSRP specifying documents, RFC >>>>> 4975 and RFC 4976, but there would not find any text at all related to >>>>> "framerate". So this case seems pretty clear and I would therefore >>>>> conclude that the "framerate" attribute should not be used for >>>>> MSRP, and >>>>> that a receiver of such an offer or answer should ignore it. >>>>> >>>>> When looking at the definition of the "lang" attribute in RFC 4566 I >>>>> would not see any explicit hint of what protocols this attribute might >>>>> be used with, especially if "lang" could be used when negotiating an >>>>> MSRP session. When then looking at RFC 4975 I would indeed find >>>>> "lang" - >>>>> but not as SDP attribute, rather as XML tag parameter within an >>>>> example >>>>> MSRP message payload. Thus, the case of the "lang" attribute might not >>>>> be as unambiguous as the one with the "framerate" attribute, but here >>>>> too I think the typical choice would be to ignore that attribute when >>>>> receiving such an offer or answer. >>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>>> sdpneg-08 may also be applied in these cases. >>>>> >>>>> Admittedly, these examples may seem a bit far-fetched, but would those >>>>> go into the direction you had in mind? >>>> >>>> Yes. Note that using examples is just me grasping at straws, since a >>>> real solution looks like to big a problem for this draft to tackle by >>>> itself. I am entirely open to other ideas for how to deal with this. >>> [CNG] I don't see what the example buys? I don't see that the behaviour >>> is any different between using additional attributes in the datachannel >>> vs. the non data channel case. E.g. for >>> >>> c=IN IP4 10.10.10.1 >>> m=message 7394 TCP/MSRP * >>> a=accept-types:message/cpim text/plain text/html >>> a=lang:.... >>> a=framerate:... >>> The ignore behaviour would be the same. >>> In the above example the attributes are scoped by the m= line. In the >>> data channel case the attributes are scoped by the relevant a=dcmap: >>> line. >> >> My concern is that SDP has no notion of subprotocol, even though in >> practice it shows up lots of places. It only has a notion of the >> protocol field in the m-line. Beyond that a *convention* has developed >> to denote a layering within the protocol through use of "/". AFAIK >> this isn't formally written down anywhere. >> >> So, in principle we could define an RTP sub-protocol for use over a >> data channel. And then we could talk about using the attributes that >> apply to RTP in dcsa for a channel using RTP. But note there is no >> formal definition of the *protocol*s where RTP attributes are relevant. >> >> A lot of the very old stuff was just sloppy. To be fair, it was >> probably good enough for the cases in front of them at the time, and >> they weren't yet in a position to foresee how things would evolve. It >> is just another example of how old stuff rots and has to be refreshed >> from time to time. >> >> But I don't think *this* draft is the place to fix it. So, in lieu of >> doing that I'm just looking for some way to clarify things. >> >> Thanks, >> Paul >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Feb 26 09:47: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 021FE1B2C47 for ; Fri, 26 Feb 2016 09:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 VwljqnekKhgE for ; Fri, 26 Feb 2016 09:46:59 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 680871B2C41 for ; Fri, 26 Feb 2016 09:46:58 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id y8so40502319igp.1 for ; Fri, 26 Feb 2016 09:46:58 -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; bh=O6TSffUn7Z4N48CeOQ3so7pp41ZlSu2jUCcpCigbS8A=; b=bneyukWwS3WDFunjgow2Gn6Kw+T7/Hz1K4IHXdixsqfBcCXN5JlFgtd/1SDDhknK// th/aDzEIsRLC3r+vQ2ilA9DLog2GWt5l70wCDK20a1eGVLQWQG6XTjTQ0tZpWNjr5dXk yCvGR8BhnMsw0ZfG0/LCgHsSU0Y7Uy4kzKtoBkYTN4bywuv3vn/pcMD2MYAGHuy65ZDp Skcx3MDzb+pfpq/KOK3Xo3Qt1Qr6KCBbe2D3zqxM/0l6WwyqextmRvDX/uAn0w2NxvEA 4sB50THe9vbFUSd8QMIVArqXgpIti07wzCejCB58FVgayvPRhoGRbbYbEy/25MNkAhK6 JNgQ== 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; bh=O6TSffUn7Z4N48CeOQ3so7pp41ZlSu2jUCcpCigbS8A=; b=XCQcKHDS+miusPLnVEegpoL7rVfVB1f4Tv3woZBVWYoy0b8bl5LTGseoeo4JuUA7sW xZMcyEDXAirYwqVqDj3EabzYLMvs1uuOIlRyrwYaj2gK0OgzqE/qdNozuLEj45mOgGGz dshBKgWXuhXrgntblTBFgknxO0UjNynZ5HDQsykD4rRl1dAbDhyc4eRFGcZ/JPWzrgdZ jlqsVgEJV0/gxZ6llIFDk38XdPugKncndx4UM26sx2x9JjL3QTD2E02PfzD5FdAjR8oN mRGhpEnqB9bhYUKY9/gh3Z4e25fppNoqrWdRwUQhxq2+9wFjkAs3PaNPLFtGccrlOZy0 f3Ew== X-Gm-Message-State: AD7BkJLQBmyxA2yCWWKrzBX2ID5Nd/z8EkR/f7U35+tOdGbW5jHXkavArBk9B3cgsIiBuw== X-Received: by 10.50.109.196 with SMTP id hu4mr4017937igb.24.1456508817820; Fri, 26 Feb 2016 09:46:57 -0800 (PST) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id c193sm5717329ioe.18.2016.02.26.09.46.56 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 09:46:56 -0800 (PST) Received: by mail-io0-f169.google.com with SMTP id 9so124823594iom.1 for ; Fri, 26 Feb 2016 09:46:56 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.12.226 with SMTP id 95mr9830969iom.70.1456508816223; Fri, 26 Feb 2016 09:46:56 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 09:46:56 -0800 (PST) In-Reply-To: <0B916011-8889-480D-9890-65336341D534@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <7BD08FA0-DEC4-4FCF-8A23-2043079C0C46@csperkins.org> <0B916011-8889-480D-9890-65336341D534@csperkins.org> Date: Fri, 26 Feb 2016 12:46:56 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Colin Perkins Content-Type: multipart/alternative; boundary=001a113f8f8e9a787c052cafe261 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:47:00 -0000 --001a113f8f8e9a787c052cafe261 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 12:42 PM, Colin Perkins wrote: > > On 26 Feb 2016, at 17:40, Roman Shpount wrote: > > Why does PT needs to be unique in both directions (entire RTP session) vs > unique in each direction? Having a unique PT in each direction is enough to > unambiguously decode the packet. SSRC might change but the packet flow > direction is well known when the packet is received. > > > Because there might be more than one participant in the session. > > P.S. I am, of cause, talking about unicast sessions only. > > > So am I. Unicast != only two participants. > > I see -- having PT point to different codec profiles for send and receive breaks RTP forwarders/mixers. Thank You, _____________ Roman Shpount --001a113f8f8e9a787c052cafe261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 26, 2016 at 12:42 PM, Colin Perkins <= csp@csperkins.org> wrote:


W= hy does PT needs to be unique in both directions (entire RTP session) vs un= ique in each direction? Having a unique PT in each direction is enough to u= nambiguously decode the packet. SSRC might change but the packet flow direc= tion is well known when the packet is received.
=

Because there might be more than o= ne participant in the session.

P.S. I am, of cause, talking about unicast sessions only= .

So am I. = Unicast !=3D only two participants.=C2=A0

=

I see -- having PT point to d= ifferent codec profiles for send and receive breaks RTP forwarders/mixers.<= /div>

Thank You,
_____________
Roman Shpount
=C2=A0
--001a113f8f8e9a787c052cafe261-- From nobody Fri Feb 26 09:52:23 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 BC5DD1B2C95 for ; Fri, 26 Feb 2016 09:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 2p9f49kFx_yC for ; Fri, 26 Feb 2016 09:52:20 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 8F2901B2C8E for ; Fri, 26 Feb 2016 09:52:20 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id z8so40596174ige.0 for ; Fri, 26 Feb 2016 09:52: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; bh=Lx2HorjFjoFPgorODgb0gt1ZzaIQxF+toHBV+VtGNCo=; b=hsmvPI7fFZCgbdcPbCPWRdCqRG3pZL0cqAuRGQvY5G4NTLzSQHbD4TDSTsYd/EsLDX a2Xq4pedAG/PzYru13EJRRm/2tDmHP+dmM1DjbQT7ZPvtpb/rp6rzoh9K7DZXe0DQnsu 5LUhn34GKs5axk3a2tnzmgSXDuI2KXKDduwM+TLSYMLSlzTS0f4pw8KETbNAnfs407Gd joyxv22oq3L0Z/pPBNdEV5VihD/sf4vK8XDLE/pV30UmUbbN3A1pgMjmoBzB2plqEIsz EciWI8kJntfxQ0HjcZcUF9wT30VWuIDQTrKFpcBovkW2P7ojxXqPrF6mIDENhrhJX6ry rwvQ== 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; bh=Lx2HorjFjoFPgorODgb0gt1ZzaIQxF+toHBV+VtGNCo=; b=f7w1kwDkGh95Fdqzc6YfDYEDg92st5XjqpNvSUEd+9ARLhuhINsms36x60ZL8n9aHh o5Z4cNowS4qKKR0etpC7UZNjr0y61M4BIYIwh06NPyVkyqFZrsOvgYzOVwLjNeL2MR6a dZu35FhZsR3teHMK5VA2BIqfhbv9ItM7T+weGqlUOJTL9OEhjfa2uYEPX4puzi4cymmz pVGp90AlBR5nGRazngJAyrY3OnoWXN+sst0YscnYwTsF5Typ4v44EoKXgxGKgRtCNsi0 Ssl85AcRVLdFwzyqMpO4JOIf932dDtvS8o7cbgT02ol6DCVuFlr0HgaaNDD05tPqy1Yf L13Q== X-Gm-Message-State: AD7BkJJOBycKZgoidMjBbdE6ZL+MWLN8UeiXT8pUMK3wThxmfiFWZ5S7/orW7jDl6KMg8g== X-Received: by 10.50.92.68 with SMTP id ck4mr4026653igb.93.1456509139965; Fri, 26 Feb 2016 09:52:19 -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 n75sm5737753ioe.28.2016.02.26.09.52.18 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 09:52:18 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id y8so40596032igp.1 for ; Fri, 26 Feb 2016 09:52:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.194 with SMTP id y2mr4000396igl.96.1456509138037; Fri, 26 Feb 2016 09:52:18 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 09:52:17 -0800 (PST) In-Reply-To: <56D08962.3060006@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> Date: Fri, 26 Feb 2016 12:52:17 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bfea0b6c90aeb052caff591 Archived-At: Cc: Colin Perkins , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 17:52:21 -0000 --047d7bfea0b6c90aeb052caff591 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 12:20 PM, Paul Kyzivat wrote: > > The session remains, and so the PT bindings remain. But the O/A rules are > negotiating which of those are to be used going forward. If the new offer > no longer mentions some PTs that were previously bound, then it is saying > that it doesn't want to receive them any more. > > It is becoming clear to me that it will be necessary to define PT bindings > - what they are, when they are established, when they are forgotten, and > the scope within which they live. Each participant will need to know these > bindings, and they must agree on them, except for well defined signaling > delays. I guess this is a lot like an RTP session, except that it is tied > to O/A signaling. > One other thing to keep in mind is that RTP session creation and tear down is not time synchronized with O/A. End point might still be receiving media packets for the previous RTP session after O/A completes. If O/A happen often enough, several O/A exchanges can complete while old RTP sessions established by old O/A exchanges are still running. PT should uniquely identify codec profile for all of them. In case of SIP, O/A exchanges typically take more time then RTP session setup/tear down, so keeping track of the last two O/A exchanges is typically enough. Regards, _____________ Roman Shpount --047d7bfea0b6c90aeb052caff591 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 26, 2016 at 12:20 PM, Paul Kyzivat <<= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank">pkyzivat@alum.mit= .edu> wrote:

 The session remains, and so the PT bindings remain. But the O/A rules are n= egotiating which of those are to be used going forward. If the new offer no= longer mentions some PTs that were previously bound, then it is saying tha= t it doesn't want to receive them any more.

It is becoming clear to me that it will be necessary to define PT bindings = - what they are, when they are established, when they are forgotten, and th= e scope within which they live. Each participant will need to know these bi= ndings, and they must agree on them, except for well defined signaling dela= ys. I guess this is a lot like an RTP session, except that it is tied to O/= A signaling.

One other thing to keep in= mind is that RTP session creation and tear down is not time synchronized w= ith O/A. End point might still be receiving media packets for the previous = RTP session after O/A completes. If O/A happen often enough, several O/A ex= changes can complete while old RTP sessions established by old O/A exchange= s are still running. PT should uniquely identify codec profile for all of t= hem. In case of SIP, O/A exchanges typically take more time then RTP sessio= n setup/tear down, so keeping track of the last two O/A exchanges is typica= lly enough.

Regards,
_____________
Roman Shpount
=C2=A0
--047d7bfea0b6c90aeb052caff591-- From nobody Fri Feb 26 10:08: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 645F71B2D17 for ; Fri, 26 Feb 2016 10:08:05 -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 dZzUDMPavvkl for ; Fri, 26 Feb 2016 10:08:04 -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 15F5E1B2D12 for ; Fri, 26 Feb 2016 10:08:03 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-01v.sys.comcast.net with comcast id P67v1s0022AWL2D01682AZ; Fri, 26 Feb 2016 18:08:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with comcast id P6811s00Z3KdFy1016821b; Fri, 26 Feb 2016 18:08:02 +0000 To: Colin Perkins , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <7BD08FA0-DEC4-4FCF-8A23-2043079C0C46@csperkins.org> From: Paul Kyzivat Message-ID: <56D09481.8080207@alum.mit.edu> Date: Fri, 26 Feb 2016 13:08:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7BD08FA0-DEC4-4FCF-8A23-2043079C0C46@csperkins.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456510083; bh=pyH064uOspRKTfa6sjxbrye+KOBRqxwfy1ouzxcNrIQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=feu/bj7gE5iRuBNEAyTv0LrV6X1876be0t66imKIuQ/YAw/wTOFNZInYKklXn8q5h FXHMPayWrcsvOLxHEx+19WJW8OfjKWHk93IWek9P/4k5LYxAKQKEoKwNlkzwA6JXtk niQlsBdeRtWrY70F1M/jClKZLGP9Trbv9+Gb4mfbO8FmztX7C0IVOuSwBzHig/tHtZ oWhbXM3rivPoMURD7gIIiK8NZLyjcPpArXY3FtwrikQB11yTDnJjIKoJ5fsYy/IqNW eVR/oOzDXGxGU+NZU7ULYrmD2sshEkY91x/xDVrFOdf02jgS8XjAGBQ4lZsdTlzpKD 38IsM6smvjASg== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 18:08:05 -0000 On 2/26/16 12:34 PM, Colin Perkins wrote: > >> On 26 Feb 2016, at 17:06, Roman Shpount > > wrote: >> >> On Fri, Feb 26, 2016 at 4:39 AM, Colin Perkins > > wrote: >> >> That depends exactly what 3264 allows: if the two ends use >> different payload types to refer to the same codec, that’s okay; >> but if the two ends use the same payload type to refer to >> different codecs, that problematic. >> >> >> Why is using the same PT to refer to different codecs is problematic? >> Can you point out any potential problems that this will cause from RTP >> perspective? > > If I receive a packet with payload type X, how do I know which of the > codecs it refers to? > > You’d have to make the PT mapping per SSRC, but the SSRCs can change > without signalling, so that doesn’t help unless you somehow label the > RTP stream with a header extension that says what payload type space > it’s using. > > The entire point of the PT is that it uniquely identifies a codec > configuration. And the entire point of O/A with RTP is for each participant to indicate the PT:codec-configuration it expects senders to use when sending packets to it. That mapping *isn't* SSRC-specific. So for the two-participant case there doesn't seem to be a problem. Each participant carries one set of bindings for packets it sends, and a different set for the packets it receives. If there are multiple participants it gets harder. If we allow conflicting bindings for each participant, then when the mixer sends out a packet to multiple participants it must be prepared to use different PTs for each receiver. OTOH, if we try to write the O/A rules to prevent conflicting bindings, then it must be defined in such a way as to inform all potential senders of all bindings. When there are more that two participants (with a mixer in the middle) then there is potential for a race: two participants might concurrently send offers to the mixer, each establishing a new binding, using the *same* previously-unbound PT. Both can't be allowed to succeed. I don't right now see how to solve that problem. Thanks, Paul From nobody Fri Feb 26 10:11: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 D94B31B2D81 for ; Fri, 26 Feb 2016 10:11:51 -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 YYkX3W2qfKiF for ; Fri, 26 Feb 2016 10:11:51 -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 38CC11B2D7F for ; Fri, 26 Feb 2016 10:11:50 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-04v.sys.comcast.net with comcast id P6BF1s0022Udklx016BpRX; Fri, 26 Feb 2016 18:11:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id P6Bo1s00N3KdFy1016Bpsn; Fri, 26 Feb 2016 18:11:49 +0000 To: Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> From: Paul Kyzivat Message-ID: <56D09563.9040509@alum.mit.edu> Date: Fri, 26 Feb 2016 13:11:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.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=1456510309; bh=VY7AXRbIntw7iRtk5JSKosOWGI6xjjpvJ14z6gXgnHk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=qGfxbCjjihPG31MHQR+WPoftOcx356VpMjMthN0hopSWNjnd3hUTZJsOw4YCvnnC6 CQtkP/JbB83o+77EEY+Om1qTBS0q6GjKjyK+1lDpx1IlriKexhXQdCVfYbOOA5HgBG ydUZmHv5sxbsdgvF1bo+iJjEtG+bnLzc4PO84u27cWR85IBLfr5dzUHER2y1uShP7g 6IgEX+gE8Y4fmRn/aIDq3+c+Wymg5U4O3hM8buPPENEaClyhpLJBwKI9IrYmC1KX0i SfLWTLH/G7A5u7ZpiQsb/MwG/2IVxmWbrtzxmv/J9JaZPcBUirLS21mWGyx0GcFKA2 jgeM+Cv5t3HXA== Archived-At: Cc: Colin Perkins , "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 26 Feb 2016 18:11:52 -0000 On 2/26/16 12:52 PM, Roman Shpount wrote: > On Fri, Feb 26, 2016 at 12:20 PM, Paul Kyzivat > wrote: > > > The session remains, and so the PT bindings remain. But the O/A > rules are negotiating which of those are to be used going forward. > If the new offer no longer mentions some PTs that were previously > bound, then it is saying that it doesn't want to receive them any more. > > It is becoming clear to me that it will be necessary to define PT > bindings - what they are, when they are established, when they are > forgotten, and the scope within which they live. Each participant > will need to know these bindings, and they must agree on them, > except for well defined signaling delays. I guess this is a lot like > an RTP session, except that it is tied to O/A signaling. > > > One other thing to keep in mind is that RTP session creation and tear > down is not time synchronized with O/A. End point might still be > receiving media packets for the previous RTP session after O/A > completes. If O/A happen often enough, several O/A exchanges can > complete while old RTP sessions established by old O/A exchanges are > still running. PT should uniquely identify codec profile for all of > them. In case of SIP, O/A exchanges typically take more time then RTP > session setup/tear down, so keeping track of the last two O/A exchanges > is typically enough. Yes, I understand that. I don't see how to solve it. It presents a hard problem. The new session may include a new participant that doesn't know the old bindings. If we require it to know them then that will require us to write more rules, and potentially break some existing usages. Thanks, Paul From nobody Fri Feb 26 13:24: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 96BBC1B308E for ; Fri, 26 Feb 2016 13:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 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.006, 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 9PAwsB_vCwcs for ; Fri, 26 Feb 2016 13:24:15 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 F07CB1B3095 for ; Fri, 26 Feb 2016 13:24:14 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id x143so1632444oix.2 for ; Fri, 26 Feb 2016 13:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DoPkfwVALR4JGUYRHtmflhguMw0fkcxVfCzLjxDTzqs=; b=WN/xomeojeI4b+6WAjumP0AglWCquMtkjmfP5pt9sTg9Hj41YE3xdf6oCPShg4fN60 ULNikEjpcV3GV4sLnKdebHcJqtU7ZxTYqFDfSFtvViaBexn6iTfhq5DhjXt8GNDO8OHU n/izw7HWSf62V9mNQBTpGA7W1g7ST8U5HrE5Tmaths0mERhoUWf+fPQd15BW+EfTTh0m jRl1agnnzVOdp9z6NQdq4DkoRtj1WK7sxUs0d9Z/BicrL6UsN9ImzitxNAd+qXGJQywC JPf2HNid6C7x/UR75LkxaKc9m4cYXnGsol2gAu4VkLa1o4eJu827eo40mne9xYT0sTMG Qj2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DoPkfwVALR4JGUYRHtmflhguMw0fkcxVfCzLjxDTzqs=; b=c4hJZV5AKBZ9QPqcfHO9k4bZQtIXjIF8hTFXBdTWavyLDMJQc8YG1TvVPSIblsbBC/ RDEFu5X8B2JVXc8NybuipqUMPpo5R9itiCCUvmlxprXHZAC1riLf9w7+kXM1gixghL2D M/0st1Z1kDra5r4fwoMPVnG0V00pgzdGXN2baC/ERv3MHbiKFable6eLLUSgLHb1X1Ui fwiI0AsB5RrNWXaRkY5nKLpLAz3PWGsS7F6JPDOx43GTmzHUV+tS52PttVU1IhWMid3h l9Vi9sPKWnLiPLMCWcpuS3pJmLMcMiKvz3Ha7vxYRI4kGIT0oemKmeds08IMPcSCtruf iPyQ== X-Gm-Message-State: AD7BkJJLdqt/26X4nWfDp/sQJ0+pvg8w/vTMwuCeNQCZ1sDkMW5Ql0BL1eSxvJKSMsirxeXIJlbXVxsjPolTnFLV X-Received: by 10.202.49.138 with SMTP id x132mr2913466oix.106.1456521854313; Fri, 26 Feb 2016 13:24:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.104.67 with HTTP; Fri, 26 Feb 2016 13:23:34 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E40FC1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BED248@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37BEF98E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C1D520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C4815B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E24284@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E40FC1@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Fri, 26 Feb 2016 13:23:34 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113c9854bc3d98052cb2eb6d Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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, 26 Feb 2016 21:24:16 -0000 --001a113c9854bc3d98052cb2eb6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure. On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Peter, > > > > I submitted a new version (-27) of BUNDLE a few days ago. Could you take = a > look at the ICE Considerations section, and say whether you are ok with t= he > text? > > > > Thanks! > > > > Regards, > > > > Christer > > > > *From:* Peter Thatcher [mailto:pthatcher@google.com] > *Sent:* 25 February 2016 08:53 > *To:* Christer Holmberg > *Cc:* Roman Shpount ; mmusic@ietf.org; Paul Kyzivat < > pkyzivat@alum.mit.edu> > > *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE > > > > That makes sense to me. > > > > On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi Roman, > > I didn't check whether some of the ICE attributes were session-level, but > I agree with what you say: the same rule should apply to all media-level > ICE attributes. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > > *From: *Roman Shpount > *Sent: *=E2=80=8E21/=E2=80=8E02/=E2=80=8E2016 08:21 > *To: *Christer Holmberg > *Cc: *Peter Thatcher ; mmusic@ietf.org; Paul Kyziva= t > > *Subject: *Re: [MMUSIC] Questions about ICE candidates with BUNDLE > > On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > >> Correct, and that's one reason I suggest that we limit the scope to > ICE, eventhough we probably > >> could do the same thing for any IDENTICAL and TRANSPORT category > attribute. > > > =E2=80=8B> While it would be nice to remove any duplication, the duplicat= ion is > particularly painful for ICE candidates, because > > there can be a lot of them, and because they change without any > offer/answer action (thanks to trickle ICE). =E2=80=8B > > So if we just covered that candidates, we'd be getting most of the valu= e. > > Assuming the scope is ICE, shouldn't the same still apply also to other > ICE related attributes? I assume the values for the "remote-candidates", > "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", "ice-pacing" and > "ice-options" attributes will be identical within a BUNDLE group, so... > > > > "ice-lite" and "ice-options" are session level only candidates, so they > should not be in the m=3D line BUNDLE or any other type. The same logic t= hat > applies to ICe candidates should apply to other media level ICE SDP > attributes or things will break > > > > Regards, > > _____________ > Roman Shpount > > > > > --001a113c9854bc3d98052cb2eb6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure.

On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Peter,

=C2=A0

I submitted a new version (-27) of BU= NDLE a few days ago. Could you take a look at the ICE Considerations sectio= n, and say whether you are ok with the text?

=C2=A0

Thanks!

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Peter Thatcher [mailto:pthatcher@google.com]
Sent: 25 February 2016 08:53
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Roman Shpount <roman@telurix.com>; mmusic@ietf.org; Paul Kyzivat <pkyzivat@alum.mit.edu>


Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE<= /u>

=C2=A0

That makes sense to me.

=C2=A0

On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi Roman,

I didn't check whether some of the ICE attributes were session-level, b= ut I agree with what you say: the same rule should apply to all media-level= ICE attributes.

Regards,

Christer

Sent from my Windows Phone

From: Roman Sh= pount
Sent: =E2=80=8E21/=E2=80=8E02/=E2=80=8E2016 08:21 To: Christer Holmberg
Cc: Peter Thatcher; mmusic@ietf.org; <= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank"> Paul Kyzivat
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE<= u>

On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

>> Correct, and that's one reason I sugges= t that we limit the scope to ICE, eventhough we probably
>> could do the same thing for any IDENTICAL and TRANSPORT category a= ttribute.
>
=E2=80=8B> While it would be nice to remove any duplication, the duplica= tion is particularly painful for ICE candidates, because
> there can be a lot of them, and because they change without any offer/= answer action (thanks to trickle ICE). =E2=80=8B =C2=A0
> So if we just covered that candidates, we'd be getting most of the= value.
=C2=A0
Assuming the scope is ICE, shouldn't the same still apply also to other= ICE related attributes? I assume the values for the "remote-candidate= s",=C2=A0 "ice-lite", "ice-mismatch", "ice-uf= rag", "ice-pwd", "ice-pacing" and "ice-option= s" attributes will be identical within a BUNDLE group, so...

=C2=A0

"ice-lite" and "ice-options" are= session level only candidates, so they should not be in the m=3D line BUND= LE or any other type. The same logic that applies to ICe candidates should = apply to other media level ICE SDP attributes or things will break

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0


--001a113c9854bc3d98052cb2eb6d-- From nobody Sat Feb 27 01:29: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 77A161A0267 for ; Sat, 27 Feb 2016 01:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 4BoU1kJSo2Sv for ; Sat, 27 Feb 2016 01:29:07 -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 370231A0217 for ; Sat, 27 Feb 2016 01:29:07 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id y8so53408527igp.0 for ; Sat, 27 Feb 2016 01:29: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; bh=/27aSJiuoMJuNWFAMv1j4dGhtQLfjuqXxQJwJxZqqKs=; b=PxZcz5TriYCHYZa6tTn7C94FvphjW3k035WUhHgLYE0Ga9uEu/o/js5wmJFAPqb8Qy Tphx/LVUO8Wia4cGUrtciyykO0hi83h5lxu+8tr66khi/M8LcV8Kh/yAh2gcL6F+ZTvb 9SC5irouH7vUFcpYt+y6TjLgMintSf6d1uyBumZhpH/oGoB2w5oC70rU8y47tpnS0U69 kc122nyGyLd39TtvPUZNJoFgYk2QIVHAkpkFYfPXKavbi3a4VCGCCOP8C9W26SCAoLQC EF6W6kfcudQWUlo0lSHBOzWa4sD+SgabGdsvM7iENNgkUr1Y/w1vb8HyB5h1qp3Gl1Al sHyA== 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; bh=/27aSJiuoMJuNWFAMv1j4dGhtQLfjuqXxQJwJxZqqKs=; b=A8X48wi+zBYJT66LAS+9HbEar+evBHWjFebAzmHMOx7J29a/QjNJqk0r2U84orDAxv 6yU4nyUM+piT20QWwqOg5Wz4nwbCZfd9dUw2Ot+EUNY1qGRD4EdEUDN46NSQLiZk7hnD XP17aN2K3q2b1IgbvizLH+Kr8tTSmIvkkRNi8ouqh+ODZISGMoCf1stpO73d+IFdvNmS MXInl3YGYZ0/a0lzpccqU+YtHBLusYV0lrs6jBPZ3knHSdLz/hWupoH8KR3RKzz0UYOR kco1SL4yoXsIG6oESOCblzPnCVPC2SNLazRl+aPrJ6blkT+ox5+RcLPW2421fMCkKtFl ohpQ== X-Gm-Message-State: AD7BkJJSIjAoWsZETOQEtJBi2dWI7t6NLRCHVjFqsLbtcvg26w5my7096d0rsw8pL49KtQ== X-Received: by 10.50.66.212 with SMTP id h20mr1754261igt.43.1456565346447; Sat, 27 Feb 2016 01:29:06 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id c193sm7024120ioe.18.2016.02.27.01.29.04 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 27 Feb 2016 01:29:04 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id g6so54377482igt.1 for ; Sat, 27 Feb 2016 01:29:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr1845430igh.2.1456565344035; Sat, 27 Feb 2016 01:29:04 -0800 (PST) Received: by 10.36.105.77 with HTTP; Sat, 27 Feb 2016 01:29:03 -0800 (PST) In-Reply-To: <56D09563.9040509@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> Date: Sat, 27 Feb 2016 04:29:03 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat , Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bdca2ecec75c5052cbd0bf9 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 27 Feb 2016 09:29:08 -0000 --047d7bdca2ecec75c5052cbd0bf9 Content-Type: text/plain; charset=UTF-8 One potential solution is to generate any offer in such a way that it will be compatible with all the completed O/A exchanges for this end point. If an end point receives an offer which is not compatible with existing state, i.e. an offer which is reusing one of the PT for a different codec profile similar, this end point must allocate new transport (use new local address/port or new local set of candidates in case of ICE) for the answer and consider this a start of the new session (discard all the PT use history). If new transport cannot be allocated, for instance if responding to an offer with ICE and existing ufrag, then offer must be refused with 488 or m line with port 0. This way end point can always uniquely map the PT to the codec profile based on PT and local transport where the packet is received. In case of 3pcc, an end point might get an offer which is incompatible with its PT use history; allocate new local transport, and handle it as a new RTP session. What do you think? _____________ Roman Shpount --047d7bdca2ecec75c5052cbd0bf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One potential solution is to generate any offer in such a = way that it will be compatible with all the completed O/A exchanges for thi= s end point. If an end point receives an offer which is not compatible with= existing state, i.e. an offer which is reusing one of the PT for a differe= nt codec profile similar, this end point must allocate new transport (use n= ew local address/port or new local set of candidates in case of ICE) for th= e answer and consider this a start of the new session (discard all the PT u= se history). If new transport cannot be allocated, for instance if respondi= ng to an offer with ICE and existing ufrag, then offer must be refused with= 488 or m line with port 0. This way end point can always uniquely map the = PT to the codec profile based on PT and local transport where the packet is= received. In case of 3pcc, an end point might get an offer which is incomp= atible with its PT use history; allocate new local transport, and handle it= as a new RTP session.

What do you think?
_____________
Roman= Shpount
--047d7bdca2ecec75c5052cbd0bf9-- From nobody Sat Feb 27 08:10: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 EE07D1A8906 for ; Sat, 27 Feb 2016 08:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 eX32oFoZrPrt for ; Sat, 27 Feb 2016 08:10:26 -0800 (PST) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 519231A8902 for ; Sat, 27 Feb 2016 08:10:24 -0800 (PST) X-AuditID: 12074413-eefff7000000516b-06-56d1ca6f38c0 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id E9.4D.20843.F6AC1D65; Sat, 27 Feb 2016 11:10:23 -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 u1RGALgX004134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 27 Feb 2016 11:10:22 -0500 To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> From: Paul Kyzivat Message-ID: <56D1CA6C.70700@alum.mit.edu> Date: Sat, 27 Feb 2016 11:10:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IRYndR1M0/dTHM4Ow/QYsLMw8zWkxd/pjF YsaFqcwOzB6/vl5l81iy5CeTx60pBQHMUdw2SYklZcGZ6Xn6dgncGWtePGMqOMpVsfbvJLYG xiUcXYycHBICJhLb22azdDFycQgJbGWU+PX4KjOE85RJYt2R8+wgVcIC9hLHmyexgNgiAkkS J6+sgyr6yCIxYcVcsCJmAXWJiXNvMIHYbAJaEnMO/Qdr4BXQlLjTNZ8RxGYRUJXoXHEHzBYV SJOY1TcBqkZQ4uTMJ2A2p0CgxNG/CxghZppJzNv8kBnClpfY/nYO8wRG/llIWmYhKZuFpGwB I/MqRrnEnNJc3dzEzJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJNjJBAFd7BuOuk3CFGAQ5GJR5e gVUXwoRYE8uKK3MPMUpyMCmJ8vaJXwwT4kvKT6nMSCzOiC8qzUktPsQowcGsJMLbkASU401J rKxKLcqHSUlzsCiJ86otUfcTEkhPLEnNTk0tSC2CycpwcChJ8L47AdQoWJSanlqRlplTgpBm 4uAEGc4lJVKcmpeSWpRYWpIRD4rK+GJgXIKkeID2yp0E2VtckJgLFIVoPcWoKCXOawqSEABJ ZJTmwY2FpZ9XjOJAXwrz2oNU8QBTF1z3K6DBTECDZ244BzK4JBEhJdXAOJs/W6PhjPG/hRsE L0s7y16ad/pVVOeFnV/ZLxR/c59mrn7F8fcG9l71lQuu/HvOYM9pznEuObkv/VeRAUvv7/ts Tp+TDv//HffA79Xp1rOfHfanpgUwOZ87sbZ6kUxZ/aftkpmXjkS42d0K/Bz88ejbcsdKn0sr WhjPv/6klJrif+9+79Uzl5RYijMSDbWYi4oTAc7hi2waAwAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 27 Feb 2016 16:10:28 -0000 On 2/27/16 4:29 AM, Roman Shpount wrote: > One potential solution is to generate any offer in such a way that it > will be compatible with all the completed O/A exchanges for this end > point. If an end point receives an offer which is not compatible with > existing state, i.e. an offer which is reusing one of the PT for a > different codec profile similar, this end point must allocate new > transport (use new local address/port or new local set of candidates in > case of ICE) for the answer and consider this a start of the new session > (discard all the PT use history). If new transport cannot be allocated, > for instance if responding to an offer with ICE and existing ufrag, then > offer must be refused with 488 or m line with port 0. This way end point > can always uniquely map the PT to the codec profile based on PT and > local transport where the packet is received. In case of 3pcc, an end > point might get an offer which is incompatible with its PT use history; > allocate new local transport, and handle it as a new RTP session. > > What do you think? While there are probably a lot of details to work out, I like it as the outline of a direction to pursue. It could get complicated for a focus. It might require the focus to change mixing policies for the offending participant. Thanks, Paul From nobody Sun Feb 28 03:01: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 93B951B3421; Sun, 28 Feb 2016 03:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8-hWQHmXMAd; Sun, 28 Feb 2016 03:01:15 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 E8AD61B341F; Sun, 28 Feb 2016 03:01:11 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id y8so64908641igp.0; Sun, 28 Feb 2016 03:01: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; bh=2QvlKig/SGwL8OgTyMPN+Xaxfn/uJyEPrKVm9pOvbrQ=; b=Gjh/KZNJsMDwEADMCOQRzhMAYPBVreXIVI5XfOdJHpYNW7TlAm9+IjS0UDYO2tcp9x wSdpXDoUJFTcR86bB6AZmn5sntfBGAia0uBYYPv0BtdHyAmC1ZByVigOl3ftWTb2y3g0 GRVV2Zk1O1sGNZFPQhec+kXD4zJNEJ+2gRJC3Zis4BzoBDzJww/NISz9QCx8GKA3302Y AHDWiuqrZOhHBgibPQoLU2bWA2WV2e7IblIeyjZtUDUFHqz9Yzv+Z8S8Y/xOX5DkCCyB 0zXR3WPl4/xH8oB5j3XHO03kCQsPJRn2WZt0LNzyp0qDLYElG5jif3yJt0YwulrG0SyV XsCA== 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; bh=2QvlKig/SGwL8OgTyMPN+Xaxfn/uJyEPrKVm9pOvbrQ=; b=l2BSGFdYFwbhGkAO5Lgf3KHS6byD6C/xTOCypGM67x8rE6chQMWJyOlLdV8EJhDnmk Mjsevcr1ubdotSMh8xF4hgCyjBY2aSuoLZbqwr2wo9AQGn3NhtIJiNoB3JIBE/+dGYXR +uhXKH1BkxD9ZufvTHmD7ElIhLw6sEJh7kyyfEsKHIMZ6UJX1PVaFj16IuOv0nrQVZsB 0IOddTex2mBbLPjfAbGYmggUyc5t9HGawKCqnB6eCBvRP0vvfGG9s/nvVJhRB2br/gov 0BDdHXIYMhuMWFCUjO2uIGJIdBVvypgS7aQV9K4gDoZKrKYvTN48xVxav/GTlpdtZ2Ex uOYA== X-Gm-Message-State: AD7BkJLs+wK0Q04u6Ver4bqNVNtsUJ4dctdoZk7+XMJYwgZQJNR6UmayvxmlVxBiIG0mpcP3xPDCvbbrPqI0dw== MIME-Version: 1.0 X-Received: by 10.50.20.129 with SMTP id n1mr5651441ige.77.1456657271314; Sun, 28 Feb 2016 03:01:11 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 28 Feb 2016 03:01:11 -0800 (PST) In-Reply-To: <56C63BE8.6000607@cisco.com> References: <56C63BE8.6000607@cisco.com> Date: Sun, 28 Feb 2016 22:01:11 +1100 Message-ID: From: Martin Thomson To: Flemming Andreasen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: mmusic , draft-ietf-mmusic-mux-exclusive@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-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: Sun, 28 Feb 2016 11:01:16 -0000 On 19 February 2016 at 08:47, Flemming Andreasen wrote: > https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-03.txt I've read it, but I've not followed the list discussion much. This document needs to more clearly articulate the reason for the attribute. An implementation that fails to generate unique RTCP port numbers (on a=rtcp or a=candidate lines) AND checks for a=rtcp-mux attributes will produce the same effect as with this attribute. Can we mandate either mandatory inclusion of a=rtcp with matching transport parameters, or mandatory omission of a=rtcp? If there is a reason to allow this choice, it might be wise to document it. Since we're exclusive, I see no reason to waste bytes and cycles on a=rtcp; I'd prefer to have it omitted. We're highly unlikely to be compatible with anyone expecting to rely on a=rtcp in any case. Editorial: Rather than: The RTCWEB WG has defined that support of the fallback mentioned above is optional. Therefore, there is a need for a mechanism that allows an endpoint to indicate exclusive support of RTP/RTCP multiplexing, meaning that endpoint only supports RTP/RTCP multiplexing and is not able to fallback to usage of separate ports for RTP and RTCP. Say: Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose to not implement separation of RTP and RTCP. For those applications, this document defines an SDP attribute to signal intent to require multiplexing. From nobody Sun Feb 28 18:48:56 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 3C4341B2A63 for ; Sun, 28 Feb 2016 18:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, 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 n0SpSRx8ZJ3s for ; Sun, 28 Feb 2016 18:48:51 -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 246C91B2A80 for ; Sun, 28 Feb 2016 18:48:50 -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=JmcKVLhcJpZb9js1pnk4UgXOhd3oqlhuX941rrTp3cM=; b=wyyZ8f7bLlpQ2nqTalGu8h3C0r 2TRitpvJrak5rdxkXrs+88QSQ21LeOoNO41X8kIn5v+fCFF8M6qYnxTsht2QMtGV4snSQC64Egpks qIRVxcFuscAmfv4mB/4hGHLYhks95P15oQc7GFNBUMXTCaWt6hMlEByJyBcLFF/0Urd6WKyQNu4bH pPM6Yc5Tq/M6+LBCEl9zhksuWbU2t26y1rtq0IWQ7pEFJiRDZ3QJPkV/iCfr1JXUepFuVWOaUDHBH 0z+IImlFN7lURX94mSCvE6dTniKoorwKWWZ+QFIAoQJyJx47wH/HhFWR9yeCyHxRkUgDRJu1/vtEV GO5AO/pQ==; Received: from ppp118-209-76-198.lns20.mel4.internode.on.net ([118.209.76.198]:52095 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aaDtA-000YL9-Ei for mmusic@ietf.org; Mon, 29 Feb 2016 13:48:48 +1100 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> <56D05E8D.5080306@alcatel-lucent.com> <56D08F58.1040709@alum.mit.edu> From: Christian Groves Message-ID: <56D3B18E.7000904@nteczone.com> Date: Mon, 29 Feb 2016 13:48:46 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D08F58.1040709@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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] 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: Mon, 29 Feb 2016 02:48:55 -0000 Hello Paul and Juergen, On 27/02/2016 4:46 AM, Paul Kyzivat wrote: > Hi, > > On 2/26/16 9:17 AM, Juergen Stoetzer-Bradler wrote: >> Hello Paul, Christian, >> >> Would propose to add following definition of term "subprotocol" to the >> terminology section 3 of the sdpneg draft: >> >> Data channel subprotocol: The application protocol which is >> transported over a single data channel. Data channel subprotocol >> messages are sent as data channel payload over an established >> data >> channel. If an SDP offer/answer exchange is used as specified in >> this document to negotiate the establishment of data channels, >> corresponding data channel properties, associated data channel >> subprotocols and data channel subprotocol properties, then the >> data >> channel subprotocols may be identified by the values of the >> "subprotocol" parameters of the SDP "a=dcmap" attributes as >> described in Section 5.1.1.5. Within this document the term >> "data >> channel subprotocol" is often abbreviated as just "subprotocol". >> >> This text could explicitly narrow down the notion of "subprotocol" >> within the data channel SDP offer/answer context and might especially be >> helpful distinguishing it from the usages of "subprotocol" in the >> Websocket RFC 6455 (where the term "subprotocol" was taken from, but >> where it does not seem to be formally defined). This text may certainly >> not be helpful in more general non-data channel contexts. But it might >> help to clarify that every occurrence of of the term "subprotocol" in >> the sdpneg draft refers to the application protocol which (typically but >> not necessarily) is identified via the a=dcmap's "subprotocol" >> parameter. >> >> Would such an explicit definition be helpful from your point of view? > > It might *help*, but it doesn't get at the main problem I see. > > The question is how does this sub-protocol relate the the proto field > used in m-lines? But not to the proto of the m-line for data channel. > My point is that many sdp attributes were designed to be used with > particular proto fields. For instance, with RTP/AVP, RTP/AVPF, > TCP/RTP/AVP, RTP/SAVP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, > RTP/SAVPF, UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF, > DCCP/TLS/RTP/SAVPF, ... [CNG] Does sub-protocol have to relate to the proto field? The proto field in the case of WebRTC-datachannel is UDP/DTLS/SCTP. What ever is carried in the individual data channels is the sub-protocol. Draft-ietf-mmusic-data-channel-sdpneg is only considering this. > > In general they are described as being applicable to RTP. But what is > RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a > super-protocol (of AVP, AVPF, SAVP, SAVPF)? [CNG] I'm not sure it matters? If someone wants to run a particular RTP profile over a data channel then it is a sub-protocol of UDP/DTLS/SCTP. All the other above examples have already been defined so I don't see we gain anything by trying to label them as a sub-protocol etc. > > If we wanted to define use of RTP over a data channel, what > sub-protocol(s) would we have to define? I *think* we would have to > define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted > to support over a data channel. [CNG] Yes I would agree. > > And then how would we do it, and where would we specify which > attributes could be used with dcsa? Would we have to update the > documents that define those attributes? [CNG] I assume we'd follow the example of draft-ietf-mmusic-msrp-usage-data-channel. It discusses the use of existing attributes. I don't see that RTP would need to do anything different. > > ISTM there are similar (though not so complex) issues for pretty much > any attribute that we might want to reuse over a data channel. [CNG] Some will be complex, some will be a no brainer. What draft-ietf-mmusic-data-channel-sdpneg provides is a syntax for re-using attributes. It doesn't provide semantics for every attribute. Implementors need to understand that some attributes have been defined with a particular protocol stack in mind and that they the behaviour may need to be modified when using a data channel. > > Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, > RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the > websocket/datachannel registry. And then that document might say that > any sdp attribute designed to be used with protos */(each of these > subprotocols) may also be used in dcsa for a channel using these > protocols. [CNG] Yes it "could" be, if someone actually wanted to carry RTP over a data channel. That would follow with what is being done for MSRP and BFCP. I don't see RTP as being any different. > > Thanks, > Paul > >> Thanks, >> Juergen >> >> >> On 25.02.2016 22:38, EXT Paul Kyzivat wrote: >>> On 2/24/16 7:24 PM, Christian Groves wrote: >>>> Hello Juergen and Paul, >>>> >>>> Please see at end. >>>> >>>> Regards, Christian >>>> >>>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>>>> ..snip.. >>>>>> >>>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>>>> >>>>>>>> Have just submitted version 08 of >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>>>> The changes compared to version 07 are essentially as follows. >>>>>>>> >>>>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>>>> regarding the >>>>>>>> relationship of subprotocols and their attributes. >>>>>>>> * Two new SDP offer/answer considerations in section 5.2.5 >>>>>>>> (Various >>>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>>>>> channel transport specific semantic is not known. >>>>>>>> * A new paragraph in section 8.1 (IANA Considerations / >>>>>>>> Subprotocol >>>>>>>> Identifiers) related to cases, where a subprotocol is defined for >>>>>>>> data >>>>>>>> channel and Websocket transport. >>>>>>>> >>>>>>>> These changes should address the points discussed in this email >>>>>>>> thread. >>>>>>> >>>>>>> This is an improvement. But I think things could still be made >>>>>>> clearer. >>>>>>> >>>>>>> Consider the following addition to 5.1.2.1: >>>>>>> >>>>>>> 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. A data channel >>>>>>> specific usage of a subprotocol attribute is expected to be >>>>>>> specified >>>>>>> in the same document, which registers the subprotocol's >>>>>>> identifier >>>>>>> for data channel usage as described in Section 8.1. >>>>>>> >>>>>>> This text makes sense when there is a clear distinction between >>>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved >>>>>>> there >>>>>>> is no such clear distinction in many cases, such as RTP over UDP or >>>>>>> TCP, etc. Those are combined into a single protocol value. While >>>>>>> that >>>>>>> can usually be parsed apart at slashes, there isn't good >>>>>>> terminology >>>>>>> for it. >>>>>>> >>>>>>> My point is that when I read the above, I don't know how it applies >>>>>>> to, say, RTP attributes. Or does it only apply for attributes that >>>>>>> are >>>>>>> clearly defined for a *sub*protocol? >>>>>>> >>>>>>> I think this is primarily that we lack well defined vocabulary for >>>>>>> all >>>>>>> of this. But I think it would be too much to expect this draft to >>>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it >>>>>>> would be >>>>>>> sufficient to give some concrete examples, even if they have to be >>>>>>> hypothetical ones. >>>>>> >>>>>> [Juergen] Agree that it would be helpful to have more precise >>>>>> definitions of the differences of the terms protocol and >>>>>> subprotocol, >>>>>> especially when those terms are used outside the scope of data >>>>>> channels >>>>>> (or Websockets). When only focusing on data channels the notion of a >>>>>> "subprotocol" seems to be clearer - at least >>>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" >>>>>> parameter. >>>>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>>>> informally starts using the term "subprotocol" in the >>>>>> introduction and >>>>>> there refers to Websocket "subprotocols". Perhaps we should add the >>>>>> term >>>>>> "subprotocol" to the list of used terminology in section 3. >>>>>> >>>>>> The sdpneg document, together with the data channel subprotocol >>>>>> specific >>>>>> document (which defines the value of the a=dcmap attribute's >>>>>> "subprotocol" parameter), should certainly give clear guidance on >>>>>> how to >>>>>> interpret SDP offers or answers like e.g.: >>>>>> >>>>>> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >>>>>> c=IN IP4 10.10.10.1 >>>>>> a=max-message-size:100000 >>>>>> a=sctp-port:5000 >>>>>> ... >>>>>> a=dcmap:0 subprotocol="MSRP" >>>>>> a=dcsa:0 accept-types:message/cpim text/plain >>>>>> a=dcsa:0 framerate:... >>>>>> a=dcsa:0 lang:... >>>>>> >>>>>> An implementation receiving such an offer would need to decide >>>>>> what to >>>>>> do with the dcsa embedded framerate and lang attributes. Or, someone >>>>>> implementing MSRP over data channel based services may need to >>>>>> decide >>>>>> whether or not to use these attributes, and if yes, how. >>>>>> (I am using these two attributes just as hypothetical examples - >>>>>> don't >>>>>> want to suggest that those may indeed be used for MSRP over data >>>>>> channel >>>>>> transport). >>>>>> >>>>>> The msrp-usage-data-channel document doesn't mention these two >>>>>> attributes. When looking at the IANA SDP attribute registry >>>>>> tables, I >>>>>> would find both attributes specified in RFC 4566. There, >>>>>> "framerate" is >>>>>> explicitly said to be defined only "for video media". Just to be >>>>>> sure I >>>>>> could additionally have a look at the MSRP specifying documents, RFC >>>>>> 4975 and RFC 4976, but there would not find any text at all >>>>>> related to >>>>>> "framerate". So this case seems pretty clear and I would therefore >>>>>> conclude that the "framerate" attribute should not be used for >>>>>> MSRP, and >>>>>> that a receiver of such an offer or answer should ignore it. >>>>>> >>>>>> When looking at the definition of the "lang" attribute in RFC 4566 I >>>>>> would not see any explicit hint of what protocols this attribute >>>>>> might >>>>>> be used with, especially if "lang" could be used when negotiating an >>>>>> MSRP session. When then looking at RFC 4975 I would indeed find >>>>>> "lang" - >>>>>> but not as SDP attribute, rather as XML tag parameter within an >>>>>> example >>>>>> MSRP message payload. Thus, the case of the "lang" attribute >>>>>> might not >>>>>> be as unambiguous as the one with the "framerate" attribute, but >>>>>> here >>>>>> too I think the typical choice would be to ignore that attribute >>>>>> when >>>>>> receiving such an offer or answer. >>>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>>>> sdpneg-08 may also be applied in these cases. >>>>>> >>>>>> Admittedly, these examples may seem a bit far-fetched, but would >>>>>> those >>>>>> go into the direction you had in mind? >>>>> >>>>> Yes. Note that using examples is just me grasping at straws, since a >>>>> real solution looks like to big a problem for this draft to tackle by >>>>> itself. I am entirely open to other ideas for how to deal with this. >>>> [CNG] I don't see what the example buys? I don't see that the >>>> behaviour >>>> is any different between using additional attributes in the >>>> datachannel >>>> vs. the non data channel case. E.g. for >>>> >>>> c=IN IP4 10.10.10.1 >>>> m=message 7394 TCP/MSRP * >>>> a=accept-types:message/cpim text/plain text/html >>>> a=lang:.... >>>> a=framerate:... >>>> The ignore behaviour would be the same. >>>> In the above example the attributes are scoped by the m= line. In the >>>> data channel case the attributes are scoped by the relevant a=dcmap: >>>> line. >>> >>> My concern is that SDP has no notion of subprotocol, even though in >>> practice it shows up lots of places. It only has a notion of the >>> protocol field in the m-line. Beyond that a *convention* has developed >>> to denote a layering within the protocol through use of "/". AFAIK >>> this isn't formally written down anywhere. >>> >>> So, in principle we could define an RTP sub-protocol for use over a >>> data channel. And then we could talk about using the attributes that >>> apply to RTP in dcsa for a channel using RTP. But note there is no >>> formal definition of the *protocol*s where RTP attributes are relevant. >>> >>> A lot of the very old stuff was just sloppy. To be fair, it was >>> probably good enough for the cases in front of them at the time, and >>> they weren't yet in a position to foresee how things would evolve. It >>> is just another example of how old stuff rots and has to be refreshed >>> from time to time. >>> >>> But I don't think *this* draft is the place to fix it. So, in lieu of >>> doing that I'm just looking for some way to clarify things. >>> >>> Thanks, >>> Paul >>> >> >> >> _______________________________________________ >> 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 Sun Feb 28 21:30: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 9AD3A1B2C45 for ; Sun, 28 Feb 2016 21:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 NHKOQLe4fuKe for ; Sun, 28 Feb 2016 21:29:56 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 EE84F1B2C43 for ; Sun, 28 Feb 2016 21:29:55 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id z135so176562936iof.0 for ; Sun, 28 Feb 2016 21:29: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; bh=9Q98Kt8fnCfV9NE4tU/gI6ggx+AmgqQ/ZYfUTAkYM1c=; b=PDeuNnTKT3V4E1Urd+i0fldwhnDdMcAp2bWingVrBJqaD6TRkvK7TWZFkwN/H7z9Wg WnCP7TDdcCncV1adRgrNVnkGFcczmWHHcTFcksSqqMAq8jr7MRFYB76/A7BOjpdZhKsT /DvyMudaDVwFkYSVjrcPCyj0QZ0a5nnJg9fBJx7Q2zl4ZyrX0Wl2rrvj46Wrat5b8pdj /5+uJRAEnMuvMOirQCefOhFBbgoZOxkyu0iEwYCYJkBkAG3H0xzqBpLWMmv1DMJM7DlR HAj0DI1sBibmD64KWKukqHKX2few0/Qqz4J5vnn93VlR4pXqPLqAF/IktYHRj9OwOS6E sDvA== 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; bh=9Q98Kt8fnCfV9NE4tU/gI6ggx+AmgqQ/ZYfUTAkYM1c=; b=f474MK4uCk2WhnJq4EQLfXOo4L4uXHNvKaKmU6JXCtYZl3UxoQcF6Lk/IboeBe/MCB HFlfsZXwH67KwVHsSGmell4MCbK/l7m8c8Es9vajobiD4EMP9l0vaTFKz0955FBwSWK8 a1oUdNCKofzRXoQqAIz7lr6Uc8WbXs1UeIjQLPcER5HMNxq6nkyzeh57TfCtg+c7Nf4f 1gVwTvQYe12F83z7g0ICslyI3vn/8TPQOcu+enBLK6DKWFYp/ZfMDDzf07ZZdrkwsbUs 0oVuLXi8D9ELWD3GU0xd2jkOrtlxx7dn7k47X/4HsFRM82wMI5Ql6NKQErjPgts9bFtG 7Cmw== X-Gm-Message-State: AG10YOTFa0niEp1HKQpdMKmB0p4OJ8/VjGzeE/hk2cUms7fDPvvpLUmudClOyjUUBMMayA== X-Received: by 10.107.164.145 with SMTP id d17mr16709742ioj.112.1456723795360; Sun, 28 Feb 2016 21:29:55 -0800 (PST) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id o65sm10365407ioi.24.2016.02.28.21.29.53 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 21:29:53 -0800 (PST) Received: by mail-io0-f181.google.com with SMTP id z135so176562332iof.0 for ; Sun, 28 Feb 2016 21:29:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr16139476ioe.38.1456723793075; Sun, 28 Feb 2016 21:29:53 -0800 (PST) Received: by 10.36.105.77 with HTTP; Sun, 28 Feb 2016 21:29:52 -0800 (PST) In-Reply-To: <56D1CA6C.70700@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> Date: Mon, 29 Feb 2016 00:29:52 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140b47238eb21052ce1f056 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 05:29:57 -0000 --001a1140b47238eb21052ce1f056 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 27, 2016 at 11:10 AM, Paul Kyzivat wrote: > On 2/27/16 4:29 AM, Roman Shpount wrote: > >> One potential solution is to generate any offer in such a way that it >> will be compatible with all the completed O/A exchanges for this end >> point. If an end point receives an offer which is not compatible with >> existing state, i.e. an offer which is reusing one of the PT for a >> different codec profile similar, this end point must allocate new >> transport (use new local address/port or new local set of candidates in >> case of ICE) for the answer and consider this a start of the new session >> (discard all the PT use history). If new transport cannot be allocated, >> for instance if responding to an offer with ICE and existing ufrag, then >> offer must be refused with 488 or m line with port 0. This way end point >> can always uniquely map the PT to the codec profile based on PT and >> local transport where the packet is received. In case of 3pcc, an end >> point might get an offer which is incompatible with its PT use history; >> allocate new local transport, and handle it as a new RTP session. >> >> What do you think? >> > > While there are probably a lot of details to work out, I like it as the > outline of a direction to pursue. > > It could get complicated for a focus. It might require the focus to change > mixing policies for the offending participant. > PT collisions are already a quite complicated for the conference focus. Conference focus needs to deal with situations when multiple inbound callers (in case of meet-me conference) use the same PT in incompatible way. When outbound calls are placed from the focus, end points can add PT to the answer which can also produce PT collisions. With my proposal these collisions can be resolved using a re-INVITE from the focus which will force new RTP sessions to be created on the clients. >From implementation experience PT collisions do not present a real problem in practice. All practical implementations of RTP mux that I had dealt with either worked with specially pre-provisioned end points which all used the same PT for the same codec profiles or conference focus implemented PT re-mapping on each of the call legs. Regards, _____________ Roman Shpount --001a1140b47238eb21052ce1f056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 27, 2016 = at 11:10 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:=
On 2/27/1= 6 4:29 AM, Roman Shpount wrote:
One potential solution is to generate any offer in such a way that it
will be compatible with all the completed O/A exchanges for this end
point. If an end point receives an offer which is not compatible with
existing state, i.e. an offer which is reusing one of the PT for a
different codec profile similar, this end point must allocate new
transport (use new local address/port or new local set of candidates in
case of ICE) for the answer and consider this a start of the new session (discard all the PT use history). If new transport cannot be allocated,
for instance if responding to an offer with ICE and existing ufrag, then offer must be refused with 488 or m line with port 0. This way end point can always uniquely map the PT to the codec profile based on PT and
local transport where the packet is received. In case of 3pcc, an end
point might get an offer which is incompatible with its PT use history;
allocate new local transport, and handle it as a new RTP session.

What do you think?

 While there are probably a lot of details to work out, I like it as the out= line of a direction to pursue.

It could get complicated for a focus. It might require the focus to change = mixing policies for the offending participant.

PT collisions are already a quite complicated for the conference fo= cus. Conference focus needs to deal with situations when multiple inbound c= allers (in case of meet-me conference) use the same PT in incompatible way.= When outbound calls are placed from the focus, end points can add PT to th= e answer which can also produce PT collisions. With my proposal these colli= sions can be resolved using a re-INVITE from the focus which will force new= RTP sessions to be created on the clients.=C2=A0

= >From implementation experience PT collisions do not present a real problem = in practice. All practical implementations of RTP mux that I had dealt with= either worked with specially pre-provisioned end points which all used the= same PT for the same codec profiles or conference focus implemented PT re-= mapping on each of the call legs.

Regards,
_____________
Roman Shpount
=C2=A0
--001a1140b47238eb21052ce1f056-- From nobody Mon Feb 29 00: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 A64D61B2DC3; Mon, 29 Feb 2016 00:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_19=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 fjt9L13Y3kv5; Mon, 29 Feb 2016 00:12: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 83AD81B2DC2; Mon, 29 Feb 2016 00:12:06 -0800 (PST) X-AuditID: c1b4fb30-f79096d000002f68-da-56d3fd545790 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.7A.12136.45DF3D65; Mon, 29 Feb 2016 09:12:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 09:12:04 +0100 From: Christer Holmberg To: Martin Thomson , Flemming Andreasen Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt Thread-Index: AQHRapX1Z8HRswOqR0GYHJw2SIRNvp9BSLqAgAFtVhA= Date: Mon, 29 Feb 2016 08:12:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4B32F@ESESSMB209.ericsson.se> References: <56C63BE8.6000607@cisco.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.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7q27I38thBodma1lc3nqK1eL9BV2L a2f+MVpMXf6YxYHFY8rvjaweO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAlfG9uOPmQpmyFU8 6FrG2MC4RbaLkZNDQsBE4mHfAXYIW0ziwr31bF2MXBxCAocZJbbMO8MO4SxmlLg/6TVTFyMH B5uAhUT3P22QBhGBCIm7rzYzgdjMAqUSpxZ8AhskLOAisfTSHWaIGleJQ5Pfs0PYVhJdqw+A 1bMIqEpMfLYTbCSvgK9Ez3ywEiGBfInpfU/AWjkFAiXOPX3JAmIzAt32/dQaqFXiEreezGeC uFlAYsme88wQtqjEy8f/WCFsRYmdZ9uZQcYzC2hKrN+lD9GqKDGl+yHYKl4BQYmTM5+wTGAU m4Vk6iyEjllIOmYh6VjAyLKKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCqDm75bbCD8eVz x0OMAhyMSjy8G5wvhwmxJpYVV+YeYpTgYFYS4V12FSjEm5JYWZValB9fVJqTWnyIUZqDRUmc l/UTUEogPbEkNTs1tSC1CCbLxMEp1cAYk7Dcd33su8/pk+SX/Os9/YynP3tW1ezXX9VNVzKI zLyn+3LpRr/088e8rh1iX/TB8mTeiwuv2iecKzRTKnf+s+2Ounxhp7zNtsSYtYUORmbrHXdz Wv+6zh+ht/3B//h7Z+76vgt/ftY7uLqF508w4/57v4pOb5yl8NF8kROL1bF9FlsjdVwUlViK MxINtZiLihMBismLK6YCAAA= Archived-At: Cc: mmusic , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 08:12:08 -0000 SGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMhIFNlZSBpbmxpbmUuDQoNCj4g VGhpcyBkb2N1bWVudCBuZWVkcyB0byBtb3JlIGNsZWFybHkgYXJ0aWN1bGF0ZSB0aGUgcmVhc29u IGZvciB0aGUgYXR0cmlidXRlLiAgQW4gaW1wbGVtZW50YXRpb24gdGhhdCBmYWlscyB0byBnZW5l cmF0ZSANCj4gdW5pcXVlIFJUQ1AgcG9ydCBudW1iZXJzIChvbiBhPXJ0Y3Agb3IgYT1jYW5kaWRh dGUgbGluZXMpIEFORCBjaGVja3MgZm9yIGE9cnRjcC1tdXggYXR0cmlidXRlcyB3aWxsIHByb2R1 Y2UgdGhlIHNhbWUgZWZmZWN0IGFzIHdpdGggdGhpcyBhdHRyaWJ1dGUuDQoNClBlcmhhcHMsIGJ1 dCB0aGVyZSBhcmUgYXQgbGVhc3QgYSBjb3VwbGUgb2Ygc2VtYW50aWNhbCBpc3N1ZXMgd2l0aCB0 aGF0Og0KDQpGSVJTVCwgc2VjdGlvbiA1LjEuMyBvZiBSRkMgNTc2MSBzYXlzOg0KDQogICAiSWYg aXQgaXMgZGVzaXJlZCB0byB1c2UgYm90aCBJQ0UgYW5kIG11bHRpcGxleGVkIFJUUCBhbmQgUlRD UCwgdGhlDQogICBpbml0aWFsIG9mZmVyIE1VU1QgY29udGFpbiBhbiAiYT1ydGNwLW11eCIgYXR0 cmlidXRlIHRvIGluZGljYXRlIHRoYXQNCiAgIFJUUCBhbmQgUlRDUCBtdWx0aXBsZXhpbmcgaXMg ZGVzaXJlZCBhbmQgTVVTVCBjb250YWluICJhPWNhbmRpZGF0ZToiDQogICBsaW5lcyBmb3IgYm90 aCBSVFAgYW5kIFJUQ1AgYWxvbmcgd2l0aCBhbiAiYT1ydGNwOiIgbGluZSBpbmRpY2F0aW5nIGEN CiAgIGZhbGxiYWNrIHBvcnQgZm9yIFJUQ1AgaW4gdGhlIGNhc2UgdGhhdCB0aGUgYW5zd2VyZXIg ZG9lcyBub3Qgc3VwcG9ydA0KICAgUlRQIGFuZCBSVENQIG11bHRpcGxleGluZy4gIFRoaXMgTVVT VCBiZSBkb25lIGZvciBlYWNoIG1lZGlhIHdoZXJlDQogICBSVFAgYW5kIFJUQ1AgbXVsdGlwbGV4 aW5nIGlzIGRlc2lyZWQuIg0KDQoNClNFQ09ORCwgZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1z ZHAgbWFuZGF0ZXMgaXQuIE5vdywgdGhhdCBpZiBvYnZpb3VzbHkgc29tZXRoaW5nIHdlIGNhbiBj aGFuZ2UsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHBlb3BsZSBkaWRuJ3Qgd2FudCB0 byB1cGRhdGUgNTc2MS4NCg0KDQpUSElSRCwgaWYgSUNFIGlzIG5vdCB1c2VkIHRvIGJlZ2luIHdp dGgsIHRoZXJlIHdpbGwgYmUgbm8gY2FuZGlkYXRlcywgc28gYT1ydGNwLW11eCB3aWxsIG9idmlv dXNseSBub3QgcHJvZHVjZSB0aGUgc2FtZSByZXN1bHQgOikNCg0KDQo+IENhbiB3ZSBtYW5kYXRl IGVpdGhlciBtYW5kYXRvcnkgaW5jbHVzaW9uIG9mIGE9cnRjcCB3aXRoIG1hdGNoaW5nIHRyYW5z cG9ydCBwYXJhbWV0ZXJzLCBvciBtYW5kYXRvcnkgb21pc3Npb24gb2YgYT1ydGNwPyAgSWYgDQo+ IHRoZXJlIGlzIGEgcmVhc29uIHRvIGFsbG93IHRoaXMgY2hvaWNlLCBpdCBtaWdodCBiZSB3aXNl IHRvIGRvY3VtZW50IGl0LiAgU2luY2Ugd2UncmUgZXhjbHVzaXZlLCBJIHNlZSBubyByZWFzb24g dG8gd2FzdGUgYnl0ZXMgYW5kIA0KPiBjeWNsZXMgb24gYT1ydGNwOyBJJ2QgcHJlZmVyIHRvIGhh dmUgaXQgb21pdHRlZC4gIFdlJ3JlIGhpZ2hseSB1bmxpa2VseSB0byBiZSBjb21wYXRpYmxlIHdp dGggYW55b25lIGV4cGVjdGluZyB0byByZWx5IG9uIGE9cnRjcCBpbiBhbnkgY2FzZS4NCg0KVGhl IG9ubHkgcmVhc29uIGlzIGlmIHRoZSBtdXgtZXhjbHVzaXZlIG1lY2hhbmlzbSBpcyB1c2VkIHRv Z2V0aGVyIHdpdGggc29tZSBvdGhlciBtZWNoYW5pc20gdGhhdCByZXF1aXJlcyB1c2FnZSBvZiBh PXJ0Y3AuIEFzIG1lbnRpb25lZCBlYXJsaWVyLCBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNk cCBjdXJyZW50bHkgcmVxdWlyZXMgdXNhZ2Ugb2YgYT1ydGNwIHdpdGggUlRDUC4NCg0KV2UgY291 bGQgb2YgY291cnNlIHNheSB0aGF0IG9uZSBtdXN0IG5vdCBpbmNsdWRlIGE9cnRjcCwgdW5sZXNz IHVzZWQgdG9nZXRoZXIgd2l0aCBhIG1lY2hhbmlzbSB0aGF0IHJlcXVpcmVzIGl0LCBhbmQgdGhl biB3ZSBzdG9wIGRlZmluaW5nIGZ1dHVyZSBtZWNoYW5pc21zIHRoYXQgdXNlIGE9cnRjcC4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+IEVkaXRvcmlhbDoNCj4NCj4gUmF0aGVyIHRoYW46DQo+ DQo+ICAgVGhlIFJUQ1dFQiBXRyBoYXMgZGVmaW5lZCB0aGF0IHN1cHBvcnQgb2YgdGhlIGZhbGxi YWNrIG1lbnRpb25lZA0KPiAgIGFib3ZlIGlzIG9wdGlvbmFsLiAgVGhlcmVmb3JlLCB0aGVyZSBp cyBhIG5lZWQgZm9yIGEgbWVjaGFuaXNtIHRoYXQNCj4gICBhbGxvd3MgYW4gZW5kcG9pbnQgdG8g aW5kaWNhdGUgZXhjbHVzaXZlIHN1cHBvcnQgb2YgUlRQL1JUQ1ANCj4gICBtdWx0aXBsZXhpbmcs IG1lYW5pbmcgdGhhdCBlbmRwb2ludCBvbmx5IHN1cHBvcnRzIFJUUC9SVENQDQo+ICAgbXVsdGlw bGV4aW5nIGFuZCBpcyBub3QgYWJsZSB0byBmYWxsYmFjayB0byB1c2FnZSBvZiBzZXBhcmF0ZSBw b3J0cw0KPiAgIGZvciBSVFAgYW5kIFJUQ1AuDQo+DQo+U2F5Og0KPg0KPiAgIFNvbWUgbmV3ZXIg YXBwbGljYXRpb25zIHRoYXQgZG8gbm90IHJlcXVpcmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3 aXRoIHBlZXJzIHRoYXQgY2Fubm90IG11bHRpcGxleCBSVENQIG1pZ2h0IGNob29zZSB0byBub3Qg DQo+ICAgaW1wbGVtZW50IHNlcGFyYXRpb24gb2YgUlRQIGFuZCBSVENQLiAgRm9yIHRob3NlIGFw cGxpY2F0aW9ucywgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIFNEUCBhdHRyaWJ1dGUgdG8gc2ln bmFsIGludGVudCB0byByZXF1aXJlIG11bHRpcGxleGluZy4NCg0KTG9va3MgZ29vZC4NCg0KVGhh bmtzIQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Mon Feb 29 00:36: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 BF6A01B2E0A; Mon, 29 Feb 2016 00:36:27 -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_14=0.6, J_CHICKENPOX_19=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 TFJdrT8jVseT; Mon, 29 Feb 2016 00:36:26 -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 75AE51B2E09; Mon, 29 Feb 2016 00:36:25 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-4f-56d40307199d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.49.25494.70304D65; Mon, 29 Feb 2016 09:36:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 09:36:02 +0100 From: Christer Holmberg To: Martin Thomson , Flemming Andreasen Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt Thread-Index: AQHRapX1Z8HRswOqR0GYHJw2SIRNvp9BSLqAgAFtVhCAAAzIEA== Date: Mon, 29 Feb 2016 08:36:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4B3F1@ESESSMB209.ericsson.se> References: <56C63BE8.6000607@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E4B32F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4B32F@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.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7tC4785Uwg+ZmOYvLW0+xWry/oGtx 7cw/Roupyx+zOLB4TPm9kdVj56y77B5LlvxkCmCO4rJJSc3JLEst0rdL4MrYesC7YIZyxeaW OUwNjEuUuhg5OSQETCROLDvMBGGLSVy4t56ti5GLQ0jgMKPE2bYTUM5iRomTVx6xdjFycLAJ WEh0/9MGaRARiJC4+2ozWDOzQKnEqQWf2EFsYQEXiaWX7jBD1LhKHJr8nh3CdpL4sqmXEcRm EVCVmPbsFiPISF4BX4nTM5wgVm1mlFh2/DIbSA2ngJ/ExLdXwGxGoOO+n1oDtUtc4taT+VBH C0gs2XOeGcIWlXj5+B8rhK0osfNsOzPIfGYBTYn1u/QhWhUlpnQ/BDuHV0BQ4uTMJywTGMVm IZk6C6FjFpKOWUg6FjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjKqDW37r7mBc/drx EKMAB6MSD+8G58thQqyJZcWVuYcYJTiYlUR4n/8BCvGmJFZWpRblxxeV5qQWH2KU5mBREudl +wSUEkhPLEnNTk0tSC2CyTJxcEo1MOqs32uXvjcwTLLhZscElymn5qxKWrzuxrILSQuiMk7t mZl9IIPn2Fem7dyigl+bX8/gsOwMW/BYtueyG+9KK/a5zl82LF5oHnfId/0vuQM3z81XF23O 1XldZHI2ant6Us7n92osso9Oa+84w6DpmPyTcVWNsbflkawV6X99lm3/8EGvXujhgp1KLMUZ iYZazEXFiQBdbbbGpgIAAA== Archived-At: Cc: mmusic , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 08:36:27 -0000 Rk9VUlRILCBhbmQgcGVyaGFwcyB0aGlzIGlzIG1vcmUgdGhlb3JldGljYWwsIGlmIHlvdSB1c2Ug dHJpY2tsZSB0aGVuIGE9cnRjcC1tdXggZG9lcyBub3QgaW5kaWNhdGUgd2hldGhlciBSVENQIGNh bmRpZGF0ZXMgd2lsbCBjb21lIGxhdGVyIG9yIG5vdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFtt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXSANClNlbnQ6IDI5LiBoZWxtaWt1 dXRhIDIwMTYgMTA6MTINClRvOiBNYXJ0aW4gVGhvbXNvbjsgRmxlbW1pbmcgQW5kcmVhc2VuDQpD YzogbW11c2ljOyBkcmFmdC1pZXRmLW1tdXNpYy1tdXgtZXhjbHVzaXZlQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogW01NVVNJQ10gV0dMQyBvbiBkcmFmdC1pZXRmLW1tdXNpYy1tdXgtZXhjbHVzaXZl LTAzLnR4dA0KDQpIaSBNYXJ0aW4sDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyEgU2VlIGlu bGluZS4NCg0KPiBUaGlzIGRvY3VtZW50IG5lZWRzIHRvIG1vcmUgY2xlYXJseSBhcnRpY3VsYXRl IHRoZSByZWFzb24gZm9yIHRoZSANCj4gYXR0cmlidXRlLiAgQW4gaW1wbGVtZW50YXRpb24gdGhh dCBmYWlscyB0byBnZW5lcmF0ZSB1bmlxdWUgUlRDUCBwb3J0IG51bWJlcnMgKG9uIGE9cnRjcCBv ciBhPWNhbmRpZGF0ZSBsaW5lcykgQU5EIGNoZWNrcyBmb3IgYT1ydGNwLW11eCBhdHRyaWJ1dGVz IHdpbGwgcHJvZHVjZSB0aGUgc2FtZSBlZmZlY3QgYXMgd2l0aCB0aGlzIGF0dHJpYnV0ZS4NCg0K UGVyaGFwcywgYnV0IHRoZXJlIGFyZSBhdCBsZWFzdCBhIGNvdXBsZSBvZiBzZW1hbnRpY2FsIGlz c3VlcyB3aXRoIHRoYXQ6DQoNCkZJUlNULCBzZWN0aW9uIDUuMS4zIG9mIFJGQyA1NzYxIHNheXM6 DQoNCiAgICJJZiBpdCBpcyBkZXNpcmVkIHRvIHVzZSBib3RoIElDRSBhbmQgbXVsdGlwbGV4ZWQg UlRQIGFuZCBSVENQLCB0aGUNCiAgIGluaXRpYWwgb2ZmZXIgTVVTVCBjb250YWluIGFuICJhPXJ0 Y3AtbXV4IiBhdHRyaWJ1dGUgdG8gaW5kaWNhdGUgdGhhdA0KICAgUlRQIGFuZCBSVENQIG11bHRp cGxleGluZyBpcyBkZXNpcmVkIGFuZCBNVVNUIGNvbnRhaW4gImE9Y2FuZGlkYXRlOiINCiAgIGxp bmVzIGZvciBib3RoIFJUUCBhbmQgUlRDUCBhbG9uZyB3aXRoIGFuICJhPXJ0Y3A6IiBsaW5lIGlu ZGljYXRpbmcgYQ0KICAgZmFsbGJhY2sgcG9ydCBmb3IgUlRDUCBpbiB0aGUgY2FzZSB0aGF0IHRo ZSBhbnN3ZXJlciBkb2VzIG5vdCBzdXBwb3J0DQogICBSVFAgYW5kIFJUQ1AgbXVsdGlwbGV4aW5n LiAgVGhpcyBNVVNUIGJlIGRvbmUgZm9yIGVhY2ggbWVkaWEgd2hlcmUNCiAgIFJUUCBhbmQgUlRD UCBtdWx0aXBsZXhpbmcgaXMgZGVzaXJlZC4iDQoNCg0KU0VDT05ELCBkcmFmdC1pZXRmLW1tdXNp Yy1pY2Utc2lwLXNkcCBtYW5kYXRlcyBpdC4gTm93LCB0aGF0IGlmIG9idmlvdXNseSBzb21ldGhp bmcgd2UgY2FuIGNoYW5nZSwgYnV0IG15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgcGVvcGxlIGRp ZG4ndCB3YW50IHRvIHVwZGF0ZSA1NzYxLg0KDQoNClRISVJELCBpZiBJQ0UgaXMgbm90IHVzZWQg dG8gYmVnaW4gd2l0aCwgdGhlcmUgd2lsbCBiZSBubyBjYW5kaWRhdGVzLCBzbyBhPXJ0Y3AtbXV4 IHdpbGwgb2J2aW91c2x5IG5vdCBwcm9kdWNlIHRoZSBzYW1lIHJlc3VsdCA6KQ0KDQoNCj4gQ2Fu IHdlIG1hbmRhdGUgZWl0aGVyIG1hbmRhdG9yeSBpbmNsdXNpb24gb2YgYT1ydGNwIHdpdGggbWF0 Y2hpbmcgDQo+IHRyYW5zcG9ydCBwYXJhbWV0ZXJzLCBvciBtYW5kYXRvcnkgb21pc3Npb24gb2Yg YT1ydGNwPyAgSWYgdGhlcmUgaXMgYSANCj4gcmVhc29uIHRvIGFsbG93IHRoaXMgY2hvaWNlLCBp dCBtaWdodCBiZSB3aXNlIHRvIGRvY3VtZW50IGl0LiAgU2luY2Ugd2UncmUgZXhjbHVzaXZlLCBJ IHNlZSBubyByZWFzb24gdG8gd2FzdGUgYnl0ZXMgYW5kIGN5Y2xlcyBvbiBhPXJ0Y3A7IEknZCBw cmVmZXIgdG8gaGF2ZSBpdCBvbWl0dGVkLiAgV2UncmUgaGlnaGx5IHVubGlrZWx5IHRvIGJlIGNv bXBhdGlibGUgd2l0aCBhbnlvbmUgZXhwZWN0aW5nIHRvIHJlbHkgb24gYT1ydGNwIGluIGFueSBj YXNlLg0KDQpUaGUgb25seSByZWFzb24gaXMgaWYgdGhlIG11eC1leGNsdXNpdmUgbWVjaGFuaXNt IGlzIHVzZWQgdG9nZXRoZXIgd2l0aCBzb21lIG90aGVyIG1lY2hhbmlzbSB0aGF0IHJlcXVpcmVz IHVzYWdlIG9mIGE9cnRjcC4gQXMgbWVudGlvbmVkIGVhcmxpZXIsIGRyYWZ0LWlldGYtbW11c2lj LWljZS1zaXAtc2RwIGN1cnJlbnRseSByZXF1aXJlcyB1c2FnZSBvZiBhPXJ0Y3Agd2l0aCBSVENQ Lg0KDQpXZSBjb3VsZCBvZiBjb3Vyc2Ugc2F5IHRoYXQgb25lIG11c3Qgbm90IGluY2x1ZGUgYT1y dGNwLCB1bmxlc3MgdXNlZCB0b2dldGhlciB3aXRoIGEgbWVjaGFuaXNtIHRoYXQgcmVxdWlyZXMg aXQsIGFuZCB0aGVuIHdlIHN0b3AgZGVmaW5pbmcgZnV0dXJlIG1lY2hhbmlzbXMgdGhhdCB1c2Ug YT1ydGNwLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4gRWRpdG9yaWFsOg0KPg0KPiBSYXRo ZXIgdGhhbjoNCj4NCj4gICBUaGUgUlRDV0VCIFdHIGhhcyBkZWZpbmVkIHRoYXQgc3VwcG9ydCBv ZiB0aGUgZmFsbGJhY2sgbWVudGlvbmVkDQo+ICAgYWJvdmUgaXMgb3B0aW9uYWwuICBUaGVyZWZv cmUsIHRoZXJlIGlzIGEgbmVlZCBmb3IgYSBtZWNoYW5pc20gdGhhdA0KPiAgIGFsbG93cyBhbiBl bmRwb2ludCB0byBpbmRpY2F0ZSBleGNsdXNpdmUgc3VwcG9ydCBvZiBSVFAvUlRDUA0KPiAgIG11 bHRpcGxleGluZywgbWVhbmluZyB0aGF0IGVuZHBvaW50IG9ubHkgc3VwcG9ydHMgUlRQL1JUQ1AN Cj4gICBtdWx0aXBsZXhpbmcgYW5kIGlzIG5vdCBhYmxlIHRvIGZhbGxiYWNrIHRvIHVzYWdlIG9m IHNlcGFyYXRlIHBvcnRzDQo+ICAgZm9yIFJUUCBhbmQgUlRDUC4NCj4NCj5TYXk6DQo+DQo+ICAg U29tZSBuZXdlciBhcHBsaWNhdGlvbnMgdGhhdCBkbyBub3QgcmVxdWlyZSBiYWNrd2FyZCBjb21w YXRpYmlsaXR5IHdpdGggcGVlcnMgdGhhdCBjYW5ub3QgbXVsdGlwbGV4IFJUQ1AgbWlnaHQgY2hv b3NlIHRvIG5vdCANCj4gICBpbXBsZW1lbnQgc2VwYXJhdGlvbiBvZiBSVFAgYW5kIFJUQ1AuICBG b3IgdGhvc2UgYXBwbGljYXRpb25zLCB0aGlzIGRvY3VtZW50IGRlZmluZXMgYW4gU0RQIGF0dHJp YnV0ZSB0byBzaWduYWwgaW50ZW50IHRvIHJlcXVpcmUgbXVsdGlwbGV4aW5nLg0KDQpMb29rcyBn b29kLg0KDQpUaGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Mon Feb 29 00: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 9777A1B2DD3 for ; Mon, 29 Feb 2016 00:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5, 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 rP5C94e-uwOF for ; Mon, 29 Feb 2016 00:46:03 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 633711B2E32 for ; Mon, 29 Feb 2016 00:46:03 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 687EBE4772CBB for ; Mon, 29 Feb 2016 08:45:59 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1T8k1At020950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Feb 2016 08:46:01 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1T8jwb5019053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Feb 2016 09:46:00 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.33]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 29 Feb 2016 09:45:59 +0100 From: "Schwarz, Albrecht (Nokia - DE)" To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg Thread-Index: AQHRK4TSx7C8BOzqRoKqmvGfP3/g4Z61TmFp///0nACAXN0KB4ALF657gBzt17uAAHRDgIAEUD8xgAApQACAA7xPAIAAc4rA Date: Mon, 29 Feb 2016 08:45:58 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1ACE19D4AFD@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> <56D05E8D.5080306@alcatel-lucent.com> <56D08F58.1040709@alum.mit.edu> <56D3B18E.7000904@nteczone.com> In-Reply-To: <56D3B18E.7000904@nteczone.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 29 Feb 2016 08:46:09 -0000 > Perhaps a document could be created that defined RTP/AVP, RTP/AVPF,=20 > RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the=20 > websocket/datachannel registry. And then that document might say that=20 > any sdp attribute designed to be used with protos */(each of these=20 > subprotocols) may also be used in dcsa for a channel using these=20 > protocols. [CNG] Yes it "could" be, if someone actually wanted to carry RTP over a=20 data channel. That would follow with what is being done for MSRP and=20 BFCP. I don't see RTP as being any different. There isn't any use case at all for RTP-over-DC, neither for RTP in general= nor specific RTP profiles "RTP/". Thus, I concur to Christian. Regards, Albrecht -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christian Gr= oves Sent: Montag, 29. Februar 2016 03:49 To: mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg Hello Paul and Juergen, On 27/02/2016 4:46 AM, Paul Kyzivat wrote: > Hi, > > On 2/26/16 9:17 AM, Juergen Stoetzer-Bradler wrote: >> Hello Paul, Christian, >> >> Would propose to add following definition of term "subprotocol" to=20 >> the terminology section 3 of the sdpneg draft: >> >> Data channel subprotocol: The application protocol which is >> transported over a single data channel. Data channel subprotocol >> messages are sent as data channel payload over an established=20 >> data >> channel. If an SDP offer/answer exchange is used as specified in >> this document to negotiate the establishment of data channels, >> corresponding data channel properties, associated data channel >> subprotocols and data channel subprotocol properties, then the=20 >> data >> channel subprotocols may be identified by the values of the >> "subprotocol" parameters of the SDP "a=3Ddcmap" attributes as >> described in Section 5.1.1.5. Within this document the term=20 >> "data >> channel subprotocol" is often abbreviated as just "subprotocol". >> >> This text could explicitly narrow down the notion of "subprotocol" >> within the data channel SDP offer/answer context and might especially=20 >> be helpful distinguishing it from the usages of "subprotocol" in the=20 >> Websocket RFC 6455 (where the term "subprotocol" was taken from, but=20 >> where it does not seem to be formally defined). This text may=20 >> certainly not be helpful in more general non-data channel contexts.=20 >> But it might help to clarify that every occurrence of of the term=20 >> "subprotocol" in the sdpneg draft refers to the application protocol=20 >> which (typically but not necessarily) is identified via the a=3Ddcmap's = "subprotocol" >> parameter. >> >> Would such an explicit definition be helpful from your point of view? > > It might *help*, but it doesn't get at the main problem I see. > > The question is how does this sub-protocol relate the the proto field=20 > used in m-lines? But not to the proto of the m-line for data channel. > My point is that many sdp attributes were designed to be used with=20 > particular proto fields. For instance, with RTP/AVP, RTP/AVPF,=20 > TCP/RTP/AVP, RTP/SAVP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF,=20 > RTP/SAVPF, UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF,=20 > DCCP/TLS/RTP/SAVPF, ... [CNG] Does sub-protocol have to relate to the proto field? The proto field = in the case of WebRTC-datachannel is UDP/DTLS/SCTP. What ever is carried in= the individual data channels is the sub-protocol.=20 Draft-ietf-mmusic-data-channel-sdpneg is only considering this. > > In general they are described as being applicable to RTP. But what is=20 > RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a=20 > super-protocol (of AVP, AVPF, SAVP, SAVPF)? [CNG] I'm not sure it matters? If someone wants to run a particular RTP=20 profile over a data channel then it is a sub-protocol of UDP/DTLS/SCTP.=20 All the other above examples have already been defined so I don't see we=20 gain anything by trying to label them as a sub-protocol etc. > > If we wanted to define use of RTP over a data channel, what=20 > sub-protocol(s) would we have to define? I *think* we would have to=20 > define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted=20 > to support over a data channel. [CNG] Yes I would agree. > > And then how would we do it, and where would we specify which=20 > attributes could be used with dcsa? Would we have to update the=20 > documents that define those attributes? [CNG] I assume we'd follow the example of=20 draft-ietf-mmusic-msrp-usage-data-channel. It discusses the use of=20 existing attributes. I don't see that RTP would need to do anything=20 different. > > ISTM there are similar (though not so complex) issues for pretty much=20 > any attribute that we might want to reuse over a data channel. [CNG] Some will be complex, some will be a no brainer. What=20 draft-ietf-mmusic-data-channel-sdpneg provides is a syntax for re-using=20 attributes. It doesn't provide semantics for every attribute.=20 Implementors need to understand that some attributes have been defined=20 with a particular protocol stack in mind and that they the behaviour may=20 need to be modified when using a data channel. > > Perhaps a document could be created that defined RTP/AVP, RTP/AVPF,=20 > RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the=20 > websocket/datachannel registry. And then that document might say that=20 > any sdp attribute designed to be used with protos */(each of these=20 > subprotocols) may also be used in dcsa for a channel using these=20 > protocols. [CNG] Yes it "could" be, if someone actually wanted to carry RTP over a=20 data channel. That would follow with what is being done for MSRP and=20 BFCP. I don't see RTP as being any different. > > Thanks, > Paul > >> Thanks, >> Juergen >> >> >> On 25.02.2016 22:38, EXT Paul Kyzivat wrote: >>> On 2/24/16 7:24 PM, Christian Groves wrote: >>>> Hello Juergen and Paul, >>>> >>>> Please see at end. >>>> >>>> Regards, Christian >>>> >>>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>>>> ..snip.. >>>>>> >>>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>>>> >>>>>>>> Have just submitted version 08 of >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>>>> The changes compared to version 07 are essentially as follows. >>>>>>>> >>>>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>>>> regarding the >>>>>>>> relationship of subprotocols and their attributes. >>>>>>>> * Two new SDP offer/answer considerations in section 5.2.5 >>>>>>>> (Various >>>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>>>>> channel transport specific semantic is not known. >>>>>>>> * A new paragraph in section 8.1 (IANA Considerations / >>>>>>>> Subprotocol >>>>>>>> Identifiers) related to cases, where a subprotocol is defined for >>>>>>>> data >>>>>>>> channel and Websocket transport. >>>>>>>> >>>>>>>> These changes should address the points discussed in this email >>>>>>>> thread. >>>>>>> >>>>>>> This is an improvement. But I think things could still be made >>>>>>> clearer. >>>>>>> >>>>>>> Consider the following addition to 5.1.2.1: >>>>>>> >>>>>>> It is assumed that in general the usages of subprotocol related >>>>>>> media >>>>>>> level attributes are independent from the subprotocol's=20 >>>>>>> transport >>>>>>> protocol. Such transport protocol independent subprotocol=20 >>>>>>> related >>>>>>> attributes are used in the same way as defined in the original >>>>>>> subprotocol specification, also if the subprotocol is=20 >>>>>>> transported >>>>>>> over a data channel and if the attribute is correspondingly >>>>>>> embedded >>>>>>> in a "a=3Ddcsa" attribute. >>>>>>> >>>>>>> There may be cases, where the usage of a subprotocol related=20 >>>>>>> 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. A data channel >>>>>>> specific usage of a subprotocol attribute is expected to be >>>>>>> specified >>>>>>> in the same document, which registers the subprotocol's=20 >>>>>>> identifier >>>>>>> for data channel usage as described in Section 8.1. >>>>>>> >>>>>>> This text makes sense when there is a clear distinction between >>>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved >>>>>>> there >>>>>>> is no such clear distinction in many cases, such as RTP over UDP or >>>>>>> TCP, etc. Those are combined into a single protocol value. While=20 >>>>>>> that >>>>>>> can usually be parsed apart at slashes, there isn't good=20 >>>>>>> terminology >>>>>>> for it. >>>>>>> >>>>>>> My point is that when I read the above, I don't know how it applies >>>>>>> to, say, RTP attributes. Or does it only apply for attributes that >>>>>>> are >>>>>>> clearly defined for a *sub*protocol? >>>>>>> >>>>>>> I think this is primarily that we lack well defined vocabulary for >>>>>>> all >>>>>>> of this. But I think it would be too much to expect this draft to >>>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it >>>>>>> would be >>>>>>> sufficient to give some concrete examples, even if they have to be >>>>>>> hypothetical ones. >>>>>> >>>>>> [Juergen] Agree that it would be helpful to have more precise >>>>>> definitions of the differences of the terms protocol and=20 >>>>>> subprotocol, >>>>>> especially when those terms are used outside the scope of data >>>>>> channels >>>>>> (or Websockets). When only focusing on data channels the notion of a >>>>>> "subprotocol" seems to be clearer - at least >>>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" >>>>>> parameter. >>>>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>>>> informally starts using the term "subprotocol" in the=20 >>>>>> introduction and >>>>>> there refers to Websocket "subprotocols". Perhaps we should add the >>>>>> term >>>>>> "subprotocol" to the list of used terminology in section 3. >>>>>> >>>>>> The sdpneg document, together with the data channel subprotocol >>>>>> specific >>>>>> document (which defines the value of the a=3Ddcmap attribute's >>>>>> "subprotocol" parameter), should certainly give clear guidance on >>>>>> how to >>>>>> interpret SDP offers or answers like e.g.: >>>>>> >>>>>> m=3Dapplication 10001 UDP/DTLS/SCTP webrtc-datachannel >>>>>> c=3DIN IP4 10.10.10.1 >>>>>> a=3Dmax-message-size:100000 >>>>>> a=3Dsctp-port:5000 >>>>>> ... >>>>>> a=3Ddcmap:0 subprotocol=3D"MSRP" >>>>>> a=3Ddcsa:0 accept-types:message/cpim text/plain >>>>>> a=3Ddcsa:0 framerate:... >>>>>> a=3Ddcsa:0 lang:... >>>>>> >>>>>> An implementation receiving such an offer would need to decide=20 >>>>>> what to >>>>>> do with the dcsa embedded framerate and lang attributes. Or, someone >>>>>> implementing MSRP over data channel based services may need to=20 >>>>>> decide >>>>>> whether or not to use these attributes, and if yes, how. >>>>>> (I am using these two attributes just as hypothetical examples -=20 >>>>>> don't >>>>>> want to suggest that those may indeed be used for MSRP over data >>>>>> channel >>>>>> transport). >>>>>> >>>>>> The msrp-usage-data-channel document doesn't mention these two >>>>>> attributes. When looking at the IANA SDP attribute registry=20 >>>>>> tables, I >>>>>> would find both attributes specified in RFC 4566. There, >>>>>> "framerate" is >>>>>> explicitly said to be defined only "for video media". Just to be >>>>>> sure I >>>>>> could additionally have a look at the MSRP specifying documents, RFC >>>>>> 4975 and RFC 4976, but there would not find any text at all=20 >>>>>> related to >>>>>> "framerate". So this case seems pretty clear and I would therefore >>>>>> conclude that the "framerate" attribute should not be used for >>>>>> MSRP, and >>>>>> that a receiver of such an offer or answer should ignore it. >>>>>> >>>>>> When looking at the definition of the "lang" attribute in RFC 4566 I >>>>>> would not see any explicit hint of what protocols this attribute=20 >>>>>> might >>>>>> be used with, especially if "lang" could be used when negotiating an >>>>>> MSRP session. When then looking at RFC 4975 I would indeed find >>>>>> "lang" - >>>>>> but not as SDP attribute, rather as XML tag parameter within an >>>>>> example >>>>>> MSRP message payload. Thus, the case of the "lang" attribute=20 >>>>>> might not >>>>>> be as unambiguous as the one with the "framerate" attribute, but=20 >>>>>> here >>>>>> too I think the typical choice would be to ignore that attribute=20 >>>>>> when >>>>>> receiving such an offer or answer. >>>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>>>> sdpneg-08 may also be applied in these cases. >>>>>> >>>>>> Admittedly, these examples may seem a bit far-fetched, but would=20 >>>>>> those >>>>>> go into the direction you had in mind? >>>>> >>>>> Yes. Note that using examples is just me grasping at straws, since a >>>>> real solution looks like to big a problem for this draft to tackle by >>>>> itself. I am entirely open to other ideas for how to deal with this. >>>> [CNG] I don't see what the example buys? I don't see that the=20 >>>> behaviour >>>> is any different between using additional attributes in the=20 >>>> datachannel >>>> vs. the non data channel case. E.g. for >>>> >>>> c=3DIN IP4 10.10.10.1 >>>> m=3Dmessage 7394 TCP/MSRP * >>>> a=3Daccept-types:message/cpim text/plain text/html >>>> a=3Dlang:.... >>>> a=3Dframerate:... >>>> The ignore behaviour would be the same. >>>> In the above example the attributes are scoped by the m=3D line. In th= e >>>> data channel case the attributes are scoped by the relevant a=3Ddcmap: >>>> line. >>> >>> My concern is that SDP has no notion of subprotocol, even though in >>> practice it shows up lots of places. It only has a notion of the >>> protocol field in the m-line. Beyond that a *convention* has developed >>> to denote a layering within the protocol through use of "/". AFAIK >>> this isn't formally written down anywhere. >>> >>> So, in principle we could define an RTP sub-protocol for use over a >>> data channel. And then we could talk about using the attributes that >>> apply to RTP in dcsa for a channel using RTP. But note there is no >>> formal definition of the *protocol*s where RTP attributes are relevant. >>> >>> A lot of the very old stuff was just sloppy. To be fair, it was >>> probably good enough for the cases in front of them at the time, and >>> they weren't yet in a position to foresee how things would evolve. It >>> is just another example of how old stuff rots and has to be refreshed >>> from time to time. >>> >>> But I don't think *this* draft is the place to fix it. So, in lieu of >>> doing that I'm just looking for some way to clarify things. >>> >>> Thanks, >>> Paul >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Feb 29 01:37: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 8F2251B2EDD; Mon, 29 Feb 2016 01:36:59 -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 KeXrq9LTyfpy; Mon, 29 Feb 2016 01:36:57 -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 236BB1B2ED8; Mon, 29 Feb 2016 01:36:56 -0800 (PST) X-AuditID: c1b4fb30-f79096d000002f68-02-56d41136fd05 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.6C.12136.63114D65; Mon, 29 Feb 2016 10:36:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 10:36:53 +0100 From: Christer Holmberg To: mmusic Thread-Topic: Draft new: draft-holmberg-mmusic-4572-update Thread-Index: AdFy1FBcjXYj62IYQle5pMOTuSLOpA== Date: Mon, 29 Feb 2016 09:36:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4B61C@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E4B61CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdQ9dM8EqYwer5Rhbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgylvQeYS7YK1/x7PAylgbGaTJdjJwcEgImEvd/LGGH sMUkLtxbzwZiCwkcZpTo/WXaxcgFZC9mlHj7+ylTFyMHB5uAhUT3P22QGhEBGYm9mzYzg9jM AqYSD1+tYQSxhYHsG/9vskHUWEn837EbytaTmLrrOdguFgFViSmH54HV8wr4SpzftIgJxGYE uuH7qTVMEDPFJW49mc8EcZuAxJI955khbFGJl4//sULYihI7z7Yzg5zGLJAvsa6PB2KkoMTJ mU9YJjAKz0IyaRZC1SwkVRAlOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHi1OKk3HQj I73Uoszk4uL8PL281JJNjMB4Objlt8EOxpfPHQ8xCnAwKvHwbnC+HCbEmlhWXJl7iFGCg1lJ hPf5H6AQb0piZVVqUX58UWlOavEhRmkOFiVxXtZPQCmB9MSS1OzU1ILUIpgsEwenVAOjm1+Y svHlnOl9fq+uO954eDk9pUU998jTXZe5z2k2RW5UzYg6xr3kl6n6gsecB5Mnu3E0eDAXf/At Kp2378XDhq+iNnkpszx/7lizu22xhcnBG0dU+teq39vwx/Lat/7KQ3ltN6038eW7nrZk/viS 6+DeC/ab5jziT+APtpbTPFe6JnU24wthJZbijERDLeai4kQA3gT9VJMCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new: draft-holmberg-mmusic-4572-update 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, 29 Feb 2016 09:36:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E4B61CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I submitted a new draft, draft-holmberg-mmusic-4572-update. The purpose is = for making the 4572 updates we have been discussing: usage of multiple 'fin= gerprint' attributes, and updating the preferred cipher suite. The cipher suite update should not be a big issue, but feel free to suggest= text regarding the 'fingerprint' attribute. Also on github: https://github.com/cdh4u/draft-4572-update Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37E4B61CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I submitted a new draft, draft-holmberg-mmusic-4572-updat= e. The purpose is for making the 4572 updates we have been discussing: usag= e of multiple ‘fingerprint’ attributes, and updating the preferred cipher suite.

 = ;

The cipher= suite update should not be a big issue, but feel free to suggest text rega= rding the ‘fingerprint’ attribute.

 = ;

Also on gi= thub: https://github.com/cdh4u/draft-4572-update

 = ;

Regards,

 = ;

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E4B61CESESSMB209erics_-- From nobody Mon Feb 29 05:28: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 742C81A89A5 for ; Mon, 29 Feb 2016 05:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 UE2_mG_Vc4GK for ; Mon, 29 Feb 2016 05:27:57 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC441A8999 for ; Mon, 29 Feb 2016 05:27:57 -0800 (PST) Received: from [130.209.247.112] (port=60774 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aaNre-0003Vv-3S; Mon, 29 Feb 2016 13:27:54 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56D1CA6C.70700@alum.mit.edu> Date: Mon, 29 Feb 2016 13:27:49 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 13:27:59 -0000 > On 27 Feb 2016, at 16:10, Paul Kyzivat wrote: >=20 > On 2/27/16 4:29 AM, Roman Shpount wrote: >> One potential solution is to generate any offer in such a way that it >> will be compatible with all the completed O/A exchanges for this end >> point. If an end point receives an offer which is not compatible with >> existing state, i.e. an offer which is reusing one of the PT for a >> different codec profile similar, this end point must allocate new >> transport (use new local address/port or new local set of candidates = in >> case of ICE) for the answer and consider this a start of the new = session >> (discard all the PT use history). If new transport cannot be = allocated, >> for instance if responding to an offer with ICE and existing ufrag, = then >> offer must be refused with 488 or m line with port 0. This way end = point >> can always uniquely map the PT to the codec profile based on PT and >> local transport where the packet is received. In case of 3pcc, an end >> point might get an offer which is incompatible with its PT use = history; >> allocate new local transport, and handle it as a new RTP session. >>=20 >> What do you think? >=20 > While there are probably a lot of details to work out, I like it as = the outline of a direction to pursue. >=20 > It could get complicated for a focus. It might require the focus to = change mixing policies for the offending participant. I expect it depends on the RTP topology in use. Some of the options in = RFC 7667 treat different call legs as separate RTP sessions, whereas = others treat them as a single session. That makes a difference, since PT = is session scoped.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Mon Feb 29 05:28: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 35BC51A89AF for ; Mon, 29 Feb 2016 05:28:18 -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 aUJlK7cJFdEQ for ; Mon, 29 Feb 2016 05:28:16 -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 4EBA41A89A9 for ; Mon, 29 Feb 2016 05:28:15 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-c0-56d4476c2099 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.18.25494.C6744D65; Mon, 29 Feb 2016 14:28:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 14:28:12 +0100 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wARGIiAAAEzHQAAFHhLgAANDP0AAABf9wAAANkcgAABPnAAAACT0gAAARuRgAAArliAACAJAYAADgPBAABONv0AABK4WIA= Date: Mon, 29 Feb 2016 13:28:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> 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_7594FB04B1934943A5C02806D1A2204B37E4BD38ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7lG6u+5Uwg97J7BZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgy+vuOMxW8ya843nWEtYHx RU4XIyeHhICJROvtPiYIW0ziwr31bF2MXBxCAocZJWaf2MUC4SxmlOh9sQMow8HBJmAh0f1P G6RBRMBboq+vgx0kzCygLnF1cRBIWFjAXmL6s8dMECUOEre3/mIHGSMi0MUocWTbN1aQBIuA qkRrw1ewIl4BX4kXd9rAbCGBG6wST15Wg9icAoESdz+cYgexGYGO+35qDVgNs4C4xK0n86GO FpBYsuc8M4QtKvHy8T9WCFtRYufZdmaI+nyJfV8+M0PsEpQ4OfMJywRG0VlIRs1CUjYLSdks sNc0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJN jMD4O7jlt+4OxtWvHQ8xCnAwKvHwbnC+HCbEmlhWXJl7iFGCg1lJhNfa9UqYEG9KYmVValF+ fFFpTmrxIUZpDhYlcV62T0DVAumJJanZqakFqUUwWSYOTqkGRsOddnq+F01yg08d8X2zlev6 1bTLH0K0tf9226tGvlSsndrlYPw75PXRdf5xOnpi3e5CUTJL0x+mtdYn3S9ve3b+Tub/ekEH PcmTvMLb7r7+9KdTNkp5xsUvC94eaY62U8674M9yWk/Of7fqM3aVhVYJTn2XrY7asGY29b44 dYeJa3p89mJNJZbijERDLeai4kQA0yjTHLsCAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 13:28:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E4BD38ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNEUCBPZmZlci9BbnN3ZXIgY2F1c2VzIGxvdHMgb2YgcHJvYmxlbS4gV2hlbiBJIHJl YWQgYWxsIHRoaXMgaXQgc2VlbXMgbGlrZSB3ZSB3YW50IHRvIGNvbXBsaWNhdGUgdGhpbmdzIOKA kyB3aGljaCB2ZXJ5IGxpa2VseSB3aWxsIGNhdXNlIGFueSBtb3JlIHByb2JsZW1zLg0KDQpUd28g ZW5kcG9pbnRzIHVzZSBTRFAgT2ZmZXIvQW5zd2VyIHRvIG5lZ290aWF0ZSBhbiDigJxTRFAgc2Vz c2lvbuKAnS4gQ2Fu4oCZdCB3ZSB0cnkgdG8gZGVmaW5lIHdoYXQgcnVsZXMgYXBwbHkgd2l0aGlu IHRoYXQg4oCcU0RQIHNlc3Npb27igJ0/IFdoeSBkbyB3ZSBoYXZlIHRvIHRhbGsgYWJvdXQgUlRQ IHNlc3Npb25zIGV0Yz8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hw b3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMjkuIGhlbG1pa3V1dGEgMjAx NiA3OjMwDQpUbzogUGF1bCBLeXppdmF0DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmc7IG1tdXNpY0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIE9mZmVyL0Fuc3dlciBQVCBRdWVzdGlvbnMg LSB0ZXh0IHByb3Bvc2FsDQoNCk9uIFNhdCwgRmViIDI3LCAyMDE2IGF0IDExOjEwIEFNLCBQYXVs IEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQu ZWR1Pj4gd3JvdGU6DQpPbiAyLzI3LzE2IDQ6MjkgQU0sIFJvbWFuIFNocG91bnQgd3JvdGU6DQpP bmUgcG90ZW50aWFsIHNvbHV0aW9uIGlzIHRvIGdlbmVyYXRlIGFueSBvZmZlciBpbiBzdWNoIGEg d2F5IHRoYXQgaXQNCndpbGwgYmUgY29tcGF0aWJsZSB3aXRoIGFsbCB0aGUgY29tcGxldGVkIE8v QSBleGNoYW5nZXMgZm9yIHRoaXMgZW5kDQpwb2ludC4gSWYgYW4gZW5kIHBvaW50IHJlY2VpdmVz IGFuIG9mZmVyIHdoaWNoIGlzIG5vdCBjb21wYXRpYmxlIHdpdGgNCmV4aXN0aW5nIHN0YXRlLCBp LmUuIGFuIG9mZmVyIHdoaWNoIGlzIHJldXNpbmcgb25lIG9mIHRoZSBQVCBmb3IgYQ0KZGlmZmVy ZW50IGNvZGVjIHByb2ZpbGUgc2ltaWxhciwgdGhpcyBlbmQgcG9pbnQgbXVzdCBhbGxvY2F0ZSBu ZXcNCnRyYW5zcG9ydCAodXNlIG5ldyBsb2NhbCBhZGRyZXNzL3BvcnQgb3IgbmV3IGxvY2FsIHNl dCBvZiBjYW5kaWRhdGVzIGluDQpjYXNlIG9mIElDRSkgZm9yIHRoZSBhbnN3ZXIgYW5kIGNvbnNp ZGVyIHRoaXMgYSBzdGFydCBvZiB0aGUgbmV3IHNlc3Npb24NCihkaXNjYXJkIGFsbCB0aGUgUFQg dXNlIGhpc3RvcnkpLiBJZiBuZXcgdHJhbnNwb3J0IGNhbm5vdCBiZSBhbGxvY2F0ZWQsDQpmb3Ig aW5zdGFuY2UgaWYgcmVzcG9uZGluZyB0byBhbiBvZmZlciB3aXRoIElDRSBhbmQgZXhpc3Rpbmcg dWZyYWcsIHRoZW4NCm9mZmVyIG11c3QgYmUgcmVmdXNlZCB3aXRoIDQ4OCBvciBtIGxpbmUgd2l0 aCBwb3J0IDAuIFRoaXMgd2F5IGVuZCBwb2ludA0KY2FuIGFsd2F5cyB1bmlxdWVseSBtYXAgdGhl IFBUIHRvIHRoZSBjb2RlYyBwcm9maWxlIGJhc2VkIG9uIFBUIGFuZA0KbG9jYWwgdHJhbnNwb3J0 IHdoZXJlIHRoZSBwYWNrZXQgaXMgcmVjZWl2ZWQuIEluIGNhc2Ugb2YgM3BjYywgYW4gZW5kDQpw b2ludCBtaWdodCBnZXQgYW4gb2ZmZXIgd2hpY2ggaXMgaW5jb21wYXRpYmxlIHdpdGggaXRzIFBU IHVzZSBoaXN0b3J5Ow0KYWxsb2NhdGUgbmV3IGxvY2FsIHRyYW5zcG9ydCwgYW5kIGhhbmRsZSBp dCBhcyBhIG5ldyBSVFAgc2Vzc2lvbi4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCldoaWxlIHRo ZXJlIGFyZSBwcm9iYWJseSBhIGxvdCBvZiBkZXRhaWxzIHRvIHdvcmsgb3V0LCBJIGxpa2UgaXQg YXMgdGhlIG91dGxpbmUgb2YgYSBkaXJlY3Rpb24gdG8gcHVyc3VlLg0KDQpJdCBjb3VsZCBnZXQg Y29tcGxpY2F0ZWQgZm9yIGEgZm9jdXMuIEl0IG1pZ2h0IHJlcXVpcmUgdGhlIGZvY3VzIHRvIGNo YW5nZSBtaXhpbmcgcG9saWNpZXMgZm9yIHRoZSBvZmZlbmRpbmcgcGFydGljaXBhbnQuDQoNClBU IGNvbGxpc2lvbnMgYXJlIGFscmVhZHkgYSBxdWl0ZSBjb21wbGljYXRlZCBmb3IgdGhlIGNvbmZl cmVuY2UgZm9jdXMuIENvbmZlcmVuY2UgZm9jdXMgbmVlZHMgdG8gZGVhbCB3aXRoIHNpdHVhdGlv bnMgd2hlbiBtdWx0aXBsZSBpbmJvdW5kIGNhbGxlcnMgKGluIGNhc2Ugb2YgbWVldC1tZSBjb25m ZXJlbmNlKSB1c2UgdGhlIHNhbWUgUFQgaW4gaW5jb21wYXRpYmxlIHdheS4gV2hlbiBvdXRib3Vu ZCBjYWxscyBhcmUgcGxhY2VkIGZyb20gdGhlIGZvY3VzLCBlbmQgcG9pbnRzIGNhbiBhZGQgUFQg dG8gdGhlIGFuc3dlciB3aGljaCBjYW4gYWxzbyBwcm9kdWNlIFBUIGNvbGxpc2lvbnMuIFdpdGgg bXkgcHJvcG9zYWwgdGhlc2UgY29sbGlzaW9ucyBjYW4gYmUgcmVzb2x2ZWQgdXNpbmcgYSByZS1J TlZJVEUgZnJvbSB0aGUgZm9jdXMgd2hpY2ggd2lsbCBmb3JjZSBuZXcgUlRQIHNlc3Npb25zIHRv IGJlIGNyZWF0ZWQgb24gdGhlIGNsaWVudHMuDQoNCkZyb20gaW1wbGVtZW50YXRpb24gZXhwZXJp ZW5jZSBQVCBjb2xsaXNpb25zIGRvIG5vdCBwcmVzZW50IGEgcmVhbCBwcm9ibGVtIGluIHByYWN0 aWNlLiBBbGwgcHJhY3RpY2FsIGltcGxlbWVudGF0aW9ucyBvZiBSVFAgbXV4IHRoYXQgSSBoYWQg ZGVhbHQgd2l0aCBlaXRoZXIgd29ya2VkIHdpdGggc3BlY2lhbGx5IHByZS1wcm92aXNpb25lZCBl bmQgcG9pbnRzIHdoaWNoIGFsbCB1c2VkIHRoZSBzYW1lIFBUIGZvciB0aGUgc2FtZSBjb2RlYyBw cm9maWxlcyBvciBjb25mZXJlbmNlIGZvY3VzIGltcGxlbWVudGVkIFBUIHJlLW1hcHBpbmcgb24g ZWFjaCBvZiB0aGUgY2FsbCBsZWdzLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4g U2hwb3VudA0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37E4BD38ESESSMB209erics_ 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+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNEUCBPZmZlci9B bnN3ZXIgY2F1c2VzIGxvdHMgb2YgcHJvYmxlbS4gV2hlbiBJIHJlYWQgYWxsIHRoaXMgaXQgc2Vl bXMgbGlrZSB3ZSB3YW50IHRvIGNvbXBsaWNhdGUgdGhpbmdzIOKAkyB3aGljaCB2ZXJ5IGxpa2Vs eSB3aWxsIGNhdXNlIGFueSBtb3JlDQogcHJvYmxlbXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlR3byBlbmRwb2ludHMgdXNlIFNEUCBPZmZlci9BbnN3ZXIgdG8gbmVnb3Rp YXRlIGFuIOKAnFNEUCBzZXNzaW9u4oCdLiBDYW7igJl0IHdlIHRyeSB0byBkZWZpbmUgd2hhdCBy dWxlcyBhcHBseSB3aXRoaW4gdGhhdCDigJxTRFAgc2Vzc2lvbuKAnT8gV2h5IGRvIHdlDQogaGF2 ZSB0byB0YWxrIGFib3V0IFJUUCBzZXNzaW9ucyBldGM/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb21hbiBTaHBvdW50IFttYWlsdG86 cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjkuIGhlbG1pa3V1dGEgMjAx NiA3OjMwPGJyPg0KPGI+VG86PC9iPiBQYXVsIEt5eml2YXQ8YnI+DQo8Yj5DYzo8L2I+IENocmlz dGVyIEhvbG1iZXJnOyBtbXVzaWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtN TVVTSUNdIE9mZmVyL0Fuc3dlciBQVCBRdWVzdGlvbnMgLSB0ZXh0IHByb3Bvc2FsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0 LCBGZWIgMjcsIDIwMTYgYXQgMTE6MTAgQU0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0QGFsdW0u bWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMi8yNy8xNiA0OjI5IEFN LCBSb21hbiBTaHBvdW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T25lIHBvdGVudGlhbCBzb2x1dGlvbiBpcyB0byBnZW5lcmF0ZSBhbnkgb2ZmZXIgaW4gc3Vj aCBhIHdheSB0aGF0IGl0PGJyPg0Kd2lsbCBiZSBjb21wYXRpYmxlIHdpdGggYWxsIHRoZSBjb21w bGV0ZWQgTy9BIGV4Y2hhbmdlcyBmb3IgdGhpcyBlbmQ8YnI+DQpwb2ludC4gSWYgYW4gZW5kIHBv aW50IHJlY2VpdmVzIGFuIG9mZmVyIHdoaWNoIGlzIG5vdCBjb21wYXRpYmxlIHdpdGg8YnI+DQpl eGlzdGluZyBzdGF0ZSwgaS5lLiBhbiBvZmZlciB3aGljaCBpcyByZXVzaW5nIG9uZSBvZiB0aGUg UFQgZm9yIGE8YnI+DQpkaWZmZXJlbnQgY29kZWMgcHJvZmlsZSBzaW1pbGFyLCB0aGlzIGVuZCBw b2ludCBtdXN0IGFsbG9jYXRlIG5ldzxicj4NCnRyYW5zcG9ydCAodXNlIG5ldyBsb2NhbCBhZGRy ZXNzL3BvcnQgb3IgbmV3IGxvY2FsIHNldCBvZiBjYW5kaWRhdGVzIGluPGJyPg0KY2FzZSBvZiBJ Q0UpIGZvciB0aGUgYW5zd2VyIGFuZCBjb25zaWRlciB0aGlzIGEgc3RhcnQgb2YgdGhlIG5ldyBz ZXNzaW9uPGJyPg0KKGRpc2NhcmQgYWxsIHRoZSBQVCB1c2UgaGlzdG9yeSkuIElmIG5ldyB0cmFu c3BvcnQgY2Fubm90IGJlIGFsbG9jYXRlZCw8YnI+DQpmb3IgaW5zdGFuY2UgaWYgcmVzcG9uZGlu ZyB0byBhbiBvZmZlciB3aXRoIElDRSBhbmQgZXhpc3RpbmcgdWZyYWcsIHRoZW48YnI+DQpvZmZl ciBtdXN0IGJlIHJlZnVzZWQgd2l0aCA0ODggb3IgbSBsaW5lIHdpdGggcG9ydCAwLiBUaGlzIHdh eSBlbmQgcG9pbnQ8YnI+DQpjYW4gYWx3YXlzIHVuaXF1ZWx5IG1hcCB0aGUgUFQgdG8gdGhlIGNv ZGVjIHByb2ZpbGUgYmFzZWQgb24gUFQgYW5kPGJyPg0KbG9jYWwgdHJhbnNwb3J0IHdoZXJlIHRo ZSBwYWNrZXQgaXMgcmVjZWl2ZWQuIEluIGNhc2Ugb2YgM3BjYywgYW4gZW5kPGJyPg0KcG9pbnQg bWlnaHQgZ2V0IGFuIG9mZmVyIHdoaWNoIGlzIGluY29tcGF0aWJsZSB3aXRoIGl0cyBQVCB1c2Ug aGlzdG9yeTs8YnI+DQphbGxvY2F0ZSBuZXcgbG9jYWwgdHJhbnNwb3J0LCBhbmQgaGFuZGxlIGl0 IGFzIGEgbmV3IFJUUCBzZXNzaW9uLjxicj4NCjxicj4NCldoYXQgZG8geW91IHRoaW5rPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2hpbGUgdGhlcmUgYXJlIHBy b2JhYmx5IGEgbG90IG9mIGRldGFpbHMgdG8gd29yayBvdXQsIEkgbGlrZSBpdCBhcyB0aGUgb3V0 bGluZSBvZiBhIGRpcmVjdGlvbiB0byBwdXJzdWUuPGJyPg0KPGJyPg0KSXQgY291bGQgZ2V0IGNv bXBsaWNhdGVkIGZvciBhIGZvY3VzLiBJdCBtaWdodCByZXF1aXJlIHRoZSBmb2N1cyB0byBjaGFu Z2UgbWl4aW5nIHBvbGljaWVzIGZvciB0aGUgb2ZmZW5kaW5nIHBhcnRpY2lwYW50LjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UFQg Y29sbGlzaW9ucyBhcmUgYWxyZWFkeSBhIHF1aXRlIGNvbXBsaWNhdGVkIGZvciB0aGUgY29uZmVy ZW5jZSBmb2N1cy4gQ29uZmVyZW5jZSBmb2N1cyBuZWVkcyB0byBkZWFsIHdpdGggc2l0dWF0aW9u cyB3aGVuIG11bHRpcGxlIGluYm91bmQgY2FsbGVycyAoaW4gY2FzZSBvZiBtZWV0LW1lIGNvbmZl cmVuY2UpIHVzZSB0aGUgc2FtZSBQVCBpbiBpbmNvbXBhdGlibGUgd2F5LiBXaGVuIG91dGJvdW5k IGNhbGxzDQogYXJlIHBsYWNlZCBmcm9tIHRoZSBmb2N1cywgZW5kIHBvaW50cyBjYW4gYWRkIFBU IHRvIHRoZSBhbnN3ZXIgd2hpY2ggY2FuIGFsc28gcHJvZHVjZSBQVCBjb2xsaXNpb25zLiBXaXRo IG15IHByb3Bvc2FsIHRoZXNlIGNvbGxpc2lvbnMgY2FuIGJlIHJlc29sdmVkIHVzaW5nIGEgcmUt SU5WSVRFIGZyb20gdGhlIGZvY3VzIHdoaWNoIHdpbGwgZm9yY2UgbmV3IFJUUCBzZXNzaW9ucyB0 byBiZSBjcmVhdGVkIG9uIHRoZSBjbGllbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIGltcGxlbWVudGF0aW9uIGV4cGVy aWVuY2UgUFQgY29sbGlzaW9ucyBkbyBub3QgcHJlc2VudCBhIHJlYWwgcHJvYmxlbSBpbiBwcmFj dGljZS4gQWxsIHByYWN0aWNhbCBpbXBsZW1lbnRhdGlvbnMgb2YgUlRQIG11eCB0aGF0IEkgaGFk IGRlYWx0IHdpdGggZWl0aGVyIHdvcmtlZCB3aXRoIHNwZWNpYWxseSBwcmUtcHJvdmlzaW9uZWQg ZW5kIHBvaW50cyB3aGljaCBhbGwgdXNlZCB0aGUgc2FtZSBQVCBmb3INCiB0aGUgc2FtZSBjb2Rl YyBwcm9maWxlcyBvciBjb25mZXJlbmNlIGZvY3VzIGltcGxlbWVudGVkIFBUIHJlLW1hcHBpbmcg b24gZWFjaCBvZiB0aGUgY2FsbCBsZWdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21h biBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37E4BD38ESESSMB209erics_-- From nobody Mon Feb 29 07:16:30 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 2ED571B3354 for ; Mon, 29 Feb 2016 07:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=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 l7XjIEogmaRd for ; Mon, 29 Feb 2016 07:16:25 -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 BB9581B3362 for ; Mon, 29 Feb 2016 07:16:15 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-01v.sys.comcast.net with comcast id QFGB1s00329Cfhx01FGF3y; Mon, 29 Feb 2016 15:16:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id QFGE1s00B3KdFy101FGEd3; Mon, 29 Feb 2016 15:16:15 +0000 To: mmusic@ietf.org References: <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> <56D05E8D.5080306@alcatel-lucent.com> <56D08F58.1040709@alum.mit.edu> <56D3B18E.7000904@nteczone.com> <786615F3A85DF44AA2A76164A71FE1ACE19D4AFD@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56D460BD.6080306@alum.mit.edu> Date: Mon, 29 Feb 2016 10:16:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACE19D4AFD@FR711WXCHMBA03.zeu.alcatel-lucent.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=1456758975; bh=b2WAKYiKfz66NPuZwyC9w3ImKq7WFsCTh4eaTzu8uLU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=cxAuqRxbtmwAk/Gfg8mUbZxDeYkMm7xNx6vwuzq5cfiR0T0JQnOms7kXvECUlC5X0 uOSA3bBu53IgIxg5yTjKMmNNTJcqt+B8ZWm/ECaDKrcXX0SqQ1VbsoMxnN83fX+qEf lNKC6aynGFDnCjuZQFrvD9EHTzhu2nPte90vRePfTEUYaSiN3AnbwMrlye+puYTJ9+ YA4VXzZrVfTh8c2j1MVjucPKrwOqJJ96s7FKsj2J/PYflgYE3hVJMJim9s5Y6gbA1D xNW5aKZ8yUyc8MOmq9Pd4NYI0TelT8EgF8oIOcKEwuQaATu9gEqAbZ4SC3XNEZODFJ JgOufhso5w21Q== 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: Mon, 29 Feb 2016 15:16:29 -0000 Since I am the only one who thinks there is a problem I'm going to just stop talking about it. We can deal with the problem if/when it arises. (I don't like leaving loose ends, but it isn't important enough to pursue here.) Thanks, Paul On 2/29/16 3:45 AM, Schwarz, Albrecht (Nokia - DE) wrote: >> Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, >> RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the >> websocket/datachannel registry. And then that document might say that >> any sdp attribute designed to be used with protos */(each of these >> subprotocols) may also be used in dcsa for a channel using these >> protocols. > [CNG] Yes it "could" be, if someone actually wanted to carry RTP over a > data channel. That would follow with what is being done for MSRP and > BFCP. I don't see RTP as being any different. > > There isn't any use case at all for RTP-over-DC, neither for RTP in general nor specific RTP profiles "RTP/". > Thus, I concur to Christian. > Regards, > Albrecht > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christian Groves > Sent: Montag, 29. Februar 2016 03:49 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg > > Hello Paul and Juergen, > > On 27/02/2016 4:46 AM, Paul Kyzivat wrote: >> Hi, >> >> On 2/26/16 9:17 AM, Juergen Stoetzer-Bradler wrote: >>> Hello Paul, Christian, >>> >>> Would propose to add following definition of term "subprotocol" to >>> the terminology section 3 of the sdpneg draft: >>> >>> Data channel subprotocol: The application protocol which is >>> transported over a single data channel. Data channel subprotocol >>> messages are sent as data channel payload over an established >>> data >>> channel. If an SDP offer/answer exchange is used as specified in >>> this document to negotiate the establishment of data channels, >>> corresponding data channel properties, associated data channel >>> subprotocols and data channel subprotocol properties, then the >>> data >>> channel subprotocols may be identified by the values of the >>> "subprotocol" parameters of the SDP "a=dcmap" attributes as >>> described in Section 5.1.1.5. Within this document the term >>> "data >>> channel subprotocol" is often abbreviated as just "subprotocol". >>> >>> This text could explicitly narrow down the notion of "subprotocol" >>> within the data channel SDP offer/answer context and might especially >>> be helpful distinguishing it from the usages of "subprotocol" in the >>> Websocket RFC 6455 (where the term "subprotocol" was taken from, but >>> where it does not seem to be formally defined). This text may >>> certainly not be helpful in more general non-data channel contexts. >>> But it might help to clarify that every occurrence of of the term >>> "subprotocol" in the sdpneg draft refers to the application protocol >>> which (typically but not necessarily) is identified via the a=dcmap's "subprotocol" >>> parameter. >>> >>> Would such an explicit definition be helpful from your point of view? >> >> It might *help*, but it doesn't get at the main problem I see. >> >> The question is how does this sub-protocol relate the the proto field >> used in m-lines? But not to the proto of the m-line for data channel. >> My point is that many sdp attributes were designed to be used with >> particular proto fields. For instance, with RTP/AVP, RTP/AVPF, >> TCP/RTP/AVP, RTP/SAVP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, >> RTP/SAVPF, UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF, >> DCCP/TLS/RTP/SAVPF, ... > [CNG] Does sub-protocol have to relate to the proto field? The proto field in the case of WebRTC-datachannel is UDP/DTLS/SCTP. What ever is carried in the individual data channels is the sub-protocol. > Draft-ietf-mmusic-data-channel-sdpneg is only considering this. > >> >> In general they are described as being applicable to RTP. But what is >> RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a >> super-protocol (of AVP, AVPF, SAVP, SAVPF)? > [CNG] I'm not sure it matters? If someone wants to run a particular RTP > profile over a data channel then it is a sub-protocol of UDP/DTLS/SCTP. > All the other above examples have already been defined so I don't see we > gain anything by trying to label them as a sub-protocol etc. > >> >> If we wanted to define use of RTP over a data channel, what >> sub-protocol(s) would we have to define? I *think* we would have to >> define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted >> to support over a data channel. > [CNG] Yes I would agree. >> >> And then how would we do it, and where would we specify which >> attributes could be used with dcsa? Would we have to update the >> documents that define those attributes? > [CNG] I assume we'd follow the example of > draft-ietf-mmusic-msrp-usage-data-channel. It discusses the use of > existing attributes. I don't see that RTP would need to do anything > different. > >> >> ISTM there are similar (though not so complex) issues for pretty much >> any attribute that we might want to reuse over a data channel. > [CNG] Some will be complex, some will be a no brainer. What > draft-ietf-mmusic-data-channel-sdpneg provides is a syntax for re-using > attributes. It doesn't provide semantics for every attribute. > Implementors need to understand that some attributes have been defined > with a particular protocol stack in mind and that they the behaviour may > need to be modified when using a data channel. >> >> Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, >> RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the >> websocket/datachannel registry. And then that document might say that >> any sdp attribute designed to be used with protos */(each of these >> subprotocols) may also be used in dcsa for a channel using these >> protocols. > [CNG] Yes it "could" be, if someone actually wanted to carry RTP over a > data channel. That would follow with what is being done for MSRP and > BFCP. I don't see RTP as being any different. >> >> Thanks, >> Paul >> >>> Thanks, >>> Juergen >>> >>> >>> On 25.02.2016 22:38, EXT Paul Kyzivat wrote: >>>> On 2/24/16 7:24 PM, Christian Groves wrote: >>>>> Hello Juergen and Paul, >>>>> >>>>> Please see at end. >>>>> >>>>> Regards, Christian >>>>> >>>>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>>>>> ..snip.. >>>>>>> >>>>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>>>>> >>>>>>>>> Have just submitted version 08 of >>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>>>>> The changes compared to version 07 are essentially as follows. >>>>>>>>> >>>>>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>>>>> regarding the >>>>>>>>> relationship of subprotocols and their attributes. >>>>>>>>> * Two new SDP offer/answer considerations in section 5.2.5 >>>>>>>>> (Various >>>>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>>>>>> channel transport specific semantic is not known. >>>>>>>>> * A new paragraph in section 8.1 (IANA Considerations / >>>>>>>>> Subprotocol >>>>>>>>> Identifiers) related to cases, where a subprotocol is defined for >>>>>>>>> data >>>>>>>>> channel and Websocket transport. >>>>>>>>> >>>>>>>>> These changes should address the points discussed in this email >>>>>>>>> thread. >>>>>>>> >>>>>>>> This is an improvement. But I think things could still be made >>>>>>>> clearer. >>>>>>>> >>>>>>>> Consider the following addition to 5.1.2.1: >>>>>>>> >>>>>>>> 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. A data channel >>>>>>>> specific usage of a subprotocol attribute is expected to be >>>>>>>> specified >>>>>>>> in the same document, which registers the subprotocol's >>>>>>>> identifier >>>>>>>> for data channel usage as described in Section 8.1. >>>>>>>> >>>>>>>> This text makes sense when there is a clear distinction between >>>>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved >>>>>>>> there >>>>>>>> is no such clear distinction in many cases, such as RTP over UDP or >>>>>>>> TCP, etc. Those are combined into a single protocol value. While >>>>>>>> that >>>>>>>> can usually be parsed apart at slashes, there isn't good >>>>>>>> terminology >>>>>>>> for it. >>>>>>>> >>>>>>>> My point is that when I read the above, I don't know how it applies >>>>>>>> to, say, RTP attributes. Or does it only apply for attributes that >>>>>>>> are >>>>>>>> clearly defined for a *sub*protocol? >>>>>>>> >>>>>>>> I think this is primarily that we lack well defined vocabulary for >>>>>>>> all >>>>>>>> of this. But I think it would be too much to expect this draft to >>>>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it >>>>>>>> would be >>>>>>>> sufficient to give some concrete examples, even if they have to be >>>>>>>> hypothetical ones. >>>>>>> >>>>>>> [Juergen] Agree that it would be helpful to have more precise >>>>>>> definitions of the differences of the terms protocol and >>>>>>> subprotocol, >>>>>>> especially when those terms are used outside the scope of data >>>>>>> channels >>>>>>> (or Websockets). When only focusing on data channels the notion of a >>>>>>> "subprotocol" seems to be clearer - at least >>>>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" >>>>>>> parameter. >>>>>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>>>>> informally starts using the term "subprotocol" in the >>>>>>> introduction and >>>>>>> there refers to Websocket "subprotocols". Perhaps we should add the >>>>>>> term >>>>>>> "subprotocol" to the list of used terminology in section 3. >>>>>>> >>>>>>> The sdpneg document, together with the data channel subprotocol >>>>>>> specific >>>>>>> document (which defines the value of the a=dcmap attribute's >>>>>>> "subprotocol" parameter), should certainly give clear guidance on >>>>>>> how to >>>>>>> interpret SDP offers or answers like e.g.: >>>>>>> >>>>>>> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >>>>>>> c=IN IP4 10.10.10.1 >>>>>>> a=max-message-size:100000 >>>>>>> a=sctp-port:5000 >>>>>>> ... >>>>>>> a=dcmap:0 subprotocol="MSRP" >>>>>>> a=dcsa:0 accept-types:message/cpim text/plain >>>>>>> a=dcsa:0 framerate:... >>>>>>> a=dcsa:0 lang:... >>>>>>> >>>>>>> An implementation receiving such an offer would need to decide >>>>>>> what to >>>>>>> do with the dcsa embedded framerate and lang attributes. Or, someone >>>>>>> implementing MSRP over data channel based services may need to >>>>>>> decide >>>>>>> whether or not to use these attributes, and if yes, how. >>>>>>> (I am using these two attributes just as hypothetical examples - >>>>>>> don't >>>>>>> want to suggest that those may indeed be used for MSRP over data >>>>>>> channel >>>>>>> transport). >>>>>>> >>>>>>> The msrp-usage-data-channel document doesn't mention these two >>>>>>> attributes. When looking at the IANA SDP attribute registry >>>>>>> tables, I >>>>>>> would find both attributes specified in RFC 4566. There, >>>>>>> "framerate" is >>>>>>> explicitly said to be defined only "for video media". Just to be >>>>>>> sure I >>>>>>> could additionally have a look at the MSRP specifying documents, RFC >>>>>>> 4975 and RFC 4976, but there would not find any text at all >>>>>>> related to >>>>>>> "framerate". So this case seems pretty clear and I would therefore >>>>>>> conclude that the "framerate" attribute should not be used for >>>>>>> MSRP, and >>>>>>> that a receiver of such an offer or answer should ignore it. >>>>>>> >>>>>>> When looking at the definition of the "lang" attribute in RFC 4566 I >>>>>>> would not see any explicit hint of what protocols this attribute >>>>>>> might >>>>>>> be used with, especially if "lang" could be used when negotiating an >>>>>>> MSRP session. When then looking at RFC 4975 I would indeed find >>>>>>> "lang" - >>>>>>> but not as SDP attribute, rather as XML tag parameter within an >>>>>>> example >>>>>>> MSRP message payload. Thus, the case of the "lang" attribute >>>>>>> might not >>>>>>> be as unambiguous as the one with the "framerate" attribute, but >>>>>>> here >>>>>>> too I think the typical choice would be to ignore that attribute >>>>>>> when >>>>>>> receiving such an offer or answer. >>>>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>>>>> sdpneg-08 may also be applied in these cases. >>>>>>> >>>>>>> Admittedly, these examples may seem a bit far-fetched, but would >>>>>>> those >>>>>>> go into the direction you had in mind? >>>>>> >>>>>> Yes. Note that using examples is just me grasping at straws, since a >>>>>> real solution looks like to big a problem for this draft to tackle by >>>>>> itself. I am entirely open to other ideas for how to deal with this. >>>>> [CNG] I don't see what the example buys? I don't see that the >>>>> behaviour >>>>> is any different between using additional attributes in the >>>>> datachannel >>>>> vs. the non data channel case. E.g. for >>>>> >>>>> c=IN IP4 10.10.10.1 >>>>> m=message 7394 TCP/MSRP * >>>>> a=accept-types:message/cpim text/plain text/html >>>>> a=lang:.... >>>>> a=framerate:... >>>>> The ignore behaviour would be the same. >>>>> In the above example the attributes are scoped by the m= line. In the >>>>> data channel case the attributes are scoped by the relevant a=dcmap: >>>>> line. >>>> >>>> My concern is that SDP has no notion of subprotocol, even though in >>>> practice it shows up lots of places. It only has a notion of the >>>> protocol field in the m-line. Beyond that a *convention* has developed >>>> to denote a layering within the protocol through use of "/". AFAIK >>>> this isn't formally written down anywhere. >>>> >>>> So, in principle we could define an RTP sub-protocol for use over a >>>> data channel. And then we could talk about using the attributes that >>>> apply to RTP in dcsa for a channel using RTP. But note there is no >>>> formal definition of the *protocol*s where RTP attributes are relevant. >>>> >>>> A lot of the very old stuff was just sloppy. To be fair, it was >>>> probably good enough for the cases in front of them at the time, and >>>> they weren't yet in a position to foresee how things would evolve. It >>>> is just another example of how old stuff rots and has to be refreshed >>>> from time to time. >>>> >>>> But I don't think *this* draft is the place to fix it. So, in lieu of >>>> doing that I'm just looking for some way to clarify things. >>>> >>>> Thanks, >>>> Paul >>>> >>> >>> >>> _______________________________________________ >>> 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 Mon Feb 29 07:28:41 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 0D5451B33D5 for ; Mon, 29 Feb 2016 07:28:40 -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 k4bae3GLj3Fq for ; Mon, 29 Feb 2016 07:28:38 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916571B33D3 for ; Mon, 29 Feb 2016 07:28:38 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-08v.sys.comcast.net with comcast id QFTx1s009516pyw01FUdoJ; Mon, 29 Feb 2016 15:28:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-08v.sys.comcast.net with comcast id QFUc1s00P3KdFy101FUde7; Mon, 29 Feb 2016 15:28:37 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56D463A3.8070007@alum.mit.edu> Date: Mon, 29 Feb 2016 10:28:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4BD38@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=1456759717; bh=ngJXOmhBAWERI6dZMzjRZshsURKdcpd6rdByJm7FhPc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Rqq7CvYf6BqoELMecbqR6DhUBR77b85EPajqkugw4eyO4I/y/v4m39CmAsAaDBmC0 qbU9GpqGwSi7X2D+11eLN0qt8v1dBv1JcIvSX0NGeK++4GexVKFJbQiasRiEAo8hAy qIMjzKhZYdQkFQPYhllBlW7rjX7firqGzBResNnH4bHfXMcUvdpiYgkaYVP9f2t3sa tAXfJ8XmiPLLCqhD1iDqBVhR7yCc/UP6p3bfdOeG2d5LToAyMDI0IJednCNdx4+cba tEAeF8UoOJLFaLvQ7OOzcBhN+v0u1KKRQ8DgQZdRkwdWsykiI9Y4UiudI9FzLtgz++ +EDTUA99eGa6w== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 15:28:40 -0000 On 2/29/16 8:28 AM, Christer Holmberg wrote: > Hi, > > SDP Offer/Answer causes lots of problem. When I read all this it seems > like we want to complicate things which very likely will cause any > more problems. > > Two endpoints use SDP Offer/Answer to negotiate an SDP session. Cant > we try to define what rules apply within that SDP session? Why do we > have to talk about RTP sessions etc? I've been trying to understand this since I first started working on sip (in 2002). I'm *finally* starting to understand some of the motivations for the words in 3264. Unfortunately those words fell far short of covering the concerns. I agree that 3264 seems to have a notion of an "SDP session", that is different from an RTP session. But when using RTP a consequence is that RTP sessions are being established and updated. Those do have rules of their own. It is presumably as hard or harder to change those as it is to change the O/A rules. While 3264 phrases its PT rules in the context of an SDP session, they are pretty much scoped to an RTP session. (There is no interaction between the PTs of different m-lines.) AFAICT the only thing considering the SDP session can bring to this is to impose a rule that the PT bindings be retained for an m-line even when the RTP session for that m-line changes. I can see no downside in removing that restriction. Thanks, Paul > Regards, > > Christer > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 29. helmikuuta 2016 7:30 > *To:* Paul Kyzivat > *Cc:* Christer Holmberg; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Offer/Answer PT Questions - text proposal > > On Sat, Feb 27, 2016 at 11:10 AM, Paul Kyzivat > wrote: > > On 2/27/16 4:29 AM, Roman Shpount wrote: > > One potential solution is to generate any offer in such a way that it > will be compatible with all the completed O/A exchanges for this end > point. If an end point receives an offer which is not compatible with > existing state, i.e. an offer which is reusing one of the PT for a > different codec profile similar, this end point must allocate new > transport (use new local address/port or new local set of candidates in > case of ICE) for the answer and consider this a start of the new session > (discard all the PT use history). If new transport cannot be allocated, > for instance if responding to an offer with ICE and existing ufrag, then > offer must be refused with 488 or m line with port 0. This way end point > can always uniquely map the PT to the codec profile based on PT and > local transport where the packet is received. In case of 3pcc, an end > point might get an offer which is incompatible with its PT use history; > allocate new local transport, and handle it as a new RTP session. > > What do you think? > > > While there are probably a lot of details to work out, I like it as > the outline of a direction to pursue. > > It could get complicated for a focus. It might require the focus to > change mixing policies for the offending participant. > > PT collisions are already a quite complicated for the conference focus. > Conference focus needs to deal with situations when multiple inbound > callers (in case of meet-me conference) use the same PT in incompatible > way. When outbound calls are placed from the focus, end points can add > PT to the answer which can also produce PT collisions. With my proposal > these collisions can be resolved using a re-INVITE from the focus which > will force new RTP sessions to be created on the clients. > > From implementation experience PT collisions do not present a real > problem in practice. All practical implementations of RTP mux that I had > dealt with either worked with specially pre-provisioned end points which > all used the same PT for the same codec profiles or conference focus > implemented PT re-mapping on each of the call legs. > > Regards, > > _____________ > Roman Shpount > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Feb 29 08:05: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 012E31B350B for ; Mon, 29 Feb 2016 08:05:39 -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 eLP2We55OqhN for ; Mon, 29 Feb 2016 08:05:38 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122BF1B3508 for ; Mon, 29 Feb 2016 08:05:37 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-03v.sys.comcast.net with comcast id QG4t1s00C4tLnxL01G5dBl; Mon, 29 Feb 2016 16:05:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-02v.sys.comcast.net with comcast id QG5c1s00R3KdFy101G5c02; Mon, 29 Feb 2016 16:05:37 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37E45EA2@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56D46C50.9060601@alum.mit.edu> Date: Mon, 29 Feb 2016 11:05:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E45EA2@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=1456761937; bh=nU9Kb1SJq8Jf9HA3HJi5df3q9hbxp/c8tJTahn2uEJk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BRtLoAr76wQDTT9I6SZln/KrZ1YZFkCYyvss74irmsmNuH4wTw53YgARVH3tu7wpN XrFGqmcViY+wOZRujiImEpf2wLFPO+fEPm93vS7No0hNIOaY7mXSFpDTpZWIWgqp/g cQKHDKsaVL8HJ1qnKL2EusCR9EGxBmYzhe72mPI9JIHNLJz9iJK+tVEyHymE4mO2r2 M87htxxg56pSoBIMlXRKsUiP9oVd23s62oC7XdqdLG/3uROLbQ2mk8QwXEWF8WdRES zJWbv+HeHN2+rKE1PoPxU1fxm/6eKSavCjwp4olVF0MsYtVP6enWMXt0cUhUqG+nXJ CtV+HfavBsCow== Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09 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, 29 Feb 2016 16:05:39 -0000 This is better. A couple of things about this one: In section 5.1: The certificate received during the DTLS handshake MUST match a fingerprint received in an SDP "fingerprint" attribute. If a fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects. IIUC, when there are multiple fingerprints the intent is that there will be multiple certificates, each matching one of the fingerprints. And that the point of this is that the recipient be able to deal with at least one of them, not that the recipient must verify all of them. (Do I have that right?) If so, I don't think the text above is consistent with that. I think it should probably say: One of the certificates received during the DTLS handshake MUST match one of the fingerprints received in an SDP "fingerprint" attribute. If not, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprints have been received before establishing the connection; however, this may have undesirable latency effects. If the above is true, then it is possible that adding/changing a fingerprint might not require establishing a new DTLS association. If the association had been established based on a fingerprint that remains, then it doesn't matter what happens to the other fingerprints. I don't have a clear understanding of if/how that might change the text. And I don't see a reason why anybody would do that. Thanks, Paul From nobody Mon Feb 29 08:37: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 319661B372E for ; Mon, 29 Feb 2016 08:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.664 X-Spam-Level: ** X-Spam-Status: No, score=2.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FB_CIALIS_LEO3=3.899, 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 G-rE4xmHjfIS for ; Mon, 29 Feb 2016 08:37:15 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43601A1B66 for ; Mon, 29 Feb 2016 08:37:14 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-11v.sys.comcast.net with comcast id QGcC1s0032N9P4d01GdEx3; Mon, 29 Feb 2016 16:37:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id QGdD1s00f3KdFy101GdD66; Mon, 29 Feb 2016 16:37:14 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37E4B61C@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56D473B8.3050902@alum.mit.edu> Date: Mon, 29 Feb 2016 11:37:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4B61C@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=1456763834; bh=QiKBfEE0AVZQ/AgbnuncLnu1ysRVvHZhOENLE2+TtiE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SEPBpuq+x0P/EmhwnVc0bV3dRALDTcQtlvN3OkJelN348GurAYXf3XjVuJU39BX8n BaMGtfe+xSBCYG7D/eBTIFovjdgRENWf4dMfqOog6zD0l28pFWy6H8CZrd8Ei69CEt VHkxpXiftJrc2IWwIRE6ROZKhUjTckaSUNSbx6grm09Q+4JYhNZzoY0LP6+9k2vMcy L07+hHISuIwhCbNBA/o6xYz1lyUs18Hy/3m9QB/sjIy5cOiEbTBHLbqfOY4U1Y2xXl +uGCq1OgnMezLRJc82hZ677mIUrrw7bDqVOL8f1hev0rImhmLf3NE1Th/8nx7ho6G3 EOn09JqXOi0UA== Archived-At: Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-4572-update 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, 29 Feb 2016 16:37:16 -0000 Christer, On 2/29/16 4:36 AM, Christer Holmberg wrote: > Hi, > > I submitted a new draft, draft-holmberg-mmusic-4572-update. The purpose > is for making the 4572 updates we have been discussing: usage of > multiple fingerprint attributes, and updating the preferred cipher suite. > > The cipher suite update should not be a big issue, but feel free to > suggest text regarding the fingerprint attribute. Section 3 starts with "This section updates section 5 of RF 4572". But then just before the old text is: "Update to section 8.3.2"! What is that about? (In the html it is linked to a non-existent section in *this* draft. And there is also no section 8.3.2 in 4572.) Clearly is is really section 5 that is being changed. But showing the change this way with old/new versions of the entire section makes it very difficult to see what the actual change is. I had to use it to create a temporary update to 4572 text and run diff on it to find that the actual change was simply: s/'SHA-1' preferred/'SHA-256' preferred/ Can you do something to make that clearer? (E.g., reduce the old and new parts to just the affected paragraph, and also verbally describe what has been changed.) After doing the diff, I find no text discussing the semantics of multiple fingerprint attributes. What am I missing? Are you waiting for somebody else to propose the semantics? (I want to hear from somebody that has asked for this feature.) Thanks, Paul From nobody Mon Feb 29 10:40: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 706B01A892B for ; Mon, 29 Feb 2016 10:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 Wy4ceq2giB2c for ; Mon, 29 Feb 2016 10:40:47 -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 4A21A1B3980 for ; Mon, 29 Feb 2016 10:40:47 -0800 (PST) X-AuditID: c1b4fb30-f79096d000002f68-e6-56d490ad967b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0E.47.12136.DA094D65; Mon, 29 Feb 2016 19:40:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 19:40:44 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-4572-update Thread-Index: AdFy1FBcjXYj62IYQle5pMOTuSLOpAAMr5kAAAZo6l0= Date: Mon, 29 Feb 2016 18:40:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4D3D0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E4B61C@ESESSMB209.ericsson.se>, <56D473B8.3050902@alum.mit.edu> In-Reply-To: <56D473B8.3050902@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E4D3D0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdRXfthCthBlcXKFtMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG9dn3mAtuGFasOtbB2MDYrtXFyMkhIWAi seLTG0YIW0ziwr31bF2MXBxCAocZJQ5s/8IK4SxmlJj78T5zFyMHB5uAhUT3P22QBhEBX4ln j2+zgdjCAk4S05/+ZYSIO0ssP98HZVtJLOlfzAJiswioSjxq28AEMoYXqPfN79ouRnag8bkS 7REgBZwCOhKn3h0Ca2QEuub7qTVMIDazgLhE05eVrBBXCkgs2XOeGcIWlXj5+B8rRE2+xM73 M8HqeQUEJU7OfMIygVF4FpL2WUjKZiEpg4gbSHx5fxvK1pZYtvA1M4StL9H9/jQTsvgCRvZV jKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIGRc3DLb4MdjC+fOx5iFOBgVOLh3eB8OUyINbGs uDL3EKMEB7OSCK9C+5UwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rysn4CqBdITS1KzU1MLUotg skwcnFINjPq/nja1vNQ6YGgpOi/5stucY4x9rww5Dopz32HepKkXdMNp4oofankLP1ievf7x 5IuVMj3GWzh+xOkmi1hqH7dpMNZK2J3yX8Sl2SBXP2xqRfrU+f7iyYzG/3bd+3bvaQqXbNjd qFda3JfZ1325abnioLxms9y5cy2zfsotW3XTV+VYlqXqXyWW4oxEQy3mouJEABGuE++YAgAA Archived-At: Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-4572-update 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, 29 Feb 2016 18:40:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E4D3D0ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Paul, The reference to section 8.3.2 doesn't belong there. I used another XML fil= e as template, and forgot to change it. Regarding the fingerprint attribute - there is no new text yet. I am asking= people to suggest text :) Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD29/=FD02/=FD2016 18:37 To: mmusic@ietf.org Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-4572-update Christer, On 2/29/16 4:36 AM, Christer Holmberg wrote: > Hi, > > I submitted a new draft, draft-holmberg-mmusic-4572-update. The purpose > is for making the 4572 updates we have been discussing: usage of > multiple =91fingerprint=92 attributes, and updating the preferred cipher = suite. > > The cipher suite update should not be a big issue, but feel free to > suggest text regarding the =91fingerprint=92 attribute. Section 3 starts with "This section updates section 5 of RF 4572". But then just before the old text is: "Update to section 8.3.2"! What is that about? (In the html it is linked to a non-existent section in *this* draft. And there is also no section 8.3.2 in 4572.) Clearly is is really section 5 that is being changed. But showing the change this way with old/new versions of the entire section makes it very difficult to see what the actual change is. I had to use it to create a temporary update to 4572 text and run diff on it to find that the actual change was simply: s/'SHA-1' preferred/'SHA-256' preferred/ Can you do something to make that clearer? (E.g., reduce the old and new parts to just the affected paragraph, and also verbally describe what has been changed.) After doing the diff, I find no text discussing the semantics of multiple fingerprint attributes. What am I missing? Are you waiting for somebody else to propose the semantics? (I want to hear from somebody that has asked for this feature.) Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B37E4D3D0ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Paul,

The reference to section 8.3.2 doesn't belong there. I used another XML fil= e as template, and forgot to change it.

Regarding the fingerprint attribute - there is no new text yet. I am asking= people to suggest text :)

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD29= /=FD02/=FD2016 18:37
To: mmusic@ietf.org
Subject: Re: [= MMUSIC] Draft new: draft-holmberg-mmusic-4572-update

Christer,

On 2/29/16 4:36 AM, Christer Holmberg wrote:
> Hi,
>
> I submitted a new draft, draft-holmberg-mmusic-4572-update. The purpos= e
> is for making the 4572 updates we have been discussing: usage of
> multiple =91fingerprint=92 attributes, and updating the preferred ciph= er suite.
>
> The cipher suite update should not be a big issue, but feel free to > suggest text regarding the =91fingerprint=92 attribute.

Section 3 starts with "This section updates section 5 of RF 4572"= . But
then just before the old text is: "Update to section 8.3.2"! What= is
that about? (In the html it is linked to a non-existent section in
*this* draft. And there is also no section 8.3.2 in 4572.)

Clearly is is really section 5 that is being changed. But showing the
change this way with old/new versions of the entire section makes it
very difficult to see what the actual change is. I had to use it to
create a temporary update to 4572 text and run diff on it to find that
the actual change was simply:

s/'SHA-1' preferred/'SHA-256' preferred/

Can you do something to make that clearer? (E.g., reduce the old and new parts to just the affected paragraph, and also verbally describe what
has been changed.)

After doing the diff, I find no text discussing the semantics of
multiple fingerprint attributes. What am I missing? Are you waiting for somebody else to propose the semantics? (I want to hear from somebody
that has asked for this feature.)

     Thanks,
     Paul


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B37E4D3D0ESESSMB209erics_-- From nobody Mon Feb 29 11:07: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 D9C881B3A34 for ; Mon, 29 Feb 2016 11:07:41 -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 5NG3ynV4r8-Y for ; Mon, 29 Feb 2016 11:07:38 -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 88AEC1B3A38 for ; Mon, 29 Feb 2016 11:07:38 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-a6-56d496f8debd Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C4.62.20792.8F694D65; Mon, 29 Feb 2016 20:07:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 20:07:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-4572-update Thread-Index: AdFy1FBcjXYj62IYQle5pMOTuSLOpAAMr5kAAAc/zFA= Date: Mon, 29 Feb 2016 19:07:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4D502@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E4B61C@ESESSMB209.ericsson.se> <56D473B8.3050902@alum.mit.edu> In-Reply-To: <56D473B8.3050902@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2J7oO6PaVfCDJbdNbKYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MHW3FBU/ZKt7PXMjWwLiUtYuRk0NCwERi /bmZbBC2mMSFe+uBbC4OIYHDjBLbvv4AKxISWMwoMWeZbBcjBwebgIVE9z9tkLCIgK/Es8e3 wXqFBZwkpj/9ywgRd5ZYfr4PyraS+DplLhOIzSKgKvHnz2kWEJsXqPfSxyMsEOPzJRqOXWYG sTkFdCROvTsE1ssIdM/3U2vAepkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/0H9oiTRuOQJK0S9 jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnp pRZlJhcX5+fp5aWWbGIExsjBLb+tdjAefO54iFGAg1GJh3eD8+UwIdbEsuLK3EOMEhzMSiK8 Cu1XwoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzsn0CqhZITyxJzU5NLUgtgskycXBKNTDWeM7S kVHQWyJeHmI+d2+kqJ2/uz9726aF/9+2hDWweJSFnT7do1f+SXUl44HdzWJHHsrvZb78S8rc Viuk6eeHt2sX8BubqXOHm+/6N8fOnoXp4NKnslfnu8/8nSL34t6rY6pGSqfjmS+ueJyVly1V FXx6VuG3O6veGfwr8rMpT7Z6bzWpuViJpTgj0VCLuag4EQBKzuBIjQIAAA== Archived-At: Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-4572-update 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, 29 Feb 2016 19:07:42 -0000 Hi, ... > s/'SHA-1' preferred/'SHA-256' preferred/ > > Can you do something to make that clearer? (E.g., reduce the old and new = parts to just the affected paragraph, and also verbally describe what has b= een changed.) If that's the ONLY change, I agree it should be done that way. But, I assume the fingerprint changes will be done in the same section, so = let's first work on the changes and then we see how we document them. > After doing the diff, I find no text discussing the semantics of multiple= fingerprint attributes. What am I missing? Are you waiting for somebody el= se to propose the semantics?=20 Yes. > (I want to hear from somebody that has asked for this feature.) Martin mentioned the draft he had been working with. I understood you had l= ooked at it, but did not find the semantics? Regards, Christer From nobody Mon Feb 29 11:18: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 DE1A71B3A4B for ; Mon, 29 Feb 2016 11:18:31 -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 hHq02CxUKoEd for ; Mon, 29 Feb 2016 11:18: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 905331B3835 for ; Mon, 29 Feb 2016 11:18:29 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-cc-56d49982701c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.0A.25494.28994D65; Mon, 29 Feb 2016 20:18:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 20:18:25 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wARGIiAAAEzHQAAFHhLgAANDP0AAABf9wAAANkcgAABPnAAAACT0gAAARuRgAAArliAACAJAYAADgPBAABONv0AABK4WIAAAjCagAAJzjpQ Date: Mon, 29 Feb 2016 19:18:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> In-Reply-To: <56D463A3.8070007@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7lG7zzCthBkv3CFpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGo6XTWQreq1a8nHGBpYHxsWwXIyeHhICJ xN+9vYwQtpjEhXvr2boYuTiEBA4zSjxa+4YRwlnMKDHj3xfWLkYODjYBC4nuf9ogDSICvhLP Ht9mA7GFBewlpj97zAQRd5C4vfUXO0iviMA0RolVD+azgiRYBFQlTkyYBNbAC9T8dMVSqAX7 2CS2PP/DBrKAU0BHYtFNPZAaRqCLvp9aAzaUWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4St JNG45AkrRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoW pxYX56YbGeulFmUmFxfn5+nlpZZsYgRGysEtv3V3MK5+7XiIUYCDUYmHd4Pz5TAh1sSy4src Q4wSHMxKIrwK7VfChHhTEiurUovy44tKc1KLDzFKc7AoifOyfQKqFkhPLEnNTk0tSC2CyTJx cEo1MPoZ5uz0bbqs+bwhTLbug9eblQkvJtxfdKWO6bbjZI+81N/bntY43bdk1ma6wLOtSM14 5Uk3LauTxTsl386u8yhnvaqnUKkhs+DsQ6sV/KouhgEVQf8KPb9MCq5Otkme4SL7f/556669 SmKT7wTsf9S3NW5bl7VFk+wusZuCDxjOLt8gwXNuthJLcUaioRZzUXEiAN8cXeqQAgAA Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 19:18:32 -0000 Hi, >> SDP Offer/Answer causes lots of problem. When I read all this it seems=20 >> like we want to complicate things - which very likely will cause any=20 >> more problems. >> >> Two endpoints use SDP Offer/Answer to negotiate an "SDP session".=20 >> Can't we try to define what rules apply within that "SDP session"? Why=20 >> do we have to talk about RTP sessions etc? > > I've been trying to understand this since I first started working on sip = (in 2002). I'm *finally* starting to=20 > understand some of the motivations for the words in 3264. Unfortunately t= hose words fell far short of covering the concerns. > > I agree that 3264 seems to have a notion of an "SDP session", that is dif= ferent from an RTP session. > > But when using RTP a consequence is that RTP sessions are being establish= ed and updated. Those do have rules of=20 > their own. It is presumably as hard or harder to change those as it is to= change the O/A rules. > > While 3264 phrases its PT rules in the context of an SDP session, they ar= e pretty much scoped to an RTP session.=20 >(There is no interaction between the PTs of different m-lines.) AFAICT the= only thing considering the SDP session=20 > can bring to this is to impose a rule that the PT bindings be retained fo= r an m-line even when the RTP session for=20 > that m-line changes. I can see no downside in removing that restriction. Unless there is RTP session rules saying that the PT bindings must change i= n case of a new RTP session (within a given SDP session), I see no reason w= hy we should introduce such rules within an SDP session. (There may of course be other reasons why a new RTP session requires an O/A= transaction, and maybe we need to describe that, but that is a separate is= sue) Regards, Christer > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 29. helmikuuta 2016 7:30 > *To:* Paul Kyzivat > *Cc:* Christer Holmberg; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Offer/Answer PT Questions - text proposal > > On Sat, Feb 27, 2016 at 11:10 AM, Paul Kyzivat > wrote: > > On 2/27/16 4:29 AM, Roman Shpount wrote: > > One potential solution is to generate any offer in such a way that it > will be compatible with all the completed O/A exchanges for this end > point. If an end point receives an offer which is not compatible with > existing state, i.e. an offer which is reusing one of the PT for a > different codec profile similar, this end point must allocate new > transport (use new local address/port or new local set of candidates = in > case of ICE) for the answer and consider this a start of the new sess= ion > (discard all the PT use history). If new transport cannot be allocate= d, > for instance if responding to an offer with ICE and existing ufrag, t= hen > offer must be refused with 488 or m line with port 0. This way end po= int > can always uniquely map the PT to the codec profile based on PT and > local transport where the packet is received. In case of 3pcc, an end > point might get an offer which is incompatible with its PT use histor= y; > allocate new local transport, and handle it as a new RTP session. > > What do you think? > > > While there are probably a lot of details to work out, I like it as > the outline of a direction to pursue. > > It could get complicated for a focus. It might require the focus to > change mixing policies for the offending participant. > > PT collisions are already a quite complicated for the conference focus. > Conference focus needs to deal with situations when multiple inbound=20 > callers (in case of meet-me conference) use the same PT in=20 > incompatible way. When outbound calls are placed from the focus, end=20 > points can add PT to the answer which can also produce PT collisions.=20 > With my proposal these collisions can be resolved using a re-INVITE=20 > from the focus which will force new RTP sessions to be created on the cli= ents. > > From implementation experience PT collisions do not present a real=20 > problem in practice. All practical implementations of RTP mux that I=20 > had dealt with either worked with specially pre-provisioned end points=20 > which all used the same PT for the same codec profiles or conference=20 > focus implemented PT re-mapping on each of the call legs. > > Regards, > > _____________ > Roman Shpount > > > > _______________________________________________ > 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 Feb 29 11:33: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 AC8B01B3A73; Mon, 29 Feb 2016 11:33:43 -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 pJ7EpPNOwxvX; Mon, 29 Feb 2016 11:33:42 -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 D8E051B3A82; Mon, 29 Feb 2016 11:33:30 -0800 (PST) X-AuditID: c1b4fb30-f79096d000002f68-93-56d49d0896e6 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AA.2B.12136.80D94D65; Mon, 29 Feb 2016 20:33:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 20:33:19 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-dtls-sdp-09 Thread-Index: AdFwZztYg0twwL1AR4qDbJGareGECwCm2lMAAAkS0nA= Date: Mon, 29 Feb 2016 19:33:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4D6D5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E45EA2@ESESSMB209.ericsson.se> <56D46C50.9060601@alum.mit.edu> In-Reply-To: <56D46C50.9060601@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7ty7n3CthBidnsFtcO/OP0eL8zvVM FlOXP2axWLHhAKsDi8ff9x+YPHbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujL2/WAv6BStm LJ/K3MC4hbeLkZNDQsBE4tXix0wQtpjEhXvr2boYuTiEBA4zSuzu2cQGkhASWMwosWVfahcj BwebgIVE9z9tkLCIgK/Es8e3wUqYBeolPk3dyAJiCwvYSkxvamWCqLGTWPT+IpRtJfFzxkR2 EJtFQFXi0oo7YDYv0JxTi1awQ6zKl/i/8hQjiM0poCOx7NMqsJmMQLd9P7WGCWKXuMStJ/Oh bhaQWLLnPDOELSrx8vE/VghbSaJxyRNWiHodiQW7P0HdqS2xbOFrZoi9ghInZz5hmcAoNgvJ 2FlIWmYhaZmFpGUBI8sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMDIOrjlt8EOxpfPHQ8x CnAwKvHwbnC+HCbEmlhWXJl7iFGCg1lJhFeh/UqYEG9KYmVValF+fFFpTmrxIUZpDhYlcV7W T0DVAumJJanZqakFqUUwWSYOTqkGxtJrygY+SQ1TPn1abOb9I+RWiPKyPv5nB5Vn/t9f0/cw 4z+fWoBrZUzi7dj5HBu2FBzWWhHysaeGS3+/9tfz8YcCp8bsTng08/KP6vkst482mTd++Bvb pZzt2d1kX3IysE1U+eP+93serrGLvLrMeJFrgVbN5hlCvVvjp2pZ2WbMd5m9h9szVomlOCPR UIu5qDgRALOD96uoAgAA Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09 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, 29 Feb 2016 19:33:43 -0000 Hi Paul, >This is better. A couple of things about this one: > >In section 5.1: > > The certificate received during the DTLS handshake MUST match a > fingerprint received in an SDP "fingerprint" attribute. If a > fingerprint does not match the hashed certificate, then the endpoint > MUST tear down the media session immediately. Note that it is > permissible to wait until the other side's fingerprint has been > received before establishing the connection; however, this may have > undesirable latency effects. > > IIUC, when there are multiple fingerprints the intent is that there will = be multiple certificates, each=20 > matching one of the fingerprints. And that the point of this is that the = recipient be able to deal with=20 > at least one of them, not that the recipient must verify all of them. > > (Do I have that right?) > > If so, I don't think the text above is consistent with that. I think it s= hould probably say: > > One of the certificates received during the DTLS handshake MUST > match one of the fingerprints received in an SDP "fingerprint" > attribute. If not, then the endpoint MUST tear down the media > session immediately. Note that it is permissible to wait until > the other side's fingerprints have been received before establishing > the connection; however, this may have undesirable latency effects. > > If the above is true, then it is possible that adding/changing a fingerpr= int might not require establishing a=20 > new DTLS association. If the association had been established based on a = fingerprint that remains, then it=20 > doesn't matter what happens to the other fingerprints. MAYBE (there are others that know this better than me) there are cases wher= e a new DTLS association would not be required, but I think we should have = consistent rules. And, as far as I know, it is quite unlikely that there will be any fingerpr= int changes within a session to begin with, so I don't think we are going t= o end up in a situation with lots of DTLS associations being re-established= even if there may not be a need for it. Regards, Christer From nobody Mon Feb 29 12:41:37 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 96ED91B3B9C; Mon, 29 Feb 2016 12:37:12 -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.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160229203712.19855.71359.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 12:37:12 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-16.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, 29 Feb 2016 20:37:13 -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 of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) Authors : Christer Holmberg Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-16.txt Pages : 24 Date : 2016-02-29 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 29 13:02: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 766C01B3C05 for ; Mon, 29 Feb 2016 13:02:45 -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 B_OgXXjjnZRw for ; Mon, 29 Feb 2016 13:02:44 -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 283D11B3C04 for ; Mon, 29 Feb 2016 13:02:44 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with comcast id QLyw1s0032Bo0NV01M2jNM; Mon, 29 Feb 2016 21:02:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id QM2j1s0013KdFy101M2jp3; Mon, 29 Feb 2016 21:02:43 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56D4B1F1.2070706@alum.mit.edu> Date: Mon, 29 Feb 2016 16:02:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4D5E9@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=1456779763; bh=Zm/XE931iYkgQI0+ee1a47Z+uduvSrsEcXgAT9nnLZQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WD+MG4S4oY36+Z5jw+WqGPmdJ6rqgKoWkPoVl5qHxAsi9dQjnVY44hHWUtMmyj5Bx J/jZitZvDOHDklOXHt3u/nKb0gT6qmAbiaeyro2sh9gdZV9ur4JD8TBkgyT1BNNETs QYN/0ndQ9faCs7HmqrMExY/LYEH+EEI24ngLqv8otb0YoViCKRDUw9CMlI1DQhdeFS aTdrIsV5MMC2WAaSZotbJKjuoFJDXuffB54ZxusrWFRW054B2gvFFVv+V/dHCs7weP tjNRPWG1zxAFFRkde/xRkGCDnjR4Oo0lQclIcQk7o+G24aN6t4ucYx4OWxnR5FSd2J CHz8ezoZZSm0A== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 21:02:45 -0000 On 2/29/16 2:18 PM, Christer Holmberg wrote: > Hi, > >>> SDP Offer/Answer causes lots of problem. When I read all this it seems >>> like we want to complicate things - which very likely will cause any >>> more problems. >>> >>> Two endpoints use SDP Offer/Answer to negotiate an "SDP session". >>> Can't we try to define what rules apply within that "SDP session"? Why >>> do we have to talk about RTP sessions etc? >> >> I've been trying to understand this since I first started working on sip (in 2002). I'm *finally* starting to >> understand some of the motivations for the words in 3264. Unfortunately those words fell far short of covering the concerns. >> >> I agree that 3264 seems to have a notion of an "SDP session", that is different from an RTP session. >> >> But when using RTP a consequence is that RTP sessions are being established and updated. Those do have rules of >> their own. It is presumably as hard or harder to change those as it is to change the O/A rules. >> >> While 3264 phrases its PT rules in the context of an SDP session, they are pretty much scoped to an RTP session. >> (There is no interaction between the PTs of different m-lines.) AFAICT the only thing considering the SDP session >> can bring to this is to impose a rule that the PT bindings be retained for an m-line even when the RTP session for >> that m-line changes. I can see no downside in removing that restriction. > > Unless there is RTP session rules saying that the PT bindings must change in case of a new RTP session (within a given SDP session), I see no reason why we should introduce such rules within an SDP session. > > (There may of course be other reasons why a new RTP session requires an O/A transaction, and maybe we need to describe that, but that is a separate issue) I'm not saying that the MUST change. Rather I'm saying that they need not remain. Certainly you could use the same PTs on the m-line for the new session. But I suggest we should make clear that there is no need to *remember* bindings from prior RTP sessions that shared the same m-line. I don't see how that would break anything that currently works, and it provides a fix for things that might not work now. If one implementation took this new approach, and recycled a PT in a new RTP session, and the other end was an old implementation that remembered the binding and refused the offer, then it might not work as well as if the new implementation remembered the old binding. But that is just a matter of backward compatibility. We could certainly mention that new implementations might, when possible, attempt to remember and preserve old PT bindings just to avoid this problem, while *allowing* those bindings to be changed. Just a a nod to backward compatibility. Tying this to RTP sessions will fix problems where it isn't possible to preserve old bindings. And it gives a rational underpinning to the rules. Thanks, Paul From nobody Mon Feb 29 13:28: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 A56971B3C84 for ; Mon, 29 Feb 2016 13:28: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, 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 khKZ5VDawqxT for ; Mon, 29 Feb 2016 13:28:51 -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 A020A1B3C83 for ; Mon, 29 Feb 2016 13:28:50 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-57-56d4b81084a9 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D6.15.25494.018B4D65; Mon, 29 Feb 2016 22:28:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 22:28:48 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wARGIiAAAEzHQAAFHhLgAANDP0AAABf9wAAANkcgAABPnAAAACT0gAAARuRgAAArliAACAJAYAADgPBAABONv0AABK4WIAAAjCagAAJzjpQAAHc3IAAAjRVsA== Date: Mon, 29 Feb 2016 21:28:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4D951@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> <56D4B1F1.2070706@alum.mit.edu> In-Reply-To: <56D4B1F1.2070706@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7ma7AjithBhu2WVpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG78kfWAr+SlesffuQtYFxqlgXIyeHhICJ xKZvs1kgbDGJC/fWs3UxcnEICRxmlFjR9ZANJCEksJhR4uptIJuDg03AQqL7nzZIWETAV+LZ 49tgJcIC9hLTnz1mgog7SNze+osdZI6IwDJGiZ/H7zCCJFgEVCWOt81lBbF5gZpf/H/MDrFs CbvE3V9NYAlOAR2Jpy//MIPYjEAXfT+1Bmwqs4C4xK0n85kgLhWQWLLnPDOELSrx8vE/Vghb SaJxyRNWiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhQt Ti0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMlINbfuvuYFz92vEQowAHoxIP7wbny2FCrIllxZW5 hxglOJiVRHhzt10JE+JNSaysSi3Kjy8qzUktPsQozcGiJM7L9gmoWiA9sSQ1OzW1ILUIJsvE wSnVwOh6uPjAHdkOSbHHG2pNqrYqHQtakKh4uf1qC1/6NtmFpzs13CKm7P/y2Dtj47/7Wl+F Vh+qt7kv8OBWsNDX4+zpmyufvFfafeukvM7rBe9zo1Z573o999THz7enp0+oNGaUufN99RPf w3ZRJTPLjLpk/N7cSnZxOxFWHia6UPJ7W0v2JteGHTVKLMUZiYZazEXFiQC/PrFUkAIAAA== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 21:28:52 -0000 Hi, >>>> SDP Offer/Answer causes lots of problem. When I read all this it=20 >>>> seems like we want to complicate things - which very likely will=20 >>>> cause any more problems. >>>> >>>> Two endpoints use SDP Offer/Answer to negotiate an "SDP session". >>>> Can't we try to define what rules apply within that "SDP session"?=20 >>>> Why do we have to talk about RTP sessions etc? >>> >>> I've been trying to understand this since I first started working on=20 >>> sip (in 2002). I'm *finally* starting to understand some of the motivat= ions for the words in 3264. Unfortunately those words fell far short of cov= ering the concerns. >>> >>> I agree that 3264 seems to have a notion of an "SDP session", that is d= ifferent from an RTP session. >>> >>> But when using RTP a consequence is that RTP sessions are being=20 >>> established and updated. Those do have rules of their own. It is presum= ably as hard or harder to change those as it is to change the O/A rules. >>> >>> While 3264 phrases its PT rules in the context of an SDP session, they = are pretty much scoped to an RTP session. >>> (There is no interaction between the PTs of different m-lines.)=20 >>> AFAICT the only thing considering the SDP session can bring to this=20 >>> is to impose a rule that the PT bindings be retained for an m-line even= when the RTP session for that m-line changes. I can see no downside in rem= oving that restriction. >> >> Unless there is RTP session rules saying that the PT bindings must chang= e in case of a new RTP session=20 >> (within a given SDP session), I see no reason why we should introduce su= ch rules within an SDP session. >> >> (There may of course be other reasons why a new RTP session requires=20 >> an O/A transaction, and maybe we need to describe that, but that is a=20 >> separate issue) > > I'm not saying that the MUST change. Rather I'm saying that they need not= remain. Certainly you could=20 > use the same PTs on the m-line for the new session. But I suggest we shou= ld make clear that there is no need to > *remember* bindings from prior RTP sessions that shared the same m-line. Why? If it's the same SDP session, we could still mandate bindings to remai= n. The SDP state still remains, so the previous binding information would n= ot be "lost". Assume that there are cases where the new RTP session would not require a n= ew O/A transaction. The new bindings would not be signalled. >I don't see how that would break anything that currently works, and it pro= vides a fix for things that might not work now. What won't work now? Why do we need to allow recycling within the same SDP = session? If I've missed it, please let me know... In any case, I think we have two separate questions: 1. What are the rules within a given RTP session? 2. Does a change of the RTP session, within the given SDP session, have an = impact on the rules? Regards, Christer > If one implementation took this new approach, and recycled a PT in a new = RTP session, and the other end was an=20 > old implementation that remembered the binding and refused the offer, the= n it might not work as well as if the=20 > new implementation remembered the old binding. > > But that is just a matter of backward compatibility. We could certainly m= ention that new implementations might, when=20 > possible, attempt to remember and preserve old PT bindings just to avoid = this problem, while >*allowing* those bindings to be changed. Just a a nod to backward compatib= ility. From nobody Mon Feb 29 13:40:22 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 5EA6C1B3CCB for ; Mon, 29 Feb 2016 13:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 f8HzfFECpPrL for ; Mon, 29 Feb 2016 13:40:19 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686AD1B3CCC for ; Mon, 29 Feb 2016 13:40:16 -0800 (PST) Received: from [81.187.2.149] (port=39448 helo=[192.168.0.86]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aaVY4-0000Sg-5G; Mon, 29 Feb 2016 21:40:13 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4D951@ESESSMB209.ericsson.se> Date: Mon, 29 Feb 2016 21:40:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <66F2264B-3CA3-4650-88B6-89FC64D5FD29@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> <56D4B1F1.2070706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D951@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 21:40:21 -0000 > On 29 Feb 2016, at 21:28, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>> SDP Offer/Answer causes lots of problem. When I read all this it=20= >>>>> seems like we want to complicate things - which very likely will=20= >>>>> cause any more problems. >>>>>=20 >>>>> Two endpoints use SDP Offer/Answer to negotiate an "SDP session". >>>>> Can't we try to define what rules apply within that "SDP session"?=20= >>>>> Why do we have to talk about RTP sessions etc? >>>>=20 >>>> I've been trying to understand this since I first started working = on=20 >>>> sip (in 2002). I'm *finally* starting to understand some of the = motivations for the words in 3264. Unfortunately those words fell far = short of covering the concerns. >>>>=20 >>>> I agree that 3264 seems to have a notion of an "SDP session", that = is different from an RTP session. >>>>=20 >>>> But when using RTP a consequence is that RTP sessions are being=20 >>>> established and updated. Those do have rules of their own. It is = presumably as hard or harder to change those as it is to change the O/A = rules. >>>>=20 >>>> While 3264 phrases its PT rules in the context of an SDP session, = they are pretty much scoped to an RTP session. >>>> (There is no interaction between the PTs of different m-lines.)=20 >>>> AFAICT the only thing considering the SDP session can bring to this=20= >>>> is to impose a rule that the PT bindings be retained for an m-line = even when the RTP session for that m-line changes. I can see no downside = in removing that restriction. >>>=20 >>> Unless there is RTP session rules saying that the PT bindings must = change in case of a new RTP session=20 >>> (within a given SDP session), I see no reason why we should = introduce such rules within an SDP session. >>>=20 >>> (There may of course be other reasons why a new RTP session requires=20= >>> an O/A transaction, and maybe we need to describe that, but that is = a=20 >>> separate issue) >>=20 >> I'm not saying that the MUST change. Rather I'm saying that they need = not remain. Certainly you could=20 >> use the same PTs on the m-line for the new session. But I suggest we = should make clear that there is no need to >> *remember* bindings from prior RTP sessions that shared the same = m-line. >=20 > Why? If it's the same SDP session, we could still mandate bindings to = remain. The SDP state still remains, so the previous binding information = would not be "lost". >=20 > Assume that there are cases where the new RTP session would not = require a new O/A transaction. The new bindings would not be signalled. >=20 >> I don't see how that would break anything that currently works, and = it provides a fix for things that might not work now. >=20 > What won't work now? Why do we need to allow recycling within the same = SDP session? If I've missed it, please let me know... >=20 > In any case, I think we have two separate questions: >=20 > 1. What are the rules within a given RTP session? A given RTP session has a mapping between RTP numbers and payload = formats (i.e., codecs). All participants in the session are supposed to = agree on that mapping, otherwise bad things can happen (trying to decode = a packet with the wrong codec). > 2. Does a change of the RTP session, within the given SDP session, = have an impact on the rules? The mapping is per RTP session. If two consecutive RTP sessions have the = same mapping, that=E2=80=99s okay; it=E2=80=99s also okay if not.=20 Colin > Regards, >=20 > Christer >=20 >=20 >> If one implementation took this new approach, and recycled a PT in a = new RTP session, and the other end was an=20 >> old implementation that remembered the binding and refused the offer, = then it might not work as well as if the=20 >> new implementation remembered the old binding. >>=20 >> But that is just a matter of backward compatibility. We could = certainly mention that new implementations might, when=20 >> possible, attempt to remember and preserve old PT bindings just to = avoid this problem, while >> *allowing* those bindings to be changed. Just a a nod to backward = compatibility. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ From nobody Mon Feb 29 13:52: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 5CDD31B3D19 for ; Mon, 29 Feb 2016 13:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 I0d5a0yKIH39 for ; Mon, 29 Feb 2016 13:52:40 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 919811B3D16 for ; Mon, 29 Feb 2016 13:52:40 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id g203so202075754iof.2 for ; Mon, 29 Feb 2016 13:52:40 -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; bh=YuVtJR+tHwNwmxqJ2g/HOiTL+e85RWMId4Uoe5rA/6g=; b=uSlb3KYo9MUxDJRKzHAFbu+n3BY1thMV3V0GjtNV8HBEam4K2aQxPU55C/kXdGfWxv dL7GEAn5DuecBSyCM5wVBAsny86Tv7/OIClrSU5AOxMaISY4wh1depnwzjhQwwDb9nhH UXL6iqtXCVnIF3A/AirxT5/lCWX8j91ea8iPk9Dd44Wqfz5QFegRKv9QFaTTCKQGcpCN KPknsLdloeQCm2DaMLDKnvFGzzNpjAoZKOE6pSleusQ7bcsyOGubUMWm05L6GkrjwRGN 9eEDc8AjiQkHZanCmGqy33W2c6hyj8rZVQc+YZ+r/Lz7o42B97e0VHBqnJf+Y2nFvi0x Pq3Q== 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; bh=YuVtJR+tHwNwmxqJ2g/HOiTL+e85RWMId4Uoe5rA/6g=; b=e1vFAI0Q2wqiReADqV0KQ8GdR5zkT/BDAO0PNfD+rXk8FVc2IkhluL0Yul2GlxYSg+ N1tHLhAF6Ef53LPr8j9x4j3hoKBq2HXJFGmNYqTE9mmu05WBXkDoxzJGXfE9N9a4Jduc vDAPaEt2pi6XD4eJcAb/8pIy8wJmxDQj9n9EKy3ROUC6ZC+Hr57alE1EnFc6ZfFHF9Rg QTMRzRfXPly0UzD1glnGCbso8CD/idI6Fjq28KhNRS2msxlJUyMD/J76FhIjyKoNDEWJ TmwBgRg0E7aVo3h3000xq1cafPTl9q2sM+WTpInsUjwc2D9wTcbFnfvmC76qihVEp/kc iIXA== X-Gm-Message-State: AG10YOTHU6ccBUS2zGk3ajhdVbUJisDqOR68DxNy6czx50Axms15AWjCEZGRcoaNOBAhgg== X-Received: by 10.107.17.147 with SMTP id 19mr26015234ior.109.1456782760060; Mon, 29 Feb 2016 13:52:40 -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 wj3sm7501188igb.6.2016.02.29.13.52.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 13:52:38 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id xg9so4961505igb.1; Mon, 29 Feb 2016 13:52:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.61.166 with SMTP id q6mr199229igr.96.1456782758150; Mon, 29 Feb 2016 13:52:38 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 29 Feb 2016 13:52:38 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4D6D5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E45EA2@ESESSMB209.ericsson.se> <56D46C50.9060601@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D6D5@ESESSMB209.ericsson.se> Date: Mon, 29 Feb 2016 16:52:38 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bdca2f8d08c49052cefaa7f Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09 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, 29 Feb 2016 21:52:42 -0000 --047d7bdca2f8d08c49052cefaa7f Content-Type: text/plain; charset=UTF-8 On Mon, Feb 29, 2016 at 2:33 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > If so, I don't think the text above is consistent with that. I think it > should probably say: > > > > One of the certificates received during the DTLS handshake MUST > > match one of the fingerprints received in an SDP "fingerprint" > > attribute. If not, then the endpoint MUST tear down the media > > session immediately. Note that it is permissible to wait until > > the other side's fingerprints have been received before establishing > > the connection; however, this may have undesirable latency effects. > > > > If the above is true, then it is possible that adding/changing a > fingerprint might not require establishing a > > new DTLS association. If the association had been established based on a > fingerprint that remains, then it > > doesn't matter what happens to the other fingerprints. > > MAYBE (there are others that know this better than me) there are cases > where a new DTLS association would not be required, but I think we should > have consistent rules. > > And, as far as I know, it is quite unlikely that there will be any > fingerprint changes within a session to begin with, so I don't think we are > going to end up in a situation with lots of DTLS associations being > re-established even if there may not be a need for it. > Even though it is technically possible to keep the connection if the fingerprint of the currently used certificate did not change, I think it is more important to have consistent rules in which end points will have no ambiguity that new DTLS association must be re-established. I do not see any use cases when one of the fingerprints changed while others were kept the same. Forcing new DTLS association when any fingerprint changes also allows the signaling agent to easily examine the SDP and validate that if any fingerprints changed, dtls-association attribute is set to new. It would be much harder to verify what dtls-association value should be in SDP if partial fingerprint changes were allowed on the connection, since signaling agent might not have means to determine which fingerprint was currently used to verify the media connection. Things also would become really confusing in case when different certificates are used for RTP and RTCP. End point might want to change only of the certificates and keep the other certificate the same. This end point will change only one fingerprint in the SDP. What dtls-connection value should be there? Is it existing connection or the new one? It would be much simpler to require that both connections were simply re-established. Regards, _____________ Roman Shpount --047d7bdca2f8d08c49052cefaa7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 29, 2016 at 2:33 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
> If so, I don't think the text ab= ove is consistent with that. I think it should probably say:
>
>=C2=A0 =C2=A0 One of the certificates received during the DTLS handshak= e MUST
>=C2=A0 =C2=A0 match one of the fingerprints received in an SDP "fi= ngerprint"
>=C2=A0 =C2=A0 attribute.=C2=A0 If not, then the endpoint MUST tear down= the media
>=C2=A0 =C2=A0 session immediately.=C2=A0 Note that it is permissible to= wait until
>=C2=A0 =C2=A0 the other side's fingerprints have been received befo= re establishing
>=C2=A0 =C2=A0 the connection; however, this may have undesirable latenc= y effects.
>
> If the above is true, then it is possible that adding/changing a finge= rprint might not require establishing a
> new DTLS association. If the association had been established based on= a fingerprint that remains, then it
> doesn't matter what happens to the other fingerprints.

MAYBE (there are others that know this better than me) there are cases wher= e a new DTLS association would not be required, but I think we should have = consistent rules.

And, as far as I know, it is quite unlikely that there will be any fingerpr= int changes within a session to begin with, so I don't think we are goi= ng to end up in a situation with lots of DTLS associations being re-establi= shed even if there may not be a need for it.

Even though it is technically possible to keep the connection if the = fingerprint of the currently used certificate did not change, I think it is= more important to have consistent rules in which end points will have no a= mbiguity that new DTLS association must be re-established. I do not see any= use cases when one of the fingerprints changed while others were kept the = same.

Forcing new DTLS association when any finger= print changes also allows the signaling agent to easily examine the SDP and= validate that if any fingerprints changed, dtls-association attribute is s= et to new. It would be much harder to verify what dtls-association value sh= ould be in SDP if partial fingerprint changes were allowed on the connectio= n, since signaling agent might not have means to determine which fingerprin= t was currently used to verify the media connection.

Things also would become really confusing in case when different certifi= cates are used for RTP and RTCP. End point might want to change only of the= certificates and keep the other certificate the same. This end point will = change only one fingerprint in the SDP. What dtls-connection value should b= e there? Is it existing connection or the new one? It would be much simpler= to require that both connections were simply re-established.
Regards,
_____________=
Roman Shpount
=C2=A0
--047d7bdca2f8d08c49052cefaa7f-- From nobody Mon Feb 29 13:59: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 9D3901B3D6F for ; Mon, 29 Feb 2016 13:59:51 -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 9S57hcEU8HPX for ; Mon, 29 Feb 2016 13:59:50 -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 C6F6D1B3D6A for ; Mon, 29 Feb 2016 13:59:49 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-9c-56d4bf53a390 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.87.25494.35FB4D65; Mon, 29 Feb 2016 22:59:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 22:59:47 +0100 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wARGIiAAAEzHQAAFHhLgAANDP0AAABf9wAAANkcgAABPnAAAACT0gAAARuRgAAArliAACAJAYAADgPBAABONv0AABK4WIAAAjCagAAJzjpQAAHc3IAAAjRVsP//+M8A///qvQA= Date: Mon, 29 Feb 2016 21:59:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4DB7C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> <56D4B1F1.2070706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D951@ESESSMB209.ericsson.se> <66F2264B-3CA3-4650-88B6-89FC64D5FD29@csperkins.org> In-Reply-To: <66F2264B-3CA3-4650-88B6-89FC64D5FD29@csperkins.org> 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+NgFupnkeLIzCtJLcpLzFFi42KZGbHdQzd4/5Uwg+m/VS2WvzzBaDF1+WMW ixUbDrA6MHv8ff+ByWPa/ftsHkuW/GQKYI7isklJzcksSy3St0vgypjZc4yxYBFXxb85vcwN jA1cXYycHBICJhLzbj5kgbDFJC7cW88GYgsJHGaU2H3NvYuRC8hezChxb9U3oCIODjYBC4nu f9ogNSICqhI7jv9jBLGZBXwlXi74wgxiCwvYS0x/9pgJosZB4vbWX+wgc0QENjFK/Dq1AGwB C1Dzp/nLmEFm8gI1bzskBLF3PofEmb3KIDangKPE64M7wG5jBLrt+6k1TBC7xCVuPZnPBHGz gMSSPeeZIWxRiZeP/7FC2EoSjUuesIKMZxbQlFi/Sx+iVVFiSvdDdhCbV0BQ4uTMJywTGMVm IZk6C6FjFpKOWUg6FjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjKaDW37r7mBc/drx EKMAB6MSD+8G58thQqyJZcWVuYcYJTiYlUR4c7ddCRPiTUmsrEotyo8vKs1JLT7EKM3BoiTO y/YJqFogPbEkNTs1tSC1CCbLxMEp1cAoU1AkKqElx94VsmFxa5WP3oJF/4N2zBA/3vNU+2zJ jDXt7gHFMk0ei6x/6G5ZUf62INI+dMre1T2bO29K6H//JcfgFZuYoTtF5Uiu0vLUH99rGydY pl7Jm2H6we1lzOqrJrviv5u+Yi358cCc5xrnzodHVq9/F9t2snheFUvW1DqpA9PncMgqsRRn JBpqMRcVJwIAq6Cl5qICAAA= Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 21:59:51 -0000 SGksDQoNCi4uLg0KDQo+PiBJbiBhbnkgY2FzZSwgSSB0aGluayB3ZSBoYXZlIHR3byBzZXBhcmF0 ZSBxdWVzdGlvbnM6DQo+PiANCj4+IDEuIFdoYXQgYXJlIHRoZSBydWxlcyB3aXRoaW4gYSBnaXZl biBSVFAgc2Vzc2lvbj8NCj4NCj4gQSBnaXZlbiBSVFAgc2Vzc2lvbiBoYXMgYSBtYXBwaW5nIGJl dHdlZW4gUlRQIG51bWJlcnMgYW5kIHBheWxvYWQgZm9ybWF0cyAoaS5lLiwgY29kZWNzKS4gQWxs IA0KPiBwYXJ0aWNpcGFudHMgaW4gdGhlIHNlc3Npb24gYXJlIHN1cHBvc2VkIHRvIGFncmVlIG9u IHRoYXQgbWFwcGluZywgb3RoZXJ3aXNlIGJhZCB0aGluZ3MgY2FuIGhhcHBlbiAodHJ5aW5nIHRv IGRlY29kZSBhIHBhY2tldCB3aXRoIHRoZSB3cm9uZyBjb2RlYykuDQoNClNvLCB0aGF0IG1lYW5z IHRoYXQgdGhlIG1hcHBpbmcgaGFzIHRvIGJlIHVuaXF1ZSBpbiBib3RoIGRpcmVjdGlvbnMuIEku ZS4gbm8gdXNhZ2Ugb2YgUFQxMTEvVlA4IGluIG9uZSBkaXJlY3Rpb24gYW5kIFBUMTExL0FNUi1X RyBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uLg0KDQo+PiAyLiBEb2VzIGEgY2hhbmdlIG9mIHRoZSBS VFAgc2Vzc2lvbiwgd2l0aGluIHRoZSBnaXZlbiBTRFAgc2Vzc2lvbiwgaGF2ZSBhbiBpbXBhY3Qg b24gdGhlIHJ1bGVzPw0KPg0KPiBUaGUgbWFwcGluZyBpcyBwZXIgUlRQIHNlc3Npb24uIElmIHR3 byBjb25zZWN1dGl2ZSBSVFAgc2Vzc2lvbnMgaGF2ZSB0aGUgc2FtZSBtYXBwaW5nLCB0aGF04oCZ cyBva2F5OyBpdOKAmXMgYWxzbyBva2F5IGlmIG5vdC4gDQoNClRoYW5rcy4gU28sIGFnYWluLCBp cyB0aGVyZSBhIHJlYXNvbiB3aHkgd2UsIHdpdGhpbiBhbiBTRFAgc2Vzc2lvbiwgd291bGQgYWxs b3cgcmVjeWNsZSBvZiB0aGUgbWFwcGluZyAtIGV2ZW4gaWYgdGhlIGFzc29jaWF0ZWQgUlRQIHNl c3Npb24gY2hhbmdlcz8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg== From nobody Mon Feb 29 14:03: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 3DEAE1B3D90 for ; Mon, 29 Feb 2016 14:03:46 -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 93HUyXkT42Gx for ; Mon, 29 Feb 2016 14:03:45 -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 D4AD11B3D94 for ; Mon, 29 Feb 2016 14:03:44 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-04v.sys.comcast.net with comcast id QMyS1s0082PT3Qt01N3k68; Mon, 29 Feb 2016 22:03:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with comcast id QN3j1s00T3KdFy101N3jUJ; Mon, 29 Feb 2016 22:03:44 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56CF9400.2020002@alum.mit.edu> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> <56D4B1F1.2070706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D951@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56D4C03E.7010403@alum.mit.edu> Date: Mon, 29 Feb 2016 17:03:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4D951@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=1456783424; bh=VOgwnMGyVwLWwCymDi+Xqo/K7xwAgPRTZ+P9aCdTcb4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PUx2dYo9erbgzZArhkwRt/GK3wS4GDxqS6elLtUuq6S6QMHqb71B1qDBoRZRukJZj 1sfYMgAXp2y1bJFKJ32jKIGltUUaOQ4JHR0UpgqUB1zSKUQaG6I8DZzr8wyQZPUgF8 W4Vo8y1rRrjYmiwEJcTcuaMga7UR9EbfoMEAxaaxFPbwMESgmGE/ker1SW7OYfrz+k j7DJLYY2PhCDWOpJFJwt01V50eQjxN3IOAKugoRQhxpceTCmG56Jvcxl0y+DQ+rp4O MSUxJ59smBkwTbV0HMRlKQ4aEiXnxJ/0Rc+k+OEucQirZ9hvMjnXU+AehXz6MKJE93 0n7F3UU5v9PJQ== Archived-At: Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 22:03:46 -0000 On 2/29/16 4:28 PM, Christer Holmberg wrote: > Hi, > >>>>> SDP Offer/Answer causes lots of problem. When I read all this it >>>>> seems like we want to complicate things - which very likely will >>>>> cause any more problems. >>>>> >>>>> Two endpoints use SDP Offer/Answer to negotiate an "SDP session". >>>>> Can't we try to define what rules apply within that "SDP session"? >>>>> Why do we have to talk about RTP sessions etc? >>>> >>>> I've been trying to understand this since I first started working on >>>> sip (in 2002). I'm *finally* starting to understand some of the motivations for the words in 3264. Unfortunately those words fell far short of covering the concerns. >>>> >>>> I agree that 3264 seems to have a notion of an "SDP session", that is different from an RTP session. >>>> >>>> But when using RTP a consequence is that RTP sessions are being >>>> established and updated. Those do have rules of their own. It is presumably as hard or harder to change those as it is to change the O/A rules. >>>> >>>> While 3264 phrases its PT rules in the context of an SDP session, they are pretty much scoped to an RTP session. >>>> (There is no interaction between the PTs of different m-lines.) >>>> AFAICT the only thing considering the SDP session can bring to this >>>> is to impose a rule that the PT bindings be retained for an m-line even when the RTP session for that m-line changes. I can see no downside in removing that restriction. >>> >>> Unless there is RTP session rules saying that the PT bindings must change in case of a new RTP session >>> (within a given SDP session), I see no reason why we should introduce such rules within an SDP session. >>> >>> (There may of course be other reasons why a new RTP session requires >>> an O/A transaction, and maybe we need to describe that, but that is a >>> separate issue) >> >> I'm not saying that the MUST change. Rather I'm saying that they need not remain. Certainly you could >> use the same PTs on the m-line for the new session. But I suggest we should make clear that there is no need to >> *remember* bindings from prior RTP sessions that shared the same m-line. > > Why? If it's the same SDP session, we could still mandate bindings to remain. The SDP state still remains, so the previous binding information would not be "lost". We have seen there are cases where it is *hard* to preserve the bindings. For instance because the updating O/A is attaching the call to a pre-existing RTP session, that has a different set of bindings. > Assume that there are cases where the new RTP session would not require a new O/A transaction. The new bindings would not be signalled. I guess in that case it doesn't matter until there is an O/A that proposes a change to the existing RTP session that conflicts with bindings that are present but that haven't yet been signaled in an O/A. If that happens, then I guess it would be necessary to either create a new RTP session or else reject the SDP. >> I don't see how that would break anything that currently works, and it provides a fix for things that might not work now. > > What won't work now? Why do we need to allow recycling within the same SDP session? If I've missed it, please let me know... I don't know where this need originally came from. I think there was something about compatibility with H.323. (IIRC the H.323 O/A rules are different.) But again, I think the case that has been identified here is when connecting to a pre-existing RTP session. > In any case, I think we have two separate questions: > > 1. What are the rules within a given RTP session? > 2. Does a change of the RTP session, within the given SDP session, have an impact on the rules? I agree that it is good to treat these as separate questions. Thanks, Paul > Regards, > > Christer > > >> If one implementation took this new approach, and recycled a PT in a new RTP session, and the other end was an >> old implementation that remembered the binding and refused the offer, then it might not work as well as if the >> new implementation remembered the old binding. >> >> But that is just a matter of backward compatibility. We could certainly mention that new implementations might, when >> possible, attempt to remember and preserve old PT bindings just to avoid this problem, while >> *allowing* those bindings to be changed. Just a a nod to backward compatibility. > > From nobody Mon Feb 29 14:06:56 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 D91EB1B3D9F for ; Mon, 29 Feb 2016 14:06:54 -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 rcuAi1sf76pE for ; Mon, 29 Feb 2016 14:06:54 -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 376421B3DA7 for ; Mon, 29 Feb 2016 14:06:48 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with comcast id QN531s0092JGN3p01N6n0a; Mon, 29 Feb 2016 22:06:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id QN6m1s00b3KdFy101N6nLP; Mon, 29 Feb 2016 22:06:47 +0000 To: Christer Holmberg , Colin Perkins References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <56D08962.3060006@alum.mit.edu> <56D09563.9040509@alum.mit.edu> <56D1CA6C.70700@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> <56D4B1F1.2070706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D951@ESESSMB209.ericsson.se> <66F2264B-3CA3-4650-88B6-89FC64D5FD29@csperkins.org> <7594FB04B1934943A5C02806D1A2204B37E4DB7C@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56D4C0F5.50901@alum.mit.edu> Date: Mon, 29 Feb 2016 17:06:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4DB7C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456783607; bh=txxkoJ5u1YfSicvCEJA1NuS78t9Biziy+Jb+sa6jb1U=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hv1neSbfvkrkrEXvdjcd7VHV9UGoxz+1uUN0n6obqqnzHQUFVN9c49S6grd92cEFa chg+UsKMQxiS6XTEeWwo0siVB8Q6vH1Wzf9/oZozUoSzi8AV+GkAJ1UYa1ZrQBKlTQ TfpgyN5bsUf3kfOBbCHXufQPUupXXHpg/G095grinJKNUUdPKTgHXkoY5dVlyS84PL Eav3LBprQMcDWsWkvJWKVmCIpPoSNnskRII0gyVyEJZXwhjmlRJ1LW89vAMXfq3zkU Z2c7mAeAQdqseuRnR44WL/I3/hr4k5aris7U1Kdxk+2KYMb2xK2EI5bA7BaOvOTGwP hOJ/3N8qGLJhw== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal 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, 29 Feb 2016 22:06:55 -0000 On 2/29/16 4:59 PM, Christer Holmberg wrote: > Hi, > > ... > >>> In any case, I think we have two separate questions: >>> >>> 1. What are the rules within a given RTP session? >> >> A given RTP session has a mapping between RTP numbers and payload formats (i.e., codecs). All >> participants in the session are supposed to agree on that mapping, otherwise bad things can happen (trying to decode a packet with the wrong codec). > > So, that means that the mapping has to be unique in both directions. I.e. no usage of PT111/VP8 in one direction and PT111/AMR-WG in the other direction. I think what we have concluded earlier in this thread is that there can't be *conflicting* meanings in the two directions. But there can be multiple PTs for a given codec config, and an agreement that a different PT is used for each direction. Thanks, Paul >>> 2. Does a change of the RTP session, within the given SDP session, have an impact on the rules? >> >> The mapping is per RTP session. If two consecutive RTP sessions have the same mapping, that’s okay; it’s also okay if not. > > Thanks. So, again, is there a reason why we, within an SDP session, would allow recycle of the mapping - even if the associated RTP session changes? > > Regards, > > Christer > > > From nobody Mon Feb 29 14:16: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 2B0991B3DE5 for ; Mon, 29 Feb 2016 14:16:53 -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 tjVDyhRgWFDY for ; Mon, 29 Feb 2016 14:16:52 -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 EB7C11B3DE4 for ; Mon, 29 Feb 2016 14:16:51 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-02v.sys.comcast.net with comcast id QNF21s0042Qkjl901NGrr4; Mon, 29 Feb 2016 22:16:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id QNGq1s00P3KdFy101NGqjC; Mon, 29 Feb 2016 22:16:51 +0000 To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B37E45EA2@ESESSMB209.ericsson.se> <56D46C50.9060601@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D6D5@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56D4C351.1000003@alum.mit.edu> Date: Mon, 29 Feb 2016 17:16:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.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=1456784211; bh=ISf+TTTcPWfNbPkPURxWXwl/aASROgRMa11WTj7XXFs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PgYznxprL/aw6AOAznSjFdjwGqzoPsLxVFpG6L9jmypTMSnls9WotAv4zoyH8jZK/ VeKJyme4p2NHPugH/naURYBLd44aNGFXsQrnUm5sCdvAmp1o9Z+na56Z7IYk4cyT9C Z/XK89LWIeGP4QR/ar9O8i9I2nNADBJj/IDvlpmZP0PCF9Ip63cBoc7rRvxfPStkeB 1QIN1VhdUErD5LTrWVDRrm6KFaya5aq2ovEyUsYvpOzlyJKD7EdnXVebupmE7I7swA lxOj5AYKR/mJsemsEEWCw4Azw1Ql/A0QnooZpQLl8DUDzrgXazBU7nyvb8ST7S/bNP fJhzWaMx6aeJg== Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09 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, 29 Feb 2016 22:16:53 -0000 On 2/29/16 4:52 PM, Roman Shpount wrote: > On Mon, Feb 29, 2016 at 2:33 PM, Christer Holmberg > > > wrote: > > > If so, I don't think the text above is consistent with that. I > think it should probably say: > > > > One of the certificates received during the DTLS handshake MUST > > match one of the fingerprints received in an SDP "fingerprint" > > attribute. If not, then the endpoint MUST tear down the media > > session immediately. Note that it is permissible to wait until > > the other side's fingerprints have been received before > establishing > > the connection; however, this may have undesirable latency > effects. > > > > If the above is true, then it is possible that adding/changing a > fingerprint might not require establishing a > > new DTLS association. If the association had been established > based on a fingerprint that remains, then it > > doesn't matter what happens to the other fingerprints. > > MAYBE (there are others that know this better than me) there are > cases where a new DTLS association would not be required, but I > think we should have consistent rules. > > And, as far as I know, it is quite unlikely that there will be any > fingerprint changes within a session to begin with, so I don't think > we are going to end up in a situation with lots of DTLS associations > being re-established even if there may not be a need for it. > > > Even though it is technically possible to keep the connection if the > fingerprint of the currently used certificate did not change, I think it > is more important to have consistent rules in which end points will have > no ambiguity that new DTLS association must be re-established. I do not > see any use cases when one of the fingerprints changed while others were > kept the same. > > Forcing new DTLS association when any fingerprint changes also allows > the signaling agent to easily examine the SDP and validate that if any > fingerprints changed, dtls-association attribute is set to new. It would > be much harder to verify what dtls-association value should be in SDP if > partial fingerprint changes were allowed on the connection, since > signaling agent might not have means to determine which fingerprint was > currently used to verify the media connection. > > Things also would become really confusing in case when different > certificates are used for RTP and RTCP. End point might want to change > only of the certificates and keep the other certificate the same. This > end point will change only one fingerprint in the SDP. What > dtls-connection value should be there? Is it existing connection or the > new one? It would be much simpler to require that both connections were > simply re-established. I am ok with deciding that the rule should be if any fingerprint changes then a new association is required. Not because it is technically necessary, but simply because it makes the rules simpler and more comprehensible, and because the likelihood of this causing an inordinate extra cost is low. But we should not say or imply that the recipient is obligated to check that each of the fingerprints match a cert. (We can require this of the sender.) It should be sufficient for the receiver to pick the fingerprint(s) it is going to use and check them. Thanks, Paul From nobody Mon Feb 29 14:41: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 7F6481B3E5D for ; Mon, 29 Feb 2016 14:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 KELfP6ORxb4z for ; Mon, 29 Feb 2016 14:41: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 7C6091B3E5E for ; Mon, 29 Feb 2016 14:41:55 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id n190so143786iof.0 for ; Mon, 29 Feb 2016 14:41: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; bh=I21/411htGKb/yRVdraoQtuqo4hmbMPcRL13Fp1n+eM=; b=z4kpCI5eBDzQUYqHSw8yCi8dDzLJ2a08J6bbwo32q8Ls9UhGkJACS3s+NAwwqB5ecL M6JOA4GoNncoOu2tUm3/zT8gAA8leCXGFGc9PvFcC9D8+Xdp8FfrPaRnPukDK+omeQlm bZgOzFxOILFu8/Q53f70nb9GDuVmtF6rAfh1kcehNwOvgo3RF7ZPTxhMkqq1gvBLHuLz UclBPgpCjndcXn0LNylAl1eRzN1ccW6TmnD0oAp2i8equrWOSD2RlBjSwOR4qApsI/7D 3+vIgUSlm9GovB3Co1ZlTVqMYd9H4JB2vsRp3lqRMTAJbVgbqJhz9/tcrRQWEDzyTYlw Wueg== 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; bh=I21/411htGKb/yRVdraoQtuqo4hmbMPcRL13Fp1n+eM=; b=WxwZxzpPKNjhX1Q2kI8KAlWTRY2cfeG0llIMyJQX6Q8vlCEhMVsE4ke+H2eOdYk63H Gg/tTCevxKtIa6OuyDZzpmgEpa6E1DXx7M3qE6jhhLVMhKxqQT0+XQIOzKs9gmYDpV3g rcXFq0jybbjuaobP4n23OUNsYaHr1pUjGUKrIhFa/NvOGDbWkSCNg9wpmULmLZUuSbkq +DfNaZPJL+tMKWJ6zHyRQ+pSKNv0+eJl4RLaIISjIBgwuneFInrZnfSgiNqdSuifIMpr a/HtjcZqlHycampgaR2LVX4fhY1RgVNNygFKSzR93QLMpASlLMWJTa6aIsHrf+8hL2oY ONUw== X-Gm-Message-State: AG10YOTDxxCeka57GCa3kaJ8N3yqyl1kVuLjpPpKuDt3ivpkrekV1pdkmcxO7AYFawSiWQ== X-Received: by 10.107.135.229 with SMTP id r98mr19899028ioi.68.1456785715005; Mon, 29 Feb 2016 14:41:55 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by smtp.gmail.com with ESMTPSA id m7sm11616935ioa.42.2016.02.29.14.41.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 14:41:53 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id y8so7032042igp.0; Mon, 29 Feb 2016 14:41:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.28.48 with SMTP id y16mr397761igg.2.1456785712740; Mon, 29 Feb 2016 14:41:52 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 29 Feb 2016 14:41:52 -0800 (PST) In-Reply-To: <56D4C351.1000003@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37E45EA2@ESESSMB209.ericsson.se> <56D46C50.9060601@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D6D5@ESESSMB209.ericsson.se> <56D4C351.1000003@alum.mit.edu> Date: Mon, 29 Feb 2016 17:41:52 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0158b360ec0a79052cf05a21 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09 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, 29 Feb 2016 22:41:56 -0000 --089e0158b360ec0a79052cf05a21 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 29, 2016 at 5:16 PM, Paul Kyzivat wrote: > > I am ok with deciding that the rule should be if any fingerprint changes > then a new association is required. Not because it is technically > necessary, but simply because it makes the rules simpler and more > comprehensible, and because the likelihood of this causing an inordinate > extra cost is low. > > But we should not say or imply that the recipient is obligated to check > that each of the fingerprints match a cert. (We can require this of the > sender.) It should be sufficient for the receiver to pick the > fingerprint(s) it is going to use and check them. > > For recipient it should be sufficient to check dtls-association attribute. Sender must set dtls-association to new if it changed any of the fingerprints. _____________ Roman Shpount --089e0158b360ec0a79052cf05a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 29, 2016 at 5:16 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

I am ok with deciding that the rule should be if any fingerprint changes th= en a new association is required.=C2=A0 Not because it is technically neces= sary, but simply because it makes the rules simpler and more comprehensible= , and because the likelihood of this causing an inordinate extra cost is lo= w.

But we should not say or imply that the recipient is obligated to check tha= t each of the fingerprints match a cert. (We can require this of the sender= .) It should be sufficient for the receiver to pick the fingerprint(s) it i= s going to use and check them.


For recipient it should be sufficient = to check dtls-association attribute. Sender must set dtls-association to ne= w if it changed any of the fingerprints.
_____________
Roman Shpount
=C2=A0
--089e0158b360ec0a79052cf05a21-- From nobody Mon Feb 29 17:03: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 DDC681A8716; Mon, 29 Feb 2016 17:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, 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 0zeeD66fhRRt; Mon, 29 Feb 2016 17:03:43 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 B13F71A870F; Mon, 29 Feb 2016 17:03:43 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id n190so3194607iof.0; Mon, 29 Feb 2016 17:03:43 -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; bh=BZIGA9+vQDSB5CMkOQylkPV8wlsg5io3y7W7dgg5VHQ=; b=EE9POif3t5XauXfns1r3oR0rdMo0QxQF6yh05GvP60bfE80eaqY4QLmJAcuAi2rW02 5iQjHvR1AluHVH6CyVRiDa02whpP7ACPu5Zh7yBi25kDIF+awpZeBBwX0FZ+8aGmVkzG YY6SnF+G6KXZ5T+nswYmkKijrPgwowQUXY8gaWz6i14T8B1iDP/tTxUi6Ppv443jlxi+ 06R95G78Xm1f9z9IkllREw3VzM/3EmSEKme+ZP/T/DGabaAaguC6lqmQdvE8NsFP3W09 g01oH7Xz1zXLq7ar+BcRB7sY25zVZojcaoMHX76ywzDjI8ejN1m8RicfzdwnZ5awoTvw 1fvQ== 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; bh=BZIGA9+vQDSB5CMkOQylkPV8wlsg5io3y7W7dgg5VHQ=; b=C4NP7Y7osn8v0HJEhD8MMm8sw+pn5G44XT/NSISLiRbWau0FOnlWM7ru54KYapOwsI yT+YSaIblpEBYZ4lQtb7VQWfXeUqr7q5teMmZLnkmVx2kzbrMtibtvVpazmCVIIUr37J axMGuNGMcQFwKbqYngxLy4il4VjzSqT2DC0BFc9hVh8varDES1lDQfYlB6k3y635j0+5 EhRRWGA1ZCX2VAlJHfrVHAubqsshVSZmxk5QTlZZRFnWF2NZaZvuUOMOJTHF2O+wTnYc D7IoLqU5jvQl6GcrOn/6ZG/Lfv8OIWlfE3/BCXBTbZlOjGvPQkoYVNQOFurWoFbhoJ++ EWvQ== X-Gm-Message-State: AG10YOSSSOueOoRL0VZaKSPUDNJXXjJhLuwOoj/V57d+rVjA7PpBUYFjX2xNjLlKiNyFBzfqAoHpsuyv2IZvVA== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr23049422iop.100.1456794223108; Mon, 29 Feb 2016 17:03:43 -0800 (PST) Received: by 10.36.53.79 with HTTP; Mon, 29 Feb 2016 17:03:43 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4B32F@ESESSMB209.ericsson.se> References: <56C63BE8.6000607@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E4B32F@ESESSMB209.ericsson.se> Date: Tue, 1 Mar 2016 12:03:43 +1100 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Flemming Andreasen , mmusic , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-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, 01 Mar 2016 01:03:45 -0000 On 29 February 2016 at 19:12, Christer Holmberg wrote: > FIRST, section 5.1.3 of RFC 5761 says: > > "If it is desired to use both ICE and multiplexed RTP and RTCP, the > initial offer MUST contain an "a=rtcp-mux" attribute to indicate that > RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" > lines for both RTP and RTCP along with an "a=rtcp:" line indicating a > fallback port for RTCP in the case that the answerer does not support > RTP and RTCP multiplexing. This MUST be done for each media where > RTP and RTCP multiplexing is desired." If you think that you can do this without updating RFC 5761, I'm surprised. RFC 5761 envisages a world where mux-exclusive is an impossibility; clearly this is no longer the case. You describe a cage that we built for ourselves. We are perfectly able to use the same power that built that cage to dismantle it. In the end, it's just words. > SECOND, draft-ietf-mmusic-ice-sip-sdp mandates it. Now, that if obviously something we can change, but my understanding was that people didn't want to update 5761. Fixing ice-sip-sdp seems reasonable. Since the patient is still on the table, we have some time to retrieve the missing forceps. > THIRD, if ICE is not used to begin with, there will be no candidates, so a=rtcp-mux will obviously not produce the same result :) By which you mean you get RTP_port+1 for RTCP? This isn't strong motivation, since you will tear down a session immediately after discovering that they don't want mux and don't understand mux-exclusive. > FOURTH, and perhaps this is more theoretical, if you use trickle then a=rtcp-mux does not indicate whether RTCP candidates will come later or not. Yes, this is the one that I thought of. This is actually the best motivation to my mind, though again somewhat weak. Again, you only have a problem with a peer that doesn't want mux AND doesn't understand this spec. > We could of course say that one must not include a=rtcp, unless used together with a mechanism that requires it, and then we stop defining future mechanisms that use a=rtcp. I think that would be a fine thing to do. Again, since ice-sip-sdp is still in the working group, we should fix that while we are at it (add an exclusion for exclusive). Note that again, this is a box of our own design, we can decide to update those documents here. "The a=rtcp attribute MUST NOT be included unless other documents (other than RFC 5761) mandate its inclusion. If present, a=rtcp MUST include a port number of 9." Or something along those lines. From nobody Mon Feb 29 21:25:07 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 EB9A71ACDF8; Mon, 29 Feb 2016 21:25:04 -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.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160301052504.2966.13975.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 21:25:04 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-proto-iana-registration-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 05:25:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control 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-06.txt Pages : 8 Date : 2016-02-29 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-proto-iana-registration-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 29 21:27: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 610B81ACDFF for ; Mon, 29 Feb 2016 21:27:11 -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 TP7GHXsXYHbw for ; Mon, 29 Feb 2016 21:27:09 -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 62B191ACDBA for ; Mon, 29 Feb 2016 21:27:09 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id k196so158016833vka.0 for ; Mon, 29 Feb 2016 21:27:09 -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; bh=ZnWwUGcueh0xZX4bLGlLMKM46G/6ABf/ej0ge54WYT8=; b=KSglLy+OtsMQCDtXnI+kGGfgrK4XXAFQdFV1hP8T5J8LnWGFnNwInX4vJU4mQWAamI FdtW4xejuV/YloJc55ldZE2zjRiqUNBvECy7rK3EPwCZsSnDwcB1Ugjth/3Zean/145c OGuT5bWiM7gpqwTZeI/odqpcWo5wejzfMQPf2cmXTn6nAbFVI3Lh+5t0sxADXungfhhz sanpTihr3cmyt6h4agYxTmD++dfgXseDJx/vxfhiAIJambwg7v8P/Oup4CcdKlm4ax1Y KANFErPGBouO5Pbs1MBOsZI9BcSqHaqE4pkg5EU+tEkketaBcv5xof11pBDYCaGUS9aZ S3zQ== 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; bh=ZnWwUGcueh0xZX4bLGlLMKM46G/6ABf/ej0ge54WYT8=; b=cuGmtlaGkeW1HzTBQX3ag/GaubHDWyJnDcUiaZyH0XTeAb/Ym0n6hGDdZINDYQfc/g axao4xiFnM5WmKCMxL0m1fiZuobMHPfGOyycZ3Mw44O5JFwfGmH4Npi7qWTjToWq9d/I SmAkHK5CrVFqcYKeeG36jlIiGi3gvoAMnC7j0Tx6B+g+9rqHKYdgSFzTRhyNDSLbcD8q WZpp7528Y2uBPYBsGEYB9+cLyP1STzxxWbAE7g3PnibDASdT9ACdp5TrECYgnsqHsKRB fw2QMd0Paa3lhJDwdDqjhjtgK8/lKk08zQ5CdTbgRAVcQQvy+YPW4ewbb63l4KNZ3q3F +/hw== X-Gm-Message-State: AD7BkJJSvrrWglhENFlgsIb5nH4MZPoSmJ7Sz76Oke6G8S2lP6FA4oYE+lsez4f+cELRdSv0E6YAwTWSpJaVeA== MIME-Version: 1.0 X-Received: by 10.31.5.71 with SMTP id 68mr14231690vkf.25.1456810028513; Mon, 29 Feb 2016 21:27:08 -0800 (PST) Received: by 10.176.66.199 with HTTP; Mon, 29 Feb 2016 21:27:08 -0800 (PST) In-Reply-To: <20160301052504.2966.13975.idtracker@ietfa.amsl.com> References: <20160301052504.2966.13975.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 21:27:08 -0800 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=001a1143d2e0413f24052cf60473 Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-proto-iana-registration-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 05:27:11 -0000 --001a1143d2e0413f24052cf60473 Content-Type: text/plain; charset=UTF-8 Hello All The version -06 addresses SecDir, OpsDir review comments Thanks Suhas On Mon, Feb 29, 2016 at 9: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 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-06.txt > Pages : 8 > Date : 2016-02-29 > > 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-06 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-proto-iana-registration-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1143d2e0413f24052cf60473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 The version -06 addres= ses SecDir, OpsDir review comments

Thanks
Suhas=C2=A0

On Mon, Feb 29, 2016 at 9:25 PM, <internet-drafts@ietf.org= > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Multiparty Multimedia Session Control of t= he 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-06.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-02-29

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-06

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


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

--001a1143d2e0413f24052cf60473-- From nobody Mon Feb 29 23:52: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 A192A1A92E7; Mon, 29 Feb 2016 23:52:19 -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 4xH_K1cKtTqb; Mon, 29 Feb 2016 23:52:17 -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 9FFFF1ABD35; Mon, 29 Feb 2016 23:52:16 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-dc-56d54a2d4719 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.DF.20792.D2A45D65; Tue, 1 Mar 2016 08:52:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Tue, 1 Mar 2016 08:52:13 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt Thread-Index: AQHRapX1Z8HRswOqR0GYHJw2SIRNvp9BSLqAgAFtVhCAARBmgIAAfwvQ Date: Tue, 1 Mar 2016 07:52:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4E32C@ESESSMB209.ericsson.se> References: <56C63BE8.6000607@cisco.com> <7594FB04B1934943A5C02806D1A2204B37E4B32F@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+NgFprKIsWRmVeSWpSXmKPExsUyM2K7q66e19Uwg9v3OS0ubz3FavH+gq7F tTP/GC2mLn/M4sDiMeX3RlaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugStj9rebTAWb1CvW NjWzNzBuUOti5OSQEDCReHXgPwuELSZx4d56ti5GLg4hgcOMEjvXbmeBcBYxSkzsWgyU4eBg E7CQ6P6nDdIgIqArsejsA3aQGmaBBYwSR18fYAVJCAu4SCy9dIcZoshV4tDk9+wQtpvEhKWz wOIsAioSvyetZQaZySvgK3GjXQ1i1y9GiRk/NoHVcAoESjR2t4D1MgJd9/3UGiYQm1lAXOLW k/lMEFcLSCzZc54ZwhaVePn4HyuErSjR/rSBEWQ+s4CmxPpd+hCtihJTuh+CjeQVEJQ4OfMJ ywRGsVlIps5C6JiFpGMWko4FjCyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQIj6+CW31Y7 GA8+dzzEKMDBqMTDW3D2SpgQa2JZcWXuIUYJDmYlEd6tLlfDhHhTEiurUovy44tKc1KLDzFK c7AoifOyfbocJiSQnliSmp2aWpBaBJNl4uCUamB0D+monaXDN9+/7lCkms/XD60aydaf6iyX Ok3+6CG3X2j23lf3Hv9IDtvdp3eSK1FexvzjlrjlsyQzLIRi3m+4m2ZyvFTq6qy96rL/eJ9y LWE4fG79zqXvQ6xVeGb9FcrZ9v1bg3Bdo8i7L3P4Eq3DNAqK1r+Pum5dpX9M5FtzkepD1a+b PA2VWIozEg21mIuKEwGdBHdMqAIAAA== Archived-At: Cc: Flemming Andreasen , mmusic , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-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, 01 Mar 2016 07:52:19 -0000 SGksDQoNCj4+IEZJUlNULCBzZWN0aW9uIDUuMS4zIG9mIFJGQyA1NzYxIHNheXM6DQo+Pg0KPj4g ICAgIklmIGl0IGlzIGRlc2lyZWQgdG8gdXNlIGJvdGggSUNFIGFuZCBtdWx0aXBsZXhlZCBSVFAg YW5kIFJUQ1AsIHRoZQ0KPj4gICAgaW5pdGlhbCBvZmZlciBNVVNUIGNvbnRhaW4gYW4gImE9cnRj cC1tdXgiIGF0dHJpYnV0ZSB0byBpbmRpY2F0ZSB0aGF0DQo+PiAgICBSVFAgYW5kIFJUQ1AgbXVs dGlwbGV4aW5nIGlzIGRlc2lyZWQgYW5kIE1VU1QgY29udGFpbiAiYT1jYW5kaWRhdGU6Ig0KPj4g ICAgbGluZXMgZm9yIGJvdGggUlRQIGFuZCBSVENQIGFsb25nIHdpdGggYW4gImE9cnRjcDoiIGxp bmUgaW5kaWNhdGluZyBhDQo+PiAgICBmYWxsYmFjayBwb3J0IGZvciBSVENQIGluIHRoZSBjYXNl IHRoYXQgdGhlIGFuc3dlcmVyIGRvZXMgbm90IHN1cHBvcnQNCj4+ICAgIFJUUCBhbmQgUlRDUCBt dWx0aXBsZXhpbmcuICBUaGlzIE1VU1QgYmUgZG9uZSBmb3IgZWFjaCBtZWRpYSB3aGVyZQ0KPj4g ICAgUlRQIGFuZCBSVENQIG11bHRpcGxleGluZyBpcyBkZXNpcmVkLiINCj4NCj4gSWYgeW91IHRo aW5rIHRoYXQgeW91IGNhbiBkbyB0aGlzIHdpdGhvdXQgdXBkYXRpbmcgUkZDIDU3NjEsIEknbSBz dXJwcmlzZWQuICBSRkMgNTc2MSBlbnZpc2FnZXMgYSB3b3JsZCB3aGVyZSBtdXgtZXhjbHVzaXZl IGlzIGFuIGltcG9zc2liaWxpdHk7IGNsZWFybHkgdGhpcyBpcyBubyBsb25nZXIgdGhlIGNhc2Uu DQo+DQo+IFlvdSBkZXNjcmliZSBhIGNhZ2UgdGhhdCB3ZSBidWlsdCBmb3Igb3Vyc2VsdmVzLiAg V2UgYXJlIHBlcmZlY3RseSBhYmxlIHRvIHVzZSB0aGUgc2FtZSBwb3dlciB0aGF0IGJ1aWx0IHRo YXQgY2FnZSB0byBkaXNtYW50bGUgaXQuICBJbiB0aGUgZW5kLCBpdCdzIGp1c3Qgd29yZHMuDQoN CldlIGFncmVlZCBlYXJsaWVyIHRvIG5vdCB1cGRhdGUgZXhpc3RpbmcgbWVjaGFuaXNtcy4gSSB0 aGluayB3ZSBzaG91bGQga2VlcCA1NzYxIGl0IGFzIGl0IGlzLCBmb3IgYmFja3dhcmQgY29tcGF0 aWJpbGl0eSwgYmVjYXVzZSB0aGVyZSBhcmUgZGVwbG95bWVudHMgdGhhdCB1c2UgaXQuDQoNCj4+ IFNFQ09ORCwgZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAgbWFuZGF0ZXMgaXQuIE5vdywg dGhhdCBpZiBvYnZpb3VzbHkgc29tZXRoaW5nIHdlIGNhbiBjaGFuZ2UsIGJ1dCBteSB1bmRlcnN0 YW5kaW5nIHdhcyB0aGF0IHBlb3BsZSBkaWRuJ3Qgd2FudCB0byB1cGRhdGUgNTc2MS4NCj4NCj4g Rml4aW5nIGljZS1zaXAtc2RwIHNlZW1zIHJlYXNvbmFibGUuICBTaW5jZSB0aGUgcGF0aWVudCBp cyBzdGlsbCBvbiB0aGUgdGFibGUsIHdlIGhhdmUgc29tZSB0aW1lIHRvIHJldHJpZXZlIHRoZSBt aXNzaW5nIGZvcmNlcHMuDQoNCkFncmVlLiANCg0KPj4gVEhJUkQsIGlmIElDRSBpcyBub3QgdXNl ZCB0byBiZWdpbiB3aXRoLCB0aGVyZSB3aWxsIGJlIG5vIGNhbmRpZGF0ZXMsIA0KPj4gc28gYT1y dGNwLW11eCB3aWxsIG9idmlvdXNseSBub3QgcHJvZHVjZSB0aGUgc2FtZSByZXN1bHQgOikNCj4N Cj4gQnkgd2hpY2ggeW91IG1lYW4geW91IGdldCBSVFBfcG9ydCsxIGZvciBSVENQPyAgVGhpcyBp c24ndCBzdHJvbmcgbW90aXZhdGlvbiwgc2luY2UgeW91IHdpbGwgdGVhciBkb3duIGEgc2Vzc2lv biBpbW1lZGlhdGVseSBhZnRlciBkaXNjb3ZlcmluZyB0aGF0IHRoZXkgZG9uJ3Qgd2FudCBtdXgg YW5kIGRvbid0IHVuZGVyc3RhbmQgbXV4LWV4Y2x1c2l2ZS4NCg0KUGVvcGxlIGRpZCBub3Qgd2Fu dCBhIHNvbHV0aW9uIHdoZXJlIG9uZSBzdGFydHMgc2VuZGluZyBzdHVmZiBhbmQgdGhlbiByZWFs aXplIGl0IGRvZXNuJ3Qgd29yay4NCg0KQWxzbywgaW50ZXJtZWRpYXJpZXMgd2lsbCBtYXkgc3Rp bGwgcmVzZXJ2ZSByZXNvdXJjZXMgZm9yIFJUQ1AsIGFzIHRoZXkgZG9uJ3Qga25vdyB3aGV0aGVy IGl0IHdpbGwgYmUgdXNlZCBvciBub3QuDQoNCj4+IEZPVVJUSCwgYW5kIHBlcmhhcHMgdGhpcyBp cyBtb3JlIHRoZW9yZXRpY2FsLCBpZiB5b3UgdXNlIHRyaWNrbGUgdGhlbiBhPXJ0Y3AtbXV4IGRv ZXMgbm90IGluZGljYXRlIHdoZXRoZXIgUlRDUCBjYW5kaWRhdGVzIHdpbGwgY29tZSBsYXRlciBv ciBub3QuDQo+DQo+IFllcywgdGhpcyBpcyB0aGUgb25lIHRoYXQgSSB0aG91Z2h0IG9mLiAgVGhp cyBpcyBhY3R1YWxseSB0aGUgYmVzdCBtb3RpdmF0aW9uIHRvIG15IG1pbmQsIHRob3VnaCBhZ2Fp biBzb21ld2hhdCB3ZWFrLiAgQWdhaW4sIHlvdSBvbmx5IGhhdmUgYSBwcm9ibGVtIHdpdGggYSBw ZWVyIHRoYXQgZG9lc24ndCB3YW50IG11eCBBTkQgZG9lc24ndCB1bmRlcnN0YW5kIHRoaXMgc3Bl Yy4NCg0KSSB0aGluayB5b3Ugd291bGQgaGF2ZSBwcm9ibGVtIHdpdGggYW55IHBlZXIsIGJlY2F1 c2UgdGhleSBkb24ndCBrbm93IGlmIHRoZSBSVENQIGNhbmRpZGF0ZSB3aWxsIGNvbWUgbGF0ZXIg KGluIGNhc2Ugb2YgdHJpY2tsZSkgb3IgaWYgaXQgd29uJ3QgY29tZSBhdCBhbGwgKGluIGNhc2Ug b2YgZXhjbHVzaXZlLW11eCkuDQoNCj4+IFdlIGNvdWxkIG9mIGNvdXJzZSBzYXkgdGhhdCBvbmUg bXVzdCBub3QgaW5jbHVkZSBhPXJ0Y3AsIHVubGVzcyB1c2VkIHRvZ2V0aGVyIHdpdGggYSBtZWNo YW5pc20gdGhhdCByZXF1aXJlcyBpdCwgYW5kIHRoZW4gd2Ugc3RvcCBkZWZpbmluZyBmdXR1cmUg bWVjaGFuaXNtcyB0aGF0IHVzZSBhPXJ0Y3AuDQo+DQo+IEkgdGhpbmsgdGhhdCB3b3VsZCBiZSBh IGZpbmUgdGhpbmcgdG8gZG8uICBBZ2Fpbiwgc2luY2UgaWNlLXNpcC1zZHAgaXMgc3RpbGwgaW4g dGhlIHdvcmtpbmcgZ3JvdXAsIHdlIHNob3VsZCBmaXggdGhhdCB3aGlsZSB3ZSBhcmUgYXQgaXQg KGFkZCBhbiBleGNsdXNpb24gZm9yIGV4Y2x1c2l2ZSkuDQoNCkFncmVlLiBUaGF0IHdlIHNob3Vs ZCBkbyBubyBtYXR0ZXIgaG93IHdlIGluZGljYXRlIG11eC1leGNsdXNpdmUuDQoNCj4gTm90ZSB0 aGF0IGFnYWluLCB0aGlzIGlzIGEgYm94IG9mIG91ciBvd24gZGVzaWduLCB3ZSBjYW4gZGVjaWRl IHRvIHVwZGF0ZSB0aG9zZSBkb2N1bWVudHMgaGVyZS4gICJUaGUgYT1ydGNwIGF0dHJpYnV0ZSBN VVNUIE5PVCBiZSBpbmNsdWRlZCANCj51bmxlc3Mgb3RoZXIgZG9jdW1lbnRzIChvdGhlciB0aGFu IFJGQyA1NzYxKSBtYW5kYXRlIGl0cyBpbmNsdXNpb24uICBJZiBwcmVzZW50LCBhPXJ0Y3AgTVVT VCBpbmNsdWRlIGEgcG9ydCBudW1iZXIgb2YgOS4iICBPciBzb21ldGhpbmcgYWxvbmcgdGhvc2Ug bGluZXMuDQoNClN1cmUsIEkgY2FuIGFkZCB0ZXh0IGxpa2UgdGhhdCB0byB0aGUgZHJhZnQsIGFu ZCB3ZSBjYW4gdXBkYXRlIGljZS1zaXAtc2RwLg0KDQpCdXQsIGFnYWluLCBpdCB3YXMgZWFybGll ciBhZ3JlZWQgdG8gbm90IHVwZGF0ZSBleGlzdGluZyBtZWNoYW5pc21zIChSRkMgNTc2MSBldGMp LCBhbmQgSSByZWFsbHkgd291bGQgbm90IGxpa2UgdG8gY2hhbmdlIHRoYXQgZGVjaXNpb24gYXQg dGhpcyBwb2ludC4gVGhlIG5ldyBhdHRyaWJ1dGUgcHJvdmlkZXMgYW4gZXhwbGljaXQgaW5kaWNh dG9yLCBhbmQgaXMgbm90IGRlcGVuZGVudCBvbiBpY2UgY2FuZGlkYXRlcyBldGMuIEFsc28sIGl0 J3MganVzdCBhbiBTRFAgYXR0cmlidXRlLCBzbyBpdCdzIG5vdCBhIG1ham9yIHRoaW5nIHRvIGlt cGxlbWVudC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg==

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 8:57 PM, Christian Gr= oves <Christian.Groves@nteczone.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hello

I think the fact that the draft doesn't support DTLS-over-SCTP has been= known for some time. No one has been pushing for its inclusion. I'd be= happy if it was left out to be able to progress the draft.

Alternatively we can do what I think Albrecht is suggesting. Reserve proto = values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate their use= by SDP should be defined in a future specification. I don't think its = worth solving that problem now.

Regards, Christian

On 9/02/2016 7:45 AM, Christer Holmberg wrote:

Hi,

> The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully com= patible with draft-ietf-mmusic-dtls-sdp.

> In particular, RFC 6083 does not allow DTLS association span across mu= ltiple SCTP associations, but

> draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association through= a transport change. The most likely

> solution to this is updating RFC 6083, but, if no one is using DTLS-ov= er-SCTP, it would be easier just to say

> that DTLS-over-SCTP is not supported.

 **If** we decide to keep DTLS-over-SCTP in the draft, my suggestion would b= e to say that =E2=80=9CDTLS preservation over transport change=E2=80=9D doe= s not apply to DTLS-over-SCTP, with a reference to RFC 6083.

Then, if someone at some point updates RFC 6083, the SCTP-SDP spec also has= to be updated.

I do NOT want to delay draft-sctp-sdp until a possible RFC 6083 update has = been done (assuming people would agree to do it in the first place).

Regards,

Christer

_____________
Roman Shpount

 On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) <albrecht.schwarz@n= okia.com <mailto:albrecht.schwarz@nokia.com>> wrote:

=C2=A0 =C2=A0 Hello Christer,

=C2=A0 =C2=A0 the titel of the (future) RFC will not exclude any SCTP trans= port
=C2=A0 =C2=A0 modes.

=C2=A0 =C2=A0 And a comprehensive and future safe protocol specification sh= ould
=C2=A0 =C2=A0 cover all existing ones, which is =E2=80=9CDTLS/SCTP/IP=E2=80= =9D as well as
=C2=A0 =C2=A0 =E2=80=9CSCTP/UDP/IP=E2=80=9D (RFC 6951).

=C2=A0 =C2=A0 These two SCTP transport modes should be indicated as well, =C2=A0 =C2=A0 independent of potential intentions to be used soon.

=C2=A0 =C2=A0 Codepoint space could be reserved, placeholder sections tagge= d as
=C2=A0 =C2=A0 =E2=80=9Cnot yet supported=E2=80=9D of =E2=80=9Cfor further s= tudies=E2=80=9D, etc, but the worst
=C2=A0 =C2=A0 case would be any kind of interaction issues in future.

=C2=A0 =C2=A0 My view,

=C2=A0 =C2=A0 Albrecht

 =C2=A0 =C2=A0 *From:*mmusic [mailto:mmusic-bounces@ietf.org
=C2=A0 =C2=A0 <mailto:mmusic-bounces@ietf.org>] *On Behalf Of *EXT Christer Ho= lmberg
=C2=A0 =C2=A0 *Sent:* Montag, 8. Februar 2016 15:33
=C2=A0 =C2=A0 *To:* mmusic <mmusic@ietf.org <mailto:mmusic@ietf.org>>
=C2=A0 =C2=A0 *Subject:* [MMUSIC] DTLS-over-SCTP, anyone?<= br>
=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A
=C2=A0 =C2=A0 procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.

=C2=A0 =C2=A0 As we know, SCTP-over-DTLS is used for the WebRTC data channe= l.

=C2=A0 =C2=A0 My question is: does anyone intend to use DTLS-over-SCTP?

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Christer


=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