From nobody Thu Jun 1 00:20:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32301294F4; Thu, 1 Jun 2017 00:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFMJKGVBCrKV; Thu, 1 Jun 2017 00:20:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C39612AF6E; Thu, 1 Jun 2017 00:20:11 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-76-592fc02941b9 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.44.19050.920CF295; Thu, 1 Jun 2017 09:20:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Thu, 1 Jun 2017 09:17:55 +0200 From: Christer Holmberg To: Cullen Jennings , Ben Campbell CC: Eric Rescorla , Roman Shpount , "Martin Thomson" , "mmusic-chairs@ietf.org" , mmusic Thread-Topic: [MMUSIC] Fwd: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHS2ldELwNcYwD50E6oSow85173oqIPrDeA Date: Thu, 1 Jun 2017 07:17:54 +0000 Message-ID: References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> In-Reply-To: <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="Windows-1252" Content-ID: <096224745518964BB6BA81B56CA504A7@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUyM2K7pa7mAf1IgwXXLSzmd55mt1jx+hy7 xYf1Pxgtrp35x2hxfud6Joupyx+zWMy4MJXZgd1j56y77B5Llvxk8rh8/iOjx6ydT1g8Jj9u Y/a4NaUggC2KyyYlNSezLLVI3y6BK+Pi5wa2gnciFXOP5zQwHhHoYuTkkBAwkZj9eBpbFyMX h5DAEUaJ9tYWFghnEaPExQ+H2LsYOTjYBCwkuv9pgzSICDhLtG9dzw5SwyxwkFHi86VmRpCE sEC9xLrHq1lBEiICDYwSj/p+sIA0iwgYSaxslQWpYRFQkVj9vpcFxOYVsJa4PuMC1LIFjBI3 u5aADeIUsJJ4+mc7K4jNKCAm8f3UGiYQm1lAXOLWk/lMEGcLSCzZc54ZwhaVePn4HyvILlEB PYl3+z0hwooSH1/tY4RoNZB4f24+M4RtLXHuyH6okdoSyxa+Zoa4R1Di5MwnLBMYxWch2TYL SfssJO2zkLTPQtK+gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgHB/c8ttqB+PB546H GAU4GJV4eBn260cKsSaWFVfmHmKU4GBWEuHlqwQK8aYkVlalFuXHF5XmpBYfYpTmYFES53XY dyFCSCA9sSQ1OzW1ILUIJsvEwSnVwLjhR07MjZ7Kxw/c/C4YizTPcz/WPCXoiXzxpRO1Pddy xd1T3SYJKXBuyZob1dA09w5HT/vlwgVW3Mwb8rdrfX0crnszMf3VhNdxiS1rLsWoMQRZZJ45 dcFPNWN/xwOTk2Jnyh6Uu8t8D5O9PkvCTKag5jD3yS+m/O/v8Mbr3fpw1ruo5K1XihJLcUai oRZzUXEiAKqaOZTfAgAA Archived-At: Subject: Re: [MMUSIC] Fwd: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 07:20:17 -0000 Hi, >No ... the draft (with the PR) does not work. The key issue is the line > > However, the offerer MUST NOT > complete the DTLS handshake before it has received the SDP answer. > >This breaks the usage of DTLS-SRTP with SIP and is not needed. The >argument that you should not send media before you know who it is going >to is not the problem. The key issue is that some times an SIP UA needs >to be able to receive media before it knows who it is from. Of course the >UA should indicate in the caller ID etc that it is does not know who it >is from. It might be really reasonable for the UA not to send any human >generated media before it get the the dtls-id in the offer/answer, and >validate any identity assertions, and validates in the certificates are >not revoked, and whatever else the UA wants to to but the spec should not >forbid receiving information while that is all happening. And to receive >media, it needs to complete the DTLS handshake. > >Let me ask, for your average call flow that uses PRACK, do we think that >call flow would work if we said there could not be any media before the >Answer was received ? I am aware of systems, especially SBCs and media gating devices, that will not accept media until the answer has been received - PRACK or no PRACK. Having said that, I am staying neutral in this case - I just want text that everyone can live with, so we can get the draft done... >I'm sure the next issue is just my confusion but I was under the >impression this would help solve the unauthenticated keying problem fro >DTLS-SRTP. But the dtls-id in this draft never get tied to anything in >the TLS session. Is that specified elsewhere? Do we need a ref to it ? The original intention of the id was to be able to indicate whether a new association is to be established. Martin=B9s draft, draft-thomson-mmusic-sdp-uks, extends the usage, but we earlier agreed that we are not going to reference it from draft-dtls-sdp. >One other issues ... It seems that this removes from RFC5763 the line > > The SIP message containing the offer SHOULD be sent to > the offerer's SIP proxy over an integrity protected channel. > >from RFC 5763. Any reason for that? Seems like the fingerprint should >still be integrity protected. The text was removed based on a comment in Ben=B9s AD review (14th March): "-9.2, paragraph 5: "The SIP message containing the offer SHOULD be sent To the offerer=B9s SIP proxy over an integrity protected channel": This seems redundant with a previous statement 2 sentences back. (Yes, this was in the original text=8A)" Regards, Christer From nobody Fri Jun 2 06:47:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB36E12EBB3 for ; Fri, 2 Jun 2017 06:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.624 X-Spam-Level: X-Spam-Status: No, score=-12.624 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emw6zbLl8V-j for ; Fri, 2 Jun 2017 06:47:40 -0700 (PDT) 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 C4710120721 for ; Fri, 2 Jun 2017 06:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=593; q=dns/txt; s=iport; t=1496411260; x=1497620860; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=CypAspg+g0LpAMqhZ5YCpHK92ju03ZD/i9S10wxBZTs=; b=Bt1YyrX6eEDJkuXgI68S9WMmsM7tpxF6EbrXeoFJES+KcnWlp4SJIgBC S6iWTvrGHBpggx/ZbVDJNpL1k8QYNw1s83LUO3XzfmDeaR9k0y1Vuc2kR bAnIXLGmZ1Lh8jjM1zdT5rKJfYjidZqVB1OLNXx4uraLDo353TlBUF16h E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AwCfazFZ/5ldJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1eFYrIOgg+JIUAXAQIBAQEBAQEBayiFQhU2QAImAl8NCAEBihkNnwCQC4I?= =?us-ascii?q?mi1ABAQEHAiaBC4VWgguKcIJgAQSeL4FbkVCBbokehm6UXCECNIEKUSMVRochJ?= =?us-ascii?q?IopAQEB?= X-IronPort-AV: E=Sophos;i="5.39,285,1493683200"; d="scan'208";a="434199040" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2017 13:47:40 +0000 Received: from [10.118.10.22] (rtp-fandreas-2-8815.cisco.com [10.118.10.22]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v52Dldbs018329 for ; Fri, 2 Jun 2017 13:47:40 GMT To: mmusic From: Flemming Andreasen Message-ID: <75cd540c-2a5e-9c93-ad47-48854b3d84fd@cisco.com> Date: Fri, 2 Jun 2017 09:47:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] Preparing for Prague (IETF 99) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 13:47:42 -0000 Greetings MMUSIC IETF 99 will take place July 16-21 in Prague. We have requested a 2.5 hour meeting slot for MMUSIC, 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. 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 Jun 2 09:44:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE87126CE8 for ; Fri, 2 Jun 2017 09:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfMNo8EUSpeG for ; Fri, 2 Jun 2017 09:44:45 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 30A09126C25 for ; Fri, 2 Jun 2017 09:44:45 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id r66so19339896yba.2 for ; Fri, 02 Jun 2017 09:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ehpBBhgDTkZix/cr2VpJb94QdEZg3HQbqZYHxmq4FLk=; b=c9NNgTsQTaE4/WfABG5sG+ouI9NSD+XxchQFvM6Ag3XVaTE0lsf72bI+YaXax5kor9 OgoAopNS3HIANuuRy4q2bI7Iuk5jbsxZjB0x5omoVw1BkArsPO4vPTlYRR5TOJr6VF6a oMC5HEvGHE168xFQIZSHSzn1Lj22KVoENir99eu0fIJ4BtPr19GdKc5UP9y8Tw2Xhyz0 iqh66pJUrwspZ2LQLbvXDAV1ujy+7To5F8/DBrp4iCcMGVSVgtK5qQ3iKiOC7Sqf/Tbk he+tSUF3Xm00C/gL2+z3MMz9l+YSIPKvarS0ssw+8/5VZW9EGI2SK4S9j7AlUSq10YWQ Sd5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ehpBBhgDTkZix/cr2VpJb94QdEZg3HQbqZYHxmq4FLk=; b=e87p1Aw+IL+yvNnCJggTzOGSSFZCrfLjtFFAgzychbfOFLKiyKoXo6AyLbzJZHKBVf wADqjWpI/6Kikz0q0mLGxv1CZRApxKIOWge8M5yMAoz9Usb1YjRziFFMwwc3nF9l8P95 SmZnrTQvqH5xsMshc62EJSPCtRr43YB4U406hAJC2mADnfKELKqL3UvBGK3cyozKPzsq Fzg23rkGkCz21ECoN2hGMe0ksuRWrSu3xItxrvLcdSwY1n2jUWhR2e/ghwJgPXbxCFiY vOSryG7m3Fz0PObV2cUnVCtLGyzFsF+YJL3MXGD2uJmtNXfV7xqEzLnKwkf+qfK1Brfn MeoA== X-Gm-Message-State: AODbwcCJ/NXriYc0r9mFAoPW8Zqi+cVUEACgtHZ/Iq805zjq6avhh2IT 0Gyjs0On/XwJ1VXIaxmQRlWRF1SILo+eA75wxw== X-Received: by 10.37.30.135 with SMTP id e129mr611327ybe.71.1496421884216; Fri, 02 Jun 2017 09:44:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.137 with HTTP; Fri, 2 Jun 2017 09:44:03 -0700 (PDT) From: Eric Rescorla Date: Fri, 2 Jun 2017 09:44:03 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary="001a1143f2f2d7fe570550fcde85" Archived-At: Subject: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:44:47 -0000 --001a1143f2f2d7fe570550fcde85 Content-Type: text/plain; charset="UTF-8" Hi folks, RFC 5763 required (and JSEP imported) that all offers include a=setup:actpass However, assuming I am reading: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 correctly, S 4.2 allows the initial offer to contain anything, though encourages actpass: When an offerer sends the initial offer, the offerer MUST insert an SDP 'setup' attribute according to the procedures in [RFC4145], and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique value. If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 'passive' attribute value, the offerer MUST be prepared to receive a DTLS ClientHello message (if a new DTLS association is established by the answerer) from the answerer before the offerer receives the SDP answer. For subequent offers, it also gives flexibility but points at 4145. So... 1. Changing the behavior for initial offers seems like it presents a serious interop risk, because previously you could depend on the offer being actpass. 2. JSEP requires actpass for all offers, so at least it's stricter. What was the rationale for these changes? Feel free to point me at the mailing list discussion where that happened. -Ekr Hi folks, RFC 5763 required (and JSEP imported) that all offers include a=setup:actpass However, assuming I am reading: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 correctly, S 4.2 allows the initial offer to contain anything, though encourages actpass: When an offerer sends the initial offer, the offerer MUST insert an SDP 'setup' attribute according to the procedures in [RFC4145], and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique value. If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 'passive' attribute value, the offerer MUST be prepared to receive a DTLS ClientHello message (if a new DTLS association is established by the answerer) from the answerer before the offerer receives the SDP answer. For subequent offers, it also gives flexibility but points at 4145. So... 1. Changing the behavior for initial offers seems like it presents a serious interop risk, because previously you could depend on the offer being actpass. 2. JSEP requires actpass for all offers, so at least it's stricter. What was the rationale for these changes? Feel free to point me at the mailing list discussion where that happened. -Ekr --001a1143f2f2d7fe570550fcde85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

RFC 5763 required = (and JSEP imported) that all offers include

=C2=A0= a=3Dsetup:actpass

However, assuming I am reading:=
=C2=A0 https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24<= /div>
=C2=A0=C2=A0
correctly, S 4.2 allows the initial offer = to contain anything,
though encourages actpass:

=C2=A0 =C2=A0When an offerer sends the initial offer, the offerer M= UST insert an
=C2=A0 =C2=A0SDP 'setup' attribute accordin= g to the procedures in [RFC4145], and
=C2=A0 =C2=A0one or more SD= P 'fingerprint' attributes according to the procedures
= =C2=A0 =C2=A0in [RFC8122].=C2=A0 In addition, the offerer MUST insert in th= e offer an
=C2=A0 =C2=A0SDP 'tls-id' attribute with a uni= que value.

=C2=A0 =C2=A0If the offerer inserts the= SDP 'setup' attribute with an 'actpass' or
=C2= =A0 =C2=A0'passive' attribute value, the offerer MUST be prepared t= o receive a
=C2=A0 =C2=A0DTLS ClientHello message (if a new DTLS = association is established by
=C2=A0 =C2=A0the answerer) from the= answerer before the offerer receives the SDP
=C2=A0 =C2=A0answer= .

For subequent offers, it also gives flexibility = but points at 4145.


So...

1. Changing the behavior for initial offers seems like it p= resents
a serious interop risk, because previously you could depe= nd on
the offer being actpass.

2. JSEP r= equires actpass for all offers, so at least it's stricter.

What was the rationale for these changes? Feel = free to point me at the
mailing list discussion where that happen= ed.

-Ekr
=C2=A0Hi folks,

<= /div>
RFC 5763 required (and JSEP imported) that all offers include

=C2=A0 a=3Dsetup:actpass

How= ever, assuming I am reading:
=C2=A0=C2=A0
correctly, S 4= .2 allows the initial offer to contain anything,
though encourage= s actpass:

=C2=A0 =C2=A0When an offerer sends the = initial offer, the offerer MUST insert an
=C2=A0 =C2=A0SDP 's= etup' attribute according to the procedures in [RFC4145], and
=C2=A0 =C2=A0one or more SDP 'fingerprint' attributes according to= the procedures
=C2=A0 =C2=A0in [RFC8122].=C2=A0 In addition, the= offerer MUST insert in the offer an
=C2=A0 =C2=A0SDP 'tls-id= ' attribute with a unique value.

=C2=A0 =C2=A0= If the offerer inserts the SDP 'setup' attribute with an 'actpa= ss' or
=C2=A0 =C2=A0'passive' attribute value, the of= ferer MUST be prepared to receive a
=C2=A0 =C2=A0DTLS ClientHello= message (if a new DTLS association is established by
=C2=A0 =C2= =A0the answerer) from the answerer before the offerer receives the SDP
=C2=A0 =C2=A0answer.

For subequent offers, i= t also gives flexibility but points at 4145.


<= /div>
So...

1. Changing the behavior for initi= al offers seems like it presents
a serious interop risk, because = previously you could depend on
the offer being actpass.

2. JSEP requires actpass for all offers, so at least it'= ;s stricter.


What was the rationale= for these changes? Feel free to point me at the
mailing list dis= cussion where that happened.

-Ekr
=C2=A0=
--001a1143f2f2d7fe570550fcde85-- From nobody Fri Jun 2 11:02:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48234128D6F for ; Fri, 2 Jun 2017 11:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0dPf701cu1H for ; Fri, 2 Jun 2017 11:02:19 -0700 (PDT) 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 8DCF212894A for ; Fri, 2 Jun 2017 11:02:19 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e193so54274963pfh.0 for ; Fri, 02 Jun 2017 11:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WD6H2ChKc0C7T/ILQ2DgJfdDy4OX/VQoPqISvt6JTYw=; b=dLTjXXPFQw0W+7/4eY+Uhxm3+mh2OAk2d7BragiZoQ78TIROqeE5gsgxMAfg0Xj4GW FZYq3JzROz4H+EFZpb6fqNEebnFJBsbK5/VCKBzAkaUvbFonMXV2EiJ89DzLUKQKzUM2 u7Vx6Lape6tNQRXstC3XwNbZQD1b2ff7RswRXtwSkSwrq3XfU5A0YJBroiwhb0vkosoJ H69vLpi8AjhlJDK3AtGZVNHABCCAKP8VgGzjsmotkCtGOBEfpMsOzX9z1A6AOLcL5x6u Wt2LaJ0YMLukMo1mqfvwjTt0agLP5V9JkJp934Xn4+x/W5VS/yXlgwfp26OpUlI0Zobt SLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WD6H2ChKc0C7T/ILQ2DgJfdDy4OX/VQoPqISvt6JTYw=; b=bZOkkxHk9ik9DA6FDaRHmETBrG+k5KZEp1gfryh2KH+Vr83zQVhWsJNqo3Kf+X7KlL r/6GrtyTVpXPLy6foH0dH+mTtssPl0NFLIzXG5lUGCHq1qgueQuI2FQDz8EH2KlWpVJ5 +LS1ypBaMtwaJQ+6MGVCMWE5knKWFCBmYz452CKrDEXEq7n5N8o7w2h0KigkRsc3srYH YEtb2QxqpoLUYHvD1K2u54dAZZvB+2+foTcri/BEW/wzMDnjAXBYs4v7MMao7gyTsQBj mCIZtSF7MnIVEd1KhLxrVeA0QSDcfjGTwoO0iL0TI5MyS+jlXrdvFCkjWuH3eG1qmC1L n+XA== X-Gm-Message-State: AODbwcCebqy151x98oIeyuyFASDvPQElowjQcKka9RrnmSzxGa9vyGgt P0h6rzgaHogownicBuY= X-Received: by 10.99.113.78 with SMTP id b14mr8335785pgn.229.1496426538816; Fri, 02 Jun 2017 11:02:18 -0700 (PDT) Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com. [209.85.192.171]) by smtp.gmail.com with ESMTPSA id n7sm41467649pfk.74.2017.06.02.11.02.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 11:02:18 -0700 (PDT) Received: by mail-pf0-f171.google.com with SMTP id e193so54274571pfh.0 for ; Fri, 02 Jun 2017 11:02:18 -0700 (PDT) X-Received: by 10.84.225.146 with SMTP id u18mr1074452plj.264.1496426537961; Fri, 02 Jun 2017 11:02:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Fri, 2 Jun 2017 11:02:17 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Fri, 2 Jun 2017 14:02:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: mmusic WG Content-Type: multipart/alternative; boundary="f403045ec5403a4f2c0550fdf4bf" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 18:02:21 -0000 --f403045ec5403a4f2c0550fdf4bf Content-Type: text/plain; charset="UTF-8" Hi All, There was a discussion regarding the setup attribute value in subsequent offers when establishing new DTLS association is not desired. Based on that discussion it was decided that setup value can be either currently negotiated value or actpass. There are also UDP/DTLS without STUN NAT traversal scenarios that only work when end point behind NAT is active. I think sending actpass in offers is a generally safer option, but I think SHOULD here is more appropriate then MUST. Please note that https://tools.ietf.org/html/rfc5763#section-5 says: The endpoint MUST use the setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer. This applies not only to initial but to ALL offers. Finally, I can double check, but I am fairly sure there are current implementation that violate this rule. Regards, _____________ Roman Shpount On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla wrote: > Hi folks, > > RFC 5763 required (and JSEP imported) that all offers include > > a=setup:actpass > > However, assuming I am reading: > https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 > > correctly, S 4.2 allows the initial offer to contain anything, > though encourages actpass: > > When an offerer sends the initial offer, the offerer MUST insert an > SDP 'setup' attribute according to the procedures in [RFC4145], and > one or more SDP 'fingerprint' attributes according to the procedures > in [RFC8122]. In addition, the offerer MUST insert in the offer an > SDP 'tls-id' attribute with a unique value. > > If the offerer inserts the SDP 'setup' attribute with an 'actpass' or > 'passive' attribute value, the offerer MUST be prepared to receive a > DTLS ClientHello message (if a new DTLS association is established by > the answerer) from the answerer before the offerer receives the SDP > answer. > > For subequent offers, it also gives flexibility but points at 4145. > > > So... > > 1. Changing the behavior for initial offers seems like it presents > a serious interop risk, because previously you could depend on > the offer being actpass. > > 2. JSEP requires actpass for all offers, so at least it's stricter. > > > What was the rationale for these changes? Feel free to point me at the > mailing list discussion where that happened. > > -Ekr > Hi folks, > > RFC 5763 required (and JSEP imported) that all offers include > > a=setup:actpass > > However, assuming I am reading: > https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 > > correctly, S 4.2 allows the initial offer to contain anything, > though encourages actpass: > > When an offerer sends the initial offer, the offerer MUST insert an > SDP 'setup' attribute according to the procedures in [RFC4145], and > one or more SDP 'fingerprint' attributes according to the procedures > in [RFC8122]. In addition, the offerer MUST insert in the offer an > SDP 'tls-id' attribute with a unique value. > > If the offerer inserts the SDP 'setup' attribute with an 'actpass' or > 'passive' attribute value, the offerer MUST be prepared to receive a > DTLS ClientHello message (if a new DTLS association is established by > the answerer) from the answerer before the offerer receives the SDP > answer. > > For subequent offers, it also gives flexibility but points at 4145. > > > So... > > 1. Changing the behavior for initial offers seems like it presents > a serious interop risk, because previously you could depend on > the offer being actpass. > > 2. JSEP requires actpass for all offers, so at least it's stricter. > > > What was the rationale for these changes? Feel free to point me at the > mailing list discussion where that happened. > > -Ekr > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --f403045ec5403a4f2c0550fdf4bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,<= /span>

There was a discussion regarding the= setup attribute value in subsequent offers when establishing new DTLS asso= ciation is not desired. Based on that discussion it was decided that setup = value can be either currently negotiated value or actpass.=C2=A0There are also UDP/DTLS without STUN NAT traversal sc= enarios that only work when end point behind NAT is active. I think sending= actpass in offers is a generally safer option, but I think SHOULD here is = more appropriate then MUST.

Please note that=C2=A0https://tools.ietf.org/html/rfc5763#section-5 says= :

The endpoint MUST use the setup attribute defined in [= RFC4145]. The endpoint that is the offerer MUST use the setup attribute val= ue of setup:actpass and be prepared to receive a client_hello before it rec= eives the answer.

This applies= not only to initial but to ALL offers.

Finally, I can double check, but I am fairly sure there are current impl= ementation that violate this rule.

Re= gards,

_____________Roman Shpount

On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescor= la <= ekr@rtfm.com> wrote:
Hi folks,

RFC 5763 required (and J= SEP imported) that all offers include

=C2=A0 a=3Ds= etup:actpass

However, assuming I am reading:
=
=C2=A0=C2=A0
correctly, S 4.2 allows t= he initial offer to contain anything,
though encourages actpass:<= /div>

=C2=A0 =C2=A0When an offerer sends the initial off= er, the offerer MUST insert an
=C2=A0 =C2=A0SDP 'setup' a= ttribute according to the procedures in [RFC4145], and
=C2=A0 =C2= =A0one or more SDP 'fingerprint' attributes according to the proced= ures
=C2=A0 =C2=A0in [RFC8122].=C2=A0 In addition, the offerer MU= ST insert in the offer an
=C2=A0 =C2=A0SDP 'tls-id' attri= bute with a unique value.

=C2=A0 =C2=A0If the offe= rer inserts the SDP 'setup' attribute with an 'actpass' or<= /div>
=C2=A0 =C2=A0'passive' attribute value, the offerer MUST = be prepared to receive a
=C2=A0 =C2=A0DTLS ClientHello message (i= f a new DTLS association is established by
=C2=A0 =C2=A0the answe= rer) from the answerer before the offerer receives the SDP
=C2=A0= =C2=A0answer.

For subequent offers, it also gives= flexibility but points at 4145.


So= ...

1. Changing the behavior for initial offers se= ems like it presents
a serious interop risk, because previously y= ou could depend on
the offer being actpass.

<= div>2. JSEP requires actpass for all offers, so at least it's stricter.=


What was the rationale for these c= hanges? Feel free to point me at the
mailing list discussion wher= e that happened.

-Ekr
=C2=A0Hi folks,

RFC 5763 required (and JSEP imported) that all offer= s include

=C2=A0 a=3Dsetup:actpass

<= /div>
However, assuming I am reading:
= =C2=A0=C2=A0
correctly, S 4.2 allows the initial offer to contain= anything,
though encourages actpass:

= =C2=A0 =C2=A0When an offerer sends the initial offer, the offerer MUST inse= rt an
=C2=A0 =C2=A0SDP 'setup' attribute according to the= procedures in [RFC4145], and
=C2=A0 =C2=A0one or more SDP 'f= ingerprint' attributes according to the procedures
=C2=A0 =C2= =A0in [RFC8122].=C2=A0 In addition, the offerer MUST insert in the offer an=
=C2=A0 =C2=A0SDP 'tls-id' attribute with a unique value.=

=C2=A0 =C2=A0If the offerer inserts the SDP '= setup' attribute with an 'actpass' or
=C2=A0 =C2=A0&#= 39;passive' attribute value, the offerer MUST be prepared to receive a<= /div>
=C2=A0 =C2=A0DTLS ClientHello message (if a new DTLS association = is established by
=C2=A0 =C2=A0the answerer) from the answerer be= fore the offerer receives the SDP
=C2=A0 =C2=A0answer.
=
For subequent offers, it also gives flexibility but points a= t 4145.


So...

<= div>1. Changing the behavior for initial offers seems like it presents
a serious interop risk, because previously you could depend on
<= div>the offer being actpass.

2. JSEP requires actp= ass for all offers, so at least it's stricter.


What was the rationale for these changes? Feel free to poin= t me at the
mailing list discussion where that happened.

-Ekr
=C2=A0

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

--f403045ec5403a4f2c0550fdf4bf-- From nobody Fri Jun 2 11:28:25 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8FD12955D for ; Fri, 2 Jun 2017 11:28:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149642810420.31788.15179705279257677096.idtracker@ietfa.amsl.com> Date: Fri, 02 Jun 2017 11:28:24 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 18:28:24 -0000 Changed milestone "Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Informational", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Fri Jun 2 13:28:57 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6D1129AB3 for ; Fri, 2 Jun 2017 13:28:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149643533557.31749.17987036780969368507.idtracker@ietfa.amsl.com> Date: Fri, 02 Jun 2017 13:28:55 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:28:55 -0000 Changed milestone "Submit Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile as Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Fri Jun 2 14:16:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7601201FA for ; Fri, 2 Jun 2017 14:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqssSl-iXfJS for ; Fri, 2 Jun 2017 14:16:16 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 42A1412714F for ; Fri, 2 Jun 2017 14:16:16 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id n23so57063202pfb.2 for ; Fri, 02 Jun 2017 14:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xBT6iSXCR/cLIDv9Zyhfq2PazoQkQMGi7lZ/2RE9SAs=; b=TKNgHDbEUo9V0PrbqGi5IpH8gVqZxF6KekdpBhOl25+xDyh0GYWvZko1iL02vOzW6Z rgnY8tXuhQ25N9KAP6Y+x5rw8LXIVRqKVnMeg+zv/1tLOlb+0cblAS0SmnKhmjUju41T tAPq0/Ne1rgk30IX4l2Ae5sc8YLoxi3SbN/spM+jbLsPxVIp/yGpez01KmWN0K7IKT1q 4HQbHoalQwokhPwZRyVN7CTjacOYtE4zzEUnrglEzWmZdR98qQeYaY94oBas/jDjX7ce YPBrEb0kFZKDLEinLUwy1OI0o6sSN8M2MMwalUFBhOcdqvcDz+uUdZBlyvl979gFuBk+ 8AUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xBT6iSXCR/cLIDv9Zyhfq2PazoQkQMGi7lZ/2RE9SAs=; b=NsVpmtDzWbgX4vuFXswhLSxTMNMSu9yDPVZ4qrhwow+z+lGHfXH/Nzs0vT3YCwc8RW y6sViXqLrmUaTwVczP52ZoazQK6j5cpcjxfRd0lxQh+huQCRQzINwLkiU7+DL5tt61iV 4DfKXNxTn2uo/lGR9KE1apxzSpz8eoLJvUL9E54F6bYJ067mHyVZ7sndUHJOUxyXYhg4 e2K9KgAD4FuHBZlELF3I7jr71K1gf1yJz4ELjWBRULjX8j/nIrPw+B3qHlt7wgWWde1m R3H3ItcNZENAo83tWMObC/u+Sdbnd4kxyAHJzfWZ7wmUqtxo0MAStpApKCimhj3QNVYQ 9wIw== X-Gm-Message-State: AODbwcB9/4LPtSql8v/icljwJkpyrEkQMXo53YVhavYY8F7nwg9PtW7F rwj9/Cksk5cqGJuxyok= X-Received: by 10.84.216.23 with SMTP id m23mr1697733pli.268.1496438175615; Fri, 02 Jun 2017 14:16:15 -0700 (PDT) Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com. [74.125.83.42]) by smtp.gmail.com with ESMTPSA id w2sm3242080pfb.18.2017.06.02.14.16.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 14:16:15 -0700 (PDT) Received: by mail-pg0-f42.google.com with SMTP id x64so12173282pgd.3 for ; Fri, 02 Jun 2017 14:16:15 -0700 (PDT) X-Received: by 10.99.114.66 with SMTP id c2mr9176627pgn.130.1496438174747; Fri, 02 Jun 2017 14:16:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Fri, 2 Jun 2017 14:16:14 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Fri, 2 Jun 2017 17:16:14 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: mmusic WG Content-Type: multipart/alternative; boundary="f403045c56cad596aa055100a9bd" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 21:16:19 -0000 --f403045c56cad596aa055100a9bd Content-Type: text/plain; charset="UTF-8" Just to provide the historic background for this change. We have discussed setup role in subsequent offers with Christer before IETF95 and decided to remove the text that setup MUST be actpass in all the offers. This removed this requirement from the initial offers as well (even though they weren't discussed at that time). Now we have three options: 1. setup can be whatever application wants in all offers (current text) 2. setup MUST be actpass in initial offer and whatever application wants in subsequent (or, alternatively actpass or negotiated role in subsequent offers). 3. setup MUST be actpass in all the offers (back to RFC 5763) My top preference is that setup SHOULD be actpass in all the offers. Second preference is 1 and hope that application will do the right thing. >From my point of view 2 is strange, since there is no principal difference between initial and subsequent offers, especially when 3pcc comes into play. Any offer can end up being subsequent for one end point and initial for another. I also think that RFC 5763 requirement is too strong. There are implementations which send offers without actpass so it is already violated. There are also legitimate scenarios where sending current role (subsequent offers without ICE restart) or active (endpoints with basic UDP behind NAT) makes more sense. Regards, _____________ Roman Shpount On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount wrote: > Hi All, > > There was a discussion regarding the setup attribute value in subsequent > offers when establishing new DTLS association is not desired. Based on that > discussion it was decided that setup value can be either currently > negotiated value or actpass. There are also UDP/DTLS without STUN NAT > traversal scenarios that only work when end point behind NAT is active. I > think sending actpass in offers is a generally safer option, but I think > SHOULD here is more appropriate then MUST. > > Please note that https://tools.ietf.org/html/rfc5763#section-5 says: > > The endpoint MUST use the setup attribute defined in [RFC4145]. The > endpoint that is the offerer MUST use the setup attribute value of > setup:actpass and be prepared to receive a client_hello before it receives > the answer. > > > This applies not only to initial but to ALL offers. > > Finally, I can double check, but I am fairly sure there are current > implementation that violate this rule. > > Regards, > > _____________ > Roman Shpount > > On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla wrote: > >> Hi folks, >> >> RFC 5763 required (and JSEP imported) that all offers include >> >> a=setup:actpass >> >> However, assuming I am reading: >> https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 >> >> correctly, S 4.2 allows the initial offer to contain anything, >> though encourages actpass: >> >> When an offerer sends the initial offer, the offerer MUST insert an >> SDP 'setup' attribute according to the procedures in [RFC4145], and >> one or more SDP 'fingerprint' attributes according to the procedures >> in [RFC8122]. In addition, the offerer MUST insert in the offer an >> SDP 'tls-id' attribute with a unique value. >> >> If the offerer inserts the SDP 'setup' attribute with an 'actpass' or >> 'passive' attribute value, the offerer MUST be prepared to receive a >> DTLS ClientHello message (if a new DTLS association is established by >> the answerer) from the answerer before the offerer receives the SDP >> answer. >> >> For subequent offers, it also gives flexibility but points at 4145. >> >> >> So... >> >> 1. Changing the behavior for initial offers seems like it presents >> a serious interop risk, because previously you could depend on >> the offer being actpass. >> >> 2. JSEP requires actpass for all offers, so at least it's stricter. >> >> >> What was the rationale for these changes? Feel free to point me at the >> mailing list discussion where that happened. >> >> -Ekr >> Hi folks, >> >> RFC 5763 required (and JSEP imported) that all offers include >> >> a=setup:actpass >> >> However, assuming I am reading: >> https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 >> >> correctly, S 4.2 allows the initial offer to contain anything, >> though encourages actpass: >> >> When an offerer sends the initial offer, the offerer MUST insert an >> SDP 'setup' attribute according to the procedures in [RFC4145], and >> one or more SDP 'fingerprint' attributes according to the procedures >> in [RFC8122]. In addition, the offerer MUST insert in the offer an >> SDP 'tls-id' attribute with a unique value. >> >> If the offerer inserts the SDP 'setup' attribute with an 'actpass' or >> 'passive' attribute value, the offerer MUST be prepared to receive a >> DTLS ClientHello message (if a new DTLS association is established by >> the answerer) from the answerer before the offerer receives the SDP >> answer. >> >> For subequent offers, it also gives flexibility but points at 4145. >> >> >> So... >> >> 1. Changing the behavior for initial offers seems like it presents >> a serious interop risk, because previously you could depend on >> the offer being actpass. >> >> 2. JSEP requires actpass for all offers, so at least it's stricter. >> >> >> What was the rationale for these changes? Feel free to point me at the >> mailing list discussion where that happened. >> >> -Ekr >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --f403045c56cad596aa055100a9bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to provide the historic background for this change. W= e have discussed setup role in subsequent offers with Christer before IETF9= 5 and decided to remove the text that setup MUST be actpass in all the offe= rs. This removed this requirement from the initial offers as well (even tho= ugh they weren't discussed at that time).

Now we have three options:

<= /div>
1. setup can be whatever application wants in all offers (current= text)
2. setup MUST be actpass in initial offer and whatever app= lication wants in subsequent (or, alternatively actpass or negotiated role = in subsequent offers).
3. setup MUST be actpass in all the offers= (back to RFC 5763)

My top preference is that setu= p SHOULD be actpass in all the offers. Second preference is 1 and hope that= application will do the right thing.

From my poin= t of view 2 is strange, since there is no principal difference between init= ial and subsequent offers, especially when 3pcc comes into play. Any offer = can end up being subsequent for one end point and initial for another.

I also think that RFC 5763 requirement is too strong. = There are implementations which send offers without actpass so it is alread= y violated. There are also legitimate scenarios where sending current role= =C2=A0(subsequent offers without ICE resta= rt) or active=C2=A0(endpoints with = basic UDP behind NAT)=C2=A0makes mo= re sense.

Regards,

_____________
Roman Shpount=

On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpoun= t <roman@telurix.com> wrote:
Hi Al= l,

There was a discussion regarding = the setup attribute value in subsequent offers when establishing new DTLS a= ssociation is not desired. Based on that discussion it was decided that set= up value can be either currently negotiated value or actpass.=C2=A0There are also UDP/DTLS without STUN NAT traversal= scenarios that only work when end point behind NAT is active. I think send= ing actpass in offers is a generally safer option, but I think SHOULD here = is more appropriate then MUST.


The endpoint MUST use the = setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST= use the setup attribute value of setup:actpass and be prepared to receive = a client_hello before it receives the answer.

This applies not only to initial but to ALL offers.

Finally, I can double check, but I am fairly= sure there are current implementation that violate this rule.

Regards,
_____________
Roman Shpount

On Fri, Jun 2, 2017 a= t 12:44 PM, Eric Rescorla <ekr@rtfm.com> wrote:
H= i folks,

RFC 5763 required (and JSEP imported) tha= t all offers include

=C2=A0 a=3Dsetup:actpass

However, assuming I am reading:
=C2=A0 https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24<= /div>
=C2=A0=C2=A0
correctly, S 4.2 allows the initial offer = to contain anything,
though encourages actpass:

=C2=A0 =C2=A0When an offerer sends the initial offer, the offerer M= UST insert an
=C2=A0 =C2=A0SDP 'setup' attribute accordin= g to the procedures in [RFC4145], and
=C2=A0 =C2=A0one or more SD= P 'fingerprint' attributes according to the procedures
= =C2=A0 =C2=A0in [RFC8122].=C2=A0 In addition, the offerer MUST insert in th= e offer an
=C2=A0 =C2=A0SDP 'tls-id' attribute with a uni= que value.

=C2=A0 =C2=A0If the offerer inserts the= SDP 'setup' attribute with an 'actpass' or
=C2= =A0 =C2=A0'passive' attribute value, the offerer MUST be prepared t= o receive a
=C2=A0 =C2=A0DTLS ClientHello message (if a new DTLS = association is established by
=C2=A0 =C2=A0the answerer) from the= answerer before the offerer receives the SDP
=C2=A0 =C2=A0answer= .

For subequent offers, it also gives flexibility = but points at 4145.


So...

1. Changing the behavior for initial offers seems like it p= resents
a serious interop risk, because previously you could depe= nd on
the offer being actpass.

2. JSEP r= equires actpass for all offers, so at least it's stricter.

What was the rationale for these changes? Feel = free to point me at the
mailing list discussion where that happen= ed.

-Ekr
=C2=A0Hi folks,

<= /div>
RFC 5763 required (and JSEP imported) that all offers include

=C2=A0 a=3Dsetup:actpass

How= ever, assuming I am reading:
=C2=A0=C2=A0
correctly, S 4.2 allows the initial offer to contain anything,
though encourages actpass:

=C2=A0 =C2=A0Whe= n an offerer sends the initial offer, the offerer MUST insert an
= =C2=A0 =C2=A0SDP 'setup' attribute according to the procedures in [= RFC4145], and
=C2=A0 =C2=A0one or more SDP 'fingerprint' = attributes according to the procedures
=C2=A0 =C2=A0in [RFC8122].= =C2=A0 In addition, the offerer MUST insert in the offer an
=C2= =A0 =C2=A0SDP 'tls-id' attribute with a unique value.
=C2=A0 =C2=A0If the offerer inserts the SDP 'setup' att= ribute with an 'actpass' or
=C2=A0 =C2=A0'passive'= ; attribute value, the offerer MUST be prepared to receive a
=C2= =A0 =C2=A0DTLS ClientHello message (if a new DTLS association is establishe= d by
=C2=A0 =C2=A0the answerer) from the answerer before the offe= rer receives the SDP
=C2=A0 =C2=A0answer.

For subequent offers, it also gives flexibility but points at 4145.
=


So...

1. Changi= ng the behavior for initial offers seems like it presents
a serio= us interop risk, because previously you could depend on
the offer= being actpass.

2. JSEP requires actpass for all o= ffers, so at least it's stricter.


What was the rationale for these changes? Feel free to point me at the
mailing list discussion where that happened.

<= div>-Ekr
=C2=A0

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


--f403045c56cad596aa055100a9bd-- From nobody Fri Jun 2 14:33:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650A5126DED for ; Fri, 2 Jun 2017 14:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsint4gWz6KD for ; Fri, 2 Jun 2017 14:33:42 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F833126D73 for ; Fri, 2 Jun 2017 14:33:42 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-10v.sys.comcast.net with SMTP id GuByd2BOF61D9GuCTdZaDg; Fri, 02 Jun 2017 21:33:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1496439221; bh=jZ1STUeqSneGJm68o4EB2lWN118EH5LByPPXKlSpQ0s=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=c7T5fvF6fj+o4iJV4ToAW1GPeZRxgFALnEkT0S31RDmTFmh+OWfK91EWaXTT9kGNA J+pr8Ta4UIeH0NkF7O6/ZrNBC5wzvT23pgxu8+Ys7SFlC5mV0ccsOt5P7wJHtRdpYC uHruhKclF/HOMy0uNJ0jViEY7g+Yr7HQXOTiD5mnZsTZkF0XTh9/ssR5/U4PXfi+uO djqdf+vfWPZ0rjQhmCRnes3oKHpy3Q3SUhBOOZsC7o7biRspBhcDczM/zEN3gUQpcH 3YdfnrwTKd7C900VoL5otk9JZY+GgVTquxOLDbbCYeTgrRQuWH6FpiaRFNPfwoDOIJ slx/HQ8eo2Rfw== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-10v.sys.comcast.net with SMTP id GuCSdmgNnX2FjGuCTdDlkA; Fri, 02 Jun 2017 21:33:41 +0000 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: <5bd77e3f-e90b-5de4-2d97-170c952c2ba3@comcast.net> Date: Fri, 2 Jun 2017 17:33:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPHwjsEmjFqXFDnDkyt+zmZ41Yj1YMcfQrNesgQbHJAp+uOiKA1BU3xtdo5QMsoSzMyAiSejfJL4F6dQIJlllxi4tJXcpFGHM/goG6Up44K0y5uWg+ae IPywqzILlcbaJTGBLR300X95DbU4j7E6E/sQPYYNyz1Ao09uLIlscR9i Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 21:33:44 -0000 The scope for this discussion isn't defined. Is this just for SRTP? Or also for SCTP? Or also for TCP and TLS? Thanks, Paul On 6/2/17 5:16 PM, Roman Shpount wrote: > Just to provide the historic background for this change. We have > discussed setup role in subsequent offers with Christer before IETF95 > and decided to remove the text that setup MUST be actpass in all the > offers. This removed this requirement from the initial offers as well > (even though they weren't discussed at that time). > > Now we have three options: > > 1. setup can be whatever application wants in all offers (current text) > 2. setup MUST be actpass in initial offer and whatever application wants > in subsequent (or, alternatively actpass or negotiated role in > subsequent offers). > 3. setup MUST be actpass in all the offers (back to RFC 5763) > > My top preference is that setup SHOULD be actpass in all the offers. > Second preference is 1 and hope that application will do the right thing. > > From my point of view 2 is strange, since there is no principal > difference between initial and subsequent offers, especially when 3pcc > comes into play. Any offer can end up being subsequent for one end point > and initial for another. > > I also think that RFC 5763 requirement is too strong. There are > implementations which send offers without actpass so it is already > violated. There are also legitimate scenarios where sending current role > (subsequent offers without ICE restart) or active (endpoints with basic > UDP behind NAT) makes more sense. > > Regards, > > _____________ > Roman Shpount > > On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount > wrote: > > Hi All, > > There was a discussion regarding the setup attribute value in > subsequent offers when establishing new DTLS association is not > desired. Based on that discussion it was decided that setup value > can be either currently negotiated value or actpass. There are also > UDP/DTLS without STUN NAT traversal scenarios that only work when > end point behind NAT is active. I think sending actpass in offers is > a generally safer option, but I think SHOULD here is more > appropriate then MUST. > > Please note that https://tools.ietf.org/html/rfc5763#section-5 > says: > > The endpoint MUST use the setup attribute defined in [RFC4145]. > The endpoint that is the offerer MUST use the setup attribute > value of setup:actpass and be prepared to receive a client_hello > before it receives the answer. > > > This applies not only to initial but to ALL offers. > > Finally, I can double check, but I am fairly sure there are current > implementation that violate this rule. > > Regards, > > _____________ > Roman Shpount > > On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla > wrote: > > Hi folks, > > RFC 5763 required (and JSEP imported) that all offers include > > a=setup:actpass > > However, assuming I am reading: > https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 > > correctly, S 4.2 allows the initial offer to contain anything, > though encourages actpass: > > When an offerer sends the initial offer, the offerer MUST > insert an > SDP 'setup' attribute according to the procedures in > [RFC4145], and > one or more SDP 'fingerprint' attributes according to the > procedures > in [RFC8122]. In addition, the offerer MUST insert in the > offer an > SDP 'tls-id' attribute with a unique value. > > If the offerer inserts the SDP 'setup' attribute with an > 'actpass' or > 'passive' attribute value, the offerer MUST be prepared to > receive a > DTLS ClientHello message (if a new DTLS association is > established by > the answerer) from the answerer before the offerer receives > the SDP > answer. > > For subequent offers, it also gives flexibility but points at 4145. > > > So... > > 1. Changing the behavior for initial offers seems like it presents > a serious interop risk, because previously you could depend on > the offer being actpass. > > 2. JSEP requires actpass for all offers, so at least it's stricter. > > > What was the rationale for these changes? Feel free to point me > at the > mailing list discussion where that happened. > > -Ekr > Hi folks, > > RFC 5763 required (and JSEP imported) that all offers include > > a=setup:actpass > > However, assuming I am reading: > https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 > > correctly, S 4.2 allows the initial offer to contain anything, > though encourages actpass: > > When an offerer sends the initial offer, the offerer MUST > insert an > SDP 'setup' attribute according to the procedures in > [RFC4145], and > one or more SDP 'fingerprint' attributes according to the > procedures > in [RFC8122]. In addition, the offerer MUST insert in the > offer an > SDP 'tls-id' attribute with a unique value. > > If the offerer inserts the SDP 'setup' attribute with an > 'actpass' or > 'passive' attribute value, the offerer MUST be prepared to > receive a > DTLS ClientHello message (if a new DTLS association is > established by > the answerer) from the answerer before the offerer receives > the SDP > answer. > > For subequent offers, it also gives flexibility but points at 4145. > > > So... > > 1. Changing the behavior for initial offers seems like it presents > a serious interop risk, because previously you could depend on > the offer being actpass. > > 2. JSEP requires actpass for all offers, so at least it's stricter. > > > What was the rationale for these changes? Feel free to point me > at the > mailing list discussion where that happened. > > -Ekr > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Jun 2 15:36:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4916E12954D for ; Fri, 2 Jun 2017 15:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtyFZZ31nXjR for ; Fri, 2 Jun 2017 15:36:16 -0700 (PDT) Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) (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 693FF12946E for ; Fri, 2 Jun 2017 15:36:16 -0700 (PDT) Received: by mail-pf0-f178.google.com with SMTP id 83so224pfr.0 for ; Fri, 02 Jun 2017 15:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VXscGGkmxgfZ0/jZIPIwtGtvk+PnlLu8UYmqfVPyH3o=; b=YFKwzqkOjWGOYsHDLm2VG+r+hsdHOzYXpAattP/SGB1ZasHM6Iv6kiJJiXMXNUEIiL 4xEgU9TyBgA91GiVAJQ+BqM1sYVdF0IWLoVEF6oJRXQLe6cd77Rc6Q3tDyhhJ4mziVmr Zyi+a8hk7Uv9eD1j1/JJ8Svj/8JlhdlHduruWBfZt2EUOcWxAGp2zFdC7IgWFshexkhW s533MzsUP43wSevDV9tlW7NWhUXYReRMZ2e15hRDmSgeuypMzN0ZPvVOxaoGda7mErRg VBD4iM160PoKx8gcQtyeIKQOomOm+6rA+694jjlBBLPSXdPcjMnaItDxwT8vJtvaG+1d M9Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VXscGGkmxgfZ0/jZIPIwtGtvk+PnlLu8UYmqfVPyH3o=; b=jwexqlJB3DbxB7rZpNkZpwuX2G7WVQVGVAz+/KG5Tmbc3KMBU0iC/k+KJdBOeWHW6f /N1sH0A+OxBfLLhWE7J9PxM/jHqh6Of48SzXJffFFwXamR+gGwgbfNZPXVZGhy6EYI+b 3ahC4BOt1Au/xVmu6mx4IaSaC6kZm/b/ZBYU0AdoH3ol59nD0OxpLPZugeC5s/vrHK0E 9sb3h7KlcnzvYib9rAnKLcu6HoSVTeF40zePt8az3EnaM2J6YjDHMYRj3OOaZfOAKz4D TVJhmy3vLxk6mF4GbR5RTA+mS4eynxDHZSL/7pTCLxvtF4dGDJbNlHgJLy8iw7uPtYRF hKgA== X-Gm-Message-State: AODbwcDyFiE3IbPk5trIzNUwpjFdfnHkwRlSPd6vRdjbG8pCJWY3RhlT NRNI9QaZC7lPUQlE7wA= X-Received: by 10.98.9.91 with SMTP id e88mr8977762pfd.177.1496442915751; Fri, 02 Jun 2017 15:35:15 -0700 (PDT) Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com. [209.85.192.180]) by smtp.gmail.com with ESMTPSA id r29sm13543952pfg.95.2017.06.02.15.35.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 15:35:15 -0700 (PDT) Received: by mail-pf0-f180.google.com with SMTP id n23so57695130pfb.2 for ; Fri, 02 Jun 2017 15:35:14 -0700 (PDT) X-Received: by 10.84.130.7 with SMTP id 7mr2064593plc.35.1496442914740; Fri, 02 Jun 2017 15:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Fri, 2 Jun 2017 15:35:13 -0700 (PDT) In-Reply-To: <5bd77e3f-e90b-5de4-2d97-170c952c2ba3@comcast.net> References: <5bd77e3f-e90b-5de4-2d97-170c952c2ba3@comcast.net> From: Roman Shpount Date: Fri, 2 Jun 2017 18:35:13 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c12f4bc5c2d5e055101c40c" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 22:36:18 -0000 --94eb2c12f4bc5c2d5e055101c40c Content-Type: text/plain; charset="UTF-8" Paul, I assume this is limited to anything which implements draft-ietf-mmusic-dtls-sdp, which means it covers UDP/TLS/*, UDP/DTLS/* or TDP/DTLS/* protocols such as UDP/TLS/RTP/SAVP, TCP/DTLS/RTP/SAVP, UDP/DTLS/SCTP, TCP/DTLS/SCTP. TCP/* and TLS/* protocols are not in scope of this discussion and they continue to be covered by RFC 4145 as far as setup attribute is concerned. Regards, _____________ Roman Shpount On Fri, Jun 2, 2017 at 5:33 PM, Paul Kyzivat wrote: > The scope for this discussion isn't defined. Is this just for SRTP? Or > also for SCTP? Or also for TCP and TLS? > > Thanks, > Paul > > On 6/2/17 5:16 PM, Roman Shpount wrote: > >> Just to provide the historic background for this change. We have >> discussed setup role in subsequent offers with Christer before IETF95 and >> decided to remove the text that setup MUST be actpass in all the offers. >> This removed this requirement from the initial offers as well (even though >> they weren't discussed at that time). >> >> Now we have three options: >> >> 1. setup can be whatever application wants in all offers (current text) >> 2. setup MUST be actpass in initial offer and whatever application wants >> in subsequent (or, alternatively actpass or negotiated role in subsequent >> offers). >> 3. setup MUST be actpass in all the offers (back to RFC 5763) >> >> My top preference is that setup SHOULD be actpass in all the offers. >> Second preference is 1 and hope that application will do the right thing. >> >> From my point of view 2 is strange, since there is no principal >> difference between initial and subsequent offers, especially when 3pcc >> comes into play. Any offer can end up being subsequent for one end point >> and initial for another. >> >> I also think that RFC 5763 requirement is too strong. There are >> implementations which send offers without actpass so it is already >> violated. There are also legitimate scenarios where sending current role >> (subsequent offers without ICE restart) or active (endpoints with basic UDP >> behind NAT) makes more sense. >> >> Regards, >> >> _____________ >> Roman Shpount >> >> On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount > roman@telurix.com>> wrote: >> >> Hi All, >> >> There was a discussion regarding the setup attribute value in >> subsequent offers when establishing new DTLS association is not >> desired. Based on that discussion it was decided that setup value >> can be either currently negotiated value or actpass. There are also >> UDP/DTLS without STUN NAT traversal scenarios that only work when >> end point behind NAT is active. I think sending actpass in offers is >> a generally safer option, but I think SHOULD here is more >> appropriate then MUST. >> >> Please note that https://tools.ietf.org/html/rfc5763#section-5 >> says: >> >> The endpoint MUST use the setup attribute defined in [RFC4145]. >> The endpoint that is the offerer MUST use the setup attribute >> value of setup:actpass and be prepared to receive a client_hello >> before it receives the answer. >> >> >> This applies not only to initial but to ALL offers. >> >> Finally, I can double check, but I am fairly sure there are current >> implementation that violate this rule. >> >> Regards, >> >> _____________ >> Roman Shpount >> >> On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla > > wrote: >> >> Hi folks, >> >> RFC 5763 required (and JSEP imported) that all offers include >> >> a=setup:actpass >> >> However, assuming I am reading: >> https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 >> >> correctly, S 4.2 allows the initial offer to contain anything, >> though encourages actpass: >> >> When an offerer sends the initial offer, the offerer MUST >> insert an >> SDP 'setup' attribute according to the procedures in >> [RFC4145], and >> one or more SDP 'fingerprint' attributes according to the >> procedures >> in [RFC8122]. In addition, the offerer MUST insert in the >> offer an >> SDP 'tls-id' attribute with a unique value. >> >> If the offerer inserts the SDP 'setup' attribute with an >> 'actpass' or >> 'passive' attribute value, the offerer MUST be prepared to >> receive a >> DTLS ClientHello message (if a new DTLS association is >> established by >> the answerer) from the answerer before the offerer receives >> the SDP >> answer. >> >> For subequent offers, it also gives flexibility but points at >> 4145. >> >> >> So... >> >> 1. Changing the behavior for initial offers seems like it presents >> a serious interop risk, because previously you could depend on >> the offer being actpass. >> >> 2. JSEP requires actpass for all offers, so at least it's >> stricter. >> >> >> What was the rationale for these changes? Feel free to point me >> at the >> mailing list discussion where that happened. >> >> -Ekr >> Hi folks, >> >> RFC 5763 required (and JSEP imported) that all offers include >> >> a=setup:actpass >> >> However, assuming I am reading: >> https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 >> >> correctly, S 4.2 allows the initial offer to contain anything, >> though encourages actpass: >> >> When an offerer sends the initial offer, the offerer MUST >> insert an >> SDP 'setup' attribute according to the procedures in >> [RFC4145], and >> one or more SDP 'fingerprint' attributes according to the >> procedures >> in [RFC8122]. In addition, the offerer MUST insert in the >> offer an >> SDP 'tls-id' attribute with a unique value. >> >> If the offerer inserts the SDP 'setup' attribute with an >> 'actpass' or >> 'passive' attribute value, the offerer MUST be prepared to >> receive a >> DTLS ClientHello message (if a new DTLS association is >> established by >> the answerer) from the answerer before the offerer receives >> the SDP >> answer. >> >> For subequent offers, it also gives flexibility but points at >> 4145. >> >> >> So... >> >> 1. Changing the behavior for initial offers seems like it presents >> a serious interop risk, because previously you could depend on >> the offer being actpass. >> >> 2. JSEP requires actpass for all offers, so at least it's >> stricter. >> >> >> What was the rationale for these changes? Feel free to point me >> at the >> mailing list discussion where that happened. >> >> -Ekr >> >> _______________________________________________ >> 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 > --94eb2c12f4bc5c2d5e055101c40c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul,

I assume this is limited to anyth= ing=C2=A0which implements draft-ietf-mmusic-dtls-sdp, which means it covers= UDP/TLS/*, UDP/DTLS/* or TDP/DTLS/* protocols such as UDP/TLS/RTP/SAVP, TC= P/DTLS/RTP/SAVP, UDP/DTLS/SCTP, TCP/DTLS/SCTP.

TCP= /* and TLS/* protocols are not in scope of this discussion and they continu= e to be covered by RFC 4145 as far as setup attribute is concerned.

Regards,

_____________
Roman Shpount

On Fri, Jun 2, 2017 at 5:33 PM, Paul Kyzivat= <paul.kyzivat@comcast.net> wrote:
The scope for this discussion isn't defined. Is this = just for SRTP? Or also for SCTP? Or also for TCP and TLS?

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

On 6/2/17 5:16 PM, Roman Shpount wrote:
Just to provide the historic background for this change. We have discussed = setup role in subsequent offers with Christer before IETF95 and decided to = remove the text that setup MUST be actpass in all the offers. This removed = this requirement from the initial offers as well (even though they weren= 9;t discussed at that time).

Now we have three options:

1. setup can be whatever application wants in all offers (current text)
2. setup MUST be actpass in initial offer and whatever application wants in= subsequent (or, alternatively actpass or negotiated role in subsequent off= ers).
3. setup MUST be actpass in all the offers (back to RFC 5763)

My top preference is that setup SHOULD be actpass in all the offers. Second= preference is 1 and hope that application will do the right thing.

=C2=A0From my point of view 2 is strange, since there is no principal diffe= rence between initial and subsequent offers, especially when 3pcc comes int= o play. Any offer can end up being subsequent for one end point and initial= for another.

I also think that RFC 5763 requirement is too strong. There are implementat= ions which send offers without actpass so it is already violated. There are= also legitimate scenarios where sending current role (subsequent offers wi= thout ICE restart) or active (endpoints with basic UDP behind NAT) makes mo= re sense.

Regards,

_____________
Roman Shpount

 On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> wr= ote:

=C2=A0 =C2=A0 Hi All,

=C2=A0 =C2=A0 There was a discussion regarding the setup attribute value in=
=C2=A0 =C2=A0 subsequent offers when establishing new DTLS association is n= ot
=C2=A0 =C2=A0 desired. Based on that discussion it was decided that setup v= alue
=C2=A0 =C2=A0 can be either currently negotiated value or actpass. There ar= e also
=C2=A0 =C2=A0 UDP/DTLS without STUN NAT traversal scenarios that only work = when
=C2=A0 =C2=A0 end point behind NAT is active. I think sending actpass in of= fers is
=C2=A0 =C2=A0 a generally safer option, but I think SHOULD here is more
=C2=A0 =C2=A0 appropriate then MUST.

=C2=A0 =C2=A0 Please note that https://tools.ietf.org/h= tml/rfc5763#section-5
=C2=A0 =C2=A0 <https://tools.ietf.org/html/rfc5= 763#section-5> says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The endpoint MUST use the setup attribute defin= ed in [RFC4145].
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The endpoint that is the offerer MUST use the s= etup attribute
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value of setup:actpass and be prepared to recei= ve a client_hello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 before it receives the answer.


=C2=A0 =C2=A0 This applies not only to initial but to ALL offers.

=C2=A0 =C2=A0 Finally, I can double check, but I am fairly sure there are c= urrent
=C2=A0 =C2=A0 implementation that violate this rule.

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 _____________
=C2=A0 =C2=A0 Roman Shpount

=C2=A0 =C2=A0 On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla <ekr@rtfm.com
=C2=A0 =C2=A0 <mailto:= ekr@rtfm.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi folks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 5763 required (and JSEP imported) that all = offers include

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dsetup:actpass

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, assuming I am reading:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.i= etf.org/html/draft-ietf-mmusic-dtls-sdp-24
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://too= ls.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 correctly, S 4.2 allows the initial offer to co= ntain anything,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 though encourages actpass:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When an offerer sends the initial= offer, the offerer MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 insert an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP 'setup' attribute acc= ording to the procedures in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC4145], and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one or more SDP 'fingerprint&= #39; attributes according to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 procedures
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in [RFC8122].=C2=A0 In addition, = the offerer MUST insert in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 offer an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP 'tls-id' attribute wi= th a unique value.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the offerer inserts the SDP &#= 39;setup' attribute with an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 'actpass' or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'passive' attribute value= , the offerer MUST be prepared to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 receive a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS ClientHello message (if a ne= w DTLS association is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 established by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the answerer) from the answerer b= efore the offerer receives
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the SDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 answer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For subequent offers, it also gives flexibility= but points at 4145.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 So...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Changing the behavior for initial offers see= ms like it presents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a serious interop risk, because previously you = could depend on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the offer being actpass.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2. JSEP requires actpass for all offers, so at = least it's stricter.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 What was the rationale for these changes? Feel = free to point me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mailing list discussion where that happened.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -Ekr
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi folks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 5763 required (and JSEP imported) that all = offers include

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dsetup:actpass

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, assuming I am reading:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.i= etf.org/html/draft-ietf-mmusic-dtls-sdp-24
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://too= ls.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 correctly, S 4.2 allows the initial offer to co= ntain anything,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 though encourages actpass:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When an offerer sends the initial= offer, the offerer MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 insert an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP 'setup' attribute acc= ording to the procedures in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC4145], and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one or more SDP 'fingerprint&= #39; attributes according to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 procedures
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in [RFC8122].=C2=A0 In addition, = the offerer MUST insert in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 offer an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP 'tls-id' attribute wi= th a unique value.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the offerer inserts the SDP &#= 39;setup' attribute with an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 'actpass' or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'passive' attribute value= , the offerer MUST be prepared to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 receive a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS ClientHello message (if a ne= w DTLS association is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 established by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the answerer) from the answerer b= efore the offerer receives
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the SDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 answer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For subequent offers, it also gives flexibility= but points at 4145.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 So...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Changing the behavior for initial offers see= ms like it presents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a serious interop risk, because previously you = could depend on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the offer being actpass.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2. JSEP requires actpass for all offers, so at = least it's stricter.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 What was the rationale for these changes? Feel = free to point me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mailing list discussion where that happened.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -Ekr

=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic@ietf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/mmusic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mai= lman/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

--94eb2c12f4bc5c2d5e055101c40c-- From nobody Sat Jun 3 00:06:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87C9126C0F for ; Sat, 3 Jun 2017 00:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA3yAYxGDJTk for ; Sat, 3 Jun 2017 00:06:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A091250B8 for ; Sat, 3 Jun 2017 00:06:13 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-58-59325fe45c11 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.5A.22014.4EF52395; Sat, 3 Jun 2017 09:06:12 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0339.000; Sat, 3 Jun 2017 09:04:13 +0200 From: Christer Holmberg To: Roman Shpount , Eric Rescorla CC: mmusic WG Thread-Topic: [MMUSIC] actpass redux Thread-Index: AQHS27+QUKTkX8TgukOHH0lDl2aBAKIRu7eAgAA2MQCAAMRawA== Date: Sat, 3 Jun 2017 07:04:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBD7C32@ESESSMB109.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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CBD7C32ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7h+6TeKNIgz2/5CxWvD7HbjF1+WMW ixkXpjI7MHssWfKTyWPy4zZmj1tTCgKYo7hsUlJzMstSi/TtErgy/p2bwV6wqZWpYtGMLewN jEf+MXYxcnJICJhI7L/azNrFyMUhJHCEUeLqj09QziJGibcr5jN1MXJwsAlYSHT/0wZpEBFw lujqvccKYjMLyEtcWLKGCcQWFlCW2P+8ixGiRkXiZftSFgjbSWJ750ewGhag+ISDX9hAbF4B X4m/mzeyQ+y6xyix4+tGsKGcAoES01Y/ArMZBcQkvp+CWMAsIC5x68l8JoirBSSW7DnPDGGL Srx8/I8VwlaSaFzyBOq4fIlp5y4yQywTlDg58wnLBEaRWUhGzUJSNgtJ2Sygl5kFNCXW79KH KFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAaDu45bfq DsbLbxwPMQpwMCrx8Dr4GkUKsSaWFVfmHmKU4GBWEuH1DwIK8aYkVlalFuXHF5XmpBYfYpTm YFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwGgsNVs8yvCHpKOchMXav9vTVt22uXHKa7eI if+aoHPsSnveF4r5H1rpLXhI+slP+wOHJs1jft5m+PEYu/Dk8C7x5zF3jPaWHor7wXjk9c6L i5KMT1r+OLrh7e+wE/P7GJ8v+sAUrrPWYHIZO9Oed5U/hSOke6b65p2ZquqVd1bz+LPJEzxs lmQosRRnJBpqMRcVJwIAQis9x7ICAAA= Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 07:06:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CBD7C32ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkZvciBzdWJzZXF1ZW50IG9mZmVycywgZHJhZnQtZHRscy1zZHAgc2F5cyBTSE9VTEQt dXNlLWFjdHBhc3MtTUFZLXVzZS1zb21ldGhpbmctZWxzZS4NCg0KV2UgY2FuIGFwcGx5IHRoYXQg U0hPVUxEIHRvIGluaXRpYWwgb2ZmZXJzIGlmIHBlb3BsZSB3YW50IHRvLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFJvbWFuIFNocG91bnQNClNlbnQ6IDAyIEp1bmUgMjAxNyAyMzoxNg0K VG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCkNjOiBtbXVzaWMgV0cgPG1tdXNpY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBhY3RwYXNzIHJlZHV4DQoNCkp1c3QgdG8g cHJvdmlkZSB0aGUgaGlzdG9yaWMgYmFja2dyb3VuZCBmb3IgdGhpcyBjaGFuZ2UuIFdlIGhhdmUg ZGlzY3Vzc2VkIHNldHVwIHJvbGUgaW4gc3Vic2VxdWVudCBvZmZlcnMgd2l0aCBDaHJpc3RlciBi ZWZvcmUgSUVURjk1IGFuZCBkZWNpZGVkIHRvIHJlbW92ZSB0aGUgdGV4dCB0aGF0IHNldHVwIE1V U1QgYmUgYWN0cGFzcyBpbiBhbGwgdGhlIG9mZmVycy4gVGhpcyByZW1vdmVkIHRoaXMgcmVxdWly ZW1lbnQgZnJvbSB0aGUgaW5pdGlhbCBvZmZlcnMgYXMgd2VsbCAoZXZlbiB0aG91Z2ggdGhleSB3 ZXJlbid0IGRpc2N1c3NlZCBhdCB0aGF0IHRpbWUpLg0KDQpOb3cgd2UgaGF2ZSB0aHJlZSBvcHRp b25zOg0KDQoxLiBzZXR1cCBjYW4gYmUgd2hhdGV2ZXIgYXBwbGljYXRpb24gd2FudHMgaW4gYWxs IG9mZmVycyAoY3VycmVudCB0ZXh0KQ0KMi4gc2V0dXAgTVVTVCBiZSBhY3RwYXNzIGluIGluaXRp YWwgb2ZmZXIgYW5kIHdoYXRldmVyIGFwcGxpY2F0aW9uIHdhbnRzIGluIHN1YnNlcXVlbnQgKG9y LCBhbHRlcm5hdGl2ZWx5IGFjdHBhc3Mgb3IgbmVnb3RpYXRlZCByb2xlIGluIHN1YnNlcXVlbnQg b2ZmZXJzKS4NCjMuIHNldHVwIE1VU1QgYmUgYWN0cGFzcyBpbiBhbGwgdGhlIG9mZmVycyAoYmFj ayB0byBSRkMgNTc2MykNCg0KTXkgdG9wIHByZWZlcmVuY2UgaXMgdGhhdCBzZXR1cCBTSE9VTEQg YmUgYWN0cGFzcyBpbiBhbGwgdGhlIG9mZmVycy4gU2Vjb25kIHByZWZlcmVuY2UgaXMgMSBhbmQg aG9wZSB0aGF0IGFwcGxpY2F0aW9uIHdpbGwgZG8gdGhlIHJpZ2h0IHRoaW5nLg0KDQpGcm9tIG15 IHBvaW50IG9mIHZpZXcgMiBpcyBzdHJhbmdlLCBzaW5jZSB0aGVyZSBpcyBubyBwcmluY2lwYWwg ZGlmZmVyZW5jZSBiZXR3ZWVuIGluaXRpYWwgYW5kIHN1YnNlcXVlbnQgb2ZmZXJzLCBlc3BlY2lh bGx5IHdoZW4gM3BjYyBjb21lcyBpbnRvIHBsYXkuIEFueSBvZmZlciBjYW4gZW5kIHVwIGJlaW5n IHN1YnNlcXVlbnQgZm9yIG9uZSBlbmQgcG9pbnQgYW5kIGluaXRpYWwgZm9yIGFub3RoZXIuDQoN CkkgYWxzbyB0aGluayB0aGF0IFJGQyA1NzYzIHJlcXVpcmVtZW50IGlzIHRvbyBzdHJvbmcuIFRo ZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggc2VuZCBvZmZlcnMgd2l0aG91dCBhY3RwYXNz IHNvIGl0IGlzIGFscmVhZHkgdmlvbGF0ZWQuIFRoZXJlIGFyZSBhbHNvIGxlZ2l0aW1hdGUgc2Nl bmFyaW9zIHdoZXJlIHNlbmRpbmcgY3VycmVudCByb2xlIChzdWJzZXF1ZW50IG9mZmVycyB3aXRo b3V0IElDRSByZXN0YXJ0KSBvciBhY3RpdmUgKGVuZHBvaW50cyB3aXRoIGJhc2ljIFVEUCBiZWhp bmQgTkFUKSBtYWtlcyBtb3JlIHNlbnNlLg0KDQpSZWdhcmRzLA0KDQpfX19fX19fX19fX19fDQpS b21hbiBTaHBvdW50DQoNCk9uIEZyaSwgSnVuIDIsIDIwMTcgYXQgMjowMiBQTSwgUm9tYW4gU2hw b3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6 DQpIaSBBbGwsDQoNClRoZXJlIHdhcyBhIGRpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSBzZXR1cCBh dHRyaWJ1dGUgdmFsdWUgaW4gc3Vic2VxdWVudCBvZmZlcnMgd2hlbiBlc3RhYmxpc2hpbmcgbmV3 IERUTFMgYXNzb2NpYXRpb24gaXMgbm90IGRlc2lyZWQuIEJhc2VkIG9uIHRoYXQgZGlzY3Vzc2lv biBpdCB3YXMgZGVjaWRlZCB0aGF0IHNldHVwIHZhbHVlIGNhbiBiZSBlaXRoZXIgY3VycmVudGx5 IG5lZ290aWF0ZWQgdmFsdWUgb3IgYWN0cGFzcy4gVGhlcmUgYXJlIGFsc28gVURQL0RUTFMgd2l0 aG91dCBTVFVOIE5BVCB0cmF2ZXJzYWwgc2NlbmFyaW9zIHRoYXQgb25seSB3b3JrIHdoZW4gZW5k IHBvaW50IGJlaGluZCBOQVQgaXMgYWN0aXZlLiBJIHRoaW5rIHNlbmRpbmcgYWN0cGFzcyBpbiBv ZmZlcnMgaXMgYSBnZW5lcmFsbHkgc2FmZXIgb3B0aW9uLCBidXQgSSB0aGluayBTSE9VTEQgaGVy ZSBpcyBtb3JlIGFwcHJvcHJpYXRlIHRoZW4gTVVTVC4NCg0KUGxlYXNlIG5vdGUgdGhhdCBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2MyNzZWN0aW9uLTUgc2F5czoNCg0KVGhlIGVu ZHBvaW50IE1VU1QgdXNlIHRoZSBzZXR1cCBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBbUkZDNDE0NV0u IFRoZSBlbmRwb2ludCB0aGF0IGlzIHRoZSBvZmZlcmVyIE1VU1QgdXNlIHRoZSBzZXR1cCBhdHRy aWJ1dGUgdmFsdWUgb2Ygc2V0dXA6YWN0cGFzcyBhbmQgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBh IGNsaWVudF9oZWxsbyBiZWZvcmUgaXQgcmVjZWl2ZXMgdGhlIGFuc3dlci4NCg0KVGhpcyBhcHBs aWVzIG5vdCBvbmx5IHRvIGluaXRpYWwgYnV0IHRvIEFMTCBvZmZlcnMuDQoNCkZpbmFsbHksIEkg Y2FuIGRvdWJsZSBjaGVjaywgYnV0IEkgYW0gZmFpcmx5IHN1cmUgdGhlcmUgYXJlIGN1cnJlbnQg aW1wbGVtZW50YXRpb24gdGhhdCB2aW9sYXRlIHRoaXMgcnVsZS4NCg0KUmVnYXJkcywNCg0KX19f X19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBGcmksIEp1biAyLCAyMDE3IGF0IDEyOjQ0 IFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdy b3RlOg0KSGkgZm9sa3MsDQoNClJGQyA1NzYzIHJlcXVpcmVkIChhbmQgSlNFUCBpbXBvcnRlZCkg dGhhdCBhbGwgb2ZmZXJzIGluY2x1ZGUNCg0KICBhPXNldHVwOmFjdHBhc3MNCg0KSG93ZXZlciwg YXNzdW1pbmcgSSBhbSByZWFkaW5nOg0KICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjQNCg0KY29ycmVjdGx5LCBTIDQuMiBhbGxvd3MgdGhl IGluaXRpYWwgb2ZmZXIgdG8gY29udGFpbiBhbnl0aGluZywNCnRob3VnaCBlbmNvdXJhZ2VzIGFj dHBhc3M6DQoNCiAgIFdoZW4gYW4gb2ZmZXJlciBzZW5kcyB0aGUgaW5pdGlhbCBvZmZlciwgdGhl IG9mZmVyZXIgTVVTVCBpbnNlcnQgYW4NCiAgIFNEUCAnc2V0dXAnIGF0dHJpYnV0ZSBhY2NvcmRp bmcgdG8gdGhlIHByb2NlZHVyZXMgaW4gW1JGQzQxNDVdLCBhbmQNCiAgIG9uZSBvciBtb3JlIFNE UCAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZXMgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzDQog ICBpbiBbUkZDODEyMl0uICBJbiBhZGRpdGlvbiwgdGhlIG9mZmVyZXIgTVVTVCBpbnNlcnQgaW4g dGhlIG9mZmVyIGFuDQogICBTRFAgJ3Rscy1pZCcgYXR0cmlidXRlIHdpdGggYSB1bmlxdWUgdmFs dWUuDQoNCiAgIElmIHRoZSBvZmZlcmVyIGluc2VydHMgdGhlIFNEUCAnc2V0dXAnIGF0dHJpYnV0 ZSB3aXRoIGFuICdhY3RwYXNzJyBvcg0KICAgJ3Bhc3NpdmUnIGF0dHJpYnV0ZSB2YWx1ZSwgdGhl IG9mZmVyZXIgTVVTVCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGENCiAgIERUTFMgQ2xpZW50SGVs bG8gbWVzc2FnZSAoaWYgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZCBieQ0K ICAgdGhlIGFuc3dlcmVyKSBmcm9tIHRoZSBhbnN3ZXJlciBiZWZvcmUgdGhlIG9mZmVyZXIgcmVj ZWl2ZXMgdGhlIFNEUA0KICAgYW5zd2VyLg0KDQpGb3Igc3ViZXF1ZW50IG9mZmVycywgaXQgYWxz byBnaXZlcyBmbGV4aWJpbGl0eSBidXQgcG9pbnRzIGF0IDQxNDUuDQoNCg0KU28uLi4NCg0KMS4g Q2hhbmdpbmcgdGhlIGJlaGF2aW9yIGZvciBpbml0aWFsIG9mZmVycyBzZWVtcyBsaWtlIGl0IHBy ZXNlbnRzDQphIHNlcmlvdXMgaW50ZXJvcCByaXNrLCBiZWNhdXNlIHByZXZpb3VzbHkgeW91IGNv dWxkIGRlcGVuZCBvbg0KdGhlIG9mZmVyIGJlaW5nIGFjdHBhc3MuDQoNCjIuIEpTRVAgcmVxdWly ZXMgYWN0cGFzcyBmb3IgYWxsIG9mZmVycywgc28gYXQgbGVhc3QgaXQncyBzdHJpY3Rlci4NCg0K DQpXaGF0IHdhcyB0aGUgcmF0aW9uYWxlIGZvciB0aGVzZSBjaGFuZ2VzPyBGZWVsIGZyZWUgdG8g cG9pbnQgbWUgYXQgdGhlDQptYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiB3aGVyZSB0aGF0IGhhcHBl bmVkLg0KDQotRWtyDQogSGkgZm9sa3MsDQoNClJGQyA1NzYzIHJlcXVpcmVkIChhbmQgSlNFUCBp bXBvcnRlZCkgdGhhdCBhbGwgb2ZmZXJzIGluY2x1ZGUNCg0KICBhPXNldHVwOmFjdHBhc3MNCg0K SG93ZXZlciwgYXNzdW1pbmcgSSBhbSByZWFkaW5nOg0KICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjQNCg0KY29ycmVjdGx5LCBTIDQuMiBh bGxvd3MgdGhlIGluaXRpYWwgb2ZmZXIgdG8gY29udGFpbiBhbnl0aGluZywNCnRob3VnaCBlbmNv dXJhZ2VzIGFjdHBhc3M6DQoNCiAgIFdoZW4gYW4gb2ZmZXJlciBzZW5kcyB0aGUgaW5pdGlhbCBv ZmZlciwgdGhlIG9mZmVyZXIgTVVTVCBpbnNlcnQgYW4NCiAgIFNEUCAnc2V0dXAnIGF0dHJpYnV0 ZSBhY2NvcmRpbmcgdG8gdGhlIHByb2NlZHVyZXMgaW4gW1JGQzQxNDVdLCBhbmQNCiAgIG9uZSBv ciBtb3JlIFNEUCAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZXMgYWNjb3JkaW5nIHRvIHRoZSBwcm9j ZWR1cmVzDQogICBpbiBbUkZDODEyMl0uICBJbiBhZGRpdGlvbiwgdGhlIG9mZmVyZXIgTVVTVCBp bnNlcnQgaW4gdGhlIG9mZmVyIGFuDQogICBTRFAgJ3Rscy1pZCcgYXR0cmlidXRlIHdpdGggYSB1 bmlxdWUgdmFsdWUuDQoNCiAgIElmIHRoZSBvZmZlcmVyIGluc2VydHMgdGhlIFNEUCAnc2V0dXAn IGF0dHJpYnV0ZSB3aXRoIGFuICdhY3RwYXNzJyBvcg0KICAgJ3Bhc3NpdmUnIGF0dHJpYnV0ZSB2 YWx1ZSwgdGhlIG9mZmVyZXIgTVVTVCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGENCiAgIERUTFMg Q2xpZW50SGVsbG8gbWVzc2FnZSAoaWYgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbiBpcyBlc3RhYmxp c2hlZCBieQ0KICAgdGhlIGFuc3dlcmVyKSBmcm9tIHRoZSBhbnN3ZXJlciBiZWZvcmUgdGhlIG9m ZmVyZXIgcmVjZWl2ZXMgdGhlIFNEUA0KICAgYW5zd2VyLg0KDQpGb3Igc3ViZXF1ZW50IG9mZmVy cywgaXQgYWxzbyBnaXZlcyBmbGV4aWJpbGl0eSBidXQgcG9pbnRzIGF0IDQxNDUuDQoNCg0KU28u Li4NCg0KMS4gQ2hhbmdpbmcgdGhlIGJlaGF2aW9yIGZvciBpbml0aWFsIG9mZmVycyBzZWVtcyBs aWtlIGl0IHByZXNlbnRzDQphIHNlcmlvdXMgaW50ZXJvcCByaXNrLCBiZWNhdXNlIHByZXZpb3Vz bHkgeW91IGNvdWxkIGRlcGVuZCBvbg0KdGhlIG9mZmVyIGJlaW5nIGFjdHBhc3MuDQoNCjIuIEpT RVAgcmVxdWlyZXMgYWN0cGFzcyBmb3IgYWxsIG9mZmVycywgc28gYXQgbGVhc3QgaXQncyBzdHJp Y3Rlci4NCg0KDQpXaGF0IHdhcyB0aGUgcmF0aW9uYWxlIGZvciB0aGVzZSBjaGFuZ2VzPyBGZWVs IGZyZWUgdG8gcG9pbnQgbWUgYXQgdGhlDQptYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiB3aGVyZSB0 aGF0IGhhcHBlbmVkLg0KDQotRWtyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxt YWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4CBD7C32ESESSMB109erics_ 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 LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZvciBzdWJzZXF1ZW50IG9mZmVycywgZHJhZnQtZHRs cy1zZHAgc2F5cyBTSE9VTEQtdXNlLWFjdHBhc3MtTUFZLXVzZS1zb21ldGhpbmctZWxzZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldlIGNhbiBhcHBseSB0aGF0IFNI T1VMRCB0byBpbml0aWFsIG9mZmVycyBpZiBwZW9wbGUgd2FudCB0by48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rlcg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlJvbWFuIFNocG91bnQ8YnI+DQo8Yj5TZW50OjwvYj4gMDIgSnVuZSAyMDE3IDIz OjE2PGJyPg0KPGI+VG86PC9iPiBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBtbXVzaWMgV0cgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIGFjdHBhc3MgcmVkdXg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IHRvIHByb3ZpZGUgdGhlIGhpc3RvcmljIGJhY2tncm91 bmQgZm9yIHRoaXMgY2hhbmdlLiBXZSBoYXZlIGRpc2N1c3NlZCBzZXR1cCByb2xlIGluIHN1YnNl cXVlbnQgb2ZmZXJzIHdpdGggQ2hyaXN0ZXIgYmVmb3JlIElFVEY5NSBhbmQgZGVjaWRlZCB0byBy ZW1vdmUgdGhlIHRleHQgdGhhdCBzZXR1cCBNVVNUIGJlIGFjdHBhc3MgaW4gYWxsIHRoZSBvZmZl cnMuIFRoaXMgcmVtb3ZlZCB0aGlzIHJlcXVpcmVtZW50DQogZnJvbSB0aGUgaW5pdGlhbCBvZmZl cnMgYXMgd2VsbCAoZXZlbiB0aG91Z2ggdGhleSB3ZXJlbid0IGRpc2N1c3NlZCBhdCB0aGF0IHRp bWUpLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPk5vdyB3ZSBoYXZlIHRo cmVlIG9wdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPjEuIHNldHVwIGNhbiBi ZSB3aGF0ZXZlciBhcHBsaWNhdGlvbiB3YW50cyBpbiBhbGwgb2ZmZXJzIChjdXJyZW50IHRleHQp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+Mi4gc2V0dXAgTVVT VCBiZSBhY3RwYXNzIGluIGluaXRpYWwgb2ZmZXIgYW5kIHdoYXRldmVyIGFwcGxpY2F0aW9uIHdh bnRzIGluIHN1YnNlcXVlbnQgKG9yLCBhbHRlcm5hdGl2ZWx5IGFjdHBhc3Mgb3IgbmVnb3RpYXRl ZCByb2xlIGluIHN1YnNlcXVlbnQgb2ZmZXJzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2NvbG9yOmJsYWNrIj4zLiBzZXR1cCBNVVNUIGJlIGFjdHBhc3MgaW4gYWxsIHRoZSBvZmZl cnMgKGJhY2sgdG8gUkZDIDU3NjMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFj ayI+TXkgdG9wIHByZWZlcmVuY2UgaXMgdGhhdCBzZXR1cCBTSE9VTEQgYmUgYWN0cGFzcyBpbiBh bGwgdGhlIG9mZmVycy4gU2Vjb25kIHByZWZlcmVuY2UgaXMgMSBhbmQgaG9wZSB0aGF0IGFwcGxp Y2F0aW9uIHdpbGwgZG8gdGhlIHJpZ2h0IHRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Y29sb3I6YmxhY2siPkZyb20gbXkgcG9pbnQgb2YgdmlldyAyIGlzIHN0cmFuZ2UsIHNpbmNlIHRo ZXJlIGlzIG5vIHByaW5jaXBhbCBkaWZmZXJlbmNlIGJldHdlZW4gaW5pdGlhbCBhbmQgc3Vic2Vx dWVudCBvZmZlcnMsIGVzcGVjaWFsbHkgd2hlbiAzcGNjIGNvbWVzIGludG8gcGxheS4gQW55IG9m ZmVyIGNhbiBlbmQgdXAgYmVpbmcgc3Vic2VxdWVudCBmb3INCiBvbmUgZW5kIHBvaW50IGFuZCBp bml0aWFsIGZvciBhbm90aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2si PkkgYWxzbyB0aGluayB0aGF0IFJGQyA1NzYzIHJlcXVpcmVtZW50IGlzIHRvbyBzdHJvbmcuIFRo ZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggc2VuZCBvZmZlcnMgd2l0aG91dCBhY3RwYXNz IHNvIGl0IGlzIGFscmVhZHkgdmlvbGF0ZWQuIFRoZXJlIGFyZSBhbHNvIGxlZ2l0aW1hdGUgc2Nl bmFyaW9zIHdoZXJlIHNlbmRpbmcgY3VycmVudA0KIHJvbGUmbmJzcDsoc3Vic2VxdWVudCBvZmZl cnMgd2l0aG91dCBJQ0UgcmVzdGFydCkgb3IgYWN0aXZlJm5ic3A7KGVuZHBvaW50cyB3aXRoIGJh c2ljIFVEUCBiZWhpbmQgTkFUKSZuYnNwO21ha2VzIG1vcmUgc2Vuc2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1biAyLCAyMDE3 IGF0IDI6MDIgUE0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPkhpIEFsbCw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+VGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiByZWdhcmRpbmcg dGhlIHNldHVwIGF0dHJpYnV0ZSB2YWx1ZSBpbiBzdWJzZXF1ZW50IG9mZmVycyB3aGVuIGVzdGFi bGlzaGluZyBuZXcgRFRMUyBhc3NvY2lhdGlvbiBpcyBub3QgZGVzaXJlZC4gQmFzZWQgb24gdGhh dCBkaXNjdXNzaW9uIGl0IHdhcyBkZWNpZGVkIHRoYXQgc2V0dXAgdmFsdWUgY2FuDQogYmUgZWl0 aGVyIGN1cnJlbnRseSBuZWdvdGlhdGVkIHZhbHVlIG9yIGFjdHBhc3MuJm5ic3A7VGhlcmUgYXJl IGFsc28gVURQL0RUTFMgd2l0aG91dCBTVFVOIE5BVCB0cmF2ZXJzYWwgc2NlbmFyaW9zIHRoYXQg b25seSB3b3JrIHdoZW4gZW5kIHBvaW50IGJlaGluZCBOQVQgaXMgYWN0aXZlLiBJIHRoaW5rIHNl bmRpbmcgYWN0cGFzcyBpbiBvZmZlcnMgaXMgYSBnZW5lcmFsbHkgc2FmZXIgb3B0aW9uLCBidXQg SSB0aGluayBTSE9VTEQgaGVyZSBpcyBtb3JlDQogYXBwcm9wcmlhdGUgdGhlbiBNVVNULjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPlBsZWFzZSBub3RlIHRoYXQmbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2MyNzZWN0aW9uLTUiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2MyNzZWN0aW9u LTU8L2E+IHNheXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgZW5kcG9pbnQgTVVTVCB1c2UgdGhlIHNldHVwIGF0dHJpYnV0ZSBkZWZp bmVkIGluIFtSRkM0MTQ1XS4gVGhlIGVuZHBvaW50IHRoYXQgaXMgdGhlIG9mZmVyZXIgTVVTVCB1 c2UgdGhlIHNldHVwIGF0dHJpYnV0ZSB2YWx1ZSBvZiBzZXR1cDphY3RwYXNzIGFuZCBiZSBwcmVw YXJlZCB0byByZWNlaXZlIGEgY2xpZW50X2hlbGxvIGJlZm9yZSBpdCByZWNlaXZlcyB0aGUgYW5z d2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPlRoaXMgYXBwbGllcyBu b3Qgb25seSB0byBpbml0aWFsIGJ1dCB0byBBTEwgb2ZmZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Y29sb3I6YmxhY2siPkZpbmFsbHksIEkgY2FuIGRvdWJsZSBjaGVjaywgYnV0IEkgYW0g ZmFpcmx5IHN1cmUgdGhlcmUgYXJlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gdGhhdCB2aW9sYXRl IHRoaXMgcnVsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGcmksIEp1biAyLCAyMDE3IGF0IDEyOjQ0IFBNLCBFcmljIFJlc2NvcmxhICZsdDs8 YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBm b2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UkZDIDU3NjMgcmVxdWlyZWQgKGFuZCBKU0VQIGltcG9ydGVkKSB0aGF0IGFsbCBvZmZlcnMg aW5jbHVkZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgYT1zZXR1cDphY3RwYXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGFzc3VtaW5nIEkgYW0gcmVhZGluZzo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMt ZHRscy1zZHAtMjQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yNDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29ycmVjdGx5LCBTIDQuMiBh bGxvd3MgdGhlIGluaXRpYWwgb2ZmZXIgdG8gY29udGFpbiBhbnl0aGluZyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRob3VnaCBlbmNvdXJhZ2Vz IGFjdHBhc3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtXaGVuIGFuIG9mZmVyZXIgc2VuZHMgdGhlIGluaXRpYWwgb2Zm ZXIsIHRoZSBvZmZlcmVyIE1VU1QgaW5zZXJ0IGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7U0RQICdzZXR1cCcgYXR0cmli dXRlIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbiBbUkZDNDE0NV0sIGFuZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O29uZSBvciBtb3JlIFNEUCAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZXMgYWNjb3JkaW5nIHRvIHRo ZSBwcm9jZWR1cmVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7aW4gW1JGQzgxMjJdLiZuYnNwOyBJbiBhZGRpdGlvbiwgdGhl IG9mZmVyZXIgTVVTVCBpbnNlcnQgaW4gdGhlIG9mZmVyIGFuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7U0RQICd0bHMtaWQn IGF0dHJpYnV0ZSB3aXRoIGEgdW5pcXVlIHZhbHVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7SWYgdGhlIG9mZmVyZXIg aW5zZXJ0cyB0aGUgU0RQICdzZXR1cCcgYXR0cmlidXRlIHdpdGggYW4gJ2FjdHBhc3MnIG9yPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7J3Bhc3NpdmUnIGF0dHJpYnV0ZSB2YWx1ZSwgdGhlIG9mZmVyZXIgTVVTVCBiZSBwcmVw YXJlZCB0byByZWNlaXZlIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtEVExTIENsaWVudEhlbGxvIG1lc3NhZ2UgKGlmIGEg bmV3IERUTFMgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQgYnk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0aGUgYW5zd2Vy ZXIpIGZyb20gdGhlIGFuc3dlcmVyIGJlZm9yZSB0aGUgb2ZmZXJlciByZWNlaXZlcyB0aGUgU0RQ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7YW5zd2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gb3Igc3ViZXF1ZW50IG9mZmVycywgaXQgYWxzbyBnaXZlcyBmbGV4aWJp bGl0eSBidXQgcG9pbnRzIGF0IDQxNDUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28uLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gQ2hhbmdpbmcgdGhlIGJlaGF2aW9yIGZvciBp bml0aWFsIG9mZmVycyBzZWVtcyBsaWtlIGl0IHByZXNlbnRzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIHNlcmlvdXMgaW50ZXJvcCByaXNrLCBi ZWNhdXNlIHByZXZpb3VzbHkgeW91IGNvdWxkIGRlcGVuZCBvbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIG9mZmVyIGJlaW5nIGFjdHBhc3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIu IEpTRVAgcmVxdWlyZXMgYWN0cGFzcyBmb3IgYWxsIG9mZmVycywgc28gYXQgbGVhc3QgaXQncyBz dHJpY3Rlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGF0IHdhcyB0aGUgcmF0aW9uYWxlIGZvciB0aGVzZSBjaGFuZ2VzPyBGZWVsIGZy ZWUgdG8gcG9pbnQgbWUgYXQgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5tYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiB3aGVyZSB0aGF0IGhhcHBl bmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDtIaSBmb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UkZDIDU3NjMgcmVxdWlyZWQgKGFuZCBKU0VQIGltcG9ydGVkKSB0aGF0 IGFsbCBvZmZlcnMgaW5jbHVkZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgYT1zZXR1cDphY3RwYXNzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGFzc3VtaW5nIEkg YW0gcmVhZGluZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tbXVzaWMtZHRscy1zZHAtMjQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yNDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29ycmVj dGx5LCBTIDQuMiBhbGxvd3MgdGhlIGluaXRpYWwgb2ZmZXIgdG8gY29udGFpbiBhbnl0aGluZyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRob3Vn aCBlbmNvdXJhZ2VzIGFjdHBhc3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtXaGVuIGFuIG9mZmVyZXIgc2VuZHMgdGhl IGluaXRpYWwgb2ZmZXIsIHRoZSBvZmZlcmVyIE1VU1QgaW5zZXJ0IGFuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7U0RQICdz ZXR1cCcgYXR0cmlidXRlIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbiBbUkZDNDE0NV0s IGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwO29uZSBvciBtb3JlIFNEUCAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZXMgYWNj b3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7aW4gW1JGQzgxMjJdLiZuYnNwOyBJbiBh ZGRpdGlvbiwgdGhlIG9mZmVyZXIgTVVTVCBpbnNlcnQgaW4gdGhlIG9mZmVyIGFuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 U0RQICd0bHMtaWQnIGF0dHJpYnV0ZSB3aXRoIGEgdW5pcXVlIHZhbHVlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7SWYg dGhlIG9mZmVyZXIgaW5zZXJ0cyB0aGUgU0RQICdzZXR1cCcgYXR0cmlidXRlIHdpdGggYW4gJ2Fj dHBhc3MnIG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7J3Bhc3NpdmUnIGF0dHJpYnV0ZSB2YWx1ZSwgdGhlIG9mZmVyZXIg TVVTVCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtEVExTIENsaWVudEhlbGxvIG1l c3NhZ2UgKGlmIGEgbmV3IERUTFMgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQgYnk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDt0aGUgYW5zd2VyZXIpIGZyb20gdGhlIGFuc3dlcmVyIGJlZm9yZSB0aGUgb2ZmZXJlciByZWNl aXZlcyB0aGUgU0RQPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7YW5zd2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igc3ViZXF1ZW50IG9mZmVycywgaXQgYWxzbyBn aXZlcyBmbGV4aWJpbGl0eSBidXQgcG9pbnRzIGF0IDQxNDUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28uLi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gQ2hhbmdpbmcgdGhlIGJl aGF2aW9yIGZvciBpbml0aWFsIG9mZmVycyBzZWVtcyBsaWtlIGl0IHByZXNlbnRzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIHNlcmlvdXMgaW50 ZXJvcCByaXNrLCBiZWNhdXNlIHByZXZpb3VzbHkgeW91IGNvdWxkIGRlcGVuZCBvbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIG9mZmVyIGJl aW5nIGFjdHBhc3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjIuIEpTRVAgcmVxdWlyZXMgYWN0cGFzcyBmb3IgYWxsIG9mZmVycywgc28gYXQg bGVhc3QgaXQncyBzdHJpY3Rlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHdhcyB0aGUgcmF0aW9uYWxlIGZvciB0aGVzZSBjaGFu Z2VzPyBGZWVsIGZyZWUgdG8gcG9pbnQgbWUgYXQgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiB3aGVy ZSB0aGF0IGhhcHBlbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CBD7C32ESESSMB109erics_-- From nobody Mon Jun 5 00:18:09 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32075129ADF; Mon, 5 Jun 2017 00:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfOXqWYtMMBP; Mon, 5 Jun 2017 00:18:04 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF650129ADC; Mon, 5 Jun 2017 00:18:03 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-fc-593505a9e562 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1F.3C.03383.9A505395; Mon, 5 Jun 2017 09:18:01 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 09:16:20 +0200 From: Christer Holmberg To: Roman Shpount , Cullen Jennings CC: Ben Campbell , Eric Rescorla , "Martin Thomson" , "mmusic-chairs@ietf.org" , mmusic Thread-Topic: [MMUSIC] Fwd: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHS2ldELwNcYwD50E6oSow85173oqIO6swAgAcKVoA= Date: Mon, 5 Jun 2017 07:16:19 +0000 Message-ID: References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D55AE0931DBABchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUyM2K7qO5KVtNIg1OTbSzmd55mt1jx+hy7 xYf1Pxgtrp35x2hxfud6Joupyx+zWMy4MJXZgd1j56y77B5Llvxk8rh8/iOjx6ydT1g8Jj9u Y/a4NaUggC2KyyYlNSezLLVI3y6BK+PSyx+sBd92MFZ82f6DuYHx/2bGLkYODgkBE4lZU1m6 GLk4hASOMEps/T2dvYuRE8hZxCjRNZ0ZpIZNwEKi+582SFhEwE3i7Yw3rCD1zAL7GCW2n+li AUkIC9RLrHu8GiwhItDAKPGo7wcLRIeVxJVXW8FsFgEVicaZ3cwgNq+AtcSNr39ZITY/Z5RY 2/YNrIhTIFDi6tmlYEWMAmIS30+tYQKxmQXEJW49mQ9mSwgISCzZc54ZwhaVePn4HyvIpaIC ehLv9ntChBUlPr7axwjRmiCx7WwvO8ReQYmTM5+wTGAUnYVk6iwkZbOQlEHEtSS+/NjHBmEr SkzpfghUwwFka0q8eVgLYVpL3NmegaxiASPHKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzA +D645bfuDsbVrx0PMQpwMCrx8Gq+NYkUYk0sK67MPcQowcGsJMJbfB0oxJuSWFmVWpQfX1Sa k1p8iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dUA6NVx7avCTtNe0w/dFdvmv0l6Mru nb/0b29e3sb5VcTjf/4xp5XpJRfrUmf93h8z74b6rv8v25bY3j6TfiXbu7BokUTGo9zMC7rH dt0MOJVX3Dsl/nn/362Trp24N3/6rWIBNj9mwe8LnqlekBX5eaOndcsB9l3nn+rMmPfooTmn r37ky6PXruhqKLEUZyQaajEXFScCAAeIYKTrAgAA Archived-At: Subject: Re: [MMUSIC] Fwd: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 07:18:07 -0000 --_000_D55AE0931DBABchristerholmbergericssoncom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 Um9tYW4sIGFyZSB5b3UgcGxhbm5pbmcgdG8gY3JlYXRlIGEgcHVsbCByZXF1ZXN0Pw0KDQpDdWxs ZW4sIGZlZWwgZnJlZSB0byBzdWdnZXN0IHRleHQgdGhhdCB3b3VsZCBhZGRyZXNzIHlvdXIgaXNz dWUuDQoNCkkgZG8gTk9UIHdhbnQgdG8gZW5kIHVwIGhhdmluZyBhIG1pY3JvcGhvbmUgYXJndW1l bnQgYWJvdXQgdGhpcyBpbiBQcmFndWUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206 IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNv bT4+DQpEYXRlOiBUaHVyc2RheSAxIEp1bmUgMjAxNyBhdCAwMTo1MQ0KVG86IEN1bGxlbiBKZW5u aW5ncyA8Zmx1ZmZ5QGlpaS5jYTxtYWlsdG86Zmx1ZmZ5QGlpaS5jYT4+DQpDYzogQmVuIENhbXBi ZWxsIDxiZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+LCBFcmljIFJlc2Nv cmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+LCBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+ PiwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4sICJtbXVzaWMtY2hhaXJzQGlldGYu b3JnPG1haWx0bzptbXVzaWMtY2hhaXJzQGlldGYub3JnPiIgPG1tdXNpYy1jaGFpcnNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpYy1jaGFpcnNAaWV0Zi5vcmc+PiwgIm1tdXNpY0BpZXRmLm9yZzxtYWls dG86bW11c2ljQGlldGYub3JnPiIgPG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBGd2Q6IGRyYWZ0LWR0bHMtc2RwOiBBbGxvdyBv ZmZlcmVyIHRvIGVzdGFibGlzaCBEVExTIGFzc29jaWF0aW9uIGJlZm9yZSBpdCBoYXMgcmVjZWl2 ZWQgdGhlIFNEUCBhbnN3ZXI/DQoNCkhpIEFsbCwNCg0KSSB3aWxsIHRyeSB0byBwdXQgdG9nZXRo ZXIgYSBuZXcgcHVsbCByZXF1ZXN0IHRoYXQgd2lsbCBhZGRyZXNzIEN1bGxlbidzIGNvbmNlcm5z Lg0KDQpXaGF0IEkgd2FudCB0byBwcm9wb3NlIGlzOg0KDQoxLiBTdGFydGluZyBEVExTIGhhbmRz aGFrZSB1bnRpbCB0aGUgY29ycmVzcG9uZGVkIGFuc3dlciBpcyByZWNlaXZlZCBpcyBOT1QgUkVD T01NRU5ERUQgc2luY2UgaXQgY2FuIHJlc3VsdCBpbiB1bmF1dGhlbnRpY2F0ZWQgbWVkaWEuIElm IHVuYXV0aGVudGljYXRlZCBtZWRpYSBpcyBwbGF5ZWQgdG8gdGhlIGVuZCB1c2VyLCBpbiBjYXNl cyBzdWNoIGFzIGVhcmx5IG1lZGlhIGluIFNJUCBjYWxscywgdGhpcyBzaG91bGQgYmUgaW5kaWNh dGVkIHRvIHRoZSBlbmQgdXNlci4NCg0KMi4gSWYgRFRMUyBhc3NvY2lhdGlvbnMgYXJlIGVzdGFi bGlzaGVkIGJlZm9yZSB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXJzIGFyZSByZWNlaXZlZCwgdGhl c2UgYXNzb2NpYXRpb25zIE1VU1QgYmUgdG9ybiBkb3duIHdoZW4gbm8gbW9yZSBhbnN3ZXJzIGFy ZSBleHBlY3RlZCBhbmQgbm8gbWF0Y2hpbmcgZmluZ2VycHJpbnRzIGFyZSBmb3VuZC4NCg0KU28s IGFzIGEgcmVzdWx0LCB1bmF1dGhlbnRpY2F0ZWQgbWVkaWEgaXMgTk9UIFJFQ09NTUVOREVELCBi dXQgc3RpbGwgYWxsb3dlZC4gRW5kIHVzZXIgU0hPVUxEIGJlIHByb3Blcmx5IHdhcm5lZCB3aGVu IHVuYXV0aGVudGljYXRlZCBtZWRpYSBpcyBwbGF5ZWQuIFNJUCBpcyBzYXZlZC4NCg0KRmluYWxs eSwgdG8gcHJvdmlkZSBzZWN1cmUgc29sdXRpb24gZm9yIDEtODAwLUdPRkVERVggc2NlbmFyaW8g d2l0aCBmdWxsIElDRSBlbmQgcG9pbnRzLCB0cmlja2xlIElDRSBzaG91bGQgYmUgZXh0ZW5kZWQg dG8gcHJvdmlkZSB0bHMtaWQgYW5kIGZpbmdlcnByaW50LiBUaGlzIHdheSBEVExTIGFzc29jaWF0 aW9uIGNhbiBiZSBlc3RhYmxpc2hlZCBiZWZvcmUgY29kZWNzIGFyZSBuZWdvdGlhdGVkLCB3aGlj aCBzaG91bGQgYWxsb3cgZnVsbCBmZWF0dXJlZCBicmlkZ2luZyB3aXRoIFNJUC4NCg0KUmVnYXJk cywNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBXZWQsIE1heSAzMSwgMjAx NyBhdCA1OjQ1IFBNLCBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZm eUBpaWkuY2E+PiB3cm90ZToNCg0KTm8gLi4uIHRoZSBkcmFmdCAod2l0aCB0aGUgUFIpIGRvZXMg bm90IHdvcmsuIFRoZSBrZXkgaXNzdWUgaXMgdGhlIGxpbmUNCg0KICAgSG93ZXZlciwgdGhlIG9m ZmVyZXIgTVVTVCBOT1QNCiAgIGNvbXBsZXRlIHRoZSBEVExTIGhhbmRzaGFrZSBiZWZvcmUgaXQg aGFzIHJlY2VpdmVkIHRoZSBTRFAgYW5zd2VyLg0KDQpUaGlzIGJyZWFrcyB0aGUgdXNhZ2Ugb2Yg RFRMUy1TUlRQIHdpdGggU0lQIGFuZCBpcyBub3QgbmVlZGVkLiBUaGUgYXJndW1lbnQgdGhhdCB5 b3Ugc2hvdWxkIG5vdCBzZW5kIG1lZGlhIGJlZm9yZSB5b3Uga25vdyB3aG8gaXQgaXMgZ29pbmcg dG8gaXMgbm90IHRoZSBwcm9ibGVtLiBUaGUga2V5IGlzc3VlIGlzIHRoYXQgc29tZSB0aW1lcyBh biBTSVAgVUEgIG5lZWRzIHRvIGJlIGFibGUgdG8gcmVjZWl2ZSBtZWRpYSBiZWZvcmUgaXQga25v d3Mgd2hvIGl0IGlzIGZyb20uIE9mIGNvdXJzZSB0aGUgVUEgc2hvdWxkIGluZGljYXRlIGluIHRo ZSBjYWxsZXIgSUQgZXRjIHRoYXQgaXQgaXMgZG9lcyBub3Qga25vdyB3aG8gaXQgaXMgZnJvbS4g SXQgbWlnaHQgYmUgcmVhbGx5IHJlYXNvbmFibGUgZm9yIHRoZSBVQSBub3QgdG8gc2VuZCBhbnkg aHVtYW4gZ2VuZXJhdGVkIG1lZGlhIGJlZm9yZSBpdCBnZXQgdGhlIHRoZSBkdGxzLWlkIGluIHRo ZSBvZmZlci9hbnN3ZXIsIGFuZCB2YWxpZGF0ZSBhbnkgaWRlbnRpdHkgYXNzZXJ0aW9ucywgYW5k IHZhbGlkYXRlcyBpbiB0aGUgY2VydGlmaWNhdGVzIGFyZSBub3QgcmV2b2tlZCwgYW5kIHdoYXRl dmVyIGVsc2UgdGhlIFVBIHdhbnRzIHRvIHRvIGJ1dCB0aGUgc3BlYyBzaG91bGQgbm90IGZvcmJp ZCByZWNlaXZpbmcgaW5mb3JtYXRpb24gd2hpbGUgdGhhdCBpcyBhbGwgaGFwcGVuaW5nLiBBbmQg dG8gcmVjZWl2ZSBtZWRpYSwgaXQgbmVlZHMgdG8gY29tcGxldGUgdGhlIERUTFMgaGFuZHNoYWtl Lg0KDQpMZXQgbWUgYXNrLCBmb3IgeW91ciBhdmVyYWdlIGNhbGwgZmxvdyB0aGF0IHVzZXMgUFJB Q0ssIGRvIHdlIHRoaW5rIHRoYXQgY2FsbCBmbG93IHdvdWxkIHdvcmsgaWYgd2Ugc2FpZCB0aGVy ZSBjb3VsZCBub3QgYmUgYW55IG1lZGlhIGJlZm9yZSB0aGUgQW5zd2VyIHdhcyByZWNlaXZlZCA/ DQoNCg0KSSdtIHN1cmUgdGhlIG5leHQgaXNzdWUgaXMganVzdCBteSBjb25mdXNpb24gYnV0IEkg d2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoaXMgd291bGQgaGVscCBzb2x2ZSB0aGUgdW5hdXRo ZW50aWNhdGVkIGtleWluZyBwcm9ibGVtIGZybyBEVExTLVNSVFAuIEJ1dCB0aGUgZHRscy1pZCBp biB0aGlzIGRyYWZ0IG5ldmVyIGdldCB0aWVkIHRvIGFueXRoaW5nIGluIHRoZSBUTFMgc2Vzc2lv bi4gSXMgdGhhdCBzcGVjaWZpZWQgZWxzZXdoZXJlPyBEbyB3ZSBuZWVkIGEgcmVmIHRvIGl0ID8N Cg0KT25lIG90aGVyIGlzc3VlcyAuLi4gSXQgc2VlbXMgdGhhdCB0aGlzIHJlbW92ZXMgZnJvbSBS RkM1NzYzIHRoZSBsaW5lDQoNCiAgVGhlIFNJUCBtZXNzYWdlIGNvbnRhaW5pbmcgdGhlIG9mZmVy IFNIT1VMRCBiZSBzZW50IHRvDQogICB0aGUgb2ZmZXJlcidzIFNJUCBwcm94eSBvdmVyIGFuIGlu dGVncml0eSBwcm90ZWN0ZWQgY2hhbm5lbC4NCg0KZnJvbSBSRkMgNTc2My4gQW55IHJlYXNvbiBm b3IgdGhhdD8gU2VlbXMgbGlrZSB0aGUgZmluZ2VycHJpbnQgc2hvdWxkIHN0aWxsIGJlIGludGVn cml0eSBwcm90ZWN0ZWQuDQoNCg0KDQoNCg0KDQo+IE9uIE1heSAzMSwgMjAxNywgYXQgMjoyMiBQ TSwgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+ IHdyb3RlOg0KPg0KPg0KPiBDYW4gcGVvcGxlIGxpdmUgd2l0aCB0aGUgUFIgYXMgaXQgY3VycmVu dGx5IHN0YW5kcywgZXZlbiBpZiBpdKGvcyBub3QgobBwZXJmZWN0obE/IElmIG5vdCwgd2hhdCB3 b3VsZCBpdCB0YWtlIHRvIGJlIGFibGUgdG8gbGl2ZSB3aXRoIGl0PyBJdKGvcyBiZWVuIGFsbW9z dCAyIG1vbnRocyBzaW5jZSB0aGUgSUVURiBMQyBjb21wbGV0ZWQuIEl0IHdvdWxkIGJlIG5pY2Ug dG8gcHJvZ3Jlc3MgdGhpcyBzb29uLg0KPg0KPiBUaGFua3MhDQo+DQo+IEJlbi4NCj4NCj4+IEJl Z2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPj4NCj4+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIDxj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4+DQo+PiBTdWJqZWN0OiBSZTogW01NVVNJQ10gZHJhZnQtZHRscy1zZHA6IEFs bG93IG9mZmVyZXIgdG8gZXN0YWJsaXNoIERUTFMgYXNzb2NpYXRpb24gYmVmb3JlIGl0IGhhcyBy ZWNlaXZlZCB0aGUgU0RQIGFuc3dlcj8NCj4+IERhdGU6IE1heSAyOSwgMjAxNyBhdCA1OjQxOjE5 IEFNIENEVA0KPj4gVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208 bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+LCBFcmljIFJlc2NvcmxhIDxla3JAcnRm bS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+DQo+PiBDYzogIm1tdXNpY0BpZXRmLm9yZzxtYWls dG86bW11c2ljQGlldGYub3JnPiIgPG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYu b3JnPj4NCj4+DQo+PiBIaSwNCj4+DQo+PiBJIGhhdmUgdXBkYXRlZCB0aGUgUFIuDQo+Pg0KPj4g VGhlIHRleHQgbm93IHNheXMgqfhjb21wbGV0Zan3IGluc3RlYWQgb2YgqfhmaW5hbGlzZan3LiBJ biBhZGRpdGlvbiwgSSByZW1vdmVkDQo+PiB0aGUgdGV4dCBhYm91dCBhdHRhY2tzLCBhbmQgb25s eSBrZXB0IHRoZSB0ZXh0IHNheWluZyB0aGF0IG1lZGlhIHJlY2VpdmVkDQo+PiBiZWZvcmUgdGhl IGFuc3dlciBtdXN0IGJlIGNvbnNpZGVyZWQgdW5hdXRoZW50aWNhdGVkLg0KPj4NCj4+IElmIHBl b3BsZSBhcmUgc3RpbGwgbm90IGhhcHB5IHdpdGggdGhlIHRleHQsIEmp9mQgcmVhbGx5IGFwcHJl Y2lhdGUgc29tZQ0KPj4gdGV4dC4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+ Pg0KPj4NCj4+DQo+PiBPbiAyNi8wNS8xNyAxNDozMiwgIm1tdXNpYyBvbiBiZWhhbGYgb2YgQ2hy aXN0ZXIgSG9sbWJlcmciDQo+PiA8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KPj4gd3JvdGU6 DQo+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4gWW91IGFyZSB0aGUgRFRMUyBndXJ1cyAtIHBsZWFzZSBz dWdnZXN0IGNoYW5nZXMgdGhhdCBtYWtlcyB0aGUgdGV4dA0KPj4+IGNvcnJlY3QgLSBhbmQgc3Rp bGwgaG9wZWZ1bGx5IGtlZXBzIEN1bGxlbiBoYXBweSA6KQ0KPj4+DQo+Pj4gUmVnYXJkcywNCj4+ Pg0KPj4+IENocmlzdGVyDQo+Pj4NCj4+Pg0KPj4+IE9uIDI2LzA1LzE3IDE0OjAxLCAiTWFydGlu IFRob21zb24iIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IE9uIDI2IE1heSAyMDE3IGF0IDIwOjM3LCBF cmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0K Pj4+Pj4gQWxzbywgeW91IHNheSB0aGF0IGlmIHlvdSBpbml0aWF0ZSB0aGUgaGFuZHNoYWtlIGJl Zm9yZSB0aGUgYW5zd2VyDQo+Pj4+PiBpcyByZWNlaXZlZCB5b3UgYXJlIHZ1bG5lcmFibGUgdG8g YXR0YWNrcy4gV2hhdCBhdHRhY2tzIGFyZSB0aG9zZT8NCj4+Pj4NCj4+Pj4gSXQgc2hvdWxkIGJl ICJjb21wbGV0ZSIgLSBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgY29tcGxldGVkIGhhbmRzaGFr ZQ0KPj4+PiBsZWFkcyBpbW1lZGlhdGVseSB0byB1c2luZyB0aGUgY29ubmVjdGlvbi4gIFJlYWxs eSwgaXQncyB1c2luZyB0aGUNCj4+Pj4gY29ubmVjdGlvbiAoc2VuZGluZyBvciByZWNlaXZpbmcg ZGF0YSBvciB1c2luZyBleHBvcnRlcnMpIHRoYXQgcHV0cw0KPj4+PiB5b3UgYXQgcmlzaywgYnV0 IEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIHdvcnRoIHB1dHRpbmcgdGhhdCBmaW5lIGENCj4+Pj4g ZGlzdGluY3Rpb24gb24gaXQuDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+PiBtbXVzaWNA aWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+PiBtbXVz aWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gbW11c2lj QGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg0K --_000_D55AE0931DBABchristerholmbergericssoncom_ Content-Type: text/html; charset="euc-kr" Content-ID: <10F1EBBDA86921468A6D41020779991A@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+Um9tYW4sIGFy ZSB5b3UgcGxhbm5pbmcgdG8gY3JlYXRlIGEgcHVsbCByZXF1ZXN0PzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+Q3VsbGVuLCBmZWVsIGZyZWUgdG8gc3VnZ2VzdCB0ZXh0IHRoYXQgd291 bGQgYWRkcmVzcyB5b3VyIGlzc3VlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBk byBOT1Qgd2FudCB0byBlbmQgdXAgaGF2aW5nIGEgbWljcm9waG9uZSBhcmd1bWVudCBhYm91dCB0 aGlzIGluIFByYWd1ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaHJpc3RlcjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpi bGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6 IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVt IG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkZyb206IDwvc3Bhbj5Sb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5IDEgSnVuZSAyMDE3IGF0IDAxOjUx PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Q3VsbGVuIEpl bm5pbmdzICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGlpaS5jYSI+Zmx1ZmZ5QGlpaS5jYTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+QmVu IENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1 bS5jb208L2E+Jmd0OywgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZt LmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDssIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJt YWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208 L2E+Jmd0OywNCiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWMtY2hhaXJzQGlldGYub3JnIj5tbXVz aWMtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1j aGFpcnNAaWV0Zi5vcmciPm1tdXNpYy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPiZxdW90Ow0K ICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ UmU6IFtNTVVTSUNdIEZ3ZDogZHJhZnQtZHRscy1zZHA6IEFsbG93IG9mZmVyZXIgdG8gZXN0YWJs aXNoIERUTFMgYXNzb2NpYXRpb24gYmVmb3JlIGl0IGhhcyByZWNlaXZlZCB0aGUgU0RQIGFuc3dl cj88YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPkhpIEFsbCwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd2lsbCB0cnkgdG8gcHV0 IHRvZ2V0aGVyIGEgbmV3IHB1bGwgcmVxdWVzdCB0aGF0IHdpbGwgYWRkcmVzcyBDdWxsZW4ncyBj b25jZXJucy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgSSB3YW50IHRvIHBy b3Bvc2UgaXM6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4xLiBTdGFydGluZyBEVExT IGhhbmRzaGFrZSB1bnRpbCB0aGUgY29ycmVzcG9uZGVkIGFuc3dlciBpcyByZWNlaXZlZCBpcyBO T1QgUkVDT01NRU5ERUQgc2luY2UgaXQgY2FuIHJlc3VsdCBpbiB1bmF1dGhlbnRpY2F0ZWQgbWVk aWEuIElmIHVuYXV0aGVudGljYXRlZCBtZWRpYSBpcyBwbGF5ZWQgdG8gdGhlIGVuZCB1c2VyLCBp biBjYXNlcyBzdWNoIGFzIGVhcmx5IG1lZGlhIGluIFNJUCBjYWxscywgdGhpcyBzaG91bGQgYmUg aW5kaWNhdGVkDQogdG8gdGhlIGVuZCB1c2VyLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+Mi4gSWYgRFRMUyBhc3NvY2lhdGlvbnMgYXJlIGVzdGFibGlzaGVkIGJlZm9yZSB0aGUgY29y cmVzcG9uZGluZyBhbnN3ZXJzIGFyZSByZWNlaXZlZCwgdGhlc2UgYXNzb2NpYXRpb25zIE1VU1Qg YmUgdG9ybiBkb3duIHdoZW4gbm8gbW9yZSBhbnN3ZXJzIGFyZSBleHBlY3RlZCBhbmQgbm8gbWF0 Y2hpbmcgZmluZ2VycHJpbnRzIGFyZSBmb3VuZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlNvLCBhcyBhIHJlc3VsdCwgdW5hdXRoZW50aWNhdGVkIG1lZGlhIGlzIE5PVCBSRUNPTU1F TkRFRCwgYnV0IHN0aWxsIGFsbG93ZWQuIEVuZCB1c2VyIFNIT1VMRCBiZSBwcm9wZXJseSB3YXJu ZWQgd2hlbiB1bmF1dGhlbnRpY2F0ZWQgbWVkaWEgaXMgcGxheWVkLiBTSVAgaXMgc2F2ZWQuPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5GaW5hbGx5LCB0byBwcm92aWRlIHNlY3VyZSBz b2x1dGlvbiBmb3IgMS04MDAtR09GRURFWCBzY2VuYXJpbyB3aXRoIGZ1bGwgSUNFIGVuZCBwb2lu dHMsIHRyaWNrbGUgSUNFIHNob3VsZCBiZSBleHRlbmRlZCB0byBwcm92aWRlIHRscy1pZCBhbmQg ZmluZ2VycHJpbnQuIFRoaXMgd2F5IERUTFMgYXNzb2NpYXRpb24gY2FuIGJlIGVzdGFibGlzaGVk IGJlZm9yZSBjb2RlY3MgYXJlIG5lZ290aWF0ZWQsIHdoaWNoIHNob3VsZCBhbGxvdyBmdWxsDQog ZmVhdHVyZWQgYnJpZGdpbmcgd2l0aCBTSVAuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5SZWdhcmRzLDwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNs ZWFyPSJhbGwiPg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFy dG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8 L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgTWF5 IDMxLCAyMDE3IGF0IDU6NDUgUE0sIEN1bGxlbiBKZW5uaW5ncyA8c3BhbiBkaXI9Imx0ciI+DQom bHQ7PGEgaHJlZj0ibWFpbHRvOmZsdWZmeUBpaWkuY2EiIHRhcmdldD0iX2JsYW5rIj5mbHVmZnlA aWlpLmNhPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KTm8gLi4uIHRoZSBkcmFmdCAod2l0aCB0aGUg UFIpIGRvZXMgbm90IHdvcmsuIFRoZSBrZXkgaXNzdWUgaXMgdGhlIGxpbmU8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7SG93ZXZlciwgdGhlIG9mZmVyZXIgTVVTVCBOT1Q8YnI+DQombmJzcDsgJm5i c3A7Y29tcGxldGUgdGhlIERUTFMgaGFuZHNoYWtlIGJlZm9yZSBpdCBoYXMgcmVjZWl2ZWQgdGhl IFNEUCBhbnN3ZXIuPGJyPg0KPGJyPg0KVGhpcyBicmVha3MgdGhlIHVzYWdlIG9mIERUTFMtU1JU UCB3aXRoIFNJUCBhbmQgaXMgbm90IG5lZWRlZC4gVGhlIGFyZ3VtZW50IHRoYXQgeW91IHNob3Vs ZCBub3Qgc2VuZCBtZWRpYSBiZWZvcmUgeW91IGtub3cgd2hvIGl0IGlzIGdvaW5nIHRvIGlzIG5v dCB0aGUgcHJvYmxlbS4gVGhlIGtleSBpc3N1ZSBpcyB0aGF0IHNvbWUgdGltZXMgYW4gU0lQIFVB Jm5ic3A7IG5lZWRzIHRvIGJlIGFibGUgdG8gcmVjZWl2ZSBtZWRpYSBiZWZvcmUgaXQga25vd3Mg d2hvDQogaXQgaXMgZnJvbS4gT2YgY291cnNlIHRoZSBVQSBzaG91bGQgaW5kaWNhdGUgaW4gdGhl IGNhbGxlciBJRCBldGMgdGhhdCBpdCBpcyBkb2VzIG5vdCBrbm93IHdobyBpdCBpcyBmcm9tLiBJ dCBtaWdodCBiZSByZWFsbHkgcmVhc29uYWJsZSBmb3IgdGhlIFVBIG5vdCB0byBzZW5kIGFueSBo dW1hbiBnZW5lcmF0ZWQgbWVkaWEgYmVmb3JlIGl0IGdldCB0aGUgdGhlIGR0bHMtaWQgaW4gdGhl IG9mZmVyL2Fuc3dlciwgYW5kIHZhbGlkYXRlIGFueSBpZGVudGl0eQ0KIGFzc2VydGlvbnMsIGFu ZCB2YWxpZGF0ZXMgaW4gdGhlIGNlcnRpZmljYXRlcyBhcmUgbm90IHJldm9rZWQsIGFuZCB3aGF0 ZXZlciBlbHNlIHRoZSBVQSB3YW50cyB0byB0byBidXQgdGhlIHNwZWMgc2hvdWxkIG5vdCBmb3Ji aWQgcmVjZWl2aW5nIGluZm9ybWF0aW9uIHdoaWxlIHRoYXQgaXMgYWxsIGhhcHBlbmluZy4gQW5k IHRvIHJlY2VpdmUgbWVkaWEsIGl0IG5lZWRzIHRvIGNvbXBsZXRlIHRoZSBEVExTIGhhbmRzaGFr ZS48YnI+DQo8YnI+DQpMZXQgbWUgYXNrLCBmb3IgeW91ciBhdmVyYWdlIGNhbGwgZmxvdyB0aGF0 IHVzZXMgUFJBQ0ssIGRvIHdlIHRoaW5rIHRoYXQgY2FsbCBmbG93IHdvdWxkIHdvcmsgaWYgd2Ug c2FpZCB0aGVyZSBjb3VsZCBub3QgYmUgYW55IG1lZGlhIGJlZm9yZSB0aGUgQW5zd2VyIHdhcyBy ZWNlaXZlZCA/PGJyPg0KPGJyPg0KPGJyPg0KSSdtIHN1cmUgdGhlIG5leHQgaXNzdWUgaXMganVz dCBteSBjb25mdXNpb24gYnV0IEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoaXMgd291bGQg aGVscCBzb2x2ZSB0aGUgdW5hdXRoZW50aWNhdGVkIGtleWluZyBwcm9ibGVtIGZybyBEVExTLVNS VFAuIEJ1dCB0aGUgZHRscy1pZCBpbiB0aGlzIGRyYWZ0IG5ldmVyIGdldCB0aWVkIHRvIGFueXRo aW5nIGluIHRoZSBUTFMgc2Vzc2lvbi4gSXMgdGhhdCBzcGVjaWZpZWQgZWxzZXdoZXJlPyBEbw0K IHdlIG5lZWQgYSByZWYgdG8gaXQgPzxicj4NCjxicj4NCk9uZSBvdGhlciBpc3N1ZXMgLi4uIEl0 IHNlZW1zIHRoYXQgdGhpcyByZW1vdmVzIGZyb20gUkZDNTc2MyB0aGUgbGluZTxicj4NCjxicj4N CiZuYnNwOyBUaGUgU0lQIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgb2ZmZXIgU0hPVUxEIGJlIHNl bnQgdG88YnI+DQombmJzcDsgJm5ic3A7dGhlIG9mZmVyZXIncyBTSVAgcHJveHkgb3ZlciBhbiBp bnRlZ3JpdHkgcHJvdGVjdGVkIGNoYW5uZWwuPGJyPg0KPGJyPg0KZnJvbSBSRkMgNTc2My4gQW55 IHJlYXNvbiBmb3IgdGhhdD8gU2VlbXMgbGlrZSB0aGUgZmluZ2VycHJpbnQgc2hvdWxkIHN0aWxs IGJlIGludGVncml0eSBwcm90ZWN0ZWQuPGJyPg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxkaXYg Y2xhc3M9Img1Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IE9uIE1h eSAzMSwgMjAxNywgYXQgMjoyMiBQTSwgQmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86 YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgQ2FuIHBlb3BsZSBsaXZlIHdpdGggdGhlIFBSIGFzIGl0IGN1 cnJlbnRseSBzdGFuZHMsIGV2ZW4gaWYgaXShr3Mgbm90IKGwcGVyZmVjdKGxPyBJZiBub3QsIHdo YXQgd291bGQgaXQgdGFrZSB0byBiZSBhYmxlIHRvIGxpdmUgd2l0aCBpdD8gSXShr3MgYmVlbiBh bG1vc3QgMiBtb250aHMgc2luY2UgdGhlIElFVEYgTEMgY29tcGxldGVkLiBJdCB3b3VsZCBiZSBu aWNlIHRvIHByb2dyZXNzIHRoaXMgc29vbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MhPGJy Pg0KJmd0Ozxicj4NCiZndDsgQmVuLjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBCZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZyb206IENocmlzdGVy IEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi48d2JyPmNvbTwvYT4mZ3Q7PGJyPg0KJmd0 OyZndDsgU3ViamVjdDogUmU6IFtNTVVTSUNdIGRyYWZ0LWR0bHMtc2RwOiBBbGxvdyBvZmZlcmVy IHRvIGVzdGFibGlzaCBEVExTIGFzc29jaWF0aW9uIGJlZm9yZSBpdCBoYXMgcmVjZWl2ZWQgdGhl IFNEUCBhbnN3ZXI/PGJyPg0KJmd0OyZndDsgRGF0ZTogTWF5IDI5LCAyMDE3IGF0IDU6NDE6MTkg QU0gQ0RUPGJyPg0KJmd0OyZndDsgVG86IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWls dG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+ Jmd0OywgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWty QHJ0Zm0uY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBDYzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRv Om1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBoYXZl IHVwZGF0ZWQgdGhlIFBSLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHRleHQgbm93 IHNheXMgqfhjb21wbGV0Zan3IGluc3RlYWQgb2YgqfhmaW5hbGlzZan3LiBJbiBhZGRpdGlvbiwg SSByZW1vdmVkPGJyPg0KJmd0OyZndDsgdGhlIHRleHQgYWJvdXQgYXR0YWNrcywgYW5kIG9ubHkg a2VwdCB0aGUgdGV4dCBzYXlpbmcgdGhhdCBtZWRpYSByZWNlaXZlZDxicj4NCiZndDsmZ3Q7IGJl Zm9yZSB0aGUgYW5zd2VyIG11c3QgYmUgY29uc2lkZXJlZCB1bmF1dGhlbnRpY2F0ZWQuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiBwZW9wbGUgYXJlIHN0aWxsIG5vdCBoYXBweSB3aXRo IHRoZSB0ZXh0LCBJqfZkIHJlYWxseSBhcHByZWNpYXRlIHNvbWU8YnI+DQomZ3Q7Jmd0OyB0ZXh0 Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IENocmlzdGVyPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgT24gMjYvMDUvMTcgMTQ6MzIsICZxdW90O21tdXNpYyBvbiBiZWhh bGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcmcXVvdDs8YnI+DQomZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIj5tbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwv YT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+PHdicj4mZ3Q7PGJyPg0K Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSGksPGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFlvdSBhcmUgdGhlIERUTFMgZ3VydXMgLSBw bGVhc2Ugc3VnZ2VzdCBjaGFuZ2VzIHRoYXQgbWFrZXMgdGhlIHRleHQ8YnI+DQomZ3Q7Jmd0OyZn dDsgY29ycmVjdCAtIGFuZCBzdGlsbCBob3BlZnVsbHkga2VlcHMgQ3VsbGVuIGhhcHB5IDopPGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IENocmlzdGVyPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDI2LzA1LzE3IDE0OjAxLCAmcXVvdDtNYXJ0 aW4gVGhvbXNvbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbSI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiAyNiBNYXkgMjAxNyBhdCAyMDozNywgRXJp YyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWxzbywgeW91IHNheSB0 aGF0IGlmIHlvdSBpbml0aWF0ZSB0aGUgaGFuZHNoYWtlIGJlZm9yZSB0aGUgYW5zd2VyPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgcmVjZWl2ZWQgeW91IGFyZSB2dWxuZXJhYmxlIHRvIGF0 dGFja3MuIFdoYXQgYXR0YWNrcyBhcmUgdGhvc2U/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgSXQgc2hvdWxkIGJlICZxdW90O2NvbXBsZXRlJnF1b3Q7IC0gb24g dGhlIGFzc3VtcHRpb24gdGhhdCBhIGNvbXBsZXRlZCBoYW5kc2hha2U8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IGxlYWRzIGltbWVkaWF0ZWx5IHRvIHVzaW5nIHRoZSBjb25uZWN0aW9uLiZuYnNwOyBS ZWFsbHksIGl0J3MgdXNpbmcgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBjb25uZWN0aW9uIChz ZW5kaW5nIG9yIHJlY2VpdmluZyBkYXRhIG9yIHVzaW5nIGV4cG9ydGVycykgdGhhdCBwdXRzPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyB5b3UgYXQgcmlzaywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCBp dCdzIHdvcnRoIHB1dHRpbmcgdGhhdCBmaW5lIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRpc3Rp bmN0aW9uIG9uIGl0Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZn dDsmZ3Q7IG1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuLzx3YnI+bGlzdGluZm8vbW11c2ljPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsmZ3Q7IG1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi88d2JyPmxpc3RpbmZvL21tdXNpYzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBt bXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYu b3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vbW11 c2ljPC9hPjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N Cjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D55AE0931DBABchristerholmbergericssoncom_-- From nobody Mon Jun 5 05:31:31 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D481273E2 for ; Mon, 5 Jun 2017 05:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSFVHsP6GLIz for ; Mon, 5 Jun 2017 05:31:26 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 D58FE12871F for ; Mon, 5 Jun 2017 05:31:25 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l75so14616633ywc.3 for ; Mon, 05 Jun 2017 05:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MMqYm5fO9Qwe5zroi2v5UwU/d7tt5KYG7ubzxHaHOsM=; b=RI1aeplHfEOIi5yEOrSYqQYReyfq1rsAD/ZUbRUB/CIEzKcosHTbGN7M4zdlXsBa6l J97ZWFzENAeJWzFV8ukcZ/rXzXxpi3tshZv92ChryrCAZW4WuHKzQ7Gc3eNKgFGF54Wz vAfW9pTZcrkCKbs02kPAxyCHbRy8skCecP3myfVymJrvLDHqGgilGDHhwIanv38xKmkl Y8HPfZjBXXNpy2FBPul7QmQOnpegVaSaK1qquZF+/Gp/M7eTOoxTcCiu6pMLEcg+x4wh wOuGdJ6Ix0aHWeryZ72tpSYVU2uF7VgYoa2M4ZihU4J8/ZY9e3UCS2cNpVTtE5mG3nfr BZkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MMqYm5fO9Qwe5zroi2v5UwU/d7tt5KYG7ubzxHaHOsM=; b=BJdLRVW/8V8NsUzw9Rgls4z+QPFpQrzQwFUQeLHKOCRDuu538IycE8j/Fjj9+Rmv32 zBjfi6glbRMRU6jTakIf3KK/sdrwvOA6H9tcJ44NBsLohgLb2Zru98VICF1WM6ySzQpc 8GBD/uIFu1AZDQQ5AH0Er2K3aCpY6wor2rwWu6Bz9gJXv5MMh7P+WPB219qgyMWyzZjT ZhM0lyly1X38heXIrNmTBcJp8lW1Xqjz/ndjW0gZRhpaQ48QrQ+bpAsgcSz6cCB2REC1 bW+v9BjoX2c31K3QkMqny5y0O0S4P5vl2HImKAVxl72KRhnBmwuu+UhEV7HXDoQbdRtN FVEg== X-Gm-Message-State: AODbwcCucK+BUNujiFvvM4QHLq6FSJgpDQB44oQ4U2HyNvSiL+ER2/Xd vWzWnWsZKBzjwr/yvZKen26074JPVW1L4g4= X-Received: by 10.129.97.193 with SMTP id v184mr15414484ywb.270.1496665885011; Mon, 05 Jun 2017 05:31:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Mon, 5 Jun 2017 05:30:44 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 5 Jun 2017 14:30:44 +0200 Message-ID: To: Roman Shpount Cc: mmusic WG Content-Type: multipart/alternative; boundary="001a114907226c9dd4055135aede" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 12:31:29 -0000 --001a114907226c9dd4055135aede Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 11:16 PM, Roman Shpount wrote: > Just to provide the historic background for this change. We have discussed > setup role in subsequent offers with Christer before IETF95 and decided to > remove the text that setup MUST be actpass in all the offers. This removed > this requirement from the initial offers as well (even though they weren't > discussed at that time). > > Now we have three options: > > 1. setup can be whatever application wants in all offers (current text) > 2. setup MUST be actpass in initial offer and whatever application wants > in subsequent (or, alternatively actpass or negotiated role in subsequent > offers). > 3. setup MUST be actpass in all the offers (back to RFC 5763) > > My top preference is that setup SHOULD be actpass in all the offers. > Second preference is 1 and hope that application will do the right thing. > > From my point of view 2 is strange, since there is no principal difference > between initial and subsequent offers, especially when 3pcc comes into > play. Any offer can end up being subsequent for one end point and initial > for another. > > I also think that RFC 5763 requirement is too strong. There are > implementations which send offers without actpass so it is already > violated. There are also legitimate scenarios where sending current role (subsequent > offers without ICE restart) or active (endpoints with basic UDP behind > NAT) makes more sense. > The argument for initial versus subsequent is that subsequent never worked properly in 5763 anyway, so even if it's a good idea to not require actpass in all cases, relaxing the rule is going to cause bustage for implementations which (correctly) rely on the initial offer being actpass. For this reason, I am not in favor of removing the MUST for the initial offer. I would be fine with MUST for initial and SHOULD for subsequent. -Ekr Regards, > > _____________ > Roman Shpount > > On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount wrote: > >> Hi All, >> >> There was a discussion regarding the setup attribute value in subsequent >> offers when establishing new DTLS association is not desired. Based on that >> discussion it was decided that setup value can be either currently >> negotiated value or actpass. There are also UDP/DTLS without STUN NAT >> traversal scenarios that only work when end point behind NAT is active. I >> think sending actpass in offers is a generally safer option, but I think >> SHOULD here is more appropriate then MUST. >> >> Please note that https://tools.ietf.org/html/rfc5763#section-5 says: >> >> The endpoint MUST use the setup attribute defined in [RFC4145]. The >> endpoint that is the offerer MUST use the setup attribute value of >> setup:actpass and be prepared to receive a client_hello before it receives >> the answer. >> >> >> This applies not only to initial but to ALL offers. >> >> Finally, I can double check, but I am fairly sure there are current >> implementation that violate this rule. >> >> Regards, >> >> _____________ >> Roman Shpount >> >> On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla wrote: >> >>> Hi folks, >>> >>> RFC 5763 required (and JSEP imported) that all offers include >>> >>> a=setup:actpass >>> >>> However, assuming I am reading: >>> https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 >>> >>> correctly, S 4.2 allows the initial offer to contain anything, >>> though encourages actpass: >>> >>> When an offerer sends the initial offer, the offerer MUST insert an >>> SDP 'setup' attribute according to the procedures in [RFC4145], and >>> one or more SDP 'fingerprint' attributes according to the procedures >>> in [RFC8122]. In addition, the offerer MUST insert in the offer an >>> SDP 'tls-id' attribute with a unique value. >>> >>> If the offerer inserts the SDP 'setup' attribute with an 'actpass' or >>> 'passive' attribute value, the offerer MUST be prepared to receive a >>> DTLS ClientHello message (if a new DTLS association is established by >>> the answerer) from the answerer before the offerer receives the SDP >>> answer. >>> >>> For subequent offers, it also gives flexibility but points at 4145. >>> >>> >>> So... >>> >>> 1. Changing the behavior for initial offers seems like it presents >>> a serious interop risk, because previously you could depend on >>> the offer being actpass. >>> >>> 2. JSEP requires actpass for all offers, so at least it's stricter. >>> >>> >>> What was the rationale for these changes? Feel free to point me at the >>> mailing list discussion where that happened. >>> >>> -Ekr >>> Hi folks, >>> >>> RFC 5763 required (and JSEP imported) that all offers include >>> >>> a=setup:actpass >>> >>> However, assuming I am reading: >>> https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 >>> >>> correctly, S 4.2 allows the initial offer to contain anything, >>> though encourages actpass: >>> >>> When an offerer sends the initial offer, the offerer MUST insert an >>> SDP 'setup' attribute according to the procedures in [RFC4145], and >>> one or more SDP 'fingerprint' attributes according to the procedures >>> in [RFC8122]. In addition, the offerer MUST insert in the offer an >>> SDP 'tls-id' attribute with a unique value. >>> >>> If the offerer inserts the SDP 'setup' attribute with an 'actpass' or >>> 'passive' attribute value, the offerer MUST be prepared to receive a >>> DTLS ClientHello message (if a new DTLS association is established by >>> the answerer) from the answerer before the offerer receives the SDP >>> answer. >>> >>> For subequent offers, it also gives flexibility but points at 4145. >>> >>> >>> So... >>> >>> 1. Changing the behavior for initial offers seems like it presents >>> a serious interop risk, because previously you could depend on >>> the offer being actpass. >>> >>> 2. JSEP requires actpass for all offers, so at least it's stricter. >>> >>> >>> What was the rationale for these changes? Feel free to point me at the >>> mailing list discussion where that happened. >>> >>> -Ekr >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> > --001a114907226c9dd4055135aede Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 11:16 PM, Roman Shpount <roman@telurix.com&= gt; wrote:
Just t= o provide the historic background for this change. We have discussed setup = role in subsequent offers with Christer before IETF95 and decided to remove= the text that setup MUST be actpass in all the offers. This removed this r= equirement from the initial offers as well (even though they weren't di= scussed at that time).

Now we have three options:

1. setup can = be whatever application wants in all offers (current text)
2. set= up MUST be actpass in initial offer and whatever application wants in subse= quent (or, alternatively actpass or negotiated role in subsequent offers).<= /div>
3. setup MUST be actpass in all the offers (back to RFC 5763)

My top preference is that setup SHOULD be actpass in = all the offers. Second preference is 1 and hope that application will do th= e right thing.

From my point of view 2 is strange,= since there is no principal difference between initial and subsequent offe= rs, especially when 3pcc comes into play. Any offer can end up being subseq= uent for one end point and initial for another.

I = also think that RFC 5763 requirement is too strong. There are implementatio= ns which send offers without actpass so it is already violated. There are a= lso legitimate scenarios where sending current role=C2=A0(subsequent offers without ICE restart) or active=C2=A0(endpoints with basic UDP behind NAT)=C2= =A0makes more sense.

The argument for initial v= ersus subsequent is that subsequent never worked properly in 5763
anyway, so even if it's a good idea to not require actpass in all case= s, relaxing the rule is
going to cause bustage for implementation= s which (correctly) rely on the initial offer
being actpass. For = this reason, I am not in favor of removing the MUST for the initial
offer. I would be fine with MUST for initial and SHOULD for subsequent.<= /div>

-Ekr

Regards,

_________= ____
Roman Shpount=

On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpoun= t <roman@telurix.com> wrote:
Hi Al= l,

There was a discussion regarding = the setup attribute value in subsequent offers when establishing new DTLS a= ssociation is not desired. Based on that discussion it was decided that set= up value can be either currently negotiated value or actpass.=C2=A0There are also UDP/DTLS without STUN NAT traversal= scenarios that only work when end point behind NAT is active. I think send= ing actpass in offers is a generally safer option, but I think SHOULD here = is more appropriate then MUST.


The endpoint MUST use the = setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST= use the setup attribute value of setup:actpass and be prepared to receive = a client_hello before it receives the answer.

This applies not only to initial but to ALL offers.

Finally, I can double check, but I am fairly= sure there are current implementation that violate this rule.

Regards,
_____________
Rom= an Shpount

= On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla <ekr@rtfm.com> wro= te:
Hi folks,

RFC 5763 required (and JSEP imported) that all offers include
=C2=A0 a=3Dsetup:actpass

However, ass= uming I am reading:
=C2=A0=C2=A0
= correctly, S 4.2 allows the initial offer to contain anything,
th= ough encourages actpass:

=C2=A0 =C2=A0When an offe= rer sends the initial offer, the offerer MUST insert an
=C2=A0 = =C2=A0SDP 'setup' attribute according to the procedures in [RFC4145= ], and
=C2=A0 =C2=A0one or more SDP 'fingerprint' attribu= tes according to the procedures
=C2=A0 =C2=A0in [RFC8122].=C2=A0 = In addition, the offerer MUST insert in the offer an
=C2=A0 =C2= =A0SDP 'tls-id' attribute with a unique value.

=
=C2=A0 =C2=A0If the offerer inserts the SDP 'setup' attribute = with an 'actpass' or
=C2=A0 =C2=A0'passive' attri= bute value, the offerer MUST be prepared to receive a
=C2=A0 =C2= =A0DTLS ClientHello message (if a new DTLS association is established by
=C2=A0 =C2=A0the answerer) from the answerer before the offerer rec= eives the SDP
=C2=A0 =C2=A0answer.

For s= ubequent offers, it also gives flexibility but points at 4145.

So...

1. Changing the = behavior for initial offers seems like it presents
a serious inte= rop risk, because previously you could depend on
the offer being = actpass.

2. JSEP requires actpass for all offers, = so at least it's stricter.


What= was the rationale for these changes? Feel free to point me at the
mailing list discussion where that happened.

-Ek= r
=C2=A0Hi folks,

RFC 5763 required (and= JSEP imported) that all offers include

=C2=A0 a= =3Dsetup:actpass

However, assuming I am reading:
=C2=A0=C2=A0
correctly, S 4.2 allo= ws the initial offer to contain anything,
though encourages actpa= ss:

=C2=A0 =C2=A0When an offerer sends the initial= offer, the offerer MUST insert an
=C2=A0 =C2=A0SDP 'setup= 9; attribute according to the procedures in [RFC4145], and
=C2=A0= =C2=A0one or more SDP 'fingerprint' attributes according to the pr= ocedures
=C2=A0 =C2=A0in [RFC8122].=C2=A0 In addition, the offere= r MUST insert in the offer an
=C2=A0 =C2=A0SDP 'tls-id' a= ttribute with a unique value.

=C2=A0 =C2=A0If the = offerer inserts the SDP 'setup' attribute with an 'actpass'= or
=C2=A0 =C2=A0'passive' attribute value, the offerer M= UST be prepared to receive a
=C2=A0 =C2=A0DTLS ClientHello messag= e (if a new DTLS association is established by
=C2=A0 =C2=A0the a= nswerer) from the answerer before the offerer receives the SDP
= =C2=A0 =C2=A0answer.

For subequent offers, it also= gives flexibility but points at 4145.


<= div>So...

1. Changing the behavior for initial off= ers seems like it presents
a serious interop risk, because previo= usly you could depend on
the offer being actpass.

<= /div>
2. JSEP requires actpass for all offers, so at least it's str= icter.


What was the rationale for t= hese changes? Feel free to point me at the
mailing list discussio= n where that happened.

-Ekr
=C2=A0
=

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



--001a114907226c9dd4055135aede-- From nobody Mon Jun 5 07:03:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C41129649 for ; Mon, 5 Jun 2017 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3FyizNRhgUu for ; Mon, 5 Jun 2017 07:03:16 -0700 (PDT) Received: from smtp114.iad3a.emailsrvr.com (smtp114.iad3a.emailsrvr.com [173.203.187.114]) (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 95829129549 for ; Mon, 5 Jun 2017 07:03:16 -0700 (PDT) Received: from smtp31.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A8044249CF; Mon, 5 Jun 2017 10:03:11 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp31.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D346F24875; Mon, 5 Jun 2017 10:03:10 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 05 Jun 2017 10:03:11 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Mon, 5 Jun 2017 08:03:09 -0600 Cc: Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Transfer-Encoding: quoted-printable Message-Id: <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 14:03:18 -0000 > On May 31, 2017, at 4:51 PM, Roman Shpount wrote: >=20 > 1. Starting DTLS handshake until the corresponded answer is received = is NOT RECOMMENDED since it can result in unauthenticated media. If = unauthenticated media is played to the end user, in cases such as early = media in SIP calls, this should be indicated to the end user. No. Doing the handshake as quickly as possible is recommend - it's what = you do with the media before you know who you are talking to that is the = issue you are concerned with. And knowing who you are talking often = involves much more than checking the fingerprint. So I don't agree this = is not recommended.=20 From nobody Mon Jun 5 08:39:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDA4129AFF; Mon, 5 Jun 2017 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipTFT1Dcwbjv; Mon, 5 Jun 2017 08:39:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7619129B14; Mon, 5 Jun 2017 08:39:20 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-3d-59357b27be98 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1C.82.03383.72B75395; Mon, 5 Jun 2017 17:39:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 17:36:05 +0200 From: Christer Holmberg To: Cullen Jennings , Roman Shpount CC: Ben Campbell , Eric Rescorla , "Martin Thomson" , "mmusic-chairs@ietf.org" , mmusic Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHS3gR6cOUoIT8u10KHxHCOXLs6qqIWZoyA Date: Mon, 5 Jun 2017 15:36:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBDB1E4@ESESSMB109.ericsson.se> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> In-Reply-To: <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> 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+NgFlrOIsWRmVeSWpSXmKPExsUyM2J7oK56tWmkwZPz/BbzO0+zW6x4fY7d 4sP6H4wW1878Y7Q4v3M9k8XU5Y9ZLGZcmMrswO6xc9Zddo8lS34yeVw+/5HRY9bOJywekx+3 MXvcmlIQwBbFZZOSmpNZllqkb5fAlfHvcknBSdaKpcv2MzcwrmPpYuTkkBAwkbi+9AJ7FyMX h5DAEUaJ3ff3sEE4ixglzrYfAXI4ONgELCS6/2mDNIgIuEnsfv8VrIZZYB+jxPYzXWCThAWq JO6s/scKUVQtsfn4RbBeEQEjiQsbYkFMFgEVidl/QkAqeAV8Jc7eaWSFWDWdSeLLgUtMIAlO ASuJLVe/gdmMAmIS30+tAbOZBcQlbj2ZzwRxtIDEkj3nmSFsUYmXjyHWSggoSSy6/RmqXkdi we5PbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtTi4tz042M9VKL MpOLi/Pz9PJSSzYxAqPv4JbfujsYV792PMQowMGoxMP7n800Uog1say4MvcQowQHs5IIr1YU UIg3JbGyKrUoP76oNCe1+BCjNAeLkjivw74LEUIC6YklqdmpqQWpRTBZJg5OqQbGSJF4ubRV z3ZXZL5+/IF5ofUiyWm/zyjaHdzCJ7NScs7pFv7P2jFWqwsYNi4+vfTSBk7zmutcq33fRv68 GCDRuczx2L/EE93HJ6X+nKLHJVDw4+DdZQlrX/kV5KZwzZAWWp384kDzDZHPky6GyeTkLF1+ Nn3apBMVF/4yxx2NvaTxesX8i6uF6pVYijMSDbWYi4oTASxBFju6AgAA Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 15:39:24 -0000 Hi, >> 1. Starting DTLS handshake until the corresponded answer is received is = NOT RECOMMENDED since it can >> result in unauthenticated media. If unauthenticated media is played to t= he end user, in cases such as early=20 >> media in SIP calls, this should be indicated to the end user. > > No. Doing the handshake as quickly as possible is recommend - it's what y= ou do with the media before > you know who you are talking to that is the issue you are concerned with.= And knowing who you are=20 > talking often involves much more than checking the fingerprint. So I don'= t agree this is not recommended.=20 Could you suggest text that you WOULD agree to? :) Regards, Christer From nobody Mon Jun 5 09:58:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D63127866 for ; Mon, 5 Jun 2017 09:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb-SuN8NJmwr for ; Mon, 5 Jun 2017 09:58:39 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 5FD8E1277BB for ; Mon, 5 Jun 2017 09:58:39 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v18so13249788pgb.1 for ; Mon, 05 Jun 2017 09:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4v2PiPyZD8Z9er1e790oLZXT+TBRXQuc1+p9DwywSMo=; b=lioAs28sTLprYpC2KNqymO0SOY5DBidCH2Vmjjnj5bVJkFmCnN7bKOaR+PtsWb/6e3 4Q70/h433jauD+RAe1ktnSb9ZexOQTvns1rG9wUH5nu1RZrsPY/Rd9gg2apCmYV+MjKR 6k7yBN5WQdw5BZnhNpQ8LCEARM/SVnyY2TZokVIRldwkjHB3Z9nt17fQgKvnuyVpwGjx DLNBq4EfpGSA6r753jCATUtJpHE5X6d2DUYKn9Cm6BaCbGOKNdnK3M4DDRA2H8R9cIsZ qmKPr2FpKkU8XeTfsWT9yR9vve+ZyWPJNcxNIJ4q+6R0lyqxNRVbsxprEnVAjRcNKs1y f/qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4v2PiPyZD8Z9er1e790oLZXT+TBRXQuc1+p9DwywSMo=; b=bCTIf70/HxwDuGstYfm8wEOXnHTnANoTsj9PwyB4RBK23S2mlNXMSxH/tQ+1a9R+m8 9NHaIr0NVVG7EdofyryY6oTS3TjyecMY79tzMyqYlDtlTixP9jrIPATMXhHFuWbfi/bn fZV7YyYhDxH8sJRnb67lJOW2DTJyL8/4OWUBTAxgiDhQ+L53/AqwUUGyoMN3zf4bMbts ZtHG5u2Ev6VB5ZBxdN6ngeWZ1kxJuFXnCHRAR8qNXr9JBE6zvu4vRKAQO/4VTMD/gluu mA2Jvhjww0PJOZrstVtRLQFcnhC8FG1rqjYkLnD4OkOWF7PE2crWCnbDXahukjK/hzVF 6UVQ== X-Gm-Message-State: AODbwcCmffmNp6u45MFBmIcImx4T2i3SRQFqLpSwWIs1R3OiZyOKkyoN xp06U9As5L3ysNkptc0= X-Received: by 10.84.191.165 with SMTP id a34mr16131045pld.136.1496681919006; Mon, 05 Jun 2017 09:58:39 -0700 (PDT) Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id q6sm1827410pfi.129.2017.06.05.09.58.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 09:58:38 -0700 (PDT) Received: by mail-pf0-f179.google.com with SMTP id m17so85698487pfg.3; Mon, 05 Jun 2017 09:58:38 -0700 (PDT) X-Received: by 10.84.217.154 with SMTP id p26mr16084976pli.295.1496681917806; Mon, 05 Jun 2017 09:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Mon, 5 Jun 2017 09:58:37 -0700 (PDT) In-Reply-To: <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> From: Roman Shpount Date: Mon, 5 Jun 2017 12:58:37 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Type: multipart/alternative; boundary="f403045c5a0c0d81dc0551396ae8" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:58:41 -0000 --f403045c5a0c0d81dc0551396ae8 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings wrote: > > > On May 31, 2017, at 4:51 PM, Roman Shpount wrote: > > > > 1. Starting DTLS handshake until the corresponded answer is received is > NOT RECOMMENDED since it can result in unauthenticated media. If > unauthenticated media is played to the end user, in cases such as early > media in SIP calls, this should be indicated to the end user. > > No. Doing the handshake as quickly as possible is recommend - it's what > you do with the media before you know who you are talking to that is the > issue you are concerned with. And knowing who you are talking often > involves much more than checking the fingerprint. So I don't agree this is > not recommended. > There are also implementation issues with getting media and not playing it. End point will still need to either buffer or somehow process the received packets so that playback can be started when the answer is received. If handshake is delayed until answer is received, none of this is an issue, so implementation is simpler. More importantly, I do not think new systems should be built without ICE. I understand there are legacy implementations which use symmetric UDP for media. In such cases it is allowed to complete handshake. Such solutions are legacy and building new systems like this are not recommended. It is recommended that new systems should implement full ICE, consent to send, and do not complete DTLS handshake before an answer SDP is received. Regards, _____________ Roman Shpount --f403045c5a0c0d81dc0551396ae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <= ;fluffy@iii.ca> wrote:

> On May 31, 2017, at 4:51 PM, Roman Shpount <roman@telurix.com> wrote:
>
> 1. Starting DTLS handshake until the corresponded answer is received i= s NOT RECOMMENDED since it can result in unauthenticated media. If unauthen= ticated media is played to the end user, in cases such as early media in SI= P calls, this should be indicated to the end user.

No. Doing the handshake as quickly as possible is recommend - it'= ;s what you do with the media before you know who you are talking to that i= s the issue you are concerned with. And knowing who you are talking often i= nvolves much more than checking the fingerprint. So I don't agree this = is not recommended.

There are also impl= ementation issues with getting media and not playing it. End point will sti= ll need to either buffer or somehow process the received packets so that pl= ayback can be started when the answer is received. If handshake is delayed = until answer is received, none of this is an issue, so implementation is si= mpler.

More importantly, I do not think new system= s should be built without ICE. I understand there are legacy implementation= s which use symmetric UDP for media. In such cases it is allowed to complet= e handshake. Such solutions are legacy and building new systems like this a= re not recommended. It is recommended that new systems should implement ful= l ICE, consent to send, and do not complete DTLS handshake before an answer= SDP is received.

Regards,
_____________
Roman Shpount
=C2=A0
--f403045c5a0c0d81dc0551396ae8-- From nobody Wed Jun 7 11:29:54 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E839129B01; Wed, 7 Jun 2017 11:29:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149686018620.2571.3953302082248256329@ietfa.amsl.com> Date: Wed, 07 Jun 2017 11:29:46 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 18:29:46 -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 SRTP and RTCP Feedback using the RTP/AVP Profile Authors : Andrew Hutton Roland Jesske Alan Johnston Gonzalo Salgueiro Bernard Aboba Filename : draft-ietf-mmusic-opportunistic-negotiation-00.txt Pages : 6 Date : 2017-06-05 Abstract: This document describes how the use of the Secure Real-time transport protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Audio Video Profile) defined in [RFC3551]. Such a mechanism is used to provide a means for encrypted media to be used in environments where support for encryption is not known in advance, and not required. The same mechanism is also applied to negotiation of the Extended RTP Profile for Real-time Transport Control Protocol Based Feedback (RTP/ AVPF) [RFC4585]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-00 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-negotiation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 7 14:52:35 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B1A12EB53; Wed, 7 Jun 2017 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX4_gmhRoZtX; Wed, 7 Jun 2017 14:52:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8251293EC; Wed, 7 Jun 2017 14:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6035; q=dns/txt; s=iport; t=1496872352; x=1498081952; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=AIqlTnYprs9N8vBpCDaLDdVugrlbWdsxyxtfyfrkl0Y=; b=in2jiGj2TJGlJ+Odx2/72M7zTL59piPnSrEyMlCJQWtWzn1cxtHywgAf ZC8INGhBjV4Ir6Yl3a7lnvy1PQg5u1l9aO+BP7d55mlekjGcvhCdpPNg5 U/Tdfgfnd05J+G/YWbyg3lk+TZBfjujoCwXDJoJHyPID1EA6Sjj9kwRl6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAADodDhZ/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBb4NzihiRaZBHhTmCEIYkAoJ1PxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBI1YFCwsYIwQDAgJGEQYBDAYCAQEXigMFCK8sgiYri1QBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR6GYYFgK4J1h3yCYQEEnjmTOIsPhnGUZx84gQpRIxWGAoFoJDa?= =?us-ascii?q?KAQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="254899335" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 21:52:31 +0000 Received: from [10.118.10.22] (rtp-fandreas-2-8815.cisco.com [10.118.10.22]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v57LqURZ022930; Wed, 7 Jun 2017 21:52:30 GMT To: Roman Shpount , Cullen Jennings References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> Cc: Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic From: Flemming Andreasen Message-ID: Date: Wed, 7 Jun 2017 17:52:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------11398487FB2991B7641B487E" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 21:52:34 -0000 This is a multi-part message in MIME format. --------------11398487FB2991B7641B487E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Can we get some specific text proposals from the people that seem to care about what we end up with here ? Thanks -- Flemming (as MMUSIC co-chair) On 6/5/17 12:58 PM, Roman Shpount wrote: > On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings > wrote: > > > > On May 31, 2017, at 4:51 PM, Roman Shpount > wrote: > > > > 1. Starting DTLS handshake until the corresponded answer is > received is NOT RECOMMENDED since it can result in unauthenticated > media. If unauthenticated media is played to the end user, in > cases such as early media in SIP calls, this should be indicated > to the end user. > > No. Doing the handshake as quickly as possible is recommend - it's > what you do with the media before you know who you are talking to > that is the issue you are concerned with. And knowing who you are > talking often involves much more than checking the fingerprint. So > I don't agree this is not recommended. > > > There are also implementation issues with getting media and not > playing it. End point will still need to either buffer or somehow > process the received packets so that playback can be started when the > answer is received. If handshake is delayed until answer is received, > none of this is an issue, so implementation is simpler. > > More importantly, I do not think new systems should be built without > ICE. I understand there are legacy implementations which use symmetric > UDP for media. In such cases it is allowed to complete handshake. Such > solutions are legacy and building new systems like this are not > recommended. It is recommended that new systems should implement full > ICE, consent to send, and do not complete DTLS handshake before an > answer SDP is received. > > Regards, > _____________ > Roman Shpount --------------11398487FB2991B7641B487E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Can we get some specific text proposals from the people that seem to care about what we end up with here ?

Thanks

-- Flemming (as MMUSIC co-chair)


On 6/5/17 12:58 PM, Roman Shpount wrote:
On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <fluffy@iii.ca> wrote:

> On May 31, 2017, at 4:51 PM, Roman Shpount <roman@telurix.com> wrote:
>
> 1. Starting DTLS handshake until the corresponded answer is received is NOT RECOMMENDED since it can result in unauthenticated media. If unauthenticated media is played to the end user, in cases such as early media in SIP calls, this should be indicated to the end user.

No. Doing the handshake as quickly as possible is recommend - it's what you do with the media before you know who you are talking to that is the issue you are concerned with. And knowing who you are talking often involves much more than checking the fingerprint. So I don't agree this is not recommended.

There are also implementation issues with getting media and not playing it. End point will still need to either buffer or somehow process the received packets so that playback can be started when the answer is received. If handshake is delayed until answer is received, none of this is an issue, so implementation is simpler.

More importantly, I do not think new systems should be built without ICE. I understand there are legacy implementations which use symmetric UDP for media. In such cases it is allowed to complete handshake. Such solutions are legacy and building new systems like this are not recommended. It is recommended that new systems should implement full ICE, consent to send, and do not complete DTLS handshake before an answer SDP is received.

Regards,
_____________
Roman Shpount
 

--------------11398487FB2991B7641B487E-- From nobody Wed Jun 7 15:59:05 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7317A120454 for ; Wed, 7 Jun 2017 15:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVAvwBvldzJV for ; Wed, 7 Jun 2017 15:58:53 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 4D4DB1270B4 for ; Wed, 7 Jun 2017 15:58:52 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id f185so9810811pgc.0 for ; Wed, 07 Jun 2017 15:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3T+KuJ7GYfSyglfJXjSoSxF8Rat5BGy/cxwVSf8yR+Q=; b=m+4hFI3YthACaLiWseyzYE5tg7Js+bCv1BnIJB5cCsIScnV/NDchFvgn0b5doCFkeY GSMIP8Xrm/YzgedsTNtpxrS8sPhTF0FyHpuMscye11HjuORtFKZxYcDSuHIT+Z7SH6Az NKHLdY/LFX7X3VSyx12Cfp5FcMAaMY3AWA43cSEuH+octFqqjL9QeL0yA4uzWgjhNjDw mzaVz1P4SQ1AGYLd6bvdzk1Yj8pYt6/NAREP8n8wfVPCci+Ata2Y17RwTXHcLhk+krGx Y3BLQmdPdQBoGBJ8maY6Ny9kXzhygLL9Fc5xneUp7gMpXyjVQABuRjYvfi5gF5tNjVix ixmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3T+KuJ7GYfSyglfJXjSoSxF8Rat5BGy/cxwVSf8yR+Q=; b=qRHC1hrJEhDYu7qdCTglwABnPSiLvJGfoEZTU+HSbr+Ayhk2+RPMjKr7lf4WVx/M0w F488jM1bqK+XIS1bIAgPeRhbtCA3PbH1NfdITA//23jYMJzy+BchkCUWcxe3EOu/+ic8 tAXgasB9ZSbyZfiamLxEVfGvO/JP4A9IR1ZiYn6S3tD5mkG41S0h0XM4t7pu2EmBOWk2 jV4c4gUaGOe0aIslMIQFYL5YsbtjVdPLEiINKsbGkDP7BVe5UFPmY7ZJg4QYZRZlq2qk xkYzjcF6vPGaAAGrg2tNpoErpdFHyo16twZpSEJH+jhuQ8uCF7w/jecSWaA1Y1jIW4u1 QDYA== X-Gm-Message-State: AODbwcBGfId70I8nfKr6PqFqz9Sb4c/SjaUIi8DzE94LUFEEE1RwRGaI ay8yNHlnXU1UEA6T X-Received: by 10.98.209.22 with SMTP id z22mr32764268pfg.95.1496876331787; Wed, 07 Jun 2017 15:58:51 -0700 (PDT) Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com. [74.125.83.52]) by smtp.gmail.com with ESMTPSA id c123sm5331890pfa.100.2017.06.07.15.58.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 15:58:50 -0700 (PDT) Received: by mail-pg0-f52.google.com with SMTP id k71so9794428pgd.2; Wed, 07 Jun 2017 15:58:49 -0700 (PDT) X-Received: by 10.84.217.154 with SMTP id p26mr30341103pli.295.1496876329586; Wed, 07 Jun 2017 15:58:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Wed, 7 Jun 2017 15:58:49 -0700 (PDT) In-Reply-To: References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> From: Roman Shpount Date: Wed, 7 Jun 2017 18:58:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Flemming Andreasen Cc: Cullen Jennings , Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Type: multipart/alternative; boundary="f403045c5a0ce5d8a8055166ad2a" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:59:04 -0000 --f403045c5a0ce5d8a8055166ad2a Content-Type: text/plain; charset="UTF-8" As a way forward on this issue, I am proposing the following: 1. Remove any recommendation regarding handling DTLS association before the answer (leave it up to implementation) 2. Put a note that accepting DTLS association before the answer can result in unverified media and if this media is played back to the end user, end user SHOULD be notified that media is coming from an unverified source. 3. Add clarification that DTLS associations established before the answer MUST be torn down when no more answers are expected and that fingerprints in any of the received answers match the negotiated certificate (Right now it is specified that DTLS association MUST be torn down if it does not match the answer. This is wrong if forking is used and multiple answers are received). Does anyone opposes this? Regards, _____________ Roman Shpount On Wed, Jun 7, 2017 at 5:52 PM, Flemming Andreasen wrote: > Can we get some specific text proposals from the people that seem to care > about what we end up with here ? > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > On 6/5/17 12:58 PM, Roman Shpount wrote: > > On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings wrote: > >> >> > On May 31, 2017, at 4:51 PM, Roman Shpount wrote: >> > >> > 1. Starting DTLS handshake until the corresponded answer is received is >> NOT RECOMMENDED since it can result in unauthenticated media. If >> unauthenticated media is played to the end user, in cases such as early >> media in SIP calls, this should be indicated to the end user. >> >> No. Doing the handshake as quickly as possible is recommend - it's what >> you do with the media before you know who you are talking to that is the >> issue you are concerned with. And knowing who you are talking often >> involves much more than checking the fingerprint. So I don't agree this is >> not recommended. >> > > There are also implementation issues with getting media and not playing > it. End point will still need to either buffer or somehow process the > received packets so that playback can be started when the answer is > received. If handshake is delayed until answer is received, none of this is > an issue, so implementation is simpler. > > More importantly, I do not think new systems should be built without ICE. > I understand there are legacy implementations which use symmetric UDP for > media. In such cases it is allowed to complete handshake. Such solutions > are legacy and building new systems like this are not recommended. It is > recommended that new systems should implement full ICE, consent to send, > and do not complete DTLS handshake before an answer SDP is received. > > Regards, > _____________ > Roman Shpount > > > > --f403045c5a0ce5d8a8055166ad2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a way forward on this issue, I am proposing the followi= ng:

1. = Remove any recommendation regarding handling DTLS association before the an= swer (leave it up to implementation)
2. Put a note that accepting DTLS association before the an= swer can result in unverified media and if this media is played back to the= end user, end user SHOULD be notified that media is coming from an unverif= ied source.
3. Add cl= arification that DTLS associations established before the answer MUST be to= rn down when no more answers are expected and that fingerprints in any of t= he received answers match the negotiated certificate (Right now it is speci= fied that DTLS association MUST be torn down if it does not match the answe= r. This is wrong if forking is used and multiple answers are received).

Does anyone opposes this?

Regards,

_____________
Roman Shpount

On Wed, Jun 7, 2017 at 5:52 PM, Flemming And= reasen <fandreas@cisco.com> wrote:
=20 =20 =20
Can we get some specific text proposals from the people that seem to care about what we end up with here ?

Thanks

-- Flemming (as MMUSIC co-chair)



On 6/5/17 12:58 PM,= Roman Shpount wrote:
=20
On Mon, Jun= 5, 2017 at 10:03 AM, Cullen Jennings <fluffy@iii.ca> wrote:

> On May 31, 2017, at 4:51 PM, Roman Shpount <roman@telurix.com> wrote:
>
> 1. Starting DTLS handshake until the corresponded answer is received is NOT RECOMMENDED since it can result in unauthenticated media. If unauthenticated media is played to the end user, in cases such as early media in SIP calls, this should be indicated to the end user.

No. Doing the handshake as quickly as possible is recommend - it's what you do with the media before you know who you are talking to that is the issue you are concerned with. And knowing who you are talking often involves much more than checking the fingerprint. So I don't agree this is not recommended.

There are also implementation issues with getting media and not playing it. End point will still need to either buffer or somehow process the received packets so that playback can be started when the answer is received. If handshake is delayed until answer is received, none of this is an issue, so implementation is simpler.

More importantly, I do not think new systems should be built without ICE. I understand there are legacy implementations which use symmetric UDP for media. In such cases it is allowed to complete handshake. Such solutions are legacy and building new systems like this are not recommended. It is recommended that new systems should implement full ICE, consent to send, and do not complete DTLS handshake before an answer SDP is received.

Regards,
_________= ____
Roman Shpount
=C2=A0


--f403045c5a0ce5d8a8055166ad2a-- From nobody Wed Jun 7 22:16:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0A127868 for ; Wed, 7 Jun 2017 22:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi52nXyiCzE7 for ; Wed, 7 Jun 2017 22:16:38 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::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 B9CED127444 for ; Wed, 7 Jun 2017 22:16:38 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id f192so7265092yba.2 for ; Wed, 07 Jun 2017 22:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Ng4TvEs37IkUUoPCnc9U36yCoTN1qc0zaeAyL4JQTE=; b=HZ3NleyNkFhtpNQ+iQcmVAaIrQc5xw9Ns1Lnm2DfQ9xMvloPFLVkyhUaYxcVHiL6DT MilxbPkep1fpmMHQmG9BdFPmdHZxdVAhCL/GgB7/TftR5GBogQj1ssiqH9SYwbv+xn9e yS2JLq3mkUL8Nps2INHJ44ikqi48f8JqyuT0+cEPyRG1pY2KMGd4tfEZUZV0bA9RkPwC kmUhrF27ARHXE45fcPDo7yml9xrToxILJ/7+XLoJtgh6hyax1t9f1DDMFoPP19RvECik 2rDeRwSW0yR7fuWVrB1HTD9hab2T1XN5Vvl379VdQ79C1d+6oddR1vzq1hLSVm08xic1 v/nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Ng4TvEs37IkUUoPCnc9U36yCoTN1qc0zaeAyL4JQTE=; b=f253W3XJN0kDTzPA+uOyui0Ign6k3zwTGg/5pXJrMkWdIxD1EabDMpWpieQoBEooHW aOwQUTjE9wo7oF5JFzEkun4iMASP63HhsRa9tnBEDkEukEKx3yOkvJun4w5VnrmSBsQV tT6oK7I5upRiUszfe05Q0KvLcTd9B7e+xA1PvJ/8/0g6zImdXJsFjL7nIV9YE04lcl4S 3m9wfvZ804YXyrvyW38ba719KZ2mJeugRCoG9jQJ1Hr2LVPTnQRMx4dIMmIZwufMksc/ aodVB52MR2667sf3egOpnfNJ41e13au5TzeP+LDs8PRng8FjcIvTlf7NJ8LSPR9GcnZb aEpg== X-Gm-Message-State: AODbwcBiTWzpcADDRyysmdWtY4A4WnMc9IUS1kPEpv1eC4KIOugdpvuP a7LX8j0QJ1YagMQ8OVh0WHN71T0tHn5W X-Received: by 10.37.44.72 with SMTP id s69mr9295962ybs.89.1496898997981; Wed, 07 Jun 2017 22:16:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Wed, 7 Jun 2017 22:15:57 -0700 (PDT) In-Reply-To: References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> From: Eric Rescorla Date: Thu, 8 Jun 2017 07:15:57 +0200 Message-ID: To: Roman Shpount Cc: Flemming Andreasen , Cullen Jennings , Ben Campbell , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Type: multipart/alternative; boundary="001a11432ade0a948b05516bf5c4" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 05:16:41 -0000 --001a11432ade0a948b05516bf5c4 Content-Type: text/plain; charset="UTF-8" i can live with that. -Ekr On Thu, Jun 8, 2017 at 12:58 AM, Roman Shpount wrote: > As a way forward on this issue, I am proposing the following: > > 1. Remove any recommendation regarding handling DTLS association before > the answer (leave it up to implementation) > 2. Put a note that accepting DTLS association before the answer can result > in unverified media and if this media is played back to the end user, end > user SHOULD be notified that media is coming from an unverified source. > 3. Add clarification that DTLS associations established before the answer > MUST be torn down when no more answers are expected and that fingerprints > in any of the received answers match the negotiated certificate (Right now > it is specified that DTLS association MUST be torn down if it does not > match the answer. This is wrong if forking is used and multiple answers are > received). > > Does anyone opposes this? > > Regards, > > _____________ > Roman Shpount > > On Wed, Jun 7, 2017 at 5:52 PM, Flemming Andreasen > wrote: > >> Can we get some specific text proposals from the people that seem to care >> about what we end up with here ? >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> >> On 6/5/17 12:58 PM, Roman Shpount wrote: >> >> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings wrote: >> >>> >>> > On May 31, 2017, at 4:51 PM, Roman Shpount wrote: >>> > >>> > 1. Starting DTLS handshake until the corresponded answer is received >>> is NOT RECOMMENDED since it can result in unauthenticated media. If >>> unauthenticated media is played to the end user, in cases such as early >>> media in SIP calls, this should be indicated to the end user. >>> >>> No. Doing the handshake as quickly as possible is recommend - it's what >>> you do with the media before you know who you are talking to that is the >>> issue you are concerned with. And knowing who you are talking often >>> involves much more than checking the fingerprint. So I don't agree this is >>> not recommended. >>> >> >> There are also implementation issues with getting media and not playing >> it. End point will still need to either buffer or somehow process the >> received packets so that playback can be started when the answer is >> received. If handshake is delayed until answer is received, none of this is >> an issue, so implementation is simpler. >> >> More importantly, I do not think new systems should be built without ICE. >> I understand there are legacy implementations which use symmetric UDP for >> media. In such cases it is allowed to complete handshake. Such solutions >> are legacy and building new systems like this are not recommended. It is >> recommended that new systems should implement full ICE, consent to send, >> and do not complete DTLS handshake before an answer SDP is received. >> >> Regards, >> _____________ >> Roman Shpount >> >> >> >> > --001a11432ade0a948b05516bf5c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i can live with that.

-Ekr

On = Thu, Jun 8, 2017 at 12:58 AM, Roman Shpount <roman@telurix.com> wrote:
As a way fo= rward on this issue, I am proposing the following:

1. Remove any recommendation re= garding handling DTLS association before the answer (leave it up to impleme= ntation)
2. Put a not= e that accepting DTLS association before the answer can result in unverifie= d media and if this media is played back to the end user, end user SHOULD b= e notified that media is coming from an unverified source.
3. Add clarification that DTLS assoc= iations established before the answer MUST be torn down when no more answer= s are expected and that fingerprints in any of the received answers match t= he negotiated certificate (Right now it is specified that DTLS association = MUST be torn down if it does not match the answer. This is wrong if forking= is used and multiple answers are received).

Does anyone opposes this?

Regards,

_____________
Ro= man Shpount

On Wed, Jun 7, 2017 at 5:52 PM, Flemming And= reasen <fandreas@cisco.com> wrote:
=20 =20 =20
Can we get some specific text proposals from the people that seem to care about what we end up with here ?

Thanks

-- Flemming (as MMUSIC co-chair)



On 6/5/17 12:58 PM, Roman Shpount wrote:
=20
On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <fluffy@iii.ca> wrote:

> On May 31, 2017, at 4:51 PM, Roman Shpount <roman@telurix.com> wrote:
>
> 1. Starting DTLS handshake until the corresponded answer is received is NOT RECOMMENDED since it can result in unauthenticated media. If unauthenticated media is played to the end user, in cases such as early media in SIP calls, this should be indicated to the end user.

No. Doing the handshake as quickly as possible is recommend - it's what you do with the media before you know who you are talking to that is the issue you are concerned with. And knowing who you are talking often involves much more than checking the fingerprint. So I don't agree this is not recommended.

There are also implementation issues with getting media and not playing it. End point will still need to either buffer or somehow process the received packets so that playback can be started when the answer is received. If handshake is delayed until answer is received, none of this is an issue, so implementation is simpler.

More importantly, I do not think new systems should be built without ICE. I understand there are legacy implementations which use symmetric UDP for media. In such cases it is allowed to complete handshake. Such solutions are legacy and building new systems like this are not recommended. It is recommended that new systems should implement full ICE, consent to send, and do not complete DTLS handshake before an answer SDP is received.

Regards,
_____________
Roman Shpount
=C2=A0



--001a11432ade0a948b05516bf5c4-- From nobody Thu Jun 8 06:25:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9375C12EB0F for ; Thu, 8 Jun 2017 06:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdsc6MTbyiNQ for ; Thu, 8 Jun 2017 06:25:25 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 E6B0D12EAF2 for ; Thu, 8 Jun 2017 06:25:24 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1484158ED; Thu, 8 Jun 2017 09:25:20 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 27ECB58E5; Thu, 8 Jun 2017 09:25:19 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 08 Jun 2017 09:25:20 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 8 Jun 2017 07:25:17 -0600 Cc: Roman Shpount , Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Transfer-Encoding: quoted-printable Message-Id: <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> To: Flemming Andreasen X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 13:25:26 -0000 I think the key things are: For devices that want to minimize delay in setting up media and avoid = media clipping, doing the TLS handshake as soon as possible is good = design but in some cases this means the system does the handshake = before the identity of the fingerprint is known.=20 If this is done, there is a risk of sending or receiving media before = the identity of the remote side is known and the system needs to be = designed to deal with theses risks in a way that is appropriate for the = system that uses this. =20 Receiving media from an unknown sources typically has fairly low risk = while sending human generated media, such as the input from a microphone = or camera, to a unknown users has much higher privacy risks.=20 If we agree on the above, I think we could get text that covers that. = Note that I think the key thing one needs to wait for is not just the = fingerprint in the Answer but also knowing the identity of the Answer. = In many cases this is just the =46rom in the answer as the signaling is = trusted but in case where it is not, the key thing is to know the media = is going to the appropriate person and that might involve more that just = having the fingerprint in the answer.=20 > On Jun 7, 2017, at 3:52 PM, Flemming Andreasen = wrote: >=20 > Can we get some specific text proposals from the people that seem to = care about what we end up with here ?=20 >=20 > Thanks=20 >=20 > -- Flemming (as MMUSIC co-chair) >=20 >=20 > On 6/5/17 12:58 PM, Roman Shpount wrote: >> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings = wrote: >>=20 >> > On May 31, 2017, at 4:51 PM, Roman Shpount = wrote: >> > >> > 1. Starting DTLS handshake until the corresponded answer is = received is NOT RECOMMENDED since it can result in unauthenticated = media. If unauthenticated media is played to the end user, in cases such = as early media in SIP calls, this should be indicated to the end user. >>=20 >> No. Doing the handshake as quickly as possible is recommend - it's = what you do with the media before you know who you are talking to that = is the issue you are concerned with. And knowing who you are talking = often involves much more than checking the fingerprint. So I don't agree = this is not recommended. >>=20 >> There are also implementation issues with getting media and not = playing it. End point will still need to either buffer or somehow = process the received packets so that playback can be started when the = answer is received. If handshake is delayed until answer is received, = none of this is an issue, so implementation is simpler. >>=20 >> More importantly, I do not think new systems should be built without = ICE. I understand there are legacy implementations which use symmetric = UDP for media. In such cases it is allowed to complete handshake. Such = solutions are legacy and building new systems like this are not = recommended. It is recommended that new systems should implement full = ICE, consent to send, and do not complete DTLS handshake before an = answer SDP is received. >>=20 >> Regards, >> _____________ >> Roman Shpount >> =20 >=20 From nobody Thu Jun 8 09:49:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B91294F7 for ; Thu, 8 Jun 2017 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo1Ifr4AlzVl for ; Thu, 8 Jun 2017 09:49:43 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 70BD21294BF for ; Thu, 8 Jun 2017 09:49:43 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 9so19091947pfj.1 for ; Thu, 08 Jun 2017 09:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4+dNWKcXh7bYk8zQrX0Ke3euEC8bZ6gIDT7ubGRciJc=; b=OVc2WExAEqCETLivESt0LsHN3s/ES/d8Avf00KqyhkjCnHy38Cv+FEw3pl+DmpSE+L uOeZTBZen3X6NaXjJTyiR+gpTzYv3PfNWsXGfYT1CqrG55hrVI7t3UhKUca3ofTJgrdE bgzXtyF1nXEBovYriVi9JYjzRbYMJt2ISmiDnGojh108/G/FGHgnuhRF3+JI7QZnD7jr jdRVRnGFMnr0s13nEdcKegzBNLvAEVWzAMaxgECTmpqvfpR1sMz5YUv6V3+8OxWEMy0e DIHzSDTZTmV+fpluk7W/hKOU1Zse4hVnFYWTp8mcDkfpRs/p7V99Tl7p/2MeXw0/fiI6 68Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4+dNWKcXh7bYk8zQrX0Ke3euEC8bZ6gIDT7ubGRciJc=; b=RRiX3vA1N0b98x+ggOTl2096y/cGZW0qEEwnkaFiXCVb2ynvWb4RrYeHSVddF+C+9u gopg2b9xNgEO+j7r4DNcQ/b0i3RcPQ3BtuDG443Ozd6MxSBiN5QDB6Emc3no89dcvzju Ym7Mu6w0k+DuziBxFFIkP1SAm//5LVAK6oNUAvn9iTGjvr/JDQFIhVKyh0iMWdYusw29 hUM/WbzPC1y6BUV5vJJRVHrL5LZ/SmkKvoJQcj73zM7SlNzXhcelIJzT2m04WXPoEgua QTsm7BnjXtxL05Hyu7wcWXeKv4CMxp6IoV65ET8faxDUTQA+/ZwAJ6tv1kA4bQ5Ftaxz +G1w== X-Gm-Message-State: AODbwcBnB9IRNQ3YHe1j6F+qieLYnYo53PE2btRwmpJVvP9TE1BOL73Q OGUm7rpiVnoz12/i X-Received: by 10.99.107.136 with SMTP id g130mr37505448pgc.3.1496940583038; Thu, 08 Jun 2017 09:49:43 -0700 (PDT) Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com. [209.85.192.180]) by smtp.gmail.com with ESMTPSA id v8sm350075pfa.10.2017.06.08.09.49.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 09:49:41 -0700 (PDT) Received: by mail-pf0-f180.google.com with SMTP id 9so19091692pfj.1; Thu, 08 Jun 2017 09:49:41 -0700 (PDT) X-Received: by 10.98.223.131 with SMTP id d3mr17645097pfl.112.1496940581217; Thu, 08 Jun 2017 09:49:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Thu, 8 Jun 2017 09:49:40 -0700 (PDT) In-Reply-To: <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> From: Roman Shpount Date: Thu, 8 Jun 2017 12:49:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Flemming Andreasen , Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Type: multipart/alternative; boundary="f403045cc7d497f287055175a3f8" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 16:49:45 -0000 --f403045cc7d497f287055175a3f8 Content-Type: text/plain; charset="UTF-8" We can expand the language regarding unverified DTLS association that end point SHOULD inform the end user when unverified media is played and SHOULD not send user generated media until stream is verified. I also want to add that fingerprints SHOULD be sent over integrity protected signaling channel. I think this should address your concern about the Answer identity. I think specifics of integrity protection of fingerprint delivery is outside of scope of this draft. Would this address your comments? Regards, _____________ Roman Shpount On Thu, Jun 8, 2017 at 9:25 AM, Cullen Jennings wrote: > > I think the key things are: > > For devices that want to minimize delay in setting up media and avoid > media clipping, doing the TLS handshake as soon as possible is good design > but in some cases this means the system does the handshake before the > identity of the fingerprint is known. > > If this is done, there is a risk of sending or receiving media before the > identity of the remote side is known and the system needs to be designed to > deal with theses risks in a way that is appropriate for the system that > uses this. > > Receiving media from an unknown sources typically has fairly low risk > while sending human generated media, such as the input from a microphone or > camera, to a unknown users has much higher privacy risks. > > If we agree on the above, I think we could get text that covers that. Note > that I think the key thing one needs to wait for is not just the > fingerprint in the Answer but also knowing the identity of the Answer. In > many cases this is just the From in the answer as the signaling is trusted > but in case where it is not, the key thing is to know the media is going > to the appropriate person and that might involve more that just having the > fingerprint in the answer. > > > > > On Jun 7, 2017, at 3:52 PM, Flemming Andreasen > wrote: > > > > Can we get some specific text proposals from the people that seem to > care about what we end up with here ? > > > > Thanks > > > > -- Flemming (as MMUSIC co-chair) > > > > > > On 6/5/17 12:58 PM, Roman Shpount wrote: > >> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings wrote: > >> > >> > On May 31, 2017, at 4:51 PM, Roman Shpount wrote: > >> > > >> > 1. Starting DTLS handshake until the corresponded answer is received > is NOT RECOMMENDED since it can result in unauthenticated media. If > unauthenticated media is played to the end user, in cases such as early > media in SIP calls, this should be indicated to the end user. > >> > >> No. Doing the handshake as quickly as possible is recommend - it's what > you do with the media before you know who you are talking to that is the > issue you are concerned with. And knowing who you are talking often > involves much more than checking the fingerprint. So I don't agree this is > not recommended. > >> > >> There are also implementation issues with getting media and not playing > it. End point will still need to either buffer or somehow process the > received packets so that playback can be started when the answer is > received. If handshake is delayed until answer is received, none of this is > an issue, so implementation is simpler. > >> > >> More importantly, I do not think new systems should be built without > ICE. I understand there are legacy implementations which use symmetric UDP > for media. In such cases it is allowed to complete handshake. Such > solutions are legacy and building new systems like this are not > recommended. It is recommended that new systems should implement full ICE, > consent to send, and do not complete DTLS handshake before an answer SDP is > received. > >> > >> Regards, > >> _____________ > >> Roman Shpount > >> > > > > --f403045cc7d497f287055175a3f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We c= an expand the language regarding unverified DTLS association that end point= SHOULD inform the end user when unverified media is played and SHOULD not = send user generated media until stream is verified.

I also want to add that finge= rprints SHOULD be sent over integrity protected signaling channel. I think = this should address your concern about the Answer identity. I think specifi= cs of integrity protection of fingerprint delivery is outside of scope of t= his draft.

Would this address your comments?

=
Regards,
_____________
Roman Shpount

On Thu, Jun 8, 2017 at 9:= 25 AM, Cullen Jennings <fluffy@iii.ca> wrote:

I think the key things are:

For devices that want to minimize delay in setting up media and avoid media= clipping, doing the TLS handshake as soon as possible is good design but i= n some cases this means the system does=C2=A0 the handshake before the iden= tity of the fingerprint is known.

If this is done, there is a risk of sending or receiving media before the i= dentity of the remote side is known and the system needs to be designed to = deal with theses risks in a way that is appropriate for the system that use= s this.

Receiving media from an unknown sources typically has fairly low risk while= sending human generated media, such as the input from a microphone or came= ra, to a unknown users has much higher privacy risks.

If we agree on the above, I think we could get text that covers that. Note = that I think the key thing one needs to wait for is not just the fingerprin= t in the Answer but also knowing the identity of the Answer. In many cases = this is just the From in the answer as the signaling is trusted but in case= where it is not, the key thing is to=C2=A0 know the media is going to the = appropriate person and that might involve more that just having the fingerp= rint in the answer.



> On Jun 7, 2017, at 3:52 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
>
> Can we get some specific text proposals from the people that seem to c= are about what we end up with here ?
>
> Thanks
>
> -- Flemming (as MMUSIC co-chair)
>
>
> On 6/5/17 12:58 PM, Roman Shpount wrote:
>> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <fluffy@iii.ca> wrote:
>>
>> > On May 31, 2017, at 4:51 PM, Roman Shpount <roman@telurix.com> wrote:
>> >
>> > 1. Starting DTLS handshake until the corresponded answer is r= eceived is NOT RECOMMENDED since it can result in unauthenticated media. If= unauthenticated media is played to the end user, in cases such as early me= dia in SIP calls, this should be indicated to the end user.
>>
>> No. Doing the handshake as quickly as possible is recommend - it&#= 39;s what you do with the media before you know who you are talking to that= is the issue you are concerned with. And knowing who you are talking often= involves much more than checking the fingerprint. So I don't agree thi= s is not recommended.
>>
>> There are also implementation issues with getting media and not pl= aying it. End point will still need to either buffer or somehow process the= received packets so that playback can be started when the answer is receiv= ed. If handshake is delayed until answer is received, none of this is an is= sue, so implementation is simpler.
>>
>> More importantly, I do not think new systems should be built witho= ut ICE. I understand there are legacy implementations which use symmetric U= DP for media. In such cases it is allowed to complete handshake. Such solut= ions are legacy and building new systems like this are not recommended. It = is recommended that new systems should implement full ICE, consent to send,= and do not complete DTLS handshake before an answer SDP is received.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>


--f403045cc7d497f287055175a3f8-- From nobody Thu Jun 8 11:23:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6334412EB01; Thu, 8 Jun 2017 11:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HDoDSlkf6mP; Thu, 8 Jun 2017 11:23:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E011250B8; Thu, 8 Jun 2017 11:23:20 -0700 (PDT) X-AuditID: c1b4fb30-4a9ff70000003fda-98-5939961450bc Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.9A.16346.41699395; Thu, 8 Jun 2017 20:23:18 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Thu, 8 Jun 2017 20:23:20 +0200 From: Christer Holmberg To: Cullen Jennings , Flemming Andreasen CC: Roman Shpount , Ben Campbell , "Eric Rescorla" , Martin Thomson , "mmusic-chairs@ietf.org" , mmusic Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHS3gR6cOUoIT8u10KHxHCOXLs6qqIWXGKAgAN2xgCAAQSegIAAdFXA Date: Thu, 8 Jun 2017 18:23:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBE25D6@ESESSMB109.ericsson.se> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> In-Reply-To: <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> 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+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7qK7YNMtIg4YnGhbzO0+zW6x4fY7d 4v0FXYsP638wWlw784/R4vzO9UwWU5c/ZrGYcWEqswOHx5TfG1k9ds66y+6xZMlPJo/L5z8y esza+YTFY/LjNmaPW1MKAtijuGxSUnMyy1KL9O0SuDJe37nHXPBKoOL/y7WMDYzLeLsYOTkk BEwkZv9sYu5i5OIQEjjCKDFl4h0WCGcRo8SLnq+sXYwcHGwCFhLd/7RBGkQEfCRWPzgA1sAs 8JBRov/lc0aQhLBAlcSd1f9YIYqqJTYfv8gG0isi4CbR+sITJMwioCIx/2ozC4jNK+Ar0bRi JxvEroPMEpv+XwSbwylgJfHh/0p2EJtRQEzi+6k1TCA2s4C4xK0n85kgrhaQWLLnPDOELSrx 8jHEXgkBJYnGJU9YIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZ wMiyilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwJg9u+W2wg/Hlc8dDjAIcjEo8vB6ilpFC rIllxZW5hxglOJiVRHiPGgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKanZpa kFoEk2Xi4JRqYHTy/qLXvtNd5r1t0qXsCrU1b4UeZTuEZDCr6bO7Ptj6tzFxr1VrSzrb3C8f Nl5sXLbFN/zZXoZ59mwT5tVxflFlt8nJ2Dljb9uqBnHRQ6Jbev6UXvrBpPne6XhOwcGtq423 XtJbc9dnhn517A6ja4UnQ/4Ua5/5LOI5y6rQwjB759xVX0N5VyqxFGckGmoxFxUnAgCSuLDe xQIAAA== Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 18:23:22 -0000 Hi, ... >If we agree on the above, I think we could get text that covers that. We don't "get" text - someone has to produce it :) Regards, Christer > On Jun 7, 2017, at 3:52 PM, Flemming Andreasen wrote= : >=20 > Can we get some specific text proposals from the people that seem to care= about what we end up with here ?=20 >=20 > Thanks=20 >=20 > -- Flemming (as MMUSIC co-chair) >=20 >=20 > On 6/5/17 12:58 PM, Roman Shpount wrote: >> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings wrote: >>=20 >> > On May 31, 2017, at 4:51 PM, Roman Shpount wrote: >> > >> > 1. Starting DTLS handshake until the corresponded answer is received i= s NOT RECOMMENDED since it can result in unauthenticated media. If unauthen= ticated media is played to the end user, in cases such as early media in SI= P calls, this should be indicated to the end user. >>=20 >> No. Doing the handshake as quickly as possible is recommend - it's what = you do with the media before you know who you are talking to that is the is= sue you are concerned with. And knowing who you are talking often involves = much more than checking the fingerprint. So I don't agree this is not recom= mended. >>=20 >> There are also implementation issues with getting media and not playing = it. End point will still need to either buffer or somehow process the recei= ved packets so that playback can be started when the answer is received. If= handshake is delayed until answer is received, none of this is an issue, s= o implementation is simpler. >>=20 >> More importantly, I do not think new systems should be built without ICE= . I understand there are legacy implementations which use symmetric UDP for= media. In such cases it is allowed to complete handshake. Such solutions a= re legacy and building new systems like this are not recommended. It is rec= ommended that new systems should implement full ICE, consent to send, and d= o not complete DTLS handshake before an answer SDP is received. >>=20 >> Regards, >> _____________ >> Roman Shpount >> =20 >=20 From nobody Thu Jun 8 12:09:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D94128CF0 for ; Thu, 8 Jun 2017 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbXh8Ji2U1Kq for ; Thu, 8 Jun 2017 12:09:52 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D482126CF9 for ; Thu, 8 Jun 2017 12:09:52 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-12v.sys.comcast.net with SMTP id J2oRdDzUmdlFQJ2oZdpehL; Thu, 08 Jun 2017 19:09:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1496948991; bh=+bNadLDqAyqZM1F+B5CRTWSh0RkyxUVI5ouM27HyBr8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=IHHeZLGcHQ1YKyRD2zI25GFcCU5S8PKbs96HMqlYBJERwj+/AgA3x6+NzYF/9vP92 d4HFlVkwpn1zy+FWWf8LoR8i1VbQHGuSDL95fDNSjk1U5vwpJfqXFYUwI5OXa/TeKT 7rHKUSxyJUw6UGAZJBCiwga9dPoEXG9QQOJa+J3Q1P4h67oVpFkI8oOOevEYGN/urX jybO4WKDWznxQZYF36K31SXZCb5s45exYgNe1txJIARLUyoRGuH6WaUGtOHyMLzatA VrWoFXIsf/2N9m7mrxDXqVEGelXGinrRG0VK5QDLg9PYFPb10sT7kWtj6Ykjdo81mF YlrN3qh9LD4Zw== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-18v.sys.comcast.net with SMTP id J2oYd9OxcStKdJ2oZdxyhZ; Thu, 08 Jun 2017 19:09:51 +0000 To: mmusic@ietf.org References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> From: Paul Kyzivat Message-ID: <7a029c60-a5fb-bc38-1080-7ff9e08f48a8@comcast.net> Date: Thu, 8 Jun 2017 15:09:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMyHlFjL2/YBj/6DrYdbpV4xop9wW0zW7DLQgK+w+155DgpptCCABLnA353Al0rPXZm1OcvO6tjS6V/UthW+nyeFJ5v28erKyL52/CTl7MoVchzhr8tm oiEaeDTUgOUm2JicMujyllasEVpUSs19mXUyomHR3F+OoBFG/Fc9GLK3 Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 19:09:55 -0000 On 6/8/17 9:25 AM, Cullen Jennings wrote: > > I think the key things are: > > For devices that want to minimize delay in setting up media and avoid media clipping, doing the TLS handshake as soon as possible is good design but in some cases this means the system does the handshake before the identity of the fingerprint is known. > > If this is done, there is a risk of sending or receiving media before the identity of the remote side is known and the system needs to be designed to deal with theses risks in a way that is appropriate for the system that uses this. > > Receiving media from an unknown sources typically has fairly low risk while sending human generated media, such as the input from a microphone or camera, to a unknown users has much higher privacy risks. > > If we agree on the above, I think we could get text that covers that. Note that I think the key thing one needs to wait for is not just the fingerprint in the Answer but also knowing the identity of the Answer. In many cases this is just the From in the answer as the signaling is trusted but in case where it is not, the key thing is to know the media is going to the appropriate person and that might involve more that just having the fingerprint in the answer. The above discussion only pertains to DTLS used for *media*. Some additional consideration is needed regarding non-media usage. (Notably data channels.) Thanks, Paul >> On Jun 7, 2017, at 3:52 PM, Flemming Andreasen wrote: >> >> Can we get some specific text proposals from the people that seem to care about what we end up with here ? >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> On 6/5/17 12:58 PM, Roman Shpount wrote: >>> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings wrote: >>> >>>> On May 31, 2017, at 4:51 PM, Roman Shpount wrote: >>>> >>>> 1. Starting DTLS handshake until the corresponded answer is received is NOT RECOMMENDED since it can result in unauthenticated media. If unauthenticated media is played to the end user, in cases such as early media in SIP calls, this should be indicated to the end user. >>> >>> No. Doing the handshake as quickly as possible is recommend - it's what you do with the media before you know who you are talking to that is the issue you are concerned with. And knowing who you are talking often involves much more than checking the fingerprint. So I don't agree this is not recommended. >>> >>> There are also implementation issues with getting media and not playing it. End point will still need to either buffer or somehow process the received packets so that playback can be started when the answer is received. If handshake is delayed until answer is received, none of this is an issue, so implementation is simpler. >>> >>> More importantly, I do not think new systems should be built without ICE. I understand there are legacy implementations which use symmetric UDP for media. In such cases it is allowed to complete handshake. Such solutions are legacy and building new systems like this are not recommended. It is recommended that new systems should implement full ICE, consent to send, and do not complete DTLS handshake before an answer SDP is received. >>> >>> Regards, >>> _____________ >>> Roman Shpount >>> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Jun 8 13:28:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64BB126BF7 for ; Thu, 8 Jun 2017 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HVTVcHZlsR7 for ; Thu, 8 Jun 2017 13:28:19 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 6628D1293D9 for ; Thu, 8 Jun 2017 13:28:19 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id x63so20811580pff.3 for ; Thu, 08 Jun 2017 13:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8B/5yx5LdB4fJbubncymE14ONcgzFYw769MDCdk2qcc=; b=xCs6YPnkoMtuOrpApbNH5UhUMA9dL8Ap0oN44QZJh+M/qp/mT3mpt2oOmTFs+/TeXz tpINJUVZ6bvKMPPoAXHTK9WlMt4QHNiYHAOtHD0xmg47b602ZygED10cKgxAVx/p1tAr 5t1kO7QGoFw7Z6JJtNa2qtNATTeMlcmA5Cwbm4WbLYkS0r636F346CN50mWgbLO2DTOR D3fVjOY2DLAa5iU3Va5MfQkYdvbMSKFDWSGFj/4YJkGUuamacEGng6+GT9zT22eXiMe5 UaPgu4IOYK+UIfPOxo/NFjhcY0YjlPiw6DW38qaD+wIIH98zSfOhODiNFGR/jhN4TwG3 hkYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8B/5yx5LdB4fJbubncymE14ONcgzFYw769MDCdk2qcc=; b=E2YHwESN2oAmoiFk1S4DhpDpFDgv04MnJID0OhnKSRVrKG2KozSi+UHIq4Sr+gGTg4 u3LZ3SjJvx+HhIikVTou8QIYmHczxJO+od60Gxlp/hWKxFE5/S2tOpMNftsLdEN7LIhr 1BMffCYFKHo1EDnKLrVUnY6u2Q/5hrlfi+c9LLm2npC8FHhGec8aLrgF+SWPCNa2tsu2 eGwaLYMtwFE2eZRSYwSR+BDQd6Dc6vt0j0aV8b2rmRV10YKZqnWnFDIt5eNwlr/YoEhR CgrXBmruBO2a0C10ZXrmWA5uMPCkJRaR2fVvck4FnkCJykxbVVgymjG218C8gOw+lX7E lYPg== X-Gm-Message-State: AODbwcB6mzXh5F8PszksvVJv1LJAU9FpjtnbgA5zKrydnmxVtwscVyKv 5+cdDqeDRmlmzzZD4Ls= X-Received: by 10.99.64.1 with SMTP id n1mr39602530pga.197.1496953698809; Thu, 08 Jun 2017 13:28:18 -0700 (PDT) Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com. [209.85.192.172]) by smtp.gmail.com with ESMTPSA id k192sm11770602pgc.31.2017.06.08.13.28.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 13:28:18 -0700 (PDT) Received: by mail-pf0-f172.google.com with SMTP id l89so20856442pfi.2 for ; Thu, 08 Jun 2017 13:28:17 -0700 (PDT) X-Received: by 10.84.130.7 with SMTP id 7mr36259225plc.35.1496953697559; Thu, 08 Jun 2017 13:28:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Thu, 8 Jun 2017 13:28:16 -0700 (PDT) In-Reply-To: <7a029c60-a5fb-bc38-1080-7ff9e08f48a8@comcast.net> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> <7a029c60-a5fb-bc38-1080-7ff9e08f48a8@comcast.net> From: Roman Shpount Date: Thu, 8 Jun 2017 16:28:16 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c12f4bc637140055178b1ce" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 20:28:21 -0000 --94eb2c12f4bc637140055178b1ce Content-Type: text/plain; charset="UTF-8" On Thu, Jun 8, 2017 at 3:09 PM, Paul Kyzivat wrote: > On 6/8/17 9:25 AM, Cullen Jennings wrote: > >> >> The above discussion only pertains to DTLS used for *media*. Some > additional consideration is needed regarding non-media usage. (Notably data > channels.) > Do you have any suggestions regarding the non "media" usage, i.e. data? I think offering end point SHOULD not send any data before the answer is received, but I am not sure if this means actual data or negotiation messages (INIT-ACK) as well. Putting this another way, should answering end point proceed with SCTP handshake before the answer is received? If INIT-ACK is not sent, SCTP setup is delayed and no data is sent. This is similar to what I have proposed with DTLS where it did not work because of data requirements, but I got to ask if this is acceptable for data. Regards, _____________ Roman Shpount --94eb2c12f4bc637140055178b1ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 8, 2017 at 3:09 PM, Paul Kyzivat <paul.kyzivat@com= cast.net> wrote:
On 6= /8/17 9:25 AM, Cullen Jennings wrote:

 The above discussion only pertains to DTLS used for *media*. Some additiona= l consideration is needed regarding non-media usage. (Notably data channels= .)

Do you have any suggestions regardin= g the non "media" usage, i.e. data?

I th= ink offering end point SHOULD not send any data before the answer is receiv= ed, but I am not sure if this means actual data or negotiation messages (IN= IT-ACK) as well.=C2=A0 Putting this another way, should answering end point= proceed with SCTP handshake before the answer is received? If INIT-ACK is = not sent, SCTP setup is delayed and no data is sent. This is similar to wha= t I have proposed with DTLS where it did not work because of data requireme= nts, but I got to ask if this is acceptable for data.

<= div>Regards,
_____________
Roma= n Shpount
=C2=A0
--94eb2c12f4bc637140055178b1ce-- From nobody Thu Jun 8 17:03:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C8912E044 for ; Thu, 8 Jun 2017 17:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFHdXoSTp-9d for ; Thu, 8 Jun 2017 17:03:40 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 08EDE129B6D for ; Thu, 8 Jun 2017 17:03:40 -0700 (PDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 43D18253EC; Thu, 8 Jun 2017 20:03:29 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp25.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 39E66252D4; Thu, 8 Jun 2017 20:03:28 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 08 Jun 2017 20:03:29 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 8 Jun 2017 18:03:26 -0600 Cc: Flemming Andreasen , Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Transfer-Encoding: quoted-printable Message-Id: <46506F82-3944-471C-80E9-D622EB3E1211@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 00:03:42 -0000 > On Jun 8, 2017, at 10:49 AM, Roman Shpount wrote: >=20 > We can expand the language regarding unverified DTLS association that = end point SHOULD inform the end user when unverified media is played and = SHOULD not send user generated media until stream is verified. >=20 > I also want to add that fingerprints SHOULD be sent over integrity = protected signaling channel. I think this should address your concern = about the Answer identity. I think specifics of integrity protection of = fingerprint delivery is outside of scope of this draft. >=20 > Would this address your comments? No.=20 You keep trying to design the overall security of every system that uses = this draft in this draft and that won't work. You need to let the system = that use this draft define out the security for that system works. All = we need here is to define how to set up a DTLS session using TLS. How = any systems decides to use identity founds in TLS is complicated and = differs for different usages. That's the same here - how the fingerprint = are bound to identities changes for different usages of this. For = example, the important part is to know who the media is coming from or = going to. In some cases, integrity protection channels from trusted = sources might provide that the SIP =46rom header and fingerprint were = matched together and helped solve that. But in some case, for example = the work on passport at IETF, it is not the integrity protected channel = that that mattered, it was a signature on a the passport object that = tied the fingerprint to the identity that is important. What would help is if the first thing is do we agree on the points I = sent out and if not, lets figure out why, and if yes, then we can work = on text.=20 I agree with Paul's comment that we need to deal with data too and my = points did not. However, on data I will also argue that is not the place = of this draft to define the totally security for all the systems that = might use this.=20 >=20 > Regards, > _____________ > Roman Shpount >=20 > On Thu, Jun 8, 2017 at 9:25 AM, Cullen Jennings wrote: >=20 > I think the key things are: >=20 > For devices that want to minimize delay in setting up media and avoid = media clipping, doing the TLS handshake as soon as possible is good = design but in some cases this means the system does the handshake = before the identity of the fingerprint is known. >=20 > If this is done, there is a risk of sending or receiving media before = the identity of the remote side is known and the system needs to be = designed to deal with theses risks in a way that is appropriate for the = system that uses this. >=20 > Receiving media from an unknown sources typically has fairly low risk = while sending human generated media, such as the input from a microphone = or camera, to a unknown users has much higher privacy risks. >=20 > If we agree on the above, I think we could get text that covers that. = Note that I think the key thing one needs to wait for is not just the = fingerprint in the Answer but also knowing the identity of the Answer. = In many cases this is just the =46rom in the answer as the signaling is = trusted but in case where it is not, the key thing is to know the media = is going to the appropriate person and that might involve more that just = having the fingerprint in the answer. >=20 >=20 >=20 > > On Jun 7, 2017, at 3:52 PM, Flemming Andreasen = wrote: > > > > Can we get some specific text proposals from the people that seem to = care about what we end up with here ? > > > > Thanks > > > > -- Flemming (as MMUSIC co-chair) > > > > > > On 6/5/17 12:58 PM, Roman Shpount wrote: > >> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings = wrote: > >> > >> > On May 31, 2017, at 4:51 PM, Roman Shpount = wrote: > >> > > >> > 1. Starting DTLS handshake until the corresponded answer is = received is NOT RECOMMENDED since it can result in unauthenticated = media. If unauthenticated media is played to the end user, in cases such = as early media in SIP calls, this should be indicated to the end user. > >> > >> No. Doing the handshake as quickly as possible is recommend - it's = what you do with the media before you know who you are talking to that = is the issue you are concerned with. And knowing who you are talking = often involves much more than checking the fingerprint. So I don't agree = this is not recommended. > >> > >> There are also implementation issues with getting media and not = playing it. End point will still need to either buffer or somehow = process the received packets so that playback can be started when the = answer is received. If handshake is delayed until answer is received, = none of this is an issue, so implementation is simpler. > >> > >> More importantly, I do not think new systems should be built = without ICE. I understand there are legacy implementations which use = symmetric UDP for media. In such cases it is allowed to complete = handshake. Such solutions are legacy and building new systems like this = are not recommended. It is recommended that new systems should implement = full ICE, consent to send, and do not complete DTLS handshake before an = answer SDP is received. > >> > >> Regards, > >> _____________ > >> Roman Shpount > >> > > >=20 >=20 From nobody Thu Jun 8 17:12:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474BC129B77 for ; Thu, 8 Jun 2017 17:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3nlOaRc3oWM for ; Thu, 8 Jun 2017 17:12:30 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 CC0CE129B70 for ; Thu, 8 Jun 2017 17:12:30 -0700 (PDT) Received: from smtp33.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp33.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 119E95717; Thu, 8 Jun 2017 20:12:30 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp33.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8D48856C7; Thu, 8 Jun 2017 20:12:29 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 08 Jun 2017 20:12:30 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 8 Jun 2017 18:12:28 -0600 Cc: Roman Shpount , mmusic WG Content-Transfer-Encoding: quoted-printable Message-Id: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 00:12:32 -0000 > On Jun 5, 2017, at 6:30 AM, Eric Rescorla wrote: >=20 > For this reason, I am not in favor of removing the MUST for the = initial > offer. I would be fine with MUST for initial +1 above=20 > and SHOULD for subsequent. SHOULD seems sort of not great here in that some people will assume = everything else will do actpass because it is SHOULD and no reason not = to and other will assume that they don't have to implement actpass = because is is actually SHOULD with a hind "but we know you won't" - = that combination will not help interop I think I would prefer in subsequent offers to say=20 MUST be actpass or the values that would not cause the roles to change.=20= I'm open to it saying other things but I think this is a case where = using SHOULD is not helpful=20 From nobody Thu Jun 8 17:36:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CDE12EAB2 for ; Thu, 8 Jun 2017 17:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUowxwgRhpHl for ; Thu, 8 Jun 2017 17:36:53 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 4CFBA129C12 for ; Thu, 8 Jun 2017 17:36:53 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m62so131235612itc.0 for ; Thu, 08 Jun 2017 17:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8UTu6A92y6tMnw3cLYn8HhT+gRKU6VMsjnuyjdOyU0E=; b=S+/qTuzAIXplrgdyv+SBzlLwgLmzzlLDpsmzDW8roFSAmPxSCeas8blfTQr408AXq2 kuEpeSrw26QpMH9X7t48zq1wfNRCUFRPiEVIPwdvBji0RUMvEjY6okZXu+OpMwaQUiGQ +qttBHHe9qh1O6OCEyqpq8zJct4sIqrQfxveJEEL590NMlKkUmRWnJt0nGkk4GeKKIgZ ux+vL08Eu5LUOGdB4nuV3i1YUJH4kVkM8fpTtcUK0ibBiHboZpX8bFTZYDLcWpizbjCv Wh8+2+Tyo27Qg01E5pMa9JjrTu1zHLK2RMVElRRWsnRT93NvTc9CPnkXn7/i5UXJ8PSI 1rFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8UTu6A92y6tMnw3cLYn8HhT+gRKU6VMsjnuyjdOyU0E=; b=Ga16B0DnOCZ1meF2SiU9sLjZf13k8eO7QrlRZJo31LEU+aVin4ZolrZhlxCZhwGTW5 /Oirr4wcnGH1R/2nhNWEIVkojOAaogpniOltRprEPN4uNgY0HTHH71yQu1cM6GD1iz78 zNejk+AqIusbjmbmRi017pLOel71oLzAHJHOM4kkmgqGGv6Y2vFXP5mYMdyHw3DYRWsc kSSmoIH1YWcOInOz+TPa9Tdw/44xqCpDE2gK2tVH9+2tiuaD8Wcpt+036+LOmrIM7SZU RTHIpgMpF2DJ0trzGfbOStAKcB/pHrw1JsODzNffgFDtBehtmm0BE8FF0nPoenGpf8n0 0eqA== X-Gm-Message-State: AODbwcAN/SVeyk3agGgj/XiGZuLL9/BoTrcMSzLUDRqCB6LXjqgg/5uq oUU5gZ2BYnkPWBBZ6YE= X-Received: by 10.36.40.17 with SMTP id h17mr8569527ith.39.1496968612597; Thu, 08 Jun 2017 17:36:52 -0700 (PDT) Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com. [209.85.192.169]) by smtp.gmail.com with ESMTPSA id 197sm162799ity.5.2017.06.08.17.36.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 17:36:51 -0700 (PDT) Received: by mail-pf0-f169.google.com with SMTP id x63so22477569pff.3; Thu, 08 Jun 2017 17:36:50 -0700 (PDT) X-Received: by 10.84.132.98 with SMTP id 89mr36963240ple.29.1496968610381; Thu, 08 Jun 2017 17:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Thu, 8 Jun 2017 17:36:49 -0700 (PDT) In-Reply-To: <46506F82-3944-471C-80E9-D622EB3E1211@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> <46506F82-3944-471C-80E9-D622EB3E1211@iii.ca> From: Roman Shpount Date: Thu, 8 Jun 2017 20:36:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Flemming Andreasen , Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Type: multipart/alternative; boundary="94eb2c12572a430b8a05517c2ac4" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 00:36:55 -0000 --94eb2c12572a430b8a05517c2ac4 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 8, 2017 at 8:03 PM, Cullen Jennings wrote: > > > On Jun 8, 2017, at 10:49 AM, Roman Shpount wrote: > > > > We can expand the language regarding unverified DTLS association that > end point SHOULD inform the end user when unverified media is played and > SHOULD not send user generated media until stream is verified. > > > > I also want to add that fingerprints SHOULD be sent over integrity > protected signaling channel. I think this should address your concern about > the Answer identity. I think specifics of integrity protection of > fingerprint delivery is outside of scope of this draft. > > > > Would this address your comments? > > No. > > You keep trying to design the overall security of every system that uses > this draft in this draft and that won't work. You need to let the system > that use this draft define out the security for that system works. All we > need here is to define how to set up a DTLS session using TLS. How any > systems decides to use identity founds in TLS is complicated and differs > for different usages. That's the same here - how the fingerprint are bound > to identities changes for different usages of this. For example, the > important part is to know who the media is coming from or going to. In some > cases, integrity protection channels from trusted sources might provide > that the SIP From header and fingerprint were matched together and helped > solve that. But in some case, for example the work on passport at IETF, it > is not the integrity protected channel that that mattered, it was a > signature on a the passport object that tied the fingerprint to the > identity that is important. > > What would help is if the first thing is do we agree on the points I sent > out and if not, lets figure out why, and if yes, then we can work on text. > You have mentioned that we removed the requirement that session description should be sent over integrity protected channel. This requirement was present in https://tools.ietf.org/html/rfc5763#section-5 and got removed in this draft. I assumed you wanted to bring this back. I understand that until answer identity and integrity is verified and until fingerprint is matched, received media is coming from an unverified source and ultimately not secure. Validation of session description identity and integrity is something that is outside of scope of this document. Stating that this document only provides a partial solution and that it SHOULD be used with a signaling channel that provides identity and integrity validation in order to guarantee that data delivered over DTLS association is secure is very much in scope. It should also be in scope to state that media can be received before DTLS association is verified and that it is up to the application if this media should be played and how to appropriately inform the user. I am trying to understand what exactly you are trying to change in my proposal. I am trying to propose something that addresses your points but apparently I am getting wrong. So, can you propose the text? Regarding handling of data, we just finished datachannel related drafts. None of them define how data sent over SCTP association is supposed to be handled before DTLS association is verified. If this information is not present in any of those drafts, should it simply be left undefined? Keep in mind that people (like W3C in regard of webrtc) are asking how unverified media and data should be handled. If anything, some guideline should be provided in security considerations section of this draft. Regards, _____________ Roman Shpount --94eb2c12572a430b8a05517c2ac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 8, 2017 at 8:03 PM, Cullen Jennings <= fluffy@iii.ca> wrote:

> On Jun 8, 2017, at 10:49 AM, Roman Shpount <roman@telurix.com> wrote:
>
> We can expand the language regarding unverified DTLS association that = end point SHOULD inform the end user when unverified media is played and SH= OULD not send user generated media until stream is verified.
>
> I also want to add that fingerprints SHOULD be sent over integrity pro= tected signaling channel. I think this should address your concern about th= e Answer identity. I think specifics of integrity protection of fingerprint= delivery is outside of scope of this draft.
>
> Would this address your comments?

No.

You keep trying to design the overall security of every system that uses th= is draft in this draft and that won't work. You need to let the system = that use this draft define out the security for that system works. All we n= eed here is to define how to set up a DTLS session using TLS. How any syste= ms decides to use identity founds in TLS is complicated and differs for dif= ferent usages. That's the same here - how the fingerprint are bound to = identities changes for different usages of this.=C2=A0 For example, the imp= ortant part is to know who the media is coming from or going to. In some ca= ses, integrity protection channels from trusted sources might provide that = the SIP From=C2=A0 header and fingerprint were matched together and helped = solve that. But in some case, for example the work on passport at IETF, it = is not the integrity protected channel that that mattered, it was a signatu= re on a the passport object that tied the fingerprint to the identity that = is important.

What would help is if the first thing is do we agree on the points I sent o= ut and if not, lets figure out why, and if yes, then we can work on text.

You have mentioned that we removed the r= equirement that session description should be sent over integrity protected= channel. This requirement was present in https://tools.ietf.org/html/rfc5763#section-5 = and got removed in this draft. I assumed you wanted to bring this back.

I understand that until answer identity and integrity= is verified and until fingerprint is matched, received media is coming fro= m an unverified source and ultimately not secure. Validation of session des= cription identity and integrity is something that is outside of scope of th= is document. Stating that this document only provides a partial solution an= d that it SHOULD be used with a signaling channel that provides identity an= d integrity validation in order to guarantee that data delivered over =C2= =A0DTLS association is secure is very much in scope. It should also be in s= cope to state that media can be received before DTLS association is verifie= d and that it is up to the application if this media should be played and h= ow to appropriately inform the user.

I am trying t= o understand what exactly you are trying to change in my proposal. I am try= ing to propose something that addresses your points but apparently I am get= ting wrong. So, can you propose the text?=C2=A0

Re= garding handling of data, we just finished datachannel related drafts. None= of them define how data sent over SCTP association is supposed to be handl= ed before DTLS association is verified. If this information is not present = in any of those drafts, should it simply be left undefined?

<= /div>
Keep in mind that people (like W3C in regard of webrtc) are askin= g how unverified media and data should be handled. If anything, some guidel= ine should be provided in security considerations section of this draft.

Regards,
__= ___________
Roman Shpount
=C2=A0
--94eb2c12572a430b8a05517c2ac4-- From nobody Thu Jun 8 17:49:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0EE12869B for ; Thu, 8 Jun 2017 17:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBKb48f3q5l5 for ; Thu, 8 Jun 2017 17:49:07 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FAD12751F for ; Thu, 8 Jun 2017 17:49:07 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id x63so22556360pff.3 for ; Thu, 08 Jun 2017 17:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kKSYwSANQURdOTu9C5Z+4FSBiSrOnzBJDdmZ9yI2LaU=; b=OG+aRp8ZhnKLaEHeatOqJrsgwE68UNid2FJCbSw+wK2CLl2T1B2kzxSPEgBSEgWmte OItUS2MHwfdy5VxrRNd61xD4WKtKh4RUkytasMVvGNZA3XvFk5eQOWyGd0xne9kWxfGI kIpSwDn6GMccQX7ieH2qqJVowzj5MRV+tJ3gxVh0IMhTLwmfQdmc9A3rrucUj9WpAGDU /ix4pPWDlet9byB2sEnwQ/26PfVPgsA/Jqixr+7LCZHbun9L+GOKUoIvQK9oQ4MA7KBL Q3pJo7afSnIddE8f/U9woKA3ESv7vbYXOnf7NlrTKHTpRpTunLStT+RJF/N1i88wt1ZH qr0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kKSYwSANQURdOTu9C5Z+4FSBiSrOnzBJDdmZ9yI2LaU=; b=sOwoAi3HGcOc+/MMgN/nFJLusBYMuxI9u3THuf8bcnatyWGMTS+3UEYsAJIblm4862 UV3+J6buSZFVsFdd40Vb1VKao2EbpWPXvY7uY0QPOPH41sA5jqGstI4sPAmsFmFqgCP0 xhoeCcSWgQc0hoStVwHTA+oPiIafNEIizaaLM+wavrgGceQrjWfCu5VjDs5k0mSwJsva vUJOJYcUKzHfTzQ8/Fgw+OrDW1d8tqhI2SqXNH25gdWkzcVHY4Whxod5OLyjuoWM3qeA WllHfP39htX3eBB3RdgNg2Rns0f5ywRgJsh2LbAwOHc6rfnzi6JIcRUzMO2vgJrJo0Qv Bm9A== X-Gm-Message-State: AODbwcDTBOshDKqxEPMvTwT7uSqD4SvvauPe4Qli8uIgFLhKWF/BBygO 9kZoRjHJuH9aqXA8b2s= X-Received: by 10.84.131.2 with SMTP id 2mr23009587pld.61.1496969346424; Thu, 08 Jun 2017 17:49:06 -0700 (PDT) Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com. [74.125.83.50]) by smtp.gmail.com with ESMTPSA id v9sm11620144pgb.25.2017.06.08.17.49.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 17:49:05 -0700 (PDT) Received: by mail-pg0-f50.google.com with SMTP id k71so21110763pgd.2 for ; Thu, 08 Jun 2017 17:49:05 -0700 (PDT) X-Received: by 10.98.112.135 with SMTP id l129mr40398289pfc.27.1496969345288; Thu, 08 Jun 2017 17:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.66 with HTTP; Thu, 8 Jun 2017 17:49:03 -0700 (PDT) In-Reply-To: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> From: Roman Shpount Date: Thu, 8 Jun 2017 20:49:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Eric Rescorla , mmusic WG Content-Type: multipart/alternative; boundary="001a113bfb5010d42805517c56a0" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 00:49:09 -0000 --001a113bfb5010d42805517c56a0 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 8, 2017 at 8:12 PM, Cullen Jennings wrote: > > > On Jun 5, 2017, at 6:30 AM, Eric Rescorla wrote: > > > > For this reason, I am not in favor of removing the MUST for the initial > > offer. I would be fine with MUST for initial > +1 above > > > and SHOULD for subsequent. > > SHOULD seems sort of not great here in that some people will assume > everything else will do actpass because it is SHOULD and no reason not to > and other will assume that they don't have to implement actpass because is > is actually SHOULD with a hind "but we know you won't" - that combination > will not help interop > > I think I would prefer in subsequent offers to say > > MUST be actpass or the values that would not cause the roles to change. > > I think what EKR is trying to say here SHOULD be actpass and MUST be actpass or the value that would not cause the setup role change. Also note that 3pcc might cause an offer to be treated as subsequent offer by offerer and new offer by the answerer. If non-actpass setup roles are allowed in subsequent offers, they will have to be handled in initial offers as well. In that sense setup roles rules should be the same for both initial and subsequent offers. Since there are already implementations that do current role in subsequent offers, the cat is out of the bag. Because of this, I think for the best interop, offerer MUST specify actpass for both initial and subsequent offers but answerer MUST be able to handle active and passive setup roles as well. Regards, _____________ Roman Shpount --001a113bfb5010d42805517c56a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 8, 2017 at 8:12 PM, Cullen Jennings <= fluffy@iii.ca> wrote:

> On Jun 5, 2017, at 6:30 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> For this reason, I am not in favor of removing the MUST for the initia= l
> offer. I would be fine with MUST for initial
+1 above

> and SHOULD for subsequent.

SHOULD seems sort of not great here in that some people will assume everyth= ing else will do actpass because it is SHOULD and no reason not to and othe= r will assume that they don't have to implement actpass because is is a= ctually SHOULD with a hind "but we know you won't"=C2=A0 - th= at combination will not help interop

I think I would prefer in subsequent offers to say

MUST be actpass or the values that would not cause the roles to change.


I think what EKR is trying to say here= SHOULD be actpass and MUST be actpass or the value that would not cause th= e setup role change.

Also note that 3pcc might cau= se an offer to be treated as subsequent offer by offerer and new offer by t= he answerer. If non-actpass setup roles are allowed in subsequent offers, t= hey will have to be handled in initial offers as well. In that sense setup = roles rules should be the same for both initial and subsequent offers. Sinc= e there are already implementations that do current role in subsequent offe= rs, the cat is out of the bag. Because of this, I think for the best intero= p, offerer MUST specify actpass for both initial and subsequent offers but = answerer MUST be able to handle active and passive setup roles as well.

Regards,
___= __________
Roman Shpount
=C2=A0
--001a113bfb5010d42805517c56a0-- From nobody Fri Jun 9 06:17:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1111120046 for ; Fri, 9 Jun 2017 06:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFIpDk384kxa for ; Fri, 9 Jun 2017 06:17:35 -0700 (PDT) Received: from smtp114.iad3a.emailsrvr.com (smtp114.iad3a.emailsrvr.com [173.203.187.114]) (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 8DB041201F2 for ; Fri, 9 Jun 2017 06:17:35 -0700 (PDT) Received: from smtp39.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B7BE856F7; Fri, 9 Jun 2017 09:17:29 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp39.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4152E5939; Fri, 9 Jun 2017 09:17:29 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 09 Jun 2017 09:17:29 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 9 Jun 2017 07:17:28 -0600 Cc: Eric Rescorla , mmusic WG Content-Transfer-Encoding: quoted-printable Message-Id: <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 13:17:37 -0000 > On Jun 8, 2017, at 6:49 PM, Roman Shpount wrote: >=20 > Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able = to handle active and passive setup roles as well. that works for me=20 From nobody Fri Jun 9 06:33:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB011201F2 for ; Fri, 9 Jun 2017 06:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChEGfepM14yE for ; Fri, 9 Jun 2017 06:33:00 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 06FB41241FC for ; Fri, 9 Jun 2017 06:32:59 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 30FBD5812; Fri, 9 Jun 2017 09:32:57 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8512357AB; Fri, 9 Jun 2017 09:32:56 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 09 Jun 2017 09:32:57 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 9 Jun 2017 07:32:55 -0600 Cc: mmusic , Christer Holmberg Content-Transfer-Encoding: quoted-printable Message-Id: <727A5880-BAF5-44FC-8112-6FF5206AEEBC@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> <46506F82-3944-471C-80E9-D622EB3E1211@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 13:33:02 -0000 I'd really really appreciate if you could give me a hint of it you agree = with my original points I asked about or which ones you disagree with = and why. The three points I am interested in are: For devices that want to minimize delay in setting up media and avoid = media clipping, doing the TLS handshake as soon as possible is good = design but in some cases this means the system does the handshake = before the identity of the fingerprint is known.=20 If this is done, there is a risk of sending or receiving media before = the identity of the remote side is known and the system needs to be = designed to deal with theses risks in a way that is appropriate for the = system that uses this. =20 Receiving media from an unknown sources typically has fairly low risk = while sending human generated media, such as the input from a microphone = or camera, to a unknown users has much higher privacy risks.=20 If we agree on a high level that is reasonable advice to be in this = draft, then it's easier to get to the details. I feel like we are in = some weird loop where I keep trying to explain why I don't find the text = acceptable and then you propose a change which does not have much to do = with what I am concerned about. I suspect you have a strong idea of what = you mean by "not secure" and I have no idea what you think being = "secure" is in the various contexts of WebRTC, SIP, SIP to PSTN, and = other places.=20 > On Jun 8, 2017, at 6:36 PM, Roman Shpount wrote: >=20 > On Thu, Jun 8, 2017 at 8:03 PM, Cullen Jennings wrote: >=20 > > On Jun 8, 2017, at 10:49 AM, Roman Shpount = wrote: > > > > We can expand the language regarding unverified DTLS association = that end point SHOULD inform the end user when unverified media is = played and SHOULD not send user generated media until stream is = verified. > > > > I also want to add that fingerprints SHOULD be sent over integrity = protected signaling channel. I think this should address your concern = about the Answer identity. I think specifics of integrity protection of = fingerprint delivery is outside of scope of this draft. > > > > Would this address your comments? >=20 > No. >=20 > You keep trying to design the overall security of every system that = uses this draft in this draft and that won't work. You need to let the = system that use this draft define out the security for that system = works. All we need here is to define how to set up a DTLS session using = TLS. How any systems decides to use identity founds in TLS is = complicated and differs for different usages. That's the same here - how = the fingerprint are bound to identities changes for different usages of = this. For example, the important part is to know who the media is = coming from or going to. In some cases, integrity protection channels = from trusted sources might provide that the SIP =46rom header and = fingerprint were matched together and helped solve that. But in some = case, for example the work on passport at IETF, it is not the integrity = protected channel that that mattered, it was a signature on a the = passport object that tied the fingerprint to the identity that is = important. >=20 > What would help is if the first thing is do we agree on the points I = sent out and if not, lets figure out why, and if yes, then we can work = on text. >=20 > You have mentioned that we removed the requirement that session = description should be sent over integrity protected channel. This = requirement was present in https://tools.ietf.org/html/rfc5763#section-5 = and got removed in this draft. I assumed you wanted to bring this back. >=20 > I understand that until answer identity and integrity is verified and = until fingerprint is matched, received media is coming from an = unverified source and ultimately not secure. Validation of session = description identity and integrity is something that is outside of scope = of this document. Stating that this document only provides a partial = solution and that it SHOULD be used with a signaling channel that = provides identity and integrity validation in order to guarantee that = data delivered over DTLS association is secure is very much in scope. = It should also be in scope to state that media can be received before = DTLS association is verified and that it is up to the application if = this media should be played and how to appropriately inform the user. >=20 > I am trying to understand what exactly you are trying to change in my = proposal. I am trying to propose something that addresses your points = but apparently I am getting wrong. So, can you propose the text?=20 >=20 > Regarding handling of data, we just finished datachannel related = drafts. None of them define how data sent over SCTP association is = supposed to be handled before DTLS association is verified. If this = information is not present in any of those drafts, should it simply be = left undefined? >=20 > Keep in mind that people (like W3C in regard of webrtc) are asking how = unverified media and data should be handled. If anything, some guideline = should be provided in security considerations section of this draft. >=20 > Regards, > _____________ > Roman Shpount > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Jun 9 07:18:55 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9752129483 for ; Fri, 9 Jun 2017 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7DLmdY5WEWR for ; Fri, 9 Jun 2017 07:18:52 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 40B0412945F for ; Fri, 9 Jun 2017 07:18:52 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id f185so27116627pgc.0 for ; Fri, 09 Jun 2017 07:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7hUthKzVEDKbt+gGN63b058O6byCk14wK33TIXw50yE=; b=bTeGmw5QmJqAYhfQuLlt/Kg08ptB/pliI09X8/wxaECrETNwQAEGN5dEV/nWPmlM3D ebzEvWQx0KrSMGziyjfXrgLp3Tkjqtb8667rtYzWh0Yco1KFMEiLumjh+yszIgmswBJF sdOcf9N6s7Lq/wo++jCqVkGGEypsQV3eez2nQxEb+XbKykxLYLqXucr5i4n/Y1RkKYuU G4pEi7TIzPdHxyzQwJP0t/u3BbVrEGDnRI8PvXVgcb3T7jlgXsv1scIeA0Z8jQrWSne5 iVfk3DpmZezi7OctSqIghcA1o+rns2HPVQx/2e0jvOY9KI7YGVDY0PC0T0ZpTXGvktgh oBEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7hUthKzVEDKbt+gGN63b058O6byCk14wK33TIXw50yE=; b=s/bgzFUqfHG9PxyDb4vplTQ5Gu6alv7XMzf2w5dScqZ/gFu/kTmZIVTR5t3La0Sc7U 04df7N/p/gfr5TyyqvvZrGllIcM7RPJS2RZx4WIvBZDrzwtPSl/NqiutF5S85oj155UJ FSnW5i18pYuaJU3joCiG0EH9PfFec9Hedjl14B4eCVj5cLuyRtSUdnt+YAyDy3WSoOrX P1X/3FJSAM3q+dV+5qSA3i+kzaDHyfk8zljE264b3p3Bzvg+JCAZwaho6JYApQouSD1T 8qSkDh58pHI6Ba244s2FqSXF9mNgng3Orlifk/be0OWZFB04Au9gjsTprITGLdFWZgv/ wsHg== X-Gm-Message-State: AODbwcD1/oef2k5NMToJIaa/v+hLzmgRP/tIAkSvADxgtxGR2DXkZs7s 7YLywnIxR5U4x8ZR55M= X-Received: by 10.84.130.98 with SMTP id 89mr28117894plc.222.1497017931617; Fri, 09 Jun 2017 07:18:51 -0700 (PDT) Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com. [209.85.192.178]) by smtp.gmail.com with ESMTPSA id r73sm3713017pfk.114.2017.06.09.07.18.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 07:18:51 -0700 (PDT) Received: by mail-pf0-f178.google.com with SMTP id x63so29007674pff.3 for ; Fri, 09 Jun 2017 07:18:50 -0700 (PDT) X-Received: by 10.98.223.131 with SMTP id d3mr22581051pfl.112.1497017930396; Fri, 09 Jun 2017 07:18:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Fri, 9 Jun 2017 07:18:49 -0700 (PDT) In-Reply-To: <727A5880-BAF5-44FC-8112-6FF5206AEEBC@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> <46506F82-3944-471C-80E9-D622EB3E1211@iii.ca> <727A5880-BAF5-44FC-8112-6FF5206AEEBC@iii.ca> From: Roman Shpount Date: Fri, 9 Jun 2017 10:18:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: mmusic , Christer Holmberg Content-Type: multipart/alternative; boundary="f403045cc7d4f6bfec055187a501" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 14:18:54 -0000 --f403045cc7d4f6bfec055187a501 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jennings wrote: > I'd really really appreciate if you could give me a hint of it you agree > with my original points I asked about or which ones you disagree with and > why. The three points I am interested in are: > > For devices that want to minimize delay in setting up media and avoid > media clipping, doing the TLS handshake as soon as possible is good design > but in some cases this means the system does the handshake before the > identity of the fingerprint is known. > Doing TLS handshake as soon as possible is a good design. Doing answer identity and integrity validation and validating certificate fingerprints as soon as possible is a better design. I understand that doing answer and fingerprint validation is not always possible when interfacing with legacy SIP devices, but there is no reason to design new solutions which process media before the answer. For instance WebRTC has no reason to support unverified media. Because of this, I think that anything that produces unverified media is a bad design which has no reason to exist apart for legacy interop. Specifics on how to design session description identity and integrity validation are clearly out of scope for this draft. All of this being said, what I am proposing for the sake of moving this draft forward does not contradict any of your points. Once again, what I am proposing is: 1. Remove any recommendation regarding handling DTLS association before the answer (leave it up to implementation) 2. Put a note that accepting DTLS association before the answer can result in unverified media and if this media is played back to the end user, end user SHOULD be notified that media is coming from an unverified source. 3. Add clarification that DTLS associations established before the answer MUST be torn down when no more answers are expected and that fingerprints in any of the received answers match the negotiated certificate (Right now it is specified that DTLS association MUST be torn down if it does not match the answer. This is wrong if forking is used and multiple answers are received). Draft does not advise that DTLS association should be established before the answer is received (I think this is wrong), but it also does not advise that it should not (you think it is wrong). This way implementation decides what's best for it. Does it contradict anything that you want to accomplish? If it does, what needs to be changed? Regards, _____________ Roman Shpount --f403045cc7d4f6bfec055187a501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jenn= ings <fluffy@iii.ca> wrote:
I'd really real= ly appreciate if you could give me a hint of it you agree with my original = points I asked about or which ones you disagree with and why. The three poi= nts I am interested in are:

For devices that want to minimize delay in setting up media and avoid media= clipping, doing the TLS handshake as soon as possible is good design but i= n some cases this means the system does=C2=A0 the handshake before the iden= tity of the fingerprint is known.

Doing TLS handshake as soon as possible is a good design. Doing answer id= entity and integrity validation and validating certificate fingerprints as = soon as possible is a better design. I understand that doing answer and fin= gerprint validation is not always possible when interfacing with legacy SIP= devices, but there is no reason to design new solutions which process medi= a before the answer. For instance WebRTC has no reason to support unverifie= d media. Because of this, I think that anything that produces unverified me= dia is a bad design which has no reason to exist apart for legacy interop. = Specifics on how to design session description identity and integrity valid= ation are clearly out of scope for this draft.

All= of this being said, what I am proposing for the sake of moving this draft = forward does not contradict any of your points. Once again, what I am propo= sing is:

1. Remove any recommendation rega= rding handling DTLS association before the answer (leave it up to implement= ation)
2. Pu= t a note that accepting DTLS association before the answer can result in un= verified media and if this media is played back to the end user, end user S= HOULD be notified that media is coming from an unverified source.
3. Add clarification that DTLS associations established be= fore the answer MUST be torn down when no more answers are expected and tha= t fingerprints in any of the received answers match the negotiated certific= ate (Right now it is specified that DTLS association MUST be torn down if i= t does not match the answer. This is wrong if forking is used and multiple = answers are received).

Draft does not advis= e that DTLS association should be established before the answer is received= (I think this is wrong), but it also does not advise that it should not (y= ou think it is wrong). This way implementation decides what's best for = it.

Does it contradict anything that you want to a= ccomplish?
If it does, what needs to be changed?

Regards,
_____________
Roman Shpount
=C2=A0
--f403045cc7d4f6bfec055187a501-- From nobody Fri Jun 9 11:00:55 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50120126C89 for ; Fri, 9 Jun 2017 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Qb-MfFanP7 for ; Fri, 9 Jun 2017 11:00:52 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82EE1267BB for ; Fri, 9 Jun 2017 11:00:51 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-03v.sys.comcast.net with SMTP id JOCZd7a20fuM3JODLdJAA9; Fri, 09 Jun 2017 18:00:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1497031251; bh=XwCcGzIs4wp40uFbNhxA9Zs6HIXtIU+bMWnb8n8yjNw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=CBt8JIyGrKuOBWTeQEFC3qacKzVzWiRFNv11NaHSFu/QT5umCNgGPB6cbJzBglEhw MJOqJCCgUMmXRhWs/LOFTeekQxtTsb6u09eUjLSEoUgIemql6dNc49GX4bNc3G3Eoq nLy+6SHWVKjDWwQNNWcy/z7BGae1z9LwoR1sXbyrWmYw7+kFLdcRtdOclboX8e0sl7 md434/wITnvPzl/l77M40Hfzn72crhGzo7+t4dr8IhuzxLg5teYNgxu6YfdOZcZk04 GbXna14dnFFZ4ycmTVFWn3UCZCRNOPIpP96C+EEwintnwAlKjDpkCXRRfcrf0Xv834 Ap/jEnwfix4og== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-12v.sys.comcast.net with SMTP id JODKd4NxDqoNEJODKdJiaz; Fri, 09 Jun 2017 18:00:51 +0000 To: mmusic@ietf.org References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> From: Paul Kyzivat Message-ID: Date: Fri, 9 Jun 2017 14:00:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMS21W3XEV0qJ4Rf8qfKPMLstBuORY5sYGWcXOSdkgmouefrna3qvouSegQ58aV2eG5A/w2LExvzIy6qb2xaQgC/ZBizupfFJxs/OAdHWKWf/yStluni bGpeBECLmPz64SY/G5Czaxp8Eo1e3eTVxZyf3khfvd42DxkvELcxEE2z Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 18:00:53 -0000 On 6/9/17 9:17 AM, Cullen Jennings wrote: > >> On Jun 8, 2017, at 6:49 PM, Roman Shpount wrote: >> >> Because of this, I think for the best interop, offerer MUST specify actpass for both initial and subsequent offers but answerer MUST be able to handle active and passive setup roles as well. > > that works for me I don't understand what this accomplishes. If you must be able to accept anything in a received offer, then what is gained by restricting what can be used in an offer? Thanks, Paul From nobody Fri Jun 9 11:23:32 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3237012708C for ; Fri, 9 Jun 2017 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71ppgXEzZ9aS for ; Fri, 9 Jun 2017 11:23:29 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e: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 D8E891289C3 for ; Fri, 9 Jun 2017 11:23:29 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id k71so28956765pgd.2 for ; Fri, 09 Jun 2017 11:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xHzDpnD5WKKu3Iz6zLpw4Er5k2IvamVyGNMx2aQicSw=; b=2Ie4ij4oMUCzGDqkG1KaVOz6KmXoXfTIOYCUIPCMSPCeRFiOlcqQY1A1twToPdrNnt DRJnRaLuUxKoprzAt313/P7+OC/xACY2jzEtS+HE7AoF36CowJVpo/1U6a0HqlIbuYP8 qd7iI0rxWBd1RzU8Ih9Xk4q43OToWpBnnuViUZjhSmqj/JUid0mEURqt1ZJVDDM/iYq4 sGAJoDEhJ068o06VeAsexiTfIvvQ91v9oMovtaTYxr2QNnl/IFCv81PxBDWxykRq3l1e toJdZuHaNd9jj1txGRLQJs92yoFA/0U75VX9X0w3TXBH2EJNspfbL/qXMGz/LWhJ+ZEn 899A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xHzDpnD5WKKu3Iz6zLpw4Er5k2IvamVyGNMx2aQicSw=; b=QJVDtWsxD5DX2VbdPBFeLJIlZr0F8ki0YppB5tZmJ1n0nEhnuQjDwSRB2iSTYCG6qM qoILITfH1y14dhIVRVkIm/00kjlQhZHF8lyJXlSyWL5mTuBQIANJWXgmC+x2gsGsSq6C PrPrzASShZ68+tFQwBmotIeFE/XoH8/SMuGw48A/liW2uon+v6moPN8aDFNFdHLfR3dP xZZg097VV+dEBjkEVxKEcFqPQXcwR1OdokIyIQq/7DH9jaVQwnLSbIyhx20NN4aDipqg qITpkbslW3UC+XppWVca/yVJo8XSUJJiWHlKVEmo35VfM2Bxd4uKNDx/3UkCGrFqbn9E QHjg== X-Gm-Message-State: AODbwcAPHQrbzuwMUWgtBfUb7jXrKac5KSgFZCEHgkEduHh7eyvjNQ82 77cVNs0RLyLfBMhDiwM= X-Received: by 10.99.95.193 with SMTP id t184mr44056796pgb.127.1497032609340; Fri, 09 Jun 2017 11:23:29 -0700 (PDT) Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com. [74.125.83.49]) by smtp.gmail.com with ESMTPSA id c27sm4504907pfj.107.2017.06.09.11.23.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 11:23:28 -0700 (PDT) Received: by mail-pg0-f49.google.com with SMTP id f185so28984749pgc.0 for ; Fri, 09 Jun 2017 11:23:28 -0700 (PDT) X-Received: by 10.98.223.131 with SMTP id d3mr23639199pfl.112.1497032608337; Fri, 09 Jun 2017 11:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Fri, 9 Jun 2017 11:23:27 -0700 (PDT) In-Reply-To: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> From: Roman Shpount Date: Fri, 9 Jun 2017 14:23:27 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f403045cc7d4d658ba05518b1064" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 18:23:31 -0000 --f403045cc7d4d658ba05518b1064 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat wrote: > On 6/9/17 9:17 AM, Cullen Jennings wrote: > >> >> On Jun 8, 2017, at 6:49 PM, Roman Shpount wrote: >>> >>> Because of this, I think for the best interop, offerer MUST specify >>> actpass for both initial and subsequent offers but answerer MUST be able to >>> handle active and passive setup roles as well. >>> >> >> that works for me >> > > I don't understand what this accomplishes. If you must be able to accept > anything in a received offer, then what is gained by restricting what can > be used in an offer? > This is all because of legacy interop. There are legacy end points that send non-actpass, so end point MUST be able to accept active and passive to interop with such legacy devices. There are also legacy end points that only expect actass so end point MUST only send actpass to interop with such devices. _____________ Roman Shpount --f403045cc7d4d658ba05518b1064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@com= cast.net> wrote:
On 6/9/17 9:17 AM, Cullen Jennings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:

=C2=A0 Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able to= handle active and passive setup roles as well.

that works for me

I don't understand what this accomplishes. If you must be able to accep= t anything in a received offer, then what is gained by restricting what can= be used in an offer?

This is all becau= se of legacy interop. There are legacy end points that send non-actpass, so= end point MUST be able to accept active and passive to interop with such l= egacy devices. There are also legacy end points that only expect actass so = end point MUST only send actpass to interop with such devices.
_____________
Roman Shpount
=C2=A0
--f403045cc7d4d658ba05518b1064-- From nobody Fri Jun 9 12:34:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AD9129469 for ; Fri, 9 Jun 2017 12:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF7EecJ2I7-E for ; Fri, 9 Jun 2017 12:34:45 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A48129458 for ; Fri, 9 Jun 2017 12:34:44 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-03v.sys.comcast.net with SMTP id JPg0d7hz2fuM3JPgCdJQF4; Fri, 09 Jun 2017 19:34:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1497036884; bh=+YH7MKGbJ2zm0AUSo3Xj/egrZxvnpDZqRbf4QMSDcK8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hvXTyeFJ9g53yRj1UhZWVR28Dak3z3zmGdJnAk444nOkrTrnbgoXcvCyHZgkeRWFF r6pQS255Xyy2yiWSOKI/fuuWQIvaRdaxiwTxZStrOQLeSj6fRI3P05VtDNLJ7hNzm2 S7Hy80sEGAxbL483XlHNFt7qMTYYZCVy/lJsts76aiKhrfrZIDdufv4wPv1DesHHbh FjocJIQ37VrXGMLPEg0LTfmUPXSE7HkimJJyBeUZNM8IwhT0eWj6KKXHHfw46QuAS2 CEoElRmRnrCDv+1eXXspZGm3ttX+02oNKy1rEx1qbBWOBEVkUaNfGWBiYryA3PHVnD zXY9TA7QBz6PA== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-18v.sys.comcast.net with SMTP id JPgBdEZCuStKdJPgBd0V5M; Fri, 09 Jun 2017 19:34:44 +0000 To: Roman Shpount Cc: "mmusic@ietf.org" References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> From: Paul Kyzivat Message-ID: <34a8b084-aa24-6fe2-ef2a-f713f75fcaaf@comcast.net> Date: Fri, 9 Jun 2017 15:34:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJUikdzKlCHTeOov/k0esNjftAEpxVqbH1kFmoi3r0d93Q3YDAF/SR2voiykcOlRzU1g4CzIacxBSTcML79/iEtzo1FtxyTJgQaCbBxdMjxJhqDt4FMv TIYfRD3v9S/cOWOr+m8yq3eZNzDVCnJtSvBHJRMpxt9+Ann/MKUue9S8ObwM6ng4t1h8Q77WA8+qO3c48iPR2kAbolQK+50Mc08= Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 19:34:46 -0000 On 6/9/17 2:23 PM, Roman Shpount wrote: > On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat > wrote: > > On 6/9/17 9:17 AM, Cullen Jennings wrote: > > > On Jun 8, 2017, at 6:49 PM, Roman Shpount > wrote: > > Because of this, I think for the best interop, offerer > MUST specify actpass for both initial and subsequent offers > but answerer MUST be able to handle active and passive setup > roles as well. > > > that works for me > > > I don't understand what this accomplishes. If you must be able to > accept anything in a received offer, then what is gained by > restricting what can be used in an offer? > > > This is all because of legacy interop. There are legacy end points that > send non-actpass, so end point MUST be able to accept active and passive > to interop with such legacy devices. There are also legacy end points > that only expect actass so end point MUST only send actpass to interop > with such devices. I understand that. But if you accept that legacy interop is needed, then there ceases to be any reason to mandate actpass for things that conform to this spec. It would be different if you were proposing a path to deprecating and then dropping the legacy support. If that is the intent then it is worth saying something explicit about it. Thanks, Paul From nobody Fri Jun 9 12:41:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24C7128D3E for ; Fri, 9 Jun 2017 12:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R8Z20Vrg0sP for ; Fri, 9 Jun 2017 12:41:53 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 D994A126D85 for ; Fri, 9 Jun 2017 12:41:53 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id k71so29479639pgd.2 for ; Fri, 09 Jun 2017 12:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HNrT9oZCDG7rG09w9Ip3uFPL0kHR0d314yvQYu88t10=; b=io9Ef8hXfeoeCdkA1cDijP8Jp6pxCsFevFjANuWakEBP8MSj2MsTKTO/TaLv6Z5DOM UzRVYYF+4tqWfvOn7ewrw85rkJLr5tHa+gD3xEzYstZaXB7L3CJeWUCF9s+FNyB1+lqK 0hgQnKjXtVeGerZ5VNzBYcGcO95xYGOZ4A7tReRf86CuvMg1UiAPVZDQIrxUjdzzk3MC VWm74pNlhNCLZxExhAn3lUIwrr04rVBNLAM+9pNn8YxV2O5HjgyTl557cVXUow3LWUWy viT2IxmyZF2j41vx5fCztGVXUVCAS/ZmNFcUEQrjmtPrgBNbHmH/r+OatTXufHLIrw9I 2RTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HNrT9oZCDG7rG09w9Ip3uFPL0kHR0d314yvQYu88t10=; b=aoIcmbHZpLmbd2Su8peAH5Z9Dpzg3uqolGj1yfrtlWWXX9htb0JMHPrrJ5IuqcgRQN wlkBYrK7953gmbndqSpNGs1h6UE34120KrQ6Q9fF+PYoD/kuxu2vlr+jBTdVfH6FnqfV 4QfvAFRgsf5AsMCsweEWb/s2uzeFLJ7MObLDarKa9Snso73ORVSfAGihbpQZMAgKyOX0 a3CwW8aiGGG6iLjhksxtmBDvA0Lql8HeExiz1UCUA3z3qdgQRHBa0JDhqj/4rzSOyW85 IuB48wjgYnScR5u1obdFHWB1q+E24ecrmWG/Szzw1ioPICxi/ck4hmb8oPuL1qa7v6pF yg9w== X-Gm-Message-State: AODbwcD8Yl3qXraDzd/nvTCapzGnHoTRA1oMATKtWVkfHyYWuFBSY7uF CD2cKMTc2LsFpw9pIZU= X-Received: by 10.98.66.131 with SMTP id h3mr31926284pfd.12.1497037313158; Fri, 09 Jun 2017 12:41:53 -0700 (PDT) Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com. [209.85.192.176]) by smtp.gmail.com with ESMTPSA id h68sm402810pfh.45.2017.06.09.12.41.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 12:41:52 -0700 (PDT) Received: by mail-pf0-f176.google.com with SMTP id 83so31616000pfr.0 for ; Fri, 09 Jun 2017 12:41:52 -0700 (PDT) X-Received: by 10.99.143.9 with SMTP id n9mr19211742pgd.145.1497037312079; Fri, 09 Jun 2017 12:41:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Fri, 9 Jun 2017 12:41:51 -0700 (PDT) In-Reply-To: <34a8b084-aa24-6fe2-ef2a-f713f75fcaaf@comcast.net> References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> <34a8b084-aa24-6fe2-ef2a-f713f75fcaaf@comcast.net> From: Roman Shpount Date: Fri, 9 Jun 2017 15:41:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f403045da70033c04605518c293e" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 19:41:56 -0000 --f403045da70033c04605518c293e Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat wrote: > On 6/9/17 2:23 PM, Roman Shpount wrote: > >> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat > > wrote: >> >> On 6/9/17 9:17 AM, Cullen Jennings wrote: >> >> >> On Jun 8, 2017, at 6:49 PM, Roman Shpount > > wrote: >> >> Because of this, I think for the best interop, offerer >> MUST specify actpass for both initial and subsequent offers >> but answerer MUST be able to handle active and passive setup >> roles as well. >> >> >> that works for me >> >> >> I don't understand what this accomplishes. If you must be able to >> accept anything in a received offer, then what is gained by >> restricting what can be used in an offer? >> >> >> This is all because of legacy interop. There are legacy end points that >> send non-actpass, so end point MUST be able to accept active and passive to >> interop with such legacy devices. There are also legacy end points that >> only expect actass so end point MUST only send actpass to interop with such >> devices. >> > > I understand that. But if you accept that legacy interop is needed, then > there ceases to be any reason to mandate actpass for things that conform to > this spec. It would be different if you were proposing a path to > deprecating and then dropping the legacy support. If that is the intent > then it is worth saying something explicit about it. > The situation right now is that there are implementations that send offers with setup role set to active or passive. So, my suggestion for the language (subject to future wordsmithing) is: End points MUST set setup role to actpass in all offers. End points SHOULD accept setup role active or passive in an offer if interoperability with legacy end points is desired. Does this work? _____________ Roman Shpount --f403045da70033c04605518c293e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jun 9, 2017 at 3:34= PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
On 6/9/17 2:23 PM, Roma= n Shpount wrote:
On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast.net <mailto= :paul.kyzivat= @comcast.net>> wrote:

=C2=A0 =C2=A0 On 6/9/17 9:17 AM, Cullen Jennings wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Jun 8, 2017, at 6:49 PM, Roman= Shpount <roman@t= elurix.com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:roman@telurix.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Because of this, I t= hink for the best interop, offerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST specify actpass for both ini= tial and subsequent offers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 but answerer MUST be able to hand= le active and passive setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 roles as well.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 that works for me


=C2=A0 =C2=A0 I don't understand what this accomplishes. If you must be= able to
=C2=A0 =C2=A0 accept anything in a received offer, then what is gained by =C2=A0 =C2=A0 restricting what can be used in an offer?


This is all because of legacy interop. There are legacy end points that sen= d non-actpass, so end point MUST be able to accept active and passive to in= terop with such legacy devices. There are also legacy end points that only = expect actass so end point MUST only send actpass to interop with such devi= ces.

I understand that. But if you accept that legacy interop is needed, then th= ere ceases to be any reason to mandate actpass for things that conform to t= his spec. It would be different if you were proposing a path to deprecating= and then dropping the legacy support. If that is the intent then it is wor= th saying something explicit about it.

= The situation right now is that there are implementations that send offers = with setup role set to active or passive. So, my suggestion for the language (subject to futu= re wordsmithing) is: End points MUST set setup role to actpass in all offer= s. End points SHOULD accept setup role active or passive in an offer if int= eroperability with legacy end points is desired.

Does this work?
_____________
Roman Shpount
=C2=A0
--f403045da70033c04605518c293e-- From nobody Fri Jun 9 14:18:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D849F1275AB for ; Fri, 9 Jun 2017 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bcD_I_-sziu for ; Fri, 9 Jun 2017 14:18:35 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5505F120724 for ; Fri, 9 Jun 2017 14:18:35 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-01v.sys.comcast.net with SMTP id JRIadG2NCO3QoJRIgd0eck; Fri, 09 Jun 2017 21:18:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1497043114; bh=T2rOboFnE2aaySlK2jUxoPkMYYIbqp+ObpQ47rK3O1c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=JJKu2kfetocnjE09eZYbb9zHBq+X5M4tR1agEP1onQCZlHBNCZ7yoNARMJ4zcDPiT 7s3LK93LHIRRDUvTshSNwsjhgxl6YsRF+W1pbudJ9i++67QZgu4aql4Hynx/P51hCE Xq9gjnQ9rAuNcEblxAHQzbkLxxI3020r/lZcsKt47gaIJqRacTCh7Zny32TPCOBhjx oVKhUaDDJoNpD1ZWjGRTRjEWCqy/6VQ7Wob97at7jZCHge4UkrHbN/bpNGbxexQW5l 8kXGgPFxy8o/PshNwJ3rAMvLyI65uIY36BgluyS1/rORuS6yp5gRplp0RyqMb+mbuz ER6p2Vs3dfa+w== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-03v.sys.comcast.net with SMTP id JRIfdujQkVzqSJRIgdNUJX; Fri, 09 Jun 2017 21:18:34 +0000 To: Roman Shpount Cc: "mmusic@ietf.org" References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> <34a8b084-aa24-6fe2-ef2a-f713f75fcaaf@comcast.net> From: Paul Kyzivat Message-ID: Date: Fri, 9 Jun 2017 17:18:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKNaj9ga8YAnk410XjDvRbMHhslJ79A/u8hHGGnlFQdR7Nzcx3Zr4k3mxwl+vBhOHQ/jbNneQmVZYat9R+X9MLS8+PVYaUIvKM3++sbqrrEqw10vCwGB FRso8cDoO6MuiBcjbdKDPL6wRbk6PM+jwdx9Mw16C5z7L6vuHc2bckfb/eQx1JryrEDjm0eckz/cpFfk+dDaQ2hk7Pt0+KRHWVM= Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 21:18:37 -0000 On 6/9/17 3:41 PM, Roman Shpount wrote: > > On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat > wrote: > > On 6/9/17 2:23 PM, Roman Shpount wrote: > > On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat > > >> wrote: > > On 6/9/17 9:17 AM, Cullen Jennings wrote: > > > On Jun 8, 2017, at 6:49 PM, Roman Shpount > > >> wrote: > > Because of this, I think for the best interop, > offerer > MUST specify actpass for both initial and > subsequent offers > but answerer MUST be able to handle active and > passive setup > roles as well. > > > that works for me > > > I don't understand what this accomplishes. If you must be > able to > accept anything in a received offer, then what is gained by > restricting what can be used in an offer? > > > This is all because of legacy interop. There are legacy end > points that send non-actpass, so end point MUST be able to > accept active and passive to interop with such legacy devices. > There are also legacy end points that only expect actass so end > point MUST only send actpass to interop with such devices. > > > I understand that. But if you accept that legacy interop is needed, > then there ceases to be any reason to mandate actpass for things > that conform to this spec. It would be different if you were > proposing a path to deprecating and then dropping the legacy > support. If that is the intent then it is worth saying something > explicit about it. > > > The situation right now is that there are implementations that send > offers with setup role set to active or passive. Why is that a problem? > So, my suggestion for > the language (subject to future wordsmithing) is: End points MUST set > setup role to actpass in all offers. End points SHOULD accept setup role > active or passive in an offer if interoperability with legacy end points > is desired. So is it your intent to make implementation of support for responding to a non-actpass offer OPTIONAL? This encourages implementations to decide to not support legacy interop. IMO this is a bad idea because it is rarely possible to ensure that it won't eventually be required. Thanks, Paul From nobody Fri Jun 9 14:48:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A80A129478 for ; Fri, 9 Jun 2017 14:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y_cqM33ElRB for ; Fri, 9 Jun 2017 14:48:51 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e: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 DFE3512717E for ; Fri, 9 Jun 2017 14:48:50 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id a70so30229697pge.3 for ; Fri, 09 Jun 2017 14:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lFc58nXkyzIwBsgQOnbbPxyJBU9ErFRsZfjg/HI34dw=; b=tiTCF7zMGa5mRZZGAnRZPXiZ0Ae+/BebOllMex052T2EJKHybpwDitk4+p7t0tk8ag fK/wUQaJe+MV5lrulL4vNT9/Y9epIyWdMh+kywbJHyOM22SmtoK5oz9WyjbGGXHx42pr Yk+Wus3OD+uHonF/sVR2HeRa9R7xl2Ae52lK63q+W3Tu3GOyjROat2TbOHlCb60cD/v/ ZAlb/9P7gN7ID5RlY4JC9lrFRCndn34VpGObnIBBZ5klehfnWjbW94mUtL/4laRSYfH7 2YMzj5dSC6iqLxMNMQbZmlBBYP3yoALqkYaYgfr4zkA1wUuc1IqQyZ3oJQlO4AxKCw29 O8Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lFc58nXkyzIwBsgQOnbbPxyJBU9ErFRsZfjg/HI34dw=; b=JGiHiTdkcswtOlj+M6E9zoNH/4ab1csuGdoszertxFhh5CR9QXG4CXJq+BNBbDdk4f sbKzYc6JzjywPUx90f+NM2hCZtUN3ONkTe7puGRqxHjanE7hCrcp8+mmEMAK8lnVfRiq epND8UbAhRkQ8uJZ7l+hlB4yQfr5gucdgVu7KhJivkfTODJVcDAwDT1F1NZPuWKfyDke s30rG3aotuk1151Q/mWfpD8qnRt6i6eQ/2Su65S6aCUXXLXDLd3Ko1CiEyHzTZ44pjfy Wwf+nYzB4grDsctq4EmGyrLcy/obaot/E9aIJIWq79xohbpAiZdErDSjWuPWmi2GXO39 lGHQ== X-Gm-Message-State: AODbwcAn5RyimjW2s3KHovgHepRix/+S71Oy9VZs2pOqRhGFsntl1iOO LOolFJaqGX5XEEHHqnw= X-Received: by 10.99.149.70 with SMTP id t6mr45302033pgn.168.1497044930342; Fri, 09 Jun 2017 14:48:50 -0700 (PDT) Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com. [74.125.83.49]) by smtp.gmail.com with ESMTPSA id 71sm3825325pgd.57.2017.06.09.14.48.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 14:48:49 -0700 (PDT) Received: by mail-pg0-f49.google.com with SMTP id v18so30243332pgb.1 for ; Fri, 09 Jun 2017 14:48:49 -0700 (PDT) X-Received: by 10.84.133.100 with SMTP id 91mr529345plf.106.1497044929277; Fri, 09 Jun 2017 14:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Fri, 9 Jun 2017 14:48:48 -0700 (PDT) In-Reply-To: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> <34a8b084-aa24-6fe2-ef2a-f713f75fcaaf@comcast.net> From: Roman Shpount Date: Fri, 9 Jun 2017 17:48:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c124f4a39029605518def7f" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 21:48:53 -0000 --94eb2c124f4a39029605518def7f Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 5:18 PM, Paul Kyzivat wrote: > On 6/9/17 3:41 PM, Roman Shpount wrote: > >> >> On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat > > wrote: >> >> On 6/9/17 2:23 PM, Roman Shpount wrote: >> >> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat >> >> > >> wrote: >> >> On 6/9/17 9:17 AM, Cullen Jennings wrote: >> >> >> On Jun 8, 2017, at 6:49 PM, Roman Shpount >> >> > >> >> wrote: >> >> Because of this, I think for the best interop, >> offerer >> MUST specify actpass for both initial and >> subsequent offers >> but answerer MUST be able to handle active and >> passive setup >> roles as well. >> >> >> that works for me >> >> >> I don't understand what this accomplishes. If you must be >> able to >> accept anything in a received offer, then what is gained by >> restricting what can be used in an offer? >> >> >> This is all because of legacy interop. There are legacy end >> points that send non-actpass, so end point MUST be able to >> accept active and passive to interop with such legacy devices. >> There are also legacy end points that only expect actass so end >> point MUST only send actpass to interop with such devices. >> >> >> I understand that. But if you accept that legacy interop is needed, >> then there ceases to be any reason to mandate actpass for things >> that conform to this spec. It would be different if you were >> proposing a path to deprecating and then dropping the legacy >> support. If that is the intent then it is worth saying something >> explicit about it. >> >> >> The situation right now is that there are implementations that send >> offers with setup role set to active or passive. >> > > Why is that a problem? If we simply specify that offers MUST contain setup role set to actpass, implementation would legitimately respond to anything with setup role set to active or passive with an error. We want to avoid this since there are existing end points that send active or passive in offers. There are also legacy end points that will only accept actpass. New end points MUST set setup role to actpass to work with them. Finally, setup role MUST be actpass since this allows answering party to determine the setup role. Answering end points typically should be active, since this reduces the call setup time. There is an exception to this for ICE-lite or symmetric UDP, where end points on public IP typically should be passive even when they are answering, since it will require the end point behind NAT to send the first packet to open the NAT pin-hole. > So, my suggestion for the language (subject to future wordsmithing) is: >> End points MUST set setup role to actpass in all offers. End points SHOULD >> accept setup role active or passive in an offer if interoperability with >> legacy end points is desired. >> > > So is it your intent to make implementation of support for responding to a > non-actpass offer OPTIONAL? This encourages implementations to decide to > not support legacy interop. IMO this is a bad idea because it is rarely > possible to ensure that it won't eventually be required. > You just said that we need to add language about phasing out support for offers with active or passive. We can phase out handling of active and passive setup roles when they are no longer used by existing implementations. This is why it is a SHOULD. We can make handling active and passive offers permanent and put it under a MUST. Regards, _____________ Roman Shpount --94eb2c124f4a39029605518def7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 9, 2017 at 5:18 PM, Paul Kyzivat <paul.kyzivat@com= cast.net> wrote:
On 6/9/17 3:41 PM, Roman Sh= pount wrote:

On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat <paul.kyzivat@comcast.net <mailto= :paul.kyzivat= @comcast.net>> wrote:

=C2=A0 =C2=A0 On 6/9/17 2:23 PM, Roman Shpount wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat =C2=A0 =C2=A0 =C2=A0 =C2=A0 <paul.kyzivat@comcast.net <mailto:paul.kyzivat@comcast.net= >
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:paul.kyzivat@comcast.net
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:paul.kyzivat@comcast.net>>> wro= te:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 6/9/17 9:17 AM, Cullen J= ennings wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0On Jun 8, 2017, at 6:49 PM, Roman Shpount
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <roman@telurix.com <mailto:roman@telurix.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:roman@= telurix.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:roman@telurix.com>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Because of this, I think for the best interop,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 offerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0MUST specify actpass for both initial and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 subsequent offers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0but answerer MUST be able to handle active and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 passive setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0roles as well.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that works fo= r me


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't understand what= this accomplishes. If you must be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 able to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accept anything in a receiv= ed offer, then what is gained by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0restricting what can be use= d in an offer?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is all because of legacy interop. There ar= e legacy end
=C2=A0 =C2=A0 =C2=A0 =C2=A0 points that send non-actpass, so end point MUST= be able to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 accept active and passive to interop with such = legacy devices.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There are also legacy end points that only expe= ct actass so end
=C2=A0 =C2=A0 =C2=A0 =C2=A0 point MUST only send actpass to interop with su= ch devices.


=C2=A0 =C2=A0 I understand that. But if you accept that legacy interop is n= eeded,
=C2=A0 =C2=A0 then there ceases to be any reason to mandate actpass for thi= ngs
=C2=A0 =C2=A0 that conform to this spec. It would be different if you were<= br> =C2=A0 =C2=A0 proposing a path to deprecating and then dropping the legacy<= br> =C2=A0 =C2=A0 support. If that is the intent then it is worth saying someth= ing
=C2=A0 =C2=A0 explicit about it.


The situation right now is that there are implementations that send offers = with setup role set to active or passive.

Why is that a problem?

If we simply specify= that offers MUST contain setup role set to actpass, implementation would l= egitimately respond to anything with setup role set to active or passive wi= th an error. We want to avoid this since there are existing end points that= send active or passive in offers.

There are also = legacy end points that will only accept actpass. New end points MUST set se= tup role to actpass to work with them.

Finally, se= tup role MUST be actpass since this allows answering party to determine the= setup role. Answering end points typically should be active, since this re= duces the call setup time. There is an exception to this for ICE-lite or sy= mmetric UDP, where end points on public IP typically should be passive even= when they are answering, since it will require the end point behind NAT to= send the first packet to open the NAT pin-hole.
=C2=A0
So, my suggestion for the langu= age (subject to future wordsmithing) is: End points MUST set setup role to = actpass in all offers. End points SHOULD accept setup role active or passiv= e in an offer if interoperability with legacy end points is desired.

 So is it your intent to make implementation of support for responding to a = non-actpass offer OPTIONAL? This encourages implementations to decide to no= t support legacy interop. IMO this is a bad idea because it is rarely possi= ble to ensure that it won't eventually be required.

You just said that we need to add language about phasing o= ut support for offers with active or passive. We can phase out handling of = active and passive setup roles when they are no longer used by existing imp= lementations. This is why it is a SHOULD. We can make handling active and p= assive offers permanent and put it under a MUST.=C2=A0

=
Regards,
_____________
Rom= an Shpount
=C2=A0
--94eb2c124f4a39029605518def7f-- From nobody Sat Jun 10 02:35:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71544124D37 for ; Sat, 10 Jun 2017 02:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmO-DD3QbeBz for ; Sat, 10 Jun 2017 02:35:16 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 0E7561201F2 for ; Sat, 10 Jun 2017 02:35:16 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l75so26234837ywc.3 for ; Sat, 10 Jun 2017 02:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9GUPoNDPwwCQFjOm1zCb7FqUR1pMiBDpR9fEsQTriAo=; b=kCL9F7P48ptSNtZ/xOFnTe/LfNwR1BfJ/Fz0J9pGJoxc+uaLkI/smKQh46lr7uVKVc io8V/ZBotYVzSjiHeDZlMMNZ0e6LPgwzFVI3E7tOjazd1S6sMngjk2byjhOXG+1nV6SJ mXcrx9ykyQK7BqBCzFpGzTdw3gDmCMdr7EBqpPWwVo/V6evOy3RF434z/scDFyR3Y7IW 4/uXNIHYzDLhSlXuhaPuoJ0fSCnh8qq/GaGsjjNbJBFIkfZcfz8jVNpfBYfWqxoF32Uz rXh16wjoX65OaF94JzkoD96LQcZtHv308rGGnwjJnIFZFDhGWYiZU/SGVBJbX2mmOg36 +d1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9GUPoNDPwwCQFjOm1zCb7FqUR1pMiBDpR9fEsQTriAo=; b=CHLFUcWwpV71GXJktvmdtvdfhwCTin/ok8FvJ5qCQsiImzuThYg8dwxhYbT2eHkwXG abIKQoehN8XO/s5j5z2ifmAEspCZ8jUgWaoEYAfwo580ZoYD6ad+h/KLMhoEA+at2QRb ub0OOq42KOrMv4A+vhDfYStvJtOpF8gt2O77j5l4YU2TTW4HpJVjMcpGN7orDZzz8xoC lnlyEmgM/sakA+EEZ+4ctjhrL7kQeY0qp1aXd9nWVcxx+B980s+jZ6cZml9QUQl+V21q Jzt0Wb5yMRiHRfQBynKmox8Jc737ZjRZzUa6yu01V7xSefCTRuLmZD7PjqaTEMR+R2kV rB/g== X-Gm-Message-State: AODbwcDiM3HZQ/RSPm5uCL0IGjRKYCHRqP16bPL1+6ENlP9S25YIn2++ UtFsxZpt3/lAH3kN48xPWU35x/ol/CMP X-Received: by 10.129.43.68 with SMTP id r65mr11700945ywr.24.1497087315205; Sat, 10 Jun 2017 02:35:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 10 Jun 2017 02:34:34 -0700 (PDT) In-Reply-To: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> From: Eric Rescorla Date: Sat, 10 Jun 2017 10:34:34 +0100 Message-ID: To: Roman Shpount Cc: Paul Kyzivat , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a1141e7989efc51055197cdbd" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 09:35:19 -0000 --001a1141e7989efc51055197cdbd Content-Type: text/plain; charset="UTF-8" On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount wrote: > On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat > wrote: > >> On 6/9/17 9:17 AM, Cullen Jennings wrote: >> >>> >>> On Jun 8, 2017, at 6:49 PM, Roman Shpount wrote: >>>> >>>> Because of this, I think for the best interop, offerer MUST specify >>>> actpass for both initial and subsequent offers but answerer MUST be able to >>>> handle active and passive setup roles as well. >>>> >>> >>> that works for me >>> >> >> I don't understand what this accomplishes. If you must be able to accept >> anything in a received offer, then what is gained by restricting what can >> be used in an offer? >> > > This is all because of legacy interop. There are legacy end points that > send non-actpass, so end point MUST be able to accept active and passive to > interop with such legacy devices. > Those legacy endpoints are clearly noncomformant, so I'm not sure I care about breaking them, > There are also legacy end points that only expect actass so end point MUST > only send actpass to interop with such devices. > These legacy endpoints are conformant, which is why it's important to accommodate them -Ekr > _____________ > Roman Shpount > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1141e7989efc51055197cdbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.com&g= t; wrote:
On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <= paul.kyzivat@comcast.net> wrote:
On 6/9/17 9:17 AM, Cullen Jennings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:

=C2=A0 Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able to= handle active and passive setup roles as well.

that works for me

I don't understand what this accomplishes. If you must be able to accep= t anything in a received offer, then what is gained by restricting what can= be used in an offer?

This is al= l because of legacy interop. There are legacy end points that send non-actp= ass, so end point MUST be able to accept active and passive to interop with= such legacy devices.

<= div>Those legacy endpoints are clearly noncomformant, so I'm not sure I= care about breaking them,

=C2=A0
There are also legacy end points that only expect act= ass so end point MUST only send actpass to interop with such devices.
=

These legacy endpoints a= re conformant, which is why it's important to accommodate them

-Ekr
=C2=A0
=
_____________
Roman Shpount
=
=C2=A0

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

--001a1141e7989efc51055197cdbd-- From nobody Mon Jun 12 00:33:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05423129C36 for ; Mon, 12 Jun 2017 00:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_177CdQjtT9 for ; Mon, 12 Jun 2017 00:33:39 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8017C129C26 for ; Mon, 12 Jun 2017 00:33:39 -0700 (PDT) X-AuditID: c1b4fb30-874f69a000003fda-86-593e43d1e815 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.72.16346.1D34E395; Mon, 12 Jun 2017 09:33:37 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Mon, 12 Jun 2017 09:33:36 +0200 From: Christer Holmberg To: Eric Rescorla , Roman Shpount CC: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] actpass redux Thread-Index: AQHS27+QUKTkX8TgukOHH0lDl2aBAKIRu7eAgAA2MQCABCQrAIAFew8AgAAKOICAANEbAIAATywAgAAGUoCAAP6QAIADNvOA Date: Mon, 12 Jun 2017 07:33:35 +0000 Message-ID: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D5641A331E1FEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2J7iO5FZ7tIg5P/1SxWvD7HbjF1+WMW iwc/etksZlyYyuzA4jH58RxGjyVLfjIBWW3MHremFASwRHHZpKTmZJalFunbJXBl/N/5nrlg bmjFtZU3mRoYj3l0MXJySAiYSOxZOpWpi5GLQ0jgCKPEzPczmCGcxYwSq9afA3I4ONgELCS6 /2mDNIgIOEucaHvBBmIzCwRJnDrdCWYLCyhL3JzcwAxRoyLxsn0pC4SdJ/Hqxld2EJtFQFVi 54kOJpCRvALWEgcmJUOs6meVePdtJ1gvp0CgRN/uq6wgNqOAmMT3U2uYIHaJS9x6Mp8J4mgB iSV7zjND2KISLx//YwWZKSqgJ/FuvydEWFHi46t9jBCtCRJLjl8GO4FXQFDi5MwnLBMYRWch mToLSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45ywhhW0scefyKDVnNAkaOVYyixanFSbnp RkZ6qUWZycXF+Xl6eaklmxiBsXpwy2+DHYwvnzseYhTgYFTi4d1maRcpxJpYVlyZe4hRgoNZ SYT3shNQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsbO sHVV85IXFEuezpATtTr1oimvOj9t43H2jqUZNUc1Zj35Efn0jYNiW3yo/0mNB4VxHT99tM4f Z+/b6fks88U+q0MVP0zfs7GJPn2l3b197leFWpe8uN1Nd8u27z1QoL1O8s2aGyJr/t9SVrh0 /uiWg8HaT/eF8z9zPluz9LLIPfuEfcFVzp+VWIozEg21mIuKEwEbJwwY0QIAAA== Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 07:33:42 -0000 --_000_D5641A331E1FEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, First, one of the reasons we update specs is because there are usages etc, = that people weren=92t aware of when the original spec was published, that w= e think we need to cover. So, rather than just saying that we don=92t care = about non-comformant endpoints, we should ask WHY they are non-comformant. = Is there a specific use-case behind? If so, do we need to cover that use-ca= se? Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp i= s GENERIC - one of the main reasons we do the spec in the first place is to= have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDPTL-DT= LS) DOES allow non-actpass values in the offer: "The offerer SHOULD assign the SDP "setup" attribute with a value o= f "actpass", unless the offerer insists on being either the sender or receiver of the DTLS ClientHello message," draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and b= y mandating actpass we would remove a valid option for UDPTL-DTLS. Sure, we= can do that, but it cannot be based on a claim that existing endpoints are= non-comformant. And, I do NOT think we want to allow non-actpass for some usages (e.g., UDP= TL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because that wo= uld go against the purpose of having generic DTLS O/A procedures. Regards, Christer From: mmusic > on b= ehalf of Eric Rescorla > Date: Saturday 10 June 2017 at 12:34 To: Roman Shpount > Cc: Paul Kyzivat = >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] actpass redux On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount > wrote: On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat > wrote: On 6/9/17 9:17 AM, Cullen Jennings wrote: On Jun 8, 2017, at 6:49 PM, Roman Shpount > wrote: Because of this, I think for the best interop, offerer MUST specify actpa= ss for both initial and subsequent offers but answerer MUST be able to hand= le active and passive setup roles as well. that works for me I don't understand what this accomplishes. If you must be able to accept an= ything in a received offer, then what is gained by restricting what can be = used in an offer? This is all because of legacy interop. There are legacy end points that sen= d non-actpass, so end point MUST be able to accept active and passive to in= terop with such legacy devices. Those legacy endpoints are clearly noncomformant, so I'm not sure I care ab= out breaking them, There are also legacy end points that only expect actass so end point MUST = only send actpass to interop with such devices. These legacy endpoints are conformant, which is why it's important to accom= modate them -Ekr _____________ Roman Shpount _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D5641A331E1FEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

First, one of the reasons we update specs is because there are usages = etc, that people weren=92t aware of when the original spec was published, t= hat we think we need to cover. So, rather than just saying that we don=92t = care about non-comformant endpoints, we should ask WHY they are non-comformant. Is there a specific use-case be= hind? If so, do we need to cover that use-case?

Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-= sdp is GENERIC - one of the main reasons we do the spec in the first place = is to have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDP= TL-DTLS) DOES allow non-actpass values in the offer:

	"The offerer SHOULD assign the SDP &quo=
t;setup" attribute with a value of
   	"a=
ctpass", unless the offerer insists on being either the sender or
   	receive=
r of the DTLS ClientHello message,"
draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, = and by mandating actpass we would remove a valid option for UDPTL-DTLS. Sur= e, we can do that, but it cannot be based on a claim that existing endpoint= s are non-comformant. 

And, I do NOT think we want to allow non-actpass for some usages (e.g.= , UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because th= at would go against the purpose of having generic DTLS O/A procedures.

Regards,

Christer


From: mmusic <mmusic-bounces@ietf.org> on behalf of Eric = Rescorla <ekr@rtfm.com>
Date: Saturday 10 June 2017 at 12:3= 4
To: Roman Shpount <roman@telurix.com>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] actpass redux=



On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.co= m> wrote:
On Fri, Jun 9, 2017 at = 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
On 6/9/17 9:17 AM, Cullen Jenn= ings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:

  Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able to= handle active and passive setup roles as well.

that works for me

I don't understand what this accomplishes. If you must be able to accept an= ything in a received offer, then what is gained by restricting what can be = used in an offer?
This is all because of legacy interop. There are legacy end points tha= t send non-actpass, so end point MUST be able to accept active and passive = to interop with such legacy devices.

Those legacy endpoints are clearly noncomformant, so I'm not sure I ca= re about breaking them,

 
There are also legacy end points that only expect actass so end point = MUST only send actpass to interop with such devices.

These legacy endpoints are conformant, which is why it's important to = accommodate them

-Ekr
 
_____________
Roman Shpount
 

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

--_000_D5641A331E1FEchristerholmbergericssoncom_-- From nobody Mon Jun 12 01:01:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8434C129C3F for ; Mon, 12 Jun 2017 01:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnozkdrXA2IB for ; Mon, 12 Jun 2017 01:00:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37992128D16 for ; Mon, 12 Jun 2017 01:00:57 -0700 (PDT) X-AuditID: c1b4fb3a-31fff70000004a6a-67-593e4a387858 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.0E.19050.83A4E395; Mon, 12 Jun 2017 10:00:56 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0339.000; Mon, 12 Jun 2017 10:00:55 +0200 From: Christer Holmberg To: Roman Shpount , Cullen Jennings CC: mmusic Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHS3gR6cOUoIT8u10KHxHCOXLs6qqIWXGKAgAN2xgCAAQSegIAAORoAgAB5MgCAAAlUgIAA2NeAgAAM04CABIF+AA== Date: Mon, 12 Jun 2017 08:00:54 +0000 Message-ID: References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca> <6D9B0AD9-F9C9-4DF6-A2AB-D160094E5FE3@iii.ca> <46506F82-3944-471C-80E9-D622EB3E1211@iii.ca> <727A5880-BAF5-44FC-8112-6FF5206AEEBC@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D56424651E242christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7lq6Fl12kwc+PEhYf1v9gtJi6/DGL xYwLU5kdmD2WLPnJ5HH5/EdGj1tTCgKYo7hsUlJzMstSi/TtErgy/t2YwFhwy7di3syZTA2M Rx27GDk5JARMJCb3TWDpYuTiEBI4wiixYcpxRghnMaPE9cn97F2MHBxsAhYS3f+0QRpEBNwk 3s54wwpiMwvISMw428gEUiIsUCVx8lkdREm1xObjF9kg7CyJxj+dYDaLgKrEvglvWUBsXgFr iZ+Pm9khVn1jlfg4rYsZJMEpECjx5+tNJhCbUUBM4vupNUwQu8Qlbj2ZzwRxtIDEkj3nmSFs UYmXj/+xgtwgKqAn8W6/J0RYUeLjq32MEK0JEo2TvjFD7BWUODnzCcsERtFZSKbOQlI2C0kZ RNxA4v25+cwQtrbEsoWvoWx9iY1fzjJC2NYSS+acY0RWs4CRYxWjaHFqcXFuupGRXmpRZnJx cX6eXl5qySZGYFwe3PLbagfjweeOhxgFOBiVeHjvWNhFCrEmlhVX5h5ilOBgVhLhvecBFOJN SaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNTqoHR1Uz1egx72hOT tkb74IUVCo+jtpx7t8Ij/+wLjpJ13aVNzsV6S14JftSd/21d3D4/m6Ldr7j3x+eLZ5rtzL79 4K9F0m0Fxz85MSJ5mhdNfS5daTkeNXeG3plZfnl9jhOnm6ha3t+9pVdrziHZ9sdvufxZrJ87 KHs6JWkyLtkRdvX1jw12+/8psRRnJBpqMRcVJwIAdG0TrMcCAAA= Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:01:00 -0000 --_000_D56424651E242christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I also don=92t see how Roman=92s suggestion would contradict what Cullen wa= nts to contradict. Roman, please make the pull request so that we have actu= al text to look at. Regards, Christer From: Roman Shpount > Date: Friday 9 June 2017 at 17:18 To: Cullen Jennings > Cc: "mmusic@ietf.org" >, Christer Holmberg > Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS assoc= iation before it has received the SDP answer? On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jennings > wrote: I'd really really appreciate if you could give me a hint of it you agree wi= th my original points I asked about or which ones you disagree with and why= . The three points I am interested in are: For devices that want to minimize delay in setting up media and avoid media= clipping, doing the TLS handshake as soon as possible is good design but i= n some cases this means the system does the handshake before the identity = of the fingerprint is known. Doing TLS handshake as soon as possible is a good design. Doing answer iden= tity and integrity validation and validating certificate fingerprints as so= on as possible is a better design. I understand that doing answer and finge= rprint validation is not always possible when interfacing with legacy SIP d= evices, but there is no reason to design new solutions which process media = before the answer. For instance WebRTC has no reason to support unverified = media. Because of this, I think that anything that produces unverified medi= a is a bad design which has no reason to exist apart for legacy interop. Sp= ecifics on how to design session description identity and integrity validat= ion are clearly out of scope for this draft. All of this being said, what I am proposing for the sake of moving this dra= ft forward does not contradict any of your points. Once again, what I am pr= oposing is: 1. Remove any recommendation regarding handling DTLS association before the= answer (leave it up to implementation) 2. Put a note that accepting DTLS association before the answer can result = in unverified media and if this media is played back to the end user, end u= ser SHOULD be notified that media is coming from an unverified source. 3. Add clarification that DTLS associations established before the answer M= UST be torn down when no more answers are expected and that fingerprints in= any of the received answers match the negotiated certificate (Right now it= is specified that DTLS association MUST be torn down if it does not match = the answer. This is wrong if forking is used and multiple answers are recei= ved). Draft does not advise that DTLS association should be established before th= e answer is received (I think this is wrong), but it also does not advise t= hat it should not (you think it is wrong). This way implementation decides = what's best for it. Does it contradict anything that you want to accomplish? If it does, what needs to be changed? Regards, _____________ Roman Shpount --_000_D56424651E242christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

I also don=92t see how Roman=92s suggestion would contradict what Cull= en wants to contradict. Roman, please make the pull request so that we have= actual text to look at.

Regards,

Christer



From: Roman Shpount <roman@telurix.com>
Date: Friday 9 June 2017 at 17:18 To: Cullen Jennings <fluffy@iii.ca>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] draft-dtls-sd= p: Allow offerer to establish DTLS association before it has received the S= DP answer?

On Fri, Jun 9, 20= 17 at 9:32 AM, Cullen Jennings <fl= uffy@iii.ca> wrote:
I'd really really appreciate if you could give me a hint of it you agree wi= th my original points I asked about or which ones you disagree with and why= . The three points I am interested in are:

For devices that want to minimize delay in setting up media and avoid media= clipping, doing the TLS handshake as soon as possible is good design but i= n some cases this means the system does  the handshake before the iden= tity of the fingerprint is known.

Doing TLS handshake as soon as possible is a good design. Doing answer= identity and integrity validation and validating certificate fingerprints = as soon as possible is a better design. I understand that doing answer and = fingerprint validation is not always possible when interfacing with legacy SIP devices, but there is no reason = to design new solutions which process media before the answer. For instance= WebRTC has no reason to support unverified media. Because of this, I think= that anything that produces unverified media is a bad design which has no reason to exist apart for legacy intero= p. Specifics on how to design session description identity and integrity va= lidation are clearly out of scope for this draft.

All of this being said, what I am proposing for the sake of moving thi= s draft forward does not contradict any of your points. Once again, what I = am proposing is:

1. Remove any recommendation regarding hand= ling DTLS association before the answer (leave it up to implementation)
2. Put a note that accepti= ng DTLS association before the answer can result in unverified media and if= this media is played back to the end user, end user SHOULD be notified tha= t media is coming from an unverified source.
3. Add clarification that DTLS associations= established before the answer MUST be torn down when no more answers are e= xpected and that fingerprints in any of the received answers match the nego= tiated certificate (Right now it is specified that DTLS association MUST be torn down if it does not match the= answer. This is wrong if forking is used and multiple answers are received= ).

Draft does not advise that DTLS association should be established befo= re the answer is received (I think this is wrong), but it also does not adv= ise that it should not (you think it is wrong). This way implementation dec= ides what's best for it.

Does it contradict anything that you want to accomplish?
If it does, what needs to be changed?

Regards,
_____________
Roman Shpount
 
 --_000_D56424651E242christerholmbergericssoncom_-- From nobody Mon Jun 12 02:58:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E585127201 for ; Mon, 12 Jun 2017 02:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNrif3zSQacs for ; Mon, 12 Jun 2017 02:58:38 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 6535C1294EE for ; Mon, 12 Jun 2017 02:58:38 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id v7so17367272ywc.2 for ; Mon, 12 Jun 2017 02:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8brsJJQmvYoHCp8YhWBHpJBXS/lRsv+EKzHLPe1YzMo=; b=VmXbzSqawQS3uruX3eftrw78syetg6t8OQJ31983UEOqapFWfJtzs5O7cudeVI6zJE g782gVHOyKinXJLF5XLSf9EVMLH+dVDF7udbSf8JeEvQMoZwQ1ede+zdGiBK4NqJdPcP GrldNzqcROwmUQqYZ5d7/k5Imh3w1LVa0yRv/PpmNp/5uiTalk1AR6cnJXoVQN1Nja40 Z29PFlLihwzxUrX7tCbZSbmHN+7LWbiIBlPiMnoB8QkPVjkLYIjx+fekknPZJpKDMXH2 Ulca72OpS0Hv9sfNRSoopUsFQvAWpY8ROUw/sVOygTUrmD8qKuvtaNI+BpQqc6A96nk4 xidA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8brsJJQmvYoHCp8YhWBHpJBXS/lRsv+EKzHLPe1YzMo=; b=s8OEQv9nLjRJc9nulKBhmjL8/mgjeYdNpXijYz+XCGIWsb9rV6Hmj7dk2AuHmC10yh 7nNFijPp7NnrrLFmphRZMGVz4BK8kIXR82HkGHMq19Bwznwe9WyDunwbEizrbB9FmXyI xGrJ83Ly9Rtqr1S+2jlrZlEQ1yO1V+j4CeSPWN8r3eKqRAx3dCmqLrhg/m0r5aQtf74+ Hr6IlqzALH3FDnOBg9I7pr96S6uOwCnJxTqDNSIDIPBUHBucbdyKGPW/xCVhsFUREgap u5kARRj1wYDTY0jqX+zRY7HIKnHP1T7x6WlDry7XTyQn7y14LWs1ew17qBRhRhdXPRBd Y1yQ== X-Gm-Message-State: AODbwcDoOQxeoWGQp9a8JglO93shXrf2/aLnIpGtdUOOkMfgIDUfPKvm guePySb1+hanNIyxx9S9v4qAXtVCxkx9 X-Received: by 10.129.109.4 with SMTP id i4mr25078138ywc.3.1497261517648; Mon, 12 Jun 2017 02:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 12 Jun 2017 02:57:56 -0700 (PDT) In-Reply-To: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> From: Eric Rescorla Date: Mon, 12 Jun 2017 10:57:56 +0100 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Paul Kyzivat , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd184e5bbe20551c05cf1" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:58:40 -0000 --001a114dd184e5bbe20551c05cf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 12, 2017 at 8:33 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > First, one of the reasons we update specs is because there are usages etc= , > that people weren=E2=80=99t aware of when the original spec was published= , that we > think we need to cover. So, rather than just saying that we don=E2=80=99t= care > about non-comformant endpoints, we should ask WHY they are non-comformant= . > Is there a specific use-case behind? If so, do we need to cover that > use-case? > Yes, and one of the things we have to keep in mind is not breaking conformant endpoints. Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp > is GENERIC - one of the main reasons we do the spec in the first place is > to have the DTLS-related O/A procedures in one place. And, RFC 7345 > (UDPTL-DTLS) DOES allow non-actpass values in the offer: > > "The offerer SHOULD assign the SDP "setup" attribute with a value of > "actpass", unless the offerer insists on being either the sender or > receiver of the DTLS ClientHello message," > > draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and > by mandating actpass we would remove a valid option for UDPTL-DTLS. Sure, > we can do that, but it cannot be based on a claim that existing endpoints > are non-comformant. > > And, I do NOT think we want to allow non-actpass for some usages (e.g., > UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because th= at > would go against the purpose of having generic DTLS O/A procedures. > Well, given that we apparently have incompatible existing RFCs, I'm not sure I see any alternative. -Ekr > Regards, > > Christer > > > From: mmusic on behalf of Eric Rescorla < > ekr@rtfm.com> > Date: Saturday 10 June 2017 at 12:34 > To: Roman Shpount > Cc: Paul Kyzivat , "mmusic@ietf.org" < > mmusic@ietf.org> > Subject: Re: [MMUSIC] actpass redux > > > > On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount wrote: > >> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat >> wrote: >> >>> On 6/9/17 9:17 AM, Cullen Jennings wrote: >>> >>>> >>>> On Jun 8, 2017, at 6:49 PM, Roman Shpount wrote: >>>>> >>>>> Because of this, I think for the best interop, offerer MUST specify >>>>> actpass for both initial and subsequent offers but answerer MUST be a= ble to >>>>> handle active and passive setup roles as well. >>>>> >>>> >>>> that works for me >>>> >>> >>> I don't understand what this accomplishes. If you must be able to accep= t >>> anything in a received offer, then what is gained by restricting what c= an >>> be used in an offer? >>> >> >> This is all because of legacy interop. There are legacy end points that >> send non-actpass, so end point MUST be able to accept active and passive= to >> interop with such legacy devices. >> > > Those legacy endpoints are clearly noncomformant, so I'm not sure I care > about breaking them, > > > >> There are also legacy end points that only expect actass so end point >> MUST only send actpass to interop with such devices. >> > > These legacy endpoints are conformant, which is why it's important to > accommodate them > > -Ekr > > >> _____________ >> Roman Shpount >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --001a114dd184e5bbe20551c05cf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 8:33 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

First, one of the reasons we update specs is because there are usages = etc, that people weren=E2=80=99t aware of when the original spec was publis= hed, that we think we need to cover. So, rather than just saying that we do= n=E2=80=99t care about non-comformant endpoints, we should ask WHY they are non-comformant. Is there a specific use-case be= hind? If so, do we need to cover that use-case?

Yes, and one of the things we have to keep in mind is not = breaking conformant endpoints.


Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-= sdp is GENERIC - one of the main reasons we do the spec in the first place = is to have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDP= TL-DTLS) DOES allow non-actpass values in the offer:

	"The offerer SHOULD assign the SDP "s=
etup" attribute with a value of
   	"actpass", unless the offerer insists on being=
 either the sender or
   	receiver of the DTLS ClientHello message,"
draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, = and by mandating actpass we would remove a valid option for UDPTL-DTLS. Sur= e, we can do that, but it cannot be based on a claim that existing endpoint= s are non-comformant.=C2=A0

And, I do NOT think we want to allow non-actpass for some usages (e.g.= , UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because th= at would go against the purpose of having generic DTLS O/A procedures.

Well, given that we apparently have= incompatible existing RFCs, I'm not sure I see any
alternati= ve.

-Ekr


Regards,

Christer


From: mmusic <mmusic-bounces@ietf.org> = on behalf of Eric Rescorla <ekr@rtfm.com>
Date: Saturday 10 June 2017 at 12:3= 4
To: Roman Shpount <roman@telurix.com>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ie= tf.org" <m= music@ietf.org>
Subject: Re: [MMUSIC] actpass redux=



On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.co= m> wrote:
On= Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
On 6/9/17= 9:17 AM, Cullen Jennings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:

=C2=A0 Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able to= handle active and passive setup roles as well.

that works for me

I don't understand what this accomplishes. If you must be able to accep= t anything in a received offer, then what is gained by restricting what can= be used in an offer?
This is all because of legacy interop. There are legacy end points tha= t send non-actpass, so end point MUST be able to accept active and passive = to interop with such legacy devices.

Those legacy endpoints are clearly noncomformant, so I'm not sure = I care about breaking them,

=C2=A0
There are also legacy end points that only expect actass so end point = MUST only send actpass to interop with such devices.

These legacy endpoints are conformant, which is why it's important= to accommodate them

-Ekr
=C2=A0
__= ___________
Roman Shpount
=C2=A0

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


--001a114dd184e5bbe20551c05cf1-- From nobody Mon Jun 12 04:26:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D3C12E052 for ; Mon, 12 Jun 2017 04:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCSZ6LFGCf6j for ; Mon, 12 Jun 2017 04:26:00 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8F31294FA for ; Mon, 12 Jun 2017 04:25:59 -0700 (PDT) X-AuditID: c1b4fb25-545149a0000046b1-3d-593e7a458760 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 43.32.18097.54A7E395; Mon, 12 Jun 2017 13:25:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Mon, 12 Jun 2017 13:25:56 +0200 From: Christer Holmberg To: Eric Rescorla CC: Roman Shpount , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] actpass redux Thread-Index: AQHS27+QUKTkX8TgukOHH0lDl2aBAKIRu7eAgAA2MQCABCQrAIAFew8AgAAKOICAANEbAIAATywAgAAGUoCAAP6QAIADNvOA///0PgCAAEysgA== Date: Mon, 12 Jun 2017 11:25:55 +0000 Message-ID: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D56454AB1E2C9christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7oq5rlV2kweujGhYrXp9jt5i6/DGL xYMfvWwWMy5MZXZg8Zj8eA6jx5IlP5mArDZmj1tTCgJYorhsUlJzMstSi/TtErgy7kw7zlYw r6riy5cTrA2MDzO6GDk5JARMJCa2LGfpYuTiEBI4wijx5GMbK4SzmFHi985ZzF2MHBxsAhYS 3f+0QRpEBBQkfv05wQJiMwuUSjy43M4MYgsLKEvcnNzADFGjIvGyfSkLhF0ncfPOCXaQMSwC qhI/J3qBhHkFrCV+7t7FBLGqg01i8vRrjCAJToFAiXePJzOB2IwCYhLfT61hgtglLnHryXwm iKMFJJbsOc8MYYtKvHz8jxVkvqiAnsS7/Z4QYSWJHxsuQZ2ZIDHtxU9GiL2CEidnPmGZwCg6 C8nUWUjKZiEpg4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNtaouXidjZkNQsYOVYxihanFifl phsZ66UWZSYXF+fn6eWllmxiBMbqwS2/VXcwXn7jeIhRgINRiYd3c6VdpBBrYllxZe4hRgkO ZiUR3jcVQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoY 3Q7VFKTenhcxd1/JFe0Ehe62OzVPr3Abifyxi5EI9yvWlpnC0/BievOqMhZBJ8GWLtXQri1n jFPyWScoGs+xPy52/9WHHzeMKjnsSnLjlijurYqquHp9+ak+To5VBgqXZO56CnqH5H/M0Ou2 aZGM8dNQeZPo7L03/+eDSy8WvORnfpBzv0OJpTgj0VCLuag4EQBdrnf70QIAAA== Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 11:26:03 -0000 --_000_D56454AB1E2C9christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, First, one of the reasons we update specs is because there are usages etc, = that people weren=92t aware of when the original spec was published, that w= e think we need to cover. So, rather than just saying that we don=92t care = about non-comformant endpoints, we should ask WHY they are non-comformant. = Is there a specific use-case behind? If so, do we need to cover that use-ca= se? Yes, and one of the things we have to keep in mind is not breaking conforma= nt endpoints. "Be conservative in what you send, be liberal in what you accept=94 As far as I understand, we would still mandate endpoints to support receivi= ng non-actpass values. Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp i= s GENERIC - one of the main reasons we do the spec in the first place is to= have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDPTL-DT= LS) DOES allow non-actpass values in the offer: "The offerer SHOULD assign the SDP "setup" attribute with a value o= f "actpass", unless the offerer insists on being either the sender or receiver of the DTLS ClientHello message," draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and b= y mandating actpass we would remove a valid option for UDPTL-DTLS. Sure, we= can do that, but it cannot be based on a claim that existing endpoints are= non-comformant. And, I do NOT think we want to allow non-actpass for some usages (e.g., UDP= TL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because that wo= uld go against the purpose of having generic DTLS O/A procedures. Well, given that we apparently have incompatible existing RFCs, I'm not sur= e I see any alternative. I object to that =96 we basically would have to update the spec every time = there is a new data type, or define the type-specific O/A procedures in a s= eparate spec =96 which is what has been previously been done. I think our aim should be to have generic procedures, even if that means we= have to change procedures some existing RFCs. Regards, Christer From: mmusic > on b= ehalf of Eric Rescorla > Date: Saturday 10 June 2017 at 12:34 To: Roman Shpount > Cc: Paul Kyzivat = >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] actpass redux On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount > wrote: On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat > wrote: On 6/9/17 9:17 AM, Cullen Jennings wrote: On Jun 8, 2017, at 6:49 PM, Roman Shpount > wrote: Because of this, I think for the best interop, offerer MUST specify actpa= ss for both initial and subsequent offers but answerer MUST be able to hand= le active and passive setup roles as well. that works for me I don't understand what this accomplishes. If you must be able to accept an= ything in a received offer, then what is gained by restricting what can be = used in an offer? This is all because of legacy interop. There are legacy end points that sen= d non-actpass, so end point MUST be able to accept active and passive to in= terop with such legacy devices. Those legacy endpoints are clearly noncomformant, so I'm not sure I care ab= out breaking them, There are also legacy end points that only expect actass so end point MUST = only send actpass to interop with such devices. These legacy endpoints are conformant, which is why it's important to accom= modate them -Ekr _____________ Roman Shpount _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D56454AB1E2C9christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5A1C3B773D760243BA877EE8AECC735D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,


First, one of the reasons we update specs is because there are usages = etc, that people weren=92t aware of when the original spec was published, t= hat we think we need to cover. So, rather than just saying that we don=92t = care about non-comformant endpoints, we should ask WHY they are non-comformant. Is there a specific use-case be= hind? If so, do we need to cover that use-case?

Yes, and one of the things we have to keep in mind is not breaking con= formant endpoints.

"Be conservative in what you send, be l= iberal in what you accept=94

As far as I understand, we would still mand= ate endpoints to support receiving non-actpass values.


Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-= sdp is GENERIC - one of the main reasons we do the spec in the first place = is to have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDP= TL-DTLS) DOES allow non-actpass values in the offer:

	"The offerer SHOULD assign the SDP "s=
etup" attribute with a value of
   	"actpass", unless the offerer insists on being=
 either the sender or
   	receiver of the DTLS ClientHello message,"
draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, = and by mandating actpass we would remove a valid option for UDPTL-DTLS. Sur= e, we can do that, but it cannot be based on a claim that existing endpoint= s are non-comformant. 

And, I do NOT think we want to allow non-actpass for some usages (e.g.= , UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because th= at would go against the purpose of having generic DTLS O/A procedures.

Well, given that we appare= ntly have incompatible existing RFCs, I'm not sure I see any alternative.

I object to that =96 we basically would have t= o update the spec every time there is a new data type, or define the type-s= pecific O/A procedures in a separate spec =96 which is what has b= een previously been done.

I think our aim should be to have generic proc= edures, even if that means we have to change procedures some existing RFCs.=

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> = on behalf of Eric Rescorla <ekr@rtfm.com>
Date: Saturday 10 June 2017 at 12:3= 4
To: Roman Shpount <roman@telurix.com>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ie= tf.org" <m= music@ietf.org>
Subject: Re: [MMUSIC] actpass redux=



On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.co= m> wrote:
On= Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
On 6/9/17= 9:17 AM, Cullen Jennings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:

  Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able to= handle active and passive setup roles as well.

that works for me

I don't understand what this accomplishes. If you must be able to accept an= ything in a received offer, then what is gained by restricting what can be = used in an offer?
This is all because of legacy interop. There are legacy end points tha= t send non-actpass, so end point MUST be able to accept active and passive = to interop with such legacy devices.

Those legacy endpoints are clearly noncomformant, so I'm not sure I ca= re about breaking them,

 
There are also legacy end points that only expect actass so end point = MUST only send actpass to interop with such devices.

These legacy endpoints are conformant, which is why it's important to = accommodate them

-Ekr
 
__= ___________
Roman Shpount
 

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


--_000_D56454AB1E2C9christerholmbergericssoncom_-- From nobody Mon Jun 12 05:33:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747D812EAA8 for ; Mon, 12 Jun 2017 05:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7_fAtEe1ifg for ; Mon, 12 Jun 2017 05:33:15 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 CE39512EAAB for ; Mon, 12 Jun 2017 05:33:14 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 4so26426960ybl.1 for ; Mon, 12 Jun 2017 05:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vTD3nTIYUb0DrMmlG+UNwu8Db/2tLQeQtP0/6un8Dug=; b=iy7/tmh3BVXYZc8muMMzyJ1InmSOyBesRislPjiH6o6hfvgEUnxGpDaTUDu3k2wxDH Mn/4DrBMpWO/D3UvvyFgDX+T8NWgQeGtpQbR4ChUDruxQ8TSsNukuZQrkeIzXPV3w9Gj 8Ar1cJ4GJj+GKZsfAYbuqWkesl7SvxfOdYEsvG75zFLRLV9QcsVNUXibvHekSZzKBdzy tsVrPU8JHKVHE/1SvRr1IsyOLVj4cq/Ho3Bftqi7FdfQitvpD0AnU0o2HbZLYsSOj0Ta i6ncbiDCOi6yqjIw6DDEfGD1O91V/umwZL7zr7EuM5tguNnTJYkFhDqfpldwvn3pvoM3 CaAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vTD3nTIYUb0DrMmlG+UNwu8Db/2tLQeQtP0/6un8Dug=; b=pEQnEgLeeyxNyFYxNw52paR7yn969aCjXDE86p5slezIENhBUcHsqQ+nkeWeZg6ecS j4JSqpuQRiQmRyX17uzAPI/StFToxDBE9VyoMoJANHdk7LQQy3JK+Wbl+A1iu6F8NFce 79/+rEtH6mSwr+qgsC3bWmRN2Uj8dZEKtLP4j2mBGurEh06x6QIn0Rg2Sr8bYMbMuU1N 5J+5nyb23+92b6tSdztg4WZe9xljgCxuKzfsvkDsmT3fcF3I4sbmkAkdYkBV+p7pCC4n LtLu5YhrRrGvem2vXcNdeUPKTanDK6JQfwIt4gVCBAVgp7Nh2FOb69VQa78Du8jhMeuR GBLw== X-Gm-Message-State: AODbwcAVxKOK69QKo36zbZjgtTPGiRcy64dOgKaf5iayBM5q2GhdQNP/ LdrBnCoEpQGsiEyUxBEDpSOYb1pFXmse X-Received: by 10.37.44.72 with SMTP id s69mr23556717ybs.89.1497270793904; Mon, 12 Jun 2017 05:33:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 12 Jun 2017 05:32:33 -0700 (PDT) In-Reply-To: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> From: Eric Rescorla Date: Mon, 12 Jun 2017 13:32:33 +0100 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Paul Kyzivat , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a11432adecdba390551c28510" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 12:33:17 -0000 --001a11432adecdba390551c28510 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 12, 2017 at 12:25 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> First, one of the reasons we update specs is because there are usages >> etc, that people weren=E2=80=99t aware of when the original spec was pub= lished, >> that we think we need to cover. So, rather than just saying that we don= =E2=80=99t >> care about non-comformant endpoints, we should ask WHY they are >> non-comformant. Is there a specific use-case behind? If so, do we need t= o >> cover that use-case? >> > > Yes, and one of the things we have to keep in mind is not breaking > conformant endpoints. > > *"Be conservative in what you send, be liberal in what you accept=E2=80= =9D* > https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ As far as I understand, we would still mandate endpoints to support > receiving non-actpass values. > I don't believe that 5763-conformant endpoints are in fact required to do so, and therefore it's not appropriate to break them by allowing people to send actpass in initial offers when offering DTLS-SRTP. -Ekr > > Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp >> is GENERIC - one of the main reasons we do the spec in the first place i= s >> to have the DTLS-related O/A procedures in one place. And, RFC 7345 >> (UDPTL-DTLS) DOES allow non-actpass values in the offer: >> >> "The offerer SHOULD assign the SDP "setup" attribute with a value of >> "actpass", unless the offerer insists on being either the sender or >> receiver of the DTLS ClientHello message," >> >> draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, an= d >> by mandating actpass we would remove a valid option for UDPTL-DTLS. Sure= , >> we can do that, but it cannot be based on a claim that existing endpoint= s >> are non-comformant. >> >> And, I do NOT think we want to allow non-actpass for some usages (e.g., >> UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because t= hat >> would go against the purpose of having generic DTLS O/A procedures. >> > > Well, given that we apparently have incompatible existing RFCs, I'm not > sure I see any alternative. > > I object to that =E2=80=93 we basically would have to update the spec eve= ry time > there is a new data type, or define the type-specific O/A procedures in a > separate spec =E2=80=93 which is what has been previously been done. > > I think our aim should be to have generic procedures, even if that means > we have to change procedures some existing RFCs. > > From: mmusic on behalf of Eric Rescorla < > ekr@rtfm.com> > Date: Saturday 10 June 2017 at 12:34 > To: Roman Shpount > Cc: Paul Kyzivat , "mmusic@ietf.org" < > mmusic@ietf.org> > Subject: Re: [MMUSIC] actpass redux > > > > On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount wrote: > >> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat >> wrote: >> >>> On 6/9/17 9:17 AM, Cullen Jennings wrote: >>> >>>> >>>> On Jun 8, 2017, at 6:49 PM, Roman Shpount wrote: >>>>> >>>>> Because of this, I think for the best interop, offerer MUST specify >>>>> actpass for both initial and subsequent offers but answerer MUST be a= ble to >>>>> handle active and passive setup roles as well. >>>>> >>>> >>>> that works for me >>>> >>> >>> I don't understand what this accomplishes. If you must be able to accep= t >>> anything in a received offer, then what is gained by restricting what c= an >>> be used in an offer? >>> >> >> This is all because of legacy interop. There are legacy end points that >> send non-actpass, so end point MUST be able to accept active and passive= to >> interop with such legacy devices. >> > > Those legacy endpoints are clearly noncomformant, so I'm not sure I care > about breaking them, > > > >> There are also legacy end points that only expect actass so end point >> MUST only send actpass to interop with such devices. >> > > These legacy endpoints are conformant, which is why it's important to > accommodate them > > -Ekr > > >> _____________ >> Roman Shpount >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > > > --001a11432adecdba390551c28510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 12:25 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,


First, one of the reasons we update specs is because there are usages = etc, that people weren=E2=80=99t aware of when the original spec was publis= hed, that we think we need to cover. So, rather than just saying that we do= n=E2=80=99t care about non-comformant endpoints, we should ask WHY they are non-comformant. Is there a specific use-case be= hind? If so, do we need to cover that use-case?

Yes, and one of the things we have to keep in mind is not breaking con= formant endpoints.

"Be conservative in what you send, be liberal in what you accep= t=E2=80=9D




=
As far as I understand, we would still mandate endpoints to support receiv= ing non-actpass values.

I don= 9;t believe that 5763-conformant endpoints are in fact required to do so, a= nd
therefore it's not appropriate to break them by allowing p= eople to send actpass
in initial offers when offering DTLS-SRTP.<= /div>

-Ekr




Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-= sdp is GENERIC - one of the main reasons we do the spec in the first place = is to have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDP= TL-DTLS) DOES allow non-actpass values in the offer:

	"The offerer S=
HOULD assign the SDP "setup" attribute with a value of
   	"actpass", unless =
the offerer insists on being either the sender or
   	receiver of the DTLS ClientH=
ello message,"
draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, = and by mandating actpass we would remove a valid option for UDPTL-DTLS. Sur= e, we can do that, but it cannot be based on a claim that existing endpoint= s are non-comformant.=C2=A0

And, I do NOT think we want to allow non-actpass for some usages (e.g.= , UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because th= at would go against the purpose of having generic DTLS O/A procedures.

Well, given that we apparentl= y have incompatible existing RFCs, I'm not sure I see any alternative.<= /div>

I object to that =E2=80=93 we basically= would have to update the spec every time there is a new data type, or defi= ne the type-specific O/A procedures in a separate spec=C2=A0=E2=80=93=C2=A0= which is what has been previously been done.

I think our aim should be to have generic proc= edures, even if that means we have to change procedures some existing RFCs.=



From: mmusic <mmusic-bounces@ietf.org> = on behalf of Eric Rescorla <ekr@rtfm.com>
Date: Saturday 10 June 2017 at 12:3= 4
To: Roman Shpount <roman@telurix.com>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ie= tf.org" <m= music@ietf.org>
Subject: Re: [MMUSIC] actpass redux=



On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.co= m> wrote:
On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
On 6/9/17 9:17 AM, Cullen Jennings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:

=C2=A0 Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able to= handle active and passive setup roles as well.

that works for me

I don't understand what this accomplishes. If you must be able to accep= t anything in a received offer, then what is gained by restricting what can= be used in an offer?
This is all because of legacy interop. There are legacy end points tha= t send non-actpass, so end point MUST be able to accept active and passive = to interop with such legacy devices.

Those legacy endpoints are clearly noncomformant, so I'm not sure = I care about breaking them,

=C2=A0
There are also legacy end points that only expect actass so end point = MUST only send actpass to interop with such devices.

These legacy endpoints are conformant, which is why it's important= to accommodate them

-Ekr
=C2=A0
_____________
Roman Shpount
=C2=A0

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




--001a11432adecdba390551c28510-- From nobody Mon Jun 12 06:06:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE7126CC4 for ; Mon, 12 Jun 2017 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngGKF12KQvSM for ; Mon, 12 Jun 2017 06:06:13 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EFB127868 for ; Mon, 12 Jun 2017 06:06:01 -0700 (PDT) X-Halon-ID: dfc59824-4f6f-11e7-bcca-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 12 Jun 2017 15:05:56 +0200 (CEST) To: "mmusic (E-mail)" , Henning G Schulzrinne , Gonzalo Camarillo From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 12 Jun 2017 15:05:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [MMUSIC] New SDP grouping semantics proposes to use mid order in group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:06:18 -0000 I have made a draft, proposing four new SDP grouping semantics according to the RFC 5888 framework. https://datatracker.ietf.org/doc/draft-hellstrom-language-grouping/ Two of them propose to use the order that the mid's appear in the group attribute as the order of preference for using media for language contents. I have not seen the order of the mid's be used before. I hope that it is an acceptable semantics detail that can be used within this application. Right? Regards Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se From nobody Mon Jun 12 06:18:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698F0127B52 for ; Mon, 12 Jun 2017 06:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU_aS8Wu42MU for ; Mon, 12 Jun 2017 06:18:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0844A12714F for ; Mon, 12 Jun 2017 06:18:17 -0700 (PDT) X-AuditID: c1b4fb3a-31fff70000004a6a-7b-593e9498d14d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 35.CC.19050.8949E395; Mon, 12 Jun 2017 15:18:16 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0339.000; Mon, 12 Jun 2017 15:18:15 +0200 From: Christer Holmberg To: Eric Rescorla CC: Roman Shpount , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] actpass redux Thread-Index: AQHS27+QUKTkX8TgukOHH0lDl2aBAKIRu7eAgAA2MQCABCQrAIAFew8AgAAKOICAANEbAIAATywAgAAGUoCAAP6QAIADNvOA///0PgCAAEysgP//3oeAgABA9wA= Date: Mon, 12 Jun 2017 13:18:15 +0000 Message-ID: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D56470361E2EDchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7ve6MKXaRBoevC1mseH2O3WLq8scs Fg9+9LJZzLgwldmBxWPy4zmMHkuW/GQCstqYPW5NKQhgieKySUnNySxLLdK3S+DK2NPFWTCt j7Hi6tJfTA2Mu6q6GDk5JARMJGY/+8XWxcjFISRwhFHifuNxFghnMaPEvjm97F2MHBxsAhYS 3f+0QRpEBBQkfv05wQJiMwuUSjy43M4MYgsLKEvcnNzADFGjIvGyfSnYHBGBLkaJmSv6WEES LAKqEn3LlrGB2LwC1hLXD9+G2tzILrHq+XQmkASnQKDEvu8djCA2o4CYxPdTa5ggtolL3Hoy nwnibAGJJXvOM0PYohIvH/9jBTlUVEBP4t1+T4iwokT70wZGiNYEiT1XH7NC7BWUODnzCcsE RtFZSKbOQlI2C0kZRNxA4v25+cwQtrbEsoWvoWx9iY1fzjJC2NYSr9rXsSCrWcDIsYpRtDi1 uDg33chIL7UoM7m4OD9PLy+1ZBMjMF4PbvlttYPx4HPHQ4wCHIxKPLyr+u0ihVgTy4orcw8x SnAwK4nwfpoEFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNT qoFRfW7Sqh4byTX8plOXq/BUBF58KuBS8WCO57ctjCb8R3h+vV+wrOJ9ubC4r45ynMizVPWT Cs620buEryyTKJLRtJi1hWNvtJD3sQ6Bx2VnGHc6XAk7UnVC/V15yLvUIs7JHPuvzuy02jXV uTJ7+beNku+V1K/a7l2h2nzTYabpnY1zl/duDbdSYinOSDTUYi4qTgQAQhQPWtMCAAA= Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:18:20 -0000 --_000_D56470361E2EDchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, First, one of the reasons we update specs is because there are usages etc, = that people weren=92t aware of when the original spec was published, that w= e think we need to cover. So, rather than just saying that we don=92t care = about non-comformant endpoints, we should ask WHY they are non-comformant. = Is there a specific use-case behind? If so, do we need to cover that use-ca= se? Yes, and one of the things we have to keep in mind is not breaking conforma= nt endpoints. "Be conservative in what you send, be liberal in what you accept=94 https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ Expired :) As far as I understand, we would still mandate endpoints to support receivi= ng non-actpass values. I don't believe that 5763-conformant endpoints are in fact required to do s= o, and therefore it's not appropriate to break them by allowing people to send act= pass in initial offers when offering DTLS-SRTP. I assume you mean non-actpass? But, my point was that, AFAIK, the suggestion has been to say that endpoint= s must send actpass, but must support receiving non-actpass. Am I wrong? Regards, Christer Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp i= s GENERIC - one of the main reasons we do the spec in the first place is to= have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDPTL-DT= LS) DOES allow non-actpass values in the offer: "The offerer SHOULD assign the SDP "setup" attribute with a value o= f "actpass", unless the offerer insists on being either the sender or receiver of the DTLS ClientHello message," draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and b= y mandating actpass we would remove a valid option for UDPTL-DTLS. Sure, we= can do that, but it cannot be based on a claim that existing endpoints are= non-comformant. And, I do NOT think we want to allow non-actpass for some usages (e.g., UDP= TL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because that wo= uld go against the purpose of having generic DTLS O/A procedures. Well, given that we apparently have incompatible existing RFCs, I'm not sur= e I see any alternative. I object to that =96 we basically would have to update the spec every time = there is a new data type, or define the type-specific O/A procedures in a s= eparate spec =96 which is what has been previously been done. I think our aim should be to have generic procedures, even if that means we= have to change procedures some existing RFCs. From: mmusic > on b= ehalf of Eric Rescorla > Date: Saturday 10 June 2017 at 12:34 To: Roman Shpount > Cc: Paul Kyzivat = >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] actpass redux On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount > wrote: On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat > wrote: On 6/9/17 9:17 AM, Cullen Jennings wrote: On Jun 8, 2017, at 6:49 PM, Roman Shpount > wrote: Because of this, I think for the best interop, offerer MUST specify actpa= ss for both initial and subsequent offers but answerer MUST be able to hand= le active and passive setup roles as well. that works for me I don't understand what this accomplishes. If you must be able to accept an= ything in a received offer, then what is gained by restricting what can be = used in an offer? This is all because of legacy interop. There are legacy end points that sen= d non-actpass, so end point MUST be able to accept active and passive to in= terop with such legacy devices. Those legacy endpoints are clearly noncomformant, so I'm not sure I care ab= out breaking them, There are also legacy end points that only expect actass so end point MUST = only send actpass to interop with such devices. These legacy endpoints are conformant, which is why it's important to accom= modate them -Ekr _____________ Roman Shpount _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D56470361E2EDchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,



First, one of the reasons we update specs is because there are usages = etc, that people weren=92t aware of when the original spec was published, t= hat we think we need to cover. So, rather than just saying that we don=92t = care about non-comformant endpoints, we should ask WHY they are non-comformant. Is there a specific use-case be= hind? If so, do we need to cover that use-case?

Yes, and one of the things we have to keep in mind is not breaking con= formant endpoints.

= "Be conservative in what you send, be liberal in what you accept=94

Expired :)



As far as I understand, we would still mandate endpoints to support receiv= ing non-actpass values.

I don't believe that 5763-conformant endpoints are in fact required to= do so, and
therefore it's not appropriate to break them by allowing people to sen= d actpass
in initial offers when offering DTLS-SRTP.

I assume you mean non-actpass?

But, my point was that, AFAIK, the suggestion has been to say that end= points must send actpass, but must support receiving non-actpass. Am I wron= g?

Regards,

Christer





Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-= sdp is GENERIC - one of the main reasons we do the spec in the first place = is to have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDP= TL-DTLS) DOES allow non-actpass values in the offer:

	"The offerer S=
HOULD assign the SDP "setup" attribute with a value of
   	"actpass", unless =
the offerer insists on being either the sender or
   	receiver of the DTLS ClientH=
ello message,"
draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, = and by mandating actpass we would remove a valid option for UDPTL-DTLS. Sur= e, we can do that, but it cannot be based on a claim that existing endpoint= s are non-comformant. 

And, I do NOT think we want to allow non-actpass for some usages (e.g.= , UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because th= at would go against the purpose of having generic DTLS O/A procedures.

Well, given that we apparentl= y have incompatible existing RFCs, I'm not sure I see any alternative.

I object to that =96 we basically would have t= o update the spec every time there is a new data type, or define the type-s= pecific O/A procedures in a separate spec =96 which is what has b= een previously been done.

I think our aim should be to have generic proc= edures, even if that means we have to change procedures some existing RFCs.=



From: mmusic <mmusic-bounces@ietf.org> = on behalf of Eric Rescorla <ekr@rtfm.com>
Date: Saturday 10 June 2017 at 12:3= 4
To: Roman Shpount <roman@telurix.com>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ie= tf.org" <m= music@ietf.org>
Subject: Re: [MMUSIC] actpass redux=



On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <roman@telurix.co= m> wrote:
On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <paul.kyzivat@comcast= .net> wrote:
On 6/9/17 9:17 AM, Cullen Jennings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <roman@telurix.com> wrote:

  Because of this, I think for the best interop, offerer MUST specify = actpass for both initial and subsequent offers but answerer MUST be able to= handle active and passive setup roles as well.

that works for me

I don't understand what this accomplishes. If you must be able to accept an= ything in a received offer, then what is gained by restricting what can be = used in an offer?
This is all because of legacy interop. There are legacy end points tha= t send non-actpass, so end point MUST be able to accept active and passive = to interop with such legacy devices.

Those legacy endpoints are clearly noncomformant, so I'm not sure I ca= re about breaking them,

 
There are also legacy end points that only expect actass so end point = MUST only send actpass to interop with such devices.

These legacy endpoints are conformant, which is why it's important to = accommodate them

-Ekr
 
_____________
Roman Shpount
 

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




--_000_D56470361E2EDchristerholmbergericssoncom_-- From nobody Mon Jun 12 06:21:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D77127B52 for ; Mon, 12 Jun 2017 06:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eelMxp_Ih4wX for ; Mon, 12 Jun 2017 06:21:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDA0127869 for ; Mon, 12 Jun 2017 06:21:10 -0700 (PDT) X-AuditID: c1b4fb30-491ff70000003fda-2a-593e954379b5 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.47.16346.3459E395; Mon, 12 Jun 2017 15:21:08 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0339.000; Mon, 12 Jun 2017 15:21:07 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "mmusic (E-mail)" , Henning G Schulzrinne , Gonzalo Camarillo Thread-Topic: [MMUSIC] New SDP grouping semantics proposes to use mid order in group Thread-Index: AQHS43yxJl/iJ0ErEUG6yzUKCI/mtKIhSTCA Date: Mon, 12 Jun 2017 13:21:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <332EECEAB7B89D4E9C9A1606676DEEE7@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7oK7LVLtIg2szdS12vD/DYnGlbyWT xdTlj1kcmD2+3jrI5LFkyU8mj4mLPzEHMEdx2aSk5mSWpRbp2yVwZXS29zIV7GKuOPinn6mB 8R5TFyMnh4SAicSbh7MYuxi5OIQEjjBKbDw2lQnCWcwosfLGYbYuRg4ONgELie5/2iANIgLn GSV+z+YBCQsLhEocX58LEQ6TONeyhwnCNpLYNvc2K4jNIqAq8brvHCOIzStgLbHv6TawGiEB W4lVZ7vBbE4BO4mD186wgdiMAmIS30+tAYszC4hL3HoyH+pOAYkle84zQ9iiEi8f/2MFOUFU QE/i3X5PiLCixNXpy6Fa9SRuTJ3CBmFbS7w9c4sRwtaWWLbwNTPEOYISJ2c+YZnAKDYLybZZ SNpnIWmfhaR9FpL2BYysqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+zglt8GOxhfPnc8 xCjAwajEw9s1wS5SiDWxrLgy9xCjBAezkgjvp0lAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryO +y5ECAmkJ5akZqemFqQWwWSZODilGhg3b5rlUhMg/tfbSdw9gc9LqDmKy13q2hWjh/zlm28K 3vz5acsNRd1nxr8jlE+9Zf1suvZsbNnSGU4bD/HVqDvy17bL6sX9jOTwbuy34gnYrXJj+eva 2y3W17Y0BcUof57xqiI/f1WQmp9h0eZ9qz8dunnv23LDedd2rnYruRDooTzte9Ot3CYlluKM REMt5qLiRACpAK+irwIAAA== Archived-At: Subject: Re: [MMUSIC] New SDP grouping semantics proposes to use mid order in group X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:21:12 -0000 Hi, >I have made a draft, proposing four new SDP grouping semantics according >to the RFC 5888 framework. > >https://datatracker.ietf.org/doc/draft-hellstrom-language-grouping/ > >Two of them propose to use the order that the mid's appear in the group >attribute as the order of preference for using media for language >contents. > >I have not seen the order of the mid's be used before. BUNDLE. Regards, Christer From nobody Mon Jun 12 06:30:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB512EAE9 for ; Mon, 12 Jun 2017 06:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6il-QYHGYpE for ; Mon, 12 Jun 2017 06:29:58 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 DF71012EAC6 for ; Mon, 12 Jun 2017 06:29:55 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id p189so50971487lfe.2 for ; Mon, 12 Jun 2017 06:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sFJw7rFIB6R/JswyT1NDGbqECVccB65w23KQt6UucDc=; b=Me8syHDaxYrTVakr3VK8sljVNrInsRoMEQqg99y3k7iEULe4IzztQObLxdf7ECjUHA +89G3YjdvnoCxl7s9ADPeAhB5sfZzxzxThZ6dNHFCNXMFhhC37OAWguQfDB86Z59ym8+ pDkr0LyDHtLGlYkniHYM+3raQsImjjYHzfjheV/1pTtP/yvosECd/C3A+T60lb+K+haj Ak0H9S48/zHX/KWXMBHIzp9aAAtPyN4e+d3bF9I8/HCau3yxwlN+vORCZxNwgJbIrSZf ztw+gJgGWewgWjFXs2PP4yIhsI5sZWvNYFJPLdllmvK8AHeZNGhcIoGXSb4obLNsY3F4 yKTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sFJw7rFIB6R/JswyT1NDGbqECVccB65w23KQt6UucDc=; b=s+o59/cHfHjrvSn9uZMysZB/hHlRfX/jCEKsf37EIkRvrKk+7Ru3DVBn9yUprG4bcw IBL9vZNIm8GjO5HLqIYAsqNpgXlIluh28Smzft6XoXBfUOpIadcevDFToU+3ygRFqgHz Wwn0NtBIVcJOMim7xhDsAsqnWxArUn9FNuWmdnA+Qcrc5JHabpEluiySC8nH02ix27xY kiXmRwGqAkFi6IcH5+iU1gltuI+Y2tWy/Hx9Aw/KJlAIRnHiHIndJvRXYDGlB3FZ9Fph v+AFR5DjyAWKY3uIuRDPx1/2ZmOvJlCX+rarmNMjtB5/9k9ap6Yaq2v1Kc9bL/LBPxnO ssOg== X-Gm-Message-State: AKS2vOxiWp8yu3U8wjhcO/4pi7/Y1qArC/VyTG4UjvrPSa+KGLDFe0wl BvVgmBO9YSDo2Ccv4Y0pwQ/v41FyXg== X-Received: by 10.25.196.17 with SMTP id u17mr1461757lff.19.1497274194115; Mon, 12 Jun 2017 06:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Mon, 12 Jun 2017 06:29:53 -0700 (PDT) In-Reply-To: References: <6355EA0B-2C28-4D47-9600-F64F898BFC86@iii.ca> <14ED932A-FCC7-4C4A-93BB-627A4E55F552@iii.ca> From: Martin Thomson Date: Mon, 12 Jun 2017 14:29:53 +0100 Message-ID: To: Christer Holmberg Cc: Eric Rescorla , Paul Kyzivat , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:30:00 -0000 On 12 June 2017 at 14:18, Christer Holmberg wrote: > https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ > > Expired :) Bug fixed. Thanks for the reminder. From nobody Tue Jun 13 10:08:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E12129410 for ; Tue, 13 Jun 2017 10:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ4fAGJ_llye for ; Tue, 13 Jun 2017 10:08:52 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AFE131901 for ; Tue, 13 Jun 2017 10:08:52 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id v104so143870342wrb.0 for ; Tue, 13 Jun 2017 10:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b925fa/ljfOxY2sy7nXCfpniUF6dFhsnizoy3rjdX9s=; b=HoPUwP/qinRaabexW1PenHhHniZZ45x1NBHoHsfyC0RLGmCULTQ58kAmXLmSQqSasQ O6c8VPXCzF86tfsSw9J6lDkPotJTxu+Np42y8ZDtzEsrLHoDnetwBac7jxaJyw7Htt46 bLNuNXSA3fqM1yT/9lJigeEC9hexRpx0C/FX1C1wccduRXginDZ4tKOy0uyKQEqGWuw2 KmJwYsEQ2telK3ato+6vf8l2lYQdDv1Ur9gnfYIaV424ipngZE1i4PbCsw4rC9imPVd0 uDeuojY1GNeCOehoq19mhKSGzts0Q9x2tXjHVqkOkmZ05Spwv5SQKF1lIKXKryqz/cxS FuqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=b925fa/ljfOxY2sy7nXCfpniUF6dFhsnizoy3rjdX9s=; b=CtUWRAbp3O9gLE6WQXyFXJfUL1yeOsQn+RA3z1gOlqvxu8/m4hLW/zUUAldW9r2O+e DlPEQCIUIe4XrAZ4c3eR0kA3OQFdwey/YE2yyX3ndO6XCRjFkZc51o8qORI6R2ExSrt/ zjY1owPcpr5lctyUFqYHE1Cq7ckBqZk7nGG26PQ8GjB5I6qonj174De9DvwGMiJNDAhr MMiAQaUg9dxgRRSnivJoWnoKSIYfNOjmriyNEP+9+R+0GUwgMEsFOsP3fqRa8NnwU912 FaPYZ5MhHyYg745Ds2RNqu4hXnfHE3O+totCJP9vI4aXy8UG93lKIRz3GaEK6tdHUhd4 atUQ== X-Gm-Message-State: AKS2vOybQXUlbFXjC3G+0H1HYY1VoBa7cY+BOJXZbcRVU76giiu1dYSw RqOcW43Nfxc8+ubP+h4ACw19t60obBR5PvHE6Q== X-Received: by 10.80.214.25 with SMTP id x25mr702450edi.13.1497373728812; Tue, 13 Jun 2017 10:08:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Tue, 13 Jun 2017 10:08:28 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 13 Jun 2017 19:08:28 +0200 Message-ID: To: Roman Shpount Cc: Eric Rescorla , mmusic WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:08:55 -0000 2017-06-02 20:02 GMT+02:00 Roman Shpount : > There was a discussion regarding the setup attribute value in subsequent > offers when establishing new DTLS association is not desired Hi, I've silently read all this thread. In fact I already participated in this exact subject in some threads in the past (so long ago). But it seems that problems in SDP persist forever. I think it's time to expel SDP from our lives, specially in WebRTC where we, the developers, can do media signaling much better than the SDP-way. All this kinds of problems are because a full SDP blob must be generated and consumed by the remote party for *every* minor change in the multimedia session. So, if I want to add a video stream on top of the same ICE+DTLS transport, or if I want to pause it, or remove it, or whatever, I must send a full SDP and the remote peer must figure out whether such a SDP involves a ICE change, DTLS change, streams change, codecs change, etc etc. This means a "full re-inspection" of all the parameters (ICE, DTLS, RTP, RTCP, etc) for every SDP O/A renegotiation. When SDP was about simple bidirectional audio it was just fine. But nowadays SDP is unsustainable. Now we have a draft that defines a new a=3Dtls-id attribute to avoid DTLS re-handshake on a SDP O/A renegotiation. That's a hack IMHO. We may also invent a new a=3Dice-id to avoid inspecting remote ICE ufrag/passwd/candidates every time a multimedia session change is desired. And also a=3Dm-id attribute (per media section) so the receiver figures out whether something has changed in such a media section or not, etc. Ah, and we have BUNDLE so the "transport" is just defined in the first media section (or the first *active* one, who knows?). 1) Transport =3D> UDP or TCP or ICE 2) Security =3D> DTLS or SRTP 3) Media =3D> Parameters for independent send/recv media streams That's all we need, nothing else: a clear layers separation so we can signal each layer parameters independently. Yes, that's similar to what ORTC provides, which is far from perfect, but it becomes much more comfortable to work with. IMHO it's really sad that WebRTC 1.0 has been polluted with this legacy "media signaling" mechanism. WebRTC was born so many years ago and, in 2017 with spec 1.0.0 about to be released, we still have spec and implementation problems when it comes to "renegotiate" something in the session because the remote may attempt a new DTLS handshake... just LoL. I do know that my complain is slightly off-topic given that this is MMUSIC, which is supposed to be 100% SDP related. But I wonder why the MMUSIC WG is still 100% tiled to SDP rather than just defining multimedia related parameters as it should (IMHO). The longer this WG defines multimedia stuff for just SDP, the longer the developers will suffer the SDP re-negotiation and its inherited "full re-inspection". I'm sorry for this email, but I just can not bear to see so many bright minds wasting so much time due to a single SDP line whose value may have to be different on each re-O/A (depending on who the re-offerer is) to just keep the underlying transport untouched ("actpass =3D=3D> active", "passive <=3D=3D actpass"). Having to change thi= ngs to change nothing seems surrealist. Regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 13 11:23:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC112943E for ; Tue, 13 Jun 2017 11:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1O3cR_rzK8g for ; Tue, 13 Jun 2017 11:23:05 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B17D124BE8 for ; Tue, 13 Jun 2017 11:23:05 -0700 (PDT) X-AuditID: c1b4fb30-4a9ff70000003fda-1d-59402d867910 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.C9.16346.68D20495; Tue, 13 Jun 2017 20:23:03 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Tue, 13 Jun 2017 20:23:02 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount CC: mmusic WG Thread-Topic: [MMUSIC] actpass redux Thread-Index: AQHS27+QUKTkX8TgukOHH0lDl2aBAKIRu7eAgBE6nACAADV8UA== Date: Tue, 13 Jun 2017 18:23:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBEAD3D@ESESSMB109.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdWrdd1yHSYMJ6FYvp+2wspi5/zGIx 48JUZgdmj3MN79k9liz5yeRxa0pBAHMUl01Kak5mWWqRvl0CV8bpnyuZClYwVUx9PI2xgXEB UxcjJ4eEgInE1oWT2LoYuTiEBI4wSjz8vYUNJCEksJhRYuZ1oCIODjYBC4nuf9ogYRGBRIkl M2ezg9jMAvISF5asAZsjLKAssf95FyNEjYrEy/alLBC2k8SG9VPAbBYBVYmFh2+CjecV8JWY 82A9K8Tee4wSj+a/BWvmFAiU2PbrGFgDo4CYxPdTEAuYBcQlbj2ZD3W0gMSSPeeZIWxRiZeP /7FC2EoSi25/BruZWUBTYv0ufYhWRYkp3Q/ZIfYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJG llWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgTFzcMtvgx2ML587HmIU4GBU4uGdLugQKcSa WFZcmXuIUYKDWUmEd40yUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6YklqdmpqQWp RTBZJg5OqQbGjryWRr8N7R3tMT+3xD6xUZi6qzxqbtqfaVNj/3ipKGnriRv6MW9KZMvxnHU+ yk/z9pHG+iO+jxMZr9YFbj+pdcHwTH3ZD057SVbZ6vmJ7/S/KFpfPsq5PaWrUvTuXbeEkgLV 87Unbir6yry9k1W4sctERvCeps7d1PlSDxfK2Hy6sHBu1SolluKMREMt5qLiRACMNd7qlQIA AA== Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 18:23:07 -0000 SGksDQoNCkkgZG9uJ3QgbmVjZXNzYXJpbHkgZGlzYWdyZWUgd2l0aCB5b3UsIGFuZCBJIGRvbid0 IGtub3cgaWYgeW91ciBlLW1haWwgaXMgb2ZmLXRvcGljIGZvciBNTVVTSUMsIGJ1dCBpdCBmb3Ig c3VyZSBJUyBvZmYtdG9waWMgZm9yIFRISVMgdGhyZWFkLCBhbmQgdGhlIGRyYWZ0L2NoYXJ0ZXIg aXRlbSBkaXNjdXNzZWQgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Tue Jun 13 13:34:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D8E129C4A for ; Tue, 13 Jun 2017 13:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFjBYv2Teoxw for ; Tue, 13 Jun 2017 13:33:59 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id D3F78129AC7 for ; Tue, 13 Jun 2017 13:33:58 -0700 (PDT) X-AuditID: 12074413-d93ff7000000742e-d3-59404c33b009 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 59.DE.29742.33C40495; Tue, 13 Jun 2017 16:33:56 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v5DKXsGQ018884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Jun 2017 16:33:55 -0400 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: <402e9b86-e28f-e2ab-d3b3-2f34e9dd0bff@alum.mit.edu> Date: Tue, 13 Jun 2017 16:33:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqGvi4xBp8GC/msXU5Y9ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseaaVMF+5YrJ938wNjDOl+li5OSQEDCR2PnnK0sXIxeHkMAO Joknn/8zQjivmSTurdzPBFIlLGAkcen0NBYQW0RAWGLG279sEEX3GCUezX/LCJJgE9CSmHPo P1gRr4A9UMMSZhCbRUBV4ub9VjYQW1QgTeLPpRvMEDWCEidnPgGr5xQIlNj26xiYzSxgJjFv 80NmCFtc4taT+UwQtrxE89bZzBMY+WchaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3W LU5OzMtLLdI118vNLNFLTSndxAgJS+EdjLtOyh1iFOBgVOLhffDePlKINbGsuDL3EKMkB5OS KO8SO4dIIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8hzyAcrwpiZVVqUX5MClpDhYlcV61Jep+ QgLpiSWp2ampBalFMFkZDg4lCd6pXkCNgkWp6akVaZk5JQhpJg5OkOE8QMMngyzmLS5IzC3O TIfIn2LU5fg1c+sXJiGWvPy8VClxXilvoCIBkKKM0jy4ObB08opRHOgtYV4RkCoeYCqCm/QK aAkT0JLrV2xAlpQkIqSkGhhrIlZNPr/57Cv2iqL26wkrbWznrmxeYbyL8ZnS8+0cot+Utmpv 8ZjIeLZiTv/P9SbNH97eLDz3tGbZtYqeu88OyM8vf3ip+Pm+0NKLJgsDr4eFK4YzvtXd/Fau x5jzJtPafcnuR5/8W3FCu3+PyuqT906t7GJVDc6Tf8765WBFdoXrUR1VlfIsJZbijERDLeai 4kQApArMsQIDAAA= Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:34:01 -0000 Iñaki, [Changing the subject, since it was *very* off-topic.] I've added my comments at the end. On 6/13/17 1:08 PM, Iñaki Baz Castillo wrote: > 2017-06-02 20:02 GMT+02:00 Roman Shpount : >> There was a discussion regarding the setup attribute value in subsequent >> offers when establishing new DTLS association is not desired > > Hi, I've silently read all this thread. In fact I already participated > in this exact subject in some threads in the past (so long ago). But > it seems that problems in SDP persist forever. > > I think it's time to expel SDP from our lives, specially in WebRTC > where we, the developers, can do media signaling much better than the > SDP-way. > > All this kinds of problems are because a full SDP blob must be > generated and consumed by the remote party for *every* minor change in > the multimedia session. So, if I want to add a video stream on top of > the same ICE+DTLS transport, or if I want to pause it, or remove it, > or whatever, I must send a full SDP and the remote peer must figure > out whether such a SDP involves a ICE change, DTLS change, streams > change, codecs change, etc etc. This means a "full re-inspection" of > all the parameters (ICE, DTLS, RTP, RTCP, etc) for every SDP O/A > renegotiation. > > When SDP was about simple bidirectional audio it was just fine. But > nowadays SDP is unsustainable. > > Now we have a draft that defines a new a=tls-id attribute to avoid > DTLS re-handshake on a SDP O/A renegotiation. That's a hack IMHO. We > may also invent a new a=ice-id to avoid inspecting remote ICE > ufrag/passwd/candidates every time a multimedia session change is > desired. And also a=m-id attribute (per media section) so the receiver > figures out whether something has changed in such a media section or > not, etc. Ah, and we have BUNDLE so the "transport" is just defined in > the first media section (or the first *active* one, who knows?). > > 1) Transport => UDP or TCP or ICE > 2) Security => DTLS or SRTP > 3) Media => Parameters for independent send/recv media streams > > That's all we need, nothing else: a clear layers separation so we can > signal each layer parameters independently. Yes, that's similar to > what ORTC provides, which is far from perfect, but it becomes much > more comfortable to work with. > > IMHO it's really sad that WebRTC 1.0 has been polluted with this > legacy "media signaling" mechanism. WebRTC was born so many years ago > and, in 2017 with spec 1.0.0 about to be released, we still have spec > and implementation problems when it comes to "renegotiate" something > in the session because the remote may attempt a new DTLS handshake... > just LoL. > > I do know that my complain is slightly off-topic given that this is > MMUSIC, which is supposed to be 100% SDP related. But I wonder why the > MMUSIC WG is still 100% tiled to SDP rather than just defining > multimedia related parameters as it should (IMHO). The longer this WG > defines multimedia stuff for just SDP, the longer the developers will > suffer the SDP re-negotiation and its inherited "full re-inspection". Everybody who has worked with SDP realizes that it is ill-suited to the tasks we use it for. Quite a long time ago there was an effort called SDPng that tried to define a new syntax. I wasn't involved in that, but it seemed like it was defining something reasonable (XML based IIRC). But it failed because (IIUC) nobody could see a viable migration plan to introduce it. I think you are suggesting to do something new but limit its scope to WebRTC. Such a narrow scope would ease the migration effort. There would still be one but perhaps people would be willing to suffer through it. BUT, WebRTC doesn't stand alone. Interworking with SIP is still important, and probably will be for a long time. Also, your description of what is needed is simplistic. What features (functionality, not syntax) of SDP O/A are not needed with WebRTC? AFAICT all the stuff that describes codecs is needed, and much of the rest. There is a lot of that, spread over many RFCs. All of that would have to be re-done. Doing something new here may well be the right thing to do. But the first step is to carefully define the scope of applicability, and what interworking requirements there are with things outside that scope. Then perhaps the size of the effort can be estimated and the feasibility doing so assessed. Thanks, Paul From nobody Tue Jun 13 14:18:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFAF131101 for ; Tue, 13 Jun 2017 14:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUdqsiXi6fnw for ; Tue, 13 Jun 2017 14:18:05 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 8953712EB3F for ; Tue, 13 Jun 2017 14:18:05 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id q97so161796509wrb.2 for ; Tue, 13 Jun 2017 14:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h9BKN6ui6QIVC5a42ub99wr/F/h9Dqq0582UAU4c2d4=; b=h1o3D9yXUenWE+6RiqROYdcA43Vo2Kle5gQ0fHnr0r1wA2lZSNY6V4LF05xMkEObd8 PfYuq3tBb+/OYX9gqmtAMBnlZh/YrTOUQ1VqNrHBarXOfAPtqTao8iwMS/zuUMab7X1I nUh/d/fdA9wohySs5uM3cpn1yXsR3pT5U8byvmj1yfgPJqY4g+iWf5G5ybdcuTT5JCXb pzLwSmQTQmQ9EpkyZleRWjBfEUN9VYXq4W69t/wfv3S/AmJNKHxr2nMWyg1pX7BaKaKg CeMWYz0MkHMVuk7S8eYgEcnsFy9ezZ/VrCUy6JWbyJFfhX3VKSHZo69IZOE+a6IJwD3y Mu+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=h9BKN6ui6QIVC5a42ub99wr/F/h9Dqq0582UAU4c2d4=; b=YGW+NbXNJ5mWBKMkpDiX/1ke61MAMW/UxZGeYtI31QP2PFhOKTIRNArPd/zWFkQitz V5tx7Rw674cM0OEkmG6ShaN2S41eYbsN9I5GHhZj365jk3dwbtwCtK2KBN0AJStewuV5 9oxft1MKMvs/BnbOzeRZEkzfc1TlTWkPpEECo2rFEOzPlZU36p+oZPSNUo7IQS1yvTJA yp3rSAQDjQmxY2mzb8mAS8wR9z8VwmrmBoLoSv3PRZlPaswAP0phxgPMhpssF4+wWEDf cPrgPXOEir+iZ4b6RlwYzc9EovLHACzd27J1e9fWTvEi4ccNmRfli2RQZJcYhua5KtQB BHGw== X-Gm-Message-State: AKS2vOxJNFtSchE6z+qwmlPXrB/FclVyTWHVE+0QmFdEBve0Qlb90sg4 lz0qgL/kiDokjDUuu4GdwPZSYqTxViSS X-Received: by 10.80.147.226 with SMTP id o89mr1397842eda.112.1497388684093; Tue, 13 Jun 2017 14:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Tue, 13 Jun 2017 14:17:43 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBEAD3D@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CBEAD3D@ESESSMB109.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 13 Jun 2017 23:17:43 +0200 Message-ID: To: Christer Holmberg Cc: Roman Shpount , mmusic WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] actpass redux X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 21:18:08 -0000 2017-06-13 20:23 GMT+02:00 Christer Holmberg : > I don't necessarily disagree with you, and I don't know if your e-mail is= off-topic for MMUSIC, but it for sure IS off-topic for THIS thread, and th= e draft/charter item discussed :) Hi Christer, Probably you are right, and sorry for that. Being honest, I started writing a very different email exposing my experience with the issue being discussed in the thread. It said something as follows: I've seen the "SDP DTLS role conflict" in many implementations. AFAIR older versions of Firefox and Asterisk wrote, in a re-offer, an a=3Dsetup attribute with the effective value (active or passive) as negotiated during the initial O/A, which breaks the RFC because it MUST be "actpass", so Chrome complained. I've also seen (and reported) that FreeSwitch changes its DTLS a=3Dsetup role during a re-negotiation, but the funny thing here is that it was just a cosmetic change in the SDP (internally FreeSwitch wants to keep the initially negotiated DTLS connection regardless what it actually writes in the re-offer): https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-10258/FS-10258= .html But after writing it, I've realized that if it's so complex for existing implementations to deal with this specification rule (still in 2017) changing the spec or creating a new one won't help much (at least in the short term), so I got really frustrated and ended sending my original text. Regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 13 14:46:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE00128C81 for ; Tue, 13 Jun 2017 14:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjWp5HhzYjqB for ; Tue, 13 Jun 2017 14:46:11 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 35F6B127077 for ; Tue, 13 Jun 2017 14:46:11 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id v104so152983612wrb.0 for ; Tue, 13 Jun 2017 14:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=opQa9z9IiLctlPhB2ZE4TN1MYTZJlmGQLxCD3s2gf0w=; b=UaSfYcH1gfimdsMGv8e1WQl6wqlbil6lqpq0o1vRHkWJq0YiILsSTuypgl8sUiUfcy 1Y72zcn8YhM5vFd5+B5m2puzAfS/qlHx04ZBWAsDOJTZhXd2rvpc4azQAOEIXEmUA38C fLrjMDz6fPjX8qYGro8kBYEyLwCm7s2NbybsCx8ogeZv3p09JJk9htAz8meQXtGzqIdw U8QkfptBURbNIzqlNuO/A5Wb2wEssL99UZeHUvrdfLh96q3hPV/U+QgbRtzfcgTxtyIY NL+Swvb2KrSQYpUaQig2xoP7wUIoWkdM+MVoaTyqN5rUhzFIb/04K9u362UKRB2DrIvr W+GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=opQa9z9IiLctlPhB2ZE4TN1MYTZJlmGQLxCD3s2gf0w=; b=pvPoCE2KsB8NfiDiyRL5gTyS8tgAsjT3oiCBtfv6rj+ypcZWPBJ4hUXV90oDOi41QF MV/ut+zIDVIIOKQ/ra3AYovt2EbvluGaeALZxnbS33dgZXiU/KNW00u26VMp3tzQ7H6e Ak4dtdU+K/X9BG0Y9GbYIM3N5oBdlpqDB1nMwF9GIyyDtMIfUjUT7CKRvn+41BnXhILI 7P1IYRubtysv1UDr3QEeR3lpzGT2VD4JRYpO0jHAS/3dku/X+Ou7FatQNcFSNDZy08Oq cHAcw2BVgRDeIGFfPNCRKEcSjv7S8fnEPADFFxCSq1MUHaoEcADhFG6qF0XVOatMrjek td0A== X-Gm-Message-State: AKS2vOz7UrWcXVhRKXCaXP3SRuFwO3kbiygWrRV2wOpyeFPQNpnkJ/ge Yg3oLYATZIXc9Y/h8808UYmy3Ctq2tmJ X-Received: by 10.80.206.22 with SMTP id y22mr1452903edi.20.1497390369648; Tue, 13 Jun 2017 14:46:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Tue, 13 Jun 2017 14:45:49 -0700 (PDT) In-Reply-To: <402e9b86-e28f-e2ab-d3b3-2f34e9dd0bff@alum.mit.edu> References: <402e9b86-e28f-e2ab-d3b3-2f34e9dd0bff@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 13 Jun 2017 23:45:49 +0200 Message-ID: To: Paul Kyzivat Cc: "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 21:46:14 -0000 2017-06-13 22:33 GMT+02:00 Paul Kyzivat : > Everybody who has worked with SDP realizes that it is ill-suited to the > tasks we use it for. Quite a long time ago there was an effort called SDP= ng > that tried to define a new syntax. I wasn't involved in that, but it seem= ed > like it was defining something reasonable (XML based IIRC). But it failed > because (IIUC) nobody could see a viable migration plan to introduce it. > > I think you are suggesting to do something new but limit its scope to > WebRTC. Such a narrow scope would ease the migration effort. There would > still be one but perhaps people would be willing to suffer through it. > > BUT, WebRTC doesn't stand alone. Interworking with SIP is still important= , > and probably will be for a long time. Also, your description of what is > needed is simplistic. What features (functionality, not syntax) of SDP O/= A > are not needed with WebRTC? AFAICT all the stuff that describes codecs is > needed, and much of the rest. There is a lot of that, spread over many RF= Cs. > All of that would have to be re-done. > > Doing something new here may well be the right thing to do. But the first > step is to carefully define the scope of applicability, and what > interworking requirements there are with things outside that scope. Then > perhaps the size of the effort can be estimated and the feasibility doing= so > assessed. Hi Paul, I'm not asking for a SDP 2.0 in JSON/XML or any other format. In your text above, you state that "all the stuff that describes codecs is needed, and much of the rest", and I don't agree with that: ORTC has proven to provide the *same* functionality as SDP, but without imposing the exchange of a full SDP blob/string. Yes, codec parameters must be exchanged between peers, but that does not mean that a SDP (or similar format) is required. Instead, in ORTC, it's up to the application/developer to decide how to signal parameters between the endpoints of a multimedia session. In ORTC an endpoint can signal ICE parameters, DTLS parameters, RTP parameters, and other parameters in an independent way (so, if for example a new video stream is added, there is no need to signal all the ICE/DTLS stuff to the remote party again, but just the RTP parameters related to the new stream). This design prevents issues such as the "SDP DTLS role conflict" described in the previous email thread. You say "There is a lot of that, spread over many RFCs". And that's true, but ORTC specification [*] collects many of those parameters and re-uses them within their own Dictionaries about ICE, DTLS, RTP, RTCP, etc. It's true that there are tons of RFC's that define multimedia parameters assuming SDP syntax, but IMHO the SDP-ish is just a minor component in those specifications, nothing too hard to circumvent IHMO (in fact, ORTC did it). > I think you are suggesting to do something new but limit its scope to We= bRTC Not exactly. Continue reading, please. > WebRTC doesn't stand alone. Interworking with SIP is still important Sure, and I understand that SIP indeed requires a wire-signaling format/syntax because SIP requires interoperability between different devices in both, the signaling and media, planes. But IMHO that does not justify the fact that all the multimedia related specifications are tiled to just SDP. SDP should not be the minimum irreducible unit for exchanging multimedia information, and ORTC is a good example of the opposite. What I would expect nowadays from the MMUSIC WG is to define multimedia parameters (including different *layers" such as transport, security/encryption, RTP, RTCP, etc) rather than a single format(SDP) to cover them all. Having that, WebRTC could perfectly drop SDP and define some proper Dictionaries (as ORTC) pointing to those parameters defined by MMUSIC so WebRTC developers are done and free to exchange data as they wish. And when it comes to SIP, of course the SIP protocol needs a "multimedia format". A separate WG or a different task within MMUSIC could be responsible of producing an standardized "multimedia format" for SIP with those parameters, let it be SDP or SDP 2.0. Anyhow, if so many things within the SDP are so problematic for WebRTC, they will also be problematic for SIP (once SIP devices implement so many advanced features such as those in WebRTC devices), so still I consider that sending a full SDP to just renegotiate a new codec (or remove a specific video stream) will produce real problems as we suffer in WebRTC. But again, this is a separate concern that should just affect to SIP devices (because SIP chose to go with SDP), and not to WebRTC. Thanks a lot for your response, regards. [*] http://draft.ortc.org/ --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 13 16:33:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6E127241 for ; Tue, 13 Jun 2017 16:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COGN4zVyeOjM for ; Tue, 13 Jun 2017 16:33:04 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956661205D3 for ; Tue, 13 Jun 2017 16:33:04 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id 191so72442011vko.2 for ; Tue, 13 Jun 2017 16:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TSY/u96tJjc+Zd9OXc1j5XYkqVH2kMaLT+Ewmo3aoNA=; b=KXf9KrUNSiSHRBNQx6AWBeLEjy0E24gW+rrAhsEcdmC4P5sQ9Ezh+6iFoWpSUc+0jw tRz0U7shj9U/G3mmlFh9lHBSVIPQn86oLCJadKtg4k+YbKoi8dsxbnpaZLpX04fKFuXl l4mswEYQVbVhWlzJeHFGXZJZ5FapNVmSLK6rKIA3UXLnS/6pQFWsgMGQlzGq0TfFr8qv 078dKvP3EhnBIE9SkrAy8AlD8Uk8VidHjGUqUvmvP+oLwHCTlDO3LEIpBWn3seiK9UmA /TDywoeOZ0VsLVhfFgGR/5Ul0tcdcCPmcJrOo37yVw9CE65QGGeZltRs1NEFFRycEZzb lTgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TSY/u96tJjc+Zd9OXc1j5XYkqVH2kMaLT+Ewmo3aoNA=; b=p5IQQ8RrcdDc+qQX83kTRNEZlpQ3H0to38YY1FR0SJtQqsrlloCT3p6jg2BHM9G69L ee7pQIOslSK/ERGCfzZtqveNM+REz0S/3VBkBSnOkHAXgP6P7nt6HJPy/NvT1evm1maD D2C/488RIa9hmj7TLEYU8oG7/a9DNL9m55uyapWhBpqxtq58jl30ZzQB/WNpvxNvaERV Arfi8AbYAux9wcNautTUwcSC47pgImK58qOy+/owTAdJPJalMKFxFm7OeK7jbn4/Y2RV xGOI1tIQuAc/QERBYT0ven1lBs8UBwGZiRqpwhIJ1RvtwHDAOTICBhi5mXtIr64Sl2og 5HQA== X-Gm-Message-State: AKS2vOwmaKs2x5TRd84f0utNdejP+wYt9IS8oa/BgK0e5XhwDGvWovan yYH9HQ/XnnNcny5rrPiOexEMPcGgjjvBtfU= X-Received: by 10.31.174.16 with SMTP id x16mr1506380vke.136.1497396783235; Tue, 13 Jun 2017 16:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.218 with HTTP; Tue, 13 Jun 2017 16:32:42 -0700 (PDT) In-Reply-To: References: <402e9b86-e28f-e2ab-d3b3-2f34e9dd0bff@alum.mit.edu> From: Bernard Aboba Date: Tue, 13 Jun 2017 16:32:42 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144078c5a48b60551dfdbfa" Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 23:33:08 -0000 --001a1144078c5a48b60551dfdbfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable First, let me apologize for contributing to this thread. Just as my wife has counseled me to limit my viewing of TV news programming to under 10 minutes a day (since more than this seems to lead to ranting and foaming at the mouth), so too would it be in my best interest not to contribute to this thread. However, although I will try to keep this response brief, I simply cannot resist. In my defense, since it is now June, this is at least one new year's resolution that I have kept for half a year, rather than the customary three weeks. And yes, I listened to Jim Comey's testimony last week and Jeff Session's today, both for more than 10 minutes. I will however, attempt to heed Tim Cook's recent advice to MIT graduates (see: https://www.washingtonpost.com/national/higher-education/apple-ceo-tim-cook= -to-address-2017-graduates-at-mit/2017/06/09/ee763ac8-4ccb-11e7-987c-42ab57= 45db2e_story.html?utm_term=3D.676972454c80 ) "Don't listen to trolls, and don't become one." Overall, my observation is that applications utilizing the RTCWEB protocol stack that require interoperability with other SIP implementations tend to utilize an "SDP adapter" (along the lines of adapter.js) that functions much like an "in-application SBC", so as to ensure SDP interoperability. However, those applications only requiring interoperability with versions of the same application running on other platforms (e.g. an application building on iOS, Android, Mac OS X and UWP) generally do not need an SDP adapter. Sometimes this is because they utilize JSON signaling and therefore do not use SIP/SDP signaling at all, and sometimes it is because their builds on all platforms utilize the same SDP dialect (typically the dialect utilized in the webrtc.org implementation). Within each of the categories described above, there are applications written to a native WebRTC 1.0 API, applications written to a "shimmed" WebRTC 1.0 API running over ORTC, and ORTC native applications. This is because ORTC is not so much an API as a "micro-kernel" approach to realtime communications. That is, just as one can use a micro-kernel to support multiple upper layer sub-systems (e.g. Posix, Win32, etc.), using ORTC it is possible to support multiple signaling approaches (e.g. SIP, H.323, JSON, etc.) on top of the same core media library. This is perhaps demonstrated most clearly in the ORTC Lib implementation (see https://github.com/ortclib), which provides both access to ORTC as well as the WebRTC 1.0 API, and could, I believe be used to provide support for H.323, although so far noone has contributed an implementation of that. However, while I have seen many different applications utilizing the RTCWEB protocol stack with different interoperability requirements, one thing I have not so far encountered is an a situation where there has been a need for standardizing a non-SDP signaling mechanism. If you are developing a basic realtime application that needs to provide interoperable A/V with a different realtime application (either on the same platform, or a different one), so far my experience has been that SIP/SDP works well enough. And where it doesn't work well enough (such as in advanced video conferencing scenarios involving multi-stream, simulcast, SVC, VR/AR, etc.) the odds are that interoperability between distinct applications is not required, in which case a non-SIP/SDP signaling approach can be utilized. So with respect to the need to standardize a non-SDP signaling mechanism, my view is "Don't bother, be happy." Gotta go. My 10 minutes are up. On Tue, Jun 13, 2017 at 2:45 PM, I=C3=B1aki Baz Castillo wr= ote: > 2017-06-13 22:33 GMT+02:00 Paul Kyzivat : > > Everybody who has worked with SDP realizes that it is ill-suited to the > > tasks we use it for. Quite a long time ago there was an effort called > SDPng > > that tried to define a new syntax. I wasn't involved in that, but it > seemed > > like it was defining something reasonable (XML based IIRC). But it fail= ed > > because (IIUC) nobody could see a viable migration plan to introduce it= . > > > > I think you are suggesting to do something new but limit its scope to > > WebRTC. Such a narrow scope would ease the migration effort. There woul= d > > still be one but perhaps people would be willing to suffer through it. > > > > BUT, WebRTC doesn't stand alone. Interworking with SIP is still > important, > > and probably will be for a long time. Also, your description of what is > > needed is simplistic. What features (functionality, not syntax) of SDP > O/A > > are not needed with WebRTC? AFAICT all the stuff that describes codecs = is > > needed, and much of the rest. There is a lot of that, spread over many > RFCs. > > All of that would have to be re-done. > > > > Doing something new here may well be the right thing to do. But the fir= st > > step is to carefully define the scope of applicability, and what > > interworking requirements there are with things outside that scope. The= n > > perhaps the size of the effort can be estimated and the feasibility > doing so > > assessed. > > Hi Paul, > > I'm not asking for a SDP 2.0 in JSON/XML or any other format. In your > text above, you state that "all the stuff that describes codecs is > needed, and much of the rest", and I don't agree with that: > > ORTC has proven to provide the *same* functionality as SDP, but > without imposing the exchange of a full SDP blob/string. Yes, codec > parameters must be exchanged between peers, but that does not mean > that a SDP (or similar format) is required. Instead, in ORTC, it's up > to the application/developer to decide how to signal parameters > between the endpoints of a multimedia session. In ORTC an endpoint can > signal ICE parameters, DTLS parameters, RTP parameters, and other > parameters in an independent way (so, if for example a new video > stream is added, there is no need to signal all the ICE/DTLS stuff to > the remote party again, but just the RTP parameters related to the new > stream). This design prevents issues such as the "SDP DTLS role > conflict" described in the previous email thread. > > You say "There is a lot of that, spread over many RFCs". > > And that's true, but ORTC specification [*] collects many of those > parameters and re-uses them within their own Dictionaries about ICE, > DTLS, RTP, RTCP, etc. It's true that there are tons of RFC's that > define multimedia parameters assuming SDP syntax, but IMHO the SDP-ish > is just a minor component in those specifications, nothing too hard to > circumvent IHMO (in fact, ORTC did it). > > > > I think you are suggesting to do something new but limit its scope to > WebRTC > > Not exactly. Continue reading, please. > > > > WebRTC doesn't stand alone. Interworking with SIP is still important > > Sure, and I understand that SIP indeed requires a wire-signaling > format/syntax because SIP requires interoperability between different > devices in both, the signaling and media, planes. But IMHO that does > not justify the fact that all the multimedia related specifications > are tiled to just SDP. SDP should not be the minimum irreducible unit > for exchanging multimedia information, and ORTC is a good example of > the opposite. > > What I would expect nowadays from the MMUSIC WG is to define > multimedia parameters (including different *layers" such as transport, > security/encryption, RTP, RTCP, etc) rather than a single format(SDP) > to cover them all. Having that, WebRTC could perfectly drop SDP and > define some proper Dictionaries (as ORTC) pointing to those parameters > defined by MMUSIC so WebRTC developers are done and free to exchange > data as they wish. And when it comes to SIP, of course the SIP > protocol needs a "multimedia format". A separate WG or a different > task within MMUSIC could be responsible of producing an standardized > "multimedia format" for SIP with those parameters, let it be SDP or > SDP 2.0. > > Anyhow, if so many things within the SDP are so problematic for > WebRTC, they will also be problematic for SIP (once SIP devices > implement so many advanced features such as those in WebRTC devices), > so still I consider that sending a full SDP to just renegotiate a new > codec (or remove a specific video stream) will produce real problems > as we suffer in WebRTC. But again, this is a separate concern that > should just affect to SIP devices (because SIP chose to go with SDP), > and not to WebRTC. > > > Thanks a lot for your response, regards. > > > > [*] http://draft.ortc.org/ > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1144078c5a48b60551dfdbfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
First, let me apologize for contributing to this thread.= =C2=A0

Just as my wife has counseled me to limit my= viewing of TV news programming to under 10 minutes a day (since more than = this seems to lead to ranting and foaming at the mouth), so too would it be= in my best interest not to contribute to this thread.=C2=A0

=
However, although I will try to keep this response brief, I simp= ly cannot resist.=C2=A0 In my defense, since it is now June, this is at lea= st one new year's resolution that I have kept for half a year, rather t= han the customary three weeks. =C2=A0 And yes, I listened to Jim Comey'= s testimony last week and Jeff Session's today, both for more than 10 m= inutes.


"Don't listen to trolls, and don&= #39;t become one."=C2=A0

Overall, my observat= ion is that applications utilizing the RTCWEB protocol stack that require i= nteroperability with other SIP implementations tend to utilize an "SDP= adapter" (along the lines of adapter.js) that functions much like an = "in-application SBC", so as to ensure SDP interoperability.=C2=A0= However, those applications only requiring interoperability with versions = of the same application running on other platforms (e.g. an application bui= lding on iOS, Android, Mac OS X and UWP) generally do not need an SDP adapt= er.=C2=A0 Sometimes this is because they utilize JSON signaling and therefo= re do not use SIP/SDP signaling at all, and sometimes it is because their b= uilds on all platforms utilize the same SDP dialect (typically the dialect = utilized in the webrtc.org implementation= ).

Within each of the categories described abo= ve, there are applications written to a native WebRTC 1.0 API, applications= written to a "shimmed" WebRTC 1.0 API running over ORTC, and ORT= C native applications.=C2=A0 This is because ORTC is not so much an API as = a "micro-kernel" approach to realtime communications.=C2=A0
=

That is, just as one can use a micro-kernel to support = multiple upper layer sub-systems (e.g. Posix, Win32, etc.), using ORTC it i= s possible to support multiple signaling approaches (e.g. SIP, H.323, JSON,= etc.) on top of the same core media library.=C2=A0

This is perhaps demonstrated most clearly in the ORTC Lib implementation = (see https://github.com/ortclib)= , which provides both access to ORTC as well as the WebRTC 1.0 API, and cou= ld, I believe be used to provide support for H.323, although so far noone h= as contributed an implementation of that.

However,= while I have seen many different applications utilizing the RTCWEB protoco= l stack with different interoperability requirements, one thing I have not = so far encountered is an a situation where there has been a need for standa= rdizing a non-SDP signaling mechanism.

If you are = developing a basic realtime application that needs to provide interoperable= A/V with a different realtime application (either on the same platform, or= a different one), so far my experience has been that SIP/SDP works well en= ough.=C2=A0 And where it doesn't work well enough (such as in advanced = video conferencing scenarios involving multi-stream, simulcast, SVC, VR/AR,= etc.) the odds are that interoperability between distinct applications is = not required, in which case a non-SIP/SDP signaling approach can be utilize= d. =C2=A0

So with respect to the need to standardi= ze a non-SDP signaling mechanism, my view is "Don't bother, be hap= py."=C2=A0

Gotta go.=C2=A0 My 10 minutes are = up.=C2=A0

=C2=A0=C2=A0





On Tue, Jun 13, 2017 at 2:4= 5 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
2017-06-13 22:33 GMT+02:00 Paul Kyz= ivat <pkyzivat@alum.mit.edu= >:
> Everybody who has worked with SDP realizes that it is ill-suited to th= e
> tasks we use it for. Quite a long time ago there was an effort called = SDPng
> that tried to define a new syntax. I wasn't involved in that, but = it seemed
> like it was defining something reasonable (XML based IIRC). But it fai= led
> because (IIUC) nobody could see a viable migration plan to introduce i= t.
>
> I think you are suggesting to do something new but limit its scope to<= br> > WebRTC. Such a narrow scope would ease the migration effort. There wou= ld
> still be one but perhaps people would be willing to suffer through it.=
>
> BUT, WebRTC doesn't stand alone. Interworking with SIP is still im= portant,
> and probably will be for a long time. Also, your description of what i= s
> needed is simplistic. What features (functionality, not syntax) of SDP= O/A
> are not needed with WebRTC? AFAICT all the stuff that describes codecs= is
> needed, and much of the rest. There is a lot of that, spread over many= RFCs.
> All of that would have to be re-done.
>
> Doing something new here may well be the right thing to do. But the fi= rst
> step is to carefully define the scope of applicability, and what
> interworking requirements there are with things outside that scope. Th= en
> perhaps the size of the effort can be estimated and the feasibility do= ing so
> assessed.

Hi Paul,

I'm not asking for a SDP 2.0 in JSON/XML or any other format. In your text above, you state that "all the stuff that describes codecs is
needed, and much of the rest", and I don't agree with that:

ORTC has proven to provide the *same* functionality as SDP, but
without imposing the exchange of a full SDP blob/string. Yes, codec
parameters must be exchanged between peers, but that does not mean
that a SDP (or similar format) is required. Instead, in ORTC, it's up to the application/developer to decide how to signal parameters
between the endpoints of a multimedia session. In ORTC an endpoint can
signal ICE parameters, DTLS parameters, RTP parameters, and other
parameters in an independent way (so, if for example a new video
stream is added, there is no need to signal all the ICE/DTLS stuff to
the remote party again, but just the RTP parameters related to the new
stream). This design prevents issues such as the "SDP DTLS role
conflict" described in the previous email thread.

You say "There is a lot of that, spread over many RFCs".

And that's true, but ORTC specification [*] collects many of those
parameters and re-uses them within their own Dictionaries about ICE,
DTLS, RTP, RTCP, etc. It's true that there are tons of RFC's that define multimedia parameters assuming SDP syntax, but IMHO the SDP-ish
is just a minor component in those specifications, nothing too hard to
circumvent IHMO (in fact, ORTC did it).


>=C2=A0 I think you are suggesting to do something new but limit its sco= pe to WebRTC

Not exactly. Continue reading, please.


> WebRTC doesn't stand alone. Interworking with SIP is still importa= nt

Sure, and I understand that SIP indeed requires a wire-signaling
format/syntax because SIP requires interoperability between different
devices in both, the signaling and media, planes. But IMHO that does
not justify the fact that all the multimedia related specifications
are tiled to just SDP. SDP should not be the minimum irreducible unit
for exchanging multimedia information, and ORTC is a good example of
the opposite.

What I would expect nowadays from the MMUSIC WG is to define
multimedia parameters (including different *layers" such as transport,=
security/encryption, RTP, RTCP, etc) rather than a single format(SDP)
to cover them all. Having that, WebRTC could perfectly drop SDP and
define some proper Dictionaries (as ORTC) pointing to those parameters
defined by MMUSIC so WebRTC developers are done and free to exchange
data as they wish. And when it comes to SIP, of course the SIP
protocol needs a "multimedia format". A separate WG or a differen= t
task within MMUSIC could be responsible of producing an standardized
"multimedia format" for SIP with those parameters, let it be SDP = or
SDP 2.0.

Anyhow, if so many things within the SDP are so problematic for
WebRTC, they will also be problematic for SIP (once SIP devices
implement so many advanced features such as those in WebRTC devices),
so still I consider that sending a full SDP to just renegotiate a new
codec (or remove a specific video stream) will produce real problems
as we suffer in WebRTC. But again, this is a separate concern that
should just affect to SIP devices (because SIP chose to go with SDP),
and not to WebRTC.


Thanks a lot for your response, regards.



[*] http://draft.ortc.org/


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

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

--001a1144078c5a48b60551dfdbfa-- From nobody Tue Jun 13 17:10:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB7129A9F for ; Tue, 13 Jun 2017 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0ZNHY1JIcMb for ; Tue, 13 Jun 2017 17:10:34 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFC112EA56 for ; Tue, 13 Jun 2017 17:10:34 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-12v.sys.comcast.net with SMTP id KvsbdLUezdlFQKvtJd29qf; Wed, 14 Jun 2017 00:10:33 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with SMTP id KvtIdmkuUbkqIKvtIdgV5D; Wed, 14 Jun 2017 00:10:33 +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 v5E0AV5M018374 for ; Tue, 13 Jun 2017 20:10:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v5E0AUlQ018371; Tue, 13 Jun 2017 20:10:31 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: mmusic@ietf.org In-Reply-To: (bernard.aboba@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 13 Jun 2017 20:10:30 -0400 Message-ID: <87lgovig3t.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLjDHtjlwZ6F/SqrUhEK/GtjKI3njQJ16vyuZWWiN6ubTbcu30c/jeZaX0LEkuKqT8oLZrCInDjBtLWNuNq6xLJk/uldjvsx/ThjAU9Z5sjMcQQvPX3T zT8plQ402SNCAB3LDmYoTwTuz+EH1qrV0MqfC5IuQtTKF58J6G/vYr5i Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:10:36 -0000 In my experience, there are a number of things that are universally agreed to be "the wrong tool for every job". The classical subject for that observation is vise grips -- and every toolbox contains a pair. In software, it's the language Perl -- and every system has a bunch of Perl scripts that do vital tasks. And in media protocols, it's SDP -- and any interoperable system can send and receive SDP. It seems that everyone who has dealt with SDP in the last ten years rants that SDP is horrible, and works on systems that use SDP. The problem with all of these tools is that they *work*, they can be used to do whatever is needed at the moment, in a way that is adequate for the users' needs, in environments where it is quite difficult to do that. It may be possible to transition a large section of real-time media away from SDP. But the way to argue for that is to present the outline of a technical replacement, and a roadmap for implementing it in the overall ecosystem -- including the strategy for interoperating with systems that use SDP. Dale From nobody Wed Jun 14 03:06:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950D2129B64 for ; Wed, 14 Jun 2017 03:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJvpkjMYIola for ; Wed, 14 Jun 2017 03:06:15 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D391271FD for ; Wed, 14 Jun 2017 03:06:14 -0700 (PDT) X-AuditID: c1b4fb25-545149a0000046b1-32-59410a948164 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.47.18097.49A01495; Wed, 14 Jun 2017 12:06:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Wed, 14 Jun 2017 12:06:11 +0200 From: Christer Holmberg To: Roman Shpount , Cullen Jennings , "Eric Rescorla" CC: mmusic Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? - Updated PR Thread-Index: AQHS5PXYBF/b9T08mE6k5iisEptUBA== Date: Wed, 14 Jun 2017 10:06:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D566E5B31E4C4christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7uu5ULsdIgz1rWS1WvD7HbvFh/Q9G i6nLH7NYzLgwldmBxWPJkp9MHpfPf2T0mPy4jdnj1pSCAJYoLpuU1JzMstQifbsEroymO53M BYvDKtrWnmVvYDzn0cXIySEhYCLRMO85axcjF4eQwBFGiUOHdzFCOIsZJXYsO8jSxcjBwSZg IdH9TxukQUQgQ+Lzg8lMIDazgIzEjLONYLawQDujxOclQSC9IgIdQPbLyYwgvSICehIz15aB 1LAIqEpM6HjHCmLzClhL3J/dB9bLKCAm8f3UGqiZ4hK3nsxngjhOQGLJnvPMELaoxMvH/1hB RooCjXy33xMirCix82w7M0RrgsSa5gZGiPGCEidnPmGZwCg8C8nUWUjKZiEpg4gbSLw/N58Z wtaWWLbwNZStL7Hxy1lGCNtaov3qcSZkNQsYOVYxihanFiflphsZ66UWZSYXF+fn6eWllmxi BMbewS2/VXcwXn7jeIhRgINRiYd3zUaHSCHWxLLiytxDjBIczEoivBLngUK8KYmVValF+fFF pTmpxYcYpTlYlMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwmt3vPVLjtMDsKM+uhSqTFsvF xi9fypIZ7f7q+t7kWdO3iR9vXD2p3aFnr1OGVkvKg8NJ8qbRUvvTcu/55nzkKJZZNjPZI3Tf oS360WW8/jrezP8Wfk7/YjQ96sPR8HPXCz7PuBDxhetwYlHS4eW/p02VfeEW0+e+O7F70Uqe o8Lsm82YS07+VmIpzkg01GIuKk4EAKSnMkm5AgAA Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? - Updated PR X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:06:17 -0000 --_000_D566E5B31E4C4christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have updated the PR. I hope it addresses the opinions of everyone: * It removes any text regarding handling of DTLS associations before th= e answer. * It adds a note saying any data received is to be considered coming fr= om an unverified source, but that the processing of the data is outside the= scope of the document * It adds text to the SIP considerations, saying that the offerer shoul= d wait for all SDP answers until it declares a possible fingerprint mismatc= h. https://github.com/cdh4u/draft-dtls-sdp/pull/31 Note that this PR does not address the actpass issue =96 any changes associ= ated with that issue will be in a separate PR. Regards, Christer From: Roman Shpount > Date: Friday 9 June 2017 at 17:18 To: Cullen Jennings > Cc: "mmusic@ietf.org" >, Christer Holmberg > Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS assoc= iation before it has received the SDP answer? On Fri, Jun 9, 2017 at 9:32 AM, Cullen Jennings > wrote: I'd really really appreciate if you could give me a hint of it you agree wi= th my original points I asked about or which ones you disagree with and why= . The three points I am interested in are: For devices that want to minimize delay in setting up media and avoid media= clipping, doing the TLS handshake as soon as possible is good design but i= n some cases this means the system does the handshake before the identity = of the fingerprint is known. Doing TLS handshake as soon as possible is a good design. Doing answer iden= tity and integrity validation and validating certificate fingerprints as so= on as possible is a better design. I understand that doing answer and finge= rprint validation is not always possible when interfacing with legacy SIP d= evices, but there is no reason to design new solutions which process media = before the answer. For instance WebRTC has no reason to support unverified = media. Because of this, I think that anything that produces unverified medi= a is a bad design which has no reason to exist apart for legacy interop. Sp= ecifics on how to design session description identity and integrity validat= ion are clearly out of scope for this draft. All of this being said, what I am proposing for the sake of moving this dra= ft forward does not contradict any of your points. Once again, what I am pr= oposing is: 1. Remove any recommendation regarding handling DTLS association before the= answer (leave it up to implementation) 2. Put a note that accepting DTLS association before the answer can result = in unverified media and if this media is played back to the end user, end u= ser SHOULD be notified that media is coming from an unverified source. 3. Add clarification that DTLS associations established before the answer M= UST be torn down when no more answers are expected and that fingerprints in= any of the received answers match the negotiated certificate (Right now it= is specified that DTLS association MUST be torn down if it does not match = the answer. This is wrong if forking is used and multiple answers are recei= ved). Draft does not advise that DTLS association should be established before th= e answer is received (I think this is wrong), but it also does not advise t= hat it should not (you think it is wrong). This way implementation decides = what's best for it. Does it contradict anything that you want to accomplish? If it does, what needs to be changed? Regards, _____________ Roman Shpount --_000_D566E5B31E4C4christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I have updated the PR. I hope it addresses the opinions of everyone:&n= bsp;
  • It removes any text regarding handling of DTLS associations before the = answer. 
  • It adds a note saying any data received is to be cons= idered coming from an unverified source, but that the processing of the dat= a is outside the scope of the document
  • It adds text to the SIP cons= iderations, saying that the offerer should wait for all SDP answers until i= t declares a possible fingerprint mismatch.

Note that this PR does not address the actpass issue =96 any changes a= ssociated with that issue will be in a separate PR.

Regards,

Christer


From: Roman Shpount <roman@telurix.com>
Date: Friday 9 June 2017 at 17:18 To: Cullen Jennings <fluffy@iii.ca>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] draft-dtls-sd= p: Allow offerer to establish DTLS association before it has received the S= DP answer?

On Fri, Jun 9, 20= 17 at 9:32 AM, Cullen Jennings <fl= uffy@iii.ca> wrote:
I'd really really appreciate if you could give me a hint of it you agree wi= th my original points I asked about or which ones you disagree with and why= . The three points I am interested in are:

For devices that want to minimize delay in setting up media and avoid media= clipping, doing the TLS handshake as soon as possible is good design but i= n some cases this means the system does  the handshake before the iden= tity of the fingerprint is known.

Doing TLS handshake as soon as possible is a good design. Doing answer= identity and integrity validation and validating certificate fingerprints = as soon as possible is a better design. I understand that doing answer and = fingerprint validation is not always possible when interfacing with legacy SIP devices, but there is no reason = to design new solutions which process media before the answer. For instance= WebRTC has no reason to support unverified media. Because of this, I think= that anything that produces unverified media is a bad design which has no reason to exist apart for legacy intero= p. Specifics on how to design session description identity and integrity va= lidation are clearly out of scope for this draft.

All of this being said, what I am proposing for the sake of moving thi= s draft forward does not contradict any of your points. Once again, what I = am proposing is:

1. Remove any recommendation regarding hand= ling DTLS association before the answer (leave it up to implementation)
2. Put a note that accepti= ng DTLS association before the answer can result in unverified media and if= this media is played back to the end user, end user SHOULD be notified tha= t media is coming from an unverified source.
3. Add clarification that DTLS associations= established before the answer MUST be torn down when no more answers are e= xpected and that fingerprints in any of the received answers match the nego= tiated certificate (Right now it is specified that DTLS association MUST be torn down if it does not match the= answer. This is wrong if forking is used and multiple answers are received= ).

Draft does not advise that DTLS association should be established befo= re the answer is received (I think this is wrong), but it also does not adv= ise that it should not (you think it is wrong). This way implementation dec= ides what's best for it.

Does it contradict anything that you want to accomplish?
If it does, what needs to be changed?

Regards,
_____________
Roman Shpount
 
 --_000_D566E5B31E4C4christerholmbergericssoncom_-- From nobody Wed Jun 14 03:41:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAA7129BF5 for ; Wed, 14 Jun 2017 03:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etib1JRJWRAt for ; Wed, 14 Jun 2017 03:41:15 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4580129C04 for ; Wed, 14 Jun 2017 03:41:14 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id o83so88741460lff.3 for ; Wed, 14 Jun 2017 03:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3DaZ9e+GnorO9gR90ZfcIKb98rPDNi9UZTmes84e/pY=; b=1KPXm+xrdiF7lVy+qUMal7hCM8WYobREoDe8tnf6J59720twv/6QhTZS6XchBjQw7G K5eWFSsg/zhOk69MAj/D6aisbTgGFvIJoWR5Xvnhqxrmw/1yG9o4mPH+qgYpYFhq5EaO p1sUh4RAttB0SecAaFlmFVIh0tM9HQ1i4Iqf5YVccWz3Jv9LIj3hYNDdXFIcrq0vaCij pbOYvUva8T2OTedi4xBKcc1CDi3Aq+uoP+bh9nS9wNpkex8UtefVJtROl8X3VlW75ADA 5cfPwkH28mi7RioK7dML+nglMpo7nGDv/7VhbVJOBDAtBYOt6b30+aZYFoiHf99xaWA4 PscQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3DaZ9e+GnorO9gR90ZfcIKb98rPDNi9UZTmes84e/pY=; b=j/oAjtZ63NskPcNK6cT6OerPixKMaIEbUBIhAcosKrYNru1/8tzLxzzcTAyaIg1jzy W4IumUTOht/U6SmryCkN4hzAxhl4oJP4RiOZAYw/aTDM6+/7ue+IZJJ8xQztMdFDIaOI VhV3J05UNGG0q6jApA7O1UR78AooCVd8Txj6ZZ7z79SPfiglbFCie+df0ZOahM+SxXJb h7Atz/CWJAPRWFThBLcUIm17p8adhCaB84vpD/PgcdVl4D/y73hKpOwyLGbaO5IxX3vl u0RUCZAWingU6HHTXuvAswo1fPeKiZsV4Td7I7zul/dDzXhalRX4zZV0oKSl959vKMFo TAjw== X-Gm-Message-State: AKS2vOzagB4ZlJTxcYjNyoYlIjkKHQnSlPdTLBKQG97XisvFLXuyptAq y0/NllmJtKnoujbsOJqQAs6YUSPVLrRI X-Received: by 10.80.165.108 with SMTP id z41mr520388edb.60.1497436872863; Wed, 14 Jun 2017 03:41:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Wed, 14 Jun 2017 03:40:52 -0700 (PDT) In-Reply-To: References: <402e9b86-e28f-e2ab-d3b3-2f34e9dd0bff@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 14 Jun 2017 12:40:52 +0200 Message-ID: To: Bernard Aboba Cc: "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:41:17 -0000 2017-06-14 1:32 GMT+02:00 Bernard Aboba : > sometimes it is because their builds on all platforms utilize the same SD= P dialect (typically the dialect utilized in the webrtc.org implementation)= . > [...] > one thing I have not so far encountered is an a situation where there has > been a need for standardizing a non-SDP signaling mechanism. Just an observation about this: at least in WebRTC land, one cannot just decide whether to use SDP or not, he just needs to use it (the browser generates SDP blobs and consumes SDP blobs) but the fact is that, in complex scenarios others than P2P audio/video calls (for example SFUs), current vendors are doing very funny things that makes me worry about how the adoption of SDP in WebRTC is: I've seen that some SFU vendors (and their corresponding client's logic) just use SDP for the initial "connection" between clients and the SFU server. Usually there is just a single in-the-wire SDP O/A in which ICE and DTLS parameters are exchanged, so the transport is established. Some vendors also include some hardcoded m=3D sections with various hardcoded SSRCs for audio and video which don't represent a real remote audio/video, but a future one. Then, when a real participant joins the same conference, the SFU signals it out-of-band to all the others, and rewrite RTP packets (SSRC, PT, etc) from the new participant to satisfy one of the already hardcoded SSRC values in the already negotiated SDP O/A. When a participant leaves, or pauses his video, etc, that's not signaled via the SDP mechanism but out-of-band. Some other SFUs scenarios send out-of-band info to participants and those locally mangle the remote SDP (for example, to include a new SSRC or m=3D section) but there is no a real SDP exchange from endpoint to endpoint. So, IMHO this clearly shows the "hardcoded" way in which current complex WebRTC scenarios make use of the SDP mechanism to make the browser's SDP engine happy while still avoiding SDP renegotiation and SDP signaling features as much as possible. Said in other words: people try to avoid SDP and its semantics as much as possible. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jun 14 03:44:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31516129BF5 for ; Wed, 14 Jun 2017 03:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu5zCaVO3Yds for ; Wed, 14 Jun 2017 03:44:42 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 237AD129C06 for ; Wed, 14 Jun 2017 03:44:42 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id q97so183569268wrb.2 for ; Wed, 14 Jun 2017 03:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DM+hmhAid6H5axyGttNxc/kJUVW/M2b9J5M7IK/jNY8=; b=y4d4L1BKmE5X/dCaFpwx0hYLLIQ5wtRUgMWzQGMrPNlCfGPuB8kC67P6PI+xaxYXy8 UPSLec6CqopJHMr6/CPDaE8QQIdAT0BgQSQgr2L1mq5cEpc97HqaQ6+Od8+yV/audzk/ oj70Tqn3npO1T0MyX7DAM+DJBLN7V48b+ogif4+rBHUZ50Ngk38cirzbym1lExKqJaky QhERo8OBfi6uA8i1LNIgwXLi+4ruUQHxcuRb+7aYNvygWt9HbAHOuRX85VBxjnsLqlK7 J0apL6lmjF8gjIi/fhneoMooAdxPCCKqj1KAGHf4EzSqjeR27C0ICyuLTVcNUqpKw6yn aUOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DM+hmhAid6H5axyGttNxc/kJUVW/M2b9J5M7IK/jNY8=; b=fJPkcAYiAC/z/EeD/cDvn8TkCE4bgN0FcwS1flGmXUIHKFjTTZTK8PPMXs29dBGgTg T0uTD0uDn9z5gg9GNJ+2A4KpCnLb2sEnngQx0Lv4TAox+Lbcdy1AYkWV49o8KKEhJnsc 0c8Y4z4ZXyVdn4n7cQr0Abxy6n/pGb9zo3iFJ+D0APK24MdwrDwjwj84S2CN+mfABZxZ 6oe1W7Jj6d/GxzGa/WiONtUhXBk4/XM5QES0OqmbHh/9eOF51ZRD3MQFkfbc8I9H2fkD x2NfGflNHKC3LwUXiW/OojtRFf1ljwF58BXR/AEZBMn+hGQaDU0Qanc+2WhZbyL5UJIO 0jpg== X-Gm-Message-State: AKS2vOzEL8I3db4EerxM4yt0VhiW/LOOSCJLCIZ2AVPz5eVn57XsQrOJ Us9COdpJsxwVusMkkRy3vYIuwePZyMlgRn4= X-Received: by 10.80.214.25 with SMTP id x25mr502256edi.13.1497437080687; Wed, 14 Jun 2017 03:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Wed, 14 Jun 2017 03:44:20 -0700 (PDT) In-Reply-To: <87lgovig3t.fsf@hobgoblin.ariadne.com> References: <87lgovig3t.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 14 Jun 2017 12:44:20 +0200 Message-ID: To: "Dale R. Worley" Cc: "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:44:44 -0000 2017-06-14 2:10 GMT+02:00 Dale R. Worley : > It may be possible to transition a large section of real-time media away > from SDP. But the way to argue for that is to present the outline of a > technical replacement As said in a previous comments, there is no need for a SDP replacement. Nobody is asking for SDP 2.0 but, instead, "define the multimedia parameters and let me signal them in my preferred way". --=20 I=C3=B1aki Baz Castillo From nobody Wed Jun 14 04:05:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36FB1292FC for ; Wed, 14 Jun 2017 04:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhyNrKH3eqBM for ; Wed, 14 Jun 2017 04:05:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674DA1277BB for ; Wed, 14 Jun 2017 04:05:35 -0700 (PDT) X-AuditID: c1b4fb2d-ef7ff7000000080d-20-5941187c2ab0 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.26.02061.C7811495; Wed, 14 Jun 2017 13:05:33 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Wed, 14 Jun 2017 13:05:32 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "Dale R. Worley" CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] it's time to expel SDP from our lives Thread-Index: AQHS5KKhRhapqyXwvUa8fJQ0LD1J8qIkC44AgAA6JQA= Date: Wed, 14 Jun 2017 11:05:32 +0000 Message-ID: References: <87lgovig3t.fsf@hobgoblin.ariadne.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.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7hG6thGOkQetCSYvp+2wspi5/zGLx 8kSZA7PHuYb37B6T939l9liy5CdTAHMUl01Kak5mWWqRvl0CV8bKKxeZC3azVWzdsoSxgXEG axcjB4eEgInE3PPcXYxcHEICRxglDr6/xQbhLGaUOPr0EgtIEZuAhUT3P+0uRk4OEYEkiZmd x8B6mQXUJa4uDgIJCwtYSzS+mM8CUWIjsfXsTyjbSuL4ngdsIOUsAqoSLT/8QMK8QOVfF29i hth0gFHi/bLvYPWcAoESMxY9ZQaxGQXEJL6fWsMEYjMLiEvcejIfzJYQEJBYsuc8M4QtKvHy 8T+wc0QF9CTe7feECCtJ/NhwiQWiVU/ixtQpbBC2tUTfueusELa2xLKFr5kh7hGUODnzCcsE RvFZSLbNQtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGHkHt/zW 3cG4+rXjIUYBDkYlHt7OTQ6RQqyJZcWVuYcYJTiYlUR4Jc4DhXhTEiurUovy44tKc1KLDzFK c7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamAM2Fe4jamzr6vY3ij+ou11Na0Ljx77LRH4 7S/aOVWrxdQhvHiR4NKtmT9MeX7/3Zx7Yr8XC8dvpmqHdu4Ne+3b9SN/r5r451DUlwdLF+rP UbR1UsgLeu/qdXvPpmsnt/3aNWm/9nr15/lZW+8tzFBi+7q1rqt8zhJWnamG+XvFl7zPCNH6 +2atEktxRqKhFnNRcSIAb95TTLgCAAA= Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:05:38 -0000 Hi, >>It may be possible to transition a large section of real-time media away >> from SDP. But the way to argue for that is to present the outline of a >> technical replacement > >As said in a previous comments, there is no need for a SDP >replacement. Nobody is asking for SDP 2.0 but, instead, "define the >multimedia parameters and let me signal them in my preferred way". Well, in order to have interoperability, people need to have a common preferred way. That=B9s why we do standardisation. =20 In WebRTC, if people download the same web site, they will automatically get the same parameter signalling mechanism, no matter whether it=B9s standardised or not. But, if people download different web each may come with different mechanisms, in which case they won=B9t interop. Regards, Christer From nobody Wed Jun 14 04:06:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52293129568 for ; Wed, 14 Jun 2017 04:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9Mu3K_w6rDx for ; Wed, 14 Jun 2017 04:06:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDCD1292FC for ; Wed, 14 Jun 2017 04:06:25 -0700 (PDT) X-AuditID: c1b4fb25-17fff700000046b1-e0-594118af0cfc Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.55.18097.FA811495; Wed, 14 Jun 2017 13:06:24 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Wed, 14 Jun 2017 13:06:23 +0200 From: Christer Holmberg To: Christer Holmberg , =?Windows-1252?Q?I=F1aki_Baz_Castillo?= , "Dale R. Worley" CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] it's time to expel SDP from our lives Thread-Index: AQHS5KKhRhapqyXwvUa8fJQ0LD1J8qIkC44AgAA6JQCAAAA9gA== Date: Wed, 14 Jun 2017 11:06:22 +0000 Message-ID: References: <87lgovig3t.fsf@hobgoblin.ariadne.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.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7uu4GCcdIg2nHpCym77OxmLr8MYvF yxNlDswe5xres3tM3v+V2WPJkp9MAcxRXDYpqTmZZalF+nYJXBkrn9xnLFjIWbHu4F6WBsYL 7F2MnBwSAiYSCzqPMncxcnEICRxhlHj19wUrhLOYUWLOvK9AVRwcbAIWEt3/tEHiIgKzGCV2 L1nFCBJnFlCXuLo4CGSQsIC1ROOL+SwgtoiAjcTWsz+hbCeJN20/wcawCKhK7FnGCxLmBSo/ 8fEnG8SqT4wSG3b1MoEkOIF6Jy/bxApiMwqISXw/tQYsziwgLnHryXwmiKMFJJbsOc8MYYtK vHz8jxVkvqiAnsS7/Z4QYSWJHxsusUC0Gki8PzefGcK2llh/cSKUrS2xbOFrZoh7BCVOznzC MoFRfBaSbbOQtM9C0j4LSfssJO0LGFlXMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgRG38Et v1V3MF5+43iIUYCDUYmHd81Gh0gh1sSy4srcQ4wSHMxKIrwS54FCvCmJlVWpRfnxRaU5qcWH GKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MDZHnVexPHXuzCoOiZeRqTvvVKy5qObV pc+22Dhd33jTJ15x8cqFvL13k59u9Q3fkREu/mNmhHls98VPTxSn9GyU0d+Vcu51p87MfQ9P v5QRfSF8n/dFv6LNA/b3mwQ59WbfnxjzuGPntKw7Hx80M60JTow277vPfWGWHd8P5pAbn2TE rRvStymxFGckGmoxFxUnAgCxgyW5ugIAAA== Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:06:28 -0000 =85and, just to clarify: I do NOT suggest SDP 2.0 :) On 14/06/17 14:05, "mmusic on behalf of Christer Holmberg" wrote: >Hi, > >>>It may be possible to transition a large section of real-time media away >>> from SDP. But the way to argue for that is to present the outline of a >>> technical replacement >> >>As said in a previous comments, there is no need for a SDP >>replacement. Nobody is asking for SDP 2.0 but, instead, "define the >>multimedia parameters and let me signal them in my preferred way". > >Well, in order to have interoperability, people need to have a common >preferred way. That=B9s why we do standardisation. >=20 >In WebRTC, if people download the same web site, they will automatically >get the same parameter signalling mechanism, no matter whether it=B9s >standardised or not. But, if people download different web each may come >with different mechanisms, in which case they won=B9t interop. > >Regards, > >Christer > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Jun 14 04:09:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7C8129C58 for ; Wed, 14 Jun 2017 04:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACLcgiKoXGQR for ; Wed, 14 Jun 2017 04:09:08 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 F13B4129BA0 for ; Wed, 14 Jun 2017 04:09:07 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id p189so89398109lfe.2 for ; Wed, 14 Jun 2017 04:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VZ30Uy8d4wXuxAkl2DM58/jiHPIviyLqSgdi88DLhC8=; b=Onft/0MwTYQ5uD0qXaSMI78ZfXU1Rvur49P5RW954x2WK7CbljT/7e1hpDI/vKOMw4 AMGeUUueZPSYm00o/iVpPRbQM36tJBIVRfXFNGVirHtqCanZiSKS+t9P5mGBsNhefXyd y9agYc6LUr0MB1WMAiCi/peDp7AS8X6OXT7HAUB7OR/Rjz9Mq+PLiV2BdN5TooH8ljo4 BLq+JT0Iqcmzmnnx/5ds6kcQNl+lemDJr/lOS4guxOhiCeNMR43D8fiuSNweNvglTaNm 0gZUgT2GfSgWB6xgALKToY99MoexHK4quyDtLe8USuG9rw2PKzbJ4qY9c3KahrHmju2X kKtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VZ30Uy8d4wXuxAkl2DM58/jiHPIviyLqSgdi88DLhC8=; b=dn9Ty3sGLlBf2A/P/fZcAYyiNMMmvvEEL9/Ehi0Stc+ywAxQ9MKgHG5q7Rb8GhLmep 9TfPy3UldCvdz2XQDXZXKeiGlhsxTXZlvrqcK5hJuDpHWzdqrgxmQZmLIXwqkBPcaLFM dxFjVyWF0xlw/8K64xvLF2LrXUr91UqFUzJIwoNjqkJDYsWmCOSP5UtvwU1Dib854O0s SFGjC96LDMtjs77cvikJ57OBRmgDMr4/kCVs3HnVT+GyM2iOcRHiN9uYoGcyrZPnOWDc je8vquuba510MI0BDQGTT+I8c6GJjC1XuuUHD9fm9mBpdpAA/cBJN4+/Bwn8EkM/Yg8Q 83lQ== X-Gm-Message-State: AKS2vOzbwElRcowseIvreSsUKv+4InQ+9zEvxJnoipdnYdi6Fg4PoFUT NaRlFMIE2vND4s8DMmc2yZyF6lMtygs8 X-Received: by 10.80.147.226 with SMTP id o89mr605185eda.112.1497438546130; Wed, 14 Jun 2017 04:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Wed, 14 Jun 2017 04:08:45 -0700 (PDT) In-Reply-To: References: <87lgovig3t.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 14 Jun 2017 13:08:45 +0200 Message-ID: To: Christer Holmberg Cc: "Dale R. Worley" , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:09:10 -0000 2017-06-14 13:05 GMT+02:00 Christer Holmberg : >>As said in a previous comments, there is no need for a SDP >>replacement. Nobody is asking for SDP 2.0 but, instead, "define the >>multimedia parameters and let me signal them in my preferred way". > > Well, in order to have interoperability, people need to have a common > preferred way. That=C2=B9s why we do standardisation. And that's why SDP already exists. But that does not mean that we need that WebRTC is SDP based. > In WebRTC, if people download the same web site, they will automatically > get the same parameter signalling mechanism, no matter whether it=C2=B9s > standardised or not. But, if people download different web each may come > with different mechanisms, in which case they won=C2=B9t interop. Sure, but I'm talking about that. I just focus on the communication between the JS application and the browser's WebRTC engine, which is made via JS API by exchanging SDP blobs. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jun 14 04:21:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73412E03A for ; Wed, 14 Jun 2017 04:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCIo0iYNDYCF for ; Wed, 14 Jun 2017 04:20:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BFD1201FA for ; Wed, 14 Jun 2017 04:20:56 -0700 (PDT) X-AuditID: c1b4fb25-545149a0000046b1-24-59411c162e56 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.E8.18097.61C11495; Wed, 14 Jun 2017 13:20:55 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Wed, 14 Jun 2017 13:20:53 +0200 From: Christer Holmberg To: =?Windows-1252?Q?I=F1aki_Baz_Castillo?= CC: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] it's time to expel SDP from our lives Thread-Index: AQHS5KKhRhapqyXwvUa8fJQ0LD1J8qIkC44AgAA6JQD//8yugIAAN5yA Date: Wed, 14 Jun 2017 11:20:52 +0000 Message-ID: References: <87lgovig3t.fsf@hobgoblin.ariadne.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.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7tK64jGOkQc9fTovp+2wspi5/zGLx 8kSZA7PHuYb37B6T939l9liy5CdTAHMUl01Kak5mWWqRvl0CV8bnr1PYCk6xVBzcvo2lgfEs cxcjJ4eEgInErV0LGbsYuTiEBI4wSvydPp0JwlnMKDHrzz2WLkYODjYBC4nuf9ogDSIC1hKP 5p9hA7GZBfwk7n5tABskDBRvfDGfBaLGRmLr2Z9QtpvE6d5LjCBjWARUJX4+LQYJ8wKVT2h8 C7VqJ5PEmmv7GUESnAKBEtf+nGAHsRkFxCS+n1rDBLFLXOLWk/lMEEcLSCzZcx7qAVGJl4// sYLMFxXQk3i33xPElBBQkpi2NQ2i00Di/bn5zBC2tUTD/omsELa2xLKFr5khzhGUODnzCcsE RvFZSJbNQtI+C0n7LCTts5C0L2BkXcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGHsHt/xW 3cF4+Y3jIUYBDkYlHt41Gx0ihVgTy4orcw8xSnAwK4nwFko5RgrxpiRWVqUW5ccXleakFh9i lOZgURLnddx3IUJIID2xJDU7NbUgtQgmy8TBKdXAaGC/yKtHoPJ08KlZ61s7+O/fkVZcLcHd t19Ks9W52/1YdOz80Gvr5+cn/JbfunyHcMMKlj9/ZTQW+qbs7JWKc67vXWs2a3d4yt2e00kb lYJ+GKolv937J5vPMSafZ5N97YLq10/fHWA7Hb3H7MiiyNseco/+rpVWy0yJFVSpUwp7Kmgl nxirxFKckWioxVxUnAgAYdYkJ7kCAAA= Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:21:00 -0000 Hi, >>>As said in a previous comments, there is no need for a SDP >>>replacement. Nobody is asking for SDP 2.0 but, instead, "define the >>>multimedia parameters and let me signal them in my preferred way". >> >> Well, in order to have interoperability, people need to have a common >> preferred way. That=B9s why we do standardisation. > >And that's why SDP already exists. But that does not mean that we need >that WebRTC is SDP based. Well, THAT discussion IS off-topic for MMUSIC :) The choice to use SDP was done by RTCWEB, wasn=92t it? Regards, Christer From nobody Wed Jun 14 04:25:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A841288B8 for ; Wed, 14 Jun 2017 04:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8dItDPWFses for ; Wed, 14 Jun 2017 04:25:44 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 328A61201FA for ; Wed, 14 Jun 2017 04:25:44 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id q97so185196592wrb.2 for ; Wed, 14 Jun 2017 04:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T5SYJOPN+SXcIxbJtiF+w2upO/jqrRTCzRa9hKdAWPE=; b=eB3VMo1k71KbeCi4uUfCBV1A8To4hR59osuJFDqm92GCkTHM8jW+a09Xyw7/YTNxRn OYgqXcBdV1OQK28jL85h6oiEWkc11AW34k5RNALXG91ZEwPadmJxAEVISP4dAPavQX5c gNh7lCL+PwkX3eteuM9YxrOs8RZomSVvLL0ZCX9smnCN03qNzxELqfNUaT0RT9WlgUFM JdsFO/i/47RB/LA5HQF18B1diFWf8NEQ30XYVzdkWjp1rumdr3ijsaucDo7yIJyrFwIz AvenEp5NrfNVkrFOVu6RBjqWPnI+3PpPjH3d/rzEARtYYusXMPeHRR6NLJJ/V/Hk0AOK 0F/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T5SYJOPN+SXcIxbJtiF+w2upO/jqrRTCzRa9hKdAWPE=; b=JfhTxp9ngIqtuz2AxRrdSjDlFSy4AjO2374zGcbdE/MH2zv91Zqvwbid9BnerGzJ5o r+Ippn6CPiW4omA3vpNQwxQRlmaZAS/9607qkJjjqv3scwlfxpeDDycmMzmUzx+xciII HYRwaqkjgAyc5SdEj9yMGVaRJZxu/mv6OEvslSJ/wHtJll2CcZJ9LOIo1Zn3zdEOZu+f QdoAxBCD6VkWuok4z/3D/Se0NK+kxDC4mmJrmGJN5DKkR4LPdEim5MjGhahHWasNc/yw 2xiHPQ8zOtqMVdV3bAhxNmHd5TImA4MQ2r8oEdWoMW0yEWOx5x/B3yyx9toEEwtNlVTr z7Ig== X-Gm-Message-State: AKS2vOyuvEBViSLclVq8GbV0R1dUdQyg/zwJNK7x3h1gFkFcNScMgaZF 6teTRGDD2R8ewQCK6KSMuSBvLxjsZSMW8IE= X-Received: by 10.80.165.10 with SMTP id y10mr629966edb.64.1497439542654; Wed, 14 Jun 2017 04:25:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Wed, 14 Jun 2017 04:25:22 -0700 (PDT) In-Reply-To: References: <87lgovig3t.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 14 Jun 2017 13:25:22 +0200 Message-ID: To: Christer Holmberg Cc: "Dale R. Worley" , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:25:46 -0000 2017-06-14 13:20 GMT+02:00 Christer Holmberg : >>And that's why SDP already exists. But that does not mean that we need >>that WebRTC is SDP based. > > Well, THAT discussion IS off-topic for MMUSIC :) > > The choice to use SDP was done by RTCWEB, wasn=E2=80=99t it? Right. However, the problem I see is that the only WG defining multimedia parameters is MMUSIC, and it defines those within the SDP context, making it hard to enable any other approach than SDP. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jun 14 08:14:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E8F12EAC1 for ; Wed, 14 Jun 2017 08:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71idtvt1cIyI for ; Wed, 14 Jun 2017 08:14:19 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9166912420B for ; Wed, 14 Jun 2017 08:14:19 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-04v.sys.comcast.net with SMTP id L9zQd64AuscBPL9zudBraz; Wed, 14 Jun 2017 15:14:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1497453258; bh=y0EVwiDORO2/pnzV4mDalGKlfPOp3wOjedjCit9IC+8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=eXFNlYcNdebQWNRxWwugNUhxT5BB3gAt2oWW2vnMgZ2opIhfnRqnWpxkonOwbiRs3 oo/NPYm63BJ14qJ8V6hXczrwaaMCHWIEACUqCi5fWn/lBx+pBvxrAotBpVN9GFUA5b tNKPLwPxonwc4Bin6HKHJpUudIv/jUlRJQEQ4gtRS2fbiksm9FFhlhkk/V/j6rkPUa ccuOINXmszUUTlQqRCu3GSa99aMVNKrSfED8eLk3+AZwea88ijcdIJHBDhSaZd9QMU 4S5ipgpQU4z7Fk8cbb8QArNy6z0kVJ9UVa2fj7ZvFHuFBH7poTeEti9x8mTksVr9+s EAKOBFCylxu4A== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-13v.sys.comcast.net with SMTP id L9zudgQYrAtR2L9zudHOUU; Wed, 14 Jun 2017 15:14:18 +0000 To: mmusic@ietf.org References: <87lgovig3t.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Wed, 14 Jun 2017 11:14:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfIvZVb+uR32la8dNYuRlE8EWp4h2BbGITPpkjp0gE+gBATaHpmmcxqTO3cmwxSCbGJEnPbdxtEmcu9LxgtVPIw6avaET3q6cNcfonFa9dUx+iKp081ZO iVqR41CPHAUrdezjkbDJylUOdF+LKheHexFk471r65wMyNrkvxThkrNY Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:14:21 -0000 On 6/14/17 7:25 AM, Iñaki Baz Castillo wrote: > 2017-06-14 13:20 GMT+02:00 Christer Holmberg : >>> And that's why SDP already exists. But that does not mean that we need >>> that WebRTC is SDP based. >> >> Well, THAT discussion IS off-topic for MMUSIC :) >> >> The choice to use SDP was done by RTCWEB, wasn’t it? > > Right. However, the problem I see is that the only WG defining > multimedia parameters is MMUSIC, and it defines those within the SDP > context, making it hard to enable any other approach than SDP. Well, there has to be *some* agreed upon means for defining these parameters. SDP is being used because that is what there is, even though it is far from ideal. Certainly something else could be used, but then that needs to be defined. I guess you are arguing that this partition the definition, separating semantics from syntax. While that is certainly possible, it probably won't make the job simpler. What is needed is a concrete proposal. Thanks, Paul From nobody Wed Jun 14 08:18:31 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE13112EB69 for ; Wed, 14 Jun 2017 08:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FZze4gkR5bD for ; Wed, 14 Jun 2017 08:18:28 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 9CF4512EB07 for ; Wed, 14 Jun 2017 08:18:28 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id r103so2802036wrb.0 for ; Wed, 14 Jun 2017 08:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C8Cu3S+/CZQACw/XYLzLElDfrxGpUfArPN0J0j6c7mc=; b=wtOvLoDTyc5Ua2pytALuVU/8njrs+K60Gr+06nZG3XmaD6RMj8bqrqFhsdFyfJmTZN qRPG9l4nO72/EHIzILxnkBHgNZYDrdSsJ3MKCuti5ldj7v+QZdiTSdqR04HXKd1iRo1q 6MD6NA6ByflE/a0vMH4Q53OJmWUsis/Y9hHC0IlvHhYB8FsQoMnHEOfPpHlr0mt8kV9o wta5t3iv6J2MiD2QCFzBJZhKnOtcV62+oPpsRxsDiPMJ78zVWgEEdP8tl7Wia0jVm1hs RMmJvCO6HuoVYZUK/Ud5cYxFWuJr3sCGyfF9kkuU10W5fFKJzy4G/r9WQ0c50hTeHBKJ qm7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C8Cu3S+/CZQACw/XYLzLElDfrxGpUfArPN0J0j6c7mc=; b=j1lKLUFYEjiHuCh5W9g2AfVtdy1ib65Q3/Tz9TYt9+V5X2ULP9yCiNGFkaAE+fVP/b vGrxbtt/8xEVM9oN9qtYa2FdUgnSZztmMWZooNBgRGDMFdMgY8icqGi3K8L5VWAubPoy 1b+9btypCnDLBVTlPYoU4fIy34McrhefyOgj7KEszKb65johZCt/h2iSY/mz0wU245rg A1pStCBiHt+oNbJ48Yc6q/wrRTEve7dgb/gZTiR6jR+rulrrhujcQkJ90sLQi5soHb3c mm7HuS6IaDBvZdrnGdRVBSyVLYvjB8kBYBDHEhzvExIjMY3nBMuTncEcJ3Zjw0NbdNae v5Aw== X-Gm-Message-State: AKS2vOyQzLYaznOGmfFH2sq0C0WW4vVEfeUl6jmgvnZBpVM6SbmmJ1Jw WGFlGb7c1aka+JBTuYDreqnVkJhhM6/h X-Received: by 10.80.206.22 with SMTP id y22mr492698edi.20.1497453506930; Wed, 14 Jun 2017 08:18:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.87 with HTTP; Wed, 14 Jun 2017 08:18:06 -0700 (PDT) In-Reply-To: References: <87lgovig3t.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 14 Jun 2017 17:18:06 +0200 Message-ID: To: Paul Kyzivat Cc: "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] it's time to expel SDP from our lives X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:18:31 -0000 2017-06-14 17:14 GMT+02:00 Paul Kyzivat : > I guess you are arguing that this partition the definition, separating > semantics from syntax. Yes. > What is needed is a concrete proposal. Agreed. Thanks. --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 16 05:58:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438EC129BE6 for ; Fri, 16 Jun 2017 05:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WE77z_yKb-i for ; Fri, 16 Jun 2017 05:58:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34CF1201FA for ; Fri, 16 Jun 2017 05:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2929; q=dns/txt; s=iport; t=1497617925; x=1498827525; h=to:from:subject:message-id:date:mime-version; bh=/4tGqQsfsVIgn6F67DDb1xDiLiZ+V9cZ9/PTM4h8IRk=; b=PLNU8tDqmn68ebmgtDE7r0ZEuQibZ7JGr3QEgsFkv9v2vqTEuLSL6Xgm 4cBT6s0ymE6V3isKpuDFuIgjRZ/uRwmEUqOm3GfqYO8MsvgcOkp/yWxl7 aHRxCPhG68AglFp9n/SHB+oEYbw5f9b+t6XQa1bEzH9KvF8S4wMjyhWXF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAwDK1ENZ/4MNJK1dHQEFAQsBg1iFW?= =?us-ascii?q?ooYkVmQb4U6ghGJDj8YAQIBAQEBAQEBayiFQkskBgE9Al8NCAEBihsNi1SdYYI?= =?us-ascii?q?mKosaAQEIAgElhmOCCwuKaYJhBYcZiSOOG44ohTKCCIVHg0uGdJUGHzg/S1EjF?= =?us-ascii?q?UmHKySKBQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,347,1493683200"; d="scan'208,217";a="248285171" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2017 12:58:44 +0000 Received: from [10.118.10.22] (rtp-fandreas-2-8815.cisco.com [10.118.10.22]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5GCwir6007061 for ; Fri, 16 Jun 2017 12:58:44 GMT To: mmusic From: Flemming Andreasen Message-ID: Date: Fri, 16 Jun 2017 08:58:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9DED451960FD209B7194817B" Archived-At: Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 99 (Prague) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:58:47 -0000 This is a multi-part message in MIME format. --------------9DED451960FD209B7194817B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi IETF99 in Prague will be here before you know it, and the MMUSIC WG has asked for a 2.5 hour meeting this time. Draft submissions and WG agendas are both due in less than 3 weeks, so now would be a good time to start preparing and 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 productive manner. 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. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding up progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following: - name of the draft and the presenter - how much time 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) --------------9DED451960FD209B7194817B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi

IETF99 in Prague will be here before you know it, and the MMUSIC WG has asked for a 2.5 hour meeting this time. Draft submissions and WG agendas are both due in less than 3 weeks, so now would be a good time to start preparing and 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 productive manner. 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. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding up progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following:

- name of the draft and the presenter
- how much time 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)

--------------9DED451960FD209B7194817B-- From nobody Fri Jun 16 06:22:50 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 824F9129C12 for ; Fri, 16 Jun 2017 06:22:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149761936852.24163.4107733256246999719.idtracker@ietfa.amsl.com> Date: Fri, 16 Jun 2017 06:22:48 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 13:22:48 -0000 Changed milestone "Using the SDP Offer/Answer Mechanism for DTLS", set due date to July 2017 from February 2017. Changed milestone "Submit RTP Payload Format Constraints as Proposed Standard", set due date to August 2017 from March 2017. Changed milestone "Submit SDP Negotiation of DataChannel sub-protocols as Proposed Standard", set due date to September 2017 from January 2017. Changed milestone "Submit Interactive Connectivity Establishment (ICE) with SDP offer/answer and SIP as Proposed Standard", set due date to September 2017 from April 2017. Changed milestone "Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard", set due date to October 2017 from February 2017. Changed milestone "Submit SIP usage for Trickle ICE as Proposed Standard", set due date to October 2017 from March 2017. Changed milestone "Submit Using Simulcast in SDP and RTP Sessions as Proposed Standard", set due date to October 2017 from March 2017. Changed milestone "Submit MSRP over Data Channels as Proposed Standard", set due date to March 2018 from March 2017. Changed milestone "Submit revised SDP specification to IETF as Proposed Standard", set due date to March 2018 from July 2017. URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Fri Jun 16 06:25:00 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C700129C12 for ; Fri, 16 Jun 2017 06:24:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149761949837.24272.13452295761896922773.idtracker@ietfa.amsl.com> Date: Fri, 16 Jun 2017 06:24:58 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 13:24:58 -0000 Changed milestone "Submit Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile as Proposed Standard", added draft-ietf-mmusic-opportunistic-negotiation to milestone, removed draft-hutton-mmusic-opportunistic-negotiation from milestone. URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Fri Jun 16 09:06:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A1512944A for ; Fri, 16 Jun 2017 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY_6nDD2cDHj for ; Fri, 16 Jun 2017 09:06:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FFC129415 for ; Fri, 16 Jun 2017 09:06:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 08D0EB80164; Fri, 16 Jun 2017 09:05:54 -0700 (PDT) To: fandreas@cisco.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, bo.burman@ericsson.com, fandreas@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: fluffy@iii.ca, mmusic@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170616160554.08D0EB80164@rfc-editor.org> Date: Fri, 16 Jun 2017 09:05:54 -0700 (PDT) Archived-At: Subject: [MMUSIC] [Technical Errata Reported] RFC5939 (5042) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:06:10 -0000 The following errata report has been submitted for RFC5939, "Session Description Protocol (SDP) Capability Negotiation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5042 -------------------------------------- Type: Technical Reported by: Typo in example Section: 4.2 Original Text ------------- m=audio 59000 UDP/TLS/RTP/AVP 98 Corrected Text -------------- m=audio 59000 UDP/TLS/RTP/SAVP 98 Notes ----- The example missed an S in the mine type. The list of allowed types is at https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2 and UDP/TLS/RTP/AVP is not a registered device. Because this is over TLS, it is a SRTP (not RTP) and should use SAVP not AVP. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5939 (draft-ietf-mmusic-sdp-capability-negotiation-13) -------------------------------------- Title : Session Description Protocol (SDP) Capability Negotiation Publication Date : September 2010 Author(s) : F. Andreasen Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Fri Jun 16 09:14:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8161293E9 for ; Fri, 16 Jun 2017 09:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNn9SaKniN2Q for ; Fri, 16 Jun 2017 09:14:01 -0700 (PDT) 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 68D4D1294B7 for ; Fri, 16 Jun 2017 09:13:58 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5GGDvu3057367 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 16 Jun 2017 11:13:57 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_BC42ACBC-0AB4-421F-B4CD-368A0BDB9298" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: References: <20170616160554.08D0EB80164@rfc-editor.org> To: mmusic Date: Fri, 16 Jun 2017 11:13:55 -0500 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [MMUSIC] Fwd: [Technical Errata Reported] RFC5939 (5042) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:14:03 -0000 --Apple-Mail=_BC42ACBC-0AB4-421F-B4CD-368A0BDB9298 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This seems correct to me on a quick scan, modulo the work around = opportunistic srtp, which shouldn=E2=80=99t affect the erratum at this = point. Thoughts? Thanks! Ben. > Begin forwarded message: >=20 > From: RFC Errata System > Subject: [Technical Errata Reported] RFC5939 (5042) > Date: June 16, 2017 at 11:05:54 AM CDT > To: fandreas@cisco.com, ben@nostrum.com, aamelnikov@fastmail.fm, = adam@nostrum.com, bo.burman@ericsson.com, fandreas@cisco.com > Cc: fluffy@iii.ca, mmusic@ietf.org, rfc-editor@rfc-editor.org >=20 > The following errata report has been submitted for RFC5939, > "Session Description Protocol (SDP) Capability Negotiation". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5042 >=20 > -------------------------------------- > Type: Technical > Reported by: Typo in example >=20 > Section: 4.2 >=20 > Original Text > ------------- > m=3Daudio 59000 UDP/TLS/RTP/AVP 98 >=20 > Corrected Text > -------------- > m=3Daudio 59000 UDP/TLS/RTP/SAVP 98 >=20 > Notes > ----- > The example missed an S in the mine type. The list of allowed types is = at = https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-p= arameters-2 and UDP/TLS/RTP/AVP is not a registered device. Because = this is over TLS, it is a SRTP (not RTP) and should use SAVP not AVP. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5939 (draft-ietf-mmusic-sdp-capability-negotiation-13) > -------------------------------------- > Title : Session Description Protocol (SDP) Capability = Negotiation > Publication Date : September 2010 > Author(s) : F. Andreasen > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG --Apple-Mail=_BC42ACBC-0AB4-421F-B4CD-368A0BDB9298 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

This = seems correct to me on a quick scan, modulo the work around = opportunistic srtp, which shouldn=E2=80=99t affect the erratum at this = point. Thoughts?

Thanks!

Ben.

Begin forwarded = message:

From: = RFC Errata System <rfc-editor@rfc-editor.org>
Subject: = [Technical Errata = Reported] RFC5939 (5042)
Date: = June 16, 2017 at 11:05:54 AM = CDT
To: = fandreas@cisco.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, bo.burman@ericsson.com, fandreas@cisco.com
Cc: = fluffy@iii.ca, mmusic@ietf.org, rfc-editor@rfc-editor.org

The following errata report = has been submitted for RFC5939,
"Session Description = Protocol (SDP) Capability Negotiation".

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

--------------------------------------
Type: = Technical
Reported by: Typo in example = <fluffy@iii.ca>

Section: 4.2

Original Text
-------------
m=3Daudio 59000 UDP/TLS/RTP/AVP 98

Corrected Text
--------------
m=3Daudio 59000 UDP/TLS/RTP/SAVP 98

Notes
-----
The example missed an = S in the mine type. The list of allowed types is at = https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-p= arameters-2 and UDP/TLS/RTP/AVP  is not a registered device. = Because this is over TLS, it is a SRTP (not RTP) and should use SAVP not = AVP.

Instructions:
-------------
This erratum is currently posted = as "Reported". If necessary, please
use "Reply All" to = discuss whether it should be verified or
rejected. When a = decision is reached, the verifying party  
can log in = to change the status and edit the report, if necessary.
--------------------------------------
RFC5939 = (draft-ietf-mmusic-sdp-capability-negotiation-13)
--------------------------------------
Title =             &n= bsp; : Session Description Protocol (SDP) Capability Negotiation
Publication Date    : September 2010
Author(s) =           : F. = Andreasen
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: Multiparty Multimedia Session Control RAI
Area =             &n= bsp;  : Real-time Applications and Infrastructure
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_BC42ACBC-0AB4-421F-B4CD-368A0BDB9298-- From nobody Fri Jun 16 15:23:23 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAAB1292FD; Fri, 16 Jun 2017 15:23:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149765179602.24205.1669457452598120537@ietfa.amsl.com> Date: Fri, 16 Jun 2017 15:23:16 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 22:23:16 -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: Session Description Protocol Authors : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-19.txt Pages : 61 Date : 2017-06-16 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-19 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 16 15:32:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3280E127076 for ; Fri, 16 Jun 2017 15:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhQNxHH0kfOd for ; Fri, 16 Jun 2017 15:32:13 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 CCE2C126CC4 for ; Fri, 16 Jun 2017 15:32:12 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 84so16180620ybe.0 for ; Fri, 16 Jun 2017 15:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=p11pK6sYMTmBMBMOeeFSALvPwZ+URnLCNo9my0VcQ68=; b=OqhofpGAvpjAbhCMtzAZG2WmzK0OrOm/OzIwW4xOt6GQwhEjJWt/3y8M5Bogk/J0L0 AaY05XPAzB9vMBan4XXIKIkyBDudq0fNBPYLWdQE6ug8ba0UM92dCLIWgjNFUGoKjFpa GEpqnmjeo1aUSxx7bm9EiPF0fLUV4PO+N/WV03RoAPr5ARoqy9As1pMTV78NVUG/qyEj VvfTUdGeh+0ihl4+2+HdQ2jxT1XyQQg1sYBAFW2hkB8SyeEvCIcgbc88rHJe2STH8jUs eoGQej4yc5DpoFZBf0EQOCX7901CfSH9nPaUPXcish2rzXkQq0v77zWUNwXz+mcsQPkq W5sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=p11pK6sYMTmBMBMOeeFSALvPwZ+URnLCNo9my0VcQ68=; b=U9iI4cR1Hq5EPApBspcdv0jqh7xSg/FBQU/FPkQSWlEMgfEFDnPWoq8TxCaXjPLsn/ kEjfFEvDs1YLbS8UeatQfUStqEih0K4VBwE7txZWw1pesU8YFQ02DH0dDHqfQ6UX/YPQ Li0LT6JsgzlKcrFzW9sGqL75e8OQOFBr1rV/vYikR3UYgR/TQhzAIZwT2l0th29pSoOt spdguzwJapWtp/IERa3F2GlWRHunEUZ4BVwc4Kykiq7ErqLhMNar6Er+uJnwlTWAlN/c eTqNN9HvHSicunL88TLF6s5anfAi6Fp7tUBomEs3ZgK86oX8umR39Mqpg7oImfeetFCV EYZA== X-Gm-Message-State: AKS2vOyws0dYdLqCsurF9vm5RiSh9+dx/wnG6mpq3tg3JHpXNWTpSZKH 2fGgWQPMQq3e8cKAqXx0c0A4fbDZTYbD1kI= X-Received: by 10.37.11.68 with SMTP id 65mr5109264ybl.94.1497652331899; Fri, 16 Jun 2017 15:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.91.193 with HTTP; Fri, 16 Jun 2017 15:32:11 -0700 (PDT) In-Reply-To: <149765179618.24205.7010922835529746440.idtracker@ietfa.amsl.com> References: <149765179618.24205.7010922835529746440.idtracker@ietfa.amsl.com> From: "Ali C. Begen" Date: Sat, 17 Jun 2017 01:32:11 +0300 Message-ID: To: mmusic Content-Type: multipart/alternative; boundary="001a11c006b23d9b6d05521b5b9e" Archived-At: Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 22:32:15 -0000 --001a11c006b23d9b6d05521b5b9e Content-Type: text/plain; charset="UTF-8" Hi everyone There have been some comments on and off the list regarding the 4566bis draft and with this update, I am hoping that I made all the changed asked for. There were a few errors that were taken care of, some ABNF syntax has been improved, references have been updated, etc. https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rfc4566bis-18&url2=draft-ietf-mmusic-rfc4566bis-19 Please check whether you have outstanding issues or not. I saw that the chairs updated the milestone for this draft, and from my perspective, the draft is ready to go to WGLC. -acbegen PS Van J.'s email is bouncing and I was told his current email was van@google.com. I sent an email, but no response. If anybody has more info on this, let me know. We need a working email for him to go thru the publication process. ---------- Forwarded message ---------- From: Date: Sat, Jun 17, 2017 at 1:23 AM Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-19.txt To: Colin Perkins , Mark Handley , Ali Begen , Van Jacobson A new version of I-D, draft-ietf-mmusic-rfc4566bis-19.txt has been successfully submitted by Ali Begen and posted to the IETF repository. Name: draft-ietf-mmusic-rfc4566bis Revision: 19 Title: SDP: Session Description Protocol Document date: 2017-06-17 Group: mmusic Pages: 61 URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic- rfc4566bis-19.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic- rfc4566bis/ Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-19 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-mmusic- rfc4566bis-19 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic- rfc4566bis-19 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a11c006b23d9b6d05521b5b9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone

There have been some commen= ts on and off the list regarding the 4566bis draft and with this update, I = am hoping that I made all the changed asked for. There were a few errors th= at were taken care of, some ABNF syntax has been improved, references have = been updated, etc.


=
Please check whether you have outstanding issues or not. I saw t= hat the chairs updated the milestone for this draft, and from my perspectiv= e, the draft is ready to go to WGLC.

-acbegen

PS Van J.'s email is bouncing and I was told his c= urrent email was van@google.com. I se= nt an email, but no response. If anybody has more info on this, let me know= . We need a working email for him to go thru the publication process.
=

---------- Forwarded message ----------=
From: <internet-drafts@ietf.org>
Date: Sat, Jun 17, 2017 at 1:23 AM
Subject: New Version Notificatio= n for draft-ietf-mmusic-rfc4566bis-19.txt
To: Colin Perkins <csp@csperkins.org>, Mark Handley <<= a href=3D"mailto:m.handley@cs.ucl.ac.uk">m.handley@cs.ucl.ac.uk>, Al= i Begen <ali.begen@networked.media>, Van Jacobson <van@parc.com>



A new version of I-D, draft-ietf-mmusic-rfc4566bis-19.txt
has been successfully submitted by Ali Begen and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-mmusic-rfc4566bis<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A019
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP: Session Description Protocol<= br> Document date:=C2=A0 2017-06-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 61
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-mmus= ic-rfc4566bis-19.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-19
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4= 566bis-19
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-19

Abstract:
=C2=A0 =C2=A0This memo defines the Session Description Protocol (SDP).=C2= =A0 SDP is
=C2=A0 =C2=A0intended for describing multimedia sessions for the purposes o= f
=C2=A0 =C2=A0session announcement, session invitation, and other forms of =C2=A0 =C2=A0multimedia session initiation.=C2=A0 This document obsoletes R= FC 4566.




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

The IETF Secretariat


--001a11c006b23d9b6d05521b5b9e-- From nobody Sat Jun 17 15:54:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E025B1243F6 for ; Sat, 17 Jun 2017 15:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gw43Yfvjb6j for ; Sat, 17 Jun 2017 15:54:12 -0700 (PDT) Received: from smtp90.ord1c.emailsrvr.com (smtp90.ord1c.emailsrvr.com [108.166.43.90]) (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 2655D1242F7 for ; Sat, 17 Jun 2017 15:54:12 -0700 (PDT) Received: from smtp28.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 081F8402C5; Sat, 17 Jun 2017 18:54:09 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 70A1640130; Sat, 17 Jun 2017 18:54:08 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (d75-159-47-121.abhsia.telus.net [75.159.47.121]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 17 Jun 2017 18:54:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <20170616160554.08D0EB80164@rfc-editor.org> Date: Sat, 17 Jun 2017 16:54:07 -0600 Cc: Flemming Andreasen , Ben Campbell , Alexey Melnikov , Adam Roach , Bo Burman Content-Transfer-Encoding: quoted-printable Message-Id: <79C4D134-A22E-4FFB-945F-CBC8CE2331CA@iii.ca> References: <20170616160554.08D0EB80164@rfc-editor.org> To: mmusic X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5939 (5042) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 22:54:14 -0000 > On Jun 16, 2017, at 10:05 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC5939, > "Session Description Protocol (SDP) Capability Negotiation". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5042 >=20 > -------------------------------------- > Type: Technical > Reported by: Typo in example >=20 > Section: 4.2 >=20 > Original Text > ------------- > m=3Daudio 59000 UDP/TLS/RTP/AVP 98 >=20 > Corrected Text > -------------- > m=3Daudio 59000 UDP/TLS/RTP/SAVP 98 >=20 > Notes > ----- > The example missed an S in the mine type. The list of allowed types is = at = https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-p= arameters-2 and UDP/TLS/RTP/AVP is not a registered device. Because = this is over TLS, it is a SRTP (not RTP) and should use SAVP not AVP. >=20 >=20 I have no idea how I cut and paste in mine type there. I should have put = "proto" not "mine type". Sorry From nobody Mon Jun 19 08:02:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59710131526 for ; Mon, 19 Jun 2017 08:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhN-GXXuk00M for ; Mon, 19 Jun 2017 08:02:24 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D6E13151B for ; Mon, 19 Jun 2017 08:02:18 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-09v.sys.comcast.net with SMTP id MyBBdPafVQe9cMyC1dOtXC; Mon, 19 Jun 2017 15:02:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1497884537; bh=vYCW2IFRKOsDDbKDzExMsPke3MCbDFdK7Wc7E6rCOzo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hvF5oq076xBAXn63Nsh9xR0R2GFIX8+j6KvYVI5lujAg5sG6Zp1ChjqhKfxCE2mrB pU5Fdqlwk5dS5g5cqXHzLvfrCyR/vBvRVjGBWrUFFM91b3A4yXxZUY8gw7NmSVSRRV V0r7mN8klvak3uflKwaEbf79ymwqV7Dr3NVsUMhmrIBmmhXD/qokygtwbV0mQR7lbe B872/88fTEADat2EfGAAvhRdM7eLVvcLb2kl3c9zo8PDlYSCxeeHDasRpMVx+V8YvI 9qF2aQTfQQRoiIhQomkseGtjvhOEvvJ+Snjvqy+xwK7hudR4w0UZp4tI4kKj6I5vmq TP1w4Df8ML7Ew== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-17v.sys.comcast.net with SMTP id MyC1dfPby8hkfMyC1dQxzl; Mon, 19 Jun 2017 15:02:17 +0000 To: mmusic@ietf.org References: <149765179618.24205.7010922835529746440.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Mon, 19 Jun 2017 11:02:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKT4dURaYyqZj2r+OG4SlxzinFDR77gMnlI1Nbez9DnxRtffYtU1jnqSmgCoXIhFEHSfwMq5QjIn3VwACeMlGs7CR/l4ZZ2ucJJkBFIGNlPzoT+VS97M ZrnuXzrGs+l4R8AAnDt1SbAsYUdefpLYpxpcLkutOLxDFY0pONOp27Ib Archived-At: Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:02:26 -0000 Hi Ali, On 6/16/17 6:32 PM, Ali C. Begen wrote: > Hi everyone > > There have been some comments on and off the list regarding the 4566bis > draft and with this update, I am hoping that I made all the changed > asked for. There were a few errors that were taken care of, some ABNF > syntax has been improved, references have been updated, etc. > > https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rfc4566bis-18&url2=draft-ietf-mmusic-rfc4566bis-19 > > Please check whether you have outstanding issues or not. I saw that the > chairs updated the milestone for this draft, and from my perspective, > the draft is ready to go to WGLC. I like the change to the grammar that moves the notation for optionality/repetition of individual fields from the definition of those fields to the overall definition of the session-description: session-description = proto-version origin-field session-name-field [information-field] [uri-field] *email-fields *phone-fields [connection-field] *bandwidth-fields 1*time-fields [key-field] *attribute-fields *media-descriptions However, this change induced a bug in the definition of media-descriptions: media-descriptions = media-field information-field *connection-field bandwidth-fields key-field attribute-fields This needs the same changes made to session-description. So this needs to be changed to: media-descriptions = media-field [information-field] *connection-field *bandwidth-fields [key-field] *attribute-fields Also this change does result in some very odd naming, where the names of some fields are plural but now ought to be singular. These ought to be fixed. Specifically: email-fields => email-field phone-fields => phone-field bandwidth-fields => bandwidth-field time-fields => time-field attribute-fields => attribute-field media-descriptions => media-description Otherwise the new version seems good to me. Thanks, Paul From nobody Mon Jun 19 09:18:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233AB131581 for ; Mon, 19 Jun 2017 09:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTqx6nQ_uk4k for ; Mon, 19 Jun 2017 09:18:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66D913158F for ; Mon, 19 Jun 2017 09:18:12 -0700 (PDT) X-AuditID: c1b4fb25-17fff700000046b1-f7-5947f9425f58 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 89.D0.18097.249F7495; Mon, 19 Jun 2017 18:18:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Mon, 19 Jun 2017 18:18:10 +0200 From: Christer Holmberg To: Eric Rescorla , Roman Shpount , Paul Kyzivat , "mmusic@ietf.org" CC: Ben Campbell Thread-Topic: [MMUSIC] actpass redux- suggestion & PR Thread-Index: AQHS6RekZVZHHpF0pkGf6nWRHITilw== Date: Mon, 19 Jun 2017 16:18:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D56D60131E797christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7t67zT/dIg8WLtSzmd55mt1jx+hy7 xdTlj1ksHvzoZbO4/nQXiwOrx+THcxg9liz5yeQxa+cTFiC3jdlj69+/bAGsUVw2Kak5mWWp Rfp2CVwZ8+8uYS1YJlSxrHcvcwPjO/4uRk4OCQETiQv/elm6GLk4hASOMErcPn+VEcJZzCjx 5+FO5i5GDg42AQuJ7n/aIHERgVmMEl0PTjGDdDMLKEns236EFcQWBpr08eheJhBbRMBUYsLs rewQtp7E9KZOdpA5LAKqEmff1oOEeQWsJXpu3AcrYRQQk/h+ag0TxEhxiVtP5jNBHCcgsWTP eWYIW1Ti5eN/rCBjRIFGvtvvCWJKAF0wbWsaRGeCxNE705kgpgtKnJz5hGUCo/AsJENnISmb haQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPgeo5gGxriVe7wpGVLGDkWMUoWpxanJSbbmSsl1qU mVxcnJ+nl5dasokRGI0Ht/xW3cF4+Y3jIUYBDkYlHt73790jhVgTy4orcw8xSnAwK4nwNj0C CvGmJFZWpRblxxeV5qQWH2KU5mBREud13HchQkggPbEkNTs1tSC1CCbLxMEp1cDII5l7uOJM 76rG6JoKU46STbOOOdx6vrbqzRZGR1fT22v8mN2mfDFwK0rd9+xIwl03G6t5S/v++y3RS9UV Opcx20Xk4+zpN1p2cotIXHx0hfOKZcQMvb0ZC1aXJmQ7majxdLUGMEnuUJ90KnTSeYfzGZtK FohkrOK+bKp8WJb7njH3NNeF6zKUWIozEg21mIuKEwEGzq7RwgIAAA== Archived-At: Subject: Re: [MMUSIC] actpass redux- suggestion & PR X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:18:46 -0000 --_000_D56D60131E797christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Taking into account the input from Ekr, Roman, Cullen and Paul, what about = the following suggestion: 1. In the initial offer, and endpoint MUST send actpass 2. In and subsequent offer, and endpoint MUST send actpass, or a value refl= ecting the currently negotiated value // This is what the draft currently s= ays 3. An endpoint MUST accept receiving a non-actpass value, in order to be ba= ckward compatible with legacy devices that use such values. PR: https://github.com/cdh4u/draft-dtls-sdp/pull/32 Regards, Christer --_000_D56D60131E797christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

Taking into account the input from Ekr, Roman, Cullen and Paul, what a= bout the following suggestion:

1. In = the initial offer, and endpoint MUST send actpass
2. In = and subsequent offer, and endpoint MUST send actpass, or a value reflecting= the currently negotiated value // This is what the draft currently says
3. An = endpoint MUST accept receiving a non-actpass value, in order to be backward= compatible with legacy devices that use such values.


Regards,

Christer
--_000_D56D60131E797christerholmbergericssoncom_-- From nobody Mon Jun 19 23:45:09 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FDF128959 for ; Mon, 19 Jun 2017 23:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Can-uV3s8QB for ; Mon, 19 Jun 2017 23:45:03 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA261131966 for ; Mon, 19 Jun 2017 23:45:01 -0700 (PDT) X-AuditID: c1b4fb3a-307ff70000004a6a-57-5948c4698cd7 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.D3.19050.964C8495; Tue, 20 Jun 2017 08:45:00 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0339.000; Tue, 20 Jun 2017 08:44:57 +0200 From: Christer Holmberg To: Christer Holmberg , Eric Rescorla , Roman Shpount , Paul Kyzivat , "mmusic@ietf.org" CC: Ben Campbell Thread-Topic: [MMUSIC] actpass redux- suggestion & PR Thread-Index: AQHS6RekZVZHHpF0pkGf6nWRHITil6ItYAYA Date: Tue, 20 Jun 2017 06:44:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D56E9E2F1E854christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUyM2J7oG7OEY9Ig8YDfBbzO0+zW6x4fY7d YuryxywWD370sllcf7qLxYHVY/LjOYweS5b8ZPKYtfMJC5Dbxuyx9e9ftgDWKC6blNSczLLU In27BK6M5QvnsxQ0a1dM/rqGtYFxl2oXIyeHhICJxN/LU5i7GLk4hASOMErcunOJFSQhJLCY UWLGXeMuRg4ONgELie5/2iA1IgIXGCWe/nzKBFLDLKAksW/7EbB6YaBBH4/uBYuLCJhKTJi9 lR3CNpK4e3QpG4jNIqAq8WDaGhYQm1fAWqLhay8zxC5riZM/94HZnAI2EidO3gWbySggJvH9 1BqoXeISt57MZ4I4WkBiyZ7zzBC2qMTLx/9YQe4UFdCTeLffEyKsJPFjwyUWiNYEibdv5rNC rBWUODnzCcsERtFZSKbOQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceQ/VaSxyduRVFzQJG jlWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgRF8cMtvqx2MB587HmIU4GBU4uF9eNgjUog1 say4MvcQowQHs5II79PlQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8DvsuRAgJpCeWpGanphak FsFkmTg4pRoY566fqHDb/sYOy9zche47u1UbvNQ1FLVZLKUOl29bzOowNz3y8Ne3anO+fmpf ufLpCuviu50C5+T/yB7aLasT9aCfza7U/5bs3MdT55WyzXabm3XDrrTnXvr2SucFEYyLZ/L5 e138nF3+mevXm3nPYy9GXV4kJPcqq9HU5/Hpfa9Lz3d+l2o5oMRSnJFoqMVcVJwIAOvvPkjc AgAA Archived-At: Subject: Re: [MMUSIC] actpass redux- suggestion & PR X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 06:45:07 -0000 --_000_D56E9E2F1E854christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I intend to merge the PR, and submit a new version of the draft tomorrow (W= ednesday). Are people ok with the PR? It may not be exactly what everyone w= ant, but hopefully it is something that everyone can live with. On Thursday I will leave for 2 week vacation, so I REALLY want the new vers= ion out before that, so that we can move the draft forward. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Monday 19 June 2017 at 19:18 To: Eric Rescorla >, Roman Shpount >, Paul Kyzivat >, "mmusic@ietf.org" > Cc: Ben Campbell > Subject: Re: [MMUSIC] actpass redux- suggestion & PR Hi, Taking into account the input from Ekr, Roman, Cullen and Paul, what about = the following suggestion: 1. In the initial offer, and endpoint MUST send actpass 2. In and subsequent offer, and endpoint MUST send actpass, or a value refl= ecting the currently negotiated value// This is what the draft currently sa= ys 3. An endpoint MUST accept receiving a non-actpass value, in order to be ba= ckward compatible with legacy devices that use such values. PR: https://github.com/cdh4u/draft-dtls-sdp/pull/32 Regards, Christer --_000_D56E9E2F1E854christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I intend to merge the PR, and submit a new version of the draft tomorr= ow (Wednesday). Are people ok with the PR? It may not be exactly what every= one want, but hopefully it is something that everyone can live with.

On Thursday I will leave for 2 week vacation, so I REALLY want the new= version out before that, so that we can move the draft forward.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Monday 19 June 2017 at 19:18<= br> To: Eric Rescorla <ekr@rtfm.com>, Roman Shpount <rshpount@turbobridge.com>, Paul Kyzivat = <paul.kyzivat@comcast.net>, "mmusic@ietf.org" <mmusic@ietf.org>
Cc: Ben Campbell <ben@nostrum.com>
Subject: Re: [MMUSIC] actpass redux= - suggestion & PR


Hi,

Taking into account the input from Ekr, Roman, Cullen and Paul, what a= bout the following suggestion:

1. In = the initial offer, and endpoint MUST send actpass
2. In = and subsequent offer, and endpoint MUST send actpass, or a value reflecting= the currently negotiated value// This is what the draft currently says
3. An = endpoint MUST accept receiving a non-actpass value, in order to be backward= compatible with legacy devices that use such values.


Regards,

Christer
 --_000_D56E9E2F1E854christerholmbergericssoncom_-- From nobody Wed Jun 21 06:27:34 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C48D2129462; Wed, 21 Jun 2017 06:27:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149805164576.15928.11888929595220492572@ietfa.amsl.com> Date: Wed, 21 Jun 2017 06:27:25 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-25.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:27:26 -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-25.txt Pages : 24 Date : 2017-06-21 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a TLS connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-25 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 06:30:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526E6129B0E; Wed, 21 Jun 2017 06:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiR_LgU1Mc1U; Wed, 21 Jun 2017 06:30:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14BAD129B04; Wed, 21 Jun 2017 06:30:39 -0700 (PDT) X-AuditID: c1b4fb25-545149a0000046b1-e0-594a74fe2485 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.B7.18097.EF47A495; Wed, 21 Jun 2017 15:30:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Wed, 21 Jun 2017 15:30:37 +0200 From: Christer Holmberg To: "mmusic@ietf.org" CC: "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-dtls-25 Thread-Index: AQHS6pKQ9KPoh7CYAkKwI+Kqc4dkRg== Date: Wed, 21 Jun 2017 13:30:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D5704FA91E9FFchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7hO6/Eq9Ig5YbfBbzO0+zW5zfuZ7J YuryxywOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8bb/6IFZ7gqPq74wtbAOJ+zi5GT Q0LAROLD811MXYxcHEICRxglVjxdCeUsZpRomPqevYuRg4NNwEKi+582SIOIgLrE1709zCA2 s0C4xJw3Z1hBbGEBS4mNR+6wQ9TYScxqP8sCYetJ3N/6mRHEZhFQlTg+cR4TiM0rYC1x5uIz sDmMAmIS30+tYYKYKS5x68l8JojjBCSW7DnPDGGLSrx8/I8V5BxRoJnv9ntChBUlPr7axwjR miCx9eUrZojxghInZz5hmcAoPAvJ1FlIymYhKYOIG0i8PzefGcLWlli28DWUrS+x8ctZRgjb WuLQT5h6iJoFjByrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj6+CW36o7GC+/cTzEKMDB qMTD2xLtFSnEmlhWXJl7iFGCg1lJhDe8ECjEm5JYWZValB9fVJqTWnyIUZqDRUmc13HfhQgh gfTEktTs1NSC1CKYLBMHp1QDo8yWGl/DjSaX703a0l/IUr5fjOmH1f3E4Otrrpy+upQtvJFn t/vKmXJhUqVTcpksWuSX+e3jzd42d9s0q+N11/gPcFi3tla5eSyVePgnjeu9ypJ7/NvtF6gJ 3f9lODl5T9z6f3Y+cud8mWoVhGr+n1X7k83ir7T4eOKza48Mfwnlrl04ZU6ouhJLcUaioRZz UXEiAGInwnmqAgAA Archived-At: Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-dtls-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:30:46 -0000 --_000_D5704FA91E9FFchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-25) of draft-ietf-mmusic-sdp-dtls. The new version addresses the media-handling-before-fingerprint issue and a= ctpass issue. There are currently no other open issues. Regards, Christer --_000_D5704FA91E9FFchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-25) of draft-ietf-mmusic-sdp-dtls.

The new version addresses the media-handling-before-fingerprint issue = and actpass issue.

There are currently no other open issues.

Regards,

Christer
--_000_D5704FA91E9FFchristerholmbergericssoncom_-- From nobody Wed Jun 21 14:40:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04088127873 for ; Wed, 21 Jun 2017 14:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXUfWo9lrXVs for ; Wed, 21 Jun 2017 14:40:03 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45343124217 for ; Wed, 21 Jun 2017 14:40:03 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-02v.sys.comcast.net with SMTP id NnJkdeloKBHfPNnM2dXUIM; Wed, 21 Jun 2017 21:40:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1498081202; bh=LtgUgfgwnoS10Bj/YDgubs/gv8FkTAnZqsDobJrRDXo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SzxLXEk5Oya3x/NzBS9jQDNXS2lmvM3SjkUXm01YsMOkmfKIMIfbs0yXJFk/QRKIn EkU/SbOvEGi9duD5Ya4fFFJlXT7X/81darK2DrynCR6E5tVlx63rMufrgsv8gt3AoM Baje1MYrE9IQn/hl8E6iZwyfHJwCe2wzdYlOPB2Z7e9RYxCCla+ndxJYrVyN+gnJOI Dr5fmB6iaL/SACYFRPmOhS5tWEBJQSvcsuP2yjnO1HpyES58jzNLzIILM2CozuAkHd 9Q18Tqr+C8mCVqeC1qcdnjPPcfA+VoCgrEA+MiJrBKlVKaGcQ8gTL6RGgzjWRAE421 HwguqgozPGXsQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-20v.sys.comcast.net with SMTP id NnM1divRbULyFNnM1dfL1l; Wed, 21 Jun 2017 21:40:02 +0000 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: Date: Wed, 21 Jun 2017 17:40:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfAajO5VynT8iwrmFwIfdKEgNKfdLbTLNyXuZlFqrAlshztNhbUBxIXai1xSu6bzTU6CaTiJdmPl8FZzc9Wj97JjiTLO2g3v1aZnBfiHhcCvo2TF3aiiZ i1ppZB1CiO7XdWnyDOpUyHKw0v7grfaA5GGmO1r+zUYPpmaAyiDWSa4R Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-dtls-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:40:05 -0000 Christer, There is an issue in the new Note in section 5.1 - a bunch of encoded characters. Thanks, Paul On 6/21/17 9:30 AM, Christer Holmberg wrote: > Hi, > > I’ve submitted a new version (-25) of draft-ietf-mmusic-sdp-dtls. > > The new version addresses the media-handling-before-fingerprint issue > and actpass issue. > > There are currently no other open issues. > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Jun 21 16:39:01 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5378312426E; Wed, 21 Jun 2017 16:39:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149808834030.30646.15372335842482120198@ietfa.amsl.com> Date: Wed, 21 Jun 2017 16:39:00 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-20.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 23:39: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 : SDP: Session Description Protocol Authors : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-20.txt Pages : 61 Date : 2017-06-21 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-20 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 16:39:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED8F12426E for ; Wed, 21 Jun 2017 16:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNwcPVwq8pTB for ; Wed, 21 Jun 2017 16:39:35 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 B53C81200CF for ; Wed, 21 Jun 2017 16:39:35 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 84so150503ybe.0 for ; Wed, 21 Jun 2017 16:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6uYqiEQHcEs7cnMCWMjy0O0L7eFZ4/Daq7sAS0aQ7fM=; b=062fMNhx7aqA7922rOmYP/4Df+eTtDtkQTrBiK+nsq2MTqc7oDBhFahRb8Fl2wday8 IK9W+vCaGTMuohPLiBmDoSl0DPDh8XWArYeu7vIkxBYSo8icVeeWM3riiWJyiAZDgIfj 1to85LsoKKbwOW7fu73tgydCAbsmxLu+hbGppF0qhwovURV5Fw9NPM7qOX6O90HYMgLx 8So5HKTZazHXSdhAOt5kc4OTuDOqIu2aHx2uMyzlJoQrTDxs0oMRlSE9/d0MQ7td5168 qNwauCC6ZqfRyK+4Ymefe1bJtyNO5TWiz5hjRxTaURUJCFIj6pcDhnpXm2bx9whsWrk/ AHmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6uYqiEQHcEs7cnMCWMjy0O0L7eFZ4/Daq7sAS0aQ7fM=; b=e+DvaZ3jB0pUWQu9pE20Zh4SJszlQKg+lKQiyKIX+0ikXZqmewRARYPGQY6eXzkbkh s98U2vPLFsvPz6rqPph4WJVirXYVeMyIuWi3joAqMRGS3W9fVoGE7dw4XmDsSJir+gH6 eyT7ZTu9YTDuPFDCGTw3Z+CkXKswAD6PgJ1JZRWybOUuH9reEhoqXkJS58bXvBGPmWl/ yd3qigKF4Zm0y2Bm26mCcOVWyfmFAh6AtPbEa5qMIlpPIBw+6alhzD9pC90viD/kdh0U c3/KW+QRxQjgshpy3AdId12J2dLDcC5r9OvAIpciIJc4ixhGKro2eeI4PWBmlecNiht6 2VxQ== X-Gm-Message-State: AKS2vOyFr3RMy6qD70A/Iqwb2IfxnhD3P+NIJSPouzDW3x3V9MA/dTlf 8MBlBhVGIRZ6kyP2DPaeIuRvi1Sz80yc X-Received: by 10.37.75.5 with SMTP id y5mr3993025yba.257.1498088374921; Wed, 21 Jun 2017 16:39:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.91.70 with HTTP; Wed, 21 Jun 2017 16:39:34 -0700 (PDT) In-Reply-To: References: <149765179618.24205.7010922835529746440.idtracker@ietfa.amsl.com> From: "Ali C. Begen" Date: Thu, 22 Jun 2017 02:39:34 +0300 Message-ID: To: Paul Kyzivat Cc: mmusic Content-Type: multipart/alternative; boundary="94eb2c0941766e027b055280e167" Archived-At: Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-19.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 23:39:38 -0000 --94eb2c0941766e027b055280e167 Content-Type: text/plain; charset="UTF-8" Hi Paul Thanks for catching the error. It is fixed and submitted now. -acbegen On Mon, Jun 19, 2017 at 6:02 PM, Paul Kyzivat wrote: > Hi Ali, > > On 6/16/17 6:32 PM, Ali C. Begen wrote: > >> Hi everyone >> >> There have been some comments on and off the list regarding the 4566bis >> draft and with this update, I am hoping that I made all the changed asked >> for. There were a few errors that were taken care of, some ABNF syntax has >> been improved, references have been updated, etc. >> >> https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rfc4566b >> is-18&url2=draft-ietf-mmusic-rfc4566bis-19 >> >> Please check whether you have outstanding issues or not. I saw that the >> chairs updated the milestone for this draft, and from my perspective, the >> draft is ready to go to WGLC. >> > > I like the change to the grammar that moves the notation for > optionality/repetition of individual fields from the definition of those > fields to the overall definition of the session-description: > > session-description = proto-version > origin-field > session-name-field > [information-field] > [uri-field] > *email-fields > *phone-fields > [connection-field] > *bandwidth-fields > 1*time-fields > [key-field] > *attribute-fields > *media-descriptions > > However, this change induced a bug in the definition of media-descriptions: > > media-descriptions = media-field > information-field > *connection-field > bandwidth-fields > key-field > attribute-fields > > This needs the same changes made to session-description. So this needs to > be changed to: > > media-descriptions = media-field > [information-field] > *connection-field > *bandwidth-fields > [key-field] > *attribute-fields > > Also this change does result in some very odd naming, where the names of > some fields are plural but now ought to be singular. These ought to be > fixed. Specifically: > > email-fields => email-field > phone-fields => phone-field > bandwidth-fields => bandwidth-field > time-fields => time-field > attribute-fields => attribute-field > media-descriptions => media-description > > Otherwise the new version seems good to me. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c0941766e027b055280e167 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul

Thanks for catching the error. = It is fixed and submitted now.

-acbegen

On Mon, Jun 19, = 2017 at 6:02 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
Hi Ali,

On 6/16/17 6:32 PM, Ali C. Begen wrote:
Hi everyone

There have been some comments on and off the list regarding the 4566bis dra= ft and with this update, I am hoping that I made all the changed asked for.= There were a few errors that were taken care of, some ABNF syntax has been= improved, references have been updated, etc.

https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-rfc4= 566bis-18&url2=3Ddraft-ietf-mmusic-rfc4566bis-19

Please check whether you have outstanding issues or not. I saw that the cha= irs updated the milestone for this draft, and from my perspective, the draf= t is ready to go to WGLC.

 I like the change to the grammar that moves the notation for optionality/re= petition of individual fields from the definition of those fields to the ov= erall definition of the session-description:

=C2=A0 =C2=A0session-description =3D proto-version
=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=A0origin-field
=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=A0session-name-field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[information-field]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[uri-field]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*email-fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*phone-fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[connection-field]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*bandwidth-fields
=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=A01*time-fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[key-field]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*attribute-fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*media-descriptions

However, this change induced a bug in the definition of media-descriptions:=

=C2=A0 =C2=A0media-descriptions =3D=C2=A0 media-field
=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=A0information-field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*connection-field
=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=A0bandwidth-fields
=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=A0key-field
=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=A0attribute-fields

This needs the same changes made to session-description. So this needs to b= e changed to:

=C2=A0 =C2=A0media-descriptions =3D=C2=A0 media-field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[information-field]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*connection-field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*bandwidth-fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[key-field]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0*attribute-fields

Also this change does result in some very odd naming, where the names of so= me fields are plural but now ought to be singular. These ought to be fixed.= Specifically:

email-fields =3D> email-field
phone-fields =3D> phone-field
bandwidth-fields =3D> bandwidth-field
time-fields =3D> time-field
attribute-fields =3D> attribute-field
media-descriptions =3D> media-description

Otherwise the new version seems good to me.

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

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

--94eb2c0941766e027b055280e167-- From nobody Wed Jun 21 22:38:16 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 597221200CF; Wed, 21 Jun 2017 22:38:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149810988933.30434.6338603326774938537@ietfa.amsl.com> Date: Wed, 21 Jun 2017 22:38:09 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-26.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:38: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 : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-26.txt Pages : 24 Date : 2017-06-21 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a TLS connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-26 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-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 Wed Jun 21 22:39:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4EA124D37 for ; Wed, 21 Jun 2017 22:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11Dh0724Wlj0 for ; Wed, 21 Jun 2017 22:39:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E991200CF for ; Wed, 21 Jun 2017 22:39:18 -0700 (PDT) X-AuditID: c1b4fb25-167ff700000046b1-c7-594b580366f9 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 93.95.18097.3085B495; Thu, 22 Jun 2017 07:39:16 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Thu, 22 Jun 2017 07:39:15 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-25 Thread-Index: AQHS6xnhshxtLqsx10i6QAR5Td0+iQ== Date: Thu, 22 Jun 2017 05:39:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7qC5LhHekwZ89hhZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4su4we8FTtopft58zNTCeZO1i5OSQEDCR aGq8wwhiCwkcYZS481+9i5ELyF7MKPF8eg9bFyMHB5uAhUT3P22QGhGBIIm5jV+YQGxhATeJ s303mSHi7hL7z/QwQth6EtPmvgOrYRFQldjx5C0zyBheAWuJlx85QcKMAmIS30+tASthFhCX uPVkPhPEOQISS/acZ4awRSVePv7HCtIqCjTy3X5PEFNCQFFieb8cRKeexI2pU9ggbGuJ/SuW sEDY2hLLFr4Gm8IrIChxcuYTlgmMIrOQLJuFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyFgv tSgzubg4P08vL7VkEyMwPg5u+a26g/HyG8dDjAIcjEo8vLr23pFCrIllxZW5hxglOJiVRHg1 XIBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MJqVPVBM UK0wZHfs+5QwN+ZrR86q6CaxR19EhLZ2vrbXPLz8w3tBnwMJkX4cEg0nnjx+xy9+5WSrYmpd wdEX3XPW/e3sfPlb7ucv8y9rAr/fihZK0pdik97VcuVi8b+5zp/vcz1cxmHlzTop6d7BXwt2 aYtHtjqfWzPlzU7rW8b2z9vdEjhuSymxFGckGmoxFxUnAgCCPRNGiwIAAA== Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:39:20 -0000 Hi, >There is an issue in the new Note in section 5.1 - a bunch of encoded >characters. Fixed (together with a few editorial nits), and version-26 submitted. Thanks! Regards, Christer > > Thanks, > Paul > >On 6/21/17 9:30 AM, Christer Holmberg wrote: >> Hi, >>=20 >> I=B9ve submitted a new version (-25) of draft-ietf-mmusic-sdp-dtls. >>=20 >> The new version addresses the media-handling-before-fingerprint issue >> and actpass issue. >>=20 >> There are currently no other open issues. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jun 22 00:53:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3B6128990 for ; Thu, 22 Jun 2017 00:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhb-whj-GMeL for ; Thu, 22 Jun 2017 00:53:47 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697B2128799 for ; Thu, 22 Jun 2017 00:53:44 -0700 (PDT) X-Halon-ID: e6d5c878-571f-11e7-b254-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id e6d5c878-571f-11e7-b254-005056917f90; Thu, 22 Jun 2017 09:53:40 +0200 (CEST) To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <149808834030.30646.15372335842482120198@ietfa.amsl.com> Cc: mmusic@ietf.org From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <16ef75c9-0169-6dd6-011a-db948df8fdbe@omnitor.se> Date: Thu, 22 Jun 2017 09:53:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149808834030.30646.15372335842482120198@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------279A2D86C550181769CCB4EE" Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-20.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 07:53:49 -0000 This is a multi-part message in MIME format. --------------279A2D86C550181769CCB4EE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, A couple of observations: Observation 1: Comments with questions in rtpmap specification. In section 6.6 rtpmap, there is the following syntax description: ----------------------------- rtpmap-value = payload-type SP encoding-name "/" clock-rate [ "/" encoding-params ] payload-type = zero-based-integer encoding-name = token clock-rate = integer ; do we want to define a limited range for this? encoding-params = channels ; 4566 is vague about what this can be. RFC4855 seems to be ; the authoritative source, and only allows the ; value of the media subtype "channels" parameter - the ; number of audio channels. ; Does anyone think this can be used for something else??? ; (The implication that multiple parameters might be included ; seems a misdirection - additional parameters are ; to go into a=fmtp.) ; Does anyone have an example of other parameters ; using this field? channels = integer ; Is there any reason to make this less restrictive? ------------------- The comments look very much as intended to be questions to be resolved before publication. If there are no answers on the questions, you might want to settle the syntax to the current and delete the comments or change them to explanations. Or, if you want to keep the questions until the last call, it might be good to collect them in an editors' note, so they are not forgotten. ------------------------------------------------------------------------------------- Observation 2: Number-of-addresses in multicast addresses In section 9, syntax description of IP4-multicast and IP6-multicast, there is an unexplained integer parameter at the end. The convention seems to be that parameters get a name indicating its use, and then on another line the parameter syntax is defined. The parameter is the number-of-addresses specified in section 5.7. Therefore I suggest to insert a name "numaddr" in place of the "integer" and explain its syntax in a separate line. -----------current text---------------------------------- IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ] ; IP4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = IP6-address [ "/" integer ] ; IP6 address starting with FF -----------proposed new text--------------------- IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" numaddr ] ; IP4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = IP6-address [ "/" numaddr ] ; IP6 address starting with FF numaddr = integer --------------end of change-------------------------- The draft looks good. Regards Gunnar ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se Den 2017-06-22 kl. 01:39, skrev internet-drafts@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 of the IETF. > > Title : SDP: Session Description Protocol > Authors : Mark Handley > Van Jacobson > Colin Perkins > Ali Begen > Filename : draft-ietf-mmusic-rfc4566bis-20.txt > Pages : 61 > Date : 2017-06-21 > > Abstract: > This memo defines the Session Description Protocol (SDP). SDP is > intended for describing multimedia sessions for the purposes of > session announcement, session invitation, and other forms of > multimedia session initiation. This document obsoletes RFC 4566. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-20 > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-20 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-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. > > 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 -- --------------279A2D86C550181769CCB4EE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Ali,

A couple of observations:


Observation 1: Comments with questions in rtpmap specification.

In section 6.6 rtpmap, there is the following syntax description:

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

         rtpmap-value = payload-type SP encoding-name
           "/" clock-rate [ "/" encoding-params ]
         payload-type = zero-based-integer
         encoding-name = token
         clock-rate = integer
           ; do we want to define a limited range for this?
         encoding-params = channels
           ; 4566 is vague about what this can be. RFC4855 seems to be
           ; the authoritative source, and only allows the
           ; value of the media subtype "channels" parameter - the
           ; number of audio channels.
           ; Does anyone think this can be used for something else???
           ; (The implication that multiple parameters might be included
           ; seems a misdirection - additional parameters are
           ; to go into a=fmtp.)
           ; Does anyone have an example of other parameters
           ; using this field?
         channels = integer
           ; Is there any reason to make this less restrictive?
-------------------

The comments look very much as intended to be questions to be resolved before publication. 
If there are no answers on the questions, you might want to settle the syntax to the current and delete the comments or change them to explanations. 
Or, if you want to keep the questions until the last call, it might be good to collect them in an editors' note, so they are not forgotten.
-------------------------------------------------------------------------------------

Observation 2: Number-of-addresses in multicast addresses

In section 9, syntax description of IP4-multicast and IP6-multicast, there is an unexplained integer parameter at the end. The convention seems to be that parameters get a name indicating its use, and then on another line the parameter syntax is defined. The parameter is the number-of-addresses specified in section 5.7. Therefore I suggest to insert a name "numaddr" in place of the "integer" and explain its syntax in a separate line.  

-----------current text----------------------------------
IP4-multicast =         m1 3( "." decimal-uchar )
                        "/" ttl [ "/" integer ]
                        ; IP4 multicast addresses may be in the
                        ; range 224.0.0.0 to 239.255.255.255
                        m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
                        ("23" DIGIT )

 IP6-multicast =        IP6-address [ "/" integer ]
                        ; IP6 address starting with FF
-----------proposed new text---------------------
IP4-multicast =         m1 3( "." decimal-uchar )
                        "/" ttl [ "/" numaddr ]
                        ; IP4 multicast addresses may be in the
                        ; range 224.0.0.0 to 239.255.255.255
                        m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
                        ("23" DIGIT )

 IP6-multicast =        IP6-address [ "/" numaddr ]
                        ; IP6 address starting with FF

numaddr =	integer
--------------end of change--------------------------



The draft looks good.

Regards
Gunnar
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se

Den 2017-06-22 kl. 01:39, skrev internet-drafts@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 of the IETF.

        Title           : SDP: Session Description Protocol
        Authors         : Mark Handley
                          Van Jacobson
                          Colin Perkins
                          Ali Begen
	Filename        : draft-ietf-mmusic-rfc4566bis-20.txt
	Pages           : 61
	Date            : 2017-06-21

Abstract:
   This memo defines the Session Description Protocol (SDP).  SDP is
   intended for describing multimedia sessions for the purposes of
   session announcement, session invitation, and other forms of
   multimedia session initiation.  This document obsoletes RFC 4566.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-20
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-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.

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


--
--------------279A2D86C550181769CCB4EE-- From nobody Thu Jun 22 12:16:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83F6126B7E for ; Thu, 22 Jun 2017 12:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBwFtb2kSwYm for ; Thu, 22 Jun 2017 12:16:23 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE05E124D85 for ; Thu, 22 Jun 2017 12:16:22 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-05v.sys.comcast.net with SMTP id O7Zmdhbo7zz3dO7aYdUMKt; Thu, 22 Jun 2017 19:16:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1498158982; bh=jHQGVaQ+JiVAg5aFmxZ2jTIb6BjZBL5a37GBBA0IbzU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=K/QjRPv/BGNHXjMrRgyZnUqoM9rYwGwGi8zDItg3AGMM93T/x3Lc6pX+kzoUOafZ5 HIrc1yCYi1yExpL0TrFa7A0lGp0M6ut3mvXQt6immcjFXDdxXVReCW3oqt1swEdmrQ g8ArCg/9fDD6CJAXzpQdQW48skCLVobwoaVMiQsS33+2VjXiyJPFrAdk6UpB6xr3so SEWp4vCSMJBw3FBbN2er23Aq2IrO+ts+v1qAi+XHicnmXlErhERaYkAnaT6kaOJxmY 2hE2vNUiTDBRx/aqtA6wSvrDcEPovMjb0D6KWSl91PXn6mVKD0xOkAqGVQFcGHlMrP udtpMh+PA7I8Q== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-16v.sys.comcast.net with SMTP id O7aXdFLLZ96jtO7aXd5YPn; Thu, 22 Jun 2017 19:16:22 +0000 To: mmusic@ietf.org References: <149765179618.24205.7010922835529746440.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Thu, 22 Jun 2017 15:16:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLqVQpnxG8OtJVnJRPdYepLzdQsN0cP+1IRR4qG2g3b9Z4bzoZJ03JrFTlhKCcmD8CA2k4PgAZNX/WaSoHMIWer+UwYgYmDfP4DFZKLKHCz9BZOTCVve 3mSfeVc/obMSeft+09SusuFI4UUZb3c92pprvsR5h2u7+9ZS1q3ZllT9 Archived-At: Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-20.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 19:16:25 -0000 One thing you missed in the ABNF def of media-description: s/*attribute-fields/*attribute-field/ Otherwise looks good. Thanks, Paul On 6/21/17 7:39 PM, Ali C. Begen wrote: > Hi Paul > > Thanks for catching the error. It is fixed and submitted now. > > -acbegen > > On Mon, Jun 19, 2017 at 6:02 PM, Paul Kyzivat > wrote: > > Hi Ali, > > On 6/16/17 6:32 PM, Ali C. Begen wrote: > > Hi everyone > > There have been some comments on and off the list regarding the > 4566bis draft and with this update, I am hoping that I made all > the changed asked for. There were a few errors that were taken > care of, some ABNF syntax has been improved, references have > been updated, etc. > > https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rfc4566bis-18&url2=draft-ietf-mmusic-rfc4566bis-19 > > > Please check whether you have outstanding issues or not. I saw > that the chairs updated the milestone for this draft, and from > my perspective, the draft is ready to go to WGLC. > > > I like the change to the grammar that moves the notation for > optionality/repetition of individual fields from the definition of > those fields to the overall definition of the session-description: > > session-description = proto-version > origin-field > session-name-field > [information-field] > [uri-field] > *email-fields > *phone-fields > [connection-field] > *bandwidth-fields > 1*time-fields > [key-field] > *attribute-fields > *media-descriptions > > However, this change induced a bug in the definition of > media-descriptions: > > media-descriptions = media-field > information-field > *connection-field > bandwidth-fields > key-field > attribute-fields > > This needs the same changes made to session-description. So this > needs to be changed to: > > media-descriptions = media-field > [information-field] > *connection-field > *bandwidth-fields > [key-field] > *attribute-fields > > Also this change does result in some very odd naming, where the > names of some fields are plural but now ought to be singular. These > ought to be fixed. Specifically: > > email-fields => email-field > phone-fields => phone-field > bandwidth-fields => bandwidth-field > time-fields => time-field > attribute-fields => attribute-field > media-descriptions => media-description > > Otherwise the new version seems good to me. > > 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 Fri Jun 23 17:09:28 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A65AD129B66; Fri, 23 Jun 2017 17:07:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ben@nostrum.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282167.7840.10565697114128039096.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:01 -0700 Archived-At: Subject: [MMUSIC] mmusic - Requested session has been scheduled for IETF 99 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:02 -0000 Dear Flemming Andreasen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mmusic Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room Name: Athens/Barcelona size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Multiparty Multimedia Session Control Area Name: Applications and Real-Time Area Session Requester: Flemming Andreasen Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: quic perc tls ice httpbis rtcweb avtcore avtext sipcore dispatch payload core dots sipbrandy Second Priority: clue xrblock rmcat stir tram sfc regext People who must be present: Ben Campbell Flemming Andreasen Bo Burman Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 27 22:38:36 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A27128DF2; Tue, 27 Jun 2017 22:38:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149862831524.18209.8119852542592020502@ietfa.amsl.com> Date: Tue, 27 Jun 2017 22:38:35 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 05:38: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 : Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-13.txt Pages : 43 Date : 2017-06-27 Abstract: This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 22:44:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29169128D3E for ; Tue, 27 Jun 2017 22:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXv3vUq2ArPT for ; Tue, 27 Jun 2017 22:43:59 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 B750D128DF2 for ; Tue, 27 Jun 2017 22:43:59 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id r62so42706004qkf.0 for ; Tue, 27 Jun 2017 22:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qTz4oz8W+E7gDN6RTjIXCGtpU0wkdBf02lxLV44rRfo=; b=r4D6p9XG22UBBGXm49eahmTCpP38cNLDfBkvdP/DqGLP5TM9QiFma1yghORRvCW/KM RHtXbH+/1/crLSfzuQ4HgsSFTQoD+KoJcSueGcsi7bmwczmAC3W2b87Ihs7zslSznMSs 6NewdwWo/eNziCWNO9d80e2uuffK9zoIOVFGSIs4B/LeXN80V/Ni/SIqSq7cAG4IWJU3 kFUmtZL902GCgSnw3sFlidrez/g80dpZUzS1AadAbeiOyYZLXV/w/48Y0eJrs+3vRlvD tuG/JY44/9bS6V2Gz1jNG6qnwGrho1yc2vuGfbvLO8CzK3KDqvICkRL9Zpz/HksXptme k3IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qTz4oz8W+E7gDN6RTjIXCGtpU0wkdBf02lxLV44rRfo=; b=nzbJy9KsHENAJwRdG/a6XmmeITrVRcZnnr7YJsq5joOtPq0WPzTcDIUk2hUgNnm697 OsaY7upFToHZn7y/96EmKH3NBQ3xpw9F8x099HFxr6D0L7u4rRkSRKfn0VWB5d+cIX83 kYNy7Qnk1l9BK0Thj8mBFuTpbqdysaLb1HlZlHOatNRg7Q2alQ9e0yh8iR/THJVKiTUb NeAr5s0zOl6732rpN3IM/ZgEDyYGpD5DfC6Ufm6tqlowQ6lpPs3OKT5iU9sUOOMNLH8B qiFSe+FXRIBozEB+NNA181zrb3JM/HiBbzDG+42qlXwEXNWCCT3Zd8NR+049D/1sD6Y8 xiQQ== X-Gm-Message-State: AKS2vOwifTHro82jwlwMqelncS6Rmu2AVuESG32F2sesSg1LTTsAldiF bKG28ndX1zyUaHhbtqx6lzTho7j2ZJkg X-Received: by 10.55.214.78 with SMTP id t75mr9947237qki.239.1498628638610; Tue, 27 Jun 2017 22:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.148.161 with HTTP; Tue, 27 Jun 2017 22:43:57 -0700 (PDT) In-Reply-To: <149862831524.18209.8119852542592020502@ietfa.amsl.com> References: <149862831524.18209.8119852542592020502@ietfa.amsl.com> From: Suhas Nandakumar Date: Tue, 27 Jun 2017 22:43:57 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary="001a1149ce6ea79af00552feabfa" Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 05:44:02 -0000 --001a1149ce6ea79af00552feabfa Content-Type: text/plain; charset="UTF-8" Hello All I have submitted version 13 of the ice-sip-sdp draft that incorporates the changes for the open issues from IETF 98, except for one that deals with the Default Candidate/Transport switch recommendations. Notable changes 1. Draft title has been updated to reflect SDP O/A procedures and not SIP 2. All SIP related text are moved into SIP Considerations Section 3. ice-options definition has been updated to reflect the notes from the meeting. please let me know your feedback Thanks Suhas On Tue, Jun 27, 2017 at 10:38 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 : Session Description Protocol (SDP) Offer/Answer > procedures for Interactive Connectivity Establishment (ICE) > Authors : Marc Petit-Huguenin > Ari Keranen > Suhas Nandakumar > Filename : draft-ietf-mmusic-ice-sip-sdp-13.txt > Pages : 43 > Date : 2017-06-27 > > Abstract: > This document describes Session Description Protocol (SDP) Offer/ > Answer procedures for carrying out Interactive Connectivity > Establishment (ICE) between the agents. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13 > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-13 > > > 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 > --001a1149ce6ea79af00552feabfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All

I have submitted v= ersion 13 of the ice-sip-sdp draft that incorporates the changes for the op= en issues from IETF 98, =C2=A0except for one that deals with the Default Ca= ndidate/Transport switch recommendations.

Notable = changes
1. Draft title has been updated to reflect SDP O/A proced= ures and not SIP
2. All SIP related text are moved into SIP Consi= derations Section
3. ice-options definition has been updated to r= eflect the notes from the meeting.


= please let me know your feedback

Thanks
= Suhas


On Tue, Jun 27, 2017 at 10:38 PM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
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:= Session Description Protocol (SDP) Offer/Answer procedures for Interactive= Connectivity Establishment (ICE)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-27

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


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

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

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


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

--001a1149ce6ea79af00552feabfa-- From nobody Thu Jun 29 02:00:21 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA3127B57; Thu, 29 Jun 2017 02:00:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149872681949.6567.14654001420652908376@ietfa.amsl.com> Date: Thu, 29 Jun 2017 02:00:19 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 09:00:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : SDP: Session Description Protocol Authors : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-21.txt Pages : 61 Date : 2017-06-29 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-21 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 29 02:02:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AAB12ECBC for ; Thu, 29 Jun 2017 02:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDPT7et_it29 for ; Thu, 29 Jun 2017 02:02:26 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 70EA612EB8C for ; Thu, 29 Jun 2017 02:02:26 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id j11so34265586ywa.2 for ; Thu, 29 Jun 2017 02:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t/MnnM/cT1Yb9TrhyiVGO7FBN9ZE+N9vx/OAHsnEboI=; b=uCU/AIY7XNNImiJ70sqF/kmBx6UJVTZhQB4PJh+iPD+mqFlBLcNpaR2lqqhTojXGBj b3NoJdcqh2p9RXoW0klZrWeeSSibBwtEuabdFsa8Ho6+uFNEKPX4gDDKC7mpYdwjRFIj MxOU9vknYACOqhy4nGXGvfsN1Yt7NoKVxf0o0W7HYjibUMPaGfYj30NfxIzGITI+G9u9 Ulx6WoEBPB3loJXo8HU4lBDAdqyPNl4SUGGL6mO/X6ud62Q1y76boUEk12vyOMyFyrbX Sie2p+m7ej6uF1SgL2QFDKMewC+0NZAsQ/Yx1RnCrkl//+jf8Y5t02rQmHJdR1yKC9PY vCRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t/MnnM/cT1Yb9TrhyiVGO7FBN9ZE+N9vx/OAHsnEboI=; b=U9Rsqc+jY1XbL/CUnKqq1110QX+XEQ1IbEahLj7aQSC2qOBC5D0ewv0bDsgzWKe4eN LC0fiyuzqi+QPaPVw0pH6VaNbyLxeJ8RdXOo93gbaC6+h2RG63tw5KL9GuoD3fflxAPH dSigod4exQI/FpkeFos6weoRryw0LclA4jaDyaESh00oGI2kNs1pqvPJhgGZM8HOvdhi oYqCuB5lcPWHOOhAz5LsPLBcz4JjUTccZSmNRDQBn10aV5rQXW4nTr36VtRSaW5My4VP 3c7l5k7oSzyYOC9Yf5+eT47BUzgRlBc4DQIo7zzn9QFvm1CpjrBpI6LYNaKHR0ulDvL2 2eqg== X-Gm-Message-State: AKS2vOxgROgWF2qbGgd/S387uMw3UKlaBgs9w11eYuB3zkG1mjnkhqco m6I4s7xQHsmjOqHE4t/ROKbA5D0Yvnmx X-Received: by 10.129.200.8 with SMTP id n8mr5457879ywi.163.1498726945520; Thu, 29 Jun 2017 02:02:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.91.70 with HTTP; Thu, 29 Jun 2017 02:02:25 -0700 (PDT) In-Reply-To: <149872681966.6567.11073635242816770442.idtracker@ietfa.amsl.com> References: <149872681966.6567.11073635242816770442.idtracker@ietfa.amsl.com> From: "Ali C. Begen" Date: Thu, 29 Jun 2017 12:02:25 +0300 Message-ID: To: mmusic Content-Type: multipart/alternative; boundary="089e0821f7d83414dd0553158f20" Archived-At: Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 09:02:28 -0000 --089e0821f7d83414dd0553158f20 Content-Type: text/plain; charset="UTF-8" Hi everyone This fixes Paul's and Gunnar's comments. -acbegen ---------- Forwarded message ---------- From: Date: Thu, Jun 29, 2017 at 12:00 PM Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-21.txt To: Colin Perkins , Mark Handley , Ali Begen , Van Jacobson A new version of I-D, draft-ietf-mmusic-rfc4566bis-21.txt has been successfully submitted by Ali Begen and posted to the IETF repository. Name: draft-ietf-mmusic-rfc4566bis Revision: 21 Title: SDP: Session Description Protocol Document date: 2017-06-29 Group: mmusic Pages: 61 URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic- rfc4566bis-21.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic- rfc4566bis/ Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-21 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-mmusic- rfc4566bis-21 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic- rfc4566bis-21 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e0821f7d83414dd0553158f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone

This fixes Paul's and G= unnar's comments.

-acbegen

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu,= Jun 29, 2017 at 12:00 PM
Subject: New Version Notification for draft-ie= tf-mmusic-rfc4566bis-21.txt
To: Colin Perkins <csp@csperkins.org>, Mark Handley <m.handley@cs.ucl.ac.uk>, Ali Begen <ali= .begen@networked.media>, Van Jacobson <van@parc.com>



A new version of I-D, draft-ietf-mmusic-rfc4566bis-21.txt
has been successfully submitted by Ali Begen and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-mmusic-rfc4566bis<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A021
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP: Session Description Protocol<= br> Document date:=C2=A0 2017-06-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 61
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-mmus= ic-rfc4566bis-21.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-21
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4= 566bis-21
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-21

Abstract:
=C2=A0 =C2=A0This memo defines the Session Description Protocol (SDP).=C2= =A0 SDP is
=C2=A0 =C2=A0intended for describing multimedia sessions for the purposes o= f
=C2=A0 =C2=A0session announcement, session invitation, and other forms of =C2=A0 =C2=A0multimedia session initiation.=C2=A0 This document obsoletes R= FC 4566.




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

The IETF Secretariat


--089e0821f7d83414dd0553158f20-- From nobody Thu Jun 29 09:54:53 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA0129B41 for ; Thu, 29 Jun 2017 09:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByOfSRUeN_sD for ; Thu, 29 Jun 2017 09:54:50 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E663126BF3 for ; Thu, 29 Jun 2017 09:54:50 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-09v.sys.comcast.net with SMTP id QciFdBvCdyGojQciPdECuZ; Thu, 29 Jun 2017 16:54:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1498755289; bh=cEYH9T2WZ8gYBGK79W5IBAqKzrHmVXPAw4kncPIxU+0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=CcfqcHn3xDFY8/yFosAyzQByQ7e6vtF1yYZIn2Uw/6+ODAlgRhjmMwugPmJio5CEE xWd9svoESP3DPGtTSiyKRoSvgfBX2aVhvnFmW/SmLIOqKX3S3oKifI2kOJ2Xk3/F5o A2zyJF7jhFUQSqR1u9nfIQ4xFbrJix52rNOt2jmV+dzdS4rFTum4il1OJFlrEMnOoo +VhoC++FuHyCxK+UNYKljKDiuS3nVB2L/fkzoOJXRAybDOCMldwnj+7UJmUEikFY7V rfdnxFMiM9S3i50c/3G6tVQU4HvZh+PBXmxXWPVt1fjRrAQQMFZe6oBB6UO4FYKOf8 O8XGnNzQVM8fg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-08v.sys.comcast.net with SMTP id QciOdOQ3UXZbjQciPdyY1v; Thu, 29 Jun 2017 16:54:49 +0000 To: mmusic@ietf.org References: <149872681966.6567.11073635242816770442.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Thu, 29 Jun 2017 12:54:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJFkTd655azOMc/awvcn87Xel0j78zY+Hqs6eQGV8FnB1wMTNnwrMDzLNyO1FUvWnRppdXu5M4lMd+TW8dt57ZNDHrLFCOpq4cyZhEZKJpuQXSbTGGaw TkMfH9KjvamNDqhVrkdAlAwGKjKeC8dmZzGcBeUFacIFVnho5ke/iEv5 Archived-At: Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 16:54:53 -0000 On 6/29/17 5:02 AM, Ali C. Begen wrote: > Hi everyone > > This fixes Paul's and Gunnar's comments. I ran this abnf through bap for a formal check and found a couple of things: 1) The definition of media-description still references bandwidth-fields rather than bandwidth-field. 2) The definition of key-type is not right - it seems to have lost a lot in the process of adopting the %s notation. To preserve compatibility with 4566 it should be: key-type = %s"prompt" / %s"clear:" text / %s"base64:" base64 / %s"uri:" uri Otherwise looks good to me. Thanks, Paul > -acbegen > > ---------- Forwarded message ---------- > From: ** > > Date: Thu, Jun 29, 2017 at 12:00 PM > Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-21.txt > To: Colin Perkins >, Mark > Handley >, Ali > Begen , Van Jacobson > > > > > A new version of I-D, draft-ietf-mmusic-rfc4566bis-21.txt > has been successfully submitted by Ali Begen and posted to the > IETF repository. > > Name: draft-ietf-mmusic-rfc4566bis > Revision: 21 > Title: SDP: Session Description Protocol > Document date: 2017-06-29 > Group: mmusic > Pages: 61 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-21.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-21 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-21 > > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-21 > > > Abstract: > This memo defines the Session Description Protocol (SDP). SDP is > intended for describing multimedia sessions for the purposes of > session announcement, session invitation, and other forms of > multimedia session initiation. This document obsoletes RFC 4566. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Jun 30 07:33:21 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED00C129A96; Fri, 30 Jun 2017 07:33:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149883319992.4610.8190200617990517791@ietfa.amsl.com> Date: Fri, 30 Jun 2017 07:33:19 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-22.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 14:33:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : SDP: Session Description Protocol Authors : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-22.txt Pages : 61 Date : 2017-06-30 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-22 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 30 07:34:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A5712EC23 for ; Fri, 30 Jun 2017 07:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLu3WyjPYC9h for ; Fri, 30 Jun 2017 07:34:11 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 0E8EA127868 for ; Fri, 30 Jun 2017 07:34:11 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id 84so38807347ybe.0 for ; Fri, 30 Jun 2017 07:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MJCkwX9T8fW0liz5MVFdUO5r2xz2miPXSLLxMOKvtt8=; b=xsR3EFqxsGZsnvTtXeZuZyoqqJ7lgTn0r5qBmcWkuWTIS9M/DFcPu3i5Z/c0tzFp6C IDyOF94bhPVl4lbSvF6TWmEWRmosj1JOkT6+s8RGPu+h6eGjSXiI7Sfx3QXPUuFvq9Kp TOxfAfXyz2XJZuKj+Hd3vhxyi+586KhWb6DdWhMubcVPh3NnlHeJL3kCnq6LBH4dNfLZ HfodqX+x6ZLK+8v5gMfX7bjYCnqWdqh/xQ13t0eZajFXiXEoBwI+f8LPqgHy8+LXtFf3 I//7ewMx/rt0rYohNXga7SsWIfSRuq0kgtqRUJx4694wjX/WxtEscG8WwH8J6DVc7LDN 9Gnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MJCkwX9T8fW0liz5MVFdUO5r2xz2miPXSLLxMOKvtt8=; b=pz3FJ6g/5ld1RrZKD0Km6KZylS99Q1dV69awOkbhhQX8YFP/c2qWt/VigO5q7c2RgX uxHe8qUHMDzS1x3UqZWDN7YCZ8PNO/P5nZT/CTZMrVNuTG6u1oJlDRgpqqgNJGcNBpma 8BJbnME3K3bVpsBsZcGeWbpagMQDAfzu3Hw0KVvQ+hHVcr3wQrZ6eC/9KWiP6QORTRPB ILdHvV2IB47jT9UF7Mw99yOsunD8t/th1QLKohEeFf8WPQiFvWIo9fHqWss///be1LYf mzvd0QRhbi5lyd5WQcWvUn67ZCVMFIAjUoezBAagWqyS5et/2QPvJXc0OSBq7Qasek4e z8Pg== X-Gm-Message-State: AIVw111Dcs6WZrk0fZsi4YCrcqs16ecwoakht34xPVyJOhGJO3ECM8e5 s4dj9Gif4xqWQ6YhFpTHcz9IPwgqnu+J X-Received: by 10.37.2.209 with SMTP id 200mr2097998ybc.4.1498833250358; Fri, 30 Jun 2017 07:34:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.91.194 with HTTP; Fri, 30 Jun 2017 07:34:09 -0700 (PDT) In-Reply-To: References: <149872681966.6567.11073635242816770442.idtracker@ietfa.amsl.com> From: "Ali C. Begen" Date: Fri, 30 Jun 2017 17:34:09 +0300 Message-ID: To: Paul Kyzivat Cc: mmusic Content-Type: multipart/alternative; boundary="001a113d49607747c505532e4f01" Archived-At: Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 14:34:14 -0000 --001a113d49607747c505532e4f01 Content-Type: text/plain; charset="UTF-8" Thanks Paul, v22 should be all good now. -acbegen On Thu, Jun 29, 2017 at 7:54 PM, Paul Kyzivat wrote: > On 6/29/17 5:02 AM, Ali C. Begen wrote: > >> Hi everyone >> >> This fixes Paul's and Gunnar's comments. >> > > I ran this abnf through bap for a formal check and found a couple of > things: > > 1) The definition of media-description still references bandwidth-fields > rather than bandwidth-field. > > 2) The definition of key-type is not right - it seems to have lost a lot > in the process of adopting the %s notation. To preserve compatibility with > 4566 it should be: > > key-type = %s"prompt" / > %s"clear:" text / > %s"base64:" base64 / > %s"uri:" uri > > > Otherwise looks good to me. > > Thanks, > Paul > > -acbegen >> >> ---------- Forwarded message ---------- >> From: ** > >> Date: Thu, Jun 29, 2017 at 12:00 PM >> Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-21.txt >> To: Colin Perkins >, Mark >> Handley >, Ali >> Begen , Van Jacobson > van@parc.com>> >> >> >> >> A new version of I-D, draft-ietf-mmusic-rfc4566bis-21.txt >> has been successfully submitted by Ali Begen and posted to the >> IETF repository. >> >> Name: draft-ietf-mmusic-rfc4566bis >> Revision: 21 >> Title: SDP: Session Description Protocol >> Document date: 2017-06-29 >> Group: mmusic >> Pages: 61 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc45 >> 66bis-21.txt > rfc4566bis-21.txt> >> Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ < >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/> >> Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-21 < >> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-21> >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4 >> 566bis-21 > 4566bis-21> >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-21 < >> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-21> >> >> Abstract: >> This memo defines the Session Description Protocol (SDP). SDP is >> intended for describing multimedia sessions for the purposes of >> session announcement, session invitation, and other forms of >> multimedia session initiation. This document obsoletes RFC 4566. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org < >> http://tools.ietf.org>. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> 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 > --001a113d49607747c505532e4f01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Paul, v22 should be all good now.

-acbegen

On Thu, Jun 29, 2017 at 7:54 PM, Paul Kyzivat <paul.kyzivat@co= mcast.net> wrote:
On 6/29/17 5:02 AM, Ali C. Begen wrote:
Hi everyone

This fixes Paul's and Gunnar's comments.

 I ran this abnf through bap for a formal check and found a couple of things= :

1) The definition of media-description still references bandwidth-fields ra= ther than bandwidth-field.

2) The definition of key-type is not right - it seems to have lost a lot in= the process of adopting the %s notation. To preserve compatibility with 45= 66 it should be:

=C2=A0 =C2=A0key-type =3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %s"= prompt" /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0%s"clear:" text=C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0%s"base64:" base64 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0%s"uri:" uri


Otherwise looks good to me.

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

-acbegen

---------- Forwarded message ----------
 From: ** <= internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Date: Thu, Jun 29, 2017 at 12:00 PM
Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-21.= txt
 To: Colin Perkins <csp@csperkins.org <mailto:csp@csperkins.org>>, Mark Handley <m.handley@cs.ucl.ac.uk = <mailto:m.ha= ndley@cs.ucl.ac.uk>>, Ali Begen <ali.begen@networked.medi= a>, Van Jacobson <v= an@parc.com <mailto:van@parc.com>>



A new version of I-D, draft-ietf-mmusic-rfc4566bis-21.txt
has been successfully submitted by Ali Begen and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-mmusic-rfc4566bis<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A021
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP: Session Description Protocol<= br> Document date:=C2=A0 2017-06-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mmusic
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 61
 URL: https://www.ietf.org/in= ternet-drafts/draft-ietf-mmusic-rfc4566bis-21.txt <https://www.ietf.org/internet-= drafts/draft-ietf-mmusic-rfc4566bis-21.txt>
Status: https://datatracker.ietf.org/d= oc/draft-ietf-mmusic-rfc4566bis/ <https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc456= 6bis/>
Htmlized: https://tools.ietf.org/html/dr<= wbr>aft-ietf-mmusic-rfc4566bis-21 <https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-21&= gt;
Htmlized: https://datatracker.i= etf.org/doc/html/draft-ietf-mmusic-rfc4566bis-21 <https://datatracker.ietf.org/doc/= html/draft-ietf-mmusic-rfc4566bis-21>
Diff: https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-mmusic-rfc4566bis-21 <https://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-mmusic-rfc4566bis-21>

Abstract:
=C2=A0 =C2=A0 This memo defines the Session Description Protocol (SDP).=C2= =A0 SDP is
=C2=A0 =C2=A0 intended for describing multimedia sessions for the purposes = of
=C2=A0 =C2=A0 session announcement, session invitation, and other forms of<= br> =C2=A0 =C2=A0 multimedia session initiation.=C2=A0 This document obsoletes = RFC 4566.




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 <http://= tools.ietf.org>.

The IETF Secretariat




_______________________________________________
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

--001a113d49607747c505532e4f01--