Sonata - SIP provisioning server

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

On point 3, I will make a comment that there are excellent provisioning systems 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 the work of phones from different manufacturers in the provisioning module, for example, Yeastar PBX.

HabrΓ© is also full of recipes for setting up devices from various vendors: time, two. But as they say, all systems have a fatal flaw. So let's make our bike.

own format

As xkcd says, if you don't want to deal with 14 formats - come up with the 15th. Therefore, we use the general settings for any phone and make our own json config format.

Roughly 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 set up local time, sip-lines. Everything is simple here. More examples can be seen here.

your server is provisioned

The manufacturer's manuals usually have a paragraph that says: take csv, write down the login-password-mac-address there, generate files with our proprietary 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 do and encrypt the generated config file.

But it's all classic. The modern smoothie and twitter approach is to make a ready-made web server that isn't as powerful as Apache and does just one little thing. Generate and send configs by reference.

Let's stop here and remember that almost all SIP phones can now get configs via http/https, so we don't consider other implementations (ftp, tftp, ftps). Then, each phone knows its own MAC address. Therefore, we will make two links: one is personal - by the device key, the second is general, which works by linking a common token and a poppy address.

Also, I will not dwell on zero-config, i.e. setting up the phone from scratch, i.e. you plugged it into the network and he hop earned. No, in my scenario, you plugged it into the network, made a preliminary configuration (configured it to receive a config from the provision server), and then drink pinocolade and reconfigure the phone as it should through the provision. Handing out Option 66 is up to the DHCP server.

By the way, I’m completely tired of saying β€œprovisioning”, so the word was reduced to β€œprovisioning”, please don’t kick with your feet.

And one more thing: our proxy server does not have a UI, i.e. user interface. Possibly yet, but I'm not sure, because. I don't 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 and not UI? Because I already have my own phone 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 provisioning server. And already the server, according to the rules specified in the json file, will give the necessary device its config or not, if the device is not the right one, or does not meet the criteria also specified in this json.

Sonata - SIP provisioning server

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

Key features:

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

  • one format for all vendors, all customization 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 a token, each phone receives its own config by specifying the mac-address. Or a personal link by key.

  • API for managing (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 the config with tests. To make sure it all works.

Cons:

So far, there is no encryption used in the framework of sonata. Those. you can of course start using https by putting nginx before sonata for example. But branded methods are not yet involved. Why? The project is still young, it has just launched its first hundred devices. And, of course, I collect ideas and feedback. Further, in order to make everything safe so that the configs cannot be sniffed on the network, it is probably worth getting confused on encryption keys, tls and their hedgehogs, but this will be continued.

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

The result?

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

Once again, how is this supposed to work?

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

in subsequent operation, only two steps:

  1. We form a json config and publish it to sonata
  2. The device is tightening the config

What phones are being promoted?

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 uploading the config via the device's personal link, the mac-address will also be checked.
by ip. By the 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 The API supports the swagger specification, you can use online utility for test API requests.

OK, great. The thing is cool, how to try?

The easiest way to deploy a docker image based on a repository sonata sample. The repository contains installation instructions.

What if I know node.js?

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

Will there be development of the sonata?

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

Summary and Acknowledgments

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

I also express my gratitude to all colleagues who helped, advised, tested, provided / donated phones for tests. In fact, the project involved in varying degrees, a lot of people with whom I talked at work, on AsterConf'e, in chats and emails. Thanks for the ideas and thoughts.

Source: habr.com

Add a comment