Voix sur IP. Sébastien BAUDRAND Laurent LEGAZ Mathieu LOSLIER ESIPE-MLV 18/10/2013

Transcription

1 2013 Voix sur IP Sébastien BAUDRAND Laurent LEGAZ Mathieu LOSLIER ESIPE-MLV 18/10/2013

2 Sommaire Introduction Pré-requis Matériels utilisés Logiciels utilisés Protocoles mis en œuvre Session Initiation Protocol (SIP RFC 3261 et 3265) Real-time Transport Protocol (RTP) Installation et configuration du serveur Asterisk Installation de Asterisk Configuration Asterisk Installation et configuration des téléphones : logiciels Twinkle Paramétrage d ALSA Installation et configuration des clients Twinkle Questions Configuration de la boite vocale du voic Interconnexion de deux serveurs Asterisk : Trunk SIP Première tentative Seconde tentative Peering Configuration de serveur A Configuration de serveur B Questions Conclusion IR ESIPE Engineering School Paris. Oct

3 Introduction Ce rapport présente le TP de VoIP réalisé par Sébastien BAUDRAND, Laurent LEGAZ et Mathieu LOSLIER dans le cadre de leurs enseignements en VoIP dispensés par Hakim BADIS. Il a été réalisé à la suite d un cours magistral et 4 heures et d une séance de travaux pratiques de 4 heures abordant les systèmes de VoIP existant et, surtout, les protocoles SIP et RTP. La VoIP, «Voice over IP» ou Voix sur IP est une méthodologie et un ensemble de protocoles permettant de réaliser le transfert de voix sur un support numérique, via le protocole internet : IP, avec une qualité de service comparable aux téléphones analogiques classiques. Asterisk est un serveur PBX ou PABX, il est open source et peut être utilisé pour réaliser des centres de téléphonies ou de conférences audio via VoIP. Plusieurs protocoles sont en jeu pour déployer cette technologie, ou peuvent être ajoutés, par exemple pour permettre le chiffrement des conversations. Le protocole utilisé dans le cadre d initialisation des sessions dans le cadre d une conversation VoIP est SIP, puis le couple RTP/RTCP est employé pour diffuser la voix en temps réel sur le support de communication. D autres protocoles, basés eux aussi sur RTP et principalement axés vers l audioconférence, sont supportés par Asterisk, tels la famille de protocoles H.323. Dans un premier temps, ce rapport présente le matériel nécessaire à la réalisation du TP, ou pouvant être utilisés pour reproduire les manipulations décrites. Dans un second temps, il présente la mise en place d un serveur Asterisk simple et la communication entre deux intervenants soit par connexion directe entre les deux (avec mise en relation par l intermédiaire d un serveur SIP), soit par utilisation d un proxy SIP. Nous tenterons ensuite de mettre en place une boîte vocale, puis de réaliser un «Trunk» reliant deux serveurs de téléphonie distants. 1. Pré-requis Afin de réaliser le TP de Voix sur IP dans de bonnes conditions, plusieurs pré-requis aussi bien matériel que logiciel ont été nécessaire. 1.1 Matériels utilisés Le TP a été réalisé sur des PC ayant comme système d exploitation Debian Linux pour les machines ayant les rôles de serveur et clients. Pour le matériel chargé de la voix, nous avions en notre possession de simple PC avec micro-casque. Mais il est tout à fait envisageable d utiliser des appareils de type SIP Phones ou PDA Phones avec connexion à un réseau (par exemple en wifi) et client SIP installé. IR ESIPE Engineering School Paris. Oct

4 1.2 Logiciels utilisés Divers logiciels ont été utilisés afin de réaliser le TP VoIP, que ce soit pour utiliser la téléphonie, ou pour analyser les paquets transmis lors des échanges entre le client et le serveur VoIP. Pour l utilisation de la VoIP, nous utilisons la version libre du logiciel de téléphonie par IP Twinkle exploitant des comptes SIP pour la partie cliente. Twinkle est relativement personnalisable : il permet notamment de gérer le délai avant de faire basculer l'appel sur votre ligne téléphonique normale, de choisir votre statut actuel (disponible/occupé). Pour la partie serveur, nous avons utilisé le logiciel Asterisk, autocommutateur téléphonique privé open source et propriétaire (publié sous licence GPL et licence propriétaire1) pour systèmes GNU/Linux. Il permet, entre autres, la messagerie vocale, les files d'attente, les agents d'appels, les musiques d'attente et les mises en garde d'appels, la distribution des appels. Nous avons également utilisé les outils de manipulations de trames d iptables et d iproute2, ainsi que l analyseur de trames Wireshark. 1.3 Protocoles mis en œuvre Session Initiation Protocol (SIP RFC 3261 et 3265) SIP (Session Initiation Protocol) est un protocole de signalisation permettant d établir, de modifier et de fermer des sessions multimédia. Ce protocole a été conçu par le groupe MMUSIC (Multiparty Multimedia Session Control) et est désormais maintenu par l IETF (Internet Engineering Task Force). Basé sur des échanges de messages textes ASCII (Requêtes/Réponses), il est fortement inspiré du protocole HTTP (HyperText Transfert Protocol). Les messages de requêtes Il existe 6 types de message différents : - REGISTER : pour l enregistrement des informations d un contact - INVITE : initialise une session - ACK : acquittement d une réponse - CANCEL : annuler un échange de messages en cours - BYE : pour terminer les sessions - OPTIONS : pour demander aux serveurs des informations sur leurs capacités Les messages de réponse Les réponses peuvent être de plusieurs types: IR ESIPE Engineering School Paris. Oct

5 - 1xx : Information (requête reçue, en progression ) - 2xx : Succès (action reçue, compris et accepté) - 3xx : Redirection - 4xx : Erreur client (mauvaise syntaxe de la requête) - 5xx : Erreur Serveur Le protocole SDP (Session Description Protocol) SIP utilise le protocole SDP pour définir le type de média (audio, vidéo), le protocole de transport (RTP, UDP, IP), et le format du média (H.261 video, MPEG video ) à utiliser entre les clients de la session Real-time Transport Protocol (RTP) RTP (Real-Time Transport Protocol) est un protocole de gestion des flux multimédia (voix, vidéos, data). Il permet de transporter les informations codées (voix, vidéos) en temps réel. RTCP est utilisé en parallèle à RTP pour superviser les communications multimédia. Il assure la qualité de service des communications RTP : les différents participants d une communication envoient des paquets RTCP périodiquement. Ces paquets donnent des informations sur l état de la communication : délai, perte de paquets. La topologie de notre réseau VoIP est la suivante : IR ESIPE Engineering School Paris. Oct

6 2. Installation et configuration du serveur Asterisk 2.1 Installation de Asterisk Tout d'abord, veillez à avoir une distribution à jour : sudo apt-get update La première opération consiste à installer le logiciel Asterisk sur la machine serveur Debian : sudo apt-get install Asterisk Pour vérifier le bon fonctionnement du serveur Asterisk, il est maintenant possible de l'exécuter en mode verbeux (option-v) avec une interface ligne de commande associée (option-c): Asterisk -vvvvc Une invite de commande doit apparaître à la fin si tout se déroule correctement : Asterisk Ready. *CLI> On peut alors rapidement voir l'ensemble des commandes disponibles via l'interface CLI (Command Line Interface). *CLI>help 2.2 Configuration Asterisk La configuration d'asterisk s'articule sur les fichiers de configuration suivants : - /etc/asterisk/sip.conf/sip.conf : configuration globale d'asterisk - /etc/asterisk/users.conf/users.conf : configuration des utilisateurs - /etc/asterisk/extentions.conf/extentions.conf : fichier d extension pour gérer les différents appels Chaque modification dans la configuration devra être suivie par la commande reload saisie dans la console d Astrerisk. Nous allons commencer par éditer le fichier de configuration SIP de notre serveur, à savoir sip.conf. Le but est ici de créer deux utilisateurs. L'intérêt de créer des utilisateurs réside dans le fait que les clients SIP vont pouvoir s'authentifier auprès du serveur, ce qui permettra par la suite de «localiser» ces utilisateurs (savoir avec quelle adresse IP les contacter par exemple) : IR ESIPE E Engineering School Paris. Oct

7 [laurent] type=friend host=dynamic username=laurent secret=lolo callerid="laurent" <555> context=default [sebastien] type=friend host=dynamic username=sebastien secret=seb callerid="sebastien" <556> context=default Ici nous avons crée les utilisateurs Laurent et Sebastien, les deux ayant le même mot de passe (secret) «lolo» (pour des besoins de simplicité). Le type friend spécifie que cet utilisateur pourra être appelé et pourra appeler. Le champ host à dynamic signifie que l'adresse IP de l'utilisateur sera amenée à changer. Le champ username spécifie le nom que l'utilisateur devra saisir pour s'authentifier au serveur. Le champ callerid correspond à ce qu'il sera affiché sur les clients SIP des utilisateurs lorsque qu'ils communiqueront avec l'utilisateur en question. Le champ mailbox est utilisé par Asterisk pour envoyer les messages vocaux vers les boites mail des utilisateurs (comportement par défaut). Enfin le champ context (que nous avons ajouté) permet de segmenter l'administration des utilisateurs et du dialplan. Par exemple dans le cadre de ce TP, tous nos utilisateurs seront définis dans le contexte default. Un contexte voiplan devra être défini en conséquence dans le dialplan. Lorsqu'un utilisateur définis dans le contexte default appellera, son appel sera automatiquement géré dans le contexte default du dialplan. Ceci permet de structurer notre infrastructure logique. Pour recharger le module SIP afin de relire la configuration modifiée il suffit de taper la commande : *CLI>sip reload Il suffit maintenant d'attribuer un numéro de téléphone à chacun des deux téléphones que nous venons de déclarer. Le fichier extensions.conf permet d'associer à chaque numéro de téléphone une IR ESIPE Engineering School Paris. Oct

8 suite de commandes. Pour ce faire, il suffit d'ajouter les deux lignes suivantes à la fin de ce fichier (plus exactement à la fin du contexte [default]) : [default] exten => 555,1,Dial(SIP/sebastien, 10) exten => 555,n,HangUp() exten => 556,1,Dial(SIP/laurent, 10) exten => 556,n,HangUp() Ici on a dit plusieurs choses. Tout d'abord nous associons le numéro 555 à l'action Dial(SIP/sebastien, 10). Cette action (Dial) a pour effet d'appeler l utilisateur SIP sebastien (donc en utilisant le protocole SIP). Aussi, nous indiquons un timeout de 10 secondes, après quoi l'appel sera considéré comme non aboutissant. Le deuxième chiffre de la ligne : «1» correspond à la priorité de l'action à effectuer. Ici on indique que la priorité absolue (à savoir 1) est d'appeler sebastien. Pour faciliter l exploitation de ce fichier de configuration, Asterisk a pensé à définir le «n» qui signifie «next». Il est alors plus aisé d'insérer une ligne entre deux autres sans pour autant avoir à modifier toutes les priorités des lignes du dessous. Ici on spécifie que si au bout de 10 secondes Sebastien ne répond pas, alors on passe à l'action suivante (priorité au dessus, ici n) qui consiste tout simplement à raccrocher (HangUp). En fait l'action «raccrocher» aura pour effet d'envoyer un message Request avec pour méthode la méthode BYE (comme vue plus haut). On fait de même avec l utilisateur laurent, excepté qu'on lui attribue le numéro 556. Une fois les fichiers édités, il faut avertir le serveur Asterisk que l'on a modifié ces fichiers. Pour signaler au serveur Asterisk de recharger sa configuration sip ainsi que la configuration du dialplan, on se connecte en ligne de commande et on agit comme suit : *CLI>dialplan reload *CLI>sip reload 3. Installation et configuration des téléphones : logiciels Twinkle 3.1 Paramétrage d ALSA Pour utiliser le téléphone logiciel Twinkle, il est préférable de se procurer un micro-casque. Il faut également s'assurer que le son du micro et celui du casque fonctionnent correctement avec le greffon ALSA (Advanced Linux Sound Architecture). IR ESIPE Engineering School Paris. Oct

9 Avant tout, il faut installer le système de base ALSA et ses utilitaires : apt-get install alsa-base apt-get install alsa-utils Il est alors possible de lancer la détection de la carte son et l'installation du driver ALSA correspondant, via la commande alsaconf ou alsamixer. Puis, de paramétrer convenablement les volumes du casque et du micro via la commande alsamixer. Le logiciel Alsamixer s'utilise à l'aide : - Des flèches haut/bas pour régler un niveau sonore. - Des flèches gauche/droite pour se déplacer sur les différentes sources. - De la touche [M] pour activer/désactiver une source. - De la touche [ESC] pour quitter. La configuration d alsamixer doit correspondre aux deux figures suivantes : Figure 1 - AlsaMixer, affichage en console Linux Debian Pour un premier essai, le micro et le casque seront activés (Attention! «MM» dans Alsamixer signifie Mute donc désactivé) et mis au maximum. Pour commencer, on peut tester le casque avec un fichier.wav quelconque : aplay fichier.wav IR ESIPE Engineering School Paris. Oct

10 Ensuite, lorsque le test du casque est positif, on peut tester le micro : arecord f cd test.wav aplay test.wav Il faut généralement relancer plusieurs fois Alsamixer pour affiner empiriquement les niveaux sonores du micro et du casque jusqu'à avoir une qualité audio correcte. 3.2 Installation et configuration des clients Twinkle Maintenant que l'on est assuré du bon fonctionnement du micro-casque, on peut installer le téléphone logiciel Twinkle sur la première des machines clientes Debian. Pour cela : apt-get install twinkle Le reste de la configuration d twinkle se fait simplement à travers l'interface graphique. La configuration décrite est réalisée sans l'assistant de première configuration. Lancer maintenant un client Twinkle : twinkle & Et suivre les étapes à l aide du Wizard. Figure 2- Utilisation du wizard pour la configuration des clients Twinkle. IR ESIPE Engineering School Paris. Oct

11 Si l enregistrement est OK, le premier client Twinkle est configuré correctement, il est possible d'appeler un numéro d'accueil sur le serveur Asterisk en composant le 3. Un message de bienvenue est alors annoncé («Welcome to the Asterisk Open Source PBX...»). Une fois les deux clients correctement configurés, il est possible d'effectuer un appel interne du premier poste client Twinkle vers le second et vice-versa. Pour cela, il faut respectivement composer le 556 sur le premier poste ou le 555 sur le second. 3.3 Questions 1/ A quoi sert le secret dans le fichier de configuration sip.conf? Le secret permet de d établir une connexion avec le serveur de manière sécurisé en demandant un mot de passe. Il est impossible de connecter en anonyme et d appeler un autre client. Grâce à cette sécurisation on peut faire un historique d appel d un utilisateur. 2/ Quelle est la commande sous Asterisk qui permet d afficher les clients sip? Commenter le résultat. La commande sip show user permet de lister tous les clients configurés dans le fichier sip.conf. On peut remarquer pour chaque client : - un nom d utilisateur (username), - un mot de passe (secret), - un numéro de compte associé (Accountcode) pour une éventuelle facturation, - un contexte d exécution par défaut (Def.context), - une liste de droits associée (ACL : Access Control List) définie dans le fichier acl.conf - une configuration pour la translation d adresse (NAT) 3/ Afficher les canaux sip avant un appel pendant un appel Avant un appel : Pendant un appel : On peut donc avoir un aperçu général de toutes les communications en cours. IR ESIPE Engineering School Paris. Oct

12 4/ Quels sont les messages échangés avec le serveur Asterisk lors d une inscription (registration) Dans ce scénario Laurent ( ) s'enregistre auprès du serveur Asterisk ( ). Nous analysons les flux associés à cette communication : Plus schématiquement nous avons lors d une inscription les actions suivantes : 1. Le client essaie de s'enregistrer avec le serveur. IR ESIPE Engineering School Paris. Oct

13 2. Le serveur rejette l'enregistrement du client et lui envoie en retour un "challenge digest" composé du type d'algorithme, un "realm" et un "nonce". Le "nonce" est une valeur aléatoire créée sur serveur Asterisk et envoyée au client. Il a un temps de vie limité évitant des attaques de type "replay". Chaque "challenge digest" contient une valeur nonce différente. Le "realm" est le nom de domaine SIP. Le principe de la "digest authentication" est de vérifier que les deux parties qui communiquent connaissent un mot de passe partagé. 3. Le client envoie une nouvelle demande d'enregistrement mais cette fois avec une "digest response" composée par : o Un "username" (nom d'utilisateur), un "realm", un "nonce", un "URI", une "response"(réponse) et un type d'algorithme o Une "URI" (Uniform Resource Identifier) est une chaine de caractère utilisée pour identifier une ressource. o Le "nonce" envoyé par le serveur est utilisé pour créer la réponse ("response"). Le serveur vérifie les informations d authentification du client avec son fichier de configuration sip.conf, et le challenge calculé par le client. En fonction des résultats le serveur accepte la connexion du client. 4. Le serveur est capable, après calculs, de valider le mot de passe du client avec le "digest response" qu'il a juste reçu. Avec le processus de la "digest authentication", aucun mot de IR ESIPE Engineering School Paris. Oct

14 passe n est échangé entre le client et le serveur. Le serveur peut envoyer un message au client pour valider l'enregistrement. 5/ Détailler le contenu et commenter en utilisant Wireshark les messages de signalisation SIP/SDP ainsi que les messages RTP échangés entre les deux PCs et le serveur Asterisk lors d un établissement d une connexion VoIP. Analysons les flux associés grâce aux trames capturées par Wireshark : Au niveau du serveur Asterisk, on observe les logs de l appel passé à sebastien : Laurent ( ) communique avec le serveur Asterisk ( ), ce dernier agit comme un proxy. Laurent envoie d'abord un message INVITE qui contient un message SDP. On voit la l'intérêt du proxy Asterisk car la destination de la requête de laurent se limite à ceci : On voit bien que laurent n'a aucune information sur sebastien si ce n'est uniquement son numéro de téléphone, ici 556. C'est ici que se joue le travail de notre serveur Asterisk. Ce dernier connaît IR ESIPE Engineering School Paris. Oct

15 l'adresse IP de laurent (car laurent s'est préalablement enregistré) et donc le serveur Asterisk pourra forwarder les requêtes de laurent vers sebastien. Le payload SDP ressemble à peu près à ce que l'on a vu précédemment, ce dernier permet à laurent de spécifier ses besoins en terme de «média» (au passage on voit qu'elle utilise Twinkle) : Une chose est cependant intéressante à observer. Le flux RTP n'est pas direct. En effet le flux RTP passe par le proxy Asterisk : On peut voir que le flux part de laurent pour aller vers le serveur Asterisk ( ). Au passage, on note l'utilisation du protocole de contrôle de la session RTP, à savoir RTCP. C'est un comportement tout à fait normal. Plus généralement voici les échanges entre 2 clients Twinkle et un serveur Asterisk lors d un appel passé par le client 1 vers le client 2. IR ESIPE Engineering School Paris. Oct

16 Le SIP Client 1 envoie un message INVITE au Proxy. Le SIP Client 1 reçoit ensuite un 100 Trying, en réponse à son INVITE. Le même échange (INVITE trying) se fait ensuite entre le Proxy et le SIP Client 2. Ce dernier envoie alors un «180 ringing» que le Proxy transmet au SIP Client 1. Cela signifie que le terminal destinataire de l appel sonne. Lorsque le terminal appelé décroche, le SIP Client 2 envoie un «200 OK» au Proxy qui fait à nouveau suivre le paquet au SIP Client 1. 6/ Quels sont les codecs proposés par l appelant et acceptés par l appelé? On peut retrouver les codecs de l appelant dans le message INVITE au niveau de SDP dans le corps du message de SIP : De même voici les codecs acceptés par l appelé : IR ESIPE Engineering School Paris. Oct

17 7/ Quels sont les messages de signalisation SIP échangés entre les deux PCs et le serveur lors d une rupture d une connexion VoIP? Lors de la rupture d'une connexion VoIP, le proxy Asterisk envoie un message BYE aux utilisateurs. Ici nous avons repris le scénario précédent et nous avons analysé ce qu'il se passait quand sebastien mettait fin à la connexion : Ainsi, lorsque la connexion se ferme : - Le client qui initie la fermeture envoi un message SIP Bye au serveur. - Le serveur relais le message SIP Bye à l autre client - Puis les deux clients envoient un message RTCP GoodBye au serveur 8/ Quels sont les messages de signalisation échangés lorsqu un 3 ème PC tente d appeler un PC qui est déjà en communication? Le PC 3 envoie une requête INVITE au serveur Asterisk, mais le PC en cours de communication va envoyer un message 486 Busy au serveur pour indiquer qu il est déjà occupé. Et l appelant va recevoir un message d erreur 603 Declined. 9/ Si Hakim veut appeler Zak sans passer par le serveur Asterisk, quelle serait la technique utilisée? Montrer dans ce cas-là les messages échangés en détaillant le contenu IR ESIPE Engineering School Paris. Oct

18 Pour pouvoir se passer du serveur Asterisk nous pouvons directement nous connecter à l autre utilisateur (zak) grâce à son adresse IP: zack@adresseip. On réalise alors une architecture SIP en P2P (Peer to Peer) comme le logiciel Skype. 4. Configuration de la boite vocale du voic 1/ Expliquer les lignes qu on vient de rajouter dans le fichier /etc/asterisk/extensions.conf Asterisk permet effectivement d'exploiter une boite vocale. Aussi Asterisk permet d'envoyer les différents messages vocaux aux boites mails associées aux différents utilisateurs. Pour configurer la fonction de boite vocale d Asterisk, on va éditer le fichier voic .conf comme suit : 555 => lolo,laurent,laurent@localhost,, attach=no review=yes 556=> seb,sebastien,sebastien@localhost,, attach=no review=yes Ici on indique que laurent (555) aura pour mot de passe de messagerie «lolo», que l'on attachera pas le message vocale au mail et que l'on permettra à la personne qui laisse un message à laurent de relire ou de ré-enregistrer son message. Aussi, on pense à éditer notre fichier extensions.conf de sorte que lorsqu une personne n'arrive pas à contacter un utilisateur, elle tombe sur sa messagerie exten => 555,2,Voic (555) exten => 556,2,Voic (556) IR ESIPE Engineering School Paris. Oct

19 exten => 700,1,Voic Main Lorsqu il y a un appel à 555, le serveur Asterisk va proposer à l appelant de laisser un message vocal pour la boite à lettre 555. Il en est de même pour 556. Le chiffre 2 représente la priorité, ce qui détermine l ordre d exécution des commandes dans le cas ou il y en aurait plusieurs. Enfin, on pense à permettre à nos utilisateurs d'appeler leur boite vocale avec le numéro / Expliquer par un schéma le fonctionnement global de la messagerie qu on vient de réaliser Un appel est passé, la personne distante ne répond pas, le serveur prend alors main et demande à l utilisateur de laisser un message. Une fois le message terminé, il est sauvegardé sur le serveur. Pour réussir à consulter ses messages, la personne doit composer le 700. IR ESIPE Engineering School Paris. Oct

20 5. Interconnexion de deux serveurs Asterisk : Trunk SIP Première tentative On souhaite connecter deux serveurs Asterisk entre eux pour faire dialoguer les clients du serveur A avec ceux du serveur B et vice versa. Figure 3 - Topologie réseau, premier essai Après la configuration des clients et du routeur comme indiqué dans le schéma ci-dessus. Nous pouvons tester la connectivité entre les deux serveurs : SCREEN Le principe du peering (aussi appelé trunk sip) consiste à ajouter un utilisateur qui correspond en fait au serveur peer (disons A). Ce serveur va devoir s enregistrer vers le serveur B. Une fois enregistré, ce dernier pourra forwarder des appels spécifiques (par exemple des appels dont le premier numéro est 7) vers notre serveur B. C est en quelque sorte un routage du dialplan. Dans notre cas, il faut faire un peering dans les deux sens A vers B et vice versa. On en déduit qu il faudra considérer nos peers comme un «friend» étant donnée qu on l appel et qu il nous appel. Pout le serveur Asterisk A, on garde la même configuration que lors de la première partie du TP, à savoir la configuration du fichier sip.conf suivante : [laurent] type=friend host=dynamic username=laurent secret=lolo callerid="laurent" <555> IR ESIPE Engineering School Paris. Oct

21 context=default [sebastien] type=friend host=dynamic username=sebastien secret=seb callerid="sebastien" <556> context=default On va ajouter l utilisateur suivant (TrunkAB), à savoir l utilisateur qui correspond à l autre serveur. [TrunkAB] type=friend host=dynamic secret=pass context=default insecure=port, invite Dans ce cas l autre serveur doit utiliser TrunkAB comme username et «pass» comme mot de passe pour s enregistrer vers le serveur A. Pour s enregistrer le serveur B doit contenir la ligne suivante dans son fichier sip.conf : register => TrunkAB:pass@ L autre serveur ayant une configuration similaire, nous devons ajouter dans le fichier sip.conf du serveur A : register => TrunkBA:pass@ Après un sip.reload, nous obtenons : (none)*cli> sip reload Reloading SIP (none)*cli> sip show users Username Secret Accountcode Def.Context ACL NAT laurent lolo default No Always TrunkAB pass default No Always sebastien seb default No Always (none)*cli> Enfin il faut modifier notre dialplan de manière à ce que les appels commençant par le chiffre 1 soient redirigés vers le serveur B. Il suffit d ajouter la ligne suivante dans le fichier extension.conf : exten=>_1xx,1,dial(sip/trunkab/${exten}) IR ESIPE Engineering School Paris. Oct

22 Ainsi tous les appels de 3 chiffres commençant par 1 sont redirigés vers l utilisateur trunkab, c est à dire le serveur A. On lui envoie l extension demandée via la variable ${EXTEN}. Ainsi, on a le fichier sip.conf du serveur A : register => TrunkAB:pass@ [laurent] type=friend host=dynamic username=laurent secret=lolo callerid="laurent" <555> mailbox=laurent@voip.lan context=default [sebastien] type=friend host=dynamic username=sebastien secret=seb callerid="sebastien" <556> mailbox=sebastien@voip.lan context=default Le fichier extensions.conf du serveur A : [default] exten => 555,1,Dial(SIP/sebastien, 10) exten => 555,n,HangUp() exten => 556,1,Dial(SIP/laurent, 10) exten => 556,n,HangUp() exten=>_1xx,1,dial(sip/trunkba/${exten}) Ainsi, on a le fichier sip.conf du serveur B : register => TrunkAB:pass@ [laurent] type=friend host=dynamic username=laurent secret=lolo callerid="laurent" <555> mailbox=laurent@voip.lan context=default IR ESIPE Engineering School Paris. Oct

23 [sebastien] type=friend host=dynamic username=sebastien secret=seb callerid="sebastien" <556> context=default Le fichier extensions.conf du serveur B : [default] exten => 555,1,Dial(SIP/sebastien, 10) exten => 555,n,HangUp() exten => 556,1,Dial(SIP/laurent, 10) exten => 556,n,HangUp() exten=>_1xx,1,dial(sip/trunkba/${exten}) Malheureusement, nous n avons pas eu le temps au cours de la séance de TP de réaliser entièrement le montage réseau et de tester cette configuration. Nous nous serions certainement rendu compte à ce moment que quelques erreurs auraient posées problèmes (directive «exten» et les plages de numéros choisis). Seconde tentative Nous avons pu profiter d une seconde chance et renouveler l essai. Nous nous sommes alors associés à un autre groupe afin de réaliser les manipulations en suivant la procédure fournie par notre professeur M. Hakim Badis. Nous allons créer et configurer ici, un Trunk SIP, afin d interconnecter deux serveurs Asterisk distants (appartenant à 2 sous réseaux différents) et permettre ainsi la communication entre des clients éloignés appartenant chacun distinctement au dial plan de l un ou de l autre serveur de téléphonie. Alice appartient au dial plan du serveur A, bob celui du serveur B. Le serveur B ne connaît pas Alice et A ne connaît pas Bob. La communication entre Alice et Bob est assurée à l aide d un Trunk SIP reliant les deux serveurs SIP. Plus précisément, pour la plage de numéros concernant Alice, le serveur B sait qu il doit forwarder l appel sur le Trunk à destination du serveur A qui retransmet jusqu Alice. La topologie du réseau utilisé est la suivante : IR ESIPE Engineering School Paris. Oct

24 Figure 4 - Topologie réseau, second essai La topologie réseau et sa mise en place ne seront pas détaillée dans ce rapport. De part les précédentes manipulations, nous pouvons également assumer ici que les clients SIP sont proprement configurés. Intéressons nous alors à la configuration réalisées pour chaque serveur Asterisk. Peering Le «Voice peering» à ne pas confondre avec une architecture Peer-to-peer SIP (ex : skype), est le principe de transférer des appels d un fournisseur de téléphonie internet (ou ITSP pour «Internet telephony service provider») à un autre via VoIP. C est bien ce que nous cherchons à réaliser avec un Trunk SIP sous Astrisk. Configuration de serveur A Dans l ordre, cette configuration fut réalisée postérieurement : après la configuration du serveur B. Le fichier sip.conf définit un utilisateur : Alice (ici «1000») et enregistre le Trunk définit depuis IR ESIPE Engineering School Paris. Oct

25 le serveur B (A ce niveau, le serveur A connaît l utilisateur trunk et cet utilisateur, une fois enregistré, accède alors également au serveur A). ; serveur A [general] disallow=all allow=ulaw canreinvite=no register => trunk-b01-a01:trunk@ [1000] type=friend host=dynamic secret=toto username=1000 callerid="1000" <1000> On configure alors le fichier extensions.conf afin de faire le lien entre la plage de numéros en 2000 et l utilisateur trunk vers lequel il faudra rediriger les appels : le serveur B. ; serveur A [globals] [general] autofallthrough=yes [default] exten => 1000,1,Dial(SIP/1000) exten => _2XXX,1,Dial(SIP/trunk-B01-A01/${EXTEN}) ; Entre 2000 et 2999 Configuration de serveur B Nous avons commencé par la configuration du serveur B, on définissant le fichier sip.conf et en vérifiant la bonne connectivité avec son client SIP (Bob, ici «2000») : ; serveur B [general] disallow=all allow=ulaw canreinvite=no [trunk-b01-a01] type=friend secret=trunk host=dynamic [2000] type=friend IR ESIPE Engineering School Paris. Oct