Archives par mois : janvier 2012

VoIP & NAT (2): Les différents types de NAT

25 janvier 2012

Comme nous en discutions dans notre précédent post, l’introduction des NAT dans les réseaux actuels, si elle a résolu, du moins temporairement, le problème de la pénurie d’adresses IPv4, a par la même occasion engendré de nouvelles contraintes techniques pour un certain type de trafic, et plus particulièrement, en ce qui nous intéresse ici, en téléphonie sur IP (ToIP ou Telephony over IP). La prise en compte de ces nouvelles contraintes se repose sur la détermination du type de NAT que le trafic doit traverser. En effet, par un manque de cadre et d’orientation lors de leurs conceptions, leurs implémentations s’avèrent très disparates. Ce post vous décrit les différentes méthodes existantes permettant leur classification.
(suite…)

RTCWeb: des fonctions de communications dans le navigateur Web

19 janvier 2012

Le projet WebRTC vient d’annoncer la disponibilité dans Chrome d’une première implémentation de l’API WebRTC. Ce projet s’intègre dans la récente initiative RTCWeb visant à intégrer des fonctions de communication temps-réel dans les navigateurs Web. Nous profitons de cette occasion pour présenter les objectifs et l’architecture générale de RTCWeb.

Objectifs de RTCweb

Les fonctions offertes par le navigateur Web sont de plus en plus étendues et lui permettent de déborder de son rôle historique d’affichage de pages Web pour devenir un véritable environnement d’exécution d’applications riches. Cette tendance a ainsi été popularisée par des services tels que GMail et la suite Google Apps.

Les fonctions multimédias et de communications interactives ont jusqu’à récemment été rendues possibles uniquement par l’utilisation de plugins propriétaires tels que Flash Player (les objets de type ActiveX, Java ou autres n’ayant eu qu’un succès très limité dans ce cadre) qui a permis notamment le développement massif de la vidéo Web avec des services comme YouTube. Il devient maintenant possible de téléphoner à partir d’une page Web intégrant une applet Flash (voir par exemple http://call.nexcom.fr).

Le développement de la technologie HTML5 qui intègre une multitude de nouvelles fonctions permet maintenant de standardiser ces fonctionnalités. Ainsi les services de diffusions vidéo (Youtube par exemple) ou de partage de documents (tel Slideshare) sont engagés dans une logique de remplacement de fonctions auparavant développées en Flash par du HTML5. Ces fonctions restent pour l’instant relativement simples et sans interactions complexes mais l’évolution rapide des standards permet maintenant d’envisager le développement d’applications Web plus sophistiquées.

L’initiative RTCWeb (Real Time Collaboration on the Web) vise ainsi à standardiser l’infrastructure implémentée au sein des navigateurs Web permettant d’établir des communications audio et vidéo, directes, interactives et en temps-réel, entre des utilisateurs Web.

Cet effort se déroule au sein de deux groupes de travail:

Ces deux groupes ont démarré depuis peu et de nombreux points restent ouverts et sujets à (vives) discussions, le sujet intéressant les plus grands acteurs de l’Internet (Google, Cisco, Mozilla, Apple, Skype …). Ainsi, nous décrivons par la suite les grands principes de RTCWeb sans rentrer dans les détails techniques susceptibles d’évoluer. Nous reviendrons plus tard sur ces derniers ainsi que l’API WebRTC avec de nouveaux articles quand ces points seront plus aboutis.

Architecture générale RTCWeb

RTCWeb ne vise pas à intégrer dans le navigateur des services de haut niveau de type softphone. L’idée est plutôt de spécifier les primitives nécessaires à la mise en oeuvre de tels service en conjonction avec des serveurs externes. En particulier, l’objectif est de permettre à ce qu’une application Javascript intégrée au sein d’une page Web et s’exécutant dans un navigateur standard puisse établir une communication utilisant des canaux audio, vidéos et de données et ce, sans contrainte sur le type de service fourni par l’application Web.

Un service de type softphone pourra ainsi être fourni par une application Javascript implémentant un widget téléphone et mettant en oeuvre un protocole de signalisation basé par exemple sur les WebSockets. Cette application utilisera les primitives RTCWeb pour capturer les flux audio et vidéo de la webcam, les encoder et les transmettre au correspondant.

Le schéma suivant illustre une utilisation typique de RTCWeb. Il est important de noter qu’il existe un lien media direct entre navigateurs et basé sur les protocoles définis au sein de RTCWeb. En revanche la signalisation emprunte un chemin qui peut être plus complexe et utilise des protocoles qui peuvent être propriétaires. Dans cet exemple, la signalisation utilise la connexion HTTP/Web Sockets entre le navigateur et le serveur Web et est spécifique à l’application Web délivrée par le serveur et s’exécutant au sein du navigateur. S’il y a un besoin d’interopabilité, la communication entre serveurs Web sera purement du ressort applicatif et pourra utiliser un protocole standard tel que SIP.

 

Il reste maintenant à définir les détails de ces différentes primitives et protocoles. Les discussions portent en particulier sur les points suivants:

  • format des flux: quels sont les codecs offerts par le navigateur ? Doit-on spécifier une liste de codecs communs et toujours disponibles ?
  • transport des données média: de nombreuses discussions portent sur le choix de RTP/SRTP, SRTP doit-il être imposé ou disponible en option ? Pour la gestion de la connectivité, ICE sera probablement utilisé.
  • session de contrôle: doit-on réutiliser un protocole tel que SIP ou XMPP ou laisser cette partie sous le contrôle de l’application. Un consensus s’est dégagé sur cette dernière possibilité afin d’être le plus ouvert et flexible possible, il est ainsi probable que l’on verra apparaître des librairies Javascript implémentant SIP ou des protocoles simplifiés propriétaires. Dans tous les cas, quel modèle utiliser pour la négociation des formats média (SDP, autre …) ?

Le prochain article de cette série sera consacré à l’étude de l’API WebRTC, qui permet à l’application Javascript d’accéder à toutes ces primitives et de construire ainsi une application tirant parti de ces nouvelles fonctions HTML5.

Quelles solutions pour la voix sur LTE (VoLTE) ?

16 janvier 2012

LTE (Long Term Evolution) constitue l’évolution 4G des réseaux de télécommunications mobiles et offrira notamment des débits mobiles beaucoup plus élevés que les réseaux actuels. Le réseau EPS (il convient de parler plutôt de réseau EPS, Evolved Packet System, le terme LTE désignant plutôt l’interface radio entre le mobile et le réseau mobile 4G) présente la particularité par rapport aux précédents réseaux mobiles 2G/3G de ne fournir qu’un service PS (Packet Service) de données alors que les réseaux 2G/3G offrent à la fois des services de type CS (Circuit Service) pour la voix et de type PS pour les données

Le réseau EPS ne propose ainsi que l’accès aux réseaux de données PDN (Packet Data Network) et tous les services devront ainsi être ainsi être conçus au dessus d’IP y compris les services traditionnels tels que la voix ou les SMS. Cela constitue donc une évolution majeure et les opérateurs devront déployer de nouveaux systèmes afin de continuer de fournir un service de voix sur les réseaux mobiles 4G. Pour cela, plusieurs solutions ont été imaginées.

CSFB (Circuit Switched FallBack)

Cette première solution consiste tout simplement à continuer d’utiliser le réseau 2G/3G pour le service téléphonique et à réserver le réseau 4G pour le service de transmission de données. Avec ce principe, le terminal mobile est connecté soit au réseau actuel GSM/UMTS soit au réseau LTE selon l’application qu’il utilise. Un échange de signalisation entre d’une part le coeur de réseau NSS (Network Sub System) et d’autre part le coeur de réseau EPC (Evolved Packet Core) du réseau 4G est alors nécessaire afin que le mobile puisse basculer vers le réseau 2G/3G lorsqu’étant connecté au réseau LTE, il reçoit ou désire émettre un appel téléphonique. S’il souhaite conserver ses communications données en cours, il est également nécessaire de basculer le mode PS établi avec le réseau 4G vers le mode PS sur le réseau 2G/3G.

VoLTE CSFB

Cette solution offre l’avantage de se baser sur des technologies existantes et éprouvées mais présente cependant plusieurs inconvénients:

  • le temps de bascule entre les réseaux 4G et 2G/3G est significatif (de l’ordre de quelques secondes en moyenne) ce qui, en terme d’expérience utilisateur, n’est guère satisfaisant et l’on voit mal les premiers utilisateurs de LTE, probablement assez technophiles et dotés de smartphones les plus récents, accepter une telle régression.
  • les transferts de données sont également perturbés durant la bascule ce qui, à l’heure des téléphones multitâches avec de nombreuses applications s’exécutant en tâche de fond, devra s’effectuer le plus rapidement possible afin de limiter l’impact en terme d’usage
  • ce modèle s’intègre mal avec des perpectives de développements de nouveaux services en isolant la voix sur des anciennes technologies sans possibilité d’évolution. Il serait ainsi impossible par exemple, de proposer des services combinant voix et données en tirant profit du débit 4G (conférence, collaboration, jeux …).

Il s’agit là des principaux écueils du CSFB qui souffre en outre d’autres insuffisances (mauvaise intégration avec de potentielles femtocells LTE, mauvaise occupation de la bande radio …).

En résumé, le CSFB offre l’avantage de permettre une réutilisation complète de l’infrastructure existante (réseau, services, systèmes de facturation ..) en ne nécessitant que quelques mises à jours mineures. Cependant il s’agit là d’une solution permettant plus de prolonger la vie du réseau 2G/3G existant que de tirer profit de l’introduction de la 4G, ce qui risque de réduire fortement l’intérêt de déployer cette nouvelle technologie.

Un mécanisme assez similaire consiste à se connecter à la fois aux réseaux 2G/3G et 4G, mais de façon simultanée afin d’éviter la phase de bascule radio. Cette approche, connue sous le nom de SVLTE (Simultaneous Voice and LTE), a également le mérite de ne pas nécessiter de modifications dans le réseau mais conduit à une plus grande complexité du téléphone ainsi qu’une consommation énergétique accrue. Des terminaux utilisant ce système sont déjà disponibles en CDMA/LTE (pas encore en GSM/UMTS/LTE).

VoLGA (Voice Over LTE via Generic Access)

Cette seconde solution permet également de réutiliser l’infrastructure voix existante mais de manière un peu plus évoluée. Elle consiste à connecter le réseau EPS au coeur de réseau NSS qui fournit le service téléphonique 2G/3G par l’intermédiaire d’une passerelle VANC (VoLGA Access Network Controller). La signalisation 2G/3G de la téléphonie est ainsi réutilisée mais est transportée sur le réseau de données 4G en étant encapsulée au sein de paquets IP. Le réseau EPS joue alors le rôle de réseau d’accès au même titre que le BSS (Base Station Sub-system) du réseau 2G ou l’UTRAN (UMTS TRAnsport Network) du réseau 3G.

VoLTE VoLGA

Cette solution présente l’avantage de n’apporter aucune modification tant au niveau du réseau EPS que du cœur de réseau NSS. Par contre, le mobile doit intégrer des adaptations pour le transport, sur le réseau 4G, de la signalisation NAS (Non Access Stratum) échangée entre le mobile et le réseau NSS.

Ce principe est déjà utilisé au sein de l’UMA (Unlicensed Mobile Access) qui permet de connecter des terminaux WiFi aux réseaux 2G / 3G. L’UMA est notamment mis en oeuvre dans l’offre Unik d’Orange qui permet d’accéder aux services 2G/3G sur son téléphone mobile à travers un réseau WiFi.

Comme le CSFB, VoLGA permet de réutiliser l’infrastructure existante, ce qui assure un déploiement rapide ainsi qu’une transparence complète du réseau vis-à-vis des services téléphoniques. De plus, VoLGA ne souffre pas des défauts majeurs de CSFB en assurant un accès simultané aux services voix 2G/3G et données LTE. Au niveau du réseau, VoLGA ne nécessite que le déploiement de quelques nouveaux éléments (VANC principalement). Le terminal, en revanche, devra également intégrer cette nouvelle technologie afin d’être en mesure d’encapsuler la téléphonie 2G/3G dans des paquets IP.

Le support de VoLGA dans le terminal constitue le principal obstacle à son adoption car cela nécessite un support fort des fournisseurs de mobiles pour une technologie de transition qui n’a pas vocation à être utilisée sur le long-terme. Ce point est de plus exacerbé par le fait qu’il s’agit d’une technologie non adoptée par le 3GPP, l’organisme qui est en charge des spécifications GSM et LTE. Par ailleurs, VoLGA, comme CSFB, ne permet pas de véritables services de convergence car les réseaux gérant la voix et les données restent séparés.

IMS (IP Multimedia Subsystem)

La dernière solution, qui est présentée comme la solution cible à long terme est celle de la mise en oeuvre de l’IMS, qui est le réseau multimédia IP spécifié par le 3GPP. Ce réseau, extérieur au réseau 4G, permet de supporter tous types de services et de réseaux d’accès. Il est notamment déjà en cours de déploiement pour la VoIP résidentiel et constitue donc pour les opérateurs et constructeurs une solution universelle et largement supportée permettant de mutualiser au maximum les nouvelles infrastructures.

VoLTE IMS

Le réseau IMS est basé sur l’emploi du protocole de signalisation SIP (Session Initiation Protocol) qui permet l’enregistrement du mobile au service téléphonique et l’établissement d’une session, et du protocole SDP (Session Description Protocol), associé au protocole SIP, qui supporte la négociation du média (voix, vidéo, données). La seconde fonction assurée par l’architecture IMS concerne le traitement du flux média pour les fonctions indisponibles dans le réseau 4G comme la conférence, la génération des annonces et les passerelles vers les réseaux téléphoniques fixes PSTN (Public Switched Telephone Network) et les réseaux de mobiles PLMN (Public Land Mobile Network).

L’utilisation de l’IMS constitue donc une rupture technologique dans les réseaux mobiles en étant la première à se baser entièrement sur un réseau de données IP. Cela garantit la plus grande richesse fonctionnelle, la possibilité d’introduire de véritables services de convergences voix/données ainsi que les meilleures possibilités d’évolution.

Cependant, la solution IMS nécessite un investissement conséquent car elle ne réutilise pas l’infrastructure existante. Par ailleurs, il s’agit d’un changement technologique majeur et il conviendra d’assurer dès le début une qualité de service et une expérience utilisateur au moins au niveau de celles actuelles afin d’éviter un rejet des utilisateurs. Naturellement, cette solution sera d’autant plus facile et moins risquée à déployer dès le début que l’opérateur dispose déjà d’une infrastructure IMS opérationnelle sur d’autres réseaux d’accès, ADSL par exemple. Afin de réduire ce risque lié à l’introduction immédiate d’un nouveau système complexe, les principaux acteurs de la téléphonie ont lancé l’initiative One Voice. Cette initiative a conduit à la définition d’un sous-ensemble de fonctionnalités IMS définies par le 3GPP. Ce sous-ensemble permet ainsi de simplifier le déploiement de l’IMS dans un cadre LTE tout en garantissant une interopérabilité maximale.

Conclusion

Il existe donc plusieurs solutions afin d’assurer un service de voix sur les nouveaux réseaux 4G. Par ailleurs, il n’est pas exclu que certains opérateurs choisissent une solution de type over-the-top basée une technologie non spécifique au 3GPP ou aux réseaux mobiles. Cela pourrait être un service basé sur l’utilisation simple de SIP ou bien encore sur une technologie propriétaire telle que Skype. Cependant cette approche, externe au réseau de l’opérateur, ne bénéficie alors pas des services de ce dernier (QoS, handover …). Il sera également intéressant de suivre les positions de Google et d’Apple ; en effet, Android et l’iPhone constituent les principaux terminaux susceptibles de bénéficier de LTE. Ces nouveaux acteurs ne sont pas issus de l’écosystème traditionnel des télécommunications et pourraient, une nouvelle fois, bouleverser ce marché. De plus, ils dominent le marché des tablettes en pleine croissance et à la base de nouveaux usages mobiles, ce qui pourrait influencer fortement les stratégies de déploiements LTE.

Le tableau ci-dessous présente un résumé des avantages et inconvénients de ces différentes technologies:

VoLTE – comparaison

Il n’existe pas de solution universelle et constituant une évolution logique et sans heurts des technologies actuellement déployées. Les opérateurs devront alors trouver le meilleur compromis adapté à leur situation et à leurs objectifs. Chacun aura donc à composer avec de multiples facteurs et prendre en compte des éléments tels que:

  • l’horizon de déploiement de la LTE
  • la couverture LTE: hotspots uniquement ou nationale
  • le type de réseau actuellement déployé et leurs potentielles évolutions
  • l’introduction de nouveaux services notamment de convergence
  • la volonté ou non de franchir le pas tout IP au plus vite
  • les technologies supportées par les partenaires de roaming ainsi que les fournisseurs de terminaux

A l’heure actuelle, il semble qu’un consensus se dégage en faveur d’une solution IMS mais, pour séduisante qu’elle soit sur le papier et à long terme, il s’agit également de la solution qui nécessite les changements les plus radicaux. CSFB est une technologie de transition simple à mettre en oeuvre mais il reste à voir si ses défauts pourront être acceptés par les utilisateurs. VoLGA est apparu comme une meilleure solution d’intérim mais souffre toujours d’un déficit d’adoption au niveau de la standardisation, ce qui compromet fortement son avenir. Enfin, SVLTE semble susciter de l’intérêt et, si les impacts sur le terminal se révèlent acceptables, pourrait constituer la solution transitoire la plus simple à mettre en oeuvre avant de basculer sur IMS.

Il sera donc intéressant d’observer dès 2012 les premiers déploiements LTE et les solutions retenues, ce qui fera l’objet de prochains articles. Nous aborderons également les technologies permettant de gérer le handover 2G/3G et LTE. En effet, la couverture LTE ne devrait être que partielle au début et il faudra également assurer la continuité du service voix en cas de sortie de cette couverture.

VoIP & NAT (1): Qu’est-ce que le NAT ?

6 janvier 2012

L’un des problèmes les plus fréquemment rencontrés lors du déploiement d’un système VoIP est celui de la traversée de NAT. Bien que le principe du NAT en lui-même soit relativement simple, les conséquences sur les protocoles de VoIP sont assez complexes et il n’existe malheureusement pas de solutions simples et universelles pour y remédier. Dans cette série d’articles, nous décrirons les difficultés rencontrées lors d’un déploiement VoIP en présence de NAT ainsi que les différentes solutions, que ce soit dans les équipements disponibles du commerce ou dans les spécifications récentes et non encore mises en pratique. Dans ce premier article, nous allons examiner ce qu’est le NAT, les raisons de l’introduction de ce mécanisme et son principe général de fonctionnement.

Les origines du mécanisme de NAT (Network Address Translation) sont intimement liées avec la démocratisation des accès à Internet au cours des années 1990. Ce réseau global se repose en effet sur l’utilisation de IPv4 (Internet Protocol version 4) qui, lorsqu’il a été défini au début des années 80, n’avait jamais envisagé une telle expansion. Il faut en effet comprendre que tout équipement souhaitant communiquer au sein d’un réseau (et par conséquent, Internet aussi), doit impérativement disposer d’une adresse IP unique, tout comme une habitation afin de pouvoir recevoir du courrier par exemple. Alors que cette dernière se repose sur le nom de rue, ville, code postal …, IPv4 code ses adresses sur 32 bits, ce qui permet de disposer d’un peu plus de 4 milliards d’adresses différentes. Au début d’Internet, ce nombre paraissant plus que suffisant et l’on ne pensait pas manquer d’adresses disponibles.

Cependant avec l’explosion des demandes d’accès, que ce soit par des particuliers ou des entreprises (pouvant utiliser parfois quelques dizaines, centaines, voire plus, d’adresses) ainsi qu’une méthode d’attribution ayant conduit à des gaspillages importants, il est apparu, dès le début des années 90, qu’un épuisement était inévitable à moyen terme.

(suite…)

Lomaco
Savelec
DGAC
athemium
LOGO-CONVERGENCE-2019_300px_mod
alten
Motorola
Astellia
AIRBUS
broadpeak
Adeunis
axione
davidson
BureauVeritas
Monaco Telecom_550x550
ESR Groupe H69
GFI
Groupama-logo
assystem-logo
sierra_wireless
neosoft
logo_SDIS54_mod
actility
logo-coriolis-telecom_mod
TuffigoRapidex
ADP
econocom
engie-ineo
Sofrecom
NETENSIA
XURA 90H
AXIANS
akio
SFR
sagemcom
Viibe
NIJI
adventiel
SopraSteria
Thales
CGI
DCNS
t&t
Keolis
nokia-logo
SII
VA SOLUTIONS2
HubOne
orange
Modis
iagility
Schneider-mod
Deltadore
cirpack
CMB ARKEA
image_et_reseau
intel
Bouygues E&S
SNCF_2011
technicolor
la poste
setelia
capgemini
Amphenol-Antenna-Solutions-Logo-2-mod
Italtel
Icosnet
Extia