Sonata - SIP provisioning server

I do not know what to compare provisioning with. Maybe with a cat? It seems possible without him, but with him a little better. Especially if it works))

Formulation of the problem:

1. I want to set up SIP phones quickly, easily, safely. When installing the phone and even more so when it is reconfigured.
2. Many vendors have their own configs formats, their own utilities for generating configs, their own way of protecting configs. And to deal with each is not very desirable.
3. Many solutions on provisioning, a) are focused on one vendor or one telephone system, b) are quite cumbersome, a bunch of scripts, parameters, br-p ...

On point 3, I will make a comment that there are excellent systems provided for FreePBX , for FusionPBX , for Kazoo , where there are templates for phones of various vendors in the public domain. There are commercial solutions, where you can also configure in the module the operation of phones from different manufacturers, for example, automatic telephone exchange Yeastar.

Habré is also full of recipes for how to set up various vendors: one , two . But as they say, all systems have a fatal flaw. Therefore we will make your bike.

own format

As they say in xkcd, you do not want to deal with 14 formats - think up the 15th . Therefore, we use the general settings for any phone and make our own json-format config.

Something like this:

{ "key": "sdgjdeu9443908", "token": "590sfdsf8u984", "model": "gxp1620", "vendor": "grandstream", "mac": "001565113af8", "timezone_offset": "GMT+03", "ntp_server": "pool.ntp.org", "status": true, "accounts": [ { "name": "", "line": 1, "sip_register": "sip.mobilonsip.ru", "sip_name": "sip102", "sip_user": "sip102", "sip_password": "4321", "sip_auth": "sip102" } ] } 

So, in any phone you need to configure local time, sip-lines. It's simple. More examples can be found here .

your server is provisioned

In the manufacturer’s manuals there is usually a clause where it says: take a csv, write down the login-password-mac-address there, with our proprietary script, generate files, put them under the Apache web server and it will be fine.

The next paragraph of the manual is usually told what else you can encrypt the generated config file.

But this is all a classic. The modern approach with smoothies and twitter says that you need to make a ready webserver, which will not be as powerful as Apache, but will only do one small thing. Create and give configs by reference.

We’ll stop here and remember that almost all SIP phones can now get configs via http / https, so we don’t consider any other implementations (ftp, tftp, ftps). Then, each phone knows its MAC address. Therefore, we will make two links: one personal one - according to the device key, the second common one, which works on the basis of a common token and a mac address.

Also, I will not dwell on the zero-config, i.e. setting up the phone from scratch, i.e. you stuck it in the network and he earned the hop. No, in my scenario, you plugged into the network, made a pre-configuration (configured to receive the config from the server provisioning), and then drink the pinhole and reconfigure the phone as it should through the control. Distributing Option 66 is the concern of the DHCP server.

By the way, I was completely tortured to say "provisioning", so the word was reduced to "provision", do not kick, please, with your feet.

And yet: our server has no UI, i.e. user interface. Perhaps, for now, but not sure, because I do not need. But there is an API for saving / deleting settings, getting a list of supported vendors, models, everything is described according to the canons of the swagger specification.

Why API, not UI? Because I already have my own telephone system, then I have a source of credentials, where it is enough for me to take this data, put together the necessary json and publish it on the server. And already the server is provisioned according to the rules specified in the json-file, it will give the correct device its config or will not issue it if the device is not that, or does not meet the criteria specified also in this json'e.

Here is such a microservice provision. Sonata is called, the source code is available on the githab, there is also a ready docker image , an example of using the docker here .

Key Chips:

• in any case, limited access to the configuration by time, the default is 10 minutes. If you want to make the config available again, republish the configuration again.

  
  

• one format for all vendors, all the tweaking is removed in sonata, you send standardized json, you configure any available equipment.

  
  

• all issued configs to devices are logged, all problem areas can be viewed in the log and see errors

  
  

• it is possible to use one common link with token, each phone receives its config by specifying the mac-address. Or a personal link by key.

  
  

• API for management (management) and issuing configs to phones (provisioning) are divided by ports

  
  

• Tests For me it was very important to fix the format of the issued config and cover all the usual situations of issuing a config with tests. To make it all work clearly.

  
  

Minuses:

So far, no encryption is used within the sonata framework. Those. Of course, you can start using https, putting for example, nginx, in front of sonata. But proprietary methods are not yet involved. Why? The project is still young, it is unlikely that its first hundred devices were blocked. And, of course, I collect ideas, feedback. Further, to make everything secure so that configs cannot be sniffed on the network, it is probably worth confusing with the encryption keys, tls and hedgehog with them, but this will be a continuation.

Lack of UI. Perhaps this is a significant disadvantage for the end user, but for the system administrator, the console utility is more important than a full-fledged application. Make a console utility was in the plans, but not sure whether it is needed?

What is the result?

A small and simple web server for providing multiple phone models with management APIs.

Once again, how should this work?

1. Install the sonata.
2. We form json-config and publish it in sonata.
3. Then we get the link for provision from sonata.
4. Then we indicate this link in the telephone set.
5. The device tightens the config

in subsequent operation only two steps:

1. We form json-config and publish it in sonata
2. The device tightens the config

What phones are provided?

Vendors Grandstream, Fanvil, Yealink. Configs within the vendor are more or less the same, but may differ depending on the firmware - it may be necessary to test it additionally.

What rules can I set?

By the time. You can specify the time until which the config will be available.
By mac-address. When the config is returned via the device's personal link, the mac-address will also be checked.
By ip. By ip-address where the request was made.

How to interact with sonata?

Through the API, making http requests. The API will be available in your installation. Because The API supports the swagger specification, you can use the online utility for test requests to the API.

OK, great. Cool thing, how to try?

The easiest way is to deploy a docker image based on the sonata-sample repository. In the repository is installation instructions.

And if I know node.js?

If you have experience using JavaScript, then you will quickly understand how everything works here.

Will the development of sonata?

I partially achieved my goals. Further development is a question of my tasks on automating phone settings. There is also an opportunity to expand configs to customize phone buttons, add address books, maybe something else, write in the comments.

Resume and Thanks

I will be glad to constructive suggestions / objections / comments and questions, because may well be something incomprehensibly described.

I also thank all the colleagues who helped, advised, tested, provided / donated test phones. In reality, a lot of people with whom I spoke at work, in chat rooms and emails participated in the project in various ways. Thanks for the ideas and thoughts.