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 configure SIP phones quickly, simply, safely. When installing the phone, and even more so when reconfiguring it.
2. Many vendors have their own config formats, their utilities for generating configs, their own ways to protect configs. But I don’t really want to deal with everyone.
3. Many provisioning solutions, a) are focused on one vendor or one telephone system, b) they are rather cumbersome to implement, a bunch of scripts, parameters, br ...

On point 3 I’ll make a comment that there are excellent systems for FreePBX , FusionPBX , Kazoo , where there are publicly available templates for phones of various vendors. There are commercial solutions where it is also possible to configure in the module the performance of telephones of different manufacturers, for example, Yeastar PBX.

On Habré also is full of recipes how to configure devices of various vendors: one , two . But as they say, all systems have a fatal flaw. So make your bike.

own format

As they say in xkcd, 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 the local time, sip lines. Everything is simple here. More examples can be found here .

own server

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

The next paragraph of the manual usually tells you 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-made web server that will not be as powerful as Apache, but will only do one small thing. Form and give configs by reference.

Here we stop and recall that almost all SIP phones can now receive configs via http / https, so we do not consider other implementations (ftp, tftp, ftps). Then, each phone knows its own poppy address. Therefore, we will make two links: one personal - on the key of the device, the second general, which works on a bunch of common token and poppy address.

Also, I will not dwell on zero-config, i.e. setting up the phone from scratch, i.e. You stuck it in the network and it earned a hop. No, in my scenario, you stuck it in the network, made a preliminary configuration (configured it to receive the config from the server), and then drink some chocolate and reconfigure the phone as needed through the service. Distributing Option 66 is the concern of the DHCP server.

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

And one more thing: 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 an API, not a UI? Because I already have my own telephone system, then, I have a source of credentials, where I just need to take this data, compose the necessary json and publish it on the server. And already the server is secure according to the rules specified in the json-file, it will give out the config to the necessary device or will not give out if the device is wrong, or does not meet the criteria specified in this json as well.

Here is such a microservice provision turned out. It is called sonata , the source code is available on the github, there is also a ready-made docker image , an example of using docker here .

Key features:

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

  
  

• one format for all vendors, all tuning 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 own config by specifying the mac address. Or a personal link on key.

  
  

• The APIs for management and provisioning are split across ports

  
  

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

  
  

Minuses:

So far, sonata encryption has not been used. Those. Of course, you can start using https by putting nginx, for example, before sonata. But here are the proprietary methods not yet involved. Why? The project is still young, almost overturned its first hundred devices. And, of course, I collect ideas, feedback. Further, in order to make everything safe so that configs cannot be sniffed on the network, it is probably worth bothering with encryption keys, tls and a hedgehog with them, but this will be a continuation.

Lack of UI. Perhaps this is a significant minus for the end user, but for the system administrator, the console utility is more important than a full-fledged application. There were plans to make a console utility, but not sure if it is needed?

What is the result?

Small and simple web server for provisioning several phone models with API for management.

Once again, how should this work?

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

there are only two steps in subsequent operation:

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

What kind of phones are uploaded?

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 additionally.

What rules can be set?

By time. You can specify the time until which the config will be available.
By mac address. When you send the config via the personal link of the device, the mac address will also be checked.
By ip. By ip-address, from 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 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?

Проще всего развернуть docker-образ на основе репозитория sonata-sample. В репозитории лежит инструкция по установке.

А если знаю node.js?

Если у вас есть опыт использования JavaScript, то вы быстро разберетесь как все здесь устроено.

Будет ли развитие sonata?

Частично своих целей я достиг. Дальнейшее развитие — это вопрос моих задач по теме автоматизации настройки телефонов. Есть еще возможность расширить конфиги для настройки кнопок телефона, добавить провижн адресных книжек, возможно еще что-то, напишите в комментариях.

Резюме и благодарности

Буду рад конструктивным предложениям/возражениям/комментариям и вопросам, т.к. вполне может быть что-то непонятно описал.

I also thank all the colleagues who helped, advised, tested, provided / donated phones for tests. Actually, a lot of people with whom I talked at work, in chat rooms and emails were involved in the project to a different extent. Thanks for the ideas and thoughts.