VOIP. QoS SIP TOPOLOGIE DU RÉSEAU

Transcription

1 VOIP QoS SIP TOPOLOGIE DU RÉSEAU La voix sur réseau IP, parfois appelée téléphonie IP ou téléphonie sur Internet, et souvent abrégée en ''VoIP'' (abrégé de l'anglais Voice over IP), est une technique qui permet de communiquer par voix à distance via le réseau Internet, ou tout autre réseau acceptant le protocole TCP/IP. Si dessus (schéma), notre réseau comme il monté et configuré. L objectif premier est que le poste SN ou est installé un téléphone XLITE puisse communiquer avec le téléphone SIP AASTRA. Une fois le câblage effectué et la configuration des interfaces réseau, il nous faut ajouter les routes sur nos deux routeurs qui permettront aux deux sites (LANNION & RENNES) de communiquer. Sur le routeur de LANNION (réseau- masque- passerelle) IP ROUTE (FAI) IP ROUTE (RENNES)

2 Sur le routeur de RENNES IP ROUTE (LANNION) Nous sommes maintenant presque en mesure de communiquer par téléphone, il nous suffit juste de configurer notre XLITE (téléphone virtuelle qui fonctionne avec un casque audio) et notre vrai téléphone IP AASTRA. Pour XLITE, il faut entrer ces options (en rouge ce sont des exemples) : - Un nom de machine : SIP301 - Un nom d utilisateur ou numéro de poste: Le domaine (serveur proxy SIP) où la demande de communication sera envoyé : (schéma) - «register with domain and receive incoming calls» - «set outbound via : proxy address » Pour le téléphone physique, voir la documentation mais penser à mettre le port sur 5060, le proxy et le registrar* sera *«Le Registrar est un serveur qui gère les requêtes REGISTER envoyées par les Users Agents pour signaler leur emplacement courant. Ces requêtes contiennent donc une adresse IP, associée à une URI, qui seront stockées dans une base de données. Les URI SIPs sont très similaires dans leur forme à des adresses sip:utilisateur@domaine.com» Un ping pour voir la connectivité entre les deux sites VOIP : ÉTUDE DU PROTOCOLE SIP A l aide de Wireshark nous avons capturé une communication entre le XLITE et le Proxy_Registrar Nous allons étudier cette capture et tenter d expliquer ce qu il s y passe. Tout d abord du n 8 à 11 nous avons des requêtes de type DNS vers la passerelle AAAA est utilisé pour les adresses IPv6 et A pour l IPv4. Mais allons plutôt voir plus bas et le protocole SIP

3 Il y a d abord une requête de type REGISTER de la part du client à direction de notre PROXY ; Cette requête REGISTER est une méthode d'enregistrement permettant à un agent (UA-User Agent) de communiquer son adresse IP et l'url où le joindre. Suivent deux statuts «100 TRYING» et «200 OK» envoyé par le REGISTRAR vers le demandeur : SIP/ Trying [Essai] La réponse 100 (En essai) indique que le «register» a été reçue et que le mandataire travaille en son nom pour acheminer à la destination. SIP/ OK La réponse 200 OK confirme que le traitement de la requête est effectué avec succès. Les informations accompagnant la réponse dépendent de la méthode utilisée pour la requête. Une fois enregistré, le client envoie une requête de type SUBSCRIBE, c est une requête d'abonnement aux évènements d'un autre agent identifié par son URI. Il y a dans cette requête un «expire», Cette valeur de expires indique la durée de l abonnement. Afin de prolonger effectivement les abonnements au-delà de la durée communiquée dans l en-tête "Expires", les abonnés ont besoin de rafraîchir les abonnements de façon périodique en utilisant un nouveau message SUBSCRIBE On peut constater aussi les ports utilisés coté XLITE(17566) et coté REGISTRAR (5060/par défaut)

4 Mise en place d une communication entre deux terminaux et analyse via Wireshark A la suite de cette communication, notre capture nous permet par exemple de visualiser qui est l initiateur de fin de communication : La requête BYE, qui stipule une session de communication est envoyé au client depuis le PROXY. Dans l entête du message on peut y voir ceci : La méthode BYE est envoyé depuis le terminal AASTRA vers le PROXY qui lui-même informera l interlocuteur de la session et y mettra un terme. Le client QUI N A PAS fait la demande de fin de session va envoyer, via le protocole RTCP (Real-time Transport Control Protocol), un rapport expéditeur (SENDER REPORT) qui présente des statistiques de transmission et de réception pour tous les paquets RTP envoyés pendant l'intervalle de communication. Suit une requête «200 OK» pour nous dire que tout c est bien passé. - L image suivante nous montre que le protocole de transport mit en jeu est l UDP, il fonctionne sans négociation et permet la transmission de données de manière très simple entre deux entités, chacune étant définie par une adresse IP et un numéro de port. - Notre protocole SIP n est pas en reste puisque lors de cette communication, il s est passé plusieurs choses On peut constater 5 trames SIP, «INVITE» «180 Ringing» «200 OK» «ACK» «BYE» & «200 OK», passons les en revue :

5 SIP/2.0 INVITE Méthode utilisée pour établir des sessions de communication entre agents. SIP/ Ringing [Sonnerie] Le client qui a reçu la requête INVITE présente l'appel à l'utilisateur. Cette réponse peut être utilisée pour transmettre une tonalité de sonnerie distante lorsqu'elle comprend une description de session. SIP/ OK La réponse 200 OK confirme que le traitement de la requête est effectué avec succès. Les informations accompagnant la réponse dépendent de la méthode utilisée pour la requête. SIP/2.0 ACK Méthode servant à accuser la réception d'autres requêtes. SIP/2.0BYE Fin de session de communication SIP/ OK Réponse positive du receveur de la requête DIAGRAMME TEMPOREL SIP

6 Les champs d'entête suivants se retrouvent dans toutes les requêtes SIP : From To Call-ID CSeq Via Max-Forwards Content-Type Content-Length Voyons leur rôle : FROM Il contient un nom entre guillemets qui rappelle le numéro (téléphone) ainsi que l'adresse ip de l'émetteur de la requête. TO Il contient lui aussi les mêmes informations que le FROM mais du destinataire CALL-ID Le Call-ID est un identifiant unique généré pour toute nouvelle requête. Il permet de mettre en correspondance les requêtes et les réponses. CSeq Indique un numéro de séquence et la méthode utilisé (INVITE-ACK-CANCEL-BYE, etc ) VIA Le champ Via sert à retracer la route suivie par une requête SIP au travers des serveurs SIP successifs. A chaque passage par un nouveau serveur, un nouveau champ est ajouté à la liste de champs Via déjà présente dans le message. Une fois la requête arrivée à destination, la réponse suivra chaque serveur SIP exactement en sens inverse.

7 MAX-FORWARDS Limite le nombre de serveurs SIP qui peuvent être traversés jusqu'à destination (nombre de saut). Chaque serveur recevant une requête devra décrémenter la valeur du champ Max-Forwards. Si un serveur reçoit une requête avec un champ Max-Forwards égal à 0, il renvoie une réponse 483 Too Many Hops. CONTENT-TYPE Décrit le type d'information contenu dans le corps du message. CONTENT-LENGH Indique le nombre d'octets dans le corps du message. Le codec utilisé (PLAYLOAD TYPE) est G.711 PCMA (8) et ça dans les deux sens La vitesse de l UDP permet environ un échange de 100 trames RTP par seconde! La QoS, impact d une vitesse de liaison (serial) intersites. Dans notre schéma, notre communication entre les deux sites passe par un lien «serial» entre nos deux routeurs. Par défaut, sur un équipement CISCO, le «clock rate» ou la vitesse de l horloge est paramétrée sur Mais c est quoi au juste et comment ça fonctionne? On utilisera un câblage ayant une connexion DCE et DTE de part et d'autre. Le routeur DCE donnera la fréquence de cette horloge. C est un signal électrique oscillant qui va rythmer les actions. Ici pour la VOIP et pour toutes les datas d ailleurs, plus la fréquence est élevée plus le circuit sera rapide et ainsi on devrait normalement avoir moins de pertes de données lors d une communication. La gestion des files d attentes se fera en mode FIFO (First In, First Out) qu on activera avec cette commande sur les ports SERIAL. Par défaut ce mode est activé sur toutes les autres interfaces sur les routeurs CISCO ; «no fair-queue» ;

8 Le principe du FIFO est la conservation de l'ordre d'entrée lors de la sortie. L'illustration pourrait en être un tube dans lequel les pièces sortent séquentiellement dans le même ordre qu'elles y sont entrées. Premier arrivé, premier sorti Pour tester notre communication en termes de performances et d audibilité, nous pouvons réduire notre fréquence d horloge sur le port SERIAL DCE. La commande «clock rate (valeur)» sur l interface du SERIAL permet cette modification. Il y a bien sur un seuil à ne pas atteindre si on veut une bonne transmission, voici nos tests réalisés en laboratoire : VITESSE DE L HORLOGE EFFETS OBTENUS 1200 AUCUN SONS GROS DÉCALAGE DANS LA TRANSMISSION ÉCHO DANS LES DEUX SENS FAIBLE ÉCHO - MINIMUM REQUIS Étude des débits de connexion L utilitaire IpTraffic situé des deux côtés de notre «lab» va nous permettre de «mesurer» les débits de connexion Coté générateur : 1.47 Mb/s Coté absorbeur 944 Kb/s Mise en place de la QoS Voici les étapes à suivre : 1) Configuration du lien SERIAL 0/3/0 - Vitesse de l horloge physique (câble DCE): «clock rate » - Lecture de la valeur pour calculer la QoS : «Bandwidth 250» - Bandwidth 250 2) Reconnaitre le flux à privilégier - class-map match-any cla_voice - match protocol rtp - exit 3) Définir la politique à suivre pour le flux - policy-map pole_reseau - class cla_voise - bandwidth percent 70 4) Appliquer la politique sur l interface SERIAL 0/3/0 - service-policy output pole_reseau

9 Lors d une nouvelle capture de débit entre une communication VOIP, la QoS écrase les données autres que la voix : Du coté de RENNES, sur nos images du dessus, on peut constater une baisse significative du débit (TROUGHPUT) de 236Kb/s à 156Kb/s. Nous n avons cependant pas remarqué de latence ou gigue (fluctuation de signal). On peut aussi paramétrer une QoS en fonction des protocoles et avec un traitement spécifique de la voix, pour cela il faut créer plusieurs classes et les intégrer dans une politique. Exemple : On va configurer 4 flux selon ces paramètres : FLUX 1 : 20% pour le protocole RTP FLUX 2 : 5% de la bande passante résiduelle, protocole pop3 (port 110) FLUX 3 : 20% de la bande passante résiduelle, protocole SUNRPC (port 111) FLUX 4 : 50% de la bande passante résiduelle, tous les autres protocoles On va configurer une «access-list» (ACL) sur un des routeurs (Lannion) qui servira à filtrer le trafic. Lannion(config)#access-list 101 permit udp any gt 1024 any Explication: Création d une liste d accès étendue ACCESS-LIST, avec le chiffre 101 (étendue de 100 à 199), en dessous de 1 à 99 c est pour une liste standard. La différence entre liste d accès standard et étendue est que la standard va seulement examiner l adresse IP source alors que l étendue pourra examiner les adresses IP et les ports aussi bien source que destination. De plus cette ACL étendue examinera tous les types de protocoles (IP, ICMP, TCP, UDP). PERMIT signifie «certain paquets à transmettre (Specify To Forward)», ici nous choisissons le protocole UDP. ANY va cibler tout hôte source, GT pour les ports supérieur à 1024 et enfin ANY pour tout hôte de destination. Notre access-list prête on va maintenant configurer les classes : Lannion(config)#class-map match-any cla_rtp Lannion(config-cmap)#match access-group 101 Lannion(config-cmap)#exit Lannion(config)#class-map match-any cla_110 Lannion(config-cmap)#match access-group 101 Lannion(config-cmap)#exit

10 Lannion(config)#class-map match-any cla_111 Lannion(config-cmap)#match access-group 101 Lannion(config-cmap)#exit On définit maintenant notre politique et on attribue les priorités de flux à nos classes : Lannion(config)#policy-map pole_flux Lannion(config-pmap)#class cla_rtp Lannion(config-pmap-c)#priority percent 20 Lannion(config-pmap-c)#exit Lannion(config-pmap)#class cla_110 Lannion(config-pmap-c)#bandwidth remaining percent 5 Lannion(config-pmap-c)#exit Lannion(config-pmap)#class cla_111 Lannion(config-pmap-c)#bandwidth remaining percent 20 Lannion(config-pmap-c)#exit Priority signifie que quel que soit le paquet qui arrive, celui qui a la priority passe devant. Bandwidth remaining veut dire «reste de la bande passante». On finit par appliquer la QoS sur l interface de notre routeur : Lannion(config)#int serial 0/3/0 Lannion(config-if)# service-policy output pole_flux Lannion(config-if)#exit Il faut réaliser cette manipulation sur les deux routeurs, dans le cas contraire, seul les paquets arrivant sur le routeur bénéficiant de la QoS seront traités. Lors de nos tests de débit maximal avec la QoS, on a mesuré 7,5 Mb/s de débit pour tous les flux (2,3,4)