tp de voix sur ip avec sip et rtp · tp de voix sur ip avec sip et rtp 3. protocoles mis en œuvre...

2008

UFR Ingénieurs 2000 Fabien Bidet Vivien Boistuaud Mary Douis Florence Fraux Julien Herr

TP DE VOIX SUR IP AVEC SIP ET RTP

Ce document a été réalisé par F. Bidet, V. Boistuaud, M. Douis, F. Fraux et J. Herr dans le cadre des travaux pratiques de Voix sur IP coordonnés par Damien Boutoille, au sein de l’UFR Ingénieurs 2000 de l’Université de Marne-la-vallée.

TP de Voix sur IP avec SIP et RTP

Table des matières

Introduction .......................................................................................................................................................................... 4

1. Pré-requis ..................................................................................................................................................................... 5

1. Matériel utilisé ....................................................................................................................................................... 5

2. Logiciels utilisés ..................................................................................................................................................... 5

3. Protocoles mis en œuvre ................................................................................................................................... 6

1. Session Initiation Protocol (SIP – RFC 3261 et 3265) ........................................................................... 6

2. Real-time Transport Protocol (RTP) ........................................................................................................... 7

2. Appel simple en VoIP ............................................................................................................................................... 8

1. Communication RTP directe (sans proxy) .................................................................................................... 8

1. Configuration du client SIP sous Windows ............................................................................................. 9

2. Configuration du client SIP sous Linux .................................................................................................... 9

3. Configuration de SIP Express Routeur (SER) ....................................................................................... 11

4. Résultats de l’expérimentation ................................................................................................................ 11

5. Inconvénient de l’expérimentation ........................................................................................................ 12

2. Utilisation d’un proxy SIP ................................................................................................................................ 13

1. Modification de la configuration des clients ....................................................................................... 13

2. Modification de la configuration de SER .............................................................................................. 13

3. Résultats de l’expérimentation ................................................................................................................ 14

4. Inconvénients de l’expérimentation ...................................................................................................... 14

3. Communication VoIP inter-domaines ............................................................................................................ 16

1. Quelques explications sur la configuration DNS pour SIP .................................................................. 17

2. Configuration DNS adéquate pour l’entreprise A .................................................................................. 20

3. Configuration DNS adéquate pour l’entreprise B .................................................................................. 21

4. Résultats de l’expérimentation ..................................................................................................................... 22

4. Choix des coders-decoders pour les communications ............................................................................. 24

1. Identification du type de service (TOS) utilisé par RTP......................................................................... 24

2. Etude des débits optimaux sur différents codecs .................................................................................. 24

3. Simulation de pertes pour un paquet G.711 loi A ................................................................................. 28

4. Simulation de pertes pour un paquet GSM 06.10 .................................................................................. 29

5. Simulation de pertes pour un paquet G.726 ........................................................................................... 29

6. Simulation de pertes pour un paquet G.721 ........................................................................................... 30

7. Récapitulatif sur la qualité des codecs usuels en VoIP ......................................................................... 31

Fabien Bidet – Vivien Boistuaud – Mary Douis – Julien Herr – Florence Fraux 2Ingénieurs 2000 – IR3 – 2007-2008


5. Ajout de service à SER ........................................................................................................................................... 32

1. Par envoi d’une URI de redirection .............................................................................................................. 32

2. Par branchage interne vers le nouveau correspondant ...................................................................... 35

Conclusion .......................................................................................................................................................................... 37



Introduction

Ce rapport présente le TP de VoIP réalisé par Fabien Bidet, Vivien Boistuaud, Mary

Douis, Florence Fraux et Julien Herr dans le cadre de leurs enseignements en VoIP

dispensés par Damien Boutoille.

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, le protocole H323 n’ayant été présenté que succinctement.

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 SIP 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.

Dans un troisième temps, il présente les procédés de communication inter-

domaines. Ensuite, sont présentés les différents types de codecs, leur qualité à

l’usage et leur résistance aux pertes. Enfin, ce rapport présente l’ajout de

fonctionnalités avancées à SER, proxy SIP, de sorte que nous puissions simuler le

renvoi d’appel vers un standard d’entreprise.

Bien que toutes les manipulations n’aient pas pu être réalisées durant le TP, ce

rapport s’efforce de présenter les manipulations qui auraient dû y avoir été réalisées,

et qui ont été refaites en dehors des heures prévues à cet effet.



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. Matériel utilisé

Le TP a été réalisé sur des PC ayant comme système d’exploitation Debian Linux

pour les machines ayant le rôle de serveur. Les machines clientes étaient basées sur

un système d’exploitation Windows Vista, les cartes sons fournis ne fonctionnant

pas sous Linux.

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é.

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 proxy SIP du nom de

SIP Express Router (SER) d’IPTel (http://www.iptel.org/downloads) pour la partie

serveur SIP. Sa version libre est disponible à l’adresse suivante :

http://www.openser.org/.

Pour la partie cliente, nous devions utiliser le logiciel Ekiga

(http://www.gnomemeeting.org). Cependant, comme précisé précédemment, le

son ne fonctionnait pas sur les machines Linux, c’est pourquoi nous nous sommes

tournés vers des clients Windows. Malgré de nombreux tests, aucun client SIP pour

Windows n’a pu répondre totalement à nos besoins mais nous avons cependant

choisi d’utiliser le client propriétaire WengoPhone (http://www.wengophone.fr)

pour sa simplicité d’utilisation.

Nous avons également utilisé les outils de manipulations de trames d’iptables et

d’iproute2, ainsi que l’analyseur de trames Wireshark (http://www.wireshark.org).


http://www.iptel.org/downloads

http://www.openser.org/

http://www.gnomemeeting.org/

http://www.wengophone.fr/

http://www.wireshark.org/


3. Protocoles mis en œuvre

1. 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:

• 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

Fabien Bidet – Vivien Boistuaud – Mary Douis – Julien Herr – Florence Fraux 6

Ingénieurs 2000 – IR3 – 2007-2008


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.

2. 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.



2. Appel simple en VoIP

Dans la première étape du TP, nous avons mis en œuvre deux appels simples en

VoIP entre deux clients d’un même réseau, enregistré sur le même serveur SIP.

Le premier appel simple est effectué via une connexion directe entre les clients. Elle

ne peut fonctionner au travers d’un NAT non configuré mais permet d’aborder

simplement l’utilisation d’un serveur SIP. La seconde configuration quand à elle,

montre l’utilisation du serveur SIP utilisé également comme proxy SIP, ce qui permet

de centraliser les communications et de pouvoir, éventuellement, changer de

medium d’accès durant le proxying (comme un passage VoIP vers RTC).

1. Communication RTP directe (sans proxy)

Afin de tester un appel simple en VoIP entre deux clients, nous avons mis en place la

maquette décrite par la figure ci-après

Le mode opératoire de cette expérimentation est très simple. Les deux clients

s’enregistrent au serveur. L’un des clients tente d’appeler le second. Le serveur met

en relation les deux clients en utilisant SIP et la communication peut enfin

commencer en utilisant le protocole RTP pour communiquer directement entre les

deux clients SIP.


Figure 1 - Communication simple sans proxy SIP

SIP Phone

SIP Phone

SIP over UDP

RTP

SIP Server

SIP over UDP

Ingénieurs 2000 – IR3 – 2007-2008


1. Configuration du client SIP sous Windows

Figure 2 - Configuration WengoPhone

WengoPhone permet de configurer simplement un compte SIP. Il suffit, comme

indiqué sur la figure ci-avant de saisir le nom d’utilisateur, son mot de passe ainsi

que le domaine SIP auquel il veut se connecter.

Dans notre cas, nous choisissons comme identifiant « kevin » et comme domaine,

l’adresse IP de notre serveur SIP (192.17.9.4). Nous n’avons pas de mot passe à

saisir, notre serveur n’en demandant pas. En utilisation réelle en entreprise, il est

conseillé de créer les comptes SIP nécessaires pour chaque utilisateur du système de

VoIP.

2. Configuration du client SIP sous Linux

La configuration du client Linux, Ekiga, que nous avons utilisé, est sensiblement la

même que pour le client WengoPhone décrite précédemment. Toutefois, Ekiga

propose l’utilisation de plusieurs codecs audio utilisables pour les communications

RTP, et il est possible de définir ceux que l’on souhaite pouvoir utiliser et leur ordre

de priorité.



Figure 3 - Configuration Ekiga

Comme nom de compte, l’utilisateur peut indiquer un alias de son choix, qui lui

permette d’identifier rapidement son compte SIP. Le champs « Registar »

correspond en fait à l’adresse du serveur SIP auprès duquel Ekiga doit s’enregistrer.

Enfin, le nom d’utilisateur et le mot de passe sont dépendants des conditions

d’accès aux services proposés par le serveur SIP. Dans notre cas, aucun mot de passe

n’est nécessaire et le nom d’utilisateur est libre.

Figure 4 - Configuration Codec audio Ekiga

Le choix des codecs est un élément phare de Ekiga, qui va nous permettre dans la

suite de ce rapport de tester plusieurs algorithmes de compression audio et ainsi,

d’évaluer leur qualité.



3. Configuration de SIP Express Routeur (SER)

Le logiciel SIP Express Router possède une configuration de base permettant de

monter rapidement un proxy SIP pour faire communiquer des machines sans

configuration particulière. Cependant, il est d’affiner paramètres en modifiant le

fichier /etc/openser/openser.cfg qui contient l’ensemble des données de

paramétrage.

4. Résultats de l’expérimentation

Figure 5 - Capture protocole et port

• Quel est le port utilisé pour SIP

SIP utilise le port 5060, port attribué par l’organisme IANA. On peut vérifier

l’information sur le site web de l’IANA (http://www.iana.org/assignments/port-

numbers) :

sip 5060/tcp SIP sip 5060/udp SIP sip-tls 5061/tcp SIP-TLS sip-tls 5061/udp SIP-TLS

La capture ci-avant permet également de confirmer le port utilisé pour SIP.

• SIP utilise-t-il TCP ou UDP

Comme nous pouvons le voir dans la capture ci-avant, le protocole utilisé pour

transporter SIP est l’UDP.


Ingénieurs 2000 – IR3 – 2007-2008

http://www.iana.org/assignments/port-numbers

http://www.iana.org/assignments/port-numbers


• Dans quelle condition SIP utilise-t-il TCP

L’utilisation de TCP dépend du MTU utilisé sur le réseau qui sert de support aux

communications VoIP. La RFC 3261 décrit le protocole SIP et affirme que si la taille

du MTU est trop faible, il ne serait pas possible de transporter un paquet RealTime

Transport Protocol (RTP) dans un datagramme UDP. Or UDP ne gère pas la

fragmentation des données, il est convient donc d’utiliser un protocole de transport

qui contrôle les congestions, comme TCP.

De plus, si on souhaite que la communication soit sécurisée par TLS ou SSL, il est

nécessaire d’utiliser le protocole de transport TCP car aucun équivalent n’existe pour

UDP. Notre serveur, OpenSER supporte le TLS à condition que OpenSSL soit installé

et que son support ai été activé lors de la compilation.

5. Inconvénient de l’expérimentation

La structure même de l’architecture proposée empêche deux clients qui ne peuvent

pas s’atteindre directement (par exemple, si l’un se trouve derrière un NAT) de

communiquer ensemble. Aussi, cette architecture est adéquate pour des clients

ayant une adresse IP publique ou se trouvant sur le même réseau routable (par

exemple sur un LAN) mais est inadéquate au vue des méthodes courante utilisées

actuellement en IPv4 (comme le NAT).



2. Utilisation d’un proxy SIP

Afin de résoudre le problème de routage des communications RTP, on peut utiliser

OpenSER (ou tout serveur SIP) en tant que proxy SIP. Le serveur est alors

responsable de relayer les paquets RTP entre les deux clients, levant ainsi la barrière

imposée par le NAT ou le changement de medium (par exemple si on doit passer

par une communication RTC pour joindre le destinataire).

Nous allons donc mettre en place un proxy SIP en plus de notre serveur SIP, de sorte

à ce que toutes les communications soient centralisées au niveau du proxy.

1. Modification de la configuration des clients

Figure 6 - Mise en place d'un proxy SIP

Aucune modification de la configuration n’est nécessaire au niveau du client, dans la

mesure où c’est le serveur qui, lui-même, va choisir de prendre en charge le

proxying des communications. Le serveur va lui-même substituer, lors de l’envoi des

paquets de négociation RTP, une adresse et un numéro de port qu’il affecte à la

connexion proxy plutôt que l’adresse IP réelle du client.

L’avantage est que ceci est transparent pour le client, même lors de l’utilisation d’un

NAT. Pour le serveur en revanche, ceci peut être la cause de congestions réseaux si

les liens de communication ne sont pas correctement dimensionnés par rapport au

nombre de communications qui sont susceptibles de transiter par lui.

2. Modification de la configuration de SER

Au niveau du server, on ajoute dans le fichier de configuration de OpenSER

(/etc/openser/openser.cfg) la ligne suivante :



loadmodule "/usr/lib/ser/modules/tm.so"

Celle-ci suffit à activer le proxy SIP, qui relaie alors les communications.


Le résultat de nos expérimentations nous ont permis de répondre aux questions

suivantes :

• Expliquer ce qu’est un proxy stateless

Un proxy stateless est un proxy qui ne garde pas de mémoire des opérations qui ont

été effectuées auparavant. De ce fait, il traite chaque opération indépendamment

des autres. Il se contente de faire les actions minimales à chaque requête et ne fait

donc aucun contrôle et aucun enregistrement d’appel. A l’opposé, un proxy statefull

assure un contrôle des requêtes et effectue un suivi des appels ou des transactions.

• Quelle est la ligne de configuration qui fait que notre proxy est stateful

OpenSER fonctionne avec des modules. Dans le fichier de configuration, on

remarque la présence de la ligne

loadmodule "/usr/lib/ser/modules/tm.so"

Le module TM est associé à la gestion d’états dans le proxy SIP, soit à l’aspect

stateful.

• Quel est l’intérêt d’avoir un proxy stateful (rapidité de renvoi des paquets…)

Le proxy stateful permet de garder une trace des informations échangées et

notamment des appels passés et de la route à emprunter pour le relai des

communications vers un client ou un autre proxy SIP.

SIP permet également l’utilisation de la messagerie instantanée, la notion de session

est donc très présente pour limiter la charge de travail et le débit consacré aux

communications de ce type. Comme nous l’avons évoqué auparavant, un proxy

stateless ne gère pas les états des clients, il nous faut donc utiliser un proxy stateful.

4. Inconvénients de l’expérimentation

Le gros inconvénient de cette expérimentation, est que les clients du réseau

peuvent se connecter au serveur SIP mais il n’est pas possible à des clients externes

au réseau (internet par exemple) de joindre notre serveur, excepté si le client Fabien Bidet – Vivien Boistuaud – Mary Douis – Julien Herr – Florence Fraux 14

Ingénieurs 2000 – IR3 – 2007-2008


connaît l’adresse IP et le port exacts de notre serveur SIP, et que les NAT éventuels

sont configurés correctement.

C’est pour cela que, dans la section suivante, nous décrivons le mode opératoire

nécessaire à la mise en place d’une communication inter-domaine avec découverte

automatique du serveur SIP par l’intermédiaire d’entrées DNS.



3. Communication VoIP inter-domaines

Dans cette partie, lors du TP, nous avons mis en place une configuration permettant

de passer des appels SIP depuis un proxy vers un client attaché à un autre serveur

proxy SIP. Voici l’architecture type de la solution à mettre en place :

Nous décrirons donc dans cette partie comment le DNS a été paramétré, de manière

à ce que le proxy SIP de notre domaine puisse trouver le proxy SIP du domaine à

contacter. Nous vérifierons ensuite que l’on peut faire des communications inter-

domaines à l’aide de cette configuration.

SIP utilise des entrées DNS spécifiques afin de permettre à un client de convertir une

SIP URI en une adresse IP, ainsi que le port et le protocole de transfert du hop

suivant à contacter. SIP utilise aussi DNS dans le cas où l’appelant n’a pas réussi à

contacter le destinataire, une réponse de serveur est alors envoyée à un client

backup.

Voici un exemple simple de communication SIP entre deux domaines distincts, sur

la page suivante.


Internet /WAN / MAN

SIP Phone

SIP Phone

SIP Serverand proxy

SIP over UDP

SIP over UDP

SIP Serverand proxy

SIP over UDP

SIP over UDP

SIP Client

PDA Phonewith SIP Client

Name Server

NS Requests forFinding SIP server address

Name Server

Figure 7 - Communication SIP inter-domaines avec résolution DNS

Ingénieurs 2000 – IR3 – 2007-2008


Le SIP client 1 (sip:[email protected]) souhaite appeler le SIP client 2

(sip:[email protected]), pour cela le premier SIP client 1 s’enregistre

d’abord auprès du proxy 1, qui est le serveur SIP local de l’entreprise A.

Le SIP client 1 envoi alors une demande d’appel destiné au SIP client 2, au proxy 1.

Ce dernier cherche alors dans les entrées DNS de l’entreprise B les informations sur

le serveur SIP correspondant, et forwarde alors la requête au proxy 2.

Le proxy 2 forwarde à son tour l’appel au SIP Client 2. Le proxy 1 a besoin de

déterminer un serveur SIP pour le Domaine B. C’est dans ce but que proxy 1 fait

appel aux procédures DNS.

1. Quelques explications sur la configuration DNS pour SIP

Afin de joindre facilement un correspondant connecté à un proxy SIP donnée

depuis un autre proxy SIP, il a fallut inventer un moyen de répertorier publiquement

les informations concernant la configuration SIP d’un domaine.

Plutôt que de mettre au point un nouveau protocole (comme UDDI pour les

WebServices SOAP), les concepteurs de SIP ont définit dans la RFC 3263 un moyen

de préciser dans les serveurs de noms de domaine (protocole DNS) les informations

sur la configuration SIP d’un domaine.

Pour cela, les inventeurs de SIP ont défini deux types d’entrées déjà existantes en

DNS pour permettre de présenter aux clients SIP et proxys SIP :

• Les protocoles supportés, et les serveurs et ports de service correspondants,

• Les préférences d’utilisation des différents modes de connexion SIP (UDP,

TCP, TCP+TLS…) ;



Ainsi, dans un premier temps, il est nécessaire de définir des entrées SRV (définition

de service) dans le DNS pour préciser les services SIP proposés en fonction du

protocole de transport qu’ils gèrent.

Les entrées SRV pour SIP sont de la forme :

_sip._transport IN SRV priority importance port servername

La signification des différents paramètres de ce type d’entrée est la suivante :

• _transport vaut soit :

o _udp pour la déclaration d’un serveur SIP exploitant UDP ;

o _tcp pour la déclaration d’un serveur SIP exploitant TCP ;

o _tls pour la déclaration d’un serveur SIP exploitant TCP+TLS ;

• IN indique qu’il s’agit d’une entrée de classe INET (IP), ce qui est le cas de

presque toutes les entrées DNS ;

• SRV indique qu’il s’agit d’une entrée de définition de service ;

• priority est un nombre compris entre 0 et la taille maximale d’un

entier non signé de 32 bits, et qui indique la priorité de l’entrée. Plus le

nombre est proche de 0, plus l’entrée est prioritaire. Les entrées

prioritaires doivent être utilisées en priorité par rapport à celles qui ont

une priorité moins importante.

• importance est un nombre compris entre 0 et la taille maximale d’un

entier non signé de 32 bits, et qui indique l’importance d’un serveur par

rapport à un autre en cas de priorité égale. Dans ce cas, le nombre de

requêtes envoyées à un serveur par rapport à un autre de même

importance doit être un rapport de proportionnalité de leurs

importances. Un serveur d’importance 30 doit recevoir 3 requêtes pour 1

requête envoyée à un serveur d’importance 10.

• Le nombre suivant (port) désigne le port IP sur lequel le service est

joignable, ceci dépend de s’il d’agit d’une entrée UDP ou d’une entrée

TCP. Ainsi, la valeur de ce champs doit être comprise entre 1 et 65536,



avec pour habitude d’utiliser le port 5060 pour TCP et UDP, et 5061

comme port pour les communications SIP sur TCP+TLS.

• Enfin, la dernière information de la ligne est le nom de domaine

pleinement qualifié (terminé par un point) ou partiellement qualifié

(auquel le daemon DNS ajoutera les informations du domaine parent),

Par exemple, pour définir l’existence d’un serveur SIP utilisant UDP sur le port 5060,

de priorité 0 et d’importance 10, pour le domaine mycompany.com, ayant comme

serveur SIP un serveur ayant une entrée DNS portant le nom sip-

proxy.mycompany.com :

_sip._udp IN SRV 0 10 5060 sip-proxy sip-proxy IN A 72.0.0.2

Comme le montrent les informations ci-dessus, on peut ainsi définir les

configurations exactes correspondant aux besoins des clients et proxy SIP

souhaitant communiquer avec notre domaine.

Cependant, un deuxième type d’entrée a été défini dans la RFC 3263 afin de laisser

la possibilité aux administrateurs systèmes de définir les préférences d’utilisation en

matière de choix du protocole de transport utilisé pour SIP.

Ainsi, la norme définit qu’il faut utiliser des entrées DNS de type NAPTR pour définir

ces informations de préférence. Ces entrées sont de la forme :

domain-name IN NAPTR order preference flags service regexp target

Le format des champs à remplacer dans la ligne précédente sont les suivants :

• domain-name représente un nom de domaine pleinement qualifié (FQN) ou

partiellement qualifié. Si votre serveur DNS est bind, vous pouvez y indiquer

@ si le fichier de configuration correspond à la configuration du domaine

pour lequel vous souhaitez déclarer vos préférences SIP.

• IN et NAPTR ont la même signification que dans l’exemple précédent, c'est-

à-dire qu’il s’agit d’une information de classe Internet (IN) et qu’il s’agit

d’une entrée de type pointeur d’information.

• Le champ order, qui est un nombre compris entre 0 et la valeur maximale

d’un entier non signé de 32 bits. Il s’agit d’un indice de priorité : si le client



trouve plusieurs réponses correspondant à ses besoins, il doit

obligatoirement prendre celle qui a l’ordre le plus bas.

• Le champ preference agit de la même façon que le champ order, mais

indique une contrainte permissive : le client est libre de choisir la réponse

qui lui convient le mieux, sachant que le serveur indique son propre ordre

de préférence via le champ preference.

• Le champ flags précise des lettres décrivant l’entrée. Un "s" spécifie que

l’entrée est complète et suffisante au client pour traiter les demandes.

• Le champ service indique le type de service qui constitue l’entrée.

"SIP+D2U" signifie SIP over UDP, "SIP+D2T" signifie SIP over TCP,

"SIPS+D2T" signifie SIP over TLS over TCP; il n’y a pas d’équivalent pour

UDP.

• Le champ regexp désigne une expression rationnelle qui sert à substituer

des informations " " désigne une expression rationnelle (regexp) qui permet

de substituer des informations dans la valeur du champ domain-name. en

général, il est déconseillé de l’utiliser.

• Enfin, la dernière entrée indique le nom de l’entrée DNS fournissant le

service SIP correspondant (par exemple un FQDN ou un nom partiellement

qualifié, du type _sip._udp pour UDP, _sip._tcp pour TCP et ainsi de suite…).

2. Configuration DNS adéquate pour l’entreprise A

Pour communiquer avec une autre entreprise, l’entreprise A doit tout d’abord

déclarer sa configuration SIP de façon publique. Cette dernière est déclarée dans le

DNS, par défaut, comme décrit précédemment. Les proxys SIP utilisent le nom de

domaine qui est indiqué dans la SIP URI du destinataire ou de l’expéditeur pour

effectuer les résolutions DNS.

Voici un exemple de configuration DNS SIP pour l’entreprise A, sur la page suivante.



_sip._udp.company-a.local. IN SRV 10 10 5060 sip-proxy1.company-a.local. ; Si on souhaite aussi proposer une connexion TCP sur les deux serveurs _sip._tcp.company-a.local. IN SRV 10 10 5060 sip-proxy1.company-a.local. ; Si nous avions activé le support TLS via OpenSSL sur OpenSER, ; nous pourrions ajouter : ;_sip._tls.company-a.local. IN SRV 10 10 5061 sip-proxy1.company-a.local. : Nous sommes sur un LAN Ethernet, le MTU devrait donc être suffisant ; pour préférer UDP par rapport à TCP : company-a.local. IN NAPTR 0 0 “s” “SIP+D2U” “” _sip._udp.company-a.local. company-a.local. IN NAPTR 10 0 “s” “SIP+D2T” “” _sip._tcp.company-a.local.

IN signifie Internet, il indique la classe d’entrée. SRV est le type de l’entrée de la

table. 5060 est le port de destination. Le nom_domaine_proxy est un nom complet

relatif à la racine des DNS. Le premier « 10 » indique la priorité de choix du serveur.

Le second « 10 » indique le poids du serveur.

Les serveurs SIP, se chargeant de transférer l’appel, doivent posséder une entrée par

adresse IP dans leur table. Pour notre proxy SIP personnel, nous avons configuré de

la façon suivante :

sip-proxy1.company-a.local. IN A 172.17.0.8

3. Configuration DNS adéquate pour l’entreprise B

La configuration de l’entreprise B est sensiblement similaire, à l’exception du fait

que l’adresse du serveur proxy SIP vers lequel les demandes sont redirigées est

différente et correspond à celle du second proxy SIP mis en place par un autre

groupe de TP.



_sip._udp.company-b.local. IN SRV 10 10 5060 sip-proxy1.company-b.local. _sip._tcp.company-b.local. IN SRV 10 10 5060 sip-proxy1.company-b.local. ; SSL n’est pas active sur l’OpenSER du second groupe ;_sip._tls.company-b.local. IN SRV 10 10 5061 sip-proxy1.company-b.local. ; Pour la preference UDP par rapport à TCP company-b.local. IN NAPTR 0 0 “s” “SIP+D2U” “” _sip._udp.company-b.local. company-b.local. IN NAPTR 10 0 “s” “SIP+D2T” “” _sip._tcp.company-b.local. ; Entrée d’adresse pour le proxy SIP sip-proxy1.company-b.local. IN A 172.17.0.14


Suite aux tests réalisés en TP, nous avons réussi à faire communiquer deux SIP client.

Des traces ethereal ont été relevées. Les Voici :

Celles-ci montrent l’échange de trames réalisé afin de permettre aux deux SIP Client

de communiquer. Voici schématiquement l’échange de ces trames :



Le SIP Client 1 envoie un message « SUBSCRIBE » puis « INVITE » au Proxy. Ce

message « INVITE » correspond au message SETUP du RNIS(Réseau Numérique à

Intégration de Services). Le SIP Client 1 reçoit ensuite un « 100 Trying », en réponse à

son « INVITE ». Le même échange (INVITE + 100 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.



4. Choix des coders-decoders1 pour les communications

Les coders-decoders (codecs) sont utilisés pour compresser (en entrée) et

décompresser (en sortie) les informations utiles d’une session multimédia (voix ou

vidéos). En VoIP, chaque poste client supporte un certain nombre de ces codecs ; il

faut que le codec utilisé soit le même pour tous les participants d’une session

multimédia.

1. Identification du type de service (TOS) utilisé par RTP

Tous les en-têtes IP ont un octet TOS (Type de Service). Intégré au protocole il y a

plusieurs années, cet attribut a récemment été redéfini en tant que domaine DSCP

(DiffServe Code Point). La « Qualité de Service » fait référence à l’ensemble des

paramètres, à la fois pour les transmissions avec (TCP) et sans connexion (IP), qui

définissent la performance, en termes de qualité de la transmission et de

disponibilité du service.

Dans le cas de RTP, la valeur du champ DSCP est de « 0x28 ».

La commande « tc » (Trafic Control) est utilisé pour gérer les paramètres de contrôle

du trafic (contrôle de bande passante). Elle utilise les éléments suivants :

• un choix de gestionnaires de mise en file d'attente par flux réseau, • un choix de règles de classification des paquets avant leur mise en file d'attente, • un choix d'ordonnanceurs pour la mise en forme du trafic sortie d'une interface.

2. Etude des débits optimaux sur différents codecs

Il faut se rappeler que les paquets RTP ne contiennent pas seulement les données

voix, il y a aussi les en-têtes à prendre en compte dans la taille des paquets.

Type d’en-tête de protocole Taille des données (en octets)

20 octets En-tête IPv4

8 octets En-tête UDP

12 octets En-tête RTP

1 Plus couramment on abrège l’expression « coders-decoders » par codec.


Ingénieurs 2000 – IR3 – 2007-2008


Chaque codec utilise une compression différente ce qui correspond à des tailles

d’échantillons différentes.

Taille d’un sample

(en bits)

Fréquence de sampling (échantillonnage)

Codec utilisé

8 8 kHz G.711 a-law (loi A)

GSM-FR (ETSI 06.10

– Full Rate)

13 8kHz

4 8 kHz G.726

4 8kHz G.721

On rappelle que le calcul de la taille totale du paquet s’effectue comme suit :

Taille totale = taille entête L2 + taille entête IP + taille entête UDP + taille entête RTP + taille voice payload

Remarque : dans la suite de ce document, lors des calculs, nous considérons la définition

du kilooctet définie par la norme IEC 60027-2, c'est-à-dire que 1 Ko et 1 Kbit représentent

respectivement 1000 octets et 1000 bits. Dans l’éventualité où nous parlerions de

kilooctet binaire, nous le noterions par l’utilisation des abbréviations Kio et Kibits.

Codec G711 loi A :

Taille voice payload 240 octets

Temps par trame 30 ms

Taille totale du paquet (1 trame) 40 + 240 = 280 octets

(280 * 1000) / 30 =~ 9,333 Ko/s

Soit ~ 74,67 Kbits/s Débit IP (1 trame)

Taille totale du paquet (4 trames)

40 + 4 * 240 = 1000 octets

Débit IP (4 trames) (1000 * 1000) / (4 * 30) =~ 8,333 Ko/s

Soit ~ 66,67 Kbits/s



Codec GSM 06.10 :




(73 * 1000) / 20 = 3,65 Ko/s

Soit 29,2 Kbits/s Débit IP (1 trame)

40 + 4 * 33 = 172 octets Taille totale du paquet (4 trames)

(172 * 1000) / (4 * 20) =~ 2,150 Ko/s

Soit ~ 17,2 Kbits/s

Débit IP (4 trames)

Codec G726 :




(120 * 1000) / 20 = 6 Ko/s

Soit 48 Kbits/s Débit IP (1 trame)


(360 * 1000) / (4 * 20) =~ 4,5 Ko/s

Soit ~ 36 Kbits/s




Codec G721 :




(80 * 1000) / 10 = 8 Ko/s

Soit 64 Kbits/s Débit IP (1 trame)


(200 * 1000) / (4 * 10) =~ 5 Ko/s

Soit ~ 40 Kbits/s


Ces informations ont été obtenues en faisant l’assertion que le codec G.721 était une

version moins évoluée mais prédécesseur de la version 32Kbps du G.726, dont on le

rapproche souvent. Aussi, ces informations sont basées sur le G.726-32. Etant donné le

peu d’informations concernant le codec G.721, il est possible que ces informations soient

erronées.

3. Gain en plaçant 4 trames par paquet au lieu d’une

Ce tableau récapitule le gain en bande passante pour chaque codec, si on place

quatre trames audio par paquet au lieu d’une :

Codec BP pour 1 trame BP pour 4 trames Gain en BP

74,67 Kbits/s 66,67 Kbits/s 10,7% G.711 loi A

29,2 Kbits/s 17,2 Kbits/s 41,1 % GSM 06.10

48 Kbits/s 36 kbits/s 25,0% G.726

64 Kbits/s 40 kbits/s 37,5% G.721



On constate que le codec pour lequel il est le plus intéressant de grouper les trames

dans un même paquet est le codec GSM qui, de plus, est le moins coûteux en bande

passante.

4. Simulation de pertes pour un paquet G.711 loi A

Premier à avoir été utilisé dans la VoIP, ce codex reste intéressant pour des raisons

de compatibilité entre marques d'équipements différentes. Il utilise le principe de

codage du signal selon une échelle logarithmique.

C’est le codec utilisé par le client KPhone, par exemple.

Pour simuler un taux de perte à 10%, on doit mettre en place un filtre :

tc qdisc add dev eth0 parent 1 :10 handle 10 : sfq

Le rate, ou bitrate, est le taux de transfert de données exprimé en bits par seconde.

Ici, avec un débit IP de 74,67 kbits/sec, on obtient le calcul suivant :

rate = 74,67 – 10*74,67/100 = 67,2 kbits/sec

Le burst correspond à la taille du conteneur de jetons. Il est calculé en multipliant le

taux de perte (différence entre le débit théorique et le débit avec pertes) avec le

temps utilisé pour le passage des trames.

10*74,67/100 = 7,47 kbits/sec = 0,93 koctets/sec temps par trame = 30 ms 10% trames bloquées soit 9 trames sur 10 qui passent = 9*30 = 270 ms taille totale = 0,93*270 /1000 = 251 octets



Le rate, ou bitrate, est le taux de transfert de données exprimé en bits par seconde.

Ici, avec un débit IP de 74,67 kbits/sec, on obtient le calcul suivant :

rate = 74,67 – 20*74,67/100 = 59,7 kbits/sec

Le burst correspond à la taille du conteneur de jetons. Il est calculé en multipliant le

taux de perte (différence entre le débit théorique et le débit avec pertes) avec le

temps utilisé pour le passage des trames.



20*74,67/100 = 14,9 kbits/sec = 1,9 koctets/sec temps par trame = 30 ms 20% trames bloquées soit 8 trames sur 10 qui passent = 8*30 = 240 ms taille totale = 1,9*240 /1000 = 456 octets

5. Simulation de pertes pour un paquet GSM 06.10



On peut alors déterminer les contraintes de débit et de temps nécessaires pour

respecter l’envoi des paquets avec 10% de pertes.

rate = 29,2 – 10*29,2/100 = 26,3 kbits/sec burst = 10*29,2/100 = 2,92 kbits/sec = 0,37 koctets/sec temps par trame = 30 ms 10% trames bloquées soit 9 trames sur 10 qui passent = 9*30 = 270 ms taille totale = 0,37*270 /1000 = 100 octets





rate = 29,2 – 20*29,2/100 = 59,7 kbits/sec burst = 20*29,2/100 = 5,84 kbits/sec = 0,73 koctets/sec temps par trame = 30 ms 20% trames bloquées soit 8 trames sur 10 qui passent = 8*30 = 240 ms taille totale = 0,73*240 /1000 = 175 octets

6. Simulation de pertes pour un paquet G.726







rate = 48 – 10*48/100 = 43,2 kbits/sec burst = 10*48/100 = 4,8 kbits/sec = 0,6 koctets/sec temps par trame = 30 ms 10% trames bloquées soit 9 trames sur 10 qui passent = 9*30 = 270 ms taille totale = 0,6*270 /1000 = 162 octets






7. Simulation de pertes pour un paquet G.721












rate = 64 – 20*64/100 = 51,2 kbits/sec burst = 20*64/100 = 12,8 kbits/sec = 1,6 Ko/sec temps par trame = 10 ms 20% trames bloquées soit 8 trames sur 10 qui passent = 8*10 = 80 ms taille totale = 1,6*80 /1000 = 128 octets

8. Récapitulatif sur la qualité des codecs usuels en VoIP

Pour comparer les codecs, il est possible d’utiliser l’indicateur MOS (Mean Opinion

Score) qui est un outil de mesure de la qualité audio (1 = médiocre, 5 = parfait).

CODECS Qualité MOS

G.711 loi A 4

GSM 06.10 3,5

G.726 3,85

G.721 3,8



5. Ajout de service à SER

La dernière partie de ce TP consistait à ajouter de la logique au Proxy SIP. C’est-à-

dire que nous devions ajouter un renvoi vers un SIP uri par défaut. Celui-ci joue un

rôle de répondeur. Lorsque le destinataire de l’appel est absent l’appelant est

redirigé vers un standard vocal. Deux possibilités s’offraient à nous, renvoyer une

réponse 302 avec la nouvelle uri à l’appelant ou créer une branche vers le nouveau

destinataire.

1. Par envoi d’une URI de redirection

Cette façon de procéder se rapproche de la méthode employée par HTTP, mais cela

ne masque pas la redirection au SIP Client.

Voici un exemple d’échange de trames SIP lorsqu’il se produit un échec :

Pour renvoyer une réponse 302 avec la nouvelle uri à l’appelant un fichier de

configuration doit être modifié. Une fois rectifié, le cheminement de l’appel sera le

même que celui sur le schéma suivant :



Le fichier de configuration à modifier est openser.cfg se trouvant dans le

répertoire /etc/openser.

Dans ce dernier la méthode t_on_failure() informe SER lorsque l’appel à échoué

et que nous souhaitons faire une manipulation spéciale, suite à cet échec. Quand à

la méthode t_relay() elle permet de faire un forward stateful à l’appelant. L’appel

de la méthode t_on_failure() se fera de ce fait avant l’appel de la méthode

t_relay(), de ce fait SER passera le contrôle au bloc de code appelé par la

méthode t_on_failure() et se trouvant à la fin du fichier de configuration.

Voici les morceaux de code du fichier de configuration corrigés et modifiés pour

mettre en place une redirection 302 vers [email protected] :



# Si aucune redirection vers des routes n’existe, ajouter une redirection vers # la route 1 route {

… route(1);

} # Définition de la route 1 appelée précédemment route[1] { # redirige vers une route d’erreur, la failure_route[1] t_on_failure(1); # handler par défaut pour l’envoi d’erreurs au client si le message # n’a pas pu être traité if ( !t_relay() ) { sl_reply_error(); } # Fin de l’exécution du code # Attention, s’il y a d’autres routes appelées après la route 1, alors # elles ne seront pas appelées à cause de cette instruction exit; } failure_route[1] { # On souhaite intercepter les erreurs 408 et 486 if ( t_check_status("408") || t_check_status("486") ) { # On remplace le contact qui était appelé par # sip:[email protected] replace(“Contact.*”, “Contact:sip:[email protected]”); t_reply(“302”, “Moved tototralala”); } }

Une fois que le système tient compte de ces modifications, une uri de redirection

(sip:[email protected]) est donc envoyée lorsqu’un appel échoue, comme

le montre la capture wireshark de la page suivante.

Il faut cependant noter que certains clients SIP, comme WengoPhone, ne suivent

pas du tout les redirections 302 et ne notifient pas l’utilisateur. D’après la norme, le

client est supposé poser la question à l’utilisateur avant de suivre la redirection.



2. Par branchage interne vers le nouveau correspondant

Si cette méthode est employée cela permet de se rapprocher de la téléphonie

classique, la compatibilité est assurée et, contrairement à l’envoi d’une uri de

redirection, cela masque la redirection au client.

Pour créer une branche vers le nouveau destinataire le fichier openser.cfg doit

être à nouveau modifié. Une fois ceci fait le cheminement de l’appel est le suivant :

Comme il s’agit du même fichier de configuration on utilise les mêmes méthodes.

On fait donc appel à t_on_failure() avant t_relay(). Le contenu du bloc

failure_route[1] appelé par t_on_failure(1) change par rapport à la



solution précédente, puisqu’il ne s’agit plus d’un envoie d’uri de redirection, mais

d’un branchage interne vers le nouvel appelant. Cette manipulation sera totalement

transparente pour le SIP Client à l’origine de l’appel.

Voici les modifications apportées au fichier openser.cfg, elles ne concernent que

la route d’erreur 1 que nous avions précédemment définit :

failure_route[1] { # On souhaite intercepter les erreurs 408 et 486 if ( t_check_status("408") || t_check_status("486") ) { # On fait une branche interne pour connecter la communication # à la ligne du contact sip:[email protected] plutôt qu’à # l’utilisateur à qui l’appel était destiné subst_uri('/.*/sip:[email protected]/'); # Notez que la substitution est faite par regexp. # On notifie alors le branchement er on force le relai de la # communication. append_branch(); t_relay(); } }

Comme pour la solution précédente le système ne tiendra compte de ces

modifications qu’une fois le serveur redémarré. Le client n’est plus notifié, dans ce

cas, de la redirection. Ce mode de fonctionnement est plus proche de celui utilisé

dans un PABX pour rediriger un appel vers un standard d’entreprise dans le cas où

l’interlocuteur appelé ne répond pas.



Fabien Bidet – Vivien Boistuaud – Mary Douis – Julien Herr – Florence FrauxIngénieurs 2000 – IR3 – 2007-2008

37

Conclusion

Le protocole SIP, bien que plus récent que le protocole H.323, est en passe de

devenir le protocole standardisé de VoIP le plus utilisé par les opérateurs. Issu du

monde de l’internet (IETF) et non des consortiums de téléphonistes, SIP s’avère plus

évolutif et plus libre que H.323, ce qui lui a valu son adoption générale.

Cependant, comme le montre ce rapport, les technologies de VoIP, même pour les

solutions SIP et RTP, restent variées et pas toujours compatible.

En effet, SIP n’assure une compatibilité que dans une certaine mesure : tous les

SIPPhone (logiciels comme matériels) ne comprennent pas l’ensemble des codes

d’erreurs renvoyés par le serveur (par exemple pour la redirection 302) et ne

supportent pas l’ensemble des codecs audios.

En effet, RTP assure un moyen uniformisé pour transporter des messages en temps

réel (Realtime Transport Protocol) mais ne garanti pas que le format des données

transportées soit uniformisé, bien qu’il prévoit que le choix du codec soit négocié

entre les clients.

En conséquence, de nombreuses technologies de VoIP proposent des

fonctionnalités supplémentaires intermédiaires (comme les informations de

messagerie vocale, …) restent propriétaires et non compatibles entre plusieurs

fabriquant, rendant ainsi difficile la compatibilité. Par conséquent, afin de s’assurer

que la transition RTC vers VoIP se réussisse dans les meilleures conditions possibles,

il est nécessaire que les opérateurs fassent des efforts sur le respect strict des

standards et la normalisation des fonctionnalités à valeur ajoutée.

tp de voix sur ip avec sip et rtp · tp de voix sur ip avec sip et rtp 3. protocoles mis en œuvre...

Documents