La transition entre IPv4 et IPv6 se rapproche toujours un peu plus, et il convient de se préparer à aborder cette transition au mieux. Le cadre le plus intéressant à considérer ici dans le monde de la ToIP (Telephony over IP) se repose sur l’utilisation du protocole SIP (Session Initiation Protocol), majoritairement utilisé à l’heure actuelle et en voie de devenir toujours plus important à l’avenir. Le déploiement de IPv6 se fera progressivement, et il y aura obligatoirement une période plus ou moins longue pendant laquelle IPv4 cohabitera avec IPv6. Si IPv6 n’apporte aucun réel changement par rapport à IPv4 dans le fonctionnement général des réseaux, ces deux protocoles sont néanmoins incompatibles directement, et il est nécessaires de pouvoir effectuer une transition de la manière la plus transparente possible.

(suite…)

Au sein de notre série d’articles relatifs à la traversée de NAT, nous avons abordé, dans cet autre billet, une approche courante envisagée par les acteurs de l’industrie : les ALG et SBC. Nous en avions conclu que cette approche, si elle n’est pas dénuée de bon sens, est sujette principalement à deux gros problèmes :

• Les implémentations « grand public » des ALG sont le plus souvent lacunaires, engendrant plus de problèmes qu’elles en résolvent.
• Les SBC requièrent des compétences et connaissances coûteuses les réservant à certains types d’environnements.

Il était par conséquent nécessaire de combler le vide qui caractérisa la traversée de NAT pendant longtemps, avant que les standards commencent à se développer sérieusement. Des approches ont été envisagées par les différentes implémentation de serveurs SIP au fil du temps, que ce soit de soft switch/IPBX complets (Asterisk, FreeSWITCH) ou de « simples » proxys. Nous allons nous attarder ici particulièrement sur ce dernier cas, et en particulier sur OpenSIPS, un proxy SIP particulièrement performant, modulaire et évolutif.

(suite…)

Lors de nos différents articles relatifs aux solutions de traversée de NAT, nous avons détaillés les approches proposées par l’IETF (received/rport, SIP-OUTBOUND, STUN, TURN, ICE) et étant par conséquent normalisées. Ces protocoles, s’ils offrent ensemble une approche complète, efficace et évolutive, sont malheureusement pour la plupart très récents : les acteurs de l’industrie (opérateurs, intégrateurs, …) ont dû trouver des solutions qui leur ouvraient l’utilisation de SIP/RTP dans le cadre de la voix sur IP. Plusieurs solutions existent à ce niveau, mais la plus commune à l’heure actuelle est caractérisée par les ALG (Application Level Gateways) et, de manière plus spécifique, les SBC (Session Border Controllers).

(suite…)

Dans notre précédent article, nous avons commencé à discuter des mécanismes régissant le protocole ICE, notamment lorsque le processus s’initie : récupération des couples adresse/port par lesquelles une extrémité sera en mesure d’émettre une requête, puis les échanger avec la partie distante jusqu’à ce que l’un comme l’autre disposent de l’ensemble des informations. Cette étape est essentielle, mais, comme dans la réalité, lorsque des candidats sont définis, il faut encore, par la suite, les élire de manière à définir lequel sera choisi au final. Ce second article sur ICE traite de ce sujet en particulier : la sélection d’un candidat au travers de tests de connectivité.

(suite…)

ICE, ou Interactive Connectivity Establishment, apporte un niveau d’abstraction aux protocoles STUN et TURN décrits dans les articles précédents (respectivement ici et là). Alors que beaucoup de solutions, et STUN et TURN en font partie lorsqu’ils sont utilisés indépendamment, plaçaient l’intelligence au niveau des serveurs (ceux-ci détenant le maximum d’informations), ICE fait le pari inverse : intégrer cette intelligence au niveau du client. En effet, comme le discutera cet article ainsi que le suivant, les serveurs ne servent désormais que d’outils permettant au client d’apprendre et de connaître son environnement.

(suite…)

Lors de notre précédent article, nous avions discuté de STUN, dont les fonctionnalités offrent déjà une gamme de services intéressantes. Il avait cependant été question que cette traversée de NAT, si elle est efficace, n’est pas exhaustive, puisque seuls les NAT dont les associations sont créées indépendamment de la destination sont supportés. Malheureusement, beaucoup de NAT à l’heure actuelle ne fonctionnent pas de cette manière, étant bien souvent des NAT symétriques ou, plus manière plus générique, dépendants de la destination. TURN (Traversal Using Relays around NAT) a été étudié comme un extension à STUN venant particulièrement combler ce problème en proposant une approche se basant sur un serveur relai servant de pont entre les deux parties.

(suite…)

Dans cet article, nous discutions des méthodes permettant la traversée de NAT des messages SIP, tant pour les réponses que les requêtes. Nous avons mentionné une méthode permettant de maintenir les différentes associations au niveau du NAT valides en utilisant le protocole STUN. Toutefois, qu’est-ce que STUN et comment fonctionne-t-il ?

(suite…)

Lors de notre dernière incursion dans les méandres des NAT en VoIP, nous avions discuté de la méthode envisagée pour permettre aux réponses SIP (200 OK par exemple) d’atteindre leur cible. Il avait toutefois été noté qu’il était, en théorie, impossible de réutiliser ces informations dans le but d’acheminer des requêtes SIP (INVITE par exemple). L’IETF a de ce fait imaginé une méthode spécifique permettant aux requêtes distantes de contacter un client situé derrière un NAT : SIP-OUTBOUND. Alors que les attributs received et rport modifient les entêtes Via, cette méthode s’occupe d’altérer les informations contenues dans le Contact afin de pouvoir acheminer la requête correctement. Mais si elle se limitait à ceci, elle n’aurait que peu d’intérêts.

(suite…)

Dans la continuité des articles relatifs au NAT en ToIP publiés précédemment (introduction sur les NAT et terminologie des NAT), examinons tout d’abord le problème du point de vue de SIP, ainsi que les méthodes de résolution pouvant s’appliquer.

Lorsque SIP (Session Initiation Protocol) a été initialement spécifié aux alentours des années 2000 (mars 1999 pour être exact), il est intéressant de noter que, si les NAT existaient déjà et étaient déployés de manière conséquente, il n’a jamais été question de leur traversée par le protocole. De l’aveu même de ses auteurs, le protocole n’est pas pensé pour géré le NAT :

« A host behind a network address translator (NAT) or firewall may not be able to insert a network address into the Via header that can be reached by the next hop beyond the NAT. Use of the received attribute allows SIP requests to traverse NAT’s which only modify the source IP address. NAT’s which modify port numbers, called Network Address Port Translator’s (NAPT) will not properly pass SIP when transported on UDP, in which case an application layer gateway is required. When run over TCP, SIP stands a better chance of traversing NAT’s, since its behavior is similar to HTTP in this case (but of course on different ports). »

Pire encore, la seule fonctionnalité qui lui permettrait de gérer ce problème partiellement s’avère lacunaire, puisqu’elle ne prend en considération que l’adresse et non le port. Mais pourquoi SIP a-t-il autant de problèmes à traverser les NAT ? Tout simplement car SIP, en tant que protocole applicatif, transport ses propres adresses et ports au sein de ses messages de manière à établir des sessions entre deux entités. Toutefois voici ce qui se passe réellement lorsqu’une requête SIP traverse un NAT :

Lorsque le client émet une requête à destination de son proxy SIP (1), il forme son message SIP en utilisant les adresses et ports dont il a connaissance, c’est-à-dire des adresses privées, en règle générale. Ces informations correspondent pour le moment aux entêtes TCP/IP permettant le routage des paquets vers leur destination. Toutefois, lorsque le message va avoir traversé le NAT (2), ce dernier va modifier les entêtes TCP/IP des paquets afin que les réponses puissent aboutir et pointer vers l’adresse, non plus du client (privée et inaccessible depuis l’extérieure), mais publique. Malheureusement, le NAT ne fonctionnant qu’au niveau du réseau (TCP/IP), il n’est pas en mesure de modifier le contenu du message SIP en tant que tel. De ce fait, aucune réponse SIP ne pourra aboutir correctement.

Dès lors, comment procéder à la résolution de ce problème au niveau SIP ? Les auteurs de la spécification originelle avaient envisagé une gestion lacunaire des réponses SIP (par l’entête Via) au travers d’un attribut received. Lorsqu’un serveur reçoit une requête, il définit cet attribut en y associant l’adresse par laquelle la requête a été émise. Puisqu’il réceptionne la requête modifiée du NAT, il est en mesure de connaître l’adresse à laquelle il doit envoyer les réponses à la requête. Toutefois, comme le suggère notre précédent post, il manque une composante importante afin que les réponses soient acheminées correctement : le port !

Ce manque a été comblé en 2003 avec l’introduction d’un nouveau paramètre au champ Via : puisque l’adresse est récupérée dans un attribut received, pourquoi ne pas stocker le port de manière similaire. Cette extension au protocole SIP rajoute par conséquent un attribut rport (pour received port) qui permet de stocker, en plus de l’adresse, le port par lequel la requête a été émise du NAT. L’ajout de cette fonctionnalité permet l’introduction du concept de réponse symétrique (symmetric response) qui réutilise systématiquement le même couple adresse/port pour émettre et recevoir.

Client SIP :

INVITE sip:ua2@nexcom.fr SIP/2.0

Via: SIP/2.0/UDP 10.0.0.1:4540;rport;branch=Kkjshdyff

Proxy SIP :

INVITE sip:ua2@nexcom.fr SIP/2.0

Via: SIP/2.0/UDP proxy.nexcom.fr;branch=Kkjsh77

Via: SIP/2.0/UDP 10.0.0.1:4540;received=123.4.56.78;rport=9988

;branch=Kkjshdyff

Malheureusement, ces paramètres ne s’appliquent qu’aux réponses (par exemple 180 Ringing), mais ne permettent pas, par leur conception, d’être utilisés en dehors de ce cadre, notamment pour acheminer des requêtes venant d’un utilisateur distant souhaitant contacter le client. Comme nous en discuterons, certaines implémentations ont contourné ce problème en stockant par exemple ces valeurs de manière persistante afin de les réutiliser dans d’autres cas de figures (ce qui est en soi relativement malin). Toutefois, ce genre de solution ne respectent pas le cadre classique des standards, qui définissent une méthode spécifique pour ce cas précis, et qui sera détaillée prochainement dans un nouvel article : la spécification SIP-OUTBOUND !

Stay tuned !

Nous avons présenté dans notre précédent article les principaux concepts et l’architecture générale de RTCWeb. Nous abordons maintenant dans ce billet, l’API WebRTC, qui va permettre aux applications s’exécutant dans les navigateurs Web d’exploiter toutes ces fonctions. Cette API, encore à l’état de working draft, est développée par le W3C (World Wide Web Consortium) et utilise de nombreux éléments introduits en HTML5 (balise video par exemple).

Notre objectif dans cet article est de décrire le fonctionnement global de l’établissement de session entre deux navigateurs. L’implémentation d’une telle fonction repose sur 3 phases principales: l’acquisition des ressources audio/vidéo dans le navigateur de l’émetteur, la transmission de ces flux sur le réseau et le rendu sur le navigateur du récepteur. Nous décrivons ainsi les deux principales primitives WebRTC permettant d’atteindre ce but: la Stream API qui permet la manipulation de ressources multimédias et l’interface PeerConnection qui assure la communication à travers le réseau. Nous présentons les principes généraux de ces deux primitives sans rentrer, à ce stade, dans les détails de l’API car ces derniers ne sont pas stabilisés et vont encore faire l’objet de nombreuses modifications.

Stream API

La Stream API, et en particulier son objet MediaStream, est au cœur du fonctionnement de WebRTC. Toute la partie multimédia passe par elle, quelle que soit la source et la destination du trafic.

Un flux média (media stream en anglais) contient et traite les pistes audio et vidéo. Ces flux peuvent provenir de différentes sources (locales ou distantes), et sont émis à des destinations variables (locales ou distantes également). Au sein de cette interface, seul l’objet MediaStream reste immuable quelle que soit le cas de figure considéré.

Les différentes étapes illustrées sur la figure ci-dessus sont les suivantes:

1. Construction de l’object MediaStream

L’objet MediaStream prend en paramètre soit une connexion distante (PeerConnection, voir ci-après), soit un objet LocalMediaStream ayant accès aux ressources locales du terminal. Ces accès, pour des raisons de sécurité, doivent être explicitement donnés par l’utilisateur au cas par cas, via l’usage de boutons (« Diffuser ma vidéo » pour autoriser le flux vidéo par exemple) ou par des préférences dédiées à chaque page et gérées par le navigateur. La fonction getUserMedia() récupère, simultanément ou séparément (il est possible de l’appeler plusieurs fois), les différentes sources afin de les traiter par la suite.

2. Sources locales

Ces ressources peuvent émaner de différentes origines, notamment d’équipements de capture en temps réel (microphone, webcam, caméra …) ou de fichiers locaux au terminal. Le support de ces différentes sources est assurée grâce aux nouvelles fonctionnalités offertes par HTML5 (File API, Media Capture).

3. Gestion des différents flux

Un MediaStreamTrack est créé pour chacun des flux, audio ou vidéo. Puisqu’il peut exister de multiples flux simultanés (plusieurs microphones distincts par exemple), ceux-ci sont stockés au sein de listes de type MediaStreamTrackList. Ces listes sont utilisées pour créer le flux média (MediaStream). Il est ici intéressant de noter plusieurs points :

• Grâce à ces listes, l’objet MediaStream est dynamique. Il devient en effet possible d’ajouter et de retirer à la volée des flux multimédias sans avoir besoin de recréer un nouvel objet (fonction add() de l’objet MediaStreamTrackList).
• Les pistes audio peuvent contenir un nombre variables de canaux (mono, stéréo, 5.1 …), permettant leur utilisation dans de multiples situations différentes. Ces canaux sont les plus petites unités d’un MediaStream.

4. Utilisation du MediaStream

Cet objet MediaStream peut ensuite être utilisé dans divers cas de figures :

• le flux peut être directement affiché dans le navigateur local, ce qui peut servir à afficher le retour d’une webcam locale ou le flux en provenance d’un tiers via un objet PeerConnection en entrée;
• les flux peuvent être enregistrés dans des fichiers locaux;
• les flux peuvent être envoyés à un tiers à l’aide d’un objet PeerConnection, ce qui est est l’objectif même de WebRTC.

La pratique veut que ces objets MediaStream disposent d’un URL pour l’objet binaire qu’il représente (BLOB ou Binary Large OBject). La fonction createObjectURL crée cet URL. Les données de l’objet que cet URL représente doivent être compréhensibles directement par les éléments HTML5 audio ou video.

Dernier point intéressant au sujet de cette Stream API, il est possible d’adjoindre à ce schéma général un objet MediaStreamRecorder permettant, comme son nom le laisse suggérer, d’enregistrer en temps réel les flux audio/vidéo. Cet enregistrement est représenté sous la forme d’un BLOB. Cet enregistreur doit être capable de gérer efficacement l’ajout ou la suppression de MediaStreamTrack du flux multimédia.

Pour plus d’informations sur la gestion des fichiers et des BLOB, se référer à la File API.

La figure ci-dessous illustre un cas d’usage typique du fonctionnement de MediaStream. La fonction getUserMedia() (1), déclenchée par un bouton, autorise l’accès aux différents équipements (microphone, webcam …) (2) afin d’en récupérer les flux audio/vidéo. Ces LocalMediaStream ou MediaStreamTrack sont traité par la fonction appelée (callback) en cas de succès, afin de les ajouter aux MediaStreamTrackList d’un objet MediaStream, créant effectivement le flux média. Celui-ci peut ensuite être ajouté à une connexion sortante (4) PeerConnection afin de transmettre le flux à un destinataire.

PeerConnection API

Si l’objet MediaStream discuté précédemment est incontournable pour la manipulation des flux multimédias, l’objet PeerConnection de son côté est primordial pour l’établissement d’une connexion, de manière transparente, entre deux entités RTCWeb. Définie au sein de la même spécification que la Stream API, cette API risque d’être altérée en profondeur dans les mois à venir puisque l’IETF est en train de définir un framework d’établissement de session pour RTCWeb/WebRTC (JSEP ou Javascript Session Establishment Protocol actuellement en draft00) qui va avoir un impact certain sur les routines de l’objet PeerConnection. Partant de ce constat, nous faisons ici le choix de n’énoncer que les éléments généraux qui seront probablement traités par l’objet, d’une manière ou d’une autre.

L’objet PeerConnection gère l’ensemble de l’établissement de connexion avec la partie distante. Actuellement, comme décrit dans la figure ci-dessus, lors de sa création, il est possible de remarquer qu’il prend deux paramètres qui traitent de deux aspects bien distincts :

• Son premier paramètre spécifie un serveur STUN/TURN pour la traversée de NAT des flux multimédias qui systématiquement tentée par l’usage d’ICE.
• Son second paramètre définit la fonction à appeler (callback) pour envoyer des messages de signalisation. Il est dès lors possible de manipuler et personnaliser les messages envoyés au destinataire via cette fonction.

La signaling callback passée en second paramètre permet de générer les messages de signalisation, nécessaires pour échanger les informations de connexion, grâce à SDP. Le protocole de signalisation en lui-même (SIP, Jabber/Jingle, propriétaire) est laissé au libre choix de l’implémentation. Afin de permettre l’utilisation de SIP dans ce cadre, un draft est en discussion au sein de l’IETF afin d’ajouter un transport de type WebSocket au protocole SIP.

Encore peu utilisé au sein de la VoIP actuellement, le protocole ICE va gagner, avec ces implémentations, ses lettres de noblesse puisqu’il prend ici une place centrale dans la traversée des NAT des flux multimédias. Si les détails de son fonctionnement sortent du cadre de cet article, rappelons toutefois qu’il a pour objectif de négocier automatiquement et de manière totalement transparente la connexion en effectuant de multiples tests de connectivité entre les deux terminaux (ici, les navigateurs) après avoir récupéré son adresse publique et une éventuelle adresse relai grâce respectivement au serveur STUN ou TURN passé en paramètre. L’efficacité de ce protocole n’est plus à prouver et son déploiement dans ce cadre renforce encore la facilité d’accès par les utilisateurs finaux aux applications développées sur cette base.

Démonstration basique

Afin d’illustrer cette API, nous vous présentons ci-dessous un exemple, très simple, d’utilisation de l’objet MediaStream, sans connexion à un hôte distant, mais en affichant le retour direct du flux d’une webcam connectée sur votre ordinateur. Seule une démonstration basique est proposée ici pour plusieurs raisons :

• La spécification est encore au stade de brouillon fonctionnel (working draft) et est donc fortement susceptible de changer à l’avenir. Notamment, l’objet PeerConnection est actuellement en pleine refonte, mais il est aussi probable que des modifications soient apportées à MediaStream également.
• Les implémentations sont expérimentales et souvent instables. En l’état ici, seuls les navigateurs expérimentaux Opera Labs Camera et Google Chrome Canary sont supportés. Si vous testez cette page avec ces navigateurs, ils doivent vous demander si vous souhaitez autoriser ou non l’usage de la webcam. A noter que Chrome Canary nécessite une configuration manuelle à l’adresse chrome://flags afin d’activer l’option MediaStream

Note: nous ne pouvons garantir un fonctionnement optimal de cette démonstration, ces fonctions étant expérimentales et susceptibles de changements à tout moment dans les implémentations.

Si cette démonstration est extrêmement basique, elle donne un aperçu de ce que ces deux APIs, relativement simples, peuvent offrir lorsque les implémentations seront finalisées et massivement déployées (téléphonie/visiophonie à partir d’un simple navigateur de manière standardisée, …). Les progrès réalisés au cours de ces derniers mois sont impressionnants et présagent du meilleur pour RTCWeb et son API, WebRTC. A suivre …

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…)

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:

• à l’IETF dans le cadre du RTCWeb Working Group pour la définition des formats et protocoles utilisés pour la communication entre navigateurs
• au W3C dans le cadre du Web Real-Time Communications Working Group pour la définition des APIs mises à disposition des applications Web

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.

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.

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

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…)