4 the mechanism of remote provisioning, 1 servers, 2 bria-to-server exchange – CounterPath Bria 4 Provisioning Guide - Enterprise Deployments User Manual

Page 9

Advertising
background image

Bria 4 Provisioning Guide – Enterprise Deployments

5

1.4 The Mechanism of Remote Provisioning

Each remote provisioning service involves an exchange between the login server and an individual Bria client.
The exchange is performed over HTTP or HTTPS.

1.4.1 Servers

You must deploy servers to handle the provisioning requests:

The “login server”: a server to handle login requests. This server is simply a web server that, at a minimum,
can serve one plaintext or XML file.

The “update server”: a server to handle remote update, if you decide to implement remote updates.

The “upgrade executable server”: a server to handle remote upgrades of the Bria application, if you decide
to implement remote upgrades.

These server roles may in fact all be deployed on the same physical server: that is your decision.

You must set these servers in Bria.

The login server must be manually entered by the user on the Login dialog, as described in “Specifying the
Login Server” on page 10.

You will set the update server and upgrade executable server (if they are being used) in the provisioning
response that you set the first time the user logs in.

Login Server

The hardware requirements of the login server depend on what the server will do. If it will have a complicated
backend database and processing in order to retrieve the settings that are to be provisioned, then the server
should be of higher processing capabilities. Regardless, the login server is simply a web server and it only needs
to serve one file for provisioning; this file is in plaintext or XML format.

The login server could be a Linux® machine with an Apache™ web server or a Microsoft® Windows®
machine with an IIS web server.

1.4.2 Bria-to-Server Exchange

The exchange between Bria and the appropriate server involves the following:

When the appropriate trigger occurs, Bria sends an HTTP or HTTPS request to the server. For login, the
trigger is the user pressing OK on the Bria login dialog. For remote upgrade, the trigger is startup of the
softphone.

The server responds.

Bria reads the response and takes the appropriate action: starts the softphone and registers with the SIP
proxy, or finds and installs the upgrade.

Use of Scripts and Macros

You may want to run an appropriate script on the given web server, to provide the information required by Bria.
To run a script, include it in the URL for that server.

Running scripts usually requires information about the user’s deployment. The URL for the appropriate server
can include macros. When Bria contacts the server, it replaces the macros with the real data and includes this
information in the HTTPS request.

Advertising