La Voix sur IP : quelle architecture ?

Par Jean-Michel Cornu

Ce document publié par la Fing est une synthèse de deux présentations données dans le cadre de la troisième journée sur les technologies et les standards de l’Internet le 20 octobre 2003 (http://www.isoc-gfsi.org/gfsi/reunions/journee-francaise-IETF-3.html ) :

• La voix et Internet par Cédric Aoun de Nortel Networks : http://www.isoc-gfsi.org/gfsi/reunions/IETF-3/Cedric_Aoun/index.htm
• De l’Internet aux réseaux de Nouvelle Génération, le point de vue de l’opérateur par Bruno Chatras de France Telecom R&D : http://www.isoc-gfsi.org/gfsi/reunions/IETF-3/Bruno_Chatras/index.htm

Il existe plusieurs approches pour offrir des services de téléphonie et de visiophonie sur des réseaux IP. Certaines placent l’intelligence dans le réseau alors que d’autres préfèrent une approche pair à pair avec l’intelligence répartie à la périphérie (terminal de téléphonie IP, passerelle avec le réseau téléphonique commuté...). Chacune a ses avantages et ses inconvénients, et ces diverses approches se déclinent au travers de différents protocoles.

Les protocoles pour terminaux simples : MCGP/MEGACO

Dans une première approche, la passerelle qui fait le lien entre le réseau téléphonique et le réseau de voix sur IP est considérée comme stupide et toute l’intelligence est intégrée dans un contrôleur de passerelle (MGC Media Gateway Controler). Ainsi, les services proposés sont indépendants de la passerelle utilisée et de son constructeur. Le protocole MEGACO/H248 définit les échanges entre ces deux parties.

Il a été adopté par l’IETF (RFC 3015) et l’UIT-T (Union International des Télécommunications, recommandation H248). Il s’agit d’une évolution de l’ancien protocole MCGP (Media Controler Gateway Protocol) pour le faire converger avec le projet de norme équivalente MDCP de l’UIT-T.

Cette approche permet la construction de terminaux simples et bons marchés. La freebox proposée par le fournisseur d’accès Internet Free dans les zones dégroupées intègre cette approche avec MGCP. Outre ses fonctions locales (modem, routeur, set top box...) elle inclut une passerelle " stupide " entre le poste téléphonique et le réseau Internet. L’intelligence est alors localisée dans le réseau.

Cette architecture éclatée où les différents types de contrôles peuvent être dans des équipements séparés est bien adaptée à un passage à l’échelle de la voix sur IP pour reprendre quasiment à l’identique les services existants des réseaux téléphoniques commutés classiques.

La centralisation rend le réseau vulnérable à la défaillance d’un équipement de contrôle si celui-ci est unique, mais les protocoles MGCP/MEGACO prévoient des procédures permettant à une passerelle de basculer d’un contrôleur à l’autre en cas de panne du contrôleur primaire.

Le protocole H323

A l’inverse, dans le protocole H323 développé par l’UIT-T, l’ensemble des contrôles sont intégrés dans le terminal ou la passerelle (aussi bien le contrôle des services et des appels que celui du transport des paquets). Cela permet de faire de la téléphonie ou de la visiophonie en pair à pair sans nécessiter de passer par un système de contrôle centralisé (bien que certaines architectures H323 utilisent malgré tout un centre de contrôle centralisé).

Le protocole H323 est en fait l’adaptation aux réseaux IP du protocole de visiophonie H320 développé à l’origine pour le RNIS (Réseau National à Intégration de Services commercialisé sous le nom Numeris en France). Il existe également des déclinaisons pour d’autres types de réseau (ATM, réseaux locaux et même pour les réseaux téléphoniques et en particulier les réseaux mobiles).  

Le protocole H323 définit des échanges en pair à pair entre quatre types d’équipements : des terminaux de visiophonie ou de voix sur IP, des passerelles entre le réseau téléphonique et le réseau de voix sur IP, des équipements offrant des services particuliers (MCU Multipoint Control Unit par exemple pour les conférences multicast pour plus de trois personnes) et des " gatekeeper " (centres de contrôle) pour l’administration de la bande passante et faire fonction d’autocommutateurs virtuels.Ce protocole est utilisé par la plupart des logiciels de visiophonie. Pour garantir l’interopérabilité entre deux équipements utilisant H323, il faut cependant utiliser la même version et les mêmes options dans le protocole.

H323 peut être utilisé dans une architecture purement pair à pair avec l’ensemble des services intégrés dans les terminaux, mais dans ce cas, il devient plus difficile de passer à l’échelle et les évolutions peuvent nécessiter des temps de déploiement plus long pour de nouveaux services car chaque équipement doit intégrer l’ensemble des services. Mais cette architecture est également plus robuste car un problème sur un équipement n’affecte pas les autres équipements.

Le protocole SIP

Le protocole SIP (Session Initialisation Protocol) peut également être utilisé avec une approche pair à pair. Il est cependant également utilisé dans certains cas avec une grande partie du contrôle dans le réseau (par exemple dans la téléphonie mobile avec l’architecture 3GPP IMS ou sur les réseaux câblés de type PacketCable).

Il a été initialisé par le groupe MMUSIC (Multiparty Multimedia Session Control) et est maintenant développé par le groupe SIP de l’IETF (RFC 2543 de mars 1999 puis RFC 3261 de juillet 2002). Il est bien plus récent que le protocole H323 et pour l’instant moins mature et moins répandu que H323. 

Il permet d’établir un appel simplement en cliquant directement sur une URL depuis une page Web ou un courriel avec une syntaxe du type " sip:infos_utilisateurs@domaine " à laquelle il est possible de rajouter des paramètres et des entêtes. Par exemples : sip :jmcornu@fing.org ou sip :+33143386262@passerelle.fr,user=phone. Cette capacité à intégrer des URI SIP est complémentaire aux fonctionnalités permises par enum (voir " enum : reflexion collective sur les usages " - http://www.fing.org/index.php?num=2609,4 )

SIP pourrait être une alternative plus évoluée qui pourrait remplacer à terme H323. Il existe cependant de nombreux profils de ce standard adaptés à divers usages mais qui risquent de créer une confusion et des problèmes d’interopérabilité :

• Le profil SIP du 3GPP sur les téléphones mobiles de 3^ème génération
• Celui de MSF (Multiservices Switching Protocol)
• Les spécifications TIPHON proposées par l’ETSI
• La version du consortium PacketCable pour l’utilisation sur le câble
• Les profils UIT pour l’interfonctionnement avec le RTC
• ...

SIP doit encore faire ses preuves dans la phase actuelle de déploiement qui nous dira si ce protocole sera un succès ou non.

Développements du réseau

Le développement de la voix sur IP dépendra également du développement des fonctionnalités du réseau.

Contrairement aux données où seul le débit global compte, il faut garantir pour la voix un flux le plus régulier possible. Cela peut se faire de différentes façons :

• En utilisant des protocoles de transport simplifiés pour ne pas ralentir le trafic, quitte à ne pas prendre en compte la gestion des erreurs (la voix est peu sensible à quelques erreurs contrairement aux données mais la qualité perçue est très dépendante des fluctuations de délais dues aux congestions dans le réseau). Ainsi, UDP (User Datagram Protocol) est plus adapté pour le transport de la voix que TCP qui est utilisé par exemple pour le trafic Web ou mail. A terme, le nouveau protocole DCCP (Datagram Congestion Control Protocol), très simplifié et adapté au trafic point à point pourrait remplacer UDP.
• On peut également utiliser un mécanisme de buffering pour stocker d’avance des paquets et ainsi être plus indépendant des aléas du réseau comme dans le cas du streaming (diffusion audio ou vidéo sur Internet). Mais au-delà d’un certain délai de latence, la téléphonie est perçue comme " half-duplex " (échanges alternés de la voix comme en radio amateur). Ce délai varie suivant la culture des personnes et est typiquement de 160 ms en Europe du Sud ou 200 ms en Europe du Nord.
• Pour garantir un délai d’acheminement, il est nécessaire d’utiliser un système de Qualité de Service (voir la fiche d’expertise sur la QoS : http://www.fing.org/index.php?num=1880,4 ). Faut-il ou non attendre la mise en place de fonctionnalités de qualité de service sur le réseau Internet avant de l’utiliser pour la voix sur IP ? Une approche alternative consiste à considérer que l’augmentation de la bande passante dans les coeurs de réseaux permet de gérer sans problème les pics de trafic et d’éviter ainsi les congestions (voir l’article sur Ca*net4 au Canada : http://www.fing.org/index.php?num=2458,1 ). Il reste à voir si cette approche simple (il est plus facile et moins cher d’augmenter la bande passante que de mettre en place de la Qualité de service de bout en bout) passera à l’échelle dans le cas d’une reprise d’une part significative du trafic téléphonique commuté. Pour ce qui est des réseaux d’accès, la question de la qualité de service reste posée (mais trouve des solutions plus simples si le réseau d’accès est maîtrisé par un opérateur unique).

D’autres fonctionnalités du réseau ont un impact sur la voix sur IP tels que la sécurité, pour garantir la confidentialité des communications, ou l’adressage direct du terminal (les boîtiers NAT masquent les adresses réelles à l’extérieur du réseau d’entreprise).
L’arrivée d’IPv6 devrait résoudre le manque d’adresses IP actuelles tout en intégrant des mécanismes de sécurité pour protéger les terminaux des attaques directes (Voir la fiche sur les boîtiers intermédiaires http://www.fing.org/index.php?num=1925,4 )

Enfin, si la téléphonie IP est appelée à remplacer complètement le Réseau Téléphonique Commuté, il est important qu’elle reprenne à l’identique dès le début, les services offerts par le réseau traditionnel. Il faut par exemple, garantir que le trafic fax sera bien acheminé. C’est également le cas pour les services d’urgence, en particulier ceux nécessitant une information de localisation (15 en France ou 911 aux Etats Unis qui appellent le Samu le plus proche) ou les numéros en 08XX qui peuvent rediriger vers divers centres de traitement suivant le lieu d’où on appelle. Pour le service de présentation du numéro, seul MEGACO permet de reproduire à l’identique le service normalisé par l’ETSI utilisé dans les réseaux commutés. Lorsque la voix sur IP est utilisée comme une seconde ligne en complément du RTC classique, la reprise à l’identique des services téléphoniques est moins critique.

La voix sur IP se met en place progressivement. La question se pose maintenant de sa capacité à passer à l’échelle afin de récupérer progressivement le trafic du réseau téléphonique commuté pour offrir une véritable convergence voix-données. Il existe deux visions différentes du basculement progressif du Réseau Téléphonique Commuté vers la voix sur IP. Certains voient une intégration des services de téléphonie au sein du réseau Internet, tandis que d’autres prévoient un ensemble de réseaux IP exploités par des opérateurs avec les mêmes contraintes de fiabilité, disponibilité et sécurité que le RTC et des passerelles vers l’Internet public (l’utilisation d’IP et de SIP proposée par le 3GPP dans le cadre des versions R5 et R6 de l’UMTS va dans ce sens). Que ce soit sous la forme d’un réseau unifié ou de deux réseaux interconnectés (un pour les services IP à fiabilité garantie - Managed IP Networks - et l’autre pour l’Internet actuel toujours sur IP mais sans garantie de qualité de service), la complexité doit restée masquée à l’utilisateur qui veut bénéficier du meilleur de chaque monde tout en profitant de l’intégration des données, de la voix et de l’image. Si les acteurs de la voix sur IP arrivent à cela, de nombreux usages deviennent possibles que les utilisateurs sauront sans nul doute inventer.