Il était auparavant possible de positionner un maximum de paramètres dans la section générale du fichier sip.conf, mais la gestion des exceptions n’était pas simple et imposait une rigueur importante.

L’utilisation des modèles SIP s’effectue en deux temps : définition puis utilisation.

Définition des modèles

Le principe est simple, on définit un contexte suivi par une inclusion optionnelle d’autres modèles :

[internal-codec](!)
        disallow=all
        allow=alaw

[internal-sip](!)
        type=friend
        host=dynamic
        qualify=150
        context=internal

Là j’ai défini une section avec les codecs qui seront utilisés sur les postes internes internal-codec et un modèle pour les postes de mon réseau internal-sip. La syntaxe (!) permet de spécifier que ce contexte est un modèle et éventuellement les inclusions d’autres modèles séparés par une ,.

Utilisation des modèles pour les extensions

Au niveau de la définition des extensions, on ajoute (modèles) derrière le nom du contexte pour appliquer le ou les modèles spécifiés et séparés par des ,.

[100](internal-sip,internal-codec)
callerid=Lab 1 <100>

[101](internal-sip)
callerid=Lab 2 <101>

[102](internal-sip)
callerid=Lab 3 <102>

Simple, rapide et vraiment pratique. Voilà un argument intéressant en faveur de la 1.6, même si cela peut sembler un détail, mais lorsque l’on écrit les configurations à la main pour plus de précision c’est important en terme d’efficacité et de lisibilité.

Certes on peut transporter de la voix sur IP et depuis bien longtemps d’ailleurs, la numérisation des réseaux de téléphonie à débuté dans les années 60 et utiliser des réseaux de paquet ne complexifie pas énormément le processus. Un peu de gestion de gigue et de réordonnancement des trames et le tour est joué. Avant les années 2000 des produits étaient en production chez les opérarteurs data pour transporter de la voix, souvent sur FrameRelay à l’époque mais le principe est exactement le même.

Mais de là à transporter de la voix dans un réseau IP qui lui même est transporté sur un réseau de mobile est loin d’être une solution technique élégante. En particulier on mettra en lumière les problèmes de bande passante sur la voix montante et de délai. Pour la bande passante on utilise en général 80Kbps pour transporter un appel en G.711, skype utilise un codec large bande pour donner plus de qualité et on peut descendre la consommation en utilisant des codecs plus agressifs mais nécessitant plus de CPU (G729 par exemple) ou tout simplement le codec GSM (le comble du paradoxe non ?). La bande passante peut varier en fonction de l’usage sur la partie données, donc dans une zone de population dense, il sera préférable de passer par le réseau voix traditionnel.
Pour ce qui est du délai, en fonction du niveau de signal on peut avoir des délais de transit autour de 200ms alors que l’on considère un appel de bonne qualité en dessous de 150ms et la plupart des utilisateurs commencent à ressentir le délai à partir de 90ms.

Tout ceci va s’améliorer avec les nouvelles technologies de transmission notamment le HSDPA (High Speed Downlink Packet Access), mais ce n’est pas pour tout de suite sur l’ensemble du réseau.

Nous avons été habitués avec la téléphonie à un niveau de qualité assez élevé et nous devrions tenter d’avoir encore mieux plutôt que de niveler par le bas. Dans la téléphonie sur IP nous avons beaucoup de travail pour éduquer nos clients sur le fait que la qualité peut être bien meilleure que dans la téléphonie traditionnelle, si on s’en donne la peine. Dommage que des services comme ceux-là sortent trop tôt par rapport à la capacité des réseaux des opérateurs à l’absorber, la qualité va être faible et on va assimiler VoIP avec mauvaise qualité.

Messieurs les opérateurs, la balle est désormais dans votre camp pour migrer rapidement vos réseaux en IP, augmenter la bande passante et nous offrir des solutions SIP homogènes et ouvertes.

« Pour beaucoup de clients, la qualité audio n’est pas encore satisfaisante », explique Pascal Richard, directeur technique chez Resophone.

Quel est le rapport entre le trunk SIP et la qualité audio ressentie par les utilisateurs ? S’il on fait bien les choses, ce que je me tue à dire lors des cours que je donne, on peut avoir une qualité au moins aussi bonne, voir meilleure avec l’utilisation de codec à large bande. SIP est un protocole de signalisation pas de gestion de la qualité de service. Dès lors que l’on utilise un réseau asynchrone pour transporter des données temps réel, il est important de mettre en place des méthodes et outils pour atteindre le niveau de qualité demandé par les utilisateurs. On ne met pas en place un code G.729 pour le plaisir, mais bien comme un compromis entre qualité d’écoute plus faible et consommation de bande passante réduite.

Le passage en SIP nécessite principalement des équipements dans les entreprises et c’est ici à mon avis que cela coince aujourd’hui. Les installateurs préfèrent pousser pour un passage sur du T0/T2 qui est simple, fonctionnel et efficace. L’opérateur historique ne va pas dire le contraire puisque tirant des revenus important de cette activité déjà largement amortie. D’ailleurs il suffit de questionner un chargé d’affaire de la marque pour avoir des informations sur leur interconnexion Trunk SIP pour s’en convaincre.
D’autre part, les constructeurs ayant un retard fou sur la mise en place de pile SIP dans leurs machines historiquement H.323, n’y vont que petit à petit. Autant la connexion des postes utilisateurs en IP propriétaire est facile à vendre, autant il est difficile de faire pression pour l’utilisation d’un protocole maison dès lors que l’on se connecte à l’extérieur avec des opérateurs multiples.

SIP ne sera par tiré par les utilisateurs d’Asterisk ou de FreePBX, j’en doute fort, ni par les petits opérateurs allant chercher principalement de la TPE et du particulier en SIP. Tant que les opérateurs de premier ordre ne pousseront pas les clients vers les nouveaux réseaux IP en présentant la valeur ajoutée plutôt que la réduction de coût (erreur stratégique à mon sens), les choses n’avanceront que lentement.

Le trunk SIP c’est l’avenir, aucun doute là dessus à cette heure. Il ne reste plus qu’à y aller en faisant attention à l’installation afin que les clients ne soient pas déçus : gestion de priorité IP, redondance si besoin, intégration des flux de données et hybrides (fax par exemple), utilisation des téléphones SIP et des bornes DECT/SIP en provenance des constructeurs compétents, sécurité bien sûr…

On trouve donc du PlcmSpIp dans les tentatives d’accès SSH, étonnant non ? Cela signifie qu’il y a une probabilité non nulle que des téléphones IP soient directement connectés à l’Internet, ce qui n’est pas bien prudent vous en conviendrez.

Au minimum, on met en place un filtrage, idéalement un VPN, mais encore mieux un Asterisk, un SER ou équivalent en guise de SBC.

Enfin, moi ce que j’en dis…

Il est clair que la migration sur IP de la voix est importante aujourd’hui et inéluctable. Bien ou pas ce n’est pas le débat ici. Tant que l’on mettra IP en avant, des solutions ouvertes feront leur apparition et l’interopérabilité deviendra la maître mot, permettant aux clients de faire leur marché sans rester attaché à un constructeur ou une solution propriétaire.

Dès qu’il est question de mobilité et donc principalement en entreprise où les distances à couvrir sont plus importantes que chez les particuliers, on quitte un monde qui était dominé par le DECT pour un nouveau monde. Longtemps, l’offre IP des constructeurs historiques de téléphonie avait délaissé la partie mobile pour reprendre simplement la partie DECT numérique existante au catalogue. On a donc vu apparaître des solutions chez les pro-IP qui, ne pouvant pas être basées sur DECT, se sont rabattues sur un moyen de transport existant et peu coûteux : Wi-Fi (IEEE 802.11 pour être exact).

On l’a déjà dit ici Wi-Fi n’est pas fait pour transporter un flux temps réel et la voix en est un. L’acquittement positif de toutes les trames de données, les délais d’attentes pour la prise de parole, la nature half-duplex du média radio utilisé avec la méthode d’accès CSMA/CA font de ce protocole un excellent moyen économique de pousser des trames IP, mais sans aucun contrôle sur le délai un très mauvais candidat pour la téléphonie. Pour connecter mon micro c’est parfait, fabriquer un hot-spot c’est idéal, jouer à Mario Kart sur la Wii c’est super, mais pour le transport de la voix dans un environnement professionnel c’est plus discutable.

Afin de s’en sortir, il y a eu longtemps l’approche quantitative : la bande passante disponible sur un point d’accès Wi-Fi peut aller jusqu’à 25Mbps environ en 802.11g, donc pour faire passer une communication téléphonique à 80Kbps environ c’est très largement suffisant. On peut même se permettre de mettre plusieurs communications simultanées et de la donnée en plus. Le soucis vient un peu plus tard, lorsque la partie données du réseau commence à être utilisée plus largement, alors le réseau ne tient plus face à des besoins de temps réel, une fois de plus il n’a pas été conçu pour cela. Il faudra donc multiplier les points d’accès pour espérer répartir les terminaux associés à chacun.

Autre soucis du Wi-Fi, la mobilité et non l’itinérance comme sa conception le suppose. Bien souvent, les terminaux Wi-Fi ne cherchent une nouvelle source de réseau (un point d’accès) que lorsque celle sur laquelle ils sont associés propose un niveau de signal faible (SNR). Alors débute une traque qui consiste à analyser chaque canal radio (nous en disposons de 14 en France) à l’écoute d’une trame de balise qui est émise par défaut toutes les 100ms. Le temps de recalibrer une radio sur un terminal à faible coût prend tout simplement du temps. Donc on arrive à un délai de passage d’un point d’accès à un autre qui peut facilement atteindre la seconde, soit 20 fois plus long que ce qui est communément admis dans l’industrie de la voix. Ce délai pourrait largement être réduit mais avec des coûts d’électronique plus importants. Une nouvelle norme fait donc son apparition, mais à partir de quand sera-t-elle disponible dans les équipements utilisés en entreprise et notamment en PME ?

L’autre approche consiste donc à faire du qualitatif : on met en place de nouvelles normes faisant évoluer le Wi-Fi dans une optique de qualité de service. L’approche bande passante que l’on a pu voir dans 802.11n ne s’applique pas aux entreprises pour des raisons évidentes de radio, nous laisserons donc cela pour les particuliers et leur TV HD. Dans le qualitatif on nous promet donc une capacité de roaming et un traitement de la QoS avec le respect de classes de service. Cette approche est excellente, mais va à l’encontre des économies annoncées pour un passage en ToIP puisque celui-ci s’appuie sur une infrastructure IP existante. Or pour faire de la mobilité en ToIP sur du Wi-Fi il sera nécessaire de mettre en place une infrastructure lourde Wi-Fi qui sera probablement mono constructeur (point d’accès et téléphone) dans un premier temps.

Alors, quitte à mettre en place une infrastructure spécifique, pourquoi ne pas aller vers du DECT. Ce protocole existe et a fait ses preuves. La couverture radio est plus simple à définir en raison de la bande de fréquence utilisée et de la portée des communications. Les bornes DECT aujourd’hui parlent en SIP avec l’infrastructure de téléphonie. Mais surtout le confort d’écoute est de très haute qualité puisque le réseau est dédié à cet usage d’une part et que la QoS est gérée de façon intrinsèque. Enfin, la densité est plus importante au regard de la bande passante utilisée.

Aujourd’hui que le marché est mature en terme d’offre DECT sur SIP et en attendant plus de maturité au niveau du Wi-Fi adapté à la voix, je continuerai donc à proposer à mes clients, ayant des besoins importants de mobilité en voix, de regarder sérieusement les solutions DECT. Bien sûr à contrario, lorsque l’infrastructure Wi-Fi existe dans l’entreprise et que l’on ne souhaite pas avoir un usage industriel de la partie téléphonie mobile, quelques terminaux Wi-Fi SIP et le tour est joué.

Et vous, Wi-Fi ou DECT sur votre Asterisk ?

• if_inbound: permet de définir la carte réseau de votre réseau interne, Là où le téléphone se trouve (eth0 par exemple)
• if_outbound: permet de définir la carte réseau externe. Dans mon cas, il s’agit de l’interface virtuelle montée par mon VPN (tap0 par exemple)
• hosts_allow_reg: la liste des machines/réseaux qui auront le droit d’utiliser le proxy pour s’enregistrer sur un serveur SIP.

Vous avez à présent un proxy sip fonctionnel. L’ajout de log de debug (paramètre silence_log) peut être utilisé pour diagnostiquer les éventuels problèmes.

Finalement il manque juste à cet outils un portage sous Windows…

La page du projet est ici: siproxd

Ainsi, l’objectif d’Astitray est le suivant:

• Une application simple
• Intégrée au poste de travail
• Permettant de générer des appels sur son téléphone
• Avec un annuaire central

Bien évidement, il est impensable d’ouvrir un accès manager pour chaque poste de travail. De même partager un accès commun amène inévitablement à des « débordements » (déclenchement d’un appel chez son voisin principalement…).

Aussi astitray est livré avec un serveur XMLRPC écrit en PHP. Celui-ci gère le contrôle d’accès et permet l’appel aux différents services. L’autre objectif de ce serveur est aussi de réaliser un couche d’abstraction pour la communication avec le PBX. Ainsi il est possible, via l’écriture d’un « driver », de réaliser les mêmes opérations sur un autre PBX qu’Asterisk.

Néanmoins, suivant le nombre de poste de travail, le serveur XMLRPC ne peut être utilisé en direct sur le manager d’Asterisk et l’emploi d’un proxy est indispensable. Astitray utilise Ajam pour communiquer avec Asterisk. Pour le moment aucun Proxy de manager Asterisk ne supporte ce nouveau protocole. Aussi l’écriture d’un driver supportant le protocole natif d’Asterisk est donc une prochaine étape pour le projet !

La page du projet est : Astitray.

Plus d’information ici.

Il est assez fréquent en ce moment de voir des systèmes de gestion des appels ou ACD fonctionner assez mal lorsqu’il est question de passer l’appel sur un agent. Ces derniers jours, j’ai eu l’occasion de contacter mon FAI préféré pour des soucis de qualité et de mise à disposition de ligne DSL, mais également ce matin ma caisse de sécurité sociale, avec des attentes interminables mais surtout avec des lignes qui sont raccrochées lorsque l’agent semble prendre l’appel. Je doute que ce soit les agents qui raccrochent l’appel de façon volontaire, même si dans certains cas la manipulation des postes téléphonique n’est pas ergonomique et peut entraîner ce genre de désagrément. Je pense plutôt qu’il s’agit de réel problème de tenu à la charge des ACD et d’une mauvaise ingénierie.

Les systèmes de téléphonies étant de plus en plus complexes et l’attente des utilisateurs de plus en plus grande il est urgent que les gestionnaires de système de téléphonie s’occupent sérieusement de ce problème de qualité. Un bon suivi des causes d’arrêt des appels doit permettre d’améliorer les fonctionnements internes de l’ACD et ainsi la qualité des services client, car finalement avoir un appel en attente dans une file si celui-ci n’aboutit pas sur un agent qui va résoudre le problème ou donner la bonne information coûte très cher, en image mais également d’un point de vue de l’infrastructure.

Et vous, que faites vous sur votre système pour vous collecter les informations de qualité ?

Le matériel

Le téléphone Aastra 312 respire le solide, il est sensiblement plus gros que l’ensemble des téléphones Wi-Fi que nous avons pu testé et ressemble plus à une téléphone DECT d’entreprise qu’à un GSM, ce qui semble une approche cohérente par rapport au marché des entreprises.

140 grammes sur notre balance avec sa batterie, il est livré avec un petit socle permettant de le recharger tout en le gardant sous le yeux sur le bureau. Petit plus, on peut configurer le 312 de façon spécifique lorsqu’il est sur son socle, par exemple en désactivant la sonnerie ou en forçant l’écran à rester allumé.

En terme d’autonomie, les tests que nous avons effectués indiquent une capacité à tenir environ 2h30 en communication, ce qui est largement suffisant pour la plupart des usages mobiles qui visent plus le fait d’être joignable que de tenir une longue conversation. Un indicateur sonore de fin d’autonomie peut être mis en service si besoin.

Le logiciel

D’une prise en main assez simple, le téléphone dispose d’une interface dépouillée sur un écran couleur LCD assez grand (trop pour les informations à afficher). Une liste d’icône sur la partie supérieure de l’écran présente le statut du réseau et la qualité de la liaison Wi-Fi, ainsi que des informations sur la configuration (renvoi, message vocal, verrouillage du clavier, réveil, …).

La configuration s’effectue via un menu d’accès aisé, mais il est nécessaire de faire référence à la documentation avant de se lancer dans celle-ci. Pour la partie Wi-Fi on retrouve ce qui est indispensable aujourd’hui à savoir une recherche des SSID proposés sur la zone avec leur niveau de qualité de signal respectif, une configuration de la sécurité proposant WPA en mode clé partagé (pas de mode entreprise, ce qui pourrait être demandé par certaines entreprises).

La configuration réseau intègre aussi bien l’adressage que la partie SIP. Ce choix est original est assez perturbant, en effet, s’il on choisi DHCP, il faut alors que le serveur DHCP fournisse les informations relatives à la partie SIP. Dans l’absolu cette solution est excellente pour les entreprises de taille moyenne (ou grosse) disposant d’une solution de fourniture d’adresse évoluée et notamment qui va permettre de configurer des extensions (vendor class), en revanche si vous souhaitez connecter votre téléphone sur un point d’accès routeur grand public, vous devrez passer en adressage fixe, dommage.

Notre premier essai en adressage IP fixe a été concluant, aussi bien la partie Wi-Fi que l’enregistrement sur notre Asterisk a fonctionné du premier coup et sans soucis particulier. On retrouve alors un poste SIP traditionnel du point de vue de la configuration, notamment du côté de l’IPBX. On pourrait regretter que la pile SIP soit différente (extérieurement au moins) des modèles filaires de la gamme, mais ce n’est pas spécialement bloquant, surtout lorsque l’on passe en configuration via DHCP.

Pour la partie configuration par DHCP il nous a fallu chercher un peu, notamment pour configurer notre serveur DHCP afin qu’il fournisse les options spécifiques au téléphone. Une fois maîtrisée, cette partie permet d’automatiser la configuration de l’ensemble des postes IP mobiles, sur la base de leur adresse MAC, ce qui est souvent le cas dans la téléphonie sur IP.

Il ne reste, en terme de configuration, que la partie Wi-Fi à effectuer sur chaque téléphone de façon manuelle. Cette partie est assez rapide mais à répéter sur tous les téléphones du parc. On veillera donc à spécifier des paramètres réseaux corrects, dans notre cas du WPA avec une clé partagée assez longue. Ceci va dans le sens de dédier un réseau Wi-Fi (SSID) à l’usage de la téléphonie si le parc est de taille importante, sinon, à chaque changement de paramètre il sera nécessaire de repasser sur l’ensemble des téléphones, ce qui sera fastidieux et consommateur de temps.

Usage

A l’usage, le téléphone Aastra 312 est simple et efficace. On retrouve des fonctionnements très classiques d’un téléphone DECT d’entreprise avec quelques fonctions spécifiques à la partie Wi-Fi, notamment une indication sonore en cas de signal faible.

On remarque la richesse fonctionnelle sur les fonctions de téléphonie, par exemple, les renvois en cas d’occupation, systématique ou après un délai configurable. La partie écran, image de fond, réglage de l’intensité est simple et suffisante, ainsi que la partie sonneries.

Le répertoire est présent, mais pas (à priori) téléchargeable depuis un serveur d’entreprise. Chaque utilisateur devra donc gérer son répertoire, comme sur un téléphone GSM en sorte. Petit avantage proposé ici, le stockage du répertoire et des paramètres de l’utilisateur s’effectue sur une carte mémoire qui peut être déplacée dans un autre téléphone de même type. Ceci permettra alors d’en changer en cas de problème technique, c’est une solution intermédiaire, on aurait bien sûr préféré voir également un annuaire d’entreprise interrogé en LDAP par exemple et contenant l’ensemble des informations partageables entre les postes utilisateurs.

Ce qui est le plus frappant sur ce produit est la qualité d’écoute. Nous sommes, en effet, avec ce produit très proche d’un DECT classique, ce qui avec la contrainte d’utilisation du Wi-Fi est assez remarquable. La qualité de fabrication du combiné apporte également un plus à l’impression de confort aussi bien pour l’utilisateur du téléphone que son interlocuteur. D’un point de vue des codecs, la choix est très restreint, on restera si possible sur du G.711, il consomme un peu plus de bande passante, mais l’impact sur le Wi-Fi n’est pas plus important et surtout il offre une qualité élevée.

Nous avons également apprécié le fait de pouvoir supprimer la sonnerie lorsque le téléphone est sur son socle de chargement, donc à priori sur votre bureau. En effet, s’il on couple notre mobile à un téléphone de bureau SIP traditionnel, alors on pourra créer, par le plan d’appel du PABX IP, un scénario avec appel sur le mobile et débordement sur le fixe, ou un groupement faisant sonner les deux postes (fixe et mobile). Ainsi, le mobile pourra être utilisé lorsqu’il n’est pas sur la base et le poste fixe dans le cas contraire. C’est facile à mettre en place, pratique et très riche fonctionnellement.

Le dernier point à aborder est celui du déplacement sur un site de taille importante et donc disposant de plusieurs points d’accès Wi-Fi (ESSID dans la littérature Wi-Fi). La solution technique du Wi-Fi n’est pas optimale pour la mobilité, en effet, les échanges sont nombreux entre les clients et le point d’accès lors de l’association du mobile. Les essais que nous avons effectués dans le cas le pire, c’est à dire avec des points d’accès ne mettant pas en oeuvre des solutions simplifiant la mobilité des clients, ont montré que le temps de bascule est d’environ 300 à 500 ms. Si le téléphone n’est pas en utilisation, ce délai est sans impact, en revanche en communication vous remarquerez le changement de point d’accès par une coupure de la voix pendant ce délai. Ceci s’explique et n’est pas spécialement gênant si on prend comme référence la téléphonie mobile de type GSM, en revanche, le DECT sur ce point est bien meilleur car proposant une mobilité sans coupure.

Conclusion

En résumé, Aastra nous propose ici un bon produit, riche fonctionnellement et facilement intégrable à une plate-forme SIP. Nous en attendions un peu plus, mais nous sommes très exigeants en tant qu’utilisateur.

En revanche d’un point de vue technologique la solution est remarquable dans sa finition; on sait que le Wi-Fi n’est pas la plate-forme rêvée pour faire transiter de la voix, l’Aastra 312 s’en sort bien, si bien que l’on oublie qu’il utilise cette technologie¹. Il ne reste plus qu’à travailler un peu sur les aspects d’intégration avec le monde extérieur, notamment au niveau du répertoire pour avoir un produit parfait.

Donc si vous envisagez de mettre en place une extension sans fil à votre système de téléphonie SIP (qu’il soit à base d’Aastra ou d’une autre produit), n’hésitez pas. L’infrastructure réseau à mettre en place vous offrira de la mobilité pour un grand panel d’équipement et vous pourrez ainsi avoir quelques téléphones mobiles à un coût d’intégration moindre qu’avec du DECT/SIP.

Cet Aastra 312 est probablement l’un des meilleurs téléphones SIP Wi-Fi du marché, sans aucun doute. Il faudra suivre les évolutions techniques et commerciales pour le valider complètement et attendre les réponses des autres constructeurs.

Annexe: configuration du serveur DHCP

Si vous avez opté pour des postes Aastra 312, il vous faut mettre en place un serveur DHCP permettant d’automatiser la configuration de ceux-ci pour la partie SIP. Etant donné que nous y avons passé un peu de temps, voici la configuration à mettre en place sur un serveur de type ISC DHCPD sous Linux, si vous avec un Windows 2003 serveur, c’est plus simple…

Dans la configuration dhcpd.conf il faut tout d’abord créer une classe dédiée au modèle Aastra 312 et regroupant les définitions des paramètres spécifiques, on commence par la définition des options:

######################## AASTRA WI-FI PHONE 312
option space aastra312;
# Country
# 1 ALLEMAGNE, 2 GRANDE-BRETAGNE, 3 SUISSE, 4 ESPAGNE, 5 FRANCE, 6 ITALIE
# 7 RUSSIEi, 8 BELGIQUE, 9 PAYS-BAS, 10 TCHEQUIE, 14 FINLANDE
# 16 POLOGNE, 25 TAIWAN, 100 ETATS-UNIS, 102 CANADA
option aastra312.country      code 17 = unsigned integer 16;
# Nom du compte
option aastra312.name         code 20 = string;
# Adresse proxy SIP|nom[:port]
option aastra312.sipproxy     code 21 = string;
# Adresse registrar|nom[:port]
option aastra312.sipregistrar code 22 = string;
# Adresse proxy sortant[:port]
option aastra312.sipoutproxy  code 23 = string;
# ID de l utilisateur SIP & password
option aastra312.sipuser      code 24 = string;
option aastra312.sippwd       code 25 = string;

Puis on construit la classe, ici, tous les téléphones Aastra 312 qui vont demander une adresse au serveur DHCP vont présenter un label constructeur nommé “AastraPhone312”. On crée donc une classe qui va s’appliquer à cet ensemble, basé sur le discriminant du modèle:

class "Aastra 312" {
  match if option vendor-class-identifier = "AastraPhone312";
  vendor-option-space aastra312;
  option aastra312.country 5;
  option aastra312.sipproxy "192.168.16.40";
}

Ici, nous avons spécifié pour l’ensemble de nos téléphones Aastra 312 le fait que le pays était la France et que le serveur Proxy était à l’adresse 192.168.16.40. Nous aurions pu également spécifier un proxy de sortie et un registrar différent si besoin.

Il nous reste à configuré chaque téléphone de façon spécifique par rapport à ses attributs SIP. Dans la définition du sous-réseau, nous spécifions pour chaque téléphone une entrée basée sur son adresse MAC:

  host aastra312-45d0 {
       hardware ethernet 00:30:42:0d:45:d0;
       option aastra312.sipuser "12";
       option aastra312.name "Alex Chauvin";
  }

Ici, nous fournissons les informations spécifiques à l’identification au niveau SIP et au nom du téléphone qui sera affiché sur l’écran. Nous ajouterions le mot de passe SIP si l’authentification était demandée.

Un fois configuré sur la partie Wi-Fi et pour utiliser le DHCP, votre téléphone devra afficher le niveau du signal en haut à gauche de l’écran si tout va bien, sinon, il clignotera avec l’indicateur DHCP, signe qu’il y a un soucis. Attention, le débugage de cette partie n’est pas simple et a nécessité dans notre cas l’utilisation d’un analyseur de protocole afin de valider les échanges.

1. ce qui pour l’utilisateur ne doit pas apparaître d’ailleurs [↩]