• 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 [↩]

ENUM est un système d’annuaire, basé sur la structure du DNS, permettant d’associer à un numéro de téléphone traditionnel (format E.164) des informations relatives à l’Internet. On peut manipuler ainsi des adresses de courriel, des URL mais surtout et c’est ce qui nous intéresse ici des moyens d’être joint en téléphonie sur IP.

ENUM va donc autoriser une transition en douceur entre le monde de la téléphonie traditionnelle dans lequel nous manipulons des “numéros de téléphone” (au format E.164 donc) et le monde de la téléphonie sur IP dans lequel nous manipulons des URI (plutôt au format RFC822 comme les adresses de courriel).

Comment fonctionne ENUM

ENUM est basé sur le DNS, il s’agit donc de données, accessibles via ce protocole largement diffusé sur Internet et indexées par rapport à une entrée de type numéro de téléphone au format E.164. Il faut donc disposer d’un tel numéro afin d’avoir une entrée dans un annuaire ENUM, c’est l’idée de base.

Lorsqu’un PABX IP souhaite acheminer un appel vers un correspondant, il peut alors effectuer une requête de type DNS à un annuaire ENUM, afin de savoir si le numéro demandé n’est pas associé à un moyen de communication sur IP. Si un tel moyen existe, l’appel pourra alors être écoulé en IP (disons en utilisant SIP par exemple) et sur Internet (ou un réseau privé IP). Si en revanche aucun enregistrement n’est disponible dans l’ENUM, alors on utilisera un autre moyen d’acheminer l’appel, via son opérateur SIP ou en RTC.

S’inscrire

Avant de pouvoir recevoir des appels via ENUM, il est nécessaire de s’inscrire à un ou plusieurs annuaires. En effet, il existe plusieurs initiatives dans ce domaine qui n’est toujours pas organisé puisque un manque à gagner évident pour les opérateurs téléphoniques plane autour d’une généralisation d’un tel usage.

La façon la plus simple de démarrer est d’utiliser le service de e164.org. Après création d’un compte, vous pourrez alors effectuer deux types d’enregistrement:

• à partir d’un numéro de téléphone valide associé a un ou plusieurs moyen de communication ToIP,
• à partir d’un PABX IP connecté à Internet (en direct ou via un SBC¹ disposer de numéro virtuels disponibles à tout utilisateur de e164.org. Pour information, un préfixe de 10.000 SDA vous est attribué lors de l’inscription de votre serveur, c’est pas mal pour démarrer.

Attention: l’enregistrement d’une entrée ENUM chez e164.org nécessite la configuration préalable de votre système de téléphonie, en effet, afin d’éviter les abus, un appel est effectué et doit aboutir correctement sur votre enregistrement SIP.

Valider son inscription

Une fois inscrit, vos informations ENUM vont être propagées dans l’arborescence DNS et sont donc consultables à l’aide d’un client DNS. Je vous conseille d’installer dig s’il n’est pas déjà présent sur votre système.

La syntaxe de requête utilise le format de résolution inverse du DNS, on va donc devoir écrire son numéro de téléphone à l’envers (très bon pour les neurones). On cherche bien sûr une information spécifique, pas une adresse IP ou un nom de domaine, c’est pourquoi il faut spécifier dans la recherche le champ NAPTR. La syntaxe de recherche peut ressembler à :

dig 9.9.9.9.8.7.3.5.0.0.9.9.2.8.8.e164.org. NAPTR

Cette commande recherche le moyen de joindre ce numéro de téléphone, en l’occurrence et remis dans le bon sens il s’agit du : 88299 005378 9999. Ce numéro est extrait de ma plage de numéros privés, enregistrée chez e164.org et permettant d’accéder à une extension de test sur mon Asterisk en IAX. Le résultat de la requête contient l’information recherchée :

;; ANSWER SECTION:
9.9.9.9.8.7.3.5.0.0.9.9.2.8.8.e164.org. 600 IN NAPTR
   100 10 "u" "E2U+IAX2"
   "!^\+88299005378(.*)$!iax2:guest@cislyon.homeip.net/88299005378\1!" .

Il s’agit bien d’un enregistrement pour de l’IAX et vous avez le chemin permettant d’accéder à mon PABX via ce protocole et donc à utiliser dans votre commande Dial().

Une fois que vous voyez vos enregistrements avec dig, vous devez être joignable depuis tous les PABX connectés à Internet et effectuant des recherches dans ENUM.

Configuration d’Asterisk pour ENUM

Vous trouverez de la littérature sur Internet pour configurer votre Asterisk pour qu’il puisse faire de l’ENUM, mais voici une solution clé en main si vous souhaitez aller vite.

Pour recevoir des appels en IAX

IAX est le protocole propriétaire permettant de construire des faisceaux entre Asterisk sans contraintes de négociation des numéros de port relatifs au transport de la voix, en effet la signalisation et les communications sont transportées sur le même port UDP. Une fois que votre installation de sécurité a autorisé les appels entrants vers votre PABX, il reste à configurer celui-ci pour accepter les appels.

Dans iax.conf on ajoute une section qui est en phase avec l’enregistrement dans ENUM, par exemple, mon numéro 88299 005378 9999 est associé avec l’utilisateur guest derrière un serveur dont le nom est cislyon.homeip.net. La section est donc:

[guest]
type=user
context=fromiax

Elle est basique étant donné que les appels peuvent provenir de n’importe quel Asterisk sur Internet². Tout appel vers l’utilisateur guest sera acheminé vers le contexte fromiax que l’on retrouve dans le plan d’appel.

Le plan d’appel extensions.conf doit contenir de quoi gérer un appel entrant, classiquement on aura quelque chose qui pourrait ressembler à

[fromiax]
; echo pour Enum IAX
exten => 882990053789999,1,Answer()
exten => 882990053789999,n,Echo()

On valide le numéro d’appel et exécute les actions spécifiques, ici une prise de ligne et un Echo() qui permet de faire du test³.

Pour recevoir des appels en SIP

Le cas de SIP est un peu différent dans la méthode même si le principe est exactement le même: accepter un appel de l’extérieur. Nous considérons ici que votre Asterisk et la solution de sécurité réseau sont configurés pour accepter des appels en SIP.

Dans un premier temps il est important de mettre en place un contexte dans sip.conf permettant à e164.org de valider votre serveur. Ceci peut nécessiter des ajustements en fonction du fournisseur de service ENUM sélectionné. Je vous propose quelque chose comme:

[enumsip-e164]
type=peer
host=e164.org
qualify=no
context=from-e164org
insecure=very

On ajoutera dans le plan d’appel la section correspondante à la validation de l’appel:

[from-e164org]
exten => _.,1,Answer()
exten => _.,2,Hangup()

Il est maintenant nécessaire de configurer notre Asterisk pour accepter des appels de n’importe quel correspondant sur Internet utilisant SIP. Ceci n’est pas trivial dans Asterisk qui souhaite valider la provenance des initiations de session SIP et les rattacher à un contexte dans sip.conf. Or ici, nous ne pouvons pas créer un contexte pour chaque contrepartie, celles-ci étant inconnues par définition. On utilisera donc la fonction de dernier recours mise en place dans le traitement des appels SIP et qui constitue à déléguer au plan d’appel le soin de valider celui-ci. Tous les appels parvenant dans notre Asterisk en SIP seront donc acheminé automatiquement dans le contexte du plan d’appel nommé default. Dans ce contexte nous devrons être très sélectif et traiter uniquement nos SDA. Par exemple, toujours tiré de ma liste de SDA e164.org mais en SIP cette fois ci, je vous propose la configuration suivante pour le fichier extensions.conf:

[default]
; echo pour ENUM SIP
exten => 882990065339999,1,Answer()
exten => 882990065339999,n,Echo()

Un appel vers le numéro 88299 006533 9999, aboutira en SIP sur un Echo() localisé dans mon Asterisk.

Nous avons donc désormais un système capable de recevoir des appels SIP ou IAX depuis un tiers sur Internet et basé sur un numéro de SDA existant dans le monde RTC ou sur une SDA offerte par notre fournisseur ENUM.

Passage d’appel

Nous allons voir maintenant comment acheminer un appel à partir de notre Asterisk, relié à Internet et ceci après avoir effectué une recherche dans la base ENUM.

Le principe est d’utiliser, avant l’appel, une (ou plusieurs) recherche à l’aide de la fonction ENUMLOOKUP. Cette fonction est disponible dans le module func_enum.so qui doit donc être chargé et son fichier enum.conf présent dans le répertoire des configurations.

La fonction ENUMLOOKUP effectue la requête DNS permettant d’extraire les informations correspondantes, de la base du fournisseur sélectionné, par défaut e164.arpa. Elle peut effectuer des recherches plus ou moins ciblées et s’informer également sur le nombre d’enregistrements présents dans la base DNS.

Nous vous proposons une solution de code à ajouter dans le fichier extensions.conf et permettant d’automatiser cette recherche, par le biais d’une macro:

; callENUM *****
; --- get address in ENUM DNS record and dial
; args:
;  1: extension
;  2: domain to lookup
;  3: iax2 or sip
;
[macro-callENUM]
exten => s,1,Set(count=${ENUMLOOKUP(+${ARG1},${ARG3},c,,${ARG2})}|counter=0)
exten => s,n(start),GotoIf($["${counter}" >= "${count}"]?end)
exten => s,n,Set(counter=$[${counter}+1])
exten => s,n,Set(ENUM=${ENUMLOOKUP(+${ARG1},${ARG3},,${counter},${ARG2})})
exten => s,n,GotoIf($["${LEN(${ENUM})}" = "0" ]?start)
exten => s,n,Set(DIALSTR=${ARG3}/${ENUM})
exten => s,n(dodial),Dial(${DIALSTR},30)
exten => s,n,GotoIf($["${DIALSTATUS}"=="CHANUNAVAIL"]?start)
exten => s,n,GotoIf($["${DIALSTATUS}"=="CONGESTION"]?start)
exten => s,n(end),Verbose(Dial failed due to ${DIALSTATUS})

Son fonctionnement est le suivant: on vérifie tout d’abord qu’au moins un enregistrement est bien présent dans la base DNS (il peut en effet y en avoir plusieurs dans le cas de solution redondante). Ensuite, en fonction de la technologie recherchée (IAX ou SIP), on cherche les informations qui serviront au Dial(). L’appel est présenté et s’il échoue on essaye l’enregistrement ENUM suivant jusqu’à sortir de la macro.

Le principe d’appel de cette macro est, par exemple, le suivant:

exten => _X.,1,Macro(callENUM,${EXTEN},e164.org,iax2)
exten => _X.,2,Macro(callENUM,${EXTEN},e164.org,sip)
exten => _X.,3,Macro(callENUM,${EXTEN},e164.arpa,sip)

Ici, on fait d’abord une tentative en IAX, puis en SIP, la base étant celle d’e164.org. Si l’appel n’aboutit pas, on tente une recherche dans la base de e164.arpa, en SIP uniquement.

Conclusion

La communication sans opérateur voix est une réalité technique, mais pas encore sur le terrain en raison de l’usage massif du réseau RTC à ce jour. La migration lente mais inéluctable vers les opérateurs SIP (Centrex IP) pour l’acheminement des appels ouvre la porte à des initiatives comme celle d’ENUM pour l’usage de la voix en peer-to-peer. Restera à surveiller les évolutions réglementaires, notamment au niveau des interceptions légales et la réponse des opérateurs qui ne vont pas laisser un marché leur échapper de la sorte.

Ne vous attendez néanmoins pas à passer ou recevoir beaucoup d’appel via ENUM, mais ceci peut être utilisé pour joindre des partenaires, des sites distants ou pourquoi pas des usagers de la communauté Asterisk ayant lu cet article.

1. Session Border Controller [↩]
2. nous évoquerons dans un article prochain les solutions pour limiter le spam ou spit [↩]
3. vous pouvez l’utiliser d’ailleurs [↩]

• Sur la période 2007-2010, la demande pour des solutions hybrides diminuera, au profit des solutions “full IP” basées sur des PBX IP et des postes IP.
• En 2010, l’IDATE prévoit qu’environ 70% des lignes fonctionneront sur des ports IP, et 30% encore en TDM.
• La base installée IP se partagera alors entre les IP PBX “full IP”, les IP PBX hybrides et les solutions de Centrex IP.
• Concernant l’IP Centrex, les prévisions les plus optimistes pour 2010 prévoient que cette solution aura atteint 20% du marché mondial (en nombre de ports). Cette part de marché sera probablement inférieure en Europe.
• Les solutions Mobile PBX devraient rester plus encore plus marginales à moyen terme, représentant moins de 10% du marché en 2010.

Cette analyse me paraît réaliste par rapport aux mouvements de marché que l’on observe en ce moment, que ce soit chez les opérateurs, les constructeurs de PBX ou les solutions ouvertes comme Asterisk et l’offre pléthorique d’intégration associée. En revanche il faut bien différencier la technologie qui est utilisée sur la partie PABX interne, c’est à dire entre le PABX et les postes téléphoniques et la connectivité avec le monde extérieur (opérateurs, prestataires de services, groupement d’abonnés).

J’ajoute et en conclue:

• votre prochain système de téléphonie doit être sur IP,
• il devra encore gérer des lignes traditionnelles, en attendant que l’offre IP des opérateurs se stabilise,
• tout PABX ou équipement proposé sur le marché à cette heure aux entreprises doit supporter SIP,
• il faut ouvrir les fonctionalités des PABX afin qu’ils puissent écouler des appels en mode peer-to-peer directement avec le PABX de l’interlocuteur (à travers des systèmes comme ENUM par exemple),
• les opérateurs IP Centrex pûr (cf B3G, Ipnotic, …) doivent proposer des offres SIP pour les détenteurs de PABX IP qui ne souhaitent pas encore passer en tout Centrex,
• les éditeurs de solution basées sur Asterisk, OpenSER, FreeSwitch doivent challenger les constructeurs traditionnels et leur prendre des parts de marché. En revanche, ils se doivent de proposer des solutions simples, intégrées, adaptées et performantes tout en ne négligeant pas le service.,
• les techniciens et ingénieurs du secteur doivent se former à à téléphonie sur IP de façon sérieuse.

Alors on pourrait dire “encore un nouveau téléphone Wi-Fi”, il faudra avant de juger l’avoir dans les mains et le tester sérieusement par rapport à la concurrence. Mais si Aastra a reporté son expérience SIP présente dans la gamme 5xi dans ce téléphone, alors on aura probablement un produit de bonne facture. De plus, il dispose d’une fonctionnalité que je trouve intéressante: une carte mémoire contenant le répertoire et la configuration et permettant ainsi de changer de terminal sans avoir à le reconfigurer; on connaissait cette fonction sur les platines de téléphonie de marché, mais à ma connaissance pas encore sur un téléphone SIP.

On notera dans les points positifs (entre autre):

• une vrai documentation utilisateur
• le support de WPA et WPA2 en mode clé partagée
• le support de 802.11e pour l’économie d’énergie U-APSD
• un affichage des informations d’itinérance, lorsque le téléphone passe d’un AP Wi-Fi à un autre il l’affiche à l’écran et garde des informations sur la qualité du signal

Dans les points négatifs je ne relèverais à cette heure que le fait que l’information sur le site web d’Aastra n’est pas simple à trouver…

Tout ceci nous met l’eau à la bouche. Mesdames et Messieurs chez Aastra France, n’hésitez pas à nous faire parvenir un téléphone d’essai au laboratoire de Panoramisk, nous nous ferons un plaisir de communiquer ce que nous en pensons.

Introduction

Wireshark s’est imposé comme l’outil à avoir dans sa trousse dès lors que l’on manipule des données sur un réseau et que l’on souhaite les analyser. Même si sur certains points il peut être considéré comme moins performant que des produits commerciaux, Wireshark dispose de fonctions très avancées dans l’analyse, notamment des protocoles de téléphonie sur IP. Nous allons utiliser aujourd’hui les fonctions d’analyse SIP et RTP disponibles.

Principe de capture

Le principe de fonctionnement d’une analyse de réseau est toujours le même: il faut capturer des trames circulant sur le réseau avant de pouvoir les analyser. L’analyse peut s’effectuer en temps réel ou en temps différé.
Il est important de se positionner au bon endroit du réseau afin de pouvoir capturer les trames qui nous intéressent. Malheureusement, le modèle très distribué de SIP ne va pas nous aider dans cette démarche, mais il existe des solutions.

Afin de collecter les trames nous allons soit utiliser directement Wireshark, qui dispose d’un module de capture, soit l’application en ligne tcpdump qui est plus légère et intégré sur la plupart des Unix du marché.

Deux solutions de capture sont proposées ici:

• via un port miroir sur le réseau: cette solution nécessite de disposer d’équipements de réseau autorisant la capture sur un port ou un VLan. On parle souvent de port miroir ou SPAN en fonction des constructeurs, le mécanisme est le suivant: on demande au commutateur réseau de recopier tous les paquets passant sur le port à écouter et de les rediriger sur un port sur lequel on connectera l’analyseur de protocole. S’il on dispose d’un VLan dédié à la voix, on pourra alors envisager d’effectuer une capture sur l’ensemble de celui-ci, si les commutateurs en sont capables. La cible simple pour l’analyse est le PABX IP ou tout du moins la partie qui héberge la fonction proxy. Une seconde cible possible est le téléphone IP qui sera observé, on aura alors l’ensemble des informations échangées par cet équipement.
• via une capture sur le proxy: la seconde solution consiste à capturer directement le trafic sur le PABX IP ou le proxy s’il est possible d’utiliser un tcpdump ou équivalent sur cette machine. C’est le cas d’Asterisk qui est hébergé sur un système Linux dans la plupart des cas.

Capturer avec tcpdump

Dans le monde Asterisk nous pouvons tirer partie de deux caractéristiques principales par rapport à la capture du trafic:

• le système d’exploitation est souvent un Linux, disposant facilement de la commande tcpdump (à installer à partir des packages, c’est plus simple)
• Asterisk fonctionne comme un “back-to-back UA”, c’est à dire qu’il reste actif dans la communication pour le transport de la signalisation et de la voix¹.

En effectuant une capture à l’aide de tcpdump directement sur notre Asterisk, nous aurons donc toute la communication, depuis la signalisation de l’appel jusqu’au trames RTP contenant la voix.

tcpdump est une commande en ligne, que l’on peut donc utiliser sans interface graphique et directement sur le serveur. Cette commande doit être lancée avec quelques paramètres permettant de faciliter l’analyse et de limiter la taille du fichier de stockage. Je vous propose les paramètres suivants:

• -p : uniquement les paquets étant visibles par l’interface réseau d’Asterisk seront capturées, sinon tcpdump tente de capturer également les trames qui ne sont pas pour sa machine,
• -n : pas de résolution de nom, on pourra effectuer ceci après coup si besoin est,
• -s 0 : on capture toute la trame, pas uniquement les premiers octets constituant les en-têtes, souvent suffisant pour la partie purement protocolaire, nous avons besoin d’analyser le contenu des paquets, SIP étant un protocole verbeux,
• -w fichier : on va sauvegarder les trames capturées dans un fichier et pas uniquement les afficher à l’écran, ceci permettra une analyse à posteriori, plus simple à effectuer. S’il on spécifie le nom de fichier ‘-’, alors le contenu est dirigé sur la sortie standard, nous y reviendrons plus tard.

En complément, on peut spécifier à tcpdump un filtre permettant de limiter la collecte à une partie du trafic. Dans notre cas nous pouvons nous concentrer sur le protocole UDP et éventuellement limiter les ports. Etant donné que RTP utilise des ports UDP attribués de façon dynamique, on se limitera à ce protocole. En complément on pourra limiter les adresses IP communicantes.

Capture en local

Afin de capturer directement sur le serveur Asterisk, il est nécessaire d’y être connecté, soit sur la console soit via un ssh.

En exécutant la commande

tcpdump -w trace.cap -p -n -s 0 "udp”

, nous allons récupérer l’ensemble des trames UDP qui auront transité par notre Asterisk jusqu’à ce que l’on arrête la capture par un CTRL-c. Le fichier ainsi construit pourra être analysé plus tard. On pourra éventuellement le compresser avec gzip si l’espace de stockage est limitée sur notre serveur Asterisk.

Capture à distance

Plus simple à utiliser que la capture en local et le transfert de fichier de capture après coup, on peut également utiliser ssh pour effectuer une capture à distance sur notre serveur Asterisk. Depuis son poste client il suffit d’invoquer la commande tcpdump à distance dans un tunnel ssh. ssh est installé dans les commandes de base sur Linux et Mac OS X, on installera cygwin sur Windows pour récupérer un environnement similaire.

La commande proposée est la suivante :

ssh root@asterisk 'tcpdump -w - -p -n -s 0 udp' > capture-asterisk.cap

Les trames capturées sur le serveur asterisk via tcpdump ne seront pas sauvegardées en local dans un fichier, mais dirigées vers la sortie standard et donc reviendrons sur le poste client via le tunnel ssh² pour se retrouver finalement dans le fichier capture-asterisk.cap. On peut ainsi piloter des captures depuis son poste de travail sur des serveurs Asterisk distant sans trop de contrainte.

Analyse

Une fois que l’on dispose d’une capture dans un fichier, il est alors temps d’utiliser Wireshark pour analyser son contenu.

Wireshark dispose d’une interface graphique capable de présenter les trames de la capture et d’en décoder le contenu. Les protocoles Ethernet et IP sont connus depuis longtemps, mais on trouve également SIP, IAX2 et RTP qui nous intéressent plus dans notre cas.

Depuis l’explorateur de fichiers on ouvre la capture (fichier avec extension .cap) et Wireshark nous présente l’ensemble des trames dans la partie supérieure et le contenu de la trame sélectionnée dans la partie inférieure de la fenêtre. On peut sélectionner la trame à analyser en faisant défiler la liste dans laquelle les trames sont triées par heure d’arrivée.

Filtrage

Afin de filtrer la liste de trames et de n’en afficher qu’une partie plus spécifique, on peut utiliser le champ ‘Filter’ situé au dessus de la liste. Le filtrage de Wireshark utilise un langage spécifique qui s’apprend au fur et à mesure, un principe de base est que le filtre est valide lorsque la couleur de fond de celui-ci est vert. On peut par exemple sélectionner les trames SIP en utilisant le filtre : sip, les trames IAX avec le filtre : iax2.

Pour aller plus loin, on peut enrichir le filtrage à l’aide des champs situés dans la partie analyseur de protocole. Chaque partie du protocole peut être détaillée à l’aide du [+] situé dans la colonne de gauche. Par exemple pour filtrer les trames en provenance d’un client particulier, on se basera sur son adresse IP. On ouvre pour cela la partie IP (Internet Protocol) dans laquelle il suffit de sélectionner la source avec le bouton droit de la souris et d’ajouter ce champ à notre filtre à l’aide du menu “Apply as filter / … and Selected”.

Analyse SIP

Traquer les trames une à une est une approche difficile et fastidieuse. Dans certains cas, il est intéressant de s’appuyer sur l’analyse automatique proposée par Wireshark dans le menu “Statistics / VoIP calls”.

Dans la fenêtre s’affichent tous les appels contenus dans la trace³.

A partir de cette liste on peut afficher la conversation sous forme graphique. Cette vue permet une rapide analyse des échanges, elle est fortement couplée aux paquets ce qui autorise une navigation rapide pour une analyse plus poussée du contenu des trames. Il est également possible d’analyser la partie voix contenu dans les trames RTP de l’échange.

La fonction “Player” décode le contenu des échantillons de voix et permet de rejouer la conversation, ceci peut-être utile pour constater une mauvaise qualité reportée par un utilisateur vers une destination particulière par exemple.

Analyse RTP

Le protocole RTP⁴ n’est pas spécifique à la téléphonie sur IP mais utilisé de façon unanime pour l’instant, que ce soit dans le monde SIP ou le monde H.323. Wireshark dispose d’un outil d’analyse fin des échanges RTP entre deux terminaux. On trouve la fonction dans le menu “Statistics / RTP / Stream Analysis”.

La fenêtre d’analyse donne des informations sur les terminaux, le codec utilisé et des statistiques sur la communication: le nombre de trame perdues et la gigue constatée. On peut aller plus dans le détail et analyser les trames une par une afin de constater les écarts de gigue ou la répartition des trames perdues sur l’échange. Cet outil permet également de sauvegarder le contenu de la communication dans un fichier son qui sera utilisable par la suite pour une analyse audio.

Conclusion

La téléphonie sur IP, comme toutes les applications utilisant fortement le réseau se doit d’être analysée lorsqu’il y a des problèmes. Afin de ne pas être pris de court, une bonne technique est de s’être préparé à effectuer ces analyses. Cette répétition peut permettre également d’effectuer un audit de son système et ainsi renforcer sa connaissance de celui-ci. Même si les protocoles sont souvent difficiles à appréhender, leur connaissance permet de résoudre bien des problèmes en amont.

1. ceci va à l’encontre du modèle distribué de SIP mais permet d’ajouter des fonctionnalité de téléphonie - voir l’article “Asterisk et transport de la voix” [↩]
2. on utilisera les clés ssh afin d’automatiser l’identification de l’utilisateur et éviter ainsi d’avoir à taper son mot de passe à chaque fois [↩]
3. s’il on prend une trace en temps réel, alors cette liste se modifie au fil de l’eau [↩]
4. Real Time Protocol [↩]