UNIVERSITE HENRI POINCARE NANCY I Ecole Supérieure d’Informatique et Applications de Lorraine

Xavier AMEZIANE Sébastien LEVEQUE

Lionel ZEINER

ESIAL Troisième année Année universitaire 2002 – 2003

PPRROOJJEETT RREESSEEAAUUXX VVooiiccee oovveerr IInntteerrnneett PPrroottooccooll

1

SSoommmmaaiirree Introduction 2 1. Idée 3 2.Le but : une réduction des coûts attendus 3 3. La voix 3 4. Difficultés associées à la transmission de la voix sur IP 4 4.1 Comparaison IP - Télécoms 4 4.2 Le transfert de la voix : un chemin semé d’embûches 5 4.2.1 Analyse des délais 5 4.2.2 Analyse des pertes 7 4.2.3 Conclusions 7 5. Principe de fonctionnement 7 6. Les protocoles 8 6.1 Le protocole H.323 8 6.2 Le protocole SIP 9 6.2.1 Les fonctionnalités utilisées par SIP 10 6.2.2 Les composants de SIP 10 6.2.3 Utilisation de SIP 11 6.2.4 Les protocoles utilisés 11 6.2.5 Les messages SIP 12 6.2.6 Exemples de transactions 17 6.2.7 Conclusions 19 6.3 Le protocole MGCP 20 6.3.1 Généralités 20 6.3.2 Fonctionnement de MGCP 21 7. Matériels nécessaires à la mise en place de la VoIP 27 7.1 Introduction 27 7.2 Approche centralisée contre approche distribuée 27 7.3 Exemple de matériel proposé par le constructeur Cisco 28 7.4 Détail des matériels Cisco à utiliser 30 Conclusion 37

2

IInnttrroodduuccttiioonn

Avec plus de 100 millions d'utilisateurs au niveau mondial, Internet représente à

l'évidence un phénomène en forte croissance (exponentielle depuis plusieurs années) dans le domaine des nouveaux moyens de communication.

Bien que l’Internet se développe rapidement, le téléphone reste encore le favori du public en matière de communication. Plus convivial car le contact est presque réel, il reste en plus simple d'utilisation. Pourtant, il fusionne de plus en plus avec le matériel informatique.

Les utilisateurs du téléphone ont depuis toujours été habitués à payer leurs communications en fonction de la distance et de la durée de celles-ci, mais depuis l'émergence et l'extraordinaire développement de l'Internet, les mentalités changent et on s'habitue au principe de réseau informatique et de son accès forfaitaire. On peut ainsi communiquer, par écran interposé, n'importe où dans le monde sans aucune considération financière puisque le prix est toujours celui d'une communication locale. C'est évidemment cet aspect financier qui est à l'origine de la téléphonie sur IP. Car c'est une révolution au niveau des tarifs qui s'annoncent démesurément bas.

3

1. Idée

Voice over IP : voix sur IP. Transport de la voix sur des réseaux de données IP. La voix est numérisée, enfermée dans des paquets de données, puis transmise sur le réseau. Confondue parfois avec la téléphonie sur IP (ToIP : telephony on IP), terme désignant une architecture tout-IP et ses services de téléphonie associés.

L'enjeu de la voix sur IP est de taille : téléphoner en utilisant les réseaux de données traditionnels. À la clé, une convergence voix-données-images autour d'un protocole unique (IP), une réduction des coûts et la centralisation des infrastructures dans un unique réseau. Pour le grand public, la téléphonie sur IP désigne avant tout les logiciels ou les offres permettant de coder la voix sur un réseau IP public. Avec évidemment une qualité et une sécurité minimales. Dans le monde de l'entreprise, qualité de service oblige, la VoIP ne se conçoit aujourd'hui que dans le cadre d'un réseau privé, WAN (Wide Area Network) ou LAN (Local Area Network).

2. Le but : une réduction des coûts attendue

Premier bénéfice attendu de la VoIP : l'allégement des factures téléphoniques intra-entreprises, voire entreprises-fournisseurs-clients dans le cas de réseaux étendus. Imaginons, par exemple, la société Durand disposant de deux sites de production, l'un à Paris, l'autre à Lyon. Pour tout ce qui concerne le transfert de données informatiques, les deux entités sont reliées par une ligne spécialisée. Pour les communications téléphoniques, chacune dispose d'une infrastructure télécoms traditionnelle construite autour d'un PBX (autocommutateur téléphonique interne). Lorsqu'un salarié parisien téléphone à l'un de ses collègues lyonnais, l'appel transite par le PBX avant d'être acheminé jusqu'à Lyon par le réseau téléphonique traditionnel ou RTC (réseau téléphonique commuté). Comment la société Durand peut-elle passer à la VoIP ? En reliant directement, dans un premier temps, ses deux PBX par la ligne spécialisée. Le signal de voix analogique est alors compressé et codé pour être inséré dans des paquets IP, transmis sur le lien, puis décodé et décompressé à l'autre extrémité. Mais l'entreprise Durand peut aller plus loin. Elle peut faire le choix du tout-IP et miser sur la téléphonie sur IP. Elle pourra alors remplacer ses anciens combinés téléphoniques par des terminaux IP (téléphones IP ou PC équipés d'un logiciel de téléphonie). Cet exemple se place dans un contexte de WAN ou de réseau étendu. Reste qu'avec la chute actuelle des tarifs téléphoniques, un changement d'architecture n'est pas toujours facile à justifier. Certains défendent néanmoins que la téléphonie sur IP est déjà rentable au niveau d'un LAN ou réseau local. Ici, le surcoût de la téléphonie classique est à mettre au compte du déplacement fréquent des téléphones (déménagements, aménagements de nouveaux bureaux...) et à la gestion du câblage. Avec la téléphonie sur IP, ce souci disparaît car les terminaux, dotés chacun d'une adresse IP, peuvent être connectés instantanément à n'importe quel endroit du réseau.

3. La voix Le système vocal est complexe et basé sur des ondes sonores de fréquences différentes. Le spectre des fréquences perçues par l’oreille humaine s’étale de 100 Hz à 20 kHz. Cette fourchette est, cependant, à réduire si l’on veut distinguer les fréquences utiles des fréquences audibles. En effet, la quasi-totalité d’un message sonore est compréhensible dans

4

la fourchette 300-3400 Hz. Cette dernière correspond, d’ailleurs, à celle utilisée par le téléphone standard.

Une conversation entre deux personnes respecte deux principes : intelligibilité et interactivité. Couper la parole à quelqu’un ne se fait pas, mais c’est un gage d’interactivité et de dialogue. En terme de transmission numérique, cela se traduit par le terme duplex. Une conversation full duplex assure cette interactivité car chaque locuteur peut parler en même temps, ce qui arrive quand deux personnes parlent de leur propre expérience sans s’écouter... Un mode half duplex induit une conversation unidirectionnelle du style CB (Citizen Band) :

« quel est ton QRZ, à toi ! je viens de Moselle, à toi ! » Cette interactivité implique des notions de délais dans le transport de la voix (avec le

téléphone, par exemple). Les mesures effectuées montrent qu’un temps de transit inférieur à 150 ms garantit un dialogue actif. Jusqu’à 400 ms (limite supérieure) le dialogue reste tout de même assez réactif. Au-delà de cette limite le contradicteur aura l’impression de parler dans le vide.

4. Difficultés associées à la transmission de la voix sur IP Afin de bien percevoir les difficultés associées au transport de la voix sur IP, un comparatif entre la commutation de circuits des télécoms et la commutation de paquets d’IP est nécessaire. Ensuite, une étude des différents délais associés à VoIP permettra de comprendre les facteurs incompressibles négatifs pour la communication.

4.1 Comparaison IP – Télécoms Les deux approches IP et télécoms sont pratiquement opposées. Où IP est simple et débrouillard, les télécoms sont complexes et figés. Le réseau qui est utilisé par les télécoms est le réseau X25. Le tableau suivant établi la comparaison entre ces deux systèmes sur différents points :

5

4.2 Le transfert de la voix : un chemin semé d’embûches

Le tableau précédent fait un état des lieux des différences entre IP et X25. Il est cependant nécessaire d'expliquer comment arrivent ses défauts de transmission. Voici pourquoi cette partie répertorie les trois principales causes des difficultés et des limites associées à VoIP :

• Délai : temps de transmission d'un paquet (doit rester inférieur à 400ms pour respecter les contraintes d'une conversation interactive).

• Gigue : variation de délai (nécessite un buffer de resynchronisation en bout de chemin).

• Perte : disparition de paquets au cours de la communication (fait partie de la transmission IP mais doit être soit réduite, soit inhibée).

Le schéma ci-dessus reprend les difficultés évoquées et permet de comprendre quels sont les effets indésirables impliqués.

4.2.1 Analyse des délais Quantifier le délai de transmission sur le réseau de manière fiable est quasi impossible, car il y a trop d'inconnues : Table de routage, congestion, pannes, files d'attente… Cependant sur le chemin que prendrait une transmission de voix, on peut détailler certains délais inhérents au réseau :

6

Délais de l'émetteur :

• Numérisation et codage : temps mis par une carte son ou une passerelle pour numériser et coder un signal initialement analogique.

• Compression qui se décompose en trois parties : o Délai de trame : contrairement à la numérisation d'un signal qui se fait en

continue, la compression porte sur une certaine longueur de données. Attendre ces informations induit un temps non nul de traitement

o Délai d'encodage : la compression par synthèse s'appuyant sur la prédiction, ce délai est nécessaire à l'encodeur pour savoir, pendant qu'il est en fonctionnement comment évolue le signal.

o Délai de traitement : temps mis par l'algorithme pour compresser une trame. Il dépend du processeur et de l'algorithme utilisé.

• Mise en paquets : intervalle de temps pendant lequel l'application constitue un paquet (création de l'en-tête, remplissage des données).

• Transmission : ce temps dépend de la configuration dans laquelle on se trouve. A savoir soit on est relié par modem soit par accès direct sur un LAN-WAN.

Délais réseau :

• Propagation : sur un réseau filaire, la vitesse de propagation est de 200000 km/s, cela induit un temps de propagation non nul.1111111111111111111111111111111111111 - Commutation et files d'attente : suivant la nature du réseau différents temps peuvent être indexés.

Délais du récepteur (ce sont les mêmes que pour l'émetteur) :

• Réception. • Buffer de gigue : cette mémoire tampon permet de resynchroniser les paquets arrivant

avec des délais variables. Elle sert donc à compenser les décalages et remettre en ordre les paquets.

• Dépaquetisation. • Décompression.

7

• Décodage et conversion numérique analogique. Jusqu'à présent les mesures effectuées avec une solution téléphone à téléphone (via IP), sur un réseau bien géré et surdimensionné (en bande passante), montrent un délai total de 200 ms.

4.2.2 Analyse des pertes La perte d'un paquet occasionne un manque d'information lors de la réception du signal audio. Suivant le nombre de paquets perdus, la qualité sonore en bout de ligne peut s'en ressentir. Dans la philosophie IP, cette perte de paquet fait partie intégrante du concept. En effet les routeurs sont obligés (avec l'algorithme Random Early Detection) de détruire des paquets afin d'anticiper d'éventuelles congestions. Il existe principalement quatre causes de perte de paquet :

• Durée de vie épuisée (TTL = 0). • Retard à la réception supérieur au buffer de gigue. • Destruction par un module congestionné. • Invalidité du paquet due à des défauts de transmission.

4.2.3 Conclusions

Toutes ces contraintes et défauts inhérents à IP sont les fondements des difficultés rencontrées par le concept VoIP.

5. Principe de fonctionnement

Tout projet de VoIP ou de téléphonie sur IP nécessite une transformation du PBX de l'entreprise. Une première solution consiste à y insérer une carte IP faisant office de passerelle entre le réseau téléphonique et le réseau IP. Cette démarche présente l'avantage de préserver l'existant et les postes analogiques. Seconde possibilité : remplacer le PBX par un IPBX, un matériel profilé pour le tout-IP et qui implique un déploiement massif de terminaux IP. Ces deux solutions techniques intègrent différentes fonctions de base, dont une unité de contrôle d'accès (gatekeeper), qui gère l'identification des appels, la traduction du numéro de téléphone en adresse IP, et éventuellement la définition des règles d'appel. Viennent ensuite une passerelle (gateway), chargée de l'interconnexion entre équipements réseaux hétérogènes (téléphone analogique ou numérique, carte RNIS...), et enfin une unité de contrôle (MCU Multipoint Controller Unit) gérant les sessions multicast. Aujourd'hui, l'un des freins de la téléphonie sur IP réside dans l'absence de standards communs à tous les constructeurs. Même s'il constitue souvent une base commune, le protocole de signalisation H.323 (issu d'une recommandation de l'International Telecommunication Union - Telecommunication standardization (ITU-T)) est rarement utilisé tel quel. Plus simple, SIP (proposé par Internet Engineering Task Force (IETF)) est encore peu adopté par les constructeurs de matériels. Enfin, MGCP (Media Gateway Control Protocol), autre standard de l'IETF, peine aussi à s'imposer. Une fois la communication établie, le transport et le contrôle des flux de données sont assurés par deux autres protocoles : RTP (Realtime Transport Protocol) et RTCP (Realtime Transport Control Protocol). Le premier permet de reconstituer la base de temps, de détecter les pertes et d'identifier le contenu des paquets pour leur transmission sécurisée. Le

8

second, RTCP fournit, entre autres, des informations sur la qualité de la session. Lorsque les paquets de voix transitent sur le réseau, les paramètres à maîtriser sont la latence (délai de transmission), la gigue (variation du délai de transmission), la perte des paquets (au-delà de 20 %, le signal n'est plus audible). Pour s'en assurer, les différents équipements du réseau (postes clients, routeurs...) doivent être dotés de dispositifs de QoS (qualité de service). La priorité est ainsi donnée aux paquets de voix. Sur Internet, l'hétérogénéité des matériels réseau impliqués empêche toute maîtrise de la qualité de transmission. C'est la raison pour laquelle il est aujourd'hui impossible de mettre en place de la voix sur IP sur Internet avec un niveau d'exigence acceptable pour une entreprise.

6. Les protocoles

Ainsi, nous pouvons conclure qu’il existe trois principaux protocoles utilisés pour la

voix sur IP : • Le protocole H.323 (de l’ITU-T) • Le protocole SIP (de l’IETF) • Le protocole MGCP (de l’IETF)

6.1 Le protocole H.323

H.323 (« Visual Telephone Systems and Equipment for Local Area Networks which

Provide a Non-Guaranteed Quality of Service ») : le standard H.323 fournit les services pour le transfert de l’audio, de la vidéo ou de données à travers des réseaux IP. En se référant à ce standard, les produits de constructeurs différents sont censés interopérer, sans souci de compatibilité.

H.323 est un ensemble de recommandations venant le ITU-T, qui définissent des standards pour le transport de données multimédia sur des réseaux locaux qui ne fournissent pas une qualité de service garantie. La première version a été approuvée en 1996 par le Study Group 16 de l’ITU-T, la version 2 l’ayant été en janvier 1998. Ce standard a une étendue très large, incluant à la fois des stations de visio conférence que des PC multimédia, en mode point à point ou en mode multi points. H.323 définit également le contrôle des appels, la gestion de la bande passante, les interfaces entre le(s) LAN(s) et les autres réseaux. H.323 définit quatre composants majeurs qui interagissent dans un réseau de paquets :

• les “endpoints”, qui initient un appel audio, vidéo ou de visio conférence • une passerelle ( “gateway” ) pour l’interaction avec un réseau téléphonique commuté • un élément optionnel ( “gatekeeper” ) qui permet la connectivité entre des

équipements ISDN externes qui appellent dans le réseau de paquets pour atteindre un élément H.323

• les MCUs ( « Multipoint Control Units » ) pour la conduite de visio conférences en multi points.

Concernant le support de la voix, H.323 supporte 5 algorithmes : G.711 ( obligatoire ), G.722, G.728, G.723.1 et G.729, G.723.1 ayant été choisi comme celui par défaut pour les applications de téléphonie dans le monde Internet. H.323 fait partie d’une série plus large de standards de communication qui permettent la visioconférence à travers un ensemble de réseaux. Connus sous le terme générique, H.32x, cette série inclut notamment H.320 et H.324, qui adressent les communications dans le monde ISDN d’une part, et pour les réseaux RTCs d’autre part.

9

Schéma de la pile protocolaire H.323 :

Architecture globale d’H.323 :

6.2 Le protocole SIP

Cette partie se concentre sur le protocole d’ouverture de session (SIP), qui est un protocole récent publié par l’I.E.T.F. (Internet Engineering Task Force) sous la RFC (Request For Comments) 2543 en mars 1999. La RFC 2543 présente la source d’information la plus complète sur le sujet.

Selon la RFC 2543, le protocole d’initiation de session (SIP) est un protocole de signalisation appartenant à la couche application du modèle OSI. Son rôle est d’ouvrir, modifier et libérer les sessions ou appels ouverts entre un ou plusieurs utilisateurs. Pour ouvrir une session, l’utilisateur émet une invitation transportant un descripteur de session permettant aux utilisateurs souhaitant communiquer de s’accorder sur la compatibilité de leur média. SIP

10

peut relier des stations mobiles en transmettant ou redirigeant les requêtes vers la position courante de la station appelée.

6.2.1 Les fonctions utilisées par SIP Pour établir et terminer des communications multimédia, SIP utilise les 5 fonctions suivantes :

• User location : permet de localiser le poste terminal utilisé pour communiquer • User capabilities : détermine quels média vont être échangés(voix, vidéo, données…)

ainsi que les paramètres associés • User availability : détermine si le poste appelé souhaite communiquer et autorise

l’appelant à la contacter • Call setup ou " ringing ": avertit les parties appelant et appelé de la demande

d’ouverture de session (sonnerie ou message de réception d’appel) et mise en place des paramètres d’appel

• Call handling : gère le transfert et la fermeture des appels

6.2.2 Les composants de SIP Comme HTTP, SIP propose l’établissement, la modification et la clôture de sessions en mode client / serveur, c’est à dire l’échange de requêtes coté client et réponse coté serveur. Exemple : Dans un système SIP on trouve deux composantes, les users agents (U.A.S et U.A.C) et un réseau de serveurs.

• l’U.A.S (User Agent Server) : représente l’agent de la partie appelée, c’est une application de type serveur qui contacte l’utilisateur lorsqu’une requête SIP est reçue. Et elle renvoie une réponse au nom de l’utilisateur

• l’U.A.C (User Agent Client) : représente l’agent de la partie appelante, c’est une application de type client qui initie les requêtes

• le relais mandataire ou P.S. (Proxy Server) : auquel est relié un terminal fixe ou mobile (lors de son déplacement, le terminal est relié au PS le plus proche et change

User Agent SIP A

User Agent SIP B

Serveur SIP

1 INVITE

4 OK

5 ACK

2 INVITE

3 OK

6 ACK

11

constamment de PS) agit à la fois comme client et serveur. Un tel serveur peut interpréter et modifier les messages qu’il reçoit avant de les retransmettre

• le R.S (Redirect Server) : réalise simplement une association (mapping) d’adresses vers une ou plusieurs nouvelles adresses ( lorsqu’un client appelle un terminal mobile - redirection vers le PS le plus proche - ou en mode multicast - le message émis est redirigé vers toutes les sorties auxquelles sont reliés les destinataires - ). Notons qu’un Redirect Server est consulté par l'UAC comme un simple serveur et ne peut émettre de requêtes contrairement au PS.;

• le L.S (Location Server)fournit la position courante des utilisateurs dont la communication traverse les RS et PS auxquels il est rattaché : cette fonction est assurée par le service de localisation

• le RG (Registrar) est un serveur qui accepte les requêtes REGISTER et offre également un service de localisation comme le LS. Chaque PS ou RS est généralement relié à un Registrar.

6.2.3 Utilisation de SIP

L’ouverture d’une session à l’aide du protocole SIP peut s’effectuer de façon directe entre deux User Agents qui jouent le rôle de client et de serveur ou de façon indirecte au travers d’un serveur proxy. Dans ce dernier cas, le serveur à en charge la localisation du serveur B (exemple) dont l’adresse est passé dans le message INVITE. Dans le cas de changement de localisation , le serveur proxy est renseigné sur l’adresse de l’utilisateur à l’aide du serveur de localisation. Et le serveur proxy adresse un message 302 MOVE TEMPORARILY avec les nouvelles coordonnées de localisation

6.2.4 Les protocoles utilisés L’architecture en couches de SIP, telle que la présente le modèle OSI, incorpore les protocoles : RTP, RSVP, RTCP, SAP et SDP.

• RSVP est un protocole utilisé pour réserver les ressources réseaux sur IP avec une excellente qualité de service(QoS)

• R.T.P.(Real-time Transport Protocol) pour transporter des informations en temps réel avec une excellente qualité de services

IPV4,IPV6

UDP

TCP

RSVP

RTSP

SIP

RTCP

RTP

SDP

Media

12

• R.T.C.P.(Real-Time streaming Control Protocol) pour assurer le contrôle de flux des données multimédia

• S.A.P. (Session Announcement Protocol) pour préciser si les sessions mutimedia ouvertes

• S.D.P.(Session Description Protocol) est un protocole de description des sessions multimédia

Exemple de SDP pour la téléphonie sur internet :

6.2.5 Les messages SIP

Contrairement au protocole HTTP, qui est basé sur TCP, SIP utilise UDP pour les

applications multimédia. Pour transporter plusieurs transactions à la fois, SIP peut utiliser une simple connexion TCP(mode flux) ou des datagrammes UDP(mode bloc). Seulement,les datagrammes UDP, tout en-têtes compris, ne doivent pas excéder une certaine longueur(M.T.U. pour Maximum Transmission Unit). Si la MTU est inconnue, elle est de 1500 octets par défaut. Cette taille permet l’encapsulation des datagrammes UDP ou segments TCP dans des paquets IP sans fragmentation. Un message SIP peut être à la fois une requête d’un client vers un serveur ou une réponse d’un serveur vers un client. Ces deux types de messages SIP utilisent le format suivant :

Ligne de requête ou ligne d’état Entête de requête ou de réponse CRLF : Balise indiquant le début de corps du message Corps du message

6.2.5.1 Les requêtes et les réponses SIP

Ø Les requêtes SIP

Les méthodes utilisées dans une requête SIP sont :

13

• INVITE : indique que l’application ou utilisateur est invité à participer à une session. Le corps du message contient la description de la session (média supportés par l’appelant entre autres).

• ACK : confirme que le client a reçu une réponse définitive à une requête INVITE. • OPTIONS : un PS en mesure de contacter l’UAS appelé, doit répondre à une requête

OPTIONS en précisant ses capacités à contacter l’UAS. • BYE : est utilisée par l’UAS de l'appelé pour signaler au PS local qu’il ne souhaite

plus participer à la session. • CANCEL : la requête CANCEL permet d’annuler une requête non validée par une

réponse finale d’état. • REGISTER : cette méthode est utilisée par le client pour enregistrer l’adresse listée

dans l’URL TO par le serveur auquel il est relié. Ø Les réponses SIP

Une réponse à une requête est caractérisée, par un code et un motif , appelés code d’état et reason phrase respectivement. Un code d’état est un entier codé sur 3 bits indiquant un résultat à l’issue de la réception d’une requête. Ce résultat est précisé par une phrase, text-based (UTF-8), expliquant le motif du refus ou de l’acceptation de la requête. Le code d’état est donc destiné à l’automate gérant l’établissement des sessions SIP et les motifs aux programmeurs. Il existe 6 classes de réponses et donc de codes d’état, représentées par le premier bit :

• 1xx = Information : la requête a été reçue et continue à être traitée • 2xx = Succès : l’action a été reçue avec succès, comprise et acceptée • 3xx = Redirection : une autre action doit être menée afin de valider la requête • 4xx = Erreur du client : la requête contient une syntaxe éronnée ou ne peut pas être

traitée par ce serveur • 5xx = Erreur du serveur : le serveur n’a pas réussi à traiter une requête apparemment

correcte • 6xx = Echec général : la requête ne peut être traitée par aucun serveur

Exemple :

14

Requête INVITE Réponse à la requête INVITE SIP/2.0 200 OK Via : SIP/2.0/UDP swerdet.ausys.se FROM : Mattias<sip : mattias@ausys.se> TO: Lars<sip: lars@ausys.se> Call-ID: 4353456345@swerdet.ausys.se Content- Type: application/sdp Content-length : 158 V=0 O=lars 3245436364 3453633533 IN IP4 172.4.5.4 S=Hello again C= IN IP4 mars.ausys.se M=audio 3456 RTP/AVP 0 3 4 5

INVITE sip :mattias@mars.ausys.se SIP/2.0 Via : SIP/2.0/UDP swerdet.ausys.se From : Lars<sip :lars@ausys.se> To: Mattias<sip:mattias@ausys.se> Call – ID: 4353456345@swerdet.ausys.se Cseq: 1 INVITE Subject: Hello Mattias Content – Type: application/sdp Content-type : application/sdp Content-Lengt : 187 V=0 O=mattias 52655765 2687637 IN IP4 172.2.2.5 S= Hello Mattias C= IN IP4 swerdet.ausys.se M = audio 3456 RTP/AVP 0 3 4 5

6.2.5.2 Les en-têtes SIP

Les différents champs d'en-tête qu'utilise SIP ne nécessitent pas d'ordre particulier sauf dans le cas de l'en-tête général Via où l'ordre des champs d'en-tête importe. En particulier, l'on distingue les champs d'en-têtes des messages transmis saut par saut (c'est-à-dire qui sont interprétés et peuvent être modifiés ou ajoutés par tous les serveurs qu'ils traversent) des en-têtes des messages transmis de bout en bout(interprétés par les émetteurs et destinataires uniquement et non modifiables par les serveurs traversés). Les champs d'en-tête saut par saut doivent apparaître avant les champs d'en-tête de bout en bout. Les PS ne doivent pas réordonner les champs d'en-tête mais peuvent ajouter éventuellement des champs Via ou autres champs de type "saut par saut". Chaque méthode (ACK, BYE, CANCEL, INVITE, OPTIONS, REGISTER) requière, ne supporte pas ou supporte de façon optionnelle certains champs d'en-tête. Par exemple, les champs d'en-tête CALL-ID, Cseq, FROM, TO et Via sont requis par toutes les méthodes(dans le cas de la méthode OPTIONS, il faut ajouter en plus le champ d'en-tête Allow). Ces champs d'en-tête sont de type "de bout en bout". Il existe 4 types de champs d'en-tête:

• En-tête général s’applique à la fois aux messages de requête et de réponse : Accept ou Accept-Encoding ou Accept-Language ou CALL-ID ou Contact ou Cseq ou Date ou Encryption ou Expires ou From ou Record-Route ou Timestamp ou To ou Via

• En-tête d’entité définit le type d'informations contenues dans le Corps du message ou

la ressource identifiée par la requête en l'absence du Corps du message : Content-Encoding ou Content-Lenght ou Content-Type

15

• En-tête de requête Le champ d'en-tête de requête autorise le client à ajouter des

informations concernant sa requête et lui-même à destination du serveur : Authorization ou Contact ou Hide ou Max-Forwards ou Organization ou Priority ou Proxy-Authorization ou Proxy-Require ou Route ou Require ou Response-Key ou Subject ou User-Agent

• En-tête de réponse Le champ d'en-tête de réponse autorise le serveur à ajouter des

informations concernant sa réponse, qui ne peuvent pas être placées dans la ligne d'état, sur lui-même et sur l'accès à la ressource identifiée par la requête URI : Allow ou Proxy-Authorization ou Retry-After ou Server ou Unsupported ou Warning ou WWW-Authenticate.

Dans le tableau suivant on donnera le détail d’utilisations de ces différents champs :

Champs Utilisations Accept Utilisé dans les messages INVITE, OPTIONS et REGISTER qui

permet d'indiquer les types de média qui seront acceptés dans la réponse à ce message.

Accept-Encoding Conditionne la réponse car il détermine quels codages text-based y seront acceptés.

Accept-Language Il permet au client d’indiquer au serveur quel langage à utiliser dans le corps du message de la réponse au client.

Allow Indique les méthodes valides supportées par les entités identifiées par la requête URI.

Authorization Champ optionnel à inclure par l'utilisateur souhaitant s'authentifier vis à vis du serveur auquel il est relié

Call-ID Identifie une invitation précise ou tous les enregistrements d’un client particulier.

Contact

Champ pouvant apparaître dans les requêtes INVITE, ACK et REGISTER ou dans les réponses de codes 1xx, 2xx, 3xx et 485. Il fournit en général l’URL où l'utilisateur pourra

Content-Encoding Indique le code utilisé pour écrire et lire l'en-tête d'entité. Ainsi le serveur qui reçoit le message sait quel mécanisme de décodage appliquer pour lire le Content-Type décrit ci-dessus et peut connaître le type de média utilisé. Ce champ est très utile si l'on veut compresser les en-têtes sans perdre les informations précieuses qu'ils contiennent

Content-Length Il indique simplement la taille du Corps du message envoyé, en nombre décimal d'octets.

Content-Type Il indique les types de média utilisés dans le Corps du message envoyé.

16

Cseq Chaque requête doit obligatoirement contenir un numéro de séquence Cseq (entier non signé de 32 bits). Le Cseq initial est choisi arbitrairement par celui qui envoie la requête INVITE mais doit toujours être inférieur à 2^31.

Date donne la date d’émission de la requête ou de la réponse. Les retransmissions possèdent la même date que la requête ou réponse d’origine.

Encryption Ce champ spécifie si le message est crypté et suivant quel cryptage.

Expires donne la durée au-delà de laquelle le message expire.

From indique la personne à l'origine du message Hide Le client utilise ce champ lorsqu'il veut que le chemin compris

dans l'En-Tête VIA soit caché aux prochains Proxy Servers que traversera le message.

Max-Forwards utilisé pour limiter le nombre de PS ou passerelles que la requête peut traverser jusqu’au prochain serveur dans le sens de l'UAC vers l'UAS (downstream).

Organization Précise le nom de l’organisation à laquelle l’entité dont émane la requête ou la réponse appartient

Priority Indique le niveau d’urgence de la requête, tel qu’il est perçu par le client.

Proxy-Authenticate Ce champ doit être rempli dans une réponse Proxy Authentification Required (code 407).

Proxy-Authorization Permet au client de s’identifier dans sa requête en destination d’un PS le lui ayant demandé.

Proxy-Require Indique quels champs d’en-tête le PS supporte.

Record-Route Ce champ permet de mémoriser un chemin pour faciliter l'acheminement de la réponse. Chaque Proxy Serveur traversé ajoute son adresse dans ce champ en début de liste. Le serveur appelé copie cette liste, sans la changer, dans l'en-tête Route de sa réponse. La première entrée est ainsi l'adresse du serveur le plus proche de celui qui répond.

Response-Key le client utilise cet en-tête dans sa requête pour déterminer la clé a utilisé pour crypter la réponse.

Retry-After ce champ n'est utilisé que dans les réponses Service Unavailable(code 503), Not Found (code 404), Busy (code 600) ou bien Decline (code 603) pour indiquer à l'emetteur de la requête quand est-ce qu'un service "normal" pourra reprendre. Il contient une date ou un nombre en décimal de secondes.

Server Il contient les informations sur les softwares utilisés par les

17

UAS. Subject Résumé ou nature de l'appel qui peut permettre de le filtrer sans

avoir à lire la description de la session.

Timestamp Précise l'instant (date) où le client a envoyé la requête au serveur.

To C'est l'adresse du destinataire. Ce champ est bien sûr obligatoire.

Unsupported Liste quelles configurations ne sont pas supportées par le serveur.

User-Agent Contient des informations sur le terminal de l'utilisateur (UAC/UAS) à l’origine de la requête.

Via Contient les adresses des serveurs (PS) que traverse la requête. Warning Les avertissements sont contenus dans les réponses dans le

langage le plus compréhensible pour l'utilisateur. WWW-Authenticate Doit être inclus dans une réponse Unauthorized (code 401).

Contrairement aux protocoles standards tels que IP ou TCP, où le format des paquets ou segments est bien déterminé, le format des messages SIP n’est pas standard. Les champs d’en-tête sont choisis " à la carte " selon un panel de champs. Lorsque les messages SIP sont transportés par UDP, avec authentification et une description de session complexe, il arrive que la taille du message SIP de requête ou réponse dépasse la MTU. Pour résoudre ce problème, un format compact a été défini utilisant des abréviations pour les champs d’en-tête suivants :

Champ d’en-tête Abréviation associée Content-Type C Content - Encoding E From F CALL-ID I Contact M(pour " moved ") Content-Length L Subject S To T Via V

Les clients doivent être capables de mélanger des champs d’en-tête de messages courts (format normal) avec ceux de messages longs (format compact) en utilisant les mêmes requêtes. Les serveurs doivent accepter ces deux formats à la fois.

6.2.6 Exemples de transactions

Pour faire appel à SIP, l’application de l’UAC appelant envoie une requête INVITE au Proxy Server (PS) auquel il est relié. Ce serveur, via d'autres PS, transmet cette requête à l'UAS auquel est relié l’appelé. Cette requête demande à l’appelé s’il veut rejoindre un forum

18

de discussion, assister à une visioconférence ou établir simplement une communication privée avec l’appelant. Si l’appelé est d’accord, il renvoie une réponse OK (code 200) à l’appelant qui confirme alors qu’il a bien reçu la réponse de l’appelant. Pour cela, il envoie une requête ACK, acquittement (acknoledgement) à l’appelé. De la même manière, si l’utilisateur souhaite se déconnecter, l’application de l’utilisateur émet une requête BYE au lieu de ACK.

La requête INVITE contient la description de la session ouverte qui stipule quels sont les médias et formats des messages SIP utilisés (protocole SDP) . Pour une communication unicast, la requête INVITE précise les types de média et formats que l’appelant utilisera et vers où il souhaite que les données soient envoyées. Si l’appelé est d’accord avec cette description, sa réponse contiendra les mêmes paramètres(toutes les requêtes et leurs réponses ont le même Call-ID) . En multicast, l’appelé répondra que si sa description est différente. Exemple de fonctionnement d’une requête INVITE en mode Proxy Server (PS) :

1. Le client appelant (UAC) envoie au PS une requête INVITE avec l’adresse SIP du destinataire henning@columbia.edu 2. Le PS contacte le Location Serveur et lui fournit toute ou une partie de l’adresse SIP du destinataire : henning 3. Le PS obtient alors une adresse plus précise hgs@play 4. Le PS envoie une requête INVITE au serveur destinataire dont l’adresse lui a été fournie par le service de localisation du Location Server : play 5. L’UAS du destinataire avertit l'appelé 6. Et retourne au PS de l'appelant l’accord du destinataire pour communiquer par une réponse OK (code 200) 7. Ce PS retourne alors au client appelant l’accord du destinataire 8. La réception de l’accord du destinataire est acquittée par le client appelant par une requête ACK 9. Cet acquittement est transmis directement à l’appelé 10. Communication établie

19

Exemple de fonctionnement d’une requête INVITE en mode Redirect Server [5]

1. Le client appelant (UAC) envoie une requête INVITE au redirect serveur (RS) avec l’adresse destinataire 2. et 3. Le RS contacte le Location Server qui lui fournit l’adresse du serveur destinataire : columbia.edu 4. Le RS renvoie au client appelant la nouvelle adresse par une réponse Moved (code 302) signalant que le terminal destinataire a changé de PS ; 5. Le client appelant envoie une requête ACK au RS pour acquitter ; 6. Puis ce client envoie une requête INVITE au serveur du destinataire. Cette requête possède le même Call-ID que la première mais son numéro de séquence Cseq est plus élevé 7. Le PS du destinataire avertit l'UAS de l'appelé , qui retourne au PS son accord pour communiquer par une réponse OK (code 200). Le PS retourne au client appelant l’accord du destinataire 8. La réception de l’accord du destinataire est acquittée par le client appelant par une requête ACK , Cet acquittement est transmis directement à l’appelé Nous venons de voir, à travers ces 2 exemples que si certains paramètres de la session doivent être changés, un nouveau INVITE est émis tout en conservant le Call-ID mais un Cseq plus grand doit être utilisé. Pour localiser un utilisateur SIP, notons d’abord qu’un terminal utilisateur peut constamment se déplacer. Sa position doit être enregistrée dynamiquement par un location server. Un tel serveur enregistre plusieurs positions pour un même terminal, qui est relié à plusieurs PS à la fois lorsqu’il se déplace (les PS les plus proches) . Lorsqu'un serveur SIP interroge son location server, il établit une liste des postions possibles de l’utilisateur à partir des résultats reçus. Cette liste contient 0 position ou plus. Pour communiquer sa nouvelle position au serveur SIP, le terminal de l’utilisateur lui envoie une requête REGISTER.

6.2.7 Conclusions

SIP (Session Invitation Protocol) est un protocole de signalisation permettant à un appelant de retrouver un appelé via des serveurs dits "proxy" ou "redirect", ceux-ci pouvant consulter des serveurs de "localisation" ou des serveurs "registrars" auprès desquels les utilisateurs ont pu enregistrer leur localisation (même temporaire). Une fois que le client

20

(l'appelant) a localisé l'appelé, ce dernier accepte ou refuse ou redirige l'appel. S'il accepte, l'appelant et l'appelé peuvent communiquer.

6.3 Le protocole MGCP Le protocole MGCP (Media Gateway to Media Controller Protocols) résulte de la

fusion des deux protocole SGCP 1.1 ( Simple Gatte Control Protocol ) et du protocole IDPC 1.0 ( Internet Protocol Device Control ). Le protocole SGCP est utilisé pour contrôler l’activité d’une Telephony Gateway à travers un élément de contrôle d’appel externe nommé Call Agent. Le protocole IPDC est utilisé pour réaliser le control de connexions du Media Gateway et le transport de la signalisation. Le protocole MGCP suppose une architecture de contrôle d’appelle dont laquelle l’élément intelligent de contrôle se trouve en dehors de Gateway, et c’est lui qui assure le contrôle de l’activité de la passerelle multimédia à l’aide d’un protocole de contrôle. Cet élément de contrôle s’appelle Media Gateway Contoller ou Call Agent. Dans l’architecture MGCP il existe plusieurs Call Agent. Le protocole MGCP suppose que ces différents Calls Agents doivent se synchroniser l’un avec les autres pour envoyer des messages cohérents aux passerelles au-dessous de leurs contrôles. Finalement MGCP est un protocole maître /esclave ou on s’attend à ce que les Gateways exécutent des commandes envoyées par les Call Agents.

6.3.1 Généralités

Dans le réseau téléphonique la couche de signalisation est séparée de la couche de transport de parole. Le rôle important de la signalisation est d’échanger les messages entre les différentes entités pour établir un circuit de parole entre des utilisateurs qui désirent dialoguer. Le rôle des protocoles de VOIP est d’assurer la connexion entre les deux réseaux RTC/RNIS et le réseau Internet. C’est dans cette notion d’interconnexion entre les deux mondes que se situe le protocole MGCP.

Cette intégration permet au réseau RTC de voir les éléments de réseau téléphonique comme étant autre switcher du réseau RTC.

L’architecture relative à l’interconnexion du réseau téléphonique avec un réseau IP est présente sur le schéma ci-dessous.

21

Le pôle d'interconnexion est composé de trois entités fonctionnelles et d'un protocole permettant le dialogue au niveau de ces entités :

• Passerelle multimédia (Media Gataway). Elle assure la transformation d'un flux vocal

entre le mode circuit et le mode paquet. • Contrôleur de la passerelle multimédia (Media Gateway Controller). Il assure le

contrôle de l'activité de la passerelle multimédia à l'aide du protocole de contrôle (Control Protocol).

• Module de signalisation. Il assure la transcription de la signalisation ISUP.

Ces trois entités fonctionnelles peuvent être physiquement séparées ou alors couplées au sein d'un même équipement.

Le protocole MGCP est le protocole de contrôle qui permet le dialogue entre Media Gateway Controller ( Call Agent ) et Media Gateway.

Dans ce protocole l’interconnexion entre le réseau téléphonique et le réseau IP est assuré par deux niveaux logiques :

• Niveaux de signalisation assurés par l’utilisation du SG (Signaling Gateway). • Niveaux de voix assurés par l’utilisation de passerelle multimédia.

Pour plus d’information on peut regarder le scénario d’établissement d’un appel.

En ce qui concerne le Call Agent il y a trois catégories de messages :

• Des messages du réseau RTC transférés par le SG ( Signaling Gateway). • Des messages originaires Network Management échangés entre le Call Agent et les

Gateways.. • Des messages de la MGC pour maintenir la Bases de données.

L’architecture générale du protocole MGCP la suivante :

• STP Point de Transfert de Signalisations • SSP Point de Signalisation • SG Gateway de Signalisation • MG Media Gateway (Passerelle Multimédia) • ISUP ISDN User Part

Dans cette architecture la gestion des différents Gateways ainsi que les interconnexions avec le réseau PSTN est assurée par les Call Agents. L’identification d’une extrémité ce fait par la nom du domaine de la Gateway a laquelle l’extrémité est reliée et par un nom local dans ce Gateway.

6.3.2 Fonctionnement de MGCP 6.3.2.1 Les commandes MGCP

22

Le protocole MGCP est un protocole de contrôle de fonctionnement de Media Gateway. Dans ce protocole l’élément intelligent est le Call Agent il contrôle les passerelles par l’utilisation des huit commandes échanger entre lui et les passerelles. Ces commandes sont représentées dans le tableau suivant :

Commandes Directions Code

NotificationRequest Call Agent à Gateway RQNT Notification Gateway à Call Agent NTFY CreateConnection Call Agent à Gateway CRCX ModifyConnection Call Agent à Gateway MDCX DeleteConnection Call Agent à Gateway DLCX AuditEndPoint Call Agent à Gateway AUEP AuditConnection Call Agent à Gateway AUCX RestartInProgress Gateway à Call Agent RSIP

Notification Request : Le Call Agent peut envoyer cette commande au Gateway, pour lui demander de détecter l’apparition des évènements spécifiques pour un terminal. Ces spécifications peuvent être des signalisations téléphoniques comme l’accrochage ou le décrochage du téléphone ou bien des tonalités pour des extrémités spécifique. Une des plus importantes options de Notification Request est l’association d’une action avec chaque évènement. L’utilisation de cette option permet la réduction de nombre de messages échangés entre le Call Agent et le Media Gateway. Notification Command : Le Gateway utilise cette commande comme réponse à la commande Notification Request envoyer par le Call Agent, cette commande indique au Call Agent que l’évènement est déclenché. Le Gateway peut envoyer un ou plusieurs réponses à des évènement dans une seule commande, ces évènements sont envoyés par le Media Gateway dans l’ordre de détection des ces évènements et c’est le rôle de Call Agent de mettre ces évènements dans l’ordre correcte. Create Connection : Cette commande est envoyée par le Call Agent au Media Gateway pour créer une connexion entre deux extrémités. Autres que les paramètres nécessaires qui permettent au Media Gateway de créer des connexions, il y a des options LocalConnectionOptions qui définissent les qualités de services de la connexion. Par l’envoie du message Notification Request le Call Agent a la capacité d’envoyer des actions qui correspondent à chaque évènement. L’utilisation de cette option dans la création d’une connexion permet de diminuer le nombre de messages échangés entre le Call Agent et le Media Gateway. Modify Connection :

23

Cette commande permet au Call Agent de modifier les paramètres associés à une connexion déjà établie. Delete Connection : Cette commande est envoyée par le Call Agent au Gateway, elle lui permet de terminer une conversation téléphonique. S’il existe plus d’un seul Media Gateway pour une conversation le Call Agent doit envoyer cette commande à chaque Gateway. Une fonctionnalité important du protocole MGCP associé à cette commande est qu’il faut au Media Gateway lors de la terminaison d’un appel d’envoyer au Call Agent une réponse qui contient les informations suivantes : − Nombres de paquets (RTP) envoyés. − Nombres d’octets envoyés. − Nombres de paquets (RTP) reçus. − Nombres d’octets reçus. − Nombres de paquets perdus. − Information sur la gigue. − Information sur les délais de transmission. Pour plus d’information sur ces paramètres on peut regarder le RFC 1889. Le protocole MGCP permet au Gateway de couper une connexion quand il veut. Dans ce cas le Gateway envoie au Call Agent une commande Delete Connection qui contient tous les paramètres statistiques si dessus. Il faut noter aussi que la Call Agent à la possibilité de supprimer une connexion de multiples-extrémités dans le même temps et ceci par l’envoie d’un message Delete Connection a un Gateway avec le caractère *. Cette commande ne ramène pas des informations statistiques sur la connexion. Audit Endpoint : Le Call Agent peut utiliser cette commande pour détecter si une extrémité est décrochée ou en état de sonnerie. Dans ce cas le Gateway ramène une réponse qui contient des informations sur des extrémités spécifiques. Audit Connection : Cette commande permet au Call Agent de détecter tous les paramètres liés à une connexion spécifique. Restart In Progress : Cette commande est envoyée par le Gateway au Call Agent. Il permet d’informer le Call Agent de mettre hors services une extrémité ou un groupe d’extrémités qu’ils ont des problèmes. Dans ce cas la Call Agent peut décider de tester ces extrémités avant de les mettre hors service. Pour se familiariser un peu avec le protocole MGCP nous allons développer un scénario d’établissement d’une connexion entre deux extrémités.

24

Nous allons développer un scénario de création d’une connexion dont laque lle l’utilisateur A appelle l’utilisateur B.

6.3.2.2 Scénario L’utilisateur A utilise un terminal analogique. Dans ce cas le CO ( Central Office) qui sert l’utilisateur A est connecté à un réseau de signalisation SS7 à travers un STP (Point de Transfert de sémaphore ). L’interconnexion entre le réseau téléphonique et le réseau IP est assurée par deux niveaux logiques :

1. Niveaux de signalisation, dans ce cas le STP est connecté au Call Agent à travers une Gateway de signalisation( SG ), le rôle de SG est de convertir la signalisation SS7 du réseau téléphonique en une signalisation sur le réseau IP. Dans ce cas le Call Agent joue le rôle d’une entité intermédiaire entre le Gateway de signalisation et le Gateway de multimédia.

2. Niveaux de voix, dans ce cas l’interconnections entre les 2 réseaux se fait à travers le Media Gateway.

Les Media Gateway A et B sont contrôlés par le Call Agent et ceci par l’utilisation du

protocole MGCP.

TGW : Trunking Gateway.

25

La fonctionnalité de Call Agent est représentée dans la figure suivante :

Les messages échangés entre les différentes entités pendant l’établissement de l’appel sont représentés dans le tableau suivant :

Round trips

CO SS7 TGW Call Agent RGW Utilisateur Etapes

0.5 IAM à 1 1 IAM à 2 1.5 Database lookup 3 2 ß CRCX 4 2.5 ACK à 5 3 CRCX à 6 3.5 ß ACK 7 4 ß MDCX 8 4.5 ACK à 9 5 RQNT à Ring 10 5.5 ß ACK 11 6 ß ACM 12 6.5 ß ACM 13 décrocher 14 7 ß NFTY 15 7.5 ACK à 16 8 RQNT à 17 8.5 ß ACK 18

26

9 ß MDCX 19 9.5 ACK à 20 10 ß ANM 21 10.5 ß ANM 22 (parole) 23 raccrocher 24 0.5 ß NTFY 25 1 ACK à 26 1.5 DLCX à 27 2 ß DLCX 28 2.5 ß REL 29

Scénario:

1. CO: émet un message d’initialisation (IAM) au Call Agent à travers son STP. 2. SS7 : le point de transfert de signalisation (STP) conduit le message ISUP au Gateway

de signalisation attaché au Call Agent. 3. Call Agent : cherche dans la base de données l’adresse IP de la Gateway à laquelle le

destinataire qui correspond à ce numéro est rattaché. 4. Call Agent : envoie un message Create Connection au Gateway de l’utilisateur A pour

ce connecter au réseau téléphonique. 5. TGW : envoie un message ACK au Call Agent pour lui indiquer la réception du

message CRCX. 6. Call Agent : saisit la réponse et envoie un message CRCX au Gateway de l’utilisateur

B. 7. RGW : envoie un message ACK au Call Agent pour lui indiquer la réception du

message CRCX. 8. Call Agent : indique ces informations au TGW par l’envoie d’un message Modify

Connection . 9. TGW : envoie un message ACK au Call Agent. 10. Call Agent : envoie un message Notification Request au RGW B pour lui indiquer de

sonner le téléphone B. 11. RGW : envoie un message ACK au Call Agent. 12. Call Agent : quand le Call Agent reçoit le message ACK de RGWB il envoie un

message ACM ( Address Complete Message ) au Gateway de signalisation. 13. SS7 : le STP transport cette information au CO. 14. Utilisateur B : le terminal B se décroche. 15. RGW : détecte cet évènement et informe le Call Agent par envoie de message

Notification. 16. Call Agent : envoie un message ACK au RGWB. 17. Call Agent : dans l’ordre de pouvoir détecter la terminaison de la conversation, le Call

Agent demande au RGW de lui informer le raccrochage du téléphone et ceci par l’envoie d’un message Notification Request.

18. RGW : envoie un message ACK au Call Agent. 19. Call Agent : maintenant le canal de voix doit être transformé en mode full duplex ; le

Call Agent fait ceci par l’envoie du message Modify Connection au TGW. 20. TGW : envoie un message ACK au RGWB. 21. Call Agent : peut dans ce cas envoyer un message de réponse au Gateway de

signalisation. 22. SS7 : le STP envoie cette information aux CO.

27

23. Les deux parties entrent en conversation. 24. RGW : l’utilisateur B se raccroche. 25. le RGW envoie un message de Notification au Call Agent. 26. Call Agent : envoie un message ACK au RGW. 27. Call Agent : envoie un message Delete Connection au RGW B. 28. Call Agent : envoie un message Delete Connection au TGW A. 29. Call Agent : émet un message RELEASE au Gateway de signalisation. 30. SS7 : le STP transport cette information au CO.

7. Matériels nécessaires à la mise en place de la VoIP 7.1 Introduction

L'intégration de services de téléphonie au sein de réseaux de données augure des

changements majeurs pour les entreprises car elle permet de distribuer les informations de manière plus poussée et efficace que les stratégies multiréseaux actuelles. 7.2 Approche centralisée contre approche distribuée

Dans le passé, tous les réseaux vocaux furent construits en utilisant une architecture centralisée dans lesquels les terminaux étaient contrôlés par des switchs centralisés. Bien que ce modèle fonctionne pour tous les services basiques de téléphone, il limite de beaucoup les évolutions des services associés. Un des bénéfices de la technologie VoIP est qu’elle permet aux réseaux d’être construits soit sur une architecture centralisée soit distribuée. Cette souplesse permet aux entreprises de bâtir des réseaux caractérisés à la fois par un management simplifié et aussi de l’innovation pour les terminaux, cela en fonction des protocoles ut ilisés. En général, les architectures centralisés sont associés avec les protocole MGCP ou H.248/Megaco. Ces protocoles ont été créés pour une interface centralisée qui gère le contrôle de l’appel et la logique du « switching ». L’interface centralisée discute avec les différentes passerelles qui routent et transmettent les paquets de voix. Dans les architectures centralisées, l’intelligence du réseau est centralisée et les terminaux sont relativement peu intelligents. Les partisans des architectures VoIP centralisées encouragent ce modèle car il centralise le management et le contrôle des appels. Il simplifie également le flux des appels ainsi que sa compréhension par les ingénieurs de développement. Les critiques de cette architecture avancent qu’elle étouffe l’innovation des caractéristiques des terminaux et qu’elle deviendra une entrave quand il s’agira de mettre en place des services VoIP qui vont au-delà du simple transport de voix. Les architectures distribuées sont associées avec les protocoles H.323 et SIP. Ces protocoles permettent à l’intelligence du réseau d’être distribuée entre les terminaux et les interfaces de contrôle d’appels. Dans ce contexte, « l’intelligence » englobe l’état d’un appel, les interfaces

28

d’appel, les procédures d’appel, la réservation de ressources, le paiement ou n’importe quel autre aspect de la gestion d’un appel. Les terminaux peuvent être des passerelles VoIP, des téléphones IP, des serveurs de média, ou n’importe quelle interface qui peut initier ou terminer un appel VoIP. L’interface de contrôle d’appel est appelé « gatekeeper » dans un réseau H.323 et proxy ou « redirect server » dans un réseau SIP. Les avocats de l’approche centralisée mettent en avant la souplesse de ce modèle. Il permet aux applications VoIP d’être traitées comme n’importe quel autre application IP distribuée et sa souplesse autorise d’ajouter de l’intelligence soit sur les terminaux soit sur les interfaces de contrôle d’appels en fonction du marché et des exigences technologiques du réseau. Les architectures distribuées sont souvent bien comprises par les ingénieurs qui utilisent des réseaux de données IP. Ses détracteurs soulignent que les réseaux distribués ont tendance à rendre beaucoup plus complexe leurs mises en place.

Exemple d’architecture d’un réseau VoIP

7.3 Exemple de matériel proposé par le constructeur Cisco Cisco est le constructeur leader mondial dans le domaine des matériels VoIP. Voyons maintenant quelqu’uns des types de produits proposés par ce constructeur avant de les détailler par la suite.

29

Produits Caractéristiques principales Téléphones IP de la gamme Cisco 7900

Possibilité de brancher des téléphones simples comme multifonction directement sur une connexion Ethernet 10/100 Base-T

- Téléphones simples à programmer et utiliser - Commutateur Ethernet 2 ports intégré - Nombreuses fonctions IP comprenant les applications XML

Cisco CallManager 3.2 - Traitement logiciel des appels et composant de contrôle des appels pour les solutions de téléphonie sur IP de Cisco - Installé sur les serveurs de convergence média Cisco (MCS), les systèmes Cisco ICS 7750 ou sur certains serveurs tiers (CallManager 3.2)

IPPC (Cisco IP Contact Center)

IPCC (Cisco IP Contact Center) propose un routage intelligent des appels, une téléphonie assistée par ordinateur (TAO) réseau/bureau ainsi qu'une gestion des contacts multimédia concernant les agents des centres de contacts sur un réseau IP. Il inclut plusieurs applications, notamment les suivantes :

- CallManager - Cisco ICM (Intelligent Contact Manager) - Cisco IP IVR/IP Queue Manager

Cisco IP ICD (Integrated Contact Distribution)

- Cisco IP ICD est à la fois un répartiteur automatique d'appels (ACD) basé sur logiciel et une application IVR destinée aux centres de contacts de taille moyenne utilisant les réseaux de téléphonie sur IP basés sur l'architecture Cisco AVVID. - Contrairement aux systèmes ACD propriétaires hérités, Cisco IP ICD est une plate-forme système ouverte permettant de configurer des interactions client simples ou complexes. - Cisco IP ICD dispose d'un éditeur CRS workflow graphique comportant une interface standard permettant de créer ces interactions (également appelées flux d'appels) et de construire une logique commerciale entre les fonctions IVR et ACD.

Équipement d'accès intégré de la gamme Cisco IAD 2400

Équipement d'accès intégré (IAD) à configuration fixe pour entreprises

- Transmission données/voix par TDM ou par paquet sur une seule liaison ascendante WAN - Le service de téléphonie IOS (ITS) assure un traitement IAD des appels locaux avec des fonctions de commutation. Idéal pour les petits bureaux (5 à 20 téléphones) - Fonctions reposant sur IP Keyswitch, idéal pour les petits bureaux (5 à 20 téléphones) n'ayant pas besoin de toutes les fonctions de Cisco CallManager - Prise en charge des téléphones classiques et des téléphones IP sur une seule plate-forme - Modèles de ports voix analogiques 8 FXS/16 FXS/16FXS+8FXO et port voix numérique T1 - Interfaces WAN de type T1, G.SHDSL et ADSL

Passerelles vocales Cisco

Les passerelles vocales dédiées Cisco VG200 et Cisco VG248 permettent de relier des réseaux IP à des systèmes de téléphonie traditionnels, tels que le RTC

- Prise en charge de plusieurs types d'interface, dont T1 et E1 - Entièrement paramétrable par Cisco CallManager, par une interface de commande en ligne via Telnet, ou par SNMP

30

7.4 Détail des matériels Cisco à utiliser

• Téléphones IP de la gamme Cisco 7900

Les téléphones IP Cisco permettent d'établir des communications professionnelles très simplement. Entièrement programmables, avec un choix de quatre modèles (7960, 7940, 7910 et 7910+SW ainsi que le nouveau 7905), les téléphones IP Cisco vous proposent les fonctions les plus utiles en environnement professionnel, tout cela au sein d'une plate-forme simple à programmer et à utiliser.

Les modèles 7960, 7940 et 7910+SW sont des téléphones multifonction pouvant être branchés directement sur une connexion Ethernet 10/100Base-T standard. Chaque modèle permet de passer des communications de qualité téléphonique. Ils sont équipés d'un commutateur Cisco 2 ports 10/100 pour une éventuelle connexion à un PC.

Les modèles 7910 et 7905 sont des modèles à fonctionnalités basiques avec une connexion un seul port 10 Base-T. En tant que téléphones IP, ils peuvent être installés en tout point du réseau IP de l'entreprise.

Les téléphones prennent en charge le protocole de configuration DHCP et il n'est pas obligatoire de les identifier à l'aide de Cisco CallManager. Les téléphones IP Cisco prennent en charge les algorithmes de compression audio G.711 et G.729a, le modèle 7905 prenant également en charge les algorithmes de compression audio H.323 pour répondre aux exigences en termes de bande passante bas débit. Une fonction de téléchargement du microcode permet de leur ajouter de nouvelles fonctions en les programmant depuis le système. Caractéristiques principales :

Modèle Cisco 7960 et 7940 Le modèle Cisco 7960 est un téléphone IP multifonction avec 6 lignes programmables et des touches de numérotation rapide. Le modèle Cisco 7940 dispose de deux boutons pour les utilisateurs disposant d'applications qui utilisent une moindre bande passante. Les deux comprennent un haut-parleur mains libres fonctionnant en mode bidirectionnel, ainsi qu'un bouton muet avec témoin lumineux. Un écran à cristaux liquides de 7,6 x 10 cm affiche les graphiques et les textes, tels que la date, l'heure, le nom et le numéro de l'appelant, ainsi que les numéros composés. Ces téléphones prennent également en charge le format XML, les rendant ainsi idéaux pour afficher les contenus Internet.

Module d'expansion Cisco 7914

Le module d'expansion 7914 permet d'étendre les possibilités du téléphone IP Cisco 7960 grâce à des boutons supplémentaires et à un écran à cristaux liquides, portant ainsi le nombre total de boutons à 20 avec un module ou à 34 avec deux modules.

Station de conférence Cisco IP 7935

La station de conférence Cisco IP 7935 est une station bidirectionnelle mains libres disposant de trois nouvelles touches programmables, d'un écran à cristaux liquides et de touches de navigation dans le menu. Elle convient pour les postes de travail, les bureaux et les salles de conférence de petite à moyenne taille.

Modèles Cisco 7905, 7910 et 7910+SW

Les modèles Cisco 7910 et 7910+SW sont des téléphones IP conçus pour les environnements à faible trafic, ne nécessitant

31

pas des performances supérieures, tels que les halls d'accueil ou les cantines. Ces deux modèles fonctionnent sur une seule ligne et sont équipés d'un écran à cristaux liquides affichant 2 lignes de 24 caractères, pour indiquer l'état de l'appel et afficher la présentation du numéro. Le nouveau téléphone 7905 à faible trafic dispose d'un écran large

Fonctionnalités principales : • Avec le DHCP, les nouvelles installations des téléphones IP sont extrêmement rapides. Ces

derniers peuvent être déplacés d'un port Ethernet à un autre, et ce en tout point du réseau IP de l'entreprise. Si vous déplacez un téléphone IP Cisco, aucune modification de base de données ou de câblage n'est nécessaire, contrairement aux systèmes téléphoniques traditionnels. Les téléphones IP Cisco redémarrent automatiquement et s'enregistrent de nouveau auprès de Cisco CallManager.

• Les téléphones IP Cisco sont compatibles avec Microsoft NetMeeting. Si vous utilisez NetMeeting, le partage d'applications ou la visioconférence sont accessibles à partir d'un simple bouton situé sur votre téléphone IP Cisco.

• Tous les modèles utilisent le protocole CDP (Cisco Discovery Protocole), afin de tirer leur alimentation du réseau local, éliminant ainsi tout besoin d'un bloc d'alimentation local.

• Cisco CallManager 3.2

Le logiciel de traitement d'appels Cisco CallManager ajoute des fonctions de téléphonie aux réseaux locaux d'entreprise et aux équipements réseau de téléphonie par paquets, tels que les téléphones IP, les équipements de traitement des médias, les passerelles de voix sur IP (VoIP) et les applications multimédia. Grâce à l'interface de programmation d'applications (API) de téléphonie ouverte de CallManager, les services de vidéo, voix et données, tels que les messageries unifiées, les conférences multimédia, les centres de contacts de collaboration et les systèmes de réponse interactive multimédia peuvent enfin interagir avec les solutions de téléphonie IP. Cisco CallManager est installé sur le serveur de convergence média Cisco (MCS) et sur certains serveurs tiers. Il est livré avec une suite d'applications vocales et d'utilitaires intégrés, dont Cisco WebAttendant constitué d'une console logicielle d'administration manuelle, d'une application de conférence et d'utilitaires de création de rapports. Pour plus d'informations sur la gestion réseau VoIP, reportez-vous à CiscoWorks Manager IP Telephony Environment Monitor Cisco CallManager version 3.2 est une solution de traitement des appels de téléphonie IP d'entreprise évolutive, hautement disponible et déployable. Les multiples serveurs sont mis en grappe et gérés comme une entité unique, permettant ainsi d'accepter jusqu'à 10000 utilisateurs par grappe. En reliant de multiples grappes, la capacité d'un système comportant 100 sites peut être augmentée jusqu'à près d'un million d'utilisateurs. Cette mise en grappe permet de mettre en commun la puissance de plusieurs serveurs Cisco CallManager répartis, augmentant ainsi l'évolutivité et la disponibilité de ces serveurs pour les téléphones, les passerelles et les applications. La triple redondance de serveurs de traitement des appels améliore grandement la disponibilité générale du système.

32

Caractéristiques principales :

Cisco Call Manager 3.2

- Cisco CallManager est livré avec une suite d'applications vocales permettant d'initier des conférences vocales ou d'obtenir une console d'administration manuelle, évitant ainsi d'avoir recours à du matériel dédié pour le traitement de la voix. - Les services supplémentaires ou les services avancés, tels que la mise en attente, le transfert et la redirection d'appels, les conférences, l'utilisation de plusieurs lignes, la sélection automatique à l'arrivée, la numérotation rapide, le rappel du dernier numéro ou de nombreuses autres fonctions, sont ainsi disponibles sur les téléphones IP et les passerelles. - L'amélioration des fonctions est possible grâce à l'évolutivité du logiciel et permet d'éviter des dépenses excessives en matériel qui sont le lot des systèmes de commutateurs privés classiques. - Cisco CallManager Attendant Console : cette application avec interface Web remplace la classique console d'administration manuelle et permet d'accepter et de répartir rapidement les appels vers les utilisateurs de l'entreprise. Un service d'annuaire intégré permet d'apporter des fonctions de témoin d'appel (BLF) et de sélection directe de poste (DSS) à chaque ligne du système. La console surveille l'état de chaque ligne sans recourir à des équipements de surveillance dédiés, économisant ainsi sur les coûts. - Les applications logicielles, telles que le système de répondeur vocal interactif de Cisco, Cisco IP Contact Center, Cisco Automated Attendant et Cisco SoftPhone, interagissent avec Cisco CallManager via les API de téléphonie.

• IPPC (Cisco IP Contact Center)

IPCC (Cisco IP Contact Center) propose une téléphonie assistée par ordinateur (TAO) réseau/bureau par routage intelligent des appels ainsi qu'une gestion des contacts multimédia pour les agents des centres de contact sur le réseau IP. Grâce à une solution unifiée combinant les fonctionnalités logicielles ACD avec la téléphonie IP, IPCC garantit aux sociétés le déploiement rapide d'une infrastructure distribuée de centre de contacts permettant de prendre en charge l'ensemble de leurs ventes et initiatives de services électroniques. Fonctionnalités principales :

• Intégration d'un commutateur hérité • Option de redondance • Évolutivité totale : de moins de 100 équipements à des milliers d'équipements • Interaction multicanaux - collaboration par interface Web avec fonction IRC et de rappel,

routage des e-mails, messagerie vocale et télécopie. • Liste évolutive des partenaires EcoSystem permettant d'intégrer des applications tierces

essentielles • Prise en charge de centres de contacts multisite, intégration CRM • Enregistrements détaillés des appels de contacts de bout en bout • Bureaux de superviseurs et d'agents communs à tous les produits servant à gérer l'interaction

avec les clients Cisco, tels que les produits Cisco IP ICD Standard, IP Enhanced et Cisco IP Contact Center

• Rapports historiques personnalisés et prédéfinis ; rapports en temps réel intégrés dans les

33

bureaux de superviseurs et d'agents • Prise en charge du traitement personnalisé des appels en attente comprenant la gestion de la

musique d'attente et des messages personnalisés • Affichage standard à l'écran permettant de transmettre à l'agent toute information déjà saisie

concernant l'appelant • Prise en charge complète de l'interaction agent/superviseur via une session IRC • Possibilité de prédéfinir des messages transmis entre agent et superviseur

• Cisco IP ICD (Integrated Contact Distribution)

Cisco IP Integrated Contact Distribution (IP ICD) est un répartiteur automatique d'appels (ACD) économique, simple à installer et à utiliser, destiné aux entreprises. Cisco IP ICD est intégré de manière transparente à toutes les applications de réponse au client, dont Cisco IP IVR (Interactive Voice Response) et Cisco IP AA (Automated Attendant). IP ICD présente de nombreux avantages : ce répartiteur automatique d'appels d'entrée de gamme économique est à la fois simple à installer, administrer et utiliser. Employé conjointement à Cisco IP IVR, il prend en charge les accès multimédia (voix, données et Web) et apporte des outils de personnalisation complète des scripts de gestion des flux d'appels. En outre, il peut être intégré de manière transparente aux applications de réponse au client de Cisco.

IP ICD est disponible en deux versions : Cisco IP ICD Standard et Cisco IP ICD Enhanced. La version Standard convient aux utilisateurs de premier niveau et leur permet de s'affirmer dans le segment de marché des PME.

La version Enhanced, quant à elle, offre un distributeur automatique d'appels (ACD) multifonction convenant plus particulièrement aux centres de contacts de taille moyenne. Cette version fournit également un chemin de migration vers IPCC (IP Contact Center) de Cisco, premier centre de contacts haut de gamme de Cisco. Fonctionnalités principales :

• Administration de Cisco IP ICD par navigateur Web totalement intégrée avec celle de Cisco CallManager

• Enregistrements détaillés des appels de contact de bout en bout ; l'affichage standard à l'écran permet de transmettre à l'agent toute information déjà saisie concernant l'appelant

• Rapports historiques personnalisés ou prédéfinis ; rapports en temps réel intégrés dans les bureaux de superviseurs et d'agents

• Bureaux de superviseurs et d'agents communs à tous les produits servant à gérer l'interaction avec les clients Cisco, tels que les produits Cisco IP ICD Standard, IP Enhanced et Cisco IP Contact Center

• Invite et points de files d'attentes d'appels IP complets, regroupement des fonctionnalités d'interaction vocale

• Prise en charge du traitement personnalisé des appels en attente comprenant la gestion de la musique d'attente et des messages personnalisés

• Prise en charge complète de l'interaction agent/superviseur via la fonction IRC, possibilité de prédéfinir des messages transmis entre agent et superviseur

34

• Équipement d'accès intégré de la gamme Cisco IAD 2400 avec service de téléphonie IOS (ITS)

Les équipements d'accès intégrés de la gamme Cisco IAD 2400 combinent les services de données, voix et vidéo sur les réseaux IP et ATM et constituent des solutions efficaces et économiques permettant de fournir des services vocaux et des accès Internet à haut débit pour les PME, le tout dans un système n'occupant qu'une unité d'armoire (1 RU). Associé au logiciel optionnel ITS, l'équipement IAD 2400 est une solution idéale pour fournir des services de téléphonie IP sur un réseau local convergent au sein d'un environnement de bureau réduit (5 à 20 téléphones) ne nécessitant pas les fonctionnalités de CallManager.

Caractéristiques principales :

Gamme Cisco IAD 2400

Équipement d'accès professionnel complètement intégré

- Fonctions reposant sur le service de téléphonie IOS (ITS), idéal pour les petits bureaux (5 à 20 téléphones) ne nécessitant pas les fonctionnalités de Cisco CallManager

- Prise en charge des téléphones classiques et des téléphones IP sur une seule plate -forme

- Modèles de ports voix analogiques 8 FXS/16 FXS/16FXS+8FXO et port voix numérique T1

- Interfaces WAN de type T1, ADSL et G.shdsl

Fonctionnalités principales :

• Combine des services d'accès Internet à haut débit et des services vocaux de qualité téléphonique sur une seule plate-forme IOS (le service ITS existe depuis la version 12.1(5)YD de Cisco IOS)

• TDM, VoIP et VoATM (AAL2) tous disponibles sur une seule plate-forme • Migration transparente des clients de réseaux GR-303 TDM vers des réseaux GR-303 par

paquets ou des réseaux utilisant des agents d'appel • Possibilité d'installation et de configuration automatisée à distance via le protocole SNAP

(Simple Network Auto Provisioning) et l'outil Cisco Configuration Express

35

Caractéristiques détaillées :

• Passerelles vocales Cisco

Les passerelles vocales sont reliées directement aux réseaux téléphoniques privés ou publics pour assurer le trafic voix sur les réseaux IP, en convertissant les appels IP en appels téléphoniques standard et inversement. Elles permettent l'échange entre la téléphonie par paquets et la téléphonie classique, telle que les réseaux téléphoniques publics ou privés, les télécopieurs, etc.

L'ensemble de la gamme des routeurs multiservice Cisco apporte également des fonctionnalités de passerelle vocale analogique et numérique grâce à des modules réseaux et à des cartes d'interface vocale adaptés, tels que le module d'interface analogique Catalyst 6000 FXS.

Cisco fournit les passerelles vocales dédiées suivantes : Cisco VG200 et Cisco VG248. Caractéristiques principales : Passerelle vocale Cisco VG200

- Conception et validation exclusivement destinées aux environnements AVVID de CallManager - Particulièrement adaptée aux petits bureaux et aux applications d'entreprise - Prise en charge des protocoles H.323 et MGCP, ainsi que des codecs vocaux G.711, G.729, G.723.1 - Services de transcodage et de téléconférence avec le module optionnel DSP de mise en grappe en réseau - Attribution automatique d'adresse IP et identification auprès de CallManager grâce au protocole DHCP - Point de configuration et d'administration unique via Cisco CallManager - Administration via SNMP ou ligne de commande par Telnet, gestion des téléchargements de logiciels par TFTP

IAD 2421 IAD 2423 IAD 2424 Ports LAN fixes 1 port Ethernet

(10Base-T) Idem IAD 2421 Idem IAD 2421

Ports WAN fixes T1, 1 port 1 port ADSL 1 port G.shdsl

Ports vocaux Analogiques : 8FXS, 16FXS,

16FXS+8FXO, Numérique : 1 T1

Analogiques : 8FXS Analogiques : 8FXS, 16FXS, 16FXS+8FXO,

Numérique : 1 T1

Vitesse du processeur (type)

80 MHz (RISC) Idem IAD 2421 Idem IAD 2421

Mémoire flash 16 Mo (par défaut), 32 Mo (max)

16 Mo (par défaut), 32 Mo (max)

16 Mo (par défaut), 32 Mo (max)

Mémoire DRAM 64 Mo 64 Mo 64 Mo

Dimensions (H x L x P)

4,32 x 44,45 x 28,70 cm.

Idem IAD 2421 Idem IAD 2421

36

- Accès RNIS primaire (T1/E1) (côtés réseau et utilisateur) ; T1/E1-CAS, T1/E1 QSIG avec MGCP, BRI, E&M, FXS et FXO (démarrage en boucle et par terminaison) - Services complémentaires (maintien d'appels, transfert d'appels, téléconférence, mise en attente, etc.)

Passerelle vocale Cisco VG248

La passerelle vocale Cisco VG248 est un équipement occupant 1 unité d'armoire permettant l'utilisation de 48 équipements analogiques (téléphones, fax et modems) avec Cisco Call Manager. Cette passerelle permet aux organisations possédant un parc important d'appareils téléphoniques analogiques (hôtels, universités, hôpitaux, etc.) de déployer la téléphonie sur IP tout en protégeant les investissements antérieurs. Les lignes analogiques sont multifonction (identification d'appelant, indicateur de message en attente, codes) et le prix par port est plus compétitif. La passerelle vocale VG248 permet de générer un protocole SMDI pour les ports analogiques associés, autorisant ainsi l'établissement d'une connexion à un réseau Cisco Call Manager via des systèmes de messageries vocales traditionnels. La passerelle permet de partager les systèmes de messageries vocales SMDI entre Cisco Call Manager et les PBX traditionnels.

37

CCoonncclluussiioonn

VoIP n'a pas encore pu prendre son essor pour des raisons techniques qui constituent encore un lourd handicap.

• Fiabilité

VoIP n'est pas encore suffisamment fiable et le protocole IP en est le principal responsable. De larges segments de la population internet utilisent des versions IP, comme la version IPv4 qui ne fournit pas un bon support pour un routage fiable. Or la question est la suivante : combien de temps accepte-t-on d'attendre la tonalité lorsque l'on décroche le téléphone ? Tant que IPv6, la future génération de protocole IP, n'est pas largement implémentée, VoIP ne sera pas une option intéressante pour les entreprises. Il faudrait l'utiliser avec d'autres solutions hybrides qui combinent l'IP avec des protocoles plus fiables, comme l'ATM. Bien qu'IPv6 soit déjà intégré à un certain nombre de solutions internet et à des systèmes d'exploitation comme Linux, peu d'entreprises ont migré de l'IPv4 à l'IPv6. Mais cela devrait changer dans les trois années à venir, où nous assisterons à l'utilisation conjointe de IPv4 et de IPv6 sur internet, le temps que les entreprises mettent à jour leurs équipements.

• Une qualité de son médiocre

Pour le moment, il n'y a pas de garantie de qualité sonore pour la VoIP. Elle est souvent plus mauvaise que celle d'un téléphone cellulaire utilisé dans une zone à la couverture médiocre... Les temps de latence sur le réseau, les problèmes de compression et un résultat sonore peu fidèle affaiblissent grandement la qualité sonore du VoIP. La tâche devrait être facilitée avec l'implémentation à grande échelle d'IPv6 d'ici les trois prochaines années, et l'établissement de nouveaux standards par des organismes regroupant des industriels des télécoms.

• Améliorer l'utilisation

VoIP doit offrir des fonctionnalités telles que la mise en attente d'un appel et l'identification de l'appelant, des services de base de la téléphonie traditionnelle. Aujourd'hui, l'implémentation de VoIP nécessite souvent que l'appelant tape jusqu'à 25 chiffres (numéro d'accès, numéro d'identification personnel, code et numéro de téléphone du destinataire) avant de pouvoir passer son appel. Tant que VoIP ne peut pas proposer la facilité d'utilisation et les services fournis par les systèmes vocaux traditionnels, il aura du mal à convaincre les entreprises.

• Localisation

Le nombre et la localisation des passerelles IP, qui fournissent les services de routage VoIP, limitent également le développement du VoIP. Les fournisseurs de service doivent supporter un nombre suffisant de passerelles situées dans les zones de gros trafic pour réussir à faire des économies de coûts. Mais ce sont notamment les clients internationaux qui seront pénalisés : le manque de passerelles signifie que les fournisseurs d'accès internet sont obligés

38

d'acheter et de revendre des services de routage via une autre entreprise (particulièrement pour les routages longue distance). Les coûts de la solution VoIP augmentent d'autant.

• Standards

Le VoIP dépend principalement du standard téléphonie H.323, qui permet de mélanger la voix, la vidéo et les données. Cependant, le H.323 est un standard globalement difficile à implémenter pour les fournisseurs VoIP. Bien souvent, ils choisissent une solution propriétaire afin d'obtenir un déploiement plus rapide. Ce qui peut entraîner des problèmes d'interopérabilité pour les utilisateurs.

• Support administratif

Les systèmes administratifs de comptabilité, de facturation et de gestion du réseau pour VoIP doivent être implémentés à des niveaux qui sont au moins parallèles à ceux de la téléphonie traditionnelle. Mais pour l'instant, ces derniers détiennent l'avantage dans le domaine des systèmes administratifs évolutifs qui gèrent les services administratifs.