Re: [Rum] Distinguishing RUE and Provider requirements

I’ll add some explanatory text.

I think the example you gave is probably a good illustration of MTI vs MTU.

Brian

> On Nov 4, 2019, at 11:23 AM, James Hamlin <james.hamlin@purple.us> wrote:
> 
> Thanks Brian
> 
> I understand your interpretation of MTI, but I know that someone writing a test schedule based on the RUM document will write a test that expects to see all MTI codecs in any offer SDP; and from reading the RFCs it will be difficult to positively show that they are wrong.
> 
> So I agree that some explanatory text would fix this. 
> 
> James
>  
> From: Brian Rosen <br@brianrosen.net>
> Sent: 04 November 2019 15:33
> To: James Hamlin
> Cc: rum@ietf.org; Paul Kyzivat
> Subject: Re: [Rum] Distinguishing RUE and Provider requirements
>  
> Mandatory to Implement doesn’t mean mandatory to use.  In the example of an incoming call from the PSTN, offering G.711 only is appropriate, and transcoding would not be advisable.
> 
> The IETF folk understand MTI, but perhaps some explanatory text would be helpful in the document.
> 
> Brian
> 
>> On Nov 4, 2019, at 7:56 AM, James Hamlin <james.hamlin@purple.us <mailto:james.hamlin@purple.us>> wrote:
>> 
>> Paul
>> 
>> In the draft-ietf-rum-rue-00, there's an exemption from VP8 support for providers but no exemption from Opus support. The implication is that, in a call from the PSTN using Voice Carry Over, the provider must offer OPUS even though the audio content is constrained to 8bit*8kHz PCM over the PSTN. I don't recall seeing any argument for requiring transcoding in this case; there would be no benefit in audio quality.
>> 
>> Best regards
>> 
>> James
>> 
>> ________________________________________
>> From: Rum <rum-bounces@ietf.org <mailto:rum-bounces@ietf.org>> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>
>> Sent: 01 October 2019 20:15
>> To: rum@ietf.org <mailto:rum@ietf.org>
>> Subject: [Rum] Distinguishing RUE and Provider requirements
>> 
>> In the discussion thread that followed the attached message it started
>> to become apparent that there is a need to distinguish the requirements,
>> and/or requirement strength, that apply to the RUE itself from those
>> that apply when a RUE connects to a VRS Provider.
>> 
>> Now that we have a wg draft to work from, I would like to see people
>> step forward and make proposal(s) for what those differences should be.
>> 
>> While the prior discussion focused on codecs, please also consider what
>> else might need to differ.
>> 
>>        Thanks,
>>        Paul
>> 
>> -------- Forwarded Message --------
>> Subject: [Rum] Codec requirements in draft-rosen-rue-01
>> Resent-From: pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
>> Date: Mon, 12 Aug 2019 16:20:51 -0400
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>
>> To: rum@ietf.org <mailto:rum@ietf.org>
>> 
>> draft-rosen-rue-01 changes the video codec requirements. It now simply
>> references webrtc RFC7742.
>> 
>> RFC7742 distinguishes three types of endpoints: "WebRTC browser",
>> "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes
>> that each end is one of these.
>> 
>> Is the expectation here that both the RUE and the provider comply with
>> one of these? In particular, that the provider may simply be a
>> "WebRTC-compatible endpoint? Notably:
>> 
>>    "WebRTC-compatible endpoints" are free to implement any video codecs
>>    they see fit.  This follows logically from the definition of "WebRTC-
>>    compatible endpoint".  It is, of course, advisable to implement at
>>    least one of the video codecs that is mandated for WebRTC browsers,
>>    and implementors are encouraged to do so.
>> 
>> Similarly, the audio requirements have been changed to reference webrtc
>> RFC7874. That one doesn't have the distinction between "WebRTC browser",
>> "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the
>> same requirements to all. In particular, it requires OPUS support. I
>> don't know why it doesn't make the same endpoint distinctions as for video.
>> 
>> I think simply referencing these documents isn't sufficient. Seems like
>> we need a more nuanced specification of what is required, though we may
>> still reference these docs with qualifications.
>> 
>>        Thanks,
>>        Paul
>> 
>> --
>> Rum mailing list
>> Rum@ietf.org <mailto:Rum@ietf.org>
>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0 <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0>
>> 
>> --
>> Rum mailing list
>> Rum@ietf.org <mailto:Rum@ietf.org>
>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0 <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0>
>> 
>> -- 
>> Rum mailing list
>> Rum@ietf.org <mailto:Rum@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rum <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Bi037ncYkGLDqRgIKBuu8VhgsDlD2z_xAy0Yvgpkik9j3_SwXmvpWpRQ7OutVSaBAaChuS42DJ3dBcx3O1_XYHu82ah9COcj5k8eMAjsbWoOy95Oqf-YiiE5gQ,,&typo=0>
> 