Sonata – serveur de provisioning SIP

Je ne sais pas à quoi comparer le provisioning. Peut-être à un chat ? On pourrait s'en passer, mais avec lui, c'est un peu mieux. Surtout s'il fonctionne ))

Problématique :

1. Je veux configurer les téléphones SIP rapidement, simplement et en toute sécurité. Lors de l'installation du téléphone, et encore plus lors de sa reconfiguration.
2. De nombreux fournisseurs ont leurs propres formats de configuration, leurs outils pour générer des configurations, et leurs méthodes de protection. Et s'y retrouver à chaque fois n'est pas vraiment agréable.
3. De nombreuses solutions de provisioning sont a) orientées vers un seul fournisseur ou un seul système téléphonique, b) assez encombrantes à mettre en place, avec une multitude de scripts, de paramètres, blablabla…

Concernant le point 3, je ferai un commentaire : il existe d'excellents systèmes de provisioning pour FreePBX, pour FusionPBX, pour Kazoo, qui mettent à disposition des modèles pour les téléphones de différents fournisseurs. Il existe également des solutions commerciales où l'on peut configurer, dans le module de provisioning, le fonctionnement des téléphones de différents fabricants, par exemple, les PABX Yeastar.

Il y a aussi plein de recettes sur Habr pour configurer les appareils de divers fournisseurs : un, deux. Mais comme on dit, tous les systèmes ont un défaut fatal. Donc, nous allons créer notre propre vélo.

notre propre format

Comme le dit xkcd, si tu ne veux pas gérer 14 formats — inventes-en un 15ème. Donc, nous utilisons des paramètres généraux pour n'importe quel téléphone et allons créer notre propre format de config JSON.

En gros, quelque chose comme ça :

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

Donc, dans n'importe quel téléphone, il est nécessaire de configurer l'heure locale, les lignes SIP. C'est assez simple. D'autres exemples peuvent être consultés ici.

sur notre serveur de provisioning

Dans les manuels du fabricant, il y a généralement un point qui indique : prenez un fichier CSV, enregistrez-y le nom d'utilisateur, le mot de passe et l'adresse MAC, générez des fichiers avec notre script propriétaire, placez-les sous le serveur web Apache et tout ira bien.

Dans le point suivant du manuel, il est généralement expliqué qu'il est également possible de chiffrer le fichier de configuration généré.

Mais c'est tout de la classique. L'approche moderne avec des smoothies et Twitter indique qu'il faut créer un serveur web prêt à l'emploi, qui ne sera pas aussi puissant qu'Apache, mais qui fera une seule petite tâche. Fournir et renvoyer des configurations via un lien.

Arrêtons-nous ici et rappelons-nous que presque tous les téléphones SIP peuvent maintenant obtenir des configurations via http/https, donc nous ne considérerons pas d'autres mises en œuvre (ftp, tftp, ftps). Ensuite, chaque téléphone connaît son adresse MAC. Nous ferons donc deux liens : l'un personnel - par une clé d'appareil, l'autre général, qui fonctionne par une combinaison de jeton commun et d'adresse MAC.

Je ne vais pas non plus m'attarder sur le zero-config, c'est-à-dire la configuration du téléphone « à partir de zéro », c'est-à-dire que vous l'avez branché sur le réseau et il a fonctionné. Non, dans mon scénario, vous l'avez branché sur le réseau, vous avez effectué une configuration préalable (configuré pour obtenir la configuration du serveur de provisionnement), puis vous sirotez une piña colada et reconfigurez le téléphone comme il se doit via le provisionnement. Fournir l'Option 66 est la responsabilité du serveur DHCP.

À propos, j'en ai assez de dire « provisionning », alors le mot a été abrégé en « provision », ne me tapez pas, s'il vous plaît.

Et aussi : notre serveur de provisionnement n'a pas d'UI, c'est-à-dire d'interface utilisateur. Peut-être, pour l'instant, mais je ne suis pas sûr, car je n'en ai pas besoin. En revanche, il y a une API pour sauvegarder/supprimer des paramètres, obtenir la liste des fournisseurs supportés, des modèles, tout est décrit selon les règles de la spécification swagger.

Pourquoi une API plutôt qu'une UI ? Puisque j'ai déjà mon propre système téléphonique, j'ai une source d'identifiants, où je peux simplement récupérer ces données, composer le json nécessaire et le publier sur le serveur de provisionnement. Et le serveur de provisionnement, selon les règles spécifiées dans le fichier json, fournira à l'appareil approprié sa configuration ou ne la fournira pas, si l'appareil n'est pas le bon, ou ne correspond pas aux critères également spécifiés dans ce json.

Voilà, un microservice de provisionnement a été créé. Il s'appelle sonata, le code source est disponible sur GitHub, il y a aussi un image Docker prête à l'emploi, exemple d'utilisation de Docker ici.

Caractéristiques clés :

• dans tous les cas, un accès limité à la configuration dans le temps, par défaut 10 minutes. Si vous souhaitez rendre la configuration à nouveau accessible, republiez la configuration.

• un format pour tous les fournisseurs, tout le réglage est intégré dans sonata, vous envoyez un json standardisé, paramétrez n'importe quel équipement disponible.

• Tous les fichiers de configuration fournis aux appareils sont journalisés, tous les problèmes peuvent être consultés dans le journal et les erreurs peuvent être vues.

• Il est possible d'utiliser un lien commun avec un token, chaque téléphone reçoit sa propre configuration en indiquant l'adresse MAC. Ou un lien personnel par clé.

• L'API pour la gestion et la délivrance des configurations aux téléphones est séparée par ports.

• Tests. Il était très important pour moi de fixer le format de la configuration fournie et de couvrir toutes les situations normales de délivrance de configuration par des tests. Pour que tout fonctionne correctement.

Inconvénients :

Aucune encryption n'est actuellement utilisée dans le cadre de Sonata. C'est-à-dire que vous pouvez bien sûr commencer à utiliser https en plaçant par exemple Nginx devant Sonata. Mais les méthodes propriétaires ne sont pas encore mises en œuvre. Pourquoi ? Le projet est encore jeune, il a à peine provisionné sa première centaine d'appareils. Et bien sûr, je recueille des idées, des retours. Ensuite, pour rendre tout cela sécurisé, afin que les configurations ne puissent pas être sniffées sur le réseau, il vaut probablement la peine de se pencher sur les clés de chiffrement, SSL/TLS, etc., mais cela sera pour plus tard.

Absence d'UI. Cela peut être un inconvénient majeur pour l'utilisateur final, mais pour l'administrateur système, un utilitaire en console est plutôt plus important qu'une application complète. Créer un utilitaire en console était prévu, mais je ne suis pas sûr s'il est nécessaire.

Quel est le résultat ?

Un petit et simple serveur Web pour le provisioning de plusieurs modèles de téléphones avec une API de gestion.

Encore une fois, comment cela devrait-il fonctionner ?

1. Nous installons Sonata.
2. Nous formons un fichier de configuration JSON et le publions dans Sonata.
3. Nous obtenons ensuite de Sonata un lien pour le provisioning.
4. Nous indiquons ensuite ce lien dans le téléphone.
5. L'appareil tire la configuration.

Dans l'exploitation ultérieure, seulement deux étapes :

1. Nous formons un fichier de configuration JSON et le publions dans Sonata.
2. L'appareil tire la configuration.

Quels téléphones sont provisionnés ?

Les vendeurs Grandstream, Fanvil, Yealink. Les configurations au sein du vendeur sont plus ou moins identiques, mais peuvent différer selon le firmware — des tests supplémentaires peuvent être nécessaires.

Quelles règles peuvent être définies ?

Par heure. Vous pouvez indiquer l'heure jusqu'à laquelle la configuration sera disponible.
Par adresse MAC. Lors de la fourniture de la configuration par un lien personnel, l'adresse MAC de l'appareil sera également vérifiée.
Par IP. Par l'adresse IP d'où la demande a été faite.

Comment interagir avec Sonata ?

Via l'API, en effectuant des requêtes HTTP. L'API sera accessible dans votre installation. Comme l'API prend en charge la spécification Swagger, vous pouvez l'utiliser un utilitaire en ligne pour tester les requêtes à l'API.

D'accord, super. C'est vraiment cool, comment l'essayer ?

Il est plus facile de déployer une image Docker basée sur le référentiel sonata-sample. Le référentiel contient des instructions d'installation.

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

Si vous avez de l'expérience en JavaScript, vous comprendrez rapidement comment tout cela fonctionne.

Y aura-t-il un développement de Sonata ?

Partiellement, j'ai atteint mes objectifs. Le développement futur dépend de mes tâches liées à l'automatisation de la configuration des téléphones. Il y a encore la possibilité d'élargir les configurations pour régler les boutons des téléphones, d'ajouter des adresses de provisionnement, peut-être d'autres choses, écrivez dans les commentaires.

Résumé et remerciements

Je serais heureux d'avoir des propositions / objections / commentaires constructifs et des questions, car il se peut que j'aie mal expliqué quelque chose.

Je tiens également à remercier tous les collègues qui ont aidé, conseillé, testé, fourni / donné des téléphones pour les tests. Réellement, de nombreuses personnes, avec qui j'ai interagi au travail, sont impliquées dans le projet à divers niveaux, sur AsterConfà travers des discussions dans des chats et des e-mails. Merci pour les idées et les réflexions.

Source : habr.com