Remplacer l'URL d'action et l'URI dans les téléphones SIP ou gérer via des sockets Web?

Téléphones SIP. Ordinateurs avec un combiné. En théorie, beaucoup peut être fait avec eux, mais ils ne sont utilisés que pour les appels :-)

Récemment il y a eu une conférence sur AsterKonf et il a parlé de vendeurs de leur téléphone, n'allouera pas un, tout bon, quelque part mieux, quelque part moins cher, essentiellement d'effectuer la même chose.

Certains fournisseurs améliorent la qualité sonore, quelqu'un attache une tablette avec un Android, quelqu'un essaie d'ajouter une sorte d'application. Et tout cela pour que nous installions ces téléphones sur les ordinateurs de bureau.

Et peut-être que les téléphones sont de bons candidats pour le rôle de la télécommande dans le monde de l'IoT: j'ai cliqué sur le bouton et j'ai obtenu le résultat. Et, à mon humble avis, il n'y a pas assez de moyen simple de connecter des téléphones à votre «Manager». Dans le cadre de cet article, je veux montrer à quoi cela pourrait ressembler dans un diagramme et une démonstration vidéo.

Et vous partagez dans les commentaires, s'il vous plaît, que peut-être quelque chose de similaire a déjà été mis en œuvre quelque part ou complétez vos suggestions et réflexions.

Les téléphones ont une URL d'action et des URI d'action.

L'URL d'action nous permet d'envoyer différents événements à n'importe quelle URL. Dans l'url, nous pouvons spécifier des variables prédéfinies qui seront remplies de données réelles lors d'un appel.

Ainsi, par exemple, le réglage de mon téléphone ressemble.



Concepteur d'URL d'action en ligne pour Yealink

L'URI d'action nous permet de recevoir des commandes sur l'adresse IP du téléphone, et le téléphone peut passer des appels, répondre aux appels sur commande, ajouter du volume, redémarrer, etc. dans la vidéo ci-dessous, vous pouvez voir comment tout cela se produit. Nous devons indiquer l'adresse d'où proviendront les équipes.



Tout est configurable, quel est le problème, mon frère?

Ce sont des interfaces assez fonctionnelles, mais ... elles sont assez difficiles à intégrer. C'est-à-dire nous devons prendre 100 500 actions pour le faire fonctionner. Ou remplissez 100 champs dans les paramètres de l'appareil (vous voyez vous-même à l'écran), ou confondez-vous avec les dispositions et prescrivez quelques modèles de configuration.

En conséquence, il existe de nombreuses actions dans lesquelles il est facile de faire une erreur et de ne pas obtenir ce que vous voulez, puis de passer beaucoup de temps à comprendre les raisons du comportement inapproprié de l'appareil. Et bien, si vous en faites face à un, et que vous avez cinq à dix, cent et quelques vendeurs et même des modèles de générations différentes. Puff puff puff ...

Est-ce un problème? Quelqu'un doit-il gérer le téléphone d'un abonné? À l'abonné? Depuis votre bureau, ordinateur portable ou smartphone? Support technique? À la fois interne et externe, par exemple, un fournisseur de central téléphonique virtuel? Dois-je avoir accès au téléphone différemment du simple SIP? Intégrer le téléphone avec des applications, en contournant l'IP-PBX?

Je ne peux pas répondre sans équivoque, il y a des inconvénients et des avantages. Et pour réaliser les avantages, j'aimerais pouvoir connecter rapidement l'URL et l'URI de l'action à mon "Manager". J'appelle un gestionnaire un serveur à partir duquel je peux voir de manière centralisée une liste de téléphones, leur état et à partir de n'importe lequel d'entre eux effectuer une action disponible.

Voyons le diagramme.



Imaginez que nous avons un client Websockets dans notre téléphone.

Ensuite, nous devons spécifier dans le téléphone uniquement l'adresse réseau du «Manager» et notre téléphone s'y connectera. Une fois connecté, le téléphone enverra son identifiant, son nom, son mac. Cela nous permettra par exemple de le comparer avec notre liste d'abonnés PBX.

Ensuite, nous nous abonnons aux événements qui se produisent sur le téléphone. Il y en a beaucoup, ce sont des réinscriptions, des réponses aux appels, des pressions de boutons, etc. Ensuite, nous pouvons composer le numéro de notre gestionnaire en envoyant une commande. Définissez le NPD ou supprimez le NPD. Ensuite, j'envoie une notification ou un rappel au téléphone, je crée un nouveau logo.

Et la sécurité? En général, les téléphones SIP peuvent fonctionner pour NAT, ils n'ont pas besoin d'une adresse externe. Mais si vous définissez le port du serveur Web du téléphone sur le réseau URI d'action (où la zone d'administration, en passant, fonctionne) - attendez-vous à de mauvaises surprises.

Mais si le téléphone se connecte au "Manager" via des websockets, alors c'est son initiative et son droit, il peut se déconnecter, et si vous vous connectez au serveur distant en raison de NAT, cela ressemblera à une connexion par navigateur.

Assez de mots, plus près du point. J'ai écrit un petit client de téléphone (qui à mon avis devrait être dans le téléphone), qui se connecte au serveur via la prise Web. De plus, un navigateur est connecté à ce serveur, qui peut recevoir des messages du téléphone et y envoyer des commandes.

Le client est juste un wrapper pour l'URL d'action et l'URI d'action, qui fonctionne avec le téléphone via ses interfaces familières et encapsule toutes les données dans une socket Web. Dans les sockets Web, nous avons des messages JSON réguliers avec lesquels tout développeur Web peut travailler.

Regardez la vidéo, tout est assez simple. Tout le code est suffisamment minimal pour montrer le concept.


Que se passe-t-il dans la vidéo?

1. nous démarrons le serveur qui accepte les connexions sur les websockets,
2. nous démarrons le client (qui fonctionne par Action URL & URI avec le téléphone)
3. le client se connecte au serveur
4. nous démarrons le serveur web (avec la page où le code de connexion depuis le navigateur via les websockets)
5. ouvrir la page dans le navigateur, la page se connecte au serveur
6. nous envoyons une demande d'informations depuis la page
7. la demande va jusqu'au téléphone et renvoie des informations sur les lignes téléphoniques
8. nous pouvons aussi envoyer différentes équipes
9. y compris la commande pour effectuer un appel
10. puis la commande raccrocher
11. toutes les données sont visibles dans le journal de la page, ainsi que dans la console du serveur de travail et du téléphone client
12. alors vous pouvez voir comment il réagit aux commandes de la page du téléphone

Ainsi, la connexion du téléphone au Manager n'est qu'une adresse. Et les messages des sockets Web vers une présentation différente et vice versa peuvent être n'importe quel développeur. Dans mon cas, une page est connectée au Manager. En général, il peut s'agir d'un système plus complexe qui traitera les commandes et enverra des messages au téléphone.

Avoir une méthode de connexion simple peut être pratique et donc plus facile à apprendre. Grâce à cette interface, en théorie, il est possible d'envoyer à la fois de nouvelles configurations et des messages supplémentaires, ce qui rend le téléphone facile à intégrer dans n'importe quelle infrastructure.

En général, ce ne sont que mes réflexions sur les résultats de la visualisation de nouveaux produits sur Asterkonf. Je serai heureux de voir dans les commentaires les avantages et les inconvénients. Et peut-être que l'un des fabricants verra le rationnel dans ce domaine et présentera la puce :-)

Projet Github