[Free-RTC] QR codes, mobile SIP provisioning, TLS certs

[Olle E. Johansson]

> On 07 Jul 2016, at 19:37, Daniel Pocock <daniel at pocock.pro> wrote:
> 
> 
> 
> Hi all,
> 
> One of the GSoC students, Pranav[1], has had a focus on Java, Android
> and account provisioning
> 
> He has already done some work on a library[2] to allow mobile apps to
> quickly deploy accounts from any ITSP
> 
> One of the next things under discussion is how to make mobile app SIP
> account provisioning with QR codes.
> 
> Every vendor of deskphones has their own provisioning system, they are
> all quite different.  Some are quite effective, e.g. the way Polycom
> puts certificates in every phone to avoid the risk of exposing
> credentials during provisioning or subsequent updates.
> 
> Pranav can potentially create:
> 
> a) a JAR for inclusion in apps like Lumicall and CSipSimple,
> Conversations (XMPP) and Jitsi (on both mobile and desktop)
> 
> b) a REST service running in Apache Tomcat that interacts with the
> client JAR
> 
> The question is, how should the workflow be structured?
> 
> Has anybody seen anything like this already, either for SIP, XMPP or
> other protocols like email accounts?
> 
> What should be in the QR-code, for example, should it just contain a URL
> or parameters for generating a certificate request?
> 
> Once the app starts talking to the URL, what data should be exchanged?
> 
> Does the phone need to prompt the user for any data, e.g.a PIN, or can
> it all be automatic?
> 
> Once the account is initially set up, how will changes to the settings
> be deployed?  Should the phone periodically poll the REST server and
> accept any changes automatically, or should there be a workflow for the
> user to confirm any changes?
> 
> I'm thinking that this facility could work for both per-account settings
> and maybe per-phone settings, but in the latter case we need to make
> sure it can deal with conflicts and let the user override anything.

I think this has to be targeted in many steps. Don’t bother with configuration
file formats, it’s a dead end. Everyone wants to their own thing.

Focus on discovery - how do you discover the provisioning server? And
what credentials do you need to attach to get your configuration? 
Just name them “provdata[x]” and not “user”, “secret” etc because you have no 
idea of what data one wants to send to the server. Make it *very* generic.

If you can attach a fingerprint of the expected TLS cert of the provisioning
server I think that would be a step forward.

/O