Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration

[Brian Rosen <[e-mail]>]

> On Feb 12, 2020, at 11:49 AM, Paul Kyzivat <[e-mail]> wrote:
> 
> Hi James,
> 
> I'm happy to see you posting here.
Me too!
> 
> On 2/12/20 7:28 AM, James Hamlin wrote:
>> Brian
>> We do need to be clear, that:-
>>  * A VRS user needs an account with a provider before they can use the
>>    service.
> 
> With *a* provider. Given that, they can get service from another provider via dial around. And/or they can have accounts with multiple providers.
> 
> If the RUE supports connections to multiple providers, and also supports one-stage dial-around then the distinction between the two, at least for outgoing calls, will be subtle.
My thoughts on this are that we require support for 3261 authentication on REGISTER and you need to be registered to place or receive calls.  A dial around call isn’t placed directly = it’s through the default provider.

That means I don’t think we need normative language (beyond support for 3261) to get what James is asking for.

> 
>>  * Config settings, especially credentials and phone number, are only
>>    valid for one user account, within the lifetime returned in the JSON
>>    object
>>  * A user-agent header should be supplied when retrieving configuration
>>    so that configuration can be specific to the RUE
> 
> Agree.
> 
> The point I was trying to make is that each provider will want to maintain the config information for its own account. If the user has accounts with multiple providers, then the RUE needs to fetch the config information for each of them from the corresponding provider.
> 
> Separately the RUE will need common config information - notably which providers user has accounts with. I'm imagining that the RUE will hold that locally. If the user has multiple RUEs then it might be helpful to have some common place to store that common config information, but I don't know who would host it.\
We need some ideas on exactly how to do this.  I’ll start a separate thread on that.

> 
> 	Thanks,
> 	Paul
> 
>> Best regards
>> James
>> On 29/01/2020 23:04, Brian Rosen wrote:
>> > The configuration file mechanism needs work.
>> > The current mechanism supports multiple providers in that it allows multiple username/passwords.
>> > That’s probably insufficient.  For example, each provider may have their own TURN server.  Probably, we want to allow any of the parameters to be either in the “top level” part of the object, in which case they apply globally, or in a per-provider part of the object in which case it only applies to that provider.
>> >
>> > There is also the issue of cleartext passwords.
>> >
>> > I was thinking about that, but didn’t really work out a solution.  What I’m thinking about is that maybe there is a single username/password that unlocks the file, and in the file are per-provider records.  The device itself manages the encrypt and decrypt of the file.
>> >
>> > I wondered if we could use .well-known, plus that username, to find the file at the default provider’s website, as listed in the provider file, but the user may have more than one TN at more than one default provider, so I got back to a pre-provisioned URI.
>> >
>> > This update does address all the issues I knew about.
>> >
>> > I got a private email that told me the example config file didn’t lint, and I found two errors that I’ll get into the next revision.  Since we’re likely to change that part of the document anyway, that’s no big deal.
>> >
>> > Someone also asked about why we specified STUN/TURN in the config, but didn’t mention it anywhere else.  It gets into the requirements via the WebRTC transport spec, which requires ICE, which requires STUN/TURN.  So technically, it’s okay, but do we want to point that out?
>> >
>> > Brian
>> >
>> >
>> >> On Jan 29, 2020, at 5:51 PM, Paul Kyzivat <[e-mail]> wrote:
>> >>
>> >> Brian,
>> >>
>> >> Thanks for the update. I think I will have a number of questions once have more time for study, but I have one right off:
>> >>
>> >> Section 9 says that there is one file for device configuration. That won't make it practical for a single RUE to support a user with accounts with multiple providers. Rather, to be workable it will be necessary for there to be a configuration file for each provider that the user of the RUE uses.
>> >>
>> >> The exact mechanism for setting that up needs to be worked out. Perhaps it would be sufficient for there to be another entry, for each provider, in the provider list file that is used by the RUE to retrieve the configuration for that provider.
>> >>
>> >>     Thanks,
>> >>     Paul
>> >>
>> >> On 1/29/20 4:47 PM, [e-mail] wrote:
>> >>> 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-02.txt
>> >>>     Pages           : 28
>> >>>     Date            : 2020-01-29
>> >>> 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-02
>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-02
>> >>> A diff from the previous version is available at:
>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-02
>> >>> 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/
>> >>
>> >> --
>> >> Rum mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/rum
>> >
>> >
> 
> -- 
> Rum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rum