UNIVERSITE HENRI POINCARE NANCY I

Xavier AMEZIANE Sbastien LEVEQUE Lionel ZEINER

Ecole Suprieure dInformatique et Applications de Lorraine

ESIAL Troisime anne Anne universitaire 2002 2003

PROJET RESEAUX
Voice over Internet Protocol

Sommaire
Introduction 1. Ide 2.Le but : une rduction des cots attendus 3. La voix 4. Difficults associes la transmission de la voix sur IP 4.1 Comparaison IP - Tlcoms 4.2 Le transfert de la voix : un chemin sem dembches 4.2.1 Analyse des dlais 4.2.2 Analyse des pertes 4.2.3 Conclusions 5. Principe de fonctionnement 6. Les protocoles 6.1 Le protocole H.323 6.2 Le protocole SIP 6.2.1 Les fonctionnalits utilises par SIP 6.2.2 Les composants de SIP 6.2.3 Utilisation de SIP 6.2.4 Les protocoles utiliss 6.2.5 Les messages SIP 6.2.6 Exemples de transactions 6.2.7 Conclusions 6.3 Le protocole MGCP 6.3.1 Gnralits 6.3.2 Fonctionnement de MGCP 7. Matriels ncessaires la mise en place de la VoIP 7.1 Introduction 7.2 Approche centralise contre approche distribue 7.3 Exemple de matriel propos par le constructeur Cisco 7.4 Dtail des matriels Cisco utiliser Conclusion 2 3 3 3 4 4 5 5 7 7 7 8 8 9 10 10 11 11 12 17 19 20 20 21 27 27 27 28 30 37

Introduction
Avec plus de 100 millions d'utilisateurs au niveau mondial, Internet reprsente l'vidence un phnomne en forte croissance (exponentielle depuis plusieurs annes) dans le domaine des nouveaux moyens de communication. Bien que lInternet se dveloppe rapidement, le tlphone reste encore le favori du public en matire de communication. Plus convivial car le contact est presque rel, il reste en plus simple d'utilisation. Pourtant, il fusionne de plus en plus avec le matriel informatique. Les utilisateurs du tlphone ont depuis toujours t habitus payer leurs communications en fonction de la distance et de la dure de celles-ci, mais depuis l'mergence et l'extraordinaire dveloppement de l'Internet, les mentalits changent et on s'habitue au principe de rseau informatique et de son accs forfaitaire. On peut ainsi communiquer, par cran interpos, n'importe o dans le monde sans aucune considration financire puisque le prix est toujours celui d'une communication locale. C'est videmment cet aspect financier qui est l'origine de la tlphonie sur IP. Car c'est une rvolution au niveau des tarifs qui s'annoncent dmesurment bas.

1. Ide
Voice over IP : voix sur IP. Transport de la voix sur des rseaux de donnes IP. La voix est numrise, enferme dans des paquets de donnes, puis transmise sur le rseau. Confondue parfois avec la tlphonie sur IP (ToIP : telephony on IP), terme dsignant une architecture tout-IP et ses services de tlphonie associs. L'enjeu de la voix sur IP est de taille : tlphoner en utilisant les rseaux de donnes traditionnels. la cl, une convergence voix-donnes-images autour d'un protocole unique (IP), une rduction des cots et la centralisation des infrastructures dans un unique rseau. Pour le grand public, la tlphonie sur IP dsigne avant tout les logiciels ou les offres permettant de coder la voix sur un rseau IP public. Avec videmment une qualit et une scurit minimales. Dans le monde de l'entreprise, qualit de service oblige, la VoIP ne se conoit aujourd'hui que dans le cadre d'un rseau priv, WAN (Wide Area Network) ou LAN (Local Area Network).

2. Le but : une rduction des cots attendue

Premier bnfice attendu de la VoIP : l'allgement des factures tlphoniques intraentreprises, voire entreprises- fournisseurs-clients dans le cas de rseaux tendus. Imaginons, par exemple, la socit Durand disposant de deux sites de production, l'un Paris, l'autre Lyon. Pour tout ce qui concerne le transfert de donnes informatiques, les deux entits sont relies par une ligne spcialise. Pour les communications tlphoniques, chacune dispose d'une infrastructure tlcoms traditionnelle construite autour d'un PBX (autocommutateur tlphonique interne). Lorsqu'un salari parisien tlphone l'un de ses collgues lyonnais, l'appel transite par le PBX avant d'tre achemin jusqu' Lyon par le rseau tlphonique traditionnel ou RTC (rseau tlphonique commut). Comment la socit Durand peut-elle passer la VoIP ? En reliant directement, dans un premier temps, ses deux PBX par la ligne spcialise. Le signal de voix analogique est alors compress et cod pour tre insr dans des paquets IP, transmis sur le lien, puis dcod et dcompress l'autre extrmit. Mais l'entreprise Durand peut aller plus loin. Elle peut faire le choix du tout-IP et miser sur la tlphonie sur IP. Elle pourra alors remplacer ses anciens combins tlphoniques par des terminaux IP (tlphones IP ou PC quips d'un logiciel de tlphonie). Cet exemple se place dans un contexte de WAN ou de rseau tendu. Reste qu'avec la chute actuelle des tarifs tlphoniques, un changement d'architecture n'est pas toujours facile justifier. Certains dfendent nanmoins que la tlphonie sur IP est dj rentable au niveau d'un LAN ou rseau local. Ici, le surcot de la tlphonie classique est mettre au compte du dplacement frquent des tlphones (dmnagements, amnagements de nouveaux bureaux...) et la gestion du cblage. Avec la tlphonie sur IP, ce souci disparat car les terminaux, dots chacun d'une adresse IP, peuvent tre connects instantanment n'importe quel endroit du rseau.

3. La voix
Le systme vocal est complexe et bas sur des ondes sonores de frquences diffrentes. Le spectre des frquences perues par loreille humaine stale de 100 Hz 20 kHz. Cette fourchette est, cependant, rduire si lon veut distinguer les frquences utiles des frquences audibles. En effet, la quasi-totalit dun message sonore est comprhensible dans

la fourchette 300-3400 Hz. Cette dernire correspond, dailleurs, celle utilise par le tlphone standard. Une conversation entre deux personnes respecte deux principes : intelligibilit et interactivit. Couper la parole quelquun ne se fait pas, mais cest un gage dinteractivit et de dialogue. En terme de transmission numrique, cela se traduit par le terme duplex. Une conversation full duplex assure cette interactivit car chaque locuteur peut parler en mme temps, ce qui arrive quand deux personnes parlent de leur propre exprience sans scouter... 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 dlais dans le transport de la voix (avec le tlphone, par exemple). Les mesures effectues montrent quun temps de transit infrieur 150 ms garantit un dialogue actif. Jusqu 400 ms (limite suprieure) le dialogue reste tout de mme assez ractif. Au-del de cette limite le contradicteur aura limpression de parler dans le vide.

4. Difficults associes la transmission de la voix sur IP

Afin de bien percevoir les difficults associes au transport de la voix sur IP, un comparatif entre la commutation de circuits des tlcoms et la commutation de paquets dIP est ncessaire. Ensuite, une tude des diffrents dlais associs VoIP permettra de comprendre les facteurs incompressibles ngatifs pour la communication.

4.1 Comparaison IP Tlcoms

Les deux approches IP et tlcoms sont pratiquement opposes. O IP est simple et dbrouillard, les tlcoms sont complexes et figs. Le rseau qui est utilis par les tlcoms est le rseau X25. Le tableau suivant tabli la comparaison entre ces deux systmes sur diffrents points :

4.2 Le transfert de la voix : un chemin sem dembches

Le tableau prcdent fait un tat des lieux des diffrences entre IP et X25. Il est cependant ncessaire d'expliquer comment arrivent ses dfauts de transmission. Voici pourquoi cette partie rpertorie les trois principales caus es des difficults et des limites associes VoIP : Dlai : temps de transmission d'un paquet (doit rester infrieur 400ms pour respecter les contraintes d'une conversation interactive). Gigue : variation de dlai (ncessite 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 rduite, soit inhibe).

Le schma ci-dessus reprend les difficults voques et permet de comprendre quels sont les effets indsirables impliqus. 4.2.1 Analyse des dlais Quantifier le dlai de transmission sur le rseau de manire 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 dtailler certains dlais inhrents au rseau :

Dlais de l'metteur : Numrisation et codage : temps mis par une carte son ou une passerelle pour numriser et coder un signal initialement analogique. Compression qui se dcompose en trois parties : o Dlai de trame : contrairement la numrisation d'un signal qui se fait en continue, la compression porte sur une certaine longueur de donnes. Attendre ces informations induit un temps non nul de traitement o Dlai d'encodage : la compression par synthse s'appuyant sur la prdiction, ce dlai est ncessaire l'encodeur pour savoir, pendant qu'il est en fonctionnement comment volue le signal. o Dlai de traitement : temps mis par l'algorithme pour compresser une trame. Il dpend du processeur et de l'algorithme utilis. Mise en paquets : intervalle de temps pendant lequel l'application constitue un paquet (cration de l'en-tte, remplissage des donnes). Transmission : ce temps dpend de la configuration dans laquelle on se trouve. A savoir soit on est reli par modem soit par accs direct sur un LAN-WAN.

Dlais rseau : Propagation : sur un rseau 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 rseau diffrents temps peuvent tre indexs.

Dlais du rcepteur (ce sont les mmes que pour l'metteur) : Rception. Buffer de gigue : cette mmoire tampon permet de resynchroniser les paquets arrivant avec des dlais variables. Elle sert donc compenser les dcalages et remettre en ordre les paquets. Dpaquetisation. Dcompression.
6

Dcodage et conversion numrique analogique.

Jusqu' prsent les mesures effectues avec une solution tlphone tlphone (via IP), sur un rseau bien gr et surdimensionn (en bande passante), montrent un dlai total de 200 ms. 4.2.2 Analyse des pertes La perte d'un paquet occasionne un manque d'information lors de la rception 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 intgrante du concept. En effet les routeurs sont obligs (avec l'algorithme Random Early Detection) de dtruire des paquets afin d'anticiper d'ventuelles congestions. Il existe principalement quatre causes de perte de paquet : Dure de vie puise (TTL = 0). Retard la rception suprieur au buffer de gigue. Destruction par un module congestionn. Invalidit du paquet due des dfauts de transmission. 4.2.3 Conclusions Toutes ces contraintes et dfauts inhrents IP sont les fondements des difficults rencontres par le concept VoIP.

5. Principe de fonctionnement
Tout projet de VoIP ou de tlphonie sur IP ncessite une transformation du PBX de l'entreprise. Une premire solution consiste y insrer une carte IP faisant office de passerelle entre le rseau tlphonique et le rseau IP. Cette dmarche prsente l'avantage de prserver l'existant et les postes analogiques. Seconde possibilit : remplacer le PBX par un IPBX, un matriel profil pour le tout-IP et qui implique un dploiement massif de terminaux IP. Ces deux solutions techniques intgrent diffrentes fonctions de base, dont une unit de contrle d'accs (gatekeeper), qui gre l'identification des appels, la traduction du numro de tlphone en adresse IP, et ventuellement la dfinition des rgles d'appel. Viennent ensuite une passerelle (gateway), charge de l'interconnexion entre quipements rseaux htrognes (tlphone analogique ou numrique, carte RNIS...), et enfin une unit de contrle (MCU Multipoint Controller Unit) grant les sessions multicast. Aujourd'hui, l'un des freins de la tlphonie sur IP rside dans l'absence de standards communs tous les constructeurs. Mme 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 matriels. Enfin, MGCP (Media Gateway Control Protocol), autre standard de l'IETF, peine aussi s'imposer. Une fois la communication tablie, le transport et le contrle des flux de donnes sont assurs par deux autres protocoles : RTP (Realtime Transport Protocol) et RTCP (Realtime Transport Control Protocol). Le premier permet de reconstituer la base de temps, de dtecter les pertes et d'identifier le contenu des paquets pour leur transmission scurise. Le

second, RTCP fournit, entre autres, des informations sur la qualit de la session. Lorsque les paquets de voix transitent sur le rseau, les paramtres matriser sont la latence (dlai de transmission), la gigue (variation du dlai de transmission), la perte des paquets (au-del de 20 %, le signal n'est plus audible). Pour s'en assurer, les diffrents quipements du rseau (postes clients, routeurs...) doivent tre dots de dispositifs de QoS (qualit de service). La priorit est ainsi donne aux paquets de voix. Sur Internet, l'htrognit des matriels rseau impliqus empche toute matrise 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 quil existe trois principaux protocoles utiliss pour la voix sur IP : Le protocole H.323 (de lITU-T) Le protocole SIP (de lIETF) Le protocole MGCP (de lIETF)

6.1Le 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 laudio, de la vido ou de donnes travers des rseaux IP. En se rfrant ce standard, les produits de constructeurs diffrents sont censs interoprer, sans souci de compatibilit. H.323 est un ensemble de recommandations venant le ITU-T, qui dfinissent des standards pour le transport de donnes multimdia sur des rseaux locaux qui ne fournissent pas une qualit de service garantie. La premire version a t approuve en 1996 par le Study Group 16 de lITU-T, la version 2 layant t en janvier 1998. Ce standard a une tendue trs large, incluant la fois des stations de visio confrence que des PC multimdia, en mode point point ou en mode multi points. H.323 dfinit galement le contrle des appels, la gestion de la bande passante, les interfaces entre le(s) LAN(s) et les autres rseaux. H.323 dfinit quatre composants majeurs qui interagissent dans un rseau de paquets : les endpoints, qui initient un appel audio, vido ou de visio confrence une passerelle ( gateway ) pour linteraction avec un rseau tlphonique commut un lment optionnel ( gatekeeper ) qui permet la connectivit entre des quipements ISDN externes qui appellent dans le rseau de paquets pour atteindre un lment H.323 les MCUs ( Multipoint Control Units ) pour la conduite de visio confrences 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 dfaut pour les applications de tlphonie dans le monde Internet. H.323 fait partie dune srie plus large de standards de communication qui permettent la visioconfrence travers un ensemble de rseaux. Connus sous le terme gnrique, H.32x, cette srie inclut notamment H.320 et H.324, qui adressent les communications dans le monde ISDN dune part, et pour les rseaux RTCs dautre part.

Schma de la pile protocolaire H.323 :

Architecture globale dH.323 :

6.2 Le protocole SIP

Cette partie se concentre sur le protocole douverture de session (SIP), qui est un protocole rcent publi par lI.E.T.F. (Internet Engineering Task Force) sous la RFC (Request For Comments) 2543 en mars 1999. La RFC 2543 prsente la source dinformation la plus complte sur le sujet. Selon la RFC 2543, le protocole dinitiation de session (SIP) est un protocole de signalisation appartenant la couche application du modle OSI. Son rle est douvrir, modifier et librer les sessions ou appels ouverts entre un ou plusieurs utilisateurs. Pour ouvrir une session, lutilisateur met une invitation transportant un descripteur de session permettant aux utilisateurs souhaitant communiquer de saccorder sur la compatibilit de leur mdia. SIP

peut relier des stations mobiles en transmettant ou redirigeant les requtes vers la position courante de la station appele. 6.2.1 Les fonctions utilises par SIP Pour tablir et terminer des communications multimdia, SIP utilise les 5 fonctions suivantes : User location : permet de localiser le poste terminal utilis pour communiquer User capabilities : dtermine quels mdia vont tre changs(voix, vido, donnes) ainsi que les paramtres associs User availability : dtermine si le poste appel souhaite communiquer et autorise lappelant la contacter Call setup ou " ringing ": avertit les parties appelant et appel de la demande douverture de session (sonnerie ou message de rception dappel) et mise en place des paramtres dappel Call handling : gre le transfert et la fermeture des appels 6.2.2 Les composants de SIP Comme HTTP, SIP propose ltablissement, la modification et la clture de sessions en mode client / serve ur, cest dire lchange de requtes cot client et rponse cot serveur. Exemple :

User Agent SIP A 1

Serveur SIP INVITE 2 INVITE

User Agent SIP B

OK

OK

ACK

ACK

Dans un systme SIP on trouve deux composantes, les users agents (U.A.S et U.A.C) et un rseau de serveurs. lU.A.S (User Agent Server) : reprsente lagent de la partie appele, cest une application de type serveur qui contacte lutilisateur lorsquune requte SIP est reue. Et elle renvoie une rponse au nom de lutilisateur lU.A.C (User Agent Client) : reprsente lagent de la partie appelante, cest une application de type client qui initie les requtes le relais mandataire ou P.S. (Proxy Server) : auquel est reli un terminal fixe ou mobile (lors de son dplacement, le terminal est reli au PS le plus proche et change

10

constamment de PS) agit la fois comme client et serveur. Un tel serveur peut interprter et modifier les messages quil reoit avant de les retransmettre le R.S (Redirect Server) : ralise simplement une association (mapping) dadresses vers une ou plusieurs nouvelles adresses ( lorsquun 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 relis les destinataires - ). Notons quun Redirect Server est consult par l'UAC comme un simple serveur et ne peut mettre de requtes 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 assure par le service de localisation le RG (Registrar) est un serveur qui accepte les requtes REGISTER et offre galement un service de localisation comme le LS. Chaque PS ou RS est gnralement reli un Registrar. 6.2.3 Utilisation de SIP

Louverture dune session laide du protocole SIP peut seffectuer de faon directe entre deux User Agents qui jouent le rle de client et de serveur ou de faon indirecte au travers dun serveur proxy. Dans ce dernier cas, le serveur en charge la localisation du serveur B (exemple) dont ladresse est pass dans le message INVITE. Dans le cas de changement de localisation , le serveur proxy est renseign sur ladresse de lutilisateur laide du serveur de localisation. Et le serveur proxy adresse un message 302 MOVE TEMPORARILY avec les nouvelles coordonnes de localisation 6.2.4 Les protocoles utiliss Larchitecture en couches de SIP, telle que la prsente le modle OSI, incorpore les protocoles : RTP, RSVP, RTCP, SAP et SDP. SDP Media

RTSP

SIP

RTCP

RTP

RSVP

TCP

UDP

IPV4,IPV6

RSVP est un protocole utilis pour rserver les ressources rseaux sur IP avec une excellente qualit de service(QoS) R.T.P.(Real-time Transport Protocol) pour transporter des informations en temps rel avec une excellente qualit de services
11

R.T.C.P.(Real-Time streaming Control Protocol) pour assurer le contrle de flux des donnes multimdia S.A.P. (Session Announcement Protocol) pour prciser si les sessions mutimedia ouvertes S.D.P.(Session Description Protocol) est un protocole de description des sessions multimdia

Exemple de SDP pour la tlphonie sur internet :

6.2.5 Les messages SIP Contrairement au protocole HTTP, qui est bas sur TCP, SIP utilise UDP pour les applications multimdia. 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-ttes compris, ne doivent pas excder une certaine longueur(M.T.U. pour Maximum Transmission Unit). Si la MTU est inconnue, elle est de 1500 octets par dfaut. Cette taille permet lencapsulation des datagrammes UDP ou segments TCP dans des paquets IP sans fragmentation. Un message SIP peut tre la fois une requte dun client vers un serveur ou une rponse dun serveur vers un client. Ces deux types de messages SIP utilisent le format suivant : Ligne de requte ou ligne dtat Entte de requte ou de rponse CRLF : Balise indiquant le dbut de corps du message Corps du message 6.2.5.1 Les requtes et les rponses SIP Les requtes SIP Les mthodes utilises dans une requte SIP sont :

12

INVITE : indique que lapplication ou utilisateur est invit participer une session. Le corps du message contient la description de la session (mdia supports par lappelant entre autres). ACK : confirme que le client a reu une rponse dfinitive une requte INVITE. OPTIONS : un PS en mesure de contacter lUAS appel, doit rpondre une requte OPTIONS en prcisant ses capacits contacter lUAS. BYE : est utilise par lUAS de l'appel pour signaler au PS local quil ne souhaite plus participer la session. CANCEL : la requte CANCEL permet dannuler une requte non valide par une rponse finale dtat. REGISTER : cette mthode est utilise par le client pour enregistrer ladresse liste dans lURL TO par le serveur auquel il est reli.

Les rponses SIP Une rponse une requte est caractrise, par un code et un motif , appels code dtat et reason phrase respectivement. Un code dtat est un entier cod sur 3 bits indiquant un rsultat lissue de la rception dune requte. Ce rsultat est prcis par une phrase, textbased (UTF-8), expliquant le motif du refus ou de lacceptation de la requte. Le code dtat est donc destin lautomate grant ltablissement des sessions SIP et les motifs aux programmeurs. Il existe 6 classes de rponses et donc de codes dtat, reprsentes par le premier bit : 1xx = Information : la requte a t reue et continue tre traite 2xx = Succs : laction a t reue avec succs, comprise et accepte 3xx = Redirection : une autre action doit tre mene afin de valider la requte 4xx = Erreur du client : la requte contient une syntaxe ronne ou ne peut pas tre traite par ce serveur 5xx = Erreur du serveur : le serveur na pas russi traiter une requte apparemment correcte 6xx = Echec gnral : la requte ne peut tre traite par aucun serveur Exemple :

13

Requte 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 V=0 C= IN IP4 mars.ausys.se

Rponse la requte INVITE

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

O=mattias 52655765 2687637 IN IP4 172.2.2.5 M=audio 3456 RTP/AVP 0 3 4 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-ttes SIP Les diffrents champs d'en-tte qu'utilise SIP ne ncessitent pas d'ordre particulier sauf dans le cas de l'en-tte gnral Via o l'ordre des champs d'en-tte importe. En particulier, l'on distingue les champs d'en-ttes des messages transmis saut par saut (c'est--dire qui sont interprts et peuvent tre modifis ou ajouts par tous les serveurs qu'ils traversent) des enttes des messages transmis de bout en bout(interprts par les metteurs et destinataires uniquement et non modifiables par les serveurs traverss). Les champs d'en-tte saut par saut doivent apparatre avant les champs d'en-tte de bout en bout. Les PS ne doivent pas rordonner les champs d'en-tte mais peuvent ajouter ventuellement des champs Via ou autres champs de type "saut par saut". Chaque mthode (ACK, BYE, CANCEL, INVITE, OPTIONS, REGISTER) require, ne supporte pas ou supporte de faon optionnelle certains champs d'en-tte. Par exemple, les champs d'en-tte CALL-ID, Cseq, FROM, TO et Via sont requis par toutes les mthodes(dans le cas de la mthode OPTIONS, il faut ajouter en plus le champ d'en-tte Allow). Ces champs d'en-tte sont de type "de bout en bout".

Il existe 4 types de champs d'en-tte: En-tte gnral sapplique la fois aux messages de requte et de rponse : 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-tte dentit dfinit le type d'informations contenues dans le Corps du message ou la ressource identifie par la requte en l'absence du Corps du message : ContentEncoding ou Content-Lenght ou Content- Type

14

En-tte de requte Le champ d'en-tte de requte autorise le client ajouter des informations concernant sa requte et lui- mme 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-tte de rponse Le champ d'en-tte de rponse autorise le serveur ajouter des informations concernant sa rponse, qui ne peuvent pas tre places dans la ligne d'tat, sur lui- mme et sur l'accs la ressource identifie par la requte URI : Allow ou Proxy-Authorization ou Retry-After ou Server ou Unsupported ou Warning ou WWW-Authenticate.

Dans le tableau suivant on donnera le dtail dutilisations de ces diffrents champs : Champs Accept Utilisations Utilis dans les messages INVITE, OPTIONS et REGISTER qui permet d'indiquer les types de mdia qui seront accepts dans la rponse ce message. Conditionne la rponse car il dtermine quels codages text-based y seront accepts. Il permet au client dindiquer au serveur quel langage utiliser dans le corps du message de la rponse au client. Indique les mthodes valides supportes par les entits identifies par la requte URI. Champ optionnel inclure par l'utilisateur souhaitant s'authentifier vis vis du serveur auquel il est reli Identifie une invitation prcise ou tous les enregistrements dun client particulier. Champ pouvant apparatre dans les requtes INVITE, ACK et REGISTER ou dans les rponses de codes 1xx, 2xx, 3xx et 485. Il fournit en gnral lURL o l'utilisateur pourra Indique le code utilis pour crire et lire l'en-tte d'entit. Ainsi le serveur qui reoit le message sait quel mcanisme de dcodage appliquer pour lire le Content-Type dcrit ci-dessus et peut connatre le type de mdia utilis. Ce champ est trs utile si l'on veut compresser les en-ttes sans perdre les informations prcieuses qu'ils contiennent Il indique simplement la taille du Corps du message envoy, en nombre dcimal d'octets. Il indique les types de mdia utiliss dans le Corps du message envoy.

Accept-Encoding

Accept-Language

Allow

Authorization Call-ID Contact

Content-Encoding

Content-Length

Content-Type

15

Cseq

Date

Chaque requte doit obligatoirement contenir un numro de squence Cseq (entier non sign de 32 bits). Le Cseq initial est choisi arbitrairement par celui qui envoie la requte INVITE mais doit toujours tre infrieur 2^31. donne la date dmission de la requte ou de la rponse. Les retransmissions possdent la mme date que la requte ou rponse dorigine. Ce champ spcifie si le message est crypt et suivant quel cryptage. donne la dure au-del de laquelle le message expire. indique la personne l'origine du message Le client utilise ce champ lorsqu'il veut que le chemin compris dans l'En- Tte VIA soit cach aux prochains Proxy Servers que traversera le message. utilis pour limiter le nombre de PS ou passerelles que la requte peut traverser jusquau prochain serveur dans le sens de l'UAC vers l'UAS (downstream). Prcise le nom de lorganisation laquelle lentit dont mane la requte ou la rponse appartient Indique le niveau durgence de la requte, tel quil est peru par le client. Ce champ doit tre rempli dans une rponse Proxy Authentification Required (code 407). Permet au client de sidentifier dans sa requte en destination dun PS le lui ayant demand. Indique quels champs den-tte le PS supporte. Ce champ permet de mmoriser un chemin pour faciliter l'acheminement de la rponse. Chaque Proxy Serveur travers ajoute son adresse dans ce champ en dbut de liste. Le serveur appel copie cette liste, sans la changer, dans l'en-tte Route de sa rponse. La premire entre est ainsi l'adresse du serveur le plus proche de celui qui rpond. le client utilise cet en-tte dans sa requte pour dterminer la cl a utilis pour crypter la rponse. ce champ n'est utilis que dans les rponses Service Unavailable(code 503), Not Found (code 404), Busy (code 600) ou bien Decline (code 603) pour indiquer l'emetteur de la requte quand est-ce qu'un service "normal" pourra reprendre. Il contient une date ou un nombre en dcimal de secondes. Il contient les informations sur les softwares utiliss par les

Encryption Expires From Hide

Max-Forwards

Organization Priority

Proxy-Authenticate

Proxy-Authorization

Proxy-Require Record-Route

Response-Key

Retry-After

Server

16

Subject

UAS. Rsum ou nature de l'appel qui peut permettre de le filtrer sans avoir lire la description de la session. Prcise l'instant (date) o le client a envoy la requte au serveur. C'est l'adresse du destinataire. Ce champ est bien sr obligatoire. Liste quelles configurations ne sont pas supportes par le serveur. Contient des informations sur le terminal de l'utilisateur (UAC/UAS) lorigine de la requte. Contient les adresses des serveurs (PS) que traverse la requte. Les avertissements sont contenus dans les rponses dans le langage le plus comprhensible pour l'utilisateur. Doit tre inclus dans une rponse Unauthorized (code 401).

Timestamp To

Unsupported

User-Agent

Via Warning WWW-Authenticate

Contrairement aux protocoles standards tels que IP ou TCP, o le format des paquets ou segments est bien dtermin, le format des messages SIP nest pas standard. Les champs den-tte sont choisis " la carte " selon un panel de champs. Lorsque les messages SIP sont transports par UDP, avec authentification et une description de session complexe, il arrive que la taille du message SIP de requte ou rponse dpasse la MTU. Pour rsoudre ce problme, un format compact a t dfini utilisant des abrviations pour les champs den-tte suivants : Champ den-tte Content-Type Content - Encoding From CALL-ID Contact Content-Length Subject To Via Abrviation associe C E F I M(pour " moved ") L S T V

Les clients doivent tre capables de mlanger des champs den-tte de messages courts (format normal) avec ceux de messages longs (format compact) en utilisant les mmes requtes. Les serveurs doivent accepter ces deux formats la fois. 6.2.6 Exemples de transactions Pour faire appel SIP, lapplication de lUAC appelant envoie une requte INVITE au Proxy Server (PS) auquel il est reli. Ce serveur, via d'autres PS, transmet cette requte l'UAS auquel est reli lappel. Cette requte demande lappel sil veut rejoindre un forum

17

de discussion, assister une visioconfrence ou tablir simplement une communication prive avec lappelant. Si lappel est daccord, il renvoie une rponse OK (code 200) lappelant qui confirme alors quil a bien reu la rponse de lappelant. Pour cela, il envoie une requte ACK, acquittement (acknoledgement) lappel. De la mme manire, si lutilisateur souhaite se dconnecter, lapplication de lutilisateur met une requte BYE au lieu de ACK. La requte INVITE contient la description de la session ouverte qui stipule quels sont les mdias et formats des messages SIP utiliss (protocole SDP) . Pour une communication unicast, la requte INVITE prcise les types de mdia et formats que lappelant utilisera et vers o il souhaite que les donnes soient envoyes. Si lappel est daccord avec cette description, sa rponse contiendra les mmes paramtres(toutes les requtes et leurs rponses ont le mme Call-ID) . En multicast, lappel rpondra que si sa description est diffrente. Exemple de fonctionnement dune requte INVITE en mode Proxy Server (PS) :

1. Le client appelant (UAC) envoie au PS une requte INVITE avec ladresse SIP du destinataire henning@columbia.edu 2. Le PS contacte le Location Serveur et lui fournit toute ou une partie de ladresse SIP du destinataire : henning 3. Le PS obtient alors une adresse plus prcise hgs@play 4. Le PS envoie une requte INVITE au serveur destinataire dont ladresse lui a t fournie par le service de localisation du Location Server : play 5. LUAS du destinataire avertit l'appel 6. Et retourne au PS de l'appelant laccord du destinataire pour communiquer par une rponse OK (code 200) 7. Ce PS retourne alors au client appelant laccord du destinataire 8. La rception de laccord du destinataire est acquitte par le client appelant par une requte ACK 9. Cet acquittement est transmis directement lappel 10. Communication tablie

18

Exemple de fonctionnement dune requte INVITE en mode Redirect Server [5]

1. Le client appelant (UAC) envoie une requte INVITE au redirect serveur (RS) avec ladresse destinataire 2. et 3. Le RS contacte le Location Server qui lui fournit ladresse du serveur destinataire : columbia.edu 4. Le RS renvoie au client appelant la nouvelle adresse par une rponse Moved (code 302) signalant que le terminal destinataire a chang de PS ; 5. Le client appelant envoie une requte ACK au RS pour acquitter ; 6. Puis ce client envoie une requte INVITE au serveur du destinataire. Cette requte possde le mme Call-ID que la premire mais son numro de squence 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 rponse OK (code 200). Le PS retourne au client appelant laccord du destinataire 8. La rception de laccord du destinataire est acquitte par le client appelant par une requte ACK , Cet acquitteme nt est transmis directement lappel Nous venons de voir, travers ces 2 exemples que si certains paramtres de la session doivent tre changs, 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 dabord quun terminal utilisateur peut constamment se dplacer. Sa position doit tre enregistre dynamiquement par un location server. Un tel serveur enregistre plusieurs positions pour un mme terminal, qui est reli plusieurs PS la fois lorsquil se dplace (les PS les plus proches) . Lorsqu'un serveur SIP interroge son location server, il tablit une liste des postions possibles de lutilisateur partir des rsultats reus. Cette liste contient 0 position ou plus. Pour communiquer sa nouvelle position au serveur SIP, le terminal de lutilisateur lui envoie une requte 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" auprs desquels les utilisateurs ont pu enregistrer leur localisation (mme temporaire). Une fois que le client

19

(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) rsulte 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 contrler lactivit dune Telephony Gateway travers un lment de contrle dappel externe nomm Call Agent. Le protocole IPDC est utilis pour raliser le control de connexions du Media Gateway et le transport de la signalisation. Le protocole MGCP suppose une architecture de contrle dappelle dont laquelle llment intelligent de contrle se trouve en dehors de Gateway, et cest lui qui assure le contrle de lactivit de la passerelle multimdia laide dun protocole de contrle. Cet lment de contrle sappelle Media Gateway Contoller ou Call Agent. Dans larchitecture MGCP il existe plusieurs Call Agent. Le protocole MGCP suppose que ces diffrents Calls Agents doivent se synchroniser lun avec les autres pour envoyer des messages cohrents aux passerelles au-dessous de leurs contrles. Finalement MGCP est un protocole matre /esclave ou on sattend ce que les Gateways excutent des commandes envoyes par les Call Agents. 6.3.1 Gnralits Dans le rseau tlphonique la couche de signalisation est spare de la couche de transport de parole. Le rle important de la signalisation est dchanger les messages entre les diffrentes entits pour tablir un circuit de parole entre des utilisateurs qui dsirent dialoguer. Le rle des protocoles de VOIP est dassurer la connexion entre les deux rseaux RTC/RNIS et le rseau Internet. Cest dans cette notion dinterconnexio n entre les deux mondes que se situe le protocole MGCP. Cette intgration permet au rseau RTC de voir les lments de rseau tlphonique comme tant autre switcher du rseau RTC. Larchitecture relative linterconnexion du rseau tlphonique avec un rseau IP est prsente sur le schma ci-dessous.

20

Le ple d'interconnexion est compos de trois entits fonctionnelles et d'un protocole permettant le dialogue au niveau de ces entits : Passerelle multimdia (Media Gataway). Elle assure la transformation d'un flux vocal entre le mode circuit et le mode paquet. Contrleur de la passerelle multimdia (Media Gateway Controller). Il assure le contrle de l'activit de la passerelle multimdia l'aide du protocole de contrle (Control Protocol). Module de signalisation. Il assure la transcription de la signalisation ISUP.

Ces trois entits fonctionnelles peuvent tre physiquement spares ou alors couples au sein d'un mme quipement. Le protocole MGCP est le protocole de contrle qui permet le dialogue entre Media Gateway Controller ( Call Agent ) et Media Gateway. Dans ce protocole linterconnexion entre le rseau tlphonique et le rseau IP est assur par deux niveaux logiques : Niveaux de signalisation assurs par lutilisation du SG (Signaling Gateway). Niveaux de voix assurs par lutilisation de passerelle multimdia.

Pour plus dinformation on peut regarder le scnario dtablissement dun appel. En ce qui concerne le Call Agent il y a trois catgories de messages : Des messages du rseau RTC transfrs par le SG ( Signaling Gateway). Des messages originaires Network Management changs entre le Call Agent et les Gateways.. Des messages de la MGC pour maintenir la Bases de donnes.

Larchitecture gnrale du protocole MGCP la suivante : STP Point de Transfert de Signalisations SSP Point de Signalisation SG Gateway de Signalisation MG Media Gateway (Passerelle Multimdia) ISUP ISDN User Part

Dans cette architecture la gestion des diffrents Gateways ainsi que les interconnexions avec le rseau PSTN est assure par les Call Agents. Lidentification dune extrmit ce fait par la nom du domaine de la Gateway a laquelle lextrmit est relie et par un nom local dans ce Gateway. 6.3.2 Fonctionnement de MGCP 6.3.2.1 Les commandes MGCP

21

Le protocole MGCP est un protocole de contrle de fonctionnement de Media Gateway. Dans ce protocole llment intelligent est le Call Agent il contrle les passerelles par lutilisation des huit commandes changer entre lui et les passerelles. Ces commandes sont reprsentes dans le tableau suivant :

Commandes
NotificationRequest Notification CreateConnection ModifyConnection DeleteConnection AuditEndPoint AuditConnection RestartInProgress

Directions
Call Agent Gateway Gateway Call Agent Call Agent Gateway Call Agent Gateway Call Agent Gateway Call Agent Gateway Call Agent Gateway Gateway Call Agent

Code
RQNT NTFY CRCX MDCX DLCX AUEP AUCX RSIP

Notification Request : Le Call Agent peut envoyer cette commande au Gateway, pour lui demander de dtecter lapparition des vnements spcifiques pour un terminal. Ces spcifications peuvent tre des signalisations tlphoniques comme laccrochage ou le dcrochage du tlphone ou bien des tonalits pour des extrmits spcifique. Une des plus importantes options de Notification Request est lassociation dune action avec chaque vnement. Lutilisation de cette option permet la rduction de nombre de messages changs entre le Call Agent et le Media Gateway. Notification Command : Le Gateway utilise cette commande comme rponse la commande Notification Request envoyer par le Call Agent, cette commande indique au Call Agent que lvnement est dclench. Le Gateway peut envoyer un ou plusieurs rponses des vnement dans une seule commande, ces vnements sont envoys par le Media Gateway dans lordre de dtection des ces vnements et cest le rle de Call Agent de mettre ces vnements dans lordre correcte. Create Connection : Cette commande est envoye par le Call Agent au Media Gateway pour crer une connexion entre deux extrmits. Autres que les paramtres ncessaires qui permettent au Media Gateway de crer des connexions, il y a des options LocalConnectionOptions qui dfinissent les qualits de services de la connexion. Par lenvoie du message Notification Request le Call Agent a la capacit denvoyer des actions qui correspondent chaque vnement. Lutilisation de cette option dans la cration dune connexion permet de diminuer le nombre de messages changs entre le Call Agent et le Media Gateway. Modify Connection :

22

Cette commande permet au Call Agent de modifier les paramtres associs une connexion dj tablie.

Delete Connection : Cette commande est envoye par le Call Agent au Gateway, elle lui permet de terminer une conversation tlphonique. Sil existe plus dun 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 quil faut au Media Gateway lors de la terminaison dun appel denvoyer au Call Agent une rponse qui contient les informations suivantes : Nomb res de paquets (RTP) envoys. Nombres doctets envoys. Nombres de paquets (RTP) reus. Nombres doctets reus. Nombres de paquets perdus. Information sur la gigue. Information sur les dlais de transmission.

Pour plus dinformation sur ces paramtres 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 paramtres statistiques si dessus. Il faut noter aussi que la Call Agent la possibilit de supprimer une connexion de multiples-extrmits dans le mme temps et ceci par lenvoie dun message Delete Connection a un Gateway avec le caractre *. Cette commande ne ramne pas des informations statistiques sur la connexion. Audit Endpoint : Le Call Agent peut utiliser cette commande pour dtecter si une extrmit est dcroche ou en tat de sonnerie. Dans ce cas le Gateway ramne une rponse qui contient des informations sur des extrmits spcifiques. Audit Connection : Cette commande permet au Call Agent de dtecter tous les paramtres lis une connexion spcifique. Restart In Progress : Cette commande est envoye par le Gateway au Call Agent. Il permet dinformer le Call Agent de mettre hors services une extrmit ou un groupe dextrmits quils ont des problmes. Dans ce cas la Call Agent peut dcider de tester ces extrmits avant de les mettre hors service. Pour se familiariser un peu avec le protocole MGCP nous allons dvelopper un scnario dtablissement dune connexion entre deux extrmits.
23

Nous allons dvelopper un scnario de cration dune connexion dont laque lle lutilisateur A appelle lutilisateur B. 6.3.2.2 Scnario Lutilisateur A utilise un terminal analogique. Dans ce cas le CO ( Central Office) qui sert lutilisateur A est connect un rseau de signalisation SS7 travers un STP (Point de Transfert de smaphore ). Linterconnexion entre le rseau tlphonique et le rseau IP est assure 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 rle de SG est de convertir la signalisation SS7 du rseau tlphonique en une signalisation sur le rseau IP. Dans ce cas le Call Agent joue le rle dune entit intermdiaire entre le Gateway de signalisation et le Gateway de multimdia. 2. Niveaux de voix, dans ce cas linterconnections entre les 2 rseaux se fait travers le Media Gateway. Les Media Gateway A et B sont contrls par le Call Agent et ceci par lutilisation du protocole MGCP.

TGW : Trunking Gateway.

24

La fonctionnalit de Call Agent est reprsente dans la figure suivante :

Les messages changs entre les diffrentes entits pendant ltablissement de lappel sont reprsents dans le tableau suivant :

Round trips 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5

CO IAM

SS7 IAM

TGW

Call Agent

RGW

Utilisateur

Etapes 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

ACK

ACK

ACM

Database lookup CRCX CRCX MDCX RQNT ACM

ACK

ACK

Ring

dcrocher ACK RQNT NFTY ACK

25

9 9.5 10 10.5

ACK ANM

MDCX ANM (parole) raccrocher

0.5 1 1.5 2 2.5 Scnario:

ACK DLCX DLCX REL

NTFY

19 20 21 22 23 24 25 26 27 28 29

1. CO: met un message dinitialisation (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 donnes ladresse IP de la Gateway laquelle le destinataire qui correspond ce numro est rattach. 4. Call Agent : envoie un message Create Connection au Gateway de lutilisateur A pour ce connecter au rseau tlphonique. 5. TGW : envoie un message ACK au Call Agent pour lui indiquer la rception du message CRCX. 6. Call Agent : saisit la rponse et envoie un message CRCX au Gateway de lutilisateur B. 7. RGW : envoie un message ACK au Call Agent pour lui indiquer la rception du message CRCX. 8. Call Agent : indique ces informations au TGW par lenvoie dun 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 tlphone B. 11. RGW : envoie un message ACK au Call Agent. 12. Call Agent : quand le Call Agent reoit 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 dcroche. 15. RGW : dtecte cet vnement et informe le Call Agent par envoie de message Notification. 16. Call Agent : envoie un message ACK au RGWB. 17. Call Agent : dans lordre de pouvoir dtecter la terminaison de la conversation, le Call Agent demande au RGW de lui informer le raccrochage du tlphone et ceci par lenvoie dun 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 lenvoie 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 rponse au Gateway de signalisation. 22. SS7 : le STP envoie cette information aux CO.
26

23. Les deux parties entrent en conversation. 24. RGW : lutilisateur 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. Matriels ncessaires la mise en place de la VoIP

7.1 Introduction
L'intgration de services de tlphonie au sein de rseaux de donnes augure des changements majeurs pour les entreprises car elle permet de distribuer les informations de manire plus pousse et efficace que les stratgies multirseaux actuelles.

7.2 Approche centralise contre approche distribue

Dans le pass, tous les rseaux vocaux furent construits en utilisant une architecture centralise dans lesquels les terminaux taient contrls par des switchs centraliss. Bien que ce modle fonctionne pour tous les services basiques de tlphone, il limite de beaucoup les volutions des services associs. Un des bnfices de la technologie VoIP est quelle permet aux rseaux dtre construits soit sur une architecture centralise soit distribue. Cette souplesse permet aux entreprises de btir des rseaux caractriss la fois par un management simplifi et aussi de linnovation pour les terminaux, cela en fonction des protocoles ut iliss. En gnral, les architectures centraliss sont associs avec les protocole MGCP ou H.248/Megaco. Ces protocoles ont t crs pour une interface centralise qui gre le contrle de lappel et la logique du switching . Linterface centralise discute avec les diffrentes passerelles qui routent et transmettent les paquets de voix. Dans les architectures centralises, lintelligence du rseau est centralise et les terminaux sont relativement peu intelligents. Les partisans des architectures VoIP centralises encouragent ce modle car il centralise le management et le contrle des appels. Il simplifie galement le flux des appels ainsi que sa comprhension par les ingnieurs de dveloppement. Les critiques de cette architecture avancent quelle touffe linnovation des caractristiques des terminaux et quelle deviendra une entrave quand il sagira de mettre en place des services VoIP qui vont au-del du simple transport de voix. Les architectures distribues sont associes avec les protocoles H.323 et SIP. Ces protocoles permettent lintelligence du rseau dtre distribue entre les terminaux et les interfaces de contrle dappels. Dans ce contexte, lintelligence englobe ltat dun appel, les interfaces

27

dappel, les procdures dappel, la rservation de ressources, le paiement ou nimporte quel autre aspect de la gestion dun appel. Les terminaux peuvent tre des passerelles VoIP, des tlphones IP, des serveurs de mdia, ou nimporte quelle interface qui peut initier ou terminer un appel VoIP. Linterface de contrle dappel est appel gatekeeper dans un rseau H.323 et proxy ou redirect server dans un rseau SIP. Les avocats de lapproche centralise mettent en avant la souplesse de ce modle. Il permet aux applications VoIP dtre traites comme nimporte quel autre application IP distribue et sa souplesse autorise dajouter de lintelligence soit sur les terminaux soit sur les interfaces de contrle dappels en fonction du march et des exigences technologiques du rseau. Les architectures distribues sont souvent bien comprises par les ingnieurs qui utilisent des rseaux de donnes IP. Ses dtracteurs soulignent que les rseaux distribus ont tendance rendre beaucoup plus complexe leurs mises en place.

Exemple darchitecture dun rseau VoIP

7.3 Exemple de matriel propos par le constructeur Cisco

Cisco est le constructeur leader mondial dans le domaine des matriels VoIP. Voyons maintenant quelquuns des types de produits proposs par ce constructeur avant de les dtailler par la suite.

28

Produits
Tlphones IP de la gamme Cisco 7900

Caractristiques principales
Possibilit de brancher des tlphones simples comme multifonction directement sur une connexion Ethernet 10/100 Base-T - Tlphones simples programmer et utiliser - Commutateur Ethernet 2 ports intgr - Nombreuses fonctions IP comprenant les applications XML - Traitement logiciel des appels et composant de contrle des appels pour les solutions de tlphonie sur IP de Cisco - Install sur les serveurs de convergence mdia Cisco (MCS), les systmes Cisco ICS 7750 ou sur certains serveurs tiers (CallManager 3.2) IPCC (Cisco IP Contact Center) propose un routage intelligent des appels, une tlphonie assiste par ordinateur (TAO) rseau/bureau ainsi qu'une gestion des contacts multimdia concernant les agents des centres de contacts sur un rseau IP. Il inclut plusieurs applications, notamment les suivantes : - CallManager - Cisco ICM (Intelligent Contact Manager) - Cisco IP IVR/IP Queue Manager - Cisco IP ICD est la fois un rpartiteur automatique d'appels (ACD) bas sur logiciel et une application IVR destine aux centres de contacts de taille moyenne utilisant les rseaux de tlphonie sur IP bass sur l'architecture Cisco AVVID. - Contrairement aux systmes ACD propritaires hrits, Cisco IP ICD est une plate-forme systme 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 crer ces interactions (galement appeles flux d'appels) et de construire une logique commerciale entre les fonctions IVR et ACD. quipement d'accs intgr (IAD) configuration fixe pour entreprises - Transmission donnes/voix par TDM ou par paquet sur une seule liaison ascendante WAN - Le service de tlphonie IOS (ITS) assure un traitement IAD des appels locaux avec des fonctions de commutation. Idal pour les petits bureaux (5 20 tlphones) - Fonctions reposant sur IP Keyswitch, idal pour les petits bureaux (5 20 tlphones) n'ayant pas besoin de toutes les fonctions de Cisco CallManager - Prise en charge des tlphones classiques et des tlphones IP sur une seule plate-forme - Modles de ports voix analogiques 8 FXS/16 FXS/16FXS+8FXO et port voix numrique T1 - Interfaces WAN de type T1, G.SHDSL et ADSL Les passerelles vocales ddies Cisco VG200 et Cisco VG248 permettent de relier des rseaux IP des systmes de tlphonie traditionnels, tels que le RTC - Prise en charge de plusieurs types d'interface, dont T1 et E1 - Entirement paramtrable par Cisco CallManager, par une interface de commande en ligne via Telnet, ou par SNMP

Cisco CallManager 3.2 IPPC (Cisco IP Contact Center)

Cisco IP ICD (Integrated Contact Distribution)

quipement d'accs intgr de la gamme Cisco IAD 2400

Passerelles vocales Cisco

29

7.4 Dtail des matriels Cisco utiliser

Tlphones IP de la gamme Cisco 7900

Les tlphones IP Cisco permettent d'tablir des communications professionnelles trs simplement. Entirement programmables, avec un choix de quatre modles (7960, 7940, 7910 et 7910+SW ainsi que le nouveau 7905), les tlphones 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 modles 7960, 7940 et 7910+SW sont des tlphones multifonction pouvant tre branchs directement sur une connexion Ethernet 10/100Base-T standard. Chaque modle permet de passer des communications de qualit tlphonique. Ils sont quips d'un commutateur Cisco 2 ports 10/100 pour une ventuelle connexion un PC. Les modles 7910 et 7905 sont des modles fonctionnalits basiques avec une connexion un seul port 10 Base-T. En tant que tlphones IP, ils peuvent tre installs en tout point du rseau IP de l'entreprise. Les tlphones prennent en charge le protocole de configuration DHCP et il n'est pas obligatoire de les identifier l'aide de Cisco CallManager. Les tlphones IP Cisco prennent en charge les algorithmes de compression audio G.711 et G.729a, le modle 7905 prenant galement en charge les algorithmes de compression audio H.323 pour rpondre aux exigences en termes de bande passante bas dbit. Une fonction de tlchargement du microcode permet de leur ajouter de nouvelles fonctions en les programmant depuis le systme. Caractristiques principales :

Modle Cisco 7960 et 7940

Module d'expansion Cisco 7914 Station de confrence Cisco IP 7935 Modles Cisco 7905, 7910 et 7910+SW

Le modle Cisco 7960 est un tlphone IP multifonction avec 6 lignes programmables et des touches de numrotation rapide. Le modle 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 tmoin 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 numro de l'appelant, ainsi que les numros composs. Ces tlphones prennent galement en charge le format XML, les rendant ainsi idaux pour afficher les contenus Internet. Le module d'expansion 7914 permet d'tendre les possibilits du tlphone IP Cisco 7960 grce des boutons supplmentaires et un cran cristaux liquides, portant ainsi le nombre total de boutons 20 avec un module ou 34 avec deux modules. La station de confrence 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 confrence de petite moyenne taille. Les modles Cisco 7910 et 7910+SW sont des tlphones IP conus pour les environnements faible trafic, ne ncessitant

30

pas des performances suprieures, tels que les halls d'accueil ou les cantines. Ces deux modles fonctionnent sur une seule ligne et sont quips d'un cran cristaux liquides affichant 2 lignes de 24 caractres, pour indiquer l'tat de l'appel et afficher la prsentation du numro. Le nouveau tlphone 7905 faible trafic dispose d'un cran large

Fonctionnalits principales :

Avec le DHCP, les nouvelles installations des tlphones IP sont extrmement rapides. Ces derniers peuvent tre dplacs d'un port Ethernet un autre, et ce en tout point du rseau IP de l'entreprise. Si vous dplacez un tlphone IP Cisco, aucune modification de base de donnes ou de cblage n'est ncessaire, contrairement aux systmes tlphoniques traditionnels. Les tlphones IP Cisco redmarrent automatiquement et s'enregistrent de nouveau auprs de Cisco CallManager. Les tlphones IP Cisco sont compatibles avec Microsoft NetMeeting. Si vous utilisez NetMeeting, le partage d'applications ou la visioconfrence sont accessibles partir d'un simple bouton situ sur votre tlphone IP Cisco. Tous les modles utilisent le protocole CDP (Cisco Discovery Protocole), afin de tirer leur alimentation du rseau 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 tlphonie aux rseaux locaux d'entreprise et aux quipements rseau de tlphonie par paquets, tels que les tlphones IP, les quipements de traitement des mdias, les passerelles de voix sur IP (VoIP) et les applications multimdia. Grce l'interface de programmation d'applications (API) de tlphonie ouverte de CallManager, les services de vido, voix et donnes, tels que les messageries unifies, les confrences multimdia, les centres de contacts de collaboration et les systmes de rponse interactive multimdia peuvent enfin interagir avec les solutions de tlphonie IP. Cisco CallManager est install sur le serveur de convergence mdia Cisco (MCS) et sur certains serveurs tiers. Il est livr avec une suite d'applications vocales et d'utilitaires intgrs, dont Cisco WebAttendant constitu d'une console logicielle d'administration manuelle, d'une application de confrence et d'utilitaires de cration de rapports. Pour plus d'informations sur la gestion rseau VoIP, reportez-vous CiscoWorks Manager IP Telephony Environment Monitor Cisco CallManager version 3.2 est une solution de traitement des appels de tlphonie IP d'entreprise volutive, hautement disponible et dployable. Les multiples serveurs sont mis en grappe et grs comme une entit unique, permettant ainsi d'accepter jusqu' 10000 utilisateurs par grappe. En reliant de multiples grappes, la capacit d'un systme comportant 100 sites peut tre augmente jusqu' prs d'un million d'utilisateurs. Cette mise en grappe permet de mettre en commun la puissance de plusieurs serveurs Cisco CallManager rpartis, augmentant ainsi l'volutivit et la disponibilit de ces serveurs pour les tlphones, les passerelles et les applications. La triple redondance de serveurs de traitement des appels amliore grandement la disponibilit gnrale du systme.

31

Caractristiques principales :

Cisco Call Manager 3.2

- Cisco CallManager est livr avec une suite d'applications vocales

permettant d'initier des confrences vocales ou d'obtenir une console d'administration manuelle, vitant ainsi d'avoir recours du matriel ddi pour le traitement de la voix. - Les services supplmentaires ou les servic es avancs, tels que la mise en attente, le transfert et la redirection d'appels, les confrences, l'utilisation de plusieurs lignes, la slection automatique l'arrive, la numrotation rapide, le rappel du dernier numro ou de nombreuses autres fonctions, sont ainsi disponibles sur les tlphones IP et les passerelles. - L'amlioration des fonctions est possible grce l'volutivit du logiciel et permet d'viter des dpenses excessives en matriel qui sont le lot des systmes de commutateurs privs classiques. - Cisco CallManager Attendant Console : cette application avec interface Web remplace la classique console d'administration manuelle et permet d'accepter et de rpartir rapidement les appels vers les utilisateurs de l'entreprise. Un service d'annuaire intgr permet d'apporter des fonctions de tmoin d'appel (BLF) et de slection directe de poste (DSS) chaque ligne du systme. La console surveille l'tat de chaque ligne sans recourir des quipements de surveillance ddis, conomisant ainsi sur les cots. - Les applications logicielles, telles que le systme de rpondeur vocal interactif de Cisco, Cisco IP Contact Center, Cisco Automated Attendant et Cisco SoftPhone, interagissent avec Cisco CallManager via les API de tlphonie.

IPPC (Cisco IP Contact Center)

IPCC (Cisco IP Contact Center) propose une tlphonie assiste par ordinateur (TAO) rseau/bureau par routage intelligent des appels ainsi qu'une gestion des contacts multimdia pour les agents des centres de contact sur le rseau IP. Grce une solution unifie combinant les fonctionnalits logicielles ACD avec la tlphonie IP, IPCC garantit aux socits le dploiement rapide d'une infrastructure distribue de centre de contacts permettant de prendre en charge l'ensemble de leurs ventes et initiatives de services lectroniques. Fonctionnalits principales :
Intgration d'un commutateur hrit 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 tlcopie. Liste volutive des partenaires EcoSystem permettant d'intgrer des applications tierces essentielles Prise en charge de centres de contacts multisite, intgration CRM Enregistrements dtaills des appels de contacts de bout en bout Bureaux de superviseurs et d'agents communs tous les produits servant grer l'interaction avec les clients Cisco, tels que les produits Cisco IP ICD Standard, IP Enhanced et Cisco IP Contact Center Rapports historiques personnaliss et prdfinis ; rapports en temps rel intgrs dans les

32

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 personnaliss Affichage standard l'cran permettant de transmettre l'agent toute information dj saisie concernant l'appelant Prise en charge complte de l'interaction agent/superviseur via une session IRC Possibilit de prdfinir des messages transmis entre agent et superviseur

Cisco IP ICD (Integrated Contact Distribution)

Cisco IP Integrated Contact Distribution (IP ICD) est un rpartiteur automatique d'appels (ACD) conomique, simple installer et utiliser, destin aux entreprises. Cisco IP ICD est intgr de manire transparente toutes les applications de rponse au client, dont Cisco IP IVR (Interactive Voice Response) et Cisco IP AA (Automated Attendant). IP ICD prsente de nombreux avantages : ce rpartiteur automatique d'appels d'entre de gamme conomique est la fois simple installer, administrer et utiliser. Employ conjointement Cisco IP IVR, il prend en charge les accs multimdia (voix, donnes et Web) et apporte des outils de personnalisation complte des scripts de gestion des flux d'appels. En outre, il peut tre intgr de manire transparente aux applications de rponse 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 particulirement 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. Fonctionnalits principales :
Administration de Cisco IP ICD par navigateur Web totalement intgre avec celle de Cisco CallManager Enregistrements dtaills des appels de contact de bout en bout ; l'affichage standard l'cran permet de transmettre l'agent toute information dj saisie concernant l'appelant Rapports historiques personnaliss ou prdfinis ; rapports en temps rel intgrs dans les bureaux de superviseurs et d'agents Bureaux de superviseurs et d'agents communs tous les produits servant grer 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 fonctionnalits d'interaction vocale Prise en charge du traitement personnalis des appels en attente comprenant la gestion de la musique d'attente et des messages personnaliss Prise en charge complte de l'interaction agent/superviseur via la fonction IRC, possibilit de prdfinir des messages transmis entre agent et superviseur

33

quipement d'accs intgr de la gamme Cisco IAD 2400 avec service de tlphonie IOS (ITS)

Les quipements d'accs intgrs de la gamme Cisco IAD 2400 combinent les services de donnes, voix et vido sur les rseaux IP et ATM et constituent des solutions efficaces et conomiques permettant de fournir des services vocaux et des accs Internet haut dbit pour les PME, le tout dans un systme n'occupant qu'une unit d'armoire (1 RU). Associ au logiciel optionnel ITS, l'quipement IAD 2400 est une solution idale pour fournir des services de tlphonie IP sur un rseau local convergent au sein d'un environnement de bureau rduit (5 20 tlphones) ne ncessitant pas les fonctionnalits de CallManager.

Caractristiques principales :

Gamme Cisco IAD 2400

quipement d'accs professionnel compltement intgr - Fonctions reposant sur le service de tlphonie IOS (ITS), idal pour les petits bureaux (5 20 tlphones) ne ncessitant pas les fonctionnalits de Cisco CallManager - Prise en charge des tlphones classiques et des tlphones IP sur une seule plate -forme - Modles de ports voix analogiques 8 FXS/16 FXS/16FXS+8FXO et port voix numrique T1 - Interfaces WAN de type T1, ADSL et G.shdsl

Fonctionnalits principales :
Combine des services d'accs Internet haut dbit et des services vocaux de qualit tlphonique 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 rseaux GR-303 TDM vers des rseaux GR-303 par paquets ou des rseaux utilisant des agents d'appel Possibilit d'installation et de configuration automatise distance via le protocole SNAP (Simple Network Auto Provisioning) et l'outil Cisco Configuration Express

34

Caractristiques dtailles : IAD 2421 IAD 2423

Idem IAD 2421 1 port ADSL Analogiques : 8FXS

IAD 2424
Idem IAD 2421 1 port G.shdsl Analogiques : 8FXS, 16FXS, 16FXS+8FXO, Numrique : 1 T1 Idem IAD 2421 16 Mo (par dfaut), 32 Mo (max) 64 Mo Idem IAD 2421

Ports LAN fixes Ports WAN fixes Ports vocaux

Vitesse du processeur (type) Mmoire flash Mmoire DRAM Dimensions (H x L x P)

1 port Ethernet (10Base-T) T1, 1 port Analogiques : 8FXS, 16FXS, 16FXS+8FXO, Numrique : 1 T1 80 MHz (RISC) 16 Mo (par dfaut), 32 Mo (max) 64 Mo 4,32 x 44,45 x 28,70 cm.

Idem IAD 2421 16 Mo (par dfaut), 32 Mo (max) 64 Mo Idem IAD 2421

Passerelles vocales Cisco

Les passerelles vocales sont relies directement aux rseaux tlphoniques privs ou publics pour assurer le trafic voix sur les rseaux IP, en convertissant les appels IP en appels tlphoniques standard et inversement. Elles permettent l'change entre la tlphonie par paquets et la tlphonie classique, telle que les rseaux tlphoniques publics ou privs, les tlcopieurs, etc. L'ensemble de la gamme des routeurs multiservice Cisco apporte galement des fonctionnalits de passerelle vocale analogique et numrique grce des modules rseaux et des cartes d'interface vocale adapts, tels que le module d'interface analogique Catalyst 6000 FXS. Cisco fournit les passerelles vocales ddies suivantes : Cisco VG200 et Cisco VG248. Caractristiques principales :

Passerelle vocale Cisco VG200

- Conception et validation exclusivement destines aux environnements AVVID de CallManager - Particulirement adapte 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 tlconfrence avec le module optionnel DSP de mise en grappe en rseau - Attribution automatique d'adresse IP et identification auprs de CallManager grce au protocole DHCP - Point de configuration et d'administration unique via Cisco CallManager - Administration via SNMP ou ligne de commande par Telnet, gestion des tlchargements de logiciels par TFTP

35

Passerelle vocale Cisco VG248

- Accs RNIS primaire (T1/E1) (cts rseau et utilisateur) ; T1/E1CAS, T1/E1 QSIG avec MGCP, BRI, E&M, FXS et FXO (dmarrage en boucle et par terminaison) - Services complmentaires (maintien d'appels, transfert d'appels, tlconfrence, mise en attente, etc.) La passerelle vocale Cisco VG248 est un quipement occupant 1 unit d'armoire permettant l'utilisation de 48 quipements analogiques (tlphones, fax et modems) avec Cisco Call Manager. Cette passerelle permet aux organisations possdant un parc important d'appareils tlphoniques analogiques (htels, universits, hpitaux, etc.) de dployer la tlphonie sur IP tout en protgeant les investissements antrieurs. Les lignes analogiques sont multifonction (identification d'appelant, indicateur de message en attente, codes) et le prix par port est plus comptitif. La passerelle vocale VG248 permet de gnrer un protocole SMDI pour les ports analogiques associs, autorisant ainsi l'tablissement d'une connexion un rseau Cisco Call Manager via des systmes de messageries vocales traditionnels. La passerelle permet de partager les systmes de messageries vocales SMDI entre Cisco Call Manager et les PBX traditionnels.

36

Conclusion
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 dcroche le tlphone ? Tant que IPv6, la future gnration de protocole IP, n'est pas largement implmente, VoIP ne sera pas une option intressante 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 dj intgr un certain nombre de solutions internet et des systmes d'exploitation comme Linux, peu d'entreprises ont migr de l'IPv4 l'IPv6. Mais cela devrait changer dans les trois annes 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 mdiocre

Pour le moment, i n'y a pas de garantie de qualit sonore pour la VoIP. Elle est l souvent plus mauvaise que celle d'un tlphone cellulaire utilis dans une zone la couverture mdiocre... Les temps de latence sur le rseau, les problmes de compression et un rsultat sonore peu fidle affaiblissent grandement la qualit sonore du VoIP. La tche devrait tre facilite avec l'implmentation grande chelle d'IPv6 d'ici les trois prochaines annes, et l'tablissement de nouveaux standards par des organismes regroupant des industriels des tlcoms.

Amliorer l'utilisation

VoIP doit offrir des fonctionnalits telles que la mise en attente d'un appel et l'identification de l'appelant, des services de base de la tlphonie traditionnelle. Aujourd'hui, l'implmentation de VoIP ncessite souvent que l'appelant tape jusqu' 25 chiffres (numro d'accs, numro d'identification personnel, code et numro de tlphone 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 systmes 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 dveloppement du VoIP. Les fournisseurs de service doivent supporter un nombre suffisant de passerelles situes dans les zones de gros trafic pour russir faire des conomies de cots. Mais ce sont notamment les clients internationaux qui seront pnaliss : le manque de passerelles signifie que les fournisseurs d'accs internet sont obligs

37

d'acheter et de revendre des services de routage via une autre entreprise (particulirement pour les routages longue distance). Les cots de la solution VoIP augmentent d'autant.

Standards

Le VoIP dpend principalement du standard tlphonie H.323, qui permet de mlanger la voix, la vido et les donnes. Cependant, le H.323 est un standard globalement difficile implmenter pour les fournisseurs VoIP. Bien souvent, ils choisissent une solution propritaire afin d'obtenir un dploiement plus rapide. Ce qui peut entraner des problmes d'interoprabilit pour les utilisateurs.

Support administratif

Les systmes administratifs de comptabilit, de facturation et de gestion du rseau pour VoIP doivent tre implments des niveaux qui sont au moins parallles ceux de la tlphonie traditionnelle. Mais pour l'instant, ces derniers dtiennent l'avantage dans le domaine des systmes administratifs volutifs qui grent les services administratifs.

38