From nobody Sun Sep 1 14:27:03 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 250001200C5 for ; Sun, 1 Sep 2019 14:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_MZuKJmlz4o for ; Sun, 1 Sep 2019 14:26:55 -0700 (PDT) Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 E5ABB1200A4 for ; Sun, 1 Sep 2019 14:26:54 -0700 (PDT) X-Halon-ID: 2c72834a-ccff-11e9-bdc3-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 2c72834a-ccff-11e9-bdc3-005056917a89; Sun, 01 Sep 2019 23:26:34 +0200 (CEST) To: rum@ietf.org References: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> <5142d3b2-da81-25f0-8859-694cd6126f0b@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sun, 1 Sep 2019 23:26:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5142d3b2-da81-25f0-8859-694cd6126f0b@omnitor.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - is recvonly etc support desired? 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: Sun, 01 Sep 2019 21:27:01 -0000 I would like a comment from RUM if it is desirable to have support for the direction attributes : sendrecv, sendonly, recvonly, inactive,  for RTT streams? It might be for control of muting etc in multi-party situations, but of course also in other situations. Regards Gunnar Den 2019-08-31 kl. 22:47, skrev Gunnar Hellström: > Hi John, > > Thanks for a good base for discussion. > > See inline, > > Den 2019-08-30 kl. 17:12, skrev Paul Kyzivat: >> John, >> >> On 8/30/19 7:32 AM, John Martin wrote: >>> All, >>> >>>   $0.02 on RTT: >> >> Thanks for joining in! I don't have much knowledge of (and no >> experience using) RTT so I will mostly watch from the sidelines as >> long as others join in. >> >>     Thanks, >>     Paul >> >> (BTW, I don't know how you formatted your message, but in my mail >> reader (Thunderbird) none of your lines wrapped, requiring horizontal >> scrolling to read them.) >> >>> RTT in General >>> >>> -------------- >>> >>> ISTM there are a few options for RTT in RUM, assuming the WebRTC >>> media framework is adopted (as seems likely): >>> >>> 1.Use existing browser support for SCTP as recommended by the some >>> of the WebRTC IETF WG participants. This was discussed as part of >>> the IVC WG and would require and SCTP data channel to be negotiated >>> and to encapsulate the RTP (4103) which then in turn encapsulate >>> T.140 RTT. This solution would require gateways in the VRS provider >>> networks, RTP/RTCP userspace (Javascript) layers in the browser and >>> a T.140 RTT layer/UI also written in userspace in the browser. > > The current work discussed in mmusic  about > draft-holmberg-mmusic-t140-usage-data-channel  specifies T.140 > real-time text transported directly in a "reliable" WebRTC data > channel, identified with subprotocol "t140". Would that not be > suitable for a WebRTC based RUM? The data payload will be the same as > carried in RFC 4103 if used without redundancy. You mention that > embedded RTP with RFC 4103 would be used as data also in the data > channel. That sounds complicated. What would you gain? > > I hope you also follow the discussion in mmusic. > >>> >>> 2.Wait for WebRTC to support lower level data channels. This work is >>> being discussed in the WebRTC community, but might be a case of “not >>> holding our breath”. A lower level data channel would allow RTP/RTCP >>> then T.140 to be negotiated in the SDP without the need for SCTP and >>> associated gateway needs. > Since the RTCWEB WG is closed now in IETF, this sounds as a 7 year > uncertain plan. >>> >>> >>> 3.As a stop-gap and simplification, support SIP MESSAGE as already >>> provided for by the browsers and many endpoints, including WebRTC >>> endpoints. > SCTP data channels are supported as well, and you can just agree to > start using it with a private subprotocol temporarily among RUMs until > there is a standard. So why use SIP MESSAGE? >>> >>> >>> We should not forget that RTCP must be implemented along with RTP. >>> >>> Conferencing and RTT >>> >>> -------------------- >>> >>> RTT in a conference is not currently defined and does not work using >>> currently defined standards (I must admit to being being on mmusic >>> so perhaps there are solutions being recommended there). Discussions >>> on this have been ongoing for nearly 10 years (we didn’t solve it >>> then Gunnar and I think the problems are still the same). For RTT to >>> be useful in a conference there needs to be a few problems solved. > > If you do it with multiple streams sent to the clients, then there are > no problems. Therefore there was hesitation when we discussed to bring > up the topic in IETF. > > For mixing into one stream, there are problems. You can do it with > normal RTP and conferencing specifications but get some limitations. > You can select between a presentation planned by the mixer, or use > CSRC in RTP to indicate the source of primary data in each packet and > let the client plan the presentation. Both work and do not really need > any further standardisation, but would benefit from good best practice > specifications or even a standard for solving some problems. > > Planning and formatting the presentation in the mixer has the > limitation that only the local user and one at a time of the remote > users text can be presented in real-time. Text from the others need to > be buffered until the currently presenting remote participant makes > something so that giving turn to next in queue is suitable. Switching > turn can be made automatically, based on completed phrase or sentence > or message or inactivity or allowed maximum time by the presenting > party. Identification about who is sending which text needs to be > formatted by the mixer and is likely best in form of an IRC style > label when the source is switched. This works for a call where users > are reasonably well-behaved in taking turns. There are cases where the > presentation in one column with sources in labels is not what the user > wants. > > Using just one stream, and mark by CSRC who contributed to primary > data in each packet works as long as no packet was lost. The receiver > can make a better adapted presentation for presentation preferences by > the user. And text can be presented in real-time from more than two > users at the same time. > > But in order to use the redundant RFC 4103 data to recover text in > case of packet loss, then also the redundant data needs to be marked > with source. And for that, a convention is needed and standardised. A > couple of variants are possible with different pros and cons. Losing > so many packets that a missing text marker needs to be inserted also > has its problems that needs a specified solution. > >>> >>> 1.Multi-stream support: Brian, whilst you’re right that most >>> conference systems are point-to-point for signalling they are more >>> typically point-to-multi-point for media. The conference bridge >>> usually handles the multiplexing of the streams, but they are >>> usually now multiple streams. RTT conferencing needs to have the >>> same support. We should assume conferencing is supported by way of >>> SFU not MCU – that’s how WebRTC handles conferencing and we should >>> assume the same for RTT. > Yes, that is now the main path for > draft-holmberg-mmusic-t140-usage-data-channel, and I think that is > good. That is also possible without any further standardization for > RTP based RTT. >>> >>> 2.Participant identification: streams from the conference bridge >>> (MCU/SFU) must be tagged with the sender so the UI can signal to the >>> user who sent that text (and reconstruct the stream correctly). > Yes. Use CSRC / CNAME for RTP and  stream ID / label / session > information for WebRTC data channel. >>> >>> 3.UI adaptions: Modern WebRTC based multi-party conferences have >>> adapted UIs to display multiple video streams. UI’s are adapted to >>> show the video participants however the user wants them to be >>> displayed (single full screen, tiled, voice activated etc). We >>> should expect no less from RTT conference enabled endpoints. It >>> should be a user decision (if their UI supports it) as to whether >>> they see line-by-line or RTT rendering of the text conversation. > Yes. If you want a one column presentation, a reasonable presentation > is to automatically assign one remote party at a time to be presented > in real-time and present the others phrase by phrase, and > automatically switch who is presented in real-time based on suitable > criteria. >>> >>> 4.Control of how many simultaneous participants can text and how >>> that is presented to the user needs to be explored. Multiple >>> insertion points in the UI is one approach (though rapidly breaks >>> down as the number of users increases). Line-by-line is another. >>> Facilitated GA is another (the Go Ahead concept has been used for a >>> long time in text conversations and may be appropriate in large RTT >>> conferences to control overload). >>> >>> And a final FWIW: I think the utility of RTT in a conference quickly >>> breaks down as the number of participants increases. It is >>> completely unacceptable to have a single RTT stream presented to the >>> user and an unmodified UI. You might as well revert to SIP MESSAGE >>> and something like XMPP, and that could also be an option for either >>> the short term or for endpoints that do not support multi-stream RTT. > > In some conferences it might be desirable with one dominating RTT > source: a written interpretation of what is said, and then > occasionally another participant gets the floor and types something . > It is very valuable if that mode of conferencing is available without > hazzle in general multi-party conference systems. The utility does not > break down in that situation. > > It seems to me that aiming at multi-stream RTT support is to prefer. > > > Regards > > Gunnar > >>> >>> John >>> >>> Brian said: we agreed we were using 4103 in RUM. >>> >>> Good toknow. But is there not a hope to be able to even use browser >>> >>> technology for the implementation. The browsers only support RTP for >>> >>> audio and video. Can you make RTP-based RTT work in that environment >>> and >>> >>> encrypted with the security method specified for WebRTC? >>> >>> See a bit more below: >>> >>> Den 2019-08-29 kl. 21:59, skrev Malloy, Jim: >>> >>>> “line at a time” is a user interface issue – RUM is defining a machine >>> >>>> interface.  How it’s presented to the user is out of scope. >>> >>>> >>> >>> Well, the control and coding must be made so that it is possible to >>> make >>> >>> a good presentation. Transmission only line-by-line would not suit the >>> >>> intention of RTT. It is hard to make a good RTT presentation with a >>> >>> client that is only expecting text from one other participant and a >>> >>> mixer that has the task to send text from many sources combined in one >>> >>> stream. The best result is usable but not nice. And it will be aimed at >>> >>> just one way to present RTT. No freedom to plan the presentation >>> >>> according to user preferences. >>> >>> A receiver may, if there is a desire for such functionality, store >>> >>> received text until a received message is complete. I do not think that >>> >>> it is to prefer in any situation. >>> >>> Regards >>> >>> Gunnar >>> >>>> --Jim >>> >>>> >>> >>>> *From:* Rum >>>> ; *On Behalf Of * >>> Brian Rosen >>> >>>> *Sent:* Thursday, August 29, 2019 1:15 PM >>> >>>> *To:* Kyzivat, Paul >>>> ; >>> >>>> *Cc:* rum@ietf.org >>> >>>> *Subject:* [EXT] Re: [Rum] Real-time text in WebRTC is discussed in >>> >>>> mmusic - a topic closely telated to rum >>> >>>> >>> >>>> “Line at a time” could be an implementation option.  The protocol >>> >>>> mechanism is all streams head to a mixer and the mixer sends a single >>> >>>> stream to each participant. >>> >>>> >>> >>>> Gunnar, we agreed we were using 4103 in RUM. >>> >>>> >>> >>>> Brian >>> >>>> >>> >>>> >>> >>>> >>> >>>>      On Aug 29, 2019, at 12:05 PM, Paul Kyzivat >>>> >>> >>>>  > wrote: >>> >>>> >>> >>>>      I question how well RTT text is suited to multiparty conferences. >>> >>>> >>> >>>>      If you have messages on your screen from multiple parties, and >>> >>>>      many of them are updating in real-time, are you going to be able >>> >>>>      to perceive what is going on? >>> >>>> >>> >>>>      And while you can have a column per person for two-party and >>>> maybe >>> >>>>      3-party conversations, that doesn't scale up. With many parties, >>> >>>>      some typing may scroll off the screen before it is complete. >>> >>>> >>> >>>>      Perhaps for conferences it is better to just use line-at-a-time >>> >>>>      chat. If necessary, I presume there could be gateways between RTT >>> >>>>      and chat. A RUE could have the capability to negotiate down from >>> >>>>      RTT to chat. >>> >>>> >>> >>>>      Thanks, >>> >>>>      Paul >>> >>>> >>> >>>>      On 8/28/19 2:15 AM, Gunnar Hellström wrote: >>> >>>> >>> >>>>          Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>> >>>> >>> >>>>              At least by centralizing the problem at a “mixer”, Alice >>> >>>>              and Bob will see the same thing. >>> >>>> >>> >>>>              You don’t have the problem in Instant Messaging, because >>> >>>>              you can’t backspace or delete a sent message.  Of course >>> >>>>              if multiple people are typing simultaneously in such >>> >>>>              systems, message order will be confusing in that instant. >>> >>>> >>> >>>>          Right, it is a similar kind of problem that text appears >>>> in an >>> >>>>          unexpected order. There is also at least one instant >>>> messaging >>> >>>>          service that allows modification in already sent message. But >>> >>>>          I think it has limitations to only accept that in the last >>> >>>>          message sent. it is convenient anyway. >>> >>>> >>> >>>> >>> >>>>              Anyway, we need to specify the mixer for RTT so it >>> >>>>              receives each of the RTT streams and produces a single >>> >>>>              composite stream for each participant. >>> >>>> >>> >>>>          Yes, right, and there is an effort in that direction in: >>> >>>> http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf >>>> >>> >>>>          It is written for conference-unaware user devices. >>> >>>>          The goals are specified as follows: >>> >>>>          The procedures are intended to make best efforts to present a >>> >>>>          multi-party text conversation on a terminal that has no >>> >>>>          awareness of multi-party calls. There are some obvious >>> >>>>          drawbacks, and a terminal designed with multi-party awareness >>> >>>>          will be able to present multi-party call contents in a more >>> >>>>          flexible way. Only two parties at a time will be allowed to >>> >>>>          display added text in real-time, while the other parties’ >>> >>>>          produced text will need to be stored in the multi-party >>>> server >>> >>>>          for a moment awaiting a suitable occasion to be displayed. >>> >>>>          There are also some cases of erasure that will not be >>> >>>>          performed on the target text but only indicated in another >>> >>>>          way. Even with these drawbacks, the procedure provides an >>> >>>>          opportunity to display text from more than two parties in a >>> >>>>          smooth and readable way. >>> >>>> --------------------------------------------------------------------------------------------------- >>>> >>> >>>>          I see such mixer procedures as a fall-back for cases without >>> >>>>          conference awareness, but want to see support for >>> >>>>          conference-aware terminals, where text from more than two >>> >>>>          parties can be presented in real-time, and the end user or >>>> app >>> >>>>          can have influence over the presentation style - e.g. select >>> >>>>          between the multiple column view and the >>> >>>>          one-column-with-labels view. A mixer for that case would only >>> >>>>          need to assure that the receiver has the right kind of >>> >>>>          multi-party awareness and send RTT text with source >>> >>>>          information attached, and let the receiving terminal sort out >>> >>>>          the presentation. This is already possible with CSRC and >>>> CNAME >>> >>>>          when using RTP, but we lose that possibility natively when >>> >>>>          using the WebRTC data channel to transport RTT, and would >>>> need >>> >>>>          to specify a way to include the source also for that case. >>> >>>> ------------------------------------------------------ >>> >>>>          By the way, what is your current view of how to transport RTT >>> >>>>          for RUM, now when you say that you will use WebRTC transports >>> >>>>          for media? >>> >>>>          Regards >>> >>>>          Gunnar >>> >>>> >>> >>>> >>> >>>> >>> >>>>                  On Aug 27, 2019, at 4:43 PM, Gunnar Hellström >>> >>>> >>> >>>> > >>>> >>> >>>>                  wrote: >>> >>>> >>> >>>>                  Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>> >>>> >>> >>>>                      The problem of conference 4103 RTT is high on my >>> >>>>                      list of work I need to get done.  So, I’m >>> >>>>                      motivated to help out. >>> >>>> >>> >>>>                  Thanks, great. >>> >>>> >>> >>>>                      The basic problem is that we’re going to get very >>> >>>>                      inconsistent UI doing it that way, because of how >>> >>>>                      systems will handle backspace of one party that >>> >>>>                      extends beyond responses from other parties: >>> >>>> >>> >>>>                  (well, for me the currently most basic problem is to >>> >>>>                  have a reliable way to append received text to the >>> >>>>                  already presented text of the right participant. And >>> >>>>                  that is getting worse in WebRTC than it was in RFC >>> >>>>                  4103. But we will sort it out.) >>> >>>> >>> >>>> >>> >>>>                      Alice: I waited for you >>> >>>>                      Bob: I didn’t see you >>> >>>>                      Alice: sorry >>> >>>> >>> >>>>                      And then Alice types 12 backspaces. >>> >>>> >>> >>>>                      What should happen? >>> >>>> >>> >>>> >>> >>>>                  You are right that there are a number of ways to >>> >>>>                  handle the RTT UI. And just as inconsistencies are >>> >>>>                  common with a message oriented UI, where messages >>>> show >>> >>>>                  up in a confusing order because two users completed >>> >>>>                  messages in an unexpected time order, it is possible >>> >>>>                  that RTT text gets displayed in a strange order after >>> >>>>                  erasure and retyping. It is better for RTT than for >>> >>>>                  message oriented presentation, and user get used >>>> to it >>> >>>>                  in both cases.  With the labelled style in one column >>> >>>>                  you have in the example, I would recommend that first >>> >>>>                  5 backspaces erase "sorry", next backspace erases the >>> >>>>                  line separator, and pulls down "I waited for you" to >>> >>>>                  be shown last, as an uncompleted text. Then the >>>> next 6 >>> >>>>                  backspaces erase so that only "I waited f" is >>> >>>>                  displayed. When Alice adds text and end with a new >>> >>>>                  line, the corrected sentence is allowed to flow up >>> >>>>                  when new text is added from any participant.  That >>> >>>>                  causes a bit strange order, but it is just as >>> >>>>                  manageable as when text in messaging applications >>> >>>>                  appear in an unexpected order so that one message >>> >>>>                  seems to be a respone on something totally else than >>> >>>>                  what was intended. >>> >>>> >>> >>>>                  A sophisticated UI may mark text that is moved and >>> >>>>                  modified. >>> >>>> >>> >>>>                  We want to keep sentences or at least phrases from >>> >>>>                  each participant together in a readable unit. Already >>> >>>>                  that causes a design decision on where to place the >>> >>>>                  completed chunk of text once the user has completed >>> >>>>                  it. The start of the chunk may be older than >>>> completed >>> >>>>                  text from other participants which would motivate to >>> >>>>                  move it up a bit in the presentation. But the end of >>> >>>>                  it is at that moment the latest text to present. I >>> >>>>                  think it is best to let the finished text be >>>> presented >>> >>>>                  last on the display, but let others' newer text push >>> >>>>                  everything up and be displayed last. >>> >>>> >>> >>>> >>> >>>>                 T.140 has information on how to handle erasure: >>> >>>> >>> >>>> -------------------From T.140--------------------------- >>> >>>> >>> >>>>                  8.2 Erase last character >>> >>>>                  Purpose: Erase the last character sent from the >>> >>>>                  display at the receiving end. >>> >>>>                  Code: BS: 0008. >>> >>>>                  Procedure: On the receiving end: Move the insertion >>> >>>>                  point to the last character and erase it. >>> >>>>                  Combined characters are erased as a unit, with one BS >>> >>>>                  erasing the whole character even if it is >>> >>>>                  combined from more than one component. >>> >>>>                  Control sequences (like CR LF) are erased in one >>> >>>>                  operation. >>> >>>>                  NOTE – The same action shall be taken on the local >>> >>>>                  display. >>> >>>> >>> >>>> ------------------------------------------------------------ >>> >>>> >>> >>>>                    /Gunnar >>> >>>> >>> >>>> >>> >>>> >>> >>>>                      Brian >>> >>>> >>> >>>> >>> >>>>                          On Aug 27, 2019, at 9:52 AM, Gunnar Hellström >>> >>>> >>> >>>> > >>>> >>> >>>>                          wrote: >>> >>>> >>> >>>>                          Hi, >>> >>>> >>> >>>>                          A topic is currently discussed in mmusic that >>> >>>>                          is closely related to rum. it is WebRTC >>> >>>>                          transport of real-time text. >>> >>>> >>> >>>>                          The draft is >>> >>>> draft-holmberg-mmusic-t140-usage-data-channel . >>> >>>> >>> >>>>                          A good point to start reading could be: >>> >>>> >>> >>>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel >>>> >>> >>>> >>> >>>>                          Please check if the current state of the >>> >>>>                          discussion suits rum! >>> >>>> >>> >>>>                          The only issue that seems to be remaining is >>> >>>>                          how to transport RTT data to and from a >>> >>>>                          conference server that combines all traffic >>> >>>>                          per media in a meeting in one data stream. >>> >>>>                          That is not very elegantly specified for RFC >>> >>>>                          4103 transport of RTT in RTP either, so we >>> >>>>                          might want to do a rapid action together to >>> >>>>                          solve the multi-party RTT MCU case in a >>> >>>>                          general and consistent way. >>> >>>> >>> >>>>                          Regards >>> >>>> >>> >>>>                          Gunnar >>> >>>> >>> >>>>                          -- >>> >>>> ----------------------------------------- >>> >>>>                          Gunnar Hellström >>> >>>>                          Omnitor >>> >>>> gunnar.hellstrom@omnitor.se >>> >>>> >>> >>>>                          +46 708 204 288 >>> >>>> >>> >>>>                  -- >>> >>>> ----------------------------------------- >>> >>>>                  Gunnar Hellström >>> >>>>                  Omnitor >>> >>>> gunnar.hellstrom@omnitor.se >>> >>>> >>>> >>> >>>>                  +46 708 204 288 >>> >>>> >>> >>>>          -- >>> >>>> ----------------------------------------- >>> >>>>          Gunnar Hellström >>> >>>>          Omnitor >>> >>>>         gunnar.hellstrom@omnitor.se >>>> >>> >>> >>>>          +46 708 204 288 >>> >>>> >>> >>>> >>> >>>>      -- >>> >>>>      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 >>> >>>   * [Rum] Real-time text in WebRTC is discussed in ... >>>   Gunnar >>> >>>     Hellström >>>   * Re: [Rum] Real-time text in WebRTC is discussed... >>>   Brian >>> >>>     Rosen >>>   * Re: [Rum] Real-time text in WebRTC is discussed... >>>   Gunnar >>> >>>     Hellström >>>   * Re: [Rum] Real-time text in WebRTC is discussed... >>>   Brian >>> >>>     Rosen >>>   * Re: [Rum] Real-time text in WebRTC is discussed... >>>   Gunnar >>> >>>     Hellström >>>   * Re: [Rum] Real-time text in WebRTC is discussed... >>>   Paul >>> >>>     Kyzivat >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Malloy, >>> >>>     Jim >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Paul >>> >>>     Kyzivat >>>   * Re: [Rum] Real-time text in WebRTC is discussed... >>>   Brian >>> >>>     Rosen >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Brian >>> >>>     Rosen >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Paul >>> >>>     Kyzivat >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Brian >>> >>>     Rosen >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Paul >>> >>>     Kyzivat >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Brian >>> >>>     Rosen >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Malloy, >>> >>>     Jim >>>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>   Gunnar >>> >>>     Hellström >>> >>> -- >>> >>> *John Martin* >>> >>> Email: John.Martin@Purple.us >>> >>> >> -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Sep 2 01:40:05 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 EEB6012011F for ; Mon, 2 Sep 2019 01:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fBkTzF1e3iIU for ; Mon, 2 Sep 2019 01:40:01 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (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 1EDFA12011C for ; Mon, 2 Sep 2019 01:40:00 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx7.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 02 Sep 2019 08:39:57 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 2 Sep 2019 01:39:40 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Mon, 2 Sep 2019 01:39:40 -0700 From: James Hamlin To: "rum@ietf.org" Thread-Topic: [Rum] Codec requirements in draft-rosen-rue-01 Thread-Index: AQHVUV6wjLP/Oy7TOEegGP/2NVsbUqcP75GAgAAn6QCAARFKAIAABkIAgAANRQCAAAZWAIAG7fPM Date: Mon, 2 Sep 2019 08:39:40 +0000 Message-ID: <1567413580412.20641@purple.us> 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> In-Reply-To: <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1567413581-893012-26597-262742-1 X-BESS-VER: 2019.1_20190823.2224 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.217969 [from cloudscan21-174.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Mon, 02 Sep 2019 08:40:04 -0000 =0A= 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.=0A= =0A= I believe the FCC order related to compensation by compliant providers not = that every call had to come from a compliant endpoint.=0A= =0A= Best Regards=0A= =0A= James=0A= =0A= ________________________________________=0A= From: Rum on behalf of Paul Kyzivat =0A= Sent: 28 August 2019 16:48=0A= To: rum@ietf.org=0A= Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01=0A= =0A= On 8/28/19 11:25 AM, Eric Burger wrote:=0A= > I guess the question is whether we want today=92s devices to have a chanc= e of being RUM compatible. I don=92t think anyone will be surprised if a fi= ve-year-old device is history. Is it realistic for current devices to get V= P8 upgrade? [Would be nice for some manufacturers or others building such d= evices to pipe in here.]=0A= =0A= Lets be clear about what we mean by "RUM compatible".=0A= =0A= When Henning and I were working on this with the providers in 2014 and=0A= 2015 there was an expectation that the providers would be required to=0A= support the defined RUE devices, but they would also be permitted to=0A= support their existing proprietary devices. The RUE devices could have=0A= requirements that their existing devices don't meet. But calls between=0A= the two were expected to work.=0A= =0A= There was great consternation when subsequently the FCC issued a=0A= proposed order that said only VRS calls involving RUE-compatible devices=0A= would be compensated. (But that was in 2015. I presume it has not happened.= )=0A= =0A= If there is an intent to exclude non-RUM-compliant devices from use in=0A= VRS calls then there needs to be a migration plan to get from here to there= .=0A= =0A= Thanks,=0A= Paul=0A= =0A= >> On Aug 28, 2019, at 10:38 AM, Brian Rosen wrote:=0A= >>=0A= >> 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=92t that what we want?=0A= >>=0A= >> Brian=0A= >>=0A= >>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat wrot= e:=0A= >>>=0A= >>> Inline...=0A= >>>=0A= >>> On 8/27/19 5:57 PM, Adam Roach wrote:=0A= >>>> 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 7= 742's "Non-Browser" requirements for the video codec MTI. Rationale below.= =0A= >>>> From an interop perspective, the important thing is that any given pr= ofile 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 endpoin= ts can talk to/be implemented in web browsers without the need for media tr= anscoding.=0A= >>>> For audio: WebRTC selected G.711 and Opus as both MTI; the former beca= use it works without transcoding to landline PSTN destinations, and the lat= ter 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 depl= oy into audio/video environments, backwards compatibility with the PSTN see= ms to be unnecessary baggage.=0A= >>>=0A= >>> Please keep in mind where we are coming from. The RUM will be a new int= erface 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.=0A= >>>=0A= >>> Making OPUS the only MTI audio codec would be problematic.=0A= >>>=0A= >>>> For video: While specifying either VP8 or H.264 would be sufficient fo= r system interop, and for interop with compliant WebRTC endpoints, I'd real= ly prefer not to re-live the WebRTC video codec wars. Concretely, what I wo= uld propose is that RUM indicate that the video codec requirements are defi= ned 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 req= uirements as WebRTC Non-Browsers.=0A= >>>=0A= >>> Continuing my comment above, existing devices have H.264 Constrained Ba= seline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are = many of these devices aren't capable of VP8.=0A= >>>=0A= >>> 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 t= he providers to transcode is a practical way forward. I'm dubious.=0A= >>>=0A= >>> Thanks,=0A= >>> Paul=0A= >>>=0A= >>>> /a=0A= >>>> On 8/27/19 2:34 PM, Brian Rosen wrote:=0A= >>>>> Well, we certainly want interoperability, and I think we can only get= that with MTI codecs.=0A= >>>>>=0A= >>>>> I think we really are talking about a WebRTC-compatible endpoint, but= we want interoperability with a WebRTC browser endpoint.=0A= >>>>>=0A= >>>>> Not sure how to say this. Maybe Adam can help.=0A= >>>>>=0A= >>>>> Brian=0A= >>>>>=0A= >>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat wr= ote:=0A= >>>>>>=0A= >>>>>> draft-rosen-rue-01 changes the video codec requirements. It now simp= ly references webrtc RFC7742.=0A= >>>>>>=0A= >>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", "W= ebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that= each end is one of these.=0A= >>>>>>=0A= >>>>>> Is the expectation here that both the RUE and the provider comply wi= th one of these? In particular, that the provider may simply be a "WebRTC-c= ompatible endpoint? Notably:=0A= >>>>>>=0A= >>>>>> "WebRTC-compatible endpoints" are free to implement any video cod= ecs=0A= >>>>>> they see fit. This follows logically from the definition of "Web= RTC-=0A= >>>>>> compatible endpoint". It is, of course, advisable to implement a= t=0A= >>>>>> least one of the video codecs that is mandated for WebRTC browser= s,=0A= >>>>>> and implementors are encouraged to do so.=0A= >>>>>>=0A= >>>>>> Similarly, the audio requirements have been changed to reference web= rtc RFC7874. That one doesn't have the distinction between "WebRTC browser"= , "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the sa= me requirements to all. In particular, it requires OPUS support. I don't kn= ow why it doesn't make the same endpoint distinctions as for video.=0A= >>>>>>=0A= >>>>>> I think simply referencing these documents isn't sufficient. Seems l= ike we need a more nuanced specification of what is required, though we may= still reference these docs with qualifications.=0A= >>>>>>=0A= >>>>>> Thanks,=0A= >>>>>> Paul=0A= >>>>>>=0A= >>>>>>=0A= >>>=0A= >>=0A= >> --=0A= >> Rum mailing list=0A= >> Rum@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rum=0A= >=0A= >=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rum=0A= From nobody Mon Sep 2 07:30:06 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 EDCA7120110 for ; Mon, 2 Sep 2019 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 9-sLSDjZqup6 for ; Mon, 2 Sep 2019 07:29:59 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 E3AA1120019 for ; Mon, 2 Sep 2019 07:29:58 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id o12so4212218qtf.3 for ; Mon, 02 Sep 2019 07:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GpEJ4mtLt8hf1V15c32+iMCDyB4ZzFBJ3PlD9aFZano=; b=VsGDX9lbgGBAdnhXz/SPZb18AhHMeBo1AfgUMGCEFWC9Q1XQpiIHc4tu1e4GhCgulg iDdQcTNaJMxYts4J1t7aGrb7QgYD2+asJ59pEDnLNWCTtPAima3QxZaZuleOTV1FXXZB bgK+EodglzFzX8sKrz52FlM6cdKOTEALwjGA9Z1yWJ1qVes2uxVdlN4v/H6OUCXN2Kqj MVoHOnU/e14fz4in0+IEIsU9XUpkDokpvjbb5aEjnnk+8G52X322lw45ydSwRi/80084 /cxHw/EfMysZrNPub5Xx8XqOD2uKvvM2PGg8WiCykHEl+iNZYrQHTGOrfdvYz0Kas4bQ xbbw== 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=GpEJ4mtLt8hf1V15c32+iMCDyB4ZzFBJ3PlD9aFZano=; b=grzMju5Ra5oBQl+lSMgtgcd6vlorrJBu0Toc39l5jihjuGJqZ4oRCLDI0BDIMLrJJ3 qWYwz1wLq9qQtNkZdT57xpa/mjP1Zv0Ox4q1TTYXtAhM4gWINTbow56lDtG9Pfr+Fg89 hurNLHV1DVKDddmt1zZ7/qJPc7uLb9znfwoehxkmQf/IPQ9rbIdLUbFyh/P8TlYoBLNL d/NUJgYetfTRS6G8D5h+2neROr5+Xpnx6s7+xa8MAblwxEy8IMtV6TxABBIu+NlkWmdD 1a2DNqN13hjHmUlL4pG+PjJylN9DB1Xxu9xXquMfQfq/lCGzDI3Wjkwzexf4KiK1qcW3 gKig== X-Gm-Message-State: APjAAAVkNy1IeLa2iG5ONazumAtB71ug3QyKImSivyi+XZpuYKCGECOv RrTNkreXrJX4T/rLV4VHvDTl620NGeU= X-Google-Smtp-Source: APXvYqzxsoDCjI2er3NaW1IHkiClLxkxDtqEJuplmnRlzVmtA7ggiRRVh11n+JYASw9K5QCBYzJE/w== X-Received: by 2002:a0c:94a4:: with SMTP id j33mr18655894qvj.135.1567434597440; Mon, 02 Sep 2019 07:29:57 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id o47sm1779242qto.67.2019.09.02.07.29.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Sep 2019 07:29:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Mon, 2 Sep 2019 10:29:55 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <647F8D24-5F21-4D98-83FD-DAAACBC04725@brianrosen.net> References: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> <5142d3b2-da81-25f0-8859-694cd6126f0b@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - is recvonly etc support desired? 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: Mon, 02 Sep 2019 14:30:03 -0000 I think it=E2=80=99s of marginal utility. The reason you need muting = for audio is that you can=E2=80=99t process multiple simultaneous = speakers. In RTT, it=E2=80=99s a lot easier. It makes more sense in = conference control (not from the endpoint, controlling what the mixer = does, a la xcon). OTOH, it ought to be the same as audio and video. Brian > On Sep 1, 2019, at 5:26 PM, Gunnar Hellstr=C3=B6m = wrote: >=20 > I would like a comment from RUM if it is desirable to have support for = the direction attributes : sendrecv, sendonly, recvonly, inactive, for = RTT streams? >=20 > It might be for control of muting etc in multi-party situations, but = of course also in other situations. >=20 > Regards >=20 > Gunnar >=20 > Den 2019-08-31 kl. 22:47, skrev Gunnar Hellstr=C3=B6m: >> Hi John, >>=20 >> Thanks for a good base for discussion. >>=20 >> See inline, >>=20 >> Den 2019-08-30 kl. 17:12, skrev Paul Kyzivat: >>> John, >>>=20 >>> On 8/30/19 7:32 AM, John Martin wrote: >>>> All, >>>>=20 >>>> $0.02 on RTT: >>>=20 >>> Thanks for joining in! I don't have much knowledge of (and no = experience using) RTT so I will mostly watch from the sidelines as long = as others join in. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> (BTW, I don't know how you formatted your message, but in my mail = reader (Thunderbird) none of your lines wrapped, requiring horizontal = scrolling to read them.) >>>=20 >>>> RTT in General >>>>=20 >>>> -------------- >>>>=20 >>>> ISTM there are a few options for RTT in RUM, assuming the WebRTC = media framework is adopted (as seems likely): >>>>=20 >>>> 1.Use existing browser support for SCTP as recommended by the some = of the WebRTC IETF WG participants. This was discussed as part of the = IVC WG and would require and SCTP data channel to be negotiated and to = encapsulate the RTP (4103) which then in turn encapsulate T.140 RTT. = This solution would require gateways in the VRS provider networks, = RTP/RTCP userspace (Javascript) layers in the browser and a T.140 RTT = layer/UI also written in userspace in the browser. >>=20 >> The current work discussed in mmusic about = draft-holmberg-mmusic-t140-usage-data-channel specifies T.140 real-time = text transported directly in a "reliable" WebRTC data channel, = identified with subprotocol "t140". Would that not be suitable for a = WebRTC based RUM? The data payload will be the same as carried in RFC = 4103 if used without redundancy. You mention that embedded RTP with RFC = 4103 would be used as data also in the data channel. That sounds = complicated. What would you gain? >>=20 >> I hope you also follow the discussion in mmusic. >>=20 >>>>=20 >>>> 2.Wait for WebRTC to support lower level data channels. This work = is being discussed in the WebRTC community, but might be a case of = =E2=80=9Cnot holding our breath=E2=80=9D. A lower level data channel = would allow RTP/RTCP then T.140 to be negotiated in the SDP without the = need for SCTP and associated gateway needs. >> Since the RTCWEB WG is closed now in IETF, this sounds as a 7 year = uncertain plan. >>>>=20 >>>>=20 >>>> 3.As a stop-gap and simplification, support SIP MESSAGE as already = provided for by the browsers and many endpoints, including WebRTC = endpoints. >> SCTP data channels are supported as well, and you can just agree to = start using it with a private subprotocol temporarily among RUMs until = there is a standard. So why use SIP MESSAGE? >>>>=20 >>>>=20 >>>> We should not forget that RTCP must be implemented along with RTP. >>>>=20 >>>> Conferencing and RTT >>>>=20 >>>> -------------------- >>>>=20 >>>> RTT in a conference is not currently defined and does not work = using currently defined standards (I must admit to being being on mmusic = so perhaps there are solutions being recommended there). Discussions on = this have been ongoing for nearly 10 years (we didn=E2=80=99t solve it = then Gunnar and I think the problems are still the same). For RTT to be = useful in a conference there needs to be a few problems solved. >>=20 >> If you do it with multiple streams sent to the clients, then there = are no problems. Therefore there was hesitation when we discussed to = bring up the topic in IETF. >>=20 >> For mixing into one stream, there are problems. You can do it with = normal RTP and conferencing specifications but get some limitations. You = can select between a presentation planned by the mixer, or use CSRC in = RTP to indicate the source of primary data in each packet and let the = client plan the presentation. Both work and do not really need any = further standardisation, but would benefit from good best practice = specifications or even a standard for solving some problems. >>=20 >> Planning and formatting the presentation in the mixer has the = limitation that only the local user and one at a time of the remote = users text can be presented in real-time. Text from the others need to = be buffered until the currently presenting remote participant makes = something so that giving turn to next in queue is suitable. Switching = turn can be made automatically, based on completed phrase or sentence or = message or inactivity or allowed maximum time by the presenting party. = Identification about who is sending which text needs to be formatted by = the mixer and is likely best in form of an IRC style label when the = source is switched. This works for a call where users are reasonably = well-behaved in taking turns. There are cases where the presentation in = one column with sources in labels is not what the user wants. >>=20 >> Using just one stream, and mark by CSRC who contributed to primary = data in each packet works as long as no packet was lost. The receiver = can make a better adapted presentation for presentation preferences by = the user. And text can be presented in real-time from more than two = users at the same time. >>=20 >> But in order to use the redundant RFC 4103 data to recover text in = case of packet loss, then also the redundant data needs to be marked = with source. And for that, a convention is needed and standardised. A = couple of variants are possible with different pros and cons. Losing so = many packets that a missing text marker needs to be inserted also has = its problems that needs a specified solution. >>=20 >>>>=20 >>>> 1.Multi-stream support: Brian, whilst you=E2=80=99re right that = most conference systems are point-to-point for signalling they are more = typically point-to-multi-point for media. The conference bridge usually = handles the multiplexing of the streams, but they are usually now = multiple streams. RTT conferencing needs to have the same support. We = should assume conferencing is supported by way of SFU not MCU =E2=80=93 = that=E2=80=99s how WebRTC handles conferencing and we should assume the = same for RTT. >> Yes, that is now the main path for = draft-holmberg-mmusic-t140-usage-data-channel, and I think that is good. = That is also possible without any further standardization for RTP based = RTT. >>>>=20 >>>> 2.Participant identification: streams from the conference bridge = (MCU/SFU) must be tagged with the sender so the UI can signal to the = user who sent that text (and reconstruct the stream correctly). >> Yes. Use CSRC / CNAME for RTP and stream ID / label / session = information for WebRTC data channel. >>>>=20 >>>> 3.UI adaptions: Modern WebRTC based multi-party conferences have = adapted UIs to display multiple video streams. UI=E2=80=99s are adapted = to show the video participants however the user wants them to be = displayed (single full screen, tiled, voice activated etc). We should = expect no less from RTT conference enabled endpoints. It should be a = user decision (if their UI supports it) as to whether they see = line-by-line or RTT rendering of the text conversation. >> Yes. If you want a one column presentation, a reasonable presentation = is to automatically assign one remote party at a time to be presented in = real-time and present the others phrase by phrase, and automatically = switch who is presented in real-time based on suitable criteria. >>>>=20 >>>> 4.Control of how many simultaneous participants can text and how = that is presented to the user needs to be explored. Multiple insertion = points in the UI is one approach (though rapidly breaks down as the = number of users increases). Line-by-line is another. Facilitated GA is = another (the Go Ahead concept has been used for a long time in text = conversations and may be appropriate in large RTT conferences to control = overload). >>>>=20 >>>> And a final FWIW: I think the utility of RTT in a conference = quickly breaks down as the number of participants increases. It is = completely unacceptable to have a single RTT stream presented to the = user and an unmodified UI. You might as well revert to SIP MESSAGE and = something like XMPP, and that could also be an option for either the = short term or for endpoints that do not support multi-stream RTT. >>=20 >> In some conferences it might be desirable with one dominating RTT = source: a written interpretation of what is said, and then occasionally = another participant gets the floor and types something . It is very = valuable if that mode of conferencing is available without hazzle in = general multi-party conference systems. The utility does not break down = in that situation. >>=20 >> It seems to me that aiming at multi-stream RTT support is to prefer. >>=20 >>=20 >> Regards >>=20 >> Gunnar >>=20 >>>>=20 >>>> John >>>>=20 >>>> Brian said: we agreed we were using 4103 in RUM. >>>>=20 >>>> Good toknow. But is there not a hope to be able to even use browser >>>>=20 >>>> technology for the implementation. The browsers only support RTP = for >>>>=20 >>>> audio and video. Can you make RTP-based RTT work in that = environment and >>>>=20 >>>> encrypted with the security method specified for WebRTC? >>>>=20 >>>> See a bit more below: >>>>=20 >>>> Den 2019-08-29 kl. 21:59, skrev Malloy, Jim: >>>>=20 >>>>> =E2=80=9Cline at a time=E2=80=9D is a user interface issue =E2=80=93= RUM is defining a machine=20 >>>>=20 >>>>> interface. How it=E2=80=99s presented to the user is out of = scope. >>>>=20 >>>>>=20 >>>>=20 >>>> Well, the control and coding must be made so that it is possible to = make >>>>=20 >>>> a good presentation. Transmission only line-by-line would not suit = the >>>>=20 >>>> intention of RTT. It is hard to make a good RTT presentation with a >>>>=20 >>>> client that is only expecting text from one other participant and a >>>>=20 >>>> mixer that has the task to send text from many sources combined in = one >>>>=20 >>>> stream. The best result is usable but not nice. And it will be = aimed at >>>>=20 >>>> just one way to present RTT. No freedom to plan the presentation >>>>=20 >>>> according to user preferences. >>>>=20 >>>> A receiver may, if there is a desire for such functionality, store >>>>=20 >>>> received text until a received message is complete. I do not think = that >>>>=20 >>>> it is to prefer in any situation. >>>>=20 >>>> Regards >>>>=20 >>>> Gunnar >>>>=20 >>>>> --Jim >>>>=20 >>>>>=20 >>>>=20 >>>>> *From:* Rum = ; *On Behalf Of *=20 >>>> Brian Rosen >>>>=20 >>>>> *Sent:* Thursday, August 29, 2019 1:15 PM >>>>=20 >>>>> *To:* Kyzivat, Paul = ; >>>>=20 >>>>> *Cc:* rum@ietf.org >>>>=20 >>>>> *Subject:* [EXT] Re: [Rum] Real-time text in WebRTC is discussed = in=20 >>>>=20 >>>>> mmusic - a topic closely telated to rum >>>>=20 >>>>>=20 >>>>=20 >>>>> =E2=80=9CLine at a time=E2=80=9D could be an implementation = option. The protocol=20 >>>>=20 >>>>> mechanism is all streams head to a mixer and the mixer sends a = single=20 >>>>=20 >>>>> stream to each participant. >>>>=20 >>>>>=20 >>>>=20 >>>>> Gunnar, we agreed we were using 4103 in RUM. >>>>=20 >>>>>=20 >>>>=20 >>>>> Brian >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> On Aug 29, 2019, at 12:05 PM, Paul Kyzivat = >>>>=20 >>>>> > wrote: >>>>=20 >>>>>=20 >>>>=20 >>>>> I question how well RTT text is suited to multiparty = conferences. >>>>=20 >>>>>=20 >>>>=20 >>>>> If you have messages on your screen from multiple parties, = and >>>>=20 >>>>> many of them are updating in real-time, are you going to be = able >>>>=20 >>>>> to perceive what is going on? >>>>=20 >>>>>=20 >>>>=20 >>>>> And while you can have a column per person for two-party and = maybe >>>>=20 >>>>> 3-party conversations, that doesn't scale up. With many = parties, >>>>=20 >>>>> some typing may scroll off the screen before it is complete. >>>>=20 >>>>>=20 >>>>=20 >>>>> Perhaps for conferences it is better to just use = line-at-a-time >>>>=20 >>>>> chat. If necessary, I presume there could be gateways between = RTT >>>>=20 >>>>> and chat. A RUE could have the capability to negotiate down = from >>>>=20 >>>>> RTT to chat. >>>>=20 >>>>>=20 >>>>=20 >>>>> Thanks, >>>>=20 >>>>> Paul >>>>=20 >>>>>=20 >>>>=20 >>>>> On 8/28/19 2:15 AM, Gunnar Hellstr=C3=B6m wrote: >>>>=20 >>>>>=20 >>>>=20 >>>>> Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>>>=20 >>>>>=20 >>>>=20 >>>>> At least by centralizing the problem at a = =E2=80=9Cmixer=E2=80=9D, Alice >>>>=20 >>>>> and Bob will see the same thing. >>>>=20 >>>>>=20 >>>>=20 >>>>> You don=E2=80=99t have the problem in Instant = Messaging, because >>>>=20 >>>>> you can=E2=80=99t backspace or delete a sent message. = Of course >>>>=20 >>>>> if multiple people are typing simultaneously in such >>>>=20 >>>>> systems, message order will be confusing in that = instant. >>>>=20 >>>>>=20 >>>>=20 >>>>> Right, it is a similar kind of problem that text appears = in an >>>>=20 >>>>> unexpected order. There is also at least one instant = messaging >>>>=20 >>>>> service that allows modification in already sent message. = But >>>>=20 >>>>> I think it has limitations to only accept that in the = last >>>>=20 >>>>> message sent. it is convenient anyway. >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> Anyway, we need to specify the mixer for RTT so it >>>>=20 >>>>> receives each of the RTT streams and produces a = single >>>>=20 >>>>> composite stream for each participant. >>>>=20 >>>>>=20 >>>>=20 >>>>> Yes, right, and there is an effort in that direction in: >>>>=20 >>>>> = http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specif= ications/multiparty-real-time-text-mixer-2011-04-30.pdf=20 >>>>=20 >>>>> It is written for conference-unaware user devices. >>>>=20 >>>>> The goals are specified as follows: >>>>=20 >>>>> The procedures are intended to make best efforts to = present a >>>>=20 >>>>> multi-party text conversation on a terminal that has no >>>>=20 >>>>> awareness of multi-party calls. There are some obvious >>>>=20 >>>>> drawbacks, and a terminal designed with multi-party = awareness >>>>=20 >>>>> will be able to present multi-party call contents in a = more >>>>=20 >>>>> flexible way. Only two parties at a time will be allowed = to >>>>=20 >>>>> display added text in real-time, while the other = parties=E2=80=99 >>>>=20 >>>>> produced text will need to be stored in the multi-party = server >>>>=20 >>>>> for a moment awaiting a suitable occasion to be = displayed. >>>>=20 >>>>> There are also some cases of erasure that will not be >>>>=20 >>>>> performed on the target text but only indicated in = another >>>>=20 >>>>> way. Even with these drawbacks, the procedure provides an >>>>=20 >>>>> opportunity to display text from more than two parties in = a >>>>=20 >>>>> smooth and readable way. >>>>=20 >>>>> = --------------------------------------------------------------------------= -------------------------=20 >>>>=20 >>>>> I see such mixer procedures as a fall-back for cases = without >>>>=20 >>>>> conference awareness, but want to see support for >>>>=20 >>>>> conference-aware terminals, where text from more than two >>>>=20 >>>>> parties can be presented in real-time, and the end user = or app >>>>=20 >>>>> can have influence over the presentation style - e.g. = select >>>>=20 >>>>> between the multiple column view and the >>>>=20 >>>>> one-column-with-labels view. A mixer for that case would = only >>>>=20 >>>>> need to assure that the receiver has the right kind of >>>>=20 >>>>> multi-party awareness and send RTT text with source >>>>=20 >>>>> information attached, and let the receiving terminal sort = out >>>>=20 >>>>> the presentation. This is already possible with CSRC and = CNAME >>>>=20 >>>>> when using RTP, but we lose that possibility natively = when >>>>=20 >>>>> using the WebRTC data channel to transport RTT, and would = need >>>>=20 >>>>> to specify a way to include the source also for that = case. >>>>=20 >>>>> ------------------------------------------------------ >>>>=20 >>>>> By the way, what is your current view of how to transport = RTT >>>>=20 >>>>> for RUM, now when you say that you will use WebRTC = transports >>>>=20 >>>>> for media? >>>>=20 >>>>> Regards >>>>=20 >>>>> Gunnar >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellstr=C3=B6m >>>>=20 >>>>> >>>>=20 >>>>> = >=20= >>>>=20 >>>>> wrote: >>>>=20 >>>>>=20 >>>>=20 >>>>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>>=20 >>>>>=20 >>>>=20 >>>>> The problem of conference 4103 RTT is high on = my >>>>=20 >>>>> list of work I need to get done. So, I=E2=80=99= m >>>>=20 >>>>> motivated to help out. >>>>=20 >>>>>=20 >>>>=20 >>>>> Thanks, great. >>>>=20 >>>>>=20 >>>>=20 >>>>> The basic problem is that we=E2=80=99re going = to get very >>>>=20 >>>>> inconsistent UI doing it that way, because of = how >>>>=20 >>>>> systems will handle backspace of one party = that >>>>=20 >>>>> extends beyond responses from other parties: >>>>=20 >>>>>=20 >>>>=20 >>>>> (well, for me the currently most basic problem is = to >>>>=20 >>>>> have a reliable way to append received text to = the >>>>=20 >>>>> already presented text of the right participant. = And >>>>=20 >>>>> that is getting worse in WebRTC than it was in = RFC >>>>=20 >>>>> 4103. But we will sort it out.) >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> Alice: I waited for you >>>>=20 >>>>> Bob: I didn=E2=80=99t see you >>>>=20 >>>>> Alice: sorry >>>>=20 >>>>>=20 >>>>=20 >>>>> And then Alice types 12 backspaces. >>>>=20 >>>>>=20 >>>>=20 >>>>> What should happen? >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> You are right that there are a number of ways to >>>>=20 >>>>> handle the RTT UI. And just as inconsistencies = are >>>>=20 >>>>> common with a message oriented UI, where messages = show >>>>=20 >>>>> up in a confusing order because two users = completed >>>>=20 >>>>> messages in an unexpected time order, it is = possible >>>>=20 >>>>> that RTT text gets displayed in a strange order = after >>>>=20 >>>>> erasure and retyping. It is better for RTT than = for >>>>=20 >>>>> message oriented presentation, and user get used = to it >>>>=20 >>>>> in both cases. With the labelled style in one = column >>>>=20 >>>>> you have in the example, I would recommend that = first >>>>=20 >>>>> 5 backspaces erase "sorry", next backspace erases = the >>>>=20 >>>>> line separator, and pulls down "I waited for you" = to >>>>=20 >>>>> be shown last, as an uncompleted text. Then the = next 6 >>>>=20 >>>>> backspaces erase so that only "I waited f" is >>>>=20 >>>>> displayed. When Alice adds text and end with a = new >>>>=20 >>>>> line, the corrected sentence is allowed to flow = up >>>>=20 >>>>> when new text is added from any participant. = That >>>>=20 >>>>> causes a bit strange order, but it is just as >>>>=20 >>>>> manageable as when text in messaging applications >>>>=20 >>>>> appear in an unexpected order so that one message >>>>=20 >>>>> seems to be a respone on something totally else = than >>>>=20 >>>>> what was intended. >>>>=20 >>>>>=20 >>>>=20 >>>>> A sophisticated UI may mark text that is moved = and >>>>=20 >>>>> modified. >>>>=20 >>>>>=20 >>>>=20 >>>>> We want to keep sentences or at least phrases = from >>>>=20 >>>>> each participant together in a readable unit. = Already >>>>=20 >>>>> that causes a design decision on where to place = the >>>>=20 >>>>> completed chunk of text once the user has = completed >>>>=20 >>>>> it. The start of the chunk may be older than = completed >>>>=20 >>>>> text from other participants which would motivate = to >>>>=20 >>>>> move it up a bit in the presentation. But the end = of >>>>=20 >>>>> it is at that moment the latest text to present. = I >>>>=20 >>>>> think it is best to let the finished text be = presented >>>>=20 >>>>> last on the display, but let others' newer text = push >>>>=20 >>>>> everything up and be displayed last. >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> T.140 has information on how to handle erasure: >>>>=20 >>>>>=20 >>>>=20 >>>>> -------------------=46rom T.140--------------------------- >>>>=20 >>>>>=20 >>>>=20 >>>>> 8.2 Erase last character >>>>=20 >>>>> Purpose: Erase the last character sent from the >>>>=20 >>>>> display at the receiving end. >>>>=20 >>>>> Code: BS: 0008. >>>>=20 >>>>> Procedure: On the receiving end: Move the = insertion >>>>=20 >>>>> point to the last character and erase it. >>>>=20 >>>>> Combined characters are erased as a unit, with = one BS >>>>=20 >>>>> erasing the whole character even if it is >>>>=20 >>>>> combined from more than one component. >>>>=20 >>>>> Control sequences (like CR LF) are erased in one >>>>=20 >>>>> operation. >>>>=20 >>>>> NOTE =E2=80=93 The same action shall be taken on = the local >>>>=20 >>>>> display. >>>>=20 >>>>>=20 >>>>=20 >>>>> ------------------------------------------------------------ >>>>=20 >>>>>=20 >>>>=20 >>>>> /Gunnar >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> Brian >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> On Aug 27, 2019, at 9:52 AM, Gunnar = Hellstr=C3=B6m >>>>=20 >>>>> >>>>=20 >>>>> = >=20= >>>>=20 >>>>> wrote: >>>>=20 >>>>>=20 >>>>=20 >>>>> Hi, >>>>=20 >>>>>=20 >>>>=20 >>>>> A topic is currently discussed in mmusic = that >>>>=20 >>>>> is closely related to rum. it is WebRTC >>>>=20 >>>>> transport of real-time text. >>>>=20 >>>>>=20 >>>>=20 >>>>> The draft is >>>>=20 >>>>> draft-holmberg-mmusic-t140-usage-data-channel . >>>>=20 >>>>>=20 >>>>=20 >>>>> A good point to start reading could be: >>>>=20 >>>>>=20 >>>>=20 >>>>> = https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3Ddraft-holmber= g-mmusic-t140-usage-data-channel=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> Please check if the current state of the >>>>=20 >>>>> discussion suits rum! >>>>=20 >>>>>=20 >>>>=20 >>>>> The only issue that seems to be remaining = is >>>>=20 >>>>> how to transport RTT data to and from a >>>>=20 >>>>> conference server that combines all = traffic >>>>=20 >>>>> per media in a meeting in one data = stream. >>>>=20 >>>>> That is not very elegantly specified for = RFC >>>>=20 >>>>> 4103 transport of RTT in RTP either, so = we >>>>=20 >>>>> might want to do a rapid action together = to >>>>=20 >>>>> solve the multi-party RTT MCU case in a >>>>=20 >>>>> general and consistent way. >>>>=20 >>>>>=20 >>>>=20 >>>>> Regards >>>>=20 >>>>>=20 >>>>=20 >>>>> Gunnar >>>>=20 >>>>>=20 >>>>=20 >>>>> -- >>>>=20 >>>>> ----------------------------------------- >>>>=20 >>>>> Gunnar Hellstr=C3=B6m >>>>=20 >>>>> Omnitor >>>>=20 >>>>> gunnar.hellstrom@omnitor.se >>>>=20 >>>>> >>>>=20 >>>>> +46 708 204 288 >>>>=20 >>>>>=20 >>>>=20 >>>>> -- >>>>=20 >>>>> ----------------------------------------- >>>>=20 >>>>> Gunnar Hellstr=C3=B6m >>>>=20 >>>>> Omnitor >>>>=20 >>>>> gunnar.hellstrom@omnitor.se >>>>=20 >>>>> = =20= >>>>=20 >>>>> +46 708 204 288 >>>>=20 >>>>>=20 >>>>=20 >>>>> -- >>>>=20 >>>>> ----------------------------------------- >>>>=20 >>>>> Gunnar Hellstr=C3=B6m >>>>=20 >>>>> Omnitor >>>>=20 >>>>> gunnar.hellstrom@omnitor.se = =20 >>>> >>>>=20 >>>>> +46 708 204 288 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> -- >>>>=20 >>>>> Rum mailing list >>>>=20 >>>>> Rum@ietf.org >>>>=20 >>>>> https://www.ietf.org/mailman/listinfo/rum >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> ----------------------------------------- >>>>=20 >>>> Gunnar Hellstr=C3=B6m >>>>=20 >>>> Omnitor >>>>=20 >>>> gunnar.hellstrom@omnitor.se >>>>=20 >>>> +46 708 204 288 >>>>=20 >>>> * [Rum] Real-time text in WebRTC is discussed in ... >>>> = = Gunnar=20 >>>> Hellstr=C3=B6m >>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>> = = Brian=20 >>>> Rosen >>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>> = = Gunnar=20 >>>> Hellstr=C3=B6m >>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>> = = Brian=20 >>>> Rosen >>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>> = = Gunnar=20 >>>> Hellstr=C3=B6m >>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>> = = Paul=20 >>>> Kyzivat >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Malloy,=20 >>>> Jim >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Paul=20 >>>> Kyzivat >>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>> = = Brian=20 >>>> Rosen >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Brian=20 >>>> Rosen >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Paul=20 >>>> Kyzivat >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Brian=20 >>>> Rosen >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Paul=20 >>>> Kyzivat >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Brian=20 >>>> Rosen >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Malloy,=20 >>>> Jim >>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>> = = Gunnar=20 >>>> Hellstr=C3=B6m >>>>=20 >>>> --=20 >>>>=20 >>>> *John Martin* >>>>=20 >>>> Email: John.Martin@Purple.us >>>>=20 >>>>=20 >>>=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Mon Sep 2 08:40:28 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 C78BF120043 for ; Mon, 2 Sep 2019 08:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 K5nRhXFscf6t for ; Mon, 2 Sep 2019 08:40:21 -0700 (PDT) Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 04666120024 for ; Mon, 2 Sep 2019 08:40:19 -0700 (PDT) X-Halon-ID: ec54cbf5-cd97-11e9-837a-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id ec54cbf5-cd97-11e9-837a-0050569116f7; Mon, 02 Sep 2019 17:40:00 +0200 (CEST) To: Brian Rosen Cc: rum@ietf.org References: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> <5142d3b2-da81-25f0-8859-694cd6126f0b@omnitor.se> <647F8D24-5F21-4D98-83FD-DAAACBC04725@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <76d8aec0-1e7b-c901-6902-aafdfbcfb26f@omnitor.se> Date: Mon, 2 Sep 2019 17:40:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <647F8D24-5F21-4D98-83FD-DAAACBC04725@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - is recvonly etc support desired? 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: Mon, 02 Sep 2019 15:40:27 -0000 Den 2019-09-02 kl. 16:29, skrev Brian Rosen: > I think it’s of marginal utility. The reason you need muting for audio is that you can’t process multiple simultaneous speakers. In RTT, it’s a lot easier. It makes more sense in conference control (not from the endpoint, controlling what the mixer does, a la xcon). OTOH, it ought to be the same as audio and video. Thanks, I think we have suitable wording in draft-holmberg-mmusic-t140-usage-data-channel for the direction attributes now. At the moment not as session level attributes though, but that might be less important than having them on the channel level. /Gunnar > > Brian > >> On Sep 1, 2019, at 5:26 PM, Gunnar Hellström wrote: >> >> I would like a comment from RUM if it is desirable to have support for the direction attributes : sendrecv, sendonly, recvonly, inactive, for RTT streams? >> >> It might be for control of muting etc in multi-party situations, but of course also in other situations. >> >> Regards >> >> Gunnar >> >> Den 2019-08-31 kl. 22:47, skrev Gunnar Hellström: >>> Hi John, >>> >>> Thanks for a good base for discussion. >>> >>> See inline, >>> >>> Den 2019-08-30 kl. 17:12, skrev Paul Kyzivat: >>>> John, >>>> >>>> On 8/30/19 7:32 AM, John Martin wrote: >>>>> All, >>>>> >>>>> $0.02 on RTT: >>>> Thanks for joining in! I don't have much knowledge of (and no experience using) RTT so I will mostly watch from the sidelines as long as others join in. >>>> >>>> Thanks, >>>> Paul >>>> >>>> (BTW, I don't know how you formatted your message, but in my mail reader (Thunderbird) none of your lines wrapped, requiring horizontal scrolling to read them.) >>>> >>>>> RTT in General >>>>> >>>>> -------------- >>>>> >>>>> ISTM there are a few options for RTT in RUM, assuming the WebRTC media framework is adopted (as seems likely): >>>>> >>>>> 1.Use existing browser support for SCTP as recommended by the some of the WebRTC IETF WG participants. This was discussed as part of the IVC WG and would require and SCTP data channel to be negotiated and to encapsulate the RTP (4103) which then in turn encapsulate T.140 RTT. This solution would require gateways in the VRS provider networks, RTP/RTCP userspace (Javascript) layers in the browser and a T.140 RTT layer/UI also written in userspace in the browser. >>> The current work discussed in mmusic about draft-holmberg-mmusic-t140-usage-data-channel specifies T.140 real-time text transported directly in a "reliable" WebRTC data channel, identified with subprotocol "t140". Would that not be suitable for a WebRTC based RUM? The data payload will be the same as carried in RFC 4103 if used without redundancy. You mention that embedded RTP with RFC 4103 would be used as data also in the data channel. That sounds complicated. What would you gain? >>> >>> I hope you also follow the discussion in mmusic. >>> >>>>> 2.Wait for WebRTC to support lower level data channels. This work is being discussed in the WebRTC community, but might be a case of “not holding our breath”. A lower level data channel would allow RTP/RTCP then T.140 to be negotiated in the SDP without the need for SCTP and associated gateway needs. >>> Since the RTCWEB WG is closed now in IETF, this sounds as a 7 year uncertain plan. >>>>> >>>>> 3.As a stop-gap and simplification, support SIP MESSAGE as already provided for by the browsers and many endpoints, including WebRTC endpoints. >>> SCTP data channels are supported as well, and you can just agree to start using it with a private subprotocol temporarily among RUMs until there is a standard. So why use SIP MESSAGE? >>>>> >>>>> We should not forget that RTCP must be implemented along with RTP. >>>>> >>>>> Conferencing and RTT >>>>> >>>>> -------------------- >>>>> >>>>> RTT in a conference is not currently defined and does not work using currently defined standards (I must admit to being being on mmusic so perhaps there are solutions being recommended there). Discussions on this have been ongoing for nearly 10 years (we didn’t solve it then Gunnar and I think the problems are still the same). For RTT to be useful in a conference there needs to be a few problems solved. >>> If you do it with multiple streams sent to the clients, then there are no problems. Therefore there was hesitation when we discussed to bring up the topic in IETF. >>> >>> For mixing into one stream, there are problems. You can do it with normal RTP and conferencing specifications but get some limitations. You can select between a presentation planned by the mixer, or use CSRC in RTP to indicate the source of primary data in each packet and let the client plan the presentation. Both work and do not really need any further standardisation, but would benefit from good best practice specifications or even a standard for solving some problems. >>> >>> Planning and formatting the presentation in the mixer has the limitation that only the local user and one at a time of the remote users text can be presented in real-time. Text from the others need to be buffered until the currently presenting remote participant makes something so that giving turn to next in queue is suitable. Switching turn can be made automatically, based on completed phrase or sentence or message or inactivity or allowed maximum time by the presenting party. Identification about who is sending which text needs to be formatted by the mixer and is likely best in form of an IRC style label when the source is switched. This works for a call where users are reasonably well-behaved in taking turns. There are cases where the presentation in one column with sources in labels is not what the user wants. >>> >>> Using just one stream, and mark by CSRC who contributed to primary data in each packet works as long as no packet was lost. The receiver can make a better adapted presentation for presentation preferences by the user. And text can be presented in real-time from more than two users at the same time. >>> >>> But in order to use the redundant RFC 4103 data to recover text in case of packet loss, then also the redundant data needs to be marked with source. And for that, a convention is needed and standardised. A couple of variants are possible with different pros and cons. Losing so many packets that a missing text marker needs to be inserted also has its problems that needs a specified solution. >>> >>>>> 1.Multi-stream support: Brian, whilst you’re right that most conference systems are point-to-point for signalling they are more typically point-to-multi-point for media. The conference bridge usually handles the multiplexing of the streams, but they are usually now multiple streams. RTT conferencing needs to have the same support. We should assume conferencing is supported by way of SFU not MCU – that’s how WebRTC handles conferencing and we should assume the same for RTT. >>> Yes, that is now the main path for draft-holmberg-mmusic-t140-usage-data-channel, and I think that is good. That is also possible without any further standardization for RTP based RTT. >>>>> 2.Participant identification: streams from the conference bridge (MCU/SFU) must be tagged with the sender so the UI can signal to the user who sent that text (and reconstruct the stream correctly). >>> Yes. Use CSRC / CNAME for RTP and stream ID / label / session information for WebRTC data channel. >>>>> 3.UI adaptions: Modern WebRTC based multi-party conferences have adapted UIs to display multiple video streams. UI’s are adapted to show the video participants however the user wants them to be displayed (single full screen, tiled, voice activated etc). We should expect no less from RTT conference enabled endpoints. It should be a user decision (if their UI supports it) as to whether they see line-by-line or RTT rendering of the text conversation. >>> Yes. If you want a one column presentation, a reasonable presentation is to automatically assign one remote party at a time to be presented in real-time and present the others phrase by phrase, and automatically switch who is presented in real-time based on suitable criteria. >>>>> 4.Control of how many simultaneous participants can text and how that is presented to the user needs to be explored. Multiple insertion points in the UI is one approach (though rapidly breaks down as the number of users increases). Line-by-line is another. Facilitated GA is another (the Go Ahead concept has been used for a long time in text conversations and may be appropriate in large RTT conferences to control overload). >>>>> >>>>> And a final FWIW: I think the utility of RTT in a conference quickly breaks down as the number of participants increases. It is completely unacceptable to have a single RTT stream presented to the user and an unmodified UI. You might as well revert to SIP MESSAGE and something like XMPP, and that could also be an option for either the short term or for endpoints that do not support multi-stream RTT. >>> In some conferences it might be desirable with one dominating RTT source: a written interpretation of what is said, and then occasionally another participant gets the floor and types something . It is very valuable if that mode of conferencing is available without hazzle in general multi-party conference systems. The utility does not break down in that situation. >>> >>> It seems to me that aiming at multi-stream RTT support is to prefer. >>> >>> >>> Regards >>> >>> Gunnar >>> >>>>> John >>>>> >>>>> Brian said: we agreed we were using 4103 in RUM. >>>>> >>>>> Good toknow. But is there not a hope to be able to even use browser >>>>> >>>>> technology for the implementation. The browsers only support RTP for >>>>> >>>>> audio and video. Can you make RTP-based RTT work in that environment and >>>>> >>>>> encrypted with the security method specified for WebRTC? >>>>> >>>>> See a bit more below: >>>>> >>>>> Den 2019-08-29 kl. 21:59, skrev Malloy, Jim: >>>>> >>>>>> “line at a time” is a user interface issue – RUM is defining a machine >>>>>> interface. How it’s presented to the user is out of scope. >>>>> Well, the control and coding must be made so that it is possible to make >>>>> >>>>> a good presentation. Transmission only line-by-line would not suit the >>>>> >>>>> intention of RTT. It is hard to make a good RTT presentation with a >>>>> >>>>> client that is only expecting text from one other participant and a >>>>> >>>>> mixer that has the task to send text from many sources combined in one >>>>> >>>>> stream. The best result is usable but not nice. And it will be aimed at >>>>> >>>>> just one way to present RTT. No freedom to plan the presentation >>>>> >>>>> according to user preferences. >>>>> >>>>> A receiver may, if there is a desire for such functionality, store >>>>> >>>>> received text until a received message is complete. I do not think that >>>>> >>>>> it is to prefer in any situation. >>>>> >>>>> Regards >>>>> >>>>> Gunnar >>>>> >>>>>> --Jim >>>>>> *From:* Rum ; *On Behalf Of * >>>>> Brian Rosen >>>>> >>>>>> *Sent:* Thursday, August 29, 2019 1:15 PM >>>>>> *To:* Kyzivat, Paul ; >>>>>> *Cc:* rum@ietf.org >>>>>> *Subject:* [EXT] Re: [Rum] Real-time text in WebRTC is discussed in >>>>>> mmusic - a topic closely telated to rum >>>>>> “Line at a time” could be an implementation option. The protocol >>>>>> mechanism is all streams head to a mixer and the mixer sends a single >>>>>> stream to each participant. >>>>>> Gunnar, we agreed we were using 4103 in RUM. >>>>>> Brian >>>>>> On Aug 29, 2019, at 12:05 PM, Paul Kyzivat >>>>>> > wrote: >>>>>> I question how well RTT text is suited to multiparty conferences. >>>>>> If you have messages on your screen from multiple parties, and >>>>>> many of them are updating in real-time, are you going to be able >>>>>> to perceive what is going on? >>>>>> And while you can have a column per person for two-party and maybe >>>>>> 3-party conversations, that doesn't scale up. With many parties, >>>>>> some typing may scroll off the screen before it is complete. >>>>>> Perhaps for conferences it is better to just use line-at-a-time >>>>>> chat. If necessary, I presume there could be gateways between RTT >>>>>> and chat. A RUE could have the capability to negotiate down from >>>>>> RTT to chat. >>>>>> Thanks, >>>>>> Paul >>>>>> On 8/28/19 2:15 AM, Gunnar Hellström wrote: >>>>>> Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>>>>> At least by centralizing the problem at a “mixer”, Alice >>>>>> and Bob will see the same thing. >>>>>> You don’t have the problem in Instant Messaging, because >>>>>> you can’t backspace or delete a sent message. Of course >>>>>> if multiple people are typing simultaneously in such >>>>>> systems, message order will be confusing in that instant. >>>>>> Right, it is a similar kind of problem that text appears in an >>>>>> unexpected order. There is also at least one instant messaging >>>>>> service that allows modification in already sent message. But >>>>>> I think it has limitations to only accept that in the last >>>>>> message sent. it is convenient anyway. >>>>>> Anyway, we need to specify the mixer for RTT so it >>>>>> receives each of the RTT streams and produces a single >>>>>> composite stream for each participant. >>>>>> Yes, right, and there is an effort in that direction in: >>>>>> http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf >>>>>> It is written for conference-unaware user devices. >>>>>> The goals are specified as follows: >>>>>> The procedures are intended to make best efforts to present a >>>>>> multi-party text conversation on a terminal that has no >>>>>> awareness of multi-party calls. There are some obvious >>>>>> drawbacks, and a terminal designed with multi-party awareness >>>>>> will be able to present multi-party call contents in a more >>>>>> flexible way. Only two parties at a time will be allowed to >>>>>> display added text in real-time, while the other parties’ >>>>>> produced text will need to be stored in the multi-party server >>>>>> for a moment awaiting a suitable occasion to be displayed. >>>>>> There are also some cases of erasure that will not be >>>>>> performed on the target text but only indicated in another >>>>>> way. Even with these drawbacks, the procedure provides an >>>>>> opportunity to display text from more than two parties in a >>>>>> smooth and readable way. >>>>>> --------------------------------------------------------------------------------------------------- >>>>>> I see such mixer procedures as a fall-back for cases without >>>>>> conference awareness, but want to see support for >>>>>> conference-aware terminals, where text from more than two >>>>>> parties can be presented in real-time, and the end user or app >>>>>> can have influence over the presentation style - e.g. select >>>>>> between the multiple column view and the >>>>>> one-column-with-labels view. A mixer for that case would only >>>>>> need to assure that the receiver has the right kind of >>>>>> multi-party awareness and send RTT text with source >>>>>> information attached, and let the receiving terminal sort out >>>>>> the presentation. This is already possible with CSRC and CNAME >>>>>> when using RTP, but we lose that possibility natively when >>>>>> using the WebRTC data channel to transport RTT, and would need >>>>>> to specify a way to include the source also for that case. >>>>>> ------------------------------------------------------ >>>>>> By the way, what is your current view of how to transport RTT >>>>>> for RUM, now when you say that you will use WebRTC transports >>>>>> for media? >>>>>> Regards >>>>>> Gunnar >>>>>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellström >>>>>> >>>>>> > >>>>>> wrote: >>>>>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>>>> The problem of conference 4103 RTT is high on my >>>>>> list of work I need to get done. So, I’m >>>>>> motivated to help out. >>>>>> Thanks, great. >>>>>> The basic problem is that we’re going to get very >>>>>> inconsistent UI doing it that way, because of how >>>>>> systems will handle backspace of one party that >>>>>> extends beyond responses from other parties: >>>>>> (well, for me the currently most basic problem is to >>>>>> have a reliable way to append received text to the >>>>>> already presented text of the right participant. And >>>>>> that is getting worse in WebRTC than it was in RFC >>>>>> 4103. But we will sort it out.) >>>>>> Alice: I waited for you >>>>>> Bob: I didn’t see you >>>>>> Alice: sorry >>>>>> And then Alice types 12 backspaces. >>>>>> What should happen? >>>>>> You are right that there are a number of ways to >>>>>> handle the RTT UI. And just as inconsistencies are >>>>>> common with a message oriented UI, where messages show >>>>>> up in a confusing order because two users completed >>>>>> messages in an unexpected time order, it is possible >>>>>> that RTT text gets displayed in a strange order after >>>>>> erasure and retyping. It is better for RTT than for >>>>>> message oriented presentation, and user get used to it >>>>>> in both cases. With the labelled style in one column >>>>>> you have in the example, I would recommend that first >>>>>> 5 backspaces erase "sorry", next backspace erases the >>>>>> line separator, and pulls down "I waited for you" to >>>>>> be shown last, as an uncompleted text. Then the next 6 >>>>>> backspaces erase so that only "I waited f" is >>>>>> displayed. When Alice adds text and end with a new >>>>>> line, the corrected sentence is allowed to flow up >>>>>> when new text is added from any participant. That >>>>>> causes a bit strange order, but it is just as >>>>>> manageable as when text in messaging applications >>>>>> appear in an unexpected order so that one message >>>>>> seems to be a respone on something totally else than >>>>>> what was intended. >>>>>> A sophisticated UI may mark text that is moved and >>>>>> modified. >>>>>> We want to keep sentences or at least phrases from >>>>>> each participant together in a readable unit. Already >>>>>> that causes a design decision on where to place the >>>>>> completed chunk of text once the user has completed >>>>>> it. The start of the chunk may be older than completed >>>>>> text from other participants which would motivate to >>>>>> move it up a bit in the presentation. But the end of >>>>>> it is at that moment the latest text to present. I >>>>>> think it is best to let the finished text be presented >>>>>> last on the display, but let others' newer text push >>>>>> everything up and be displayed last. >>>>>> T.140 has information on how to handle erasure: >>>>>> -------------------From T.140--------------------------- >>>>>> 8.2 Erase last character >>>>>> Purpose: Erase the last character sent from the >>>>>> display at the receiving end. >>>>>> Code: BS: 0008. >>>>>> Procedure: On the receiving end: Move the insertion >>>>>> point to the last character and erase it. >>>>>> Combined characters are erased as a unit, with one BS >>>>>> erasing the whole character even if it is >>>>>> combined from more than one component. >>>>>> Control sequences (like CR LF) are erased in one >>>>>> operation. >>>>>> NOTE – The same action shall be taken on the local >>>>>> display. >>>>>> ------------------------------------------------------------ >>>>>> /Gunnar >>>>>> Brian >>>>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellström >>>>>> >>>>>> > >>>>>> wrote: >>>>>> Hi, >>>>>> A topic is currently discussed in mmusic that >>>>>> is closely related to rum. it is WebRTC >>>>>> transport of real-time text. >>>>>> The draft is >>>>>> draft-holmberg-mmusic-t140-usage-data-channel . >>>>>> A good point to start reading could be: >>>>>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel >>>>>> Please check if the current state of the >>>>>> discussion suits rum! >>>>>> The only issue that seems to be remaining is >>>>>> how to transport RTT data to and from a >>>>>> conference server that combines all traffic >>>>>> per media in a meeting in one data stream. >>>>>> That is not very elegantly specified for RFC >>>>>> 4103 transport of RTT in RTP either, so we >>>>>> might want to do a rapid action together to >>>>>> solve the multi-party RTT MCU case in a >>>>>> general and consistent way. >>>>>> Regards >>>>>> Gunnar >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellström >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>>> >>>>>> +46 708 204 288 >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellström >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>>> >>>>>> +46 708 204 288 >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellström >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>> >>>>> >>>>>> +46 708 204 288 >>>>>> -- >>>>>> 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 >>>>> >>>>> * [Rum] Real-time text in WebRTC is discussed in ... >>>>> Gunnar >>>>> Hellström >>>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>>> Brian >>>>> Rosen >>>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>>> Gunnar >>>>> Hellström >>>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>>> Brian >>>>> Rosen >>>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>>> Gunnar >>>>> Hellström >>>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>>> Paul >>>>> Kyzivat >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Malloy, >>>>> Jim >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Paul >>>>> Kyzivat >>>>> * Re: [Rum] Real-time text in WebRTC is discussed... >>>>> Brian >>>>> Rosen >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Brian >>>>> Rosen >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Paul >>>>> Kyzivat >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Brian >>>>> Rosen >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Paul >>>>> Kyzivat >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Brian >>>>> Rosen >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Malloy, >>>>> Jim >>>>> * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>>>> Gunnar >>>>> Hellström >>>>> >>>>> -- >>>>> >>>>> *John Martin* >>>>> >>>>> Email: John.Martin@Purple.us >>>>> >>>>> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> -- >> 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 Sep 3 07:48:15 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 0CA061208D3 for ; Tue, 3 Sep 2019 07:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riCzPECgacCC for ; Tue, 3 Sep 2019 07:48:11 -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 D62A81208D4 for ; Tue, 3 Sep 2019 07:48:10 -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 x83Em8QQ017241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 3 Sep 2019 10:48:09 -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> From: Paul Kyzivat Message-ID: <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> Date: Tue, 3 Sep 2019 10:48:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <1567413580412.20641@purple.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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, 03 Sep 2019 14:48:13 -0000 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 todays devices to have a chance of being RUM compatible. I dont 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. Isnt 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 > From nobody Wed Sep 4 06:54: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 19099120100 for ; Wed, 4 Sep 2019 06:54:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LUb9iD9QQmm8 for ; Wed, 4 Sep 2019 06:54:43 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (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 EB13E120106 for ; Wed, 4 Sep 2019 06:54:42 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id s18so8609428qkj.3 for ; Wed, 04 Sep 2019 06:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rAYwQ5sVnykjRxV3sayAnlustt7UuDtRM8qMCzBkCsY=; b=GqWr6YUZdD9sGBi8nx7PvWhrC43o3TZMMeufVw9y8rREcAcbUFLOZKqMuWISM5673t 6e5aCdhKGlUzEtQBICs8rpg1bJBAh9RZK2bPPt2FlqQsgNSKeURSjiLHbaQUXqoWvLDk SkRhoBMAD47E5Mb26kQ5I5Fd8Y2k5Ort42uxcbZ/TeM1WNtNNT2vAWRc59oS8WVKdy3H D03EdciR8jVXKQXKeKM1xloZz0yNJsxHPa9WvmDfLA/YWHBvkmlGl8VlH6+C97PUdAuH h1bL8MyGCKp+sGAwNXTaohWwDS7A2pEZeqwHqBMGcUv8plBwvVu0MhEgH9XvmzRQ3Ape Z6kQ== 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=rAYwQ5sVnykjRxV3sayAnlustt7UuDtRM8qMCzBkCsY=; b=TpAjVFVHwQ5JNqeUHu1n6uvI6dyBgTIil0QLusrCl/auJZfiI9XWPeev71wXWPFuPv uaFdPAcszQ085g0lf9P+2GXHOdqLDhq/VLcHESG50YSuiB2YcbGKh6KNl/8GCzbNftgv jUd352LsZy/H0E+awWWSYugdiCYcmk1qElcpK0RI7yGHPmISiOEVP7G/JzMY23h8s7zJ a/2Rqv0FmudroC0bjfl0C6cIujl8/aTa2doG0/T1H6j6N7RD69HFqSzMA3r3AIlkRSN9 6fxHqeV3j/tABuGZjSECxZiWBYqVaoWkZju4t3E51MfsRkZmALpKG3r6/TM7OVuV65QP iEUw== X-Gm-Message-State: APjAAAUpIEU3fOCsLLqauotXMfNdBxPeL3Ha2uJj5/Ci3L5lNGnzVvqQ f5G+cUChDmwLb7knNlCxoZo07A== X-Google-Smtp-Source: APXvYqxHnof7JRRDjIqJvHPjz63vQgQ1dppCYcmbpiAisCg1NLICBCYJaoava+vQaM9JoQ2KG4O5Ng== X-Received: by 2002:a37:4651:: with SMTP id t78mr18280150qka.259.1567605281815; Wed, 04 Sep 2019 06:54:41 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id f34sm11532547qtc.19.2019.09.04.06.54.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2019 06:54:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> Date: Wed, 4 Sep 2019 09:54:39 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> 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> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Wed, 04 Sep 2019 13:54:46 -0000 I think our consensus is MTI: Audio: G.711 and Opus Video: H.264 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: >=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. >=20 > 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>>=20 >>>> -- >>>> Rum mailing list >>>> Rum@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rum >>>=20 >>>=20 >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Wed Sep 4 07:35:15 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 78F7912001A for ; Wed, 4 Sep 2019 07:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCeQWYE6bm6r for ; Wed, 4 Sep 2019 07:35:08 -0700 (PDT) Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 8386E12000F for ; Wed, 4 Sep 2019 07:35:08 -0700 (PDT) X-Halon-ID: 24c09012-cf21-11e9-bdc3-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 24c09012-cf21-11e9-bdc3-005056917a89; Wed, 04 Sep 2019 16:34:47 +0200 (CEST) To: Brian Rosen , Paul Kyzivat 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> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> Date: Wed, 4 Sep 2019 16:35:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Wed, 04 Sep 2019 14:35:15 -0000 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 Wed Sep 4 07:37:56 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 35B2B120120 for ; Wed, 4 Sep 2019 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCFw3-HNlLdO for ; Wed, 4 Sep 2019 07:37:47 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 BA7DD1201EA for ; Wed, 4 Sep 2019 07:37:46 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id r15so18973403qtn.12 for ; Wed, 04 Sep 2019 07:37:46 -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=bO0SOYO+3foG2EJcPrWSqkaGbPQldI+0bUnW3WvyqbA=; b=Rp1N2m4DWRupcaiMi3I7SSj/QN7fGnttpDbUriT9OnqgUZ/9P43iRoaW1VLDzZLeRR uWVd6C6FNI25M6PoqWK/Bq1fuXBEC+EqlWYk/+P9XdPOowjAUWjS4kDXZHx22uLuQKc8 6e+ZG0fP12HfET7cwh0xSVFvqogbEvu3vxXGOniL7tFQ4mn+zJV7DrvX+eEytOshsM0X m8YSIYdEUI8UCc8C0KapcQHqaZPPw7Ab8+gp4Jdj5Dz2kU/ePDEKnyAQTY1PSf0ZL+sK U2lMKbpqP4ipi81e2k1JtE7+SltKAW7NzyU1finsVrrbrI28bGMASfqqdULlxSIl/bO/ 6tIw== 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=bO0SOYO+3foG2EJcPrWSqkaGbPQldI+0bUnW3WvyqbA=; b=hCnQhf/ROZ+L5udg46oAXSwJ/0P/pV1Ep1aClFPZYxQF66+vjnnieLnPIJndsgxGmS EWy5HPBS0teTE8utJ5Dl1bUGY2ajJ7v5AbOsvfBkdPBZlBE55vuUQCntmvdWwv2zHRpH RMY/6OhUBvG/cCFUThJFR98s/npoOOAWrQu2xuZyMr1Wj2ZfPxApErAC/oT+HRcqqWDE G1ctgXDfK3gpZ90aTbbQe1juH6dGURUcpnujlZf+hcTRyfcHTcoT3KiHHLpdFiyH+I6V IDtq4gc1vdfeaiQ9chiGfmFm0EcHK9ttt6e+RpZfxRlMu+b8okBx02r7EAjyLgmWbJnS H1tw== X-Gm-Message-State: APjAAAWEnamQDDKbmgaXuJr+i2k/5zhBX1zp0ibT5fBN11RslK+yYtFi iWH26AtkHD0erfXJwXsspDGbcA== X-Google-Smtp-Source: APXvYqw6vZQboAbFLOGeTeiSxJIl8hXq8slK3uEB5A/n7lZl6Ec2JPdZE+31HV/AfpsnSL6XfM8Z5A== X-Received: by 2002:a0c:cdcb:: with SMTP id a11mr6406610qvn.194.1567607865633; Wed, 04 Sep 2019 07:37:45 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id v13sm9840688qkj.109.2019.09.04.07.37.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2019 07:37:45 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_83789B43-4F84-4B95-A06F-AE5D4C142D9F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 4 Sep 2019 10:37:43 -0400 In-Reply-To: <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> Cc: Paul Kyzivat , rum@ietf.org To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 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> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Wed, 04 Sep 2019 14:37:54 -0000 --Apple-Mail=_83789B43-4F84-4B95-A06F-AE5D4C142D9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. Brian > 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://www.ietf.org/mailman/listinfo/rum >>>>>=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 >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 --Apple-Mail=_83789B43-4F84-4B95-A06F-AE5D4C142D9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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.

Brian

On Sep = 4, 2019, at 10:35 AM, Gunnar Hellstr=C3=B6m <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> 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> on behalf of Paul Kyzivat = <pkyzivat@alum..mit.edu>
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 <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> 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> 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=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

= --Apple-Mail=_83789B43-4F84-4B95-A06F-AE5D4C142D9F-- From nobody Wed Sep 4 10:53: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 EBFDD120B26 for ; Wed, 4 Sep 2019 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSVzh5TfIw7X for ; Wed, 4 Sep 2019 10:52:47 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (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 CE509120B07 for ; Wed, 4 Sep 2019 10:52:44 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx11.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 04 Sep 2019 17:52:40 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Sep 2019 10:52:35 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Wed, 4 Sep 2019 10:52:35 -0700 From: James Hamlin To: Brian Rosen , Paul Kyzivat CC: "rum@ietf.org" Thread-Topic: [Rum] Codec requirements in draft-rosen-rue-01 Thread-Index: AQHVUV6wjLP/Oy7TOEegGP/2NVsbUqcP75GAgAAn6QCAARFKAIAABkIAgAANRQCAAAZWAIAG7fPMgAJvOgCAAYNjgP//x8Ht Date: Wed, 4 Sep 2019 17:52:35 +0000 Message-ID: <1567619554957.49934@purple.us> 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> In-Reply-To: <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1567619556-893020-7313-336450-1 X-BESS-VER: 2019.1_20190823.2224 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.218059 [from cloudscan20-37.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Wed, 04 Sep 2019 17:52:50 -0000 =0A= I think making Opus mandatory will require transcoding for many calls. G.71= 1 is likely to be the only option for calls that are relayed and therefore = have a PSTN leg. Making G.711 mandatory and Opus recommended would allow fo= r calls where Opus cannot sensibly be offered.=0A= =0A= MTI as the term is used in the WebRTC context ( https://webrtcglossary.com/= mti ), I think, refers to what must be implemented in a WebRTC stack wherea= s, I think, we are talking about what must be in an SDP offer.=0A= =0A= Best regards=0A= =0A= James=0A= =0A= ________________________________________=0A= From: Rum on behalf of Brian Rosen =0A= Sent: 04 September 2019 14:54=0A= To: Paul Kyzivat=0A= Cc: rum@ietf.org=0A= Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01=0A= =0A= I think our consensus is MTI:=0A= Audio: G.711 and Opus=0A= Video: H.264=0A= =0A= We need to get into the details of H.264 to maintain compatibility with the= WebRTC specs and as much backwards compatibility as possible.=0A= =0A= Anyone object?=0A= =0A= =0A= =0A= > On Sep 3, 2019, at 10:48 AM, Paul Kyzivat wrote:= =0A= >=0A= > On 9/2/19 4:39 AM, James Hamlin wrote:=0A= >> Just to add: the VRS industry supports a variety of endpoints, many of w= hich are hardware based and not built by VRS providers themselves. H.264 an= d G..711 therefore need to be in the MTI list.=0A= >> I believe the FCC order related to compensation by compliant providers n= ot that every call had to come from a compliant endpoint.=0A= >=0A= > Sorry if I got that wrong. I wrote that from memory and perhaps my memory= is faulty.=0A= >=0A= > Thanks,=0A= > Paul=0A= >=0A= >> Best Regards=0A= >> James=0A= >> ________________________________________=0A= >> From: Rum on behalf of Paul Kyzivat =0A= >> Sent: 28 August 2019 16:48=0A= >> To: rum@ietf.org=0A= >> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01=0A= >> On 8/28/19 11:25 AM, Eric Burger wrote:=0A= >>> I guess the question is whether we want today=92s devices to have a cha= nce 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= devices to pipe in here.]=0A= >> Lets be clear about what we mean by "RUM compatible".=0A= >> When Henning and I were working on this with the providers in 2014 and= =0A= >> 2015 there was an expectation that the providers would be required to=0A= >> support the defined RUE devices, but they would also be permitted to=0A= >> support their existing proprietary devices. The RUE devices could have= =0A= >> requirements that their existing devices don't meet. But calls between= =0A= >> the two were expected to work.=0A= >> There was great consternation when subsequently the FCC issued a=0A= >> proposed order that said only VRS calls involving RUE-compatible devices= =0A= >> would be compensated. (But that was in 2015. I presume it has not happen= ed.)=0A= >> If there is an intent to exclude non-RUM-compliant devices from use in= =0A= >> VRS calls then there needs to be a migration plan to get from here to th= ere.=0A= >> Thanks,=0A= >> Paul=0A= >>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen wrote:= =0A= >>>>=0A= >>>> 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 forward= s compatibility with WebRTC. Isn=92t that what we want?=0A= >>>>=0A= >>>> Brian=0A= >>>>=0A= >>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat wr= ote:=0A= >>>>>=0A= >>>>> Inline...=0A= >>>>>=0A= >>>>> On 8/27/19 5:57 PM, Adam Roach wrote:=0A= >>>>>> I certainly have thoughts. The executive summary is that I personall= y 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= .=0A= >>>>>> 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 cod= ec.. I know there is a strong desire -- one that I share -- that these endp= oints can talk to/be implemented in web browsers without the need for media= transcoding.=0A= >>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the former be= cause it works without transcoding to landline PSTN destinations, and the l= atter 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 o= pt to designate Opus as the only MTI. Given that RUM inherently needs to de= ploy into audio/video environments, backwards compatibility with the PSTN s= eems to be unnecessary baggage.=0A= >>>>>=0A= >>>>> Please keep in mind where we are coming from. The RUM will be a new i= nterface to the *existing* VRS infrastructure. That infrastructure currentl= y has proprietary devices that serve the RUE function, deployed to VRS user= s and to Communications Assistants (CAs, Interpreters). These have G.711 MT= I, and also *recommend* G.722.2.=0A= >>>>>=0A= >>>>> Making OPUS the only MTI audio codec would be problematic.=0A= >>>>>=0A= >>>>>> For video: While specifying either VP8 or H.264 would be sufficient = for system interop, and for interop with compliant WebRTC endpoints, I'd re= ally 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 de= fined 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* WebR= TC Non-Browsers per se; merely that they comply with the same video codec r= equirements as WebRTC Non-Browsers.=0A= >>>>>=0A= >>>>> Continuing my comment above, existing devices have H.264 Constrained = Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds ar= e many of these devices aren't capable of VP8.=0A= >>>>>=0A= >>>>> We can't realistically require a wholesale swap out of existing devic= es 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.=0A= >>>>>=0A= >>>>> Thanks,=0A= >>>>> Paul=0A= >>>>>=0A= >>>>>> /a=0A= >>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote:=0A= >>>>>>> Well, we certainly want interoperability, and I think we can only g= et that with MTI codecs.=0A= >>>>>>>=0A= >>>>>>> I think we really are talking about a WebRTC-compatible endpoint, b= ut we want interoperability with a WebRTC browser endpoint.=0A= >>>>>>>=0A= >>>>>>> Not sure how to say this. Maybe Adam can help.=0A= >>>>>>>=0A= >>>>>>> Brian=0A= >>>>>>>=0A= >>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = wrote:=0A= >>>>>>>>=0A= >>>>>>>> draft-rosen-rue-01 changes the video codec requirements. It now si= mply references webrtc RFC7742.=0A= >>>>>>>>=0A= >>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", = "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes th= at each end is one of these.=0A= >>>>>>>>=0A= >>>>>>>> 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:=0A= >>>>>>>>=0A= >>>>>>>> "WebRTC-compatible endpoints" are free to implement any video c= odecs=0A= >>>>>>>> they see fit. This follows logically from the definition of "W= ebRTC-=0A= >>>>>>>> compatible endpoint". It is, of course, advisable to implement= at=0A= >>>>>>>> least one of the video codecs that is mandated for WebRTC brows= ers,=0A= >>>>>>>> and implementors are encouraged to do so.=0A= >>>>>>>>=0A= >>>>>>>> Similarly, the audio requirements have been changed to reference w= ebrtc RFC7874. That one doesn't have the distinction between "WebRTC browse= r", "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.=0A= >>>>>>>>=0A= >>>>>>>> I think simply referencing these documents isn't sufficient. Seems= like we need a more nuanced specification of what is required, though we m= ay still reference these docs with qualifications.=0A= >>>>>>>>=0A= >>>>>>>> Thanks,=0A= >>>>>>>> Paul=0A= >>>>>>>>=0A= >>>>>>>>=0A= >>>>>=0A= >>>>=0A= >>>> --=0A= >>>> Rum mailing list=0A= >>>> Rum@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/rum=0A= >>>=0A= >>>=0A= >> --=0A= >> Rum mailing list=0A= >> Rum@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/rum=0A= >=0A= > --=0A= > Rum mailing list=0A= > Rum@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rum=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rum=0A= From nobody Wed Sep 4 11:55:03 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 8B918120BCC for ; Wed, 4 Sep 2019 11:55:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1nV_2lJgAVc3 for ; Wed, 4 Sep 2019 11:54:58 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (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 42853120BB4 for ; Wed, 4 Sep 2019 11:54:58 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id x134so10485159qkb.0 for ; Wed, 04 Sep 2019 11:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8yL5lRnXJrXMJQ0L7hwqnALcenyQ4thHjQXgvhgn+Tw=; b=fMYa/9/CNONa+bGQqAyt68wGyUTBAutBlM3YjpdrLad/UYcOGm3jjI/PYTfgvxZDE/ 3w/Oy1O5rL4XhN5W26H82B4U/YBSIwGWqy+AqtWIFxOmbxEPKDR3VWsa2SMR2UbD+Zir J8KXx/w5Zu8XfuDQcFtouaVT8COK4ViKDlTGLZwcal56U0MFNEeeFM0xuK//iUhxswqo 0uftz8qCVbk2z3SzxteQU6aLWL2PmETGUX4eNn0R+TF1gWR0r9bnwcnO4LP+amFrQFaK NBqC7wn+eXJeDvcJMeLrILsLNWrR4aeeCMpKawWN+40NCFPq6JQH6D3AkipqnXf/xeXq zKaQ== 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=8yL5lRnXJrXMJQ0L7hwqnALcenyQ4thHjQXgvhgn+Tw=; b=RfMv9+giNzEKzJRpKhHrKmfzuGLrr8D7/3SpIDtvOt9e0n43Q3NxUmM2eTOxBaMz81 2EPQ8YIpFNyoZHopZ4b09f6vbymJkJB4vVOXf745OY7PSz+uR/K93HjFL74CArajRRfV JVB4NQLuioTS/ngNOmSokET10InkSEU0MOYIGtW2WPApdRyCqoqnHTLKqLN3NisrW3I5 BTABtGyRvBkhwJFEUbnAmhsPm6mbwEp10U7vqvZxcx9pHLXjEilEwxKya5gAvZd9zsnq 2WwTduzX8lMZgIZyK3qOD9Y/ZKy+Kla2E26i1X7LF8fxcCkkFFt8fl+iXrx5MtJFDcB0 FQXA== X-Gm-Message-State: APjAAAXw7r5m4NGARnZybtbyvHN5nD6mrWkeR7fc/JwKcpWpR5Hdhiv/ WgrzLsw73ItyjrzlFB5tmOSEPKpdX4w= X-Google-Smtp-Source: APXvYqzBl3gdn1NsudzAoFRFR0uBv0KZIp3a3nZb6TKt8tLV2Qy0OMsnUHFlBmvu3BnYkDQ/nVPwmA== X-Received: by 2002:a37:a00d:: with SMTP id j13mr41268744qke.2.1567623297104; Wed, 04 Sep 2019 11:54:57 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id k199sm3973330qke.45.2019.09.04.11.54.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2019 11:54:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <1567619554957.49934@purple.us> Date: Wed, 4 Sep 2019 14:54:53 -0400 Cc: Paul Kyzivat , "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> <1567619554957.49934@purple.us> To: James Hamlin X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Wed, 04 Sep 2019 18:55:02 -0000 I believe way the spec reads, it=E2=80=99s MTI, and also mandatory to = offer in SDP. Adam, can you confirm? If rue calls old machine, rue offers G.711 and OPUS. Old machine = answers G.711 If old machine calls rue, old machine offers G.711 and rue answers G.711 If I=E2=80=99m mistaken, I have no problem requiring offers to have = G.711 and H.264 (and 4103). Brian > On Sep 4, 2019, at 1:52 PM, James Hamlin = wrote: >=20 >=20 > I think making Opus mandatory will require transcoding for many calls. = G.711 is likely to be the only option for calls that are relayed and = therefore have a PSTN leg. Making G.711 mandatory and Opus recommended = would allow for calls where Opus cannot sensibly be offered. >=20 > MTI as the term is used in the WebRTC context ( = https://webrtcglossary.com/mti ), I think, refers to what must be = implemented in a WebRTC stack whereas, I think, we are talking about = what must be in an SDP offer. >=20 > Best regards >=20 > James >=20 > ________________________________________ > From: Rum on behalf of Brian Rosen = > Sent: 04 September 2019 14:54 > To: Paul Kyzivat > Cc: rum@ietf.org > Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 >=20 > I think our consensus is MTI: > Audio: G.711 and Opus > Video: H.264 >=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. >>=20 >> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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 >>>>>=20 >>>>> -- >>>>> Rum mailing list >>>>> Rum@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rum >>>>=20 >>>>=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 >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Wed Sep 4 12:16:27 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 32DD9120900 for ; Wed, 4 Sep 2019 12:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 zkRw-tntE9Uf for ; Wed, 4 Sep 2019 12:16:20 -0700 (PDT) Received: from se5b-lax1.servconfig.com (se5b-lax1.servconfig.com [192.249.122.92]) (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 BE1AB12006D for ; Wed, 4 Sep 2019 12:16:20 -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 1i5alH-000hoC-NP for rum@ietf.org; Wed, 04 Sep 2019 15:16:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Content-Type:MIME-Version:To:From: In-Reply-To:Subject:Date:Sender:Reply-To:Message-ID:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=gvQVXL3llYn8LoZxKcwceej29cyqDBSDeuXi1YPYXXE=; b=kbzoTz1TZNEy D5MKEyr9eKumfp2DXlrlK9XPMK9P+KhZ3z1g4An2/hiFaMBsmCNWpfdVsxHI+/laOwS+Spxgb5W8J jBVLJda6QNAlElAvZ+H+qEvZ9qkR/o3qq6yHg0GDHSeujucnd/3k3N+zqAGESdUZ59mJ6l7tT8sxj yVv9Q=; Received: from [174.204.21.128] (port=6910 helo=[100.93.141.177]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1i5aky-0008b9-0o for rum@ietf.org; Wed, 04 Sep 2019 12:16:02 -0700 SavedFromEmail: eburger@standardstrack.com Date: Wed, 04 Sep 2019 15:15:50 -0400 In-Reply-To: Importance: normal From: Eric Burger To: rum@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_405862085696590" X-OutGoing-Spam-Status: No, score=-0.5 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 Message-ID: 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: ham X-SpamExperts-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0duM4P579sYYbdH8Mt+sPVWpSDasLI4SayDByyq9LIhVXeImttMSRxdQ UybcXBAjTUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwzmmD1lPZONmDbVrCI7lkOfH zJ6mVE7ewsipSVIfs4YOwgY9FVKJWLPjQ6TT0zpngyWFxOA5dILPypvKxNVhWW9iu9q1oNVH8nhC o/XpZxc/iXnuUw31frArk475PTzt0p8T4Nd45j4kJRgJ8MJ6+Md4EfSeS8yJNluG6jX3DLoRxK5O dUqDGvgvOW0ZV5+aaHwJ2eESrUp0Iw/gSJ3HqMuR600P9eQ3vodupN36MrkzGQZS068e3EYTgNAB jZkD8TzPF4eG61o+cxFZrUIXowfXJosMX5ZQSlYSVlCDu2lHfay0qiZGlWA7cME1MR87KvWTUIuw AP+Be6QqMx/OK6S8tu2KVBI79Uufvsp4JVtkiXe41lqpq2ZOFKLzbBWXp6KrPCklAmnloYenuVMJ ithDlN3ZFexZfYgAG9qTPTrzvgwP9cMw+lye/qXkeuruM49zcQbne4vePgcv4iEyyps9zSZic0xN U+sMoNUh1wvn89yOIY2U6E/pGzbNVF97dXlHxUbN/5WT0Em3hIRYjR/5rdSUCOd7cBJ/MG7va4Zl 5VsNmjFRP8Tn5HNzDUKU/H6jD7pq5ElFy3fFf2s/xjf9bG4oCE8tXKfGDzsW4pDsxBoFbdIyTZwD 0tTyhMSsSJ3IubBWGgd3tCW2+j49qPy8TH7WSc4+zHum9T07LFr/ZOM1zTF62ZsMIDZC39FwSAI0 wMLmmLOjPPfhuMRM/XLYM3A6BXfvel8OEFDbU50IgR7PRT5/DHVWO8a2mKDk6wbUwIyEC/K8KEtW w07pi33IciEhgmtMw3nNgNoOL9aocX5jTqOPXegHd4QqN1stFdDzDETtPsIzc13Og30NySaguH3F iNx1MYrEHZWAQSGSTwMUHD8nvT6qjZo9eXrf6YZflXKvK4TN7SfIl4AyWsJcTQxjOb16oNH/dgmH 4dCci8JLiiOdckUewCJrmQRccHsd8qMjV5g1hoDi6vb8iw== X-Report-Abuse-To: spam@se1-lax1.servconfig.com Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Wed, 04 Sep 2019 19:16:23 -0000 ----_com.samsung.android.email_405862085696590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhdCdzIHRoZSBiZWF1dHkgb2YgTVRJLiBPbGQsIG9sZCBlcXVpcG1lbnQgd2lsbCBpbnRlcm9w ZXJhdGUgKEcuNzExKSBhbmQgYXMgdGhlIGJhc2UgdXBncmFkZXMgLyBuZXcgdXNlcnMgYXBwZWFy LCB0aGV5IGdldCB0aGUgYmVuZWZpdCBvZiA0NiB5ZWFycyBvZiBjb2RlYyBkZXZlbG9wbWVudC7C oEl0J3Mgbm90IDE5NzIgYW55IG1vcmUuLi4KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LS0tLUZyb206IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4gRGF0ZTogOS80LzE5ICAy OjU0IFBNICAoR01ULTA1OjAwKSBUbzogSmFtZXMgSGFtbGluIDxqYW1lcy5oYW1saW5AcHVycGxl LnVzPiBDYzogcnVtQGlldGYub3JnLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVk dT4gU3ViamVjdDogUmU6IFtSdW1dIENvZGVjIHJlcXVpcmVtZW50cyBpbiBkcmFmdC1yb3Nlbi1y dWUtMDEgSSBiZWxpZXZlIHdheSB0aGUgc3BlYyByZWFkcywgaXTigJlzIE1USSwgYW5kIGFsc28g bWFuZGF0b3J5IHRvIG9mZmVyIGluIFNEUC7CoCBBZGFtLCBjYW4geW91IGNvbmZpcm0/SWYgcnVl IGNhbGxzIG9sZCBtYWNoaW5lLCBydWUgb2ZmZXJzIEcuNzExIGFuZCBPUFVTLsKgIE9sZCBtYWNo aW5lIGFuc3dlcnMgRy43MTFJZiBvbGQgbWFjaGluZSBjYWxscyBydWUsIG9sZCBtYWNoaW5lIG9m ZmVycyBHLjcxMSBhbmQgcnVlIGFuc3dlcnMgRy43MTFJZiBJ4oCZbSBtaXN0YWtlbiwgSSBoYXZl IG5vIHByb2JsZW0gcmVxdWlyaW5nIG9mZmVycyB0byBoYXZlIEcuNzExIGFuZCBILjI2NCAoYW5k IDQxMDMpLkJyaWFuPiBPbiBTZXAgNCwgMjAxOSwgYXQgMTo1MiBQTSwgSmFtZXMgSGFtbGluIDxq YW1lcy5oYW1saW5AcHVycGxlLnVzPiB3cm90ZTo+ID4gPiBJIHRoaW5rIG1ha2luZyBPcHVzIG1h bmRhdG9yeSB3aWxsIHJlcXVpcmUgdHJhbnNjb2RpbmcgZm9yIG1hbnkgY2FsbHMuIEcuNzExIGlz IGxpa2VseSB0byBiZSB0aGUgb25seSBvcHRpb24gZm9yIGNhbGxzIHRoYXQgYXJlIHJlbGF5ZWQg YW5kIHRoZXJlZm9yZSBoYXZlIGEgUFNUTiBsZWcuIE1ha2luZyBHLjcxMSBtYW5kYXRvcnkgYW5k IE9wdXMgcmVjb21tZW5kZWQgd291bGQgYWxsb3cgZm9yIGNhbGxzIHdoZXJlIE9wdXMgY2Fubm90 IHNlbnNpYmx5IGJlIG9mZmVyZWQuPiA+IE1USSBhcyB0aGUgdGVybSBpcyB1c2VkIGluIHRoZSBX ZWJSVEMgY29udGV4dCAoIGh0dHBzOi8vd2VicnRjZ2xvc3NhcnkuY29tL210aSApLCBJIHRoaW5r LCByZWZlcnMgdG8gd2hhdCBtdXN0IGJlIGltcGxlbWVudGVkIGluIGEgV2ViUlRDIHN0YWNrIHdo ZXJlYXMsIEkgdGhpbmssIHdlIGFyZSB0YWxraW5nIGFib3V0IHdoYXQgbXVzdCBiZSBpbiBhbiBT RFAgb2ZmZXIuPiA+IEJlc3QgcmVnYXJkcz4gPiBKYW1lcz4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPiBGcm9tOiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pj4gU2VudDogMDQgU2Vw dGVtYmVyIDIwMTkgMTQ6NTQ+IFRvOiBQYXVsIEt5eml2YXQ+IENjOiBydW1AaWV0Zi5vcmc+IFN1 YmplY3Q6IFJlOiBbUnVtXSBDb2RlYyByZXF1aXJlbWVudHMgaW4gZHJhZnQtcm9zZW4tcnVlLTAx PiA+IEkgdGhpbmsgb3VyIGNvbnNlbnN1cyBpcyBNVEk6PiBBdWRpbzogRy43MTEgYW5kIE9wdXM+ IFZpZGVvOiBILjI2ND4gPiBXZSBuZWVkIHRvIGdldCBpbnRvIHRoZSBkZXRhaWxzIG9mIEguMjY0 IHRvIG1haW50YWluIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgV2ViUlRDIHNwZWNzIGFuZCBhcyBt dWNoIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFzIHBvc3NpYmxlLj4gPiBBbnlvbmUgb2JqZWN0 Pz4gPiA+ID4+IE9uIFNlcCAzLCAyMDE5LCBhdCAxMDo0OCBBTSwgUGF1bCBLeXppdmF0IDxwa3l6 aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOj4+ID4+IE9uIDkvMi8xOSA0OjM5IEFNLCBKYW1lcyBI YW1saW4gd3JvdGU6Pj4+IEp1c3QgdG8gYWRkOiB0aGUgVlJTIGluZHVzdHJ5IHN1cHBvcnRzIGEg dmFyaWV0eSBvZiBlbmRwb2ludHMsIG1hbnkgb2Ygd2hpY2ggYXJlIGhhcmR3YXJlIGJhc2VkIGFu ZCBub3QgYnVpbHQgYnkgVlJTIHByb3ZpZGVycyB0aGVtc2VsdmVzLiBILjI2NCBhbmQgRy4uNzEx IHRoZXJlZm9yZSBuZWVkIHRvIGJlIGluIHRoZSBNVEkgbGlzdC4+Pj4gSSBiZWxpZXZlIHRoZSBG Q0Mgb3JkZXIgcmVsYXRlZCB0byBjb21wZW5zYXRpb24gYnkgY29tcGxpYW50IHByb3ZpZGVycyBu b3QgdGhhdCBldmVyeSBjYWxsIGhhZCB0byBjb21lIGZyb20gYSBjb21wbGlhbnQgZW5kcG9pbnQu Pj4gPj4gU29ycnkgaWYgSSBnb3QgdGhhdCB3cm9uZy4gSSB3cm90ZSB0aGF0IGZyb20gbWVtb3J5 IGFuZCBwZXJoYXBzIG15IG1lbW9yeSBpcyBmYXVsdHkuPj4gPj7CoMKgwqDCoMKgIFRoYW5rcyw+ PsKgwqDCoMKgwqAgUGF1bD4+ID4+PiBCZXN0IFJlZ2FyZHM+Pj4gSmFtZXM+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXz4+PiBGcm9tOiBSdW0gPHJ1bS1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLi5taXQu ZWR1Pj4+PiBTZW50OiAyOCBBdWd1c3QgMjAxOSAxNjo0OD4+PiBUbzogcnVtQGlldGYub3JnPj4+ IFN1YmplY3Q6IFJlOiBbUnVtXSBDb2RlYyByZXF1aXJlbWVudHMgaW4gZHJhZnQtcm9zZW4tcnVl LTAxPj4+IE9uIDgvMjgvMTkgMTE6MjUgQU0sIEVyaWMgQnVyZ2VyIHdyb3RlOj4+Pj4gSSBndWVz cyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50IHRvZGF54oCZcyBkZXZpY2VzIHRvIGhh dmUgYSBjaGFuY2Ugb2YgYmVpbmcgUlVNIGNvbXBhdGlibGUuIEkgZG9u4oCZdCB0aGluayBhbnlv bmUgd2lsbCBiZSBzdXJwcmlzZWQgaWYgYSBmaXZlLXllYXItb2xkIGRldmljZSBpcyBoaXN0b3J5 LiBJcyBpdCByZWFsaXN0aWMgZm9yIGN1cnJlbnQgZGV2aWNlcyB0byBnZXQgVlA4IHVwZ3JhZGU/ IFtXb3VsZCBiZSBuaWNlIGZvciBzb21lIG1hbnVmYWN0dXJlcnMgb3Igb3RoZXJzIGJ1aWxkaW5n IHN1Y2ggZGV2aWNlcyB0byBwaXBlIGluIGhlcmUuXT4+PiBMZXRzIGJlIGNsZWFyIGFib3V0IHdo YXQgd2UgbWVhbiBieSAiUlVNIGNvbXBhdGlibGUiLj4+PiBXaGVuIEhlbm5pbmcgYW5kIEkgd2Vy ZSB3b3JraW5nIG9uIHRoaXMgd2l0aCB0aGUgcHJvdmlkZXJzIGluIDIwMTQgYW5kPj4+IDIwMTUg dGhlcmUgd2FzIGFuIGV4cGVjdGF0aW9uIHRoYXQgdGhlIHByb3ZpZGVycyB3b3VsZCBiZSByZXF1 aXJlZCB0bz4+PiBzdXBwb3J0IHRoZSBkZWZpbmVkIFJVRSBkZXZpY2VzLCBidXQgdGhleSB3b3Vs ZCBhbHNvIGJlIHBlcm1pdHRlZCB0bz4+PiBzdXBwb3J0IHRoZWlyIGV4aXN0aW5nIHByb3ByaWV0 YXJ5IGRldmljZXMuIFRoZSBSVUUgZGV2aWNlcyBjb3VsZCBoYXZlPj4+IHJlcXVpcmVtZW50cyB0 aGF0IHRoZWlyIGV4aXN0aW5nIGRldmljZXMgZG9uJ3QgbWVldC4gQnV0IGNhbGxzIGJldHdlZW4+ Pj4gdGhlIHR3byB3ZXJlIGV4cGVjdGVkIHRvIHdvcmsuPj4+IFRoZXJlIHdhcyBncmVhdCBjb25z dGVybmF0aW9uIHdoZW4gc3Vic2VxdWVudGx5IHRoZSBGQ0MgaXNzdWVkIGE+Pj4gcHJvcG9zZWQg b3JkZXIgdGhhdCBzYWlkIG9ubHkgVlJTIGNhbGxzIGludm9sdmluZyBSVUUtY29tcGF0aWJsZSBk ZXZpY2VzPj4+IHdvdWxkIGJlIGNvbXBlbnNhdGVkLiAoQnV0IHRoYXQgd2FzIGluIDIwMTUuIEkg cHJlc3VtZSBpdCBoYXMgbm90IGhhcHBlbmVkLik+Pj4gSWYgdGhlcmUgaXMgYW4gaW50ZW50IHRv IGV4Y2x1ZGUgbm9uLVJVTS1jb21wbGlhbnQgZGV2aWNlcyBmcm9tIHVzZSBpbj4+PiBWUlMgY2Fs bHMgdGhlbiB0aGVyZSBuZWVkcyB0byBiZSBhIG1pZ3JhdGlvbiBwbGFuIHRvIGdldCBmcm9tIGhl cmUgdG8gdGhlcmUuPj4+wqDCoMKgwqDCoMKgwqAgVGhhbmtzLD4+PsKgwqDCoMKgwqDCoMKgIFBh dWw+Pj4+PiBPbiBBdWcgMjgsIDIwMTksIGF0IDEwOjM4IEFNLCBCcmlhbiBSb3NlbiA8YnJAYnJp YW5yb3Nlbi5uZXQ+IHdyb3RlOj4+Pj4+ID4+Pj4+IElmIHdlIHJlcXVpcmUgT1BVUyBhbmQgRy43 MTEgYXMgTVRJIGFuZCB3ZSByZXF1aXJlIGJvdGggSC4yNjQgYW5kIFZQOCBhcyBNVEksIHRoZW4g d2UgZ2V0IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGhvdXQgdHJhbnNjb2RpbmcgYW5kIGZv cndhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCBXZWJSVEMuwqAgSXNu4oCZdCB0aGF0IHdoYXQgd2Ug d2FudD8+Pj4+PiA+Pj4+PiBCcmlhbj4+Pj4+ID4+Pj4+PiBPbiBBdWcgMjgsIDIwMTksIGF0IDEw OjE1IEFNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6Pj4+Pj4+ ID4+Pj4+PiBJbmxpbmUuLi4+Pj4+Pj4gPj4+Pj4+IE9uIDgvMjcvMTkgNTo1NyBQTSwgQWRhbSBS b2FjaCB3cm90ZTo+Pj4+Pj4+IEkgY2VydGFpbmx5IGhhdmUgdGhvdWdodHMuIFRoZSBleGVjdXRp dmUgc3VtbWFyeSBpcyB0aGF0IEkgcGVyc29uYWxseSBiZWxpZXZlIFJVTSBzaG91bGQgc3BlY2lm eSBPcHVzIGFzIHRoZSBvbmUgYXVkaW8gY29kZWMgTVRJLCBhbmQgbWF0Y2ggUkZDIDc3NDIncyAi Tm9uLUJyb3dzZXIiIHJlcXVpcmVtZW50cyBmb3IgdGhlIHZpZGVvIGNvZGVjIE1USS4gUmF0aW9u YWxlIGJlbG93Lj4+Pj4+Pj4gRnJvbSBhbiBpbnRlcm9wIHBlcnNwZWN0aXZlLCB0aGUgaW1wb3J0 YW50IHRoaW5nIGlzIHRoYXQgYW55IGdpdmVuIHByb2ZpbGUgaGFzIChhdCBsZWFzdCkgb25lIE1U SSB2aWRlbyBjb2RlYyBhbmQgKGF0IGxlYXN0KSBvbmUgTVRJIGF1ZGlvIGNvZGVjLi4gSSBrbm93 IHRoZXJlIGlzIGEgc3Ryb25nIGRlc2lyZSAtLSBvbmUgdGhhdCBJIHNoYXJlIC0tIHRoYXQgdGhl c2UgZW5kcG9pbnRzIGNhbiB0YWxrIHRvL2JlIGltcGxlbWVudGVkIGluIHdlYiBicm93c2VycyB3 aXRob3V0IHRoZSBuZWVkIGZvciBtZWRpYSB0cmFuc2NvZGluZy4+Pj4+Pj4+IEZvciBhdWRpbzog V2ViUlRDIHNlbGVjdGVkIEcuNzExIGFuZCBPcHVzIGFzIGJvdGggTVRJOyB0aGUgZm9ybWVyIGJl Y2F1c2UgaXQgd29ya3Mgd2l0aG91dCB0cmFuc2NvZGluZyB0byBsYW5kbGluZSBQU1ROIGRlc3Rp bmF0aW9ucywgYW5kIHRoZSBsYXR0ZXIgYmVjYXVzZSBpdCBzb3VuZHMgbXVjaCwgbXVjaCBiZXR0 ZXIuIFJVTSBjb3VsZCBtYWtlIHRoZSBzYW1lIGRlY2lzaW9uOyBvciBpdCBjb3VsZCBkZWNpZGUg dG8gbW92ZSBhd2F5IGZyb20gYSBjb2RlYyB0aGF0IGlzIGFzIG9sZCBhcyBJIGFtIGFuZCBvcHQg dG8gZGVzaWduYXRlIE9wdXMgYXMgdGhlIG9ubHkgTVRJLiBHaXZlbiB0aGF0IFJVTSBpbmhlcmVu dGx5IG5lZWRzIHRvIGRlcGxveSBpbnRvIGF1ZGlvL3ZpZGVvIGVudmlyb25tZW50cywgYmFja3dh cmRzIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgUFNUTiBzZWVtcyB0byBiZSB1bm5lY2Vzc2FyeSBi YWdnYWdlLj4+Pj4+PiA+Pj4+Pj4gUGxlYXNlIGtlZXAgaW4gbWluZCB3aGVyZSB3ZSBhcmUgY29t aW5nIGZyb20uIFRoZSBSVU0gd2lsbCBiZSBhIG5ldyBpbnRlcmZhY2UgdG8gdGhlICpleGlzdGlu ZyogVlJTIGluZnJhc3RydWN0dXJlLiBUaGF0IGluZnJhc3RydWN0dXJlIGN1cnJlbnRseSBoYXMg cHJvcHJpZXRhcnkgZGV2aWNlcyB0aGF0IHNlcnZlIHRoZSBSVUUgZnVuY3Rpb24sIGRlcGxveWVk IHRvIFZSUyB1c2VycyBhbmQgdG8gQ29tbXVuaWNhdGlvbnMgQXNzaXN0YW50cyAoQ0FzLCBJbnRl cnByZXRlcnMpLiBUaGVzZSBoYXZlIEcuNzExIE1USSwgYW5kIGFsc28gKnJlY29tbWVuZCogRy43 MjIuMi4+Pj4+Pj4gPj4+Pj4+IE1ha2luZyBPUFVTIHRoZSBvbmx5IE1USSBhdWRpbyBjb2RlYyB3 b3VsZCBiZSBwcm9ibGVtYXRpYy4+Pj4+Pj4gPj4+Pj4+PiBGb3IgdmlkZW86IFdoaWxlIHNwZWNp ZnlpbmcgZWl0aGVyIFZQOCBvciBILjI2NCB3b3VsZCBiZSBzdWZmaWNpZW50IGZvciBzeXN0ZW0g aW50ZXJvcCwgYW5kIGZvciBpbnRlcm9wIHdpdGggY29tcGxpYW50IFdlYlJUQyBlbmRwb2ludHMs IEknZCByZWFsbHkgcHJlZmVyIG5vdCB0byByZS1saXZlIHRoZSBXZWJSVEMgdmlkZW8gY29kZWMg d2Fycy4gQ29uY3JldGVseSwgd2hhdCBJIHdvdWxkIHByb3Bvc2UgaXMgdGhhdCBSVU0gaW5kaWNh dGUgdGhhdCB0aGUgdmlkZW8gY29kZWMgcmVxdWlyZW1lbnRzIGFyZSBkZWZpbmVkIHRvIGJlIGlk ZW50aWNhbCB0byB0aG9zZSBkZWZpbmVkIGZvciAiV2ViUlRDIE5vbi1Ccm93c2VycyIgaW4gU2Vj dGlvbiA1IG9mIFJGQyA3NzQyLiBJdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0aGF0IFJVTSBlbmRw b2ludHMgKmFyZSogKm5vdCogV2ViUlRDIE5vbi1Ccm93c2VycyBwZXIgc2U7IG1lcmVseSB0aGF0 IHRoZXkgY29tcGx5IHdpdGggdGhlIHNhbWUgdmlkZW8gY29kZWMgcmVxdWlyZW1lbnRzIGFzIFdl YlJUQyBOb24tQnJvd3NlcnMuPj4+Pj4+ID4+Pj4+PiBDb250aW51aW5nIG15IGNvbW1lbnQgYWJv dmUsIGV4aXN0aW5nIGRldmljZXMgaGF2ZSBILjI2NCBDb25zdHJhaW5lZCBCYXNlbGluZSBQcm9m aWxlLCBMZXZlbCAxLjMsIHBhY2tldGl6YXRpb24gbW9kZSAxIGFzIHRoZSBNVEkgY29kZWMuIE9k ZHMgYXJlIG1hbnkgb2YgdGhlc2UgZGV2aWNlcyBhcmVuJ3QgY2FwYWJsZSBvZiBWUDguPj4+Pj4+ ID4+Pj4+PiBXZSBjYW4ndCByZWFsaXN0aWNhbGx5IHJlcXVpcmUgYSB3aG9sZXNhbGUgc3dhcCBv dXQgb2YgZXhpc3RpbmcgZGV2aWNlcyBiZWZvcmUgdGhlIFJVRSBkZWZpbmVkIGJ5IFJVTSBjYW4g d29yay4gV2UgY2FuICpkaXNjdXNzKiB3aGV0aGVyIGZvcmNpbmcgdGhlIHByb3ZpZGVycyB0byB0 cmFuc2NvZGUgaXMgYSBwcmFjdGljYWwgd2F5IGZvcndhcmQuIEknbSBkdWJpb3VzLj4+Pj4+PiA+ Pj4+Pj7CoMKgwqAgVGhhbmtzLD4+Pj4+PsKgwqDCoCBQYXVsPj4+Pj4+ID4+Pj4+Pj4gL2E+Pj4+ Pj4+IE9uIDgvMjcvMTkgMjozNCBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6Pj4+Pj4+Pj4gV2VsbCwg d2UgY2VydGFpbmx5IHdhbnQgaW50ZXJvcGVyYWJpbGl0eSwgYW5kIEkgdGhpbmsgd2UgY2FuIG9u bHkgZ2V0IHRoYXQgd2l0aCBNVEkgY29kZWNzLj4+Pj4+Pj4+ID4+Pj4+Pj4+IEkgdGhpbmsgd2Ug cmVhbGx5IGFyZSB0YWxraW5nIGFib3V0IGEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQsIGJ1 dCB3ZSB3YW50IGludGVyb3BlcmFiaWxpdHkgd2l0aCBhIFdlYlJUQyBicm93c2VyIGVuZHBvaW50 Lj4+Pj4+Pj4+ID4+Pj4+Pj4+IE5vdCBzdXJlIGhvdyB0byBzYXkgdGhpcy7CoCBNYXliZSBBZGFt IGNhbiBoZWxwLj4+Pj4+Pj4+ID4+Pj4+Pj4+IEJyaWFuPj4+Pj4+Pj4gPj4+Pj4+Pj4+IE9uIEF1 ZyAxMiwgMjAxOSwgYXQgNDoyMCBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5l ZHU+IHdyb3RlOj4+Pj4+Pj4+PiA+Pj4+Pj4+Pj4gZHJhZnQtcm9zZW4tcnVlLTAxIGNoYW5nZXMg dGhlIHZpZGVvIGNvZGVjIHJlcXVpcmVtZW50cy4gSXQgbm93IHNpbXBseSByZWZlcmVuY2VzIHdl YnJ0YyBSRkM3NzQyLj4+Pj4+Pj4+PiA+Pj4+Pj4+Pj4gUkZDNzc0MiBkaXN0aW5ndWlzaGVzIHRo cmVlIHR5cGVzIG9mIGVuZHBvaW50czogIldlYlJUQyBicm93c2VyIiwgIldlYlJUQyBub24tYnJv d3NlciIsIGFuZCAiV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQiLiBBRkFJSyBpdCBhc3N1bWVz IHRoYXQgZWFjaCBlbmQgaXMgb25lIG9mIHRoZXNlLj4+Pj4+Pj4+PiA+Pj4+Pj4+Pj4gSXMgdGhl IGV4cGVjdGF0aW9uIGhlcmUgdGhhdCBib3RoIHRoZSBSVUUgYW5kIHRoZSBwcm92aWRlciBjb21w bHkgd2l0aCBvbmUgb2YgdGhlc2U/IEluIHBhcnRpY3VsYXIsIHRoYXQgdGhlIHByb3ZpZGVyIG1h eSBzaW1wbHkgYmUgYSAiV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQ/IE5vdGFibHk6Pj4+Pj4+ Pj4+ID4+Pj4+Pj4+PsKgwqAgIldlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50cyIgYXJlIGZyZWUg dG8gaW1wbGVtZW50IGFueSB2aWRlbyBjb2RlY3M+Pj4+Pj4+Pj7CoMKgIHRoZXkgc2VlIGZpdC7C oCBUaGlzIGZvbGxvd3MgbG9naWNhbGx5IGZyb20gdGhlIGRlZmluaXRpb24gb2YgIldlYlJUQy0+ Pj4+Pj4+Pj7CoMKgIGNvbXBhdGlibGUgZW5kcG9pbnQiLsKgIEl0IGlzLCBvZiBjb3Vyc2UsIGFk dmlzYWJsZSB0byBpbXBsZW1lbnQgYXQ+Pj4+Pj4+Pj7CoMKgIGxlYXN0IG9uZSBvZiB0aGUgdmlk ZW8gY29kZWNzIHRoYXQgaXMgbWFuZGF0ZWQgZm9yIFdlYlJUQyBicm93c2Vycyw+Pj4+Pj4+Pj7C oMKgIGFuZCBpbXBsZW1lbnRvcnMgYXJlIGVuY291cmFnZWQgdG8gZG8gc28uPj4+Pj4+Pj4+ID4+ Pj4+Pj4+PiBTaW1pbGFybHksIHRoZSBhdWRpbyByZXF1aXJlbWVudHMgaGF2ZSBiZWVuIGNoYW5n ZWQgdG8gcmVmZXJlbmNlIHdlYnJ0YyBSRkM3ODc0LiBUaGF0IG9uZSBkb2Vzbid0IGhhdmUgdGhl IGRpc3RpbmN0aW9uIGJldHdlZW4gIldlYlJUQyBicm93c2VyIiwgIldlYlJUQyBub24tYnJvd3Nl ciIsIGFuZCAiV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQiLiBJdCBhcHBsaWVzIHRoZSBzYW1l IHJlcXVpcmVtZW50cyB0byBhbGwuIEluIHBhcnRpY3VsYXIsIGl0IHJlcXVpcmVzIE9QVVMgc3Vw cG9ydC4gSSBkb24ndCBrbm93IHdoeSBpdCBkb2Vzbid0IG1ha2UgdGhlIHNhbWUgZW5kcG9pbnQg ZGlzdGluY3Rpb25zIGFzIGZvciB2aWRlby4+Pj4+Pj4+Pj4gPj4+Pj4+Pj4+IEkgdGhpbmsgc2lt cGx5IHJlZmVyZW5jaW5nIHRoZXNlIGRvY3VtZW50cyBpc24ndCBzdWZmaWNpZW50LiBTZWVtcyBs aWtlIHdlIG5lZWQgYSBtb3JlIG51YW5jZWQgc3BlY2lmaWNhdGlvbiBvZiB3aGF0IGlzIHJlcXVp cmVkLCB0aG91Z2ggd2UgbWF5IHN0aWxsIHJlZmVyZW5jZSB0aGVzZSBkb2NzIHdpdGggcXVhbGlm aWNhdGlvbnMuPj4+Pj4+Pj4+ID4+Pj4+Pj4+PsKgwqDCoCBUaGFua3MsPj4+Pj4+Pj4+wqDCoMKg IFBhdWw+Pj4+Pj4+Pj4gPj4+Pj4+Pj4+ID4+Pj4+PiA+Pj4+PiA+Pj4+PiAtLT4+Pj4+IFJ1bSBt YWlsaW5nIGxpc3Q+Pj4+PiBSdW1AaWV0Zi5vcmc+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J1bT4+Pj4gPj4+PiA+Pj4gLS0+Pj4gUnVtIG1haWxpbmcgbGlzdD4+ PiBSdW1AaWV0Zi5vcmc+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dW0+PiA+PiAtLT4+IFJ1bSBtYWlsaW5nIGxpc3Q+PiBSdW1AaWV0Zi5vcmc+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bT4gPiAtLT4gUnVtIG1haWxpbmcgbGlzdD4g UnVtQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bS0t IFJ1bSBtYWlsaW5nIGxpc3RSdW1AaWV0Zi5vcmdodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J1bQ== ----_com.samsung.android.email_405862085696590 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5UaGF0J3MgdGhlIGJlYXV0eSBvZiBNVEkuIE9sZCwgb2xkIGVxdWlwbWVudCB3aWxsIGlu dGVyb3BlcmF0ZSAoRy43MTEpIGFuZCBhcyB0aGUgYmFzZSB1cGdyYWRlcyAvIG5ldyB1c2VycyBh cHBlYXIsIHRoZXkgZ2V0IHRoZSBiZW5lZml0IG9mIDQ2IHllYXJzIG9mIGNvZGVjIGRldmVsb3Bt ZW50LiZuYnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8i Pkl0J3Mgbm90IDE5NzIgYW55IG1vcmUuLi48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAi IGRpcj0iYXV0byI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAw MCIgZGlyPSJhdXRvIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IEJyaWFuIFJvc2VuICZsdDtickBi cmlhbnJvc2VuLm5ldCZndDsgPC9kaXY+PGRpdj5EYXRlOiA5LzQvMTkgIDI6NTQgUE0gIChHTVQt MDU6MDApIDwvZGl2PjxkaXY+VG86IEphbWVzIEhhbWxpbiAmbHQ7amFtZXMuaGFtbGluQHB1cnBs ZS51cyZndDsgPC9kaXY+PGRpdj5DYzogcnVtQGlldGYub3JnLCBQYXVsIEt5eml2YXQgJmx0O3Br eXppdmF0QGFsdW0ubWl0LmVkdSZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW1J1bV0gQ29k ZWMgcmVxdWlyZW1lbnRzIGluIGRyYWZ0LXJvc2VuLXJ1ZS0wMSA8L2Rpdj48ZGl2Pjxicj48L2Rp dj48L2Rpdj5JIGJlbGlldmUgd2F5IHRoZSBzcGVjIHJlYWRzLCBpdOKAmXMgTVRJLCBhbmQgYWxz byBtYW5kYXRvcnkgdG8gb2ZmZXIgaW4gU0RQLiZuYnNwOyBBZGFtLCBjYW4geW91IGNvbmZpcm0/ PGJyPjxicj5JZiBydWUgY2FsbHMgb2xkIG1hY2hpbmUsIHJ1ZSBvZmZlcnMgRy43MTEgYW5kIE9Q VVMuJm5ic3A7IE9sZCBtYWNoaW5lIGFuc3dlcnMgRy43MTE8YnI+SWYgb2xkIG1hY2hpbmUgY2Fs bHMgcnVlLCBvbGQgbWFjaGluZSBvZmZlcnMgRy43MTEgYW5kIHJ1ZSBhbnN3ZXJzIEcuNzExPGJy Pjxicj5JZiBJ4oCZbSBtaXN0YWtlbiwgSSBoYXZlIG5vIHByb2JsZW0gcmVxdWlyaW5nIG9mZmVy cyB0byBoYXZlIEcuNzExIGFuZCBILjI2NCAoYW5kIDQxMDMpLjxicj48YnI+QnJpYW48YnI+PGJy PiZndDsgT24gU2VwIDQsIDIwMTksIGF0IDE6NTIgUE0sIEphbWVzIEhhbWxpbiAmbHQ7amFtZXMu aGFtbGluQHB1cnBsZS51cyZndDsgd3JvdGU6PGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgSSB0 aGluayBtYWtpbmcgT3B1cyBtYW5kYXRvcnkgd2lsbCByZXF1aXJlIHRyYW5zY29kaW5nIGZvciBt YW55IGNhbGxzLiBHLjcxMSBpcyBsaWtlbHkgdG8gYmUgdGhlIG9ubHkgb3B0aW9uIGZvciBjYWxs cyB0aGF0IGFyZSByZWxheWVkIGFuZCB0aGVyZWZvcmUgaGF2ZSBhIFBTVE4gbGVnLiBNYWtpbmcg Ry43MTEgbWFuZGF0b3J5IGFuZCBPcHVzIHJlY29tbWVuZGVkIHdvdWxkIGFsbG93IGZvciBjYWxs cyB3aGVyZSBPcHVzIGNhbm5vdCBzZW5zaWJseSBiZSBvZmZlcmVkLjxicj4mZ3Q7IDxicj4mZ3Q7 IE1USSBhcyB0aGUgdGVybSBpcyB1c2VkIGluIHRoZSBXZWJSVEMgY29udGV4dCAoIGh0dHBzOi8v d2VicnRjZ2xvc3NhcnkuY29tL210aSApLCBJIHRoaW5rLCByZWZlcnMgdG8gd2hhdCBtdXN0IGJl IGltcGxlbWVudGVkIGluIGEgV2ViUlRDIHN0YWNrIHdoZXJlYXMsIEkgdGhpbmssIHdlIGFyZSB0 YWxraW5nIGFib3V0IHdoYXQgbXVzdCBiZSBpbiBhbiBTRFAgb2ZmZXIuPGJyPiZndDsgPGJyPiZn dDsgQmVzdCByZWdhcmRzPGJyPiZndDsgPGJyPiZndDsgSmFtZXM8YnI+Jmd0OyA8YnI+Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgRnJvbTogUnVt ICZsdDtydW0tYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJyaWFuIFJvc2VuICZs dDtickBicmlhbnJvc2VuLm5ldCZndDs8YnI+Jmd0OyBTZW50OiAwNCBTZXB0ZW1iZXIgMjAxOSAx NDo1NDxicj4mZ3Q7IFRvOiBQYXVsIEt5eml2YXQ8YnI+Jmd0OyBDYzogcnVtQGlldGYub3JnPGJy PiZndDsgU3ViamVjdDogUmU6IFtSdW1dIENvZGVjIHJlcXVpcmVtZW50cyBpbiBkcmFmdC1yb3Nl bi1ydWUtMDE8YnI+Jmd0OyA8YnI+Jmd0OyBJIHRoaW5rIG91ciBjb25zZW5zdXMgaXMgTVRJOjxi cj4mZ3Q7IEF1ZGlvOiBHLjcxMSBhbmQgT3B1czxicj4mZ3Q7IFZpZGVvOiBILjI2NDxicj4mZ3Q7 IDxicj4mZ3Q7IFdlIG5lZWQgdG8gZ2V0IGludG8gdGhlIGRldGFpbHMgb2YgSC4yNjQgdG8gbWFp bnRhaW4gY29tcGF0aWJpbGl0eSB3aXRoIHRoZSBXZWJSVEMgc3BlY3MgYW5kIGFzIG11Y2ggYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgYXMgcG9zc2libGUuPGJyPiZndDsgPGJyPiZndDsgQW55b25l IG9iamVjdD88YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyZndDsgT24gU2VwIDMs IDIwMTksIGF0IDEwOjQ4IEFNLCBQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVk dSZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBPbiA5LzIvMTkgNDozOSBBTSwg SmFtZXMgSGFtbGluIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsgSnVzdCB0byBhZGQ6IHRoZSBWUlMg aW5kdXN0cnkgc3VwcG9ydHMgYSB2YXJpZXR5IG9mIGVuZHBvaW50cywgbWFueSBvZiB3aGljaCBh cmUgaGFyZHdhcmUgYmFzZWQgYW5kIG5vdCBidWlsdCBieSBWUlMgcHJvdmlkZXJzIHRoZW1zZWx2 ZXMuIEguMjY0IGFuZCBHLi43MTEgdGhlcmVmb3JlIG5lZWQgdG8gYmUgaW4gdGhlIE1USSBsaXN0 Ljxicj4mZ3Q7Jmd0OyZndDsgSSBiZWxpZXZlIHRoZSBGQ0Mgb3JkZXIgcmVsYXRlZCB0byBjb21w ZW5zYXRpb24gYnkgY29tcGxpYW50IHByb3ZpZGVycyBub3QgdGhhdCBldmVyeSBjYWxsIGhhZCB0 byBjb21lIGZyb20gYSBjb21wbGlhbnQgZW5kcG9pbnQuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0 OyBTb3JyeSBpZiBJIGdvdCB0aGF0IHdyb25nLiBJIHdyb3RlIHRoYXQgZnJvbSBtZW1vcnkgYW5k IHBlcmhhcHMgbXkgbWVtb3J5IGlzIGZhdWx0eS48YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8YnI+Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUGF1bDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IEJl c3QgUmVnYXJkczxicj4mZ3Q7Jmd0OyZndDsgSmFtZXM8YnI+Jmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7IEZyb206IFJ1 bSAmbHQ7cnVtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBQYXVsIEt5eml2YXQg Jmx0O3BreXppdmF0QGFsdW0uLm1pdC5lZHUmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBTZW50OiAyOCBB dWd1c3QgMjAxOSAxNjo0ODxicj4mZ3Q7Jmd0OyZndDsgVG86IHJ1bUBpZXRmLm9yZzxicj4mZ3Q7 Jmd0OyZndDsgU3ViamVjdDogUmU6IFtSdW1dIENvZGVjIHJlcXVpcmVtZW50cyBpbiBkcmFmdC1y b3Nlbi1ydWUtMDE8YnI+Jmd0OyZndDsmZ3Q7IE9uIDgvMjgvMTkgMTE6MjUgQU0sIEVyaWMgQnVy Z2VyIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEkgZ3Vlc3MgdGhlIHF1ZXN0aW9uIGlzIHdo ZXRoZXIgd2Ugd2FudCB0b2RheeKAmXMgZGV2aWNlcyB0byBoYXZlIGEgY2hhbmNlIG9mIGJlaW5n IFJVTSBjb21wYXRpYmxlLiBJIGRvbuKAmXQgdGhpbmsgYW55b25lIHdpbGwgYmUgc3VycHJpc2Vk IGlmIGEgZml2ZS15ZWFyLW9sZCBkZXZpY2UgaXMgaGlzdG9yeS4gSXMgaXQgcmVhbGlzdGljIGZv ciBjdXJyZW50IGRldmljZXMgdG8gZ2V0IFZQOCB1cGdyYWRlPyBbV291bGQgYmUgbmljZSBmb3Ig c29tZSBtYW51ZmFjdHVyZXJzIG9yIG90aGVycyBidWlsZGluZyBzdWNoIGRldmljZXMgdG8gcGlw ZSBpbiBoZXJlLl08YnI+Jmd0OyZndDsmZ3Q7IExldHMgYmUgY2xlYXIgYWJvdXQgd2hhdCB3ZSBt ZWFuIGJ5ICJSVU0gY29tcGF0aWJsZSIuPGJyPiZndDsmZ3Q7Jmd0OyBXaGVuIEhlbm5pbmcgYW5k IEkgd2VyZSB3b3JraW5nIG9uIHRoaXMgd2l0aCB0aGUgcHJvdmlkZXJzIGluIDIwMTQgYW5kPGJy PiZndDsmZ3Q7Jmd0OyAyMDE1IHRoZXJlIHdhcyBhbiBleHBlY3RhdGlvbiB0aGF0IHRoZSBwcm92 aWRlcnMgd291bGQgYmUgcmVxdWlyZWQgdG88YnI+Jmd0OyZndDsmZ3Q7IHN1cHBvcnQgdGhlIGRl ZmluZWQgUlVFIGRldmljZXMsIGJ1dCB0aGV5IHdvdWxkIGFsc28gYmUgcGVybWl0dGVkIHRvPGJy PiZndDsmZ3Q7Jmd0OyBzdXBwb3J0IHRoZWlyIGV4aXN0aW5nIHByb3ByaWV0YXJ5IGRldmljZXMu IFRoZSBSVUUgZGV2aWNlcyBjb3VsZCBoYXZlPGJyPiZndDsmZ3Q7Jmd0OyByZXF1aXJlbWVudHMg dGhhdCB0aGVpciBleGlzdGluZyBkZXZpY2VzIGRvbid0IG1lZXQuIEJ1dCBjYWxscyBiZXR3ZWVu PGJyPiZndDsmZ3Q7Jmd0OyB0aGUgdHdvIHdlcmUgZXhwZWN0ZWQgdG8gd29yay48YnI+Jmd0OyZn dDsmZ3Q7IFRoZXJlIHdhcyBncmVhdCBjb25zdGVybmF0aW9uIHdoZW4gc3Vic2VxdWVudGx5IHRo ZSBGQ0MgaXNzdWVkIGE8YnI+Jmd0OyZndDsmZ3Q7IHByb3Bvc2VkIG9yZGVyIHRoYXQgc2FpZCBv bmx5IFZSUyBjYWxscyBpbnZvbHZpbmcgUlVFLWNvbXBhdGlibGUgZGV2aWNlczxicj4mZ3Q7Jmd0 OyZndDsgd291bGQgYmUgY29tcGVuc2F0ZWQuIChCdXQgdGhhdCB3YXMgaW4gMjAxNS4gSSBwcmVz dW1lIGl0IGhhcyBub3QgaGFwcGVuZWQuKTxicj4mZ3Q7Jmd0OyZndDsgSWYgdGhlcmUgaXMgYW4g aW50ZW50IHRvIGV4Y2x1ZGUgbm9uLVJVTS1jb21wbGlhbnQgZGV2aWNlcyBmcm9tIHVzZSBpbjxi cj4mZ3Q7Jmd0OyZndDsgVlJTIGNhbGxzIHRoZW4gdGhlcmUgbmVlZHMgdG8gYmUgYSBtaWdyYXRp b24gcGxhbiB0byBnZXQgZnJvbSBoZXJlIHRvIHRoZXJlLjxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxicj4mZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGF1bDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBBdWcgMjgsIDIwMTksIGF0IDEwOjM4IEFNLCBCcmlhbiBSb3Nl biAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgd2UgcmVxdWlyZSBPUFVTIGFuZCBHLjcxMSBh cyBNVEkgYW5kIHdlIHJlcXVpcmUgYm90aCBILjI2NCBhbmQgVlA4IGFzIE1USSwgdGhlbiB3ZSBn ZXQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aG91dCB0cmFuc2NvZGluZyBhbmQgZm9yd2Fy ZHMgY29tcGF0aWJpbGl0eSB3aXRoIFdlYlJUQy4mbmJzcDsgSXNu4oCZdCB0aGF0IHdoYXQgd2Ug d2FudD88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJy aWFuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg T24gQXVnIDI4LCAyMDE5LCBhdCAxMDoxNSBBTSwgUGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBh bHVtLm1pdC5lZHUmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbmxpbmUuLi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gOC8yNy8xOSA1OjU3IFBNLCBBZGFt IFJvYWNoIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgY2VydGFpbmx5 IGhhdmUgdGhvdWdodHMuIFRoZSBleGVjdXRpdmUgc3VtbWFyeSBpcyB0aGF0IEkgcGVyc29uYWxs eSBiZWxpZXZlIFJVTSBzaG91bGQgc3BlY2lmeSBPcHVzIGFzIHRoZSBvbmUgYXVkaW8gY29kZWMg TVRJLCBhbmQgbWF0Y2ggUkZDIDc3NDIncyAiTm9uLUJyb3dzZXIiIHJlcXVpcmVtZW50cyBmb3Ig dGhlIHZpZGVvIGNvZGVjIE1USS4gUmF0aW9uYWxlIGJlbG93Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEZyb20gYW4gaW50ZXJvcCBwZXJzcGVjdGl2ZSwgdGhlIGltcG9ydGFudCB0 aGluZyBpcyB0aGF0IGFueSBnaXZlbiBwcm9maWxlIGhhcyAoYXQgbGVhc3QpIG9uZSBNVEkgdmlk ZW8gY29kZWMgYW5kIChhdCBsZWFzdCkgb25lIE1USSBhdWRpbyBjb2RlYy4uIEkga25vdyB0aGVy ZSBpcyBhIHN0cm9uZyBkZXNpcmUgLS0gb25lIHRoYXQgSSBzaGFyZSAtLSB0aGF0IHRoZXNlIGVu ZHBvaW50cyBjYW4gdGFsayB0by9iZSBpbXBsZW1lbnRlZCBpbiB3ZWIgYnJvd3NlcnMgd2l0aG91 dCB0aGUgbmVlZCBmb3IgbWVkaWEgdHJhbnNjb2RpbmcuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgRm9yIGF1ZGlvOiBXZWJSVEMgc2VsZWN0ZWQgRy43MTEgYW5kIE9wdXMgYXMgYm90 aCBNVEk7IHRoZSBmb3JtZXIgYmVjYXVzZSBpdCB3b3JrcyB3aXRob3V0IHRyYW5zY29kaW5nIHRv IGxhbmRsaW5lIFBTVE4gZGVzdGluYXRpb25zLCBhbmQgdGhlIGxhdHRlciBiZWNhdXNlIGl0IHNv dW5kcyBtdWNoLCBtdWNoIGJldHRlci4gUlVNIGNvdWxkIG1ha2UgdGhlIHNhbWUgZGVjaXNpb247 IG9yIGl0IGNvdWxkIGRlY2lkZSB0byBtb3ZlIGF3YXkgZnJvbSBhIGNvZGVjIHRoYXQgaXMgYXMg b2xkIGFzIEkgYW0gYW5kIG9wdCB0byBkZXNpZ25hdGUgT3B1cyBhcyB0aGUgb25seSBNVEkuIEdp dmVuIHRoYXQgUlVNIGluaGVyZW50bHkgbmVlZHMgdG8gZGVwbG95IGludG8gYXVkaW8vdmlkZW8g ZW52aXJvbm1lbnRzLCBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSB3aXRoIHRoZSBQU1ROIHNlZW1z IHRvIGJlIHVubmVjZXNzYXJ5IGJhZ2dhZ2UuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBrZWVwIGluIG1pbmQgd2hlcmUgd2Ug YXJlIGNvbWluZyBmcm9tLiBUaGUgUlVNIHdpbGwgYmUgYSBuZXcgaW50ZXJmYWNlIHRvIHRoZSAq ZXhpc3RpbmcqIFZSUyBpbmZyYXN0cnVjdHVyZS4gVGhhdCBpbmZyYXN0cnVjdHVyZSBjdXJyZW50 bHkgaGFzIHByb3ByaWV0YXJ5IGRldmljZXMgdGhhdCBzZXJ2ZSB0aGUgUlVFIGZ1bmN0aW9uLCBk ZXBsb3llZCB0byBWUlMgdXNlcnMgYW5kIHRvIENvbW11bmljYXRpb25zIEFzc2lzdGFudHMgKENB cywgSW50ZXJwcmV0ZXJzKS4gVGhlc2UgaGF2ZSBHLjcxMSBNVEksIGFuZCBhbHNvICpyZWNvbW1l bmQqIEcuNzIyLjIuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE1ha2luZyBPUFVTIHRoZSBvbmx5IE1USSBhdWRpbyBjb2RlYyB3b3VsZCBi ZSBwcm9ibGVtYXRpYy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZvciB2aWRlbzogV2hpbGUgc3BlY2lmeWluZyBlaXRoZXIgVlA4 IG9yIEguMjY0IHdvdWxkIGJlIHN1ZmZpY2llbnQgZm9yIHN5c3RlbSBpbnRlcm9wLCBhbmQgZm9y IGludGVyb3Agd2l0aCBjb21wbGlhbnQgV2ViUlRDIGVuZHBvaW50cywgSSdkIHJlYWxseSBwcmVm ZXIgbm90IHRvIHJlLWxpdmUgdGhlIFdlYlJUQyB2aWRlbyBjb2RlYyB3YXJzLiBDb25jcmV0ZWx5 LCB3aGF0IEkgd291bGQgcHJvcG9zZSBpcyB0aGF0IFJVTSBpbmRpY2F0ZSB0aGF0IHRoZSB2aWRl byBjb2RlYyByZXF1aXJlbWVudHMgYXJlIGRlZmluZWQgdG8gYmUgaWRlbnRpY2FsIHRvIHRob3Nl IGRlZmluZWQgZm9yICJXZWJSVEMgTm9uLUJyb3dzZXJzIiBpbiBTZWN0aW9uIDUgb2YgUkZDIDc3 NDIuIEl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQgUlVNIGVuZHBvaW50cyAqYXJlKiAqbm90 KiBXZWJSVEMgTm9uLUJyb3dzZXJzIHBlciBzZTsgbWVyZWx5IHRoYXQgdGhleSBjb21wbHkgd2l0 aCB0aGUgc2FtZSB2aWRlbyBjb2RlYyByZXF1aXJlbWVudHMgYXMgV2ViUlRDIE5vbi1Ccm93c2Vy cy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgQ29udGludWluZyBteSBjb21tZW50IGFib3ZlLCBleGlzdGluZyBkZXZpY2VzIGhhdmUgSC4y NjQgQ29uc3RyYWluZWQgQmFzZWxpbmUgUHJvZmlsZSwgTGV2ZWwgMS4zLCBwYWNrZXRpemF0aW9u IG1vZGUgMSBhcyB0aGUgTVRJIGNvZGVjLiBPZGRzIGFyZSBtYW55IG9mIHRoZXNlIGRldmljZXMg YXJlbid0IGNhcGFibGUgb2YgVlA4Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBjYW4ndCByZWFsaXN0aWNhbGx5IHJlcXVpcmUgYSB3 aG9sZXNhbGUgc3dhcCBvdXQgb2YgZXhpc3RpbmcgZGV2aWNlcyBiZWZvcmUgdGhlIFJVRSBkZWZp bmVkIGJ5IFJVTSBjYW4gd29yay4gV2UgY2FuICpkaXNjdXNzKiB3aGV0aGVyIGZvcmNpbmcgdGhl IHByb3ZpZGVycyB0byB0cmFuc2NvZGUgaXMgYSBwcmFjdGljYWwgd2F5IGZvcndhcmQuIEknbSBk dWJpb3VzLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBQYXVsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAvYTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IE9uIDgvMjcvMTkgMjozNCBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlbGwsIHdlIGNlcnRhaW5seSB3YW50IGludGVy b3BlcmFiaWxpdHksIGFuZCBJIHRoaW5rIHdlIGNhbiBvbmx5IGdldCB0aGF0IHdpdGggTVRJIGNv ZGVjcy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgd2UgcmVhbGx5IGFyZSB0YWxraW5nIGFib3V0 IGEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQsIGJ1dCB3ZSB3YW50IGludGVyb3BlcmFiaWxp dHkgd2l0aCBhIFdlYlJUQyBicm93c2VyIGVuZHBvaW50Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm90IHN1 cmUgaG93IHRvIHNheSB0aGlzLiZuYnNwOyBNYXliZSBBZGFtIGNhbiBoZWxwLjxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgQnJpYW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBBdWcgMTIsIDIwMTksIGF0IDQ6MjAg UE0sIFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0OyB3cm90ZTo8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtcm9zZW4tcnVlLTAxIGNoYW5nZXMgdGhlIHZpZGVv IGNvZGVjIHJlcXVpcmVtZW50cy4gSXQgbm93IHNpbXBseSByZWZlcmVuY2VzIHdlYnJ0YyBSRkM3 NzQyLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSRkM3NzQyIGRpc3Rpbmd1aXNoZXMgdGhyZWUg dHlwZXMgb2YgZW5kcG9pbnRzOiAiV2ViUlRDIGJyb3dzZXIiLCAiV2ViUlRDIG5vbi1icm93c2Vy IiwgYW5kICJXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludCIuIEFGQUlLIGl0IGFzc3VtZXMgdGhh dCBlYWNoIGVuZCBpcyBvbmUgb2YgdGhlc2UuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElzIHRo ZSBleHBlY3RhdGlvbiBoZXJlIHRoYXQgYm90aCB0aGUgUlVFIGFuZCB0aGUgcHJvdmlkZXIgY29t cGx5IHdpdGggb25lIG9mIHRoZXNlPyBJbiBwYXJ0aWN1bGFyLCB0aGF0IHRoZSBwcm92aWRlciBt YXkgc2ltcGx5IGJlIGEgIldlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50PyBOb3RhYmx5Ojxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyAiV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9p bnRzIiBhcmUgZnJlZSB0byBpbXBsZW1lbnQgYW55IHZpZGVvIGNvZGVjczxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsgdGhleSBzZWUgZml0LiZuYnNw OyBUaGlzIGZvbGxvd3MgbG9naWNhbGx5IGZyb20gdGhlIGRlZmluaXRpb24gb2YgIldlYlJUQy08 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IGNvbXBh dGlibGUgZW5kcG9pbnQiLiZuYnNwOyBJdCBpcywgb2YgY291cnNlLCBhZHZpc2FibGUgdG8gaW1w bGVtZW50IGF0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyBsZWFzdCBvbmUgb2YgdGhlIHZpZGVvIGNvZGVjcyB0aGF0IGlzIG1hbmRhdGVkIGZvciBX ZWJSVEMgYnJvd3NlcnMsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyBhbmQgaW1wbGVtZW50b3JzIGFyZSBlbmNvdXJhZ2VkIHRvIGRvIHNvLjxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaW1pbGFybHksIHRoZSBhdWRpbyByZXF1aXJlbWVudHMgaGF2 ZSBiZWVuIGNoYW5nZWQgdG8gcmVmZXJlbmNlIHdlYnJ0YyBSRkM3ODc0LiBUaGF0IG9uZSBkb2Vz bid0IGhhdmUgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gIldlYlJUQyBicm93c2VyIiwgIldlYlJU QyBub24tYnJvd3NlciIsIGFuZCAiV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQiLiBJdCBhcHBs aWVzIHRoZSBzYW1lIHJlcXVpcmVtZW50cyB0byBhbGwuIEluIHBhcnRpY3VsYXIsIGl0IHJlcXVp cmVzIE9QVVMgc3VwcG9ydC4gSSBkb24ndCBrbm93IHdoeSBpdCBkb2Vzbid0IG1ha2UgdGhlIHNh bWUgZW5kcG9pbnQgZGlzdGluY3Rpb25zIGFzIGZvciB2aWRlby48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSSB0aGluayBzaW1wbHkgcmVmZXJlbmNpbmcgdGhlc2UgZG9jdW1lbnRzIGlzbid0IHN1 ZmZpY2llbnQuIFNlZW1zIGxpa2Ugd2UgbmVlZCBhIG1vcmUgbnVhbmNlZCBzcGVjaWZpY2F0aW9u IG9mIHdoYXQgaXMgcmVxdWlyZWQsIHRob3VnaCB3ZSBtYXkgc3RpbGwgcmVmZXJlbmNlIHRoZXNl IGRvY3Mgd2l0aCBxdWFsaWZpY2F0aW9ucy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhhbmtzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgUGF1bDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUnVtIG1haWxpbmcgbGlz dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSdW1AaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW08YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IC0tPGJyPiZn dDsmZ3Q7Jmd0OyBSdW0gbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyBSdW1AaWV0Zi5vcmc8 YnI+Jmd0OyZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVt PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyAtLTxicj4mZ3Q7Jmd0OyBSdW0gbWFpbGluZyBsaXN0 PGJyPiZndDsmZ3Q7IFJ1bUBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J1bTxicj4mZ3Q7IDxicj4mZ3Q7IC0tPGJyPiZndDsgUnVtIG1h aWxpbmcgbGlzdDxicj4mZ3Q7IFJ1bUBpZXRmLm9yZzxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnVtPGJyPjxicj4tLSA8YnI+UnVtIG1haWxpbmcgbGlzdDxi cj5SdW1AaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dW08YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_405862085696590-- From nobody Wed Sep 4 12:38:10 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 1D05B120DA3 for ; Wed, 4 Sep 2019 12:38:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SMcIBzvA4O5 for ; Wed, 4 Sep 2019 12:38:05 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (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 5BFB3120D97 for ; Wed, 4 Sep 2019 12:38:03 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx13.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 04 Sep 2019 19:37:59 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Sep 2019 12:37:55 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Wed, 4 Sep 2019 12:37:55 -0700 From: James Hamlin To: Eric Burger , "rum@ietf.org" Thread-Topic: [Rum] Codec requirements in draft-rosen-rue-01 Thread-Index: AQHVUV6wjLP/Oy7TOEegGP/2NVsbUqcP75GAgAAn6QCAARFKAIAABkIAgAANRQCAAAZWAIAG7fPMgAJvOgCAAYNjgP//x8HtgACMIoCAAAXaAP//j3xW Date: Wed, 4 Sep 2019 19:37:55 +0000 Message-ID: <1567625874574.45183@purple.us> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_156762587457445183purpleus_" MIME-Version: 1.0 X-BESS-ID: 1567625876-893024-10512-338429-1 X-BESS-VER: 2019.1_20190823.2224 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.218063 [from cloudscan17-141.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 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: Wed, 04 Sep 2019 19:38:09 -0000 --_000_156762587457445183purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just wanted to be clear that we aren't requiring the VRS provider's side to= offer Opus. Thanks ________________________________ From: Rum on behalf of Eric Burger Sent: 04 September 2019 20:15 To: rum@ietf.org Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 That's the beauty of MTI. Old, old equipment will interoperate (G.711) and = as the base upgrades / new users appear, they get the benefit of 46 years o= f codec development. It's not 1972 any more... -------- Original message -------- From: Brian Rosen Date: 9/4/19 2:54 PM (GMT-05:00) To: James Hamlin Cc: rum@ietf.org, Paul Kyzivat Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 I believe way the spec reads, it=92s MTI, and also mandatory to offer in SD= P. Adam, can you confirm? If rue calls old machine, rue offers G.711 and OPUS. Old machine answers G= .711 If old machine calls rue, old machine offers G.711 and rue answers G.711 If I=92m mistaken, I have no problem requiring offers to have G.711 and H.2= 64 (and 4103). Brian > On Sep 4, 2019, at 1:52 PM, James Hamlin wrote: > > > I think making Opus mandatory will require transcoding for many calls. G.= 711 is likely to be the only option for calls that are relayed and therefor= e have a PSTN leg. Making G.711 mandatory and Opus recommended would allow = for calls where Opus cannot sensibly be offered. > > MTI as the term is used in the WebRTC context ( https://webrtcglossary.co= m/mti ), I think, refers to what must be implemented in a WebRTC stack wher= eas, I think, we are talking about what must be in an SDP offer. > > Best regards > > James > > ________________________________________ > From: Rum on behalf of Brian Rosen > Sent: 04 September 2019 14:54 > To: Paul Kyzivat > Cc: rum@ietf.org > Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 > > I think our consensus is MTI: > Audio: G.711 and Opus > Video: H.264 > > We need to get into the details of H.264 to maintain compatibility with t= he 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 a= nd 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 memor= y 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=92s devices to have a ch= ance 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 ge= t VP8 upgrade? [Would be nice for some manufacturers or others building suc= h 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 device= s >>> would be compensated. (But that was in 2015. I presume it has not happe= ned.) >>> 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 t= here. >>> 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 forwar= ds compatibility with WebRTC. Isn=92t that what we want? >>>>> >>>>> Brian >>>>> >>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat w= rote: >>>>>> >>>>>> Inline... >>>>>> >>>>>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>>>>> I certainly have thoughts. The executive summary is that I personal= ly believe RUM should specify Opus as the one audio codec MTI, and match RF= C 7742's "Non-Browser" requirements for the video codec MTI. Rationale belo= w. >>>>>>> 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 cod= ec.. I know there is a strong desire -- one that I share -- that these endp= oints 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 b= ecause it works without transcoding to landline PSTN destinations, and the = latter because it sounds much, much better. RUM could make the same decisio= n; 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 d= eploy 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 current= ly has proprietary devices that serve the RUE function, deployed to VRS use= rs and to Communications Assistants (CAs, Interpreters). These have G.711 M= TI, 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 r= eally 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 d= efined to be identical to those defined for "WebRTC Non-Browsers" in Sectio= n 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* Web= RTC 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 a= re many of these devices aren't capable of VP8. >>>>>> >>>>>> We can't realistically require a wholesale swap out of existing devi= ces before the RUE defined by RUM can work. We can *discuss* whether forcin= g 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 s= imply references webrtc RFC7742. >>>>>>>>> >>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser",= "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes t= hat 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 "WebRT= C-compatible endpoint? Notably: >>>>>>>>> >>>>>>>>> "WebRTC-compatible endpoints" are free to implement any video c= odecs >>>>>>>>> they see fit. This follows logically from the definition of "W= ebRTC- >>>>>>>>> compatible endpoint". It is, of course, advisable to implement= at >>>>>>>>> least one of the video codecs that is mandated for WebRTC brows= ers, >>>>>>>>> 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 brows= er", "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. Seem= s 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 > > -- > 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 --_000_156762587457445183purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Just wanted to be clear that we aren't requiring the VRS provider's side= to offer Opus.


Thanks


From: Rum <rum-bounces= @ietf.org> on behalf of Eric Burger <eburger@standardstrack.com> Sent: 04 September 2019 20:15
To: rum@ietf.org
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
 
That's the beauty of MTI. Old, old equipment will interop= erate (G.711) and as the base upgrades / new users appear, they get the ben= efit of 46 years of codec development. 

It's not 1972 any more...


-------- Original message --------
From: Brian Rosen <br@brianrosen.net>
Date: 9/4/19 2:54 PM (GMT-05:00)
To: James Hamlin <james.hamlin@purple.us>
Cc: rum@ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01

I believe way the spec reads, it=92s MTI, and also mandatory to offer in SD= P.  Adam, can you confirm?

If rue calls old machine, rue offers G.711 and OPUS.  Old machine answ= ers G.711
If old machine calls rue, old machine offers G.711 and rue answers G.711
If I=92m mistaken, I have no problem requiring offers to have G.711 and H.2= 64 (and 4103).

Brian

> On Sep 4, 2019, at 1:52 PM, James Hamlin <james.hamlin@purple.us>= ; wrote:
>
>
> I think making Opus mandatory will require transcoding for many calls.= G.711 is likely to be the only option for calls that are relayed and there= fore have a PSTN leg. Making G.711 mandatory and Opus recommended would all= ow for calls where Opus cannot sensibly be offered.
>
> MTI as the term is used in the WebRTC context ( https://webrtcglossary= .com/mti ), I think, refers to what must be implemented in a WebRTC stack w= hereas, I think, we are talking about what must be in an SDP offer.
>
> Best regards
>
> James
>
> ________________________________________
> From: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br= @brianrosen.net>
> Sent: 04 September 2019 14:54
> To: Paul Kyzivat
> Cc: rum@ietf.org
> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
>
> I think our consensus is MTI:
> Audio: G.711 and Opus
> Video: H.264
>
> We need to get into the details of H.264 to maintain compatibility wit= h 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.ed= u> 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 p= roviders 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> on behalf of Paul Kyziv= at <pkyzivat@alum..mit.edu>
>>> 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 su= rprised if a five-year-old device is history. Is it realistic for current d= evices 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 requ= ired to
>>> support the defined RUE devices, but they would also be permit= ted to
>>> support their existing proprietary devices. The RUE devices co= uld 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-compatib= le 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 fro= m 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 <br@brian= rosen.net> wrote:
>>>>>
>>>>> If we require OPUS and G.711 as MTI and we require bot= h H.264 and VP8 as MTI, then we get backwards compatibility without transco= ding and forwards compatibility with WebRTC.  Isn=92t that what we wan= t?
>>>>>
>>>>> Brian
>>>>>
>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
>>>>>>
>>>>>> Inline...
>>>>>>
>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote:
>>>>>>> I certainly have thoughts. The executive summa= ry is that I personally believe RUM should specify Opus as the one audio co= dec MTI, and match RFC 7742's "Non-Browser" requirements for the = video codec MTI. Rationale below.
>>>>>>> From an interop perspective, the important thi= ng is that any given profile has (at least) one MTI video codec and (at lea= st) one MTI audio codec.. I know there is a strong desire -- one that I sha= re -- 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 b= oth MTI; the former because it works without transcoding to landline PSTN d= estinations, 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 environment= s, 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 infr= astructure currently has proprietary devices that serve the RUE function, d= eployed 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 prob= lematic.
>>>>>>
>>>>>>> For video: While specifying either VP8 or H.26= 4 would be sufficient for system interop, and for interop with compliant We= bRTC endpoints, I'd really prefer not to re-live the WebRTC video codec war= s. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those def= ined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It shoul= d 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 ou= t of existing devices before the RUE defined by RUM can work. We can *discu= ss* 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 WebR= TC-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 Kyzi= vat <pkyzivat@alum.mit.edu> wrote:
>>>>>>>>>
>>>>>>>>> draft-rosen-rue-01 changes the video c= odec requirements. It now simply references webrtc RFC7742.
>>>>>>>>>
>>>>>>>>> RFC7742 distinguishes three types of e= ndpoints: "WebRTC browser", "WebRTC non-browser", and &= quot;WebRTC-compatible endpoint". AFAIK it assumes that each end is on= e of these.
>>>>>>>>>
>>>>>>>>> Is the expectation here that both the = RUE and the provider comply with one of these? In particular, that the prov= ider may simply be a "WebRTC-compatible endpoint? Notably:
>>>>>>>>>
>>>>>>>>>   "WebRTC-compatible en= dpoints" are free to implement any video codecs
>>>>>>>>>   they see fit.  This f= ollows logically from the definition of "WebRTC-
>>>>>>>>>   compatible endpoint".=   It is, of course, advisable to implement at
>>>>>>>>>   least one of the video cod= ecs that is mandated for WebRTC browsers,
>>>>>>>>>   and implementors are encou= raged to do so.
>>>>>>>>>
>>>>>>>>> Similarly, the audio requirements have= been changed to reference webrtc RFC7874. That one doesn't have the distin= ction between "WebRTC browser", "WebRTC non-browser", a= nd "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 endpoi= nt distinctions as for video.
>>>>>>>>>
>>>>>>>>> I think simply referencing these docum= ents isn't sufficient. Seems like we need a more nuanced specification of w= hat is required, though we may still reference these docs with qualificatio= ns.
>>>>>>>>>
>>>>>>>>>    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
>
> --
> 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
--_000_156762587457445183purpleus_-- From nobody Thu Sep 5 13:31: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 2B817120868 for ; Thu, 5 Sep 2019 13:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubq-yz3IPzRB for ; Thu, 5 Sep 2019 13:31: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 8742C120271 for ; Thu, 5 Sep 2019 13:31:28 -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 x85KVORF013902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Sep 2019 16:31:25 -0400 To: Brian Rosen , =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 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> From: Paul Kyzivat Message-ID: <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> Date: Thu, 5 Sep 2019 16:31:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.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: [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: Thu, 05 Sep 2019 20:31:31 -0000 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 Sep 10 12:53:40 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 492F912008C for ; Tue, 10 Sep 2019 12:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5rc9eO7mLD6G for ; Tue, 10 Sep 2019 12:53:36 -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 B2450120096 for ; Tue, 10 Sep 2019 12:53:36 -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 x8AJrYdo019908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Sep 2019 15:53:35 -0400 From: Paul Kyzivat To: rum@ietf.org References: Message-ID: Date: Tue, 10 Sep 2019 15:53:34 -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] Call for WG adoption of: draft-rosen-rue-01 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, 10 Sep 2019 19:53:38 -0000 Reminder, This call for adoption will end next Sunday. All responses so far have been in support, but there haven't been a lot of them. If you haven't yet responded, please do. Thanks, Paul, as RUM co-chair On 8/29/19 9:50 AM, Paul Kyzivat wrote: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg > document. This is intended to evolve into the document our charter calls > for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > >     Thanks, >     Paul Kyzivat, as RUM co-chair > From nobody Tue Sep 10 13:05:31 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 5F047120096 for ; Tue, 10 Sep 2019 13:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 CZJLnzL89Bik for ; Tue, 10 Sep 2019 13:05:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962C2120058 for ; Tue, 10 Sep 2019 13:05:29 -0700 (PDT) Received: from [10.19.10.6] (ip-54-232-239-173.texas.us.northamericancoax.com [173.239.232.54]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x8AK5OlH003230 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Sep 2019 15:05:25 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1568145926; bh=YyLtazKsFQGWCQCNnF1ZAebj0+vEmVILZo4qYUQM3oE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=v9PMH0dH9ArRvEg1zXbmGrap/t4eVJqeTT8AaIPWRGfiIfJbXFDqbTB0Yo5FWSgk/ bTccOapsES6vmmyL8yS/GDrevUJgbDDHKiQlro0hu3iMQHoNfYhjYe41WPTdpjKz/d 5vBOe+KyObIXZuaL6ePxA8bR27qyyJJOa9xmoQ5s= X-Authentication-Warning: raven.nostrum.com: Host ip-54-232-239-173.texas.us.northamericancoax.com [173.239.232.54] claimed to be [10.19.10.6] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FA6D622D-1ADD-4B8E-9853-D4585AE433C5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 10 Sep 2019 15:05:23 -0500 In-Reply-To: Cc: rum@ietf.org To: Paul Kyzivat References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 10 Sep 2019 20:05:31 -0000 --Apple-Mail=_FA6D622D-1ADD-4B8E-9853-D4585AE433C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support adoption. > On Sep 10, 2019, at 2:53 PM, Paul Kyzivat = wrote: >=20 > Reminder, >=20 > This call for adoption will end next Sunday. All responses so far have = been in support, but there haven't been a lot of them. If you haven't = yet responded, please do. >=20 > Thanks, > Paul, as RUM co-chair >=20 > On 8/29/19 9:50 AM, Paul Kyzivat wrote: >> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg = document. This is intended to evolve into the document our charter calls = for. >> Comments, pro or con, on this proposal are due by Sunday September = 15. >> Thanks, >> Paul Kyzivat, as RUM co-chair >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_FA6D622D-1ADD-4B8E-9853-D4585AE433C5 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 - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl14AgMACgkQgFZKbJXz 1A3TnA//d5xOqY1rEXfGFokBVN9kanVO7oO9zIINZ0upTNVIDy9LZqOgIm+6t6C+ nN5ywby4uYazG9vNN35kmc4lJZVGJPq2SPjBhWUPwpw3kafexrCuHJJDFwAFhHE2 s7eYRDmDVb4mnb0d1yf9A0gJKQwHy6MMWg54m5rp/7zT0D0K0/mK/jsCIUJ+/9u4 cKhSEsekgceHvHa/ze3LEC1wLeibMQHz+X97jeiNcUIAOFprRBXjk98r+6dILjFp v6G1cdKuT+uywqVq+K0yf/Kh4CmkyZdAHu1ta1vfDM6oRKv8TfR7p3ut90PnF6A6 ZtxRCnrZzKjv7LuHATKMbRlWSp7e0vOayXcujm9i+n+U1Vq8YE+OZd62eJdodnih FNhnrAdXf34exeEM9QeamQ6JG7E3OJVPcCA9VCgn1+Du6K1+Tn9V15maebOBbKm1 AC1+bkWoZyEEPdQAg4ize+WUuCXC4cTi8hsLj0I1PdI+fameEbOFrwQfqH2WvuCZ rYITwuoYiYGGYMyeN6zmGFVOZ3z9tmM2E4wUR/LsBwWhkJFU1yEy3wMioEx9zHEL A1jUlnhhp4PBGUrxmx81j9PBo5VpS5bJ41HKa1yEA5chAURzB/Ebu1A2XC2zF/V6 xBAh8wSDXxPJGHjBt4nSC34H92cwIhlYdrTIhjEQFzKvyOTw4K4= =T3CZ -----END PGP SIGNATURE----- --Apple-Mail=_FA6D622D-1ADD-4B8E-9853-D4585AE433C5-- From nobody Fri Sep 13 07:42:35 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 396D8120875 for ; Fri, 13 Sep 2019 07:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty9rnvAScPFT for ; Fri, 13 Sep 2019 07:42:30 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.103]) (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 D9240120868 for ; Fri, 13 Sep 2019 07:42:28 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx8.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 13 Sep 2019 14:42:25 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 13 Sep 2019 07:40:48 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Fri, 13 Sep 2019 07:40:48 -0700 From: James Hamlin To: "rum@ietf.org" CC: Paul Kyzivat Thread-Topic: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVakA0i+jQ6mMMhEOX6Gd2YqSgdw== Date: Fri, 13 Sep 2019 14:40:48 +0000 Message-ID: <1568385648772.69603@purple.us> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1568385740-893015-29978-26766-1 X-BESS-VER: 2019.1_20190912.1934 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.218377 [from cloudscan11-190.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 13 Sep 2019 14:42:33 -0000 Paul=0A= =0A= I think we agreed that OPUS and VP8 wouldn't need to be supported on the pr= ovider side, for good reasons. The draft proposed for adoption seems to con= tradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 .=0A= =0A= Is the procedure that the document is adopted, with some agreed changes mis= sing, and then amended?=0A= =0A= Best regards=0A= =0A= James=0A= ________________________________________=0A= From: Rum on behalf of Paul Kyzivat =0A= Sent: 10 September 2019 20:53=0A= To: rum@ietf.org=0A= Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= Reminder,=0A= =0A= This call for adoption will end next Sunday. All responses so far have=0A= been in support, but there haven't been a lot of them. If you haven't=0A= yet responded, please do.=0A= =0A= Thanks,=0A= Paul, as RUM co-chair=0A= =0A= On 8/29/19 9:50 AM, Paul Kyzivat wrote:=0A= > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=0A= > document. This is intended to evolve into the document our charter calls= =0A= > for.=0A= >=0A= > Comments, pro or con, on this proposal are due by Sunday September 15.=0A= >=0A= > Thanks,=0A= > Paul Kyzivat, as RUM co-chair=0A= >=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailma= n%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBs= Ghr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,= ,&typo=3D0=0A= From nobody Fri Sep 13 08:03:19 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 1E39A120840 for ; Fri, 13 Sep 2019 08:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sorenson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFnWO2q1NLjx for ; Fri, 13 Sep 2019 08:03:00 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710042.outbound.protection.outlook.com [40.107.71.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B3F12081B for ; Fri, 13 Sep 2019 08:02:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XCgA1am7+CHfx4wNoY5ytBWwC5A6ZTiavi2TZat0MlorycFOHe3q2oDSK8KMi5krnI2YB/uMHbYZIA5jFI+JuamagEHYu9wmdS5PvElgaooWfhY6DAvhDCikIeS2MAAeVAxztECM6cBFwnP8w0mTmge9bFfL9XryKbQ37QBvCfX+0xKIATtEyZDYhx68ivHoXG6OhRpwC7tRJBjHbaJw4z8SujStQK8JaAax0MMmvOY/BBOynuy7Kli8Ge8Z6TTImoqrx9uVUc955hpSu3UnZFWtWQJb8P0JQSaxUgPZEhZNUoOeaQ+qZxGBVDn5PtxlzEdLUtxIdPhu7lIkxFedsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tVEhYPFKKMPLhALXrgmRuPjunGhwz9TV5nb4mPPIoxs=; b=PKrYLJE0DrHU/cmdLUQzc0pJ96qr5smbbjZWUO76Iv0e2mPvN70ejzdwHr5T17lqwkTUo/N+oVcq4BGqg40KfS4LhvLqmea9prMktkZlxZTfbduqLy1qJgXJ+M88T9hu1dHA3cTtC6x9Et4FXBR5uhA+gvXbopaa1zcDBI1ZQt6fJdj07IZUcQDoIKJ+6k/Q5aK7+8I9HtmanBsxXiy89mqOg2KPPMQY7BG/zCEBowZvawO8n7n7oSXpotjVA5voYyIVzJyfQ/OU2rwlf1nRPqiQ8CoISjec6IgY8jThi8jd3OqGwtkZTkv28kQnUymuRRKJ81jvDdKCWk2sBgYMlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tVEhYPFKKMPLhALXrgmRuPjunGhwz9TV5nb4mPPIoxs=; b=A2SrRRuTGkx76tgxrNYfchKXJbOCvXyxGknPNDXccKWjQ3D/swldViEf0BwRegmJB2un1yvVo3LUL8skj59sPM5+Yqc1mfAH3eFPj1xGfpcwz6Qu4+BEc0c2fVidFGM/a9h3Ba41jP3raXwhMR2wQD7amatYdeXCVKRJw9IiMHI= Received: from MWHPR04MB0991.namprd04.prod.outlook.com (10.174.250.10) by MWHPR04MB1103.namprd04.prod.outlook.com (10.174.250.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.20; Fri, 13 Sep 2019 15:02:55 +0000 Received: from MWHPR04MB0991.namprd04.prod.outlook.com ([fe80::d03d:2cd4:1055:67df]) by MWHPR04MB0991.namprd04.prod.outlook.com ([fe80::d03d:2cd4:1055:67df%7]) with mapi id 15.20.2263.018; Fri, 13 Sep 2019 15:02:55 +0000 From: Richard Shields To: James Hamlin , "rum@ietf.org" CC: Paul Kyzivat Thread-Topic: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVaBF1VkomULJvVEmMBHrwAG6tkKcpslMAgAAEVYA= Date: Fri, 13 Sep 2019 15:02:55 +0000 Message-ID: References: , <1568385648772.69603@purple.us> In-Reply-To: <1568385648772.69603@purple.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=richard@sorenson.com; x-originating-ip: [209.169.244.29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70673784-754e-4138-5a01-08d7385b7566 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR04MB1103; x-ms-traffictypediagnostic: MWHPR04MB1103: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0159AC2B97 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(366004)(136003)(376002)(199004)(189003)(13464003)(186003)(81156014)(66066001)(8676002)(476003)(25786009)(229853002)(446003)(3846002)(561944003)(33656002)(11346002)(2906002)(14454004)(2501003)(86362001)(71190400001)(6116002)(52536014)(14444005)(256004)(66946007)(71200400001)(66446008)(64756008)(66556008)(66476007)(486006)(53936002)(66574012)(316002)(9686003)(6306002)(6246003)(966005)(478600001)(7696005)(110136005)(76116006)(76176011)(99286004)(55016002)(53546011)(6506007)(5660300002)(8936002)(26005)(6436002)(74316002)(7736002)(305945005)(102836004)(81166006)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR04MB1103; H:MWHPR04MB0991.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sorenson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0AUwzobyFkFG7r1asPO0xKVVZCjzuVEN+EmRgBFX+a6nvQgS1dbwRCnxNZRKrNfHXHYrv5CFbGv7/AaDv4jxJb6FgK7akMqlYhz0sgBVCguzqxah4rBjGImPBFQXxEjrNG0Em9m0E/RR1ua+D4foFQP/G15fNfE3hm/J4ooCCY27ywk/RNCFBZIbS87NC5fUMyUWWllQRvhk/F+iDcG1G77y7QrCTkft0r8u0eat24xnDP3jQwOJbCh5mlL2Tvf1ok7idGGM1EcAxxzUJHM0ZnR/yXJ1UIR4A2sm8VdGCshp+JAWawUBrBoaXHizEaY2SBijJfiQSFprA8W2m3yiyuTtQ+2avbqky6TsdQbhfuEZwHTHrsxhaa+qWvDkjbhUHosGSHHCmI05YTONxA8tqU65dr4zcJ3V+D9IFXTNF4A= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70673784-754e-4138-5a01-08d7385b7566 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 15:02:55.8096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JH3zMyXSHXKlfihRg/HPR5fvHq31p/QeAvV8tdMECwHJTa88QVRuAvcl+07OJOGED4R6XTX8vZralImiWWx92w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR04MB1103 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 13 Sep 2019 15:03:06 -0000 This may have been brought up before. RFC 7742, referenced in section 7.3, = has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and= a WebRTC-compatible endpoint, with different levels of MTI regarding VP8.= With the proposed RUE document, what are VRS endpoints considered? Thanks, Richard -----Original Message----- From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin Sent: Friday, September 13, 2019 8:41 AM To: rum@ietf.org Cc: Paul Kyzivat Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 [EXTERNAL]=20 Paul I think we agreed that OPUS and VP8 wouldn't need to be supported on the pr= ovider side, for good reasons. The draft proposed for adoption seems to con= tradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 . Is the procedure that the document is adopted, with some agreed changes mis= sing, and then amended? =20 Best regards James ________________________________________ From: Rum on behalf of Paul Kyzivat Sent: 10 September 2019 20:53 To: rum@ietf.org Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 Reminder, This call for adoption will end next Sunday. All responses so far have been= in support, but there haven't been a lot of them. If you haven't yet respo= nded, please do. Thanks, Paul, as RUM co-chair On 8/29/19 9:50 AM, Paul Kyzivat wrote: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=20 > document. This is intended to evolve into the document our charter=20 > calls for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > > Thanks, > Paul Kyzivat, as RUM co-chair > -- Rum mailing list Rum@ietf.org https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailma= n%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBs= Ghr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,= ,&typo=3D0 -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Fri Sep 13 08:19:34 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 DE0EB1200F9 for ; Fri, 13 Sep 2019 08:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT8yRBYB2Z1U for ; Fri, 13 Sep 2019 08:19:30 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.103]) (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 B1FFE120872 for ; Fri, 13 Sep 2019 08:19:28 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx10.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 13 Sep 2019 15:19:26 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 13 Sep 2019 08:19:22 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Fri, 13 Sep 2019 08:19:22 -0700 From: James Hamlin To: Richard Shields , "rum@ietf.org" CC: Paul Kyzivat Thread-Topic: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVakA0i+jQ6mMMhEOX6Gd2YqSgd6cqKX2A//+Msu8= Date: Fri, 13 Sep 2019 15:19:21 +0000 Message-ID: <1568387962077.82824@purple.us> References: , <1568385648772.69603@purple.us>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1568387963-893019-16580-27653-1 X-BESS-VER: 2019.1_20190912.1934 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.218378 [from cloudscan12-216.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 13 Sep 2019 15:19:33 -0000 Richard=0A= =0A= This was mentioned and I think the provider side is "WebRTC-compatible endp= oint". But the text currently in 7.3 and 7.4 treats provider and RUE identi= cally.=0A= =0A= Best regards=0A= =0A= James=0A= ________________________________________=0A= From: Richard Shields =0A= Sent: 13 September 2019 16:02=0A= To: James Hamlin; rum@ietf.org=0A= Cc: Paul Kyzivat=0A= Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= This may have been brought up before. RFC 7742, referenced in section 7.3, = has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and= a WebRTC-compatible endpoint, with different levels of MTI regarding VP8.= With the proposed RUE document, what are VRS endpoints considered?=0A= =0A= Thanks,=0A= Richard=0A= =0A= -----Original Message-----=0A= From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin=0A= Sent: Friday, September 13, 2019 8:41 AM=0A= To: rum@ietf.org=0A= Cc: Paul Kyzivat =0A= Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= [EXTERNAL]=0A= =0A= Paul=0A= =0A= I think we agreed that OPUS and VP8 wouldn't need to be supported on the pr= ovider side, for good reasons. The draft proposed for adoption seems to con= tradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 .=0A= =0A= Is the procedure that the document is adopted, with some agreed changes mis= sing, and then amended?=0A= =0A= Best regards=0A= =0A= James=0A= ________________________________________=0A= From: Rum on behalf of Paul Kyzivat =0A= Sent: 10 September 2019 20:53=0A= To: rum@ietf.org=0A= Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= Reminder,=0A= =0A= This call for adoption will end next Sunday. All responses so far have been= in support, but there haven't been a lot of them. If you haven't yet respo= nded, please do.=0A= =0A= Thanks,=0A= Paul, as RUM co-chair=0A= =0A= On 8/29/19 9:50 AM, Paul Kyzivat wrote:=0A= > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=0A= > document. This is intended to evolve into the document our charter=0A= > calls for.=0A= >=0A= > Comments, pro or con, on this proposal are due by Sunday September 15.=0A= >=0A= > Thanks,=0A= > Paul Kyzivat, as RUM co-chair=0A= >=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailma= n%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBs= Ghr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,= ,&typo=3D0=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rum=0A= =0A= From nobody Fri Sep 13 08:22:37 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 E9FC712007C for ; Fri, 13 Sep 2019 08:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sorenson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XecbqW5JpTjb for ; Fri, 13 Sep 2019 08:22:31 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700057.outbound.protection.outlook.com [40.107.70.57]) (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 7C75E120047 for ; Fri, 13 Sep 2019 08:22:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BaMxkTcMsriMdtJEKxEaFiXE5JQh7+r/TTbd8lovcJxcxBTSse2ceVh+VBLyr/TVhJ9kWWFDq3DyGjrkvqmxvdgNrLh6UglbmOhdi0WAGvRLxHMSCIrPGp1VXduiDhY88v8B7WlCXijyuOiZ0vHv+r0HIkQRt5WK/gTYQ1rYXLcFQcPjMxJ4tDJaMBCq8pHllh7pjwKiAFFshiXY4HsNPRa4VziUuT9tf59m/dPHHV33YQpz1LUvZbU0HmdCX/wrlb8kMo3FaY6VurGeo1cwOhW/3zSsbXNa3oOpk9hRIKb4RRE6alqnumCUR9zMee5i4v+2Nr3l094xwRk8xFDrPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z5JCeU1KYG2r6XbAwElRIRtmsr6MijKXS8y4Jneg/04=; b=BtDLt2fTMmfNpPANpzpX4Bu4MjbXwRAyKN/JPkNv4PTSQD7ZJhMj46gjnsX6I2m0iYp2EscEmMHWcjId8wPGi7URGHP3E/yuB4qO8iFicXW0Xgk1mtPFMN6THoRZFLdWktwZx5ZL0gZ1Wqr3hJCOjdFSveQ4goH9SYr8RaOGxPwCpspjUGnjZmyCq3nZOZ32qKhcmAtmFZ9ntLbP8YYuGXT4STQrCWRjZ9qDwXPVFCill6EDYIG8DxqBDpFa68rMIu5XQbDxU0Leag+14xBRhfDIVG0y197HY4l9DzKJwKH8LfavNQOWjwChtYD/W+aOzI5LxnNc6LkiA61bjRI5WA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z5JCeU1KYG2r6XbAwElRIRtmsr6MijKXS8y4Jneg/04=; b=jgwfaJNH1HCCtCM8WlKzU2A3oRhhzRUVQXOBsas0cxxvcKu9D2vJK7QDjjw9DxIdWkZllorbdCebOrJtrEa9SzcTChbSa5ZVHjluS5E8aXzvjm7CakWnadXJcSxcDItbm6zS5MAFXy9MMshtxNCKQLsBaBl+1R6gDqiL4gTxYhQ= Received: from MWHPR04MB0991.namprd04.prod.outlook.com (10.174.250.10) by MWHPR04MB0703.namprd04.prod.outlook.com (10.172.168.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.18; Fri, 13 Sep 2019 15:22:29 +0000 Received: from MWHPR04MB0991.namprd04.prod.outlook.com ([fe80::d03d:2cd4:1055:67df]) by MWHPR04MB0991.namprd04.prod.outlook.com ([fe80::d03d:2cd4:1055:67df%7]) with mapi id 15.20.2263.018; Fri, 13 Sep 2019 15:22:29 +0000 From: Richard Shields To: James Hamlin , "rum@ietf.org" CC: Paul Kyzivat Thread-Topic: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVaBF1VkomULJvVEmMBHrwAG6tkKcpslMAgAAEVYCAAAZxgIAAAEgQ Date: Fri, 13 Sep 2019 15:22:29 +0000 Message-ID: References: , <1568385648772.69603@purple.us>, <1568387962077.82824@purple.us> In-Reply-To: <1568387962077.82824@purple.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=richard@sorenson.com; x-originating-ip: [209.169.244.29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bf1c5bc6-b2d9-4916-694a-08d7385e3123 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR04MB0703; x-ms-traffictypediagnostic: MWHPR04MB0703: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0159AC2B97 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(396003)(136003)(199004)(189003)(13464003)(8676002)(6436002)(11346002)(486006)(66574012)(966005)(14454004)(229853002)(53546011)(6506007)(186003)(478600001)(76116006)(26005)(71190400001)(71200400001)(476003)(256004)(2501003)(55016002)(102836004)(9686003)(66066001)(305945005)(53936002)(6246003)(25786009)(2906002)(74316002)(446003)(86362001)(6306002)(4326008)(14444005)(6116002)(3846002)(7736002)(33656002)(5660300002)(7696005)(99286004)(110136005)(316002)(66476007)(66556008)(64756008)(66446008)(8936002)(52536014)(81156014)(81166006)(66946007)(76176011)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR04MB0703; H:MWHPR04MB0991.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sorenson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JoBmKNpGGE3aCcfxXxccsprJ6Bb4pM9B+aCz1ewhKiAZka5s7DYdj7BIejwvjs8hyJ5FCAbAqUvJ9iZ2kOv1nQpD4v5fjO9GbrXjv48/vW5rh20uorEO1nA7SzbbL4qdKGpa/j+sf4gDtsidPiwKV1mM+q0AYAtzOX9Qr5zVNW/YLQHxogcIOHti1Hst3ews/x3xL6pRcByDil0VJ7mNq6AZoYHQ3QAnIEFkgoYjwAVZtfbrfqk412dqBbVmX/z/tSZQMqCUOkyMqdcye5zrOi417yJTuCCkPlZKphIt8QIy+Xst5cLEGRHq+JrUy3fRlD75q1n/afABdI7qvNkyji+yLMSVC+OLwlhzLe/IfMn56JSftL/Vub0xbacU63lY+347FmYuMre2DDsIHlQGxVlxsS1L5DsWBe0hOzUk4jY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf1c5bc6-b2d9-4916-694a-08d7385e3123 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 15:22:29.7890 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ng96IvSp+wDMbDfDV7m2BO2hz1tMcTd5FABn1FQTcRcoMQjVDf4u8UvCvrokVEIcxgpbs1v4xf8sewvKQtH4JA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR04MB0703 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 13 Sep 2019 15:22:35 -0000 Thanks, James. Section 5 of RFC 7742 states this: "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. Does that not alleviate the requirement to implement VP8? Thanks, Richard -----Original Message----- From: James Hamlin [mailto:james.hamlin@purple.us]=20 Sent: Friday, September 13, 2019 9:19 AM To: Richard Shields ; rum@ietf.org Cc: Paul Kyzivat Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 [EXTERNAL]=20 Richard This was mentioned and I think the provider side is "WebRTC-compatible endp= oint". But the text currently in 7.3 and 7.4 treats provider and RUE identi= cally. Best regards James ________________________________________ From: Richard Shields Sent: 13 September 2019 16:02 To: James Hamlin; rum@ietf.org Cc: Paul Kyzivat Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 This may have been brought up before. RFC 7742, referenced in section 7.3, = has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and= a WebRTC-compatible endpoint, with different levels of MTI regarding VP8.= With the proposed RUE document, what are VRS endpoints considered? Thanks, Richard -----Original Message----- From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin Sent: Friday, September 13, 2019 8:41 AM To: rum@ietf.org Cc: Paul Kyzivat Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 [EXTERNAL] Paul I think we agreed that OPUS and VP8 wouldn't need to be supported on the pr= ovider side, for good reasons. The draft proposed for adoption seems to con= tradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 . Is the procedure that the document is adopted, with some agreed changes mis= sing, and then amended? Best regards James ________________________________________ From: Rum on behalf of Paul Kyzivat Sent: 10 September 2019 20:53 To: rum@ietf.org Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 Reminder, This call for adoption will end next Sunday. All responses so far have been= in support, but there haven't been a lot of them. If you haven't yet respo= nded, please do. Thanks, Paul, as RUM co-chair On 8/29/19 9:50 AM, Paul Kyzivat wrote: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=20 > document. This is intended to evolve into the document our charter=20 > calls for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > > Thanks, > Paul Kyzivat, as RUM co-chair > -- Rum mailing list Rum@ietf.org https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailma= n%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBs= Ghr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,= ,&typo=3D0 -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Fri Sep 13 08:55: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 0644812084B for ; Fri, 13 Sep 2019 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwACpUh4e8Pf for ; Fri, 13 Sep 2019 08:55:24 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.13]) (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 CE9D712081A for ; Fri, 13 Sep 2019 08:55:22 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx12.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 13 Sep 2019 15:55:20 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 13 Sep 2019 08:55:12 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Fri, 13 Sep 2019 08:55:12 -0700 From: James Hamlin To: Richard Shields , "rum@ietf.org" CC: Paul Kyzivat Thread-Topic: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVakA0i+jQ6mMMhEOX6Gd2YqSgd6cqKX2A//+Msu+AAHjFgP//iveL Date: Fri, 13 Sep 2019 15:55:12 +0000 Message-ID: <1568390112344.87888@purple.us> References: , <1568385648772.69603@purple.us>, <1568387962077.82824@purple.us>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1568390112-893022-12576-27830-2 X-BESS-VER: 2019.1_20190912.1934 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.218379 [from cloudscan10-39.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 13 Sep 2019 15:55:31 -0000 Richard=0A= =0A= Yes, but my understanding is that the RUE is a "WebRTC endpoint" and provid= er a "WebRTC-compatible endpoint" but the current text doesn't make any dis= tinction. =0A= =0A= I just wanted to make sure that we will establish wording that makes clear = points that are important for compatibility. =0A= =0A= Best regards=0A= =0A= James=0A= =0A= =0A= ________________________________________=0A= From: Richard Shields =0A= Sent: 13 September 2019 16:22=0A= To: James Hamlin; rum@ietf.org=0A= Cc: Paul Kyzivat=0A= Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= Thanks, James.=0A= =0A= Section 5 of RFC 7742 states this:=0A= =0A= "WebRTC-compatible endpoints" are free to implement any video codecs=0A= they see fit. This follows logically from the definition of "WebRTC-=0A= compatible endpoint". It is, of course, advisable to implement at=0A= least one of the video codecs that is mandated for WebRTC browsers,=0A= and implementors are encouraged to do so.=0A= =0A= Does that not alleviate the requirement to implement VP8?=0A= =0A= Thanks,=0A= Richard=0A= =0A= -----Original Message-----=0A= From: James Hamlin [mailto:james.hamlin@purple.us]=0A= Sent: Friday, September 13, 2019 9:19 AM=0A= To: Richard Shields ; rum@ietf.org=0A= Cc: Paul Kyzivat =0A= Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= [EXTERNAL]=0A= =0A= Richard=0A= =0A= This was mentioned and I think the provider side is "WebRTC-compatible endp= oint". But the text currently in 7.3 and 7.4 treats provider and RUE identi= cally.=0A= =0A= Best regards=0A= =0A= James=0A= ________________________________________=0A= From: Richard Shields =0A= Sent: 13 September 2019 16:02=0A= To: James Hamlin; rum@ietf.org=0A= Cc: Paul Kyzivat=0A= Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= This may have been brought up before. RFC 7742, referenced in section 7.3, = has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and= a WebRTC-compatible endpoint, with different levels of MTI regarding VP8.= With the proposed RUE document, what are VRS endpoints considered?=0A= =0A= Thanks,=0A= Richard=0A= =0A= -----Original Message-----=0A= From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin=0A= Sent: Friday, September 13, 2019 8:41 AM=0A= To: rum@ietf.org=0A= Cc: Paul Kyzivat =0A= Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= [EXTERNAL]=0A= =0A= Paul=0A= =0A= I think we agreed that OPUS and VP8 wouldn't need to be supported on the pr= ovider side, for good reasons. The draft proposed for adoption seems to con= tradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 .=0A= =0A= Is the procedure that the document is adopted, with some agreed changes mis= sing, and then amended?=0A= =0A= Best regards=0A= =0A= James=0A= ________________________________________=0A= From: Rum on behalf of Paul Kyzivat =0A= Sent: 10 September 2019 20:53=0A= To: rum@ietf.org=0A= Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= Reminder,=0A= =0A= This call for adoption will end next Sunday. All responses so far have been= in support, but there haven't been a lot of them. If you haven't yet respo= nded, please do.=0A= =0A= Thanks,=0A= Paul, as RUM co-chair=0A= =0A= On 8/29/19 9:50 AM, Paul Kyzivat wrote:=0A= > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=0A= > document. This is intended to evolve into the document our charter=0A= > calls for.=0A= >=0A= > Comments, pro or con, on this proposal are due by Sunday September 15.=0A= >=0A= > Thanks,=0A= > Paul Kyzivat, as RUM co-chair=0A= >=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailma= n%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBs= Ghr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,= ,&typo=3D0=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rum=0A= =0A= =0A= From nobody Fri Sep 13 09:04:44 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 D717E120073 for ; Fri, 13 Sep 2019 09:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sorenson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82ipg7ufeuC3 for ; Fri, 13 Sep 2019 09:04:40 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700041.outbound.protection.outlook.com [40.107.70.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8A812004A for ; Fri, 13 Sep 2019 09:04:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nFO2DUf2XzbMMulDH3oRpVkU2oYGQ/98gxvLcyxolxpvTuO/zeQHE/hLtCk25YkC+XSjKju3GDI00XslM4EvCPBqJQmlqay/FqvCfaAwxD1QQXjr8CqgG7T+eqkHyzzOD33GXUKiHeqbIh5IsYT4Vi9ukjXA98Ne2IsBeBW2m7V4PEADGJppuWKdjuvG7Hqt8llyCLtip0PoPZiG968ZhzmxvJ6Rx3uFugHFhOEbk78HSVWQmErtVK6sbo85fVPR36cgd2uF462pkxls5lwqQ1BJrWPtgTSdJk6s6Y+d5UfHUWFI9L8N7xUrrTXttZT2VcphpRLCvBXCQzA4A54cdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K5enHG6jaCjEQu/gKsMcQZIo4MPxWsHCiEKJRATTEQI=; b=eJ8QlpB6njOwDITS+ulLF7VRh+NeqbzR329dHGc7dXVOxlJ/t2DuVqv/KJ3xg++ovPal4Vx9TJ3OCiIKEzfocFkqyQ+/ty236WO591eLToBiD9k9SuewyiyiI74k4PM4jXXwKX4H0Od4hoMZgeb+kxVhxRq2g3/WCpU2RkjS+jTm6EOsHgj45GtGQwtueWYWZGPz/pZPE9KkpUpu54nueS9NJmR1AgvcWPihkqTAOtLrVkfSQTW6zvjBudhtC0ZjJUfK0OzV+rlxH++g4R0rkjE+slePpRKHV5Hkr0pwE6Ji+mrAJMsO8tc2vKZRdGdOjIM/eMr6+WYyWe8QZfHplQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K5enHG6jaCjEQu/gKsMcQZIo4MPxWsHCiEKJRATTEQI=; b=WVzKCgmQhk0Pn7PP/EOnu1zbrhjx5oyY/fk1I+QfvDLJoL9idVHmP/+14bF6xd3nvf1D2b8FXwxLTJ2bCt3JmL9nCZZVOzKLoKgqu9r4nAVPIv/HZCyPuuCDBJJnY6Gi14b2LzlWZV7H8ZErSTwnWxfjuh3hBG6oo7+I0R/rwsQ= Received: from MWHPR04MB0991.namprd04.prod.outlook.com (10.174.250.10) by MWHPR04MB0926.namprd04.prod.outlook.com (10.174.174.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15; Fri, 13 Sep 2019 16:04:29 +0000 Received: from MWHPR04MB0991.namprd04.prod.outlook.com ([fe80::d03d:2cd4:1055:67df]) by MWHPR04MB0991.namprd04.prod.outlook.com ([fe80::d03d:2cd4:1055:67df%7]) with mapi id 15.20.2263.018; Fri, 13 Sep 2019 16:04:29 +0000 From: Richard Shields To: James Hamlin , "rum@ietf.org" CC: Paul Kyzivat Thread-Topic: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVaBF1VkomULJvVEmMBHrwAG6tkKcpslMAgAAEVYCAAAZxgIAAAEgQgAAJvACAAAG9oA== Date: Fri, 13 Sep 2019 16:04:29 +0000 Message-ID: References: , <1568385648772.69603@purple.us>, <1568387962077.82824@purple.us>, <1568390112344.87888@purple.us> In-Reply-To: <1568390112344.87888@purple.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=richard@sorenson.com; x-originating-ip: [209.169.244.29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdac4c65-6ea9-40f1-cbff-08d738640f35 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MWHPR04MB0926; x-ms-traffictypediagnostic: MWHPR04MB0926: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0159AC2B97 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(376002)(366004)(396003)(199004)(189003)(13464003)(66066001)(9686003)(26005)(478600001)(81156014)(8676002)(7736002)(305945005)(8936002)(476003)(55016002)(74316002)(6436002)(81166006)(186003)(561944003)(11346002)(6306002)(33656002)(486006)(2501003)(52536014)(446003)(6246003)(76116006)(53936002)(64756008)(25786009)(66556008)(66476007)(4326008)(66946007)(229853002)(66446008)(71200400001)(102836004)(76176011)(7696005)(3846002)(6506007)(6116002)(14454004)(14444005)(316002)(256004)(99286004)(53546011)(110136005)(966005)(66574012)(5660300002)(2906002)(86362001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR04MB0926; H:MWHPR04MB0991.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sorenson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: x2bcjl1d7r9QLHFTZJGP+kU2e0MvyzDYLUgNy/qnrsfwM5nuoHToTlpIaWVa9r8bHwww7cgWTYIGPcexXQoW5KYu1kZmEbY2aOwvlS9Czn4SLKYSEwnofj78kxKg2cMvMXhZP9rlcP9y53ziCqWaPZTi0Gu/rt45/evQt3MyuP3orAu7A4wXqlMl4YwJ8fppU2r/dpIz0fcU1dCfr6xARQ3nKwB8Iv0abJJ+EtYJ0p/s0R7+1lmhs2YV7/Q7XfpIRbW7jkOPScwY/1v6VN2qY6s4v0KbtZluTcKumBXgZJjMCLGOo96YGaSuStOHczrxQXXuRqlc1Aq3dOiU50w/m5WK1lpyXlgvBhrL06DMCQHlwChn8vXrfzPpkqpyXLriyLf7iIR1/3fD/T6y03O00rXgsu2sF5iGcb6fh9uEcWM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdac4c65-6ea9-40f1-cbff-08d738640f35 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 16:04:29.8643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lKIw0BmICyQRy8MlJNh8gFJB3m8+ZNEWUY6n7eylS7mwve7hkmpi7r4KLWvtQzewhD+g+ee8k8TsA1qdWJ1dqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR04MB0926 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 13 Sep 2019 16:04:43 -0000 Hi James, I agree that the wording could use clarification. The phrase, "MUST conform= " in 7.3 and the phrase, "not constrained by this specification" in RFC 774= 2 seemed confusing to me and is why I asked my question regarding what type= of endpoint VRS endpoints are considered. Thanks, Richard -----Original Message----- From: James Hamlin [mailto:james.hamlin@purple.us]=20 Sent: Friday, September 13, 2019 9:55 AM To: Richard Shields ; rum@ietf.org Cc: Paul Kyzivat Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 [EXTERNAL]=20 Richard Yes, but my understanding is that the RUE is a "WebRTC endpoint" and provid= er a "WebRTC-compatible endpoint" but the current text doesn't make any dis= tinction.=20 I just wanted to make sure that we will establish wording that makes clear = points that are important for compatibility.=20 Best regards James ________________________________________ From: Richard Shields Sent: 13 September 2019 16:22 To: James Hamlin; rum@ietf.org Cc: Paul Kyzivat Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thanks, James. Section 5 of RFC 7742 states this: "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. Does that not alleviate the requirement to implement VP8? Thanks, Richard -----Original Message----- From: James Hamlin [mailto:james.hamlin@purple.us] Sent: Friday, September 13, 2019 9:19 AM To: Richard Shields ; rum@ietf.org Cc: Paul Kyzivat Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 [EXTERNAL] Richard This was mentioned and I think the provider side is "WebRTC-compatible endp= oint". But the text currently in 7.3 and 7.4 treats provider and RUE identi= cally. Best regards James ________________________________________ From: Richard Shields Sent: 13 September 2019 16:02 To: James Hamlin; rum@ietf.org Cc: Paul Kyzivat Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 This may have been brought up before. RFC 7742, referenced in section 7.3, = has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and= a WebRTC-compatible endpoint, with different levels of MTI regarding VP8.= With the proposed RUE document, what are VRS endpoints considered? Thanks, Richard -----Original Message----- From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin Sent: Friday, September 13, 2019 8:41 AM To: rum@ietf.org Cc: Paul Kyzivat Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 [EXTERNAL] Paul I think we agreed that OPUS and VP8 wouldn't need to be supported on the pr= ovider side, for good reasons. The draft proposed for adoption seems to con= tradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 . Is the procedure that the document is adopted, with some agreed changes mis= sing, and then amended? Best regards James ________________________________________ From: Rum on behalf of Paul Kyzivat Sent: 10 September 2019 20:53 To: rum@ietf.org Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 Reminder, This call for adoption will end next Sunday. All responses so far have been= in support, but there haven't been a lot of them. If you haven't yet respo= nded, please do. Thanks, Paul, as RUM co-chair On 8/29/19 9:50 AM, Paul Kyzivat wrote: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=20 > document. This is intended to evolve into the document our charter=20 > calls for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > > Thanks, > Paul Kyzivat, as RUM co-chair > -- Rum mailing list Rum@ietf.org https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailma= n%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBs= Ghr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,= ,&typo=3D0 -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Fri Sep 13 12:12:50 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 A089E120105 for ; Fri, 13 Sep 2019 12:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NlRAl139nxo for ; Fri, 13 Sep 2019 12:12:46 -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 711221200FA for ; Fri, 13 Sep 2019 12:12:46 -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 x8DJCgnP010371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Sep 2019 15:12:43 -0400 To: James Hamlin , Richard Shields , "rum@ietf.org" References: <1568385648772.69603@purple.us> <1568387962077.82824@purple.us> <1568390112344.87888@purple.us> From: Paul Kyzivat Message-ID: Date: Fri, 13 Sep 2019 15:12:42 -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: <1568390112344.87888@purple.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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, 13 Sep 2019 19:12:49 -0000 On 9/13/19 11:55 AM, James Hamlin wrote: > Richard > > Yes, but my understanding is that the RUE is a "WebRTC endpoint" and provider a "WebRTC-compatible endpoint" but the current text doesn't make any distinction. I agree that we need to clarify that requirements differ between the RUE and the VRS provider. I think it is worth some discussion if the provider should be "WebRTC-compatible" or perhaps something more specific than that though not all the way to "WebRTC endpoint". While the goal of the WG is just to specify the RUE, I think it may well be helpful to specify (somewhere) more about the environment in which it will be used, including the other pieces that play in that environment and interact with the RUE. For instance media relays, Interactive Media Response devices, Communications Assistant devices, video mail devices. That will allow us to discuss constraints on the RUE that we need to consider and/or the potential need to develop requirements for some of those other devices. Thanks, Paul > I just wanted to make sure that we will establish wording that makes clear points that are important for compatibility. > > Best regards > > James > > > ________________________________________ > From: Richard Shields > Sent: 13 September 2019 16:22 > To: James Hamlin; rum@ietf.org > Cc: Paul Kyzivat > Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 > > Thanks, James. > > Section 5 of RFC 7742 states this: > > "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. > > Does that not alleviate the requirement to implement VP8? > > Thanks, > Richard > > -----Original Message----- > From: James Hamlin [mailto:james.hamlin@purple.us] > Sent: Friday, September 13, 2019 9:19 AM > To: Richard Shields ; rum@ietf.org > Cc: Paul Kyzivat > Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 > > [EXTERNAL] > > Richard > > This was mentioned and I think the provider side is "WebRTC-compatible endpoint". But the text currently in 7.3 and 7.4 treats provider and RUE identically. > > Best regards > > James > ________________________________________ > From: Richard Shields > Sent: 13 September 2019 16:02 > To: James Hamlin; rum@ietf.org > Cc: Paul Kyzivat > Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 > > This may have been brought up before. RFC 7742, referenced in section 7.3, has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and a WebRTC-compatible endpoint, with different levels of MTI regarding VP8. With the proposed RUE document, what are VRS endpoints considered? > > Thanks, > Richard > > -----Original Message----- > From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin > Sent: Friday, September 13, 2019 8:41 AM > To: rum@ietf.org > Cc: Paul Kyzivat > Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 > > [EXTERNAL] > > Paul > > I think we agreed that OPUS and VP8 wouldn't need to be supported on the provider side, for good reasons. The draft proposed for adoption seems to contradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 . > > Is the procedure that the document is adopted, with some agreed changes missing, and then amended? > > Best regards > > James > ________________________________________ > From: Rum on behalf of Paul Kyzivat > Sent: 10 September 2019 20:53 > To: rum@ietf.org > Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 > > Reminder, > > This call for adoption will end next Sunday. All responses so far have been in support, but there haven't been a lot of them. If you haven't yet responded, please do. > > Thanks, > Paul, as RUM co-chair > > On 8/29/19 9:50 AM, Paul Kyzivat wrote: >> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg >> document. This is intended to evolve into the document our charter >> calls for. >> >> Comments, pro or con, on this proposal are due by Sunday September 15. >> >> Thanks, >> Paul Kyzivat, as RUM co-chair >> > > -- > Rum mailing list > Rum@ietf.org > https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBsGhr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,,&typo=0 > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > > From nobody Sat Sep 14 18:01:57 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 0A7F612008C for ; Sat, 14 Sep 2019 18:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNuoklW4yZtt for ; Sat, 14 Sep 2019 18:01:54 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 CD6E3120058 for ; Sat, 14 Sep 2019 18:01:53 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id p13so2332409vso.0 for ; Sat, 14 Sep 2019 18:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=6+PEb1w9i1znRGC8F7wisAVIN+8VCBVrsV7Enj9TEhE=; b=W2+FsFrSPEmDxZ+hL+o1mxo+T7DMq0cjK/qqkifhZqa7sqZYEgosyOONmytqo+OPXA oirCkKY8p67PokuyfAckWI/UTs3QCMrw+JtuV2Mo10cuCxjKwkWktaKCe1FArATgTPE4 34LUW2+/LvbJEn1qCryB1LyVmkp+oOtdmXntLMe7RYzsngG+isiukGxnQ+/5Qfu9nPNp QPWwnmdl06oG4Mlh71Aq7mhmx4Qhpmu1tIGNFalFRjc8mcA2xA3Nwc7ys2cQSTD/8rZC FHT+AaGzXO548/CdHbYli0PMAFEWxOrb1MdXzPHjljVbQgmJOYbVSEmbYwAUsqGpDgtd oTvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=6+PEb1w9i1znRGC8F7wisAVIN+8VCBVrsV7Enj9TEhE=; b=djr/M65qFKQSEHEKjtYp2ygbigwCzKvM9SgagzjVl8Y585p/svgh2Hf8A8cgIOj49R QH83zgDy+toBHurTzYBerqNJaZWUSV0rn1DDEURTGY1zZ+DJYWqmBDeae34YZ0IGWC5v PsgSepGeXeaQYdepUNEaWqM0kdNR58AtU2nWKsnLt1mSvbzyzE/qEZNT7l3TE6rKDcgw 9KNezwcoDLeHuGSqiuzXG6M21SBb/DMOCxVnx6hR9gzff0AVRXxIwBka9DTUKEhNdx5U 7qq0VOe1/6oVb+exwjkq3FrpSrBXJ9etY0YapI7GB79AqTw/AsEEDGYo66rAMbaTfUBb fYlw== X-Gm-Message-State: APjAAAVHLMuLjJ5yOvk277ftyJvznTxCw1ez8/aRPSWNdURoqo3x20u6 1xZU44AgK/a2T6kY21vmXeuzdnVRTztNi04hCihPGVbb X-Google-Smtp-Source: APXvYqwGKDCi+lV0nHlzfJZfc+g8OvSaE4Tg5IkS8yQwC9l19Q9weqqEHAoi/TVq/FsvQSdC5QosBC70d89L1AoTv+4= X-Received: by 2002:a67:d410:: with SMTP id c16mr30552733vsj.37.1568509312871; Sat, 14 Sep 2019 18:01:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: iroach@gmail.com From: Isaac Roach Date: Sat, 14 Sep 2019 19:01:41 -0600 Message-ID: To: Paul Kyzivat Cc: rum@ietf.org Content-Type: multipart/alternative; boundary="0000000000006bb23a05928d089c" Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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: Sun, 15 Sep 2019 01:01:56 -0000 --0000000000006bb23a05928d089c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Paul, Sorenson has concerns about using the current draft as the starting point for the working group. For example, Sorenson agrees with your earlier comments highlighting the security issues that the draft presents and that it doesn't solve the client cert issue. I also am concerned about how the draft addresses 911, requiring endpoints to comply with RFC6881 and to send geolocation information, rather than using the method that the FCC=E2=80=99= s rules require (Registered Location). Sorenson would be concerned if these issues become part of a WG document. Thanks, Isaac On Thu, Aug 29, 2019 at 7:51 AM Paul Kyzivat wrote: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg > document. This is intended to evolve into the document our charter calls > for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > > Thanks, > Paul Kyzivat, as RUM co-chair > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > --0000000000006bb23a05928d089c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,
=C2=A0
Sorenson has concerns about using the current draft as th= e starting point for the working group. For example, Sorenson agrees with y= our earlier comments highlighting the security issues that the draft presen= ts and that it doesn't solve the client cert issue. I also am concerned= about how the draft addresses 911, requiring endpoints to comply with RFC6= 881 and to send geolocation information, rather than using the method that = the FCC=E2=80=99s rules require (Registered Location).=C2=A0 Sorenson would= be concerned if these issues become part of a WG document.

Thanks,

Isaac

On Thu, Aug 29, = 2019 at 7:51 AM Paul Kyzivat <p= kyzivat@alum.mit.edu> wrote:
This is a cal= l for the adoption of draft-rosen-rue-01 as a RUM wg
document. This is intended to evolve into the document our charter calls for.

Comments, pro or con, on this proposal are due by Sunday September 15.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul Kyzivat, as RUM co-chair

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--0000000000006bb23a05928d089c-- From nobody Mon Sep 16 08:18:31 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 AE57B1202A0 for ; Mon, 16 Sep 2019 08:18:29 -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 AH2V4P2ZRWly for ; Mon, 16 Sep 2019 08:18:27 -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 2DA8F12000F for ; Mon, 16 Sep 2019 08:18:26 -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 x8GFIOPw000536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2019 11:18:25 -0400 From: Paul Kyzivat To: "rum@ietf.org" References: Cc: Isaac Roach Message-ID: Date: Mon, 16 Sep 2019 11:18:24 -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] Call for WG adoption of: draft-rosen-rue-01 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: Mon, 16 Sep 2019 15:18:30 -0000 Isaac, On 9/14/19 8:59 PM, Isaac Roach wrote: > Hi Paul, > Sorenson has concerns about using the current draft as the starting > point for the working group. Right now this is the only candidate we have. Unless there is an indication that an alternative is forthcoming it will be a matter of an bird in the hand vs another in the bush. If you wish to make an alternative proposal I am willing to help you with the mechanics of doing so. Adopting this does not prevent addressing the points you raise below. > For example, Sorenson agrees with your > earlier comments highlighting the security issues that the draft > presents and that it doesn't solve the client cert issue. It would be helpful to have a discussion of the issue you want to solve. I sketch out my understanding of it in my comments. But if I properly understand your concerns then I don't know any way to satisfy them. And ISTM that web server developers should have similar concern about browsers and yet they manage without any similar verification. > I also am > concerned about how the draft addresses 911, requiring endpoints to > comply with RFC6881 and to send geolocation information, rather than > using the method that the FCC’s rules require (Registered Location). I hope Brian Rosen will respond to this, since he is expert in 911 issues. > Sorenson would be concerned if these issues become part of a WG document. Again, adopting this draft does not preclude subsequently addressing these issues. Your issues will need to be resolved one way or another before the resulting document can survive a last-call. Thanks, Paul > Thanks, > > Isaac > > On Thu, Aug 29, 2019 at 7:51 AM Paul Kyzivat > wrote: > > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg > document. This is intended to evolve into the document our charter > calls > for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > >         Thanks, >         Paul Kyzivat, as RUM co-chair > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > From nobody Mon Sep 16 08:24:31 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 36A8A1202A0 for ; Mon, 16 Sep 2019 08:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Lx_mEEK-ICr5 for ; Mon, 16 Sep 2019 08:24:26 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 DA6D0120052 for ; Mon, 16 Sep 2019 08:24:25 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id z67so306026qkb.12 for ; Mon, 16 Sep 2019 08:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eNNoDP5uSIYCnxAHJCYQqOZH5DH+KNyC+oUNxWETCxQ=; b=QoIdFZp4gIxhHL/pv1Hcgl8Z5u2YHLgpiQ+f+joO4x6APSBVc9rY1UCJqn2oNfFW9h CRDYWytBfq0VGX5XcpWuIlKhAT/yzJ56f5fJsDsHpl4PtGY/ceSqAeb6VlOm0FGSd+oA eOUTVrVpNx60ScV4f1drIgH3oj2pDZSHpKDgwbKub/1w6zyVmQIaUl6b+RdBoNvGNiNh cdpUvm+2rqJoY0AVY+l9gKh3EkcBUKu/v9UIT4AAd4r0jeP1WzC1UenPEnDuXtmI1Zy1 6LbG+oz5x6Tp9Oa5/CJccWUnJ9Iqb9RvIBLIxJGH2xSjxCniLENywEFVe4iAJ+5RqkMc NkkA== 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=eNNoDP5uSIYCnxAHJCYQqOZH5DH+KNyC+oUNxWETCxQ=; b=JYUDLWVtJf+UJLvBKmEgXltuW9DACdOA5Y5IggRrR7WGzf3uAfnnHiXht5XD4d+yFh kbSzJ27yLfD+GXmTdzyr5Og1n2tVmPQeig5SXAMrMK/cj1FGR2K6oFL5+XVLR/1WTYq/ O5pGvk1rCF1EfBAnl6oBEJy3x1GeoPy6c+MMKNrhRmljWpIhQ6VEY9fnl9YXEiVIAoEW U1NdACr9hRem7ykgdmiBD8XggvoyRRrmGRiIDACyILolE1tEP62gzM4A7iaenMPohg4I 57v9+5eEKhH7Z2LTAKj6h3QYmZTv/feJtUnVxOlhfmSjASCDtrpP/95xhPI195/6Rh2X im2w== X-Gm-Message-State: APjAAAX0YovFR133fLJmoybG9JEj5CAVA2pCiSCULi8x1VOIFQHGNFfh jdOllJbVOV+bZDci/BMFuHI17Q== X-Google-Smtp-Source: APXvYqx0TkUmeZgbirPS2LtsqRjURvP2dZihyEZuAiTYGhKz8uFy20OoI93iNeqBaZ+iUrJP4QjL2A== X-Received: by 2002:a37:6250:: with SMTP id w77mr483684qkb.153.1568647464811; Mon, 16 Sep 2019 08:24:24 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id z141sm9378833qka.126.2019.09.16.08.24.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 08:24:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Mon, 16 Sep 2019 11:24:22 -0400 Cc: "rum@ietf.org" , Isaac Roach Content-Transfer-Encoding: quoted-printable Message-Id: <353212D6-B090-42E4-B2E6-9F5271BB12DA@brianrosen.net> References: To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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: Mon, 16 Sep 2019 15:24:30 -0000 With respect to 9-1-1:=20 Devices don=E2=80=99t have any requirements to be able to support = classic emergency calling (what we would call E9-1-1 in the US) other = than, perhaps, the ability to dial a =E2=80=9Cservice code=E2=80=9D, = like 9-1-1 or 3-1-1. =20 With NG9-1-1 and the equivalents in the EU and elsewhere, the device has = to conform to RFC6881. Brian > On Sep 16, 2019, at 11:18 AM, Paul Kyzivat = wrote: >=20 > Isaac, >=20 > On 9/14/19 8:59 PM, Isaac Roach wrote: >> Hi Paul, >> Sorenson has concerns about using the current draft as the starting = point for the working group. >=20 > Right now this is the only candidate we have. Unless there is an = indication that an alternative is forthcoming it will be a matter of an = bird in the hand vs another in the bush. >=20 > If you wish to make an alternative proposal I am willing to help you = with the mechanics of doing so. >=20 > Adopting this does not prevent addressing the points you raise below. >=20 >> For example, Sorenson agrees with your earlier comments highlighting = the security issues that the draft presents and that it doesn't solve = the client cert issue. >=20 > It would be helpful to have a discussion of the issue you want to = solve. I sketch out my understanding of it in my comments. But if I = properly understand your concerns then I don't know any way to satisfy = them. And ISTM that web server developers should have similar concern = about browsers and yet they manage without any similar verification. >=20 >> I also am concerned about how the draft addresses 911, requiring = endpoints to comply with RFC6881 and to send geolocation information, = rather than using the method that the FCC=E2=80=99s rules require = (Registered Location). =20 >=20 > I hope Brian Rosen will respond to this, since he is expert in 911 = issues. >=20 >> Sorenson would be concerned if these issues become part of a WG = document. >=20 > Again, adopting this draft does not preclude subsequently addressing = these issues. Your issues will need to be resolved one way or another = before the resulting document can survive a last-call. >=20 > Thanks, > Paul >=20 >> Thanks, >> Isaac >> On Thu, Aug 29, 2019 at 7:51 AM Paul Kyzivat > wrote: >> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg >> document. This is intended to evolve into the document our charter >> calls >> for. >> Comments, pro or con, on this proposal are due by Sunday September = 15. >> Thanks, >> Paul Kyzivat, as RUM co-chair >> -- Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Mon Sep 16 09:15:36 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 D987E1200FE for ; Mon, 16 Sep 2019 09:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 hAcUBQSu1_ml for ; Mon, 16 Sep 2019 09:15:32 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (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 51CE212004F for ; Mon, 16 Sep 2019 09:15:29 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx5.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 16 Sep 2019 16:15:26 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 16 Sep 2019 09:15:22 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Mon, 16 Sep 2019 09:15:22 -0700 From: James Hamlin To: Paul Kyzivat , "rum@ietf.org" CC: Richard Shields Thread-Topic: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVakA0i+jQ6mMMhEOX6Gd2YqSgd6cqKX2A//+Msu+AAHjFgP//iveLgAC1XACABAeG/w== Date: Mon, 16 Sep 2019 16:15:21 +0000 Message-ID: <1568650521915.9877@purple.us> References: <1568385648772.69603@purple.us> <1568387962077.82824@purple.us> <1568390112344.87888@purple.us>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1568650523-893008-32612-100877-1 X-BESS-VER: 2019.1_20190912.1934 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.218473 [from cloudscan13-202.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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: Mon, 16 Sep 2019 16:15:35 -0000 Paul=0A= =0A= "... the goal of the WG is just to specify the RUE..." isn't consistent wit= h the charter which, talks of a "a RUM-compliant provider" and the document= scope which contains things like "the provider MUST". =0A= =0A= I don't think we will need to peer inside provider's networks except to poi= nt out - as we have - that there are some limitations on what codecs can re= alistically be offered at the provider's side of the RUE interface.=0A= =0A= I think the text will need to recognise - as previous versions have done - = some asymmetry between the RUE which is new and providers which are establi= shed.=0A= =0A= Best regards=0A= =0A= James =0A= =0A= =0A= ________________________________________=0A= From: Paul Kyzivat =0A= Sent: 13 September 2019 20:12=0A= To: James Hamlin; Richard Shields; rum@ietf.org=0A= Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= =0A= On 9/13/19 11:55 AM, James Hamlin wrote:=0A= > Richard=0A= >=0A= > Yes, but my understanding is that the RUE is a "WebRTC endpoint" and prov= ider a "WebRTC-compatible endpoint" but the current text doesn't make any d= istinction.=0A= =0A= I agree that we need to clarify that requirements differ between the RUE=0A= and the VRS provider. I think it is worth some discussion if the=0A= provider should be "WebRTC-compatible" or perhaps something more=0A= specific than that though not all the way to "WebRTC endpoint".=0A= =0A= While the goal of the WG is just to specify the RUE, I think it may well=0A= be helpful to specify (somewhere) more about the environment in which it=0A= will be used, including the other pieces that play in that environment=0A= and interact with the RUE. For instance media relays, Interactive Media=0A= Response devices, Communications Assistant devices, video mail devices.=0A= =0A= That will allow us to discuss constraints on the RUE that we need to=0A= consider and/or the potential need to develop requirements for some of=0A= those other devices.=0A= =0A= Thanks,=0A= Paul=0A= =0A= > I just wanted to make sure that we will establish wording that makes clea= r points that are important for compatibility.=0A= >=0A= > Best regards=0A= >=0A= > James=0A= >=0A= >=0A= > ________________________________________=0A= > From: Richard Shields =0A= > Sent: 13 September 2019 16:22=0A= > To: James Hamlin; rum@ietf.org=0A= > Cc: Paul Kyzivat=0A= > Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= >=0A= > Thanks, James.=0A= >=0A= > Section 5 of RFC 7742 states this:=0A= >=0A= > "WebRTC-compatible endpoints" are free to implement any video codecs=0A= > they see fit. This follows logically from the definition of "WebRTC-= =0A= > compatible endpoint". It is, of course, advisable to implement at=0A= > least one of the video codecs that is mandated for WebRTC browsers,= =0A= > and implementors are encouraged to do so.=0A= >=0A= > Does that not alleviate the requirement to implement VP8?=0A= >=0A= > Thanks,=0A= > Richard=0A= >=0A= > -----Original Message-----=0A= > From: James Hamlin [mailto:james.hamlin@purple.us]=0A= > Sent: Friday, September 13, 2019 9:19 AM=0A= > To: Richard Shields ; rum@ietf.org=0A= > Cc: Paul Kyzivat =0A= > Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= >=0A= > [EXTERNAL]=0A= >=0A= > Richard=0A= >=0A= > This was mentioned and I think the provider side is "WebRTC-compatible en= dpoint". But the text currently in 7.3 and 7.4 treats provider and RUE iden= tically.=0A= >=0A= > Best regards=0A= >=0A= > James=0A= > ________________________________________=0A= > From: Richard Shields =0A= > Sent: 13 September 2019 16:02=0A= > To: James Hamlin; rum@ietf.org=0A= > Cc: Paul Kyzivat=0A= > Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= >=0A= > This may have been brought up before. RFC 7742, referenced in section 7.3= , has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, a= nd a WebRTC-compatible endpoint, with different levels of MTI regarding VP= 8. With the proposed RUE document, what are VRS endpoints considered?=0A= >=0A= > Thanks,=0A= > Richard=0A= >=0A= > -----Original Message-----=0A= > From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin=0A= > Sent: Friday, September 13, 2019 8:41 AM=0A= > To: rum@ietf.org=0A= > Cc: Paul Kyzivat =0A= > Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= >=0A= > [EXTERNAL]=0A= >=0A= > Paul=0A= >=0A= > I think we agreed that OPUS and VP8 wouldn't need to be supported on the = provider side, for good reasons. The draft proposed for adoption seems to c= ontradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 .=0A= >=0A= > Is the procedure that the document is adopted, with some agreed changes m= issing, and then amended?=0A= >=0A= > Best regards=0A= >=0A= > James=0A= > ________________________________________=0A= > From: Rum on behalf of Paul Kyzivat =0A= > Sent: 10 September 2019 20:53=0A= > To: rum@ietf.org=0A= > Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01=0A= >=0A= > Reminder,=0A= >=0A= > This call for adoption will end next Sunday. All responses so far have be= en in support, but there haven't been a lot of them. If you haven't yet res= ponded, please do.=0A= >=0A= > Thanks,=0A= > Paul, as RUM co-chair=0A= >=0A= > On 8/29/19 9:50 AM, Paul Kyzivat wrote:=0A= >> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=0A= >> document. This is intended to evolve into the document our charter=0A= >> calls for.=0A= >>=0A= >> Comments, pro or con, on this proposal are due by Sunday September 15.= =0A= >>=0A= >> Thanks,=0A= >> Paul Kyzivat, as RUM co-chair=0A= >>=0A= >=0A= > --=0A= > Rum mailing list=0A= > Rum@ietf.org=0A= > https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmail= man%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHw= BsGhr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkw= g,,&typo=3D0=0A= >=0A= > --=0A= > Rum mailing list=0A= > Rum@ietf.org=0A= > https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmail= man%2flistinfo%2frum&c=3DE,1,5gFM03FhLeAehgyM5wopwvqisH_DKkNfsMVfqIMUtoJYZe= xefZEADQ9aHKc-74KC8XOuzmOWQEvBaAcc6pYgXOkk4ObSl_YHXWvalJG72uy_OQ6v038vyjCso= VU3&typo=3D0=0A= >=0A= >=0A= >=0A= =0A= From nobody Mon Sep 16 11:49:11 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 6580D120122 for ; Mon, 16 Sep 2019 11:49:08 -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 SxeQh5MZ_CK4 for ; Mon, 16 Sep 2019 11:49:01 -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 62893120890 for ; Mon, 16 Sep 2019 11:49:01 -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 x8GImu7t014996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2019 14:48:57 -0400 To: James Hamlin , "rum@ietf.org" Cc: Richard Shields References: <1568385648772.69603@purple.us> <1568387962077.82824@purple.us> <1568390112344.87888@purple.us> <1568650521915.9877@purple.us> From: Paul Kyzivat Message-ID: <075887d0-fa00-ed1a-e2de-0ea35e077d41@alum.mit.edu> Date: Mon, 16 Sep 2019 14:48:56 -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: <1568650521915.9877@purple.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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: Mon, 16 Sep 2019 18:49:09 -0000 James, On 9/16/19 12:15 PM, James Hamlin wrote: > Paul > > "... the goal of the WG is just to specify the RUE..." isn't consistent with the charter which, talks of a "a RUM-compliant provider" and the document scope which contains things like "the provider MUST". OK. I shouldn't think about it that way. After rereading the charter I find it isn't very clear and concise about exactly what is and isn't in scope. It is really the interface between a RUE and a provider, and that has two sides. > I don't think we will need to peer inside provider's networks except to point out - as we have - that there are some limitations on what codecs can realistically be offered at the provider's side of the RUE interface. > > I think the text will need to recognise - as previous versions have done - some asymmetry between the RUE which is new and providers which are established. I agree that we need to acknowledge this asymmetry. Thanks, Paul > Best regards > > James > > > ________________________________________ > From: Paul Kyzivat > Sent: 13 September 2019 20:12 > To: James Hamlin; Richard Shields; rum@ietf.org > Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 > > On 9/13/19 11:55 AM, James Hamlin wrote: >> Richard >> >> Yes, but my understanding is that the RUE is a "WebRTC endpoint" and provider a "WebRTC-compatible endpoint" but the current text doesn't make any distinction. > > I agree that we need to clarify that requirements differ between the RUE > and the VRS provider. I think it is worth some discussion if the > provider should be "WebRTC-compatible" or perhaps something more > specific than that though not all the way to "WebRTC endpoint". > > While the goal of the WG is just to specify the RUE, I think it may well > be helpful to specify (somewhere) more about the environment in which it > will be used, including the other pieces that play in that environment > and interact with the RUE. For instance media relays, Interactive Media > Response devices, Communications Assistant devices, video mail devices. > > That will allow us to discuss constraints on the RUE that we need to > consider and/or the potential need to develop requirements for some of > those other devices. > > Thanks, > Paul > >> I just wanted to make sure that we will establish wording that makes clear points that are important for compatibility. >> >> Best regards >> >> James >> >> >> ________________________________________ >> From: Richard Shields >> Sent: 13 September 2019 16:22 >> To: James Hamlin; rum@ietf.org >> Cc: Paul Kyzivat >> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 >> >> Thanks, James. >> >> Section 5 of RFC 7742 states this: >> >> "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. >> >> Does that not alleviate the requirement to implement VP8? >> >> Thanks, >> Richard >> >> -----Original Message----- >> From: James Hamlin [mailto:james.hamlin@purple.us] >> Sent: Friday, September 13, 2019 9:19 AM >> To: Richard Shields ; rum@ietf.org >> Cc: Paul Kyzivat >> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >> >> [EXTERNAL] >> >> Richard >> >> This was mentioned and I think the provider side is "WebRTC-compatible endpoint". But the text currently in 7.3 and 7.4 treats provider and RUE identically. >> >> Best regards >> >> James >> ________________________________________ >> From: Richard Shields >> Sent: 13 September 2019 16:02 >> To: James Hamlin; rum@ietf.org >> Cc: Paul Kyzivat >> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 >> >> This may have been brought up before. RFC 7742, referenced in section 7.3, has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and a WebRTC-compatible endpoint, with different levels of MTI regarding VP8. With the proposed RUE document, what are VRS endpoints considered? >> >> Thanks, >> Richard >> >> -----Original Message----- >> From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin >> Sent: Friday, September 13, 2019 8:41 AM >> To: rum@ietf.org >> Cc: Paul Kyzivat >> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >> >> [EXTERNAL] >> >> Paul >> >> I think we agreed that OPUS and VP8 wouldn't need to be supported on the provider side, for good reasons. The draft proposed for adoption seems to contradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 . >> >> Is the procedure that the document is adopted, with some agreed changes missing, and then amended? >> >> Best regards >> >> James >> ________________________________________ >> From: Rum on behalf of Paul Kyzivat >> Sent: 10 September 2019 20:53 >> To: rum@ietf.org >> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >> >> Reminder, >> >> This call for adoption will end next Sunday. All responses so far have been in support, but there haven't been a lot of them. If you haven't yet responded, please do. >> >> Thanks, >> Paul, as RUM co-chair >> >> On 8/29/19 9:50 AM, Paul Kyzivat wrote: >>> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg >>> document. This is intended to evolve into the document our charter >>> calls for. >>> >>> Comments, pro or con, on this proposal are due by Sunday September 15. >>> >>> Thanks, >>> Paul Kyzivat, as RUM co-chair >>> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBsGhr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,,&typo=0 >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,5gFM03FhLeAehgyM5wopwvqisH_DKkNfsMVfqIMUtoJYZexefZEADQ9aHKc-74KC8XOuzmOWQEvBaAcc6pYgXOkk4ObSl_YHXWvalJG72uy_OQ6v038vyjCsoVU3&typo=0 >> >> >> > > From nobody Mon Sep 16 12:07:28 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 3AC74120111 for ; Mon, 16 Sep 2019 12:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 K0HUQE1M8KOL for ; Mon, 16 Sep 2019 12:07:19 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 6E9CD120178 for ; Mon, 16 Sep 2019 12:07:09 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id r5so1255881qtd.0 for ; Mon, 16 Sep 2019 12:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=48egKthFzCObLZe+rjEwY45zuRxIQUG35kZ7IHublyo=; b=GASwPSRAaOWrEdgygmDPtG7ZqtyAcPGWuuKkMVqfB7p7QcXq1mh8GrwsIBvot5bcKc vD+MtG1XQhKEcF/nOvLBD2hmnjq8bYOoIsALRi+vSzjGfXX4pDecHEzDWew8uBkpy1Qj M3s6lrA6J6F/Q9yrBojSxv2lv9Sgd2EziVoaxy1wpvI0y4U5NRKbbWp5WwB6qyo5y3fP 0NzTGwEW3diJjqSernvNiFnoqVwxvWg9TYCKxOJJ5gIPlTLouHF/oa+7Z/NT7iEoEUDV IVoTYcsPr3DCfcXY/quU2iDjabzIaYlPUhSkXeVXkCxF3JzKnapmzHtO5thrOMNwYEsE Ff1A== 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=48egKthFzCObLZe+rjEwY45zuRxIQUG35kZ7IHublyo=; b=bn5edSmg7S0dSme5muQZjD/YbZ3VrqtMWHD9ZnCQg/ZNJNf5G95qkWU1sDi4/MHv6x D0Z8aewkDT7/ULd2u4WxQzikchl5xnVPfew0zQe09M0nN7tndqzTVkoXlXHtcQo6TOkD FeZElFvTGUetN3UuAF9WJuzByHz2cZMRvLqXsSmTiu82Pp5CfTOwV6061kK0J6o6TqrP EUPKR+DVevboBLSxv8pb2nXpIt/YPkHQCbYbzc4VforhMeH5EdJeYUKdhIE+JjP+2okp CHG7HHN3X0Vyp+UMUDbGTpcPflp/kWlGplH/ygR0KKcDpbJXJuvSepnzpg/ud/mGDri8 1C8g== X-Gm-Message-State: APjAAAV5SUd6ePbtdZ+4B+oNImLraoBGGYQWrKEOUqFKIwvLjf8XXYIX /abI4nI7b67DgRSJKlk1cSXoGQ== X-Google-Smtp-Source: APXvYqxAqmrTeOywabtbacSahbEp0810Z+AwmGbPOiEaznmsmEvZGGL+ufCK48TMxtidKYNHZAqZcg== X-Received: by 2002:ac8:36b0:: with SMTP id a45mr1211697qtc.105.1568660828278; Mon, 16 Sep 2019 12:07:08 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id 33sm4365564qtr.62.2019.09.16.12.07.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 12:07:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <075887d0-fa00-ed1a-e2de-0ea35e077d41@alum.mit.edu> Date: Mon, 16 Sep 2019 15:07:06 -0400 Cc: James Hamlin , "rum@ietf.org" , Richard Shields Content-Transfer-Encoding: quoted-printable Message-Id: References: <1568385648772.69603@purple.us> <1568387962077.82824@purple.us> <1568390112344.87888@purple.us> <1568650521915.9877@purple.us> <075887d0-fa00-ed1a-e2de-0ea35e077d41@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 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: Mon, 16 Sep 2019 19:07:27 -0000 I agree that the current language is not very clear, and not really what = we want. As Paul says, we=E2=80=99re defining an interface between a = device and a provider. We probably do care that if two rue-compliant = devices talked to one another through a provider, that all the features = worked, but I don=E2=80=99t think we would imply anything else about = what a provider did. I think we would probably say that we wished = providers had rue-compatible endpoints at, for example, a CA position, = but I don=E2=80=99t think an IETF spec could or should say anything like = that. =20 Brian > On Sep 16, 2019, at 2:48 PM, Paul Kyzivat = wrote: >=20 > James, >=20 > On 9/16/19 12:15 PM, James Hamlin wrote: >> Paul >> "... the goal of the WG is just to specify the RUE..." isn't = consistent with the charter which, talks of a "a RUM-compliant provider" = and the document scope which contains things like "the provider MUST". >=20 > OK. I shouldn't think about it that way. After rereading the charter I = find it isn't very clear and concise about exactly what is and isn't in = scope. It is really the interface between a RUE and a provider, and that = has two sides. >=20 >> I don't think we will need to peer inside provider's networks except = to point out - as we have - that there are some limitations on what = codecs can realistically be offered at the provider's side of the RUE = interface. >> I think the text will need to recognise - as previous versions have = done - some asymmetry between the RUE which is new and providers which = are established. >=20 > I agree that we need to acknowledge this asymmetry. >=20 > Thanks, > Paul >=20 >> Best regards >> James >> ________________________________________ >> From: Paul Kyzivat >> Sent: 13 September 2019 20:12 >> To: James Hamlin; Richard Shields; rum@ietf.org >> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >> On 9/13/19 11:55 AM, James Hamlin wrote: >>> Richard >>>=20 >>> Yes, but my understanding is that the RUE is a "WebRTC endpoint" and = provider a "WebRTC-compatible endpoint" but the current text doesn't = make any distinction. >> I agree that we need to clarify that requirements differ between the = RUE >> and the VRS provider. I think it is worth some discussion if the >> provider should be "WebRTC-compatible" or perhaps something more >> specific than that though not all the way to "WebRTC endpoint". >> While the goal of the WG is just to specify the RUE, I think it may = well >> be helpful to specify (somewhere) more about the environment in which = it >> will be used, including the other pieces that play in that = environment >> and interact with the RUE. For instance media relays, Interactive = Media >> Response devices, Communications Assistant devices, video mail = devices. >> That will allow us to discuss constraints on the RUE that we need to >> consider and/or the potential need to develop requirements for some = of >> those other devices. >> Thanks, >> Paul >>> I just wanted to make sure that we will establish wording that makes = clear points that are important for compatibility. >>>=20 >>> Best regards >>>=20 >>> James >>>=20 >>>=20 >>> ________________________________________ >>> From: Richard Shields >>> Sent: 13 September 2019 16:22 >>> To: James Hamlin; rum@ietf.org >>> Cc: Paul Kyzivat >>> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 >>>=20 >>> Thanks, James. >>>=20 >>> Section 5 of RFC 7742 states this: >>>=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 >>> Does that not alleviate the requirement to implement VP8? >>>=20 >>> Thanks, >>> Richard >>>=20 >>> -----Original Message----- >>> From: James Hamlin [mailto:james.hamlin@purple.us] >>> Sent: Friday, September 13, 2019 9:19 AM >>> To: Richard Shields ; rum@ietf.org >>> Cc: Paul Kyzivat >>> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >>>=20 >>> [EXTERNAL] >>>=20 >>> Richard >>>=20 >>> This was mentioned and I think the provider side is = "WebRTC-compatible endpoint". But the text currently in 7.3 and 7.4 = treats provider and RUE identically. >>>=20 >>> Best regards >>>=20 >>> James >>> ________________________________________ >>> From: Richard Shields >>> Sent: 13 September 2019 16:02 >>> To: James Hamlin; rum@ietf.org >>> Cc: Paul Kyzivat >>> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01 >>>=20 >>> This may have been brought up before. RFC 7742, referenced in = section 7.3, has three endpoint definitions: a WebRTC browser, a WebRTC = non-browser, and a WebRTC-compatible endpoint, with different levels of = MTI regarding VP8. With the proposed RUE document, what are VRS = endpoints considered? >>>=20 >>> Thanks, >>> Richard >>>=20 >>> -----Original Message----- >>> From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin >>> Sent: Friday, September 13, 2019 8:41 AM >>> To: rum@ietf.org >>> Cc: Paul Kyzivat >>> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >>>=20 >>> [EXTERNAL] >>>=20 >>> Paul >>>=20 >>> I think we agreed that OPUS and VP8 wouldn't need to be supported on = the provider side, for good reasons. The draft proposed for adoption = seems to contradict this with "RUE and Providers MUST" in sections 7.3 = and 7.4 . >>>=20 >>> Is the procedure that the document is adopted, with some agreed = changes missing, and then amended? >>>=20 >>> Best regards >>>=20 >>> James >>> ________________________________________ >>> From: Rum on behalf of Paul Kyzivat = >>> Sent: 10 September 2019 20:53 >>> To: rum@ietf.org >>> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >>>=20 >>> Reminder, >>>=20 >>> This call for adoption will end next Sunday. All responses so far = have been in support, but there haven't been a lot of them. If you = haven't yet responded, please do. >>>=20 >>> Thanks, >>> Paul, as RUM co-chair >>>=20 >>> On 8/29/19 9:50 AM, Paul Kyzivat wrote: >>>> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg >>>> document. This is intended to evolve into the document our charter >>>> calls for. >>>>=20 >>>> Comments, pro or con, on this proposal are due by Sunday September = 15. >>>>=20 >>>> Thanks, >>>> Paul Kyzivat, as RUM co-chair >>>>=20 >>>=20 >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> = https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailm= an%2flistinfo%2frum&c=3DE,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHw= BsGhr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZk= wg,,&typo=3D0 >>>=20 >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> = https://linkprotect.cudasvc.com/url?a=3Dhttps%3a%2f%2fwww.ietf.org%2fmailm= an%2flistinfo%2frum&c=3DE,1,5gFM03FhLeAehgyM5wopwvqisH_DKkNfsMVfqIMUtoJYZe= xefZEADQ9aHKc-74KC8XOuzmOWQEvBaAcc6pYgXOkk4ObSl_YHXWvalJG72uy_OQ6v038vyjCs= oVU3&typo=3D0 >>>=20 >>>=20 >>>=20 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Mon Sep 16 12:28:11 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 0516212010D for ; Mon, 16 Sep 2019 12:28:10 -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 RpoLg1T0eNOf for ; Mon, 16 Sep 2019 12:28:03 -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 B87B11200FE for ; Mon, 16 Sep 2019 12:28:03 -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 x8GJRwdK017484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2019 15:27:59 -0400 To: Brian Rosen Cc: James Hamlin , "rum@ietf.org" , Richard Shields References: <1568385648772.69603@purple.us> <1568387962077.82824@purple.us> <1568390112344.87888@purple.us> <1568650521915.9877@purple.us> <075887d0-fa00-ed1a-e2de-0ea35e077d41@alum.mit.edu> From: Paul Kyzivat Message-ID: <1d887e2b-6d30-1a3e-b22b-641b8892dcab@alum.mit.edu> Date: Mon, 16 Sep 2019 15:27:58 -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] Call for WG adoption of: draft-rosen-rue-01 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: Mon, 16 Sep 2019 19:28:10 -0000 On 9/16/19 3:07 PM, Brian Rosen wrote: > I agree that the current language is not very clear, and not really what we want. As Paul says, we’re defining an interface between a device and a provider. We probably do care that if two rue-compliant devices talked to one another through a provider, that all the features worked, but I don’t think we would imply anything else about what a provider did. I think we would probably say that we wished providers had rue-compatible endpoints at, for example, a CA position, but I don’t think an IETF spec could or should say anything like that. Perhaps it would be helpful to have the draft reference Drawing 1 of: VRS US Providers Profile TWG-6-1.0 and say that the goal is to define interface U2. That diagram was developed in the early days of the SIP Forum work on VRS. At that time the scope was expected to be broader, but was eventually limited to the R1 interface. This figure gives an overview of the bigger picture and helps put the work into context. (Note that a revision to that profile is in progress, but it won't change that figure.) Thanks, Paul From nobody Tue Sep 17 13:32: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 424BE120A07 for ; Tue, 17 Sep 2019 13:32:18 -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 6V8FzA8kOyEn for ; Tue, 17 Sep 2019 13:32:16 -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 B463E1209E0 for ; Tue, 17 Sep 2019 13:32:16 -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 x8HKWE9i008052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 17 Sep 2019 16:32:15 -0400 To: rum@ietf.org References: From: Paul Kyzivat Message-ID: <9a02e22c-654e-5d3a-991f-150778aa2919@alum.mit.edu> Date: Tue, 17 Sep 2019 16:32:14 -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: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft 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, 17 Sep 2019 20:32:22 -0000 RUM followers: The deadline for comments on the call for adoption of draft-rosen-rue-01 concluded on Sunday Sept 15. Summarizing the comments that came in: - 8 people indicated a desire to adopt; - 3 people expressed some concerns with the document. In my judgement the concerns raised are all worth of further pursuit. But I don't see any problem in addressing those via revisions to the proposed document. Since no alternative document has been offered, I conclude that we should adopt draft-rosen-rue-01 as a working group document aimed at satisfying our sole milestone: "Submit a profile of SIP and media features for use with video relay services to the IESG for publication". The author is requested to submit a new version of the document ASAP, with the name changed to: draft-ietf-run-rue-00 signifying it as a WG document. I also request that people now start posting to this mailing list issues with this document. Where possible, please start a separate thread with a meaningful title for each issue in order to facilitate orderly discussion of the issues. Note that once we seem to have consensus on the resolution to an issue then suggestions of specific text changes are welcome. Thanks, Paul (as RUM co-chair) On 8/29/19 9:50 AM, Paul Kyzivat wrote: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg > document. This is intended to evolve into the document our charter calls > for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > >     Thanks, >     Paul Kyzivat, as RUM co-chair > From nobody Wed Sep 18 14:36:31 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 6FE00120046 for ; Wed, 18 Sep 2019 14:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP0h0DrADIEt for ; Wed, 18 Sep 2019 14:36:27 -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 8D67E120043 for ; Wed, 18 Sep 2019 14:36: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 x8ILaP0m031996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Sep 2019 17:36:26 -0400 To: Roger Slusser , rum@ietf.org References: <9a02e22c-654e-5d3a-991f-150778aa2919@alum.mit.edu> <686044064.3342929.1568835154612@mail.yahoo.com> From: Paul Kyzivat Message-ID: Date: Wed, 18 Sep 2019 17:36:25 -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: <686044064.3342929.1568835154612@mail.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft 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: Wed, 18 Sep 2019 21:36:30 -0000 Roger, On 9/18/19 3:32 PM, Roger Slusser wrote: > Paul, > Think there is a typo maybe... > > draft-ietf-run-rue-00 > > Should it be draft-ietf-rum-rue-00: Right. I was just checking to see if you were paying attention. :-) Paul > Roger Slusser > > > -----Original Message----- > From: Paul Kyzivat > To: rum > Sent: Tue, Sep 17, 2019 4:32 pm > Subject: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft > > RUM followers: > > The deadline for comments on the call for adoption of draft-rosen-rue-01 > concluded on Sunday Sept 15. > > Summarizing the comments that came in: > > - 8 people indicated a desire to adopt; > - 3 people expressed some concerns with the document. > > In my judgement the concerns raised are all worth of further pursuit. > But I don't see any problem in addressing those via revisions to the > proposed document. Since no alternative document has been offered, I > conclude that we should adopt draft-rosen-rue-01 as a working group > document aimed at satisfying our sole milestone: "Submit a profile of > SIP and media features for use with video relay services to the IESG for > publication". > > The author is requested to submit a new version of the document ASAP, > with the name changed to: draft-ietf-run-rue-00 signifying it as a WG > document. > > I also request that people now start posting to this mailing list issues > with this document. Where possible, please start a separate thread with > a meaningful title for each issue in order to facilitate orderly > discussion of the issues. Note that once we seem to have consensus on > the resolution to an issue then suggestions of specific text changes are > welcome. > >     Thanks, >     Paul (as RUM co-chair) > > > On 8/29/19 9:50 AM, Paul Kyzivat wrote: > > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg > > document. This is intended to evolve into the document our charter calls > > for. > > > > Comments, pro or con, on this proposal are due by Sunday September 15. > > > >      Thanks, > >      Paul Kyzivat, as RUM co-chair > > > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From roger.slusser@verizon.net Wed Sep 18 12:32: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 4179C120B77 for ; Wed, 18 Sep 2019 12:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv_lrI7qLkra for ; Wed, 18 Sep 2019 12:32:37 -0700 (PDT) Received: from sonic302-22.consmr.mail.ne1.yahoo.com (sonic302-22.consmr.mail.ne1.yahoo.com [66.163.186.148]) (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 399C1120B71 for ; Wed, 18 Sep 2019 12:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1568835156; bh=JKZcyGC2usm72AbDMYAvEb/5d4M/PZiVfcayNnNQEsg=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=PlgbY3Drp7O9K1Pn9NTXXsJ1g0AwRJDmqETqwRlW0B/UZjb4WDzXVZ201JC+qPa7q9RU7oLiK0MfJSDaa8W7nH72R+D6mDsyBUvfHXUzkuiA3TQx5rdEdHd77IuOMHcAeZkgnGB4EqPTZJ6exy1XTJA7CizZWKclKjy65fnOVTAhq+grmvx5obh/VTCOA6X5dNXL4HUUhNeuql5mqEAl29IfW585UGlUlD17ODjrNKP4IOG83g2mhEnyGsS5Mtskpo+WZ6FxN9LfnDxq838H2MiNGblCP2dJMpd0r62qlEyBNki8dNo9Sd4x91H0GA2rFqx5lhKge9FkJf7C4Lvvmw== X-YMail-OSG: 9HktTbYVM1kXBkRPELzNSfVZ_C.GEUelskVNUiiZzGjNiXyh7ZrAKHGNCZK5Dj0 nocojqNTVr41rPCi.TBiU7fD1w_2cyCqUAG8zziBUIRyKSth4_QQhhP951uwPt8x_0VNkVKf01dg gXBrS0dVflueZ8TwMwLiaAuEWPSbZSaEEAiqSFPU6jh.YTfFa15RobE_4BZbRa6X7d1e.E2KK7_4 5QEcfmeY_31XXGN2CsDRK5Q.bWh5mXVHjoKH1Fhyh.7Tclp9jUqjk1tcb.t4STemow1PpMPwa27v 0IB.Kfui1zcBSQ40fuzD.YbGP7FPTVnSAFkcAM5AOsGfbCURGpV3EmibPnlMuIh.e.LZa66jsD0R rS.jWoaQgzp08CQg0784zY.aKpR7RHZWmzqnO3YicBjOquBH6qGLRnFfEojSYuVbkUZa0woi1q4l X53Wzlcdi0J9T4em02q8JvLmR2PrlUIzqCw08Oz2oSq7xy9czxJMghta4lNYPTni9yX_.aUxwe7m XTsc.OHmXBYO7YvATxSC6xAC9jY8rwIORhc8BUgjG7clivGPO5_ZaVouECzbf8yq5l.aWy41tE9Q NZBfmL3CCtYHarvYeoXeYmSEMSwSpw_gYlrdONRL8TgSuFmV9ws08HDFvWCY2zNBdzsuyi3kQs5I n7RrgvGfM8lhdgNmDSs.8_TkYFyu.zlfYVTFuJICAhmxThAEiwY_gsX62H3jqQ5lumMraw8csBKP vTPmg1slLWaT1Qtcf3sBws6K2Rr99gt.k9UCi1pb9WJWStkR5m12aOEb72AXelPJ4SUiCOP99pDo 1ScX91AelWz88LvGvN5OJKZL2.7nXhhL_9rAojX2vBoMejqIIxib0izw9fwAzzG90v8s___k_LJM 8ClI0HprzhJFBpe6Uf5S2JtemBB33pXnpW401hzjOhHfB4kbnaJMBKrxdMdG9XmchQlcR_CCFcGm yb22uSJ5EBn0b7kBoVnCdA5VX5C6kdptzDse7U82dThSingY4PL7XqKowhadFHV31rJfkK1IYTO1 f6duquzOjVoHYAhV3RYzxpxE5wwxVr4rfnkZ3VPZ66XCbeNNMs2eKd3a3grH._h4UtEzfHE50Pof qp3HLa3UHhGN4FJ0D8wodhgE7cJ2VObsoLjpPGf6ZqqSgnbRuXpSqTururm_FMHHbeJeGxnH36T5 F.dXII9tqbL5KlMHZTPVY_1.FhtrFTLbwZ_iiG2SjENR8fA4roUvsusTXQzdcWiYHEkBZ6bKPTTe wdRLGVd.PrE8UqVSnrRezX8HZZSIdKZhBuHjnsaJ51nWy Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Wed, 18 Sep 2019 19:32:36 +0000 Date: Wed, 18 Sep 2019 19:32:34 +0000 (UTC) From: Roger Slusser To: pkyzivat@alum.mit.edu, rum@ietf.org Message-ID: <686044064.3342929.1568835154612@mail.yahoo.com> In-Reply-To: <9a02e22c-654e-5d3a-991f-150778aa2919@alum.mit.edu> References: <9a02e22c-654e-5d3a-991f-150778aa2919@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3342928_1305730652.1568835154610" X-Mailer: WebService/1.1.14367 aolwebmail Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36 Archived-At: X-Mailman-Approved-At: Wed, 18 Sep 2019 14:37:42 -0700 Subject: Re: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft 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: Wed, 18 Sep 2019 19:41:45 -0000 ------=_Part_3342928_1305730652.1568835154610 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul,Think there is a typo maybe...=C2=A0 draft-ietf-run-rue-00 Should it be draft-ietf-rum-rue-00: Roger Slusser -----Original Message----- From: Paul Kyzivat To: rum Sent: Tue, Sep 17, 2019 4:32 pm Subject: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft RUM followers: The deadline for comments on the call for adoption of draft-rosen-rue-01=20 concluded on Sunday Sept 15. Summarizing the comments that came in: - 8 people indicated a desire to adopt; - 3 people expressed some concerns with the document. In my judgement the concerns raised are all worth of further pursuit.=20 But I don't see any problem in addressing those via revisions to the=20 proposed document. Since no alternative document has been offered, I=20 conclude that we should adopt draft-rosen-rue-01 as a working group=20 document aimed at satisfying our sole milestone: "Submit a profile of=20 SIP and media features for use with video relay services to the IESG for=20 publication". The author is requested to submit a new version of the document ASAP,=20 with the name changed to: draft-ietf-run-rue-00 signifying it as a WG=20 document. I also request that people now start posting to this mailing list issues=20 with this document. Where possible, please start a separate thread with=20 a meaningful title for each issue in order to facilitate orderly=20 discussion of the issues. Note that once we seem to have consensus on=20 the resolution to an issue then suggestions of specific text changes are=20 welcome. =C2=A0=C2=A0=C2=A0 Thanks, =C2=A0=C2=A0=C2=A0 Paul (as RUM co-chair) On 8/29/19 9:50 AM, Paul Kyzivat wrote: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=20 > document. This is intended to evolve into the document our charter calls= =20 > for. >=20 > Comments, pro or con, on this proposal are due by Sunday September 15. >=20 >=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Thanks, >=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Paul Kyzivat, as RUM co-chair >=20 --=20 Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum ------=_Part_3342928_1305730652.1568835154610 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,
Think there is a typo maybe... 
draft-ietf= -run-rue-00
Should it be draft-ietf-rum-rue-00:<= /span>

Roger Slusser


-----= Original Message-----
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: rum <rum@ietf.org>
Sent: Tue, Sep 17, 2019 4:32 pm
Subject: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft

RUM followers:

The de= adline for comments on the call for adoption of draft-rosen-rue-01
concluded on Sunday Sept 15.

Summarizing the comments that came in:

- 8 people indicated a desire to adopt;
- 3 people exp= ressed some concerns with the document.

In my judgement the concerns raised are all worth of further pursuit. But I don't see any problem in addressing those via revisio= ns to the
proposed document. Since no alternative docume= nt has been offered, I
conclude that we should adopt dra= ft-rosen-rue-01 as a working group
document aimed at sat= isfying our sole milestone: "Submit a profile of
SIP and= media features for use with video relay services to the IESG for
publication".

The author is = requested to submit a new version of the document ASAP,
= with the name changed to: draft-ietf-run-rue-00 signifying it as a WG
document.

I also request= that people now start posting to this mailing list issues
with this document. Where possible, please start a separate thread with =
a meaningful title for each issue in order to facilitate= orderly
discussion of the issues. Note that once we see= m to have consensus on
the resolution to an issue then s= uggestions of specific text changes are
welcome.

    Thanks,
=     Paul (as RUM co-chair)


On 8/29/1= 9 9:50 AM, Paul Kyzivat wrote:
> This is a call for th= e adoption of draft-rosen-rue-01 as a RUM wg
> docume= nt. This is intended to evolve into the document our charter calls
> for.
>
> Comment= s, pro or con, on this proposal are due by Sunday September 15.
>
>      Thanks,>      Paul Kyzivat, as RUM co= -chair
>

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
------=_Part_3342928_1305730652.1568835154610-- From nobody Mon Sep 23 12:48:33 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 D4F4E1200DB for ; Mon, 23 Sep 2019 12:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 l6a3ogfVEgNX for ; Mon, 23 Sep 2019 12:48:30 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 8F59812000F for ; Mon, 23 Sep 2019 12:48:30 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id d22so6941416pll.7 for ; Mon, 23 Sep 2019 12:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=A9r7HxZlPp/kRDEvsQBD9TA1WdY6XQ6szrqgGEnA7JU=; b=0gWxuH+4zQu2yThUUD4NHoxk+R9+oidAAHE+hRBYgBJIzfunvZEB72TZw6DwUidWwi PGAJF5MR/3+olVbecaAUFRi3c2EIeASe3w5PuJGDkqn4RWpHdgEejcWWGJX2gmhlGHKq +pgv8hWEfH4u24h/3iyiAGxgVnc89KU+g1KpZZeEMF/tjWwtXZyYeTbi6d8SiD5BRf4R YmMXb2O1GpeXFudPMid0KyjqaKUst6meY4roesGehc4gIh4hJpjIPMnXDvE7dGDRWQ5E okNgnGAmA4kZ/yvFf0YilkiQoQret7ZpiQhoXJ1QYc7QIsVnzM3dIrxCJNeB+IT4ETC1 5T0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=A9r7HxZlPp/kRDEvsQBD9TA1WdY6XQ6szrqgGEnA7JU=; b=NVS9x1Ef8dNtnkfQm19U3nE+Lyx5s0Pc2zFLF4O1Y+onMZ+LVvIZcynN1zCiu+4L5b 5hdP8FWpkKXRvaXFiySUPxUaGSNaofkgPzLRloHrnkzNZq/KTj2vqrDUUWWqNBIC+4pE HzGfGeQ9c4D0nFwKEXoaRujyUYv2FwFrZJHFPlIeDfLOD/lFy2CpZoa8J7grDFlxzDIP 7TH/Pg3GDBjMLG2RIcZpCBhT/nDN1/bHMX3jw3+hpsX8AvgdAVmlNXuVieTlC4rqYzMD g1G8ny2RmhIXUfbRwt1kxRenHAKJNoHGUeKOLwSjvgpx0XI9fdHaTDuyWp4jDLFKiIFx E6lg== X-Gm-Message-State: APjAAAW5ZXLVxNrQ/d4dSVCqp5/I0clm66o0+T8at1n2o19hsy/lqryg ugGI/w9dDmw7GehZ4K4xxyPLFl0zDK8= X-Google-Smtp-Source: APXvYqxTm/V6pYM1RA8If+OqYrNKuVyJ9VR8LbiweajPW5L84F5fmugL7vowQzTkuSCnRvfMJcV5qQ== X-Received: by 2002:a17:902:8649:: with SMTP id y9mr1368613plt.252.1569268108727; Mon, 23 Sep 2019 12:48:28 -0700 (PDT) Received: from brians-mbp-2623.lan ([148.64.109.153]) by smtp.gmail.com with ESMTPSA id y7sm5105791pgj.35.2019.09.23.12.48.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Sep 2019 12:48:27 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <648F2815-DD87-48D9-8B2E-198FCC91AF47@brianrosen.net> Date: Mon, 23 Sep 2019 12:48:26 -0700 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Rum] Edits as I release draft-ietf-rum-rue-00 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: Mon, 23 Sep 2019 19:48:32 -0000 Does anyone object if I: 1. Change to V3 of xml2rfc 2. Remove references to US-only constructs 3. Remove requirement for VP8 video 4. Remove non-used references causes by the switch to WebRTC media specs? I have something pretty much ready to submit that does that. Brian From nobody Wed Sep 25 10:53:35 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 9543912085B; Wed, 25 Sep 2019 10:53:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rum@ietf.org Message-ID: <156943400655.28938.13952603073833626988@ietfa.amsl.com> Date: Wed, 25 Sep 2019 10:53:26 -0700 Archived-At: Subject: [Rum] I-D Action: draft-ietf-rum-rue-00.txt 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, 25 Sep 2019 17:53:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Relay User Machine WG of the IETF. Title : Interoperability Profile for Relay User Equipment Author : Brian Rosen Filename : draft-ietf-rum-rue-00.txt Pages : 28 Date : 2019-09-24 Abstract: Video Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be supplied by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other dead/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document describes the interface between a videophone and a provider. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rum-rue-00 https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 27 08:28:30 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 A99971208CD; Fri, 27 Sep 2019 08:28:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.103.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156959809566.12431.11895845761444538230@ietfa.amsl.com> Date: Fri, 27 Sep 2019 08:28:15 -0700 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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, 27 Sep 2019 15:28:16 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3755/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Sun Sep 29 11:03:46 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 CFBC8120073 for ; Sun, 29 Sep 2019 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 vsefIZNrfepk for ; Sun, 29 Sep 2019 11:03:44 -0700 (PDT) Received: from se3b-lax1.servconfig.com (se3b-lax1.servconfig.com [192.249.122.52]) (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 68E0B120089 for ; Sun, 29 Sep 2019 11:03:44 -0700 (PDT) Received: from biz221.inmotionhosting.com ([192.145.239.201]) by se3-lax1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1iEdXd-000vF3-QV for rum@ietf.org; Sun, 29 Sep 2019 14:03:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Content-Type:MIME-Version:To:From: In-Reply-To:Subject:Date:Sender:Reply-To:Message-ID:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=7gnmXx++rPlB7Tohn1vuG8rrJrAHD9xgU3CfzNwcuZ4=; b=siRYiVP+G/CW M2PnQ4RcmjVMyPC133r1LtXsj4Si1SAYqZ6wjrPK6dxKuQnOTPsJh0uSCmjCFvSdjzhJTvSJktRiW T8gJWlMkJgbNQ0bk6KcVJJN6e62DLo4AsjTLa3A/nZOR42f6vgiw4af07aiJhUgFWRr5MsVxwb2Nl Ei18w=; Received: from [174.204.13.20] (port=7883 helo=[100.85.180.76]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iEdXJ-0056Bo-EV for rum@ietf.org; Sun, 29 Sep 2019 11:03:21 -0700 SavedFromEmail: eburger@standardstrack.com Date: Sun, 29 Sep 2019 14:03:07 -0400 In-Reply-To: <156959809566.12431.11895845761444538230@ietfa.amsl.com> Importance: normal From: Eric Burger To: rum@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_219380752397280" X-OutGoing-Spam-Status: No, score=-1.0 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 Message-ID: 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: ham X-SpamExperts-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVpZSfLYsg3Sr2 p3QH3iIGAkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwzmmD1lPZONmDbVrCI7lkOfH zJ6mVE7ewsipSVIfs4ZbZFe90A5JLl/ZIDb5P9LsgyWFxOA5dILPypvKxNVhWW9iu9q1oNVH8nhC o/XpZxc/iXnuUw31frArk475PTzt0p8T4Nd45j4kJRgJ8MJ6+D+G8xlBbX8yqaxc3Ca/JhYRxK5O dUqDGvgvOW0ZV5+aaHwJ2eESrUp0Iw/gSJ3HqMuR600P9eQ3vodupN36MrkzGQZS068e3EYTgNAB jZkD8TzPF4eG61o+cxFZrUIXowfXJosMX5ZQSlYSVlCDu2lHfay0qiZGlWA7cME1MR87KvWTUIuw AP+Be6QqMx/OK6S8tu2KVBI79Uufvsp4JVtkiXe41lqpq2ZOFKLzbBWXp6KrPCklAmnloYenuVMJ ithDlN3ZFexZfYgAG9qTPTrzvgwP9cMw+lye/qXkeuruM49zcQbne4vePgcv4iEyyps9zSZic0xN U+sMoNUh1wvbY7cuSA8rr1IX2jbfhdHpdXlHxUbN/5WT0Em3hIRYjZwaMZQYNktom9s8Zg3DRxFl 5VsNmjFRP8Tn5HNzDUKU/H6jD7pq5ElFy3fFf2s/xjf9bG4oCE8tXKfGDzsW4pDsxBoFbdIyTZwD 0tTyhMSsSJ3IubBWGgd3tCW2+j49qPy8TH7WSc4+zHum9T07LFpQdjcAy5gAXwhug2pFlRVPtcEH SDJ3e3UjxmxOb8PGwXLYM3A6BXfvel8OEFDbU50IgR7PRT5/DHVWO8a2mKDk6wbUwIyEC/K8KEtW w07pi33IciEhgmtMw3nNgNoOL9aocX5jTqOPXegHd4QqN1stFdDzDETtPsIzc13Og30NySaguH3F iNx1MYrEHZWAQSGSTwMUHD8nvT6qjZo9eXrf6YZflXKvK4TN7SfIl4AyWsJcTQxjOb16oNH/dgmH 4dCci8JLiiOdckUewCJrmQRccHsd8qMjV5g1hoDi6vb8iw== X-Report-Abuse-To: spam@se1-lax1.servconfig.com Archived-At: Subject: Re: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Sun, 29 Sep 2019 18:03:46 -0000 ----_com.samsung.android.email_219380752397280 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SXMgdGhlcmUgYW55dGhpbmcgaW4gdGhlIFJVTSB0aGF0IHJlZmVycyB0byB2aWRlbyBpbnRlcnBy ZXRlciB0ZWFtaW5nIHJlcXVlc3RzIG9uY2UgYW4gaW50ZXJwcmV0YXRpb24gc2Vzc2lvbiBpcyBl c3RhYmxpc2hlZD/CoC0tU2VudCBmcm9tIGEgc21hbGwgZGV2aWNlIHdpdGggYXV0b2NvcnJlY3Qu IFBhcnRpYWwgYmxhbWUgYXQgaHR0cHM6Ly9zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFk ZS9pbmRleC5odG1sCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBJRVRG IFNlY3JldGFyaWF0IDxpZXRmLWlwckBpZXRmLm9yZz4gRGF0ZTogOS8yNy8xOSAgMTE6MjggQU0g IChHTVQtMDU6MDApIFRvOiBkcmFmdC1pZXRmLXJ1bS1ydWVAaWV0Zi5vcmcgQ2M6IHJ1bUBpZXRm Lm9yZywgaXByLWFubm91bmNlQGlldGYub3JnIFN1YmplY3Q6IFtSdW1dIElQUiBEaXNjbG9zdXJl IFNvcmVuc29uIElQIEhvbGRpbmdzIExMQydzIFN0YXRlbWVudCBhYm91dCBJUFIKwqAgcmVsYXRl ZCB0byBkcmFmdC1pZXRmLXJ1bS1ydWUgRGVhciBCcmlhbiBSb3NlbjpBbiBJUFIgZGlzY2xvc3Vy ZSB0aGF0IHBlcnRhaW5zIHRvIHlvdXIgSW50ZXJuZXQtRHJhZnQgZW50aXRsZWQiSW50ZXJvcGVy YWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2VyIEVxdWlwbWVudCIgKGRyYWZ0LWlldGYtcnVt LXJ1ZSkgd2Fzc3VibWl0dGVkIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IG9uwqAgYW5kIGhhcyBi ZWVuIHBvc3RlZCBvbiB0aGUgIklFVEYgUGFnZW9mIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdo dHMgRGlzY2xvc3VyZXMiKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzM3NTUvKS4g VGhlIHRpdGxlIG9mIHRoZSBJUFIgZGlzY2xvc3VyZSBpcyJTb3JlbnNvbiBJUCBIb2xkaW5ncyBM TEMncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1ydW0tcnVlIlRo YW5rIHlvdUlFVEYgU2VjcmV0YXJpYXQtLSBSdW0gbWFpbGluZyBsaXN0UnVtQGlldGYub3JnaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0= ----_com.samsung.android.email_219380752397280 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5JcyB0aGVyZSBhbnl0aGluZyBpbiB0aGUgUlVNIHRoYXQgcmVmZXJzIHRvIHZpZGVvIGlu dGVycHJldGVyIHRlYW1pbmcgcmVxdWVzdHMgb25jZSBhbiBpbnRlcnByZXRhdGlvbiBzZXNzaW9u IGlzIGVzdGFibGlzaGVkPyZuYnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRp diBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgaWQ9 ImNvbXBvc2VyX3NpZ25hdHVyZSIgZGlyPSJhdXRvIj48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+LS08YnIgZGlyPSJhdXRv Ij5TZW50IGZyb20gYSBzbWFsbCBkZXZpY2Ugd2l0aCBhdXRvY29ycmVjdC4gUGFydGlhbCBibGFt ZSBhdCBodHRwczovL3N0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlL2luZGV4Lmh0bWw8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAw MDAwIiBkaXI9ImF1dG8iPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3Jp Z2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogSUVURiBTZWNyZXRhcmlhdCAm bHQ7aWV0Zi1pcHJAaWV0Zi5vcmcmZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogOS8yNy8xOSAgMTE6Mjgg QU0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IGRyYWZ0LWlldGYtcnVtLXJ1ZUBpZXRmLm9y ZyA8L2Rpdj48ZGl2PkNjOiBydW1AaWV0Zi5vcmcsIGlwci1hbm5vdW5jZUBpZXRmLm9yZyA8L2Rp dj48ZGl2PlN1YmplY3Q6IFtSdW1dIElQUiBEaXNjbG9zdXJlIFNvcmVuc29uIElQIEhvbGRpbmdz IExMQydzIFN0YXRlbWVudCBhYm91dCBJUFIKJm5ic3A7IHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1y dW0tcnVlIDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PkRlYXIgQnJpYW4gUm9zZW46PGJyPjxi cj48YnI+QW4gSVBSIGRpc2Nsb3N1cmUgdGhhdCBwZXJ0YWlucyB0byB5b3VyIEludGVybmV0LURy YWZ0IGVudGl0bGVkPGJyPiJJbnRlcm9wZXJhYmlsaXR5IFByb2ZpbGUgZm9yIFJlbGF5IFVzZXIg RXF1aXBtZW50IiAoZHJhZnQtaWV0Zi1ydW0tcnVlKSB3YXM8YnI+c3VibWl0dGVkIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IG9uJm5ic3A7IGFuZCBoYXMgYmVlbiBwb3N0ZWQgb24gdGhlICJJRVRG IFBhZ2U8YnI+b2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBEaXNjbG9zdXJlcyI8YnI+ KGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzM3NTUvKS4gVGhlIHRpdGxlIG9mIHRo ZSBJUFIgZGlzY2xvc3VyZSBpczxicj4iU29yZW5zb24gSVAgSG9sZGluZ3MgTExDJ3MgU3RhdGVt ZW50IGFib3V0IElQUiByZWxhdGVkIHRvIGRyYWZ0LWlldGYtcnVtLXJ1ZSI8YnI+PGJyPjxicj5U aGFuayB5b3U8YnI+PGJyPklFVEYgU2VjcmV0YXJpYXQ8YnI+PGJyPi0tIDxicj5SdW0gbWFpbGlu ZyBsaXN0PGJyPlJ1bUBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J1bTxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_219380752397280-- From nobody Sun Sep 29 11:23:54 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 124FA120089 for ; Sun, 29 Sep 2019 11:23: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bSKsOEqKBSaY for ; Sun, 29 Sep 2019 11:23:51 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 EEBC2120073 for ; Sun, 29 Sep 2019 11:23:50 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id m15so14021402qtq.2 for ; Sun, 29 Sep 2019 11:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lafiS/24lolUqIN/rjkhoM4alnDf4SWjCg4OUQpYE5Y=; b=UpTkeivCJyqJ1W2gO2kfmXeOf0HIfSiPN3MhMy3Kr8WiaFyEFhwxmwQavZSZL2s16F iAHVSzJa+T4VGZNjyjvAYmBGkLKXGj6TL7xcSaKBUX28IeVoR1yQifrRorfgsDRWpbNy ehQGXUKCsgSec5BnehMZHpUEEvRXYaRuva+cRkFrK4ArSf+5SHaTSSOpXlATl+3SArGo SyaLkuRT20hqo8OOVDWo7HiPt0qXEkkaDZhKyc+nsV4tthpRilDvpS1RBmDYhLc1BBvW r0bfu9KWsyAenqF9zvIoRxM7EWxsPguWxZRGSkUL5Ut7aM4CgRusLGZkGGWt6SutWu9c XauQ== 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=lafiS/24lolUqIN/rjkhoM4alnDf4SWjCg4OUQpYE5Y=; b=JuszYRbbKUc9D4A91Zc9tBOJSqihN8GUB6VnkbPxrAz8Ygcd9mm13Nxwf9NBd9+rog 2RH7de2YfD3oISelAvTxrSrozuxOlF1MNxL0fI6/crJgTyLxJo8oL36g8nhtH0NlF//A rdLN5F+X+1XztrUnHzMR1/JCSkeivH/VLvVNcmmBEKCrqSxzjWTKwWvqu3z0U/JP8ePk a22vEE7Itgo4iKCZO/IMpYXeEsWbQ7TjqKJue7AMv/jd4pA32vHw4rfrKQIAwBLDkH2f 1uNvDOe4z7tDYPIY7m11hRBKwbRNUY/D5CKCLpEWQvX2chPS3bEpKG4nTh/i3/ldnwc+ q0hg== X-Gm-Message-State: APjAAAUtCGbXTo7pFCeoNI/9Gs7JpSVZ1O/8Yl18ESMWPuNj1Q47I24i RP5YTY1NsdOX6Ar7nIdIwJuMBBeV1QE= X-Google-Smtp-Source: APXvYqxK3KGSazxqhnLBZtcJIsdDZsCwIZJT8rNgH1iNUDqdcwPCuS1u+pipndMTgxkKQWny3GoKwg== X-Received: by 2002:a0c:e04d:: with SMTP id y13mr17346738qvk.14.1569781429764; Sun, 29 Sep 2019 11:23:49 -0700 (PDT) Received: from ?IPv6:2601:19b:a00:2d20:6935:fa0a:51fd:a1d7? ([2601:19b:a00:2d20:6935:fa0a:51fd:a1d7]) by smtp.gmail.com with ESMTPSA id c12sm4284817qkc.81.2019.09.29.11.23.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Sep 2019 11:23:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Sun, 29 Sep 2019 14:23:36 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <65C2B1EA-26AB-4797-9CCA-9E792DD5740A@brianrosen.net> References: To: Eric Burger X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Sun, 29 Sep 2019 18:23:53 -0000 No that I know of > On Sep 29, 2019, at 2:03 PM, Eric Burger = wrote: >=20 > Is there anything in the RUM that refers to video interpreter teaming = requests once an interpretation session is established?=20 >=20 >=20 >=20 > -- > Sent from a small device with autocorrect. Partial blame at = https://standardstrack.com/ietf/lemonade/index.html >=20 > -------- Original message -------- > From: IETF Secretariat > Date: 9/27/19 11:28 AM (GMT-05:00) > To: draft-ietf-rum-rue@ietf.org > Cc: rum@ietf.org, ipr-announce@ietf.org > Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement = about IPR related to draft-ietf-rum-rue >=20 > Dear Brian Rosen: >=20 >=20 > An IPR disclosure that pertains to your Internet-Draft entitled > "Interoperability Profile for Relay User Equipment" = (draft-ietf-rum-rue) was > submitted to the IETF Secretariat on and has been posted on the "IETF = Page > of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/3755/). The title of the IPR = disclosure is > "Sorenson IP Holdings LLC's Statement about IPR related to = draft-ietf-rum-rue" >=20 >=20 > Thank you >=20 > IETF Secretariat >=20 > --=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