François Mouillaud

Selon le dernier observatoire de l’ARCEP, le trafic au départ des postes fixes est stabilisé depuis trois années par l’apport de plus en plus conséquent du trafic au départ des accès IP, qui vient compenser le reflux des communications émises sur le RTC (Réseau Téléphonique Commuté).

Au troisième trimestre 2007, le volume des minutes IP, en hausse de 79,1% sur un an, représente désormais un tiers du volume total des communications au départ des postes fixes contre 20% un an auparavant. L’utilisation du service téléphonique est également plus intensive pour un abonné en IP que pour un abonné à un service de téléphonie “ classique ”: 4h41 de communications par mois contre 2h55.

Mais nous ne sommes pour autant à l’ère du tout IP: ces appels aboutissent en grande majorité sur le RTC. Une très faible fraction est à destination de terminaisons IP, et, même dans ce cas, l’appel reste bien souvent acheminé en mode commuté (ne serait-ce, par exemple, que parce que seul le RTC sait router l’appel).

L’établissement de communications en VoIP de bout en bout dans un contexte inter-opérateurs n’est en effet pas un long fleuve tranquille. 

Petite revue de détails de ses subtilités…..non limitative !

 Circuits, canaux, ou sessions ?
Le choix semble désormais tranché entre le protocole historique de la téléphonie sur IP (H.323) et le petit dernier (SIP), ce dernier s’imposant de plus en plus par sa souplesse et sa convergence avec le monde Internet dont il est issu (RFC 3261). C’est aussi le protocole du futur réseau mobile multimédia IMS (IP Multimedia Subsystem). 

Il reste qu’aujourd’hui, le parc installé en terminaux (ou plus précisement de passerelles résidentielles) supportant la voix sur IP (les fameuses “box”) est largement dominé par H.323, et la coexistence entre les deux protocoles risque de durer un certain temps.  Et s’ils poursuivent un but commun, l’établissement de communications multimédia sur un réseau IP, SIP et H.323 sont des protocoles très différents qui ne peuvent trahir leurs origines. 

H.323 est tout d’abord non pas un seul protocole mais une suite complexe de plusieurs protocoles: H.225 qui se compose en RAS pour le contrôle d’accès et Q.931 (un proche cousin des protocoles du RNIS) pour le contrôle d’appel, H.245 enfin pour le contrôle des canaux media, sans oublier la suite des services supplémentaires décrite par les séries H.450.  H.323, qui est un protocole orienté bits comme les protocoles SS7 de l’ITU, et non orienté texte comme les protocoles Internet de l’IETF, s’attache à répliquer les pratiques du monde commuté. On y établit des canaux logiques comme on saisit des circuits commutés en téléphonie, chaque canal ayant son propre type de codage (codec): G.711, G.729 ou tel protocole vidéo par exemple. 

SIP, lui, propose un modèle d’établissement de sessions plus léger: il n’est plus question d’ouvrir des canaux de manière péremptoire (à prendre ou à laisser en quelque sorte), mais de proposer des sessions media à travers une offre de capacités, proposition qui commence par l’ouverture d’un ou plusieurs “dialogues”. Pour changer en cours d’appel (de codecs, de ports media, d’utilisateurs…), il ne sera pas nécessaire de fermer et de rouvrir de canaux mais de simplement renégocier les termes de la session. Un terminal SIP pourra ainsi proposer dans un message initial (INVITE) les capacités G.711, G.729, Fax T.38 et vidéo H.263 par exemple, charge à l’entité destinataire de répondre ce qu’il peut… et surtout ce qu’il veut faire. 

L’ambigüité réside dans l’interprétation de l’offre: simple description de capacités, ou proposition ferme d’établir une session ? Si j’affirme savoir faire du fax temps réel avec T.38, la session que je m’apprête à établi est-elle réellement destinée à envoyer un fax ? 

C’est la loi de l’offre et de la demande, nous dit la RFC 3264 qui modélise ce scénario d’offre/réponse dans le cas général, avec ses multiples possibilités de négociation, renégociation, changement de type de media, ajout d’une session vidéo, ou encore….passage d’un appel voix à un appel fax temps réel en T.38 !  SIP a bel et bien normalisé la description des capacités des terminaux (RFC 3407), ce qui permet de lever l’ambigüité entre demande de session et annonce des capacités et va dans le sens d’un meilleur interfonctionnement, mais cette extension est peu mise en œuvre dans la pratique. 

Ces approches “philosophiquement” différentes tournent vite au casse-tête lorsqu’il s’agit de faire inter-fonctionner les modes SIP et H.323. Surtout s’il on réalise que H.323 propose plusieurs modes d’établissement des canaux media, en particulier le mode “fast start” ou les canaux logiques sont proposés dès le message initial d’établissement d’appel, et le mode “slow start” où ils ne sont proposés qu’après la réponse du demandé, une fois les capacités des terminaux connues. 

Les différences ne s’arrêtent pas là, la palme de la complexité de l’interfonctionnement étant certainement remportée par le passage d’un appel audio à un appel fax en mode T.38 en cours d’appel: il faut alors détecter la tonalité fax, renégocier les paramètres de la session côté SIP, fermer puis rouvrir des canaux H.323.  Et ne parlons pas des spécificités exotiques de SIP comme le “forking”, qui permet de faire sonner plusieurs terminaux en parallèle pour un unique appel entrant, en établissant autant de dialogues “provisoires” en phase de sonnerie (d’où la métaphore de la fourchette)…pour n’en choisir qu’un au final.

Les codecs à l’heure des choix
Dans le monde commuté, le codage des flux media était simple, tout passait en mode MIC (Modulation par Impulsions et Codage), ce qui garantissait une “normalisation” du codage pour les appels voix, tout en autorisant des capacités support différentes (voix, data, fax..). Le signal traité dans la bande passante du téléphone (300 à 3400 Hz) était échantillonné à 64 kbit/s dans tous les cas, et garantissait un temps de traversée du réseau uniforme. 

En voix sur IP, rien de tel, toute communication doit spécifier le codage des paquets véhiculés par le protocole RTP. Le codec G.729 ou ses variantes (l’annexe A, moins complexe, l’annexe B qui propose la détection d’activité vocale et la génération de bruit de confort) y sont très demandés, notamment pour leur débit moins important (8 kb/s), autorisé par la compression. 

De plus, les échantillons voix sont codés en paquets RTP de durées variables (de 10 à 40 ms en général), la valeur 20 ms étant la plus usuelle. Sans parler des services demandant une synchronisation précise et une latence à peu près constante dans le réseau comme le fax temps réel. Enfin, certains accès (dits reach ADSL) sont trop distants du central  pour supporter un codec non compressé et doivent utiliser le G.729…mais il est impossible de le savoir par la seule analyse du numéro. 

Un problème de taille se pose en cas d’interfonctionnement entre deux offres de téléphonie ne supportant pas les mêmes codecs, ou les mêmes temps de « paquétisation ». Un élément réseau de transcodage doit alors être mis en coupure des flux signalisation et media de manière à réaliser l’adaptation. Les cas d’usages de tous les services (grand public, entreprise) et de leurs variantes (messageries, serveurs de tonalités “colorisées” par exemple) dans les différents scénarios (renvois ou transferts d’appels) promettent de beaux jours aux architectes réseau ! 

Les DTMF, un service de base… pas si basique
Un autre service “de base” en téléphonie peut jouer des tours inattendus: les DTMF (ces combinaisons de fréquence obtenues en pressant les touches d’un clavier, et incontournables dans les services types carte d’appel, menus vocaux et en général tout service nécessitant une identification par l’utilisateur). 

En téléphonie classique les tonalités DTMF sont transportées dans la bande audio sans être distinguées de la voix. Mais en ToIP, cela n’est possible qu’avec des codecs permettant de les transmettre sans distorsion de fréquence, comme le fait G.711 dans le RTC. En particulier, G.729, et surtout ses variantes moins complexes, ne permettent pas de garantir de manière certaine la transmission du signal dans la bande. 

Pour contourner le problème, les DTMF ont été retirées du flux voix et codées à part dans des paquets RTP spécifiques dits NTE (Named Telephone Events), identifiés par un codage (payload type) distinct des codecs voix et normalisé par la RFC 4733 (anciennement RFC 2833, désormais obsolète).

Le problème se complexifie quand on sait que H.323 ne supportait pas ce codage avant sa version 4, et que les DTMF étaient alors transmis hors bande, dans des messages spécifiques de signalisation H.245.  Suivant les services et les protocoles, voire selon l’interfonctionnement protocolaire propre à chaque appel, il faudra donc utiliser le codage hors bande ou dans la bande à la mode RFC 4733, et, dans ce dernier cas, s’assurer que le codage identifiant ces DTMF sera bien compris de tous les éléments réseau.

Ce qui est d’autant moins évident que certains sont en coupure de tous les types de flux (transcodeurs, contrôleurs de sessions), alors que d’autres ne voient passer que la signalisation d’appel (call servers), ou seulement les flux media (passerelles media) et leurs manipulations (protocoles MGCP / H.248).

Si ce payload type est en principe négociable et potentiellement différent en émission et en réception, comme tout autre paramètre d’un SDP de session SIP (car en fin de compte il est traité comme un codec), dans les faits toutes les passerelles media ne supportent pas un payload qu’elles n’ont pas préconisé elles-mêmes.

Obligations légales et services
Le paysage se complique avec les problématiques liées à des obligations légales et les services supplémentaires. Ainsi, la portabilité entre numéros géographiques classiques et numéros IP (en 08 ou 09) induite par les offres de type dégroupage total ou offres en zones non dégroupées dites ADSL nu (offres sans abonnement téléphonique associé) rajoute une complexité d’analyse. 

Surtout, l’acheminement ne peut plus  reposer sur une simple analyse du numéro, et les différents services offerts par les opérateurs en VoIP se superposent aux services téléponiques classiques, avec lesquels ils doivent rester compatibles, tout en supportant les nouveaux usages, comme la messagerie unifiée où l’activation du service par le client (self-care). Ce sont à chaque fois autant de traitements spécifiques à mettre en œuvre et qui complexifient le traitement de l’appel.

Par exemple, les numéros d’urgence doivent être routés en fonction de la localisation géographique de l’accès de manière à aboutir au bon service de proximité. Quand la ligne n’a plus d’identification sur le RTC, il est nécessaire de provisionner de manière spécifique son code Rivoli pour permettre ce routage. Les services d’urgence doivent également pouvoir connaître la localisation géographique de la ligne… ce qui aboutit à créer un nouvel annuaire. 

Quant aux services, si H.323 a bien balisé le terrain de la normalisation – à la mode ITU -, la situation est souvent plus floue avec SIP. Un service nécessite ainsi souvent le support de plusieurs RFC pour pouvoir fonctionner correctement. Entre RFC ou Internet Drafts plus ou moins partiellement implémentés par les industriels, interfonctionnements de services entre SIP et H.323 non normalisés, obligations de sécurité renforcées sur les points d’accès nécessitant un strict contrôle des headers SIP, le bouquet des services que nous connaissons en téléphonie mettra un peu de temps avant de s’épanouir… même si, désormais, les opérateurs ont pris le rythme d’Internet !