From nobody Wed Jun 1 00:52:12 2016 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 AA63612B054 for ; Wed, 1 Jun 2016 00:52:09 -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 0m3shDEmYcuz for ; Wed, 1 Jun 2016 00:52:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA1E12D12F for ; Wed, 1 Jun 2016 00:52:05 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-d3-574e942350a7 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4C.BF.12516.3249E475; Wed, 1 Jun 2016 09:52:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 09:51:51 +0200 From: Christer Holmberg To: Christer Holmberg , Martin Thomson , Roman Shpount Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 Thread-Index: AQHRtSvFlj02GsdUjEqN/h66uVwldJ/G2V+AgADkx4CAAGOpgIAAAaaAgAA66nD//+ymgIAAJPaQ///fdYCAABD5AIAABAeAgAAA6oCAAOs3gIABvEKAgAAif4CAACIs/oABJNaA///5JAAABOE4L///6iUAgAA3FYCAAAZ+gIAAKGoAgAAEbAD//8AqMIAAZnKAgAQpdQCAADi0gIAATZ/d///gtwD//9XcMAA44hMA///SSxD//6xPgP/+6GSA//1hVgD/+qtJAA== Date: Wed, 1 Jun 2016 07:51:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37FE6BB6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37FF0C94@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37FF3B58@ESESSMB209.ericsson.se> <2a554789-0668-74f0-4bb4-e2908daa5e91@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37FF4E53@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FBC2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FC74@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B38025D6F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-ID: <045029483A126143A5A726FCE6A2EF8C@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7nK7yFL9wg22njSyunfnHaDF1+WMW ixUbDrBazLgwldmBxePv+w9MHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBl/Pu9k LfjMWbF6203mBsZmji5GTg4JAROJc7t3M0PYYhIX7q1nA7GFBI4wSry5I9XFyAVkL2aUeDCp h6mLkYODTcBCovufNkhcRKCNUeJTfzs7SAOzgK/E+5/TwWxhAXuJq5cvM4HYIgIOEjvfXmWB aJjHJDG3byYrSIJFQEXiadMzMJtXwEriUv8XVohtPfwS747PATuJU8BaouP6ZTCbEei876fW MEFsE5e49WQ+E8TZAhJL9pyHekFU4uXjf2BDRQX0JL7cm8cIcrWEgKLE8n45iFYdiQW7P7FB 2NYS1/6egnpAW2LZwtfMEPcISpyc+YRlAqPELCTbZiFpn4WkfRaS9llI2hcwsq5iFC1OLS7O TTcy1kstykwuLs7P08tLLdnECIzXg1t+6+5gXP3a8RCjAAejEg9vAqdfuBBrYllxZe4hRgkO ZiURXsHJQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2M wY1XxbuXsTqG5mqHzPFbfOGsVvhOCXMVA1/NLhZ9Jz8jmydFpUIB9zwLj8lcTVvMci1mb3vT alZZ3nj/n3v7eY8ofLN37N5Ve0iSX/ft6zIWU11nTgF3HaZL3VWKZw/dYGyNYdpv93m6hUjV ovCL7jvflu3YoeUw6d/bFf0pbLJpi48suKXEUpyRaKjFXFScCAAEIKu/0wIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 07:52:09 -0000 Hi, The github pull request has now been updated with text based on the e-mail discussions: https://github.com/cdh4u/draft-4572-update/tree/sha-256-mandatory Note that the text does NOT yet say anything whether an answer can only contain the same hash functions as the answer. Regards, Christer On 01/06/16 09:28, "mmusic on behalf of Christer Holmberg" wrote: >Hi, > >>>> SHOULD, unless the endpoint knows that the peer supports a stronger >>>>hash >>>> algorithm, or unless the endpoint knows that the peer has not been >>>>upgraded >>>> to support the SHA-256 algorithm, or unless the endpoint is used for a >>>> service, or within an environment, that mandates usage of strong hash >>>> algorithms >>> >>> This covers all my examples, so I would be fine with this language. >> >> Might as well be a MUST given the extensive list of caveats. > >WFM. > >> Editorial: The last comma can be removed, or you could turn this into >> a bullet list of exemptions. > >Will be fixed. > >Regards, > >Christer > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Jun 1 00:58:13 2016 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 1BE2F12D146 for ; Wed, 1 Jun 2016 00:58:12 -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 bXRr1HcCTe_E for ; Wed, 1 Jun 2016 00:58:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8995A12D60A for ; Wed, 1 Jun 2016 00:58:09 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-b7-574e958f73c9 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id ED.A3.27088.F859E475; Wed, 1 Jun 2016 09:58:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 09:58:06 +0200 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 Thread-Index: AQHRtSvFlj02GsdUjEqN/h66uVwldJ/G2V+AgADkx4CAAGOpgIAAAaaAgAA66nD//+ymgIAAJPaQ///fdYCAABD5AIAABAeAgAAA6oCAAOs3gIABvEKAgAAif4CAACIs/oABJNaA///5JAAABOE4L///6iUAgAA3FYCAAAZ+gIAAKGoAgAAEbAD//8AqMIAAZnKAgAQpdQCAADi0gIAATZ/d///gtwD//9XcMAA44hMAAAFoUAAAA00LgAAfI/kA Date: Wed, 1 Jun 2016 07:58:06 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37FF3B58@ESESSMB209.ericsson.se> <2a554789-0668-74f0-4bb4-e2908daa5e91@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37FF4E53@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FBC2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FC74@ESESSMB209.ericsson.se> <2a5ebdc5-20c6-8a55-c6fd-f18957f2c4e4@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D3746FD5981Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUyM2K7qG7/VL9wg9lTtS2unfnHaDF1+WMW ixUbDrBazLgwldmBxePv+w9MHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBkNu6+y FxzSq1jcOZWxgXGpRhcjJ4eEgInExDM3WSFsMYkL99azdTFycQgJHGGUWPh5DQuEs5hRon/B cqYuRg4ONgELie5/2iANIgLeEn19HewgYWaBEIkLR0JBwsIC9hJXL19mgihxkNj59irYGBGB PiaJv7t3gI1hEVCReLS3FqSGV8BKorn3ITPEqkscEhMX3gJr5hQIlHh9r5sFxGYEOu77qTVg cWYBcYlbT+YzQRwtILFkz3lmCFtU4uXjf2DPiAroSXy5N48RZJeEgKLE8n45iNZ4iU+PTrNB 7BWUODnzCcsERrFZSKbOQlI2C0kZRNxA4v25+cwQtrbEsoWvoWx9iY1fzjJC2NYSk1d0siKr WcDIsYpRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMIYPbvltsIPx5XPHQ4wCHIxKPLwJnH7h QqyJZcWVuYcYJTiYlUR4BScDhXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5N LUgtgskycXBKNTBWbO4KNfVKPLdwWfmNOyJ3vR5si32+ovvBmeTZc5617OlZ7D9d7avDatZY 19ssR9w0VvlI/c2MFVqyaK769mzHaZNdo263RGgeY3nUlqwxYX+5zYMbu8+lfny4TFHy3Kzy S5VHw9h2TrFryOx8fX92A2OqXeiUa1vC+hd8v/h20k613uiTv8IWKbEUZyQaajEXFScCAD2+ w3fdAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 07:58:12 -0000 --_000_D3746FD5981Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Even if both endpoints use different hash functions to sign the certificate= , Roman=92s suggestions would still work as long as the offer contains fing= erprints calculated using both hash functions. Having said that, does it really matter it the answer contains additional h= ash functions =96 at long as it also contains one or more hash functions th= at were present in the offer? Not sure what the use-case would be, though= =85 Regards, Christer From: Roman Shpount > Date: Tuesday 31 May 2016 at 23:09 To: "pkyzivat@alum.mit.edu" > Cc: Christer Holmberg >, Martin Thomson >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 On Tue, May 31, 2016 at 2:34 PM, Paul Kyzivat > wrote: According to the old scheme the hash would always match that of the cert. I= f the certs in the two directions used different hashs, then so would the f= ingerprints. The rule you are suggesting would break that. I do not think there is a single implementation that actually looks at the = hash function that is used to sign the certificate when checking the finger= print, so in reality this will not break anything. For RFC4572 implementati= ons there is rarely a reason to look at certificate signature, since it wil= l only verify who signed the certificate and certificates used by RFC4572 a= re normally self signed. This entire requirement was in RFC4572 by mistake. _____________ Roman Shpount --_000_D3746FD5981Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <824CE9812CE5344695E695A1AA6D4177@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Even if both endpoints use different hash functions to sign the certif= icate, Roman=92s suggestions would still work as long as the offer contains= fingerprints calculated using both hash functions.

Having said that, does it really matter it the answer contains additio= nal hash functions =96 at long as it also contains one or more hash functio= ns that were present in the offer? Not sure what the use-case would be, tho= ugh=85

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Tuesday 31 May 2016 at 23:09<= br> To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Martin Thomson <mart= in.thomson@gmail.com>, "mmus= ic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC for draf= t-ietf-mmusic-4572-update-03

On Tue, M= ay 31, 2016 at 2:34 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
According to the old scheme the hash would always match that of the cert. I= f the certs in the two directions used different hashs, then so would the f= ingerprints.

The rule you are suggesting would break that.

I do not think there is a single implementation that actually looks at= the hash function that is used to sign the certificate when checking the f= ingerprint, so in reality this will not break anything. For RFC4572 impleme= ntations there is rarely a reason to look at certificate signature, since it will only verify who signed the= certificate and certificates used by RFC4572 are normally self signed. Thi= s entire requirement was in RFC4572 by mistake.
_________= ____
Roman Shpount
 
 --_000_D3746FD5981Cchristerholmbergericssoncom_-- From nobody Thu Jun 2 12:02:54 2016 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 5AC8C12D7DF for ; Thu, 2 Jun 2016 12:02:52 -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=brianrosen-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 QYgiQanMoBo4 for ; Thu, 2 Jun 2016 12:02:50 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 32B2712D7D8 for ; Thu, 2 Jun 2016 12:02:16 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id n63so42672418qkf.0 for ; Thu, 02 Jun 2016 12:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=5Y5rN5NcxWfAuHnZ4pHcsKP4QGrBuIl9/+wq9LkL+vg=; b=cyURfRMbSC1MsCQY+i7b05IwqXvb+66L2Q/vwR28rjTyx9159xV/a72aCJ8HVpSzyQ zAWskLAH5aXiw55Gbm8871IXEnhQthF8fFFfl9zguTWN2pyrhsRggdFA8Xrpr4L5IxTI Dt0nvKIVeNeKmzKJXV2Bqfd/zJzxKdgeQ0Xz5bLWE1mFb8lZHjk/PS3a0E/QQC7KmHtB AimFujBPZ03vxFeomQUi2aHLnIMvsYDHGj65KOdYhqS2+20BWKyU+OzTGRLCZBi9sbEv McptIOyKQWjZADSuhD8mhKAsqG1/kC9MkYhKnr1BNi5ALzKJn5jaOUAORROfzo+dLAi7 69NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=5Y5rN5NcxWfAuHnZ4pHcsKP4QGrBuIl9/+wq9LkL+vg=; b=mhXQpDgZglyGui4swPx7nKW3pU8ROak/vOM7+YYjtaY+FVzQq8YelwF7i8Rb2Z8GaK TaZpwB7nJh2SaYI/ElBb5g9RdHFCB53bNxfxXG/ljc+Pjecs3WEJEeIdbIie9j4Pu7kN XAFd8Uent9l4B61o/OrpaufxqKBF//BFTAQfk8uG/qp27SSxOfRGGSHIQMXtTvYxDMWI sUszWEoq/GDqW4BEBm7YRxe9nt1rBnTHxS+SapO0ce0VEKbsJy4T0iAMpX4QykNksawk 4BSTPEiI+HN7jeMAWOL023lhAPj8fvGc4krsxrs8ctiUb7ItVmWypwjkYqKAdGB1g5sD hLwQ== X-Gm-Message-State: ALyK8tJZj6VabRQliFDA2Td8o+hZJzRP/WInIKK7Kg+6KUjdGLEN198vLZ5Eh8JPaXYA6w== X-Received: by 10.55.188.193 with SMTP id m184mr43607347qkf.183.1464894135272; Thu, 02 Jun 2016 12:02:15 -0700 (PDT) Received: from [10.0.1.32] (dynamic-acs-24-154-119-181.zoominternet.net. [24.154.119.181]) by smtp.gmail.com with ESMTPSA id v6sm518525qhc.34.2016.06.02.12.02.14 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Jun 2016 12:02:14 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 2 Jun 2016 15:02:13 -0400 To: mmusic@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 19:02:52 -0000 Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated. We have no other way to transport flash to = interwork with our newer SIP based emergency calling systems. I=E2=80=99m prepared to write a draft that restores code 16 for flash, = as it was in 2833, but wanted to hear any objections to doing that. Brian= From nobody Thu Jun 2 13:15:33 2016 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 8593412D560 for ; Thu, 2 Jun 2016 13:15:31 -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 XMpqOkzga4EV for ; Thu, 2 Jun 2016 13:15:29 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B4112D7E3 for ; Thu, 2 Jun 2016 13:15:25 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id w184so95363240oiw.2 for ; Thu, 02 Jun 2016 13:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xT9vzxsFWW8FvpMwP/GdkGM/tfA6puozPFSXMTn4Jxg=; b=rg5w4+O86gjV/qG6IDlHcHNbh71zO2lN2o/5loIprN0fN40y9PetbfoTMS+4t0sYC2 HJWgDIhtDk7obBt9L3XHKQkogPWGjl8j6iTCtzyvmVALlsIBxVJcFwZ+D1+k+PProRri JCz6oANaz7WyxlpKhzZki7eTK57Lr4zCggJJyf1XdE3FsOjkHHYacGe8KdPSG9oeFNFe PpBisGkk0mmpj4nAhucOFvtFIJc7KO1xhycV7udo2/DvUH4M1CHlC+XyYwmKkmGJRjeQ VVL/xMqp+l75LmDc5zBw/AoYIHFBuzt6WZhy8HrvOwlBWny+s4Zc02fZCKolSIGo3D8G ka6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xT9vzxsFWW8FvpMwP/GdkGM/tfA6puozPFSXMTn4Jxg=; b=m/khq2o2XufDuBF6rip7c9Yn7O53s5YnkPP1Sr/R3HjrWVw19dyOkNS+DrcCwNb7Tz TqIgDE0hKtbNC7xNINMEQ8OsuvI9ee/wooVQWMkJhTgYXiJZNXtWzrMgRlt+Iy9Q7+pp hjD8Q4yJ1E0z/6rOdurf6BUyloMDCmvuqsHxiPkE9Ght/qZhyTEO/SVeOyoZQxTtHite Wx8dPHarKwtncCgXxxl29CdySvD62uHuRBjGnfsL/CM1yhNn01GmwyvX42O2ABQGnsTM 5OR1K6POYTcPmysaFbrL9zPh9itul7NaN6LbSPi5HkTuu8viG2udrM7AIYJMe0E5/Hg7 lcXA== X-Gm-Message-State: ALyK8tLfDW2Nr84+uH8cf2TDJRYdpKHtORRvqC9QiwCnHuB44eAvWERw3zxIpXnipf0WfZWE1hvs51Oj0pqc/w== X-Received: by 10.202.83.146 with SMTP id h140mr28697921oib.171.1464898524513; Thu, 02 Jun 2016 13:15:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.195.137 with HTTP; Thu, 2 Jun 2016 13:15:05 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 2 Jun 2016 13:15:05 -0700 Message-ID: To: Brian Rosen Content-Type: multipart/alternative; boundary=001a113d28022f938505345144ac Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:15:31 -0000 --001a113d28022f938505345144ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen wrote: > Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80= =9CFlash=E2=80=9D, > the signal caused by a momentary depression of the hook-switch in a POTS > phone. When 2833 was obsoleted by 4733, flash was dropped, although the > code 16 was reserved. > It looks to me that you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event types). This has been effectively gone a long time, in other words. > We have a use case in NENA (9-1-1 emergency stuff) where existing systems > use flash interspersed wth tones in signaling dialing events which are no= t > interpreted by the UA that receives them, but are instead transported to = a > device that creates appropriate SIP signaling for the dialing events > initiated. So, I'm not sure why invoking NENA and emergency services matters here. You don't explain what the system does and how it interoperates with anything else now. If I replace "NENA" with "A proprietary system uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately true? The key question seems to be "what are these events, and what's the right way to signal them to a gateway"? > We have no other way to transport flash to interwork with our newer SIP > based emergency calling systems. > > I=E2=80=99m prepared to write a draft that restores code 16 for flash, as= it was > in 2833, but wanted to hear any objections to doing that. > Let me gently suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be. Unless you plan to force people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb here. Just my two cents, dislodged by a knee-jerk reaction to making DTMF more important, regards, Ted > Brian > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113d28022f938505345144ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <br@brianrosen.n= et> wrote:
Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80= =9CFlash=E2=80=9D, the signal caused by a momentary depression of the hook-= switch in a POTS phone.=C2=A0 When 2833 was obsoleted by 4733, flash was dr= opped, although the code 16 was reserved.

It looks to me that you could be compliant with RFC 2833 without impleme= nting flash at all (see Section 3.3, on event types).=C2=A0 This has been e= ffectively gone a long time, in other words.


We have a use case in NENA (9-1-1 emergency stuff) where existing systems u= se flash interspersed wth tones in signaling dialing events which are not i= nterpreted by the UA that receives them, but are instead transported to a d= evice that creates appropriate SIP signaling for the dialing events initiat= ed.=C2=A0


So, I'm not sure why invo= king NENA and emergency services matters here.=C2=A0 You don't explain = what the system does and how it interoperates with anything else now.=C2=A0= =C2=A0

If I replace "NENA" with "A proprietary syste= m uses flash interspersed with other DTMF tones to send signalling events t= o a gateway" is that approximately true?=C2=A0 The key question seems = to be "what are these events, and what's the right way to signal t= hem to a gateway"?
=C2=A0
We have no other way to transport flash to interwork with ou= r newer SIP based emergency calling systems.

I=E2=80=99m prepared to write a draft that restores code 16 for flash, as i= t was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-u= se code 16, long in abeyance, for this new purpose, whatever you eventually= explain it to be.=C2=A0 Unless you plan to force people to go back through= their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure ou= t what exactly is involved in this resurrection, saying "restores"= ; seems like the wrong verb here.

Just my two cents, disl= odged by a knee-jerk reaction to making DTMF more important,

<= div>regards,

Ted
=C2=A0
Brian
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--001a113d28022f938505345144ac-- From nobody Thu Jun 2 13:49:43 2016 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 021CE12D860 for ; Thu, 2 Jun 2016 13:49:42 -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=brianrosen-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 tB27VT0A91TG for ; Thu, 2 Jun 2016 13:49:39 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C0A12D867 for ; Thu, 2 Jun 2016 13:49:38 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id n63so44431608qkf.0 for ; Thu, 02 Jun 2016 13:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=45lxIjjwz85iaZbs5Xxj1N2KgoIuQqv+H+lXPnZKtH8=; b=1S5a3UD2C62428GzV5jXge8vMaAOvnrhMSmi02DqkMDZBj2EQ50+woYqqq9C9c3s9e zB9vScHrkPrLwHssSUUmYOMutnaA5G4Mv0up/szpbMZ+M1fm7W3WGotEFZm6JbsABMuB KeqyTjnBhfEMAbTaJcc881yTAiMdKvXCVTPZQOWNa79TwgebKl2xTbnIJ13SHV4vUdOQ nNfnasaH2qfsl8F7WZ52A3qgJf7u+vohf/0YACEWnlQ3VOL9l5bcM3q3CcVocP17P0i1 lZs9Z41pOWlbIum8VuqSDIRg9BMH0MlnqG1jPo2sMHrnKcaZBCaGN5EByzi94h+ZN7eO YxiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=45lxIjjwz85iaZbs5Xxj1N2KgoIuQqv+H+lXPnZKtH8=; b=JxaIDl1YYhcxYxuq3Kn/rDzAtRl2h6ItD4s/Q2eJO/fsNKJmE6uKVJ1YzcQHhkwdRP +nDEpShwB5jVG5NIexJCamN2F+zfHz+TMCu/mn0Hr109wBzJenn7uqTin8W7OlNgB1EO NbfgnKk9Qm0SKM/Qx/p5Z+Nz8FQhnj3TXr2S9iz07wU1J34qXLbc14fopswbobGsKe1w oHdw8024ObWhSmloxSmUs/b/29rpMChlsC5A4GPsb05uO5uBflYt139zB4aYs9M7AbJZ EnKEpv/URLmAEDPpj5pP9dABOAfIv6xjKLUnh6Vv4OVTiIdQ98sZpCSjiyFAIQ0ZJ/0N EPMw== X-Gm-Message-State: ALyK8tKN84aChvYC1l2fu37+k48UeZ3nPoJ4TPYtkqT8pwkZMGcnc93+t9FuoTiT0PdjCQ== X-Received: by 10.55.209.201 with SMTP id o70mr85781qkl.179.1464900578080; Thu, 02 Jun 2016 13:49:38 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id h28sm647621qtc.37.2016.06.02.13.49.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Jun 2016 13:49:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_18B49198-D62E-45DE-B7B4-20FBF77D02DB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Thu, 2 Jun 2016 16:49:31 -0400 Message-Id: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> References: To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:49:42 -0000 --Apple-Mail=_18B49198-D62E-45DE-B7B4-20FBF77D02DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ted > On Jun 2, 2016, at 4:15 PM, Ted Hardie wrote: >=20 > Hi Brian, >=20 > On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen > wrote: > Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. >=20 > It looks to me that you could be compliant with RFC 2833 without = implementing flash at all (see Section 3.3, on event types). This has = been effectively gone a long time, in other words. I=E2=80=99m sorry, I don=E2=80=99t understand. We=E2=80=99re writing a = new standard, and I=E2=80=99d really prefer to not reference an obsolete = IETF standard in that document. I need to signal flash, the way 2833 = signaled flash, but 4733 doesn=E2=80=99t have a way to signal flash. >=20 >=20 > We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated.=20 >=20 >=20 > So, I'm not sure why invoking NENA and emergency services matters = here. You don't explain what the system does and how it interoperates = with anything else now. =20 I=E2=80=99m connecting a new IP based system that uses standards based = SIP to an existing old system. That system expects to signal to do a = call transfer or conference operation with combinations of flash and = DTMF. There is a network that is using normal SIP signaling for = transfer/conference, and this older system that is expecting hook switch = and DTMF. Ideally, we would have the UA facing the older system do the = interwork, but alas that won=E2=80=99t work, and we need another element = to do the interwork, and transport the DTMF and flash to the UA which = will play out the signaling. If I made that UA and the interworking = element conform to 2833, everything would be fine, but then I=E2=80=99m = requiring conformance to an obsolete document. >=20 >=20 > If I replace "NENA" with "A proprietary system uses flash interspersed = with other DTMF tones to send signalling events to a gateway" is that = approximately true? The key question seems to be "what are these = events, and what's the right way to signal them to a gateway=E2=80=9D? It=E2=80=99s approximately true, but it=E2=80=99s a standards based = system, not a proprietary system. The older system is standards based, = the new system is standards based, and I need to interwork them in a = standards based manner. =20 > =20 > We have no other way to transport flash to interwork with our newer = SIP based emergency calling systems. >=20 > I=E2=80=99m prepared to write a draft that restores code 16 for flash, = as it was in 2833, but wanted to hear any objections to doing that. >=20 > Let me gently suggest that you instead ask to re-use code 16, long in = abeyance, for this new purpose, whatever you eventually explain it to = be. Unless you plan to force people to go back through their old ITU = E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what = exactly is involved in this resurrection, saying "restores" seems like = the wrong verb here. I am asking to use code 16 to transport flash, in exactly the same way = 2833 did. >=20 > Just my two cents, dislodged by a knee-jerk reaction to making DTMF = more important, Yeah, I=E2=80=99m not thrilled with more backwards compatibility stuff = either, but I=E2=80=99m also not a fan of an organization like NENA = making up standards using SDP, or requiring conformance to obsolete = standards. Brian --Apple-Mail=_18B49198-D62E-45DE-B7B4-20FBF77D02DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Ted

On Jun 2, 2016, at 4:15 PM, Ted = Hardie <ted.ietf@gmail.com> wrote:

Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, = Brian Rosen <br@brianrosen.net> wrote:
Back in = RFC2833, the DTMF tones section, code 16 was defined for =E2=80=9CFlash=E2= =80=9D, the signal caused by a momentary depression of the hook-switch = in a POTS phone.  When 2833 was obsoleted by 4733, flash was = dropped, although the code 16 was reserved.

It looks to me that you could be compliant with RFC 2833 = without implementing flash at all (see Section 3.3, on event = types).  This has been effectively gone a long time, in other = words.
I=E2=80=99= m sorry, I don=E2=80=99t understand.  We=E2=80=99re writing a new = standard, and I=E2=80=99d really prefer to not reference an obsolete = IETF standard in that document.  I need to signal flash, the way = 2833 signaled flash, but 4733 doesn=E2=80=99t have a way to signal = flash.



We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated. 


So, I'm not sure why = invoking NENA and emergency services matters here.  You don't = explain what the system does and how it interoperates with anything else = now.  
I=E2=80=99m = connecting a new IP based system that uses standards based SIP to an = existing old system.  That system expects to signal to do a call = transfer or conference operation with combinations of flash and DTMF. =  There is a network that is using normal SIP signaling for = transfer/conference, and this older system that is expecting hook switch = and DTMF.  Ideally, we would have the UA facing the older system do = the interwork, but alas that won=E2=80=99t work, and we need another = element to do the interwork, and transport the DTMF and flash to the UA = which will play out the signaling.  If I made that UA and the = interworking element conform to 2833, everything would be fine, but then = I=E2=80=99m requiring conformance to an obsolete document.


If = I replace "NENA" with "A proprietary system uses flash interspersed with = other DTMF tones to send signalling events to a gateway" is that = approximately true?  The key question seems to be "what are these = events, and what's the right way to signal them to a gateway=E2=80=9D?
It=E2=80=99s = approximately true, but it=E2=80=99s a standards based system, not a = proprietary system.  The older system is standards based, the new = system is standards based, and I need to interwork them in  a = standards based manner.  
 
We have no other way to transport = flash to interwork with our newer SIP based emergency calling = systems.

I=E2=80=99m prepared to write a draft that restores code 16 for flash, = as it was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-use code 16, = long in abeyance, for this new purpose, whatever you eventually explain = it to be.  Unless you plan to force people to go back through their = old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out = what exactly is involved in this resurrection, saying "restores" seems = like the wrong verb here.
I am asking to use = code 16 to transport flash, in exactly the same way 2833 = did.


Just my two cents, dislodged by a knee-jerk reaction to = making DTMF more important,
Yeah, I=E2=80=99m = not thrilled with more backwards compatibility stuff either, but I=E2=80=99= m also not a fan of an organization like NENA making up standards using = SDP, or requiring conformance to obsolete standards.

Brian

= --Apple-Mail=_18B49198-D62E-45DE-B7B4-20FBF77D02DB-- From nobody Thu Jun 2 13:53:54 2016 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 B5D2912D873 for ; Thu, 2 Jun 2016 13:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 UYdZYVyhnmcx for ; Thu, 2 Jun 2016 13:53:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEDD12D860 for ; Thu, 2 Jun 2016 13:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3568; q=dns/txt; s=iport; t=1464900830; x=1466110430; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=LjmLrEFX/WK2ZB2obqSKFTJZwLYE9D35rZrRjPgy90A=; b=RxJssllpLJa28zJ2HRdeH6f6hydV9C5LocWrKLN7fDt2uWYpdlSCBs7l Siwhdb2GCZ6bHPOuiQJqIYrqhJN9QlavkyUMdBaghfeb6dvdUFpt8yIg2 Ydl+uL2vca49z73qag9q0JeEKAVMGnvIIu0gTFnO5CyUtlpX9ntZ68I8+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGBQA9nFBX/4wNJK1egzpWK1K1T4R5g?= =?us-ascii?q?XkXAQqFJkoCgTY6EgEBAQEBAQFlJ4RFAQEBBAEBAWsLEA8NAwECLycmAggGDQY?= =?us-ascii?q?CAQGIKw7CSwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhieBd4JWhGCFOgWYN44gg?= =?us-ascii?q?WmET4MJhVuPTCUNIoQKIDKKfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,408,1459814400"; d="scan'208,217";a="280185417" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2016 20:53:49 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u52KrnkO030874; Thu, 2 Jun 2016 20:53:49 GMT References: <73a4d9c3-ee07-6134-7f28-a0c53d530627@cisco.com> To: "Christer Holmberg (JO/LMF)" From: Flemming Andreasen X-Forwarded-Message-Id: <73a4d9c3-ee07-6134-7f28-a0c53d530627@cisco.com> Message-ID: Date: Thu, 2 Jun 2016 16:53:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <73a4d9c3-ee07-6134-7f28-a0c53d530627@cisco.com> Content-Type: multipart/alternative; boundary="------------558F687700B68D6B687DAD3D" Archived-At: Cc: mmusic Subject: [MMUSIC] Fwd: Preparing for MMUSIC meeting at IETF 96 (Berlin) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:53:53 -0000 This is a multi-part message in MIME format. --------------558F687700B68D6B687DAD3D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Christer Do you expect to have anything for the MMUSIC meeting in Berlin ? Thanks -- Flemming -------- Forwarded Message -------- Subject: [MMUSIC] Preparing for MMUSIC meeting at IETF 96 (Berlin) Date: Tue, 31 May 2016 10:15:12 -0400 From: Flemming Andreasen To: mmusic Greetings MMUSIC IETF 96 will be held in Berlin July 17-26. WG scheduling requests need to be submitted by Friday this week, however before we ask for meeting time, we would like to get an indication of what topics people would like to discuss in Berlin. Thus, if you believe you (or somebody else) have a draft that would benefit from discussion in Berlin, please let us know at this time so we can plan accordingly. Thanks -- Flemming & Bo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic . --------------558F687700B68D6B687DAD3D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Christer

Do you expect to have anything for the MMUSIC meeting in Berlin ?

Thanks

-- Flemming


-------- Forwarded Message --------
Subject: [MMUSIC] Preparing for MMUSIC meeting at IETF 96 (Berlin)
Date: Tue, 31 May 2016 10:15:12 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org> 


Greetings MMUSIC

IETF 96 will be held in Berlin July 17-26. WG scheduling requests need 
to be submitted by Friday this week, however before we ask for meeting 
time, we would like to get an indication of what  topics people would 
like to discuss in Berlin. Thus, if you believe you (or somebody else) 
have a draft that would benefit from discussion in Berlin, please let us 
know at this time so we can plan accordingly.

Thanks

-- Flemming & Bo


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
.
--------------558F687700B68D6B687DAD3D-- From nobody Thu Jun 2 13:57:35 2016 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 61F6712D0CA for ; Thu, 2 Jun 2016 13:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 gVwvDrlQWNbN for ; Thu, 2 Jun 2016 13:57:31 -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 AE6F012B02F for ; Thu, 2 Jun 2016 13:57:31 -0700 (PDT) Received: from unnumerable.local (inet-141-146-6-188.oracle.com [137.254.4.60]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u52KvUEC030322 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 2 Jun 2016 15:57:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host inet-141-146-6-188.oracle.com [137.254.4.60] claimed to be unnumerable.local To: mmusic@ietf.org References: From: Robert Sparks Message-ID: Date: Thu, 2 Jun 2016 16:57:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D1CD97B9A76466D748825447" Archived-At: Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:57:34 -0000 This is a multi-part message in MIME format. --------------D1CD97B9A76466D748825447 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Ted - IIRC the reason 16 (and several other codes) were moved to reserved in 4733 was to prepare for taking this up the standards ladder - there weren't implementations using the codepoints so the independent interoperable implementations barrier of the time couldn't be met. The text in 4733 explicitly recognized that they might be reassigned to their 2833 meaning if there were a reason to have them (favoring that over assigning the codepoint to something else), so I don't think Brian is in the weeds. I had the same initial reaction about whether flash was a reasonable thing to use this way in the first place, but I'm not sure it's enough to push back against allowing this protocol to carry the events that are actually defined. RjS On 6/2/16 4:15 PM, Ted Hardie wrote: > Hi Brian, > > On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen > wrote: > > Back in RFC2833, the DTMF tones section, code 16 was defined for > “Flash”, the signal caused by a momentary depression of the > hook-switch in a POTS phone. When 2833 was obsoleted by 4733, > flash was dropped, although the code 16 was reserved. > > > It looks to me that you could be compliant with RFC 2833 without > implementing flash at all (see Section 3.3, on event types). This has > been effectively gone a long time, in other words. > > > We have a use case in NENA (9-1-1 emergency stuff) where existing > systems use flash interspersed wth tones in signaling dialing > events which are not interpreted by the UA that receives them, but > are instead transported to a device that creates appropriate SIP > signaling for the dialing events initiated. > > > > So, I'm not sure why invoking NENA and emergency services matters > here. You don't explain what the system does and how it interoperates > with anything else now. > > If I replace "NENA" with "A proprietary system uses flash interspersed > with other DTMF tones to send signalling events to a gateway" is that > approximately true? The key question seems to be "what are these > events, and what's the right way to signal them to a gateway"? > > We have no other way to transport flash to interwork with our > newer SIP based emergency calling systems. > > I’m prepared to write a draft that restores code 16 for flash, as > it was in 2833, but wanted to hear any objections to doing that. > > > Let me gently suggest that you instead ask to re-use code 16, long in > abeyance, for this new purpose, whatever you eventually explain it to > be. Unless you plan to force people to go back through their old ITU > E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what > exactly is involved in this resurrection, saying "restores" seems like > the wrong verb here. > > Just my two cents, dislodged by a knee-jerk reaction to making DTMF > more important, > > regards, > > Ted > > Brian > _______________________________________________ > 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 --------------D1CD97B9A76466D748825447 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Ted -

IIRC the reason 16 (and several other codes) were moved to reserved in 4733 was to prepare for taking this up the standards ladder - there weren't implementations using the codepoints so the independent interoperable implementations barrier of the time couldn't be met. The text in 4733 explicitly recognized that they might be reassigned to their 2833 meaning if there were a reason to have them (favoring that over assigning the codepoint to something else), so I don't think Brian is in the weeds.

I had the same initial reaction about whether flash was a reasonable thing to use this way in the first place, but I'm not sure it's enough to push back against allowing this protocol to carry the events that are actually defined.

RjS


On 6/2/16 4:15 PM, Ted Hardie wrote:
Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <br@brianrosen.net> wrote:
Back in RFC2833, the DTMF tones section, code 16 was defined for “Flash”, the signal caused by a momentary depression of the hook-switch in a POTS phone.  When 2833 was obsoleted by 4733, flash was dropped, although the code 16 was reserved.

It looks to me that you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event types).  This has been effectively gone a long time, in other words.


We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events initiated. 


So, I'm not sure why invoking NENA and emergency services matters here.  You don't explain what the system does and how it interoperates with anything else now.  

If I replace "NENA" with "A proprietary system uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately true?  The key question seems to be "what are these events, and what's the right way to signal them to a gateway"?
 
We have no other way to transport flash to interwork with our newer SIP based emergency calling systems.

I’m prepared to write a draft that restores code 16 for flash, as it was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be.  Unless you plan to force people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb here.

Just my two cents, dislodged by a knee-jerk reaction to making DTMF more important,

regards,

Ted
 
Brian
_______________________________________________
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

--------------D1CD97B9A76466D748825447-- From nobody Thu Jun 2 13:59:22 2016 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 5EAF412D7F2 for ; Thu, 2 Jun 2016 13:59:21 -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 RrlOm-yZBqd5 for ; Thu, 2 Jun 2016 13:59:19 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B6312B02F for ; Thu, 2 Jun 2016 13:59:18 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id e72so97289325oib.1 for ; Thu, 02 Jun 2016 13:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wvRTSM8CHFQBRL/Uk3DGFSdleABSJ24UC0+YMzckKr4=; b=id3QB6C47j0HeBntEe0J0+7hQVBZ0wP6zAZ+mAYOIeYR2aH4XtKtqXILlOeYceAjHm NTmdocsFp1gtVyXUcuFrv8KjW7mr32Lpvpey4lgMJ2pHt9S3neq93YpEFK/8CYoZ5qXM DkCSxNJdN8X62Y7pmcU1OYic8eTqCqwHhUcsJl7E8fCAXKV8FVHydeKa7IKJ+PYLj4Os lOeUBvSKFUMsYb9idoxAWlEBhHe6wG8ajXKV3taCx9YDtX1VYD44NcuE8ms8jmqrSuvy AN1fiAAVVR0lrd2w8jfEEhXiHF9B5UjMgyCTYG7CCDhq4NCU5dcca+FC/LBQMgES6hlG HaLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wvRTSM8CHFQBRL/Uk3DGFSdleABSJ24UC0+YMzckKr4=; b=mtcAsR0Te0d5PNpiRWH2jyrMqwBMNVRLExMugv5AU3hEq+mFX0m1VuQ5AL540/cIZR pB1n1vtE27bcN9h14aPFADaLL5fdI5COBwnX8/0JdEAI+w5hPswUoC2wO4iSQlF+rbPE 19624FovJP/ucHm6q+HVy5uVS4WdUwMetTIMvpoaepUIBqgWRQHScAmU45fMmjoN4jZ7 yK+dSxxNuSouafh289R8ywrgi+gfU+JFq8toVMUZ09zJ/8b/qnItf++9OKExwNPOVJ3A 3pwaTbtQrR67yE4M87G/DC8+ZShcR8jglHhgrtnQQ0WC//yoX0NetTu/s2VyDBTbr3ts Qotg== X-Gm-Message-State: ALyK8tJfoTHBn4+/HsZjPaFsyqjWgVRM7A1g/NkuPfezRiGznyt1Mw7ryDn1svVfWvf00uogCuEtpf79mAJZlg== X-Received: by 10.157.49.4 with SMTP id e4mr125662otc.18.1464901158189; Thu, 02 Jun 2016 13:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.195.137 with HTTP; Thu, 2 Jun 2016 13:58:58 -0700 (PDT) In-Reply-To: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> From: Ted Hardie Date: Thu, 2 Jun 2016 13:58:58 -0700 Message-ID: To: Brian Rosen Content-Type: multipart/alternative; boundary=001a113e1ca82a6791053451e1b0 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:59:21 -0000 --001a113e1ca82a6791053451e1b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, In-line. On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen wrote: > Hi Ted > > On Jun 2, 2016, at 4:15 PM, Ted Hardie wrote: > > Hi Brian, > > On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen wrote: > >> Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80= =9CFlash=E2=80=9D, >> the signal caused by a momentary depression of the hook-switch in a POTS >> phone. When 2833 was obsoleted by 4733, flash was dropped, although the >> code 16 was reserved. >> > > It looks to me that you could be compliant with RFC 2833 without > implementing flash at all (see Section 3.3, on event types). This has be= en > effectively gone a long time, in other words. > > I=E2=80=99m sorry, I don=E2=80=99t understand. > I'm saying that since you could call yourself compliant RFC 2833 without implementing flash at all, the ability to count on this went away before the turn of the millenium. As in 16 years ago. > We=E2=80=99re writing a new standard, and I=E2=80=99d really prefer to n= ot reference an > obsolete IETF standard in that document. I need to signal flash, the way > 2833 signaled flash, but 4733 doesn=E2=80=99t have a way to signal flash. > > > >> We have a use case in NENA (9-1-1 emergency stuff) where existing system= s >> use flash interspersed wth tones in signaling dialing events which are n= ot >> interpreted by the UA that receives them, but are instead transported to= a >> device that creates appropriate SIP signaling for the dialing events >> initiated. > > > > So, I'm not sure why invoking NENA and emergency services matters here. > You don't explain what the system does and how it interoperates with > anything else now. > > I=E2=80=99m connecting a new IP based system that uses standards based SI= P to an > existing old system. That system expects to signal to do a call transfer > or conference operation with combinations of flash and DTMF. There is a > network that is using normal SIP signaling for transfer/conference, and > this older system that is expecting hook switch and DTMF. Ideally, we > would have the UA facing the older system do the interwork, but alas that > won=E2=80=99t work, and we need another element to do the interwork, and = transport > the DTMF and flash to the UA which will play out the signaling. If I mad= e > that UA and the interworking element conform to 2833, everything would be > fine, but then I=E2=80=99m requiring conformance to an obsolete document. > > > > If I replace "NENA" with "A proprietary system uses flash interspersed > with other DTMF tones to send signalling events to a gateway" is that > approximately true? The key question seems to be "what are these events, > and what's the right way to signal them to a gateway=E2=80=9D? > > It=E2=80=99s approximately true, but it=E2=80=99s a standards based syste= m, not a > proprietary system. > You say that, but you appear to be implying that it is a system based on a standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC 4733). You appear to be attempting to create a new standard in 2016 (let's be honest here, likely arriving in 2018) that recapitulates something from the past so that NENA doesn't have to update something that's been superseded. > The older system is standards based, the new system is standards based, > and I need to interwork them in a standards based manner. > You want everyone else to re-implement flash so that NENA doesn't replace their proprietary/superseded system? > > >> We have no other way to transport flash to interwork with our newer SIP >> based emergency calling systems. >> >> I=E2=80=99m prepared to write a draft that restores code 16 for flash, a= s it was >> in 2833, but wanted to hear any objections to doing that. >> > > Let me gently suggest that you instead ask to re-use code 16, long in > abeyance, for this new purpose, whatever you eventually explain it to be. > Unless you plan to force people to go back through their old ITU E.18* do= cs > and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involv= ed > in this resurrection, saying "restores" seems like the wrong verb here. > > I am asking to use code 16 to transport flash, in exactly the same way > 2833 did. > > And you want to undo the decisions that led to it being soft-dropped there and deprecated. But the justification doesn't seem to be there. > > Just my two cents, dislodged by a knee-jerk reaction to making DTMF more > important, > > Yeah, I=E2=80=99m not thrilled with more backwards compatibility stuff ei= ther, but > I=E2=80=99m also not a fan of an organization like NENA making up standar= ds using > SDP, or requiring conformance to obsolete standards. > How about they expressing what the actual gateway signalling requirements are and we solve them without zombie DTMF shuffling about? Just a thought, Ted > > Brian > > --001a113e1ca82a6791053451e1b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

In-line.

On Thu,= Jun 2, 2016 at 1:49 PM, Brian Rosen <br@brianrosen.net> wro= te:
Hi Ted

On Jun 2, 2016, at 4:15 PM, T= ed Hardie <ted.i= etf@gmail.com> wrote:

Hi Brian,

On Thu, Jun 2, 2016= at 12:02 PM, Brian Rosen <br@brianrosen.net> wrote:
Back in RFC2833, the DTMF ton= es section, code 16 was defined for =E2=80=9CFlash=E2=80=9D, the signal cau= sed by a momentary depression of the hook-switch in a POTS phone.=C2=A0 Whe= n 2833 was obsoleted by 4733, flash was dropped, although the code 16 was r= eserved.

It looks to me that you could = be compliant with RFC 2833 without implementing flash at all (see Section 3= .3, on event types).=C2=A0 This has been effectively gone a long time, in o= ther words.
I=E2=80=99= m sorry, I don=E2=80=99t understand.
I'm saying that since you could call yourself compliant RF= C 2833 without implementing flash at all, the ability to count on this went= away before the turn of the millenium.=C2=A0 As in 16 years ago.
=
=C2=A0
=C2=A0We=E2=80=99re writing a new standard, and I=E2=80= =99d really prefer to not reference an obsolete IETF standard in that docum= ent.=C2=A0 I need to signal flash, the way 2833 signaled flash, but 4733 do= esn=E2=80=99t have a way to signal flash.



We have a use case in NENA (9-1-1 emergency stuff) where existing systems u= se flash interspersed wth tones in signaling dialing events which are not i= nterpreted by the UA that receives them, but are instead transported to a d= evice that creates appropriate SIP signaling for the dialing events initiat= ed.=C2=A0


So, I'm not sure why invo= king NENA and emergency services matters here.=C2=A0 You don't explain = what the system does and how it interoperates with anything else now.=C2=A0= =C2=A0
I=E2=80=99m connect= ing a new IP based system that uses standards based SIP to an existing old = system.=C2=A0 That system expects to signal to do a call transfer or confer= ence operation with combinations of flash and DTMF.=C2=A0 There is a networ= k that is using normal SIP signaling for transfer/conference, and this olde= r system that is expecting hook switch and DTMF.=C2=A0 Ideally, we would ha= ve the UA facing the older system do the interwork, but alas that won=E2=80= =99t work, and we need another element to do the interwork, and transport t= he DTMF and flash to the UA which will play out the signaling.=C2=A0 If I m= ade that UA and the interworking element conform to 2833, everything would = be fine, but then I=E2=80=99m requiring conformance to an obsolete document= .


If I replace= "NENA" with "A proprietary system uses flash interspersed w= ith other DTMF tones to send signalling events to a gateway" is that a= pproximately true?=C2=A0 The key question seems to be "what are these = events, and what's the right way to signal them to a gateway=E2=80=9D?<= br>
It=E2=80=99s approxima= tely true, but it=E2=80=99s a standards based system, not a proprietary sys= tem.
You say that, but you appear to be= implying that it is a system based on a standard that was disappearing in = 2000 (RFC 2833) and gone by 2006 (RFC 4733).=C2=A0 You appear to be attempt= ing to create a new standard in 2016 (let's be honest here, likely arri= ving in 2018) that recapitulates something from the past so that NENA doesn= 't have to update something that's been superseded.
=C2=A0
=
=C2=A0The older system is standards based, the new system is standards ba= sed, and I need to interwork them in =C2=A0a standards based manner. =C2=A0=

<= div>You want everyone else to re-implement flash so that NENA doesn't r= eplace their proprietary/superseded system?
=C2=A0
=C2=A0
We have no other way to transport flash t= o interwork with our newer SIP based emergency calling systems.

I=E2=80=99m prepared to write a draft that restores code 16 for flash, as i= t was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-u= se code 16, long in abeyance, for this new purpose, whatever you eventually= explain it to be.=C2=A0 Unless you plan to force people to go back through= their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure ou= t what exactly is involved in this resurrection, saying "restores"= ; seems like the wrong verb here.
I am asking to use code 16 to transport flash, in exactly the s= ame way 2833 did.

<= /blockquote>

And you want to undo the decisions that led= to it being soft-dropped there and deprecated.=C2=A0 But the justification= doesn't seem to be there.

Just my two cents, dislodged by a knee-jerk= reaction to making DTMF more important,
<= /blockquote>Yeah, I=E2=80=99m not thrilled with more backwards compa= tibility stuff either, but I=E2=80=99m also not a fan of an organization li= ke NENA making up standards using SDP, or requiring conformance to obsolete= standards.

How about the= y expressing what the actual gateway signalling requirements are and we sol= ve them without zombie DTMF shuffling about?

Just a thoug= ht,

Ted
=C2=A0

Brian

<= /span>

--001a113e1ca82a6791053451e1b0-- From nobody Thu Jun 2 14:01:18 2016 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 46B6112D886 for ; Thu, 2 Jun 2016 14:01:16 -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 txTrhxMiq8ii for ; Thu, 2 Jun 2016 14:01:13 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC06012D871 for ; Thu, 2 Jun 2016 14:01:01 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id k23so97361822oih.0 for ; Thu, 02 Jun 2016 14:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UCm03W/xVVm9pnbwp/aceVinZrfsa76NA4aUrLWFZac=; b=L44QMYlqpeaXVeOh4UtkCSPHB2o3+iOpZ86lfTsQExROPCKg1aVlXG1rOJ22twpSw4 ohLY2kYZCGjlOFrmk3Cakrep9KzgzebgwMEovRq+z6QtbSqZe3U2z8M+nw5WwwD/whyO jlBdSHyKSQ2Lh6/IphGEDYZ0/96kG5BLL5UcUwffZmbZA9AZRwiZB5WzZ+oXJOgNfTHP N1LjhLOLBmaaIRdSwGuqWB1cmVD6he3DXQfFkbZBzLpMoAosg2zELq4cCozKFl8OJFYs /CyGt8uiOZu7cG5Uq/3ZF9EHj1XoClCCNoXKmYd2UJipyA6qJHC2YGQRp65wrL6N0MY6 tKUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UCm03W/xVVm9pnbwp/aceVinZrfsa76NA4aUrLWFZac=; b=kPucw4+0S3F2XuvZpMaT4OYDPGQh6wVRcHd21inu+VCO3BpLXd3BhaY5IV8xmuPSjE 5OP4u8GoebMU30Sb0r+xHXgyrT3H+vItbYBLTFkA6iYWzRg9ANPLDdjzKTGfwos4TuX9 uz30RU/jWXMM2AnQLPm5nFmxTZ+7EymFCXnMXWYiID296Y7aTxFOmyL6kIUl/tztcjJd LJiLqiHv5l32uiPBqWti1Nbyj2gd/4z2ltPGJlzPMz9byDKjR/2bm1GYVtKYBRDTFL5b ZZXZie1J+lqjXKGKdAPm1izR9F2wegQS0r75BgS/FBIdRcOz2P3Vvbx6yRSBivkFl8Av wyPw== X-Gm-Message-State: ALyK8tKwHK9RFUYTO01ZCGUsx95ngZk1SP6ZjWvi0Y8n/W/mbWgQsGvxygn7B2DQnXkl6/5J6DYk0xsOwG27kw== X-Received: by 10.157.48.89 with SMTP id w25mr116735otd.32.1464901261093; Thu, 02 Jun 2016 14:01:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.195.137 with HTTP; Thu, 2 Jun 2016 14:00:41 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 2 Jun 2016 14:00:41 -0700 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=001a11414ce04c76c7053451e7ab Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:01:16 -0000 --001a11414ce04c76c7053451e7ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2016 at 1:57 PM, Robert Sparks wrote: > Hi Ted - > > IIRC the reason 16 (and several other codes) were moved to reserved in > 4733 was to prepare for taking this up the standards ladder - there weren= 't > implementations using the codepoints so the independent interoperable > implementations barrier of the time couldn't be met. The text in 4733 > explicitly recognized that they might be reassigned to their 2833 meaning > if there were a reason to have them (favoring that over assigning the > codepoint to something else), so I don't think Brian is in the weeds. > Given that you could claim conformance to RFC 2833 without them, and given that the implementations of them never came forward, I think this retrograde motion isn't warranted by the explanation given so far. Just my two cents, obviously, Ted > I had the same initial reaction about whether flash was a reasonable thin= g > to use this way in the first place, but I'm not sure it's enough to push > back against allowing this protocol to carry the events that are actually > defined. > > RjS > > On 6/2/16 4:15 PM, Ted Hardie wrote: > > Hi Brian, > > On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen wrote: > >> Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80= =9CFlash=E2=80=9D, >> the signal caused by a momentary depression of the hook-switch in a POTS >> phone. When 2833 was obsoleted by 4733, flash was dropped, although the >> code 16 was reserved. >> > > It looks to me that you could be compliant with RFC 2833 without > implementing flash at all (see Section 3.3, on event types). This has be= en > effectively gone a long time, in other words. > > >> We have a use case in NENA (9-1-1 emergency stuff) where existing system= s >> use flash interspersed wth tones in signaling dialing events which are n= ot >> interpreted by the UA that receives them, but are instead transported to= a >> device that creates appropriate SIP signaling for the dialing events >> initiated. > > > > So, I'm not sure why invoking NENA and emergency services matters here. > You don't explain what the system does and how it interoperates with > anything else now. > > If I replace "NENA" with "A proprietary system uses flash interspersed > with other DTMF tones to send signalling events to a gateway" is that > approximately true? The key question seems to be "what are these events, > and what's the right way to signal them to a gateway"? > > >> We have no other way to transport flash to interwork with our newer SIP >> based emergency calling systems. >> >> I=E2=80=99m prepared to write a draft that restores code 16 for flash, a= s it was >> in 2833, but wanted to hear any objections to doing that. >> > > Let me gently suggest that you instead ask to re-use code 16, long in > abeyance, for this new purpose, whatever you eventually explain it to be. > Unless you plan to force people to go back through their old ITU E.18* do= cs > and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involv= ed > in this resurrection, saying "restores" seems like the wrong verb here. > > Just my two cents, dislodged by a knee-jerk reaction to making DTMF more > important, > > regards, > > Ted > > >> Brian >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > > _______________________________________________ > mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/m= music > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11414ce04c76c7053451e7ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 2, 2016 at 1:57 PM, Robert Sparks <rjspark= s@nostrum.com> wrote:
=20 =20 =20

Hi Ted -

IIRC the reason 16 (and several other codes) were moved to reserved in 4733 was to prepare for taking this up the standards ladder - there weren't implementations using the codepoints so th= e independent interoperable implementations barrier of the time couldn't be met. The text in 4733 explicitly recognized that they might be reassigned to their 2833 meaning if there were a reason to have them (favoring that over assigning the codepoint to something else), so I don't think Brian is in the weeds.

Given that you could claim conformance to RFC 2833 witho= ut them, and given that the implementations of them never came forward, I t= hink this retrograde motion isn't warranted by the explanation given so= far.

Just my two cents, obviously,

Ted=

=C2=A0

I had the same initial reaction about whether flash was a reasonable thing to use this way in the first place, but I'm not sure it's enough to push back against allowing this protocol to carry the events that are actually defined.

RjS


On 6/2/16 4:15 PM, Ted Hardie wrote:
Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <br@brianrosen.net> wrote:
Back in RFC28= 33, the DTMF tones section, code 16 was defined for =E2=80=9CFlash=E2= =80=9D, the signal caused by a momentary depression of the hook-switch in a POTS phone.=C2=A0 When 2833 was obsoleted by 4733, flash was dropped, although the code 16 was reserved.

It looks to me that you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event types).=C2=A0 This has been effectively gone a long time, in other words.


We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events initiated.=C2=A0


So, I'm not sure why invoking NENA and emergency services matters here.=C2=A0 You don't explain what the s= ystem does and how it interoperates with anything else now.=C2=A0= =C2=A0

If I replace "NENA" with "A proprietary system= uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately true?=C2=A0 T= he key question seems to be "what are these events, and what= 9;s the right way to signal them to a gateway"?
=C2=A0
We have no o= ther way to transport flash to interwork with our newer SIP based emergency calling systems.

I=E2=80=99m prepared to write a draft that restores code 16 f= or flash, as it was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be.=C2=A0 Unless you plan to for= ce people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb here.

Just my two cents, dislodged by a knee-jerk reaction to making DTMF more important,

regards,

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



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


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


--001a11414ce04c76c7053451e7ab-- From nobody Thu Jun 2 14:02:23 2016 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 60E6F12D88A for ; Thu, 2 Jun 2016 14:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 wLmF7MU0EoMP for ; Thu, 2 Jun 2016 14:02:19 -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 D9F3A12D88B for ; Thu, 2 Jun 2016 14:02:19 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u52L2Gno030771 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Jun 2016 16:02:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Ted Hardie , Brian Rosen References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> From: Adam Roach Message-ID: <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> Date: Thu, 2 Jun 2016 16:02:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------078B17A38417AAC7B079CFD8" Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:02:22 -0000 This is a multi-part message in MIME format. --------------078B17A38417AAC7B079CFD8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This sounds like a whole lot of talking past each other. Brian: do you have a rough picture of the system you're designing that you could share? Something that points out old parts versus new parts and highlights where RFC 4733 would be used? /a On 6/2/16 15:58, Ted Hardie wrote: > Howdy, > > In-line. > > On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen > wrote: > > Hi Ted > >> On Jun 2, 2016, at 4:15 PM, Ted Hardie > > wrote: >> >> Hi Brian, >> >> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen > > wrote: >> >> Back in RFC2833, the DTMF tones section, code 16 was defined >> for “Flashâ€, the signal caused by a momentary depression of >> the hook-switch in a POTS phone. When 2833 was obsoleted by >> 4733, flash was dropped, although the code 16 was reserved. >> >> >> It looks to me that you could be compliant with RFC 2833 without >> implementing flash at all (see Section 3.3, on event types). This >> has been effectively gone a long time, in other words. > I’m sorry, I don’t understand. > > > I'm saying that since you could call yourself compliant RFC 2833 > without implementing flash at all, the ability to count on this went > away before the turn of the millenium. As in 16 years ago. > > We’re writing a new standard, and I’d really prefer to not > reference an obsolete IETF standard in that document. I need to > signal flash, the way 2833 signaled flash, but 4733 doesn’t have a > way to signal flash. > >> >> >> We have a use case in NENA (9-1-1 emergency stuff) where >> existing systems use flash interspersed wth tones in >> signaling dialing events which are not interpreted by the UA >> that receives them, but are instead transported to a device >> that creates appropriate SIP signaling for the dialing events >> initiated. >> >> >> >> So, I'm not sure why invoking NENA and emergency services matters >> here. You don't explain what the system does and how it >> interoperates with anything else now. > I’m connecting a new IP based system that uses standards based SIP > to an existing old system. That system expects to signal to do a > call transfer or conference operation with combinations of flash > and DTMF. There is a network that is using normal SIP signaling > for transfer/conference, and this older system that is expecting > hook switch and DTMF. Ideally, we would have the UA facing the > older system do the interwork, but alas that won’t work, and we > need another element to do the interwork, and transport the DTMF > and flash to the UA which will play out the signaling. If I made > that UA and the interworking element conform to 2833, everything > would be fine, but then I’m requiring conformance to an obsolete > document. >> >> >> If I replace "NENA" with "A proprietary system uses flash >> interspersed with other DTMF tones to send signalling events to a >> gateway" is that approximately true? The key question seems to >> be "what are these events, and what's the right way to signal >> them to a gatewayâ€? > It’s approximately true, but it’s a standards based system, not a > proprietary system. > > You say that, but you appear to be implying that it is a system based > on a standard that was disappearing in 2000 (RFC 2833) and gone by > 2006 (RFC 4733). You appear to be attempting to create a new standard > in 2016 (let's be honest here, likely arriving in 2018) that > recapitulates something from the past so that NENA doesn't have to > update something that's been superseded. > > The older system is standards based, the new system is standards > based, and I need to interwork them in a standards based manner. > > > You want everyone else to re-implement flash so that NENA doesn't > replace their proprietary/superseded system? > >> We have no other way to transport flash to interwork with our >> newer SIP based emergency calling systems. >> >> I’m prepared to write a draft that restores code 16 for >> flash, as it was in 2833, but wanted to hear any objections >> to doing that. >> >> >> Let me gently suggest that you instead ask to re-use code 16, >> long in abeyance, for this new purpose, whatever you eventually >> explain it to be. Unless you plan to force people to go back >> through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs >> trying to figure out what exactly is involved in this >> resurrection, saying "restores" seems like the wrong verb here. > I am asking to use code 16 to transport flash, in exactly the same > way 2833 did. > > > And you want to undo the decisions that led to it being soft-dropped > there and deprecated. But the justification doesn't seem to be there. > >> >> Just my two cents, dislodged by a knee-jerk reaction to making >> DTMF more important, > Yeah, I’m not thrilled with more backwards compatibility stuff > either, but I’m also not a fan of an organization like NENA making > up standards using SDP, or requiring conformance to obsolete > standards. > > > How about they expressing what the actual gateway signalling > requirements are and we solve them without zombie DTMF shuffling about? > > Just a thought, > > Ted > > > Brian > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------078B17A38417AAC7B079CFD8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This sounds like a whole lot of talking past each other. Brian: do you have a rough picture of the system you're designing that you could share? Something that points out old parts versus new parts and highlights where RFC 4733 would be used?

/a

On 6/2/16 15:58, Ted Hardie wrote:
Howdy,

In-line.

On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen <br@brianrosen.net> wrote:
Hi Ted

On Jun 2, 2016, at 4:15 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <br@brianrosen.net> wrote:
Back in RFC2833, the DTMF tones section, code 16 was defined for “Flashâ€, the signal caused by a momentary depression of the hook-switch in a POTS phone.  When 2833 was obsoleted by 4733, flash was dropped, although the code 16 was reserved.

It looks to me that you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event types).  This has been effectively gone a long time, in other words.
I’m sorry, I don’t understand.

I'm saying that since you could call yourself compliant RFC 2833 without implementing flash at all, the ability to count on this went away before the turn of the millenium.  As in 16 years ago.
 
 We’re writing a new standard, and I’d really prefer to not reference an obsolete IETF standard in that document.  I need to signal flash, the way 2833 signaled flash, but 4733 doesn’t have a way to signal flash.



We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events initiated. 


So, I'm not sure why invoking NENA and emergency services matters here.  You don't explain what the system does and how it interoperates with anything else now.  
I’m connecting a new IP based system that uses standards based SIP to an existing old system.  That system expects to signal to do a call transfer or conference operation with combinations of flash and DTMF.  There is a network that is using normal SIP signaling for transfer/conference, and this older system that is expecting hook switch and DTMF.  Ideally, we would have the UA facing the older system do the interwork, but alas that won’t work, and we need another element to do the interwork, and transport the DTMF and flash to the UA which will play out the signaling.  If I made that UA and the interworking element conform to 2833, everything would be fine, but then I’m requiring conformance to an obsolete document.


If I replace "NENA" with "A proprietary system uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately true?  The key question seems to be "what are these events, and what's the right way to signal them to a gateway�
It’s approximately true, but it’s a standards based system, not a proprietary system.
You say that, but you appear to be implying that it is a system based on a standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC 4733).  You appear to be attempting to create a new standard in 2016 (let's be honest here, likely arriving in 2018) that recapitulates something from the past so that NENA doesn't have to update something that's been superseded.
 
 The older system is standards based, the new system is standards based, and I need to interwork them in  a standards based manner.  

You want everyone else to re-implement flash so that NENA doesn't replace their proprietary/superseded system?
 
 
We have no other way to transport flash to interwork with our newer SIP based emergency calling systems.

I’m prepared to write a draft that restores code 16 for flash, as it was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be.  Unless you plan to force people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb here.
I am asking to use code 16 to transport flash, in exactly the same way 2833 did.


And you want to undo the decisions that led to it being soft-dropped there and deprecated.  But the justification doesn't seem to be there.

Just my two cents, dislodged by a knee-jerk reaction to making DTMF more important,
Yeah, I’m not thrilled with more backwards compatibility stuff either, but I’m also not a fan of an organization like NENA making up standards using SDP, or requiring conformance to obsolete standards.

How about they expressing what the actual gateway signalling requirements are and we solve them without zombie DTMF shuffling about?

Just a thought,

Ted
 

Brian




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


--------------078B17A38417AAC7B079CFD8-- From nobody Thu Jun 2 14:06:12 2016 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 10C3012D88F for ; Thu, 2 Jun 2016 14:06:10 -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 c64048hi9MaA for ; Thu, 2 Jun 2016 14:06:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31A112D88E for ; Thu, 2 Jun 2016 14:06:07 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-63-57509fbddec5 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.9A.12926.DBF90575; Thu, 2 Jun 2016 23:06:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 23:05:43 +0200 From: Christer Holmberg To: Flemming Andreasen Thread-Topic: [MMUSIC] Preparing for MMUSIC meeting at IETF 96 (Berlin) Thread-Index: AQHRu0bdkiwoU1IZgESn/zyfd0ZCAp/WiaSAgAAjvCA= Date: Thu, 2 Jun 2016 21:05:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380308BA@ESESSMB209.ericsson.se> References: <73a4d9c3-ee07-6134-7f28-a0c53d530627@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380308BAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7h+7e+QHhBq2zLC3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXF8z0e2gqkOFTuuPmJqYJxm0cXIySEhYCIx 9fs/dghbTOLCvfVsXYxcHEICRxglXlybxAThLGaUODinF6iKg4NNwEKi+582iCkioC0xdQHY HGYBGYkZZxuZQGxhATeJeX+vsoLYIgLuEpO/72eCsK0krm15zghiswioSPz4dQRsL6+Ar8T8 holgNUIC+RInTi8G6+UUsJXY2APRywh02/dTa5ggdolL3HoynwniZgGJJXvOM0PYohIvH/9j hbCVJFZsv8QIciYz0Myzb6IgVglKnJz5hGUCo+gsJJNmIVTNQlIFUaIjsWD3JzYIW1ti2cLX zDD2mQOPmZDFFzCyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjLODW36r7mC8/MbxEKMA B6MSD++DKP9wIdbEsuLK3EOMEhzMSiK8C+YGhAvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+p GC4kkJ5YkpqdmlqQWgSTZeLglGpg9JrldC9fpcbT515ob9Z+653fin9Hta1hazn+IfH59OKr yj29aw967FQ5EZIXuKbH/eOP4p/WBReU1vGJ/Aqz59tklp8yYcWJ4IB94bWHGPT0Sqe/2Vxo t8Pw/Zm87sIX7wx2lE5MffxJ0qA6M8qQN0RHduk3hk//3SocdgcdP2Wq+clhRd81JZbijERD Leai4kQASdYhY68CAAA= Archived-At: Cc: mmusic Subject: Re: [MMUSIC] Preparing for MMUSIC meeting at IETF 96 (Berlin) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:06:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380308BAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >Do you expect to have anything for the MMUSIC meeting in Berlin ? At the moment there are no major open issues with any of my drafts. Somethi= ng may of course come from the IESG reviews etc, but I doubt the drafts wil= l even be IESG reviewed before Berlin, so... Regards, Christer -------- Forwarded Message -------- Subject: [MMUSIC] Preparing for MMUSIC meeting at IETF 96 (Berlin) Date: Tue, 31 May 2016 10:15:12 -0400 From: Flemming Andreasen To: mmusic Greetings MMUSIC IETF 96 will be held in Berlin July 17-26. WG scheduling requests need to be submitted by Friday this week, however before we ask for meeting time, we would like to get an indication of what topics people would like to discuss in Berlin. Thus, if you believe you (or somebody else) have a draft that would benefit from discussion in Berlin, please let us know at this time so we can plan accordingly. Thanks -- Flemming & Bo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic . --_000_7594FB04B1934943A5C02806D1A2204B380308BAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,


>Do you expect to have anything for= the MMUSIC meeting in Berlin ?

At the moment there are no major open= issues with any of my drafts. Something may of course come from the IESG r= eviews etc, but I doubt the drafts will even be IESG reviewed before Berlin, so…

 

Regards,

 

Christer

 

 



-------- Forwarded Message --------

Subjec= t:

[MMUSIC] Preparing for MMUSIC meeting at IETF 96 (Be= rlin)

Date: =

Tue, 31 May 2016 10:15:12 -0400

From: =

Flemming Andreasen <fandreas@cisco.com>

To:

mmusic <mmusic= @ietf.org>

 

Greetings MMUSIC
 
IETF 96 will be held in Berlin July 17-26. WG scheduling requests need=
 
to be submitted by Friday this week, however before we ask for meeting=
 
time, we would like to get an indication of what  topics people w=
ould 
like to discuss in Berlin. Thus, if you believe you (or somebody else)=
 
have a draft that would benefit from discussion in Berlin, please let =
us 
know at this time so we can plan accordingly.
 
Thanks
 
-- Flemming & Bo
 
 
_______________________________________________
mmusic mailing list
mmusic@ietf.org

https://www.i=
etf.org/mailman/listinfo/mmusic


.


 
--_000_7594FB04B1934943A5C02806D1A2204B380308BAESESSMB209erics_-- From nobody Thu Jun 2 14:23:03 2016 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 C69DC12D60C for ; Thu, 2 Jun 2016 14:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 wMS_92g6YZW5 for ; Thu, 2 Jun 2016 14:23:00 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AFB12D605 for ; Thu, 2 Jun 2016 14:23:00 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by comcast with SMTP id 8a4vbYqo0juYR8a4xbcJtT; Thu, 02 Jun 2016 21:22:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464902579; bh=pa3QhlWXQfXsIGW6Dt87LnLzKS91e4fIgp5CreIn7is=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ZJcqew7uxzOgY1rrztbAc7VhI7Bt7NQCU87OSHk0cmz0jTMb14lzOjJG+BrOWchs3 Q8CCDeVMuVnTbI4qJ3RSX5D+vuIqMOdGZzJxqZuT0TqDWVPSDVEC1eM9uKnzPxBvQn ESqLPa9XW/xAXSFJhs1se9RWGTOLDR0FlH8ddqfNMIQugtmdaZ0wIhtcp4DfymReq3 kHPe2LGYJ9K9lpHZ2NeOG8tKX8EY26wn1a6bFH/lm9BpwFmZaBsxTWYpBy6vEXWxQW UshVXOrmZluKOxas9Q189v+BoBMZxUaJ+hjxyfzyko5PcOx48d3W9Jsd4jxHZvuQ29 tUVGwFBfTPtNQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id 1xNz1t0093KdFy101xNzor; Thu, 02 Jun 2016 21:22:59 +0000 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: <306a4ff2-addd-0d8f-effc-be2aa74a2562@alum.mit.edu> Date: Thu, 2 Jun 2016 17:22:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:23:02 -0000 On 6/2/16 3:02 PM, Brian Rosen wrote: > Back in RFC2833, the DTMF tones section, code 16 was defined for “Flashâ€, the signal caused by a momentary depression of the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash was dropped, although the code 16 was reserved. What was the reason flash was dropped in 4733? Was there a "flash considered harmful" argument? Thanks, Paul > We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events initiated. We have no other way to transport flash to interwork with our newer SIP based emergency calling systems. > > I’m prepared to write a draft that restores code 16 for flash, as it was in 2833, but wanted to hear any objections to doing that. > > Brian > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Jun 2 14:41:56 2016 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 D9D6112D8C1 for ; Thu, 2 Jun 2016 14:41: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, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-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 zntcFG0QkVrY for ; Thu, 2 Jun 2016 14:41:52 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 3CC4F12D8BB for ; Thu, 2 Jun 2016 14:41:52 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id q45so7013377qtq.1 for ; Thu, 02 Jun 2016 14:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=m8/C1drHsml0VRVI2sCiFBQWwW20vmM+wYn+r2juIwU=; b=cLKi1KOwnQusqQh4PJYUZe1OYiGyo4/+cS/85H+fjXkWGdyYx68lwXE7a2kUIcg8Yz AsHDK34hilD6rQmy7NNq7/S8R9MEZtnTYUApKbdvdmQysdG/abyVSDT17fHKRJ0YGzP3 AQ4lhDX+3Ro+BkRVluUj8eFtmEfe4v/KTfI2bKKn/Rbf+bYRIBsijC1mxbmuLDfAHYDU qMX/dT9qyz2w/4tjvw/eQO4GzJzNk/alW7m4EQcNaESAO7BI1nU3jrviGZ7+YhfZLwOj nAQPPTrvSG31jecLwwnNbp36eyXl7BI2zFafIv8o1rOkfFcatjT/PV1vMfNzgfC3OTWH /Gug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=m8/C1drHsml0VRVI2sCiFBQWwW20vmM+wYn+r2juIwU=; b=cvvo3UbiFegvx5FiNRjseI9P1fTn+uBuA4Vq7N4TVAX4ZRizQl/v2sbINGWg0OX4n1 YeimftM5lvJhMrrfrCfZaNzoUgUkNnUv3DXE7gKcMOGSIfdAGHCeBhJ98tqJh/+A09jB V350ZyI+c1Vg87dyhU3oVgw8iCSNClSCIpDHE7p2T3LdafG5VRjnxrXoI+/f/mZVR/1v Y7T4Bw7n9xUcxrRPPzLIVbSHTcb07vEySQ99qe4fthDPYl7eIe+ZD4soWDUtlkIXDm9l rj4p+lXoamCt9znZVvNSOFB57ECNpdeWeomD00yJrPjli7T3Mqs4CcqcE9h8ayQQCNEn eitA== X-Gm-Message-State: ALyK8tJi2P3NF2iHHYb3LFFndw922LwqZ6aoEJstOuU4BuWWfQ+EJmp0BLCjR3GjW+vq+g== X-Received: by 10.200.56.53 with SMTP id q50mr345231qtb.22.1464903711256; Thu, 02 Jun 2016 14:41:51 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id d193sm235961qke.4.2016.06.02.14.41.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Jun 2016 14:41:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_940A4C91-0002-4881-9939-23B969DFB663" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> Date: Thu, 2 Jun 2016 17:41:46 -0400 Message-Id: <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:41:55 -0000 --Apple-Mail=_940A4C91-0002-4881-9939-23B969DFB663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sure SIP SIP MF SIP-UA =E2=80=94=E2=80=94 IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 = Legacy PSAP A call is up from the SIP-UA to the Legacy PSAP through the IWF and GW. The Legacy PSAP is trying to tell the SIP UA to transfer the call GW is an existing off the shelf, normal IP-PSTN gateway, most of which = actually are 2833 compliant, but I=E2=80=99m trying not to require = conformance to 2833. Note that =E2=80=9CMF=E2=80=9D is tone signaled = analog telephony. The actual MF protocol used here is CAMA. IWF is a B2BUA that has code we can do anything reasonable with, which = will conform to NENA standards. The Legacy PSAP signals a transfer by sending FLASH, digit, digit, = digit=E2=80=A6. The GW gets this signaling, but doesn=E2=80=99t really know what to do = with it, so it passes the sequence to the IWF The IWF recognizes this is a transfer request, and generates the REFER = to the SIP UA. The problem I=E2=80=99m solving is the signaling between the GW and the = IWF. I can transport the digits with 4733, but not the flash. > On Jun 2, 2016, at 5:02 PM, Adam Roach wrote: >=20 > This sounds like a whole lot of talking past each other. Brian: do you = have a rough picture of the system you're designing that you could = share? Something that points out old parts versus new parts and = highlights where RFC 4733 would be used? >=20 > /a >=20 > On 6/2/16 15:58, Ted Hardie wrote: >> Howdy, >>=20 >> In-line. >>=20 >> On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen < = br@brianrosen.net > = wrote: >> Hi Ted >>=20 >>> On Jun 2, 2016, at 4:15 PM, Ted Hardie > wrote: >>>=20 >>> Hi Brian, >>>=20 >>> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen < = br@brianrosen.net > = wrote: >>> Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. >>>=20 >>> It looks to me that you could be compliant with RFC 2833 without = implementing flash at all (see Section 3.3, on event types). This has = been effectively gone a long time, in other words. >> I=E2=80=99m sorry, I don=E2=80=99t understand. >>=20 >> I'm saying that since you could call yourself compliant RFC 2833 = without implementing flash at all, the ability to count on this went = away before the turn of the millenium. As in 16 years ago. >> =20 >> We=E2=80=99re writing a new standard, and I=E2=80=99d really prefer = to not reference an obsolete IETF standard in that document. I need to = signal flash, the way 2833 signaled flash, but 4733 doesn=E2=80=99t have = a way to signal flash. >>=20 >>>=20 >>>=20 >>> We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated.=20 >>>=20 >>>=20 >>> So, I'm not sure why invoking NENA and emergency services matters = here. You don't explain what the system does and how it interoperates = with anything else now. =20 >> I=E2=80=99m connecting a new IP based system that uses standards = based SIP to an existing old system. That system expects to signal to = do a call transfer or conference operation with combinations of flash = and DTMF. There is a network that is using normal SIP signaling for = transfer/conference, and this older system that is expecting hook switch = and DTMF. Ideally, we would have the UA facing the older system do the = interwork, but alas that won=E2=80=99t work, and we need another element = to do the interwork, and transport the DTMF and flash to the UA which = will play out the signaling. If I made that UA and the interworking = element conform to 2833, everything would be fine, but then I=E2=80=99m = requiring conformance to an obsolete document. >>>=20 >>>=20 >>> If I replace "NENA" with "A proprietary system uses flash = interspersed with other DTMF tones to send signalling events to a = gateway" is that approximately true? The key question seems to = be "what are these events, and what's the = right way to signal them to a gateway=E2=80=9D? >> It=E2=80=99s approximately true, but it=E2=80=99s a standards based = system, not a proprietary system. >> You say that, but you appear to be implying that it is a system based = on a standard that was disappearing in 2000 (RFC 2833) and gone by 2006 = (RFC 4733). You appear to be attempting to create a new standard in = 2016 (let's be honest here, likely arriving in 2018) that recapitulates = something from the past so that NENA doesn't have to update something = that's been superseded. >> =20 >> The older system is standards based, the new system is standards = based, and I need to interwork them in a standards based manner. =20 >>=20 >> You want everyone else to re-implement flash so that NENA doesn't = replace their proprietary/superseded system? >> =20 >>> =20 >>> We have no other way to transport flash to interwork with our newer = SIP based emergency calling systems. >>>=20 >>> I=E2=80=99m prepared to write a draft that restores code 16 for = flash, as it was in 2833, but wanted to hear any objections to doing = that. >>>=20 >>> Let me gently suggest that you instead ask to re-use code 16, long = in abeyance, for this new purpose, whatever you eventually explain it to = be. Unless you plan to force people to go back through their old ITU = E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what = exactly is involved in this resurrection, saying "restores" seems like = the wrong verb here. >> I am asking to use code 16 to transport flash, in exactly the same = way 2833 did. >>=20 >>=20 >> And you want to undo the decisions that led to it being soft-dropped = there and deprecated. But the justification doesn't seem to be there.=20= >>>=20 >>> Just my two cents, dislodged by a knee-jerk reaction to making DTMF = more important, >> Yeah, I=E2=80=99m not thrilled with more backwards compatibility = stuff either, but I=E2=80=99m also not a fan of an organization like = NENA making up standards using SDP, or requiring conformance to obsolete = standards. >>=20 >> How about they expressing what the actual gateway signalling = requirements are and we solve them without zombie DTMF shuffling about? >>=20 >> Just a thought, >>=20 >> Ted >> =20 >>=20 >> Brian >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic = >=20 --Apple-Mail=_940A4C91-0002-4881-9939-23B969DFB663 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sure


  =      SIP    SIP   MF
SIP-UA =E2=80=94=E2=80=94 = IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 Legacy PSAP

A call is up from the SIP-UA to the Legacy PSAP through the = IWF and GW.

The Legacy PSAP is trying to tell the SIP UA = to transfer the call

GW is an existing off the shelf, normal = IP-PSTN gateway, most of which actually are 2833 compliant, but I=E2=80=99= m trying not to require conformance to 2833. Note that =E2=80=9CMF=E2= =80=9D is tone signaled analog telephony.  The actual MF protocol = used here is CAMA.

IWF is a B2BUA that has code we can do = anything reasonable with, which will conform to NENA = standards.

The Legacy PSAP signals a transfer by = sending FLASH, digit, digit, digit=E2=80=A6.

The GW gets this signaling, but doesn=E2=80=99t really know = what to do with it, so it passes the sequence to the = IWF

The IWF recognizes this is a transfer request, and generates = the REFER to the SIP UA.

The problem I=E2=80=99m = solving is the signaling between the GW and the IWF.  I can = transport the digits with 4733, but not the flash.


On = Jun 2, 2016, at 5:02 PM, Adam Roach <adam@nostrum.com> = wrote:

=20 =20
This sounds like a whole lot of = talking past each other. Brian: do you have a rough picture of the system you're designing that you could share? Something that points out old parts versus new parts and highlights where RFC 4733 would be used?

/a

On 6/2/16 15:58, Ted Hardie wrote:
Howdy,

In-line.

On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen <br@brianrosen.net> = wrote:
Hi Ted

On Jun 2, 2016, at 4:15 PM, = Ted Hardie <ted.ietf@gmail.com> wrote:

Hi Brian,

=
On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen = <br@brianrosen.net> wrote:
Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80=9CFlash=E2=80=9D, the = signal caused by a momentary depression of the hook-switch in a POTS phone.  = When 2833 was obsoleted by 4733, flash was dropped, although the code 16 was reserved.

It looks to me that = you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event = types).  This has been effectively gone a long time, in other words.
I=E2=80=99m sorry, I don=E2=80=99t = understand.

I'm saying that since you could call = yourself compliant RFC 2833 without implementing flash at all, the ability to count on this went away before the turn of the millenium.  As in 16 years ago.
 
 We=E2=80=99re writing a new = standard, and I=E2=80=99d really prefer to not reference an obsolete IETF standard in that document.  I need to = signal flash, the way 2833 signaled flash, but 4733 doesn=E2=80=99t have a way to signal = flash.



We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events initiated. 


So, I'm not sure why = invoking NENA and emergency services matters here.  You don't = explain what the system does and how it interoperates with anything else now.  
I=E2=80=99m connecting a new IP based = system that uses standards based SIP to an existing old system.  That system expects to signal to = do a call transfer or conference operation with combinations of flash and DTMF.  There is a network that is using normal SIP signaling for transfer/conference, and this older system that is expecting hook switch and DTMF.  = Ideally, we would have the UA facing the older system do the interwork, but alas that won=E2=80=99t work, and = we need another element to do the interwork, and transport the DTMF and flash to the UA which will play out the signaling.  If I made = that UA and the interworking element conform to 2833, everything would be fine, but then I=E2=80=99m = requiring conformance to an obsolete document.


If I replace "NENA" with "A proprietary system uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately true?  The key question seems = to be "what are these events, and what's the right way to signal them to a gateway=E2=80=9D?
It=E2=80=99s approximately true, but = it=E2=80=99s a standards based system, not a proprietary system.
You say that, but you appear to be = implying that it is a system based on a standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC 4733).  = You appear to be attempting to create a new standard in 2016 (let's be honest here, likely arriving in 2018) that recapitulates something from the past so that NENA doesn't have to update something that's been superseded.
 
 The older system is = standards based, the new system is standards based, and I need to interwork them in  a standards based = manner.  

You want everyone else to re-implement = flash so that NENA doesn't replace their proprietary/superseded system?
 
 
We have no other way to transport flash to interwork with our newer SIP based emergency calling systems.

I=E2=80=99m prepared to write a = draft that restores code 16 for flash, as it was in 2833, but wanted to hear any objections to doing that.

Let me gently = suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be.  Unless you = plan to force people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb here.
I am asking to use code 16 to transport flash, in exactly the same way 2833 did.


And you want to undo the decisions that = led to it being soft-dropped there and deprecated.  But the justification doesn't seem to be there.

Just my two cents, = dislodged by a knee-jerk reaction to making DTMF more important,
Yeah, I=E2=80=99m not thrilled with more backwards compatibility stuff either, but I=E2=80=99= m also not a fan of an organization like NENA making up standards using SDP, or requiring conformance to obsolete standards.

How about they expressing what the = actual gateway signalling requirements are and we solve them without zombie DTMF shuffling about?

Just a thought,

Ted
 

Brian




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



= --Apple-Mail=_940A4C91-0002-4881-9939-23B969DFB663-- From nobody Thu Jun 2 14:48:52 2016 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 1D5F712D8C6 for ; Thu, 2 Jun 2016 14:48:51 -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=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 yyppLgZ54vSs for ; Thu, 2 Jun 2016 14:48:49 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 50A1712D609 for ; Thu, 2 Jun 2016 14:48:49 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u52LgSxp011097; Thu, 2 Jun 2016 17:48:47 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2375yw4tke-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Jun 2016 17:48:47 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 2 Jun 2016 17:48:46 -0400 From: "Rosen, Brian" To: Paul Kyzivat Thread-Topic: [MMUSIC] Transport of "Flash-hook" Thread-Index: AQHRvRiJJ5PXUGsAfk+dxPBxlU8Y5w== Date: Thu, 2 Jun 2016 21:48:45 +0000 Message-ID: <7BDC115A-9C7E-4A70-B351-E195FF17EF61@neustar.biz> References: <306a4ff2-addd-0d8f-effc-be2aa74a2562@alum.mit.edu> In-Reply-To: <306a4ff2-addd-0d8f-effc-be2aa74a2562@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.30] Content-Type: multipart/alternative; boundary="_000_7BDC115A9C7E4A70B351E195FF17EF61neustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-02_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:48:51 -0000 --_000_7BDC115A9C7E4A70B351E195FF17EF61neustarbiz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc2tlZCBIZW5uaW5nOg0KNDczMyB3aXRoIDE2IHNlZW1zIHBsYXVzaWJsZSAoYW5kIHNvbWV3 aGF0IHNpbXBsZXIgdGhhbiBJTkZPIGluIHRlcm1zIG9mIGltcGxlbWVudGF0aW9uKTsgSSBkaWQg YSBsaXR0bGUgYml0IG9mIGRpZ2dpbmcgdGhyb3VnaCBteSAyMDAyaXNoIGVtYWlsIGFyY2hpdmUg YW5kIHRoZSBpbmNsdXNpb24gY3JpdGVyaW9uIHNlZW1zIHRvIGhhdmUgYmVlbiBkb2N1bWVudGVk IHVzZS4gSSBoYXZlIGFuIGVtYWlsIG1lc3NhZ2UgaW5kaWNhdGluZyB0aGF0IGhvb2sgZmxhc2gg c2hvdWxkIGJlIGluY2x1ZGVkLCBidXQgaXQgbWF5IGhhdmUgZmFsbGVuIGludG8gdGhlIGNyYWNr cyBhcyA0NzM0IHdhcyBjb21wbGV0ZWQgYW5kIHdlIG5ldmVyIGdvdCBiYWNrIHRvIERDIChob29r KSBldmVudHMuDQoNCk1vc3QgdW5mb3J0dW5hdGVseSwgVG9tIGlzIG5vIGxvbmdlciB3aXRoIHVz Lg0KDQpCcmlhbg0KDQpPbiBKdW4gMiwgMjAxNiwgYXQgNToyMiBQTSwgUGF1bCBLeXppdmF0IDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3Rl Og0KDQpPbiA2LzIvMTYgMzowMiBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6DQpCYWNrIGluIFJGQzI4 MzMsIHRoZSBEVE1GIHRvbmVzIHNlY3Rpb24sIGNvZGUgMTYgd2FzIGRlZmluZWQgZm9yIOKAnEZs YXNo4oCdLCB0aGUgc2lnbmFsIGNhdXNlZCBieSBhIG1vbWVudGFyeSBkZXByZXNzaW9uIG9mIHRo ZSBob29rLXN3aXRjaCBpbiBhIFBPVFMgcGhvbmUuICBXaGVuIDI4MzMgd2FzIG9ic29sZXRlZCBi eSA0NzMzLCBmbGFzaCB3YXMgZHJvcHBlZCwgYWx0aG91Z2ggdGhlIGNvZGUgMTYgd2FzIHJlc2Vy dmVkLg0KDQpXaGF0IHdhcyB0aGUgcmVhc29uIGZsYXNoIHdhcyBkcm9wcGVkIGluIDQ3MzM/DQoN CldhcyB0aGVyZSBhICJmbGFzaCBjb25zaWRlcmVkIGhhcm1mdWwiIGFyZ3VtZW50Pw0KDQpUaGFu a3MsDQpQYXVsDQoNCldlIGhhdmUgYSB1c2UgY2FzZSBpbiBORU5BICg5LTEtMSBlbWVyZ2VuY3kg c3R1ZmYpIHdoZXJlIGV4aXN0aW5nIHN5c3RlbXMgdXNlIGZsYXNoIGludGVyc3BlcnNlZCB3dGgg dG9uZXMgaW4gc2lnbmFsaW5nIGRpYWxpbmcgZXZlbnRzIHdoaWNoIGFyZSBub3QgaW50ZXJwcmV0 ZWQgYnkgdGhlIFVBIHRoYXQgcmVjZWl2ZXMgdGhlbSwgYnV0IGFyZSBpbnN0ZWFkIHRyYW5zcG9y dGVkIHRvIGEgZGV2aWNlIHRoYXQgY3JlYXRlcyBhcHByb3ByaWF0ZSBTSVAgc2lnbmFsaW5nIGZv ciB0aGUgZGlhbGluZyBldmVudHMgaW5pdGlhdGVkLiAgV2UgaGF2ZSBubyBvdGhlciB3YXkgdG8g dHJhbnNwb3J0IGZsYXNoIHRvIGludGVyd29yayB3aXRoIG91ciBuZXdlciBTSVAgYmFzZWQgZW1l cmdlbmN5IGNhbGxpbmcgc3lzdGVtcy4NCg0KSeKAmW0gcHJlcGFyZWQgdG8gd3JpdGUgYSBkcmFm dCB0aGF0IHJlc3RvcmVzIGNvZGUgMTYgZm9yIGZsYXNoLCBhcyBpdCB3YXMgaW4gMjgzMywgYnV0 IHdhbnRlZCB0byBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGRvaW5nIHRoYXQuDQoNCkJyaWFuDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1h aWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0 DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== --_000_7BDC115A9C7E4A70B351E195FF17EF61neustarbiz_ Content-Type: text/html; charset="utf-8" Content-ID: <74BEA68F97403C44B7549E114402BA83@neustar.biz> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBhc2tlZCBIZW5uaW5nOg0KPGRp diBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7IGZv bnQtc2l6ZTogbWVkaXVtOyIgY2xhc3M9IiI+NDczMyB3aXRoIDE2IHNlZW1zIHBsYXVzaWJsZSAo YW5kIHNvbWV3aGF0IHNpbXBsZXIgdGhhbiBJTkZPIGluIHRlcm1zIG9mIGltcGxlbWVudGF0aW9u KTsgSSBkaWQgYSBsaXR0bGUgYml0IG9mIGRpZ2dpbmcgdGhyb3VnaCBteSAyMDAyaXNoIGVtYWls IGFyY2hpdmUgYW5kIHRoZSBpbmNsdXNpb24NCiBjcml0ZXJpb24gc2VlbXMgdG8gaGF2ZSBiZWVu IGRvY3VtZW50ZWQgdXNlLiBJIGhhdmUgYW4gZW1haWwgbWVzc2FnZSBpbmRpY2F0aW5nIHRoYXQg aG9vayBmbGFzaCBzaG91bGQgYmUgaW5jbHVkZWQsIGJ1dCBpdCBtYXkgaGF2ZSBmYWxsZW4gaW50 byB0aGUgY3JhY2tzIGFzIDQ3MzQgd2FzIGNvbXBsZXRlZCBhbmQgd2UgbmV2ZXIgZ290IGJhY2sg dG8gREMgKGhvb2spIGV2ZW50cy48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsgZm9udC1zaXplOiBtZWRpdW07IiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk1vc3Qg dW5mb3J0dW5hdGVseSwgVG9tIGlzIG5vIGxvbmdlciB3aXRoIHVzLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnJpYW48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdW4gMiwgMjAxNiwgYXQgNToyMiBQTSwgUGF1 bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiBjbGFz cz0iIj5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5PbiA2LzIvMTYgMzowMiBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QmFjayBpbiBSRkMyODMzLCB0aGUgRFRN RiB0b25lcyBzZWN0aW9uLCBjb2RlIDE2IHdhcyBkZWZpbmVkIGZvciDigJxGbGFzaOKAnSwgdGhl IHNpZ25hbCBjYXVzZWQgYnkgYSBtb21lbnRhcnkgZGVwcmVzc2lvbiBvZiB0aGUgaG9vay1zd2l0 Y2ggaW4gYSBQT1RTIHBob25lLiAmbmJzcDtXaGVuIDI4MzMgd2FzIG9ic29sZXRlZCBieSA0NzMz LCBmbGFzaCB3YXMgZHJvcHBlZCwgYWx0aG91Z2ggdGhlIGNvZGUNCiAxNiB3YXMgcmVzZXJ2ZWQu PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KV2hhdCB3YXMgdGhl IHJlYXNvbiBmbGFzaCB3YXMgZHJvcHBlZCBpbiA0NzMzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCldhcyB0aGVyZSBhICZxdW90O2ZsYXNoIGNvbnNpZGVyZWQgaGFybWZ1bCZxdW90OyBh cmd1bWVudD88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUt dGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5UaGFua3MsPGJyIGNsYXNz PSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl Ij48L3NwYW4+UGF1bDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPldlIGhhdmUgYSB1c2UgY2FzZSBpbiBORU5BICg5LTEtMSBlbWVy Z2VuY3kgc3R1ZmYpIHdoZXJlIGV4aXN0aW5nIHN5c3RlbXMgdXNlIGZsYXNoIGludGVyc3BlcnNl ZCB3dGggdG9uZXMgaW4gc2lnbmFsaW5nIGRpYWxpbmcgZXZlbnRzIHdoaWNoIGFyZSBub3QgaW50 ZXJwcmV0ZWQgYnkgdGhlIFVBIHRoYXQgcmVjZWl2ZXMgdGhlbSwgYnV0IGFyZSBpbnN0ZWFkIHRy YW5zcG9ydGVkIHRvIGENCiBkZXZpY2UgdGhhdCBjcmVhdGVzIGFwcHJvcHJpYXRlIFNJUCBzaWdu YWxpbmcgZm9yIHRoZSBkaWFsaW5nIGV2ZW50cyBpbml0aWF0ZWQuICZuYnNwO1dlIGhhdmUgbm8g b3RoZXIgd2F5IHRvIHRyYW5zcG9ydCBmbGFzaCB0byBpbnRlcndvcmsgd2l0aCBvdXIgbmV3ZXIg U0lQIGJhc2VkIGVtZXJnZW5jeSBjYWxsaW5nIHN5c3RlbXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KSeKAmW0gcHJlcGFyZWQgdG8gd3JpdGUgYSBkcmFmdCB0aGF0IHJlc3RvcmVzIGNv ZGUgMTYgZm9yIGZsYXNoLCBhcyBpdCB3YXMgaW4gMjgzMywgYnV0IHdhbnRlZCB0byBoZWFyIGFu eSBvYmplY3Rpb25zIHRvIGRvaW5nIHRoYXQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K QnJpYW48YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg Y2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7BDC115A9C7E4A70B351E195FF17EF61neustarbiz_-- From nobody Thu Jun 2 15:07:23 2016 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 2036012D8D0 for ; Thu, 2 Jun 2016 15:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 Qne9ep2LMI2Z for ; Thu, 2 Jun 2016 15:07:20 -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 E482012D8C1 for ; Thu, 2 Jun 2016 15:07:19 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u52M7Epl036811 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Jun 2016 17:07:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Brian Rosen References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> From: Adam Roach Message-ID: Date: Thu, 2 Jun 2016 17:07:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> Content-Type: multipart/alternative; boundary="------------1D2A948AFF9BD5A98FD22C04" Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:07:22 -0000 This is a multi-part message in MIME format. --------------1D2A948AFF9BD5A98FD22C04 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit And, for clarity: The SIP GW already sends event 16 when it sees a hookflash? Or do you need to update its software to accomodate this change? /a On 6/2/16 16:41, Brian Rosen wrote: > Sure > > > SIP SIP MF > SIP-UA —— IWF —— GW—— Legacy PSAP > > A call is up from the SIP-UA to the Legacy PSAP through the IWF and GW. > > The Legacy PSAP is trying to tell the SIP UA to transfer the call > > GW is an existing off the shelf, normal IP-PSTN gateway, most of which > actually are 2833 compliant, but I’m trying not to require conformance > to 2833. Note that “MF†is tone signaled analog telephony. The actual > MF protocol used here is CAMA. > > IWF is a B2BUA that has code we can do anything reasonable with, which > will conform to NENA standards. > > The Legacy PSAP signals a transfer by sending FLASH, digit, digit, digit…. > > The GW gets this signaling, but doesn’t really know what to do with > it, so it passes the sequence to the IWF > > The IWF recognizes this is a transfer request, and generates the REFER > to the SIP UA. > > The problem I’m solving is the signaling between the GW and the IWF. > I can transport the digits with 4733, but not the flash. > > >> On Jun 2, 2016, at 5:02 PM, Adam Roach > > wrote: >> >> This sounds like a whole lot of talking past each other. Brian: do >> you have a rough picture of the system you're designing that you >> could share? Something that points out old parts versus new parts and >> highlights where RFC 4733 would be used? >> >> /a >> >> On 6/2/16 15:58, Ted Hardie wrote: >>> Howdy, >>> >>> In-line. >>> >>> On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen wrote: >>> >>> Hi Ted >>> >>>> On Jun 2, 2016, at 4:15 PM, Ted Hardie >>> > wrote: >>>> >>>> Hi Brian, >>>> >>>> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen >>>> wrote: >>>> >>>> Back in RFC2833, the DTMF tones section, code 16 was >>>> defined for “Flashâ€, the signal caused by a momentary >>>> depression of the hook-switch in a POTS phone. When 2833 >>>> was obsoleted by 4733, flash was dropped, although the code >>>> 16 was reserved. >>>> >>>> >>>> It looks to me that you could be compliant with RFC 2833 >>>> without implementing flash at all (see Section 3.3, on event >>>> types). This has been effectively gone a long time, in other >>>> words. >>> I’m sorry, I don’t understand. >>> >>> >>> I'm saying that since you could call yourself compliant RFC 2833 >>> without implementing flash at all, the ability to count on this went >>> away before the turn of the millenium. As in 16 years ago. >>> >>> We’re writing a new standard, and I’d really prefer to not >>> reference an obsolete IETF standard in that document. I need to >>> signal flash, the way 2833 signaled flash, but 4733 doesn’t have >>> a way to signal flash. >>> >>>> >>>> >>>> We have a use case in NENA (9-1-1 emergency stuff) where >>>> existing systems use flash interspersed wth tones in >>>> signaling dialing events which are not interpreted by the >>>> UA that receives them, but are instead transported to a >>>> device that creates appropriate SIP signaling for the >>>> dialing events initiated. >>>> >>>> >>>> >>>> So, I'm not sure why invoking NENA and emergency services >>>> matters here. You don't explain what the system does and how >>>> it interoperates with anything else now. >>> I’m connecting a new IP based system that uses standards based >>> SIP to an existing old system. That system expects to signal to >>> do a call transfer or conference operation with combinations of >>> flash and DTMF. There is a network that is using normal SIP >>> signaling for transfer/conference, and this older system that is >>> expecting hook switch and DTMF. Ideally, we would have the UA >>> facing the older system do the interwork, but alas that won’t >>> work, and we need another element to do the interwork, and >>> transport the DTMF and flash to the UA which will play out the >>> signaling. If I made that UA and the interworking element >>> conform to 2833, everything would be fine, but then I’m >>> requiring conformance to an obsolete document. >>>> >>>> >>>> If I replace "NENA" with "A proprietary system uses flash >>>> interspersed with other DTMF tones to send signalling events to >>>> a gateway" is that approximately true? The key question seems >>>> to be "what are these events, and what's the right way to >>>> signal them to a gatewayâ€? >>> It’s approximately true, but it’s a standards based system, not >>> a proprietary system. >>> >>> You say that, but you appear to be implying that it is a system >>> based on a standard that was disappearing in 2000 (RFC 2833) and >>> gone by 2006 (RFC 4733). You appear to be attempting to create a >>> new standard in 2016 (let's be honest here, likely arriving in 2018) >>> that recapitulates something from the past so that NENA doesn't have >>> to update something that's been superseded. >>> >>> The older system is standards based, the new system is >>> standards based, and I need to interwork them in a standards >>> based manner. >>> >>> >>> You want everyone else to re-implement flash so that NENA doesn't >>> replace their proprietary/superseded system? >>> >>>> We have no other way to transport flash to interwork with >>>> our newer SIP based emergency calling systems. >>>> >>>> I’m prepared to write a draft that restores code 16 for >>>> flash, as it was in 2833, but wanted to hear any objections >>>> to doing that. >>>> >>>> >>>> Let me gently suggest that you instead ask to re-use code 16, >>>> long in abeyance, for this new purpose, whatever you eventually >>>> explain it to be. Unless you plan to force people to go back >>>> through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs >>>> trying to figure out what exactly is involved in this >>>> resurrection, saying "restores" seems like the wrong verb here. >>> I am asking to use code 16 to transport flash, in exactly the >>> same way 2833 did. >>> >>> >>> And you want to undo the decisions that led to it being soft-dropped >>> there and deprecated. But the justification doesn't seem to be there. >>> >>>> >>>> Just my two cents, dislodged by a knee-jerk reaction to making >>>> DTMF more important, >>> Yeah, I’m not thrilled with more backwards compatibility stuff >>> either, but I’m also not a fan of an organization like NENA >>> making up standards using SDP, or requiring conformance to >>> obsolete standards. >>> >>> >>> How about they expressing what the actual gateway signalling >>> requirements are and we solve them without zombie DTMF shuffling about? >>> >>> Just a thought, >>> >>> Ted >>> >>> >>> Brian >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --------------1D2A948AFF9BD5A98FD22C04 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
And, for clarity:

The SIP GW already sends event 16 when it sees a hookflash? Or do you need to update its software to accomodate this change?

/a

On 6/2/16 16:41, Brian Rosen wrote:
Sure


       SIP    SIP   MF
SIP-UA —— IWF —— GW—— Legacy PSAP

A call is up from the SIP-UA to the Legacy PSAP through the IWF and GW.

The Legacy PSAP is trying to tell the SIP UA to transfer the call

GW is an existing off the shelf, normal IP-PSTN gateway, most of which actually are 2833 compliant, but I’m trying not to require conformance to 2833. Note that “MF†is tone signaled analog telephony.  The actual MF protocol used here is CAMA.

IWF is a B2BUA that has code we can do anything reasonable with, which will conform to NENA standards.

The Legacy PSAP signals a transfer by sending FLASH, digit, digit, digit….

The GW gets this signaling, but doesn’t really know what to do with it, so it passes the sequence to the IWF

The IWF recognizes this is a transfer request, and generates the REFER to the SIP UA.

The problem I’m solving is the signaling between the GW and the IWF.  I can transport the digits with 4733, but not the flash.


On Jun 2, 2016, at 5:02 PM, Adam Roach <adam@nostrum.com> wrote:

This sounds like a whole lot of talking past each other. Brian: do you have a rough picture of the system you're designing that you could share? Something that points out old parts versus new parts and highlights where RFC 4733 would be used?

/a

On 6/2/16 15:58, Ted Hardie wrote:
Howdy,

In-line.

On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen <br@brianrosen.net> wrote:
Hi Ted

On Jun 2, 2016, at 4:15 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <br@brianrosen.net> wrote:
Back in RFC2833, the DTMF tones section, code 16 was defined for “Flashâ€, the signal caused by a momentary depression of the hook-switch in a POTS phone.  When 2833 was obsoleted by 4733, flash was dropped, although the code 16 was reserved.

It looks to me that you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event types).  This has been effectively gone a long time, in other words.
I’m sorry, I don’t understand.

I'm saying that since you could call yourself compliant RFC 2833 without implementing flash at all, the ability to count on this went away before the turn of the millenium.  As in 16 years ago.
 
 We’re writing a new standard, and I’d really prefer to not reference an obsolete IETF standard in that document.  I need to signal flash, the way 2833 signaled flash, but 4733 doesn’t have a way to signal flash.



We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events initiated. 


So, I'm not sure why invoking NENA and emergency services matters here.  You don't explain what the system does and how it interoperates with anything else now.  
I’m connecting a new IP based system that uses standards based SIP to an existing old system.  That system expects to signal to do a call transfer or conference operation with combinations of flash and DTMF.  There is a network that is using normal SIP signaling for transfer/conference, and this older system that is expecting hook switch and DTMF.  Ideally, we would have the UA facing the older system do the interwork, but alas that won’t work, and we need another element to do the interwork, and transport the DTMF and flash to the UA which will play out the signaling.  If I made that UA and the interworking element conform to 2833, everything would be fine, but then I’m requiring conformance to an obsolete document.


If I replace "NENA" with "A proprietary system uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately true?  The key question seems to be "what are these events, and what's the right way to signal them to a gateway�
It’s approximately true, but it’s a standards based system, not a proprietary system.
You say that, but you appear to be implying that it is a system based on a standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC 4733).  You appear to be attempting to create a new standard in 2016 (let's be honest here, likely arriving in 2018) that recapitulates something from the past so that NENA doesn't have to update something that's been superseded.
 
 The older system is standards based, the new system is standards based, and I need to interwork them in  a standards based manner.  

You want everyone else to re-implement flash so that NENA doesn't replace their proprietary/superseded system?
 
 
We have no other way to transport flash to interwork with our newer SIP based emergency calling systems.

I’m prepared to write a draft that restores code 16 for flash, as it was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be.  Unless you plan to force people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb here.
I am asking to use code 16 to transport flash, in exactly the same way 2833 did.


And you want to undo the decisions that led to it being soft-dropped there and deprecated.  But the justification doesn't seem to be there.

Just my two cents, dislodged by a knee-jerk reaction to making DTMF more important,
Yeah, I’m not thrilled with more backwards compatibility stuff either, but I’m also not a fan of an organization like NENA making up standards using SDP, or requiring conformance to obsolete standards.

How about they expressing what the actual gateway signalling requirements are and we solve them without zombie DTMF shuffling about?

Just a thought,

Ted
 

Brian




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




--------------1D2A948AFF9BD5A98FD22C04-- From nobody Fri Jun 3 01:59:15 2016 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 E59B612D1E2; Fri, 3 Jun 2016 01:59:13 -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 OG9ajz9wAWVe; Fri, 3 Jun 2016 01:59:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373F512D551; Fri, 3 Jun 2016 01:59:11 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-c5-575146dc806c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BC.80.12926.CD641575; Fri, 3 Jun 2016 10:59:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.294.0; Fri, 3 Jun 2016 10:59:01 +0200 To: Christer Holmberg , Suhas Nandakumar References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se> From: Magnus Westerlund Message-ID: <37721757-37fe-df9d-9853-4bd59c0d16f4@ericsson.com> Date: Fri, 3 Jun 2016 10:58:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM2K7t+5dt8Bwg6Mr+Sxe9qxkt1j+8gSj xdTlj1ksds7tYHZg8Zh2/z6bx85Zd9k9liz5yRTAHMVlk5Kak1mWWqRvl8CV0fP/CmPBc52K xQcXsjQwflHoYuTkkBAwkWjtuswIYYtJXLi3ng3EFhI4wigx9a1KFyMXkL2MUeLE10VACQ4O YYEQiQ0LskBMEYEEiTONXhAlRxkl3n+4xwTSyyzQyCix5YMXiM0mYCFx80cj2ExeAXuJrdd/ gdksAioS9xasB6sXFYiR2N41mR2iRlDi5MwnLCA2p4C1xJbFy9hBdjED9T7YWgYxXl6ieets ZogztSUamjpYJzAKzkLSPQuhYxaSjgWMzKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAsP4 4JbfqjsYL79xPMQowMGoxMObsCYgXIg1say4MvcQowQHs5IIr7VtYLgQb0piZVVqUX58UWlO avEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUwWSYOTqkGxhjNpMuMEw6uFX/06+SJjR+Ppt0I /MCbuL4vz9KoTEv189rXs5afV4xMTdBo2Vg/U1Bm7wX+HVqbD+VsMQgO/+P+ze/5okD+9qUf hb5dfRJ9qVhnfeHTuKN/AiUsd7WsZHltq345YdeOQ6kzXl6uSVPp2u92bb6M48JPeR2r9yYp fON/wfB92WolluKMREMt5qLiRADUliieXwIAAA== Archived-At: Cc: "Colin Perkins \(csp@csperkins.org\)" , "mmusic@ietf.org" , "avt@ietf.org" Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 08:59:14 -0000 Den 2016-05-30 kl. 10:08, skrev Christer Holmberg: > Hi Suhas, > > I have the same understanding as you: the offerer indicates support of > RTP/RTCP-mux, and the answerer decides whether to use it or not. And, if > used, it will be used in BOTH directions – i.e. the usage of RTP/RTCP is > not per direction. > > Colin? Magnus? Yes, I do agree with your interpretations here. Both that it applies bi-directional after mutual agreement, and that if the answer would like to use it, it will have to do a re-invite with an offer including a=rtcp-mux attribute to see if the peer accepts that. /Magnus > > Regards, > > Christer > > From: Suhas Nandakumar > > Date: Friday 27 May 2016 at 04:25 > To: Christer Holmberg > > Cc: "mmusic@ietf.org " >, "avt@ietf.org " > >, Magnus Westerlund > >, Colin Perkins > > > Subject: Re: [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included > in offer? > > Going along O/A negotiation procedures, i would lean towards your former > conclusion that the offer needs to include the rtcp-mux ability. > If the offer doesn't include a=rtcp-mux and the answerer wants to mux , > then it needs a new O/A from the answerer's perspectives. > > > If we make a=rtcp-mux a declarative SDP it might solve the other use-case .. > > thanks > Suhas > > On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg > > > wrote: > > (Sorry for the cross-posting)____ > > __ __ > > Hi,____ > > __ __ > > There has been a discussion in 3GPP regarding RFC 5761 > (RTP/RTCP-mux).____ > > __ __ > > Section 5.1.1 says:____ > > __ __ > > 5.1.1. SDP Signalling____ > > __ __ > > When the Session Description Protocol (SDP) [8] is used to > negotiate____ > > RTP sessions following the offer/answer model [9], the > "a=rtcp-mux"____ > > attribute (see Section 8) indicates the desire to multiplex RTP > and____ > > RTCP onto a single port. The initial SDP offer MUST include this____ > > attribute at the media level to request multiplexing of RTP and > RTCP____ > > on a single port. For example:____ > > __ __ > > v=0____ > > o=csp 1153134164 1153134164 IN IP6 > 2001:DB8::211:24ff:fea3:7a2e____ > > s=-____ > > c=IN IP6 2001:DB8::211:24ff:fea3:7a2e____ > > t=1153134164 1153137764____ > > m=audio 49170 RTP/AVP 97____ > > a=rtpmap:97 iLBC/8000____ > > a=rtcp-mux____ > > __ __ > > This offer denotes a unicast voice-over-IP session using the > RTP/AVP____ > > profile with iLBC coding. The answerer is requested to send both > RTP____ > > and RTCP to port 49170 on IPv6 address > 2001:DB8::211:24ff:fea3:7a2e.____ > > __ __ > > If the answerer wishes to multiplex RTP and RTCP onto a single > port,____ > > it MUST include a media-level "a=rtcp-mux" attribute in the > answer.____ > > The RTP payload types used in the answer MUST conform to the > rules in____ > > Section 4.____ > > __ __ > > If the answer does not contain an "a=rtcp-mux" attribute, the > offerer____ > > MUST NOT multiplex RTP and RTCP packets on a single port. > Instead,____ > > it should send and receive RTCP on a port allocated according to > the____ > > usual port-selection rules (either the port pair, or a signalled > port____ > > if the "a=rtcp:" attribute [10] is also included). This will > occur____ > > when talking to a peer that does not understand the "a=rtcp-mux"____ > > attribute.____ > > __ __ > > Q: The question is whether it is allowed to include a=rtcp-mux in an > answer if the associated offer did NOT contain a=rtcp-mux.____ > > __ __ > > The second last paragraph in the text above does say that, if the > answer wishes to do RTP/RTCP-mux, it includes a=rtcp-mux in the > answer.____ > > __ __ > > BUT, in my view that is it based on the first paragraph, which > assumes a=rtcp-mux is also included in the offer.____ > > __ __ > > Or, am I wrong? Is it allowed to include a=rtcp-mux in the answer, > even if it’s not included in the offer? If so, how will the offerer > then indicate whether mux is used or not.____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jun 3 02:25:48 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0705D12B065; Fri, 3 Jun 2016 02:25:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603092544.1402.97385.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 02:25:44 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 09:25:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-05.txt Pages : 11 Date : 2016-06-03 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 3 02:45:30 2016 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 4592F12B054; Fri, 3 Jun 2016 02:45:26 -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 JVqH6_jpy0eb; Fri, 3 Jun 2016 02:45:22 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD4D12B038; Fri, 3 Jun 2016 02:45:21 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-9e-575151af642d Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.47.27088.FA151575; Fri, 3 Jun 2016 11:45:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 11:45:19 +0200 From: Christer Holmberg To: Magnus Westerlund , Suhas Nandakumar Thread-Topic: [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? Thread-Index: AdG3iWsAcXNHXXrjTfakEZTp6P/ejwAHIEqAAKtQNIAAxI5kAAAIAfOA Date: Fri, 3 Jun 2016 09:45:18 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se> <37721757-37fe-df9d-9853-4bd59c0d16f4@ericsson.com> In-Reply-To: <37721757-37fe-df9d-9853-4bd59c0d16f4@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <88DF177B1E02B54EAFDEE50A4982D5CF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7hO76wMBwg819lhYve1ayWyx/eYLR YuryxywWO+d2MDuweEy7f5/NY+esu+weS5b8ZApgjuKySUnNySxLLdK3S+DK6D7YzlhwT6/i eM8atgbG50pdjJwcEgImEoe/vmeDsMUkLtxbD2RzcQgJHGGU+LhmMyOEs5hR4tjV20AZDg42 AQuJ7n/aIA0iAgkSO/q2sIDYzAKNjBJbPniBlAgLhEhsWJAFYooIhErcfiYNUe0m8e39XxaQ MIuAisSVXj+QMK+AlcSqpUehFv1mlDjUcxvsHE4BB4mvZ2eA2YxAp30/tYYJYpO4xK0n85kg ThaQWLLnPDOELSrx8vE/VhBbVEBP4su9eYwQcUWJq9OXQ/XqSdyYOgXsEWYBa4mWxlKIsLbE soWvmSHuEZQ4OfMJywRGiVlIts1C0j0LoXsWku5ZSLoXMLKuYhQtTi1Oyk03MtJLLcpMLi7O z9PLSy3ZxAiMzoNbfhvsYHz53PEQowAHoxIPb8KagHAh1sSy4srcQ4wSHMxKIrysAYHhQrwp iZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhg3fXhS+sI2i1v3 V4HY4/PL4y+suCDiU8D1iKfwx3WvEF6jJQ/N/vJOKfVf0sDgnSi6/xpPT8eyu24XjjFEOv7L 9+w2nrWK7e1NX7PWrfeaq3risjeJcSbHXNGbF7Xxe3LJKwuZuz+ere7YujMoOd4wtzKt+nyf xZQ3kX94vDhfh8rN+HVK66ISS3FGoqEWc1FxIgBqrXCGygIAAA== Archived-At: Cc: "Colin Perkins \(csp@csperkins.org\)" , "mmusic@ietf.org" , "avt@ietf.org" Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 09:45:26 -0000 Hi, >>I have the same understanding as you: the offerer indicates support of >> RTP/RTCP-mux, and the answerer decides whether to use it or not. And, if >> used, it will be used in BOTH directions =AD i.e. the usage of RTP/RTCP = is >> not per direction. >> >> Colin? Magnus? > >Yes, I do agree with your interpretations here. Both that it applies >bi-directional after mutual agreement, and that if the answer would like >to use it, it will have to do a re-invite with an offer including >a=3Drtcp-mux attribute to see if the peer accepts that. How could we clarify that? Errata? Clarification RFC? Regards, Christer >> >> From: Suhas Nandakumar >> >> Date: Friday 27 May 2016 at 04:25 >> To: Christer Holmberg > > >> Cc: "mmusic@ietf.org " > >, "avt@ietf.org " >> >, Magnus Westerlund >> > >, Colin Perkins >> > >> Subject: Re: [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included >> in offer? >> >> Going along O/A negotiation procedures, i would lean towards your former >> conclusion that the offer needs to include the rtcp-mux ability. >> If the offer doesn't include a=3Drtcp-mux and the answerer wants to mux = , >> then it needs a new O/A from the answerer's perspectives. >> >> >> If we make a=3Drtcp-mux a declarative SDP it might solve the other >>use-case .. >> >> thanks >> Suhas >> >> On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg >> > >> wrote: >> >> (Sorry for the cross-posting)____ >> >> __ __ >> >> Hi,____ >> >> __ __ >> >> There has been a discussion in 3GPP regarding RFC 5761 >> (RTP/RTCP-mux).____ >> >> __ __ >> >> Section 5.1.1 says:____ >> >> __ __ >> >> 5.1.1. SDP Signalling____ >> >> __ __ >> >> When the Session Description Protocol (SDP) [8] is used to >> negotiate____ >> >> RTP sessions following the offer/answer model [9], the >> "a=3Drtcp-mux"____ >> >> attribute (see Section 8) indicates the desire to multiplex RTP >> and____ >> >> RTCP onto a single port. The initial SDP offer MUST include >>this____ >> >> attribute at the media level to request multiplexing of RTP and >> RTCP____ >> >> on a single port. For example:____ >> >> __ __ >> >> v=3D0____ >> >> o=3Dcsp 1153134164 1153134164 IN IP6 >> 2001:DB8::211:24ff:fea3:7a2e____ >> >> s=3D-____ >> >> c=3DIN IP6 2001:DB8::211:24ff:fea3:7a2e____ >> >> t=3D1153134164 1153137764____ >> >> m=3Daudio 49170 RTP/AVP 97____ >> >> a=3Drtpmap:97 iLBC/8000____ >> >> a=3Drtcp-mux____ >> >> __ __ >> >> This offer denotes a unicast voice-over-IP session using the >> RTP/AVP____ >> >> profile with iLBC coding. The answerer is requested to send both >> RTP____ >> >> and RTCP to port 49170 on IPv6 address >> 2001:DB8::211:24ff:fea3:7a2e.____ >> >> __ __ >> >> If the answerer wishes to multiplex RTP and RTCP onto a single >> port,____ >> >> it MUST include a media-level "a=3Drtcp-mux" attribute in the >> answer.____ >> >> The RTP payload types used in the answer MUST conform to the >> rules in____ >> >> Section 4.____ >> >> __ __ >> >> If the answer does not contain an "a=3Drtcp-mux" attribute, the >> offerer____ >> >> MUST NOT multiplex RTP and RTCP packets on a single port. >> Instead,____ >> >> it should send and receive RTCP on a port allocated according to >> the____ >> >> usual port-selection rules (either the port pair, or a signalled >> port____ >> >> if the "a=3Drtcp:" attribute [10] is also included). This will >> occur____ >> >> when talking to a peer that does not understand the >>"a=3Drtcp-mux"____ >> >> attribute.____ >> >> __ __ >> >> Q: The question is whether it is allowed to include a=3Drtcp-mux in = an >> answer if the associated offer did NOT contain a=3Drtcp-mux.____ >> >> __ __ >> >> The second last paragraph in the text above does say that, if the >> answer wishes to do RTP/RTCP-mux, it includes a=3Drtcp-mux in the >> answer.____ >> >> __ __ >> >> BUT, in my view that is it based on the first paragraph, which >> assumes a=3Drtcp-mux is also included in the offer.____ >> >> __ __ >> >> Or, am I wrong? Is it allowed to include a=3Drtcp-mux in the answer, >> even if it=B9s not included in the offer? If so, how will the offere= r >> then indicate whether mux is used or not.____ >> >> __ __ >> >> Regards,____ >> >> __ __ >> >> Christer____ >> >> __ __ >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Fri Jun 3 05:36:17 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEA812D120; Fri, 3 Jun 2016 05:36:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603123616.1397.33827.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 05:36:16 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, mmusic@ietf.org, ben@nostrum.com Subject: [MMUSIC] mmusic - New Meeting Session Request for IETF 96 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:36:16 -0000 A new meeting session request has just been submitted by Flemming Andreasen, a Chair of the mmusic working group. --------------------------------------------------------- Working Group Name: Multiparty Multimedia Session Control Area Name: Applications and Real-Time Area Session Requester: Flemming Andreasen Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: i2nsf dots core payload dispatch sipcore avtext avtcore rtcweb httpbis ice tls Second Priority: clue p2psip straw xrblock rmcat stir tram sfc sacm Special Requests: --------------------------------------------------------- From nobody Fri Jun 3 05:36:28 2016 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 BEC7312D13E for ; Fri, 3 Jun 2016 05:36:26 -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=brianrosen-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 kJGOrjyz9SXd for ; Fri, 3 Jun 2016 05:36:23 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 44DE212D126 for ; Fri, 3 Jun 2016 05:36:23 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id j96so1101416qge.0 for ; Fri, 03 Jun 2016 05:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=bLc6KEnzaJGjah52riDibXhDUaS/PgxPtSeXg+VpmXQ=; b=t/hgphEJNbnUOtq2Jik0/ycPAiG9+BECo0EPSKFsrr7JT0N9tznQJ76Ac3WGZMXdU6 Ma0n4Fb/P8uhPWDFfjsaTGCUd/ELdFUlAbDTVAlKPF+kAzJbegQWQVQ78Gw6Yk8PYlzc MzpIuvQlNjfiHNryHkL63b/CP0YBse08fQeJ2W6iPGRvs6bjiEHGCiiA1Eor7zGdH6NE Os792tAK7RHK8fDvu2C6lDdrc0hOa8Fe/Gjw0XG738QXOiyZWzQGIw5XBp0MAXD5EobA 7ZENMvmcB1NHCqdceFyifJD3SirPXE5yJVeL6misHwR5Pcfs/8MuZj3np2J1At0TkqWg TGqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=bLc6KEnzaJGjah52riDibXhDUaS/PgxPtSeXg+VpmXQ=; b=VTIsrj5oFzPH+c9cY7eBCH8MLeaf/iaByGZsDs+eJ96WK+8PrHMMMoZdc9CTZ+RbWe 6omSIPIc7YC/VTH9FlbDO9OFvVLH1k/+PLGKSUiZCcOIIOnrW/xyTOoheu0ZG+J9oXJa ZOGUFvdJ5s4Kqb99OBbFvawnwTPsHnhL6UOpuPe5Nch03udNwqpkF8w8yqU8SOiPJORo R0nIBcqho9V+Vx9bFXOkoba5u7FudIcE0gMKDx1ACSQUs3iFlzJADR2AUKpz7FnBdXng vWz2cLiCjY4ebKWv6iCNQwEk54l+ec59TuVtHQMypYFYjieVsaiiIIzsJYQyHxbYOqt4 HTHw== X-Gm-Message-State: ALyK8tKxRvDG6NJnhvUrUS2BO+llKIGpVkQncQj8QO8Wqifd8t79J9kic4DInYfB10uCog== X-Received: by 10.140.228.134 with SMTP id y128mr2961384qhb.81.1464957382376; Fri, 03 Jun 2016 05:36:22 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 76sm984856qgt.34.2016.06.03.05.36.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Jun 2016 05:36:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 3 Jun 2016 08:36:18 -0400 Message-Id: <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:36:27 -0000 --Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yeah, the ones I know about do. They claim 2833 compliance for the most = part. As I said, one way to solve this is just require 2833 compliance in a = spec written in 2016. =20 We probably wouldn=E2=80=99t allow a normative reference to 2833 in some = standards track RFC we wrote today; we would fix whatever the problem = was. Brian > On Jun 2, 2016, at 6:07 PM, Adam Roach wrote: >=20 > And, for clarity: >=20 > The SIP GW already sends event 16 when it sees a hookflash? Or do you = need to update its software to accomodate this change? >=20 > /a >=20 > On 6/2/16 16:41, Brian Rosen wrote: >> Sure >>=20 >>=20 >> SIP SIP MF >> SIP-UA =E2=80=94=E2=80=94 IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 = Legacy PSAP >>=20 >> A call is up from the SIP-UA to the Legacy PSAP through the IWF and = GW. >>=20 >> The Legacy PSAP is trying to tell the SIP UA to transfer the call >>=20 >> GW is an existing off the shelf, normal IP-PSTN gateway, most of = which actually are 2833 compliant, but I=E2=80=99m trying not to require = conformance to 2833. Note that =E2=80=9CMF=E2=80=9D is tone signaled = analog telephony. The actual MF protocol used here is CAMA. >>=20 >> IWF is a B2BUA that has code we can do anything reasonable with, = which will conform to NENA standards. >>=20 >> The Legacy PSAP signals a transfer by sending FLASH, digit, digit, = digit=E2=80=A6. >>=20 >> The GW gets this signaling, but doesn=E2=80=99t really know what to = do with it, so it passes the sequence to the IWF >>=20 >> The IWF recognizes this is a transfer request, and generates the = REFER to the SIP UA. >>=20 >> The problem I=E2=80=99m solving is the signaling between the GW and = the IWF. I can transport the digits with 4733, but not the flash. >>=20 >>=20 >>> On Jun 2, 2016, at 5:02 PM, Adam Roach < = adam@nostrum.com > = wrote: >>>=20 >>> This sounds like a whole lot of talking past each other. Brian: do = you have a rough picture of the system you're designing that you could = share? Something that points out old parts versus new parts and = highlights where RFC 4733 would be used? >>>=20 >>> /a >>>=20 >>> On 6/2/16 15:58, Ted Hardie wrote: >>>> Howdy, >>>>=20 >>>> In-line. >>>>=20 >>>> On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen < = br@brianrosen.net > = wrote: >>>> Hi Ted >>>>=20 >>>>> On Jun 2, 2016, at 4:15 PM, Ted Hardie < = ted.ietf@gmail.com = > wrote: >>>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen < = br@brianrosen.net > = wrote: >>>>> Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. >>>>>=20 >>>>> It looks to me that you could be compliant with RFC 2833 without = implementing flash at all (see Section 3.3, on event types). This has = been effectively gone a long time, in other words. >>>> I=E2=80=99m sorry, I don=E2=80=99t understand. >>>>=20 >>>> I'm saying that since you could call yourself compliant RFC 2833 = without implementing flash at all, the ability to count on this went = away before the turn of the millenium. As in 16 years ago. >>>> =20 >>>> We=E2=80=99re writing a new standard, and I=E2=80=99d really = prefer to not reference an obsolete IETF standard in that document. I = need to signal flash, the way 2833 signaled flash, but 4733 doesn=E2=80=99= t have a way to signal flash. >>>>=20 >>>>>=20 >>>>>=20 >>>>> We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated.=20 >>>>>=20 >>>>>=20 >>>>> So, I'm not sure why invoking NENA and emergency services matters = here. You don't explain what the system does and how it interoperates = with anything else now. =20 >>>> I=E2=80=99m connecting a new IP based system that uses standards = based SIP to an existing old system. That system expects to signal to = do a call transfer or conference operation with combinations of flash = and DTMF. There is a network that is using normal SIP signaling for = transfer/conference, and this older system that is expecting hook switch = and DTMF. Ideally, we would have the UA facing the older system do the = interwork, but alas that won=E2=80=99t work, and we need another element = to do the interwork, and transport the DTMF and flash to the UA which = will play out the signaling. If I made that UA and the interworking = element conform to 2833, everything would be fine, but then I=E2=80=99m = requiring conformance to an obsolete document. >>>>>=20 >>>>>=20 >>>>> If I replace "NENA" with "A proprietary system uses flash = interspersed with other DTMF tones to send signalling events to a = gateway" is that approximately true? The key question seems to be "what = are these events, and what's the right way to signal them to a = gateway=E2=80=9D? >>>> It=E2=80=99s approximately true, but it=E2=80=99s a standards based = system, not a proprietary system. >>>> You say that, but you appear to be implying that it is a system = based on a standard that was disappearing in 2000 (RFC 2833) and gone by = 2006 (RFC 4733). You appear to be attempting to create a new standard = in 2016 (let's be honest here, likely arriving in 2018) that = recapitulates something from the past so that NENA doesn't have to = update something that's been superseded. >>>> =20 >>>> The older system is standards based, the new system is standards = based, and I need to interwork them in a standards based manner. =20 >>>>=20 >>>> You want everyone else to re-implement flash so that NENA doesn't = replace their proprietary/superseded system? >>>> =20 >>>>> =20 >>>>> We have no other way to transport flash to interwork with our = newer SIP based emergency calling systems. >>>>>=20 >>>>> I=E2=80=99m prepared to write a draft that restores code 16 for = flash, as it was in 2833, but wanted to hear any objections to doing = that. >>>>>=20 >>>>> Let me gently suggest that you instead ask to re-use code 16, long = in abeyance, for this new purpose, whatever you eventually explain it to = be. Unless you plan to force people to go back through their old ITU = E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what = exactly is involved in this resurrection, saying "restores" seems like = the wrong verb here. >>>> I am asking to use code 16 to transport flash, in exactly the same = way 2833 did. >>>>=20 >>>>=20 >>>> And you want to undo the decisions that led to it being = soft-dropped there and deprecated. But the justification doesn't seem = to be there.=20 >>>>>=20 >>>>> Just my two cents, dislodged by a knee-jerk reaction to making = DTMF more important, >>>> Yeah, I=E2=80=99m not thrilled with more backwards compatibility = stuff either, but I=E2=80=99m also not a fan of an organization like = NENA making up standards using SDP, or requiring conformance to obsolete = standards. >>>>=20 >>>> How about they expressing what the actual gateway signalling = requirements are and we solve them without zombie DTMF shuffling about? >>>>=20 >>>> Just a thought, >>>>=20 >>>> Ted >>>> =20 >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic = >>>=20 >>=20 >=20 --Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yeah, the ones I know about do.  They claim 2833 = compliance for the most part.

As I said, one way to solve this is just require 2833 = compliance in a spec written in 2016.  
We = probably wouldn=E2=80=99t allow a normative reference to 2833 in some = standards track RFC we wrote today; we would fix whatever the problem = was.

Brian

On Jun 2, 2016, at 6:07 PM, Adam Roach <adam@nostrum.com> = wrote:

=20 =20
And, for clarity:

The SIP GW already sends event 16 when it sees a hookflash? Or do you need to update its software to accomodate this change?

/a

On 6/2/16 16:41, Brian Rosen wrote:
Sure


    =    SIP    SIP   MF
SIP-UA =E2=80=94=E2= =80=94 IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 Legacy PSAP

A call is up = from the SIP-UA to the Legacy PSAP through the IWF and GW.

The Legacy PSAP = is trying to tell the SIP UA to transfer the call

GW is an = existing off the shelf, normal IP-PSTN gateway, most of which actually are 2833 compliant, but I=E2=80=99m trying not to require = conformance to 2833. Note that =E2=80=9CMF=E2=80=9D is tone signaled = analog telephony.  The actual MF protocol used here is CAMA.

IWF is a B2BUA = that has code we can do anything reasonable with, which will conform to NENA standards.

The Legacy PSAP signals a transfer by sending FLASH, digit, digit, = digit=E2=80=A6.

The GW gets this signaling, but doesn=E2=80=99t really know what to do with it, = so it passes the sequence to the IWF

The IWF = recognizes this is a transfer request, and generates the REFER to the SIP UA.

The problem = I=E2=80=99m solving is the signaling between the GW and the IWF.  I = can transport the digits with 4733, but not the = flash.


On Jun 2, 2016, at 5:02 PM, Adam Roach = <adam@nostrum.com> wrote:

This sounds like a whole lot of talking past each other. Brian: do you have a rough picture of the system you're designing that you could share? Something that points out old parts versus new parts and highlights where RFC 4733 would be used?

/a

On 6/2/16 15:58, Ted Hardie wrote:
Howdy,

In-line.

On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen = <br@brianrosen.net> wrote:
Hi Ted

On Jun 2, 2016, = at 4:15 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Hi Brian,
On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen = <br@brianrosen.net> wrote:
Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80=9CFlash=E2=80=9D,= the signal caused by a momentary depression of the hook-switch in a POTS phone.  When 2833 = was obsoleted by 4733, flash was dropped, although the code 16 was reserved.

It looks to me that you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event types).  = This has been effectively gone a long time, in other words.
I=E2=80=99m sorry, I don=E2=80=99= t understand.

I'm saying that since you could call yourself compliant RFC 2833 without implementing flash at all, the ability to count on this went away before the turn of the millenium.  As in 16 = years ago.
 
 We=E2=80=99re = writing a new standard, and I=E2=80=99d really = prefer to not reference an obsolete IETF standard in that document.  I = need to signal flash, the way 2833 signaled flash, but 4733 doesn=E2=80=99= t have a way to signal flash.



We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events = initiated. 


So, I'm not sure why invoking NENA and emergency services matters here.  You don't explain what the system does and how it interoperates with anything else = now.  
I=E2=80=99m connecting a new = IP based system that uses standards based SIP to an existing old system.  = That system expects to signal to do a call transfer or conference operation with combinations of flash and DTMF.  There is a network = that is using normal SIP signaling for transfer/conference, and this older system that is expecting hook switch and DTMF.  Ideally, we would = have the UA facing the older system do the interwork, but alas that won=E2=80= =99t work, and we need another element to do the interwork, and transport the DTMF and flash to the UA which will play out the signaling.  If I = made that UA and the interworking element conform to 2833, everything would be fine, but then I=E2=80=99m requiring conformance to an obsolete = document.


If I replace "NENA" with "A proprietary system uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately = true?  The key question seems to be "what are these events, and what's the right way to signal them to a = gateway=E2=80=9D?
It=E2=80=99s approximately = true, but it=E2=80=99s a standards based = system, not a proprietary system.
You say that, but you appear to be implying that it is a system based on a standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC 4733).  You appear to be attempting = to create a new standard in 2016 (let's be honest here, likely arriving in 2018) that recapitulates something from the past so that NENA doesn't have to update something that's been superseded.
 
 The older system = is standards based, the new system is standards based, and I need to interwork them in  a standards = based manner.  

You want everyone else to re-implement flash so that NENA doesn't replace their proprietary/superseded system?
 
 
We have no other way to transport flash to interwork with our newer SIP based emergency calling systems.

I=E2=80=99m prepared = to write a draft that restores code 16 for flash, as it was in 2833, but wanted to hear any objections to doing that.

Let me gently suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be.  Unless = you plan to force people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb = here.
I am asking to use code 16 to transport flash, in exactly the same way 2833 did.


And you want to undo the decisions that led to it being soft-dropped there and deprecated.  = But the justification doesn't seem to be there.

Just my two cents, dislodged by a knee-jerk reaction to making DTMF more = important,
Yeah, I=E2=80=99m not = thrilled with more backwards compatibility stuff either, but I=E2=80=99m also not a = fan of an organization like NENA making up standards using SDP, or requiring conformance to obsolete = standards.

How about they expressing = what the actual gateway signalling requirements are and we solve them without zombie DTMF shuffling about?

Just a thought,
=
Ted
 

Brian




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





= --Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B-- From nobody Fri Jun 3 06:09:16 2016 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 B741812D19E for ; Fri, 3 Jun 2016 06:09:14 -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 M93Xqn6vk4pE for ; Fri, 3 Jun 2016 06:09:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7AE12D0F7 for ; Fri, 3 Jun 2016 06:09:11 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-e4-5751817670fe Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B1.4E.18043.67181575; Fri, 3 Jun 2016 15:09:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 15:09:09 +0200 From: Christer Holmberg To: Christer Holmberg , Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 Thread-Index: AQHRtSvFlj02GsdUjEqN/h66uVwldJ/G2V+AgADkx4CAAGOpgIAAAaaAgAA66nD//+ymgIAAJPaQ///fdYCAABD5AIAABAeAgAAA6oCAAOs3gIABvEKAgAAif4CAACIs/oABJNaA///5JAAABOE4L///6iUAgAA3FYCAAAZ+gIAAKGoAgAAEbAD//8AqMIAAZnKAgAQpdQCAADi0gIAATZ/d///gtwD//9XcMAA44hMAAAFoUAAAA00LgAAfI/kAAG9zG4A= Date: Fri, 3 Jun 2016 13:09:09 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37FF3B58@ESESSMB209.ericsson.se> <2a554789-0668-74f0-4bb4-e2908daa5e91@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37FF4E53@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FBC2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FC74@ESESSMB209.ericsson.se> <2a5ebdc5-20c6-8a55-c6fd-f18957f2c4e4@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D3775B969B85christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUyM2K7k25ZY2C4wbPX8hZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyrm99z1bQ417x6/8t9gbG L7ZdjJwcEgImEtdm/WGBsMUkLtxbz9bFyMUhJHCEUWLNqidMEM5iRoltR2axdjFycLAJWEh0 /9MGiYsINDJKzHzzgRkkziygLnF1cRDIIGEBe4mrly8zgdgiAg4SO99eZYGon8YksXXCe7Bt LAIqEnPPTASzeQWsJO6uuc0CsayZU2LawT3MIAlOAWuJiYe3g01iBDrv+6k1YDazgLjErSfz mSDOFpBYsuc8M4QtKvHy8T9WEFtUQE/iy715jBBxJYkfGy6xQPTGS+xa/IcRYrGgxMmZT1gm MIrNQjJ2FpKyWUjKIOIGEu/PzWeGsLUlli18DWXrS2z8cpYRwraWaDvxhxFZzQJGjlWMosWp xcW56UZGeqlFmcnFxfl5enmpJZsYgVF7cMtvqx2MB587HmIU4GBU4uFNWBMQLsSaWFZcmXuI UYKDWUmEV6Y+MFyINyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMH p1QD4+zylR68nyfrOk6eoXXBKeTso2eCFW//Knz+1PZKqvvoIZ/jU7YcPJEX2P5fNqypdR+T YNHHD1dOWnSo/enND17iVmewquLTHvnKIy/TAib9Fbs0teFXT+fWj3U/imbyy7hJT7mw+WmU p7Ll5V9r+hY957V01c8T+FK15Cmngb/UN0Ynh2XrdiixFGckGmoxFxUnAgAP4rI61gIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:09:15 -0000 --_000_D3775B969B85christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What about something like: =93Unless the answerer has other ways of knowing what hash functions the of= ferer support the answerer MUST calculate, and include in the answer, at le= ast one fingerprint using a hash function that were used for calculating a = fingerprint in the associated offer. In addition, the answerer MAY calculat= e and include fingerprints using hash functions that were not used to calcu= late fingerprints in the offer.=94 Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Wednesday 1 June 2016 at 10:58 To: Roman Shpount >, "pkyzivat@= alum.mit.edu" > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 Hi, Even if both endpoints use different hash functions to sign the certificate= , Roman=92s suggestions would still work as long as the offer contains fing= erprints calculated using both hash functions. Having said that, does it really matter it the answer contains additional h= ash functions =96 at long as it also contains one or more hash functions th= at were present in the offer? Not sure what the use-case would be, though= =85 Regards, Christer From: Roman Shpount > Date: Tuesday 31 May 2016 at 23:09 To: "pkyzivat@alum.mit.edu" > Cc: Christer Holmberg >, Martin Thomson >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 On Tue, May 31, 2016 at 2:34 PM, Paul Kyzivat > wrote: According to the old scheme the hash would always match that of the cert. I= f the certs in the two directions used different hashs, then so would the f= ingerprints. The rule you are suggesting would break that. I do not think there is a single implementation that actually looks at the = hash function that is used to sign the certificate when checking the finger= print, so in reality this will not break anything. For RFC4572 implementati= ons there is rarely a reason to look at certificate signature, since it wil= l only verify who signed the certificate and certificates used by RFC4572 a= re normally self signed. This entire requirement was in RFC4572 by mistake. _____________ Roman Shpount --_000_D3775B969B85christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1DE2A842759EAC4F923A5B02C950BD2C@ericsson.com> Content-Transfer-Encoding: quoted-printable
What about something like:

=93Unless the answerer has other ways of knowing what hash functions t= he offerer support the answerer MUST calculate, and include in the answer, = at least one fingerprint using a hash function that were used for calculati= ng a fingerprint in the associated offer. In addition, the answerer MAY calculate and include fingerprints us= ing hash functions that were not used to calculate fingerprints in the offe= r.=94

Regards,

Christer 

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Wednesday 1 June 2016 at 10:5= 8
To: Roman Shpount <roman@telurix.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC for draf= t-ietf-mmusic-4572-update-03

Hi,

Even if both endpoints use different hash functions to sign the certif= icate, Roman=92s suggestions would still work as long as the offer contains= fingerprints calculated using both hash functions.

Having said that, does it really matter it the answer contains additio= nal hash functions =96 at long as it also contains one or more hash functio= ns that were present in the offer? Not sure what the use-case would be, tho= ugh=85

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Tuesday 31 May 2016 at 23:09<= br> To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Martin Thomson <mart= in.thomson@gmail.com>, "mmus= ic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC for draf= t-ietf-mmusic-4572-update-03

On Tue, M= ay 31, 2016 at 2:34 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
According to the old scheme the hash would always match that of the cert. I= f the certs in the two directions used different hashs, then so would the f= ingerprints.

The rule you are suggesting would break that.

I do not think there is a single implementation that actually looks at= the hash function that is used to sign the certificate when checking the f= ingerprint, so in reality this will not break anything. For RFC4572 impleme= ntations there is rarely a reason to look at certificate signature, since it will only verify who signed the= certificate and certificates used by RFC4572 are normally self signed. Thi= s entire requirement was in RFC4572 by mistake.
_________= ____
Roman Shpount
 
 --_000_D3775B969B85christerholmbergericssoncom_-- From nobody Fri Jun 3 07:57:16 2016 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 D843612D1D4 for ; Fri, 3 Jun 2016 07:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 0dLWEBuBsaAV for ; Fri, 3 Jun 2016 07:57:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F6E12D69E for ; Fri, 3 Jun 2016 07:57:02 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 080B058D55490; Fri, 3 Jun 2016 14:56:58 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53EuxQZ018051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 14:56:59 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53Euv8Y015740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 16:56:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 16:56:57 +0200 From: "Drage, Keith (Nokia - GB)" To: Brian Rosen , Adam Roach Thread-Topic: [MMUSIC] Transport of "Flash-hook" Thread-Index: AQHRvQFiZeCbkiRwJkKC/g8WjajlCZ/We12AgAAJnoCAAAKkAIAAAOwAgAALCgCAAAcdAIAA8tEAgABG46A= Date: Fri, 3 Jun 2016 14:56:57 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> In-Reply-To: <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF0EEC3FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:57:16 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF0EEC3FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB5b3UgbmVlZCB0byBhdCBsZWFzdCBhbnN3ZXIgYSBjb3VwbGUgb2YgcXVlc3Rpb25z Lg0KDQoNCjEpICAgICAgV2hhdCBhcmUgeW91IHVzaW5nIGl0IGZvcj8gSW4gdGhlIFBTVE4sIHRo ZSBub3JtYWwgdXNhZ2Ugd2FzIHRvIHJlY29ubmVjdCBhIHJlZ2lzdGVyIHNvIHRoYXQgc3Vic2Vx dWVudCBkaWdpdHMgY2FuIGJlIHJlY2VpdmVkLiBOb3cgd2l0aCBib3RoIG1lY2hhbmlzbXMgZm9y IHNlbmRpbmcgRFRNRiwgdGhlIHJlY2lwaWVudCBpcyBhbHJlYWR5IHRoZXJlIHRvIHJlY2VpdmUg RFRNRiB0b25lcyBhZnRlciB0aGUgaW5pdGlhbCBJTlZJVEUgaGFzIGJlZW4gc2VudCBhbmQgcmVj ZWl2ZWQgc29tZSBmb3JtIG9mIHByb3Zpc2lvbmFsIHJlc3BvbnNlIG9yIDIwMCBPSy4gQXMgc3Vj aCwgaXQgaXMgbm90IG5lZWRlZCBmb3IgdGhhdCBmdW5jdGlvbi4gSXQgaXMgZm9yIHRoYXQgcmVh c29uIEkgdGhpbmsgaXQgd2FzIGV2ZW50dWFsbHkgZHJvcHBlZCBpbiB0aGUgSVNETiBEU1MxIGRv Y3VtZW50cyAodGhlIHNpZ25hbGxpbmcgY2hhbm5lbCBhbHdheXMgYmVpbmcgaW4gZXhpc3RlbmNl IGluIElTRE4pLCBhbmQgcG9zc2libHkgdGhhdCBtYXkgYmUgdGhlIHJlYXNvbiBpdCBkb2VzIG5v dCBhcHBlYXIgaW4gdGhlIFNJUCBkb2N1bWVudHMuIE5vdyBJIGtub3cgdGhlcmUgYXJlIHNvbWUg c3BlY2lhbCBvYnNjdXJpdGllcyBpbiB0aGUgTm9ydGggQW1lcmljYW4gdXNhZ2Ugb2YgdGhpcyB0 aGF0IG1ha2VzIHR3byBkaWZmZXJlbnQgc2lnbmFscyBiYXNlZCBvbiB0aW1pbmcgZGlmZmVyZW5j ZXMsIGJ1dCBwbGVhc2UgZXhwbGFpbiBpZiB5b3UgYXJlIHVzaW5nIHRoZXNlLCBhbmQgd2hhdCB0 aGUgcmVzdWx0IG1lYW5zLg0KDQoyKSAgICAgIEluIHRoZSBOb3J0aCBBbWVyaWNhIDkxMSB3b3Jr LCBJIHVuZGVyc3Rvb2QgdGhhdCB0aGUgQ1MgZG9tYWluIHdhcyBiZWluZyBzZXBhcmF0ZWQgZnJv bSB0aGUgUFMgKFNJUCkgZG9tYWluIGV2ZW4gdGhyb3VnaCB0aGUgZW1lcmdlbmN5IHNlcnZpY2Vz IG5ldHdvcmsgYW5kIGFsbCB0aGUgd2F5IHRvIHRoZSBQU0FQLiBBcyBzdWNoLCB3aHkgYXJlIHlv dSBoYXZpbmcgdG8gaW50ZXJ3b3JrIFBTVE4gdHlwZSBzaWduYWxzLCB3aGljaCBoYXZlIHByZXN1 bWFibHkgY29tZSBmcm9tIGEgUFNUTiBlbmRwb2ludCwgYW5kIGlmIHNvIHdoZXJlIGluIHRoZSBh cmNoaXRlY3R1cmUgYXJlIHlvdSBkb2luZyBpdC4NClJlZ2FyZHMNCg0KS2VpdGgNCg0KRnJvbTog bW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlh biBSb3Nlbg0KU2VudDogMDMgSnVuZSAyMDE2IDEzOjM2DQpUbzogQWRhbSBSb2FjaA0KQ2M6IG1t dXNpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFRyYW5zcG9ydCBvZiAiRmxhc2gt aG9vayINCg0KWWVhaCwgdGhlIG9uZXMgSSBrbm93IGFib3V0IGRvLiAgVGhleSBjbGFpbSAyODMz IGNvbXBsaWFuY2UgZm9yIHRoZSBtb3N0IHBhcnQuDQoNCkFzIEkgc2FpZCwgb25lIHdheSB0byBz b2x2ZSB0aGlzIGlzIGp1c3QgcmVxdWlyZSAyODMzIGNvbXBsaWFuY2UgaW4gYSBzcGVjIHdyaXR0 ZW4gaW4gMjAxNi4NCldlIHByb2JhYmx5IHdvdWxkbuKAmXQgYWxsb3cgYSBub3JtYXRpdmUgcmVm ZXJlbmNlIHRvIDI4MzMgaW4gc29tZSBzdGFuZGFyZHMgdHJhY2sgUkZDIHdlIHdyb3RlIHRvZGF5 OyB3ZSB3b3VsZCBmaXggd2hhdGV2ZXIgdGhlIHByb2JsZW0gd2FzLg0KDQpCcmlhbg0KDQpPbiBK dW4gMiwgMjAxNiwgYXQgNjowNyBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWls dG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KDQpBbmQsIGZvciBjbGFyaXR5Og0KDQpUaGUg U0lQIEdXIGFscmVhZHkgc2VuZHMgZXZlbnQgMTYgd2hlbiBpdCBzZWVzIGEgaG9va2ZsYXNoPyBP ciBkbyB5b3UgbmVlZCB0byB1cGRhdGUgaXRzIHNvZnR3YXJlIHRvIGFjY29tb2RhdGUgdGhpcyBj aGFuZ2U/DQoNCi9hDQoNCk9uIDYvMi8xNiAxNjo0MSwgQnJpYW4gUm9zZW4gd3JvdGU6DQpTdXJl DQoNCg0KICAgICAgIFNJUCAgICBTSVAgICBNRg0KU0lQLVVBIOKAlOKAlCBJV0Yg4oCU4oCUIEdX 4oCU4oCUIExlZ2FjeSBQU0FQDQoNCkEgY2FsbCBpcyB1cCBmcm9tIHRoZSBTSVAtVUEgdG8gdGhl IExlZ2FjeSBQU0FQIHRocm91Z2ggdGhlIElXRiBhbmQgR1cuDQoNClRoZSBMZWdhY3kgUFNBUCBp cyB0cnlpbmcgdG8gdGVsbCB0aGUgU0lQIFVBIHRvIHRyYW5zZmVyIHRoZSBjYWxsDQoNCkdXIGlz IGFuIGV4aXN0aW5nIG9mZiB0aGUgc2hlbGYsIG5vcm1hbCBJUC1QU1ROIGdhdGV3YXksIG1vc3Qg b2Ygd2hpY2ggYWN0dWFsbHkgYXJlIDI4MzMgY29tcGxpYW50LCBidXQgSeKAmW0gdHJ5aW5nIG5v dCB0byByZXF1aXJlIGNvbmZvcm1hbmNlIHRvIDI4MzMuIE5vdGUgdGhhdCDigJxNRuKAnSBpcyB0 b25lIHNpZ25hbGVkIGFuYWxvZyB0ZWxlcGhvbnkuICBUaGUgYWN0dWFsIE1GIHByb3RvY29sIHVz ZWQgaGVyZSBpcyBDQU1BLg0KDQpJV0YgaXMgYSBCMkJVQSB0aGF0IGhhcyBjb2RlIHdlIGNhbiBk byBhbnl0aGluZyByZWFzb25hYmxlIHdpdGgsIHdoaWNoIHdpbGwgY29uZm9ybSB0byBORU5BIHN0 YW5kYXJkcy4NCg0KVGhlIExlZ2FjeSBQU0FQIHNpZ25hbHMgYSB0cmFuc2ZlciBieSBzZW5kaW5n IEZMQVNILCBkaWdpdCwgZGlnaXQsIGRpZ2l04oCmLg0KDQpUaGUgR1cgZ2V0cyB0aGlzIHNpZ25h bGluZywgYnV0IGRvZXNu4oCZdCByZWFsbHkga25vdyB3aGF0IHRvIGRvIHdpdGggaXQsIHNvIGl0 IHBhc3NlcyB0aGUgc2VxdWVuY2UgdG8gdGhlIElXRg0KDQpUaGUgSVdGIHJlY29nbml6ZXMgdGhp cyBpcyBhIHRyYW5zZmVyIHJlcXVlc3QsIGFuZCBnZW5lcmF0ZXMgdGhlIFJFRkVSIHRvIHRoZSBT SVAgVUEuDQoNClRoZSBwcm9ibGVtIEnigJltIHNvbHZpbmcgaXMgdGhlIHNpZ25hbGluZyBiZXR3 ZWVuIHRoZSBHVyBhbmQgdGhlIElXRi4gIEkgY2FuIHRyYW5zcG9ydCB0aGUgZGlnaXRzIHdpdGgg NDczMywgYnV0IG5vdCB0aGUgZmxhc2guDQoNCg0KT24gSnVuIDIsIDIwMTYsIGF0IDU6MDIgUE0s IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+PiB3 cm90ZToNCg0KVGhpcyBzb3VuZHMgbGlrZSBhIHdob2xlIGxvdCBvZiB0YWxraW5nIHBhc3QgZWFj aCBvdGhlci4gQnJpYW46IGRvIHlvdSBoYXZlIGEgcm91Z2ggcGljdHVyZSBvZiB0aGUgc3lzdGVt IHlvdSdyZSBkZXNpZ25pbmcgdGhhdCB5b3UgY291bGQgc2hhcmU/IFNvbWV0aGluZyB0aGF0IHBv aW50cyBvdXQgb2xkIHBhcnRzIHZlcnN1cyBuZXcgcGFydHMgYW5kIGhpZ2hsaWdodHMgd2hlcmUg UkZDIDQ3MzMgd291bGQgYmUgdXNlZD8NCg0KL2ENCg0KT24gNi8yLzE2IDE1OjU4LCBUZWQgSGFy ZGllIHdyb3RlOg0KSG93ZHksDQpJbi1saW5lLg0KDQpPbiBUaHUsIEp1biAyLCAyMDE2IGF0IDE6 NDkgUE0sIEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nl bi5uZXQ+PiB3cm90ZToNCkhpIFRlZA0KDQpPbiBKdW4gMiwgMjAxNiwgYXQgNDoxNSBQTSwgVGVk IEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20+PiB3 cm90ZToNCg0KSGkgQnJpYW4sDQoNCk9uIFRodSwgSnVuIDIsIDIwMTYgYXQgMTI6MDIgUE0sIEJy aWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+PiB3 cm90ZToNCkJhY2sgaW4gUkZDMjgzMywgdGhlIERUTUYgdG9uZXMgc2VjdGlvbiwgY29kZSAxNiB3 YXMgZGVmaW5lZCBmb3Ig4oCcRmxhc2jigJ0sIHRoZSBzaWduYWwgY2F1c2VkIGJ5IGEgbW9tZW50 YXJ5IGRlcHJlc3Npb24gb2YgdGhlIGhvb2stc3dpdGNoIGluIGEgUE9UUyBwaG9uZS4gIFdoZW4g MjgzMyB3YXMgb2Jzb2xldGVkIGJ5IDQ3MzMsIGZsYXNoIHdhcyBkcm9wcGVkLCBhbHRob3VnaCB0 aGUgY29kZSAxNiB3YXMgcmVzZXJ2ZWQuDQoNCkl0IGxvb2tzIHRvIG1lIHRoYXQgeW91IGNvdWxk IGJlIGNvbXBsaWFudCB3aXRoIFJGQyAyODMzIHdpdGhvdXQgaW1wbGVtZW50aW5nIGZsYXNoIGF0 IGFsbCAoc2VlIFNlY3Rpb24gMy4zLCBvbiBldmVudCB0eXBlcykuICBUaGlzIGhhcyBiZWVuIGVm ZmVjdGl2ZWx5IGdvbmUgYSBsb25nIHRpbWUsIGluIG90aGVyIHdvcmRzLg0KSeKAmW0gc29ycnks IEkgZG9u4oCZdCB1bmRlcnN0YW5kLg0KDQpJJ20gc2F5aW5nIHRoYXQgc2luY2UgeW91IGNvdWxk IGNhbGwgeW91cnNlbGYgY29tcGxpYW50IFJGQyAyODMzIHdpdGhvdXQgaW1wbGVtZW50aW5nIGZs YXNoIGF0IGFsbCwgdGhlIGFiaWxpdHkgdG8gY291bnQgb24gdGhpcyB3ZW50IGF3YXkgYmVmb3Jl IHRoZSB0dXJuIG9mIHRoZSBtaWxsZW5pdW0uICBBcyBpbiAxNiB5ZWFycyBhZ28uDQoNCiBXZeKA mXJlIHdyaXRpbmcgYSBuZXcgc3RhbmRhcmQsIGFuZCBJ4oCZZCByZWFsbHkgcHJlZmVyIHRvIG5v dCByZWZlcmVuY2UgYW4gb2Jzb2xldGUgSUVURiBzdGFuZGFyZCBpbiB0aGF0IGRvY3VtZW50LiAg SSBuZWVkIHRvIHNpZ25hbCBmbGFzaCwgdGhlIHdheSAyODMzIHNpZ25hbGVkIGZsYXNoLCBidXQg NDczMyBkb2VzbuKAmXQgaGF2ZSBhIHdheSB0byBzaWduYWwgZmxhc2guDQoNCg0KDQoNCldlIGhh dmUgYSB1c2UgY2FzZSBpbiBORU5BICg5LTEtMSBlbWVyZ2VuY3kgc3R1ZmYpIHdoZXJlIGV4aXN0 aW5nIHN5c3RlbXMgdXNlIGZsYXNoIGludGVyc3BlcnNlZCB3dGggdG9uZXMgaW4gc2lnbmFsaW5n IGRpYWxpbmcgZXZlbnRzIHdoaWNoIGFyZSBub3QgaW50ZXJwcmV0ZWQgYnkgdGhlIFVBIHRoYXQg cmVjZWl2ZXMgdGhlbSwgYnV0IGFyZSBpbnN0ZWFkIHRyYW5zcG9ydGVkIHRvIGEgZGV2aWNlIHRo YXQgY3JlYXRlcyBhcHByb3ByaWF0ZSBTSVAgc2lnbmFsaW5nIGZvciB0aGUgZGlhbGluZyBldmVu dHMgaW5pdGlhdGVkLg0KDQpTbywgSSdtIG5vdCBzdXJlIHdoeSBpbnZva2luZyBORU5BIGFuZCBl bWVyZ2VuY3kgc2VydmljZXMgbWF0dGVycyBoZXJlLiAgWW91IGRvbid0IGV4cGxhaW4gd2hhdCB0 aGUgc3lzdGVtIGRvZXMgYW5kIGhvdyBpdCBpbnRlcm9wZXJhdGVzIHdpdGggYW55dGhpbmcgZWxz ZSBub3cuDQpJ4oCZbSBjb25uZWN0aW5nIGEgbmV3IElQIGJhc2VkIHN5c3RlbSB0aGF0IHVzZXMg c3RhbmRhcmRzIGJhc2VkIFNJUCB0byBhbiBleGlzdGluZyBvbGQgc3lzdGVtLiAgVGhhdCBzeXN0 ZW0gZXhwZWN0cyB0byBzaWduYWwgdG8gZG8gYSBjYWxsIHRyYW5zZmVyIG9yIGNvbmZlcmVuY2Ug b3BlcmF0aW9uIHdpdGggY29tYmluYXRpb25zIG9mIGZsYXNoIGFuZCBEVE1GLiAgVGhlcmUgaXMg YSBuZXR3b3JrIHRoYXQgaXMgdXNpbmcgbm9ybWFsIFNJUCBzaWduYWxpbmcgZm9yIHRyYW5zZmVy L2NvbmZlcmVuY2UsIGFuZCB0aGlzIG9sZGVyIHN5c3RlbSB0aGF0IGlzIGV4cGVjdGluZyBob29r IHN3aXRjaCBhbmQgRFRNRi4gIElkZWFsbHksIHdlIHdvdWxkIGhhdmUgdGhlIFVBIGZhY2luZyB0 aGUgb2xkZXIgc3lzdGVtIGRvIHRoZSBpbnRlcndvcmssIGJ1dCBhbGFzIHRoYXQgd29u4oCZdCB3 b3JrLCBhbmQgd2UgbmVlZCBhbm90aGVyIGVsZW1lbnQgdG8gZG8gdGhlIGludGVyd29yaywgYW5k IHRyYW5zcG9ydCB0aGUgRFRNRiBhbmQgZmxhc2ggdG8gdGhlIFVBIHdoaWNoIHdpbGwgcGxheSBv dXQgdGhlIHNpZ25hbGluZy4gIElmIEkgbWFkZSB0aGF0IFVBIGFuZCB0aGUgaW50ZXJ3b3JraW5n IGVsZW1lbnQgY29uZm9ybSB0byAyODMzLCBldmVyeXRoaW5nIHdvdWxkIGJlIGZpbmUsIGJ1dCB0 aGVuIEnigJltIHJlcXVpcmluZyBjb25mb3JtYW5jZSB0byBhbiBvYnNvbGV0ZSBkb2N1bWVudC4N Cg0KDQoNCklmIEkgcmVwbGFjZSAiTkVOQSIgd2l0aCAiQSBwcm9wcmlldGFyeSBzeXN0ZW0gdXNl cyBmbGFzaCBpbnRlcnNwZXJzZWQgd2l0aCBvdGhlciBEVE1GIHRvbmVzIHRvIHNlbmQgc2lnbmFs bGluZyBldmVudHMgdG8gYSBnYXRld2F5IiBpcyB0aGF0IGFwcHJveGltYXRlbHkgdHJ1ZT8gIFRo ZSBrZXkgcXVlc3Rpb24gc2VlbXMgdG8gYmUgIndoYXQgYXJlIHRoZXNlIGV2ZW50cywgYW5kIHdo YXQncyB0aGUgcmlnaHQgd2F5IHRvIHNpZ25hbCB0aGVtIHRvIGEgZ2F0ZXdheeKAnT8NCkl04oCZ cyBhcHByb3hpbWF0ZWx5IHRydWUsIGJ1dCBpdOKAmXMgYSBzdGFuZGFyZHMgYmFzZWQgc3lzdGVt LCBub3QgYSBwcm9wcmlldGFyeSBzeXN0ZW0uDQpZb3Ugc2F5IHRoYXQsIGJ1dCB5b3UgYXBwZWFy IHRvIGJlIGltcGx5aW5nIHRoYXQgaXQgaXMgYSBzeXN0ZW0gYmFzZWQgb24gYSBzdGFuZGFyZCB0 aGF0IHdhcyBkaXNhcHBlYXJpbmcgaW4gMjAwMCAoUkZDIDI4MzMpIGFuZCBnb25lIGJ5IDIwMDYg KFJGQyA0NzMzKS4gIFlvdSBhcHBlYXIgdG8gYmUgYXR0ZW1wdGluZyB0byBjcmVhdGUgYSBuZXcg c3RhbmRhcmQgaW4gMjAxNiAobGV0J3MgYmUgaG9uZXN0IGhlcmUsIGxpa2VseSBhcnJpdmluZyBp biAyMDE4KSB0aGF0IHJlY2FwaXR1bGF0ZXMgc29tZXRoaW5nIGZyb20gdGhlIHBhc3Qgc28gdGhh dCBORU5BIGRvZXNuJ3QgaGF2ZSB0byB1cGRhdGUgc29tZXRoaW5nIHRoYXQncyBiZWVuIHN1cGVy c2VkZWQuDQoNCiBUaGUgb2xkZXIgc3lzdGVtIGlzIHN0YW5kYXJkcyBiYXNlZCwgdGhlIG5ldyBz eXN0ZW0gaXMgc3RhbmRhcmRzIGJhc2VkLCBhbmQgSSBuZWVkIHRvIGludGVyd29yayB0aGVtIGlu ICBhIHN0YW5kYXJkcyBiYXNlZCBtYW5uZXIuDQoNCllvdSB3YW50IGV2ZXJ5b25lIGVsc2UgdG8g cmUtaW1wbGVtZW50IGZsYXNoIHNvIHRoYXQgTkVOQSBkb2Vzbid0IHJlcGxhY2UgdGhlaXIgcHJv cHJpZXRhcnkvc3VwZXJzZWRlZCBzeXN0ZW0/DQoNCg0KV2UgaGF2ZSBubyBvdGhlciB3YXkgdG8g dHJhbnNwb3J0IGZsYXNoIHRvIGludGVyd29yayB3aXRoIG91ciBuZXdlciBTSVAgYmFzZWQgZW1l cmdlbmN5IGNhbGxpbmcgc3lzdGVtcy4NCg0KSeKAmW0gcHJlcGFyZWQgdG8gd3JpdGUgYSBkcmFm dCB0aGF0IHJlc3RvcmVzIGNvZGUgMTYgZm9yIGZsYXNoLCBhcyBpdCB3YXMgaW4gMjgzMywgYnV0 IHdhbnRlZCB0byBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGRvaW5nIHRoYXQuDQoNCkxldCBtZSBn ZW50bHkgc3VnZ2VzdCB0aGF0IHlvdSBpbnN0ZWFkIGFzayB0byByZS11c2UgY29kZSAxNiwgbG9u ZyBpbiBhYmV5YW5jZSwgZm9yIHRoaXMgbmV3IHB1cnBvc2UsIHdoYXRldmVyIHlvdSBldmVudHVh bGx5IGV4cGxhaW4gaXQgdG8gYmUuICBVbmxlc3MgeW91IHBsYW4gdG8gZm9yY2UgcGVvcGxlIHRv IGdvIGJhY2sgdGhyb3VnaCB0aGVpciBvbGQgSVRVIEUuMTgqIGRvY3MgYW5kIEJlbGxjb3JlIEdS LTUwNi1DT1JFIFBERnMgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBleGFjdGx5IGlzIGludm9s dmVkIGluIHRoaXMgcmVzdXJyZWN0aW9uLCBzYXlpbmcgInJlc3RvcmVzIiBzZWVtcyBsaWtlIHRo ZSB3cm9uZyB2ZXJiIGhlcmUuDQpJIGFtIGFza2luZyB0byB1c2UgY29kZSAxNiB0byB0cmFuc3Bv cnQgZmxhc2gsIGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5IDI4MzMgZGlkLg0KDQoNCkFuZCB5b3Ug d2FudCB0byB1bmRvIHRoZSBkZWNpc2lvbnMgdGhhdCBsZWQgdG8gaXQgYmVpbmcgc29mdC1kcm9w cGVkIHRoZXJlIGFuZCBkZXByZWNhdGVkLiAgQnV0IHRoZSBqdXN0aWZpY2F0aW9uIGRvZXNuJ3Qg c2VlbSB0byBiZSB0aGVyZS4NCg0KSnVzdCBteSB0d28gY2VudHMsIGRpc2xvZGdlZCBieSBhIGtu ZWUtamVyayByZWFjdGlvbiB0byBtYWtpbmcgRFRNRiBtb3JlIGltcG9ydGFudCwNClllYWgsIEni gJltIG5vdCB0aHJpbGxlZCB3aXRoIG1vcmUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgc3R1ZmYg ZWl0aGVyLCBidXQgSeKAmW0gYWxzbyBub3QgYSBmYW4gb2YgYW4gb3JnYW5pemF0aW9uIGxpa2Ug TkVOQSBtYWtpbmcgdXAgc3RhbmRhcmRzIHVzaW5nIFNEUCwgb3IgcmVxdWlyaW5nIGNvbmZvcm1h bmNlIHRvIG9ic29sZXRlIHN0YW5kYXJkcy4NCg0KSG93IGFib3V0IHRoZXkgZXhwcmVzc2luZyB3 aGF0IHRoZSBhY3R1YWwgZ2F0ZXdheSBzaWduYWxsaW5nIHJlcXVpcmVtZW50cyBhcmUgYW5kIHdl IHNvbHZlIHRoZW0gd2l0aG91dCB6b21iaWUgRFRNRiBzaHVmZmxpbmcgYWJvdXQ/DQpKdXN0IGEg dGhvdWdodCwNClRlZA0KDQoNCkJyaWFuDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQptbXVzaWMgbWFpbGluZyBsaXN0DQoNCm1t dXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCg0KDQo= --_000_949EF20990823C4C85C18D59AA11AD8BADF0EEC3FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7 DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjQwMDk1MzkzNDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTExMzQ5MzkzMiA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB5b3Ug bmVlZCB0byBhdCBsZWFzdCBhbnN3ZXIgYSBjb3VwbGUgb2YgcXVlc3Rpb25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgYXJlIHlvdSB1 c2luZyBpdCBmb3I/IEluIHRoZSBQU1ROLCB0aGUgbm9ybWFsIHVzYWdlIHdhcyB0byByZWNvbm5l Y3QgYSByZWdpc3RlciBzbyB0aGF0IHN1YnNlcXVlbnQgZGlnaXRzIGNhbiBiZSByZWNlaXZlZC4g Tm93IHdpdGggYm90aCBtZWNoYW5pc21zDQogZm9yIHNlbmRpbmcgRFRNRiwgdGhlIHJlY2lwaWVu dCBpcyBhbHJlYWR5IHRoZXJlIHRvIHJlY2VpdmUgRFRNRiB0b25lcyBhZnRlciB0aGUgaW5pdGlh bCBJTlZJVEUgaGFzIGJlZW4gc2VudCBhbmQgcmVjZWl2ZWQgc29tZSBmb3JtIG9mIHByb3Zpc2lv bmFsIHJlc3BvbnNlIG9yIDIwMCBPSy4gQXMgc3VjaCwgaXQgaXMgbm90IG5lZWRlZCBmb3IgdGhh dCBmdW5jdGlvbi4gSXQgaXMgZm9yIHRoYXQgcmVhc29uIEkgdGhpbmsgaXQgd2FzIGV2ZW50dWFs bHkNCiBkcm9wcGVkIGluIHRoZSBJU0ROIERTUzEgZG9jdW1lbnRzICh0aGUgc2lnbmFsbGluZyBj aGFubmVsIGFsd2F5cyBiZWluZyBpbiBleGlzdGVuY2UgaW4gSVNETiksIGFuZCBwb3NzaWJseSB0 aGF0IG1heSBiZSB0aGUgcmVhc29uIGl0IGRvZXMgbm90IGFwcGVhciBpbiB0aGUgU0lQIGRvY3Vt ZW50cy4gTm93IEkga25vdyB0aGVyZSBhcmUgc29tZSBzcGVjaWFsIG9ic2N1cml0aWVzIGluIHRo ZSBOb3J0aCBBbWVyaWNhbiB1c2FnZSBvZiB0aGlzIHRoYXQNCiBtYWtlcyB0d28gZGlmZmVyZW50 IHNpZ25hbHMgYmFzZWQgb24gdGltaW5nIGRpZmZlcmVuY2VzLCBidXQgcGxlYXNlIGV4cGxhaW4g aWYgeW91IGFyZSB1c2luZyB0aGVzZSwgYW5kIHdoYXQgdGhlIHJlc3VsdCBtZWFucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkluIHRoZSBOb3J0aCBBbWVyaWNhIDkxMSB3b3JrLCBJIHVuZGVyc3Rvb2QgdGhh dCB0aGUgQ1MgZG9tYWluIHdhcyBiZWluZyBzZXBhcmF0ZWQgZnJvbSB0aGUgUFMgKFNJUCkgZG9t YWluIGV2ZW4gdGhyb3VnaCB0aGUgZW1lcmdlbmN5IHNlcnZpY2VzIG5ldHdvcmsNCiBhbmQgYWxs IHRoZSB3YXkgdG8gdGhlIFBTQVAuIEFzIHN1Y2gsIHdoeSBhcmUgeW91IGhhdmluZyB0byBpbnRl cndvcmsgUFNUTiB0eXBlIHNpZ25hbHMsIHdoaWNoIGhhdmUgcHJlc3VtYWJseSBjb21lIGZyb20g YSBQU1ROIGVuZHBvaW50LCBhbmQgaWYgc28gd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBhcmUg eW91IGRvaW5nIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5LZWl0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBSb3Nlbjxicj4NCjxiPlNl bnQ6PC9iPiAwMyBKdW5lIDIwMTYgMTM6MzY8YnI+DQo8Yj5Ubzo8L2I+IEFkYW0gUm9hY2g8YnI+ DQo8Yj5DYzo8L2I+IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01N VVNJQ10gVHJhbnNwb3J0IG9mICZxdW90O0ZsYXNoLWhvb2smcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFoLCB0aGUgb25lcyBJIGtub3cgYWJv dXQgZG8uICZuYnNwO1RoZXkgY2xhaW0gMjgzMyBjb21wbGlhbmNlIGZvciB0aGUgbW9zdCBwYXJ0 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgSSBzYWlk LCBvbmUgd2F5IHRvIHNvbHZlIHRoaXMgaXMganVzdCByZXF1aXJlIDI4MzMgY29tcGxpYW5jZSBp biBhIHNwZWMgd3JpdHRlbiBpbiAyMDE2LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHByb2JhYmx5IHdvdWxkbuKAmXQgYWxsb3cg YSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIDI4MzMgaW4gc29tZSBzdGFuZGFyZHMgdHJhY2sgUkZD IHdlIHdyb3RlIHRvZGF5OyB3ZSB3b3VsZCBmaXggd2hhdGV2ZXIgdGhlIHByb2JsZW0gd2FzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccmlh bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biAyLCAyMDE2LCBhdCA2OjA3IFBNLCBBZGFtIFJv YWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+YWRhbUBub3N0cnVtLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuZCwgZm9yIGNsYXJpdHk6PGJyPg0KPGJyPg0KVGhlIFNJUCBHVyBhbHJl YWR5IHNlbmRzIGV2ZW50IDE2IHdoZW4gaXQgc2VlcyBhIGhvb2tmbGFzaD8gT3IgZG8geW91IG5l ZWQgdG8gdXBkYXRlIGl0cyBzb2Z0d2FyZSB0byBhY2NvbW9kYXRlIHRoaXMgY2hhbmdlPzxicj4N Cjxicj4NCi9hPGJyPg0KPGJyPg0KT24gNi8yLzE2IDE2OjQxLCBCcmlhbiBSb3NlbiB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJlIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U0lQICZuYnNw OyAmbmJzcDtTSVAgJm5ic3A7IE1GPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi PlNJUC1VQSDigJTigJQgSVdGIOKAlOKAlCBHV+KAlOKAlCBMZWdhY3kgUFNBUDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPkEgY2FsbCBpcyB1cCBmcm9tIHRoZSBTSVAtVUEg dG8gdGhlIExlZ2FjeSBQU0FQIHRocm91Z2ggdGhlIElXRiBhbmQgR1cuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+VGhlIExlZ2FjeSBQU0FQIGlzIHRyeWluZyB0byB0ZWxs IHRoZSBTSVAgVUEgdG8gdHJhbnNmZXIgdGhlIGNhbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyIj5HVyBpcyBhbiBleGlzdGluZyBvZmYgdGhlIHNoZWxmLCBub3JtYWwgSVAt UFNUTiBnYXRld2F5LCBtb3N0IG9mIHdoaWNoIGFjdHVhbGx5IGFyZSAyODMzIGNvbXBsaWFudCwg YnV0IEnigJltIHRyeWluZyBub3QgdG8gcmVxdWlyZSBjb25mb3JtYW5jZSB0byAyODMzLiBOb3Rl IHRoYXQmbmJzcDvigJxNRuKAnSBpcyB0b25lIHNpZ25hbGVkIGFuYWxvZyB0ZWxlcGhvbnkuICZu YnNwO1RoZQ0KIGFjdHVhbCBNRiBwcm90b2NvbCB1c2VkIGhlcmUgaXMgQ0FNQS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5JV0YgaXMgYSBCMkJVQSB0aGF0IGhhcyBjb2Rl IHdlIGNhbiBkbyBhbnl0aGluZyByZWFzb25hYmxlIHdpdGgsIHdoaWNoIHdpbGwgY29uZm9ybSB0 byBORU5BIHN0YW5kYXJkcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5U aGUgTGVnYWN5IFBTQVAgc2lnbmFscyBhIHRyYW5zZmVyIGJ5IHNlbmRpbmcgRkxBU0gsIGRpZ2l0 LCBkaWdpdCwgZGlnaXTigKYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+ VGhlIEdXIGdldHMgdGhpcyBzaWduYWxpbmcsIGJ1dCBkb2VzbuKAmXQgcmVhbGx5IGtub3cgd2hh dCB0byBkbyB3aXRoIGl0LCBzbyBpdCBwYXNzZXMgdGhlIHNlcXVlbmNlIHRvIHRoZSBJV0Y8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5UaGUgSVdGIHJlY29nbml6ZXMgdGhp cyBpcyBhIHRyYW5zZmVyIHJlcXVlc3QsIGFuZCBnZW5lcmF0ZXMgdGhlIFJFRkVSIHRvIHRoZSBT SVAgVUEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+VGhlIHByb2JsZW0g SeKAmW0gc29sdmluZyBpcyB0aGUgc2lnbmFsaW5nIGJldHdlZW4gdGhlIEdXIGFuZCB0aGUgSVdG LiAmbmJzcDtJIGNhbiB0cmFuc3BvcnQgdGhlIGRpZ2l0cyB3aXRoIDQ3MzMsIGJ1dCBub3QgdGhl IGZsYXNoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gSnVuIDIsIDIwMTYsIGF0IDU6MDIgUE0sIEFkYW0gUm9hY2ggJmx0 OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIj5hZGFtQG5vc3RydW0uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBzb3VuZHMgbGlrZSBhIHdob2xlIGxvdCBvZiB0YWxraW5nIHBhc3QgZWFjaCBv dGhlci4gQnJpYW46IGRvIHlvdSBoYXZlIGEgcm91Z2ggcGljdHVyZSBvZiB0aGUgc3lzdGVtIHlv dSdyZSBkZXNpZ25pbmcgdGhhdCB5b3UgY291bGQgc2hhcmU/IFNvbWV0aGluZyB0aGF0IHBvaW50 cyBvdXQgb2xkIHBhcnRzIHZlcnN1cyBuZXcgcGFydHMgYW5kIGhpZ2hsaWdodHMgd2hlcmUgUkZD IDQ3MzMgd291bGQgYmUNCiB1c2VkPzxicj4NCjxicj4NCi9hPGJyPg0KPGJyPg0KT24gNi8yLzE2 IDE1OjU4LCBUZWQgSGFyZGllIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5Ib3dkeSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4t bGluZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KT24gVGh1LCBKdW4gMiwgMjAxNiBhdCAxOjQ5IFBNLCBCcmlhbiBSb3NlbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFRlZCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdW4gMiwgMjAxNiwgYXQgNDoxNSBQTSwgVGVkIEhhcmRp ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSI+dGVkLmlldGZAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBCcmlhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIEp1biAyLCAyMDE2IGF0IDEyOjAyIFBNLCBCcmlhbiBSb3NlbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFjayBpbiBSRkMyODMzLCB0 aGUgRFRNRiB0b25lcyBzZWN0aW9uLCBjb2RlIDE2IHdhcyBkZWZpbmVkIGZvciDigJxGbGFzaOKA nSwgdGhlIHNpZ25hbCBjYXVzZWQgYnkgYSBtb21lbnRhcnkgZGVwcmVzc2lvbiBvZiB0aGUgaG9v ay1zd2l0Y2ggaW4gYSBQT1RTIHBob25lLiZuYnNwOyBXaGVuIDI4MzMgd2FzIG9ic29sZXRlZCBi eSA0NzMzLCBmbGFzaCB3YXMgZHJvcHBlZCwgYWx0aG91Z2ggdGhlIGNvZGUgMTYgd2FzIHJlc2Vy dmVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgbG9v a3MgdG8gbWUgdGhhdCB5b3UgY291bGQgYmUgY29tcGxpYW50IHdpdGggUkZDIDI4MzMgd2l0aG91 dCBpbXBsZW1lbnRpbmcgZmxhc2ggYXQgYWxsIChzZWUgU2VjdGlvbiAzLjMsIG9uIGV2ZW50IHR5 cGVzKS4mbmJzcDsgVGhpcyBoYXMgYmVlbiBlZmZlY3RpdmVseSBnb25lIGEgbG9uZyB0aW1lLCBp biBvdGhlciB3b3Jkcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBz b3JyeSwgSSBkb27igJl0IHVuZGVyc3RhbmQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSdtIHNheWluZyB0aGF0IHNpbmNlIHlvdSBjb3VsZCBjYWxsIHlvdXJzZWxmIGNvbXBsaWFudCBS RkMgMjgzMyB3aXRob3V0IGltcGxlbWVudGluZyBmbGFzaCBhdCBhbGwsIHRoZSBhYmlsaXR5IHRv IGNvdW50IG9uIHRoaXMgd2VudCBhd2F5IGJlZm9yZSB0aGUgdHVybiBvZiB0aGUgbWlsbGVuaXVt LiZuYnNwOyBBcyBpbiAxNiB5ZWFycyBhZ28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw O1dl4oCZcmUgd3JpdGluZyBhIG5ldyBzdGFuZGFyZCwgYW5kIEnigJlkIHJlYWxseSBwcmVmZXIg dG8gbm90IHJlZmVyZW5jZSBhbiBvYnNvbGV0ZSBJRVRGIHN0YW5kYXJkIGluIHRoYXQgZG9jdW1l bnQuJm5ic3A7IEkgbmVlZCB0byBzaWduYWwgZmxhc2gsIHRoZSB3YXkgMjgzMyBzaWduYWxlZCBm bGFzaCwgYnV0IDQ3MzMgZG9lc27igJl0IGhhdmUgYSB3YXkgdG8gc2lnbmFsIGZsYXNoLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2UgaGF2ZSBhIHVzZSBjYXNlIGluIE5F TkEgKDktMS0xIGVtZXJnZW5jeSBzdHVmZikgd2hlcmUgZXhpc3Rpbmcgc3lzdGVtcyB1c2UgZmxh c2ggaW50ZXJzcGVyc2VkIHd0aCB0b25lcyBpbiBzaWduYWxpbmcgZGlhbGluZyBldmVudHMgd2hp Y2ggYXJlIG5vdCBpbnRlcnByZXRlZCBieSB0aGUgVUEgdGhhdCByZWNlaXZlcyB0aGVtLCBidXQg YXJlIGluc3RlYWQgdHJhbnNwb3J0ZWQgdG8gYSBkZXZpY2UgdGhhdCBjcmVhdGVzIGFwcHJvcHJp YXRlIFNJUA0KIHNpZ25hbGluZyBmb3IgdGhlIGRpYWxpbmcgZXZlbnRzIGluaXRpYXRlZC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIEknbSBub3Qgc3VyZSB3aHkg aW52b2tpbmcgTkVOQSBhbmQgZW1lcmdlbmN5IHNlcnZpY2VzIG1hdHRlcnMgaGVyZS4mbmJzcDsg WW91IGRvbid0IGV4cGxhaW4gd2hhdCB0aGUgc3lzdGVtIGRvZXMgYW5kIGhvdyBpdCBpbnRlcm9w ZXJhdGVzIHdpdGggYW55dGhpbmcgZWxzZSBub3cuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SeKAmW0gY29ubmVjdGluZyBhIG5ldyBJUCBiYXNlZCBzeXN0ZW0gdGhhdCB1c2VzIHN0 YW5kYXJkcyBiYXNlZCBTSVAgdG8gYW4gZXhpc3Rpbmcgb2xkIHN5c3RlbS4mbmJzcDsgVGhhdCBz eXN0ZW0gZXhwZWN0cyB0byBzaWduYWwgdG8gZG8gYSBjYWxsIHRyYW5zZmVyIG9yIGNvbmZlcmVu Y2Ugb3BlcmF0aW9uIHdpdGggY29tYmluYXRpb25zIG9mIGZsYXNoIGFuZCBEVE1GLiZuYnNwOyBU aGVyZSBpcyBhIG5ldHdvcmsgdGhhdCBpcw0KIHVzaW5nIG5vcm1hbCBTSVAgc2lnbmFsaW5nIGZv ciB0cmFuc2Zlci9jb25mZXJlbmNlLCBhbmQgdGhpcyBvbGRlciBzeXN0ZW0gdGhhdCBpcyBleHBl Y3RpbmcgaG9vayBzd2l0Y2ggYW5kIERUTUYuJm5ic3A7IElkZWFsbHksIHdlIHdvdWxkIGhhdmUg dGhlIFVBIGZhY2luZyB0aGUgb2xkZXIgc3lzdGVtIGRvIHRoZSBpbnRlcndvcmssIGJ1dCBhbGFz IHRoYXQgd29u4oCZdCB3b3JrLCBhbmQgd2UgbmVlZCBhbm90aGVyIGVsZW1lbnQgdG8gZG8gdGhl IGludGVyd29yaywNCiBhbmQgdHJhbnNwb3J0IHRoZSBEVE1GIGFuZCBmbGFzaCB0byB0aGUgVUEg d2hpY2ggd2lsbCBwbGF5IG91dCB0aGUgc2lnbmFsaW5nLiZuYnNwOyBJZiBJIG1hZGUgdGhhdCBV QSBhbmQgdGhlIGludGVyd29ya2luZyBlbGVtZW50IGNvbmZvcm0gdG8gMjgzMywgZXZlcnl0aGlu ZyB3b3VsZCBiZSBmaW5lLCBidXQgdGhlbiBJ4oCZbSByZXF1aXJpbmcgY29uZm9ybWFuY2UgdG8g YW4gb2Jzb2xldGUgZG9jdW1lbnQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCklmIEkgcmVwbGFjZSAmcXVvdDtORU5BJnF1b3Q7IHdpdGggJnF1b3Q7QSBwcm9wcmlldGFy eSBzeXN0ZW0gdXNlcyBmbGFzaCBpbnRlcnNwZXJzZWQgd2l0aCBvdGhlciBEVE1GIHRvbmVzIHRv IHNlbmQgc2lnbmFsbGluZyBldmVudHMgdG8gYSBnYXRld2F5JnF1b3Q7IGlzIHRoYXQgYXBwcm94 aW1hdGVseSB0cnVlPyZuYnNwOyBUaGUga2V5IHF1ZXN0aW9uIHNlZW1zIHRvIGJlICZxdW90O3do YXQgYXJlIHRoZXNlIGV2ZW50cywgYW5kIHdoYXQncyB0aGUgcmlnaHQgd2F5IHRvIHNpZ25hbCB0 aGVtIHRvDQogYSBnYXRld2F54oCdPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl04oCZcyBhcHByb3hp bWF0ZWx5IHRydWUsIGJ1dCBpdOKAmXMgYSBzdGFuZGFyZHMgYmFzZWQgc3lzdGVtLCBub3QgYSBw cm9wcmlldGFyeSBzeXN0ZW0uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3Ugc2F5IHRo YXQsIGJ1dCB5b3UgYXBwZWFyIHRvIGJlIGltcGx5aW5nIHRoYXQgaXQgaXMgYSBzeXN0ZW0gYmFz ZWQgb24gYSBzdGFuZGFyZCB0aGF0IHdhcyBkaXNhcHBlYXJpbmcgaW4gMjAwMCAoUkZDIDI4MzMp IGFuZCBnb25lIGJ5IDIwMDYgKFJGQyA0NzMzKS4mbmJzcDsgWW91IGFwcGVhciB0byBiZSBhdHRl bXB0aW5nIHRvIGNyZWF0ZSBhIG5ldyBzdGFuZGFyZCBpbiAyMDE2IChsZXQncyBiZSBob25lc3Qg aGVyZSwNCiBsaWtlbHkgYXJyaXZpbmcgaW4gMjAxOCkgdGhhdCByZWNhcGl0dWxhdGVzIHNvbWV0 aGluZyBmcm9tIHRoZSBwYXN0IHNvIHRoYXQgTkVOQSBkb2Vzbid0IGhhdmUgdG8gdXBkYXRlIHNv bWV0aGluZyB0aGF0J3MgYmVlbiBzdXBlcnNlZGVkLjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7VGhlIG9sZGVyIHN5c3RlbSBpcyBzdGFuZGFyZHMgYmFzZWQsIHRoZSBu ZXcgc3lzdGVtIGlzIHN0YW5kYXJkcyBiYXNlZCwgYW5kIEkgbmVlZCB0byBpbnRlcndvcmsgdGhl bSBpbiAmbmJzcDthIHN0YW5kYXJkcyBiYXNlZCBtYW5uZXIuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WW91IHdhbnQgZXZlcnlvbmUgZWxzZSB0byByZS1pbXBsZW1lbnQgZmxh c2ggc28gdGhhdCBORU5BIGRvZXNuJ3QgcmVwbGFjZSB0aGVpciBwcm9wcmlldGFyeS9zdXBlcnNl ZGVkIHN5c3RlbT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBubyBvdGhlciB3YXkgdG8gdHJhbnNwb3J0 IGZsYXNoIHRvIGludGVyd29yayB3aXRoIG91ciBuZXdlciBTSVAgYmFzZWQgZW1lcmdlbmN5IGNh bGxpbmcgc3lzdGVtcy48YnI+DQo8YnI+DQpJ4oCZbSBwcmVwYXJlZCB0byB3cml0ZSBhIGRyYWZ0 IHRoYXQgcmVzdG9yZXMgY29kZSAxNiBmb3IgZmxhc2gsIGFzIGl0IHdhcyBpbiAyODMzLCBidXQg d2FudGVkIHRvIGhlYXIgYW55IG9iamVjdGlvbnMgdG8gZG9pbmcgdGhhdC48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxldCBtZSBn ZW50bHkgc3VnZ2VzdCB0aGF0IHlvdSBpbnN0ZWFkIGFzayB0byByZS11c2UgY29kZSAxNiwgbG9u ZyBpbiBhYmV5YW5jZSwgZm9yIHRoaXMgbmV3IHB1cnBvc2UsIHdoYXRldmVyIHlvdSBldmVudHVh bGx5IGV4cGxhaW4gaXQgdG8gYmUuJm5ic3A7IFVubGVzcyB5b3UgcGxhbiB0byBmb3JjZSBwZW9w bGUgdG8gZ28gYmFjayB0aHJvdWdoIHRoZWlyIG9sZCBJVFUgRS4xOCogZG9jcyBhbmQgQmVsbGNv cmUgR1ItNTA2LUNPUkUNCiBQREZzIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQgZXhhY3RseSBp cyBpbnZvbHZlZCBpbiB0aGlzIHJlc3VycmVjdGlvbiwgc2F5aW5nICZxdW90O3Jlc3RvcmVzJnF1 b3Q7IHNlZW1zIGxpa2UgdGhlIHdyb25nIHZlcmIgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFtIGFza2luZyB0byB1c2UgY29kZSAxNiB0byB0cmFuc3BvcnQgZmxh c2gsIGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5IDI4MzMgZGlkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmQgeW91IHdhbnQgdG8gdW5kbyB0aGUgZGVjaXNpb25zIHRoYXQgbGVkIHRv IGl0IGJlaW5nIHNvZnQtZHJvcHBlZCB0aGVyZSBhbmQgZGVwcmVjYXRlZC4mbmJzcDsgQnV0IHRo ZSBqdXN0aWZpY2F0aW9uIGRvZXNuJ3Qgc2VlbSB0byBiZSB0aGVyZS4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBteSB0 d28gY2VudHMsIGRpc2xvZGdlZCBieSBhIGtuZWUtamVyayByZWFjdGlvbiB0byBtYWtpbmcgRFRN RiBtb3JlIGltcG9ydGFudCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFo LCBJ4oCZbSBub3QgdGhyaWxsZWQgd2l0aCBtb3JlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHN0 dWZmIGVpdGhlciwgYnV0IEnigJltIGFsc28gbm90IGEgZmFuIG9mIGFuIG9yZ2FuaXphdGlvbiBs aWtlIE5FTkEgbWFraW5nIHVwIHN0YW5kYXJkcyB1c2luZyBTRFAsIG9yIHJlcXVpcmluZyBjb25m b3JtYW5jZSB0byBvYnNvbGV0ZSBzdGFuZGFyZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhvdyBhYm91dCB0aGV5IGV4cHJlc3Npbmcg d2hhdCB0aGUgYWN0dWFsIGdhdGV3YXkgc2lnbmFsbGluZyByZXF1aXJlbWVudHMgYXJlIGFuZCB3 ZSBzb2x2ZSB0aGVtIHdpdGhvdXQgem9tYmllIERUTUYgc2h1ZmZsaW5nIGFib3V0PzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5KdXN0IGEgdGhvdWdodCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPkJyaWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1tdXNpYyBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYu b3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADF0EEC3FR712WXCHMBA11z_-- From nobody Fri Jun 3 09:36:56 2016 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 7FB8512D52C for ; Fri, 3 Jun 2016 09:36:55 -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=brianrosen-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 u0KE3mp1Jkvo for ; Fri, 3 Jun 2016 09:36:47 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 BEFA612D71C for ; Fri, 3 Jun 2016 09:36:43 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id w16so57986678lfd.2 for ; Fri, 03 Jun 2016 09:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=M7mSVUwYrxZOVymBs+wxNRUMYcVUBzzI3f/dJQfw2es=; b=ZKrosUHBk1Cm+futtS63TRGM6BcKmKVZgsXvGHXF6geZ2FQZTgNVddD9gU4Aph7d0U kqr0DpyKaTLDdMejjCwEFMwgCSGpSLv9FbZH23oCCV3tjYSQznBPFs29xc3gKRYEwINN LDSORCPIH2TG6VmcRBxoFH/ZMH2hr+NnOxaI9AMz3XYU8Scga3x1sTMlTsSS2KA/mngR d/RmtNVb4fRcpkAkunB9kAQacil4YYvMjeN49LBYwolV12QKawOMo6sBgm1G8vQyW4PY rWpAkI5BwNvCCB+Z90A+0GeITmmpHz6nOcSGh2ggXWgyq7VKvF0ALnPZZWK9nWOrAor5 3ftg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=M7mSVUwYrxZOVymBs+wxNRUMYcVUBzzI3f/dJQfw2es=; b=EkKhaUJb7v1qbv3DQhykU4YVyhdiDxlTI8KVDJBWZqV46k+ZM59v/0jzGQNwWWBdoZ 35V6Vu02CPdfSJ65r14XFLyJF9SOOyA9NAPRREx0Kp6o+U/OE60XNflJwNOaacOD3fGO 4T4iDvsb+pUdJiBdFP4htyFLDya83wRfwutPWAISpA69oCvAecOqPqEFbumqY7f0a8cR cxQ5PjHjS7Z0Jl6arrFLizxDIHEl2ETByWsU4gajchYaNJCRWdNZYjlKE7glmlfx5x1Q XJKMeuqM0w+7BpW6M+w/etiJqStAWd+F9vJRQRJjYZtmZAAAYZ1itFaiKTCjPVwT3d+w Xp4Q== X-Gm-Message-State: ALyK8tIDUEc/Lg27OyaCncC28eNSO+mbujGl/sYp8BJl6rwEFG/BruzgwutWIM8V5Vih0T6kipf9faQaNDXyrw== MIME-Version: 1.0 X-Received: by 10.25.160.82 with SMTP id j79mr1060087lfe.72.1464971801827; Fri, 03 Jun 2016 09:36:41 -0700 (PDT) Received: by 10.25.160.15 with HTTP; Fri, 3 Jun 2016 09:36:41 -0700 (PDT) X-Originating-IP: [2600:1016:b10b:b9e5:4dbc:806f:4591:e5e8] In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 3 Jun 2016 12:36:41 -0400 Message-ID: From: Brian Rosen To: "Drage, Keith (Nokia - GB)" Content-Type: multipart/alternative; boundary=001a11412290daafe005346253cc Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:36:55 -0000 --001a11412290daafe005346253cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inline On Friday, June 3, 2016, Drage, Keith (Nokia - GB) wrote: > I think you need to at least answer a couple of questions. > > > > 1) What are you using it for? In the PSTN, the normal usage was to > reconnect a register so that subsequent digits can be received. Now with > both mechanisms for sending DTMF, the recipient is already there to recei= ve > DTMF tones after the initial INVITE has been sent and received some form = of > provisional response or 200 OK. As such, it is not needed for that > function. It is for that reason I think it was eventually dropped in the > ISDN DSS1 documents (the signalling channel always being in existence in > ISDN), and possibly that may be the reason it does not appear in the SIP > documents. Now I know there are some special obscurities in the North > American usage of this that makes two different signals based on timing > differences, but please explain if you are using these, and what the resu= lt > means. > > This is for inter working a legacy PSAP with a CAMA interface that was facing a selective router. We upgrade the network but need to be able to support non-upgraded PSAPs. It uses flash in the usual way to engage the signaling system to look for tones. The actual gateway doesn't have the ability to interwork the flash digit sequence to the right combination of INVITE and REFER to do the conferencing and transfer operations that the selective router would have done. > 2) In the North America 911 work, I understood that the CS domain > was being separated from the PS (SIP) domain even through the emergency > services network and all the way to the PSAP. As such, why are you having > to interwork PSTN type signals, which have presumably come from a PSTN > endpoint, and if so where in the architecture are you doing it. > > This is the interwork from the Legacy PSAP Gateway to the ESInet. A similar problem exists for a Legacy Selective Router Gateway that actually connects to the selective router and mimics a legacy PSAP. > Regards > > > > Keith > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org > ] *On Behalf Of = *Brian > Rosen > *Sent:* 03 June 2016 13:36 > *To:* Adam Roach > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] Transport of "Flash-hook" > > > > Yeah, the ones I know about do. They claim 2833 compliance for the most > part. > > > > As I said, one way to solve this is just require 2833 compliance in a spe= c > written in 2016. > > We probably wouldn=E2=80=99t allow a normative reference to 2833 in some = standards > track RFC we wrote today; we would fix whatever the problem was. > > > > Brian > > > > On Jun 2, 2016, at 6:07 PM, Adam Roach > wrote: > > > > And, for clarity: > > The SIP GW already sends event 16 when it sees a hookflash? Or do you nee= d > to update its software to accomodate this change? > > /a > > On 6/2/16 16:41, Brian Rosen wrote: > > Sure > > > > > > SIP SIP MF > > SIP-UA =E2=80=94=E2=80=94 IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 Leg= acy PSAP > > > > A call is up from the SIP-UA to the Legacy PSAP through the IWF and GW. > > > > The Legacy PSAP is trying to tell the SIP UA to transfer the call > > > > GW is an existing off the shelf, normal IP-PSTN gateway, most of which > actually are 2833 compliant, but I=E2=80=99m trying not to require confor= mance to > 2833. Note that =E2=80=9CMF=E2=80=9D is tone signaled analog telephony. = The actual MF > protocol used here is CAMA. > > > > IWF is a B2BUA that has code we can do anything reasonable with, which > will conform to NENA standards. > > > > The Legacy PSAP signals a transfer by sending FLASH, digit, digit, digit= =E2=80=A6. > > > > The GW gets this signaling, but doesn=E2=80=99t really know what to do wi= th it, so > it passes the sequence to the IWF > > > > The IWF recognizes this is a transfer request, and generates the REFER to > the SIP UA. > > > > The problem I=E2=80=99m solving is the signaling between the GW and the I= WF. I > can transport the digits with 4733, but not the flash. > > > > > > On Jun 2, 2016, at 5:02 PM, Adam Roach > wrote: > > > > This sounds like a whole lot of talking past each other. Brian: do you > have a rough picture of the system you're designing that you could share? > Something that points out old parts versus new parts and highlights where > RFC 4733 would be used? > > /a > > On 6/2/16 15:58, Ted Hardie wrote: > > Howdy, > > In-line. > > > On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen > wrote: > > Hi Ted > > > > On Jun 2, 2016, at 4:15 PM, Ted Hardie > wrote: > > > > Hi Brian, > > > > On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen > wrote: > > Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80= =9CFlash=E2=80=9D, > the signal caused by a momentary depression of the hook-switch in a POTS > phone. When 2833 was obsoleted by 4733, flash was dropped, although the > code 16 was reserved. > > > > It looks to me that you could be compliant with RFC 2833 without > implementing flash at all (see Section 3.3, on event types). This has be= en > effectively gone a long time, in other words. > > I=E2=80=99m sorry, I don=E2=80=99t understand. > > > > I'm saying that since you could call yourself compliant RFC 2833 without > implementing flash at all, the ability to count on this went away before > the turn of the millenium. As in 16 years ago. > > > > We=E2=80=99re writing a new standard, and I=E2=80=99d really prefer to n= ot reference an > obsolete IETF standard in that document. I need to signal flash, the way > 2833 signaled flash, but 4733 doesn=E2=80=99t have a way to signal flash. > > > > > > > We have a use case in NENA (9-1-1 emergency stuff) where existing systems > use flash interspersed wth tones in signaling dialing events which are no= t > interpreted by the UA that receives them, but are instead transported to = a > device that creates appropriate SIP signaling for the dialing events > initiated. > > > > So, I'm not sure why invoking NENA and emergency services matters here. > You don't explain what the system does and how it interoperates with > anything else now. > > I=E2=80=99m connecting a new IP based system that uses standards based SI= P to an > existing old system. That system expects to signal to do a call transfer > or conference operation with combinations of flash and DTMF. There is a > network that is using normal SIP signaling for transfer/conference, and > this older system that is expecting hook switch and DTMF. Ideally, we > would have the UA facing the older system do the interwork, but alas that > won=E2=80=99t work, and we need another element to do the interwork, and = transport > the DTMF and flash to the UA which will play out the signaling. If I mad= e > that UA and the interworking element conform to 2833, everything would be > fine, but then I=E2=80=99m requiring conformance to an obsolete document. > > > > If I replace "NENA" with "A proprietary system uses flash interspersed > with other DTMF tones to send signalling events to a gateway" is that > approximately true? The key question seems to be "what are these events, > and what's the right way to signal them to a gateway=E2=80=9D? > > It=E2=80=99s approximately true, but it=E2=80=99s a standards based syste= m, not a > proprietary system. > > You say that, but you appear to be implying that it is a system based on = a > standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC > 4733). You appear to be attempting to create a new standard in 2016 (let= 's > be honest here, likely arriving in 2018) that recapitulates something fro= m > the past so that NENA doesn't have to update something that's been > superseded. > > > The older system is standards based, the new system is standards based, > and I need to interwork them in a standards based manner. > > > > You want everyone else to re-implement flash so that NENA doesn't replace > their proprietary/superseded system? > > > > > > We have no other way to transport flash to interwork with our newer SIP > based emergency calling systems. > > I=E2=80=99m prepared to write a draft that restores code 16 for flash, as= it was > in 2833, but wanted to hear any objections to doing that. > > > > Let me gently suggest that you instead ask to re-use code 16, long in > abeyance, for this new purpose, whatever you eventually explain it to be. > Unless you plan to force people to go back through their old ITU E.18* do= cs > and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involv= ed > in this resurrection, saying "restores" seems like the wrong verb here. > > I am asking to use code 16 to transport flash, in exactly the same way > 2833 did. > > > > > > And you want to undo the decisions that led to it being soft-dropped ther= e > and deprecated. But the justification doesn't seem to be there. > > > > Just my two cents, dislodged by a knee-jerk reaction to making DTMF more > important, > > Yeah, I=E2=80=99m not thrilled with more backwards compatibility stuff ei= ther, but > I=E2=80=99m also not a fan of an organization like NENA making up standar= ds using > SDP, or requiring conformance to obsolete standards. > > > > How about they expressing what the actual gateway signalling requirements > are and we solve them without zombie DTMF shuffling about? > > Just a thought, > > Ted > > > > > > Brian > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > > > --001a11412290daafe005346253cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inline

On Friday, June 3, 2016, Drage, Keith (Nokia - GB) <keith.drage@nokia.com> wrote:
=

I think you need to at le= ast answer a couple of questions.

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What are you using i= t for? In the PSTN, the normal usage was to reconnect a register so that su= bsequent digits can be received. Now with both mechanisms for sending DTMF, the recipient is already there to receive DTMF tones aft= er the initial INVITE has been sent and received some form of provisional r= esponse or 200 OK. As such, it is not needed for that function. It is for t= hat reason I think it was eventually dropped in the ISDN DSS1 documents (the signalling channel always being in= existence in ISDN), and possibly that may be the reason it does not appear= in the SIP documents. Now I know there are some special obscurities in the= North American usage of this that makes two different signals based on timing differences, but please explai= n if you are using these, and what the result means.

This is for inter working a legacy P= SAP with a CAMA interface that was facing a selective router. We upgrade th= e network but need to be able to support non-upgraded PSAPs. It uses flash = in the usual way to engage the signaling system to look for tones. The actu= al gateway doesn't have the ability to interwork the flash digit sequen= ce to the right combination of INVITE and REFER to do the conferencing and = transfer operations that the selective router would have done.=C2=A0=C2=A0<= /div>

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the North America= 911 work, I understood that the CS domain was being separated from the PS = (SIP) domain even through the emergency services network and all the way to the PSAP. As such, why are you having to interwork PSTN= type signals, which have presumably come from a PSTN endpoint, and if so w= here in the architecture are you doing it.

<= /div>
This is the interwork from the Legacy PSAP Gat= eway to the ESInet.=C2=A0

A similar problem exists= for a Legacy Selective Router Gateway that actually connects to the select= ive router and mimics a legacy PSAP.=C2=A0

Regards

=C2=A0

Keith

=C2=A0

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: 03 June 2016 13:36
To: Adam Roach
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Transport of "Flash-hook"<= /u>

=C2=A0

Yeah, the ones I know about do.=C2=A0 They claim 283= 3 compliance for the most part.

=C2=A0

As I said, one way to solve this is just require 283= 3 compliance in a spec written in 2016. =C2=A0

We probably wouldn=E2=80=99t allow a normative refer= ence to 2833 in some standards track RFC we wrote today; we would fix whate= ver the problem was.

=C2=A0

Brian

=C2=A0

On Jun 2, 2016, at 6:07 PM, Adam Roach <adam@nostrum.com> wrote:

=C2=A0

And, for clarity:

The SIP GW already sends event 16 when it sees a hookflash? Or do you need = to update its software to accomodate this change?

/a

On 6/2/16 16:41, Brian Rosen wrote:

Sure

=C2=A0

=C2=A0

=C2=A0 =C2=A0 = =C2=A0 =C2=A0SIP =C2=A0 =C2=A0SIP =C2=A0 MF

SIP-UA =E2=80=94= =E2=80=94 IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 Legacy PSAP=

=C2=A0

A call is up fro= m the SIP-UA to the Legacy PSAP through the IWF and GW.

=C2=A0

The Legacy PSAP = is trying to tell the SIP UA to transfer the call

=C2=A0

GW is an existin= g off the shelf, normal IP-PSTN gateway, most of which actually are 2833 co= mpliant, but I=E2=80=99m trying not to require conformance to 2833. Note th= at=C2=A0=E2=80=9CMF=E2=80=9D is tone signaled analog telephony.=C2=A0 The actual MF protocol used here is CAMA.

=C2=A0

IWF is a B2BUA t= hat has code we can do anything reasonable with, which will conform to NENA= standards.

=C2=A0

The Legacy PSAP = signals a transfer by sending FLASH, digit, digit, digit=E2=80=A6.

=C2=A0

The GW gets this= signaling, but doesn=E2=80=99t really know what to do with it, so it passe= s the sequence to the IWF

=C2=A0

The IWF recogniz= es this is a transfer request, and generates the REFER to the SIP UA.

=C2=A0

The problem I=E2= =80=99m solving is the signaling between the GW and the IWF.=C2=A0 I can tr= ansport the digits with 4733, but not the flash.

=C2=A0

=C2=A0

On Jun 2, 2016, at 5:02 PM, Adam Roach <adam@nostrum.com> wrote:

=C2=A0

This sounds like a whole lot of talking past each ot= her. Brian: do you have a rough picture of the system you're designing = that you could share? Something that points out old parts versus new parts = and highlights where RFC 4733 would be used?

/a

On 6/2/16 15:58, Ted Hardie wrote:

Howdy,<= /p>

In-line.


On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen <br@bri= anrosen.net> wrote:

Hi Ted

=C2=A0

On Jun 2, 2016, at 4:15 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

=C2=A0

Hi Brian,

=C2=A0

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <br@brianrosen.net> wrote:

Back in RFC2833, the DTMF tones section, code 16 was= defined for =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depr= ession of the hook-switch in a POTS phone.=C2=A0 When 2833 was obsoleted by= 4733, flash was dropped, although the code 16 was reserved.<= /p>

=C2=A0

It looks to me that you could be compliant with RFC = 2833 without implementing flash at all (see Section 3.3, on event types).= =C2=A0 This has been effectively gone a long time, in other words.

I=E2=80=99m sorry, I don=E2=80=99t understand.

=C2=A0

I'm saying that since you could call yourself co= mpliant RFC 2833 without implementing flash at all, the ability to count on= this went away before the turn of the millenium.=C2=A0 As in 16 years ago.=

=C2=A0

=C2=A0We=E2=80=99re writing a new standard, and I=E2= =80=99d really prefer to not reference an obsolete IETF standard in that do= cument.=C2=A0 I need to signal flash, the way 2833 signaled flash, but 4733= doesn=E2=80=99t have a way to signal flash.



=C2=A0


We have a use case in NENA (9-1-1 emergency stuff) where existing systems u= se flash interspersed wth tones in signaling dialing events which are not i= nterpreted by the UA that receives them, but are instead transported to a d= evice that creates appropriate SIP signaling for the dialing events initiated.=C2=A0

=C2=A0<= /p>

So, I'm not sure why invoking NENA and emergency= services matters here.=C2=A0 You don't explain what the system does an= d how it interoperates with anything else now.=C2=A0=C2=A0

I=E2=80=99m connecting a new IP based system that us= es standards based SIP to an existing old system.=C2=A0 That system expects= to signal to do a call transfer or conference operation with combinations = of flash and DTMF.=C2=A0 There is a network that is using normal SIP signaling for transfer/conference, and this older system = that is expecting hook switch and DTMF.=C2=A0 Ideally, we would have the UA= facing the older system do the interwork, but alas that won=E2=80=99t work= , and we need another element to do the interwork, and transport the DTMF and flash to the UA which will play out the signali= ng.=C2=A0 If I made that UA and the interworking element conform to 2833, e= verything would be fine, but then I=E2=80=99m requiring conformance to an o= bsolete document.



If I replace "NENA" with "A proprietary system uses flash in= terspersed with other DTMF tones to send signalling events to a gateway&quo= t; is that approximately true?=C2=A0 The key question seems to be "wha= t are these events, and what's the right way to signal them to a gateway=E2=80=9D?

It=E2=80=99s approximately true, but it=E2=80=99s a = standards based system, not a proprietary system.

You say that, but you appear to be implying that it = is a system based on a standard that was disappearing in 2000 (RFC 2833) an= d gone by 2006 (RFC 4733).=C2=A0 You appear to be attempting to create a ne= w standard in 2016 (let's be honest here, likely arriving in 2018) that recapitulates something from the past so tha= t NENA doesn't have to update something that's been superseded.
=C2=A0

=C2=A0The older system is standards based, the new s= ystem is standards based, and I need to interwork them in =C2=A0a standards= based manner. =C2=A0

=C2=A0

You want everyone else to re-implement flash so that= NENA doesn't replace their proprietary/superseded system?

=C2=A0

=C2=A0

We have no other way to transport flash to interwork= with our newer SIP based emergency calling systems.

I=E2=80=99m prepared to write a draft that restores code 16 for flash, as i= t was in 2833, but wanted to hear any objections to doing that.

=C2=A0

Let me gently suggest that you instead ask to re-use= code 16, long in abeyance, for this new purpose, whatever you eventually e= xplain it to be.=C2=A0 Unless you plan to force people to go back through t= heir old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, s= aying "restores" seems like the wrong verb here.

I am asking to use code 16 to transport flash, in ex= actly the same way 2833 did.

=C2=A0

=C2=A0

And you want to undo the decisions that led to it be= ing soft-dropped there and deprecated.=C2=A0 But the justification doesn= 9;t seem to be there.

=C2=A0

Just my two cents, dislodged by a knee-jerk reaction= to making DTMF more important,

Yeah, I=E2=80=99m not thrilled with more backwards c= ompatibility stuff either, but I=E2=80=99m also not a fan of an organizatio= n like NENA making up standards using SDP, or requiring conformance to obso= lete standards.

=C2=A0

How about they expres= sing what the actual gateway signalling requirements are and we solve them = without zombie DTMF shuffling about?

Just a thought,

Ted

=C2=A0

=C2=A0

Brian

=C2=A0

=C2=A0




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

=C2=A0

=C2=A0

=C2=A0

=C2=A0

--001a11412290daafe005346253cc-- From nobody Fri Jun 3 09:51:44 2016 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 6D9FA12D729 for ; Fri, 3 Jun 2016 09:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 CZhBFQe9uihj for ; Fri, 3 Jun 2016 09:51:39 -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 5285812D725 for ; Fri, 3 Jun 2016 09:51:39 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u53GpYHD035280 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Jun 2016 11:51:36 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Brian Rosen , "Drage, Keith (Nokia - GB)" References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Adam Roach Message-ID: <75a6d14f-1322-7ebc-0c79-6a38c623becd@nostrum.com> Date: Fri, 3 Jun 2016 11:51:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:51:42 -0000 Given that we have deployed gateways generating these events per an older spec, and given that the code was removed only because of perceived lack of use (as opposed to a concrete sense of potential harm), it seems reasonable to revive the 2833 meaning of event 16 in a formal sense. I'll note that RFC4733 foresaw this as a reasonable kind of thing that might happen; it explicitly says: > codes 16 [and several others]... are reserved in the first instance > for specifications reviving the corresponding RFC 2833 events... I agree with what I think I hear other people saying: we don't want to encourage new uses of flash. At the same time, there's no sensible reason to force the E911 folks into doing something nonstandard just because we're afraid modern systems might copy the technique. So I would support MMUSIC adopting and requesting publication for a narrowly scoped document that registers event 16 for hook flash, assuming the scope is sufficiently well-defined (e.g., indicating that this behavior is anticipated to be used by legacy gateways of the style Brian describes, rather than native SIP terminals or traditional endpoint ATAs). /a From nobody Fri Jun 3 09:57:37 2016 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 276C312B006 for ; Fri, 3 Jun 2016 09:57:36 -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=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 A1IBnSlTUgVe for ; Fri, 3 Jun 2016 09:57:33 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA4212D729 for ; Fri, 3 Jun 2016 09:57:33 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id e72so136079770oib.1 for ; Fri, 03 Jun 2016 09:57:33 -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=13vXx/ScU8k6iDIcGW+tIaChUrA5zWoFIef4mYYsXVU=; b=lTOTq+NJ+R1rsNSfpDK8GI2WCLVqBXVpvomBYsEynm7PIJCNQQCjihTlE53ryjchW/ Bx8PGMK5G6A/d9xqr6gg0vxOfAr4uDqBkqatQrul4mbH11xqhZ1og3pGNNf5Y5o01deq ytQOWeJZhlw5RgS9FboxpGMq6i998ontDDpxzgJgNQCCo2Jgx7CoM/7oDOScNCQOfM0Z /04Fmxe5xaFzMeNC4/nP1RxkUn9c7TdDu3dXJFmZvZjjjsWHtkkBgm/1xsj65De7OrLn s3iBIND8JrrXilQ6QmAs7/nZq5m6MMoQFWxs+s288i1mZRUU9ldOmYVR+K7oQu58UTof J3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=13vXx/ScU8k6iDIcGW+tIaChUrA5zWoFIef4mYYsXVU=; b=CvTg6vfDtihth4qEgPQm2LR7m+3cViveasQurDyUdMrZ53qp5TRtoUZ2//gPl+lD5+ cOs8RiXpNzp1lIArg0L6tEq2HH50IaT2DuF42r5AP1CcTZlFHx/kUK9h8dnEMOVmRJ2a pzdC/eKsqkbg/z8g+aVIgnI9MNah+HQi97JPeJEn/a00C+kNNbmZDKHwL8SrovsUR4N2 ijBqG4YCAOjVdNM80V8Ktoum/ghwnKshJeQn2LWXEeRMtDUFdShFrgD/dfPPtZKLhwu0 gnU1AtfUYUKYBOA6TYPgINtT3mwRmK0CwabGfUJaDjKmGzo2JhORraVkQYqlfVOqM5z5 owBg== X-Gm-Message-State: ALyK8tKwHUzbYjB6+4MEfq/EanaHsaiy2Nn0MqtG+JofR1YFWA3L0ZBQqOYPC7FWUfdcTg== X-Received: by 10.157.46.80 with SMTP id c16mr2569037otd.46.1464973052874; Fri, 03 Jun 2016 09:57:32 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id 53sm3515623otv.1.2016.06.03.09.57.32 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 09:57:32 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id p194so80362902iod.1 for ; Fri, 03 Jun 2016 09:57:32 -0700 (PDT) X-Received: by 10.107.160.76 with SMTP id j73mr6407329ioe.66.1464973051919; Fri, 03 Jun 2016 09:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Fri, 3 Jun 2016 09:57:30 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37FF3B58@ESESSMB209.ericsson.se> <2a554789-0668-74f0-4bb4-e2908daa5e91@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37FF4E53@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FBC2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FC74@ESESSMB209.ericsson.se> <2a5ebdc5-20c6-8a55-c6fd-f18957f2c4e4@alum.mit.edu> From: Roman Shpount Date: Fri, 3 Jun 2016 12:57:30 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114027b85dc71e0534629e90 Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:57:36 -0000 --001a114027b85dc71e0534629e90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 3, 2016 at 9:09 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > =E2=80=9CUnless the answerer has other ways of knowing what hash function= s the > offerer support the answerer MUST calculate, and include in the answer, a= t > least one fingerprint using a hash function that were used for calculatin= g > a fingerprint in the associated offer. In addition, the answerer MAY > calculate and include fingerprints using hash functions that were not use= d > to calculate fingerprints in the offer.=E2=80=9D > > LGTM _____________ Roman Shpount --001a114027b85dc71e0534629e90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 3, 2016 at 9:09 AM, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:
=E2=80=9CUnless the answerer has other ways of knowing what hash funct= ions the offerer support the answerer MUST calculate, and include in the an= swer, at least one fingerprint using a hash function that were used for cal= culating a fingerprint in the associated offer. In addition, the answerer MAY calculate and include fingerprints us= ing hash functions that were not used to calculate fingerprints in the offe= r.=E2=80=9D


LGTM
_____________Roman Shpount
=C2=A0
--001a114027b85dc71e0534629e90-- From nobody Fri Jun 3 10:49:27 2016 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 BD71D12D789 for ; Fri, 3 Jun 2016 10:49:25 -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 Qwc9ioaRNYIw for ; Fri, 3 Jun 2016 10:49:22 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5260E12D77D for ; Fri, 3 Jun 2016 10:49:22 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j1so137971110oih.3 for ; Fri, 03 Jun 2016 10:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U6YwgZz5b+2oJHdbmC7sqObjPmhPUXuoF/pNx4BZR98=; b=DFtXkOenXPCT6LZ2g/zqt/o0B6LCOlNw3wVA8FYRJKlfc2NVZwh+/cwHAFPv2/T3kK YUbuMQ4lCGAYT01wb9G8KIRiKqvpUPmpbRxfYBE7+KuIBI+DX3LBLDamdxGHYlTTxef0 fof8V9rnh4L9wXc7AMmq42l4Zb9rlcf3EUrQydtOXCp7R4rZ+mxzQ6m1V7QS6L6QwTGS tAJhxbXNsjqXa4/5QNKEBTaCJknS7vqG8GwsyXbSUwUL0Y5cbrjMcBarY7VxnK26zSZO 2MquTLYkfRxPhFW0UhdASBHylyAY4jCnRuldBrkn2yQtjTmnuaJqy3NsgNgjDsmYm6C0 0/7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U6YwgZz5b+2oJHdbmC7sqObjPmhPUXuoF/pNx4BZR98=; b=aMxF2ULkQ1I9CQ6r/WjVRjqY2MJcUOakZBXyMWox7lewWuYJJjiTnao2xNxj93Qmix RU8aMW11n0CQ1u7rkjB4P1mB+/uPdXgJJEY7NjHhO24MVdu6fNMN+78XsJbcPOTUkkUU BtYvV8rRDyOL8lFdIjVZ3N7YhFEWWAnUpz2EW6z6ruUueG9B2aPwNCV0EMOGy0U1hTOM 7VYfMPuLTQdElU1vUzWdgJRreu3iVvCCBan5hPwjPbuWbTh8rrQMYhT4h6Yo/5PHY+5D O+MX1KPZ6SfrVd7L6bOwXE9i744HY8CqGTOOCPCpwj81ZvD2Dy5SZOtKP8kRDXqboC4/ 3jCw== X-Gm-Message-State: ALyK8tIN05EyTuwQLxbzBl+1xqUDvhJd87FWcRINgb4rqgRFKefZEW85sNumbGoA8aCihzWGkOXr8wYatcNacw== X-Received: by 10.157.49.4 with SMTP id e4mr2737894otc.18.1464976161721; Fri, 03 Jun 2016 10:49:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.195.137 with HTTP; Fri, 3 Jun 2016 10:49:02 -0700 (PDT) In-Reply-To: <75a6d14f-1322-7ebc-0c79-6a38c623becd@nostrum.com> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <75a6d14f-1322-7ebc-0c79-6a38c623becd@nostrum.com> From: Ted Hardie Date: Fri, 3 Jun 2016 10:49:02 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a113e1ca8b95288053463571b Archived-At: Cc: "mmusic@ietf.org" , "Drage, Keith \(Nokia - GB\)" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:49:26 -0000 --001a113e1ca8b95288053463571b Content-Type: text/plain; charset=UTF-8 On Fri, Jun 3, 2016 at 9:51 AM, Adam Roach wrote: > Given that we have deployed gateways generating these events per an older > spec, So I think the value of "we" is pretty small here. > and given that the code was removed only because of perceived lack of use > (as opposed to a concrete sense of potential harm), it seems reasonable to > revive the 2833 meaning of event 16 in a formal sense. > > I'll note that RFC4733 foresaw this as a reasonable kind of thing that > might happen; it explicitly says: > > codes 16 [and several others]... are reserved in the first instance for >> specifications reviving the corresponding RFC 2833 events... >> > > I agree with what I think I hear other people saying: we don't want to > encourage new uses of flash. At the same time, there's no sensible reason > to force the E911 folks into doing something nonstandard I think the continued invocation of un-upgraded PSAPs is a definite signal here. If we took out "NENA" here and said that this was a gateway deployed by, say, Walmart, would we really get the same result? They have many thousands of stores, serve millions upon millions of people in North America, and have been around long enough that they too might have legacy code deployed. Could Walmart ask for this from a global standards body? I'll try to get my knee to stop jerking on this as soon as possible, but I have to say I'm still not convinced this is a reasonable thing to standardize in 2016. This remains reserved; NENA's PSAPs are very unlikely to to find other uses of 16 that interfere with what they are doing--but standardizing this seems seriously retrograde to me. Ted > just because we're afraid modern systems might copy the technique. > > So I would support MMUSIC adopting and requesting publication for a > narrowly scoped document that registers event 16 for hook flash, assuming > the scope is sufficiently well-defined (e.g., indicating that this behavior > is anticipated to be used by legacy gateways of the style Brian describes, > rather than native SIP terminals or traditional endpoint ATAs). > > > /a > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113e1ca8b95288053463571b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 3, 2016 at 9:51 AM, Adam Roach <adam@nostrum.c= om> wrote:
Given that we have= deployed gateways generating these events per an older spec,
<= div>
So I think the value of "we" is pretty small h= ere.
=C2=A0
and given that the code was removed only because of perceived lack o= f use (as opposed to a concrete sense of potential harm), it seems reasonab= le to revive the 2833 meaning of event 16 in a formal sense.

I'll note that RFC4733 foresaw this as a reasonable kind of thing that = might happen; it explicitly says:

codes 16 [and several others]... are reserved in the first instance for spe= cifications reviving the corresponding RFC 2833 events...

I agree with what I think I hear other people saying: we don't want to = encourage new uses of flash. At the same time, there's no sensible reas= on to force the E911 folks into doing something nonstandard

I think the continued invocation of un-upgraded PSAPs is a= definite signal here.=C2=A0 If we took out "NENA" here and said = that this was a gateway deployed by, say, Walmart, would we really get the = same result?=C2=A0 They have many thousands of stores, serve millions upon = millions of people in North America, and have been around long enough that = they too might have legacy code deployed. =C2=A0 Could Walmart ask for this= from a global standards body?

I'll try to= get my knee to stop jerking on this as soon as possible, but I have to say= I'm still not convinced this is a reasonable thing to standardize in 2= 016.=C2=A0 This remains reserved; NENA's PSAPs are very unlikely to to = find other=20 uses of 16 that interfere with what they are doing--but standardizing=20 this seems seriously retrograde to me.


Ted
<= div>=C2=A0
just bec= ause we're afraid modern systems might copy the technique.

So I would support MMUSIC adopting and requesting publication for a narrowl= y scoped document that registers event 16 for hook flash, assuming the scop= e is sufficiently well-defined (e.g., indicating that this behavior is anti= cipated to be used by legacy gateways of the style Brian describes, rather = than native SIP terminals or traditional endpoint ATAs).


/a


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

--001a113e1ca8b95288053463571b-- From nobody Fri Jun 3 11:08:10 2016 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 372DC12D814 for ; Fri, 3 Jun 2016 11:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 3sFjPuweY_XF for ; Fri, 3 Jun 2016 11:08:06 -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 B37B212D80F for ; Fri, 3 Jun 2016 11:08:05 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u53I81TW042169 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Jun 2016 13:08:02 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Ted Hardie References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <75a6d14f-1322-7ebc-0c79-6a38c623becd@nostrum.com> From: Adam Roach Message-ID: <2a8cf5ef-396e-2300-6f86-7eb37764ec0d@nostrum.com> Date: Fri, 3 Jun 2016 13:08:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" , "Drage, Keith \(Nokia - GB\)" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:08:09 -0000 On 6/3/16 12:49, Ted Hardie wrote: > I think the continued invocation of un-upgraded PSAPs is a definite > signal here. If we took out "NENA" here and said that this was a > gateway deployed by, say, Walmart... That seems like a kind of apples-to-bulldozers comparison. One is a public safety governmental function with extremely disparate funds available (depending on locale) undergoing a tricky multi-decade technological upgrade; the other is a monolithic for-profit organization under a single IT administration. This video is pretty amusing overall (warning: not appropriate for more conservative workplaces), but the bit in the middle that goes over the administrative structure might shine a light on the challenges endemic in getting new technology deployed: https://www.youtube.com/watch?v=A-XlyB_QQYs > This remains reserved; NENA's PSAPs are very unlikely to to find other > uses of 16 that interfere with what they are doing--but standardizing > this seems seriously retrograde to me. I suppose it makes little practical difference, but it seems kind of an ivory-tower out-of-touch style response. "Sure, go off and do it, as long as we're not forced to acknowledge it's happening." I guess I'm having a hard time understanding the harm you clearly see in re-registering the code. /a From nobody Fri Jun 3 11:36:59 2016 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 9BB0112B00E for ; Fri, 3 Jun 2016 11:36:57 -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 mf2kxQ7Dj98W for ; Fri, 3 Jun 2016 11:36:54 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A8512D7AA for ; Fri, 3 Jun 2016 11:36:49 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id k23so140330183oih.0 for ; Fri, 03 Jun 2016 11:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Usc6y2w21vGx/GDMBItQH9clviUXL93ZZ6zXcDCNW50=; b=FbFgrkPkFywl+QhtiWYcNhZJJMcnzeKD6NBpWdTXPuRxpqydmcM7Az8A9sOXnq9Mxk wrhesRjnLCZCGpZDlOJnDpcmdJcg2zCwp4+JSE+JZvCYoztJD4rfZSJT8LfWhY7rQUng sEtmzHGhZ0lIdIty91xC/DJtMWkq/oaB3n9NXyxJMD4YlxxAKQLWOE8lJ6R9PUaOHXPX TwCRl3lWOHPK4Wt2TuJ4G+SWX6MP6aWlk4uKUE2vs44c251ciEDx/5kISzr0U2e3f+/k r8P+tmb2nMpa8+65UZTUwXU+C9yXp0Ffb008d0QxsjIT2sgyujzwARk4aLvKY/0AjsAl L1jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Usc6y2w21vGx/GDMBItQH9clviUXL93ZZ6zXcDCNW50=; b=T6KA5u9YvQ+M57wSycrAXEZxzye4DjDHxz8O+vrzsyX3pvi+ny5HYIQ9JX5vzbKLVm p8B/m2Dn2Lmy2KROxx6Z3oD6G9odd2Us6ax8ewwSTgD8tlbriRmetxgfjubWRsTSlyPc DxEZWTaZlCaTHIDcR40MO3/zbeJhcI5DqCQB557uWG0DqJt97diE3ltZiyczlGHeFlse W/WzQQvtb4k/O+RD3KTK2XRa/GZ7h8C7S7VDsVMbYeICkHcai3wkpCNGzP+UK9oe6DbT V+in6joYkqMC5nxV0OfIMe+RSDVgmeinw4M9Fggod3M2lVxg2ue541JrMTcwvfKGVFhc 1U2A== X-Gm-Message-State: ALyK8tJ8ScphYZjlX2WRMC5u9LvrAR46f6hxlqkadc1JZk8OhUd/UGutFqj5z48kY+Pzr0+FYjfnOvhFvheMew== X-Received: by 10.157.49.4 with SMTP id e4mr2857943otc.18.1464979008219; Fri, 03 Jun 2016 11:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.195.137 with HTTP; Fri, 3 Jun 2016 11:36:28 -0700 (PDT) In-Reply-To: <2a8cf5ef-396e-2300-6f86-7eb37764ec0d@nostrum.com> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <75a6d14f-1322-7ebc-0c79-6a38c623becd@nostrum.com> <2a8cf5ef-396e-2300-6f86-7eb37764ec0d@nostrum.com> From: Ted Hardie Date: Fri, 3 Jun 2016 11:36:28 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a113e1ca863702005346401f2 Archived-At: Cc: "mmusic@ietf.org" , "Drage, Keith \(Nokia - GB\)" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:36:57 -0000 --001a113e1ca863702005346401f2 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 3, 2016 at 11:08 AM, Adam Roach wrote: > On 6/3/16 12:49, Ted Hardie wrote: > >> I think the continued invocation of un-upgraded PSAPs is a definite >> signal here. If we took out "NENA" here and said that this was a gateway >> deployed by, say, Walmart... >> > > > That seems like a kind of apples-to-bulldozers comparison. One is a public > safety governmental function with extremely disparate funds available > (depending on locale) undergoing a tricky multi-decade technological > upgrade; the other is a monolithic for-profit organization under a single > IT administration. > > So that sounds like your answer is "The value of doing it is based on a perceived ability of the requester to actually upgrade". Is that the difference between this apple and that bulldozer? (will have to watch video some other time) This remains reserved; NENA's PSAPs are very unlikely to to find other uses >> of 16 that interfere with what they are doing--but standardizing this seems >> seriously retrograde to me. >> > > > I suppose it makes little practical difference, but it seems kind of an > ivory-tower out-of-touch style response. "Sure, go off and do it, as long > as we're not forced to acknowledge it's happening." > > Brian wouldn't be asking for this if someone wasn't going off to write new code. (If this were a completely static system sitting in place, he wouldn't waste his or our time asking to have the code points continued use in RFC 2833 style be documented.) Marking that new code as using something from an older, deprecated standard seems appropriate to me. That's where it is coming from in the system he's describing, and that's really what's happening. Writing a new standard that resurrects this in order to avoiding referencing the older, deprecated standard seems to me to send the wrong signal. Unless we want flash to return, new code using it should be explicit that it is maintaining a deprecated use for a legacy system; resurrecting it as a standard usage is going to send a signal that we think that new, interoperable uses of this should be expected. I don't think we should send that signal, and I didn't hear anything in Brian's use case that justifies it. If Brian would like to write an informational doc that describes flash's continuing use in gateway systems, to help ensure no one squats on the code point, I will cheer him on. My prejudices on this point are pretty thoroughly exposed here, I expect, so I doubt I have much to add. I'll answer questions if asked, but I don't expect to have much more to put into the thread. Ted /trying to stop that ol' trick knee > I guess I'm having a hard time understanding the harm you clearly see in > re-registering the code. > > /a > > --001a113e1ca863702005346401f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 3, 2016 at 11:08 AM, Adam Roach <adam@nostrum.= com> wrote:
On 6/3/16 12:49, Ted Hardie wrote:
I think the continued invocation of un-upgraded PSAPs is a definite signal = here.=C2=A0 If we took out "NENA" here and said that this was a g= ateway deployed by, say, Walmart...


That seems like a kind of apples-to-bulldozers comparison. One is a public = safety governmental function with extremely disparate funds available (depe= nding on locale) undergoing a tricky multi-decade technological upgrade; th= e other is a monolithic for-profit organization under a single IT administr= ation.

So that sounds like your answer is "The value of= doing it is based on a perceived ability of the requester to actually upgr= ade".=C2=A0 Is that the difference between this apple and that bulldoz= er?
=C2=A0
(will have to watch video some other= time)

This remains reserved; NENA's PSAPs are very unlikely to to find other = uses of 16 that interfere with what they are doing--but standardizing this = seems seriously retrograde to me.


 I suppose it makes little practical difference, but it seems kind of an ivo= ry-tower out-of-touch style response. "Sure, go off and do it, as long= as we're not forced to acknowledge it's happening."


Brian wouldn't be asking for this = if someone wasn't going off to write new code.=C2=A0 (If this were a co= mpletely static system sitting in place, he wouldn't waste his or our t= ime asking to have the code points continued use in RFC 2833 style be docum= ented.)=C2=A0 Marking that new code as using something from an older, depre= cated standard seems appropriate to me.=C2=A0 That's where it is coming= from in the system he's describing, and that's really what's h= appening.=C2=A0

Writing a new standard that resurrects this in orde= r to avoiding referencing the older, deprecated standard seems to me to sen= d the wrong signal.
Unless we want flash to return, new code using it s= hould be explicit that it is maintaining a deprecated use for a legacy syst= em; resurrecting it as a standard usage is going to send a signal that we t= hink that new, interoperable uses of this should be expected.=C2=A0 I don&#= 39;t think we should send that signal, and I didn't hear anything in Br= ian's use case that justifies it.

If Brian would like= to write an informational doc that describes flash's continuing use in= gateway systems, to help ensure no one squats on the code point, I will ch= eer him on.=C2=A0

My prejudices on this point are pretty= thoroughly exposed here, I expect, so I doubt I have much to add.=C2=A0 I&= #39;ll answer questions if asked, but I don't expect to have much more = to put into the thread.

Ted
/trying to stop= that ol' trick knee

=C2=A0
I guess I'm having a hard time understanding the harm you clearly see i= n re-registering the code.
/a


--001a113e1ca863702005346401f2-- From nobody Fri Jun 3 11:51:03 2016 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 3730612D8B4 for ; Fri, 3 Jun 2016 11:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 YSOpFqBxhbFf for ; Fri, 3 Jun 2016 11:50:59 -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 5833D12D7AD for ; Fri, 3 Jun 2016 11:50:59 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u53IoqmB045830 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Jun 2016 13:50:53 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Ted Hardie References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <75a6d14f-1322-7ebc-0c79-6a38c623becd@nostrum.com> <2a8cf5ef-396e-2300-6f86-7eb37764ec0d@nostrum.com> From: Adam Roach Message-ID: <4b988588-1de4-c65d-6182-8525dfc87b76@nostrum.com> Date: Fri, 3 Jun 2016 13:50:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mmusic@ietf.org" , "Drage, Keith \(Nokia - GB\)" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:51:02 -0000 On 6/3/16 13:36, Ted Hardie wrote: > So that sounds like your answer is "The value of doing it is based on > a perceived ability of the requester to actually upgrade". Is that > the difference between this apple and that bulldozer? Well, I'm also making a "public benefit" argument (with both characteristics being necessary and neither sufficient for the distinction), but you caught half of what I was saying. > Writing a new standard that resurrects this in order to avoiding > referencing the older, deprecated standard seems to me to send the > wrong signal. Ironically, I think we are disagreeing not because we have different goals, but because we have identical goals and different ideas about the tactics most likely to achieve those goals. I'd like to see text explicitly acknowledging that this usage will be seen in the field -- and even described in nicely formatted quasi-governmental documents -- and explaining why "you, dear reader," should not emulate it. > If Brian would like to write an informational doc that describes > flash's continuing use in gateway systems, to help ensure no one > squats on the code point, I will cheer him on. It's not what I would prefer (I'd actually like to see an IANA update that points to a document that puts the proper scoping around how the codepoint is being used and how it shouldn't be used), but it certainly seems better than just throwing our hands in the air and telling Brian to stuff it. /a From nobody Fri Jun 3 23:46:20 2016 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 35FE112B069 for ; Fri, 3 Jun 2016 23:46:19 -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 anq4SOCHjDfz for ; Fri, 3 Jun 2016 23:46:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D699512B037 for ; Fri, 3 Jun 2016 23:46:16 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-ad-575279366eac Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.26.12516.63972575; Sat, 4 Jun 2016 08:46:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Sat, 4 Jun 2016 08:46:03 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 Thread-Index: AQHRtSvFlj02GsdUjEqN/h66uVwldJ/G2V+AgADkx4CAAGOpgIAAAaaAgAA66nD//+ymgIAAJPaQ///fdYCAABD5AIAABAeAgAAA6oCAAOs3gIABvEKAgAAif4CAACIs/oABJNaA///5JAAABOE4L///6iUAgAA3FYCAAAZ+gIAAKGoAgAAEbAD//8AqMIAAZnKAgAQpdQCAADi0gIAATZ/d///gtwD//9XcMAA44hMAAAFoUAAAA00LgAAfI/kAAG9zG4AAAZXCAP/+9zIA Date: Sat, 4 Jun 2016 06:46:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38035509@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37FF3B58@ESESSMB209.ericsson.se> <2a554789-0668-74f0-4bb4-e2908daa5e91@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37FF4E53@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FBC2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FC74@ESESSMB209.ericsson.se> <2a5ebdc5-20c6-8a55-c6fd-f18957f2c4e4@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38035509ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7n655ZVC4QfdPDoupyx+zWKzYcIDV YsaFqcwOzB5/339g8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZPUv7mAs2xFacbFjB2sD4 IqqLkZNDQsBE4tL7AywQtpjEhXvr2UBsIYEjjBLPdgR2MXIB2YsZJY6sWQpUxMHBJmAh0f1P G6RGREBV4u/3yUwgNrOAr8TLBV+YQWxhAXuJjU/uMEHUOEjsfHuVBWSOiMAiJokrvQvYQRIs AioSbzacZQWxeYGa//RuYYVY/JtT4vdGDRCbUyBQ4viH62DHMQId9/3UGqhl4hK3nsxngjha QGLJnvPMELaoxMvH/1ghbCWJRbc/Q9XnS7w9upgRYpegxMmZT1gmMIrOQjJqFpKyWUjKZgG9 zCygKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZs YgTG38Etv3V3MK5+7XiIUYCDUYmH98HfwHAh1sSy4srcQ4wSHMxKIrx7i4PChXhTEiurUovy 44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBKNTDKzZlu9fScuIRTwO9jvVE6 9+vuv1/ZNiH/Z0Z+/5/3SxNKd3PX7PiVrLhj/crjk54ue7Z6Iee2GqGDLQ+++Vx7Fvn2vWf7 E/lYR9ei4l3zpllpfLZsU2y9Huu52Lh/vmzhoZfLjs7InF46Z0GTMFPv7bK1CfmdupfTK2+f q1LM8t/tsfvR4sQ3SizFGYmGWsxFxYkASqRBgLsCAAA= Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 06:46:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38035509ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHdlIGRvbuKAmXQgdGFsayBhYm91dCBvZmZlcnMgYW5kIGFuc3dlcnMgZWxzZXdo ZXJlIGluIHRoZSBkb2N1bWVudCwgSSBtb2RpZmllZCB0aGUgdGV4dCBhIGJpdDoNCg0KICAgIOKA nFdoZW4gYW4gZW5kcG9pbnQgcmVjZWl2ZXMgb25lIG9yIG1vcmUgZmluZ2VycHJpbnRzIGZyb20g aXRzIHBlZXIsDQogICAgYW5kIGlzIGFib3V0IHRvIGNhbGN1bGF0ZSBpdHMgb3duIGZpbmdlcnBy aW50cywgdW5sZXNzDQogICAgdGhlIGVuZHBvaW50IGhhcyBvdGhlciB3YXlzIG9mIGtub3dpbmcg d2hhdCBoYXNoIGZ1bmN0aW9ucyB0aGUgcGVlcg0KICAgIHN1cHBvcnRzIHRoZSBlbmRwb2ludCBN VVNUIGNhbGN1bGF0ZSBhdCBsZWFzdCBvbmUgZmluZ2VycHJpbnQgdXNpbmcNCiAgICBhIGhhc2gg ZnVuY3Rpb24gdGhhdCB3YXMgYWxzbyB1c2VkIGJ5IHRoZSBwZWVyIHRvIGNhbGN1bGF0ZSBhDQog ICAgZmluZ2VycHJpbnQuIEluIGFkZGl0aW9uLCB0aGUgZW5kcG9pbnQgTUFZIGNhbGN1bGF0ZSBm aW5nZXJwcmludHMNCiAgICB1c2luZyBoYXNoIGZ1bmN0aW9ucyB0aGF0IHdlcmUgbm90IHVzZWQg YnkgdGhlIHBlZXIu4oCdDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNo cG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDAzIEp1bmUgMjAxNiAxOTo1 OA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ DQpDYzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBtbXVzaWNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBXR0xDIGZvciBkcmFmdC1pZXRmLW1tdXNpYy00NTcy LXVwZGF0ZS0wMw0KDQoNCk9uIEZyaSwgSnVuIDMsIDIwMTYgYXQgOTowOSBBTSwgQ2hyaXN0ZXIg SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQrigJxVbmxlc3MgdGhlIGFuc3dlcmVyIGhh cyBvdGhlciB3YXlzIG9mIGtub3dpbmcgd2hhdCBoYXNoIGZ1bmN0aW9ucyB0aGUgb2ZmZXJlciBz dXBwb3J0IHRoZSBhbnN3ZXJlciBNVVNUIGNhbGN1bGF0ZSwgYW5kIGluY2x1ZGUgaW4gdGhlIGFu c3dlciwgYXQgbGVhc3Qgb25lIGZpbmdlcnByaW50IHVzaW5nIGEgaGFzaCBmdW5jdGlvbiB0aGF0 IHdlcmUgdXNlZCBmb3IgY2FsY3VsYXRpbmcgYSBmaW5nZXJwcmludCBpbiB0aGUgYXNzb2NpYXRl ZCBvZmZlci4gSW4gYWRkaXRpb24sIHRoZSBhbnN3ZXJlciBNQVkgY2FsY3VsYXRlIGFuZCBpbmNs dWRlIGZpbmdlcnByaW50cyB1c2luZyBoYXNoIGZ1bmN0aW9ucyB0aGF0IHdlcmUgbm90IHVzZWQg dG8gY2FsY3VsYXRlIGZpbmdlcnByaW50cyBpbiB0aGUgb2ZmZXIu4oCdDQoNCg0KTEdUTQ0KX19f X19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B38035509ESESSMB209erics_ 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 LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFzIHdlIGRvbuKAmXQgdGFsayBhYm91dCBvZmZlcnMg YW5kIGFuc3dlcnMgZWxzZXdoZXJlIGluIHRoZSBkb2N1bWVudCwgSSBtb2RpZmllZCB0aGUgdGV4 dCBhIGJpdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyDigJxXaGVuIGFuIGVuZHBvaW50IHJlY2VpdmVzIG9uZSBvciBtb3JlIGZpbmdl cnByaW50cyBmcm9tIGl0cyBwZWVyLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBpcyBhYm91dCB0byBjYWxj dWxhdGUgaXRzIG93biBmaW5nZXJwcmludHMsIHVubGVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGVuZHBvaW50IGhh cyBvdGhlciB3YXlzIG9mIGtub3dpbmcgd2hhdCBoYXNoIGZ1bmN0aW9ucyB0aGUgcGVlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDsgc3VwcG9ydHMgdGhlIGVuZHBvaW50IE1VU1QgY2FsY3VsYXRlIGF0IGxlYXN0IG9uZSBmaW5n ZXJwcmludCB1c2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYSBoYXNoIGZ1bmN0aW9uIHRoYXQgd2FzIGFsc28gdXNlZCBi eSB0aGUgcGVlciB0byBjYWxjdWxhdGUgYQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ZpbmdlcnByaW50LiBJbiBh ZGRpdGlvbiwgdGhlIGVuZHBvaW50IE1BWSBjYWxjdWxhdGUgZmluZ2VycHJpbnRzDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dXNpbmcgaGFzaCBmdW5jdGlvbnMgdGhhdCB3ZXJlIG5vdCB1c2VkIGJ5IHRoZSBwZWVy LuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVy aXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDAzIEp1bmUgMjAxNiAxOTo1ODxicj4NCjxiPlRv OjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAYWx1bS5taXQu ZWR1Jmd0OzsgbW11c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lD XSBXR0xDIGZvciBkcmFmdC1pZXRmLW1tdXNpYy00NTcyLXVwZGF0ZS0wMzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBGcmksIEp1biAzLCAyMDE2IGF0IDk6MDkgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKAnFVubGVzcyB0aGUgYW5zd2VyZXIgaGFzIG90 aGVyIHdheXMgb2Yga25vd2luZyB3aGF0IGhhc2ggZnVuY3Rpb25zIHRoZSBvZmZlcmVyIHN1cHBv cnQgdGhlIGFuc3dlcmVyIE1VU1QgY2FsY3VsYXRlLCBhbmQgaW5jbHVkZSBpbiB0aGUgYW5zd2Vy LCBhdCBsZWFzdCBvbmUgZmluZ2VycHJpbnQNCiB1c2luZyBhIGhhc2ggZnVuY3Rpb24gdGhhdCB3 ZXJlIHVzZWQgZm9yIGNhbGN1bGF0aW5nIGEgZmluZ2VycHJpbnQgaW4gdGhlIGFzc29jaWF0ZWQg b2ZmZXIuIEluIGFkZGl0aW9uLCB0aGUgYW5zd2VyZXIgTUFZIGNhbGN1bGF0ZSBhbmQgaW5jbHVk ZSBmaW5nZXJwcmludHMgdXNpbmcgaGFzaCBmdW5jdGlvbnMgdGhhdCB3ZXJlIG5vdCB1c2VkIHRv IGNhbGN1bGF0ZSBmaW5nZXJwcmludHMgaW4gdGhlIG9mZmVyLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxHVE08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_7594FB04B1934943A5C02806D1A2204B38035509ESESSMB209erics_-- From nobody Fri Jun 3 23:59:48 2016 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 ADF4712D0BD for ; Fri, 3 Jun 2016 23:59:47 -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 d2dIxFY6gi3N for ; Fri, 3 Jun 2016 23:59:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7E412B069 for ; Fri, 3 Jun 2016 23:59:44 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-cd-57527c5ec659 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DD.9D.18043.E5C72575; Sat, 4 Jun 2016 08:59:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0294.000; Sat, 4 Jun 2016 08:59:42 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 Thread-Index: AQHRtSvFlj02GsdUjEqN/h66uVwldJ/G2V+AgADkx4CAAGOpgIAAAaaAgAA66nD//+ymgIAAJPaQ///fdYCAABD5AIAABAeAgAAA6oCAAOs3gIABvEKAgAAif4CAACIs/oABJNaA///5JAAABOE4L///6iUAgAA3FYCAAAZ+gIAAKGoAgAAEbAD//8AqMIAAZnKAgAQpdQCAADi0gIAATZ/d///gtwD//9XcMAA44hMAAAFoUAAAA00LgAAfI/kAAG9zG4AAAZXCAP/+9zIA//3qsxA= Date: Sat, 4 Jun 2016 06:59:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38035555@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37FF3B58@ESESSMB209.ericsson.se> <2a554789-0668-74f0-4bb4-e2908daa5e91@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37FF4E53@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FBC2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3801FC74@ESESSMB209.ericsson.se> <2a5ebdc5-20c6-8a55-c6fd-f18957f2c4e4@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B38035509@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38035509@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38035555ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7t258TVC4QdM0Toupyx+zWKzYcIDV YsaFqcwOzB5/339g8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZt3tfMBXc6mCs+Pn3K2MD Y0srYxcjB4eEgIlE70WtLkZOIFNM4sK99WxdjFwcQgJHGCV+/XkA5SxmlHiy7BcbSAObgIVE 9z9tkAYRAVWJv98nM4HYzAK+Eu9/TmcHsYUF7CU2PrnDBFHjILHz7VUWCHsVk8SWj64gY1gE VCQenk4CCfMCtb6585QFYtV+Lommc3uYQRKcAn4SEx8+AJvJCHTc91NroHaJS9x6Mp8J4mgB iSV7zjND2KISLx//Y4WwlSQW3f4MVZ8vMfHwGzaIZYISJ2c+YZnAKDoLyahZSMpmISmbBXQq s4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJ ERiBB7f8ttrBePC54yFGAQ5GJR7eB38Dw4VYE8uKK3MPMUpwMCuJ8JZUBIUL8aYkVlalFuXH F5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYJyhwChpyz31ZoT3pJc74tY6 Gl/4k8fm2sJzLvzgJe1njxe/czswud7t9oRLoknX62PstE6+uyz7bM2Xip8fV7NzR3kJ1qWu /s8f2133/GuR5B4PQ4GMs9vZnlp8mXps6myDxsuSR/TOWGqsy1E3qXjSpq6ZsdJ8Z4asxNlv FZP1z7juNoqvvqvEUpyRaKjFXFScCAB6BegQvAIAAA== Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-4572-update-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 06:59:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38035555ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNoYW5nZSBpbiBnaXRodWI6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC00 NTcyLXVwZGF0ZS90cmVlL3NkcC1hbnN3ZXItY2xhcmlmaWNhdGlvbg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMDQgSnVuZSAyMDE2IDA5 OjQ2DQpUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+DQpDYzogbW11c2ljQGll dGYub3JnOyBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4NClN1YmplY3Q6IFJl OiBbTU1VU0lDXSBXR0xDIGZvciBkcmFmdC1pZXRmLW1tdXNpYy00NTcyLXVwZGF0ZS0wMw0KDQpI aSwNCg0KQXMgd2UgZG9u4oCZdCB0YWxrIGFib3V0IG9mZmVycyBhbmQgYW5zd2VycyBlbHNld2hl cmUgaW4gdGhlIGRvY3VtZW50LCBJIG1vZGlmaWVkIHRoZSB0ZXh0IGEgYml0Og0KDQogICAg4oCc V2hlbiBhbiBlbmRwb2ludCByZWNlaXZlcyBvbmUgb3IgbW9yZSBmaW5nZXJwcmludHMgZnJvbSBp dHMgcGVlciwNCiAgICBhbmQgaXMgYWJvdXQgdG8gY2FsY3VsYXRlIGl0cyBvd24gZmluZ2VycHJp bnRzLCB1bmxlc3MNCiAgICB0aGUgZW5kcG9pbnQgaGFzIG90aGVyIHdheXMgb2Yga25vd2luZyB3 aGF0IGhhc2ggZnVuY3Rpb25zIHRoZSBwZWVyDQogICAgc3VwcG9ydHMgdGhlIGVuZHBvaW50IE1V U1QgY2FsY3VsYXRlIGF0IGxlYXN0IG9uZSBmaW5nZXJwcmludCB1c2luZw0KICAgIGEgaGFzaCBm dW5jdGlvbiB0aGF0IHdhcyBhbHNvIHVzZWQgYnkgdGhlIHBlZXIgdG8gY2FsY3VsYXRlIGENCiAg ICBmaW5nZXJwcmludC4gSW4gYWRkaXRpb24sIHRoZSBlbmRwb2ludCBNQVkgY2FsY3VsYXRlIGZp bmdlcnByaW50cw0KICAgIHVzaW5nIGhhc2ggZnVuY3Rpb25zIHRoYXQgd2VyZSBub3QgdXNlZCBi eSB0aGUgcGVlci7igJ0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hw b3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMDMgSnVuZSAyMDE2IDE5OjU4 DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiBQYXVsIEt5eml2YXQg PHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj47IG1t dXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVT SUNdIFdHTEMgZm9yIGRyYWZ0LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLTAzDQoNCg0KT24gRnJp LCBKdW4gMywgMjAxNiBhdCA5OjA5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ PiB3cm90ZToNCuKAnFVubGVzcyB0aGUgYW5zd2VyZXIgaGFzIG90aGVyIHdheXMgb2Yga25vd2lu ZyB3aGF0IGhhc2ggZnVuY3Rpb25zIHRoZSBvZmZlcmVyIHN1cHBvcnQgdGhlIGFuc3dlcmVyIE1V U1QgY2FsY3VsYXRlLCBhbmQgaW5jbHVkZSBpbiB0aGUgYW5zd2VyLCBhdCBsZWFzdCBvbmUgZmlu Z2VycHJpbnQgdXNpbmcgYSBoYXNoIGZ1bmN0aW9uIHRoYXQgd2VyZSB1c2VkIGZvciBjYWxjdWxh dGluZyBhIGZpbmdlcnByaW50IGluIHRoZSBhc3NvY2lhdGVkIG9mZmVyLiBJbiBhZGRpdGlvbiwg dGhlIGFuc3dlcmVyIE1BWSBjYWxjdWxhdGUgYW5kIGluY2x1ZGUgZmluZ2VycHJpbnRzIHVzaW5n IGhhc2ggZnVuY3Rpb25zIHRoYXQgd2VyZSBub3QgdXNlZCB0byBjYWxjdWxhdGUgZmluZ2VycHJp bnRzIGluIHRoZSBvZmZlci7igJ0NCg0KDQpMR1RNDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBv dW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B38035555ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGNoYW5nZSBpbiBnaXRodWI6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczov L2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtNDU3Mi11cGRhdGUvdHJlZS9zZHAtYW5zd2VyLWNsYXJp ZmljYXRpb24iPmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC00NTcyLXVwZGF0ZS90cmVl L3NkcC1hbnN3ZXItY2xhcmlmaWNhdGlvbjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiAw NCBKdW5lIDIwMTYgMDk6NDY8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFuIFNocG91bnQgJmx0O3JvbWFu QHRlbHVyaXguY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbW11c2ljQGlldGYub3JnOyBQYXVsIEt5 eml2YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtNTVVTSUNdIFdHTEMgZm9yIGRyYWZ0LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLTAzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXMgd2UgZG9u4oCZdCB0YWxrIGFib3V0 IG9mZmVycyBhbmQgYW5zd2VycyBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50LCBJIG1vZGlmaWVk IHRoZSB0ZXh0IGEgYml0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnFdoZW4gYW4gZW5kcG9pbnQgcmVjZWl2ZXMgb25lIG9yIG1v cmUgZmluZ2VycHJpbnRzIGZyb20gaXRzIHBlZXIsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIGlzIGFib3V0 IHRvIGNhbGN1bGF0ZSBpdHMgb3duIGZpbmdlcnByaW50cywgdW5sZXNzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZW5k cG9pbnQgaGFzIG90aGVyIHdheXMgb2Yga25vd2luZyB3aGF0IGhhc2ggZnVuY3Rpb25zIHRoZSBw ZWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyBzdXBwb3J0cyB0aGUgZW5kcG9pbnQgTVVTVCBjYWxjdWxhdGUgYXQgbGVhc3Qg b25lIGZpbmdlcnByaW50IHVzaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBhIGhhc2ggZnVuY3Rpb24gdGhhdCB3YXMgYWxz byB1c2VkIGJ5IHRoZSBwZWVyIHRvIGNhbGN1bGF0ZSBhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZmluZ2VycHJp bnQuIEluIGFkZGl0aW9uLCB0aGUgZW5kcG9pbnQgTUFZIGNhbGN1bGF0ZSBmaW5nZXJwcmludHMN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt1c2luZyBoYXNoIGZ1bmN0aW9ucyB0aGF0IHdlcmUgbm90IHVzZWQgYnkg dGhlIHBlZXIu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBSb21hbiBTaHBvdW50IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29t Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYWlsdG86cm9tYW5AdGVsdXJpeC5jb208 L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiAwMyBKdW5lIDIwMTYgMTk6NTg8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJn ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBQYXVsIEt5eml2YXQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGt5eml2 YXRAYWx1bS5taXQuZWR1Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5wa3l6aXZhdEBh bHVtLm1pdC5lZHU8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7 DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIFdHTEMgZm9y IGRyYWZ0LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLTAzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVu IDMsIDIwMTYgYXQgOTowOSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKA nFVubGVzcyB0aGUgYW5zd2VyZXIgaGFzIG90aGVyIHdheXMgb2Yga25vd2luZyB3aGF0IGhhc2gg ZnVuY3Rpb25zIHRoZSBvZmZlcmVyIHN1cHBvcnQgdGhlIGFuc3dlcmVyIE1VU1QgY2FsY3VsYXRl LCBhbmQgaW5jbHVkZSBpbiB0aGUgYW5zd2VyLCBhdCBsZWFzdCBvbmUgZmluZ2VycHJpbnQNCiB1 c2luZyBhIGhhc2ggZnVuY3Rpb24gdGhhdCB3ZXJlIHVzZWQgZm9yIGNhbGN1bGF0aW5nIGEgZmlu Z2VycHJpbnQgaW4gdGhlIGFzc29jaWF0ZWQgb2ZmZXIuIEluIGFkZGl0aW9uLCB0aGUgYW5zd2Vy ZXIgTUFZIGNhbGN1bGF0ZSBhbmQgaW5jbHVkZSBmaW5nZXJwcmludHMgdXNpbmcgaGFzaCBmdW5j dGlvbnMgdGhhdCB3ZXJlIG5vdCB1c2VkIHRvIGNhbGN1bGF0ZSBmaW5nZXJwcmludHMgaW4gdGhl IG9mZmVyLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxHVE08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3Vu dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B38035555ESESSMB209erics_-- From nobody Mon Jun 6 06:54:11 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2EE12D7AF; Mon, 6 Jun 2016 06:54:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606135408.20826.87432.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 06:54:08 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 13:54: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 : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-14.txt Pages : 17 Date : 2016-06-06 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-msid-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 6 07:17:35 2016 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 40FFD12D7D0 for ; Mon, 6 Jun 2016 07:17:34 -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=brianrosen-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 QdjJp2RsaT2X for ; Mon, 6 Jun 2016 07:17:32 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 F28A112D7AE for ; Mon, 6 Jun 2016 07:17:29 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id u63so7604579qkh.0 for ; Mon, 06 Jun 2016 07:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6nU2eUnoMgclh787gfpq9xicjSu0WzNqosrVU10TgBY=; b=cph5mLeHRSnobtH4vRN+pLqeJfiWWh7KlzRq5uzva6/vAWoacdag8CzINOqFyALSRu V9TOSAMF4kCTHegMUKQ2vv25xdBcWqytK988pj6Ze/l/iIeX5tD9p3SVl02P9I8jiD8F bXVohB4aWg0L/Fx3pRf8dG10kSJ5bn89t28Wq6gsfZJniY5lvBgW5iDo5Wi0zuOKnNEf jNKtAAISK759z1XVl89aBaAAMekXRX1wB3cXL3Y922AJrj/kYNYOPD5me/Xu2aZhaACw WVQyWipm8xREBxTynl3MHvqG35RMEN2FeMxadO+NSngcVx378MOh9PDN6Gg5wGOJ9S41 rkcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6nU2eUnoMgclh787gfpq9xicjSu0WzNqosrVU10TgBY=; b=jm/JhQPh7jatHNqu0DodlO6qOEySbp2uUSI80Czqbk7uFxO1ZPtRzt/jIDI8v7nnnG v1RGbZMSVU3kvqBzbQA+qEowEjhn8E4SF3DHzGgUd48KI31qpb6DxX3tUoguLVfWHIzK nNI0MoprGnPUvzosfHm52kC4jJzNVBz65MTaBO+U+ehWFRYfFXrdN/P35rSR/8PguuPM lLua6TEKFpk+BtpHVFwxm7LfN5+IdlVNil2vz14dtHjdBAdAzNsIgE/oqMhw4adGe/cD 4JPvGq0bS8/IiW+XDBL0zfaKWFtf2bgo4uISUaT0Ylt/6W1e1Ahl6cnnaGDUNIPHpAU3 UViA== X-Gm-Message-State: ALyK8tJ38OKocDtv18cZ2DWJP4etkwQBJ9jyUlRp51U9h9ytrZC+ZYTI+HsKA5Y8GjPXLw== X-Received: by 10.55.113.197 with SMTP id m188mr15213866qkc.90.1465222649061; Mon, 06 Jun 2016 07:17:29 -0700 (PDT) Received: from [10.33.192.47] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id l64sm3139627qgd.35.2016.06.06.07.17.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Jun 2016 07:17:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <4b988588-1de4-c65d-6182-8525dfc87b76@nostrum.com> Date: Mon, 6 Jun 2016 10:17:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8BADF0EEC3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <75a6d14f-1322-7ebc-0c79-6a38c623becd@nostrum.com> <2a8cf5ef-396e-2300-6f86-7eb37764ec0d@nostrum.com> <4b988588-1de4-c65d-6182-8525dfc87b76@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" , "Drage, Keith \(Nokia - GB\)" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 14:17:34 -0000 Clearly, I agree with Adam. I want the IANA code point restored to what it=E2=80=99s being used for = in the field. I also don=E2=80=99t want to write a new document that references an old = document, and explain that the reason I=E2=80=99m doing that is that a = mistake was made when they created the new document. If I was doing this in the IETF, that would not be allowed; whatever = document I was creating would have to have instructions to IANA to = restore the code point. Since 4733 says that new entries in the registry are =E2=80=9CSpecificatio= n Required=E2=80=9D and =E2=80=9CExpert Review=E2=80=9D, I don=E2=80=99t = need a standards track document. Instead, suppose I create a short = Informational document that states that it was probably a mistake to = drop it, that we=E2=80=99re instructing IANA to restore it, include just = enough technical detail to describe the 2833 functionality in the 4733 = document context, and state what the intention is (document existing use = so that we can reference 4733 and the informational rather than 2833). Brian > On Jun 3, 2016, at 2:50 PM, Adam Roach wrote: >=20 > On 6/3/16 13:36, Ted Hardie wrote: >> So that sounds like your answer is "The value of doing it is based on = a perceived ability of the requester to actually upgrade". Is that the = difference between this apple and that bulldozer? >=20 >=20 > Well, I'm also making a "public benefit" argument (with both = characteristics being necessary and neither sufficient for the = distinction), but you caught half of what I was saying. >=20 >=20 >> Writing a new standard that resurrects this in order to avoiding = referencing the older, deprecated standard seems to me to send the wrong = signal.=20 >=20 >=20 > Ironically, I think we are disagreeing not because we have different = goals, but because we have identical goals and different ideas about the = tactics most likely to achieve those goals. I'd like to see text = explicitly acknowledging that this usage will be seen in the field -- = and even described in nicely formatted quasi-governmental documents -- = and explaining why "you, dear reader," should not emulate it. >=20 >=20 >> If Brian would like to write an informational doc that describes = flash's continuing use in gateway systems, to help ensure no one squats = on the code point, I will cheer him on. >=20 >=20 > It's not what I would prefer (I'd actually like to see an IANA update = that points to a document that puts the proper scoping around how the = codepoint is being used and how it shouldn't be used), but it certainly = seems better than just throwing our hands in the air and telling Brian = to stuff it. >=20 >=20 > /a >=20 From nobody Tue Jun 7 00:34:02 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E66AE12B056; Tue, 7 Jun 2016 00:34:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607073400.13744.104.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 00:34:00 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 07:34:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Updates to RFC 4572 Author : Christer Holmberg Filename : draft-ietf-mmusic-4572-update-04.txt Pages : 7 Date : 2016-06-07 Abstract: This document updates RFC 4572 by clarifying the usage of multiple SDP 'fingerprint' attributes with a single TLS connection. The document also updates the preferred cipher suite with a stronger cipher suite, and removes the requirement to use the same hash function for calculating a certificate fingerprint that is used to calculate the certificate signature. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 00:35:33 2016 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 895A212D531; Tue, 7 Jun 2016 00:35:26 -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 nRqsKHP_2buZ; Tue, 7 Jun 2016 00:35:25 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE72512D1AF; Tue, 7 Jun 2016 00:35:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-78-5756793abc9a Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.27.18043.A3976575; Tue, 7 Jun 2016 09:35:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0294.000; Tue, 7 Jun 2016 09:35:21 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-4572-update-04 Thread-Index: AQHRwI8lmbpuUxozt0y5qDlNzfaz5g== Date: Tue, 7 Jun 2016 07:35:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D37C54A59F56christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7sa51ZVi4wZw3bBbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyVnzbz1RwnrPi585pjA2Mmzm6GDk5JARMJNYtfcwC YYtJXLi3nq2LkYtDSOAIo0R/SzM7hLOYUeJK42sgh4ODTcBCovufNkiDiIC6xNe9PcwgNrOA qcTDV2sYQWxhARuJyfeXMUPUOEo8mzwXytaTODP/OBuIzSKgIrG4s4kNZCSvgJXE0hNmIGFG oBu+n1rDBDFSXOLWk/lMELcJSCzZc54ZwhaVePn4HyuILQo08su9eYwgYyQElCSmbU2DaI2X WLdyD9hbvAKCEidnPmGZwCgyC8nUWUjKZiEpg4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNta ovFmExOymgWMHKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAiPs4JbfVjsYDz53PMQowMGo xMO7QCssXIg1say4MvcQowQHs5II77QioBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC 6YklqdmpqQWpRTBZJg5OqQZGnXlrYvhDj1vK3OE/sGbr6dUzdHhqDy7i2r/W7KSE39nZVl07 nnm5t9+1y2e11vNo/MiTEn5SovhTQIfFlz87rz9//l5YTmfTyzsql5+fONG983OFfN5TKYn1 ZrturMk9cfZ8eqKjWeT3hNe/nbcwba2cMiXBcl7VMZHfk8JKJ96SbWL5uK4kSomlOCPRUIu5 qDgRAOmSSXSsAgAA Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 07:35:26 -0000 --_000_D37C54A59F56christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on the WGLC comments, I=92ve submitted a new version (-04) of draft-i= etf-mmusic-4572-update. Thanks to everyone who provided input and comments! :) Regards, Christer --_000_D37C54A59F56christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1402D32E7164164599F5D959EC9968B8@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on the WGLC comments, I=92ve submitted a new version (-04) of&nb= sp;draft-ietf-mmusic-4572-update.

Thanks to everyone who provided input and comments! :)

Regards,

Christer
--_000_D37C54A59F56christerholmbergericssoncom_-- From nobody Tue Jun 7 06:40:09 2016 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 46CCF12D11D for ; Tue, 7 Jun 2016 06:40: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, 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=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 fs37cAiWF6pD for ; Tue, 7 Jun 2016 06:40:05 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 0932412D0DC for ; Tue, 7 Jun 2016 06:40:05 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id h62so25084391itb.1 for ; Tue, 07 Jun 2016 06:40:04 -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=ApVNHi0NOFJKG5aRhehvrhaQf/wbYb3u6rqI+/onSUA=; b=2IkyPD0WD1MMswDhziJ/3E2fOPKDUOM2nRQ7VoVm61VVzt7sEZlelSLSgh25SD5T/D 9MbDI+mlEV2PLEaBmSfe9ZwXd/w89DB4v+XPczdPuizsrQuIPl0nQu7jBWQ9hgjYKi6g p7DG2jhc5zTE7aWOLrXMK7DnSRAqryF6t/Nuq328O76M0JZskvQqKCSosacXr/4ZPUlg /1/fXYfUeUqQRTkw9onUMdo+XnV/gBTxp4S9WfT0nme6UUrinhiy8JO+Js72ZZ3qvz6t XtjZ3MqwvzZiRmz/PDs/XX83o5xTsYpItl0WgsPfrwarup09AoN65WD4pOqXAhLvh9/U pKmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ApVNHi0NOFJKG5aRhehvrhaQf/wbYb3u6rqI+/onSUA=; b=HuvohD3zJpbcicVU6no0RyiB8i9FYRF3S++BUJVg6S23ltCj76M0jsIx++19S2GHHF /KwBlnfIBI6byVhC7azbO07UUleRbjIPoieie34VNIVNqRt+PovqQVwYgfkYUsZLkaYk vfGJ6zplQxmQ/ciiGZM1ZX8llnUlHfV3r6vgcp/jjGvXcempyFayY1yKnHQmo/XK+J5A p4Zp619km37GEzvDRPQrTDEqw16+GPD9QVyCC1Wp4FDNl044Q7jb6vi/2gpZxgSvpWPg AvZZdgdRXwsEeqszJW45ifIF3U1+JiUIe34NpePcf9y5SUbY1f4pRuceA59PzPZ2SYNC ApDw== X-Gm-Message-State: ALyK8tKdW+8cS2f0rDE0qnWC/L50mCSwqsTnWWLh8Czeq5U8NNRceDkv2zJftWzYb3Jelw== X-Received: by 10.107.31.74 with SMTP id f71mr2133461iof.180.1465306804155; Tue, 07 Jun 2016 06:40:04 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id f199sm8638322ita.17.2016.06.07.06.40.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 06:40:03 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id h62so25083165itb.1; Tue, 07 Jun 2016 06:40:03 -0700 (PDT) X-Received: by 10.36.71.8 with SMTP id t8mr4101206itb.47.1465306802824; Tue, 07 Jun 2016 06:40:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Tue, 7 Jun 2016 06:40:02 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Tue, 7 Jun 2016 09:40:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113f609c7868100534b053ee Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 13:40:08 -0000 --001a113f609c7868100534b053ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks good to me. _____________ Roman Shpount On Tue, Jun 7, 2016 at 3:35 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Based on the WGLC comments, I=E2=80=99ve submitted a new version (-04) > of draft-ietf-mmusic-4572-update. > > Thanks to everyone who provided input and comments! :) > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a113f609c7868100534b053ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good to me.

_____________
Roman Shpount

On Tue, Jun 7, 2016 at 3:35 AM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:
Hi,

Based on the WGLC comments, I=E2=80=99ve submitted a new version (-04)= of=C2=A0draft-ietf-mmusic-4572-update.

Thanks to everyone who provided input and comments! :)

Regards,

Christer

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


--001a113f609c7868100534b053ee-- From nobody Tue Jun 7 06:51:13 2016 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 D359B12B058; Tue, 7 Jun 2016 06:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 DFAdRxCCTn_g; Tue, 7 Jun 2016 06:51:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B34512D0DC; Tue, 7 Jun 2016 06:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=693; q=dns/txt; s=iport; t=1465307470; x=1466517070; h=from:subject:to:cc:message-id:date:mime-version: content-transfer-encoding; bh=oXL3iZy27VQTfuk30OT3g8WbvCmSvhLqg3BA65E/ahU=; b=hLvabWHFb7uwCWndWztxDOTT/Llm2ZZktcjNQfW6cb3OAy2YbnhPb7r6 HMuX7/Py6QWWxNXiw5HhpdDvLG/i9JqNz7qL4dNaLjP669AJnrRMf8NCR E0ZKAkAPrA5JNx6kZbeNhJ8/cJ1BfQMgNFrCr+CwgMBoLRZiluDyTl0bS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXBQCn0FZX/51dJa1dgz1WK1K4WYQII?= =?us-ascii?q?oVxgTw7EQEBAQEBAQFlJ4RvFUE1AiYCXw0IAQGIKw6qc5E0AQEBAQEBBAEBAQE?= =?us-ascii?q?BARwFgQGFJoF3iheCWQEEmEuOJ4FUFoRSgwmFW49fNCCECiAyAYoOAQEB?= X-IronPort-AV: E=Sophos;i="5.26,433,1459814400"; d="scan'208";a="110685524" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 13:51:09 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u57Dp9sM005192; Tue, 7 Jun 2016 13:51:09 GMT From: Flemming Andreasen To: mmusic Message-ID: <0e2be118-9e2c-95f2-f9a3-29968590af4b@cisco.com> Date: Tue, 7 Jun 2016 09:51:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-dtls-sdp@ietf.org Subject: [MMUSIC] WGLC for draft-ietf-mmusic-dtls-sdp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 13:51:12 -0000 Greetings MMUSIC This is to announce a 2 week WGLC on https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-13.txt as Proposed Standard. Please note that we previously issued a WGLC on the -06 version (in February), however since there has been a few changes to the document subsequently, we want to give people a chance to review those one last time. Please take a look at the document and provide any comments you may have by Tuesday, June 21, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Tue Jun 7 08:36:28 2016 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 05FB312D77D for ; Tue, 7 Jun 2016 08:36:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 RUKtAhCFPdY2 for ; Tue, 7 Jun 2016 08:36:25 -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 2CA2212D770 for ; Tue, 7 Jun 2016 08:36:24 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-02v.sys.comcast.net with SMTP id AJ16bXfM4QRyhAJ3IbEFZv; Tue, 07 Jun 2016 15:36:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465313784; bh=2OEVpsb/HnyI2b439TZOvQkoRaZubOg9PjNU/R5Cp5s=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=X0ZXi0EIsZo8G1P7rwpCfOUI9XpKOtMk+hwYo1oDyhIiUOQ+M7c9+/UNFz14nlE2P D4mKmliApa0L9feSHoSFib23aDzg7WvNc+7XfkVXo1EOhF760g95XMN1n8pDzfCW5s s9YPdkIH4CWX2lac8xs6qoj3bbe/TH6c0AoSGN0+uRYNB9h5UmwL7qrcPogziFPmPW tJ/7+wkDo8nAF5mcBSamB8vYPnvJ39FGa0me6qeVjAMNM9zqPBi2Abqp/U2L9+kKF8 3odltmLTv4CiaQJmqHYlypHbGL3+N3kkhffBPEs++d6nWOzWVmq1/SdpaWPIsV03Y9 hNCeqFxXCHbqA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id 3rcP1t00M1nMCLR01rcPqg; Tue, 07 Jun 2016 15:36:24 +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 u57FaM7v016133; Tue, 7 Jun 2016 11:36:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u57FaMMB016130; Tue, 7 Jun 2016 11:36:22 -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: Brian Rosen In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 07 Jun 2016 11:36:22 -0400 Message-ID: <87fusp80zt.fsf@hobgoblin.ariadne.com> Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 15:36:27 -0000 Brian Rosen writes: > Instead, suppose I create a short Informational document that states > that it was probably a mistake to drop it, that we're instructing IANA > to restore it, include just enough technical detail to describe the > 2833 functionality in the 4733 document context, and state what the > intention is (document existing use so that we can reference 4733 and > the informational rather than 2833). That makes sense to me. Dale From nobody Tue Jun 7 12:16:39 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AE612D504; Tue, 7 Jun 2016 12:16:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607191637.13712.7635.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 12:16:37 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-30.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:16:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-30.txt Pages : 53 Date : 2016-06-07 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-30 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 7 12:18:48 2016 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 60B5712D504; Tue, 7 Jun 2016 12:18: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 98XiaY0fOif3; Tue, 7 Jun 2016 12:18:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52FA12D681; Tue, 7 Jun 2016 12:18:43 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-01-57571e12155f Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.07.27088.21E17575; Tue, 7 Jun 2016 21:18:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Tue, 7 Jun 2016 21:18:30 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-30 Thread-Index: AdHA8UWDKXpc+/xlR8qy/jTUyc+bPA== Date: Tue, 7 Jun 2016 19:18:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38040629@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38040629ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdTFdILjzcYO8qQYvzO9czWUxd/pjF gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZN9euYCr4K1JxZM0LpgbGi0JdjJwcEgImEg3rXrND 2GISF+6tZ+ti5OIQEjjCKHGn5x5YQkhgMaPE++2CXYwcHGwCFhLd/7RBwiIC6hJf9/Ywg9jM AqYSD1+tYQQpERZwl1h0uwCixEfi3+o7rBC2nkTvoVlMICUsAioSTROCQMK8Ar4SHy7/ZgKx GYEu+H5qDRPERHGJW0/mM0FcJiCxZM95ZghbVOLl43+sELaSROOSJ6wQ9fkSa09/ZYaYKShx cuYTlgmMwrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLU4KTfd yEgvtSgzubg4P08vL7VkEyMwXg5u+W2wg/Hlc8dDjAIcjEo8vAu0wsKFWBPLiitzDzFKcDAr ifDelAoPF+JNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cCo +uDw/n+TxW8XW/Pl1kdm7btm/Ljw57UTAYu9KrfVPE/S+h/+5PWuU3t9P+X+iLvB7yKUOiOt ef7ftDkL2s99Ek0Wm8Y5K2++1na5/zGNks9DnP7se7cqZWaJyYv/p1ZsVp4bk/fKq+/em/Nt NxUsAr59vZd1VFZxQoCM2eJtB9YaOsptsz7fpsRSnJFoqMVcVJwIAKoNZA2TAgAA Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-30 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:18:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38040629ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments from the I-lost-count:th WGLC, I have submitted a new= version (-30) of draft-bundle. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B38040629ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the comments from the I-lost-count:th WGLC,= I have submitted a new version (-30) of draft-bundle.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B38040629ESESSMB209erics_-- From nobody Tue Jun 7 19:39:09 2016 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 6470112D998; Tue, 7 Jun 2016 19:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 32QETfREwsqH; Tue, 7 Jun 2016 19:39:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA8212D980; Tue, 7 Jun 2016 19:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10014; q=dns/txt; s=iport; t=1465353542; x=1466563142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FoKuRjUk1m/Xg8UdELCAFbVM4sFHmquSju+SiiJmjdQ=; b=hIz+cjH49iLsMOQGUF1DDrFOVYykRD1fsqbYmlgNOeruO9YqzRTH9QKZ C9g5cqINQfFK2r0/IIfiNO9Cn90nA6KPeuiCIA10KbDLnzca3516Wxno8 6kjxKrDtleFCGTGpVMSH8FkvAYVx0ghP8dr1pBAm6gdrDhoZPJ4QbAsSs E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AgAvhFdX/4cNJK1dgz5WfQavCIt9g?= =?us-ascii?q?XkXC4UnSgIcgSg4FAEBAQEBAQFlJ4RFAQEBAwEBAQEgBA06CwULAgEIGAICHwc?= =?us-ascii?q?CAgIfBgsVEAIEAQ0FFIgBAw8IDqtqjRENhAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEXBYEBhSaBd4JWgkOBfReCaiuCLgWIBpARNAGMK4F6gWmEUoMshTiGPYE2h2s?= =?us-ascii?q?BHjaCBgEcFoE1bgGJD38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,436,1459814400"; d="scan'208";a="112707653" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jun 2016 02:39:00 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u582d0i6014237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jun 2016 02:39:00 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 7 Jun 2016 21:38:59 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Tue, 7 Jun 2016 21:38:59 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: mmusic WG , "avt@ietf.org WG" Thread-Topic: [MMUSIC] [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes Thread-Index: AQHRthL8VuJ5x/fyEE6AYexF7eizHZ/KQAMAgAAFTwCAACwxAIAABhuAgABl14CAAAEuAIAUZtkA Date: Wed, 8 Jun 2016 02:38:59 +0000 Message-ID: References: <5745E2F4.8040206@petit-huguenin.org> <9759123A-B014-41AC-95B8-720C50BC9E57@nostrum.com> <80563BED-ADDE-4C2B-8B4E-DF1C8F3E3FA5@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.94.80] Content-Type: text/plain; charset="utf-8" Content-ID: <0FBCE471B0893F489BDCA6DFD5379255@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , Marc Petit-Huguenin , Alan Johnston , "draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org" , "draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org" Subject: Re: [MMUSIC] [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 02:39:04 -0000 SGkgQVZUICYgTU1VU0lDIC0gDQoNCkkgaGF2ZW7igJl0IGhlYXJkIGFueSBvdGhlciBvcGluaW9u cyBvbiB0aGlzLCBzbyBJ4oCZbGwgYXNzdW1lIG1ha2luZyB0aGUgY2hhbmdlIHQgdGhlIGRyYWZ0 IGlzIE9LLiAgUGxlYXNlIGluZGljYXRlIGFueSBvYmplY3Rpb24gb3ZlciB0aGUgbmV4dCBmZXcg ZGF5cyBvciB3ZSB3aWxsIHByb2NlZWQgd2l0aCB0aGUgdXBkYXRlIHRvIG11eC1maXguDQoNClRo YW5rcywgDQoNCkdvbnphbG8NCg0KDQoNCj4gT24gTWF5IDI1LCAyMDE2LCBhdCAxMTowNSBQTSwg R29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVpKSA8Z3NhbGd1ZWlAY2lzY28uY29tPiB3cm90ZToN Cj4gDQo+IE9LLCBjb29sICBUaGFua3MsIEFsYW4uICBPbmNlIHdlIGdldCBjb25zZW5zdXMgZnJv bSB0aGUgV0cocykgdGhhdCB0aGlzIGlzIHRoZSBiZXN0IHdheSBmb3J3YXJkIHdlIHdpbGwgbWFr ZSB0aGlzIGNoYW5nZSB0byBkcmFmdC1pZXRmLWF2dGNvcmUtcmZjNTc2NC1tdXgtZml4ZXMuDQo+ IA0KPiBDaGVlcnMsDQo+IA0KPiBHb256YWxvDQo+IA0KPj4gT24gTWF5IDI1LCAyMDE2LCBhdCA4 OjAxIFBNLCBBbGFuIEpvaG5zdG9uIDxhbGFuLmIuam9obnN0b25AZ21haWwuY29tPiB3cm90ZToN Cj4+IA0KPj4gSGkgR29uemFsbywNCj4+IA0KPj4gVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlv biAtIEkgaGFkIGl0IGJhY2t3YXJkcyBpbiBteSBoZWFkLiAgIEV4aXN0aW5nIFpSVFAgaW1wbGVt ZW50YXRpb25zIHdpbGwgYmUgY29tcGxpYW50IHRvIHRoZSBwcm9wb3NhbCwgYW5kIHdlIGNhbiBj b25zdHJhaW4gdGhvc2UgYml0cyB0byAwIGluIHRoZSA2MTg5YmlzIGRyYWZ0IHRvIGxvY2sgaXQg ZG93bi4NCj4+IA0KPj4gU28gSSBhbSBPSyB3aXRoIHRoaXMgcHJvcG9zYWwuDQo+PiANCj4+IC0g QWxhbiAtDQo+PiANCj4+IE9uIFdlZCwgTWF5IDI1LCAyMDE2IGF0IDE6NTYgUE0sIEdvbnphbG8g U2FsZ3VlaXJvIChnc2FsZ3VlaSkgPGdzYWxndWVpQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBIaSBB bGFuIC0NCj4+IA0KPj4gT25lIG9mIHRoZSByZWFzb25zIHdlIG1hZGUgdGhlIHN1Z2dlc3Rpb24g d2FzIGJlY2F1c2UgKGluIG91ciBlc3RpbWF0aW9uKSBpdCBkaWQgbm90IGhhdmUgYSBtYWpvciBp bXBhY3QgdG8gdGhlIFpSVFAgcGFja2V0IGZvcm1hdC4gQ3VycmVudGx5IHRoZSBwYWNrZXQgZm9y bWF0IGlzOg0KPj4gDQo+PiANCj4+ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4+ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPj4gICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPj4gICB8MCAwIDAgMXxOb3QgVXNlZCAoc2V0IHRvIHplcm8pIHwgICAgICAgICBTZXF1ZW5j ZSBOdW1iZXIgICAgICAgfA0KPj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPj4gICB8ICAgICAgICAgICAgICAgICBN YWdpYyBDb29raWUgJ1pSVFAnICgweDVhNTI1NDUwKSAgICAgICAgICAgICAgfA0KPj4gICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KPj4gICB8ICAgICAgICAgICAgICAgICAgICAgICAgU291cmNlIElkZW50aWZpZXIgICAg ICAgICAgICAgICAgICAgICAgfA0KPj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPj4gICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICB8 ICAgICAgICAgICBaUlRQIE1lc3NhZ2UgKGxlbmd0aCBkZXBlbmRzIG9uIE1lc3NhZ2UgVHlwZSkg ICAgICAgfA0KPj4gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4gLiAuICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPj4g ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBDUkMgKDEgd29yZCkgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KPj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPj4gDQo+PiANCj4+IE91ciBwcm9wb3NhbCB3YXMg dG8gc2V0IGJpdHMgNCBhbmQgNSB0byB6ZXJvLCB3aGljaCBpcyBjdXJyZW50bHkgd2hhdCB0aGUg cHJvdG9jb2wgY2FsbHMgZm9yIGFuZCBzaG91bGQgaW1wbGljaXRseSBtYWtlIGFsbCBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgY29tcGxpYW50LiAgQWxsIHdlIGFyZSBwcm9wb3NpbmcgaXMgaXMg dG8gdGFrZSBiaXRzIDQgYW5kIDUgb3V0IG9mIHRoZSDigJxOb3QgVXNlZOKAnSByYW5nZSBhbmQg bGVhdmUgdGhlbSBmaXhlZCB0byB0aGUgdmFsdWUgdGhhdCBjdXJyZW50IGltcGxlbWVudGF0aW9u cyB1c2UuICBEb2VzIHRoaXMgbWFrZSBzZW5zZT8NCj4+IA0KPj4gSW4gYW55IGNhc2UsIEnigJlk IGxpa2UgdG8gdHJ5IGFuZCB1bmRlcnN0YW5kIHdoYXQgaW1wYWN0IHRoaXMgaGFzIHRvIHRoZSBj dXJyZW50IHJmYzU3NjQtbXV4LWZpeCB0ZXh0LiAgSXMgaXQgYXMgc2ltcGxlIGFzIGV4cGxpY2l0 bHkgcmVzZXJ2aW5nIHZhbHVlcyAxNiAtIDE5IGZvciBaUlRQPyBPciBkaWQgeW91IGhhdmUgc29t ZXRoaW5nIGVsc2UgaW4gbWluZD8gIElmIHlvdSBjYW4gbWFrZSBzcGVjaWZpYyB0ZXh0IHN1Z2dl c3Rpb25zIHRoYXQgd2lsbCBzaW1wbGlmeSB0aGluZ3MuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0K Pj4gR29uemFsbw0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+PiBPbiBNYXkgMjUsIDIwMTYs IGF0IDE6MzUgUE0sIEFsYW4gSm9obnN0b24gPGFsYW4uYi5qb2huc3RvbkBnbWFpbC5jb20+IHdy b3RlOg0KPj4+IA0KPj4+IEhpIE1hcmMsDQo+Pj4gDQo+Pj4gQ2hhbmdpbmcgdGhlIHBhY2tldCBm b3JtYXQgZm9yIFpSVFAgaXMgYSBwcmV0dHkgbWFqb3IgY2hhbmdlIHRvIHRoZSBwcm90b2NvbC4u Lg0KPj4+IA0KPj4+IEkgdGhpbmsgdGhlIG9ubHkgY2FzZSB3aGVyZSB0aGlzIGlzIGFuIGlzc3Vl IHdvdWxkIGJlIGlmIGJvdGggWlJUUCBhbmQgRFRMUy1TUlRQIGFyZSBvZmZlcmVkIG9wcG9ydHVu aXN0aWNhbGx5IChPU1JUUCksIGFuZCBlaXRoZXIgWlJUUCBvciBEVExTLVNSVFAgYXJyaXZlcyBi ZWZvcmUgdGhlIGFuc3dlciBpcyByZWNlaXZlZC4gICAgRHVyaW5nIHRoaXMgd2luZG93IG9mIHRp bWUsIGEgc2xpZ2h0bHkgbW9yZSBjb21wbGljYXRlZCBhbGdvcml0aG0gY291bGQgYmUgdXNlZCB0 byBkaXN0aW5ndWlzaCBaUlRQIGZyb20gRFRMUy1TUlRQLCBzdWNoIGFzIGNoZWNraW5nIHRoZSAz Mi1iaXQgbWFnaWMgY29va2llIHRoYXQgaXMgcHJlc2VudCBpbiBldmVyeSBaUlRQIG1lc3NhZ2Uu IE90aGVyd2lzZSwgb25seSBvbmUgb2YgdGhlc2UgcHJvdG9jb2xzIHdpbGwgYmUgdXNlZCBhdCBh IHRpbWUsIHNvIGl0IGlzIG5vdCB0aGUgc2FtZSBhcyBkaXN0aW5ndWlzaGluZyBlaXRoZXIgZnJv bSBTVFVOIGFuZCBSVFAsIHdoaWNoIGhhcHBlbnMgdGhyb3VnaG91dCBhIHNlc3Npb24uDQo+Pj4g DQo+Pj4gV2UgY291bGQgcHV0IHRoaXMgZ3VpZGFuY2UgaW4gYSBSRkM2MTg5YmlzIGRyYWZ0LCBh bmQgdGhlIG90aGVyIGRvY3VtZW50cyBjb3VsZCBqdXN0IGRlZmVyIHRvIHRoYXQgZ3VpZGFuY2Ug aWYgdGhleSBzdXBwb3J0IFpSVFAgaW4gYWRkaXRpb24gdG8gRFRMUy1TUlRQIG9wcG9ydHVuaXN0 aWNhbGx5Lg0KPj4+IA0KPj4+IC0gQWxhbiAtDQo+Pj4gDQo+Pj4gT24gV2VkLCBNYXkgMjUsIDIw MTYgYXQgMTA6NTYgQU0sIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToNCj4+ PiBIaSBNYXJjLA0KPj4+IA0KPj4+IFRoYXQncyBhbG9uZyB0aGUgbGluZXMgdGhhdCBJIGV4cGVj dGVkLCBpZiB0aGUgd29ya2luZyBncm91cCBjaG9vc2VzIHRoaXMgcGF0aC4gV2hhdCBkbyBvdGhl cnMgdGhpbms/DQo+Pj4gDQo+Pj4gVGhhbmtzIQ0KPj4+IA0KPj4+IEJlbi4NCj4+PiANCj4+PiBP biAyNSBNYXkgMjAxNiwgYXQgMTI6MzcsIE1hcmMgUGV0aXQtSHVndWVuaW4gd3JvdGU6DQo+Pj4g DQo+Pj4gQXMgeW91IG1lbnRpb24sIHRoZXJlIGFyZSBzZXZlcmFsIHdheXMgdG8gaGFuZGxlIHRo aXMgaXNzdWUuIFdlIGxlYXZlIGl0IHRvIHRoZSBjb21tdW5pdHkgdG8gZGVjaWRlIHdoZXRoZXIg dG8gaW5jbHVkZSB6cnRwIGluIGJ1bmRsZSBvciBub3QuIElmIHdlIHdlcmUgdG8gdXBkYXRlIHRo ZSA1NzY0LW11eC1maXggZHJhZnQsIHdlIGZlbHQgdGhhdCB0aGUgY2xlYW5lc3Qgd2F5IHRvIGhh bmRsZSBpdCBpcyBpbiB0d28gc3RlcHMuDQo+Pj4gDQo+Pj4gT25lIHRoaW5nIHRvIG5vdGUgaXMg dGhhdCB0aGVyZSBpcyBubyBjbGFzaC9vdmVybGFwIHdpdGggU1RVTiwgc28gdXNpbmcgbWFnaWMg Y29va2llIHRvIGRpc3Rpbmd1aXNoIGZyb20gU1RVTiBpcyBhIG1vb3QgcG9pbnQuIFRoZSBvdmVy bGFwIHdpdGggdGhlIERUTFMgcmFuZ2UgaXMgd2hhdCB3ZSBuZWVkIHRvIGF2b2lkLiBUaGUgcmln aHQgdGhpbmcgdG8gZG8gc2VlbXMgdG8gYmUgdG8gd29yayBvbiBhIHJmYzYxODliaXMgZHJhZnQg dGhhdCB3b3VsZCBzZXQgYml0IDQgYW5kIDUgb2YgdGhlIGZpcnN0IGJ5dGUgb2YgdGhlIHpydHAg bWVzc2FnZSB0byAwLiBUaGlzIHdheSB6cnRwIGNhbm5vdCBjbGFzaCB3aXRoIERUTFMuDQo+Pj4g DQo+Pj4gT24gdGhlIHJmYzU3NjQtbXV4LWZpeGVzIGRyYWZ0LCB3ZSBqdXN0IGNoYW5nZSB0aGUg YWxnb3JpdGhtIHRvOg0KPj4+IA0KPj4+ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNCj4+ PiAgICAgICAgICAgfCAgICAgICAgWzAuLjNdIC0rLS0+IGZvcndhcmQgdG8gU1RVTg0KPj4+ICAg ICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCj4+PiAgICAgICAgICAgfCAgICAgIFsxNi4uMTld IC0rLS0+IGZvcndhcmQgdG8gWlJUUA0KPj4+ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwN Cj4+PiBwYWNrZXQgLS0+IHwgICAgICBbMjAuLjYzXSAtKy0tPiBmb3J3YXJkIHRvIERUTFMNCj4+ PiAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQo+Pj4gICAgICAgICAgIHwgICAgICBbNjQu Ljc5XSAtKy0tPiBmb3J3YXJkIHRvIFRVUk4gQ2hhbm5lbA0KPj4+ICAgICAgICAgICB8ICAgICAg ICAgICAgICAgIHwNCj4+PiAgICAgICAgICAgfCAgICBbMTI4Li4xOTFdIC0rLS0+IGZvcndhcmQg dG8gUlRQL1JUQ1ANCj4+PiAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4gDQo+Pj4g DQo+Pj4gRG9lcyB0aGlzIHNlZW0gbGlrZSBhIHJlYXNvbmFibGUgYXBwcm9hY2g/DQo+Pj4gDQo+ Pj4gDQo+Pj4gT24gMDUvMjQvMjAxNiAwNDoyMSBQTSwgQmVuIENhbXBiZWxsIHdyb3RlOg0KPj4+ IEhpLA0KPj4+IA0KPj4+IFRoZXJlIGFwcGVhcnMgdG8gYmUgYSBkaXNjcmVwYW5jeSBiZXR3ZWVu IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcyBhbmQgZHJhZnQtaWV0Zi1hdnRj b3JlLXJmYzU3NjQtbXV4LWZpeGVzIGNvbmNlcm5pbmcgd2hldGhlciB6cnRwIGNhbiBiZSB1c2Vk IHdpdGggYnVuZGxlLg0KPj4+IA0KPj4+IG11eC1hdHRyaWJ1dGVzIHB1dHMgdGhlIHpydHAtaGFz aCBhdHRyaWJ1dGUgW1JGQzYxODldIGluIHRoZSAidHJhbnNwb3J0IiBjYXRlZ29yeSwgbWVhbmlu ZywgYW1vbmcgb3RoZXIgdGhpbmdzLCB0aGF0IGl0IGNhbiBiZSB1c2VkIGluIGEgYnVuZGxlIGdy b3VwLiBIb3dldmVyLCBhcyB0aGUgZGVtdXggcnVsZXMgYXJlIGN1cnJlbnRseSBkZWZpbmVkIDU3 NjQtbXV4LWZpeGVzLCB6cnRwIG1lc3NhZ2VzIGNhbm5vdCBhY3R1YWxseSBiZSBkZW11eGVkLiAo SWYgSSByZWFkIHRoaW5ncyBjb3JyZWN0bHksIHRoZSBmaXJzdCBieXRlIG9mIGEgenJ0cCBtZXNz YWdlIHdpbGwgYmUgMTYsIHdoaWNoIGlzIG5vdCBpbiBhbnkgb2YgdGhlICJrbm93biByYW5nZXMi IGRlc2NyaWJlZCBpbiA1NzY1IG9yIDU3NjQtbXV4LWZpeGVzLCBhbmQgdGhlcmVmb3JlIHRoZSBt ZXNzYWdlIE1VU1QgYmUgZHJvcHBlZC4NCj4+PiANCj4+PiBUaGF0IHNlZW1zIHRvIGxlYXZlIHRo ZSBjaG9pY2Ugb2YgYWRkaW5nIHpydHAgbWVzc2FnZXMgdG8gdGhlIGRlbXV4IHJ1bGVzIGluIDU3 NjQtbXV4LWZpeGVzLCBvciByZW1vdmluZyB0aGUgaW1wbGljYXRpb24gdGhhdCB6cnRwIGNhbiBi ZSBidW5kbGVkIGZyb20gbXV4LWF0dHJpYnV0ZXMuDQo+Pj4gDQo+Pj4gQWRkaW5nIHJ1bGVzIGZv ciBkZW11eGluZyB6cnRwIHRvIDU3NjUtbXV4LWZpeGVzIHdvdWxkIHByb2JhYmx5IG5vdCBiZSBo YXJkLCBidXQgd291bGQgYmUgbm9uLXRyaXZpYWwuIFJGQyA2MTg5IGNhbGxzIGZvciB1c2luZyB0 aGUgbWFnaWMgY29va2llIHRvIGRpc3Rpbmd1aXNoIHpydHAgbWVzc2FnZXMgZnJvbSBzdHVuIG1l c3NhZ2VzLg0KPj4+IA0KPj4+IERvIHBlb3BsZSBoYXZlIG9waW5pb25zIGhvdyB0byBtb3ZlIGZv cndhcmQgd2l0aCB0aGlzPyBBbSBJIGludGVycHJldGluZyB0aGUgY29uZmxpY3QgY29ycmVjdGx5 P0tlZXAgaW4gbWluZCB0aGF0IFpSVFAgaXMgbm90IGEgc3RhbmRhcmRzLXRyYWNrIHNwZWMuIEJ1 dCBhdCB0aGUgc2FtZSB0aW1lLCBJJ20gbm90IHN1cmUgd2Ugd2FudCB0byBleGNsdWRlIGl0IGZy b20gdGhlIGJ1bmRsZSBtZWNoYW5pc20uDQo+Pj4gDQo+Pj4gVGhhbmtzIQ0KPj4+IA0KPj4+IEJl bi4NCj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+ Pj4gYXZ0QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hdnQNCj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+PiBtbXVzaWNAaWV0Zi5v cmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPj4+ IA0KPj4gDQo+PiANCj4gDQoNCg== From nobody Wed Jun 8 14:46:03 2016 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 E05E012D1A5; Wed, 8 Jun 2016 14:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 3mqNQKdqhXv8; Wed, 8 Jun 2016 14:45:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D1812D18A; Wed, 8 Jun 2016 14:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1367; q=dns/txt; s=iport; t=1465422356; x=1466631956; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2FFV5niDH4ovTmMyxsu81HkIN1Uaht9NJyOBNtbpSkY=; b=LCwtFl9wk+p6gCaOfCoZ8jpTYmOZ1KozfvDkROSmnJ6uhwmMZCrB6AiC tDRiSBFaPXZMejccxOGC8Uz352y2cS0QGLnengOO2v0SrgDXcfnB2RsLr oc5rmFrHOvDKOz3ZURZiiuk+Bm668WyRjdHw2ok2s/fRbiV9yQuW4Vax9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANBwC/kFhX/5ldJa1egz5WK1K7FYF6F?= =?us-ascii?q?wuFJ0oCgUY4FAEBAQEBAQFlJ0EBAQMJBINzAQEEAQEBGhs2CxAjLicwBg0GAgE?= =?us-ascii?q?BiCsOvgcBAQEBAQEBAQEBAQEBAQEBAQEaBYYngXeGcoV+AQSYT4EwjHaBaYRSg?= =?us-ascii?q?wmEQYEagUKOHx42ggccFoFRIDKBYYEchU6BRAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,441,1459814400"; d="scan'208";a="111287466" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2016 21:45:56 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u58LjtHf006248; Wed, 8 Jun 2016 21:45:55 GMT To: mmusic References: <90408933-ab1d-8636-9dfb-1b75443a04b8@cisco.com> From: Flemming Andreasen Message-ID: Date: Wed, 8 Jun 2016 17:45:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <90408933-ab1d-8636-9dfb-1b75443a04b8@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: [MMUSIC] Looking for review confirmation: Re: WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-29 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 21:46:03 -0000 The WGLC for bundle ended a few weeks ago, however we did not see a whole lot of reviews this time around, which is understandable given how many WGLCs we have been through and the limited set of changes in the more recent versions. If you did review the document and just didn't have any comments on it, we would appreciate a note to that effect to the mailing list. Thanks -- Flemming (MMUSIC co-chair) On 4/29/16 2:32 PM, Flemming Andreasen wrote: > Greetings > > This is to announce a 2 week Working Last Call for > > draft-ietf-mmusic-sdp-bundle-negotiation-29 > > as Proposed Standard. Please note that we previously issued a WGLC on > the -22 version (in June 2015), however, since there has been various > updates since then, we want to give people a chance to properly review > the current version one last time (hopefully). > > Please review and provide any comments you may have on the document by > Friday, May 13, 2016. Comments should be sent to the document authors > and the MMUSIC WG list. If you review the document but do not have any > comments, please send a note to that effect as well. > > Thanks > > Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Wed Jun 8 23:20:37 2016 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 A97E112D12B; Wed, 8 Jun 2016 23:20:35 -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 DQAeu02sYy9R; Wed, 8 Jun 2016 23:20:33 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 456C012D0F6; Wed, 8 Jun 2016 23:20:33 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id i187so15905909qkd.3; Wed, 08 Jun 2016 23:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iBHP4YMXXUzNOlC5UvvznrScavFFsp4pYfwwrBqmoIU=; b=yx/phBGCJsaMIaP+9X1Sh+bu79R9GDlkfGYPtY1C6rgW8LkiQx3GGVW2JnMlYNiJKh RouNvfUwUwh+pDS0az1r3soBcjcl2pyp0LEZ7ckGrA3DT+l8y0du0x8pwY+hIww4FzMJ HMHjfzZXxlu7QgB76uTInnpPeDJQjskJaTR6o01Xr5zWEoCzMY5yqf6Fwy7JfLLB28La Zlm2khYlXvGbiq59H928iUlgo8gFC1H6RxGzpdVF7RkBFAz92kDx6Nv/d/uyU9syLfKC 8PieJZpaboad5/bD/Wyd6gO+K6v7UN70GCuxq0WAeFJZnRv8sv3AR268xSq5x0k05fMJ hBHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iBHP4YMXXUzNOlC5UvvznrScavFFsp4pYfwwrBqmoIU=; b=i+9hmuY1x+hvfhIhWLmtMKVMLqaySr0lISAqJW0vffCyhkqw47MF0TMIHmfCDgQ9e7 xWbhQqLa4Irdi6Sre4bY1BkqF82qvS6Yfxg8nbQrGBV5W755EPBKra2yPsax/sFyMV5E Mbsfo+QtbxGL7en0pV3ZI7TzHbaFGwj8jXwjKvz4cT4kEdC04GVUh4j1CjUGmLW2A5Fz 65AKB8Vv3/KXvFS+kELmIScTLj3mKaxn9hiXfJJ+nwFlmFH1OrzzJyegwoFeXr8Bol+t 9jVUOyOIZyJwNHb1XuZ3gewri011O3ua3jdZ1QJZf3AmE8nvCJOIZmUdjWpbSRDiIuM5 srrg== X-Gm-Message-State: ALyK8tJTVqunWmkj0TOceOUxvzEiwev9Sgw2UKlQVOUTipibW1ANCn7z23r3Eg4KCsHqQowKVaZGXl8EguR0lw== X-Received: by 10.55.20.208 with SMTP id 77mr8282033qku.124.1465453232461; Wed, 08 Jun 2016 23:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Wed, 8 Jun 2016 23:20:31 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Jun 2016 16:20:31 +1000 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 06:20:36 -0000 This is unnecessary: When an endpoint receives one or more fingerprints from its peer, and is about to calculate its own fingerprints, unless the endpoint has other ways of knowing what hash functions the peer supports the endpoint MUST calculate at least one fingerprint using a hash function that was also used by the peer to calculate a fingerprint. In addition, the endpoint MAY calculate fingerprints using hash functions that were not used by the peer. This encourages rot. It's far easier and it can even be more secure if endpoints generate fingerprints based on their own knowledge only. On 7 June 2016 at 17:35, Christer Holmberg wrote: > Hi, > > Based on the WGLC comments, I=E2=80=99ve submitted a new version (-04) of > draft-ietf-mmusic-4572-update. > > Thanks to everyone who provided input and comments! :) > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Jun 8 23:27:43 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8353012B01E; Wed, 8 Jun 2016 23:27:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160609062739.20079.46544.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 23:27:39 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 06:27:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-06.txt Pages : 11 Date : 2016-06-08 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 8 23:31:29 2016 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 3672A12D0F6; Wed, 8 Jun 2016 23:31:28 -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 q7sGmjjlBKB8; Wed, 8 Jun 2016 23:31:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA4B12B01E; Wed, 8 Jun 2016 23:31:26 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-16-57590d3ca28c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A0.ED.27088.C3D09575; Thu, 9 Jun 2016 08:31:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 08:31:24 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-06 Thread-Index: AQHRwhiLw+OsNKDGi0SfVjf5sBvuhA== Date: Thu, 9 Jun 2016 06:31:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D37EE8AEA45Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7ma4Nb2S4wcNDFhbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyvkx/y1KwnL9i88JzTA2Mk3m7GDk5JARMJFraJrJD 2GISF+6tZ+ti5OIQEjjCKLFg3hZ2CGcxo8S9XfMZuxg5ONgELCS6/2mDNIgIqEt83dvDDGIz C5hKPHy1BqxEWMBOon+5AUSJs8TDWetZIGw9iXeb2xlBbBYBFYl1X96DtfIKWEmcuHgNrIYR 6Ibvp9YwQYwUl7j1ZD4TxG0CEkv2nGeGsEUlXj7+xwpiiwLN/HJvHiNEXFHi46t9jBC98RJH zr5hhZgvKHFy5hOWCYwis5CMnYWkbBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIbv5xlhLCtJd7u b2ZDVrOAkWMVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmCMHdzy22AH48vnjocYBTgYlXh4 E6ZGhAuxJpYVV+YeYpTgYFYS4S1mjwwX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9 sSQ1OzW1ILUIJsvEwSnVwCggM71iYQKzX5PncvUDmyWSXBf3xcd9OV5l9vB3UtvZ+GWsTA0c i+2Cjc+um3G/5EFGajWH9gOjrJyrFZu6lyxUFv+VP9/4+uk9LkWbF73xqphktJStsYPLXFRq mbvB5M/PCg9/v6K0taAt7vcXpTV11w3TdhzSfOu0Odxj3sTmoC73H2ZLFyuxFGckGmoxFxUn AgCMNTMXrQIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 06:31:28 -0000 --_000_D37EE8AEA45Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-06) of draft-ietf-mmusic-mux-exclusive, ba= sed on comments from Flemming. The changes in version =9605 and =9606 are: 1) The mux category for the attribute was changed from NORMAL to IDENTICAL. 2) The reference to draft-5245bis was changed to RFC 5245. There is nothing= 5245bis specific in the draft, and by referencing the RFC the draft won=92= t be held due a missing reference. Regards, Christer --_000_D37EE8AEA45Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0751413CE3A9FF4AA775224BA44D0C6C@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-06) of draft-ietf-mmusic-mux-exc= lusive, based on comments from Flemming.

The changes in version =9605 and =9606 are:

1) The= mux category for the attribute was changed from NORMAL to IDENTICAL.

2) The= reference to draft-5245bis was changed to RFC 5245. There is nothing 5245b= is specific in the draft, and by referencing the RFC the draft won=92t be h= eld due a missing reference.

Regards,

Christer
--_000_D37EE8AEA45Cchristerholmbergericssoncom_-- From nobody Thu Jun 9 04:16:40 2016 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 8899112B076; Thu, 9 Jun 2016 04:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 coryVb75StX2; Thu, 9 Jun 2016 04:16:37 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2068712B05E; Thu, 9 Jun 2016 04:16:37 -0700 (PDT) Received: from [130.209.247.112] (port=57616 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bAxww-00011c-SG; Thu, 09 Jun 2016 12:16:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38040629@ESESSMB209.ericsson.se> Date: Thu, 9 Jun 2016 12:16:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B38040629@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-30 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 11:16:38 -0000 > On 7 Jun 2016, at 20:18, Christer Holmberg = wrote: >=20 > Based on the comments from the I-lost-count:th WGLC, I have submitted = a new version (-30) of draft-bundle. This addresses my issue, thanks. --=20 Colin Perkins https://csperkins.org/ From nobody Thu Jun 9 10:59:15 2016 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 B4572128E19 for ; Thu, 9 Jun 2016 10:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 uRG8d13kfu6l for ; Thu, 9 Jun 2016 10:59:11 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABDB112D52D for ; Thu, 9 Jun 2016 10:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1696; q=dns/txt; s=iport; t=1465495151; x=1466704751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JBmBruRkQQBNxBfY+V0rvDClmTZ7HlxP4Y4HRru7z4c=; b=BG7f6CmoOTGr6/TIISO5piHDJkbV9zhSib27tZQgdiqiMu+uxIB3Uuf3 PZ6mwx/gb84dhieIECLMFuW0p0LK0HIz9e59qrjZfEPCfirBH9JB2JL7t KFNZ4S5fMYjc59/6tkv+IykBlvdy5vksoR8DgK35kFcgppc0pNI0M6LLF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYBQATrVlX/5xdJa1egz5WfQa7FIF6F?= =?us-ascii?q?wuFJ0oCHIEdOhIBAQEBAQEBZSeERQEBAQMBAQEBIBE6CwULAgEIDgoCAiYCAgI?= =?us-ascii?q?lCxUQAgQOBYgnCA6tQpECAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYcdglaEQ?= =?us-ascii?q?IMBK4IuBZhVAY4mjyCPZAElAi2Dbm6JCX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,446,1459814400"; d="scan'208";a="283677316" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 17:59:10 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u59Hx9HG021145 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 17:59:10 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 13:59:09 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 13:59:09 -0400 From: "Cullen Jennings (fluffy)" To: Brian Rosen Thread-Topic: [MMUSIC] Transport of "Flash-hook" Thread-Index: AQHRwnifdORb0tgNj0yctCpogEmixw== Date: Thu, 9 Jun 2016 17:59:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="utf-8" Content-ID: <92342499627CFD48ADA7387D8C6BC1B3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 17:59:14 -0000 DQpJJ3ZlIHNlZSBhIGxvdCBvZiBpbnRlcm9wIHByb2JsZW1zIHdpdGggaG9va2ZsYXNoLiBJdCdz IGNhbiBiZSBzdXJwcmlzaW5nbHkgaGFyZCBmb3IgR1dzIHRvIGRldGVjdC4gSXMgdGhlcmUgYW55 IHdheSBORU5BIGNvdWxkIGZpbmQgYSBiZXR0ZXIgd2F5IHRvIGRvIHRoaXM/IEknbSBub3Qga2Vl biBvbiBicmluZ2luZyB0aGlzIGJhY2suIA0KDQoNCj4gT24gSnVuIDIsIDIwMTYsIGF0IDE6MDIg UE0sIEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4gd3JvdGU6DQo+IA0KPiBCYWNrIGlu IFJGQzI4MzMsIHRoZSBEVE1GIHRvbmVzIHNlY3Rpb24sIGNvZGUgMTYgd2FzIGRlZmluZWQgZm9y IOKAnEZsYXNo4oCdLCB0aGUgc2lnbmFsIGNhdXNlZCBieSBhIG1vbWVudGFyeSBkZXByZXNzaW9u IG9mIHRoZSBob29rLXN3aXRjaCBpbiBhIFBPVFMgcGhvbmUuICBXaGVuIDI4MzMgd2FzIG9ic29s ZXRlZCBieSA0NzMzLCBmbGFzaCB3YXMgZHJvcHBlZCwgYWx0aG91Z2ggdGhlIGNvZGUgMTYgd2Fz IHJlc2VydmVkLg0KPiANCj4gV2UgaGF2ZSBhIHVzZSBjYXNlIGluIE5FTkEgKDktMS0xIGVtZXJn ZW5jeSBzdHVmZikgd2hlcmUgZXhpc3Rpbmcgc3lzdGVtcyB1c2UgZmxhc2ggaW50ZXJzcGVyc2Vk IHd0aCB0b25lcyBpbiBzaWduYWxpbmcgZGlhbGluZyBldmVudHMgd2hpY2ggYXJlIG5vdCBpbnRl cnByZXRlZCBieSB0aGUgVUEgdGhhdCByZWNlaXZlcyB0aGVtLCBidXQgYXJlIGluc3RlYWQgdHJh bnNwb3J0ZWQgdG8gYSBkZXZpY2UgdGhhdCBjcmVhdGVzIGFwcHJvcHJpYXRlIFNJUCBzaWduYWxp bmcgZm9yIHRoZSBkaWFsaW5nIGV2ZW50cyBpbml0aWF0ZWQuICBXZSBoYXZlIG5vIG90aGVyIHdh eSB0byB0cmFuc3BvcnQgZmxhc2ggdG8gaW50ZXJ3b3JrIHdpdGggb3VyIG5ld2VyIFNJUCBiYXNl ZCBlbWVyZ2VuY3kgY2FsbGluZyBzeXN0ZW1zLg0KPiANCj4gSeKAmW0gcHJlcGFyZWQgdG8gd3Jp dGUgYSBkcmFmdCB0aGF0IHJlc3RvcmVzIGNvZGUgMTYgZm9yIGZsYXNoLCBhcyBpdCB3YXMgaW4g MjgzMywgYnV0IHdhbnRlZCB0byBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGRvaW5nIHRoYXQuDQo+ IA0KPiBCcmlhbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= From nobody Thu Jun 9 12:21:59 2016 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 3C73E12D943 for ; Thu, 9 Jun 2016 12:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 yKp4tz7lhEVe for ; Thu, 9 Jun 2016 12:21:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4016012D935 for ; Thu, 9 Jun 2016 12:21:57 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A4261FFF8C7DF; Thu, 9 Jun 2016 19:21:51 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u59JLsKx017220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2016 19:21:54 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u59JLrPH001606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jun 2016 21:21:53 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 9 Jun 2016 21:21:53 +0200 From: "Drage, Keith (Nokia - GB)" To: "Cullen Jennings (fluffy)" , Brian Rosen Thread-Topic: [MMUSIC] Transport of "Flash-hook" Thread-Index: AQHRwnifz8tbdWsSj0aiQVFSDCR/qZ/hfHiA Date: Thu, 9 Jun 2016 19:21:52 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF12A26@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 19:21:59 -0000 SSBiZWxpZXZlIHRvIGJyaW5nIGl0IGJhY2sgeW91IHdvdWxkIGFsc28gbmVlZCB0byBkZWZpbmUg Zmxhc2hob29rLCB1bmxlc3MgeW91IGNhbiBmaW5kIGFuIGludGVybmF0aW9uYWwgZGVmaW5pdGlv biBvZiB0aGUgdGltaW5ncyBlbHNld2hlcmUgYW5kIHJlZmVyZW5jZSBpdC4NCg0KSW4gdGVybXMg b2YgdGltaW5nLCBhIGRpc2Nvbm5lY3Qgd2l0aCBhIHRpbWluZyBvZiBhcHByb3hpbWF0ZWx5IDMz JSBvZiBhIDEwMCBtcyBjeWNsZSBpcyBhIGRpYWwgcHVsc2UgKGFsdGhvdWdoIEkgYmVsaWV2ZSB0 aGVyZSBhcmUgdmFyaWFudHMgdGhhdCB3b3JrIGF0IHR3aWNlIHRoaXMgc3BlZWQuDQoNCkV1cm9w ZWFuIHN0YW5kYXJkcyBpbmRpY2F0ZSBhIGR1cmF0aW9uIG9mIDUwIC0gMTMwIG1zIGZvciByZWdp c3RlciByZWNhbGwuDQoNClNvbWV3aGVyZSBvdmVyIDUwMCBtcyBjb25zdGl0dXRlcyBhIGhhbmd1 cC4NCg0KSSBiZWxpZXZlIEkgaGF2ZSBzZWVuIFBCWCBzeXN0ZW1zIHRoYXQgaGF2ZSB1c2VkIHRo ZSBwZXJpb2QgYmV0d2VlbiAxMzAgbXMgYW5kIDUwMCBtcyBhcyBhIHNlY29uZCBmb3JtIG9mIGhv b2tmbGFzaCAtIG5vIGFjY2VzcyB0byBteSBlYXJseSBub3RlcyBhdCB0aGUgbW9tZW50Lg0KDQpJ biBtb3JlIFBCWCByZWxhdGVkIHNpZ25hbGxpbmcgc3lzdGVtcyBhIG9mZiBob29rIHRvIG9uIGhv b2sgb2YgMTQwIC0gMjkwIG1zIGNhbiBiZSBhIHdpbmsgc3RhcnQgdG8gaW5kaWNhdGUgc3RhcnRp bmcgdG8gc2VuZCBkaWdpdHMuDQoNClNvIHRoZSBwcm9ibGVtcyBhcmUgbW9yZSB0aGFuIG9uZSB0 eXBlIG9mIGhvb2tmbGFzaCBleGlzdHMsIGFuZCBwcm9iYWJseSBhIGxhY2sgb2YgZGVmaW5pdGlv biBvZiB0aGUgdGltaW5ncyBpbiBhbiBpbnRlcm5hdGlvbmFsIHNlbnNlLg0KDQpJJ2QgYWxzbyBu b3RlIHRoYXQgaWYgd2UgaGF2ZSAiaG9va2ZsYXNoIiwgd2h5IGRvbid0IHdlIGhhdmUgb24taG9v aywgb2ZmIGhvb2ssIGRpYWwgcHVsc2UsIGFuZCBzbyBvbi4gDQoNClBlcnNvbmFsbHksIGFzIHRo ZSBob29rZmxhc2ggaXMgdG8gZ2FpbiBhY2Nlc3MgdG8gc29tZXRoaW5nIHRvIHRyYW5zbWl0L3Jl Y2VpdmUgZGlnaXRzLCB0aGVuIG1heWJlIHlvdSBzaG91bGQgYmUgdHVybmluZyB0aGUgUlRQIERU TUYgY2hhbm5lbCBvbiBhbmQgb2ZmIGlmIHlvdSByZWFsbHkgd2FudCB0byBzaW11bGF0ZSBpdCEN Cg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1tdXNpYyBbbWFp bHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3VsbGVuIEplbm5pbmdz IChmbHVmZnkpDQpTZW50OiAwOSBKdW5lIDIwMTYgMTg6NTkNClRvOiBCcmlhbiBSb3Nlbg0KQ2M6 IG1tdXNpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFRyYW5zcG9ydCBvZiAiRmxh c2gtaG9vayINCg0KDQpJJ3ZlIHNlZSBhIGxvdCBvZiBpbnRlcm9wIHByb2JsZW1zIHdpdGggaG9v a2ZsYXNoLiBJdCdzIGNhbiBiZSBzdXJwcmlzaW5nbHkgaGFyZCBmb3IgR1dzIHRvIGRldGVjdC4g SXMgdGhlcmUgYW55IHdheSBORU5BIGNvdWxkIGZpbmQgYSBiZXR0ZXIgd2F5IHRvIGRvIHRoaXM/ IEknbSBub3Qga2VlbiBvbiBicmluZ2luZyB0aGlzIGJhY2suIA0KDQoNCj4gT24gSnVuIDIsIDIw MTYsIGF0IDE6MDIgUE0sIEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4gd3JvdGU6DQo+ IA0KPiBCYWNrIGluIFJGQzI4MzMsIHRoZSBEVE1GIHRvbmVzIHNlY3Rpb24sIGNvZGUgMTYgd2Fz IGRlZmluZWQgZm9yIOKAnEZsYXNo4oCdLCB0aGUgc2lnbmFsIGNhdXNlZCBieSBhIG1vbWVudGFy eSBkZXByZXNzaW9uIG9mIHRoZSBob29rLXN3aXRjaCBpbiBhIFBPVFMgcGhvbmUuICBXaGVuIDI4 MzMgd2FzIG9ic29sZXRlZCBieSA0NzMzLCBmbGFzaCB3YXMgZHJvcHBlZCwgYWx0aG91Z2ggdGhl IGNvZGUgMTYgd2FzIHJlc2VydmVkLg0KPiANCj4gV2UgaGF2ZSBhIHVzZSBjYXNlIGluIE5FTkEg KDktMS0xIGVtZXJnZW5jeSBzdHVmZikgd2hlcmUgZXhpc3Rpbmcgc3lzdGVtcyB1c2UgZmxhc2gg aW50ZXJzcGVyc2VkIHd0aCB0b25lcyBpbiBzaWduYWxpbmcgZGlhbGluZyBldmVudHMgd2hpY2gg YXJlIG5vdCBpbnRlcnByZXRlZCBieSB0aGUgVUEgdGhhdCByZWNlaXZlcyB0aGVtLCBidXQgYXJl IGluc3RlYWQgdHJhbnNwb3J0ZWQgdG8gYSBkZXZpY2UgdGhhdCBjcmVhdGVzIGFwcHJvcHJpYXRl IFNJUCBzaWduYWxpbmcgZm9yIHRoZSBkaWFsaW5nIGV2ZW50cyBpbml0aWF0ZWQuICBXZSBoYXZl IG5vIG90aGVyIHdheSB0byB0cmFuc3BvcnQgZmxhc2ggdG8gaW50ZXJ3b3JrIHdpdGggb3VyIG5l d2VyIFNJUCBiYXNlZCBlbWVyZ2VuY3kgY2FsbGluZyBzeXN0ZW1zLg0KPiANCj4gSeKAmW0gcHJl cGFyZWQgdG8gd3JpdGUgYSBkcmFmdCB0aGF0IHJlc3RvcmVzIGNvZGUgMTYgZm9yIGZsYXNoLCBh cyBpdCB3YXMgaW4gMjgzMywgYnV0IHdhbnRlZCB0byBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGRv aW5nIHRoYXQuDQo+IA0KPiBCcmlhbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxp bmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21tdXNpYw0K From nobody Thu Jun 9 23:43:02 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DB612B046; Thu, 9 Jun 2016 23:43:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610064301.16815.26792.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 23:43:01 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 06:43:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-07.txt Pages : 12 Date : 2016-06-09 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 9 23:47:35 2016 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 A746912DABB; Thu, 9 Jun 2016 23:47:33 -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 iQmsWdwl4e7D; Thu, 9 Jun 2016 23:47:32 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D4012D94A; Thu, 9 Jun 2016 23:47:31 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-c6-575a6281efb8 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.43.18043.1826A575; Fri, 10 Jun 2016 08:47:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 08:47:29 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-07 Thread-Index: AQHRwuP0iPA30gRifkiooGqIrDgRBA== Date: Fri, 10 Jun 2016 06:47:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D3803DF7A833christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7rm5jUlS4wbMrVhbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyjt57xlgwW6BiX3cncwPjQr4uRk4OCQETie8fNzFB 2GISF+6tZwOxhQSOMEqcfKLcxcgFZC9hlOg4AVLEwcEmYCHR/U8bpEZEQF3i694eZhCbWcBU 4uGrNYwgtrCAncT6HavYQcpFBJwl7jfwQJTrSZxpfc0OYrMIqEr8etjGCmLzClhJfJ2zmwXE ZgQ64fupNUwQI8Ulbj2ZD3WagMSSPeeZIWxRiZeP/4H1igLN/HJvHiNEXFFi59l2qHPiJa4s fgY1X1Di5MwnLBMYRWYhGTsLSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45ywhhW0s0nm9g QlazgJFjFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZghB3c8ttqB+PB546HGAU4GJV4eB88 iwwXYk0sK67MPcQowcGsJMIrFhgVLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJ anZqakFqEUyWiYNTqoHRqq3wyxML/mrr+T+FNbf13ap877+vVsR93YJJ3RXGpe+z35m53fHZ wWp+YNql4pkBf/01GCx8Fr68/DXp2vaNHrZHHyxhmH+/9d6OFFmb2FM3NGc0zL4ReOb43BnR YncXXdUtr2S5FnIhxLRtPyvrcqcYqzPJ0se3nPLX1ApZ1hFZ6j4/88U1JZbijERDLeai4kQA f3H/zKwCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 06:47:33 -0000 --_000_D3803DF7A833christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on comments from Flemming (while preparing the proto writeup) I=92ve = submitted a new version (-07) of draft-mux-exclusive. I=92ve added the pre-RFC5378 disclaimer, updated the BUNDLE reference versi= on, and done a couple of minor editorial corrections in the IANA considerat= ions. Regards, Christer --_000_D3803DF7A833christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7984FE85E9732C46868C0E01B0B0862E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on comments from Flemming (while preparing the proto writeup) I= =92ve submitted a new version (-07) of draft-mux-exclusive.

I=92ve added the pre-RFC5378 disclai= mer, updated the BUNDLE reference version, and done a couple of minor edito= rial corrections in the IANA considerations.

Regards,

Christer
--_000_D3803DF7A833christerholmbergericssoncom_-- From nobody Fri Jun 10 01:49:08 2016 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 05C2212D0DF for ; Fri, 10 Jun 2016 01:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 9RVZ7xhYt2VO for ; Fri, 10 Jun 2016 01:49:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDA112D09E for ; Fri, 10 Jun 2016 01:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8RMOFqNn+m8bxGpyVocZbY0xh+AiH5eA2utYYvRgJhw=; b=nVhCISEF7bsX7ekk6Jt3gpN375BV6DOR1/RUT9Rl0S9y/rjrsFlh/pGQqE3fg4a9aF6X0N+RmqzZVarMK9C2GS2F6nGXtZNmaqI+Vf1w4BVevLbDwcmmTRi0rfJkGnr6tjHnPWno9pkT1xWMpNVFl41RLK8YfrA7ou1j+hubxz4= Received: from BLUPR02MB1185.namprd02.prod.outlook.com (10.163.80.14) by BLUPR02MB1185.namprd02.prod.outlook.com (10.163.80.14) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 10 Jun 2016 08:49:02 +0000 Received: from BLUPR02MB1185.namprd02.prod.outlook.com ([10.163.80.14]) by BLUPR02MB1185.namprd02.prod.outlook.com ([10.163.80.14]) with mapi id 15.01.0517.005; Fri, 10 Jun 2016 08:49:02 +0000 From: Martin Taylor To: Brian Rosen , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Transport of "Flash-hook" Thread-Index: AQHRvQFhGGU+hqrbMU++A/vXAXNj9p/ibdXA Date: Fri, 10 Jun 2016 08:49:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Martin.Taylor@metaswitch.com; x-originating-ip: [185.82.159.246] x-ms-office365-filtering-correlation-id: 890b62bd-0c09-49cf-e8b2-08d3910c12b4 x-microsoft-exchange-diagnostics: 1; BLUPR02MB1185; 6:hWHCe5VrPp69J67+C775hFxZoHUFVmc4gFh0d+ODKzGu8S7vQ4GLhRxo9IT5k+9b+v9Dz+0hi6S74uNv+AkKrHxHDJqnaX3Vh3iuw7SjZO/G9qBCEMk/kvzXluDSTY2bHI9KEjbstZ6YbYcZx0Kr6p1uZLoyNJ/bZQ/mW23IztSz+kKqIaGjIr7XS+JTHRXwlxHJvpdYas4Ll38IC0Wg+j0FMUT/9z/b4mmlSxjzk3yU8abXglOKiXBGegnKSxh0SMB+PyKtD6Iv3uA4oKT22DNMiw9X8dE19JS6jR1S/k4=; 5:utNEPUQrSvFcT3mLvigydkuwURH7c/m7O9Byq5bVuu196JGfjpSfVDuJBRXhppW1dRvyENyJkutKZtRyLsgN54BnRJdBgGHdB5dtms2OZ+pTgPCpGBKbO9gpm0yZphJQ5CulIKuwF6ysgFYPLWcNLw==; 24:voosfxpDzk5Umj295bGHVyhYFw0JBJ3Qd2BaSyaKvKYRHiKRG5IopYA0UsZ0ZYqw/HX375JjMuNJxqNGDKjme77GnTyc0oxV2D9Ddky0YAQ=; 7:xCIjfGHRnI+etzTiZQk4whPL7I3ul0gIyQ6vFukqc6d39FtgAwpDQjvwEAc8nX+xRuaAS7g7t7sbo/TW8ZdOIfLXSuz0JP16S/0EKqwcd/E4Voaq9kWKbzKgVcDoOswOmVjaf+ML4KlBsZ3n6FfaWhZtx3OGW0GlpKRfuEpcu3Pw/QsSJ/7wVb5nwR2qK81ExmYExBH9XeG/ewkuTOJjXHc6TsfJJp7upDOmvi3qBB4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR02MB1185; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR02MB1185; BCL:0; PCL:0; RULEID:; SRVR:BLUPR02MB1185; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(189002)(199003)(8676002)(77096005)(87936001)(81166006)(68736007)(81156014)(105586002)(2900100001)(15975445007)(2906002)(76576001)(106356001)(99286002)(9686002)(2950100001)(33656002)(92566002)(107886002)(5003600100002)(50986999)(189998001)(76176999)(5001770100001)(97736004)(106116001)(5002640100001)(66066001)(122556002)(10400500002)(11100500001)(3660700001)(3846002)(74316001)(102836003)(3280700002)(586003)(101416001)(5004730100002)(8936002)(6116002)(54356999)(2501003)(19580395003)(86362001)(19580405001)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB1185; H:BLUPR02MB1185.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 08:49:02.6509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR02MB1185 Archived-At: Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 08:49:06 -0000 U2lnbmFsbGluZyBvZiBmbGFzaC1ob29rIGlzIGFuIGltcG9ydGFudCBhc3BlY3Qgb2YgUFNUTiBF bXVsYXRpb24gd2l0aCBJTVMuICBUaGVyZSBhcmUgYSBidW5jaCBvZiBtaWQtY2FsbCBzZXJ2aWNl cyB0aGF0IG11c3QgYmUgc3VwcG9ydGVkIGZvciBQT1RTIHN1Y2ggYXMgY2FsbCB0cmFuc2ZlciBh bmQgdGhyZWUtd2F5IGNhbGxpbmcgd2hpY2ggcmVseSBvbiBiZWluZyBhYmxlIHRvIHNpZ25hbCBm bGFzaC1ob29rLg0KDQpJbiBteSBleHBlcmllbmNlLCBtb3N0IFBTVE4gRW11bGF0aW9uIGltcGxl bWVudGF0aW9ucyB1c2UgU0lQIElORk8gcmVxdWVzdHMgdG8gc2lnbmFsIGZsYXNoLWhvb2suICBU byBteSBrbm93bGVkZ2UsIHRoaXMgaGFzIG5ldmVyIGJlZW4gc3RhbmRhcmRpemVkIGJ1dCB0aGVy ZSBoYXZlIGJlZW4gSS1EcyBvbiB0aGUgdG9waWMsIGUuZy4gZHJhZnQtaHdhbmctc2lwcGluZy1p bmZvbWlkY2FsbC0wMCBhbmQgZHJhZnQta2FwbGFuLXNpcC1pbmZvLXVzZS1jYXNlcy0wMS4NCg0K TWFueSBhbmFsb2cgdGVsZXBob25lIGFkYXB0ZXJzIHN1cHBvcnQgdGhlIFNJUCBJTkZPIG1ldGhv ZCBvZiBzaWduYWxsaW5nIGZsYXNoLWhvb2suDQoNCk1hcnRpbg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogMDIgSnVuZSAyMDE2IDIwOjAyDQpUbzog bW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBbTU1VU0lDXSBUcmFuc3BvcnQgb2YgIkZsYXNoLWhv b2siDQoNCkJhY2sgaW4gUkZDMjgzMywgdGhlIERUTUYgdG9uZXMgc2VjdGlvbiwgY29kZSAxNiB3 YXMgZGVmaW5lZCBmb3Ig4oCcRmxhc2jigJ0sIHRoZSBzaWduYWwgY2F1c2VkIGJ5IGEgbW9tZW50 YXJ5IGRlcHJlc3Npb24gb2YgdGhlIGhvb2stc3dpdGNoIGluIGEgUE9UUyBwaG9uZS4gIFdoZW4g MjgzMyB3YXMgb2Jzb2xldGVkIGJ5IDQ3MzMsIGZsYXNoIHdhcyBkcm9wcGVkLCBhbHRob3VnaCB0 aGUgY29kZSAxNiB3YXMgcmVzZXJ2ZWQuDQoNCldlIGhhdmUgYSB1c2UgY2FzZSBpbiBORU5BICg5 LTEtMSBlbWVyZ2VuY3kgc3R1ZmYpIHdoZXJlIGV4aXN0aW5nIHN5c3RlbXMgdXNlIGZsYXNoIGlu dGVyc3BlcnNlZCB3dGggdG9uZXMgaW4gc2lnbmFsaW5nIGRpYWxpbmcgZXZlbnRzIHdoaWNoIGFy ZSBub3QgaW50ZXJwcmV0ZWQgYnkgdGhlIFVBIHRoYXQgcmVjZWl2ZXMgdGhlbSwgYnV0IGFyZSBp bnN0ZWFkIHRyYW5zcG9ydGVkIHRvIGEgZGV2aWNlIHRoYXQgY3JlYXRlcyBhcHByb3ByaWF0ZSBT SVAgc2lnbmFsaW5nIGZvciB0aGUgZGlhbGluZyBldmVudHMgaW5pdGlhdGVkLiAgV2UgaGF2ZSBu byBvdGhlciB3YXkgdG8gdHJhbnNwb3J0IGZsYXNoIHRvIGludGVyd29yayB3aXRoIG91ciBuZXdl ciBTSVAgYmFzZWQgZW1lcmdlbmN5IGNhbGxpbmcgc3lzdGVtcy4NCg0KSeKAmW0gcHJlcGFyZWQg dG8gd3JpdGUgYSBkcmFmdCB0aGF0IHJlc3RvcmVzIGNvZGUgMTYgZm9yIGZsYXNoLCBhcyBpdCB3 YXMgaW4gMjgzMywgYnV0IHdhbnRlZCB0byBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGRvaW5nIHRo YXQuDQoNCkJyaWFuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K From nobody Fri Jun 10 04:24:10 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 172AA12D52C; Fri, 10 Jun 2016 04:24:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: , <3GPPLiaison@etsi.org> X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610112409.15371.73577.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 04:24:09 -0700 Archived-At: Cc: Ben Campbell , Multiparty Multimedia Session Control Discussion List , Alexey Melnikov , Flemming Andreasen Subject: [MMUSIC] New Liaison Statement, "Response to Liaison Statement to IETF MMUSIC concerning 'Improved end-to-end QoS Enhancements for MTSI'" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:24:09 -0000 Title: Response to Liaison Statement to IETF MMUSIC concerning 'Improved end-to-end QoS Enhancements for MTSI' Submission Date: 2016-06-10 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1481/ From: "Bo Burman" To: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org Cc: Flemming Andreasen ,Ben Campbell ,Alissa Cooper ,Bo Burman ,Alexey Melnikov ,Multiparty Multimedia Session Control Discussion List , Response Contacts: Flemming Andreasen ,Bo Burman Technical Contacts: Purpose: In response Referenced liaison: LS on Improved end-to-end QoS Enhancements for MTSI (https://datatracker.ietf.org/liaison/1442/) Body: IETF MMUSIC Working Group thanks 3GPP TSG SA WG4 for informing about their work in . It is understandable that SDP attribute-based approaches, such as solutions D and F in 3GPP TR 26.924, are being considered for further development. Of the alternatives proposed, use of an SDP attribute (i.e., an "a=" line) is to be preferred over use of further extensions to SDP "b=" lines. Attributes are the natural extension point for SDP, and offer flexibility that is not present in "b=" lines. This is compatible with the solutions proposed by 3GPP TR 26.924. Whether any new attribute is signalled per RTP payload type, as in solution D, or per "m=" line, as in solution F, is a more complex issue. Neither seems unreasonable on the surface, and a QoS attribute per "m=" line is natural if each "m=" line represents a single media sent on a single port, with the SDP offer/answer exchange being used only to select what encoding is used for that media. However, with the definition and widespread adoption of the SDP BUNDLE extension , the assumption that a single "m=" line represents a single type of media being sent on a single UDP port is becoming less tenable. IETF MMUSIC urges 3GPP TSG SA4 to consider the impact of the SDP BUNDLE extension on their choice, and to further coordinate with IETF to ensure that whatever is developed is compatible with SDP sessions where multiple "m=" lines, representing several different types of media, are sent on a single UDP port. Next IETF meetings: - IETF 96, July 17-22, 2016, Berlin, Germany - IETF 97, November 13-18, 2016, Seoul, South Korea Regards, Bo Burman MMUSIC WG co-chair Attachments: No document has been attached From nobody Fri Jun 10 06:21:18 2016 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 9B58512D90B for ; Fri, 10 Jun 2016 06:21:06 -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=brianrosen-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 J7Yvc5tijm_Q for ; Fri, 10 Jun 2016 06:21:04 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 DFD5012D53B for ; Fri, 10 Jun 2016 06:21:03 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id v48so17624983qgd.2 for ; Fri, 10 Jun 2016 06:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+W51QphSK2ot/dC7AxU14lnwKZBLSvHA3c+0j3aqBfw=; b=v/myGyUUlEl1jsHkTc9sVTumW7+BLueEeUjHJgtz+lmzm0tuUzGqLFsgx1ICRQIImA wjSvXa9mqYVJi2KBYw7mAYm/POLHk2T+fv5dbLAh5vsvQ9USM5UvFmtgAlk8YvAX5z8H 4qQ0y/PhUenpk+GRz0JAymTzgMRJrnHIn69mD8Ev64vMLpN35DQlUxgUpbI1FJ9+ndnH Ej4xkDZXIoc3o1f+My204euCzRyb+4hnOk9/RbTRjJrT04/IA0gsh1IQDeLZG5uExSbo 9ZYIFQ4JDML4TXscX1gCu7ZagY+kWWEArUxNM0G2bVQCRxy+8E6vYvN8IN3+ZjgpOpVs graA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+W51QphSK2ot/dC7AxU14lnwKZBLSvHA3c+0j3aqBfw=; b=jyB93qwtaDkAJoks8GQW/QanoFGAer9OQkrOBL81fPK2GxZllYsHvhY2XY89xYF+d6 HQC/q5+U9PD8DVc7E9vmj6Cz1jT5cWto7YB75vkc+U+vXqdIR502AA4Ksm9IeWzLBZbQ Qmj7tz5nFH1jTg6fqgR0Jq4UGimwoUQvsxl18qqZt0Gc1H5Un6AsCzi+tAdZfMLIQfTP ZOC9XF5P/wyom2piUzKDdUFpQKA+EASdiY0yNk3xCS6PyhutuNnXWfm+f6NbP4ujxhHs +yw3UgzpE4gEv1L5HIZiVdnNO8KKanFWG7WRdANUOhzEB/e+SUtFhqfddr9aQIJqhF8p nl/g== X-Gm-Message-State: ALyK8tJ+0bZBbzhfYG74xmRNfAFUYRx8SBAjSo1wnYtbBAUUbdu4tK+X7EQSz7maH2R6pA== X-Received: by 10.140.223.144 with SMTP id t138mr1770278qhb.16.1465564862686; Fri, 10 Jun 2016 06:21:02 -0700 (PDT) Received: from [10.33.192.47] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id t65sm3078847qkc.46.2016.06.10.06.21.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 06:21:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 10 Jun 2016 09:20:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 13:21:07 -0000 I have a system that has been in use for 40 years. We=E2=80=99re trying = to upgrade everything, but we can=E2=80=99t accomplish that overnight. = The installed system reliably creates and detects hook flash. No doubt = the reason it works more reliably here is that nearly every = implementation (probably ALL implementations, but I don=E2=80=99t know = that for certain), uses a computer to generate the hook flash. It=E2=80=99= s not a user depressing the physical switch on a black phone. Used to = be, isn=E2=80=99t any more. There isn=E2=80=99t any way to use some = alternate signaling: the interface is CAMA, and that=E2=80=99s it. At = one point there was a push to upgrade these systems to use ISDN, but = that got no where. I=E2=80=99m not sure there are any existing systems = that use ISDN. They all use CAMA. There are at least 4 brands of = gateways that successfully do the right thing. =20 Brian > On Jun 9, 2016, at 1:59 PM, Cullen Jennings (fluffy) = wrote: >=20 >=20 > I've see a lot of interop problems with hookflash. It's can be = surprisingly hard for GWs to detect. Is there any way NENA could find a = better way to do this? I'm not keen on bringing this back.=20 >=20 >=20 >> On Jun 2, 2016, at 1:02 PM, Brian Rosen wrote: >>=20 >> Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. >>=20 >> We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated. We have no other way to transport flash to = interwork with our newer SIP based emergency calling systems. >>=20 >> I=E2=80=99m prepared to write a draft that restores code 16 for = flash, as it was in 2833, but wanted to hear any objections to doing = that. >>=20 >> Brian >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 From nobody Fri Jun 10 06:33:38 2016 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 8437212D5B8 for ; Fri, 10 Jun 2016 06:33:37 -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=brianrosen-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 fBHSs1S8_8zW for ; Fri, 10 Jun 2016 06:33:36 -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 DA7E412B068 for ; Fri, 10 Jun 2016 06:33:35 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id c73so11555839qkg.2 for ; Fri, 10 Jun 2016 06:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rTjRXMvrMqi2jKOMqo3HX0Y5Vk75NblF7CLXucl79hc=; b=KamYZPKYruZhC5rdgaG6Xqq+So1sSG1H6fpPGPsYnGNiJv66dETaP1zLghU60T+DiJ 9MBgNHSCAyk9JNTBIIFf3gdZ1BASCH05HYEt6IbsLVYwPS70xSWbZj1PHuGoezDob2tn QRo4qvA2g05/eeJ6WQzWc3NayMHNnl6rwWu2Jh3wTWEQi/g19iglQjSIqt5PdfxvhL9F lOvRJxBCvbvcd1PPGviMznwRmNeeGv8hmaewR3HnapcevwEz9oG7yEWlob+zM43BtmbF +sqzXm9SVgxWktnjDcGWI4UfE2w0dmmLb2E4dB6XMtC5BIJjEgT8anyb+QDpM7NyU1OV Ferg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rTjRXMvrMqi2jKOMqo3HX0Y5Vk75NblF7CLXucl79hc=; b=l3Ct4nyS039DUz2sgWLIDz6OJtE6OzX9pZZBfh9Nl/RxZLaf4pGP7ita9M7fYgHIID KuaxYCoEimnU6CPS2sDDGPDz5fTfNfzfFbTNPARlyF47aze7Lp6BeYx0Vn0zrr7koVED i4WvmRbRn0SXqArfwdrWiVIkAYfC34S4fJ3ttPWsmlmAebY49vAxMreVZ6YGxQD25YU2 gDt/gCmBAduEDRMKvZ9Ff64XhctUOy28xgR930ROmCQSpKa2bqHML61gs/sNWbi/oL0/ q76aIcVayevz48BnZJzIj3n4x11XC2aOuT7xfNKGtCw1w6i+jksxnLytufGVPNgyZCR6 CPug== X-Gm-Message-State: ALyK8tKmgRfB4I28BvfwXGTBaIJahUrP2ruW748XSuhugFN0zrA6aRnxH37f84kgPGS4Lw== X-Received: by 10.55.66.135 with SMTP id p129mr1797953qka.176.1465565611850; Fri, 10 Jun 2016 06:33:31 -0700 (PDT) Received: from [10.33.192.47] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id v137sm671576qke.22.2016.06.10.06.33.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 06:33:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 10 Jun 2016 09:33:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2643330C-7659-4EC1-940C-240E2815E49E@brianrosen.net> References: To: Martin Taylor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 13:33:37 -0000 The gateways I=E2=80=99m familiar with can generate/accept code 16. It = may be that they can use INFO, but I=E2=80=99m not aware of it. The = gateways that are installed, AFAIK, use code 16. I have some queries = into implementors to verify, and I=E2=80=99ll report what I find. Brian > On Jun 10, 2016, at 4:49 AM, Martin Taylor = wrote: >=20 > Signalling of flash-hook is an important aspect of PSTN Emulation with = IMS. There are a bunch of mid-call services that must be supported for = POTS such as call transfer and three-way calling which rely on being = able to signal flash-hook. >=20 > In my experience, most PSTN Emulation implementations use SIP INFO = requests to signal flash-hook. To my knowledge, this has never been = standardized but there have been I-Ds on the topic, e.g. = draft-hwang-sipping-infomidcall-00 and = draft-kaplan-sip-info-use-cases-01. >=20 > Many analog telephone adapters support the SIP INFO method of = signalling flash-hook. >=20 > Martin >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: 02 June 2016 20:02 > To: mmusic@ietf.org > Subject: [MMUSIC] Transport of "Flash-hook" >=20 > Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. >=20 > We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated. We have no other way to transport flash to = interwork with our newer SIP based emergency calling systems. >=20 > I=E2=80=99m prepared to write a draft that restores code 16 for flash, = as it was in 2833, but wanted to hear any objections to doing that. >=20 > Brian > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Jun 10 06:38:46 2016 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 658A512D5B8 for ; Fri, 10 Jun 2016 06:38: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=brianrosen-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 q537ppE590HN for ; Fri, 10 Jun 2016 06:38:42 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 221DA12D5A8 for ; Fri, 10 Jun 2016 06:38:42 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id 9so18574306qtg.2 for ; Fri, 10 Jun 2016 06:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tJsP9xHZ59N0uDCld0np1h8h/6RYkS3SCoE/fCI4CVY=; b=yjWjyB92a86owZUmIr0RN/bZBYD7nah6NjHL1DHv7m9c+TFdxzZ5I/KKlsYAL+5ibf c1Mk52xMexDrbPELUDsYfD8UP+gLc7fPAxl+QoT/EJO2hH8/FEdtrZUY+fYsiHGabYEq e1yuUGCFVxmHl1AeoKiom91oHFZxk/ph4SDzHhDgpU7FFl0ipGQksFF1qi2mQsCfQtYw DHmF37V9RHA0i2/LVYaSHPH6rAKvCI9HN5WWhV6er3fAnKsLaO1tKl9fXREs0fJCIZL5 U4MeCxL2Xwm0jB2FKJHg2vlZ8cAYUh+wFDTL9mtikjPdUI1lQ5b4pniiM+89COAdHdhS T2Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tJsP9xHZ59N0uDCld0np1h8h/6RYkS3SCoE/fCI4CVY=; b=NJnDBJ5Jojq3y+4qMiaDNQfnvu7sWXgqPREfjHBcnRUgP7G26VQw0CY9ubvi2FYu2H W4YjWJqj014bt24NidkMy7EFIlZ3Xlk8nHtEPES59xfoADuL2V5zV2GORY4YhAlDsRAz ceT+rdGt0LOD0snCJGHYb6jVHGQ+xdVLmQ+4p7W+c5/wEv2SidBlV+WqRGMzXSac2sfm VN0CGrN287SUPUAqOTottgfj9Rk6ys0MnYjPefLcGSe8g6qJdbrrPaD/e5/CwgsQKOW/ TnowltpzPWLHa2l5Sz2ipdkS2w0Aj0BXPn1yXnyuFYLhxmyU3R2030RxGBFumGoNfF9P 7SFA== X-Gm-Message-State: ALyK8tJhhZTmPWsAqadxz5pA8JVcB4jGQYyArx//pKQbFaFv6CUCFJZg9aa3ZqkvbFlFBw== X-Received: by 10.200.35.233 with SMTP id r38mr1943237qtr.12.1465565921132; Fri, 10 Jun 2016 06:38:41 -0700 (PDT) Received: from [10.33.192.47] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id w67sm3114424qkd.26.2016.06.10.06.38.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 06:38:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF12A26@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 10 Jun 2016 09:38:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <118C7AEF-8509-402B-90C8-7BD0AD299318@brianrosen.net> References: <949EF20990823C4C85C18D59AA11AD8BADF12A26@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 13:38:44 -0000 Recall that 2833/4733 delivers the actual duration of the =E2=80=9Ctone=E2= =80=9D. It would do so with hook flash, and thus it is up to the = recipient to determine what the timing should be. I can put text in = that mentions the range from greater than dial pulse to less than hangup = (and thus 50-250 or so). The system can place calls, and those calls may end up on, e.g. an IVR. = So the gateway itself can=E2=80=99t gate the DTMF channel. The IWF has = to pass on DTMF that isn=E2=80=99t for it. Brian > On Jun 9, 2016, at 3:21 PM, Drage, Keith (Nokia - GB) = wrote: >=20 > I believe to bring it back you would also need to define flashhook, = unless you can find an international definition of the timings elsewhere = and reference it. >=20 > In terms of timing, a disconnect with a timing of approximately 33% of = a 100 ms cycle is a dial pulse (although I believe there are variants = that work at twice this speed. >=20 > European standards indicate a duration of 50 - 130 ms for register = recall. >=20 > Somewhere over 500 ms constitutes a hangup. >=20 > I believe I have seen PBX systems that have used the period between = 130 ms and 500 ms as a second form of hookflash - no access to my early = notes at the moment. >=20 > In more PBX related signalling systems a off hook to on hook of 140 - = 290 ms can be a wink start to indicate starting to send digits. >=20 > So the problems are more than one type of hookflash exists, and = probably a lack of definition of the timings in an international sense. >=20 > I'd also note that if we have "hookflash", why don't we have on-hook, = off hook, dial pulse, and so on.=20 >=20 > Personally, as the hookflash is to gain access to something to = transmit/receive digits, then maybe you should be turning the RTP DTMF = channel on and off if you really want to simulate it! >=20 > Keith >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen = Jennings (fluffy) > Sent: 09 June 2016 18:59 > To: Brian Rosen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Transport of "Flash-hook" >=20 >=20 > I've see a lot of interop problems with hookflash. It's can be = surprisingly hard for GWs to detect. Is there any way NENA could find a = better way to do this? I'm not keen on bringing this back.=20 >=20 >=20 >> On Jun 2, 2016, at 1:02 PM, Brian Rosen wrote: >>=20 >> Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. >>=20 >> We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated. We have no other way to transport flash to = interwork with our newer SIP based emergency calling systems. >>=20 >> I=E2=80=99m prepared to write a draft that restores code 16 for = flash, as it was in 2833, but wanted to hear any objections to doing = that. >>=20 >> Brian >> _______________________________________________ >> 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 Fri Jun 10 12:17:12 2016 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 6E5CF12D5A9 for ; Fri, 10 Jun 2016 12:17:10 -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=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 Vo3DeilNhFHF for ; Fri, 10 Jun 2016 12:17:08 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 A057A12D5D7 for ; Fri, 10 Jun 2016 12:17:08 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id e5so3251679ith.1 for ; Fri, 10 Jun 2016 12:17:08 -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=NflMdVV6y5CFRE21JuOSYwjEonuORumMEuu/KJxjwGs=; b=1xYUR94DwnqjREH8VBxlMEwwNedXt9jJPC/W4ldHpdlWUHe+jW2XjO2hAcgkmatT/o gG+SOZYo6M5z55he0lgR34Ti02vZkFhJxwSfD1d7sbyVzyDhHnSS7AOHSkSSEvgFfmtY KRVdDjva3TXE8z8g1sqy1bRoH+J/ySH6HJkoMAEJtRPvtJHU0Dm48c6i9qcLbLalmHot FdyaK/EC1susYfRfsGDomlMnOBfN2xVdIaNoJJGBQ1hSnl6cObJHiDiQsUpY9ktyr7lf AOYvn9wfoUfo/6OhL+V2ZSIL+pyKjHetJhcbn8Rrm7Edd9lcpuMTSgQwjVtgPS+d7d7x 1XLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NflMdVV6y5CFRE21JuOSYwjEonuORumMEuu/KJxjwGs=; b=NqHhKfdtZUcxc/0Q2zqGwkXXXHrS9OkeAXFOEYhf3rw+LKZW1ybG6uffrU6HPtpAkb aoVppCZegwvbhqFn9fQ7RA3w1GiZppkN1ma+E3O+vOV8OPwMf1nz8Db86N1QMddm/87v w04RCdDVNmMW+K2+jf1Y7B3dhyci3cCaGclcbhomcuARDaUC0qwxhEHD/7R5NbM5gtrC CpyHY7R6P6Orxw/gEtf6q/p/haTSuboIP40mjJlFFOLGpO3wqwggzGhDlzn9MfUqqt6P KWJluYrZnuOlrn3Q04UjAQNLV8H0mZ8SRIpDjLDvwy2GWrP8pcRzAUqZWkkrbMtPMZCU jyXg== X-Gm-Message-State: ALyK8tInqBalaaw4Y/DPWzPyJUoG34YrMpUC09LNHTauE/IIe6pEcLKKGNXlFjudmXdDng== X-Received: by 10.36.66.68 with SMTP id i65mr1049112itb.91.1465586228020; Fri, 10 Jun 2016 12:17:08 -0700 (PDT) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com. [209.85.214.48]) by smtp.gmail.com with ESMTPSA id 63sm996543ioj.41.2016.06.10.12.17.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 12:17:07 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id h190so3094136ith.1; Fri, 10 Jun 2016 12:17:07 -0700 (PDT) X-Received: by 10.36.209.5 with SMTP id w5mr1123477itg.47.1465586227229; Fri, 10 Jun 2016 12:17:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Fri, 10 Jun 2016 12:17:06 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Fri, 10 Jun 2016 15:17:06 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0b09b67641010534f1626b Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 19:17:10 -0000 --94eb2c0b09b67641010534f1626b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am ok with removing this. _____________ Roman Shpount On Thu, Jun 9, 2016 at 2:20 AM, Martin Thomson wrote: > This is unnecessary: > > When an endpoint receives one or more fingerprints from its peer, and > is about to calculate its own fingerprints, unless the endpoint has > other ways of knowing what hash functions the peer supports the > endpoint MUST calculate at least one fingerprint using a hash function > that was also used by the peer to calculate a fingerprint. In > addition, the endpoint MAY calculate fingerprints using hash functions > that were not used by the peer. > > This encourages rot. It's far easier and it can even be more secure > if endpoints generate fingerprints based on their own knowledge only. > > On 7 June 2016 at 17:35, Christer Holmberg > wrote: > > Hi, > > > > Based on the WGLC comments, I=E2=80=99ve submitted a new version (-04) = of > > draft-ietf-mmusic-4572-update. > > > > Thanks to everyone who provided input and comments! :) > > > > Regards, > > > > Christer > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c0b09b67641010534f1626b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am ok with removing this.
=
_____________
Roman Shpount

On Thu, Jun 9, 2016 at 2:20 AM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
This is unnecessary:

When an endpoint receives one or more fingerprints from its peer, and
is about to calculate its own fingerprints, unless the endpoint has
other ways of knowing what hash functions the peer supports the
endpoint MUST calculate at least one fingerprint using a hash function
that was also used by the peer to calculate a fingerprint. In
addition, the endpoint MAY calculate fingerprints using hash functions
that were not used by the peer.

This encourages rot.=C2=A0 It's far easier and it can even be more secu= re
if endpoints generate fingerprints based on their own knowledge only.

On 7 June 2016 at 17:35, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> Hi,
>
> Based on the WGLC comments, I=E2=80=99ve submitted a new version (-04)= of
> draft-ietf-mmusic-4572-update.
>
> Thanks to everyone who provided input and comments! :)
>
> Regards,
>
> Christer
>
> __________________= _____________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic >

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

--94eb2c0b09b67641010534f1626b-- From nobody Fri Jun 10 12:31:30 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB6112D58D; Fri, 10 Jun 2016 12:31:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610193127.18218.36185.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 12:31:27 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 19:31:27 -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 : Updates to RFC 4572 Author : Christer Holmberg Filename : draft-ietf-mmusic-4572-update-05.txt Pages : 7 Date : 2016-06-10 Abstract: This document updates RFC 4572 by clarifying the usage of multiple SDP 'fingerprint' attributes with a single TLS connection. The document also updates the preferred cipher suite with a stronger cipher suite, and removes the requirement to use the same hash function for calculating a certificate fingerprint that is used to calculate the certificate signature. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 10 12:32:58 2016 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 C2BB612D833; Fri, 10 Jun 2016 12:32:56 -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 Lf29T8kqHrpF; Fri, 10 Jun 2016 12:32:54 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7643912D611; Fri, 10 Jun 2016 12:32:53 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-5f-575b15e24616 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DE.7C.18043.2E51B575; Fri, 10 Jun 2016 21:32:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 21:32:09 +0200 From: Christer Holmberg To: Roman Shpount , Martin Thomson Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04 Thread-Index: AQHRwI8lmbpuUxozt0y5qDlNzfaz5p/gi2aAgAJrTgCAACWxQA== Date: Fri, 10 Jun 2016 19:32:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3804AC2E@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3804AC2EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7tO4j0ehwg3kHLS2unfnHaHF+53om i6nLH7NYzLgwldmBxWPnrLvsHkuW/GTyuDWlIIA5issmJTUnsyy1SN8ugStj97GtzAV3Iio2 3IlpYFwS1sXIySEhYCJx4dozNghbTOLCvfVANheHkMARRolPf7cwQThLGCV2PbgD5HBwsAlY SHT/0wZpEBEIkng+fT5YmFkgRmLaQi6QsLCAp8TqZzfZIEq8JCa+nAtlO0lMnTSBHcRmEVCV 2PJ4PpjNK+Arcersd1YQW0jgBKPE2lWJIDanQKDE1N5zTCA2I9Bt30+tAbOZBcQlbj2ZzwRx s4DEkj3nmSFsUYmXj/+xQthKEo1LnrBC1OdLNO18wwaxS1Di5MwnLBMYRWchGTULSdksJGWz wD7TlFi/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2 MQKj8OCW31Y7GA8+dzzEKMDBqMTD++BZZLgQa2JZcWXuIUYJDmYlEd7/gtHhQrwpiZVVqUX5 8UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhj7I49eTVgzY9X3+GeL+tSt H9Qslb8obrQv9+0t9ebzx9ynyGbbM1d/Zp0vfv2l7JNFW9OS7ETZ5Tey3lvhdUc3d24f5wHG i2dv3fdf0fvxdv+1k/1Fd43fvli44sgGtVdiixy+dn5SezVh1WMmt3fzDs94siRQgfvJRtaT +cFvDhznCKs6vud/tRJLcUaioRZzUXEiANZqUzW+AgAA Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 19:32:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3804AC2EESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIQ0KDQpJ4oCZdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0wNSksIHdpdGggdGhl IHRleHQgcmVtb3ZlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hw b3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMTAgSnVuZSAyMDE2IDIyOjE3 DQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkNjOiBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgbW11c2ljLWNo YWlyc0BpZXRmLm9yZzsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gRHJh ZnQgbmV3IHZlcnNpb246IGRyYWZ0LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLTA0DQoNCkkgYW0g b2sgd2l0aCByZW1vdmluZyB0aGlzLg0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoN Ck9uIFRodSwgSnVuIDksIDIwMTYgYXQgMjoyMCBBTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6 DQpUaGlzIGlzIHVubmVjZXNzYXJ5Og0KDQpXaGVuIGFuIGVuZHBvaW50IHJlY2VpdmVzIG9uZSBv ciBtb3JlIGZpbmdlcnByaW50cyBmcm9tIGl0cyBwZWVyLCBhbmQNCmlzIGFib3V0IHRvIGNhbGN1 bGF0ZSBpdHMgb3duIGZpbmdlcnByaW50cywgdW5sZXNzIHRoZSBlbmRwb2ludCBoYXMNCm90aGVy IHdheXMgb2Yga25vd2luZyB3aGF0IGhhc2ggZnVuY3Rpb25zIHRoZSBwZWVyIHN1cHBvcnRzIHRo ZQ0KZW5kcG9pbnQgTVVTVCBjYWxjdWxhdGUgYXQgbGVhc3Qgb25lIGZpbmdlcnByaW50IHVzaW5n IGEgaGFzaCBmdW5jdGlvbg0KdGhhdCB3YXMgYWxzbyB1c2VkIGJ5IHRoZSBwZWVyIHRvIGNhbGN1 bGF0ZSBhIGZpbmdlcnByaW50LiBJbg0KYWRkaXRpb24sIHRoZSBlbmRwb2ludCBNQVkgY2FsY3Vs YXRlIGZpbmdlcnByaW50cyB1c2luZyBoYXNoIGZ1bmN0aW9ucw0KdGhhdCB3ZXJlIG5vdCB1c2Vk IGJ5IHRoZSBwZWVyLg0KDQpUaGlzIGVuY291cmFnZXMgcm90LiAgSXQncyBmYXIgZWFzaWVyIGFu ZCBpdCBjYW4gZXZlbiBiZSBtb3JlIHNlY3VyZQ0KaWYgZW5kcG9pbnRzIGdlbmVyYXRlIGZpbmdl cnByaW50cyBiYXNlZCBvbiB0aGVpciBvd24ga25vd2xlZGdlIG9ubHkuDQoNCk9uIDcgSnVuZSAy MDE2IGF0IDE3OjM1LCBDaHJpc3RlciBIb2xtYmVyZw0KPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+ IEhpLA0KPg0KPiBCYXNlZCBvbiB0aGUgV0dMQyBjb21tZW50cywgSeKAmXZlIHN1Ym1pdHRlZCBh IG5ldyB2ZXJzaW9uICgtMDQpIG9mDQo+IGRyYWZ0LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLg0K Pg0KPiBUaGFua3MgdG8gZXZlcnlvbmUgd2hvIHByb3ZpZGVkIGlucHV0IGFuZCBjb21tZW50cyEg OikNCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPiBt bXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0Bp ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B3804AC2EESESSMB209erics_ 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 cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J4oCZdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNp b24gKC0wNSksIHdpdGggdGhlIHRleHQgcmVtb3ZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFu IFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAx MCBKdW5lIDIwMTYgMjI6MTc8YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OzsgbW11c2ljLWNoYWlyc0Bp ZXRmLm9yZzsgbW11c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lD XSBEcmFmdCBuZXcgdmVyc2lvbjogZHJhZnQtaWV0Zi1tbXVzaWMtNDU3Mi11cGRhdGUtMDQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG9rIHdpdGggcmVtb3Zpbmcg dGhpcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xl YXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biA5LCAyMDE2IGF0IDI6MjAg QU0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBpcyB1bm5lY2Vzc2FyeTo8YnI+DQo8YnI+DQpXaGVuIGFuIGVuZHBvaW50IHJlY2VpdmVz IG9uZSBvciBtb3JlIGZpbmdlcnByaW50cyBmcm9tIGl0cyBwZWVyLCBhbmQ8YnI+DQppcyBhYm91 dCB0byBjYWxjdWxhdGUgaXRzIG93biBmaW5nZXJwcmludHMsIHVubGVzcyB0aGUgZW5kcG9pbnQg aGFzPGJyPg0Kb3RoZXIgd2F5cyBvZiBrbm93aW5nIHdoYXQgaGFzaCBmdW5jdGlvbnMgdGhlIHBl ZXIgc3VwcG9ydHMgdGhlPGJyPg0KZW5kcG9pbnQgTVVTVCBjYWxjdWxhdGUgYXQgbGVhc3Qgb25l IGZpbmdlcnByaW50IHVzaW5nIGEgaGFzaCBmdW5jdGlvbjxicj4NCnRoYXQgd2FzIGFsc28gdXNl ZCBieSB0aGUgcGVlciB0byBjYWxjdWxhdGUgYSBmaW5nZXJwcmludC4gSW48YnI+DQphZGRpdGlv biwgdGhlIGVuZHBvaW50IE1BWSBjYWxjdWxhdGUgZmluZ2VycHJpbnRzIHVzaW5nIGhhc2ggZnVu Y3Rpb25zPGJyPg0KdGhhdCB3ZXJlIG5vdCB1c2VkIGJ5IHRoZSBwZWVyLjxicj4NCjxicj4NClRo aXMgZW5jb3VyYWdlcyByb3QuJm5ic3A7IEl0J3MgZmFyIGVhc2llciBhbmQgaXQgY2FuIGV2ZW4g YmUgbW9yZSBzZWN1cmU8YnI+DQppZiBlbmRwb2ludHMgZ2VuZXJhdGUgZmluZ2VycHJpbnRzIGJh c2VkIG9uIHRoZWlyIG93biBrbm93bGVkZ2Ugb25seS48YnI+DQo8YnI+DQpPbiA3IEp1bmUgMjAx NiBhdCAxNzozNSwgQ2hyaXN0ZXIgSG9sbWJlcmc8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZndDsgQmFzZWQgb24gdGhlIFdH TEMgY29tbWVudHMsIEnigJl2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTA0KSBvZjxicj4N CiZndDsgZHJhZnQtaWV0Zi1tbXVzaWMtNDU3Mi11cGRhdGUuPGJyPg0KJmd0Ozxicj4NCiZndDsg VGhhbmtzIHRvIGV2ZXJ5b25lIHdobyBwcm92aWRlZCBpbnB1dCBhbmQgY29tbWVudHMhIDopPGJy Pg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaHJpc3Rlcjxi cj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7IG1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxh IGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWM8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B3804AC2EESESSMB209erics_-- From nobody Fri Jun 10 14:30:30 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CC212D8E0; Fri, 10 Jun 2016 14:30:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610213029.18153.65288.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 14:30:29 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Ben Campbell's Yes on draft-ietf-mmusic-msid-14: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 21:30:30 -0000 Ben Campbell has entered the following ballot position for draft-ietf-mmusic-msid-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I made some editorial comments in my AD evaluation[1] that have not yet been addressed due to an email misconnect. There are no showstoppers there, so I'd like to move this along in parallel. [1] https://mailarchive.ietf.org/arch/msg/mmusic/KejxusGmZxF6IcEyKmlftpQqosw From nobody Fri Jun 10 15:16:54 2016 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 7795F12D195 for ; Fri, 10 Jun 2016 15:16:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 DdZm1xlONeY0 for ; Fri, 10 Jun 2016 15:16:52 -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 9A6FB12D0BD for ; Fri, 10 Jun 2016 15:16:52 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with SMTP id BUigbYJR58JCNBUjTb9t04; Fri, 10 Jun 2016 22:16:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465597011; bh=1RUqu/ij/+Vg+TuSz27hXIOWQM6Nzt5AgcQ9rXCKCG0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=pUG/+0sI5g/ZNwkAnul10Ai4Tz4EwyKRZmav/BkpTu8ZiN4cm5kwUFlSn8b3e3esA JIE5YTBVnVlcK5PF27AzjPf9h11cAitpt/0aFdElD42xx0IEennir888JZV9K6Bz2K enTPvJzqriIc8kTuWs4h8tVftir2DT7Av1417ZANsfLyj91IoxGzQB98laEKOs1a3K pT7yaC2Ek1Ru8Ccu8pIsqv2x1nKYtMzxHVCVUPqnawMeE0vKUa7GuIKXoYEly7zpG/ GSi92+w2Nsf0wryHBGgaj02fWXqlEYOWJXRWNWaTxqly8rUhKM3YA01mDyL/eg/9ET L4JjNI3iobMhA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id 5AGr1t0031nMCLR01AGrpL; Fri, 10 Jun 2016 22:16:51 +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 u5AMGoxC025967; Fri, 10 Jun 2016 18:16:50 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5AMGorQ025964; Fri, 10 Jun 2016 18:16:50 -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: Brian Rosen In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 10 Jun 2016 18:16:50 -0400 Message-ID: <874m903d0t.fsf@hobgoblin.ariadne.com> Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 22:16:53 -0000 Brian Rosen writes: > I have a system that has been in use for 40 years. We're trying to > upgrade everything, but we can't accomplish that overnight. The > installed system reliably creates and detects hook flash. No doubt > the reason it works more reliably here is that nearly every > implementation (probably ALL implementations, but I don't know that > for certain), uses a computer to generate the hook flash. > There are at least 4 brands of gateways that successfully do the right > thing. > Recall that 2833/4733 delivers the actual duration of the "tone". It > would do so with hook flash, and thus it is up to the recipient to > determine what the timing should be. I can put text in that mentions > the range from greater than dial pulse to less than hangup (and thus > 50-250 or so). It sounds like there is actual interoperation going on. If you can capture the specifications for achieving that from the current implementations, it seems like a reasonable candidate for standardization. (Even if we want to mark it 'deprecated'.) Dale From nobody Fri Jun 10 15:46:22 2016 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 68CE412D5B2 for ; Fri, 10 Jun 2016 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 CJ3SZMmXhbwQ for ; Fri, 10 Jun 2016 15:46:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3325212D508 for ; Fri, 10 Jun 2016 15:46:19 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A13EA35000B29; Fri, 10 Jun 2016 22:46:13 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5AMkH66019012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 22:46:17 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5AMkFpL000614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jun 2016 00:46:16 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sat, 11 Jun 2016 00:46:15 +0200 From: "Drage, Keith (Nokia - GB)" To: Brian Rosen , "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] Transport of "Flash-hook" Thread-Index: AQHRwxrtz8tbdWsSj0aiQVFSDCR/qZ/jSjPA Date: Fri, 10 Jun 2016 22:46:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF13847@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 22:46:21 -0000 SWYgdGhlIHB1cnBvc2Ugb2YgdGhpcyBjb21tZW50IGlzIHRvIGZvcmNlIGV2ZXJ5b25lIHRvIGJl IGNvbXBsaWFudCB3aXRoIHlvdXIgNDAgeWVhciBvbGQgc3lzdGVtLCB3aGljaCB5b3UgYWNrbm93 bGVkZ2UgeW91IHdhbnQgdG8gY2hhbmdlIG91dCBhbnl3YXksIHRoZW4gdGhhdCBzZWVtcyB0byBi ZSBhIHZlcnkgcG9vciBqdXN0aWZpY2F0aW9uLg0KDQpJIHdvdWxkIG5vdGUgdGhhdCBpZiB5b3Ug bmVlZCB0byBzcGVjaWZ5IGludGVyb3BlcmFiaWxpdHksIHRoZSB0aGUgb2xkIHZlcnNpb24gc3Rp bGwgZXhpc3RzIC0gaXQgaGFzIG5vdCBkaXNhcHBlYXJlZCBqdXN0IGJlY2F1c2UgYW5vdGhlciBk b2N1bWVudCBoYXMgcmVwbGFjZWQuDQoNClRvIG1lLCB5b3UgbmVlZCB0byBqdXN0aWZ5IHRoaXMg YmFzZWQgb24gYSBuZWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5IG9mIG5ldyBlcXVpcG1lbnQgaW4g dGhlIGZpZWxkLg0KDQpLZWl0aA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog bW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlh biBSb3Nlbg0KU2VudDogMTAgSnVuZSAyMDE2IDE0OjIxDQpUbzogQ3VsbGVuIEplbm5pbmdzIChm bHVmZnkpDQpDYzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gVHJhbnNw b3J0IG9mICJGbGFzaC1ob29rIg0KDQpJIGhhdmUgYSBzeXN0ZW0gdGhhdCBoYXMgYmVlbiBpbiB1 c2UgZm9yIDQwIHllYXJzLiAgV2XigJlyZSB0cnlpbmcgdG8gdXBncmFkZSBldmVyeXRoaW5nLCBi dXQgd2UgY2Fu4oCZdCBhY2NvbXBsaXNoIHRoYXQgb3Zlcm5pZ2h0LiAgVGhlIGluc3RhbGxlZCBz eXN0ZW0gcmVsaWFibHkgY3JlYXRlcyBhbmQgZGV0ZWN0cyBob29rIGZsYXNoLiAgTm8gZG91YnQg dGhlIHJlYXNvbiBpdCB3b3JrcyBtb3JlIHJlbGlhYmx5IGhlcmUgaXMgdGhhdCBuZWFybHkgZXZl cnkgaW1wbGVtZW50YXRpb24gKHByb2JhYmx5IEFMTCBpbXBsZW1lbnRhdGlvbnMsIGJ1dCBJIGRv buKAmXQga25vdyB0aGF0IGZvciBjZXJ0YWluKSwgdXNlcyBhIGNvbXB1dGVyIHRvIGdlbmVyYXRl IHRoZSBob29rIGZsYXNoLiAgSXTigJlzIG5vdCBhIHVzZXIgZGVwcmVzc2luZyB0aGUgcGh5c2lj YWwgc3dpdGNoIG9uIGEgYmxhY2sgcGhvbmUuICBVc2VkIHRvIGJlLCBpc27igJl0IGFueSBtb3Jl LiAgVGhlcmUgaXNu4oCZdCBhbnkgd2F5IHRvIHVzZSBzb21lIGFsdGVybmF0ZSBzaWduYWxpbmc6 IHRoZSBpbnRlcmZhY2UgaXMgQ0FNQSwgYW5kIHRoYXTigJlzIGl0LiAgQXQgb25lIHBvaW50IHRo ZXJlIHdhcyBhIHB1c2ggdG8gdXBncmFkZSB0aGVzZSBzeXN0ZW1zIHRvIHVzZSBJU0ROLCBidXQg dGhhdCBnb3Qgbm8gd2hlcmUuICBJ4oCZbSBub3Qgc3VyZSB0aGVyZSBhcmUgYW55IGV4aXN0aW5n IHN5c3RlbXMgdGhhdCB1c2UgSVNETi4gIFRoZXkgYWxsIHVzZSBDQU1BLiAgVGhlcmUgYXJlIGF0 IGxlYXN0IDQgYnJhbmRzIG9mIGdhdGV3YXlzIHRoYXQgc3VjY2Vzc2Z1bGx5IGRvIHRoZSByaWdo dCB0aGluZy4gICANCg0KQnJpYW4NCg0KPiBPbiBKdW4gOSwgMjAxNiwgYXQgMTo1OSBQTSwgQ3Vs bGVuIEplbm5pbmdzIChmbHVmZnkpIDxmbHVmZnlAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IA0K PiBJJ3ZlIHNlZSBhIGxvdCBvZiBpbnRlcm9wIHByb2JsZW1zIHdpdGggaG9va2ZsYXNoLiBJdCdz IGNhbiBiZSBzdXJwcmlzaW5nbHkgaGFyZCBmb3IgR1dzIHRvIGRldGVjdC4gSXMgdGhlcmUgYW55 IHdheSBORU5BIGNvdWxkIGZpbmQgYSBiZXR0ZXIgd2F5IHRvIGRvIHRoaXM/IEknbSBub3Qga2Vl biBvbiBicmluZ2luZyB0aGlzIGJhY2suIA0KPiANCj4gDQo+PiBPbiBKdW4gMiwgMjAxNiwgYXQg MTowMiBQTSwgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PiB3cm90ZToNCj4+IA0KPj4g QmFjayBpbiBSRkMyODMzLCB0aGUgRFRNRiB0b25lcyBzZWN0aW9uLCBjb2RlIDE2IHdhcyBkZWZp bmVkIGZvciDigJxGbGFzaOKAnSwgdGhlIHNpZ25hbCBjYXVzZWQgYnkgYSBtb21lbnRhcnkgZGVw cmVzc2lvbiBvZiB0aGUgaG9vay1zd2l0Y2ggaW4gYSBQT1RTIHBob25lLiAgV2hlbiAyODMzIHdh cyBvYnNvbGV0ZWQgYnkgNDczMywgZmxhc2ggd2FzIGRyb3BwZWQsIGFsdGhvdWdoIHRoZSBjb2Rl IDE2IHdhcyByZXNlcnZlZC4NCj4+IA0KPj4gV2UgaGF2ZSBhIHVzZSBjYXNlIGluIE5FTkEgKDkt MS0xIGVtZXJnZW5jeSBzdHVmZikgd2hlcmUgZXhpc3Rpbmcgc3lzdGVtcyB1c2UgZmxhc2ggaW50 ZXJzcGVyc2VkIHd0aCB0b25lcyBpbiBzaWduYWxpbmcgZGlhbGluZyBldmVudHMgd2hpY2ggYXJl IG5vdCBpbnRlcnByZXRlZCBieSB0aGUgVUEgdGhhdCByZWNlaXZlcyB0aGVtLCBidXQgYXJlIGlu c3RlYWQgdHJhbnNwb3J0ZWQgdG8gYSBkZXZpY2UgdGhhdCBjcmVhdGVzIGFwcHJvcHJpYXRlIFNJ UCBzaWduYWxpbmcgZm9yIHRoZSBkaWFsaW5nIGV2ZW50cyBpbml0aWF0ZWQuICBXZSBoYXZlIG5v IG90aGVyIHdheSB0byB0cmFuc3BvcnQgZmxhc2ggdG8gaW50ZXJ3b3JrIHdpdGggb3VyIG5ld2Vy IFNJUCBiYXNlZCBlbWVyZ2VuY3kgY2FsbGluZyBzeXN0ZW1zLg0KPj4gDQo+PiBJ4oCZbSBwcmVw YXJlZCB0byB3cml0ZSBhIGRyYWZ0IHRoYXQgcmVzdG9yZXMgY29kZSAxNiBmb3IgZmxhc2gsIGFz IGl0IHdhcyBpbiAyODMzLCBidXQgd2FudGVkIHRvIGhlYXIgYW55IG9iamVjdGlvbnMgdG8gZG9p bmcgdGhhdC4NCj4+IA0KPj4gQnJpYW4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+PiBtbXVzaWNAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+ IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11 c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K From nobody Fri Jun 10 15:46:34 2016 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 EA31712D754 for ; Fri, 10 Jun 2016 15:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 stu2AkLno6mu for ; Fri, 10 Jun 2016 15:46:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E662D12B00B for ; Fri, 10 Jun 2016 15:46:18 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 091B114F06648; Fri, 10 Jun 2016 22:46:13 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5AMkG8Q008259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 22:46:16 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5AMkGaQ007661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jun 2016 00:46:16 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sat, 11 Jun 2016 00:46:15 +0200 From: "Drage, Keith (Nokia - GB)" To: Brian Rosen Thread-Topic: [MMUSIC] Transport of "Flash-hook" Thread-Index: AQHRwnifz8tbdWsSj0aiQVFSDCR/qZ/hfHiAgAEX1gCAALfooA== Date: Fri, 10 Jun 2016 22:46:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF1384C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADF12A26@FR712WXCHMBA11.zeu.alcatel-lucent.com> <118C7AEF-8509-402B-90C8-7BD0AD299318@brianrosen.net> In-Reply-To: <118C7AEF-8509-402B-90C8-7BD0AD299318@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 22:46:23 -0000 VGhlIG9ubHkgd2F5IEkgY2FuIGludGVycHJldCB0aGF0IHdpdGhvdXQgYW55IHRpbWluZyBpbmZv cm1hdGlvbiBhdCBhbGwgaXMgdGhhdCB5b3UgYXJlIGFsc28gc2VuZGluZyB0aGlzIHNpZ25hbCBm b3IgZGVjYWRpYyBkaWFsbGluZyBwdWxzZXMsIGF0IHRoZSBzaG9ydGVyIGVuZCBvZiB0aGUgcGVy aW9kLCBhbmQgYWxzbyBzZW5kaW5nIGl0IHByaW9yIHRvIGhhbmd1cCwgd2hlcmUgdGhlIHNlbmRp bmcgZXF1aXBtZW50IGhhcyBub3QgeWV0IHNlZW4gdGhlIGRpc2Nvbm5lY3QgZm9yIGxvbmcgZW5v dWdoIHRvIGRldGVybWluZSBpdCBpcyBub3QgYSBob29rZmxhc2guIEFzIHN1Y2gsIGl0IGlzIG5v dCBhIGhvb2tmbGFzaCBzaWduYWwsIGl0IGlzIGEgbG9vcCBkaXNjb25uZWN0LCBsb29wIGNvbm5l Y3Qgc2lnbmFsLg0KDQpJJ2QgYWxzbyBub3RlIHRoYXQgYXMgdGhvc2UgdGltaW5ncyBkbyB2YXJ5 IGZyb20gY291bnRyeSB0byBjb3VudHJ5LCB0aGVyZSB3aWxsIGFsd2F5cyBiZSBpbnRlcnByZXRh dGlvbiBpbXBsaWNhdGlvbnMgcnVubmluZyB0aGlzIGFjcm9zcyBhbiBpbnRlcm5hdGlvbmFsIGJv dW5kYXJ5Lg0KDQpLZWl0aA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW11 c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBS b3Nlbg0KU2VudDogMTAgSnVuZSAyMDE2IDE0OjM5DQpUbzogRHJhZ2UsIEtlaXRoIChOb2tpYSAt IEdCKQ0KQ2M6IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KTsgbW11c2ljQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW01NVVNJQ10gVHJhbnNwb3J0IG9mICJGbGFzaC1ob29rIg0KDQpSZWNhbGwgdGhh dCAyODMzLzQ3MzMgZGVsaXZlcnMgdGhlIGFjdHVhbCBkdXJhdGlvbiBvZiB0aGUg4oCcdG9uZeKA nS4gIEl0IHdvdWxkIGRvIHNvIHdpdGggaG9vayBmbGFzaCwgYW5kIHRodXMgaXQgaXMgdXAgdG8g dGhlIHJlY2lwaWVudCB0byBkZXRlcm1pbmUgd2hhdCB0aGUgdGltaW5nIHNob3VsZCBiZS4gIEkg Y2FuIHB1dCB0ZXh0IGluIHRoYXQgbWVudGlvbnMgdGhlIHJhbmdlIGZyb20gZ3JlYXRlciB0aGFu IGRpYWwgcHVsc2UgdG8gbGVzcyB0aGFuIGhhbmd1cCAoYW5kIHRodXMgNTAtMjUwIG9yIHNvKS4N Cg0KVGhlIHN5c3RlbSBjYW4gcGxhY2UgY2FsbHMsIGFuZCB0aG9zZSBjYWxscyBtYXkgZW5kIHVw IG9uLCBlLmcuIGFuIElWUi4gIFNvIHRoZSBnYXRld2F5IGl0c2VsZiBjYW7igJl0IGdhdGUgdGhl IERUTUYgY2hhbm5lbC4gIFRoZSBJV0YgaGFzIHRvIHBhc3Mgb24gRFRNRiB0aGF0IGlzbuKAmXQg Zm9yIGl0Lg0KDQpCcmlhbg0KDQoNCj4gT24gSnVuIDksIDIwMTYsIGF0IDM6MjEgUE0sIERyYWdl LCBLZWl0aCAoTm9raWEgLSBHQikgPGtlaXRoLmRyYWdlQG5va2lhLmNvbT4gd3JvdGU6DQo+IA0K PiBJIGJlbGlldmUgdG8gYnJpbmcgaXQgYmFjayB5b3Ugd291bGQgYWxzbyBuZWVkIHRvIGRlZmlu ZSBmbGFzaGhvb2ssIHVubGVzcyB5b3UgY2FuIGZpbmQgYW4gaW50ZXJuYXRpb25hbCBkZWZpbml0 aW9uIG9mIHRoZSB0aW1pbmdzIGVsc2V3aGVyZSBhbmQgcmVmZXJlbmNlIGl0Lg0KPiANCj4gSW4g dGVybXMgb2YgdGltaW5nLCBhIGRpc2Nvbm5lY3Qgd2l0aCBhIHRpbWluZyBvZiBhcHByb3hpbWF0 ZWx5IDMzJSBvZiBhIDEwMCBtcyBjeWNsZSBpcyBhIGRpYWwgcHVsc2UgKGFsdGhvdWdoIEkgYmVs aWV2ZSB0aGVyZSBhcmUgdmFyaWFudHMgdGhhdCB3b3JrIGF0IHR3aWNlIHRoaXMgc3BlZWQuDQo+ IA0KPiBFdXJvcGVhbiBzdGFuZGFyZHMgaW5kaWNhdGUgYSBkdXJhdGlvbiBvZiA1MCAtIDEzMCBt cyBmb3IgcmVnaXN0ZXIgcmVjYWxsLg0KPiANCj4gU29tZXdoZXJlIG92ZXIgNTAwIG1zIGNvbnN0 aXR1dGVzIGEgaGFuZ3VwLg0KPiANCj4gSSBiZWxpZXZlIEkgaGF2ZSBzZWVuIFBCWCBzeXN0ZW1z IHRoYXQgaGF2ZSB1c2VkIHRoZSBwZXJpb2QgYmV0d2VlbiAxMzAgbXMgYW5kIDUwMCBtcyBhcyBh IHNlY29uZCBmb3JtIG9mIGhvb2tmbGFzaCAtIG5vIGFjY2VzcyB0byBteSBlYXJseSBub3RlcyBh dCB0aGUgbW9tZW50Lg0KPiANCj4gSW4gbW9yZSBQQlggcmVsYXRlZCBzaWduYWxsaW5nIHN5c3Rl bXMgYSBvZmYgaG9vayB0byBvbiBob29rIG9mIDE0MCAtIDI5MCBtcyBjYW4gYmUgYSB3aW5rIHN0 YXJ0IHRvIGluZGljYXRlIHN0YXJ0aW5nIHRvIHNlbmQgZGlnaXRzLg0KPiANCj4gU28gdGhlIHBy b2JsZW1zIGFyZSBtb3JlIHRoYW4gb25lIHR5cGUgb2YgaG9va2ZsYXNoIGV4aXN0cywgYW5kIHBy b2JhYmx5IGEgbGFjayBvZiBkZWZpbml0aW9uIG9mIHRoZSB0aW1pbmdzIGluIGFuIGludGVybmF0 aW9uYWwgc2Vuc2UuDQo+IA0KPiBJJ2QgYWxzbyBub3RlIHRoYXQgaWYgd2UgaGF2ZSAiaG9va2Zs YXNoIiwgd2h5IGRvbid0IHdlIGhhdmUgb24taG9vaywgb2ZmIGhvb2ssIGRpYWwgcHVsc2UsIGFu ZCBzbyBvbi4gDQo+IA0KPiBQZXJzb25hbGx5LCBhcyB0aGUgaG9va2ZsYXNoIGlzIHRvIGdhaW4g YWNjZXNzIHRvIHNvbWV0aGluZyB0byB0cmFuc21pdC9yZWNlaXZlIGRpZ2l0cywgdGhlbiBtYXli ZSB5b3Ugc2hvdWxkIGJlIHR1cm5pbmcgdGhlIFJUUCBEVE1GIGNoYW5uZWwgb24gYW5kIG9mZiBp ZiB5b3UgcmVhbGx5IHdhbnQgdG8gc2ltdWxhdGUgaXQhDQo+IA0KPiBLZWl0aA0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSkNCj4g U2VudDogMDkgSnVuZSAyMDE2IDE4OjU5DQo+IFRvOiBCcmlhbiBSb3Nlbg0KPiBDYzogbW11c2lj QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBUcmFuc3BvcnQgb2YgIkZsYXNoLWhv b2siDQo+IA0KPiANCj4gSSd2ZSBzZWUgYSBsb3Qgb2YgaW50ZXJvcCBwcm9ibGVtcyB3aXRoIGhv b2tmbGFzaC4gSXQncyBjYW4gYmUgc3VycHJpc2luZ2x5IGhhcmQgZm9yIEdXcyB0byBkZXRlY3Qu IElzIHRoZXJlIGFueSB3YXkgTkVOQSBjb3VsZCBmaW5kIGEgYmV0dGVyIHdheSB0byBkbyB0aGlz PyBJJ20gbm90IGtlZW4gb24gYnJpbmdpbmcgdGhpcyBiYWNrLiANCj4gDQo+IA0KPj4gT24gSnVu IDIsIDIwMTYsIGF0IDE6MDIgUE0sIEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4gd3Jv dGU6DQo+PiANCj4+IEJhY2sgaW4gUkZDMjgzMywgdGhlIERUTUYgdG9uZXMgc2VjdGlvbiwgY29k ZSAxNiB3YXMgZGVmaW5lZCBmb3Ig4oCcRmxhc2jigJ0sIHRoZSBzaWduYWwgY2F1c2VkIGJ5IGEg bW9tZW50YXJ5IGRlcHJlc3Npb24gb2YgdGhlIGhvb2stc3dpdGNoIGluIGEgUE9UUyBwaG9uZS4g IFdoZW4gMjgzMyB3YXMgb2Jzb2xldGVkIGJ5IDQ3MzMsIGZsYXNoIHdhcyBkcm9wcGVkLCBhbHRo b3VnaCB0aGUgY29kZSAxNiB3YXMgcmVzZXJ2ZWQuDQo+PiANCj4+IFdlIGhhdmUgYSB1c2UgY2Fz ZSBpbiBORU5BICg5LTEtMSBlbWVyZ2VuY3kgc3R1ZmYpIHdoZXJlIGV4aXN0aW5nIHN5c3RlbXMg dXNlIGZsYXNoIGludGVyc3BlcnNlZCB3dGggdG9uZXMgaW4gc2lnbmFsaW5nIGRpYWxpbmcgZXZl bnRzIHdoaWNoIGFyZSBub3QgaW50ZXJwcmV0ZWQgYnkgdGhlIFVBIHRoYXQgcmVjZWl2ZXMgdGhl bSwgYnV0IGFyZSBpbnN0ZWFkIHRyYW5zcG9ydGVkIHRvIGEgZGV2aWNlIHRoYXQgY3JlYXRlcyBh cHByb3ByaWF0ZSBTSVAgc2lnbmFsaW5nIGZvciB0aGUgZGlhbGluZyBldmVudHMgaW5pdGlhdGVk LiAgV2UgaGF2ZSBubyBvdGhlciB3YXkgdG8gdHJhbnNwb3J0IGZsYXNoIHRvIGludGVyd29yayB3 aXRoIG91ciBuZXdlciBTSVAgYmFzZWQgZW1lcmdlbmN5IGNhbGxpbmcgc3lzdGVtcy4NCj4+IA0K Pj4gSeKAmW0gcHJlcGFyZWQgdG8gd3JpdGUgYSBkcmFmdCB0aGF0IHJlc3RvcmVzIGNvZGUgMTYg Zm9yIGZsYXNoLCBhcyBpdCB3YXMgaW4gMjgzMywgYnV0IHdhbnRlZCB0byBoZWFyIGFueSBvYmpl Y3Rpb25zIHRvIGRvaW5nIHRoYXQuDQo+PiANCj4+IEJyaWFuDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbW11c2ljIG1haWxpbmcgbGlzdA0K Pj4gbW11c2ljQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QN Cm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMNCg== From nobody Fri Jun 10 19:13:50 2016 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 6F8D012D5B0 for ; Fri, 10 Jun 2016 19:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 IDZAMiks5zGK for ; Fri, 10 Jun 2016 19:13:46 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 14E8312B005 for ; Fri, 10 Jun 2016 19:13:46 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id d132so34391325oig.1 for ; Fri, 10 Jun 2016 19:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iBsQtEF8/AP6ZKNz1objpDyC3nLHMxK0m86t/r3X2jY=; b=WOX/3qYoflXUCLJVfPgNBTbRtex6/oiEPKhn1XhiILnmjFOBboiu20vlfJ/Msp3GJB t2aIbrjBRnScJyuvsl7C/WWw5ROjc1DUl9FOfJd4I5CPdvqg6Yy8lLZFGU/rEU65p7jE MenIMRT9H+CdrlbisDwtj7ND65NIr/4JdA2ycPSS9qkznsNLjkxS3sQwQB8cbPLbg/VT jdPggq64ywFlS+6PT00pvzoKs8zklP06YdwydSpIQ0092NGhhG68atgOall99x3XAcz8 o9NI8c1DX0fHnUp9IJBlF83X6MIxQGYUGNt0FkfgVAs9INkal6bwHnB5FsZ8BpzsWdkp Yk0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iBsQtEF8/AP6ZKNz1objpDyC3nLHMxK0m86t/r3X2jY=; b=Z4JkDKtbCsu0oLfvwIqcqsiPBbJ/AfWTbs8NMr8PfiU9MZ522F+0jEl7JjkAcArobW BtnsgMK3/ygAbDUniHNpp88wnCyOkoUfE+aqLMRQ3kQyLbzBVvu28YdXVcytnUb2zfMQ CIffweIDUO1tI1EYP2NRPTx6X4jwaYt557h01Q+zhlhBW4Ke9RjqAknE3Dz/cqtCDGOo kM4sBz+PF+GLKY4y467eqRemXExFsxKUaDHKM44QsS6qe4YlNOiCl68Sv+MPAQRd1B4z bZRmLLvK4sceITjM4e0lijD2YQGiP+7jTnaKkcVxWUJDjGLAunBc1gYR8E4D9qWInzP/ Quww== X-Gm-Message-State: ALyK8tKBh6wwxPBtSTS1IuwifEZ6tqGJGWNjnxEJujGKVHqb6uCZiP6W09or2320FWJAYgnFUGFvwcECL2ejOw== X-Received: by 10.202.97.214 with SMTP id v205mr2806329oib.204.1465611225472; Fri, 10 Jun 2016 19:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.29.187 with HTTP; Fri, 10 Jun 2016 19:13:44 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF13847@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADF13847@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Muthu Arul Mozhi Perumal Date: Sat, 11 Jun 2016 07:43:44 +0530 Message-ID: To: "Drage, Keith (Nokia - GB)" Content-Type: multipart/alternative; boundary=001a113d3a2679234f0534f7343e Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 02:13:48 -0000 --001a113d3a2679234f0534f7343e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about an informational path? That way NENA doesn't have to refer to an obsolete standard and no one would be forced to be complaint. Muthu On Sat, Jun 11, 2016 at 4:16 AM, Drage, Keith (Nokia - GB) < keith.drage@nokia.com> wrote: > If the purpose of this comment is to force everyone to be compliant with > your 40 year old system, which you acknowledge you want to change out > anyway, then that seems to be a very poor justification. > > I would note that if you need to specify interoperability, the the old > version still exists - it has not disappeared just because another docume= nt > has replaced. > > To me, you need to justify this based on a need for interoperability of > new equipment in the field. > > Keith > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: 10 June 2016 14:21 > To: Cullen Jennings (fluffy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Transport of "Flash-hook" > > I have a system that has been in use for 40 years. We=E2=80=99re trying = to > upgrade everything, but we can=E2=80=99t accomplish that overnight. The = installed > system reliably creates and detects hook flash. No doubt the reason it > works more reliably here is that nearly every implementation (probably AL= L > implementations, but I don=E2=80=99t know that for certain), uses a compu= ter to > generate the hook flash. It=E2=80=99s not a user depressing the physical= switch on > a black phone. Used to be, isn=E2=80=99t any more. There isn=E2=80=99t = any way to use > some alternate signaling: the interface is CAMA, and that=E2=80=99s it. = At one > point there was a push to upgrade these systems to use ISDN, but that got > no where. I=E2=80=99m not sure there are any existing systems that use I= SDN. They > all use CAMA. There are at least 4 brands of gateways that successfully = do > the right thing. > > Brian > > > On Jun 9, 2016, at 1:59 PM, Cullen Jennings (fluffy) > wrote: > > > > > > I've see a lot of interop problems with hookflash. It's can be > surprisingly hard for GWs to detect. Is there any way NENA could find a > better way to do this? I'm not keen on bringing this back. > > > > > >> On Jun 2, 2016, at 1:02 PM, Brian Rosen wrote: > >> > >> Back in RFC2833, the DTMF tones section, code 16 was defined for > =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of t= he hook-switch in > a POTS phone. When 2833 was obsoleted by 4733, flash was dropped, althou= gh > the code 16 was reserved. > >> > >> We have a use case in NENA (9-1-1 emergency stuff) where existing > systems use flash interspersed wth tones in signaling dialing events whic= h > are not interpreted by the UA that receives them, but are instead > transported to a device that creates appropriate SIP signaling for the > dialing events initiated. We have no other way to transport flash to > interwork with our newer SIP based emergency calling systems. > >> > >> I=E2=80=99m prepared to write a draft that restores code 16 for flash,= as it > was in 2833, but wanted to hear any objections to doing that. > >> > >> Brian > >> _______________________________________________ > >> 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 > --001a113d3a2679234f0534f7343e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about an informational path? That w= ay NENA doesn't have to refer to an obsolete standard and no one would = be forced to be complaint.

Muthu

O= n Sat, Jun 11, 2016 at 4:16 AM, Drage, Keith (Nokia - GB) <keith.drage= @nokia.com> wrote:
If the p= urpose of this comment is to force everyone to be compliant with your 40 ye= ar old system, which you acknowledge you want to change out anyway, then th= at seems to be a very poor justification.

I would note that if you need to specify interoperability, the the old vers= ion still exists - it has not disappeared just because another document has= replaced.

To me, you need to justify this based on a need for interoperability of new= equipment in the field.

Keith

-----Original Message-----
From: mmusic [mailto:mmusic-boun= ces@ietf.org] On Behalf Of Brian Rosen
Sent: 10 June 2016 14:21
To: Cullen Jennings (fluffy)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Transport of "Flash-hook"

I have a system that has bee= n in use for 40 years.=C2=A0 We=E2=80=99re trying to upgrade everything, bu= t we can=E2=80=99t accomplish that overnight.=C2=A0 The installed system re= liably creates and detects hook flash.=C2=A0 No doubt the reason it works m= ore reliably here is that nearly every implementation (probably ALL impleme= ntations, but I don=E2=80=99t know that for certain), uses a computer to ge= nerate the hook flash.=C2=A0 It=E2=80=99s not a user depressing the physica= l switch on a black phone.=C2=A0 Used to be, isn=E2=80=99t any more.=C2=A0 = There isn=E2=80=99t any way to use some alternate signaling: the interface = is CAMA, and that=E2=80=99s it.=C2=A0 At one point there was a push to upgr= ade these systems to use ISDN, but that got no where.=C2=A0 I=E2=80=99m not= sure there are any existing systems that use ISDN.=C2=A0 They all use CAMA= .=C2=A0 There are at least 4 brands of gateways that successfully do the ri= ght thing.

Brian

> On Jun 9, 2016, at 1:59 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
>
> I've see a lot of interop problems with hookflash. It's can be= surprisingly hard for GWs to detect. Is there any way NENA could find a be= tter way to do this? I'm not keen on bringing this back.
>
>
>> On Jun 2, 2016, at 1:02 PM, Brian Rosen <br@brianrosen.net> wrote:
>>
>> Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of the= hook-switch in a POTS phone.=C2=A0 When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved.
>>
>> We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events which = are not interpreted by the UA that receives them, but are instead transport= ed to a device that creates appropriate SIP signaling for the dialing event= s initiated.=C2=A0 We have no other way to transport flash to interwork wit= h our newer SIP based emergency calling systems.
>>
>> I=E2=80=99m prepared to write a draft that restores code 16 for fl= ash, as it was in 2833, but wanted to hear any objections to doing that. >>
>> Brian
>> _______________________________________________
>> 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

--001a113d3a2679234f0534f7343e-- From nobody Mon Jun 13 23:07:53 2016 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 BA6AD12DA1B for ; Mon, 13 Jun 2016 23:07:52 -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 fIITLvlL4Ns8 for ; Mon, 13 Jun 2016 23:07:50 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BD612D839 for ; Mon, 13 Jun 2016 23:07:49 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-84-575f9f335c56 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.54.18043.33F9F575; Tue, 14 Jun 2016 08:07:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 08:07:45 +0200 From: Christer Holmberg To: Flemming Andreasen , mmusic Thread-Topic: WGLC for draft-ietf-mmusic-dtls-sdp-13 - Christer's comment Thread-Index: AQHRxgMR2j5hFBHqEkKzeHLxv+Fv9Q== Date: Tue, 14 Jun 2016 06:07:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdUdd4fny4wab7yhbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyti2x65gDU/F3iVpDYx3ObsYOTgkBEwkvp7N 7GLkBDLFJC7cW8/WxcjFISRwhFFi1qEGFghnCaPE52PrWUAa2AQsJLr/aYM0iAi4ShxZeJcJ xBYW8JDYvf00E0TcU+Leoy4oW0/i2dSfrCA2i4CqxKevJ9lBbF4BK4lrt44zg9iMQIu/n1oD Vs8sIC5x68l8JoiDBCSW7DnPDGGLSrx8/A9sjijQzC/35jFCxBUldp5tZ4bo1ZO4MXUKG8iZ zALWEqsOK0KEtSWWLXzNDLFWUOLkzCcsExhFZyHZNgtJ9yyE7llIumch6V7AyLqKUbQ4tbg4 N93ISC+1KDO5uDg/Ty8vtWQTIzBmDm75bbWD8eBzx0OMAhyMSjy8D3Tiw4VYE8uKK3MPMUpw MCuJ8BbMBgrxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpg LE4ItHB6OilWIsjsf3LGeoV4P+eD54ttuGeYXDO9yPnUW1euVE9ah/t/pobLzTPRb52F1S8W PFbKujjpsqBExdN//80+5Bg0To7YF8H65K1masSZywWTj9ROfTdll1zPnrB7XZ3eZU27tU9l vdDMnJ69ok0w064974iZMIf+tVX5uY/tnq5RYinOSDTUYi4qTgQA9xGItZUCAAA= Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-dtls-sdp-13 - Christer's comment X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 06:07:53 -0000 Hi, I noted a small nit myself: Section 6 (ICE Considerations) says: "As defined in [RFC5763], each ICE candidate associated with a component is treated as being part of the same DTLS association. Therefore, from a DTLS perspective it is not considered a change of local transport parameters when an endpoint switches between those ICE candidates.=B2 Now, as the referenced text is moved from RFC5763 to draft-dtls-sdp, the reference shall be removed. NEW TEXT: "Each ICE candidate associated with a component is treated as being part of the same DTLS association. Therefore, from a DTLS perspective it is not considered a change of local transport parameters when an endpoint switches between those ICE candidates." Regards, Christer On 07/06/16 16:51, "Flemming Andreasen" wrote: >Greetings MMUSIC > >This is to announce a 2 week WGLC on > > https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-13.txt > >as Proposed Standard. Please note that we previously issued a WGLC on >the -06 version (in February), however since there has been a few >changes to the document subsequently, we want to give people a chance to >review those one last time. Please take a look at the document and >provide any comments you may have by Tuesday, June 21, 2016. Comments >should be sent to the document authors and the MMUSIC WG list. If you >review the document but do not have any comments, please send a note to >that effect as well. > >Thanks > >-- Flemming (MMUSIC co-chair) From nobody Mon Jun 13 23:44:54 2016 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 96E3B12DB30 for ; Mon, 13 Jun 2016 23:44:52 -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 KCO_GcSAbVoe for ; Mon, 13 Jun 2016 23:44:50 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5D112DB2F for ; Mon, 13 Jun 2016 23:44:49 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-c8-575fa7e0895c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E3.26.12926.0E7AF575; Tue, 14 Jun 2016 08:44:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 08:43:22 +0200 From: Christer Holmberg To: Christer Holmberg , Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-dtls-sdp-13 - Christer's comment Thread-Index: AQHRxgMR2j5hFBHqEkKzeHLxv+Fv9Z/olcqA Date: Tue, 14 Jun 2016 06:43:21 +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.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <65D83AF450CA6348B7183B4D2CD24AF0@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7iO6D5fHhBpMOSVu8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2PX/kXsBfNEKy4u2cfewHhDpIuRk0NCwETi wqdudghbTOLCvfVsXYxcHEICRxglLk3ZygySEBJYwijRss+7i5GDg03AQqL7nzZIWESgWmL1 u69MILawQLDE/itTmSDiIRIfbr5ih7CNJFpu/WIBsVkEVCU6OveAxXkFrCRmfvrKDDJSCMhu uAV2DqeAtUTDyXWMIDYj0DnfT60BG8ksIC5x68l8JogzBSSW7DnPDGGLSrx8/I8VxBYV0JP4 cm8eI8hICQEliWlb0yBatSS+/NjHBmFbS7Qd7oOyFSWmdD+EukZQ4uTMJywTGMVnIdk2C0n7 LCTts5C0z0LSvoCRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYJwd3PJbdQfj5TeOhxgF OBiVeHgf6MSHC7EmlhVX5h5ilOBgVhLhvbwEKMSbklhZlVqUH19UmpNafIhRmoNFSZzX/6Vi uJBAemJJanZqakFqEUyWiYNTqoGx/dA9ifeH77+Oe/JjF8/Uxa99/Q4eUdj9Y/JUQ0WnLdYf TjRUHAp157xdUqK8Xl137qpg75NyYl96vnr++qgnxlpkPGf6XO2HDXNX5l9i+HX+8KL0KVW7 +y64Li++0//65fTay8+/T916+5fatqzvZsXmqUKLFs7sadJ8/EqqsjBx2QQF6dtuvEosxRmJ hlrMRcWJAK9kc9GvAgAA Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-dtls-sdp-13 - Christer's comment X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 06:44:52 -0000 oaZhbmQgYSBzaW1pbGFyIGNoYW5nZSBpbiB0aGUgU0lQIENvbnNpZGVyYXRpb25zLg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQpPbiAxNC8wNi8xNiAwOTowNywgIm1tdXNpYyBvbiBiZWhhbGYg b2YgQ2hyaXN0ZXIgSG9sbWJlcmciDQo8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCndyb3RlOg0KDQo+SGksDQo+DQo+ SSBub3RlZCBhIHNtYWxsIG5pdCBteXNlbGY6DQo+DQo+U2VjdGlvbiA2IChJQ0UgQ29uc2lkZXJh dGlvbnMpIHNheXM6DQo+DQo+ICAgIkFzIGRlZmluZWQgaW4gW1JGQzU3NjNdLCBlYWNoIElDRSBj YW5kaWRhdGUgYXNzb2NpYXRlZCB3aXRoIGENCj4gICBjb21wb25lbnQgaXMgdHJlYXRlZCBhcyBi ZWluZyBwYXJ0IG9mIHRoZSBzYW1lIERUTFMgYXNzb2NpYXRpb24uDQo+ICAgVGhlcmVmb3JlLCBm cm9tIGEgRFRMUyBwZXJzcGVjdGl2ZSBpdCBpcyBub3QgY29uc2lkZXJlZCBhIGNoYW5nZSBvZg0K PiAgIGxvY2FsIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIHdoZW4gYW4gZW5kcG9pbnQgc3dpdGNoZXMg YmV0d2VlbiB0aG9zZQ0KPiAgIElDRSBjYW5kaWRhdGVzLqn3DQo+DQo+DQo+Tm93LCBhcyB0aGUg cmVmZXJlbmNlZCB0ZXh0IGlzIG1vdmVkIGZyb20gUkZDNTc2MyB0byBkcmFmdC1kdGxzLXNkcCwg dGhlDQo+cmVmZXJlbmNlIHNoYWxsIGJlIHJlbW92ZWQuDQo+DQo+TkVXIFRFWFQ6DQo+DQo+ICAg IkVhY2ggSUNFIGNhbmRpZGF0ZSBhc3NvY2lhdGVkIHdpdGggYSBjb21wb25lbnQgaXMgdHJlYXRl ZCBhcyBiZWluZw0KPiAgIHBhcnQgb2YgdGhlIHNhbWUgRFRMUyBhc3NvY2lhdGlvbi4gVGhlcmVm b3JlLCBmcm9tIGEgRFRMUyBwZXJzcGVjdGl2ZQ0KPiAgIGl0IGlzIG5vdCBjb25zaWRlcmVkIGEg Y2hhbmdlIG9mIGxvY2FsIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIHdoZW4gYW4NCj4gICBlbmRwb2lu dCBzd2l0Y2hlcyBiZXR3ZWVuIHRob3NlIElDRSBjYW5kaWRhdGVzLiINCj4NCj4NCj5SZWdhcmRz LA0KPg0KPkNocmlzdGVyDQo+DQo+DQo+T24gMDcvMDYvMTYgMTY6NTEsICJGbGVtbWluZyBBbmRy ZWFzZW4iIDxmYW5kcmVhc0BjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5HcmVldGluZ3MgTU1VU0lD DQo+Pg0KPj5UaGlzIGlzIHRvIGFubm91bmNlIGEgMiB3ZWVrIFdHTEMgb24NCj4+DQo+PiAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMTMudHh0 DQo+Pg0KPj5hcyBQcm9wb3NlZCBTdGFuZGFyZC4gUGxlYXNlIG5vdGUgdGhhdCB3ZSBwcmV2aW91 c2x5IGlzc3VlZCBhIFdHTEMgb24NCj4+dGhlIC0wNiB2ZXJzaW9uIChpbiBGZWJydWFyeSksIGhv d2V2ZXIgc2luY2UgdGhlcmUgaGFzIGJlZW4gYSBmZXcNCj4+Y2hhbmdlcyB0byB0aGUgZG9jdW1l bnQgc3Vic2VxdWVudGx5LCB3ZSB3YW50IHRvIGdpdmUgcGVvcGxlIGEgY2hhbmNlIHRvDQo+PnJl dmlldyB0aG9zZSBvbmUgbGFzdCB0aW1lLiBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIGRvY3Vt ZW50IGFuZA0KPj5wcm92aWRlIGFueSBjb21tZW50cyB5b3UgbWF5IGhhdmUgYnkgVHVlc2RheSwg SnVuZSAyMSwgMjAxNi4gQ29tbWVudHMNCj4+c2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50 IGF1dGhvcnMgYW5kIHRoZSBNTVVTSUMgV0cgbGlzdC4gSWYgeW91DQo+PnJldmlldyB0aGUgZG9j dW1lbnQgYnV0IGRvIG5vdCBoYXZlIGFueSBjb21tZW50cywgcGxlYXNlIHNlbmQgYSBub3RlIHRv DQo+PnRoYXQgZWZmZWN0IGFzIHdlbGwuDQo+Pg0KPj5UaGFua3MNCj4+DQo+Pi0tIEZsZW1taW5n IChNTVVTSUMgY28tY2hhaXIpDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+bW11c2ljQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K From nobody Tue Jun 14 08:52:19 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A2912D549; Tue, 14 Jun 2016 08:52:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614155217.19195.90094.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 08:52:17 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Joel Jaeggli's No Objection on draft-ietf-mmusic-msid-14: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 15:52:18 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-mmusic-msid-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Susan Hares performed the opsdir review. Copied here for completeness as it hasn't been addressed yet. --- I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Status: Almost ready to go, 2 minor concerns, NIT General comment: Document and concept are generally clear. Thank you for providing a simple solution to this problem. Caveat: My expertise is at lower end of the stack. I cross referenced all the WebRTC documentation, but I’ve missed how implementations provide feedback that this protocols is up and working. Therefore, I’ve indicated the operational issues as a set of questions for the authors to consider. Minor concern: 1) Error handling: Is it possible that the msid-value, msid-id, and msid-appdata can be inserted, and then received with values that are not valid (1*64token-char]? a. If so, an error sequence is necessary. b. If not, it is important to explain why not Add section to 3.2 2) Operational issues: A few questions for your to consider to provide the link to operational issues. Normal operational: How does the person who is utilizing this protocol in WebRTC situation check the status of the protocols? Is it part of the WebRTC status information that the implementations provide? If so, is there any common management parameters that you can suggest? Is this in another document in IETF or W3C? Error operations: If you can have errors, how does the person who utilizes this protocol in WebRTC find out the error rate. Again, is it part of the WebRTC status information on errors? Is it in another document W3C? Editorial NITS: Page 7, section 3.1 Paragraph 2: double “,†in the section highlighted makes this sentence’s meaning unclear. Are these two sub-thoughts? If not two sub-thoughts, then perhaps the /new/ suggested text. When MSID is used, the only time this can happen is when, at a time subsequent to the initial negotiation, a negotiation is performed where the answerer adds a MediaStreamTrack to an already established connection and starts sending data before the answer is received by the offerer. For initial negotiation, packets won't flow until the ICE candidates and fingerprints have been exchanged, so this is not an issue. /new suggested/ When MSID is used, the only time this can happen is at a time subsequent to the initial negotiation, / Paragraph 3 Pagination makes the following text difficult. Repagination in /new/ may help. Or it may highlight where I was confused by your document. /old/ The recipient of those packets will perform the following steps: o When RTP packets are initially received, it will create an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType), and use the MID RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate the RTP packets with a specific media section. If the connection is not in the RTCSignalingState "stable", it will wait at this point. o When the connection is in the RTCSignalingState "stable", it will look at the relevant media section to find the msid attribute. o If there is an msid attribute, it will use that attribute to populate the "id" field of the MediaStreamTrack and associated MediaStreams, as described above. o If there is no msid attribute, the identifier of the MediaStreamTrack will be set to a randomly generated string, and it will be signalled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". o After deciding on the "id" field to be applied to the MediaStreamTrack, the track will be signalled to the user. / /new/ The recipient of those packets will perform the following steps: o When RTP packets are initially received, it will create an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType), and use the MID RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate the RTP packets with a specific media section. - If the connection is not in the RTCSignalingState "stable", it will wait at this point. - When the connection is in the RTCSignalingState "stable", it will look at the relevant media section to find the msid attribute. · Looking a Media section: o If there is an msid attribute, it will use that attribute to populate the "id" field of the MediaStreamTrack and associated MediaStreams, as described above. o If there is no msid attribute, the identifier of the MediaStreamTrack will be set to a randomly generated string, and it will be signalled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". o After deciding on the "id" field to be applied to the MediaStreamTrack, the track will be signalled to the user. / _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir From nobody Tue Jun 14 09:42:36 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC8912D822; Tue, 14 Jun 2016 09:42:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614164231.19187.68495.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 09:42:31 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Alissa Cooper's Yes on draft-ietf-mmusic-msid-14: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:42:31 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-mmusic-msid-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 2 = OLD Multiple media descriptions with the same value for msid-id and msid- appdata is not permitted. NEW Multiple media descriptions with the same combination of msid-id and msid- appdata are not permitted. = Section 3 = s/and when the corresponding media description is disabled/or when the corresponding media description is disabled/ From nobody Tue Jun 14 09:45:01 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E09912D597; Tue, 14 Jun 2016 09:44:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614164459.19274.66428.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 09:44:59 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Benoit Claise's No Objection on draft-ietf-mmusic-msid-14: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:44:59 -0000 Benoit Claise has entered the following ballot position for draft-ietf-mmusic-msid-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No sure the following is useful information: This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. First time I see this in an abstract. From nobody Wed Jun 15 08:19:32 2016 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 E8BF112D8DA; Wed, 15 Jun 2016 08:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 PKcGa9EpHhF8; Wed, 15 Jun 2016 08:19:28 -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 E811312D1E3; Wed, 15 Jun 2016 08:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11625; q=dns/txt; s=iport; t=1466003951; x=1467213551; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+MqkJmr3hRJ+jyK64pB2XFGYKeYn0mzPZE5Wz+OitJ4=; b=abpQh/HVoa3022izk5bAuTaTmtLJhuotpVCWqu44XddXGA+AabUvI5pc Ok7c+CCxdjR9BmJMzGZK44spuDj4DQzJLt3znP8GG9nHQ8gSRDaqRbxdp UOxppwFiaCLnuAR81wSm3hGCAoQrD6UKQemeNvTgXWTiUallibLumIreP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAgCAcWFX/4gNJK1dgnBOVitSrmqHA?= =?us-ascii?q?YUBgXkXAQqFK0oCgTE4FAEBAQEBAQFlJ4RLAQEBBAEBASAKQQsFCwsRBAEBASc?= =?us-ascii?q?DAgIhBh8JCAYBDAYCAQGIEgMXDq4gjQYNg3MBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEXBYYngXeCVoJDgjOCS4JaBYhsiliEcTSML4F6gWmEUoMKhV2GTYE6h20eNoI?= =?us-ascii?q?GHYFoIDKKCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,476,1459814400"; d="scan'208,217";a="118964031" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 15:19:10 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5FFJAEc020907; Wed, 15 Jun 2016 15:19:10 GMT To: Christer Holmberg , Roman Shpount , Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B3804AC2E@ESESSMB209.ericsson.se> From: Flemming Andreasen Message-ID: Date: Wed, 15 Jun 2016 11:19:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3804AC2E@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------BE4411582ADADA156B0F4D4F" Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:19:30 -0000 This is a multi-part message in MIME format. --------------BE4411582ADADA156B0F4D4F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I take it everybody is ok with the updated draft at this point. If not, please let us know by end of this week (June 19). Thanks -- Flemming (MMUSIC co-chair) On 6/10/16 3:32 PM, Christer Holmberg wrote: > > Thanks! > > I’ve submitted a new version (-05), with the text removed. > > Regards, > > Christer > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 10 June 2016 22:17 > *To:* Martin Thomson > *Cc:* Christer Holmberg ; > mmusic-chairs@ietf.org; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Draft new version: > draft-ietf-mmusic-4572-update-04 > > I am ok with removing this. > > > _____________ > Roman Shpount > > On Thu, Jun 9, 2016 at 2:20 AM, Martin Thomson > > wrote: > > This is unnecessary: > > When an endpoint receives one or more fingerprints from its peer, and > is about to calculate its own fingerprints, unless the endpoint has > other ways of knowing what hash functions the peer supports the > endpoint MUST calculate at least one fingerprint using a hash function > that was also used by the peer to calculate a fingerprint. In > addition, the endpoint MAY calculate fingerprints using hash functions > that were not used by the peer. > > This encourages rot. It's far easier and it can even be more secure > if endpoints generate fingerprints based on their own knowledge only. > > On 7 June 2016 at 17:35, Christer Holmberg > > > wrote: > > Hi, > > > > Based on the WGLC comments, I’ve submitted a new version (-04) of > > draft-ietf-mmusic-4572-update. > > > > Thanks to everyone who provided input and comments! :) > > > > Regards, > > > > Christer > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------BE4411582ADADA156B0F4D4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I take it everybody is ok with the updated draft at this point. If not, please let us know by end of this week (June 19).

Thanks

-- Flemming (MMUSIC co-chair)



On 6/10/16 3:32 PM, Christer Holmberg wrote:

Thanks!

 

I’ve submitted a new version (-05), with the text removed.

 

Regards,

 

Christer

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 10 June 2016 22:17
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; mmusic-chairs@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-04

 

I am ok with removing this.


_____________
Roman Shpount

 

On Thu, Jun 9, 2016 at 2:20 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

This is unnecessary:

When an endpoint receives one or more fingerprints from its peer, and
is about to calculate its own fingerprints, unless the endpoint has
other ways of knowing what hash functions the peer supports the
endpoint MUST calculate at least one fingerprint using a hash function
that was also used by the peer to calculate a fingerprint. In
addition, the endpoint MAY calculate fingerprints using hash functions
that were not used by the peer.

This encourages rot.  It's far easier and it can even be more secure
if endpoints generate fingerprints based on their own knowledge only.

On 7 June 2016 at 17:35, Christer Holmberg

<christer.holmberg@ericsson.com> wrote:
> Hi,
>
> Based on the WGLC comments, I’ve submitted a new version (-04) of
> draft-ietf-mmusic-4572-update.
>
> Thanks to everyone who provided input and comments! :)
>
> Regards,
>
> Christer
>

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

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

 


--------------BE4411582ADADA156B0F4D4F-- From nobody Wed Jun 15 08:19:57 2016 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 69A2A12D548 for ; Wed, 15 Jun 2016 08:19:55 -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=brianrosen-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 ITIiBi4HBKNc for ; Wed, 15 Jun 2016 08:19:53 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CAF12D56D for ; Wed, 15 Jun 2016 08:19:42 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id p10so22214830qke.3 for ; Wed, 15 Jun 2016 08:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=0gP9SnBOnKdlDTabRdyMzFnqFBjMu77jruS58iySnCM=; b=kdzevJEL0eBqxzpKIDP0VdlDDt6q1ThHhIcawBV3eCsJo81YesYNPbtzH+OCwAXdUr BPHp1maHwP11vGbvHXLAf/RryoHd5fnUSP2pMm6CleiYpT9AcMnFzsua/Wm/COnymH5q lJFXJKrloFQuPbAUDIn1XGE7IzgV1tvsEDSv2T8CSfVA/IkkQds+nz6a6RDwSlu/ylq+ Q+GV8tkGBXE1LkcD1N/tpd5F5BwQsXNY8suOVe1IQJRiDDJYpcLRjV+YED8qmmzHFvDX uQqbGAbiyhltalzyaMqTn8olssenh/NzhaJ02YHnrK5XNXvYbpRpyMQ/YjgOzaFMlasZ WT4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0gP9SnBOnKdlDTabRdyMzFnqFBjMu77jruS58iySnCM=; b=lh+kC3p9oIxmCzTtW0Btk5ufe2SALFElFpNdCEvYZsuWUo1ipRxwh+0Ynmesq8q92M H7YqAmgtR/nzFfTy9DahS8uhEfLtbEgW8Od748fzf8vgW6qR5/i8v96Z8qYNeXA5LhUh 8I75R6tW9DYRZ4c39Q93K3jlaf93b0OyqM0W0CtGudUWFAGZHYIK79/aFDlg690bkUI/ NcHW55Vbq7ml10XUx22yS/5OYLDj17/cDEWpXqgdPNwDRR/fT/cwZfS/ZIaOm4olaSOn FE12LSrFwePlHfQCzOmCcmpW9AhKqwpcJFWxF1uzvCSwCk2Db1wWuwr5OhskhrT3FoND 3SsA== X-Gm-Message-State: ALyK8tKyotmByFb2usV9o/SZNNOB38UYHxOifJo+fAcA7xvYyAjJ+fK05TFAb0n7jrTcPA== X-Received: by 10.55.120.196 with SMTP id t187mr25183675qkc.6.1466003981517; Wed, 15 Jun 2016 08:19:41 -0700 (PDT) Received: from [10.33.192.47] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id y67sm9575153qhb.43.2016.06.15.08.19.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 08:19:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_767D7684-5A47-43C0-9AF3-30AAA602F4B6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Wed, 15 Jun 2016 11:19:37 -0400 Message-Id: <284015BF-8807-43C1-9241-4CF7B85D569F@brianrosen.net> References: <949EF20990823C4C85C18D59AA11AD8BADF13847@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Muthu Arul Mozhi Perumal X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "mmusic@ietf.org" , "Drage, Keith \(Nokia - GB\)" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:19:55 -0000 --Apple-Mail=_767D7684-5A47-43C0-9AF3-30AAA602F4B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Muthu, I propose an Informational document. Keith, I need to build a new box, which works with existing gateways and = existing PSAP equipment. The gateways implement 2833, which is still an = RFC, but is declared obsolete. 4733 didn=E2=80=99t drop code 16 because = there was a problem: it appears to be an oversight and/or lack of = documented use. I have a documented use. I need to write a new spec. = I could always reference 2833. If this was the IETF rather than NENA, I = wouldn=E2=80=99t be allowed to create a new RFC with a normative = reference to an obsolete RFC without a really good reason. Instead, I = would be asked to do what I=E2=80=99m proposing to to; fix the problem = by reserving Code 16 for hook flash. Having said that, I have inquired and determined that some gateways = indeed use INFO, rather than code 16. Some do use code 16. I=E2=80=99m = going to discuss this within NENA and decide what to request of IETF = based on this. Brian > On Jun 10, 2016, at 10:13 PM, Muthu Arul Mozhi Perumal = wrote: >=20 > How about an informational path? That way NENA doesn't have to refer = to an obsolete standard and no one would be forced to be complaint. >=20 > Muthu >=20 > On Sat, Jun 11, 2016 at 4:16 AM, Drage, Keith (Nokia - GB) = > wrote: > If the purpose of this comment is to force everyone to be compliant = with your 40 year old system, which you acknowledge you want to change = out anyway, then that seems to be a very poor justification. >=20 > I would note that if you need to specify interoperability, the the old = version still exists - it has not disappeared just because another = document has replaced. >=20 > To me, you need to justify this based on a need for interoperability = of new equipment in the field. >=20 > Keith >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org = ] On Behalf Of Brian Rosen > Sent: 10 June 2016 14:21 > To: Cullen Jennings (fluffy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Transport of "Flash-hook" >=20 > I have a system that has been in use for 40 years. We=E2=80=99re = trying to upgrade everything, but we can=E2=80=99t accomplish that = overnight. The installed system reliably creates and detects hook = flash. No doubt the reason it works more reliably here is that nearly = every implementation (probably ALL implementations, but I don=E2=80=99t = know that for certain), uses a computer to generate the hook flash. = It=E2=80=99s not a user depressing the physical switch on a black phone. = Used to be, isn=E2=80=99t any more. There isn=E2=80=99t any way to use = some alternate signaling: the interface is CAMA, and that=E2=80=99s it. = At one point there was a push to upgrade these systems to use ISDN, but = that got no where. I=E2=80=99m not sure there are any existing systems = that use ISDN. They all use CAMA. There are at least 4 brands of = gateways that successfully do the right thing. >=20 > Brian >=20 > > On Jun 9, 2016, at 1:59 PM, Cullen Jennings (fluffy) = > wrote: > > > > > > I've see a lot of interop problems with hookflash. It's can be = surprisingly hard for GWs to detect. Is there any way NENA could find a = better way to do this? I'm not keen on bringing this back. > > > > > >> On Jun 2, 2016, at 1:02 PM, Brian Rosen > wrote: > >> > >> Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression of = the hook-switch in a POTS phone. When 2833 was obsoleted by 4733, flash = was dropped, although the code 16 was reserved. > >> > >> We have a use case in NENA (9-1-1 emergency stuff) where existing = systems use flash interspersed wth tones in signaling dialing events = which are not interpreted by the UA that receives them, but are instead = transported to a device that creates appropriate SIP signaling for the = dialing events initiated. We have no other way to transport flash to = interwork with our newer SIP based emergency calling systems. > >> > >> I=E2=80=99m prepared to write a draft that restores code 16 for = flash, as it was in 2833, but wanted to hear any objections to doing = that. > >> > >> Brian > >> _______________________________________________ > >> 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 = > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = >=20 --Apple-Mail=_767D7684-5A47-43C0-9AF3-30AAA602F4B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Muthu, I propose an Informational document.

Keith, I need to build a new box, which = works with existing gateways and existing PSAP equipment.  The = gateways implement 2833, which is still an RFC, but is declared = obsolete.  4733 didn=E2=80=99t drop code 16 because there was a = problem: it appears to be an oversight and/or lack of documented use. =  I have a documented use.  I need to write a new spec.  I = could always reference 2833.  If this was the IETF rather than = NENA, I wouldn=E2=80=99t be allowed to create a new RFC with a =  normative reference to an obsolete RFC without a really good = reason.  Instead, I would be asked to do what I=E2=80=99m proposing = to to; fix the problem by reserving Code 16 for hook flash.

Having said that, I have = inquired and determined that some gateways indeed use INFO, rather than = code 16.  Some do use code 16.  I=E2=80=99m going to discuss = this within NENA and decide what to request of IETF based on = this.

Brian


On Jun 10, 2016, at 10:13 PM, = Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

How = about an informational path? That way NENA doesn't have to refer to an = obsolete standard and no one would be forced to be complaint.

Muthu

On = Sat, Jun 11, 2016 at 4:16 AM, Drage, Keith (Nokia - GB) <keith.drage@nokia.com> wrote:
If the purpose of this = comment is to force everyone to be compliant with your 40 year old = system, which you acknowledge you want to change out anyway, then that = seems to be a very poor justification.

I would note that if you need to specify interoperability, the the old = version still exists - it has not disappeared just because another = document has replaced.

To me, you need to justify this based on a need for interoperability of = new equipment in the field.

Keith

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: 10 June 2016 14:21
To: Cullen Jennings (fluffy)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Transport of "Flash-hook"

I have a system that has = been in use for 40 years.  We=E2=80=99re trying to upgrade = everything, but we can=E2=80=99t accomplish that overnight.  The = installed system reliably creates and detects hook flash.  No doubt = the reason it works more reliably here is that nearly every = implementation (probably ALL implementations, but I don=E2=80=99t know = that for certain), uses a computer to generate the hook flash.  = It=E2=80=99s not a user depressing the physical switch on a black = phone.  Used to be, isn=E2=80=99t any more.  There isn=E2=80=99t= any way to use some alternate signaling: the interface is CAMA, and = that=E2=80=99s it.  At one point there was a push to upgrade these = systems to use ISDN, but that got no where.  I=E2=80=99m not sure = there are any existing systems that use ISDN.  They all use = CAMA.  There are at least 4 brands of gateways that successfully do = the right thing.

Brian

> On Jun 9, 2016, at 1:59 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> = wrote:
>
>
> I've see a lot of interop problems with hookflash. It's can be = surprisingly hard for GWs to detect. Is there any way NENA could find a = better way to do this? I'm not keen on bringing this back.
>
>
>> On Jun 2, 2016, at 1:02 PM, Brian Rosen <br@brianrosen.net> = wrote:
>>
>> Back in RFC2833, the DTMF tones section, code 16 was defined = for =E2=80=9CFlash=E2=80=9D, the signal caused by a momentary depression = of the hook-switch in a POTS phone.  When 2833 was obsoleted by = 4733, flash was dropped, although the code 16 was reserved.
= >>
>> We have a use case in NENA (9-1-1 emergency stuff) where = existing systems use flash interspersed wth tones in signaling dialing = events which are not interpreted by the UA that receives them, but are = instead transported to a device that creates appropriate SIP signaling = for the dialing events initiated.  We have no other way to = transport flash to interwork with our newer SIP based emergency calling = systems.
>>
>> I=E2=80=99m prepared to write a draft that restores code 16 for = flash, as it was in 2833, but wanted to hear any objections to doing = that.
>>
>> Brian
>> _______________________________________________
>> 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
=


= --Apple-Mail=_767D7684-5A47-43C0-9AF3-30AAA602F4B6-- From nobody Thu Jun 16 04:39:43 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 152FB12D192; Thu, 16 Jun 2016 04:39:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160616113938.10476.41211.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2016 04:39:38 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-msid-14: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:39:38 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-mmusic-msid-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm not sure that the answer to this question will require any change to the document but wanted to check... I wondered about the privacy properties of these (and related) WebRTC identifiers, esp. if they are being handled at various different layers. Is there work somewhere in the WebRTC space that's analysing that? For example, one concern might be that msid-appdata could end up with some kind of privacy sensitive value, but there's no guidance here about that and as the examples use UUIDs it's not clear to me those represent nor what typical values will be used. (Note: I'm not saying that I believe this is a problem, I'm just checking if it's been considered.) I hope that there's no reason why these can't be very ephemeral values that don't identify (or help re-identification of) people or their preferences, locations etc., and I'd imagine there's little reason to e.g. log them. If that's the case wouldn't it be useful to add such guidance (somewhere, maybe not here) to help developers to do the right thing? From nobody Thu Jun 16 07:20:21 2016 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 0D7E012D760; Thu, 16 Jun 2016 07:20:14 -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, 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 (1024-bit key) header.d=cooperw.in header.b=Abj0U5J0; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=t9JeJUKA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAUzramUpwmu; Thu, 16 Jun 2016 07:20:12 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1454D12D773; Thu, 16 Jun 2016 07:20:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 65A802049A; Thu, 16 Jun 2016 10:20:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 16 Jun 2016 10:20:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=44j0r NguXSFBAyI9oicdAvf/+d4=; b=Abj0U5J01u8az+A6GVjDgO4pN8f5ui5VhTdKe nPOosVSY1hiMptIlOeARdZR7d8EGE5hByXBOZAwcDJF3I+ImXDjGbL443cS5cTVW l9L8vJSHMDDA2xqQPslxsQ8ccqvRhnPcpfpkR4Ebz6DoX66Y66IrCnH3KONR0f4B A6z9tk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=44j0rNguXSFBAyI9oicdAvf/+d4=; b=t9JeJ UKA8Uf+bGaB5CmEzXvnPtvaEmDmIKzjza2hNX8Onnrb/2VM8GJOU5G74aeMr9yBR EJc1INkI65JKtq4DiW69gkNLm3diReT2GXb1sQQ7A2Ue2afON/l+zD7u57uZd3BE afsuWOWxjgy5bMu6sKoEsoBDZCebk+UhS+bxZk= X-Sasl-enc: zv7dwfCpEzBYkmtkSlpQGs8wxs6w/MpDxtJt1Gvqa04G 1466086810 Received: from sjc-alcoop-88111.cisco.com (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id EEC32F2A03; Thu, 16 Jun 2016 10:20:08 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_91766EE7-2626-43A5-B2C9-56A998344F8D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20160616113938.10476.41211.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2016 07:20:07 -0700 Message-Id: <547EB0D6-0F63-4334-9D06-F15C5EF607C0@cooperw.in> References: <20160616113938.10476.41211.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, IESG , mmusic@ietf.org Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-msid-14: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:20:14 -0000 --Apple-Mail=_91766EE7-2626-43A5-B2C9-56A998344F8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 16, 2016, at 4:39 AM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-mmusic-msid-14: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > I'm not sure that the answer to this question will require any > change to the document but wanted to check...=20 >=20 > I wondered about the privacy properties of these (and related) > WebRTC identifiers, esp. if they are being handled at various > different layers. Is there work somewhere in the WebRTC space > that's analysing that? For example, one concern might be that > msid-appdata could end up with some kind of privacy sensitive > value, but there's no guidance here about that and as the > examples use UUIDs it's not clear to me those represent nor what > typical values will be used. (Note: I'm not saying that I > believe this is a problem, I'm just checking if it's been > considered.) I wonder if adding a reference to = https://www.w3.org/TR/mediacapture-streams/#dom-mediastream-id = or = parroting that guidance would help. Alissa >=20 > I hope that there's no reason why these can't be very ephemeral > values that don't identify (or help re-identification of) people > or their preferences, locations etc., and I'd imagine there's > little reason to e.g. log them. If that's the case wouldn't it > be useful to add such guidance (somewhere, maybe not here) > to help developers to do the right thing? >=20 >=20 >=20 >=20 --Apple-Mail=_91766EE7-2626-43A5-B2C9-56A998344F8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 16, 2016, at 4:39 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Stephen Farrell has entered the following ballot position = for
draft-ietf-mmusic-msid-14: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------


I'm not sure that = the answer to this question will require any
change to the = document but wanted to check...

I wondered = about the privacy properties of these (and related)
WebRTC = identifiers, esp. if they are being handled at various
different layers. Is there work somewhere in the WebRTC = space
that's analysing that? For example, one concern = might be that
msid-appdata could end up with some kind of = privacy sensitive
value, but there's no guidance here = about that and as the
examples use UUIDs it's not clear to = me those represent nor what
typical values will be used. = (Note: I'm not saying that I
believe this is a problem, = I'm just checking if it's been
considered.)




I hope that = there's no reason why these can't be very ephemeral
values = that don't identify (or help re-identification of) people
or= their preferences, locations etc., and I'd imagine there's
little reason to e.g. log them. If that's the case wouldn't = it
be useful to add such guidance (somewhere, maybe not = here)
to help developers to do the right thing?





= --Apple-Mail=_91766EE7-2626-43A5-B2C9-56A998344F8D-- From nobody Thu Jun 16 07:22:06 2016 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 C007712D7A2; Thu, 16 Jun 2016 07:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK5t_Aww5wUE; Thu, 16 Jun 2016 07:21:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD9D12D760; Thu, 16 Jun 2016 07:21:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E1DF0BE2D; Thu, 16 Jun 2016 15:21:55 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoJCx5v6TeZX; Thu, 16 Jun 2016 15:21:55 +0100 (IST) Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5B97BBE2C; Thu, 16 Jun 2016 15:21:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466086915; bh=RClznLEW4iaBOkniJjwqWgokb7Xpa42T1XtgFUZTKuo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=leEG8Pvqdhf6WM3rY8VbDfBxHd1jFSE9AyNrlepyko7hjFCpnAalYSw8KmFvxyMiB eIR9WqPRS5J1SG/EFGjmJ1wMpXs2UyBxVSdIpZewl3rRWnFJ3HUuEyook+RSFe2nMc n9hpU4XanyyEdOscU5tcLmSb38oR1e67EUG++SDQ= To: Alissa Cooper References: <20160616113938.10476.41211.idtracker@ietfa.amsl.com> <547EB0D6-0F63-4334-9D06-F15C5EF607C0@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5762B602.8030502@cs.tcd.ie> Date: Thu, 16 Jun 2016 15:21:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <547EB0D6-0F63-4334-9D06-F15C5EF607C0@cooperw.in> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070006090609070608020003" Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, IESG , mmusic@ietf.org Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-msid-14: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:21:59 -0000 This is a cryptographically signed message in MIME format. --------------ms070006090609070608020003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/06/16 15:20, Alissa Cooper wrote: >=20 >> On Jun 16, 2016, at 4:39 AM, Stephen Farrell wrote: >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-mmusic-msid-14: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> I'm not sure that the answer to this question will require any >> change to the document but wanted to check...=20 >> >> I wondered about the privacy properties of these (and related) >> WebRTC identifiers, esp. if they are being handled at various >> different layers. Is there work somewhere in the WebRTC space >> that's analysing that? For example, one concern might be that >> msid-appdata could end up with some kind of privacy sensitive >> value, but there's no guidance here about that and as the >> examples use UUIDs it's not clear to me those represent nor what >> typical values will be used. (Note: I'm not saying that I >> believe this is a problem, I'm just checking if it's been >> considered.) >=20 > I wonder if adding a reference to https://www.w3.org/TR/mediacapture-st= reams/#dom-mediastream-id or parroting that guidance would help. >=20 That'd certainly be good enough to clear the discuss. I'd still be interested in an answer to the general question as well, but that'd not be blocking. Cheers, S. > Alissa >=20 >> >> I hope that there's no reason why these can't be very ephemeral >> values that don't identify (or help re-identification of) people >> or their preferences, locations etc., and I'd imagine there's >> little reason to e.g. log them. If that's the case wouldn't it >> be useful to add such guidance (somewhere, maybe not here) >> to help developers to do the right thing? >> >> >> >> >=20 >=20 --------------ms070006090609070608020003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MTYx NDIxNTRaMC8GCSqGSIb3DQEJBDEiBCDSZNTmatisHh/OE5q3lsObqlsMfBHk0TkQh5lgkhLi CjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQByefIa2YdKSRIdiHOHp2fzz2HMX857sCGGfJZZ4nzZ+/NDT3h7RhUW 5in4PJkKmX9m0Ci2tExISmFW7nfnsVbte/HQmdfH19H7Zseb46HsmHlprSLmWe7ppyEOvtYa M4tSlJh3duN4i/npCH67pjS/63YRWPbuFPXYmeV8CaMOKQoVrGKbfWIrKWJgqHy9lgoaxrq9 rY/2BDnItDH9yjCDmPRLyuXA9M23ynFeErZRbkc3jJufhh4U3ZYJOQOfChSpWRvWaczmQ+21 3JVnGaZxylzqROAJ7XwwjMbWQxMmkqsWn+/edo7zEzg4KApBZLyw/f74DXIq6OHT7yARgK+o AAAAAAAA --------------ms070006090609070608020003-- From sancane.kurento@gmail.com Fri Jun 17 02:55:06 2016 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 3A15512B012 for ; Fri, 17 Jun 2016 02:55:06 -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 MCI2Mru4PH7I for ; Fri, 17 Jun 2016 02:55:05 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC11C12B007 for ; Fri, 17 Jun 2016 02:55:04 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id z186so67116529ywd.2 for ; Fri, 17 Jun 2016 02:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=kg1eB7YTuM97o4vyQMZagFQjODfH1vjmSqxLy4Ch+kc=; b=WvR1ZDR+Vd5GfM0ij+nsEJhR6rq08D1/ybT9gyZ3PUYAcSnT8IgtlKLE9A+jj7nymx udFYtLMmX/QyWj0P6oKXb8+Kx+3BnZdYxWg5UOF0DnQhrYCvg1HAM5RubyViBuXNynIu pr0+j0gpgD1fi3qB07rQKJXe5oXWs161BoTDJuP8wJ/HhWU9pJiRzHpps50BTXCP5OWP XqBYfa7fQpfT4FLEzxrfIaVnouDui4/CkzKqVlIl9qcYzhz5qp5KzNlGLW4PoUR5kiGj uRZxbf2hq2ZthUn5vP3FoRot7d3ND5le4UsopXW88jEJRlVMowzQ7ZrMokS7Q6d6hLUJ j0RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kg1eB7YTuM97o4vyQMZagFQjODfH1vjmSqxLy4Ch+kc=; b=V034gpKP3C9LzT8UV7JNRjLcYeyF/5UhzTl5fivSFaEiNhktBKs9G7nuZpHUYx7hL5 AbVzwaYIy9N/lGPDqWKEbN+r/zymCiZXxjPVefUzj6l0BwSdVzvIoTNxtnosIYmR80nD cxEoMbX2adnxOY3+rKimEPHZPc9RiL4rSTENYXN1xkioC2TdUi7orH8FQGWOHjB+tKg5 ocuFskS4fLPHh3GswkIlp0RrxanO2ftZTpa8nKNpTOYn43nYrFenK2rmYPlEjA6D/lga n/+r3e8U2xZynfkOuDDzqQGFlw6VMp5gEokgPRiAmRuUjyVB0AORNGKI7thY0KLtrvI0 /i9w== X-Gm-Message-State: ALyK8tIumYM595SsHmxBH/aWBz1EbcgK7N7C4p7lnmpm2HJ2Zm+zFDJDRBxMJv2xZhZn2VScYk60TmWKeJqFug== X-Received: by 10.37.208.131 with SMTP id h125mr550334ybg.7.1466157304189; Fri, 17 Jun 2016 02:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.84.65 with HTTP; Fri, 17 Jun 2016 02:55:03 -0700 (PDT) From: Santiago Carot Nemesio Date: Fri, 17 Jun 2016 11:55:03 +0200 Message-ID: To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [MMUSIC] rfc5888: Multigroup management X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 09:57:23 -0000 Hi. First of all, let me know if this list is the right place to deal with this kind of questions, if this is not, please I would really appreciate if you could address me to the right place. I'm facing a problem regarding on how to identify groups when dealing with negotiation which several groups might be involved in, specially when groups involved have the same semantic. Suposse there is an offer with next groups attributes: ... a=group:LS 1 2 3 a=group:LS 1 2 ... Suppose that the other peer only supports medias identified by the mids 1 and 2. Next would be the answer: ... a=group:LS 1 2 a=group:LS 1 2 .. so attribute order is not mandatory and there is not way to identify groups, how can the offerer know which group was offered with medias 1, 2 and 3, note that the answerer could have changed the order of the attributes in the answer making this discrimination almost impossible. Am I missing somthing, RFC58888 only warns you about that there may be several a=groups lines in a session description, but not specifies how to deal with this. Does attribute order matter for groups, if not how can above situation be managed? Regards. From nobody Fri Jun 17 12:11:56 2016 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 9DDEC12D9D8 for ; Fri, 17 Jun 2016 12:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 MicbUX6apLQa for ; Fri, 17 Jun 2016 12:11:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EC212D9EA for ; Fri, 17 Jun 2016 12:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3013; q=dns/txt; s=iport; t=1466190713; x=1467400313; h=from:subject:to:message-id:date:mime-version; bh=3AY4jRXdXC3MDP12U95+nVhrVsdlThAlm3ct2Jh+HkE=; b=Ir+BvPP195VFFYFxca9YiFJMjvT/ap2L5W67xLklBAEA42OCGbPBZR/C NkhWd8CVlIV6zRM4Kf9NcB5af8O7fS2gfKOtExS0zIJcQtxxpaQlwt5vQ mSyeIDgTB2pUzxY7x2wVfv2zdE+irjymtnLHj/UOn347JJRkfD0rWR8j8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHBADiSmRX/5hdJa1dgz6BAbQNgieCI?= =?us-ascii?q?FKCD4F6hz44FAEBAQEBAQFlJ4R1SyQGAT0CXw0IAQGILJMXjTuPYpBOAQEIAgE?= =?us-ascii?q?khieBd4oXgloFhX+HdYp9in9ugWBcgWmEUoMKhV2PdR42hAwgii0BAQE?= X-IronPort-AV: E=Sophos;i="5.26,484,1459814400"; d="scan'208,217";a="116419133" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 19:11:52 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5HJBpWV008579 for ; Fri, 17 Jun 2016 19:11:52 GMT From: Flemming Andreasen To: mmusic Message-ID: <6acef31a-dcfe-ef30-0b1f-a9248e98eb0c@cisco.com> Date: Fri, 17 Jun 2016 15:11:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A290AAEF6D03D4E660C9CEAC" Archived-At: Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 96 (Berlin) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 19:11:54 -0000 This is a multi-part message in MIME format. --------------A290AAEF6D03D4E660C9CEAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Greetings IETF96 in Buenos Aires is approaching and the MMUSIC WG will be having a 1 hour meeting this time (currently on Wednesday July 20). Draft submissions and initial WG agendas are both due July 8, so this is a friendly reminder to please 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 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) --------------A290AAEF6D03D4E660C9CEAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Greetings

IETF96 in Buenos Aires is approaching and the MMUSIC WG will be having a 1 hour meeting this time (currently on Wednesday July 20). Draft submissions and initial WG agendas are both due July 8, so this is a friendly reminder to please 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 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)

 

--------------A290AAEF6D03D4E660C9CEAC-- From nobody Fri Jun 17 15:19:31 2016 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 A0C0D12DBB0; Fri, 17 Jun 2016 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 WrUcZASUKHeu; Fri, 17 Jun 2016 15:19:27 -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 B249D12DBDF; Fri, 17 Jun 2016 15:19:27 -0700 (PDT) Received: from [10.0.1.4] (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 u5HMJOtu092409 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2016 17:19:25 -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.4] From: "Ben Campbell" To: "Suhas Nandakumar" Date: Fri, 17 Jun 2016 17:19:26 -0500 Message-ID: <9BAB6CB5-02DF-424B-8CDC-BFDC7DD2F02E@nostrum.com> In-Reply-To: <9FFB7971-3556-498B-B267-59089FBD47D7@nostrum.com> References: <9FFB7971-3556-498B-B267-59089FBD47D7@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: mmusic WG , draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sdp-mux-attributes-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 22:19:29 -0000 Hi Suhas, Where did we end up with this? It looks like the zrtp-hash thread has resolved. Do you plan an update? Thanks! Ben. On 20 May 2016, at 18:07, Ben Campbell wrote: >>> > >> >> [Suhas] . I doubt it. Do you recommend as NOT-RECOMMENDED instead. > > > That seems reasonable, unless you know of good reasons otherwise. > > > >>> >>> -15.1: >>> - Is there no need for a spec for any newly registered categories? >>> - 2nd to last paragraph: "This seems vague for a MUST. Do you >>> expect >>> the registration of a new category to change the categories >>> already assigned to existing SDP parameters? Is it possible >>> that a new category only applies to some new SDP parameters?" >>> > >> >> [Suhas] The following 2 paragraphs are supposed to mean that new >> multiplexing categories require new registrations via a spec and >> applicability of the new category to new SDP attributes and possibly >> existing SDP attributes ( if the new category makes more sense). What >> would >> be a better framing to capture the intent ? >> >> "*Further entries can be registered on a first-come first-serve >> basis. Each >> registration needs to indicate the multiplexing category value to be >> added >> to the "Multiplexing Categories" subregistry as defined in this >> section.* >> >> *Such a registration MUST also indicate the applicability of the >> newly >> defined multiplexing category value to various subregistries defined >> at >> "Session Description Protocol (SDP) Parameters".* > > > That works for me. > > >> >> > >>> - Last paragraph: 4566 procedures apply to what? The text just >>> said >>> new categories are first-come-first server. I don’t think >>> 4566 set policies for how to change mux categories. >>> > >> >> [Suhas] Agreed. I prefer removing this line altogether. Please let me >> know >> > > > I agree. > > > >>> >>> -15.2.1: >>> How do you expect the table to look after adding this RFC to the >>> references? Will this RFC be added to the entries in the MUX >>> column? >>> > >> >> [Suhas] The plan was to add the reference to this RFC in the >> "Reference >> Column" > > > Okay. > > [...] > > > >> > >>> >>> >>> # Editorial # >>> > >> > >>> - The abstract is more detailed than needed. The point is to >>> describe the >>> purpose of the draft. The second paragraph pretty much accomplishes >>> that. >>> >>> > >> [Suhas] How do this rephrase look >> >> “The purpose of this specification is to provide a framework for >> analyzing >> the multiplexing characteristics of SDP attributes when SDP is used >> to >> negotiate the usage of single 5-tuple for sending and receiving media >> associated with multiple media descriptions,. This specification also >> categorizes the existing SDP attributes based on the framework >> described >> herein.†>> > > > That works for me. > > [...] > > >> >> > >>> >>> -5 and subsections: Is there any method to the ordering? They aren't >>> in RFC order. It might make sense to group by the nature of the >>> attributes, but if that is the case here it's not explained. >>> >>> > >> [Suhas] These are not ordered as of today. I can order the 5.X >> subsections >> by RFC order, if needed. > > > Unordered is also okay. I was just wondering if there was a logic that > should be mentioned. > > > [...] From nobody Sun Jun 19 04:01:57 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFCD12D0F7; Sun, 19 Jun 2016 04:01:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160619110156.22384.53113.idtracker@ietfa.amsl.com> Date: Sun, 19 Jun 2016 04:01:56 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-31.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 11:01:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-31.txt Pages : 54 Date : 2016-06-19 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejcted. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-31 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-31 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 19 04:04:10 2016 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 8B56F12D0F7 for ; Sun, 19 Jun 2016 04:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Fy38ZhD5oGBv for ; Sun, 19 Jun 2016 04:04:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6078112B071 for ; Sun, 19 Jun 2016 04:04:06 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-16-57667c246b65 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.F7.12926.42C76675; Sun, 19 Jun 2016 13:04:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Sun, 19 Jun 2016 13:04:04 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: bundle-31 Thread-Index: AdHKGkGq1VzDV0ufTj6wLHDsf3DtLw== Date: Sun, 19 Jun 2016 11:04:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380E476C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380E476CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7ma5KTVq4waq1chZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuXtMgWzRCv+LZ7D1MD4TKiLkZNDQsBEonXrSWYIW0ziwr31 bF2MXBxCAkcYJeY+/MEK4SxhlLj9ewNjFyMHB5uAhUT3P22QBhEBdYmve3vAmoUFVCX67i1h hohrSby/N4sFwtaTWDNvESuIzQJU82HJQrA4r4CvxMP5q8DqGYEWfz+1hgnEZhYQl7j1ZD4T xEECEkv2nIc6TlTi5eN/rBC2ksTaw9tZIOrzJebufc0EMVNQ4uTMJywTGIVmIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZG YEQc3PJbdQfj5TeOhxgFOBiVeHgTjqSGC7EmlhVX5h5ilOBgVhLhFa9MCxfiTUmsrEotyo8v Ks1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAyPQn5ltbuKBelGwls9L2uqS9 Eux1/LJec/mEf4fWsG9OKpKYxyXFr+O5P6dzldUDnkn/Cw5//XJqt6D7NYPHnFML5PVuOhik fdFafj3semnU7+Vq32xnucYVz592kE3x8/UKJ1udDWt+t1R7hRy+rGJ9+NKtpJ6VyVv06o2q pvxNOpV9y2+aEktxRqKhFnNRcSIA9C8EHYQCAAA= Archived-At: Subject: [MMUSIC] Draft new version: bundle-31 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 11:04:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380E476CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-31) of draft-bundle, where I fixed some issu= es that were reported by the idnits tool. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B380E476CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-31) of draft-bu= ndle, where I fixed some issues that were reported by the idnits tool.=

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B380E476CESESSMB209erics_-- From nobody Mon Jun 20 06:39:34 2016 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 3080912D0BF for ; Mon, 20 Jun 2016 06:39:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrnCDpoe_aKL for ; Mon, 20 Jun 2016 06:39:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57B112D5C4 for ; Mon, 20 Jun 2016 06:39:25 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-77-5767f20b4397 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.8E.12926.B02F7675; Mon, 20 Jun 2016 15:39:24 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 20 Jun 2016 15:39:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DVlhx0QssIcwF1oeP1+S0icoSzYh96LOUJ0rZhbj1XI=; b=gRcpqQfAozDs7bu3BAFci55Dv86NcwjCUvVgsWBT3KOGHySkgbrZ9u4LfKUoUkzp/J350mOkdzgGxhWssH4cQAYhOlktlpgGga33Zro+0SOcY5s+/+9XVRSEWC7f8frqAwT4JBd9G/bfv1MU9/54jtuqv/yNHjFCRsfrwNMJ5+Q= Received: from AM3PR07MB1188.eurprd07.prod.outlook.com (10.163.188.26) by AM3PR07MB1188.eurprd07.prod.outlook.com (10.163.188.26) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 20 Jun 2016 13:39:22 +0000 Received: from AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::6da0:cbd6:2d8f:a096]) by AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::6da0:cbd6:2d8f:a096%14]) with mapi id 15.01.0523.015; Mon, 20 Jun 2016 13:39:22 +0000 From: Bo Burman To: Santiago Carot Nemesio , "mmusic@ietf.org" Thread-Topic: [MMUSIC] rfc5888: Multigroup management Thread-Index: AQHRyH6qwvVi/Rc6WU6N7AQmbRyFRJ/yXDfA Date: Mon, 20 Jun 2016 13:39:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-office365-filtering-correlation-id: 3feb2178-6829-4b8a-c173-08d399104992 x-microsoft-exchange-diagnostics: 1; AM3PR07MB1188; 6:q68kWMHIuLxYl6kU9pXoRXP8vIVVGfDzLrM/3zvjDxNkHQALFpJLx79V0Wov/TP9dUL06Jm3/poHhLsR2/OgapGu3w5G8IKmXKxkW+3SRfu4AU6N4z4BQtV7wWshA1TQFhb7f54f9ctI4a/S+Nq4IHtvalbB/EtNlq7/PsmfJwgXrzkF63GLw/UWLCYHCqhyz902J7rmo7q4ZbaFV2BR/tOd3MvaoKLEvcnaeeala4ZMZ1hp9uJ5BNPzYq3YzvpGjkbSFL/CuRaL+Eg0lr1y7KdmlBthLpll9Uze+PtjUI0=; 5:y2cmzlr2yNTsAM8bZheuJz4Z7vPZ1rgPk6tJJtm/3tacHsgPauRL4481iUGJFfwXHc1zJDYhUm1Jatk4eijQx1OPZXKQlJ3zD2LiFy5jNWIZycdGngX7a/3rDMB1P9Crn9L6xXPXABoBNR12dzEytA==; 24:iETS6X+viP6abyZ1SdVvchRRwOHZ3yPpxMj9xFiS2cZFs++s31J6giZ/1VV/fKH1YnJSAfJov4vhoPA47F4SIp+sA80z84lbqXZVk8hnlbM=; 7:+6ikxYGNxxIGrc7IJP/5TWhxGChKdMrRbUKWIZofLn+UeH9hXJhY1S99ei/F8tu0FgnQBEamAzGDQpgnRpqpAIKzKkeq311Vo99qGs/lmov60uigNYdVKHh2ZUumJKZBqPfohjofM/dNqxJuB0Id3V/+O1uT+GqRQSsJ01DIDEFwJwHShP9ACXxqIYyyG9Pg+iv5B2MZnYNe6QC/ZaSPpE9p2UR2tqE5irnHJFrir0VIeRlwRzgpeb63FXeW7XlC x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB1188; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR07MB1188; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1188; x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(199003)(501624003)(189002)(5004730100002)(2950100001)(11100500001)(15975445007)(76576001)(2900100001)(5002640100001)(3660700001)(5003600100002)(33656002)(92566002)(3280700002)(87936001)(106116001)(105586002)(106356001)(107886002)(5250100002)(101416001)(50986999)(54356999)(76176999)(86362001)(2501003)(19580395003)(5001770100001)(74316001)(2906002)(68736007)(9686002)(8936002)(81156014)(97736004)(66066001)(102836003)(3846002)(6116002)(19580405001)(189998001)(586003)(7846002)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1188; H:AM3PR07MB1188.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2016 13:39:22.1732 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1188 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee7utrvh6GnNPNoLthTK0mwZKIWsD6UZlX1aWWErb3M4p+ya aEGYFakoZRrmrJwwEjVdmuRrRXNZSWq+MM1ciDN0VK5mIGpZbndB337nnP//OS88FEd8jRtA qbUZtE6r1Eh5QrL8eEtoqI9LpQivLRVG3qm2k5GvnIN8ORHbprfxY43GBSKeSBDuTaI16kxa tyP6jDB58aqZn27yz7K+biNz0H1JARJQgCOgviiXz/JaeP/JxCtAQkqMLQjuVxR6gzcIXJU9 noDERRwonMkn2IoVwWTvtFdmR9CV564IKB7eApWtNlSAKEqCT8OEE9zpNSv9Fn/VcN0swbvB UbrIZ1kG89Yuj5XEwdD1vI7jZhE+BT3fcz15MY6Hjr4Fj1eAj0GL3eBhtDL3fM8jj4aD/WBs qpJg98Fg7OznsOwLDvuyV38CSop7+e7RAAeC8bc/KzkMpvG7nlUAz/Kgve6b13sA5gbHvTdK gb7he4jlEMiz6AnWYELQ/GwAsY+uh8YfCjbfzYX2iiHELkBDdf11xB4iAGzD+egWCtH/NzfL 28HQ4eKxvA0eVn3h6D23WA1vy6dIAyJrkS9DM2dTVbJdYbROfY5h0rRhWjqjCa38jZfNS8Gt aOjrPjPCFJL6iAy28woxV5nJZKeaEVAcqUQU6FQpxKIkZfZFWpeWqLugoRkzWkeRUj/RUccm hRirlBl0Ck2n07p/VYISBOSguIG2lqeftT9lD0YJEXVFHiPIZYL2zEaN5blmljpkJVU3Dm54 knUIl8sDje1FJxvKqibDMwX6VeUTEbdrm7jDnQ0bS7prRuvkjiNB7+biDCNRmy9/GFEvLDPR MS8euxqLLdabDYkf+x2Mczp061yZRmmRO9P+xNtbif0JQZdEUpJJVu4M4egY5V+Zm3l2FwMA AA== Archived-At: Subject: Re: [MMUSIC] rfc5888: Multigroup management X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 13:39:33 -0000 Hi, I think this list should be capable to answer your question. It seems to me that you in general need to consider the semantics of the gr= ouping. Looking to your example below, I don't really understand what you t= ry to express with a=3Dgroup:LS 1 2 3 a=3Dgroup:LS 1 2 Obviously, if media lines with mid 1, 2, and 3 are lip-synchronized (LS), s= o are mid 1 and 2, since it is a true subset of the first group. The second= "a=3D" line is redundant even to start with. As such, just removing or dis= regarding the resulting repeated line in the answer in your example does no= t cause any concern or ambiguity. If on the other hand two different grouping semantics were used in the offe= r, like a=3Dgroup:LS 1 2 3 a=3Dgroup:BUNDLE 1 2 and if, as in your example, the answerer does not support media with mid 3,= the resulting a=3Dgroup:LS 1 2 a=3Dgroup:BUNDLE 1 2 still makes sense, where media 1 and 2 are both lip-synchronized and part o= f the same BUNDLE. I don't think this is possible to generalize, since you could envision grou= ping semantics (current or future) that has some implicit or explicit relat= ion. Grouping semantics could for example be defined such that they are mut= ually exclusive. Say, "this is media only from cows" and "this is media onl= y from foxes"; a media line belonging to both of those groups would describ= e media from one strange animal. The RFC 5888 grouping is to be seen as a g= eneral signaling mechanism and does not concern itself with specific groupi= ng semantics. Best Regards /Bo > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Santiago Carot= Nemesio > Sent: den 17 juni 2016 11:55 > To: mmusic@ietf.org > Subject: [MMUSIC] rfc5888: Multigroup management >=20 > Hi. >=20 > First of all, let me know if this list is the right place to deal with th= is kind of questions, if this is not, please I would really > appreciate if you could address me to the right place. >=20 > I'm facing a problem regarding on how to identify groups when dealing wit= h negotiation which several groups might be > involved in, specially when groups involved have the same semantic. >=20 > Suposse there is an offer with next groups attributes: > ... > a=3Dgroup:LS 1 2 3 > a=3Dgroup:LS 1 2 > ... >=20 > Suppose that the other peer only supports medias identified by the mids 1= and 2. Next would be the answer: > ... > a=3Dgroup:LS 1 2 > a=3Dgroup:LS 1 2 > .. >=20 > so attribute order is not mandatory and there is not way to identify grou= ps, how can the offerer know which group was > offered with medias 1, 2 and 3, note that the answerer could have changed= the order of the attributes in the answer > making this discrimination almost impossible. >=20 > Am I missing somthing, RFC58888 only warns you about that there may be se= veral a=3Dgroups lines in a session description, > but not specifies how to deal with this. Does attribute order matter for = groups, if not how can above situation be > managed? >=20 > Regards. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Jun 20 09:22:22 2016 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 E7F2812D782; Mon, 20 Jun 2016 09:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 G6Dh4TKmSzgH; Mon, 20 Jun 2016 09:22:20 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D69312D7C7; Mon, 20 Jun 2016 09:21:44 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u5KGLK6S022491; Mon, 20 Jun 2016 12:21:43 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 23kfmh2jhe-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jun 2016 12:21:43 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 11:21:43 -0500 From: Jonathan Lennox To: mmusic Thread-Topic: avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. Thread-Index: AQHRyw/UIl1SwULpvEegDZi1VKrJPA== Date: Mon, 20 Jun 2016 16:21:42 +0000 Message-ID: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <891560A5E4784B418F20A1DEA74BF1AC@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-06-20_09:2016-06-20,2016-06-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1606200179 Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:22:21 -0000 VGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50IHdhcyBqdXN0IHNlbnQgb3V0IGZvciBkcmFm dC1pZXRmLWF2dGV4dC1zZGVzLWhkci1leHQuDQoNClRoaXMgZG9jdW1lbnQgd2FzIGVzc2VudGlh bGx5IG1vdGl2YXRlZCBhcyBiZWluZyBhIGdlbmVyYWxpemF0aW9uIG9mIEJVTkRMReKAmXMgTUlE LCBidXQgaXQgaGFzIG1hbmFnZWQgdG8gcGFzcyBCVU5ETEUgaW4gdGhlIElFVEYgcHJvY2Vzcy4g IFNvIEkgc3VnZ2VzdCBhdCB0aGlzIHBvaW50IEJVTkRMRSBzaG91bGQgYmUgbW9kaWZpZWQgdG8g cmVmZXJlbmNlIHNkZXMtaGRyLWV4dCBmb3IgaXRzIGRlZmluaXRpb24gb2YgdGhlIE1JRCBoZWFk ZXIgZXh0ZW5zaW9uIChhbmQgdGhlIElBTkEgaGVhZGVyIGV4dGVuc2lvbiByZWdpc3RyYXRpb24g YmUgdXBkYXRlZCB0byBwb2ludCBhdCB0aGUgbmV3IHN1YiByZWdpc3RyeSB0aGF0IHNkZXMtaGRy LWV4dCBkZWZpbmVzKS4NCg0KVGhpcyBzaG91bGRu4oCZdCBiZSBhIGJlaGF2aW9yYWwgY2hhbmdl IGF0IGFsbCwganVzdCBkb2N1bWVudGF0aW9uLg== From nobody Tue Jun 21 01:58:27 2016 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 9BCF512D0B8 for ; Tue, 21 Jun 2016 01:58: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, 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 3qpc5Fv0Ylzk for ; Tue, 21 Jun 2016 01:58:25 -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 6583712B03E for ; Tue, 21 Jun 2016 01:58:25 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v77so8155718ywg.0 for ; Tue, 21 Jun 2016 01:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3rmJDthBth+9295U6Vd9odgZ9quT3eosgZC96S43tR0=; b=f4VeW4Ellg10TqbBF/nWtvvtctZ3rVKrwKasYSV1FmiQ4u1oRYB0ZV/lO2yqtSXSPp AqUqvgQEO4GC3ffuyxy00tWqORAAaYHCuA3k9V2bmFQQ3UYwfkbkguJ3BwRh9KXkh9Zq +G+gb/OhFV/nGUCd5qBGSLnIIy/ycRGHuLqQdOEG/yaYA+zeuPbNzR7/m9QW3Lq2eSPm WJiAJM2nA9XuHZVdRh2VhTIgxzl+uj1TwZ+Zu5tc/rTCwkC51SbE6sMCc20D/Tm2iEAa eNNTW40l+yHjXiBzPfJArT705Mei0Do9MaGW1UdrxddRBuGl8E3Ub4rc3m5J+xU9Gn+6 p7Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3rmJDthBth+9295U6Vd9odgZ9quT3eosgZC96S43tR0=; b=B/xEg8NBk+ZO/IsJ4P+VIdMOr8Yk+VH5UDiHv98Lu7jQQdpUtgax1Is4mdSpQoOEaZ ZF0M3oQGHY+aG4+mIU1kiaByfIq68eA6+jS8l14HDzo2HDfbxj2dCPSRS9t7uUtA3B6T hzrbDXzmWCr5K+QrPZrAkYZtT5BBF7Sh+JvAxqKi6Kf6UN1zGV2m29JBGfsMsWO3pQ5G MYB9FmmsYjiqgIGbrPUDKILxh8tIFLmlnxCc+/s8Bskw+WR4cXBSVDmBQk2hf74pD4sU 88JKjbHjX8CKW0eSy6RDuX5XQzeCP10XbFDhrf9dRMSO1r1ZBzbcA0okUhpVleo0QvN/ lhfQ== X-Gm-Message-State: ALyK8tKjG/FRvPK4G76+lfViglO1UorjqYdSZAujc38yHJEwfaCwhBBXXXH94joI1KBaQzY3CSBEasQKOdysEw== X-Received: by 10.129.85.76 with SMTP id j73mr11119918ywb.233.1466499504661; Tue, 21 Jun 2016 01:58:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.84.65 with HTTP; Tue, 21 Jun 2016 01:58:24 -0700 (PDT) In-Reply-To: References: From: Santiago Carot Nemesio Date: Tue, 21 Jun 2016 10:58:24 +0200 Message-ID: To: Bo Burman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] rfc5888: Multigroup management X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 08:58:26 -0000 Hi, thanks a lot for your reply, see comments below. 2016-06-20 15:39 GMT+02:00 Bo Burman : > Hi, > > I think this list should be capable to answer your question. > > It seems to me that you in general need to consider the semantics of the = grouping. Looking to your example below, I don't really understand what you= try to express with > a=3Dgroup:LS 1 2 3 > a=3Dgroup:LS 1 2 > Obviously, if media lines with mid 1, 2, and 3 are lip-synchronized (LS),= so are mid 1 and 2, since it is a true subset of the first group. The seco= nd "a=3D" line is redundant even to start with. As such, just removing or d= isregarding the resulting repeated line in the answer in your example does = not cause any concern or ambiguity. This is not a real case at all, I just wanted to raise awareness about this concern, so that's just a simple example of ambiguity in case any peer needs to distinguis this case, So the semantic regarding of the grouping of medias is application dependant you can not make assumptions about what application do or even what they are trying to do, but from the implementation point of view perhaps you need to distinguish what group was offered with what medias and what medias were accepted for any specific group. So I suspects that just as it is right now this is not possible. Please, fixme if I'm wrong or I'm missing something. Thanks From nobody Tue Jun 21 06:12:39 2016 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 2961712B03E; Tue, 21 Jun 2016 06:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 R1K5NQO1bCLO; Tue, 21 Jun 2016 06:12:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF92012D7D8; Tue, 21 Jun 2016 06:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1073; q=dns/txt; s=iport; t=1466514755; x=1467724355; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=uzCkAm45ZrmKLh7Fl+XsbLhdAbXDKVl9VtEBsuAamtY=; b=CrPyMWklIbi6YVxXXt+GGAuZy6Ylt2uuMixojlKjDU3abY7F1L3r291V WVbXhfbkZouSFxUgGVW8PMsUuJ/dv74jMiB8V2jx9X1EE7NhSMZmRI8sr DWZL8vJbDoK2bpd1qZwTQeUkLNoA4StVh6h9nzdpXBZlgUkFajxUnASZV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgCGPGlX/4QNJK1dgz5WK1K6d4F6F?= =?us-ascii?q?wuFK0oCgTQ4FAEBAQEBAQFlJ4RMAQEEAQEBIA8BBTYLEAsYAgImAgInMAYBDAY?= =?us-ascii?q?CAQGILA6wXpBXAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUmgXeCVodBgloBB?= =?us-ascii?q?Jh5jiwCiUSFXY94HjaCCBwXgVEgMopIAQEB?= X-IronPort-AV: E=Sophos;i="5.26,504,1459814400"; d="scan'208";a="120178053" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2016 13:12:34 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5LDCYrh021479; Tue, 21 Jun 2016 13:12:34 GMT To: Jonathan Lennox , mmusic References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> From: Flemming Andreasen Message-ID: <92229887-fd53-4859-1369-60059c9352b7@cisco.com> Date: Tue, 21 Jun 2016 09:12:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 13:12:38 -0000 Hi Jonathan This obviously represents a change to the document that the WG would have to agree to, not least considering that we have completed WGLC on the bundle draft (several times). Can we get some more feedback on this proposal before we agree to this (late) change ? Thanks -- Flemming (as MMUSIC co-chair) On 6/20/16 12:21 PM, Jonathan Lennox wrote: > The IESG approval announcement was just sent out for draft-ietf-avtext-sdes-hdr-ext. > > This document was essentially motivated as being a generalization of BUNDLE’s MID, but it has managed to pass BUNDLE in the IETF process. So I suggest at this point BUNDLE should be modified to reference sdes-hdr-ext for its definition of the MID header extension (and the IANA header extension registration be updated to point at the new sub registry that sdes-hdr-ext defines). > > This shouldn’t be a behavioral change at all, just documentation. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Jun 21 06:39:53 2016 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 80E9712B027; Tue, 21 Jun 2016 06:39:52 -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 EpLXe5qy001W; Tue, 21 Jun 2016 06:39:51 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7FC127071; Tue, 21 Jun 2016 06:39:50 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-04-576943a42f42 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5E.2D.12516.4A349675; Tue, 21 Jun 2016 15:39:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.294.0; Tue, 21 Jun 2016 15:39:47 +0200 To: Flemming Andreasen , Jonathan Lennox , mmusic References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> From: Magnus Westerlund Message-ID: Date: Tue, 21 Jun 2016 15:39:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <92229887-fd53-4859-1369-60059c9352b7@cisco.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM2K7ou4S58xwg/N/dC2mz3rHZvH+gq7F /sXnmS2mLn/M4sDiMeX3RlaPJUt+Mnm0PbvDHsAcxWWTkpqTWZZapG+XwJWx/tc55oKbohXN J3YzNTD+Fehi5OCQEDCReLSWv4uRE8gUk7hwbz1bFyMXh5DAEUaJR18XM0M4yxklNq+/wA5S JSyQLdE1eRkbiC0ikCux9dMuZhBbSCBf4vuZmawgNjNQfOObm2D1bAIWEjd/NILV8wrYS7Q/ awerYRFQlXj36h5YXFQgRqLx9mF2iBpBiZMzn7CAHMcpYCuxYII4xEgLiZnzzzNC2PISzVtn Q63Vlmho6mCdwCg4C0n3LCQts5C0LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGMgH t/zW3cG4+rXjIUYBDkYlHl4F/YxwIdbEsuLK3EOMEhzMSiK8u+wzw4V4UxIrq1KL8uOLSnNS iw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwrrY79VZtpa2llnRSyrmYwP5mq/mq qldW5GkzVn2+Kj/59mHZCwaf/8zq6pfnEz5257yUYWFPlrXe/22Nj/Q+x/+fVGmwoSw0dv7T zuCGxOr9fy2ZvjE7z8kxKYlJkPJaO2lTLddhsfJicyfpNS3nPoT0LmaJWDT5hsyWVnbvLVPe HE/5vFdbiaU4I9FQi7moOBEAGutiQGACAAA= Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 13:39:52 -0000 Den 2016-06-21 kl. 15:12, skrev Flemming Andreasen: > Hi Jonathan > > This obviously represents a change to the document that the WG would > have to agree to, not least considering that we have completed WGLC on > the bundle draft (several times). > > Can we get some more feedback on this proposal before we agree to this > (late) change ? Hi, I think this really should be done. It is actually a fairly minor change. The main change is that the registration of the MID header extension shall be done in the sub-registry created by the SDES header extension document, and following its rules rather than the generic RTP header extension registry. In fact the current version of bundle, already reference the right registry. A thing missing is a normative reference to the SDES header ext RFC-to-be. Also when it comes to registration rules they are mostly fulfilled. 1. Any registration using an Extension URI that starts with "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also have a registered Source Description item in the "RTP SDES item types" registry. 2. A security and privacy consideration for the SDES item MUST be provided with the registration. 3. Information MUST be provided on why this SDES item requires timely delivery, motivating it to be transported in a header extension rather than as RTCP only. Looking at the current version, I would wish for a slightly clearer motivation in 14.1 for why the header extension is needed and RTCP is not sufficient. That being to ensure that one gets the MID identifier upon receipt of the first decodable media so that they can be correctly associated in the receiving application. What I feel is not adequately described is the privacy consideration for the MID item. There are no guidelines for how to generate the MID identification-tag other than it is preferably be short. I think from a privacy perspective, the most important information aspect is that no user related information shall be included in the tag value. Secondly, there is risk for implementation identification due to implementation specific patterns in how they generate the tag. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 21 06:49:29 2016 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 8DDC6127071; Tue, 21 Jun 2016 06:49:27 -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 jTiH5UfLEmzq; Tue, 21 Jun 2016 06:49:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7868A12D0A5; Tue, 21 Jun 2016 06:49:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-28-576945e1e50f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.EE.12516.1E549675; Tue, 21 Jun 2016 15:49:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 15:48:42 +0200 From: Christer Holmberg To: Magnus Westerlund , Flemming Andreasen , Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. Thread-Index: AQHRyw/UIl1SwULpvEegDZi1VKrJPJ/zxX8AgAAHmQCAADXYgA== Date: Tue, 21 Jun 2016 13:48:41 +0000 Message-ID: References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7ou5D18xwgy1L9Cymz3rHZvH+gq7F /sXnmS2mLn/M4sDiMeX3RlaPJUt+Mnm0PbvDHsAcxWWTkpqTWZZapG+XwJXx7uFZpoJHMhWb XjcwNTC+E+ti5OSQEDCR2LjwASuELSZx4d56ti5GLg4hgSOMEjM/LGWCcJYwSnzcsZe5i5GD g03AQqL7nzZIXERgMaPEtqvtLCDdzAK5Ehvf3GQHsYUFsiW6Ji9jA7FFBHIkZuztZIGwnSQ2 tq1jArFZBFQl1m1ZBGbzClhJTL35gxVi2VJGiePNX8EaOAUcJFYc/8sMYjMCnff91BomiGXi EreezGeCOFtAYsme88wQtqjEy8f/wN4RFdCT+HJvHiNEXFHi6vTlUL16EjemTmGDsK0lXv9o YoawtSWWLXzNDHGQoMTJmU9YJjBKzEKybhaS9llI2mchaZ+FpH0BI+sqRtHi1OLi3HQjY73U oszk4uL8PL281JJNjMA4Pbjlt+4OxtWvHQ8xCnAwKvHwKuhnhAuxJpYVV+YeYpTgYFYS4V3l khkuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgXGaxxM9 9Z6Vpxpq3+fdmDltZ4Rw5dFjKZ4rDmxMdGuQYjnz+2RqbKTYgSAlsa/sW8UiRU/lb9+2gTlp yia+vSf2q/SExD7rZLCIY9W/I1m5Of2Hw/kNJvMtm5xD3k5lmzVj37bLCXkZZlm6PHPuhzB9 yJwXXugVfFtZRKj7prKaSVXf997dNUosxRmJhlrMRcWJAPZtFwrPAgAA Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 13:49:27 -0000 Hi Jonathan/Magnus, So, just to clarify what I=B9d have to do in BUNDLE. 1. BUNDLE still needs to define and register the new MID RTP SDES item in the IANA "RTP SDES item types" registry. 2. BUNDLE will then register the item/URI extension in the newly formed IANA "RTP SDES Compact Header Extensions registry=B2. AFAIK, BUNDLE already does both, based on earlier feedback from Alissa. So, what exactly would I still need to change? Regarding Magnus=B9 bullets 2) and 3), where is that information for the "urn:ietf:params:rtp-hdrext:sdes:cname=B2 defined in avtext-sdes-hdr-ext? The draft mentions CNAME here and there, but I can=B9t really find a clear description of its usage in the RTP SDES header extension. Regards, Christer On 21/06/16 16:39, "Magnus Westerlund" wrote: >Den 2016-06-21 kl. 15:12, skrev Flemming Andreasen: >> Hi Jonathan >> >> This obviously represents a change to the document that the WG would >> have to agree to, not least considering that we have completed WGLC on >> the bundle draft (several times). >> >> Can we get some more feedback on this proposal before we agree to this >> (late) change ? > >Hi, > >I think this really should be done. It is actually a fairly minor >change. The main change is that the registration of the MID header >extension shall be done in the sub-registry created by the SDES header >extension document, and following its rules rather than the generic RTP >header extension registry. > >In fact the current version of bundle, already reference the right >registry. A thing missing is a normative reference to the SDES header >ext RFC-to-be. > >Also when it comes to registration rules they are mostly fulfilled. > > 1. Any registration using an Extension URI that starts with > "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also > have a registered Source Description item in the "RTP SDES > item types" registry. > > 2. A security and privacy consideration for the SDES item MUST be > provided with the registration. > > 3. Information MUST be provided on why this SDES item requires > timely delivery, motivating it to be transported in a header > extension rather than as RTCP only. > > >Looking at the current version, I would wish for a slightly clearer >motivation in 14.1 for why the header extension is needed and RTCP is >not sufficient. That being to ensure that one gets the MID identifier >upon receipt of the first decodable media so that they can be correctly >associated in the receiving application. > >What I feel is not adequately described is the privacy consideration for >the MID item. There are no guidelines for how to generate the MID >identification-tag other than it is preferably be short. I think from a >privacy perspective, the most important information aspect is that no >user related information shall be included in the tag value. Secondly, >there is risk for implementation identification due to implementation >specific patterns in how they generate the tag. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Tue Jun 21 07:48:27 2016 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 0629312D100; Tue, 21 Jun 2016 07:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 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, T_FILL_THIS_FORM_SHORT=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 FHh391K31Li0; Tue, 21 Jun 2016 07:48:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C472E12D128; Tue, 21 Jun 2016 07:48:22 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-86-576953b4ed59 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 46.DB.12516.4B359675; Tue, 21 Jun 2016 16:48:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.294.0; Tue, 21 Jun 2016 16:48:20 +0200 To: Christer Holmberg , Flemming Andreasen , Jonathan Lennox , mmusic References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> From: Magnus Westerlund Message-ID: <558b361f-43e6-ee2c-e346-22448a6eddb5@ericsson.com> Date: Tue, 21 Jun 2016 16:48:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM2K7se6W4Mxwg8VNmhbTZ71js3h/Qddi /+LzzBZTlz9mcWDxmPJ7I6vHkiU/mTzant1hD2CO4rJJSc3JLEst0rdL4Mo4dzOg4Ix4xfKb T9gbGK8IdTFyckgImEj0zj3PBGGLSVy4t56ti5GLQ0jgCKPE9pn7GEESQgLLGSV+/GQBsYUF siW6Ji8DKxIRWMwo8X/KVkaIjmuMEkd3PAWrYhbIldj45iY7iM0mYCFx80cjUAcHB6+AvcTD dyogJouAqsSRE2UgFaICMRKNtw+DVfMKCEqcnPkEbAqngLXE8xcvmEDKmYE6H2wtgxguL9G8 dTYzxGnaEg1NHawTGAVnIemehdAxC0nHAkbmVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB QXxwy2/dHYyrXzseYhTgYFTi4VXQzwgXYk0sK67MPcQowcGsJML7wjczXIg3JbGyKrUoP76o NCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVAOjeQ8jA7OqY+WzCvcLAcx+Wo5f /q7qrlI1/r+mejHrd8uvG1w84xpfrm1SlDOyUrv6s2FJREO43AeFOFmxGy+XHLafk7Ux53W6 3PpDe/pKOkU1QjN2Hw+zn2Jf3jzNkG/O5NP7cnIV+oOORFc97w9hOTnt0PL2Z2/Ktf7ld3xV ZU1YdjtgR7wSS3FGoqEWc1FxIgDSG8QAXgIAAA== Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 14:48:26 -0000 Den 2016-06-21 kl. 15:48, skrev Christer Holmberg: > > Hi Jonathan/Magnus, > > So, just to clarify what I¹d have to do in BUNDLE. > > 1. BUNDLE still needs to define and register the new MID RTP SDES item in > the IANA "RTP SDES item types" registry. > > 2. BUNDLE will then register the item/URI extension in the newly formed > IANA "RTP SDES Compact Header Extensions registry². > > AFAIK, BUNDLE already does both, based on earlier feedback from Alissa. > > So, what exactly would I still need to change? > > Regarding Magnus¹ bullets 2) and 3), where is that information for the > "urn:ietf:params:rtp-hdrext:sdes:cname² defined in avtext-sdes-hdr-ext? > The draft mentions CNAME here and there, but I can¹t really find a clear > description of its usage in the RTP SDES header extension. > > Well, as usually in retrospect, that part should have been written as its own section so that it would provide an example. Instead it is spread out across the whole document. The motivation for CNAME is covered in the general motivation for the SDES header extension, see section 3: For the case of rapid media synchronization, one may use the RTP header extension for Rapid Synchronization of RTP Flows [RFC6051]. This header extension carries the clock information present in the RTCP sender report (SR) packets. It however assumes that the CNAME binding is known, which can be provided via signaling [RFC5576] in some cases, but not all. Thus an RTP header extension for carrying SDES items like CNAME is a powerful combination to enable rapid synchronization in all cases. The privacy considerations for CNAME is covered in Section 6: Source Description items may contain data that are sensitive from a security perspective. There are SDES items that are or may be sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, PHONE, LOC and H323-CADDR. Some may contain sensitive information, like NOTE and PRIV, while others may be sensitive from profiling implementations for vulnerability or other reasons, like TOOL. The CNAME sensitivity can vary depending on how it is generated and what persistence it has. A short term CNAME identifier generated using a random number generator [RFC7022] may have minimal security implications, while a CNAME of the form user@host has privacy concerns, and a CNAME generated from a MAC address has long term tracking potentials. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 21 08:16:05 2016 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 3B43F12D957 for ; Tue, 21 Jun 2016 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 SGUAdIFPQ-T9 for ; Tue, 21 Jun 2016 08:16:03 -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 EABE412D955 for ; Tue, 21 Jun 2016 08:16:02 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-09v.sys.comcast.net with SMTP id FNMPbQqjAAlI7FNPGbSaH7; Tue, 21 Jun 2016 15:16:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466522162; bh=JCZH+e30oSkifLdZi96CUvWHZ+i//+wPXQStUEWy6co=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=p9qk0R7PSWsc4GemCOl5CRCSoCtl45lbvS41pFOBN6G/s/yu8k+479YXoolfsnGJw VFDi4+X1SiF4sQJXAVjr9q7Jq/YnQk3paZbShktWXiHfREtL0BavQTuua/SE9ViKwx D2F4ExhQAy07gyh7lnRu10HfK0n85Dl8fl+WVsdTbMXBlUE65ygb+4KPB7lruPVHAk jKTsoVgaBqgxUbNoix2B5U225kFZoQ8ZUB+LA9x5P+DRs+7QxQACiKeefzp6KwvV5R XorWqTDC4/l/bs5bTno4QUtbWtmMcGGZKOlWe3hZ6WSeb74HN5Yp3wRxREwx9yMpll qdxnLKptDDx8g== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id 9TG11t00z3KdFy101TG2xn; Tue, 21 Jun 2016 15:16:02 +0000 To: mmusic@ietf.org References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> From: Paul Kyzivat Message-ID: <37e4fd15-6344-6a30-cb3f-6b3ed1fe5fed@alum.mit.edu> Date: Tue, 21 Jun 2016 11:16:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <92229887-fd53-4859-1369-60059c9352b7@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:16:04 -0000 On 6/21/16 9:12 AM, Flemming Andreasen wrote: > Hi Jonathan > > This obviously represents a change to the document that the WG would > have to agree to, not least considering that we have completed WGLC on > the bundle draft (several times). > > Can we get some more feedback on this proposal before we agree to this > (late) change ? ISTM it would be good for Christer and Magnus to work out a specific set of changes to bundle and bring them back to the wg as a specific proposal. I guess it is just clerical, not technical, so it then should not be controversial to approve. Thanks, Paul > Thanks > > -- Flemming (as MMUSIC co-chair) > > > On 6/20/16 12:21 PM, Jonathan Lennox wrote: >> The IESG approval announcement was just sent out for >> draft-ietf-avtext-sdes-hdr-ext. >> >> This document was essentially motivated as being a generalization of >> BUNDLE’s MID, but it has managed to pass BUNDLE in the IETF process. >> So I suggest at this point BUNDLE should be modified to reference >> sdes-hdr-ext for its definition of the MID header extension (and the >> IANA header extension registration be updated to point at the new sub >> registry that sdes-hdr-ext defines). >> >> This shouldn’t be a behavioral change at all, just documentation. >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Jun 21 08:27:27 2016 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 8880F12D970; Tue, 21 Jun 2016 08:27:25 -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 sEIlbfxoXLrA; Tue, 21 Jun 2016 08:27:24 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C6E12D96D; Tue, 21 Jun 2016 08:27:23 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-6e-57695cda5b23 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.47.12926.ADC59675; Tue, 21 Jun 2016 17:27:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 17:27:18 +0200 From: Christer Holmberg To: Magnus Westerlund , Flemming Andreasen , Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. Thread-Index: AQHRyw/UIl1SwULpvEegDZi1VKrJPJ/zxX8AgAAHmQCAADXYgP//3U+AgAArneA= Date: Tue, 21 Jun 2016 15:27:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380F9149@ESESSMB209.ericsson.se> References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> <558b361f-43e6-ee2c-e346-22448a6eddb5@ericsson.com> In-Reply-To: <558b361f-43e6-ee2c-e346-22448a6eddb5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7lu6tmMxwg8YDwhbTZ71js3h/Qddi /+LzzBZTlz9mcWDxmPJ7I6vHkiU/mTzant1hD2CO4rJJSc3JLEst0rdL4MroOXKOpWA7e8W0 I3/YGxg/snYxcnJICJhIHNs1lQnCFpO4cG89WxcjF4eQwBFGibVzNjJDOEsYJd4dPwdUxcHB JmAh0f1PGyQuIrCYUWLb1XYWkG5mgVyJjW9usoPYwgLZEnfmfGUEsUUEciRm7O1kgbD9JNZ1 3GcEmcMioCpx+zY/SJhXwFfiyeYDUIt7mCRmfv0PtotTwEHiwyU+kBpGoOO+n1rDBLFKXOLW k/lQRwtILNlznhnCFpV4+fgf1GNKEmsPb4c6TU/ixtQpbBC2tsSyha+ZIfYKSpyc+YRlAqPY LCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAmPr4JbfqjsYL79x PMQowMGoxMOroJ8RLsSaWFZcmXuIUYKDWUmENyg8M1yINyWxsiq1KD++qDQntfgQozQHi5I4 r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDY/jnPxMn6mUci4/K3MM8l3Off8+TWvecElX7yQcm TU+rbVq4fZHPqjiGW6dLvz/ObXvqt17zxP9Vc88/2BPxvf6R3eTyyGMTX26rMMrunRr1SuPQ zHyLjPWeU2+fTdkmeuInlx3zvn93HRf7cV9coSZq59q5d3uN3flSi5ms+564W+8tnn1W7IMS S3FGoqEWc1FxIgBoSZMmqQIAAA== Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:27:25 -0000 Hi, ... >> Regarding Magnus=B9 bullets 2) and 3), where is that information for the= =20 >> "urn:ietf:params:rtp-hdrext:sdes:cname=B2 defined in avtext-sdes-hdr-ext= ? >> The draft mentions CNAME here and there, but I can=B9t really find a=20 >> clear description of its usage in the RTP SDES header extension. > > > Well, as usually in retrospect, that part should have been written as its= own section so that it would provide an example. Instead it is spread out = across the whole document. As avtext-sdes-hdr-ext is supposed to be a "template" for other extensions,= I think it would be good to put it in a dedicated section. After all, CNAM= E is not even the main thing of the document, just one usage of the created= registry. Also, if we update BUNDLE (if something needs to be updated) I assume the t= ext talking about the MID SDES item will be removed from avtext-sdes-hdr-ex= t? Regards, Christer From nobody Tue Jun 21 13:43:23 2016 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 978C312D77C; Tue, 21 Jun 2016 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 jJ1Y2DMLdtvH; Tue, 21 Jun 2016 13:43:21 -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 393D612D7AF; Tue, 21 Jun 2016 13:43:17 -0700 (PDT) Received: from [10.0.1.4] (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 u5LKhGvn097997 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2016 15:43:16 -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.4] From: "Ben Campbell" To: draft-ietf-mmusic-mux-exclusive.all@ietf.org, mmusic Date: Tue, 21 Jun 2016 15:43:16 -0500 Message-ID: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 20:43:22 -0000 Hi, Here is my AD Evaluation of draft-ietf-mmusic-mux-exclusive-07. I think this is almost ready for IETF last call, but would like to see some discussion of my substantive comments first. Thanks! Ben. ---------------- Substantive: -- Why the pre-RFC5378 disclaimer? I assume it's due to the two quoted "OLD" paragraphs from RFC 5761. That RFC is post-5378, but also contains the disclaimer. Has there been any discussion about getting permission to use the standard boilerplate? (If not, why not?) -- 1, 3rd paragraph: I’d like to see a bit more guidance here. What do we mean by application? I _think_ we mean something like WebRTC, where there are no legacy UAs to talk to. But I’d hate to see someone implement this in a SIP UA that talks to other arbitrary SIP UAs, just because the implementor didn’t want to bother with the legacy case. Editorial: - 4.5, last paragraph: It seems odd to find 2119 keywords in a "NOTE". I usually think of such things as parenthetical sidebars, not core protocol definition. Please consider dropping the "NOTE:" prefix. -- 11.2, reference to bundle: Outdated reference. (The RFC editor will fix this, but if there happens to be an update before then...) From nobody Tue Jun 21 14:23:31 2016 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 7505112DE1A for ; Tue, 21 Jun 2016 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 jTznTGogdYcM for ; Tue, 21 Jun 2016 14:23:29 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6DE12DA09 for ; Tue, 21 Jun 2016 14:23:29 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-08v.sys.comcast.net with SMTP id FT8Lbg6CnlVqIFT8qbtHh8; Tue, 21 Jun 2016 21:23:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466544208; bh=zpEMJTxaWMwtqqVbJ4JAH3UeMY4xoWzZIjTWiAWqNzE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=sGnnZqMNzx3yAyVlELMdBHphdeMyhHOCLiLt3eBN0EdGXz7DmYd0Ch3DKLsd9UQ8i TbKdkNhg5i2xuFKkisRqnhfsZhTh5UeGjzJFwUyL++/MbNUllMzBghO9c20vnZguD+ CSvnTh9XiWfqh53voC3M//+cL745QELkyzaqU5JBTPcYwKiQyXGshKRyUqrbngBj9V 0GkIMw9hN46QrG2ebWC1Esi3gxhjm2bjK8wQF9Eamh1MT+nnsPu5SOr9JsSHLNvzYz sFdyZ7CIgS8kbfFPfucMkOPRwNcPd26hn9gO9LsZzTVU065DQ1txMyqB9ZB/0BGDRI 7zykkk/GYs1ig== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with comcast id 9ZPU1t00F3KdFy101ZPUeH; Tue, 21 Jun 2016 21:23:28 +0000 To: mmusic@ietf.org References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> From: Paul Kyzivat Message-ID: Date: Tue, 21 Jun 2016 17:23:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:23:30 -0000 On 6/21/16 4:43 PM, Ben Campbell wrote: > Substantive: > > -- Why the pre-RFC5378 disclaimer? I assume it's due to the two quoted > "OLD" paragraphs from RFC 5761. That RFC is post-5378, but also contains > the disclaimer. Has there been any discussion about getting permission > to use the standard boilerplate? (If not, why not?) I wouldn't expect the disclaimer to be required in this case. Wouldn't the paragraphs being quoted as "OLD" count as fair use under copyright law? Thanks, Paul From nobody Tue Jun 21 19:31:55 2016 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 54EB812DF36 for ; Tue, 21 Jun 2016 19:31:53 -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 I6rswNRPTjcQ for ; Tue, 21 Jun 2016 19:31:51 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A13A12DF37 for ; Tue, 21 Jun 2016 19:31:50 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-31-5769f8956dbd Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FE.0C.12516.598F9675; Wed, 22 Jun 2016 04:31:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 04:31:48 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 Thread-Index: AQHRy/2OgUKO4Reia0a7Ui6/wDcBFp/0TMqAgAB3rvc= Date: Wed, 22 Jun 2016 02:31:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380FB8F2@ESESSMB209.ericsson.se> References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380FB8F2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdV3fqj8xwg8UzJS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj+pXj7AVXFCumNlxkbmCcKtvFyMkhIWAi sWjFLVYIW0ziwr31bF2MXBxCAkcYJVaeew2WEBJYwiix4r56FyMHB5uAhUT3P22QsIiAr8Sz x7fZQMLCAp4Sfw8JQIS9JN5deckGYVtJ7Jgylx3EZhFQlXh7bhcTiM0L1LrjUycjxPQiic+3 DjKBjOEUcJD4ei0fJMwIdM33U2vAypkFxCWavqyEulJAYsme88wQtqjEy8f/WCFq8iV+9u9n hBgvKHFy5hOWCYzCs5C0z0JSNgtJGUTcQOLL+9tQtrbEsoWvmSFsfYnu96eZkMUXMLKvYhQt Ti0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMnINbfuvuYFz92vEQowAHoxIP74MdmeFCrIllxZW5 hxglOJiVRHgTvwOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJx cEo1MEacKtQU8+za8Zmn851+919ts9StN+O6NnYuszXdtfiH6/ONahOPta2bL1hQe63txZ0M 8ydd0340bj58IIL3Wz9rY/ymg8b7dKvnfd5R+OLcjbi3sQszrMwauvlY+fScZabM6v/em1pa NeG8S+x+tT6LOsMlxlas1jxX3KQqbxvv5eaIaC3rUmIpzkg01GIuKk4EAJNDQ5iYAgAA Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 02:31:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380FB8F2ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, The idnits tool informed about pre-5378 content, so I thought a way to fix = that was to include the disclaimer. I can remove the disclaimer. But, what shall I then say if someone asks abo= ut the idnits indication? Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD22/=FD06/=FD2016 00:23 To: mmusic@ietf.org Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 On 6/21/16 4:43 PM, Ben Campbell wrote: > Substantive: > > -- Why the pre-RFC5378 disclaimer? I assume it's due to the two quoted > "OLD" paragraphs from RFC 5761. That RFC is post-5378, but also contains > the disclaimer. Has there been any discussion about getting permission > to use the standard boilerplate? (If not, why not?) I wouldn't expect the disclaimer to be required in this case. Wouldn't the paragraphs being quoted as "OLD" count as fair use under copyright law? Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B380FB8F2ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
On 6/21/16 4:43 PM, Ben Campbell wrote:

> Substantive:
>
> -- Why the pre-RFC5378 disclaimer? I assume it's due to the two quoted=
> "OLD" paragraphs from RFC 5761. That RFC is post-5378, but a= lso contains
> the disclaimer. Has there been any discussion about getting permission=
> to use the standard boilerplate? (If not, why not?)

I wouldn't expect the disclaimer to be required in this case. Wouldn't
the paragraphs being quoted as "OLD" count as fair use under copy= right law?

        Thanks,
        Paul

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B380FB8F2ESESSMB209erics_-- From nobody Tue Jun 21 23:53:01 2016 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 2DBE512D1DE; Tue, 21 Jun 2016 23:53:00 -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 VZeIt5fhR6qV; Tue, 21 Jun 2016 23:52:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC45312D1D2; Tue, 21 Jun 2016 23:52:55 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-82-576a35c5b39c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.63.12516.5C53A675; Wed, 22 Jun 2016 08:52:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 08:52:53 +0200 From: Christer Holmberg To: Ben Campbell , "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Thread-Topic: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 Thread-Index: AQHRy/2OgUKO4Reia0a7Ui6/wDcBFp/1H0CA Date: Wed, 22 Jun 2016 06:52:53 +0000 Message-ID: References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> In-Reply-To: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5E968166BEF1214A8A166C00A955DC16@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7ou4x06xwgxMLuCzmd55mt7h6S8hi 6vLHLA7MHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXxoulX5kLlnJVrLzwm6WBsZWji5GT Q0LARGJBxxwmCFtM4sK99WxdjFwcQgJHGCV27exjhHCWMEocb/8P5HBwsAlYSHT/0waJiwjM Z5TYcnM+O0i3sICDxMHD0xhBbBEBR4m2S3/ZIGwjiea5n8BqWARUJfbcecoMYvMKWEmcmHeO BcQWErCTOD99CdgVnAL2EntW9LGC2IxAF30/tQYsziwgLnHryXyoSwUkluw5zwxhi0q8fPwP rF5UQE/iy715YHdKCChJTNuaBtGqJ3Fj6hQ2CNta4mnTNyhbW2LZwtdQ5whKnJz5hGUCo/gs JNtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjLuDW37r7mBc /drxEKMAB6MSD++DHZnhQqyJZcWVuYcYJTiYlUR4N5lkhQvxpiRWVqUW5ccXleakFh9ilOZg URLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgrFiX8ZjPxMZV0rsk4lqoYp/kSZsmvgkZH+Uq jp3vduSM5F1/trr5U9O8P33aG5K1uTpX/sh1i0naUH43+mGZ7NMNzR1zpJ5dV8js9kv8/mpT FlOWo27sAhkpDZ0X2eW9F++Fqs+r5YycJhHQ+/jE/ZAvujKr5rKzcIXv2JBZI25fkLvq3nkl luKMREMt5qLiRACkDbgJtwIAAA== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 06:53:00 -0000 Hi, ... >-- 1, 3rd paragraph: > >I=B9d like to see a bit more guidance here. What do we mean by >application? I _think_ we mean something like WebRTC, where there are no >legacy UAs to talk to. But I=B9d hate to see someone implement this in a >SIP UA that talks to other arbitrary SIP UAs, just because the >implementor didn=B9t want to bother with the legacy case. What about the following: "Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose to not implement separation of RTP and RTCP. Examples of such applications are W3C WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required to interoperate with non-WEBRTC clients. For such applications, this document defines an SDP attribute to signal intent to require multiplexing." >Editorial: > >- 4.5, last paragraph: >It seems odd to find 2119 keywords in a "NOTE". I usually think of such >things as parenthetical sidebars, not core protocol definition. Please >consider dropping the "NOTE:" prefix. I=B9ll drop it. > >-- 11.2, reference to bundle: > >Outdated reference. (The RFC editor will fix this, but if there happens >to be an update before then...) I=B9ll fix it. Thanks! Regards, Christer From nobody Wed Jun 22 02:03:23 2016 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 05D4F12B060; Wed, 22 Jun 2016 02:03: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 Ps8eNQ6LxfEX; Wed, 22 Jun 2016 02:03:20 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E78712B054; Wed, 22 Jun 2016 02:03:19 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-21-576a5455fb98 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.18.12926.5545A675; Wed, 22 Jun 2016 11:03:17 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.294.0; Wed, 22 Jun 2016 11:03:15 +0200 To: Christer Holmberg , Flemming Andreasen , Jonathan Lennox , mmusic References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> <558b361f-43e6-ee2c-e346-22448a6eddb5@ericsson.com> <7594FB04B1934943A5C02806D1A2204B380F9149@ESESSMB209.ericsson.se> From: Magnus Westerlund Message-ID: <7ddcd953-d670-44fc-e5ce-83f2626d5382@ericsson.com> Date: Wed, 22 Jun 2016 11:03:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380F9149@ESESSMB209.ericsson.se> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM2K7q25oSFa4wd9HVhbTZ71js3h/Qddi /+LzzBZTlz9mcWDxmPJ7I6vHkiU/mTzant1hD2CO4rJJSc3JLEst0rdL4Mo4v6SVrWCFcMX2 0x+YGxhX8XcxcnJICJhI7D/+jwnCFpO4cG89WxcjF4eQwBFGiQmN39khnOWMEv0Xj7CCVAkL ZEt0TV4GViUisJhR4v+UrYwQVReYJDYevMQOUsUskCux8c1NMJtNwELi5o9GNhCbV8BeYtXr brA4i4CqxKEnXSwgtqhAjETj7cPsEDWCEidnPgGLcwr4STw49RjI5gCaaS/xYGsZxHh5ieat s5lBbCEBbYmGpg7WCYyCs5B0z0LomIWkYwEj8ypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2M wGA+uOW36g7Gy28cDzEKcDAq8fA+2JEZLsSaWFZcmXuIUYKDWUmE93FAVrgQb0piZVVqUX58 UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUwWSYOTqkGRkEedSfLZ6Ye3QKhbDcl5gla SH+0Vb7C72Sz+kOesZSllIDpkxUXZsZdidjUraSz99rOt9xXvW8sK6vRf7Vzi1JPkWZeZeGR r9M/STFvnrJdq9OnbVHZVjm1nq6jf2f/fnLFtHOHdP2WaBEbjxiJrZNMjM7MqeO0Ev3zTLjl lZ+txJY9e475KLEUZyQaajEXFScCAHbq8l9iAgAA Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 09:03:22 -0000 Den 2016-06-21 kl. 17:27, skrev Christer Holmberg: > Hi, > > ... > >>> Regarding Magnus¹ bullets 2) and 3), where is that information >>> for the "urn:ietf:params:rtp-hdrext:sdes:cname² defined in >>> avtext-sdes-hdr-ext? The draft mentions CNAME here and there, but >>> I can¹t really find a clear description of its usage in the RTP >>> SDES header extension. >> >> >> Well, as usually in retrospect, that part should have been written >> as its own section so that it would provide an example. Instead it >> is spread out across the whole document. > > As avtext-sdes-hdr-ext is supposed to be a "template" for other > extensions, I think it would be good to put it in a dedicated > section. After all, CNAME is not even the main thing of the document, > just one usage of the created registry. > > Also, if we update BUNDLE (if something needs to be updated) I assume > the text talking about the MID SDES item will be removed from > avtext-sdes-hdr-ext? > I think the only text in SDES header ext document about BUNDLE is the following: The ongoing work on bundling SDP media descriptions [I-D.ietf-mmusic-sdp-bundle-negotiation] has identified a new SDES item that can benefit from timely delivery. A corresponding RTP SDES compact header extension is therefore also defined and registered in that document: MID: This is a media description identifier that matches the value of the Session Description Protocol (SDP) [RFC4566] a=mid attribute [RFC5888], to associate RTP streams multiplexed on the same transport with their respective SDP media description. All I can see that is does is saying. Hey, there is this other document that also have a SDES item that needs a header extension. Here is the abstract what it does. Go read the bundle draft for the details. I don't see an issue with leaving that in. Do you? Or have I forgotten about some other text about bundle? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jun 22 02:07:03 2016 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 BCB0112B060; Wed, 22 Jun 2016 02:07:01 -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 9f2OMC2ElnAh; Wed, 22 Jun 2016 02:07:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2835E12B054; Wed, 22 Jun 2016 02:07:00 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-a0-576a5532ccf8 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 33.22.18043.2355A675; Wed, 22 Jun 2016 11:06:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 11:06:57 +0200 From: Christer Holmberg To: Magnus Westerlund , Flemming Andreasen , Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. Thread-Index: AQHRyw/UIl1SwULpvEegDZi1VKrJPJ/zxX8AgAAHmQCAADXYgP//3U+AgAArneCAAQZQAIAANGeA Date: Wed, 22 Jun 2016 09:06:58 +0000 Message-ID: References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> <558b361f-43e6-ee2c-e346-22448a6eddb5@ericsson.com> <7594FB04B1934943A5C02806D1A2204B380F9149@ESESSMB209.ericsson.se> <7ddcd953-d670-44fc-e5ce-83f2626d5382@ericsson.com> In-Reply-To: <7ddcd953-d670-44fc-e5ce-83f2626d5382@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <83253AE530DEC140A7B658E60554097F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7qK5RaFa4wYU1yhbTZ71js3h/Qddi /+LzzBZTlz9mcWDxmPJ7I6vHkiU/mTzant1hD2CO4rJJSc3JLEst0rdL4Mq4dWQWW0EjV8Xr /7PZGxjvsncxcnJICJhIXJo7GcoWk7hwbz1bFyMXh5DAEUaJH7MuMkI4SxglFp45yNzFyMHB JmAh0f1PGyQuIrCYUWLb1XYWkG5mgVyJjW9ugk0SFsiW6Jq8jA3EFhHIkZixt5MFwo6SuHVg D1icRUBVYmtfK5jNK2AlseDwLWaIZW3MErP7ZzKCJDgFHCRuNrSAFTECnff91BomiGXiEree zGeCOFtAYsme88wQtqjEy8f/WEFsUQE9iS/35jFCxBUldp5tZ4bo1ZFYsPsTG4RtLfH2xXx2 CFtbYtnC18wQBwlKnJz5hGUCo8QsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLSSy3K TC4uzs/Ty0st2cQIjNODW35b7WA8+NzxEKMAB6MSD++DHZnhQqyJZcWVuYcYJTiYlUR4Hwdk hQvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgnKMypbuo XOPH3VXHr/Lu7q5w49pxpqNScIVRgfy1qwsZBIVWtc6dt9ij7faC1SJFz2808v1P26JjtnZb pVzXVefgpwFt0cyrb97nmjv/UiU//51be+6dCZj95EnIq8tOHI8b5mtuaLtuPm/21FuNd+Vm PKhaeTXmc+jFA9onTjwLnCso1c/0WlSJpTgj0VCLuag4EQDY0Ci2zwIAAA== Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 09:07:01 -0000 Hi, ... >>Also, if we update BUNDLE (if something needs to be updated) I assume >> the text talking about the MID SDES item will be removed from >> avtext-sdes-hdr-ext? >> > >I think the only text in SDES header ext document about BUNDLE is the >following: > > The ongoing work on bundling SDP media descriptions > [I-D.ietf-mmusic-sdp-bundle-negotiation] has identified a new SDES > item that can benefit from timely delivery. A corresponding RTP SDES > compact header extension is therefore also defined and registered in > that document: > > MID: This is a media description identifier that matches the value > of the Session Description Protocol (SDP) [RFC4566] a=3Dmid > attribute [RFC5888], to associate RTP streams multiplexed on the > same transport with their respective SDP media description. > >All I can see that is does is saying. Hey, there is this other document >that also have a SDES item that needs a header extension. Here is the >abstract what it does. Go read the bundle draft for the details. > >I don't see an issue with leaving that in. Do you? Or have I forgotten >about some other text about bundle? No, you are correct. It can be left in the document. Regards, Christer From nobody Wed Jun 22 07:52:03 2016 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 C20BE12D675; Wed, 22 Jun 2016 07:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 WXmlswE2F0TK; Wed, 22 Jun 2016 07:52: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 E1EED12D924; Wed, 22 Jun 2016 07:44:50 -0700 (PDT) Received: from [10.0.1.4] (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 u5MEij49096805 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2016 09:44:46 -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.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 22 Jun 2016 09:44:48 -0500 Message-ID: In-Reply-To: References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 14:52:03 -0000 On 22 Jun 2016, at 1:52, Christer Holmberg wrote: [...] > > What about the following: > > "Some newer applications that do not require backward compatibility > with peers that cannot multiplex RTCP might choose to not implement > separation of RTP and RTCP. Examples of such applications are W3C > WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required > to interoperate with non-WEBRTC clients. For such applications, > this > document defines an SDP attribute to signal intent to require > multiplexing." > That's a good start. Would it make sense to add something to the effect of the following: "The use of this attribute in SDP offers by user agents that ever need to interoperate with peers that do not support RTC/RTCP multiplexing may harm interoperability." [...] Thanks! Ben. From nobody Wed Jun 22 08:25:57 2016 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 2860E12DC68; Wed, 22 Jun 2016 08:25:43 -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 s4_wkNsKEhgw; Wed, 22 Jun 2016 08:25:40 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F47612D7B3; Wed, 22 Jun 2016 08:13:04 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-e8-576aaafee816 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 00.ED.18043.EFAAA675; Wed, 22 Jun 2016 17:13:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 17:12:52 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 Thread-Index: AQHRy/2OgUKO4Reia0a7Ui6/wDcBFp/1H0CAgABQfQCAAClfpg== Date: Wed, 22 Jun 2016 15:12:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38100099@ESESSMB209.ericsson.se> References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38100099ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7tO6/VVnhBjP+KlrM7zzNbnH1lpDF 1OWPWRyYPZYs+cnkMWvnE5YApigum5TUnMyy1CJ9uwSujOn7brIU7FCr+Diln7GBcbliFyMH h4SAiUTXEu0uRk4gU0ziwr31bF2MXBxCAkcYJabumMIK4SxhlHh26i87SAObgIVE9z+wBhEB JYnnzVtZQGxmgVqJg7vfsoLYwgIOErtm72aBqHGUaLv0lw3CdpLY+62DCcRmEVCVeHxhI5jN K+ArMfnrRXaIXYsYJY79vAWW4BSwlzi8bC07iM0IdN33U2uYIJaJSzR9WckKcbWAxJI955kh bFGJl4//sULU5Eucn/acEWKBoMTJmU9YJjCKzELSPgtJ2SwkZRBxA4kv729D2doSyxa+Zoaw 9SW6359mQhZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwvg5u+W21g/Hgc8dDjAIc jEo8vA92ZIYLsSaWFVfmHmKU4GBWEuFVBUanEG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rh QgLpiSWp2ampBalFMFkmDk6pBkb36vbYGR+nHtgnIfbXv+tXVIfuFw7Flx5cZzfqKF5fGDvB 8qJBg4dWcbQQR57I/vjVrkp2Tgy6CyqSUqNcip45ZJ6Ymlskte74418yS0w49PmYjyx/8PtB +tOLN7aKbYl3BhqydV5HS//pKawC64I9gn7cvH5S+fbx1x5u/zKV39q5rLizUYmlOCPRUIu5 qDgRAIZmcFerAgAA Archived-At: Cc: "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 15:25:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38100099ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I'll add the text you suggested and submit a new version of the draft. Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD22/=FD06/=FD2016 17:44 To: Christer Holmberg Cc: draft-ietf-mmusic-mux-exclusive.all@ietf.org; mmusic Subject: Re: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 On 22 Jun 2016, at 1:52, Christer Holmberg wrote: [...] > > What about the following: > > "Some newer applications that do not require backward compatibility > with peers that cannot multiplex RTCP might choose to not implement > separation of RTP and RTCP. Examples of such applications are W3C > WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required > to interoperate with non-WEBRTC clients. For such applications, > this > document defines an SDP attribute to signal intent to require > multiplexing." > That's a good start. Would it make sense to add something to the effect of the following: "The use of this attribute in SDP offers by user agents that ever need to interoperate with peers that do not support RTC/RTCP multiplexing may harm interoperability." [...] Thanks! Ben. --_000_7594FB04B1934943A5C02806D1A2204B38100099ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I'll add the = text you suggested and submit a new version of the draft.

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =FD22= /=FD06/=FD2016 17:44
To: Christer Holmberg Cc: draft-ietf-mmusi= c-mux-exclusive.all@ietf.org; mmusic
Subject: Re: A= D Evaluation of draft-ietf-mmusic-mux-exclusive-07

On 22 Jun 2016, at 1:52, Christer Holmberg wrote:<= br>
[...]

>
> What about the following:
>
>    "Some newer applications that do not require ba= ckward compatibility
>    with peers that cannot multiplex RTCP might choose t= o not implement
>    separation of RTP and RTCP.  Examples of such a= pplications are W3C
>    WEBRTC [W3C.WD-webrtc-20120209] applications, that a= re not required
>    to interoperate with non-WEBRTC clients.  For s= uch applications,
> this
>    document defines an SDP attribute to signal intent t= o require
>    multiplexing."
>

That's a good start. Would it make sense to add something to the effect of the following:

"The use of this attribute in SDP offers by user agents that ever need=
to interoperate with peers that do not support RTC/RTCP multiplexing may harm interoperability."

[...]

Thanks!

Ben.
 --_000_7594FB04B1934943A5C02806D1A2204B38100099ESESSMB209erics_-- From nobody Wed Jun 22 08:48:55 2016 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 34B7212D8B0; Wed, 22 Jun 2016 08:48:50 -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 SNK1UCKvU8tj; Wed, 22 Jun 2016 08:48:47 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c: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 CBB9A12DC44; Wed, 22 Jun 2016 08:37:27 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id f126so92895218wma.1; Wed, 22 Jun 2016 08:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=Th9CdbO0JSnEiQRyy6YR6TOUAh/lfGJzx/u0r1zL3ao=; b=DD6qxsk2Hvsurhix4divT2sUAZZbpb7YSj7w5dYs/bamfY7tWvsP8qsPj8fXiUfAOy QQBDEy/r+4O1CdaPOX8mpztFggSxgWXIzazVzT7z+jf/sBBd0duajcrZfgEQsb15WD3z XJPufr9iITDK9BBfSJxDzoXIuL+LX14kTxYlHTOZzgu9KvApocPO+I1FJMHLIR/G3dzt MT1PPBk8DRnaWtWfT2PnX/XnW42R/ow8QHdC8cWb4bpg9tn6eX4i1I8aYPS7o7p0Wg9f dmTkefej3HAEQUO4kOR8hFG1Hl3P/R+2DmBegw4SPzkG+Pvv7vUVxqBxrVvtjyxqg1oa 3vlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=Th9CdbO0JSnEiQRyy6YR6TOUAh/lfGJzx/u0r1zL3ao=; b=Uh5f8wg58M9/pLLJ1vLe9uzTZ/SmzbPc6VwbSnbi+SRv3Af+lwz3Ltk2aEcjMWNUxc xaru0G62ELvgKZN+NOFiuT0jQi8PL70BigKFkHy0d6zrYvuqR6/wbk2WngGymNRifmf9 041cdnB7UXFlgijda16gcPYD362+SOpCL2Df8O4iUIvGLX8Rwuc8rEsy2dxWzMfpsrGS hTtMdnTty+y4giNGHEV8wpHMs+iWckfEbN/RTzCMvINgxzpFdMoxeU8GWFgeQofAAFPx oT7wRDHn25lYfIo5JFd36aUfQJQZr2i9dAWMyueXzk6UdVpL6VavAiGaHNW4Rbvg9pAm oxRA== X-Gm-Message-State: ALyK8tI93QJ6NtDB8js8ZXokWD4VFPMvi9/5FfbH42qhbw/eBL840QfJvIhGzK2ynHzeDA== X-Received: by 10.194.95.74 with SMTP id di10mr25846057wjb.52.1466609846324; Wed, 22 Jun 2016 08:37:26 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id u71sm1179456wmu.13.2016.06.22.08.37.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 08:37:25 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Suhas Nandakumar'" References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se> , <04d601d1ba7e$189ec900$49dc5b00$@gmail.com> <7594FB04B1934943A5C02806D1A2204B3801E9C6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3801E9C6@ESESSMB209.ericsson.se> Date: Wed, 22 Jun 2016 18:35:59 +0300 Message-ID: <13f501d1cc9b$c8409d50$58c1d7f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_13F6_01D1CCB4.ED904650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVDnqmqgE4v4cr5iz6Tekgwmz3YwI2aa3TAgpzyWkB91axhp89WGvg Content-Language: he Archived-At: Cc: 'Magnus Westerlund' , mmusic@ietf.org, 'Colin Perkins' , avt@ietf.org Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 15:48:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_13F6_01D1CCB4.ED904650 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Christer, I am not sure I understand you answer. I was wondering if the answerer = can ask to receive RTP/RTCP multiplex even if the offer did not include the rtp/rtcp-mux attribute by providing in an A=3Drtcp the port of for the RTP stream? Roni =20 From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, May 30, 2016 5:26 PM To: Roni Even; 'Suhas Nandakumar' Cc: Magnus Westerlund; 'Colin Perkins'; avt@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? =20 Hi, In an offer a=3Drtcp is used to provide a fallback port, in case the = answerer does not support RTP/RTCP-mux (but does support a=3Drtcp). Regards, Christer Sent from my Windows Phone _____ =20 From: Roni Even =20 Sent: =FD30/=FD05/=FD2016 17:19 To: 'Suhas Nandakumar' ; Christer Holmberg =20 Cc: Magnus Westerlund ; 'Colin Perkins' ; avt@ietf.org; mmusic@ietf.org Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? Hi, Agree with Suhas but have a question What if the offer has an a=3Drtcp with a port different from the RTP = one, and the response include a=3Drtcp using the same port as the RTP port? Is it allowed, at least in RFC3605 did not see any discussion about this =20 Roni =20 From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Suhas = Nandakumar Sent: Friday, May 27, 2016 4:26 AM To: Christer Holmberg Cc: Magnus Westerlund; Colin Perkins (csp@csperkins.org); = mmusic@ietf.org; avt@ietf.org Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? =20 Going along O/A negotiation procedures, i would lean towards your former conclusion that the offer needs to include the rtcp-mux ability. If the offer doesn't include a=3Drtcp-mux and the answerer wants to mux = , then it needs a new O/A from the answerer's perspectives. =20 =20 If we make a=3Drtcp-mux a declarative SDP it might solve the other = use-case .. =20 thanks Suhas =20 On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg wrote: (Sorry for the cross-posting) =20 Hi, =20 There has been a discussion in 3GPP regarding RFC 5761 (RTP/RTCP-mux). =20 Section 5.1.1 says: =20 5.1.1. SDP Signalling =20 When the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions following the offer/answer model [9], the "a=3Drtcp-mux" attribute (see Section 8) indicates the desire to multiplex RTP and RTCP onto a single port. The initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. For example: =20 v=3D0 o=3Dcsp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e s=3D- c=3DIN IP6 2001:DB8::211:24ff:fea3:7a2e t=3D1153134164 1153137764 m=3Daudio 49170 RTP/AVP 97 a=3Drtpmap:97 iLBC/8000 a=3Drtcp-mux =20 This offer denotes a unicast voice-over-IP session using the RTP/AVP profile with iLBC coding. The answerer is requested to send both RTP and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. =20 If the answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level "a=3Drtcp-mux" attribute in the answer. The RTP payload types used in the answer MUST conform to the rules in Section 4. =20 If the answer does not contain an "a=3Drtcp-mux" attribute, the = offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. =20 Q: The question is whether it is allowed to include a=3Drtcp-mux in an = answer if the associated offer did NOT contain a=3Drtcp-mux. =20 The second last paragraph in the text above does say that, if the answer wishes to do RTP/RTCP-mux, it includes a=3Drtcp-mux in the answer. =20 BUT, in my view that is it based on the first paragraph, which assumes a=3Drtcp-mux is also included in the offer. =20 Or, am I wrong? Is it allowed to include a=3Drtcp-mux in the answer, = even if it=92s not included in the offer? If so, how will the offerer then = indicate whether mux is used or not. =20 Regards, =20 Christer =20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt =20 ------=_NextPart_000_13F6_01D1CCB4.ED904650 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi Christer,

I am not sure I understand you answer. I was wondering if the = answerer can ask to receive RTP/RTCP multiplex even if the offer did not = include the rtp/rtcp-mux attribute by providing in = an

A=3Drtcp the port of for the RTP stream?

Roni

 

From:= = Christer Holmberg [mailto:christer.holmberg@ericsson.com] =
Sent: Monday, May 30, 2016 5:26 PM
To: Roni Even; = 'Suhas Nandakumar'
Cc: Magnus Westerlund; 'Colin Perkins'; = avt@ietf.org; mmusic@ietf.org
Subject: RE: [MMUSIC] [AVTCORE] = RTP/RTCP-mux: Attribute in answer if not included in = offer?

 

Hi,

= In an offer a=3Drtcp is used to provide a fallback port, in case the = answerer does not support RTP/RTCP-mux (but does support = a=3Drtcp).

Regards,

Christer

Sent from my Windows = Phone

From: = Roni Even
Sent: = =FD30/<= span lang=3DAR-SA style=3D'font-size:11.0pt'>=FD05/<= span lang=3DAR-SA style=3D'font-size:11.0pt'>=FD2016 = 17:19
To: = 'Suhas Nandakumar'; Christer = Holmberg
Cc: = Magnus Westerlund; 'Colin Perkins'; avt@ietf.org; mmusic@ietf.org
Subject: = Re: = [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in = offer?

Hi,

Agree with Suhas but have a question

What if the offer has an a=3Drtcp with a port different from the RTP = one, and the response include a=3Drtcp using the same port as the RTP = port? Is it allowed, at least in RFC3605 did not see any discussion = about this

 

Roni

 

From:= = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Suhas = Nandakumar
Sent: Friday, May 27, 2016 4:26 AM
To: = Christer Holmberg
Cc: Magnus Westerlund; Colin Perkins = (csp@csperkins.org); mmusic@ietf.org; avt@ietf.org
Subject: = Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included = in offer?

 

Going = along O/A negotiation procedures, i would lean towards your former = conclusion that the offer needs to include the rtcp-mux = ability.

If the offer doesn't = include a=3Drtcp-mux and the answerer wants to mux , then it needs a new = O/A from the answerer's perspectives.

 

 

If we make a=3Drtcp-mux a declarative SDP it might = solve the other use-case ..

 

thanks

Suhas

 

On Thu, = May 26, 2016 at 1:01 PM, Christer Holmberg <christer.holmberg@ericsson.com> = wrote:

(Sorry for the cross-posting)

 

Hi,

 

There has been a discussion in 3GPP = regarding RFC 5761 (RTP/RTCP-mux).

 

Section 5.1.1 = says:

 

5.1.1.  SDP Signalling

 

   When the Session Description Protocol (SDP) [8] is = used to negotiate

   RTP sessions following the offer/answer model [9], = the "a=3Drtcp-mux"

   = attribute (see Section 8) indicates the desire to multiplex RTP = and

   RTCP = onto a single port.  The initial SDP offer MUST include = this

   = attribute at the media level to request multiplexing of RTP and = RTCP

   on a = single port.  For example:

 

       v=3D0

       o=3Dcsp 1153134164 1153134164 = IN IP6 2001:DB8::211:24ff:fea3:7a2e

       s=3D-

       c=3DIN IP6 = 2001:DB8::211:24ff:fea3:7a2e

       t=3D1153134164 = 1153137764

       m=3Daudio 49170 RTP/AVP = 97

       a=3Drtpmap:97 = iLBC/8000

       = a=3Drtcp-mux

 

   This offer denotes a unicast voice-over-IP session = using the RTP/AVP

   profile with iLBC coding.  The answerer is = requested to send both RTP

   and = RTCP to port 49170 on IPv6 address = 2001:DB8::211:24ff:fea3:7a2e.

 

   If the answerer wishes to multiplex RTP and RTCP onto = a single port,

   it MUST include a media-level = "a=3Drtcp-mux" attribute in the = answer.

   The = RTP payload types used in the answer MUST conform to the rules = in

   = Section 4.

 

   If the answer does not contain an = "a=3Drtcp-mux" attribute, the offerer

   MUST = NOT multiplex RTP and RTCP packets on a single port.  = Instead,

   it = should send and receive RTCP on a port allocated according to = the

   usual = port-selection rules (either the port pair, or a signalled = port

   if the = "a=3Drtcp:" attribute [10] is also included).  This will = occur

   when = talking to a peer that does not understand the = "a=3Drtcp-mux"

   attribute.

 

Q: The question is whether it is = allowed to include a=3Drtcp-mux in an answer if the associated offer did = NOT contain a=3Drtcp-mux.

 

The second last paragraph in the = text above does say that, if the answer wishes to do RTP/RTCP-mux, it = includes a=3Drtcp-mux in the answer.

 

BUT, in my view that is it based on = the first paragraph, which assumes a=3Drtcp-mux is also included in the = offer.

 

Or, am I wrong? Is it allowed to include a=3Drtcp-mux in = the answer, even if it=92s not included in the offer? If so, how will = the offerer then indicate whether mux is used or = not.

 

Regards,

 

Christer

 


______________________________________= _________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

 

------=_NextPart_000_13F6_01D1CCB4.ED904650-- From nobody Wed Jun 22 10:30:27 2016 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 5D76812D9B7; Wed, 22 Jun 2016 10:30:22 -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 9cF2H9y-LfMT; Wed, 22 Jun 2016 10:30:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FC312D991; Wed, 22 Jun 2016 10:30:16 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-63-576acb25618f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.82.27088.52BCA675; Wed, 22 Jun 2016 19:30:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 19:29:36 +0200 From: Christer Holmberg To: Roni Even , 'Suhas Nandakumar' Thread-Topic: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? Thread-Index: AdG3iWsAcXNHXXrjTfakEZTp6P/ejwAHIEqAALHZ5oAABHKs+gSC+ReAAAgXIFA= Date: Wed, 22 Jun 2016 17:29:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38100A24@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se> , <04d601d1ba7e$189ec900$49dc5b00$@gmail.com> <7594FB04B1934943A5C02806D1A2204B3801E9C6@ESESSMB209.ericsson.se> <13f501d1cc9b$c8409d50$58c1d7f0$@gmail.com> In-Reply-To: <13f501d1cc9b$c8409d50$58c1d7f0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38100A24ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7k67a6axwg5+3mS1e9qxkt1j+8gSj xdTlj1ks/rYzW+yc28HswOox7f59No+ds+6yeyxZ8pMpgDmKyyYlNSezLLVI3y6BK2PTzi2M BdNfM1acPN3B2sC48hJjFyMnh4SAicStTY+hbDGJC/fWs3UxcnEICRxhlFh5YzozhLOEUWLJ jJ8sXYwcHGwCFhLd/7RBTBGBIIl9DQIgvcwCixklfn4zAgkLC8RK7HxgDBIWEYiTOLX7DQuE 7SfRfnspO4jNIqAqsbb7HlicV8BXYtOTF6wgtpDAJiaJebMUQWxOoEX/5h4EO40R6LTvp9Yw QawSl7j1ZD4TxMkCEkv2nGeGsEUlXj7+xwphK0ksuv0Zqj5fYuLzr1C7BCVOznzCMoFRdBaS UbOQlM1CUgYRN5A4t30jO4StLbFs4WtmCFtfYvvtmazI4gsY2VcxihanFiflphsZ6aUWZSYX F+fn6eWllmxiBEblwS2/DXYwvnzueIhRgINRiYf3wY7McCHWxLLiytxDjBIczEoivAHHssKF eFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MG48s1ejWJvz 4lKu+BqzpWpP7x2Pe63iWDnF7pO9o5e2hvTRb8oiL9P2JWQ1xd2um7libs23Au/+HX78X64t vHFvnmrnyjPLHbPzZn5uu8505cIn/rTjAot2r1l479jetUK+NxV8Nkv3d89+tOTm7H2vO0z+ u357XrR551+7qFdbZ9+02uWQ2flSiaU4I9FQi7moOBEATlb1HMYCAAA= Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , 'Colin Perkins' , "avt@ietf.org" Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 17:30:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38100A24ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, I don=92t think one should use a=3Drtcp to request RTP/RTCP multiplex. Regards, Christer From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 22 June 2016 18:36 To: Christer Holmberg ; 'Suhas Nandakumar' = Cc: Magnus Westerlund ; 'Colin Perkins' ; avt@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not in= cluded in offer? Hi Christer, I am not sure I understand you answer. I was wondering if the answerer can = ask to receive RTP/RTCP multiplex even if the offer did not include the rtp= /rtcp-mux attribute by providing in an A=3Drtcp the port of for the RTP stream? Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, May 30, 2016 5:26 PM To: Roni Even; 'Suhas Nandakumar' Cc: Magnus Westerlund; 'Colin Perkins'; avt@ietf.org; = mmusic@ietf.org Subject: RE: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not in= cluded in offer? Hi, In an offer a=3Drtcp is used to provide a fallback port, in case the answer= er does not support RTP/RTCP-mux (but does support a=3Drtcp). Regards, Christer Sent from my Windows Phone ________________________________ From: Roni Even Sent: =FD30/=FD05/=FD2016 17:19 To: 'Suhas Nandakumar'; Christer Holmberg Cc: Magnus Westerlund; 'Colin Perkin= s'; avt@ietf.org; mmusic@iet= f.org Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not in= cluded in offer? Hi, Agree with Suhas but have a question What if the offer has an a=3Drtcp with a port different from the RTP one, a= nd the response include a=3Drtcp using the same port as the RTP port? Is it= allowed, at least in RFC3605 did not see any discussion about this Roni From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Suhas Nandakumar Sent: Friday, May 27, 2016 4:26 AM To: Christer Holmberg Cc: Magnus Westerlund; Colin Perkins (csp@csperkins.org); mmusic@ietf.org; avt@ietf.org Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not in= cluded in offer? Going along O/A negotiation procedures, i would lean towards your former co= nclusion that the offer needs to include the rtcp-mux ability. If the offer doesn't include a=3Drtcp-mux and the answerer wants to mux , t= hen it needs a new O/A from the answerer's perspectives. If we make a=3Drtcp-mux a declarative SDP it might solve the other use-case= .. thanks Suhas On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg > wrote: (Sorry for the cross-posting) Hi, There has been a discussion in 3GPP regarding RFC 5761 (RTP/RTCP-mux). Section 5.1.1 says: 5.1.1. SDP Signalling When the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions following the offer/answer model [9], the "a=3Drtcp-mux" attribute (see Section 8) indicates the desire to multiplex RTP and RTCP onto a single port. The initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. For example: v=3D0 o=3Dcsp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e s=3D- c=3DIN IP6 2001:DB8::211:24ff:fea3:7a2e t=3D1153134164 1153137764 m=3Daudio 49170 RTP/AVP 97 a=3Drtpmap:97 iLBC/8000 a=3Drtcp-mux This offer denotes a unicast voice-over-IP session using the RTP/AVP profile with iLBC coding. The answerer is requested to send both RTP and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. If the answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level "a=3Drtcp-mux" attribute in the answer. The RTP payload types used in the answer MUST conform to the rules in Section 4. If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. Q: The question is whether it is allowed to include a=3Drtcp-mux in an answ= er if the associated offer did NOT contain a=3Drtcp-mux. The second last paragraph in the text above does say that, if the answer wi= shes to do RTP/RTCP-mux, it includes a=3Drtcp-mux in the answer. BUT, in my view that is it based on the first paragraph, which assumes a=3D= rtcp-mux is also included in the offer. Or, am I wrong? Is it allowed to include a=3Drtcp-mux in the answer, even i= f it=92s not included in the offer? If so, how will the offerer then indica= te whether mux is used or not. Regards, Christer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_7594FB04B1934943A5C02806D1A2204B38100A24ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I don=92t = think one should use a=3Drtcp to request RTP/RTCP multiplex.

 = ;

Regards,

 = ;

Christer

 = ;

 

From: = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 22 June 2016 18:36
To: Christer Holmberg <christer.holmberg@ericsson.com>; 'Suhas= Nandakumar' <suhasietf@gmail.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>; 'Colin= Perkins' <csp@csperkins.org>; avt@ietf.org; mmusic@ietf.org
Subject: RE: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if= not included in offer?

 

Hi Christer,

I am not sure I unders= tand you answer. I was wondering if the answerer can ask to receive RTP/RTC= P multiplex even if the offer did not include the rtp/rtcp-mux attribute by providing in an

A=3Drtcp the port of f= or the RTP stream?

Roni=

 

From: Ch= rister Holmberg [mailto:c= hrister.holmberg@ericsson.com]
Sent: Monday, May 30, 2016 5:26 PM
To: Roni Even; 'Suhas Nandakumar'
Cc: Magnus Westerlund; 'Colin Perkins'; avt@ietf.org; mmusic@ietf.org
Subject: RE: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if= not included in offer?

 

Hi,

In an offer a=3Drtcp is used to provide a fallback port, in case the answer= er does not support RTP/RTCP-mux (but does support a=3Drtcp).

Regards,

Christer

Sent from my Windows Phone

Fr= om: Roni E= ven
Sent: =FD30/=FD05/=FD2016 17:19
To: 'Suhas Na= ndakumar'; Christer Holmberg
Cc: Magnus Westerlund; 'Colin Perkins'; avt@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute i= n answer if not included in offer?

Hi,

Agree with Suhas but h= ave a question

What if the offer has = an a=3Drtcp with a port different from the RTP one, and the response includ= e a=3Drtcp using the same port as the RTP port? Is it allowed, at least in RFC3605 did not see any discussion about this<= span lang=3D"EN-US">

 

Roni

 

From: mm= usic [mailto:mmusic-bounces@ietf= .org] On Behalf Of Suhas Nandakumar
Sent: Friday, May 27, 2016 4:26 AM
To: Christer Holmberg
Cc: Magnus Westerlund; Colin Perkins (csp@csperkins.org); mmusic@ietf.org; avt@ietf.org
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if= not included in offer?

 

Going along O/A negotiation pro= cedures, i would lean towards your former conclusion that the offer needs t= o include the rtcp-mux ability.

If the offer doesn't include a= =3Drtcp-mux and the answerer wants to mux , then it needs a new O/A from th= e answerer's perspectives.

 

 

If we make a=3Drtcp-mux a decla= rative SDP it might solve the other use-case ..

 

thanks

Suhas

 

On Thu, May 26, 2016 at 1:01 PM= , Christer Holmberg <christer.holmberg@ericsson.com> wrote:

(Sorry for the cross-posting)

 

Hi,

 

There has been a discussion in 3GPP regarding RFC 57= 61 (RTP/RTCP-mux).

 

Section 5.1.1 says:<= /span>

 

5.1.1.  SDP Signalling

 

   When the Session Description Protocol (SDP) [= 8] is used to negotiate

   RTP sessions following the offer/answer model= [9], the "a=3Drtcp-mux"

   attribute (see Section 8) indicates the desir= e to multiplex RTP and

   RTCP onto a single port.  The initial SD= P offer MUST include this

   attribute at the media level to request multi= plexing of RTP and RTCP

   on a single port.  For example:

 

       v=3D0

       o=3Dcsp 1153134164 11= 53134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e

       s=3D-

       c=3DIN IP6 2001:DB8::= 211:24ff:fea3:7a2e

       t=3D1153134164 115313= 7764

       m=3Daudio 49170 RTP/A= VP 97

       a=3Drtpmap:97 iLBC/80= 00

       a=3Drtcp-mux

 

   This offer denotes a unicast voice-over-IP se= ssion using the RTP/AVP

   profile with iLBC coding.  The answerer = is requested to send both RTP=

   and RTCP to port 49170 on IPv6 address 2001:D= B8::211:24ff:fea3:7a2e.

 

   If the answerer wishes to multiplex RTP and R= TCP onto a single port,

   it MUST include a media-level "a=3Drtcp-= mux" attribute in the answer.

   The RTP payload types used in the answer MUST= conform to the rules in

   Section 4.

 

   If the answer does not contain an "a=3Dr= tcp-mux" attribute, the offerer=

   MUST NOT multiplex RTP and RTCP packets on a = single port.  Instead,

   it should send and receive RTCP on a port all= ocated according to the

   usual port-selection rules (either the port p= air, or a signalled port

   if the "a=3Drtcp:" attribute [10] i= s also included).  This will occur

   when talking to a peer that does not understa= nd the "a=3Drtcp-mux"

   attribute.

 

Q: The question is whether it is allowed to include = a=3Drtcp-mux in an answer if the associated offer did NOT contain a=3Drtcp-= mux.

 

The second last paragraph in the text above does say= that, if the answer wishes to do RTP/RTCP-mux, it includes a=3Drtcp-mux in= the answer.

 

BUT, in my view that is it based on the first paragr= aph, which assumes a=3Drtcp-mux is also included in the offer.

 

Or, am I wrong? Is it allowed to include a=3Drtcp-mu= x in the answer, even if it=92s not included in the offer? If so, how will = the offerer then indicate whether mux is used or not.<= o:p>

 

Regards,

 

Christer

 

=
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

 

--_000_7594FB04B1934943A5C02806D1A2204B38100A24ESESSMB209erics_-- From nobody Wed Jun 22 10:56:27 2016 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 22D8612D9E5 for ; Wed, 22 Jun 2016 10:56:22 -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=unavailable 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 0WSf3apfc1i5 for ; Wed, 22 Jun 2016 10:56:20 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D44912D9CC for ; Wed, 22 Jun 2016 10:56:20 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id s63so46812255ioi.3 for ; Wed, 22 Jun 2016 10:56:20 -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=2VlfORA8UXVTBZsur68DAyKby4hGrxe4unDhjhHZQbc=; b=N5G693F8jeeqojjJnopRf/1cLrBhjZo8gVh20wqZku4s0guG0JazFUIEdOGq9TA2zk uQQzbtOEjP165nNjpO/6+DsShVSoKiGVcUbd+r5czIKi6xmhnujuUC7e8QAiwUp0uvpm DXbe95SbLDa+r609E8Qzz3Q6DstVAmbVmFoB/lV6VAWaj4inSUAArzbyGS1vdIioOJHI Uf3S7/7tmmXPxmka3B6Te61Sizs/g6Uu693apewMUzLzFwdYETpthZTM9JUNHd1b2O5G Y3YyMsQnVYDCTzgZRqr/hGKudFSnjjlBTi8iKSh5QZh2GUPWvXWw26l9DP+ygVQeZREa 5TFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2VlfORA8UXVTBZsur68DAyKby4hGrxe4unDhjhHZQbc=; b=aM1ZZGhdOnrVzGTypfW+5xRLRzNXCqQ8tWhV9Z0d/FslhE6FmtQ3pnw1FP7K1dqfSu NWyATIsShEZdNzMtnpgI37GHrG/THshB8VAJgnWtIwCMdLv8qalFgcENt5oxZn5wfmPl M9XN/RjZDGa82ImL8LvTtPS/9HFjJLXuum2VQB8f0mBr8k1KnkJaEOHb51pLSI+ylKjX XoKDPgngr37ZX0264UQkxrynvRxYte0juqMVVAqRixKBoE1vAZutBGZDcxB6Umz/EGCE N1OTSlQcoobzyCQLI7i/z0QUjslO+snHXOxaPMHi3uP910BjLWP/cBfnKsm5CVxK0RnH Ubog== X-Gm-Message-State: ALyK8tKKWqv3F0KSh5/6lJASJtHsOVE7nTnkzcdSjWAIQiZTlhdG/AzQxz8i5eTZ8lQt4Q== X-Received: by 10.107.21.135 with SMTP id 129mr4684665iov.59.1466618179388; Wed, 22 Jun 2016 10:56:19 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id u135sm4207328ita.21.2016.06.22.10.56.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 10:56:18 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id g127so50494001ith.0; Wed, 22 Jun 2016 10:56:18 -0700 (PDT) X-Received: by 10.36.227.67 with SMTP id d64mr16628529ith.18.1466618178369; Wed, 22 Jun 2016 10:56:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.144.69 with HTTP; Wed, 22 Jun 2016 10:56:17 -0700 (PDT) In-Reply-To: <13f501d1cc9b$c8409d50$58c1d7f0$@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B37FF17DE@ESESSMB209.ericsson.se> <04d601d1ba7e$189ec900$49dc5b00$@gmail.com> <7594FB04B1934943A5C02806D1A2204B3801E9C6@ESESSMB209.ericsson.se> <13f501d1cc9b$c8409d50$58c1d7f0$@gmail.com> From: Roman Shpount Date: Wed, 22 Jun 2016 13:56:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Roni Even Content-Type: multipart/alternative; boundary=94eb2c111ada8b02ca0535e1a79f Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , avt@ietf.org, Christer Holmberg , Colin Perkins Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 17:56:22 -0000 --94eb2c111ada8b02ca0535e1a79f Content-Type: text/plain; charset=UTF-8 On Wed, Jun 22, 2016 at 11:35 AM, Roni Even wrote: > I am not sure I understand you answer. I was wondering if the answerer can > ask to receive RTP/RTCP multiplex even if the offer did not include the > rtp/rtcp-mux attribute by providing in an > > A=rtcp the port of for the RTP stream? > > > Setting a=rtcp to the same port as RTP port effectively can enable one way RTP/RTCP mux. So, it can work in an answer, but there is a big problem with it: end point has no way of knowing in advance that a=rtcp will be honored. It would typically mean that end point should be prepared to work without RTCP with RTCP sent to the wrong port. I would assume this is not a solution you would want for any new service. Regards, _____________ Roman Shpount --94eb2c111ada8b02ca0535e1a79f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 22, 2016 at 11:35 AM, Roni Even <ron.even.tlv@gmail.com&g= t; wrote:

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">I am not sure I understand you answer. I was wondering if the answer= er can ask to receive RTP/RTCP multiplex even if the offer did not include = the rtp/rtcp-mux attribute by providing in an

A=3Drtcp the port of for the RTP stream?



Setting a=3Drtcp to the same port as RTP port effectively can enable one w= ay RTP/RTCP mux. So, it can work in an answer, but there is a big problem w= ith it: end point has no way of knowing in advance that a=3Drtcp will be ho= nored. It would typically mean that end point should be prepared to work wi= thout RTCP with RTCP sent to the wrong port. I would assume this is not a s= olution you would want for any new service.

Regard= s,
_____________
Roman Shpount
=C2=A0
--94eb2c111ada8b02ca0535e1a79f-- From nobody Wed Jun 22 11:18:16 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2403B12D59E; Wed, 22 Jun 2016 11:18:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622181811.10983.32902.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2016 11:18:11 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 18:18:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-08.txt Pages : 12 Date : 2016-06-22 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 22 11:21:13 2016 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 70F8212D7E9; Wed, 22 Jun 2016 11:21:12 -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 7XK2Xzp7jeSQ; Wed, 22 Jun 2016 11:21:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D5A12D812; Wed, 22 Jun 2016 11:21:09 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-a1-576ad713a304 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.E2.18043.317DA675; Wed, 22 Jun 2016 20:21:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Wed, 22 Jun 2016 20:21:07 +0200 From: Christer Holmberg To: Christer Holmberg , Ben Campbell Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] Thread-Index: AdHMststYSnZwTq4QaCIxWBAA2FhlA== Date: Wed, 22 Jun 2016 18:21:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38100D31@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38100D31ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdUlfkela4waRTTBbzO0+zW1y9JWQx dfljFgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEr49/eWewFG70rNsx7w9bAOMW5i5GT Q0LARGLflIesELaYxIV769m6GLk4hASOMErMXrafBcJZwijx/cEK9i5GDg42AQuJ7n/aIA0i AhES3+4sZgKxmQVqJQ7ufgs2SFigWuLcp7dgg0QEGhglrs54zwrRoCexb2YfI4jNIqAqMetu N1icV8BX4uWeRywgNiPQFd9PrYEaKi5x68l8JojrBCSW7DnPDGGLSrx8/A/qaiWJRbc/Q9Xn S0xc+ZgJYqagxMmZT1gmMArPQjJqFpKyWUjKIOIGEue2b2SHsLUlli18zQxh60tsvz2TFVl8 ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzASDq45bfVDsaDzx0PMQpwMCrx8CpcygoX Yk0sK67MPcQowcGsJMLrdA0oxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6Yklqdmpq QWoRTJaJg1OqgTH7bMmkyF5HflG3zXZfmbKV2R6fDOFevaeKe8W/bTX9fzZ7h1xl9X6RHa2Z afZ6y9pipeU8Z2att9o6L0CYx9U9S7zacebRzgL+W85XXz8OP3A3We7Xkdv9/L2eJde/muc8 zpL0e7Mu6cxENm/P6o1Mmbt178/JPVuT+Ctzy6rrjWk7D15be1uJpTgj0VCLuag4EQC3CluM oAIAAA== Archived-At: Cc: "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 18:21:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38100D31ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-08) of draft-mux-exclusive, based on Ben= =92s AD comments. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 22 June 2016 18:13 To: Ben Campbell Cc: draft-ietf-mmusic-mux-exclusive.all@ietf.org; mmusic Subject: RE: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 I'll add the text you suggested and submit a new version of the draft. Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD22/=FD06/=FD2016 17:44 To: Christer Holmberg Cc: draft-ietf-mmusic-mux-exclusive.all@ietf.org; mmusic Subject: Re: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 On 22 Jun 2016, at 1:52, Christer Holmberg wrote: [...] > > What about the following: > > "Some newer applications that do not require backward compatibility > with peers that cannot multiplex RTCP might choose to not implement > separation of RTP and RTCP. Examples of such applications are W3C > WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required > to interoperate with non-WEBRTC clients. For such applications, > this > document defines an SDP attribute to signal intent to require > multiplexing." > That's a good start. Would it make sense to add something to the effect of the following: "The use of this attribute in SDP offers by user agents that ever need to interoperate with peers that do not support RTC/RTCP multiplexing may harm interoperability." [...] Thanks! Ben. --_000_7594FB04B1934943A5C02806D1A2204B38100D31ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I=92ve sub= mitted a new version (-08) of draft-mux-exclusive, based on Ben=92s AD comm= ents.

 = ;

Regards,

 = ;

Christer

 

From: = Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 22 June 2016 18:13
To: Ben Campbell <ben@nostrum.com>
Cc: draft-ietf-mmusic-mux-exclusive.all@ietf.org; mmusic <mmusic@= ietf.org>
Subject: RE: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07

 

I'll add the text you suggested and submit a new ve= rsion of the draft.

Regards,

Christer

Sent from my Windows Phone

From: Ben Campbell
Sent: =FD22/=FD06/=FD2016 17:44
To: Chris= ter Holmberg
Cc: draft-ietf-mmusic-mux-exclusive.all@ietf.org; mmusic
Subject: Re: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07

On 22 Jun 2016, at = 1:52, Christer Holmberg wrote:

[...]

>
> What about the following:
>
>    "Some newer applications that do not require ba= ckward compatibility
>    with peers that cannot multiplex RTCP might choose t= o not implement
>    separation of RTP and RTCP.  Examples of such a= pplications are W3C
>    WEBRTC [W3C.WD-webrtc-20120209] applications, that a= re not required
>    to interoperate with non-WEBRTC clients.  For s= uch applications,
> this
>    document defines an SDP attribute to signal intent t= o require
>    multiplexing."
>

That's a good start. Would it make sense to add something to the effect of the following:

"The use of this attribute in SDP offers by user agents that ever need=
to interoperate with peers that do not support RTC/RTCP multiplexing may harm interoperability."

[...]

Thanks!

Ben.

--_000_7594FB04B1934943A5C02806D1A2204B38100D31ESESSMB209erics_-- From nobody Wed Jun 22 12:17:52 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E05812D619; Wed, 22 Jun 2016 12:17:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622191751.11011.18647.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2016 12:17:51 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 19:17:51 -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-17.txt Pages : 61 Date : 2016-06-22 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-17 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 22 12:23:41 2016 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 72FBC12D5E8 for ; Wed, 22 Jun 2016 12:23:40 -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 Htwzf6xAIrKq for ; Wed, 22 Jun 2016 12:23:38 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209B212D8E9 for ; Wed, 22 Jun 2016 12:23:33 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r2so37296702oih.2 for ; Wed, 22 Jun 2016 12:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=CVg3XVevJzb30G8VdfkKKYL7zN6h6V0vhRLe0LJib3U=; b=XbHg1aUrRdZ2rr1e96xiP8rLGAM6iR26F5hQGN5TgdJNFlisUF7aOu6BD648zABQkY utR2OoqzsEbegqHnGayxaRMWEK0nS/oPQa/CvoL7uvDqpbJDvbdFPK6TLWlvDZ9B0gy6 xLBk76fLrMdD6A+RuR5UQgF9B8y/Jv3l4QuKY6Wn4QiB4/Kw+ijXKX9lpX3Jl3qBRf6c xsplx4lSjNG+7i95AjPKMYhwoCdFHWg2kaSVSCANEuYjeOHhXQUOM5Cm7cgc9XNAW6Kf Uy7+A5X3aOAz4nuJvF2+dh7heVmp8czlhJ70p11A4Ezi8c7NXgsD7RaafcrELaI9vten bNfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=CVg3XVevJzb30G8VdfkKKYL7zN6h6V0vhRLe0LJib3U=; b=XZOUmxPloV/RZ2/W+s/EjOGX+dRzWOJkpXPw7ZmJvCzJrrmeEDTtCPa3jeXCi0R33x eN0oSvEg77ChW1ukfYmVAdAj4fuFypJLux+bddd1sBuQVU4lvx5b0clUJBNcHOZ8S0kK 22Hr03pNXoYtOpt4mrngvITU477dojYjm7ThlTcOQLxzG9c2PCh2Ln3VVai1UrPedTrl HXs0oDNHlYMDiQwqzwfQQF4jLlkhguhjiFdDXGbtjro9eMUJmh5oBoCH1lcai8k0akIR snDL1t0C282p/0o3J8vIgKqN+MXtAZ4zw2zpMsREhQk1rGhh9zEJkrbVfdoIKdBSTOFB RX5A== X-Gm-Message-State: ALyK8tIkst1xGxWbLU2PxJ3BC8dFgk0/LkdDIO+NthmxHLKfiF5qF2LCS7WX7Gq6/yJTblXlyi6Mx9vnfgj2sg== X-Received: by 10.157.27.146 with SMTP id z18mr3370353otd.16.1466623412188; Wed, 22 Jun 2016 12:23:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.180.2 with HTTP; Wed, 22 Jun 2016 12:23:31 -0700 (PDT) In-Reply-To: <20160622191751.11011.18647.idtracker@ietfa.amsl.com> References: <20160622191751.11011.18647.idtracker@ietfa.amsl.com> From: "Ali C. Begen" Date: Wed, 22 Jun 2016 22:23:31 +0300 Message-ID: To: "mmusic (E-mail)" Content-Type: multipart/alternative; boundary=001a113d011480e4ec0535e2df5f Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 19:23:40 -0000 --001a113d011480e4ec0535e2df5f Content-Type: text/plain; charset=UTF-8 Hi everyone The 4566bis revision has the edits mainly provided by Christian G. Please check Section 8, for the IANA registration rules and the new registry that will combine most of the existing registries into a single one. There is only one editor's note remaining. AFAIR, Paul had an action item to check it. Besides this point, the draft should be ready for a final review. Thanks. -acbegen On Wed, Jun 22, 2016 at 10:17 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 : SDP: Session Description Protocol > Authors : Mark Handley > Van Jacobson > Colin Perkins > Ali Begen > Filename : draft-ietf-mmusic-rfc4566bis-17.txt > Pages : 61 > Date : 2016-06-22 > > 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's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-17 > > > 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 > --001a113d011480e4ec0535e2df5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone

The 4566bis revision has th= e edits mainly provided by Christian G. Please check Section 8, for the IAN= A registration rules and the new registry that will combine most of the exi= sting registries into a single one.

There is only = one editor's note remaining. AFAIR, Paul had an action item to check it= . Besides this point, the draft should be ready for a final review.

Thanks.
-acbegen

On Wed, Jun 22, 2016 at 10:17 PM, <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= SDP: Session Description Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mark= Handley
=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 Van Jacobson
=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 Colin Perkins
=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 Ali Begen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-rfc4566bis-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 61
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-22

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.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mm= usic-rfc4566bis-17

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


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

--001a113d011480e4ec0535e2df5f-- From nobody Wed Jun 22 13:49:23 2016 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 3C6C312DBD4 for ; Wed, 22 Jun 2016 13:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 r4M_A0SLSxh2 for ; Wed, 22 Jun 2016 13:49:19 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F89F12D6A1 for ; Wed, 22 Jun 2016 13:49:18 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-07v.sys.comcast.net with SMTP id Fp4rbDlKUrtfLFp5Jb1Mjt; Wed, 22 Jun 2016 20:49:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466628557; bh=tXZQFLlRiKJNNpWqyPC0T+iNFQFE/luMRUuwgfICZiQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UkVMHkBer+LmgHOQoHjQ9R+Z5keOM+469VcUgnEPk4Z+Py27Lhph3MqN4zWVGvz5I rVi1tOC+ZuIoyl4ktqz+YjKuNoqwqqxs3qgFXoP5LZ4uTTzWR5MJj6ZZrExQR3h9Lp pXB46Uu/86EVy5LUaJWOTiWEMf4RFbeYp9CPGDgcyaRyb73v1TgZiAGbkura9UdcPS GChU1DdtMYxBiVegmeg4T07d/Jofyfxcq/70hvzpJte7V5LBWPfMFo0FtUEB+OfKKY DwhuyGgkXPF192ZRhdnxWZ6biR1XtkS7KcrlMIgIOmugPu/eaf5eFnAauW7dryQktF 5wsg3bh9C2p6g== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id 9wpH1t0063KdFy101wpHLs; Wed, 22 Jun 2016 20:49:17 +0000 To: mmusic@ietf.org References: <20160622191751.11011.18647.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <8019c67c-5b1e-d356-cb7d-ca6eb2007be5@alum.mit.edu> Date: Wed, 22 Jun 2016 16:49:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 20:49:21 -0000 On 6/22/16 3:23 PM, Ali C. Begen wrote: > Hi everyone > > The 4566bis revision has the edits mainly provided by Christian G. > Please check Section 8, for the IANA registration rules and the new > registry that will combine most of the existing registries into a single > one. > > There is only one editor's note remaining. AFAIR, Paul had an action > item to check it. Besides this point, the draft should be ready for a > final review. I did reply about this in: http://mailarchive.ietf.org/arch/msg/mmusic/4m0T7Mmo95IIZE4QamL3zNHra-o But I queried (without response) on sip-implementors, not sip forum. For completeness I just now sent the same query to techwg@sipforum.org. I'll report back if I hear anything. Thanks, Paul From nobody Wed Jun 22 14:20:40 2016 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 1BA3912DC52 for ; Wed, 22 Jun 2016 14:20:34 -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 wmvKM329rndy for ; Wed, 22 Jun 2016 14:20:32 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0344112DC50 for ; Wed, 22 Jun 2016 14:20:32 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r2so41793494oih.2 for ; Wed, 22 Jun 2016 14:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VOUyT7qpzAos1hwi4zRER0s/XghcdG8wD3fNecumv8c=; b=XTMFQQvvBE13DwbVRFNi9xGSe1YnxLLlY5REnOrYQ4fWmIR6hKFvXOzB6+j755gQ+M y4KyfdbjBtgTZ4gG0dSA5Fhawq+JoX86ELUX26q+fYfKgWiHqZt/sUUkBXAuFDxDTDKV 0i4oPuIOFhWESc4sSQImjvbVCvjcsf3wr4GjcJBGn1diD0DYwKHnD2Rhcf3ifAqEBbAS Mnkie4pjpj3awAR9Zxni3r2GbsWyrIujbVraJ7q7GaWnRlRxkmDWxSpiRL/uKFsVN/5Y bstOuJ8jBOli1RSwdc7P8fEVWey+YCIl6CWcx7cDSazCVXQh3HoIjrWPZdLClcFpuCHX 1VUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VOUyT7qpzAos1hwi4zRER0s/XghcdG8wD3fNecumv8c=; b=f2qqQz/rrKTaxWY35OIak9L2S59GyFWVBP+kR69kWBtURtNI+OS925Od+H226USXEX 7z5q/2s6ZkivXC84+U03QPhRwQHIHNs4IB2CTFlQ+V90Teyytk0wqParPYDdYj3YAhL9 kbovg9bInbDRwegYHKgr292Y1kChrKbMMteg0FnBXoWZAe+r/bRMrhw7BgJ5GHknmBBe PYHTEvqUslnXdhHneBpxIc3EsWaZdOjqI1LnJhYnVNtEtE1akubqHluprIwOC+DTatG6 D42pvzRKNCx+sIJpyH/oD2ULcMmqTckwUUTSJ0F7zLYSgU8PKQ0axGVmHDm2yRtDuydR sDGg== X-Gm-Message-State: ALyK8tLPgHYkas7o4/2AIEB8Rx67conICOx9oQcNm1DvYRwuve4JionzubH+SwYqn7bZ3A80zuQ8tPkkxCnifg== X-Received: by 10.202.230.7 with SMTP id d7mr3537989oih.182.1466630431435; Wed, 22 Jun 2016 14:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.180.2 with HTTP; Wed, 22 Jun 2016 14:20:30 -0700 (PDT) In-Reply-To: <8019c67c-5b1e-d356-cb7d-ca6eb2007be5@alum.mit.edu> References: <20160622191751.11011.18647.idtracker@ietfa.amsl.com> <8019c67c-5b1e-d356-cb7d-ca6eb2007be5@alum.mit.edu> From: "Ali C. Begen" Date: Thu, 23 Jun 2016 00:20:30 +0300 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11413bcae20d8f0535e48114 Archived-At: Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 21:20:34 -0000 --001a11413bcae20d8f0535e48114 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 22, 2016 at 11:49 PM, Paul Kyzivat wrote: > On 6/22/16 3:23 PM, Ali C. Begen wrote: > >> Hi everyone >> >> The 4566bis revision has the edits mainly provided by Christian G. >> Please check Section 8, for the IANA registration rules and the new >> registry that will combine most of the existing registries into a single >> one. >> >> There is only one editor's note remaining. AFAIR, Paul had an action >> item to check it. Besides this point, the draft should be ready for a >> final review. >> > > I did reply about this in: > > http://mailarchive.ietf.org/arch/msg/mmusic/4m0T7Mmo95IIZE4QamL3zNHra-o > > But I queried (without response) on sip-implementors, not sip forum. > > For completeness I just now sent the same query to techwg@sipforum.org. > I'll report back if I hear anything. > OK thanks. I think for the time being, we can assume they will not have a response that will impact the draft. > > Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11413bcae20d8f0535e48114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 22, 2016 at 11:49 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 6/22/16 3:23 PM, Ali C. Begen wrote:
Hi everyone

The 4566bis revision has the edits mainly provided by Christian G.
Please check Section 8, for the IANA registration rules and the new
registry that will combine most of the existing registries into a single one.

There is only one editor's note remaining. AFAIR, Paul had an action item to check it. Besides this point, the draft should be ready for a
final review.

 I did reply about this in:

http://mailarchive.ietf.org/a= rch/msg/mmusic/4m0T7Mmo95IIZE4QamL3zNHra-o

But I queried (without response) on sip-implementors, not sip forum.

For completeness I just now sent the same query to techwg@sipforum.org. I'll report b= ack if I hear anything.

OK thanks. I th= ink for the time being, we can assume they will not have a response that wi= ll impact the draft.
=C2=A0

=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

--001a11413bcae20d8f0535e48114-- From nobody Thu Jun 23 17:32:27 2016 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 6162D12D783 for ; Thu, 23 Jun 2016 17:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 XWuSNvWmQBno for ; Thu, 23 Jun 2016 17:32:24 -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 E155012B042 for ; Thu, 23 Jun 2016 17:32:23 -0700 (PDT) Received: from [10.0.1.4] (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 u5O0WA7p029655 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2016 19:32:10 -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.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Thu, 23 Jun 2016 19:32:09 -0500 Message-ID: <6786C847-69AA-4427-8586-17A342FE9051@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380FB8F2@ESESSMB209.ericsson.se> References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> <7594FB04B1934943A5C02806D1A2204B380FB8F2@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat , Colin Perkins Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 00:32:25 -0000 (+ Magnus and Colin) The idnits tool will warn about that anytime you update a pre-5378 draft, or you update a later draft with the pre-5378 disclaimer. That doesn't necessarily mean you need the disclaimer--it's just telling you to think about it. I think this is a borderline case, since there is in fact quoted text. As an individual, I agree with Paul that it should count as fair use by US standards, but I don't know about other jurisdictions. The cleanest option would be to see if the previous authors (copied) will agree to letting you use the text without the disclaimer. Ben. On 21 Jun 2016, at 21:31, Christer Holmberg wrote: > Hi, > > The idnits tool informed about pre-5378 content, so I thought a way to > fix that was to include the disclaimer. > > I can remove the disclaimer. But, what shall I then say if someone > asks about the idnits indication? > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Paul Kyzivat > Sent: ‎22/‎06/‎2016 00:23 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] AD Evaluation of > draft-ietf-mmusic-mux-exclusive-07 > > On 6/21/16 4:43 PM, Ben Campbell wrote: > >> Substantive: >> >> -- Why the pre-RFC5378 disclaimer? I assume it's due to the two >> quoted >> "OLD" paragraphs from RFC 5761. That RFC is post-5378, but also >> contains >> the disclaimer. Has there been any discussion about getting >> permission >> to use the standard boilerplate? (If not, why not?) > > I wouldn't expect the disclaimer to be required in this case. Wouldn't > the paragraphs being quoted as "OLD" count as fair use under copyright > law? > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jun 23 17:33:39 2016 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 510E712D5CC; Thu, 23 Jun 2016 17:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 gYsy4tfNzfJV; Thu, 23 Jun 2016 17:33:35 -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 A1BE712B042; Thu, 23 Jun 2016 17:33:35 -0700 (PDT) Received: from [10.0.1.4] (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 u5O0XWAu029782 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2016 19:33:32 -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.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Thu, 23 Jun 2016 19:33:31 -0500 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38100D31@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B38100D31@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 00:33:37 -0000 This version addresses my comments. I will request IETF last call. I see you removed the pre-5378 disclaimer. That might have been = premature, but we can always put it back before final publication if we = decide we need to. Thanks! Ben. On 22 Jun 2016, at 13:21, Christer Holmberg wrote: > Hi, > > I=E2=80=99ve submitted a new version (-08) of draft-mux-exclusive, base= d on = > Ben=E2=80=99s AD comments. > > Regards, > > Christer > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 22 June 2016 18:13 > To: Ben Campbell > Cc: draft-ietf-mmusic-mux-exclusive.all@ietf.org; mmusic = > > Subject: RE: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 > > I'll add the text you suggested and submit a new version of the draft. > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: =E2=80=8E22/=E2=80=8E06/=E2=80=8E2016 17:44 > To: Christer Holmberg > Cc: = > draft-ietf-mmusic-mux-exclusive.all@ietf.org; = > mmusic > Subject: Re: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 > On 22 Jun 2016, at 1:52, Christer Holmberg wrote: > > [...] > >> >> What about the following: >> >> "Some newer applications that do not require backward = >> compatibility >> with peers that cannot multiplex RTCP might choose to not = >> implement >> separation of RTP and RTCP. Examples of such applications are W3C >> WEBRTC [W3C.WD-webrtc-20120209] applications, that are not = >> required >> to interoperate with non-WEBRTC clients. For such applications, >> this >> document defines an SDP attribute to signal intent to require >> multiplexing." >> > > That's a good start. Would it make sense to add something to the = > effect > of the following: > > "The use of this attribute in SDP offers by user agents that ever need > to interoperate with peers that do not support RTC/RTCP multiplexing = > may > harm interoperability." > > [...] > > Thanks! > > Ben. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jun 23 17:56:49 2016 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 C828512D5CC for ; Thu, 23 Jun 2016 17:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 8HteLSdSPyUF for ; Thu, 23 Jun 2016 17:56:45 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BB612D16F for ; Thu, 23 Jun 2016 17:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jnRW7r+0mtCjg8xjcMhNuPGc+8EJPaXAjs89LJvSuWM=; b=MjcCP/IqPlSuTlkS3NDhZwDPBr wOZVopq/CBYt+9bkF9KPCsn7FrPz5Pa0EjSAVs5TLZ/PwEc0u/fpVhtAamza+67BQSg2GD24AXiww RB/7Th225PjUQnClfGdTyztn6dJvJAo8Is7YrJ9yUQEqyQVqIVMzSY2PNaqsDj1si+IGOiV0QCGX8 TJ/TMD/r8L46ZprK51JwrR6i2Go5gPXIcZfSf3KLwziEPTiB2VO+FtZ/mjBcbQ442PmifZ7ZprXtK kAECqYwibkOqRQ8qZ5jrVC7NCDSoBuZs9II13OQxW93WOFwQ0781Y+OA0OXWm32QSZocBwHaT7c8w bZL7tolw==; Received: from ppp118-209-146-59.lns20.mel8.internode.on.net ([118.209.146.59]:53281 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bGFQI-002Oaf-Eq; Fri, 24 Jun 2016 10:56:42 +1000 To: "Ali C. Begen" , "mmusic (E-mail)" References: <20160622191751.11011.18647.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <5bca6303-35f4-c176-3d56-8eb983751811@nteczone.com> Date: Fri, 24 Jun 2016 10:56:36 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 00:56:48 -0000 Hello Ali, Thanks for doing the updates. The only issue is regarding the "Dependent on Charset" being part of the table on the IANA website. During the discussion with Paul and Flemming on developing the updates it was thought that this should be removed from the IANA website table but still included in the information needed for the registration. The reason was that its an implementation issue and an implementor should read the RFC for this level of detail. Regards, Christian On 23/06/2016 5:23 AM, Ali C. Begen wrote: > Hi everyone > > The 4566bis revision has the edits mainly provided by Christian G. > Please check Section 8, for the IANA registration rules and the new > registry that will combine most of the existing registries into a > single one. > > There is only one editor's note remaining. AFAIR, Paul had an action > item to check it. Besides this point, the draft should be ready for a > final review. > > Thanks. > -acbegen > > On Wed, Jun 22, 2016 at 10:17 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 : SDP: Session Description Protocol > Authors : Mark Handley > Van Jacobson > Colin Perkins > Ali Begen > Filename : draft-ietf-mmusic-rfc4566bis-17.txt > Pages : 61 > Date : 2016-06-22 > > 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's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-17 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Jun 24 00:30:54 2016 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 5174112D9A7; Fri, 24 Jun 2016 00:30:53 -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 RupAakmoXZHH; Fri, 24 Jun 2016 00:30:50 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535CB12D9A5; Fri, 24 Jun 2016 00:30:49 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-b8-576ce1a77b96 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.EA.12926.7A1EC675; Fri, 24 Jun 2016 09:30:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0294.000; Fri, 24 Jun 2016 09:30:07 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] Thread-Index: AdHMststYSnZwTq4QaCIxWBAA2FhlAA7Gm6AABK8ExA= Date: Fri, 24 Jun 2016 07:30:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3810669B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B38100D31@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdXXf5w5xwg839GhbzO0+zW1y9JWQx dfljFgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEr48TKKcwFGyQr7iywa2C8I9HFyMkh IWAi0XroLCuELSZx4d56ti5GLg4hgSOMEp/72lkhnCWMEktPfmfpYuTgYBOwkOj+pw3SICKg JPG8eSsLiM0sUCtxcPdbsHphgQ5GiesfPzCCOCICnYwS3/89Y4XosJJ42feUCcRmEVCV+L1q CjOIzSvgK7HvwQeo1U2MEg0Hl4ElOAXsJd7vW8YGYjMC3ff91BomiHXiEreezGeCuFtAYsme 88wQtqjEy8f/oP5Rklh0+zMTyNXMApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGMVmIZk6C6Fj FpKOWUg6FjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKODW36r7mC8/MbxEKMAB6MS D+8C5ZxwIdbEsuLK3EOMEhzMSiK8rveAQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmk J5akZqemFqQWwWSZODilGhhDvgsfntW78Mc2/YJmqR+nIvnkFhUfPWvVpXFluuv0oIIl/fk/ bbQmbNn/ZWdHcO/W+TLPz6ToeQlFpb9t+CV8z6+WubAveKthRZ1xefKZV6Xvn7uLfTHMnjB/ 98kO2wkBiwtFs5P2TD4aUMlzIPHNHBv+yOuxLK4eKzhu7XR7q5vicd09+p4SS3FGoqEWc1Fx IgCU8VOjnwIAAA== Archived-At: Cc: "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 07:30:53 -0000 SGksDQoNCj5UaGlzIHZlcnNpb24gYWRkcmVzc2VzIG15IGNvbW1lbnRzLiBJIHdpbGwgcmVxdWVz dCBJRVRGIGxhc3QgY2FsbC4NCg0KQnVlbm8hIDopDQoNCj5JIHNlZSB5b3UgcmVtb3ZlZCB0aGUg cHJlLTUzNzggZGlzY2xhaW1lci4gVGhhdCBtaWdodCBoYXZlIGJlZW4gcHJlbWF0dXJlLCBidXQg d2UgY2FuIGFsd2F5cyBwdXQgaXQgPmJhY2sgYmVmb3JlIGZpbmFsIHB1YmxpY2F0aW9uIGlmIHdl IGRlY2lkZSB3ZSBuZWVkIHRvLg0KDQpZZXMuDQoNClRoYW5rcyEgOikNCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCk9uIDIyIEp1biAyMDE2LCBhdCAxMzoyMSwgQ2hyaXN0ZXIgSG9sbWJl cmcgd3JvdGU6DQoNCj4gSGksDQo+DQo+IEnigJl2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAo LTA4KSBvZiBkcmFmdC1tdXgtZXhjbHVzaXZlLCBiYXNlZCBvbiANCj4gQmVu4oCZcyBBRCBjb21t ZW50cy4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gRnJvbTogQ2hyaXN0ZXIg SG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQo+IFNlbnQ6 IDIyIEp1bmUgMjAxNiAxODoxMw0KPiBUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+ DQo+IENjOiBkcmFmdC1pZXRmLW1tdXNpYy1tdXgtZXhjbHVzaXZlLmFsbEBpZXRmLm9yZzsgbW11 c2ljIA0KPiA8bW11c2ljQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogQUQgRXZhbHVhdGlvbiBv ZiBkcmFmdC1pZXRmLW1tdXNpYy1tdXgtZXhjbHVzaXZlLTA3DQo+DQo+IEknbGwgYWRkIHRoZSB0 ZXh0IHlvdSBzdWdnZXN0ZWQgYW5kIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4N Cj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gU2VudCBmcm9tIG15IFdpbmRvd3Mg UGhvbmUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogQmVuIENh bXBiZWxsPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+DQo+IFNlbnQ6IOKAjjIyL+KAjjA2L+KAjjIw MTYgMTc6NDQNCj4gVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+DQo+IENjOiANCj4gZHJhZnQtaWV0Zi1tbXVzaWMtbXV4LWV4Y2x1c2l2 ZS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbW11c2ljLQ0KPiBtdXgtZXhjbHVzaXZl LmFsbEBpZXRmLm9yZz47DQo+IG1tdXNpYzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KPiBTdWJq ZWN0OiBSZTogQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLW1tdXNpYy1tdXgtZXhjbHVzaXZl LTA3DQo+IE9uIDIyIEp1biAyMDE2LCBhdCAxOjUyLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToN Cj4NCj4gWy4uLl0NCj4NCj4+DQo+PiBXaGF0IGFib3V0IHRoZSBmb2xsb3dpbmc6DQo+Pg0KPj4g ICAgIlNvbWUgbmV3ZXIgYXBwbGljYXRpb25zIHRoYXQgZG8gbm90IHJlcXVpcmUgYmFja3dhcmQg DQo+PiBjb21wYXRpYmlsaXR5DQo+PiAgICB3aXRoIHBlZXJzIHRoYXQgY2Fubm90IG11bHRpcGxl eCBSVENQIG1pZ2h0IGNob29zZSB0byBub3QgDQo+PiBpbXBsZW1lbnQNCj4+ICAgIHNlcGFyYXRp b24gb2YgUlRQIGFuZCBSVENQLiAgRXhhbXBsZXMgb2Ygc3VjaCBhcHBsaWNhdGlvbnMgYXJlIFcz Qw0KPj4gICAgV0VCUlRDIFtXM0MuV0Qtd2VicnRjLTIwMTIwMjA5XSBhcHBsaWNhdGlvbnMsIHRo YXQgYXJlIG5vdCANCj4+IHJlcXVpcmVkDQo+PiAgICB0byBpbnRlcm9wZXJhdGUgd2l0aCBub24t V0VCUlRDIGNsaWVudHMuICBGb3Igc3VjaCBhcHBsaWNhdGlvbnMsIA0KPj4gdGhpcw0KPj4gICAg ZG9jdW1lbnQgZGVmaW5lcyBhbiBTRFAgYXR0cmlidXRlIHRvIHNpZ25hbCBpbnRlbnQgdG8gcmVx dWlyZQ0KPj4gICAgbXVsdGlwbGV4aW5nLiINCj4+DQo+DQo+IFRoYXQncyBhIGdvb2Qgc3RhcnQu IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gYWRkIHNvbWV0aGluZyB0byB0aGUgDQo+IGVmZmVjdCBv ZiB0aGUgZm9sbG93aW5nOg0KPg0KPiAiVGhlIHVzZSBvZiB0aGlzIGF0dHJpYnV0ZSBpbiBTRFAg b2ZmZXJzIGJ5IHVzZXIgYWdlbnRzIHRoYXQgZXZlciBuZWVkIA0KPiB0byBpbnRlcm9wZXJhdGUg d2l0aCBwZWVycyB0aGF0IGRvIG5vdCBzdXBwb3J0IFJUQy9SVENQIG11bHRpcGxleGluZyANCj4g bWF5IGhhcm0gaW50ZXJvcGVyYWJpbGl0eS4iDQo+DQo+IFsuLi5dDQo+DQo+IFRoYW5rcyENCj4N Cj4gQmVuLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K From nobody Fri Jun 24 00:54:38 2016 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 ABEAD12D197 for ; Fri, 24 Jun 2016 00:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 SkcyZn1dGn7r for ; Fri, 24 Jun 2016 00:54:34 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D86412D9CE for ; Fri, 24 Jun 2016 00:54:34 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id u201so105241670oie.0 for ; Fri, 24 Jun 2016 00:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=48o3wDKxszv/CX/zWmnqT4in9BNVKVcNHLFvJ8VSJhU=; b=Zivi2FAjQY5aHsqhppjVTWu8qv3vYRsSJe3+q9wMnjYN9YKzmwfSSag8+46CIIuCLO pKnPQYCugWaDyAezkfko4e0QrphfT8fGSVj8iBuD7q9x/7ugMAqHpDhG+MYtdErfU0lQ aFVCUTTAAX5B50ahdKfDt+sakteoyjYlW3V+hrLxop6w/pw5ztoDsW5DukaKrxDeKZ1Y Fjl70CHAh3vY6usbSsHuR8jH9hjDzHbIsFFDftO2m9l63IZP0XgevlpjkxmG4ar2k35j XxO5FvXl6KalXqZw5ZhhLgztnVecpd1kmjoL/hAadKvzaE0GI8tr8hoLkkROw9ni696O wuGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=48o3wDKxszv/CX/zWmnqT4in9BNVKVcNHLFvJ8VSJhU=; b=PhfkQ/eiNklwpAq9F+5zbdOAiK80DFOdVK58qLv2ZHKEDiastB3mYq1o/SKExDRXdb 7Yg4iwJBFBT4epOjGHnNa+xFjYhonVd4h2LhEvaZufm870XKnrp4p4rWk20S3ONwgbn8 jnBpmCF5kUS5Fo4Z3m/+woZ1b2y5vJF6ai1MX5EGumqtD1aJUy8Hr9g8kv2KyvGtl9bo mgSf+jF3d3w8jonEOw11GE05Loecc4yEnlQLo8e2qOtktXSU9AmR4ECuQIdPyxjROiVC DjXWobxE9sHkWOXNgwVGlsUjVAR1LFnI5Y7o6S/cJ17xHhSt+wOENwZVBsgyqt9O1laO jXbQ== X-Gm-Message-State: ALyK8tKIb3zxgl4OrjdX0amWWXYMi/OgoMmuz18BoxYccJGgfheat+Xp1V1qYb2zV8GV17dNSdoYff7TefqyrQ== X-Received: by 10.202.83.4 with SMTP id h4mr1570888oib.107.1466754873743; Fri, 24 Jun 2016 00:54:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.180.2 with HTTP; Fri, 24 Jun 2016 00:54:33 -0700 (PDT) In-Reply-To: <5bca6303-35f4-c176-3d56-8eb983751811@nteczone.com> References: <20160622191751.11011.18647.idtracker@ietfa.amsl.com> <5bca6303-35f4-c176-3d56-8eb983751811@nteczone.com> From: "Ali C. Begen" Date: Fri, 24 Jun 2016 10:54:33 +0300 Message-ID: To: Christian Groves Content-Type: multipart/alternative; boundary=001a113d3a0238e0830536017b78 Archived-At: Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 07:54:36 -0000 --001a113d3a0238e0830536017b78 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 24, 2016 at 3:56 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Ali, > > Thanks for doing the updates. The only issue is regarding the "Dependent > on Charset" being part of the table on the IANA website. During the > discussion with Paul and Flemming on developing the updates it was thought > that this should be removed from the IANA website table but still included > in the information needed for the registration. The reason was that its an > implementation issue and an implementor should read the RFC for this level > of detail. > Alright, I can remove that. Chairs, are we getting close to the WGLC? > > Regards, Christian > > > On 23/06/2016 5:23 AM, Ali C. Begen wrote: > >> Hi everyone >> >> The 4566bis revision has the edits mainly provided by Christian G. Please >> check Section 8, for the IANA registration rules and the new registry that >> will combine most of the existing registries into a single one. >> >> There is only one editor's note remaining. AFAIR, Paul had an action item >> to check it. Besides this point, the draft should be ready for a final >> review. >> >> Thanks. >> -acbegen >> >> On Wed, Jun 22, 2016 at 10:17 PM, > internet-drafts@ietf.org>> wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Multiparty Multimedia Session >> Control of the IETF. >> >> Title : SDP: Session Description Protocol >> Authors : Mark Handley >> Van Jacobson >> Colin Perkins >> Ali Begen >> Filename : draft-ietf-mmusic-rfc4566bis-17.txt >> Pages : 61 >> Date : 2016-06-22 >> >> 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's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-17 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-17 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at >> tools.ietf.org . >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > --001a113d3a0238e0830536017b78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 24, 2016 at 3:56 AM, Christian Groves <= ;Christi= an.Groves@nteczone.com> wrote:
Hello Ali,

Thanks for doing the updates. The only issue is regarding the "Depende= nt on Charset" being part of the table on the IANA website. During the= discussion with Paul and Flemming on developing the updates it was thought= that this should be removed from the IANA website table but still included= in the information needed for the registration. The reason was that its an= implementation issue and an implementor should read the RFC for this level= of detail.

Alright, I can remove that.= =C2=A0

Chairs, are we getting close to the WGLC?

=C2=A0

Regards, Christian


On 23/06/2016 5:23 AM, Ali C. Begen wrote:
Hi everyone

The 4566bis revision has the edits mainly provided by Christian G. Please c= heck Section 8, for the IANA registration rules and the new registry that w= ill combine most of the existing registries into a single one.

There is only one editor's note remaining. AFAIR, Paul had an action it= em to check it. Besides this point, the draft should be ready for a final r= eview.

Thanks.
-acbegen

On Wed, Jun 22, 2016 at 10:17 PM, <internet-drafts@ietf.org <mailto:internet-drafts@ietf.or= g>> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts
=C2=A0 =C2=A0 directories.
=C2=A0 =C2=A0 This draft is a work item of the Multiparty Multimedia Sessio= n
=C2=A0 =C2=A0 Control of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: SDP: Session Description Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Mark Handley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Van Jacobson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Colin Perkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ali Begen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-mmusic-rfc4566bis-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 61
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2016-06-22

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This memo defines the Session Description Protoc= ol (SDP).=C2=A0 SDP is
=C2=A0 =C2=A0 =C2=A0 =C2=A0intended for describing multimedia sessions for = the purposes of
=C2=A0 =C2=A0 =C2=A0 =C2=A0session announcement, session invitation, and ot= her forms of
=C2=A0 =C2=A0 =C2=A0 =C2=A0multimedia session initiation.=C2=A0 This docume= nt obsoletes RFC 4566.


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

=C2=A0 =C2=A0 There's also a htmlized version available at:
=C2=A0 =C2=A0 https://tools.ietf.org/html= /draft-ietf-mmusic-rfc4566bis-17

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-17


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

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

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




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


--001a113d3a0238e0830536017b78-- From nobody Fri Jun 24 03:21:48 2016 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 27E2312DA11 for ; Fri, 24 Jun 2016 03:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 48KzlG9qtJ5a for ; Fri, 24 Jun 2016 03:21:44 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3993512DA0D for ; Fri, 24 Jun 2016 03:21:44 -0700 (PDT) Received: from [81.187.2.149] (port=43231 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bGOF2-0002Mj-FM; Fri, 24 Jun 2016 11:21:41 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <6786C847-69AA-4427-8586-17A342FE9051@nostrum.com> Date: Fri, 24 Jun 2016 11:21:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE85BD4-E69A-4263-BEB7-526DF7E3A7AA@csperkins.org> References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> <7594FB04B1934943A5C02806D1A2204B380FB8F2@ESESSMB209.ericsson.se> <6786C847-69AA-4427-8586-17A342FE9051@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 10:21:46 -0000 > On 24 Jun 2016, at 01:32, Ben Campbell wrote: >=20 > (+ Magnus and Colin) >=20 > The idnits tool will warn about that anytime you update a pre-5378 = draft, or you update a later draft with the pre-5378 disclaimer. That = doesn't necessarily mean you need the disclaimer--it's just telling you = to think about it. >=20 > I think this is a borderline case, since there is in fact quoted text. = As an individual, I agree with Paul that it should count as fair use by = US standards, but I don't know about other jurisdictions. The cleanest = option would be to see if the previous authors (copied) will agree to = letting you use the text without the disclaimer. I=E2=80=99m happy for you to use any parts of RFC 5761 I wrote under the = new terms, without the disclaimer. --=20 Colin Perkins https://csperkins.org/ From nobody Fri Jun 24 07:42:42 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 628F612DB40; Fri, 24 Jun 2016 07:42:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160624144241.10837.30678.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 07:42:41 -0700 Archived-At: Cc: Flemming Andreasen , ben@nostrum.com, draft-ietf-mmusic-mux-exclusive@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org Subject: [MMUSIC] Last Call: (Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 14:42:41 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-07-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jun 24 09:03:19 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 577E312DC89; Fri, 24 Jun 2016 09:00:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160043.10933.45939.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:43 -0700 Archived-At: Cc: ben@nostrum.com, mmusic@ietf.org Subject: [MMUSIC] mmusic - Requested session has been scheduled for IETF 96 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:43 -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 (1:00:00) Wednesday, Morning Session I 1000-1230 Room Name: Charlottenburg II/III size: 175 --------------------------------------------- Special Note: 11:30-12:30 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): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: i2nsf dots core payload dispatch sipcore avtext avtcore rtcweb httpbis ice tls Second Priority: clue p2psip straw xrblock rmcat stir tram sfc sacm Special Requests: --------------------------------------------------------- From nobody Mon Jun 27 06:33:50 2016 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 C9F2A126579 for ; Mon, 27 Jun 2016 06:33:47 -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 i1GtWfFoUJL1 for ; Mon, 27 Jun 2016 06:33:44 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC2F12B046 for ; Mon, 27 Jun 2016 06:33:43 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-86-57712b353b92 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.65.27088.63B21775; Mon, 27 Jun 2016 15:33:42 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.294.0; Mon, 27 Jun 2016 15:33:41 +0200 To: Ben Campbell , Christer Holmberg References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> <7594FB04B1934943A5C02806D1A2204B380FB8F2@ESESSMB209.ericsson.se> <6786C847-69AA-4427-8586-17A342FE9051@nostrum.com> From: Magnus Westerlund Message-ID: Date: Mon, 27 Jun 2016 15:33:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <6786C847-69AA-4427-8586-17A342FE9051@nostrum.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM2J7iK6ZdmG4wbnTPBbzO0+zWyx/eYLR YuryxywWKzYcYHVg8fj7/gOTx7T799k8liz5yeQxa+cTlgCWKC6blNSczLLUIn27BK6M6Y9v sBfcF6342zaVuYHxuGAXIyeHhICJxMoNq5khbDGJC/fWs3UxcnEICRxhlJjx/DsjhLOcUeLS j4dgVcICnhJvn6xiB7FFBCIkVh28wARR9JZR4uDjnSwgCWaBIol5Bw+B2WwCFhI3fzSygdi8 AvYS52/cAbNZBFQlHn7cwgRiiwrESDTePswOUSMocXLmE7BeTqD6I1ufs0HMtJCYOf88I4Qt L9G8dTbYQUIC2hINTR2sExgFZyFpn4WkZRaSlgWMzKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJS SzYxAkP74JbfBjsYXz53PMQowMGoxMObEFAQLsSaWFZcmXuIUYKDWUmEd4NmYbgQb0piZVVq UX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUwWSYOTqkGxh0zpx2wN3gudfglx8sb NU5zN95/oOoVs8vV1K3D/+V3/lOHlbJudBrnTmR5vXz19M8+syu/btmvHHjow+EN6xRitRK7 +Ra3nuCbnv2liO3eobSvzD+9N79qXKu/helo1D0TZu+X/v9/HNlUe+TRowtS789aSzx6Gx37 eeeRvMV8f14tf3tY3nyFEktxRqKhFnNRcSIACuQH92kCAAA= Archived-At: Cc: "mmusic@ietf.org" , Paul Kyzivat , Colin Perkins Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 13:33:48 -0000 Hi, I allow you to use any parts of RFC 5761 I wrote under the new terms, without the disclaimer. Cheers Magnus Den 2016-06-24 kl. 02:32, skrev Ben Campbell: > (+ Magnus and Colin) > > The idnits tool will warn about that anytime you update a pre-5378 > draft, or you update a later draft with the pre-5378 disclaimer. That > doesn't necessarily mean you need the disclaimer--it's just telling you > to think about it. > > I think this is a borderline case, since there is in fact quoted text. > As an individual, I agree with Paul that it should count as fair use by > US standards, but I don't know about other jurisdictions. The cleanest > option would be to see if the previous authors (copied) will agree to > letting you use the text without the disclaimer. > > Ben. > > On 21 Jun 2016, at 21:31, Christer Holmberg wrote: > >> Hi, >> >> The idnits tool informed about pre-5378 content, so I thought a way to >> fix that was to include the disclaimer. >> >> I can remove the disclaimer. But, what shall I then say if someone >> asks about the idnits indication? >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ________________________________ >> From: Paul Kyzivat >> Sent: ‎22/‎06/‎2016 00:23 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 >> >> On 6/21/16 4:43 PM, Ben Campbell wrote: >> >>> Substantive: >>> >>> -- Why the pre-RFC5378 disclaimer? I assume it's due to the two quoted >>> "OLD" paragraphs from RFC 5761. That RFC is post-5378, but also contains >>> the disclaimer. Has there been any discussion about getting permission >>> to use the standard boilerplate? (If not, why not?) >> >> I wouldn't expect the disclaimer to be required in this case. Wouldn't >> the paragraphs being quoted as "OLD" count as fair use under copyright >> law? >> >> 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 > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 27 07:44:10 2016 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 0C29012D5E7 for ; Mon, 27 Jun 2016 07:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 IMEqVIdEKFf9 for ; Mon, 27 Jun 2016 07:44:07 -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 55E4312D616 for ; Mon, 27 Jun 2016 07:41:17 -0700 (PDT) Received: from [10.0.1.4] (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 u5REf4WX052308 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2016 09:41:05 -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.4] From: "Ben Campbell" To: "Colin Perkins" Date: Mon, 27 Jun 2016 09:41:10 -0500 Message-ID: <726233C7-F061-47A8-87E6-C675D8A86364@nostrum.com> In-Reply-To: <8DE85BD4-E69A-4263-BEB7-526DF7E3A7AA@csperkins.org> References: <435E20C6-C715-4656-80D4-1F01554F25F6@nostrum.com> <7594FB04B1934943A5C02806D1A2204B380FB8F2@ESESSMB209.ericsson.se> <6786C847-69AA-4427-8586-17A342FE9051@nostrum.com> <8DE85BD4-E69A-4263-BEB7-526DF7E3A7AA@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-mux-exclusive-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 14:44:09 -0000 On 24 Jun 2016, at 5:21, Colin Perkins wrote: >> On 24 Jun 2016, at 01:32, Ben Campbell wrote: >> >> (+ Magnus and Colin) >> >> The idnits tool will warn about that anytime you update a pre-5378 >> draft, or you update a later draft with the pre-5378 disclaimer. That >> doesn't necessarily mean you need the disclaimer--it's just telling >> you to think about it. >> >> I think this is a borderline case, since there is in fact quoted >> text. As an individual, I agree with Paul that it should count as >> fair use by US standards, but I don't know about other jurisdictions. >> The cleanest option would be to see if the previous authors (copied) >> will agree to letting you use the text without the disclaimer. > > I’m happy for you to use any parts of RFC 5761 I wrote under the new > terms, without the disclaimer. Thanks, Colin! Ben. From nobody Mon Jun 27 08:40:53 2016 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 B7B8C12D813; Mon, 27 Jun 2016 08:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 c6BN6nNJKFoY; Mon, 27 Jun 2016 08:40:46 -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 440C112D5F0; Mon, 27 Jun 2016 08:37:30 -0700 (PDT) Received: from [10.0.1.4] (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 u5RFbPMK058105 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2016 10:37:25 -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.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 27 Jun 2016 10:37:31 -0500 Message-ID: <64B043B7-BF6F-461E-B79C-9190B4BFB2C0@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3810669B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B38100D31@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3810669B@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:40:52 -0000 On 24 Jun 2016, at 2:30, Christer Holmberg wrote: [...] > I see you removed the pre-5378 disclaimer. That might have been > premature, but we can always put it >back before final publication if > we decide we need to. > > > Yes. Given the responses from Magnus and Colin, I think we can progress without the pre-5378 disclaimer. Thanks! Ben. From nobody Mon Jun 27 11:06:25 2016 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 B062612D5A2; Mon, 27 Jun 2016 11:06:23 -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 38_WrHzYiEFn; Mon, 27 Jun 2016 11:06:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E020312D57B; Mon, 27 Jun 2016 11:06:20 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-8e-57716b1ab10d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.53.12926.B1B61775; Mon, 27 Jun 2016 20:06:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Mon, 27 Jun 2016 20:06:18 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] Thread-Index: AdHMststYSnZwTq4QaCIxWBAA2FhlAA7Gm6AABK8ExAAo7YggAAJYyZH Date: Mon, 27 Jun 2016 18:06:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3810EE68@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B38100D31@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3810669B@ESESSMB209.ericsson.se>, <64B043B7-BF6F-461E-B79C-9190B4BFB2C0@nostrum.com> In-Reply-To: <64B043B7-BF6F-461E-B79C-9190B4BFB2C0@nostrum.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3810EE68ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2J7uK50dmG4wdM5/BbzO0+zW1y9JWQx dfljFgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEr48zqjYwFW2UrXqxdxtLA+Emyi5GT Q0LAROLK2cksELaYxIV769m6GLk4hASOMEosu76cCSQhJLCEUeLUo8QuRg4ONgELie5/2iBh EQEliefNW8F6mQVqJQ7ufssK0iss0MEocf3jB0YQR0Sgk1Hi+79nrCDNIgJuEveX2IA0sAio SrzonAHWzCvgK3Ho7zEWiMU/GSXa9nxmBElwCthLLFr4lBnEZgS67vupNUwQ28Qlmr6sZIW4 WkBiyZ7zzBC2qMTLx/9YIWryJb7/b2SFWCAocXLmE5YJjCKzkLTPQlI2C0kZRNxA4sv721C2 tsSyha+ZIWx9ie73p5mQxRcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIywg1t+q+5g vPzG8RCjAAejEg9vQkBBuBBrYllxZe4hRgkOZiUR3t8ZheFCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGCsnHKrNN6qe//3QpCMCWnM8pGZpzf73LmCu +g/L39t+1Sa9WVzLKhx5UeDAt68XI/wPepzsyOb//9Px1aqHh895fF4+ZW1q3rt0ofYL/u8v STUlhs/8ZrXkkHvyX+03jzYtiv91bFJjsrDvKuvDqafLZiiuiTAUiDuf27hga/6H0x960pn5 nr5VYinOSDTUYi4qTgQAeWoraKwCAAA= Archived-At: Cc: "draft-ietf-mmusic-mux-exclusive.all@ietf.org" , mmusic Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:06:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3810EE68ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Excellent! Thanks! :) Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD27/=FD06/=FD2016 18:37 To: Christer Holmberg Cc: draft-ietf-mmusic-mux-exclusive.all@ietf.org; mmusic Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08= [was: AD Evaluation of draft-ietf-mmusic-mux-exclusive-07] On 24 Jun 2016, at 2:30, Christer Holmberg wrote: [...] > I see you removed the pre-5378 disclaimer. That might have been > premature, but we can always put it >back before final publication if > we decide we need to. > > > Yes. Given the responses from Magnus and Colin, I think we can progress without the pre-5378 disclaimer. Thanks! Ben. --_000_7594FB04B1934943A5C02806D1A2204B3810EE68ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Excellent! Th= anks! :)

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =FD27= /=FD06/=FD2016 18:37
To: Christer Holmberg Cc: draft-ietf-mmusi= c-mux-exclusive.all@ietf.org; mmusic
Subject: Re: [= MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-08 [was: AD Eval= uation of draft-ietf-mmusic-mux-exclusive-07]

On 24 Jun 2016, at 2:30, Christer Holmberg wrote:<= br>
[...]

> I see you removed the pre-5378 disclaimer. That might have been
> premature, but we can always put it >back before final publication = if
> we decide we need to.
>
>
> Yes.

Given the responses from Magnus and Colin, I think we can progress
without the pre-5378 disclaimer.

Thanks!

Ben.

 --_000_7594FB04B1934943A5C02806D1A2204B3810EE68ESESSMB209erics_-- From nobody Mon Jun 27 22:50:56 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C5112D0BF; Mon, 27 Jun 2016 22:50:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628055054.5293.35147.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2016 22:50:54 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 05:50:54 -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 : A Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-13.txt Pages : 95 Date : 2016-06-27 Abstract: The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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 Mon Jun 27 22:52:23 2016 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 DC0E912D9BE for ; Mon, 27 Jun 2016 22:52:22 -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 akIObepeJq85 for ; Mon, 27 Jun 2016 22:52:20 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 A941112D0BF for ; Mon, 27 Jun 2016 22:52:20 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id t127so11111536qkf.1 for ; Mon, 27 Jun 2016 22:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5OkSzXa8bf50fkNqqLu48NgKqXhmtTCkOlNttN3CvX4=; b=DqDirZWL6LKG3vsq1RLCqGbPz6m+86Af+tKMqXoF6nEeDABboO0ljBtWknwRqUHaz9 FE3hg+COdykeLFWhW5kcmfjmkMXd7QD/FI7fxV+y2GwmGTjhTG7WkhyBmDOmkyVLaoaG MOPQNJmWgUTbKDRsgSUYjImo2/kmIr954pExXNNJilG1jquR80bWyOHwUNCMH1aCXOgT CeZU9ln++11wd2BzVc2wqaDww0Ouf/xkD0p+HLevU+SxhgCG19PRqY+6i0JwYindUzDX EzHf7dGuRyGdTjKNNu1YdWNQr3eK0ERkL9ZuTff5//OszWbPuQ6PuCX510zjitjXZe6d NOnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5OkSzXa8bf50fkNqqLu48NgKqXhmtTCkOlNttN3CvX4=; b=ZTxZYPUtheTbSQF/LQnqDA7eoNTAJpADnpZoGidt5Sk7f0S9M2WEwzWpuE0godCG30 P5IiEFn9vW4dwLIWVtgDCHROBGn1yKlYJpT4WkJ7DZqwckf50jK/+YH1BaPtH/xN6fjn P48gVBXGtP8/Y9ZtTf0l78l8cS5F1suI5bQ0PfNct69C2lfMY4IVZk5PNgVUo1mib4sW 07NCnPrvfeTzAdwGiC85G4fuDEXd3UEVPmlUQ/w+2LBD4YYMhrnvSkIMdYmE6LhQQqwc 1oZQ6q4Jc1GDch+NEL23rGTxaui7dSoUcprzQvOwpZS00VuJGgtQ4EuBOH73yAseSM/l wDdw== X-Gm-Message-State: ALyK8tIbNu9+/T4XKSpaY0/TAj0lmo7m0wyKs7Zc8Hlzmm3qxAISXvbi2NW8oRkD5iYeGlvToniDQgYfgsVi5A== X-Received: by 10.13.238.69 with SMTP id x66mr407431ywe.15.1467093139183; Mon, 27 Jun 2016 22:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.33.195 with HTTP; Mon, 27 Jun 2016 22:52:18 -0700 (PDT) In-Reply-To: <20160628055054.5293.35147.idtracker@ietfa.amsl.com> References: <20160628055054.5293.35147.idtracker@ietfa.amsl.com> From: Suhas Nandakumar Date: Mon, 27 Jun 2016 22:52:18 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=94eb2c034ffc69e4e20536503d4b Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 05:52:23 -0000 --94eb2c034ffc69e4e20536503d4b Content-Type: text/plain; charset=UTF-8 Hello All This version incorporates AD Evaluation review comments from Ben. Ben, Please let me know if i have addressed all the comments. Thanks Again Suhas On Mon, Jun 27, 2016 at 10:50 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 : A Framework for SDP Attributes when Multiplexing > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-13.txt > Pages : 95 > Date : 2016-06-27 > > Abstract: > The purpose of this specification is to provide a framework for > analyzing the multiplexing characteristics of Session Description > Protocol (SDP) attributes when SDP is used to negotiate the usage of > single 5-tuple for sending and receiving media associated with > multiple media descriptions. > > This specification also categorizes the existing SDP attributes based > on the framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-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 > --94eb2c034ffc69e4e20536503d4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0This version incorporat= es AD Evaluation review comments from Ben.

=C2=A0B= en,
=C2=A0 Please let me know if i have addressed all the comment= s.

Thanks Again
Suhas

On Mon, Jun 27, 2016 at = 10:50 PM, <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 95
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-27

Abstract:
=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of Session Descript= ion
=C2=A0 =C2=A0Protocol (SDP) attributes when SDP is used to negotiate the us= age of
=C2=A0 =C2=A0single 5-tuple for sending and receiving media associated with=
=C2=A0 =C2=A0multiple media descriptions.

=C2=A0 =C2=A0This specification also categorizes the existing SDP attribute= s based
=C2=A0 =C2=A0on the framework described herein.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-mmusic-sdp-mux-attributes-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

--94eb2c034ffc69e4e20536503d4b-- From nobody Tue Jun 28 06:20:10 2016 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 C50EA12B054; Tue, 28 Jun 2016 06:20:08 -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 TrMgxFX-4MnU; Tue, 28 Jun 2016 06:20:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA6112DBF6; Tue, 28 Jun 2016 06:19:48 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-25-577275edbd1e Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EA.22.27088.DE572775; Tue, 28 Jun 2016 15:04:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.294.0; Tue, 28 Jun 2016 15:04:44 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" From: Magnus Westerlund Message-ID: Date: Tue, 28 Jun 2016 15:04:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM2K7nO7b0qJwg/55ghYve1ayWxz4OJXZ 4tuFWoupyx+zWHw638Vo8WHtBTYHNo8lS34yBTBGcdmkpOZklqUW6dslcGXMWPSEreA4V8Wt 3dINjKc5uhg5OSQETCSOtX1gh7DFJC7cW8/WxcjFISRwhFHi2LFGVghnOaPEh197GEEcEYF/ jBIfN95kAWlhE7CQuPmjkQ3EFhZwlTj89jojiM0rYC/RvnILmM0ioCqxfspVsBWiAjESjbcP s0PUCEqcnPkEaA4HBzNQ/YOtZSBhZgF5ieats5lBbCEBbYmGpg7WCYx8s5B0zELomIWkYwEj 8ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwAA8uOW3wQ7Gl88dDzEKcDAq8fA+WFgYLsSa WFZcmXuIUYKDWUmEd2NxUbgQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakF qUUwWSYOTqkGxjXpU/u8j22docrEXHgla4/f1bANt81yhb2iAr4rZbps3Pb4qMmluVEKUtPt Wc64OO+60LN8zfPGiV6Hfh/bVfZdUfDp1+A/fI6Tjf53zpKpnutiuWIeozgz/0/NoNVTI4Me uT1OCGx+GndKWJdhygfH7/NF+R4539xhu96P2+tx37/auXGLViixFGckGmoxFxUnAgCr17fD PAIAAA== Archived-At: Subject: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 13:20:09 -0000 WGs, I as WG chair earlier made a mistake in failing to include the relevant WGs in our previous WG last call. Thus I would like to make a one week confirmation call on the content of draft-ietf-avtcore-rfc5764-mux-fixes-09 prior to publication request. https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ TRAM WG: Please check that you are okay with the restrictions and updates to the TURN channel allocations as well as STUN Method restrictions. TLS WG: I believe you are satisfied with the impact on the TLS IANA registry after previous discussions, but you are welcome to confirm this. ICE: For your information as this impacts protocol mechanism your are dependent on. MMUSIC: For your information due to some notes in regards to BUNDLE and RFC7345. Please provide any feedback by 5th of July. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 28 07:35:29 2016 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 240B912D1A6; Tue, 28 Jun 2016 07:35: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 IC2OEfy-XCii; Tue, 28 Jun 2016 07:35:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E4D12D1B9; Tue, 28 Jun 2016 07:35:08 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-73-57728b1a87e4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.6B.18043.A1B82775; Tue, 28 Jun 2016 16:35:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.294.0; Tue, 28 Jun 2016 16:35:06 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: From: Magnus Westerlund Message-ID: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> Date: Tue, 28 Jun 2016 16:35:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2K7oq5Ud1G4waPthhYve1ayWxz4OJXZ 4tuFWoupyx+zWHw638Vo8WHtBTYHNo8lS34yBTBGcdmkpOZklqUW6dslcGVsWbuTveCdRMWK td2MDYwPhLsYOTkkBEwkPszYzgphi0lcuLeeDcQWEjjCKPFpXX0XIxeQvZxR4s3VtcxdjBwc wgIhEsf3J4HERQT+MUp83HiTBaLBXuLXzkZmEJtNwELi5o9GsEG8QPETb74zgvSyCKhK3Pge CxIWFYiRaLx9mB2iRFDi5MwnYGM4BRwkjv/cwAJSzgzU+mBrGUiYWUBeonnrbGaITdoSDU0d rBMYBWYh6Z6F0DELSccCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHBenDLb6sdjAef Ox5iFOBgVOLhfbCwMFyINbGsuDL3EKMEB7OSCK9nV1G4EG9KYmVValF+fFFpTmrxIUZpDhYl cV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsYIVu65q/fbrOl8Y5aWzliVlNs27diE1suTYqw5 n0zP+im5f/U6tSjjCPZzWrNSDLYF9R32nda0ojqsYNvfCbN5VxQd31Gqlm7WYG948ZHo2Udz X4gcVwpbn+A7u+Lk829sTheLGT7ZRgTn6qUxfVrtEsq9um6Ly13Vd49EpxtmOXi5HGqY7q/E UpyRaKjFXFScCADk8d++UgIAAA== Archived-At: Subject: Re: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 14:35:12 -0000 Authors and WGs, In my review for the publication writeup I did spot some issues in the draft. Please consider the following issues: 1. Abstract: With the addition of the ZRTP the abstract should benefit from being updated. The ZRTP protocol being possible to multiplex is missing as well as that there are now 4 issues. 2. Abstract contains [ref] to RFC 5764. This is an ID nit. 3. Section 1. The introduction is not explicitly saying that it updates RFC 5764. I think that can be put as a sentence after: This is achieved by modifying the IANA registries with instructions for coordination between the protocols at risk. 4. Reference ID-nits: == Outdated reference: A later version (-31) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 5. Section 2: ID-nits complains about the modified boilerplate for the RFC2119 text. First of all one usually don't cut down the list to only the used ones. The requirement on all caps ones I am very divided about. I do have a preference for unmodified boilerplate, this as I otherwise have to explain in the write-up the ID-nit. 6. Section 6: In order to prevent future documents from assigning values from the unused range to a new protocol, this document modifies the RFC 5764 demultiplexing algorithm to properly account for TURN channels by allocating the values from 64 to 79 for this purpose. I think this text fails to be explicit about that this restricts the TURN Channel space to a more limited set of possible channels when the TURN client does the channel binding request. Thus affecting the TURN channel allocation algorithm in the client implementations, at least when used in combination of muxing. Based on this and the fact that this specification changes the IANA registrations performed by RFC5766, I think this document to have "Updates" for RFC5766 also. So please add that in header, abstract and introduction. 7. Updates RFC5389: Looking at the impact also on the STUN protocol I would also think that this requires and "Updates" also for RFC 5389. 8. Section 10.3: The IANA registry name is not the correct one. The IANA page says that the registry name is: Traversal Using Relays around NAT (TURN) Channel Numbers http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#turn-channel Please update. 9. Section 12.2: The reference to ZRTP [RFC6189] is likely in the wrong category, at the same time moving this to a normative one creates a downref. I guess it one that has to be accepted in this case. I suggest that you move it to the normative references. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 28 18:30:19 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C5612D911; Tue, 28 Jun 2016 18:30:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160629013014.22557.70190.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 18:30:14 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 01:30:15 -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 Simulcast in SDP and RTP Sessions Authors : Bo Burman Magnus Westerlund Suhas Nandakumar Mo Zanaty Filename : draft-ietf-mmusic-sdp-simulcast-05.txt Pages : 29 Date : 2016-06-28 Abstract: In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 28 18:36:15 2016 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 6852912D9C3 for ; Tue, 28 Jun 2016 18:36:13 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUgJ4rFcaqgS for ; Tue, 28 Jun 2016 18:36:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D6012D9C0 for ; Tue, 28 Jun 2016 18:36:10 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-ca-577326094620 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.13.12516.90623775; Wed, 29 Jun 2016 03:36:09 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 29 Jun 2016 03:36:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+/Akn0H+dAo4Z+Vw/8JlSKjUnkH9kQZceO7kqMCZcHs=; b=Z6QEjOfpc6/bJy6f69hgVDd4RRclEivQpItPULy+3OwhEyuPdP7Xs+sPSPwqlF6OPTUl1pfBujSDvDg0yIjQe4RjtImZDFPvaFq1InACjTfoELje8VM4GBc4GGb7vsYonLGE+y1qceOlXliNhf1S3K4TKL/UDnSJTaM3pxQ+6IM= Received: from AM3PR07MB1188.eurprd07.prod.outlook.com (10.163.188.26) by AM3PR07MB1187.eurprd07.prod.outlook.com (10.163.188.25) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 01:36:07 +0000 Received: from AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::85ce:ace0:567e:1d95]) by AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::85ce:ace0:567e:1d95%14]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 01:36:07 +0000 From: Bo Burman To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-simulcast-05.txt Thread-Index: AQHR0aXRho1A6j5zZ0+3c6PpcV/Jq5//qJrg Date: Wed, 29 Jun 2016 01:36:07 +0000 Message-ID: References: <20160629013014.22557.70190.idtracker@ietfa.amsl.com> In-Reply-To: <20160629013014.22557.70190.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [83.209.196.174] x-ms-office365-filtering-correlation-id: 12fe8974-d089-4f9a-d46d-08d39fbdbe49 x-microsoft-exchange-diagnostics: 1; AM3PR07MB1187; 6:53oxneFhBhwsxYkr3jAM3Kh1Y4ucaQiWGgj6Fli+ImL0X76+AwwfeJGwlO3QNKna2FQtHLgcJnvIf0EziJZiktrkM8MDi/4cjn84Vw4MvOcVbcuEJkwHtRLifSLQHXOf1RlYlyhyUAuQ6Ah/7cdvN/8KFBUkBNSe8ro9HnOl43xSed8kTLgyy//a9i4LELa5/768XaJgm////ESndkb1eFYA9SpeoetZhMHVl6NUpSkKUK6+DMoBLjIENwPnyE1Hvn6Mwap8r48NXJV6s6vFbcJC+yAVTT+ZIfk48ptf3m4=; 5:AAs8WysqMw2dP0gEa2ok5m+etbqeB0jninMaW7tMIfKaH7MEwvvFPi9E30fkgkd0T+SKZAvuTLrUYrlIPnBljrBVI8zmbKcmX1DiHiV3QwcZFzmS30OL6hPh00bnlKgpxi45mnqCk5+BXUmEuqiCIw==; 24:2HgslFG04JO/n+QU3GHuifgFCD0obHyhLgnnePeVkkDLsuIxIK1V3PzeHgGMcpt0FL2noRajQM9Eft9nUIjeN1wVa6wheZiPVoUHp45bBxA=; 7:tazZMxhRpS/2WmR3vIa+S7BmRXLa44uwaSDgOYoZzizcXNTEH0W99JitwE8AkvirKyfxfCa+428xzQCD8S+DYlsXlTDBeaAjPMqO54DtHj4vzZSWqyoZXRXTsATHY6DJLJKUEOdq/2ZUJ7+VJwlffhCn322TGdUckVH3VNmWK+2t/Q9Hdlo82aFLRvOTEhSfPph9X7g8lrwftD6VVgYhJBbevdruyEFwPQjtK27D2whIaUIy2r7rGHUko+aULSCJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB1187; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR07MB1187; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1187; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(13464003)(377424004)(189002)(76176999)(50986999)(450100001)(8936002)(54356999)(86362001)(105586002)(586003)(19580405001)(102836003)(87936001)(6116002)(9686002)(101416001)(106356001)(106116001)(230783001)(19580395003)(2351001)(3846002)(8676002)(305945005)(3660700001)(5002640100001)(7846002)(3280700002)(7736002)(66066001)(5003600100003)(7696003)(5640700001)(33656002)(68736007)(2900100001)(2950100001)(5250100002)(81156014)(1730700003)(189998001)(97736004)(76576001)(107886002)(2906002)(81166006)(110136002)(15975445007)(74316001)(2501003)(92566002)(11100500001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1187; H:AM3PR07MB1188.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 01:36:07.7475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1187 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUyM2K7ui6nWnG4wdoJIhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtNCuYIJ0hWfd+1gb2D8K9LFyMkhIWAicfldNwuELSZx4d56 ti5GLg4hgSOMEv8XL2SFcE4wSqw6sowRpIpFoJdZ4sQVF4jENUaJ5X962SGcx4wS70+eZwKp YhPQkJi/4y5Yh4iAusTXvT3MILawgL3E62snoOIOEo8PX2GHsI0k+j8uYILYoCrR9ukuWD2v QIxEQ+MHsLiQgKPElj1TwW7lFHCSaDn8E2wOI9Dd30+tAathFhCXuPVkPhPEPwISS/acZ4aw RSVePv7HClEfKTF54lmgvRxAcSWJ9iYfiBJfiSk/njCB/CIh8I5NovPqI3aIhJvEs3WfoWZm S0xe1Q4NL2uJE4tvQtnrGSUONlpB2DISN6afYIMY1M4mMf/gBjaIB1Illq9tZYQEhJTE3Sud jBMYtWYhuRvC1pFYsPsTG4StLbFs4WvmWeCwEJQ4OfMJywJGllWMosWpxcW56UbGeqlFmcnF xfl5enmpJZsYgQni4JbfujsYV792PMQowMGoxMOb8LkoXIg1say4MvcQowQHs5II73zl4nAh 3pTEyqrUovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjD1fs6tTIsV0 A3iEzkbadB5evfPWxLc+l8MvPr2ydqXa/N+uzFs1n3uXxe2fGlaZt0jXLrlBcr5HyqKg1i+T WlLq+5K1kvedqH06/98Zvb4gvXkPxU8s25D8tiNvYpO9aBzDwny7N3fUOBYta33tnuuv2nBP yX1e+qdz7jOqPq0puur/PZT7ghJLcUaioRZzUXEiAJGspQgMAwAA Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 01:36:13 -0000 Hi, This version contains the following changes: o Aligned with recent changes in draft-ietf-mmusic-rid and draft- ietf-avtext-rid. o Modified the SDP offer/answer section to follow the generally accepted structure, also adding a brief text on modifying the session that is aligned with draft-ietf-mmusic-rid. o Improved text around simulcast stream identification (as opposed to the simulcast stream itself) to consistently use the acronym SCID and defined that in the Terminology section. o Changed references for RTP-level pause/resume and VP8 payload format that are now published as RFC. o Improved IANA registration text. o Removed unused reference to draft-ietf-payload-flexible-fec- scheme. o Editorial improvements and corrections. I don't think there are any other changes needed at the moment and believe = the draft is ready for WGLC. Cheers, Bo (as individual) > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 29 juni 2016 03:30 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: I-D Action: draft-ietf-mmusic-sdp-simulcast-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control of= the IETF. >=20 > Title : Using Simulcast in SDP and RTP Sessions > Authors : Bo Burman > Magnus Westerlund > Suhas Nandakumar > Mo Zanaty > Filename : draft-ietf-mmusic-sdp-simulcast-05.txt > Pages : 29 > Date : 2016-06-28 >=20 > Abstract: > In some application scenarios it may be desirable to send multiple > differently encoded versions of the same media source in different > RTP streams. This is called simulcast. This document describes how > to accomplish simulcast in RTP and how to signal it in SDP. The > described solution uses an RTP/RTCP identification method to identify > RTP streams belonging to the same media source, and makes an > extension to SDP to relate those RTP streams as being different > simulcast formats of that media source. The SDP extension consists > of a new media level SDP attribute that expresses capability to send > and/or receive simulcast RTP streams. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-simulcast-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt