From nobody Tue Oct 1 12:15:16 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D8F12003E for ; Tue, 1 Oct 2019 12:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 xu49muS2ZyyG for ; Tue, 1 Oct 2019 12:15:12 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43CE120018 for ; Tue, 1 Oct 2019 12:15:12 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x91JFAtF024215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 1 Oct 2019 15:15:11 -0400 References: To: "rum@ietf.org" From: Paul Kyzivat X-Forwarded-Message-Id: Message-ID: Date: Tue, 1 Oct 2019 15:15:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rum] Distinguishing RUE and Provider requirements X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 19:15:15 -0000 In the discussion thread that followed the attached message it started to become apparent that there is a need to distinguish the requirements, and/or requirement strength, that apply to the RUE itself from those that apply when a RUE connects to a VRS Provider. Now that we have a wg draft to work from, I would like to see people step forward and make proposal(s) for what those differences should be. While the prior discussion focused on codecs, please also consider what else might need to differ. Thanks, Paul -------- Forwarded Message -------- Subject: [Rum] Codec requirements in draft-rosen-rue-01 Resent-From: pkyzivat@alum.mit.edu Date: Mon, 12 Aug 2019 16:20:51 -0400 From: Paul Kyzivat To: rum@ietf.org draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742. RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these. Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably: "WebRTC-compatible endpoints" are free to implement any video codecs they see fit. This follows logically from the definition of "WebRTC- compatible endpoint". It is, of course, advisable to implement at least one of the video codecs that is mandated for WebRTC browsers, and implementors are encouraged to do so. Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video. I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications. Thanks, Paul -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Tue Oct 1 13:14:13 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4DE120059 for ; Tue, 1 Oct 2019 13:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 dR8nQbL5_lao for ; Tue, 1 Oct 2019 13:14:08 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CF212001E for ; Tue, 1 Oct 2019 13:14:07 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x91KE5PK028065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 1 Oct 2019 16:14:06 -0400 To: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> From: Paul Kyzivat Message-ID: <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> Date: Tue, 1 Oct 2019 16:14:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 20:14:11 -0000 I would like to revive the point raised in the attached message that had no followup discussion. The problem with calling for mandatory media security on the RUE is that current VRS calls use insecure media. The VRS Provider Profile currently does not specify the RUE interface. It is the responsibility of the provider to interface (using SDP rewriting or media bridging) the calling RUE to either the terminating RUE or the other provider where the terminating RUE is connected. But it would be inappropriate (deceptive) to interface secure media to insecure media. There are plans to upgrade media security over the VRS Provider Profile. The following is a likely path forward, though steps 3-5 are speculation on my part: 1) The current VRS Provider Profile (v1) specifies insecure media. That is what is currently deployed by VRS providers. 2) There is a revised VRS Provider Profile (v2) in development. It hopefully will be approved by the end of this year. It calls for opportunistic media security [RFC8643] between providers. The reason is to allow gradual migration of providers to the revised profile. 3) Based on past history it may well take a year or more to accomplish a complete migration of all providers to the new profile. At that time all calls will be using secure media. 4) Once that migration is complete it will be possible to make a further revision to the profile (v3) that mandates offering unprovisional media security while still allowing the acceptance of offers of provisional media security. Again this is to allow a phase-in period. 5) Once that is complete, a v4 of the profile could then mandate unprovisional media security. If the new RUE spec isn't introduced until step (5) then media security can be achieved without any bridging or SDP rewriting. But that will likely be multiple years in the future. To incorporate the new RUE spec earlier some compromises will be required. It would be easy to change the RUE spec to use opportunistic media security. This would still result in secure media if all entities on the signaling path support it. It that won't be assured until step (3). Getting this to work with a WebRTC-based RUE (that requires secure media) will require at least SDP rewriting. Thoughts? Thanks, Paul On 9/5/19 4:31 PM, Paul Kyzivat wrote: > On 9/4/19 10:37 AM, Brian Rosen wrote: >> Yes, for sure T.140 (RFC4103). >> The providers have SBCs that anchor media, so they can handle security >> on one side but not the other.  That’s not a great answer, but it’s an >> answer.  Transcoding video is not reasonable. > > The soon to be released updated version of the Provider Profile > specifies opportunistic media security [RFC8643]. > > Also, while providers use SBCs, some of them can set up e2e media for > point to point calls, where the media won't be anchored and security > can't be twiddled. > > I think this can be a problem if RUM requires the RUE to signal > mandatory media security, which (I think) WebRTC requires. > >     Thanks, >     Paul > >> Brian >> >>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström >>> > >>> wrote: >>> >>> >>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen: >>>> I think our consensus is MTI: >>>> Audio: G.711 and Opus >>>> Video: H.264 >>> >>>  Real-time text: T.140        (I think you said it is mandatory for >>> clients, and optional for services.) >>> >>> >>> All these need then transport and security details specified to >>> assure interop with RUM. >>> >>> How can you hope for backward compatibility with legacy devices when >>> it is said in RUM that the security requirements must be met? >>> >>> Regards >>> >>> Gunnar >>> >>>> >>>> We need to get into the details of H.264 to maintain compatibility >>>> with the WebRTC specs and as much backwards compatibility as possible. >>>> >>>> Anyone object? >>>> >>>> >>>> >>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat >>>> > wrote: >>>>> >>>>> On 9/2/19 4:39 AM, James Hamlin wrote: >>>>>> Just to add: the VRS industry supports a variety of endpoints, >>>>>> many of which are hardware based and not built by VRS providers >>>>>> themselves. H.264 and G..711 therefore need to be in the MTI list. >>>>>> I believe the FCC order related to compensation by compliant >>>>>> providers not that every call had to come from a compliant endpoint. >>>>> Sorry if I got that wrong. I wrote that from memory and perhaps my >>>>> memory is faulty. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Best Regards >>>>>> James >>>>>> ________________________________________ >>>>>> From: Rum > on >>>>>> behalf of Paul Kyzivat > >>>>>> Sent: 28 August 2019 16:48 >>>>>> To: rum@ietf.org >>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >>>>>> On 8/28/19 11:25 AM, Eric Burger wrote: >>>>>>> I guess the question is whether we want today’s devices to have a >>>>>>> chance of being RUM compatible. I don’t think anyone will be >>>>>>> surprised if a five-year-old device is history. Is it realistic >>>>>>> for current devices to get VP8 upgrade? [Would be nice for some >>>>>>> manufacturers or others building such devices to pipe in here.] >>>>>> Lets be clear about what we mean by "RUM compatible". >>>>>> When Henning and I were working on this with the providers in 2014 >>>>>> and >>>>>> 2015 there was an expectation that the providers would be required to >>>>>> support the defined RUE devices, but they would also be permitted to >>>>>> support their existing proprietary devices. The RUE devices could >>>>>> have >>>>>> requirements that their existing devices don't meet. But calls >>>>>> between >>>>>> the two were expected to work. >>>>>> There was great consternation when subsequently the FCC issued a >>>>>> proposed order that said only VRS calls involving RUE-compatible >>>>>> devices >>>>>> would be compensated. (But that was in 2015. I presume it has not >>>>>> happened.) >>>>>> If there is an intent to exclude non-RUM-compliant devices from >>>>>> use in >>>>>> VRS calls then there needs to be a migration plan to get from here >>>>>> to there. >>>>>>         Thanks, >>>>>>         Paul >>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen >>>>>>> > wrote: >>>>>>>> >>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 >>>>>>>> and VP8 as MTI, then we get backwards compatibility without >>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t that >>>>>>>> what we want? >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Inline... >>>>>>>>> >>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>>>>> I certainly have thoughts. The executive summary is that I >>>>>>>>>> personally believe RUM should specify Opus as the one audio >>>>>>>>>> codec MTI, and match RFC 7742's "Non-Browser" requirements for >>>>>>>>>> the video codec MTI. Rationale below. >>>>>>>>>>  From an interop perspective, the important thing is that any >>>>>>>>>> given profile has (at least) one MTI video codec and (at >>>>>>>>>> least) one MTI audio codec.. I know there is a strong desire >>>>>>>>>> -- one that I share -- that these endpoints can talk to/be >>>>>>>>>> implemented in web browsers without the need for media >>>>>>>>>> transcoding. >>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the >>>>>>>>>> former because it works without transcoding to landline PSTN >>>>>>>>>> destinations, and the latter because it sounds much, much >>>>>>>>>> better. RUM could make the same decision; or it could decide >>>>>>>>>> to move away from a codec that is as old as I am and opt to >>>>>>>>>> designate Opus as the only MTI. Given that RUM inherently >>>>>>>>>> needs to deploy into audio/video environments, backwards >>>>>>>>>> compatibility with the PSTN seems to be unnecessary baggage. >>>>>>>>> Please keep in mind where we are coming from. The RUM will be a >>>>>>>>> new interface to the *existing* VRS infrastructure. That >>>>>>>>> infrastructure currently has proprietary devices that serve the >>>>>>>>> RUE function, deployed to VRS users and to Communications >>>>>>>>> Assistants (CAs, Interpreters). These have G.711 MTI, and also >>>>>>>>> *recommend* G.722.2. >>>>>>>>> >>>>>>>>> Making OPUS the only MTI audio codec would be problematic. >>>>>>>>> >>>>>>>>>> For video: While specifying either VP8 or H.264 would be >>>>>>>>>> sufficient for system interop, and for interop with compliant >>>>>>>>>> WebRTC endpoints, I'd really prefer not to re-live the WebRTC >>>>>>>>>> video codec wars. Concretely, what I would propose is that RUM >>>>>>>>>> indicate that the video codec requirements are defined to be >>>>>>>>>> identical to those defined for "WebRTC Non-Browsers" in >>>>>>>>>> Section 5 of RFC 7742. It should be made clear that RUM >>>>>>>>>> endpoints *are* *not* WebRTC Non-Browsers per se; merely that >>>>>>>>>> they comply with the same video codec requirements as WebRTC >>>>>>>>>> Non-Browsers. >>>>>>>>> Continuing my comment above, existing devices have H.264 >>>>>>>>> Constrained Baseline Profile, Level 1.3, packetization mode 1 >>>>>>>>> as the MTI codec. Odds are many of these devices aren't capable >>>>>>>>> of VP8. >>>>>>>>> >>>>>>>>> We can't realistically require a wholesale swap out of existing >>>>>>>>> devices before the RUE defined by RUM can work. We can >>>>>>>>> *discuss* whether forcing the providers to transcode is a >>>>>>>>> practical way forward. I'm dubious. >>>>>>>>> >>>>>>>>>     Thanks, >>>>>>>>>     Paul >>>>>>>>> >>>>>>>>>> /a >>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>>>>>>>> Well, we certainly want interoperability, and I think we can >>>>>>>>>>> only get that with MTI codecs. >>>>>>>>>>> >>>>>>>>>>> I think we really are talking about a WebRTC-compatible >>>>>>>>>>> endpoint, but we want interoperability with a WebRTC browser >>>>>>>>>>> endpoint. >>>>>>>>>>> >>>>>>>>>>> Not sure how to say this.  Maybe Adam can help. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. It >>>>>>>>>>>> now simply references webrtc RFC7742. >>>>>>>>>>>> >>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC >>>>>>>>>>>> browser", "WebRTC non-browser", and "WebRTC-compatible >>>>>>>>>>>> endpoint". AFAIK it assumes that each end is one of these. >>>>>>>>>>>> >>>>>>>>>>>> Is the expectation here that both the RUE and the provider >>>>>>>>>>>> comply with one of these? In particular, that the provider >>>>>>>>>>>> may simply be a "WebRTC-compatible endpoint? Notably: >>>>>>>>>>>> >>>>>>>>>>>>    "WebRTC-compatible endpoints" are free to implement any >>>>>>>>>>>> video codecs >>>>>>>>>>>>    they see fit.  This follows logically from the definition >>>>>>>>>>>> of "WebRTC- >>>>>>>>>>>>    compatible endpoint".  It is, of course, advisable to >>>>>>>>>>>> implement at >>>>>>>>>>>>    least one of the video codecs that is mandated for WebRTC >>>>>>>>>>>> browsers, >>>>>>>>>>>>    and implementors are encouraged to do so. >>>>>>>>>>>> >>>>>>>>>>>> Similarly, the audio requirements have been changed to >>>>>>>>>>>> reference webrtc RFC7874. That one doesn't have the >>>>>>>>>>>> distinction between "WebRTC browser", "WebRTC non-browser", >>>>>>>>>>>> and "WebRTC-compatible endpoint". It applies the same >>>>>>>>>>>> requirements to all. In particular, it requires OPUS >>>>>>>>>>>> support. I don't know why it doesn't make the same endpoint >>>>>>>>>>>> distinctions as for video. >>>>>>>>>>>> >>>>>>>>>>>> I think simply referencing these documents isn't sufficient. >>>>>>>>>>>> Seems like we need a more nuanced specification of what is >>>>>>>>>>>> required, though we may still reference these docs with >>>>>>>>>>>> qualifications. >>>>>>>>>>>> >>>>>>>>>>>>     Thanks, >>>>>>>>>>>>     Paul >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> -- >>>>>>>> Rum mailing list >>>>>>>> Rum@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rum >>>>>>> >>>>>> -- >>>>>> Rum mailing list >>>>>> Rum@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rum >>>>> -- >>>>> Rum mailing list >>>>> Rum@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rum >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >> > From nobody Tue Oct 1 13:20:04 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254E3120824 for ; Tue, 1 Oct 2019 13:19:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 YCw_XHQHLCPv for ; Tue, 1 Oct 2019 13:19:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 74C4412082E for ; Tue, 1 Oct 2019 13:19:45 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id x91KGBKM037775; Tue, 1 Oct 2019 16:19:41 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2vcd3v95ew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Oct 2019 16:19:40 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x91KJdYY006449; Tue, 1 Oct 2019 16:19:40 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x91KJYiE006256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Oct 2019 16:19:35 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id D695C400B577; Tue, 1 Oct 2019 20:19:34 +0000 (GMT) Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (unknown [130.9.129.146]) by zlp27130.vci.att.com (Service) with ESMTPS id B1573400B575; Tue, 1 Oct 2019 20:19:34 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.213]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0468.000; Tue, 1 Oct 2019 16:19:34 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat CC: "rum@ietf.org" Thread-Topic: [Rum] Media security Thread-Index: AQHVeJTTLeR0fhZF0EKk1KwKUDVVbqdGOelW Date: Tue, 1 Oct 2019 20:19:33 +0000 Message-ID: <86E626A9-C13D-4106-B423-98223BF26D84@att.com> References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu>, <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> In-Reply-To: <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_86E626A9C13D4106B42398223BF26D84attcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-01_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910010166 Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 20:19:59 -0000 --_000_86E626A9C13D4106B42398223BF26D84attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agree w Paul Martin C. Dolly Lead Member of Technical Staff Government & Services Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 1, 2019, at 4:14 PM, Paul Kyzivat > wrote: I would like to revive the point raised in the attached message that had no= followup discussion. The problem with calling for mandatory media security on the RUE is that cu= rrent VRS calls use insecure media. The VRS Provider Profile currently does= not specify the RUE interface. It is the responsibility of the provider to= interface (using SDP rewriting or media bridging) the calling RUE to eithe= r the terminating RUE or the other provider where the terminating RUE is co= nnected. But it would be inappropriate (deceptive) to interface secure medi= a to insecure media. There are plans to upgrade media security over the VRS Provider Profile. Th= e following is a likely path forward, though steps 3-5 are speculation on m= y part: 1) The current VRS Provider Profile (v1) specifies insecure media. That is = what is currently deployed by VRS providers. 2) There is a revised VRS Provider Profile (v2) in development. It hopefull= y will be approved by the end of this year. It calls for opportunistic medi= a security [RFC8643] between providers. The reason is to allow gradual migr= ation of providers to the revised profile. 3) Based on past history it may well take a year or more to accomplish a co= mplete migration of all providers to the new profile. At that time all call= s will be using secure media. 4) Once that migration is complete it will be possible to make a further re= vision to the profile (v3) that mandates offering unprovisional media secur= ity while still allowing the acceptance of offers of provisional media secu= rity. Again this is to allow a phase-in period. 5) Once that is complete, a v4 of the profile could then mandate unprovisio= nal media security. If the new RUE spec isn't introduced until step (5) then media security can= be achieved without any bridging or SDP rewriting. But that will likely be= multiple years in the future. To incorporate the new RUE spec earlier some compromises will be required. It would be easy to change the RUE spec to use opportunistic media security= . This would still result in secure media if all entities on the signaling = path support it. It that won't be assured until step (3). Getting this to w= ork with a WebRTC-based RUE (that requires secure media) will require at le= ast SDP rewriting. Thoughts? Thanks, Paul On 9/5/19 4:31 PM, Paul Kyzivat wrote: On 9/4/19 10:37 AM, Brian Rosen wrote: Yes, for sure T.140 (RFC4103). The providers have SBCs that anchor media, so they can handle security on o= ne side but not the other. That=92s not a great answer, but it=92s an answ= er. Transcoding video is not reasonable. The soon to be released updated version of the Provider Profile specifies o= pportunistic media security [RFC8643]. Also, while providers use SBCs, some of them can set up e2e media for point= to point calls, where the media won't be anchored and security can't be tw= iddled. I think this can be a problem if RUM requires the RUE to signal mandatory m= edia security, which (I think) WebRTC requires. Thanks, Paul Brian On Sep 4, 2019, at 10:35 AM, Gunnar Hellstr=F6m >= wrote: Den 2019-09-04 kl. 15:54, skrev Brian Rosen: I think our consensus is MTI: Audio: G.711 and Opus Video: H.264 Real-time text: T.140 (I think you said it is mandatory for clients= , and optional for services.) All these need then transport and security details specified to assure inte= rop with RUM. How can you hope for backward compatibility with legacy devices when it is = said in RUM that the security requirements must be met? Regards Gunnar We need to get into the details of H.264 to maintain compatibility with the= WebRTC specs and as much backwards compatibility as possible. Anyone object? On Sep 3, 2019, at 10:48 AM, Paul Kyzivat > wrote: On 9/2/19 4:39 AM, James Hamlin wrote: Just to add: the VRS industry supports a variety of endpoints, many of whic= h are hardware based and not built by VRS providers themselves. H.264 and G= ..711 therefore need to be in the MTI list. I believe the FCC order related to compensation by compliant providers not = that every call had to come from a compliant endpoint. Sorry if I got that wrong. I wrote that from memory and perhaps my memory i= s faulty. Thanks, Paul Best Regards James ________________________________________ From: Rum > on behalf of Paul Kyzivat > Sent: 28 August 2019 16:48 To: rum@ietf.org Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 On 8/28/19 11:25 AM, Eric Burger wrote: I guess the question is whether we want today=92s devices to have a chance = of being RUM compatible. I don=92t think anyone will be surprised if a five= -year-old device is history. Is it realistic for current devices to get VP8= upgrade? [Would be nice for some manufacturers or others building such dev= ices to pipe in here.] Lets be clear about what we mean by "RUM compatible". When Henning and I were working on this with the providers in 2014 and 2015 there was an expectation that the providers would be required to support the defined RUE devices, but they would also be permitted to support their existing proprietary devices. The RUE devices could have requirements that their existing devices don't meet. But calls between the two were expected to work. There was great consternation when subsequently the FCC issued a proposed order that said only VRS calls involving RUE-compatible devices would be compensated. (But that was in 2015. I presume it has not happened.= ) If there is an intent to exclude non-RUM-compliant devices from use in VRS calls then there needs to be a migration plan to get from here to there= . Thanks, Paul On Aug 28, 2019, at 10:38 AM, Brian Rosen > wrote: If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MT= I, then we get backwards compatibility without transcoding and forwards com= patibility with WebRTC. Isn=92t that what we want? Brian On Aug 28, 2019, at 10:15 AM, Paul Kyzivat > wrote: Inline... On 8/27/19 5:57 PM, Adam Roach wrote: I certainly have thoughts. The executive summary is that I personally belie= ve RUM should specify Opus as the one audio codec MTI, and match RFC 7742's= "Non-Browser" requirements for the video codec MTI. Rationale below. From an interop perspective, the important thing is that any given profile= has (at least) one MTI video codec and (at least) one MTI audio codec.. I = know there is a strong desire -- one that I share -- that these endpoints c= an talk to/be implemented in web browsers without the need for media transc= oding. For audio: WebRTC selected G.711 and Opus as both MTI; the former because i= t works without transcoding to landline PSTN destinations, and the latter b= ecause it sounds much, much better. RUM could make the same decision; or it= could decide to move away from a codec that is as old as I am and opt to d= esignate Opus as the only MTI. Given that RUM inherently needs to deploy in= to audio/video environments, backwards compatibility with the PSTN seems to= be unnecessary baggage. Please keep in mind where we are coming from. The RUM will be a new interfa= ce to the *existing* VRS infrastructure. That infrastructure currently has = proprietary devices that serve the RUE function, deployed to VRS users and = to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and= also *recommend* G.722.2. Making OPUS the only MTI audio codec would be problematic. For video: While specifying either VP8 or H.264 would be sufficient for sys= tem interop, and for interop with compliant WebRTC endpoints, I'd really pr= efer not to re-live the WebRTC video codec wars. Concretely, what I would p= ropose is that RUM indicate that the video codec requirements are defined t= o be identical to those defined for "WebRTC Non-Browsers" in Section 5 of R= FC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-= Browsers per se; merely that they comply with the same video codec requirem= ents as WebRTC Non-Browsers. Continuing my comment above, existing devices have H.264 Constrained Baseli= ne Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many= of these devices aren't capable of VP8. We can't realistically require a wholesale swap out of existing devices bef= ore the RUE defined by RUM can work. We can *discuss* whether forcing the p= roviders to transcode is a practical way forward. I'm dubious. Thanks, Paul /a On 8/27/19 2:34 PM, Brian Rosen wrote: Well, we certainly want interoperability, and I think we can only get that = with MTI codecs. I think we really are talking about a WebRTC-compatible endpoint, but we wa= nt interoperability with a WebRTC browser endpoint. Not sure how to say this. Maybe Adam can help. Brian On Aug 12, 2019, at 4:20 PM, Paul Kyzivat > wrote: draft-rosen-rue-01 changes the video codec requirements. It now simply refe= rences webrtc RFC7742. RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC n= on-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each e= nd is one of these. Is the expectation here that both the RUE and the provider comply with one = of these? In particular, that the provider may simply be a "WebRTC-compatib= le endpoint? Notably: "WebRTC-compatible endpoints" are free to implement any video codecs they see fit. This follows logically from the definition of "WebRTC- compatible endpoint". It is, of course, advisable to implement at least one of the video codecs that is mandated for WebRTC browsers, and implementors are encouraged to do so. Similarly, the audio requirements have been changed to reference webrtc RFC= 7874. That one doesn't have the distinction between "WebRTC browser", "WebR= TC non-browser", and "WebRTC-compatible endpoint". It applies the same requ= irements to all. In particular, it requires OPUS support. I don't know why = it doesn't make the same endpoint distinctions as for video. I think simply referencing these documents isn't sufficient. Seems like we = need a more nuanced specification of what is required, though we may still = reference these docs with qualifications. Thanks, Paul -- Rum mailing list Rum@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0= r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_vivuof= aYnOnkS2XR-MaoASurKoOoLc&e=3D -- Rum mailing list Rum@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0= r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_vivuof= aYnOnkS2XR-MaoASurKoOoLc&e=3D -- Rum mailing list Rum@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0= r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_vivuof= aYnOnkS2XR-MaoASurKoOoLc&e=3D -- ----------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 -- Rum mailing list Rum@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0= r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_vivuof= aYnOnkS2XR-MaoASurKoOoLc&e=3D --_000_86E626A9C13D4106B42398223BF26D84attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agree w Paul

Martin C. Dolly

Lead Member of Technical Staff

Government & Services Standar= ds

AT&T

Cell: +1.609.903= .3360

Email: md3135@att.com


On Oct 1, 2019, at 4:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I would like to revive the point raised in the attac= hed message that had no followup discussion.

The problem with calling for mandatory media security on the RUE is t= hat current VRS calls use insecure media. The VRS Provider Profile currentl= y does not specify the RUE interface. It is the responsibility of the provi= der to interface (using SDP rewriting or media bridging) the calling RUE to either the terminating RUE or the ot= her provider where the terminating RUE is connected. But it would be inappr= opriate (deceptive) to interface secure media to insecure media.

There are plans to upgrade media security over the VRS Provider Profi= le. The following is a likely path forward, though steps 3-5 are speculatio= n on my part:

1) The current VRS Provider Profile (v1) specifies insecure media. Th= at is what is currently deployed by VRS providers.

2) There is a revised VRS Provider Profile (v2) in development. It ho= pefully will be approved by the end of this year. It calls for opportunisti= c media security [RFC8643] between providers. The reason is to allow gradua= l migration of providers to the revised profile.

3) Based on past history it may well take a year or more to accomplis= h a complete migration of all providers to the new profile. At that time al= l calls will be using secure media.

4) Once that migration is complete it will be possible to make a furt= her revision to the profile (v3) that mandates offering unprovisional media= security while still allowing the acceptance of offers of provisional medi= a security. Again this is to allow a phase-in period.

5) Once that is complete, a v4 of the profile could then mandate unpr= ovisional media security.

If the new RUE spec isn't introduced until step (5) then media securi= ty can be achieved without any bridging or SDP rewriting. But that will lik= ely be multiple years in the future.

To incorporate the new RUE spec earlier some compromises will be requ= ired.

It would be easy to change the RUE spec to use opportunistic media se= curity. This would still result in secure media if all entities on the sign= aling path support it. It that won't be assured until step (3). Getting thi= s to work with a WebRTC-based RUE (that requires secure media) will require at least SDP rewriting.
Thoughts?

   Thanks,
   Paul

On 9/5/19 4:31 PM, Paul Kyzivat wrote:
On 9/4/19 10:37 AM, Brian Rosen wrote:
Yes, for sure T.140 (RFC4103).
The providers have SBCs that anchor media, = so they can handle security on one side but not the other.  That=92s n= ot a great answer, but it=92s an answer.  Transcoding video is not rea= sonable.
The soon to be released updated version of = the Provider Profile specifies opportunistic media security [RFC8643].
Also, while providers use SBCs, some of the= m can set up e2e media for point to point calls, where the media won't be a= nchored and security can't be twiddled.
I think this can be a problem if RUM requir= es the RUE to signal mandatory media security, which (I think) WebRTC requi= res.
    Thanks,
    Paul
Brian

On Sep 4, 2019, at 10:35 AM, Gunnar Hellstr= =F6m <gunnar.hellstrom@om= nitor.se <mailto:gunn= ar.hellstrom@omnitor.se>> wrote:


Den 2019-09-04 kl. 15:54, skrev Brian Rosen= :
I think our consensus is MTI:
Audio: G.711 and Opus
Video: H.264

 Real-time text: T.140  &nbs= p;     (I think you said it is mandatory for clients, a= nd optional for services.)


All these need then transport and security = details specified to assure interop with RUM.

How can you hope for backward compatibility= with legacy devices when it is said in RUM that the security requirements = must be met?

Regards

Gunnar


We need to get into the details of H.264 to= maintain compatibility with the WebRTC specs and as much backwards compati= bility as possible.

Anyone object?



On Sep 3, 2019, at 10:48 AM, Paul Kyzivat &= lt;pkyzivat@alum.mit.edu <<= a href=3D"mailto:pkyzivat@alum.mit.edu">mailto:pkyzivat@alum.mit.edu>= ;> wrote:

On 9/2/19 4:39 AM, James Hamlin wrote:
Just to add: the VRS industry supports a va= riety of endpoints, many of which are hardware based and not built by VRS p= roviders themselves. H.264 and G..711 therefore need to be in the MTI list.=
I believe the FCC order related to compensa= tion by compliant providers not that every call had to come from a complian= t endpoint.
Sorry if I got that wrong. I wrote that fro= m memory and perhaps my memory is faulty.

Thanks,
Paul

Best Regards
James
________________________________________
From: Rum <rum-bounces@ietf.org <mailto:rum-bounces@ietf.org>> on behalf of Paul Kyzivat <= pkyzivat@alum..mit.edu <https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A_= _mit.edu&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCm= pw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DkUpN= W-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=3D>>
Sent: 28 August 2019 16:48
To: rum@iet= f.org <mailto:rum@ietf.org>
Subject: Re: [Rum] Codec requirements in dr= aft-rosen-rue-01
On 8/28/19 11:25 AM, Eric Burger wrote:
I guess the question is whether we want tod= ay=92s devices to have a chance of being RUM compatible. I don=92t think an= yone will be surprised if a five-year-old device is history. Is it realisti= c for current devices to get VP8 upgrade? [Would be nice for some manufacturers or others building such devices to p= ipe in here.]
Lets be clear about what we mean by "R= UM compatible".
When Henning and I were working on this wit= h the providers in 2014 and
2015 there was an expectation that the prov= iders would be required to
support the defined RUE devices, but they w= ould also be permitted to
support their existing proprietary devices.= The RUE devices could have
requirements that their existing devices do= n't meet. But calls between
the two were expected to work.
There was great consternation when subseque= ntly the FCC issued a
proposed order that said only VRS calls inv= olving RUE-compatible devices
would be compensated. (But that was in 2015= . I presume it has not happened.)
If there is an intent to exclude non-RUM-co= mpliant devices from use in
VRS calls then there needs to be a migratio= n plan to get from here to there.
       &= nbsp;Thanks,
       &= nbsp;Paul
On Aug 28, 2019, at 10:38 AM, Brian Rosen &= lt;br@brianrosen.net <mailto:br@brianrosen.net>> wrote:

If we require OPUS and G.711 as MTI and we = require both H.264 and VP8 as MTI, then we get backwards compatibility with= out transcoding and forwards compatibility with WebRTC.  Isn=92t that = what we want?

Brian

On Aug 28, 2019, at 10:15 AM, Paul Kyzivat = <pkyzivat@alum.mit.edu <= mailto:pkyzivat@alum.mit.edu&g= t;> wrote:

Inline...

On 8/27/19 5:57 PM, Adam Roach wrote:
I certainly have thoughts. The executive su= mmary is that I personally believe RUM should specify Opus as the one audio= codec MTI, and match RFC 7742's "Non-Browser" requirements for t= he video codec MTI. Rationale below.
 From an interop perspective, the impo= rtant thing is that any given profile has (at least) one MTI video codec an= d (at least) one MTI audio codec.. I know there is a strong desire -- one t= hat I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcod= ing.
For audio: WebRTC selected G.711 and Opus a= s both MTI; the former because it works without transcoding to landline PST= N destinations, and the latter because it sounds much, much better. RUM cou= ld make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designa= te Opus as the only MTI. Given that RUM inherently needs to deploy into aud= io/video environments, backwards compatibility with the PSTN seems to be un= necessary baggage.
Please keep in mind where we are coming fro= m. The RUM will be a new interface to the *existing* VRS infrastructure. Th= at infrastructure currently has proprietary devices that serve the RUE func= tion, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and a= lso *recommend* G.722.2.

Making OPUS the only MTI audio codec would = be problematic.

For video: While specifying either VP8 or H= .264 would be sufficient for system interop, and for interop with compliant= WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec = wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be i= dentical to those defined for "WebRTC Non-Browsers" in Section 5 = of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC = Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers.
Continuing my comment above, existing devic= es have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1= as the MTI codec. Odds are many of these devices aren't capable of VP8.

We can't realistically require a wholesale = swap out of existing devices before the RUE defined by RUM can work. We can= *discuss* whether forcing the providers to transcode is a practical way fo= rward. I'm dubious.

    Thanks,
    Paul

/a
On 8/27/19 2:34 PM, Brian Rosen wrote:
Well, we certainly want interoperability, a= nd I think we can only get that with MTI codecs.

I think we really are talking about a WebRT= C-compatible endpoint, but we want interoperability with a WebRTC browser e= ndpoint.

Not sure how to say this.  Maybe Adam = can help.

Brian

On Aug 12, 2019, at 4:20 PM, Paul Kyzivat &= lt;pkyzivat@alum.mit.edu <<= a href=3D"mailto:pkyzivat@alum.mit.edu">mailto:pkyzivat@alum.mit.edu>= ;> wrote:

draft-rosen-rue-01 changes the video codec = requirements. It now simply references webrtc RFC7742.

RFC7742 distinguishes three types of endpoi= nts: "WebRTC browser", "WebRTC non-browser", and "= WebRTC-compatible endpoint". AFAIK it assumes that each end is one of = these.

Is the expectation here that both the RUE a= nd the provider comply with one of these? In particular, that the provider = may simply be a "WebRTC-compatible endpoint? Notably:

   "WebRTC-compatible e= ndpoints" are free to implement any video codecs
   they see fit.  This = follows logically from the definition of "WebRTC-
   compatible endpoint"= .  It is, of course, advisable to implement at
   least one of the video co= decs that is mandated for WebRTC browsers,
   and implementors are enco= uraged to do so.

Similarly, the audio requirements have been= changed to reference webrtc RFC7874. That one doesn't have the distinction= between "WebRTC browser", "WebRTC non-browser", and &q= uot;WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn= 't make the same endpoint distinctions as for video.

I think simply referencing these documents = isn't sufficient. Seems like we need a more nuanced specification of what i= s required, though we may still reference these docs with qualifications.

    Thanks,
    Paul


--
Rum mailing list
Rum@ietf.or= g <mailto:Rum@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mailman_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTS= QicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJ= xqhn01LZRSIbMUU&s=3DX7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= =3D

--
Rum mailing list
Rum@ietf.or= g <mailto:Rum@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mailman_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTS= QicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJ= xqhn01LZRSIbMUU&s=3DX7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= =3D
--
Rum mailing list
Rum@ietf.or= g <mailto:Rum@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mailman_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTS= QicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJ= xqhn01LZRSIbMUU&s=3DX7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= =3D

--
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
+46 708 204 288


--
Rum mailing list
Rum@ietf.org
htt= ps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_li= stinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQh= Cmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7= xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=3D
--_000_86E626A9C13D4106B42398223BF26D84attcom_-- From nobody Tue Oct 1 14:13:55 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E512001E for ; Tue, 1 Oct 2019 14:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 edi6jKUTmznx for ; Tue, 1 Oct 2019 14:13:48 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 36B55120089 for ; Tue, 1 Oct 2019 14:13:48 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id b136so51796268iof.3 for ; Tue, 01 Oct 2019 14:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ef82ku2SxfCC234pEz/XrNC28M5xvqQq2ZVu3X0YE9w=; b=rppsKX/0SgfeD2aYmGlUvQx56cjcMAFxxsXC+nq+FKtR0rhssNGVTNi1L+GsEcd0ri 3uI9Tg/nbZ+bep7zf+UQTMYtpSt6Pf0W9Bh+xxAKNZdp8+iv7+pidUD6GQp0ukXLajCj +5x96jYsW88JKtXe1Nyr0S5sT7M3e50CRE2/+BrXsSghx8aL1Tjkd/y8cKGXJ772eGGJ MqfnkKxObXWF8M5Z3nqIDpTxV6yRUBR79lRo8+RsPjujuDY4uTOKvMXZTf7ldDLudNzo VqGKbCL9YJcCHXOHWvkUuuDEB3w0lIbMgoAdX/Mxc/NzFqpv4voQ5SwMbITEYqYDkJM+ mI4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ef82ku2SxfCC234pEz/XrNC28M5xvqQq2ZVu3X0YE9w=; b=r4xLV4D8Gzldl72O8OyOuSn51+mw1Y6nAvBkHAEAoL8NCQ/84fxjAh2jN8WCVXhT93 7izSKIewEwwiYf050Juyx4g+bKWRhQqFt+ddmhoTbSOIcj9b/WNp1IkrVLleGheEUl8h f9OPQwOrLkVyXGWQgbiM70yJIk/HyNmHnfQiRqqdHwkOO/NUr2ZJu2+LaUmHdWCLCdHz RG4qWUfIoYWG44euuHiO+QgIZ95Nucj0U+ehfv2ycMxxlUnoynpt92wLsROd8xYRfKvZ Hx24GFtCeG2F63Bjj4xAwk1k2UqH4eGGI4KHgiBDURsV4RNfmPAg0GEt+3jI3MPvSk8q nwhg== X-Gm-Message-State: APjAAAVATVnOwDjcCzbr71cZa7McCk37WxndrE2AjOza78efsILAIS0T g9G2MjCY8omkXOW/7g/IspZcfw== X-Google-Smtp-Source: APXvYqwTp0JobTuzW+WELbxcdemO9EgnnZfxQsiSseoZR0mPOCIayqxvNw3TiDJKWRzaWf80yDLBcA== X-Received: by 2002:a02:7797:: with SMTP id g145mr441473jac.60.1569964427082; Tue, 01 Oct 2019 14:13:47 -0700 (PDT) Received: from brians-mbp-2707.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id c4sm7660928ioa.70.2019.10.01.14.13.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Oct 2019 14:13:46 -0700 (PDT) From: Brian Rosen Message-Id: <8D68FC26-6F7B-45AA-B615-BCA8193BC76F@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_F66A8B3E-817C-4634-86E3-606EF33DD897" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 1 Oct 2019 17:13:23 -0400 In-Reply-To: <86E626A9-C13D-4106-B423-98223BF26D84@att.com> Cc: Paul Kyzivat , "rum@ietf.org" To: MARTIN C DOLLY References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 21:13:53 -0000 --Apple-Mail=_F66A8B3E-817C-4634-86E3-606EF33DD897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As a practical matter, isn=E2=80=99t it the case that all providers have = Session Border Controllers in the path, and they anchor media at the = SBC? If that is true, the RUE can be secure and still connect to an insecure = older device. Brian > On Oct 1, 2019, at 4:19 PM, DOLLY, MARTIN C wrote: >=20 > Agree w Paul >=20 > Martin C. Dolly > Lead Member of Technical Staff > Government & Services Standards > AT&T > Cell: +1.609.903..3360 > Email: md3135@att.com >=20 > On Oct 1, 2019, at 4:14 PM, Paul Kyzivat > wrote: >=20 >> I would like to revive the point raised in the attached message that = had no followup discussion. >>=20 >> The problem with calling for mandatory media security on the RUE is = that current VRS calls use insecure media. The VRS Provider Profile = currently does not specify the RUE interface. It is the responsibility = of the provider to interface (using SDP rewriting or media bridging) the = calling RUE to either the terminating RUE or the other provider where = the terminating RUE is connected. But it would be inappropriate = (deceptive) to interface secure media to insecure media. >>=20 >> There are plans to upgrade media security over the VRS Provider = Profile. The following is a likely path forward, though steps 3-5 are = speculation on my part: >>=20 >> 1) The current VRS Provider Profile (v1) specifies insecure media. = That is what is currently deployed by VRS providers. >>=20 >> 2) There is a revised VRS Provider Profile (v2) in development. It = hopefully will be approved by the end of this year. It calls for = opportunistic media security [RFC8643] between providers. The reason is = to allow gradual migration of providers to the revised profile. >>=20 >> 3) Based on past history it may well take a year or more to = accomplish a complete migration of all providers to the new profile. At = that time all calls will be using secure media. >>=20 >> 4) Once that migration is complete it will be possible to make a = further revision to the profile (v3) that mandates offering = unprovisional media security while still allowing the acceptance of = offers of provisional media security. Again this is to allow a phase-in = period. >>=20 >> 5) Once that is complete, a v4 of the profile could then mandate = unprovisional media security. >>=20 >> If the new RUE spec isn't introduced until step (5) then media = security can be achieved without any bridging or SDP rewriting. But that = will likely be multiple years in the future. >>=20 >> To incorporate the new RUE spec earlier some compromises will be = required. >>=20 >> It would be easy to change the RUE spec to use opportunistic media = security. This would still result in secure media if all entities on the = signaling path support it. It that won't be assured until step (3). = Getting this to work with a WebRTC-based RUE (that requires secure = media) will require at least SDP rewriting. >>=20 >> Thoughts? >>=20 >> Thanks, >> Paul >>=20 >> On 9/5/19 4:31 PM, Paul Kyzivat wrote: >>> On 9/4/19 10:37 AM, Brian Rosen wrote: >>>> Yes, for sure T.140 (RFC4103). >>>> The providers have SBCs that anchor media, so they can handle = security on one side but not the other. That=E2=80=99s not a great = answer, but it=E2=80=99s an answer. Transcoding video is not = reasonable. >>> The soon to be released updated version of the Provider Profile = specifies opportunistic media security [RFC8643]. >>> Also, while providers use SBCs, some of them can set up e2e media = for point to point calls, where the media won't be anchored and security = can't be twiddled. >>> I think this can be a problem if RUM requires the RUE to signal = mandatory media security, which (I think) WebRTC requires. >>> Thanks, >>> Paul >>>> Brian >>>>=20 >>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellstr=C3=B6m = = >> wrote: >>>>>=20 >>>>>=20 >>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen: >>>>>> I think our consensus is MTI: >>>>>> Audio: G.711 and Opus >>>>>> Video: H.264 >>>>>=20 >>>>> Real-time text: T.140 (I think you said it is mandatory = for clients, and optional for services.) >>>>>=20 >>>>>=20 >>>>> All these need then transport and security details specified to = assure interop with RUM. >>>>>=20 >>>>> How can you hope for backward compatibility with legacy devices = when it is said in RUM that the security requirements must be met? >>>>>=20 >>>>> Regards >>>>>=20 >>>>> Gunnar >>>>>=20 >>>>>>=20 >>>>>> We need to get into the details of H.264 to maintain = compatibility with the WebRTC specs and as much backwards compatibility = as possible. >>>>>>=20 >>>>>> Anyone object? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat >> wrote: >>>>>>>=20 >>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote: >>>>>>>> Just to add: the VRS industry supports a variety of endpoints, = many of which are hardware based and not built by VRS providers = themselves. H.264 and G..711 therefore need to be in the MTI list. >>>>>>>> I believe the FCC order related to compensation by compliant = providers not that every call had to come from a compliant endpoint. >>>>>>> Sorry if I got that wrong. I wrote that from memory and perhaps = my memory is faulty. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>> Best Regards >>>>>>>> James >>>>>>>> ________________________________________ >>>>>>>> From: Rum = >> on behalf = of Paul Kyzivat = >> >>>>>>>> Sent: 28 August 2019 16:48 >>>>>>>> To: rum@ietf.org > >>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote: >>>>>>>>> I guess the question is whether we want today=E2=80=99s = devices to have a chance of being RUM compatible. I don=E2=80=99t think = anyone will be surprised if a five-year-old device is history. Is it = realistic for current devices to get VP8 upgrade? [Would be nice for = some manufacturers or others building such devices to pipe in here.] >>>>>>>> Lets be clear about what we mean by "RUM compatible". >>>>>>>> When Henning and I were working on this with the providers in = 2014 and >>>>>>>> 2015 there was an expectation that the providers would be = required to >>>>>>>> support the defined RUE devices, but they would also be = permitted to >>>>>>>> support their existing proprietary devices. The RUE devices = could have >>>>>>>> requirements that their existing devices don't meet. But calls = between >>>>>>>> the two were expected to work. >>>>>>>> There was great consternation when subsequently the FCC issued = a >>>>>>>> proposed order that said only VRS calls involving = RUE-compatible devices >>>>>>>> would be compensated. (But that was in 2015.. I presume it has = not happened.) >>>>>>>> If there is an intent to exclude non-RUM-compliant devices from = use in >>>>>>>> VRS calls then there needs to be a migration plan to get from = here to there. >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen >> wrote: >>>>>>>>>>=20 >>>>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 = and VP8 as MTI, then we get backwards compatibility without transcoding = and forwards compatibility with WebRTC. Isn=E2=80=99t that what we = want? >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat = = >> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Inline... >>>>>>>>>>>=20 >>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>>>>>>> I certainly have thoughts. The executive summary is that I = personally believe RUM should specify Opus as the one audio codec MTI, = and match RFC 7742's "Non-Browser" requirements for the video codec MTI. = Rationale below. >>>>>>>>>>>> =46rom an interop perspective, the important thing is that = any given profile has (at least) one MTI video codec and (at least) one = MTI audio codec.. I know there is a strong desire -- one that I share -- = that these endpoints can talk to/be implemented in web browsers without = the need for media transcoding. >>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the = former because it works without transcoding to landline PSTN = destinations, and the latter because it sounds much, much better. RUM = could make the same decision; or it could decide to move away from a = codec that is as old as I am and opt to designate Opus as the only MTI. = Given that RUM inherently needs to deploy into audio/video environments, = backwards compatibility with the PSTN seems to be unnecessary baggage. >>>>>>>>>>> Please keep in mind where we are coming from. The RUM will = be a new interface to the *existing* VRS infrastructure. That = infrastructure currently has proprietary devices that serve the RUE = function, deployed to VRS users and to Communications Assistants (CAs, = Interpreters). These have G.711 MTI, and also *recommend* G.722.2. >>>>>>>>>>>=20 >>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic. >>>>>>>>>>>=20 >>>>>>>>>>>> For video: While specifying either VP8 or H..264 would be = sufficient for system interop, and for interop with compliant WebRTC = endpoints, I'd really prefer not to re-live the WebRTC video codec wars. = Concretely, what I would propose is that RUM indicate that the video = codec requirements are defined to be identical to those defined for = "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear = that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that = they comply with the same video codec requirements as WebRTC = Non-Browsers. >>>>>>>>>>> Continuing my comment above, existing devices have H.264 = Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI = codec. Odds are many of these devices aren't capable of VP8. >>>>>>>>>>>=20 >>>>>>>>>>> We can't realistically require a wholesale swap out of = existing devices before the RUE defined by RUM can work. We can = *discuss* whether forcing the providers to transcode is a practical way = forward. I'm dubious. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>>=20 >>>>>>>>>>>> /a >>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>>>>>>>>>> Well, we certainly want interoperability, and I think we = can only get that with MTI codecs. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible = endpoint, but we want interoperability with a WebRTC browser endpoint. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Not sure how to say this. Maybe Adam can help. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Brian >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = = >> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. = It now simply references webrtc RFC7742. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC = browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK = it assumes that each end is one of these. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Is the expectation here that both the RUE and the = provider comply with one of these? In particular, that the provider may = simply be a "WebRTC-compatible endpoint? Notably: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "WebRTC-compatible endpoints" are free to implement = any video codecs >>>>>>>>>>>>>> they see fit. This follows logically from the = definition of "WebRTC- >>>>>>>>>>>>>> compatible endpoint".. It is, of course, advisable to = implement at >>>>>>>>>>>>>> least one of the video codecs that is mandated for = WebRTC browsers, >>>>>>>>>>>>>> and implementors are encouraged to do so. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Similarly, the audio requirements have been changed to = reference webrtc RFC7874. That one doesn't have the distinction between = "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible = endpoint". It applies the same requirements to all. In particular, it = requires OPUS support. I don't know why it doesn't make the same = endpoint distinctions as for video. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think simply referencing these documents isn't = sufficient. Seems like we need a more nuanced specification of what is = required, though we may still reference these docs with qualifications. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> Rum mailing list >>>>>>>>>> Rum@ietf.org > >>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D = >>>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Rum mailing list >>>>>>>> Rum@ietf.org > >>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D = >>>>>>> --=20 >>>>>>> Rum mailing list >>>>>>> Rum@ietf.org > >>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D = >>>>>=20 >>>>> --=20 >>>>> ----------------------------------------- >>>>> Gunnar Hellstr=C3=B6m >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se = > >>>>> +46 708 204 288 >>>>=20 >>=20 >> --=20 >> Rum mailing list >> Rum@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D = > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_F66A8B3E-817C-4634-86E3-606EF33DD897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = a practical matter, isn=E2=80=99t it the case that all providers have = Session Border Controllers in the path, and they anchor media at the = SBC?

If that is = true, the RUE can be secure and still connect to an insecure older = device.

Brian

On Oct 1, 2019, at 4:19 PM, DOLLY, MARTIN C <md3135@att.com> = wrote:

Agree w Paul

Martin C. Dolly
Lead = Member of Technical Staff
Government = & Services Standards
AT&T
Cell: +1.609.903..3360

On Oct 1, 2019, at 4:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I would like to revive the = point raised in the attached message that had no followup = discussion.

The problem with calling for mandatory media security = on the RUE is that current VRS calls use insecure media. The VRS = Provider Profile currently does not specify the RUE interface. It is the = responsibility of the provider to interface (using SDP rewriting or media bridging) the calling RUE to either the terminating RUE or the = other provider where the terminating RUE is connected. But it would be = inappropriate (deceptive) to interface secure media to insecure = media.

There are plans to upgrade media security over the VRS = Provider Profile. The following is a likely path forward, though steps = 3-5 are speculation on my part:

1) The current VRS Provider Profile (v1) specifies = insecure media. That is what is currently deployed by VRS = providers.

2) There is a revised VRS Provider Profile (v2) in = development. It hopefully will be approved by the end of this year. It = calls for opportunistic media security [RFC8643] between providers. The = reason is to allow gradual migration of providers to the revised profile.

3) Based on past history it may well take a year or = more to accomplish a complete migration of all providers to the new = profile. At that time all calls will be using secure media.

4) Once that migration is complete it will be possible = to make a further revision to the profile (v3) that mandates offering = unprovisional media security while still allowing the acceptance of = offers of provisional media security. Again this is to allow a phase-in period.

5) Once that is complete, a v4 of the profile could = then mandate unprovisional media security.

If the new RUE spec isn't introduced until step (5) = then media security can be achieved without any bridging or SDP = rewriting. But that will likely be multiple years in the = future.

To incorporate the new RUE spec earlier some = compromises will be required.

It would be easy to change the RUE spec to use = opportunistic media security. This would still result in secure media if = all entities on the signaling path support it. It that won't be assured = until step (3). Getting this to work with a WebRTC-based RUE (that requires secure media) will require at least SDP = rewriting.

Thoughts?

   Thanks,
   Paul

On 9/5/19 4:31 PM, Paul Kyzivat wrote:
On 9/4/19 10:37 = AM, Brian Rosen wrote:
Yes, for sure = T.140 (RFC4103).
The providers have = SBCs that anchor media, so they can handle security on one side but not = the other.  That=E2=80=99s not a great answer, but it=E2=80=99s an = answer.  Transcoding video is not reasonable.
The soon to be = released updated version of the Provider Profile specifies opportunistic = media security [RFC8643].
Also, while = providers use SBCs, some of them can set up e2e media for point to point = calls, where the media won't be anchored and security can't be = twiddled.
I think this can = be a problem if RUM requires the RUE to signal mandatory media security, = which (I think) WebRTC requires.
    Thanks,
    Paul
Brian

On Sep 4, 2019, at = 10:35 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> = wrote:


Den 2019-09-04 kl. = 15:54, skrev Brian Rosen:
I think our = consensus is MTI:
Audio: G.711 and = Opus
Video: = H.264

 Real-time = text: T.140        (I think you said = it is mandatory for clients, and optional for services.)


All these need = then transport and security details specified to assure interop with = RUM.

How can you hope = for backward compatibility with legacy devices when it is said in RUM = that the security requirements must be met?

Regards

Gunnar


We need to get = into the details of H.264 to maintain compatibility with the WebRTC = specs and as much backwards compatibility as possible.

Anyone = object?



On Sep 3, 2019, at = 10:48 AM, Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:

On 9/2/19 4:39 AM, = James Hamlin wrote:
Just to add: the = VRS industry supports a variety of endpoints, many of which are hardware = based and not built by VRS providers themselves. H.264 and G..711 = therefore need to be in the MTI list.
I believe the FCC = order related to compensation by compliant providers not that every call = had to come from a compliant endpoint.
Sorry if I got = that wrong. I wrote that from memory and perhaps my memory is = faulty.

Thanks,
Paul

Best = Regards
James
________________________________________
From: Rum <rum-bounces@ietf.org = <mailto:rum-bounces@ietf.org>> on behalf of Paul = Kyzivat <pkyzivat@alum..mit.edu <https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__mit.edu&a= mp;d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2= g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DkUpNW-xdqJT1= L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=3D>>
=
Sent: 28 August = 2019 16:48
To: rum@ietf.org <mailto:rum@ietf.org>
Subject: Re: [Rum] = Codec requirements in draft-rosen-rue-01
On 8/28/19 11:25 = AM, Eric Burger wrote:
I guess the = question is whether we want today=E2=80=99s devices to have a chance of = being RUM compatible. I don=E2=80=99t think anyone will be surprised if = a five-year-old device is history. Is it realistic for current devices = to get VP8 upgrade? [Would be nice for some manufacturers or others building such devices = to pipe in here.]
Lets be clear = about what we mean by "RUM compatible".
When Henning and I = were working on this with the providers in 2014 and
2015 there was an = expectation that the providers would be required to
support the = defined RUE devices, but they would also be permitted to
support their = existing proprietary devices. The RUE devices could have
requirements that = their existing devices don't meet. But calls between
=
the two were = expected to work.
There was great = consternation when subsequently the FCC issued a
proposed order = that said only VRS calls involving RUE-compatible devices
would be = compensated. (But that was in 2015.. I presume it has not = happened.)
If there is an = intent to exclude non-RUM-compliant devices from use in
VRS calls then = there needs to be a migration plan to get from here to there.
        Thanks,<= br class=3D"">
        Paul
On Aug 28, 2019, = at 10:38 AM, Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>> wrote:

If we require OPUS = and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get = backwards compatibility without transcoding and forwards compatibility = with WebRTC.  Isn=E2=80=99t that what we want?

Brian

On Aug 28, 2019, = at 10:15 AM, Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:

Inline...

On 8/27/19 5:57 = PM, Adam Roach wrote:
I certainly have = thoughts. The executive summary is that I personally believe RUM should = specify Opus as the one audio codec MTI, and match RFC 7742's = "Non-Browser" requirements for the video codec MTI. Rationale = below.
 =46rom an = interop perspective, the important thing is that any given profile has = (at least) one MTI video codec and (at least) one MTI audio codec.. I = know there is a strong desire -- one that I share -- that these = endpoints can talk to/be implemented in web browsers without the need for media = transcoding.
For audio: WebRTC = selected G.711 and Opus as both MTI; the former because it works without = transcoding to landline PSTN destinations, and the latter because it = sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to = designate Opus as the only MTI. Given that RUM inherently needs to = deploy into audio/video environments, backwards compatibility with the = PSTN seems to be unnecessary baggage.
Please keep in = mind where we are coming from. The RUM will be a new interface to the = *existing* VRS infrastructure. That infrastructure currently has = proprietary devices that serve the RUE function, deployed to VRS users = and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, = and also *recommend* G.722.2.

Making OPUS the = only MTI audio codec would be problematic.

For video: While = specifying either VP8 or H..264 would be sufficient for system interop, = and for interop with compliant WebRTC endpoints, I'd really prefer not = to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to = be identical to those defined for "WebRTC Non-Browsers" in Section 5 of = RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC = Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC = Non-Browsers.
Continuing my = comment above, existing devices have H.264 Constrained Baseline Profile, = Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these = devices aren't capable of VP8.

We can't = realistically require a wholesale swap out of existing devices before = the RUE defined by RUM can work. We can *discuss* whether forcing the = providers to transcode is a practical way forward. I'm = dubious.

    Thanks,
    Paul

/a
On 8/27/19 2:34 = PM, Brian Rosen wrote:
Well, we certainly = want interoperability, and I think we can only get that with MTI = codecs.

I think we really = are talking about a WebRTC-compatible endpoint, but we want = interoperability with a WebRTC browser endpoint.

Not sure how to = say this.  Maybe Adam can help.

Brian

On Aug 12, 2019, = at 4:20 PM, Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:

draft-rosen-rue-01 = changes the video codec requirements. It now simply references webrtc = RFC7742.

RFC7742 = distinguishes three types of endpoints: "WebRTC browser", "WebRTC = non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that = each end is one of these.

Is the expectation = here that both the RUE and the provider comply with one of these? In = particular, that the provider may simply be a "WebRTC-compatible = endpoint? Notably:

   "WebRTC-compatible endpoints" are free to = implement any video codecs
   they see fit.  This follows logically = from the definition of "WebRTC-
   compatible endpoint"..  It is, of = course, advisable to implement at
   least one of the video codecs that is = mandated for WebRTC browsers,
   and implementors are encouraged to do = so.

Similarly, the = audio requirements have been changed to reference webrtc RFC7874. That = one doesn't have the distinction between "WebRTC browser", "WebRTC = non-browser", and "WebRTC-compatible endpoint". It applies the same = requirements to all. In particular, it requires OPUS support. I don't know why it = doesn't make the same endpoint distinctions as for video.

I think simply = referencing these documents isn't sufficient. Seems like we need a more = nuanced specification of what is required, though we may still reference = these docs with qualifications.

    Thanks,
    Paul


--
Rum mailing = list
Rum@ietf.org <mailto:Rum@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&am= p;r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZR= SIbMUU&s=3DX7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=3D

--
Rum mailing = list
Rum@ietf.org <mailto:Rum@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&am= p;r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZR= SIbMUU&s=3DX7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=3D
--
Rum mailing = list
Rum@ietf.org <mailto:Rum@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&am= p;r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZR= SIbMUU&s=3DX7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=3D

--
-----------------------------------------
=
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
+46 708 204 = 288


--
Rum mailing list
Rum@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&am= p;r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZR= SIbMUU&s=3DX7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=3D
--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_F66A8B3E-817C-4634-86E3-606EF33DD897-- From nobody Tue Oct 1 16:51:47 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433CB1202A0 for ; Tue, 1 Oct 2019 16:51: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, SPF_HELO_NONE=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 anKKuX9MAfpx for ; Tue, 1 Oct 2019 16:51:42 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E932E120132 for ; Tue, 1 Oct 2019 16:51:41 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x91NpabF009404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Oct 2019 19:51:37 -0400 To: Brian Rosen , MARTIN C DOLLY Cc: "rum@ietf.org" References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com> <8D68FC26-6F7B-45AA-B615-BCA8193BC76F@brianrosen.net> From: Paul Kyzivat Message-ID: <8297d07c-b488-4e04-745b-df38b9b317e9@alum.mit.edu> Date: Tue, 1 Oct 2019 19:51:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <8D68FC26-6F7B-45AA-B615-BCA8193BC76F@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 23:51:46 -0000 On 10/1/19 5:13 PM, Brian Rosen wrote: > As a practical matter, isn’t it the case that all providers have Session > Border Controllers in the path, and they anchor media at the SBC? Not entirely. There is some use of ICE, along with e2e media for p2p calls. And there is a desire to encourage that. > If that is true, the RUE can be secure and still connect to an insecure > older device. I don't think it is forbidden (as it is with SIPS) but downgrading security along the path is at least deceptive in that it might lead the user into a false sense of security. Thanks, Paul > Brian > >> On Oct 1, 2019, at 4:19 PM, DOLLY, MARTIN C > > wrote: >> >> Agree w Paul >> >> Martin C. Dolly >> Lead Member of Technical Staff >> Government & Services Standards >> AT&T >> Cell: +1.609.903..3360 >> Email: md3135@att.com >> >> On Oct 1, 2019, at 4:14 PM, Paul Kyzivat > > wrote: >> >>> I would like to revive the point raised in the attached message that >>> had no followup discussion. >>> >>> The problem with calling for mandatory media security on the RUE is >>> that current VRS calls use insecure media. The VRS Provider Profile >>> currently does not specify the RUE interface. It is the >>> responsibility of the provider to interface (using SDP rewriting or >>> media bridging) the calling RUE to either the terminating RUE or the >>> other provider where the terminating RUE is connected. But it would >>> be inappropriate (deceptive) to interface secure media to insecure media. >>> >>> There are plans to upgrade media security over the VRS Provider >>> Profile. The following is a likely path forward, though steps 3-5 are >>> speculation on my part: >>> >>> 1) The current VRS Provider Profile (v1) specifies insecure media. >>> That is what is currently deployed by VRS providers. >>> >>> 2) There is a revised VRS Provider Profile (v2) in development. It >>> hopefully will be approved by the end of this year. It calls for >>> opportunistic media security [RFC8643] between providers. The reason >>> is to allow gradual migration of providers to the revised profile. >>> >>> 3) Based on past history it may well take a year or more to >>> accomplish a complete migration of all providers to the new profile. >>> At that time all calls will be using secure media. >>> >>> 4) Once that migration is complete it will be possible to make a >>> further revision to the profile (v3) that mandates offering >>> unprovisional media security while still allowing the acceptance of >>> offers of provisional media security. Again this is to allow a >>> phase-in period. >>> >>> 5) Once that is complete, a v4 of the profile could then mandate >>> unprovisional media security. >>> >>> If the new RUE spec isn't introduced until step (5) then media >>> security can be achieved without any bridging or SDP rewriting. But >>> that will likely be multiple years in the future. >>> >>> To incorporate the new RUE spec earlier some compromises will be >>> required. >>> >>> It would be easy to change the RUE spec to use opportunistic media >>> security. This would still result in secure media if all entities on >>> the signaling path support it. It that won't be assured until step >>> (3). Getting this to work with a WebRTC-based RUE (that requires >>> secure media) will require at least SDP rewriting. >>> >>> Thoughts? >>> >>>    Thanks, >>>    Paul >>> >>> On 9/5/19 4:31 PM, Paul Kyzivat wrote: >>>> On 9/4/19 10:37 AM, Brian Rosen wrote: >>>>> Yes, for sure T.140 (RFC4103). >>>>> The providers have SBCs that anchor media, so they can handle >>>>> security on one side but not the other.  That’s not a great answer, >>>>> but it’s an answer.  Transcoding video is not reasonable. >>>> The soon to be released updated version of the Provider Profile >>>> specifies opportunistic media security [RFC8643]. >>>> Also, while providers use SBCs, some of them can set up e2e media >>>> for point to point calls, where the media won't be anchored and >>>> security can't be twiddled. >>>> I think this can be a problem if RUM requires the RUE to signal >>>> mandatory media security, which (I think) WebRTC requires. >>>>     Thanks, >>>>     Paul >>>>> Brian >>>>> >>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström >>>>>> >>>>>> > wrote: >>>>>> >>>>>> >>>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen: >>>>>>> I think our consensus is MTI: >>>>>>> Audio: G.711 and Opus >>>>>>> Video: H.264 >>>>>> >>>>>>  Real-time text: T.140        (I think you said it is mandatory >>>>>> for clients, and optional for services.) >>>>>> >>>>>> >>>>>> All these need then transport and security details specified to >>>>>> assure interop with RUM. >>>>>> >>>>>> How can you hope for backward compatibility with legacy devices >>>>>> when it is said in RUM that the security requirements must be met? >>>>>> >>>>>> Regards >>>>>> >>>>>> Gunnar >>>>>> >>>>>>> >>>>>>> We need to get into the details of H.264 to maintain >>>>>>> compatibility with the WebRTC specs and as much backwards >>>>>>> compatibility as possible. >>>>>>> >>>>>>> Anyone object? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote: >>>>>>>>> Just to add: the VRS industry supports a variety of endpoints, >>>>>>>>> many of which are hardware based and not built by VRS providers >>>>>>>>> themselves. H.264 and G..711 therefore need to be in the MTI list. >>>>>>>>> I believe the FCC order related to compensation by compliant >>>>>>>>> providers not that every call had to come from a compliant >>>>>>>>> endpoint. >>>>>>>> Sorry if I got that wrong. I wrote that from memory and perhaps >>>>>>>> my memory is faulty. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> James >>>>>>>>> ________________________________________ >>>>>>>>> From: Rum >>>>>>>>> > on behalf of Paul Kyzivat >>>>>>>>> >>>>>>>>> > >>>>>>>>> Sent: 28 August 2019 16:48 >>>>>>>>> To: rum@ietf.org >>>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >>>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote: >>>>>>>>>> I guess the question is whether we want today’s devices to >>>>>>>>>> have a chance of being RUM compatible. I don’t think anyone >>>>>>>>>> will be surprised if a five-year-old device is history. Is it >>>>>>>>>> realistic for current devices to get VP8 upgrade? [Would be >>>>>>>>>> nice for some manufacturers or others building such devices to >>>>>>>>>> pipe in here.] >>>>>>>>> Lets be clear about what we mean by "RUM compatible". >>>>>>>>> When Henning and I were working on this with the providers in >>>>>>>>> 2014 and >>>>>>>>> 2015 there was an expectation that the providers would be >>>>>>>>> required to >>>>>>>>> support the defined RUE devices, but they would also be >>>>>>>>> permitted to >>>>>>>>> support their existing proprietary devices. The RUE devices >>>>>>>>> could have >>>>>>>>> requirements that their existing devices don't meet. But calls >>>>>>>>> between >>>>>>>>> the two were expected to work. >>>>>>>>> There was great consternation when subsequently the FCC issued a >>>>>>>>> proposed order that said only VRS calls involving >>>>>>>>> RUE-compatible devices >>>>>>>>> would be compensated. (But that was in 2015.. I presume it has >>>>>>>>> not happened.) >>>>>>>>> If there is an intent to exclude non-RUM-compliant devices from >>>>>>>>> use in >>>>>>>>> VRS calls then there needs to be a migration plan to get from >>>>>>>>> here to there. >>>>>>>>>         Thanks, >>>>>>>>>         Paul >>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 >>>>>>>>>>> and VP8 as MTI, then we get backwards compatibility without >>>>>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t >>>>>>>>>>> that what we want? >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> Inline... >>>>>>>>>>>> >>>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>>>>>>>> I certainly have thoughts. The executive summary is that I >>>>>>>>>>>>> personally believe RUM should specify Opus as the one audio >>>>>>>>>>>>> codec MTI, and match RFC 7742's "Non-Browser" requirements >>>>>>>>>>>>> for the video codec MTI. Rationale below. >>>>>>>>>>>>>  From an interop perspective, the important thing is that >>>>>>>>>>>>> any given profile has (at least) one MTI video codec and >>>>>>>>>>>>> (at least) one MTI audio codec.. I know there is a strong >>>>>>>>>>>>> desire -- one that I share -- that these endpoints can talk >>>>>>>>>>>>> to/be implemented in web browsers without the need for >>>>>>>>>>>>> media transcoding. >>>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the >>>>>>>>>>>>> former because it works without transcoding to landline >>>>>>>>>>>>> PSTN destinations, and the latter because it sounds much, >>>>>>>>>>>>> much better. RUM could make the same decision; or it could >>>>>>>>>>>>> decide to move away from a codec that is as old as I am and >>>>>>>>>>>>> opt to designate Opus as the only MTI. Given that RUM >>>>>>>>>>>>> inherently needs to deploy into audio/video environments, >>>>>>>>>>>>> backwards compatibility with the PSTN seems to be >>>>>>>>>>>>> unnecessary baggage. >>>>>>>>>>>> Please keep in mind where we are coming from. The RUM will >>>>>>>>>>>> be a new interface to the *existing* VRS infrastructure. >>>>>>>>>>>> That infrastructure currently has proprietary devices that >>>>>>>>>>>> serve the RUE function, deployed to VRS users and to >>>>>>>>>>>> Communications Assistants (CAs, Interpreters). These have >>>>>>>>>>>> G.711 MTI, and also *recommend* G.722.2. >>>>>>>>>>>> >>>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic. >>>>>>>>>>>> >>>>>>>>>>>>> For video: While specifying either VP8 or H..264 would be >>>>>>>>>>>>> sufficient for system interop, and for interop with >>>>>>>>>>>>> compliant WebRTC endpoints, I'd really prefer not to >>>>>>>>>>>>> re-live the WebRTC video codec wars. Concretely, what I >>>>>>>>>>>>> would propose is that RUM indicate that the video codec >>>>>>>>>>>>> requirements are defined to be identical to those defined >>>>>>>>>>>>> for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It >>>>>>>>>>>>> should be made clear that RUM endpoints *are* *not* WebRTC >>>>>>>>>>>>> Non-Browsers per se; merely that they comply with the same >>>>>>>>>>>>> video codec requirements as WebRTC Non-Browsers. >>>>>>>>>>>> Continuing my comment above, existing devices have H.264 >>>>>>>>>>>> Constrained Baseline Profile, Level 1.3, packetization mode >>>>>>>>>>>> 1 as the MTI codec. Odds are many of these devices aren't >>>>>>>>>>>> capable of VP8. >>>>>>>>>>>> >>>>>>>>>>>> We can't realistically require a wholesale swap out of >>>>>>>>>>>> existing devices before the RUE defined by RUM can work. We >>>>>>>>>>>> can *discuss* whether forcing the providers to transcode is >>>>>>>>>>>> a practical way forward. I'm dubious. >>>>>>>>>>>> >>>>>>>>>>>>     Thanks, >>>>>>>>>>>>     Paul >>>>>>>>>>>> >>>>>>>>>>>>> /a >>>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>>>>>>>>>>> Well, we certainly want interoperability, and I think we >>>>>>>>>>>>>> can only get that with MTI codecs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible >>>>>>>>>>>>>> endpoint, but we want interoperability with a WebRTC >>>>>>>>>>>>>> browser endpoint. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not sure how to say this.  Maybe Adam can help. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Brian >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. >>>>>>>>>>>>>>> It now simply references webrtc RFC7742. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC >>>>>>>>>>>>>>> browser", "WebRTC non-browser", and "WebRTC-compatible >>>>>>>>>>>>>>> endpoint". AFAIK it assumes that each end is one of these. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is the expectation here that both the RUE and the >>>>>>>>>>>>>>> provider comply with one of these? In particular, that >>>>>>>>>>>>>>> the provider may simply be a "WebRTC-compatible endpoint? >>>>>>>>>>>>>>> Notably: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>    "WebRTC-compatible endpoints" are free to implement >>>>>>>>>>>>>>> any video codecs >>>>>>>>>>>>>>>    they see fit.  This follows logically from the >>>>>>>>>>>>>>> definition of "WebRTC- >>>>>>>>>>>>>>>    compatible endpoint"..  It is, of course, advisable to >>>>>>>>>>>>>>> implement at >>>>>>>>>>>>>>>    least one of the video codecs that is mandated for >>>>>>>>>>>>>>> WebRTC browsers, >>>>>>>>>>>>>>>    and implementors are encouraged to do so. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Similarly, the audio requirements have been changed to >>>>>>>>>>>>>>> reference webrtc RFC7874. That one doesn't have the >>>>>>>>>>>>>>> distinction between "WebRTC browser", "WebRTC >>>>>>>>>>>>>>> non-browser", and "WebRTC-compatible endpoint". It >>>>>>>>>>>>>>> applies the same requirements to all. In particular, it >>>>>>>>>>>>>>> requires OPUS support. I don't know why it doesn't make >>>>>>>>>>>>>>> the same endpoint distinctions as for video. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think simply referencing these documents isn't >>>>>>>>>>>>>>> sufficient. Seems like we need a more nuanced >>>>>>>>>>>>>>> specification of what is required, though we may still >>>>>>>>>>>>>>> reference these docs with qualifications. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>     Thanks, >>>>>>>>>>>>>>>     Paul >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Rum mailing list >>>>>>>>>>> Rum@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Rum mailing list >>>>>>>>> Rum@ietf.org >>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>>>> -- >>>>>>>> Rum mailing list >>>>>>>> Rum@ietf.org >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>> >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellström >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>>> >>>>>> +46 708 204 288 >>>>> >>> >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > From nobody Tue Oct 1 16:53:32 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508391202A0 for ; Tue, 1 Oct 2019 16:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 DuIMFkK2FZtC for ; Tue, 1 Oct 2019 16:53:28 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA82E120132 for ; Tue, 1 Oct 2019 16:53:27 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x91NrMNn009526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Oct 2019 19:53:23 -0400 To: "DOLLY, MARTIN C" Cc: "rum@ietf.org" References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com> From: Paul Kyzivat Message-ID: <3e3c0b3c-0415-1785-3095-2089a281e9df@alum.mit.edu> Date: Tue, 1 Oct 2019 19:53:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <86E626A9-C13D-4106-B423-98223BF26D84@att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 23:53:31 -0000 On 10/1/19 4:19 PM, DOLLY, MARTIN C wrote: > Agree w Paul > > Martin C. Dolly Thanks Martin. Can you be more explicit about what you are agreeing with? Thanks, Paul > Lead Member of Technical Staff > > Government & Services Standards > > AT&T > > Cell: +1.609.903.3360 > > Email: md3135@att.com > > > On Oct 1, 2019, at 4:14 PM, Paul Kyzivat > wrote: > >> I would like to revive the point raised in the attached message that >> had no followup discussion. >> >> The problem with calling for mandatory media security on the RUE is >> that current VRS calls use insecure media. The VRS Provider Profile >> currently does not specify the RUE interface. It is the responsibility >> of the provider to interface (using SDP rewriting or media bridging) >> the calling RUE to either the terminating RUE or the other provider >> where the terminating RUE is connected. But it would be inappropriate >> (deceptive) to interface secure media to insecure media. >> >> There are plans to upgrade media security over the VRS Provider >> Profile. The following is a likely path forward, though steps 3-5 are >> speculation on my part: >> >> 1) The current VRS Provider Profile (v1) specifies insecure media. >> That is what is currently deployed by VRS providers. >> >> 2) There is a revised VRS Provider Profile (v2) in development. It >> hopefully will be approved by the end of this year. It calls for >> opportunistic media security [RFC8643] between providers. The reason >> is to allow gradual migration of providers to the revised profile. >> >> 3) Based on past history it may well take a year or more to accomplish >> a complete migration of all providers to the new profile. At that time >> all calls will be using secure media. >> >> 4) Once that migration is complete it will be possible to make a >> further revision to the profile (v3) that mandates offering >> unprovisional media security while still allowing the acceptance of >> offers of provisional media security. Again this is to allow a >> phase-in period. >> >> 5) Once that is complete, a v4 of the profile could then mandate >> unprovisional media security. >> >> If the new RUE spec isn't introduced until step (5) then media >> security can be achieved without any bridging or SDP rewriting. But >> that will likely be multiple years in the future. >> >> To incorporate the new RUE spec earlier some compromises will be required. >> >> It would be easy to change the RUE spec to use opportunistic media >> security. This would still result in secure media if all entities on >> the signaling path support it. It that won't be assured until step >> (3). Getting this to work with a WebRTC-based RUE (that requires >> secure media) will require at least SDP rewriting. >> >> Thoughts? >> >>    Thanks, >>    Paul >> >> On 9/5/19 4:31 PM, Paul Kyzivat wrote: >>> On 9/4/19 10:37 AM, Brian Rosen wrote: >>>> Yes, for sure T.140 (RFC4103). >>>> The providers have SBCs that anchor media, so they can handle >>>> security on one side but not the other.  That’s not a great answer, >>>> but it’s an answer.  Transcoding video is not reasonable. >>> The soon to be released updated version of the Provider Profile >>> specifies opportunistic media security [RFC8643]. >>> Also, while providers use SBCs, some of them can set up e2e media for >>> point to point calls, where the media won't be anchored and security >>> can't be twiddled. >>> I think this can be a problem if RUM requires the RUE to signal >>> mandatory media security, which (I think) WebRTC requires. >>>     Thanks, >>>     Paul >>>> Brian >>>> >>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström >>>>> >>>>> > wrote: >>>>> >>>>> >>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen: >>>>>> I think our consensus is MTI: >>>>>> Audio: G.711 and Opus >>>>>> Video: H.264 >>>>> >>>>>  Real-time text: T.140        (I think you said it is mandatory for >>>>> clients, and optional for services.) >>>>> >>>>> >>>>> All these need then transport and security details specified to >>>>> assure interop with RUM. >>>>> >>>>> How can you hope for backward compatibility with legacy devices >>>>> when it is said in RUM that the security requirements must be met? >>>>> >>>>> Regards >>>>> >>>>> Gunnar >>>>> >>>>>> >>>>>> We need to get into the details of H.264 to maintain compatibility >>>>>> with the WebRTC specs and as much backwards compatibility as possible. >>>>>> >>>>>> Anyone object? >>>>>> >>>>>> >>>>>> >>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat >>>>>> > wrote: >>>>>>> >>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote: >>>>>>>> Just to add: the VRS industry supports a variety of endpoints, >>>>>>>> many of which are hardware based and not built by VRS providers >>>>>>>> themselves. H.264 and G..711 therefore need to be in the MTI list. >>>>>>>> I believe the FCC order related to compensation by compliant >>>>>>>> providers not that every call had to come from a compliant endpoint. >>>>>>> Sorry if I got that wrong. I wrote that from memory and perhaps >>>>>>> my memory is faulty. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Best Regards >>>>>>>> James >>>>>>>> ________________________________________ >>>>>>>> From: Rum >>>>>>>> > on behalf of Paul Kyzivat >>>>>>>> >>>>>>>> > >>>>>>>> Sent: 28 August 2019 16:48 >>>>>>>> To: rum@ietf.org >>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote: >>>>>>>>> I guess the question is whether we want today’s devices to have >>>>>>>>> a chance of being RUM compatible. I don’t think anyone will be >>>>>>>>> surprised if a five-year-old device is history. Is it realistic >>>>>>>>> for current devices to get VP8 upgrade? [Would be nice for some >>>>>>>>> manufacturers or others building such devices to pipe in here.] >>>>>>>> Lets be clear about what we mean by "RUM compatible". >>>>>>>> When Henning and I were working on this with the providers in >>>>>>>> 2014 and >>>>>>>> 2015 there was an expectation that the providers would be >>>>>>>> required to >>>>>>>> support the defined RUE devices, but they would also be permitted to >>>>>>>> support their existing proprietary devices. The RUE devices >>>>>>>> could have >>>>>>>> requirements that their existing devices don't meet. But calls >>>>>>>> between >>>>>>>> the two were expected to work. >>>>>>>> There was great consternation when subsequently the FCC issued a >>>>>>>> proposed order that said only VRS calls involving RUE-compatible >>>>>>>> devices >>>>>>>> would be compensated. (But that was in 2015. I presume it has >>>>>>>> not happened.) >>>>>>>> If there is an intent to exclude non-RUM-compliant devices from >>>>>>>> use in >>>>>>>> VRS calls then there needs to be a migration plan to get from >>>>>>>> here to there. >>>>>>>>         Thanks, >>>>>>>>         Paul >>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 >>>>>>>>>> and VP8 as MTI, then we get backwards compatibility without >>>>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t >>>>>>>>>> that what we want? >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat >>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Inline... >>>>>>>>>>> >>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>>>>>>> I certainly have thoughts. The executive summary is that I >>>>>>>>>>>> personally believe RUM should specify Opus as the one audio >>>>>>>>>>>> codec MTI, and match RFC 7742's "Non-Browser" requirements >>>>>>>>>>>> for the video codec MTI. Rationale below. >>>>>>>>>>>>  From an interop perspective, the important thing is that >>>>>>>>>>>> any given profile has (at least) one MTI video codec and (at >>>>>>>>>>>> least) one MTI audio codec.. I know there is a strong desire >>>>>>>>>>>> -- one that I share -- that these endpoints can talk to/be >>>>>>>>>>>> implemented in web browsers without the need for media >>>>>>>>>>>> transcoding. >>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the >>>>>>>>>>>> former because it works without transcoding to landline PSTN >>>>>>>>>>>> destinations, and the latter because it sounds much, much >>>>>>>>>>>> better. RUM could make the same decision; or it could decide >>>>>>>>>>>> to move away from a codec that is as old as I am and opt to >>>>>>>>>>>> designate Opus as the only MTI. Given that RUM inherently >>>>>>>>>>>> needs to deploy into audio/video environments, backwards >>>>>>>>>>>> compatibility with the PSTN seems to be unnecessary baggage. >>>>>>>>>>> Please keep in mind where we are coming from. The RUM will be >>>>>>>>>>> a new interface to the *existing* VRS infrastructure. That >>>>>>>>>>> infrastructure currently has proprietary devices that serve >>>>>>>>>>> the RUE function, deployed to VRS users and to Communications >>>>>>>>>>> Assistants (CAs, Interpreters). These have G.711 MTI, and >>>>>>>>>>> also *recommend* G.722.2. >>>>>>>>>>> >>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic. >>>>>>>>>>> >>>>>>>>>>>> For video: While specifying either VP8 or H.264 would be >>>>>>>>>>>> sufficient for system interop, and for interop with >>>>>>>>>>>> compliant WebRTC endpoints, I'd really prefer not to re-live >>>>>>>>>>>> the WebRTC video codec wars. Concretely, what I would >>>>>>>>>>>> propose is that RUM indicate that the video codec >>>>>>>>>>>> requirements are defined to be identical to those defined >>>>>>>>>>>> for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It >>>>>>>>>>>> should be made clear that RUM endpoints *are* *not* WebRTC >>>>>>>>>>>> Non-Browsers per se; merely that they comply with the same >>>>>>>>>>>> video codec requirements as WebRTC Non-Browsers. >>>>>>>>>>> Continuing my comment above, existing devices have H.264 >>>>>>>>>>> Constrained Baseline Profile, Level 1.3, packetization mode 1 >>>>>>>>>>> as the MTI codec. Odds are many of these devices aren't >>>>>>>>>>> capable of VP8. >>>>>>>>>>> >>>>>>>>>>> We can't realistically require a wholesale swap out of >>>>>>>>>>> existing devices before the RUE defined by RUM can work. We >>>>>>>>>>> can *discuss* whether forcing the providers to transcode is a >>>>>>>>>>> practical way forward. I'm dubious. >>>>>>>>>>> >>>>>>>>>>>     Thanks, >>>>>>>>>>>     Paul >>>>>>>>>>> >>>>>>>>>>>> /a >>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>>>>>>>>>> Well, we certainly want interoperability, and I think we >>>>>>>>>>>>> can only get that with MTI codecs. >>>>>>>>>>>>> >>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible >>>>>>>>>>>>> endpoint, but we want interoperability with a WebRTC >>>>>>>>>>>>> browser endpoint. >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure how to say this.  Maybe Adam can help. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. >>>>>>>>>>>>>> It now simply references webrtc RFC7742. >>>>>>>>>>>>>> >>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC >>>>>>>>>>>>>> browser", "WebRTC non-browser", and "WebRTC-compatible >>>>>>>>>>>>>> endpoint". AFAIK it assumes that each end is one of these. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is the expectation here that both the RUE and the provider >>>>>>>>>>>>>> comply with one of these? In particular, that the provider >>>>>>>>>>>>>> may simply be a "WebRTC-compatible endpoint? Notably: >>>>>>>>>>>>>> >>>>>>>>>>>>>>    "WebRTC-compatible endpoints" are free to implement any >>>>>>>>>>>>>> video codecs >>>>>>>>>>>>>>    they see fit.  This follows logically from the >>>>>>>>>>>>>> definition of "WebRTC- >>>>>>>>>>>>>>    compatible endpoint".  It is, of course, advisable to >>>>>>>>>>>>>> implement at >>>>>>>>>>>>>>    least one of the video codecs that is mandated for >>>>>>>>>>>>>> WebRTC browsers, >>>>>>>>>>>>>>    and implementors are encouraged to do so. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Similarly, the audio requirements have been changed to >>>>>>>>>>>>>> reference webrtc RFC7874. That one doesn't have the >>>>>>>>>>>>>> distinction between "WebRTC browser", "WebRTC >>>>>>>>>>>>>> non-browser", and "WebRTC-compatible endpoint". It applies >>>>>>>>>>>>>> the same requirements to all. In particular, it requires >>>>>>>>>>>>>> OPUS support. I don't know why it doesn't make the same >>>>>>>>>>>>>> endpoint distinctions as for video. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think simply referencing these documents isn't >>>>>>>>>>>>>> sufficient. Seems like we need a more nuanced >>>>>>>>>>>>>> specification of what is required, though we may still >>>>>>>>>>>>>> reference these docs with qualifications. >>>>>>>>>>>>>> >>>>>>>>>>>>>>     Thanks, >>>>>>>>>>>>>>     Paul >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Rum mailing list >>>>>>>>>> Rum@ietf.org >>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>>>>> >>>>>>>> -- >>>>>>>> Rum mailing list >>>>>>>> Rum@ietf.org >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>>> -- >>>>>>> Rum mailing list >>>>>>> Rum@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellström >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> >>>>> +46 708 204 288 >>>> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= From nobody Wed Oct 2 07:38:41 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 359971200B1; Wed, 2 Oct 2019 07:38:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, rum@ietf.org, pkyzivat@alum.mit.edu, rum-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157002712020.8961.11503070925591420022.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2019 07:38:40 -0700 Archived-At: Subject: [Rum] rum - New Meeting Session Request for IETF 106 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 14:38:40 -0000 A new meeting session request has just been submitted by Paul Kyzivat, a Chair of the rum working group. --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Paul Kyzivat Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: avtcore dispatch modern sipcore ecrit mmusic Technology Overlap: quic People who must be present: Adam Roach Brian Rosen Paul Kyzivat Resources Requested: Special Requests: Please avoid Friday as Brian cannot attend that day --------------------------------------------------------- From nobody Thu Oct 3 17:47:39 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC224120827 for ; Thu, 3 Oct 2019 17:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-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 s_c-2-HQLPLn for ; Thu, 3 Oct 2019 17:47:34 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 80E26120814 for ; Thu, 3 Oct 2019 17:47:34 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id o12so6329470qtf.3 for ; Thu, 03 Oct 2019 17:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R1pQjneXP9eRO/FD+A/6o5qykh/RqFTQGRqeG/2j7gg=; b=Oh93R+c9SEJm/rGzC20w1r+UjgSoydEsfrS5PgO3fP1p+h/RKk3XoUPgQ3tvs6DfFk xF4zp7qKIqx0HkE61/QMxTAX1Eh34WX1R8WGIz1xFu6hs7NAQzcwdmtDiKWrpccb/6GW 0mygt1EPzYjs73msVjOQvUb/k27JYGIeN3Fw2K+N/dY30MVSpFT0u6sBPefjQ1HFJbFI vApVSJpciQiwIjYeloC/yM79v1W7e2ekdB5z/KhnrEczs1rntzk4CiSiWz+PsAamlMwf tUSti09fj3rwfaeJmC1Xwf/+kkVDb4ldllqoURKeaevPQPfbFmAkz3AlOnJxCQL8fFz4 sz2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R1pQjneXP9eRO/FD+A/6o5qykh/RqFTQGRqeG/2j7gg=; b=fkw+W+y4/vEvI9BsV/WWvK5YPY6W/rgFPm70wuRJEj48hRknaV/1oE3CvzG+S4CqG0 59I8PIpr68I+haTO85jCee0j1rLesRFckVbj0girNAQceuYWo7d7hL3U2G+RXZRIHle4 3SH7bSjKXhLW4IOH9fs3ayfqTd2hsotIfBma9K2S3ZdaADgyVQPqK7bwr6JHiEowO6y7 5tq0JfNJJRqNW5Pc5S0+/gsTdwZOeHSbTzwV8uSIKZlVQYebSHGMTpAYDEn+PXUavhTG c0kmapnrd+pah/tKtb5BO61wjXN63H1OrCL+q7M7g5kAwdmizrFekNJj84tx2x1wqhPf DrfA== X-Gm-Message-State: APjAAAWZ6jAva4PCdTNjTeNWVEQ2FlNoNzjMNyN3ZV0lUPQ1ZJzK834x 6m1IDTTaXh8To+cBfeGOxnYgkg== X-Google-Smtp-Source: APXvYqyF0ArnCbciJCninGUZEiPbZ4bLvns0HgP1/4TLoZvEMtdCRxNWiHoC9JaylZ+wUWTcHpcHKQ== X-Received: by 2002:ac8:2ae9:: with SMTP id c38mr13110157qta.311.1570150053409; Thu, 03 Oct 2019 17:47:33 -0700 (PDT) Received: from ?IPv6:2601:41:c402:39e0:350f:d864:d005:c51e? ([2601:41:c402:39e0:350f:d864:d005:c51e]) by smtp.gmail.com with ESMTPSA id m186sm2791787qkb.88.2019.10.03.17.47.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 17:47:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chris Wendt In-Reply-To: <3e3c0b3c-0415-1785-3095-2089a281e9df@alum.mit.edu> Date: Thu, 3 Oct 2019 20:47:30 -0400 Cc: Martin C Dolly , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com> <3e3c0b3c-0415-1785-3095-2089a281e9df@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 00:47:38 -0000 I would express my agreement maybe a different way. What doesn=E2=80=99t = make complete sense to me is the specification of RUM/RUE devices that = seem to try to live in two different worlds. What maybe i could call a = traditional SIP UE/terminal world, but also trying to stick on a vision = of moving to webrtc media, etc. and modern video conferencing world. While i understand this is all possible theoretically, I=E2=80=99m not = sure it is reality for most current webrtc supporting eco-systems. Most = i=E2=80=99m familiar with are using different signaling protocols, = support multiple participants, simulcast and multi-bitrate stream and = modern communications practices/identities etc. I think this is why we = had such a hard time finding a direction for NAANC IVC and beyond just = basic IR.94 a point to point SIP protocol based eco-system, other than = the standard deployment in the VRS world, this barely exists elsewhere, = and I would guess is trending smaller, not larger. So, i think it would be nice to sort of come to a reality check on where = this is all going. If we are talking about putting SBC/gateways in front of RUM/RUE devices = anyway, it might be better to envision gateways into webrtc devices that = look/feel more like messaging and video apps and use gateways into SIP = networks for standard NNI protocol but allow for what typically seems to = be proprietary SIP to webrtc gateway + app or SIP to webrtc gateway + = device style deployments. I know maybe that=E2=80=99s not a great = message for in the IETF and the work in this group, but i think it=E2=80=99= s really reality for most of what i know is being deployed going forward = in general. For a lot of good reasons, point to point vs multi-point = calling supporting devices/apps are what people like to use. I feel = like that is what i seem to be hearing from the communities that depend = on these devices and services generally as well, but i won=E2=80=99t = claim to be an authority for that opinion. -Chris > On Oct 1, 2019, at 7:53 PM, Paul Kyzivat = wrote: >=20 > On 10/1/19 4:19 PM, DOLLY, MARTIN C wrote: >> Agree w Paul >> Martin C. Dolly >=20 > Thanks Martin. Can you be more explicit about what you are agreeing = with? >=20 > Thanks, > Paul >=20 >> Lead Member of Technical Staff >> Government & Services Standards >> AT&T >> Cell: +1.609.903.3360 >> Email: md3135@att.com >> On Oct 1, 2019, at 4:14 PM, Paul Kyzivat > wrote: >>> I would like to revive the point raised in the attached message that = had no followup discussion. >>>=20 >>> The problem with calling for mandatory media security on the RUE is = that current VRS calls use insecure media. The VRS Provider Profile = currently does not specify the RUE interface. It is the responsibility = of the provider to interface (using SDP rewriting or media bridging) the = calling RUE to either the terminating RUE or the other provider where = the terminating RUE is connected. But it would be inappropriate = (deceptive) to interface secure media to insecure media. >>>=20 >>> There are plans to upgrade media security over the VRS Provider = Profile. The following is a likely path forward, though steps 3-5 are = speculation on my part: >>>=20 >>> 1) The current VRS Provider Profile (v1) specifies insecure media. = That is what is currently deployed by VRS providers. >>>=20 >>> 2) There is a revised VRS Provider Profile (v2) in development. It = hopefully will be approved by the end of this year. It calls for = opportunistic media security [RFC8643] between providers. The reason is = to allow gradual migration of providers to the revised profile. >>>=20 >>> 3) Based on past history it may well take a year or more to = accomplish a complete migration of all providers to the new profile. At = that time all calls will be using secure media. >>>=20 >>> 4) Once that migration is complete it will be possible to make a = further revision to the profile (v3) that mandates offering = unprovisional media security while still allowing the acceptance of = offers of provisional media security. Again this is to allow a phase-in = period. >>>=20 >>> 5) Once that is complete, a v4 of the profile could then mandate = unprovisional media security. >>>=20 >>> If the new RUE spec isn't introduced until step (5) then media = security can be achieved without any bridging or SDP rewriting. But that = will likely be multiple years in the future. >>>=20 >>> To incorporate the new RUE spec earlier some compromises will be = required. >>>=20 >>> It would be easy to change the RUE spec to use opportunistic media = security. This would still result in secure media if all entities on the = signaling path support it. It that won't be assured until step (3). = Getting this to work with a WebRTC-based RUE (that requires secure = media) will require at least SDP rewriting. >>>=20 >>> Thoughts? >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 9/5/19 4:31 PM, Paul Kyzivat wrote: >>>> On 9/4/19 10:37 AM, Brian Rosen wrote: >>>>> Yes, for sure T.140 (RFC4103). >>>>> The providers have SBCs that anchor media, so they can handle = security on one side but not the other. That=E2=80=99s not a great = answer, but it=E2=80=99s an answer. Transcoding video is not = reasonable. >>>> The soon to be released updated version of the Provider Profile = specifies opportunistic media security [RFC8643]. >>>> Also, while providers use SBCs, some of them can set up e2e media = for point to point calls, where the media won't be anchored and security = can't be twiddled. >>>> I think this can be a problem if RUM requires the RUE to signal = mandatory media security, which (I think) WebRTC requires. >>>> Thanks, >>>> Paul >>>>> Brian >>>>>=20 >>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellstr=C3=B6m = = > wrote: >>>>>>=20 >>>>>>=20 >>>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen: >>>>>>> I think our consensus is MTI: >>>>>>> Audio: G.711 and Opus >>>>>>> Video: H.264 >>>>>>=20 >>>>>> Real-time text: T.140 (I think you said it is mandatory = for clients, and optional for services.) >>>>>>=20 >>>>>>=20 >>>>>> All these need then transport and security details specified to = assure interop with RUM. >>>>>>=20 >>>>>> How can you hope for backward compatibility with legacy devices = when it is said in RUM that the security requirements must be met? >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> Gunnar >>>>>>=20 >>>>>>>=20 >>>>>>> We need to get into the details of H.264 to maintain = compatibility with the WebRTC specs and as much backwards compatibility = as possible. >>>>>>>=20 >>>>>>> Anyone object? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat = = > wrote: >>>>>>>>=20 >>>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote: >>>>>>>>> Just to add: the VRS industry supports a variety of endpoints, = many of which are hardware based and not built by VRS providers = themselves. H.264 and G..711 therefore need to be in the MTI list. >>>>>>>>> I believe the FCC order related to compensation by compliant = providers not that every call had to come from a compliant endpoint. >>>>>>>> Sorry if I got that wrong. I wrote that from memory and perhaps = my memory is faulty. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>>=20 >>>>>>>>> Best Regards >>>>>>>>> James >>>>>>>>> ________________________________________ >>>>>>>>> From: Rum = > on behalf of Paul Kyzivat = = > >>>>>>>>> Sent: 28 August 2019 16:48 >>>>>>>>> To: rum@ietf.org >>>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >>>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote: >>>>>>>>>> I guess the question is whether we want today=E2=80=99s = devices to have a chance of being RUM compatible. I don=E2=80=99t think = anyone will be surprised if a five-year-old device is history. Is it = realistic for current devices to get VP8 upgrade? [Would be nice for = some manufacturers or others building such devices to pipe in here.] >>>>>>>>> Lets be clear about what we mean by "RUM compatible". >>>>>>>>> When Henning and I were working on this with the providers in = 2014 and >>>>>>>>> 2015 there was an expectation that the providers would be = required to >>>>>>>>> support the defined RUE devices, but they would also be = permitted to >>>>>>>>> support their existing proprietary devices. The RUE devices = could have >>>>>>>>> requirements that their existing devices don't meet. But calls = between >>>>>>>>> the two were expected to work. >>>>>>>>> There was great consternation when subsequently the FCC issued = a >>>>>>>>> proposed order that said only VRS calls involving = RUE-compatible devices >>>>>>>>> would be compensated. (But that was in 2015. I presume it has = not happened.) >>>>>>>>> If there is an intent to exclude non-RUM-compliant devices = from use in >>>>>>>>> VRS calls then there needs to be a migration plan to get from = here to there. >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> If we require OPUS and G.711 as MTI and we require both = H.264 and VP8 as MTI, then we get backwards compatibility without = transcoding and forwards compatibility with WebRTC. Isn=E2=80=99t that = what we want? >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat = = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Inline... >>>>>>>>>>>>=20 >>>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>>>>>>>> I certainly have thoughts. The executive summary is that I = personally believe RUM should specify Opus as the one audio codec MTI, = and match RFC 7742's "Non-Browser" requirements for the video codec MTI. = Rationale below. >>>>>>>>>>>>> =46rom an interop perspective, the important thing is = that any given profile has (at least) one MTI video codec and (at least) = one MTI audio codec.. I know there is a strong desire -- one that I = share -- that these endpoints can talk to/be implemented in web browsers = without the need for media transcoding. >>>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the = former because it works without transcoding to landline PSTN = destinations, and the latter because it sounds much, much better. RUM = could make the same decision; or it could decide to move away from a = codec that is as old as I am and opt to designate Opus as the only MTI. = Given that RUM inherently needs to deploy into audio/video environments, = backwards compatibility with the PSTN seems to be unnecessary baggage. >>>>>>>>>>>> Please keep in mind where we are coming from. The RUM will = be a new interface to the *existing* VRS infrastructure. That = infrastructure currently has proprietary devices that serve the RUE = function, deployed to VRS users and to Communications Assistants (CAs, = Interpreters). These have G.711 MTI, and also *recommend* G.722.2. >>>>>>>>>>>>=20 >>>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic. >>>>>>>>>>>>=20 >>>>>>>>>>>>> For video: While specifying either VP8 or H.264 would be = sufficient for system interop, and for interop with compliant WebRTC = endpoints, I'd really prefer not to re-live the WebRTC video codec wars. = Concretely, what I would propose is that RUM indicate that the video = codec requirements are defined to be identical to those defined for = "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear = that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that = they comply with the same video codec requirements as WebRTC = Non-Browsers. >>>>>>>>>>>> Continuing my comment above, existing devices have H.264 = Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI = codec. Odds are many of these devices aren't capable of VP8. >>>>>>>>>>>>=20 >>>>>>>>>>>> We can't realistically require a wholesale swap out of = existing devices before the RUE defined by RUM can work. We can = *discuss* whether forcing the providers to transcode is a practical way = forward. I'm dubious. >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Paul >>>>>>>>>>>>=20 >>>>>>>>>>>>> /a >>>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>>>>>>>>>>> Well, we certainly want interoperability, and I think we = can only get that with MTI codecs. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible = endpoint, but we want interoperability with a WebRTC browser endpoint. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Not sure how to say this. Maybe Adam can help. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = = > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. = It now simply references webrtc RFC7742. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC = browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK = it assumes that each end is one of these. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Is the expectation here that both the RUE and the = provider comply with one of these? In particular, that the provider may = simply be a "WebRTC-compatible endpoint? Notably: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> "WebRTC-compatible endpoints" are free to implement = any video codecs >>>>>>>>>>>>>>> they see fit. This follows logically from the = definition of "WebRTC- >>>>>>>>>>>>>>> compatible endpoint". It is, of course, advisable to = implement at >>>>>>>>>>>>>>> least one of the video codecs that is mandated for = WebRTC browsers, >>>>>>>>>>>>>>> and implementors are encouraged to do so. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Similarly, the audio requirements have been changed to = reference webrtc RFC7874. That one doesn't have the distinction between = "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible = endpoint". It applies the same requirements to all. In particular, it = requires OPUS support. I don't know why it doesn't make the same = endpoint distinctions as for video. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think simply referencing these documents isn't = sufficient. Seems like we need a more nuanced specification of what is = required, though we may still reference these docs with qualifications. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> Rum mailing list >>>>>>>>>>> Rum@ietf.org >>>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >>>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Rum mailing list >>>>>>>>> Rum@ietf.org >>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >>>>>>>> --=20 >>>>>>>> Rum mailing list >>>>>>>> Rum@ietf.org >>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >>>>>>=20 >>>>>> --=20 >>>>>> ----------------------------------------- >>>>>> Gunnar Hellstr=C3=B6m >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se = >>>>>> +46 708 204 288 >>>>>=20 >>>=20 >>> --=20 >>> Rum mailing list >>> Rum@ietf.org >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Fri Oct 4 07:03:52 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15A51200A3 for ; Fri, 4 Oct 2019 07:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 DzsgABvCZr5O for ; Fri, 4 Oct 2019 07:03:48 -0700 (PDT) Received: from se5h-lax1.servconfig.com (se5h-lax1.servconfig.com [173.231.200.195]) (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 65CA3120071 for ; Fri, 4 Oct 2019 07:03:48 -0700 (PDT) Received: from biz221.inmotionhosting.com ([192.145.239.201]) by se5-lax1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1iGOB5-000wvX-NJ for rum@ietf.org; Fri, 04 Oct 2019 10:03:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=8EVD3X0Blo2heFwcUJt92eJTJthgm0nKbXPX+IssQkA=; b=mdLsnzoBvwmsZoFN5994D00Gy ZnqQlFwI8BVN35gkx2hu/F0LpLvfwHszEjXqgcQylm2tnUZOwAV0M9qJ5Z7pKugGWzJeubkAnHmDi aGo1JJ9Krsso6G64Z5rclmSh55MI96VQfFC8XJAqujTXm+q4Dng+4pkvWbXHoPy+LhihI=; Received: from [104.129.194.119] (port=9318 helo=[172.20.28.177]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iGOAo-007FWE-U8 for rum@ietf.org; Fri, 04 Oct 2019 07:03:18 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_572ABE8A-4AD1-466C-BF4D-3108DAD08039"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 4 Oct 2019 10:03:08 -0400 References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com> <3e3c0b3c-0415-1785-3095-2089a281e9df@alum.mit.edu> To: "rum@ietf.org" In-Reply-To: Message-Id: <2DAFDD93-4C65-4D6D-B0DF-4E036D1DCD57@standardstrack.com> X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.2 X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Originating-IP: 192.145.239.201 X-SpamExperts-Domain: biz221.inmotionhosting.com X-SpamExperts-Username: 192.145.239.201 Authentication-Results: servconfig.com; auth=pass smtp.auth=192.145.239.201@biz221.inmotionhosting.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.31) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVlueqnRQlcnPA ZGhFy6RcuUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwzmmD1lPZONmDbVrCI7lkOfH zJ6mVE7ewsipSVIfs4Yc/kxLVEzUfT4GEKd5QUMNgyWFxOA5dILPypvKxNVhWW9iu9q1oNVH8nhC o/XpZxc/iXnuUw31frArk475PTzt0p8T4Nd45j4kJRgJ8MJ6+Md4EfSeS8yJNluG6jX3DLoRxK5O dUqDGvgvOW0ZV5+ajPA51CucGfCwfE7cCW8pKMnZ2EaDA1PmQopv7SCYWfjpxOsB8gG0slV7ra6j I4BSinhxldfhg28HAKUUgnPcbwGLnc+yV7lxSY64lkQzDsaYVVWBZ0FcqQQfT778mFH9Br4UQT5O ZMr/oeXfpj/bf7wqyT5p50x81ZKcmzCu2U3UDXCzB2RvHsONj9xE9zz/uLl5G81TJjfecGPYmAYi sSCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLZ8DTogwQ+H /c7sp+LxSn8PVEt4gmaG2RjwYKjjPoxP4nuZrRf7bMi0WRR6pZ+nWQE+L26KIUIpqMXu7LLX/Pa1 iWtCOy8M+6OCBxZTXpHJW5KaEOQNGmvIwzdiYUcqNlp7/Kmr4kFmhc2FzNwaRbfpsjwkpA5KFRsg cb2fEpSR7+os1iUt1gaukab36nH0kgG7Eq6LSIf7Fi4kMqfo4VeReoFxWEGsi1V1FGos/w8r+Omg Y9x9gmn57R8zjzBPVyG7X+t1TW39Ja77LGPpOwBxiOahCAHxu+EG+tWGsedsdzYrUh8gH+Su3lfX 3GGqPPMzfUNUUo/smy/GT3Vsn3D71WYfjIt2Mg/U0mvo5fsx/73cIb08xkVb3ZKCv/rl/p4LmTGI +05EviYz0ob+L9BHzq3YSILobAzCzsa++jPAA9a5xIXWLWP5TEF+bN/aB965dj1POfQw0ScCQmri GAT9v9INL9TP6gaX4C90lPb59jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@se1-lax1.servconfig.com Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 14:03:51 -0000 --Apple-Mail=_572ABE8A-4AD1-466C-BF4D-3108DAD08039 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Said a different way, since we know it takes a while for implementors to = build to specifications once the specifications are complete, why not = specify what we need, and leave transition to industry organizations? Using Paul=E2=80=99s terminology, we would specify V3 here, and in the = VRS case V2 could be negotiated by industry and, in the U.S. case, = perhaps the FCC? The point being that since it takes years to get a standard done, and = year (singular) to release product, we set the target and let the = laggards in industry (because there will always be a vendor or two and = open source that will have it done before the document pops out of the = RFC Editor queue) catch up? > On Oct 3, 2019, at 8:47 PM, Chris Wendt = wrote: >=20 > I would express my agreement maybe a different way. What doesn=E2=80=99= t make complete sense to me is the specification of RUM/RUE devices that = seem to try to live in two different worlds. What maybe i could call a = traditional SIP UE/terminal world, but also trying to stick on a vision = of moving to webrtc media, etc. and modern video conferencing world. >=20 > While i understand this is all possible theoretically, I=E2=80=99m not = sure it is reality for most current webrtc supporting eco-systems. Most = i=E2=80=99m familiar with are using different signaling protocols, = support multiple participants, simulcast and multi-bitrate stream and = modern communications practices/identities etc. I think this is why we = had such a hard time finding a direction for NAANC IVC and beyond just = basic IR.94 a point to point SIP protocol based eco-system, other than = the standard deployment in the VRS world, this barely exists elsewhere, = and I would guess is trending smaller, not larger. >=20 > So, i think it would be nice to sort of come to a reality check on = where this is all going. >=20 > If we are talking about putting SBC/gateways in front of RUM/RUE = devices anyway, it might be better to envision gateways into webrtc = devices that look/feel more like messaging and video apps and use = gateways into SIP networks for standard NNI protocol but allow for what = typically seems to be proprietary SIP to webrtc gateway + app or SIP to = webrtc gateway + device style deployments. I know maybe that=E2=80=99s = not a great message for in the IETF and the work in this group, but i = think it=E2=80=99s really reality for most of what i know is being = deployed going forward in general. For a lot of good reasons, point to = point vs multi-point calling supporting devices/apps are what people = like to use. I feel like that is what i seem to be hearing from the = communities that depend on these devices and services generally as well, = but i won=E2=80=99t claim to be an authority for that opinion. >=20 > -Chris >=20 >=20 >=20 >> On Oct 1, 2019, at 7:53 PM, Paul Kyzivat = wrote: >>=20 >> On 10/1/19 4:19 PM, DOLLY, MARTIN C wrote: >>> Agree w Paul >>> Martin C. Dolly >>=20 >> Thanks Martin. Can you be more explicit about what you are agreeing = with? >>=20 >> Thanks, >> Paul >>=20 >>> Lead Member of Technical Staff >>> Government & Services Standards >>> AT&T >>> Cell: +1.609.903.3360 >>> Email: md3135@att.com >>> On Oct 1, 2019, at 4:14 PM, Paul Kyzivat > wrote: >>>> I would like to revive the point raised in the attached message = that had no followup discussion. >>>>=20 >>>> The problem with calling for mandatory media security on the RUE is = that current VRS calls use insecure media. The VRS Provider Profile = currently does not specify the RUE interface. It is the responsibility = of the provider to interface (using SDP rewriting or media bridging) the = calling RUE to either the terminating RUE or the other provider where = the terminating RUE is connected. But it would be inappropriate = (deceptive) to interface secure media to insecure media. >>>>=20 >>>> There are plans to upgrade media security over the VRS Provider = Profile. The following is a likely path forward, though steps 3-5 are = speculation on my part: >>>>=20 >>>> 1) The current VRS Provider Profile (v1) specifies insecure media. = That is what is currently deployed by VRS providers. >>>>=20 >>>> 2) There is a revised VRS Provider Profile (v2) in development. It = hopefully will be approved by the end of this year. It calls for = opportunistic media security [RFC8643] between providers. The reason is = to allow gradual migration of providers to the revised profile. >>>>=20 >>>> 3) Based on past history it may well take a year or more to = accomplish a complete migration of all providers to the new profile. At = that time all calls will be using secure media. >>>>=20 >>>> 4) Once that migration is complete it will be possible to make a = further revision to the profile (v3) that mandates offering = unprovisional media security while still allowing the acceptance of = offers of provisional media security. Again this is to allow a phase-in = period. >>>>=20 >>>> 5) Once that is complete, a v4 of the profile could then mandate = unprovisional media security. >>>>=20 >>>> If the new RUE spec isn't introduced until step (5) then media = security can be achieved without any bridging or SDP rewriting. But that = will likely be multiple years in the future. >>>>=20 >>>> To incorporate the new RUE spec earlier some compromises will be = required. >>>>=20 >>>> It would be easy to change the RUE spec to use opportunistic media = security. This would still result in secure media if all entities on the = signaling path support it. It that won't be assured until step (3). = Getting this to work with a WebRTC-based RUE (that requires secure = media) will require at least SDP rewriting. >>>>=20 >>>> Thoughts? >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> On 9/5/19 4:31 PM, Paul Kyzivat wrote: >>>>> On 9/4/19 10:37 AM, Brian Rosen wrote: >>>>>> Yes, for sure T.140 (RFC4103). >>>>>> The providers have SBCs that anchor media, so they can handle = security on one side but not the other. That=E2=80=99s not a great = answer, but it=E2=80=99s an answer. Transcoding video is not = reasonable. >>>>> The soon to be released updated version of the Provider Profile = specifies opportunistic media security [RFC8643]. >>>>> Also, while providers use SBCs, some of them can set up e2e media = for point to point calls, where the media won't be anchored and security = can't be twiddled. >>>>> I think this can be a problem if RUM requires the RUE to signal = mandatory media security, which (I think) WebRTC requires. >>>>> Thanks, >>>>> Paul >>>>>> Brian >>>>>>=20 >>>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellstr=C3=B6m = = > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen: >>>>>>>> I think our consensus is MTI: >>>>>>>> Audio: G.711 and Opus >>>>>>>> Video: H.264 >>>>>>>=20 >>>>>>> Real-time text: T.140 (I think you said it is mandatory = for clients, and optional for services.) >>>>>>>=20 >>>>>>>=20 >>>>>>> All these need then transport and security details specified to = assure interop with RUM. >>>>>>>=20 >>>>>>> How can you hope for backward compatibility with legacy devices = when it is said in RUM that the security requirements must be met? >>>>>>>=20 >>>>>>> Regards >>>>>>>=20 >>>>>>> Gunnar >>>>>>>=20 >>>>>>>>=20 >>>>>>>> We need to get into the details of H.264 to maintain = compatibility with the WebRTC specs and as much backwards compatibility = as possible. >>>>>>>>=20 >>>>>>>> Anyone object? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat = = > wrote: >>>>>>>>>=20 >>>>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote: >>>>>>>>>> Just to add: the VRS industry supports a variety of = endpoints, many of which are hardware based and not built by VRS = providers themselves. H.264 and G..711 therefore need to be in the MTI = list. >>>>>>>>>> I believe the FCC order related to compensation by compliant = providers not that every call had to come from a compliant endpoint. >>>>>>>>> Sorry if I got that wrong. I wrote that from memory and = perhaps my memory is faulty. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>>=20 >>>>>>>>>> Best Regards >>>>>>>>>> James >>>>>>>>>> ________________________________________ >>>>>>>>>> From: Rum = > on behalf of Paul Kyzivat = = > >>>>>>>>>> Sent: 28 August 2019 16:48 >>>>>>>>>> To: rum@ietf.org >>>>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >>>>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote: >>>>>>>>>>> I guess the question is whether we want today=E2=80=99s = devices to have a chance of being RUM compatible. I don=E2=80=99t think = anyone will be surprised if a five-year-old device is history. Is it = realistic for current devices to get VP8 upgrade? [Would be nice for = some manufacturers or others building such devices to pipe in here.] >>>>>>>>>> Lets be clear about what we mean by "RUM compatible". >>>>>>>>>> When Henning and I were working on this with the providers in = 2014 and >>>>>>>>>> 2015 there was an expectation that the providers would be = required to >>>>>>>>>> support the defined RUE devices, but they would also be = permitted to >>>>>>>>>> support their existing proprietary devices. The RUE devices = could have >>>>>>>>>> requirements that their existing devices don't meet. But = calls between >>>>>>>>>> the two were expected to work. >>>>>>>>>> There was great consternation when subsequently the FCC = issued a >>>>>>>>>> proposed order that said only VRS calls involving = RUE-compatible devices >>>>>>>>>> would be compensated. (But that was in 2015. I presume it has = not happened.) >>>>>>>>>> If there is an intent to exclude non-RUM-compliant devices = from use in >>>>>>>>>> VRS calls then there needs to be a migration plan to get from = here to there. >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen = = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> If we require OPUS and G.711 as MTI and we require both = H.264 and VP8 as MTI, then we get backwards compatibility without = transcoding and forwards compatibility with WebRTC. Isn=E2=80=99t that = what we want? >>>>>>>>>>>>=20 >>>>>>>>>>>> Brian >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat = = > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Inline... >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>>>>>>>>> I certainly have thoughts. The executive summary is that = I personally believe RUM should specify Opus as the one audio codec MTI, = and match RFC 7742's "Non-Browser" requirements for the video codec MTI. = Rationale below. >>>>>>>>>>>>>> =46rom an interop perspective, the important thing is = that any given profile has (at least) one MTI video codec and (at least) = one MTI audio codec.. I know there is a strong desire -- one that I = share -- that these endpoints can talk to/be implemented in web browsers = without the need for media transcoding. >>>>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; = the former because it works without transcoding to landline PSTN = destinations, and the latter because it sounds much, much better. RUM = could make the same decision; or it could decide to move away from a = codec that is as old as I am and opt to designate Opus as the only MTI. = Given that RUM inherently needs to deploy into audio/video environments, = backwards compatibility with the PSTN seems to be unnecessary baggage. >>>>>>>>>>>>> Please keep in mind where we are coming from. The RUM will = be a new interface to the *existing* VRS infrastructure. That = infrastructure currently has proprietary devices that serve the RUE = function, deployed to VRS users and to Communications Assistants (CAs, = Interpreters). These have G.711 MTI, and also *recommend* G.722.2. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> For video: While specifying either VP8 or H.264 would be = sufficient for system interop, and for interop with compliant WebRTC = endpoints, I'd really prefer not to re-live the WebRTC video codec wars. = Concretely, what I would propose is that RUM indicate that the video = codec requirements are defined to be identical to those defined for = "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear = that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that = they comply with the same video codec requirements as WebRTC = Non-Browsers. >>>>>>>>>>>>> Continuing my comment above, existing devices have H.264 = Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI = codec. Odds are many of these devices aren't capable of VP8. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We can't realistically require a wholesale swap out of = existing devices before the RUE defined by RUM can work. We can = *discuss* whether forcing the providers to transcode is a practical way = forward. I'm dubious. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Paul >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> /a >>>>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>>>>>>>>>>>> Well, we certainly want interoperability, and I think we = can only get that with MTI codecs. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible = endpoint, but we want interoperability with a WebRTC browser endpoint. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Not sure how to say this. Maybe Adam can help. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = = > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec = requirements. It now simply references webrtc RFC7742. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC = browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK = it assumes that each end is one of these. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Is the expectation here that both the RUE and the = provider comply with one of these? In particular, that the provider may = simply be a "WebRTC-compatible endpoint? Notably: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "WebRTC-compatible endpoints" are free to implement = any video codecs >>>>>>>>>>>>>>>> they see fit. This follows logically from the = definition of "WebRTC- >>>>>>>>>>>>>>>> compatible endpoint". It is, of course, advisable to = implement at >>>>>>>>>>>>>>>> least one of the video codecs that is mandated for = WebRTC browsers, >>>>>>>>>>>>>>>> and implementors are encouraged to do so. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Similarly, the audio requirements have been changed to = reference webrtc RFC7874. That one doesn't have the distinction between = "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible = endpoint". It applies the same requirements to all. In particular, it = requires OPUS support. I don't know why it doesn't make the same = endpoint distinctions as for video. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I think simply referencing these documents isn't = sufficient. Seems like we need a more nuanced specification of what is = required, though we may still reference these docs with qualifications. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Rum mailing list >>>>>>>>>>>> Rum@ietf.org >>>>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >>>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Rum mailing list >>>>>>>>>> Rum@ietf.org >>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >>>>>>>>> -- >>>>>>>>> Rum mailing list >>>>>>>>> Rum@ietf.org >>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >>>>>>>=20 >>>>>>> -- >>>>>>> ----------------------------------------- >>>>>>> Gunnar Hellstr=C3=B6m >>>>>>> Omnitor >>>>>>> gunnar.hellstrom@omnitor.se = >>>>>>> +46 708 204 288 >>>>>>=20 >>>>=20 >>>> -- >>>> Rum mailing list >>>> Rum@ietf.org >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DrzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=3DX7xP468QMBuG_viv= uofaYnOnkS2XR-MaoASurKoOoLc&e=3D >>=20 >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_572ABE8A-4AD1-466C-BF4D-3108DAD08039 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAl2XURwACgkQDDCGh758 rslnow/9EJ/jJFqpt6swgyrS6BDehEPmfWnZ6+cd595Znt3QjnzsCtOjb7dxPxWI Dm4VIehRKcT5RMqXEbX8I8iaLgJaz7VTHn8QAvIUkjN0AI8ywMNRz7wgaeywg2LN PKU2z/qPpqVrHra7H9/8maIo+nmqAk2Rjz9FZOwOhyhQA/W/czhIoj5gGrwPprnE SzSPIE3ME2JmTOD2fvcArfo14dZnyTSrp0kMb7ibdpiGNzLT1gLJ4iEeqCxQCkI3 RHbMLF162+rAZPvu8Jre5Smt926vCGUUJGHUq/YDcRGev7B8wFvFjJVzcGZL8QQV HcHiW+Za4gJ1iNqVwc8JEZRNPBd+sTIWBOTLYhWGVAvE1cZWMmLnKAp6NC1Bvhh5 WpF+hnfE4a/29oqbU8zBeLEr3yKDw5J39g+MWUnK4v2rzvxlRmVacuRFy0ZMtVM+ +IMxrbV7B2pJyd0y89m/ago4wI8oI/0HoWwEP0YO+wo4VjRY2tdzqbi/4MUsFkUj OfhUEWytU9514miHOJP62xKSX9DOfpUjf/iLTictp6ZGYGI/eAbnvNpusoq+rvey nGDWIdIOIy8RTwOzJf6NmJqh9k42RNT++Y7NBmTKjxXN0Y6Kk/XVbuzjROM9CSdB mFluLUQITJ2kJ0SoQh/bNbHWQ/hM7G2Aoh60OLvTcGqyQr+SVVA= =1Xqq -----END PGP SIGNATURE----- --Apple-Mail=_572ABE8A-4AD1-466C-BF4D-3108DAD08039-- From nobody Fri Oct 4 08:42:23 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C721208F1 for ; Fri, 4 Oct 2019 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 WqYcFqbusQc8 for ; Fri, 4 Oct 2019 08:42:18 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7627120903 for ; Fri, 4 Oct 2019 08:42:17 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x94Ff8qv006650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Oct 2019 11:41:10 -0400 To: Chris Wendt Cc: Martin C Dolly , "rum@ietf.org" References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com> <3e3c0b3c-0415-1785-3095-2089a281e9df@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 4 Oct 2019 11:41:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Media security X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 15:42:22 -0000 Chris, On 10/3/19 8:47 PM, Chris Wendt wrote: > I would express my agreement maybe a different way. What doesn’t make complete sense to me is the specification of RUM/RUE devices that seem to try to live in two different worlds. What maybe i could call a traditional SIP UE/terminal world, but also trying to stick on a vision of moving to webrtc media, etc. and modern video conferencing world. > > While i understand this is all possible theoretically, I’m not sure it is reality for most current webrtc supporting eco-systems. Most i’m familiar with are using different signaling protocols, support multiple participants, simulcast and multi-bitrate stream and modern communications practices/identities etc. I think this is why we had such a hard time finding a direction for NAANC IVC and beyond just basic IR.94 a point to point SIP protocol based eco-system, other than the standard deployment in the VRS world, this barely exists elsewhere, and I would guess is trending smaller, not larger. > > So, i think it would be nice to sort of come to a reality check on where this is all going. > > If we are talking about putting SBC/gateways in front of RUM/RUE devices anyway, it might be better to envision gateways into webrtc devices that look/feel more like messaging and video apps and use gateways into SIP networks for standard NNI protocol but allow for what typically seems to be proprietary SIP to webrtc gateway + app or SIP to webrtc gateway + device style deployments. I know maybe that’s not a great message for in the IETF and the work in this group, but i think it’s really reality for most of what i know is being deployed going forward in general. For a lot of good reasons, point to point vs multi-point calling supporting devices/apps are what people like to use. I feel like that is what i seem to be hearing from the communities that depend on these devices and services generally as well, but i won’t claim to be an authority for that opinion. I'm not clear on what you are suggesting here. For use with VRS there are some constraints that come into play. (Perhaps these constraints can be eased over time, but the transition must be smooth.) 1) The point of VRS is to give deaf people parity and interoperability with hearing users. Because it is a federal government program under the FCC, subsidized by a tax on telephone service, it is based on the existing telephone network. AFAIK the FCC doesn't have authority to expand it further. It must be possible for someone using a RUE to communicate with any telephone number. I didn't participate in the NAANC IVC. My understanding is that it was trying to bridge newer (proprietary) communications systems to the existing phone system. I'd appreciate having more about that introduced here where appropriate. 2) VRS is deployed to many deaf users who depend on it now. Existing VRS services use proprietary RUE devices, both in users homes and on the desks of the interpreters. Anything we do must integrate with that. Chris, can you restate what you are suggesting while making clear how it fits with constraints? Thanks, Paul > -Chris > > > >> On Oct 1, 2019, at 7:53 PM, Paul Kyzivat wrote: >> >> On 10/1/19 4:19 PM, DOLLY, MARTIN C wrote: >>> Agree w Paul >>> Martin C. Dolly >> >> Thanks Martin. Can you be more explicit about what you are agreeing with? >> >> Thanks, >> Paul >> >>> Lead Member of Technical Staff >>> Government & Services Standards >>> AT&T >>> Cell: +1.609.903.3360 >>> Email: md3135@att.com >>> On Oct 1, 2019, at 4:14 PM, Paul Kyzivat > wrote: >>>> I would like to revive the point raised in the attached message that had no followup discussion. >>>> >>>> The problem with calling for mandatory media security on the RUE is that current VRS calls use insecure media. The VRS Provider Profile currently does not specify the RUE interface. It is the responsibility of the provider to interface (using SDP rewriting or media bridging) the calling RUE to either the terminating RUE or the other provider where the terminating RUE is connected. But it would be inappropriate (deceptive) to interface secure media to insecure media. >>>> >>>> There are plans to upgrade media security over the VRS Provider Profile. The following is a likely path forward, though steps 3-5 are speculation on my part: >>>> >>>> 1) The current VRS Provider Profile (v1) specifies insecure media. That is what is currently deployed by VRS providers. >>>> >>>> 2) There is a revised VRS Provider Profile (v2) in development. It hopefully will be approved by the end of this year. It calls for opportunistic media security [RFC8643] between providers. The reason is to allow gradual migration of providers to the revised profile. >>>> >>>> 3) Based on past history it may well take a year or more to accomplish a complete migration of all providers to the new profile. At that time all calls will be using secure media. >>>> >>>> 4) Once that migration is complete it will be possible to make a further revision to the profile (v3) that mandates offering unprovisional media security while still allowing the acceptance of offers of provisional media security. Again this is to allow a phase-in period. >>>> >>>> 5) Once that is complete, a v4 of the profile could then mandate unprovisional media security. >>>> >>>> If the new RUE spec isn't introduced until step (5) then media security can be achieved without any bridging or SDP rewriting. But that will likely be multiple years in the future. >>>> >>>> To incorporate the new RUE spec earlier some compromises will be required. >>>> >>>> It would be easy to change the RUE spec to use opportunistic media security. This would still result in secure media if all entities on the signaling path support it. It that won't be assured until step (3). Getting this to work with a WebRTC-based RUE (that requires secure media) will require at least SDP rewriting. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 9/5/19 4:31 PM, Paul Kyzivat wrote: >>>>> On 9/4/19 10:37 AM, Brian Rosen wrote: >>>>>> Yes, for sure T.140 (RFC4103). >>>>>> The providers have SBCs that anchor media, so they can handle security on one side but not the other. That’s not a great answer, but it’s an answer. Transcoding video is not reasonable. >>>>> The soon to be released updated version of the Provider Profile specifies opportunistic media security [RFC8643]. >>>>> Also, while providers use SBCs, some of them can set up e2e media for point to point calls, where the media won't be anchored and security can't be twiddled. >>>>> I think this can be a problem if RUM requires the RUE to signal mandatory media security, which (I think) WebRTC requires. >>>>> Thanks, >>>>> Paul >>>>>> Brian >>>>>> >>>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström > wrote: >>>>>>> >>>>>>> >>>>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen: >>>>>>>> I think our consensus is MTI: >>>>>>>> Audio: G.711 and Opus >>>>>>>> Video: H.264 >>>>>>> >>>>>>> Real-time text: T.140 (I think you said it is mandatory for clients, and optional for services.) >>>>>>> >>>>>>> >>>>>>> All these need then transport and security details specified to assure interop with RUM. >>>>>>> >>>>>>> How can you hope for backward compatibility with legacy devices when it is said in RUM that the security requirements must be met? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Gunnar >>>>>>> >>>>>>>> >>>>>>>> We need to get into the details of H.264 to maintain compatibility with the WebRTC specs and as much backwards compatibility as possible. >>>>>>>> >>>>>>>> Anyone object? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat > wrote: >>>>>>>>> >>>>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote: >>>>>>>>>> Just to add: the VRS industry supports a variety of endpoints, many of which are hardware based and not built by VRS providers themselves. H.264 and G..711 therefore need to be in the MTI list. >>>>>>>>>> I believe the FCC order related to compensation by compliant providers not that every call had to come from a compliant endpoint. >>>>>>>>> Sorry if I got that wrong. I wrote that from memory and perhaps my memory is faulty. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> Best Regards >>>>>>>>>> James >>>>>>>>>> ________________________________________ >>>>>>>>>> From: Rum > on behalf of Paul Kyzivat > >>>>>>>>>> Sent: 28 August 2019 16:48 >>>>>>>>>> To: rum@ietf.org >>>>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >>>>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote: >>>>>>>>>>> I guess the question is whether we want today’s devices to have a chance of being RUM compatible. I don’t think anyone will be surprised if a five-year-old device is history. Is it realistic for current devices to get VP8 upgrade? [Would be nice for some manufacturers or others building such devices to pipe in here.] >>>>>>>>>> Lets be clear about what we mean by "RUM compatible". >>>>>>>>>> When Henning and I were working on this with the providers in 2014 and >>>>>>>>>> 2015 there was an expectation that the providers would be required to >>>>>>>>>> support the defined RUE devices, but they would also be permitted to >>>>>>>>>> support their existing proprietary devices. The RUE devices could have >>>>>>>>>> requirements that their existing devices don't meet. But calls between >>>>>>>>>> the two were expected to work. >>>>>>>>>> There was great consternation when subsequently the FCC issued a >>>>>>>>>> proposed order that said only VRS calls involving RUE-compatible devices >>>>>>>>>> would be compensated. (But that was in 2015. I presume it has not happened.) >>>>>>>>>> If there is an intent to exclude non-RUM-compliant devices from use in >>>>>>>>>> VRS calls then there needs to be a migration plan to get from here to there. >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen > wrote: >>>>>>>>>>>> >>>>>>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get backwards compatibility without transcoding and forwards compatibility with WebRTC. Isn’t that what we want? >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Inline... >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>>>>>>>>> I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below. >>>>>>>>>>>>>> From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec.. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding. >>>>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage. >>>>>>>>>>>>> Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2. >>>>>>>>>>>>> >>>>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic. >>>>>>>>>>>>> >>>>>>>>>>>>>> For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers. >>>>>>>>>>>>> Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8. >>>>>>>>>>>>> >>>>>>>>>>>>> We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Paul >>>>>>>>>>>>> >>>>>>>>>>>>>> /a >>>>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>>>>>>>>>>>> Well, we certainly want interoperability, and I think we can only get that with MTI codecs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not sure how to say this. Maybe Adam can help. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat > wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "WebRTC-compatible endpoints" are free to implement any video codecs >>>>>>>>>>>>>>>> they see fit. This follows logically from the definition of "WebRTC- >>>>>>>>>>>>>>>> compatible endpoint". It is, of course, advisable to implement at >>>>>>>>>>>>>>>> least one of the video codecs that is mandated for WebRTC browsers, >>>>>>>>>>>>>>>> and implementors are encouraged to do so. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Rum mailing list >>>>>>>>>>>> Rum@ietf.org >>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Rum mailing list >>>>>>>>>> Rum@ietf.org >>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>>>>> -- >>>>>>>>> Rum mailing list >>>>>>>>> Rum@ietf.org >>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >>>>>>> >>>>>>> -- >>>>>>> ----------------------------------------- >>>>>>> Gunnar Hellström >>>>>>> Omnitor >>>>>>> gunnar.hellstrom@omnitor.se >>>>>>> +46 708 204 288 >>>>>> >>>> >>>> -- >>>> Rum mailing list >>>> Rum@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > > From nobody Tue Oct 15 15:54:11 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4971D120019; Tue, 15 Oct 2019 15:54:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, rum@ietf.org, lflynn@amsl.com, rum-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157118004823.27895.8799294788836673170.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2019 15:54:08 -0700 Archived-At: Subject: [Rum] rum - Update to a Meeting Session Request for IETF 106 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 22:54:09 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the rum working group. --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: avtcore dispatch modern sipcore ecrit mmusic Technology Overlap: quic People who must be present: Adam Roach Brian Rosen Paul Kyzivat Resources Requested: Special Requests: Please avoid Friday as Brian cannot attend that day. Not Tuesday morning --------------------------------------------------------- From nobody Fri Oct 25 14:15:49 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF1120A12; Fri, 25 Oct 2019 14:12:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: adam@nostrum.com, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793010.2724.16383839545715379951.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:10 -0700 Archived-At: Subject: [Rum] rum - Requested session has been scheduled for IETF 106 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:12:19 -0000 Dear Paul Kyzivat, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rum Session 1 (1:00 requested) Thursday, 21 November 2019, Morning Session I 1000-1200 Room Name: VIP A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/rum.ics Request Information: --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Paul Kyzivat Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: avtcore dispatch modern sipcore ecrit mmusic Technology Overlap: quic People who must be present: Adam Roach Brian Rosen Paul Kyzivat Resources Requested: Special Requests: Please avoid Friday as Brian cannot attend that day. Not Tuesday morning ---------------------------------------------------------