C’est parti pour un nouveau tuto, en plusieurs parties. L’idée est de commencer par l’installation d’un SIP Server tout simple, et de le tester. Ensuite nous en installerons un second afin d’activer la haute disponibilité pour ce composant et enfin nous l’interfacerons avec Media Control Platform (MCP pour les intimes) afin de lui faire jouer quelques guides audio.
Mais commençons par le commencement, une installation de SIP Server dans le plus simple appareil…
Les bases, encore les bases, toujours les bases,…
Bon, nous commençons par les prérequis classiques sur ce blog : 1 serveur Linux CentOS7 d’aplomb, un framework fonctionnel, des sources téléchargées, du courage et… une licence avec des places SIP activées. Et oui, si l’on s’est amusé à installer un FlexLM précédemment, c’est pas pour rien.
Une fois les sources décompactées, on va de manière classique utiliser les fichiers templates proposés pour créer un nouveau modèle d’application. Je vous recommande chaudement d’importer également les métadonnées XML car les options de SIP Server sont nombreuses et pas forcément explicites…
Une fois le template créé, on crée immédiatement l’application liée pour notre premier SIP Server, ici nommée SIP_Server_1. Le 1 est bien sûr là car nous créerons ultérieurement le 2…
Je vous conseille de modifier de suite les options liées au log car vous risquez de passer quelques heures/jours à les lire. Chacun ses préférences mais personnellement c’est :
- ‘verbose’ à ‘all’ quand le volume vous le permet. Toujours plus pratique quand vous devez investiguer sur un souci qui se présente de manière aléatoire
- ‘keep-startup-files’ à ‘true’, pratique pour avoir rapidement les options de configuration de l’application en début de chaque fichier de log, et pas uniquement dans un seul dont vous aurez perdu la trace…
- ‘segment’ à ’10 MB’ pour ne pas surcharger votre éditeur de texte préféré et sa coloration syntaxique
- ‘expire’ à ’10/50/100′, bref à un chiffre et pas une durée. Alors certes, il est compliqué de se représenter la durée que vont couvrir vos logs. Mais au moins vous savez que votre application occupera avec ses logs au maximum ‘expire * segment’ Mo, et pas une tétrachiée d’octets qui rempliront votre disque et ramasseront votre installation. J’ai déjà vu un confserv mécontent des données que lui envoyait l’Interaction Server, et qui produisait un fichier de 10 Mo toutes les 3 secondes…
Pour les options autres que celles liées aux logs, je vais me concentrer sur la partie TServer. Je ne vais que les effleurer mais voici quelques unes qui me sont souvent utiles, ou m’ont déjà sorties du pétrin :
- le tryptique agent-no-answer-timeout/agent-no-answer-overflow/agent-no-answer-action : avec celles-ci, vous décrivez dans l’ordre :
- au bout de combien de temps on considère une absence de réaction d’un agent à un appel qui lui est présenté comme étant anormale
- quelle action prendre pour l’appel (‘recall’ par exemple va le renvoyer au dernier objet de distribution, vous pouvez aussi spécifier un DN spécial « routage par défaut »)
- enfin, que faire pour le statut de l’agent, et par exemple le mettre ‘notready’ ou le déconnecter avec ‘logout’. Ainsi il ne recevra plus d’appel si celui-ci s’est absenté…
- wrap-up-time : le temps laissé à l’agent entre la conclusion d’un appel et la présentation du prochain
- sip-port : par défaut à 5060, le port par lequel la signalisation SIP s’effectuera
- sip-address : par défaut à vide, il faudra la remplir si vous avez plusieurs cartes réseaux sur votre serveur, afin de vous assurer que les communications SIP partent bien sur la bonne patte
- dial-plan : pour spécifier l’objet à utiliser qui définira vos règles de numérotation vers l’extérieur ou même en interne
Une fois tout ceci paramétré, il ne vous reste plus qu’à installer le SIP Server avec le classique ‘./install.sh’ et répondre aux questions en ligne de commande.
Une fois l’installation terminée, votre application SIP_Server_1 aura dû être mise à jour et ressembler à ceci :
Vous noterez que j’ai mis à jour la valeur de l’option après ‘l’ afin que le SIP Server puisse vérifier sa licence auprès des 2 FlexLM installé, au cas où l’un d’entre eux aurait flanché…
C’est bientôt fini ?
Oui. Et non…
On va dire que la partie complexe est presque derrière nous, même si dans les faits, on peut passer des heures et des jours à parfaire les options du SIP Server.
Ils nous restent quelques étapes à faire, même si rien de très exceptionnel…
Tout d’abord, ouvrir le port SIP (le 5060 normalement). Cela se fera en 2 lignes de commandes :
sudo firewall-cmd --permanent --add-port=5060/udp
sudo firewall-cmd --reload(Pour ceux qui voudraient de plus amples informations sur firewall-cmd, vous pouvez vous reporter à mon article « Trucs & astuces Linux eudbase – Partie 1 / …« )
Là vous serez tenté de démarrer votre SIP Server flambant neuf. Allez-y , je vous attends…
Alors, démarrage puis extinction ? Et oui, car SIP Server est « un peu » exigeant et ne voudra pas démarrer sans Switch associé. Et pour déclarer un switch, il faut d’abord un switching office
Comme vous pouvez le voir, rien de très original (ne vous focalisez pas sur le nom du T-Server différent, j’ai dû utiliser une autre VM pour ma capture…)
A ce moment là, votre SIP Server devrait démarrer. Mais tant que nous y sommes, autant créer le nécessaire pour le tester !
Nous allons donc créer 2 extensions sur le SIP Server qui serviront ensuite à enregistrer 2 SIP Phones.
Ces deux extensions seront 00001 et 00002. La configuration sera ultra-basique. Ici un exemple avec 00001 :
Rien de spécial à voir sur l’onglet général. Un peu plus intéressant est l’onglet « Options » :
L’option « contact » permet de spécifier l’adresse de contact de cette extension… ou alors en la laissant à *, celle-ci sera remplacée dynamiquement quand le softphone s’enregistera. Elle prendra alors pour valeur : sip:NUMERO_EXTENSION@NOM_MACHINE_CLIENTE:PORT_SIP_CLIENT
Cela permettra ainsi au SIP Server de savoir où adresser les appels qu’il recevra.
L’option « sip-cti-control » définira quant à elle les actions que le SIP Phone aura le droit d’effectuer. Dans cet exemple du « talk,hold,dtmf », cela signifie que le téléphone vous permettra de passe un appel ^^, de mettre l’appel en attente et enfin d’envoyer des fréquences vocales.
Maintenant que les extensions sont définies, il ne nous reste plus qu’à démarrer le SIP Server et à le tester grâce à 2 SIP Phones. Dans l’exemple ci-dessous, j’utiliserai X-Lite de CounterPath.
Une fois celui-ci installé sur deux machines différentes ayant accès au serveur où vous avez installé SIP Server, il vous restera à créer un compte sur chaque X-Lite, un pour chaque extension.
Comme vous pouvez le constater, seules 2 options seront importantes :
– User ID qui sera en fait votre extension
et
– Domain qui sera l’adresse IP de votre SIP Server
Et là, sous vos yeux zébahis :
Et pour valider cela, passons un appel :
Nous voilà donc avec un SIP Server certes basique, mais fonctionnel.
Dans la prochaine partie de ce tuto, nous attaquerons un point plus « fun », en tout cas plus complexe : la mise en place de la HA pour le SIP Server.