Subject: Re: [Rum] Proposed Solution for Configuration

From: James Hamlin <[email-masked]>
Date: Fri, 4 Dec 2020 14:58:02 +0000

Brian

Just one small point: it would be good to keep the amount of data in any centrally managed list to a minimum. A list of Provider names and domains names, would be enough for the RUM RUE to display a list of providers to the user and to go to the provider's domains to get further information. Centrally managed data will always cause an administrative headache.

Best regards

James

James Hamlin
Contractor
Purple, a Division of ZP Better Together, LLC
purplevrs.com
The information contained in this e-mail message is intended
only for the personal and confidential use of the recipient(s)
named above. If you have received this communication in error,

please notify us immediately by e-mail, and delete the original
message.

From: Brian Rosen <[email-masked]>
Message-Id: <[email-masked]>
Date: Thu, 3 Dec 2020 12:25:27 -0500
To: [email-masked]
Subject: [Rum] Proposed Solution for Configuration
List-Id: Relay User Machine <rum.ietf.org>
List-Post: <mailto:[email-masked]>
Sender: "Rum" <[email-masked]>

Olle will have an alternative proposal, here is mine.

I start with the provider list.  There is a list of providers per country.  There is an IANA registry that has a country code and a URL to get that list.

The list has an entry per provider.  The entry has sets of data objects, one set per language supported.  Each set is an object with Iname for the provider, a URL for its configuration service, a URL for its customer sign up service, a URL for a help desk, and a SIP URI for a dial around front door.

A user starts with the sign up service, which uses a browser.  The result is a username/password for the account.

The RUE has an administrative account, which it maintains locally.  There is a username and password for that.  The RUE stores the URLs for a provider configuration service, username and password locally.  Only a user with the administrative username/password can see or change the data.

When the RUE restarts for any reason, or following a change in username/password, it connects to the configuration service via HTTPS, authenticates with username/password and provides the API Key.  If the API Key is good, the configuration service responds with all of the server information (Registrar, outbound proxy, TURN server, ...) for that user.

The RUE then configures for that provider, REGISTERs with the stored username and password, and is then ready to place or receive calls.

I'm thinking about some cleverness where if the RUE provides the browser that is used to sign up, perhaps there is a secure way for the provider to download username/password so it can be locally stored as above, so the user doesn't have to enter it into the RUE.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 4 Dec 2020 10:01:00 -0500

James

Thanks for the comment.  I think you are right.  There is a tradeoff of how much mechanism providers will supply vs managing the list.  If providers were willing to return an object to any querier on, say, a “well known” URL in the domain contained in the central list, then, as you suggest, all we need is the display name and that domain.

Definitely willing to write the text that way.

Brian

> On Dec 4, 2020, at 9:58 AM, James Hamlin <[email-masked]> wrote:
> 
> Brian
> 
> purplevrs.com <http://purplevrs.com/>
> From: Brian Rosen <[email-masked] <mailto:[email-masked]>>
> Message-Id: <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> List-Id: Relay User Machine <rum.ietf.org <http://rum.ietf.org/>>
> List-Post: <mailto:[email-masked] <mailto:[email-masked]>>
> Sender: "Rum" <[email-masked] <mailto:[email-masked]>>
> 
> When the RUE restarts for any reason, or following a change in username/password, it connects to the configuration service via HTTPS, authenticates with username/password and provides the API Key.  If the API Key is good, the configuration service responds with all of the server information (Registrar, outbound proxy, TURN server, …) for that user.
> 
> I’m thinking about some cleverness where if the RUE provides the browser that is used to sign up, perhaps there is a secure way for the provider to download username/password so it can be locally stored as above, so the user doesn’t have to enter it into the RUE.
> 
> Brian
> 
>

---

From: Eugene Christensen <[email-masked]>
Date: Wed, 9 Dec 2020 18:17:06 +0000

I also agree with James “to keep the amount of data in any centrally managed list to a minimum”.

CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked]<mailto:[email-masked]> or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.

From: Rum <[email-masked]> On Behalf Of Brian Rosen
Sent: Friday, December 4, 2020 8:01 AM
To: James Hamlin <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] Proposed Solution for Configuration

[EXTERNAL] James

Brian

On Dec 4, 2020, at 9:58 AM, James Hamlin <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Best regards

James

James Hamlin
Contractor
purplevrs.com<http://purplevrs.com/>

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>

Message-Id: <[email-masked]<mailto:[email-masked]>>

To: [email-masked]<mailto:[email-masked]>

List-Id: Relay User Machine <rum.ietf.org<http://rum.ietf.org/>>

Sender: "Rum" <[email-masked]<mailto:[email-masked]>>

Brian