Les commentaires des experts en réseau se prolongent sur le thème du protocole SIP (Session Initiation Protocol). Pour en comprendre la raison, il est nécessaire de décrypter le langage des spécialistes. Essayons, très concrètement, de suivre pas à pas le sens de leurs discussions.
Rappel de la définition de SIP
SIP est un protocole de signalisation créé par l’IETF pour la gestion de la couche application associée au transport de paquets en protocole Internet (IP). SIP gère les sessions de communication avec un ou plusieurs équipements participant à la distribution d’applications de type multimédia (dont le vocal avec VoIP). La rédaction de SIP a été reprise récemment par l’ETSI au sein du groupe TISPAN et l’UIT-T a créé de nouvelles extensions de SIP. Il existe donc, à côté du SIP de l’IETF, un SIP de l’UIT-T qui lui est complémentaire. La multiplicité des autres options SIP dans l’industrie font qu’aujourd’hui, en exploitation, il est nécessaire de préciser de quel protocole SIP il s’agit. Le transport des paquets IP pour l’usage vocal et/ou le multimédia peut utiliser sur les réseaux d’aujourd’hui un certain nombre d’options de SIP, tout comme il peut utiliser en tout ou partie du parcours le protocole H.323 ou H.325 de l’UIT-T. (Vous suivez toujours ?).
La vocation initiale de SIP
En langue anglaise, il faut comprendre que, pour fonctionner, SIP suppose l’existence d’un circuit téléphonique établi en protocole IP. Et, en général, quand on parle de "circuit" en anglais, on évoque un circuit quatre fils à longue distance constitué grâce à des techniques analogiques ou numériques (MIC ou RNIS, par exemple). Les pères fondateurs de SIP, il y a vingt ans, s’étaient mis dans la tête que SIP pourrait tout faire, pour le vocal (VoIP), les circuits, les terminaux, etc. dans une gestion de type "point à point" (peer-to-peer), même pour les équipements intermédiaires. Ce rêve mal formulé, disons-le à titre personnel, a donné lieu à un formidable malentendu. Malentendu normatif qui conduit aujourd’hui à un beau cafouillage. Que ceux qui ont compris autre chose lèvent le doigt pour un débat contradictoire qui éclairera nos lecteurs ! (Ne perdez pas le fil et nous allons vous éclairez !).
SIP et les PBX
A norme imprécise, mise en œuvre douteuse ! La plupart des autocommutateurs téléphoniques (PBX, dans le jargon technique, qui veut dire "Private Branche eXchange") sont conformes à ce protocole SIP, avec la particularité d’utiliser des terminaux téléphoniques aux normes propriétaires (c’est-à-dire "non normalisés" et donc plus coûteux que d’autres). Si l’appel téléphonique entre deux terminaux de la même entreprise utilise bien SIP à travers le PBX, la conversation, elle, s’en va par d’autres chemins qui utilisent l’intelligence du traitement de l’information de chacune des deux extrémités mises en présence. Et puis, en examinant les choses plus attentivement, il apparaît que sur le marché plusieurs SIP coexistent, avec des extensions différentes (les unes riches, les autres pauvres) et donc incompatibles. Personne, dans l’industrie, ne va s’engager dans un débat contre SIP, mais chacun va rechercher ses propres partenaires afin d’éviter la casse qui pourrait survenir si la signalisation ne parvenait plus à être comprise par des équipements étrangers au SIP utilisé. Un expert autorisé, Dave Michels, de chez Verge1 Consulting, rapporte que les serveurs OCS de Microsoft ne se connectent qu’aux trois exploitants de réseau autorisés (Sprint, Interoute, et Global Crossing). Cette limitation résulte d’une normalisation singulière et elle prouve que SIP est réellement une norme ouverte, mais également ouverte à toutes les interprétations et également ouverte aux plaisanteries (SIP being an "open" standard, is "open to interpretation"). Cet expert indique que SIP n’indique pas quel est le nombre d’appels affecté à chaque liaison à grande distance. SIP introduit des variables nouvelles qui rendent complexes l’interfonctionnement et réduisent la qualité de service et la sécurité. Par précaution, les exploitants de réseau exigent donc des essais préalables avant d’étendre le maillage des connexions SIP à d’autres équipements. (Ceci semble expliquer la lenteur et la prudence avec lesquelles les entreprises s’orientent vers le VoIP).
Avantages et inconvénients de SIP
L’intérêt de SIP, il faut l’avouer, réside dans son prix de mise en œuvre, car il n’exige pas d’équipements de terminaison numérique et parce que les PBX en IP sont peu coûteux. De plus, les canaux SIP à longue distance sont moitié moins chers que les circuits MIC et d’autant plus qu’il s’agit de liaisons à grande distance. Tout le monde profite de l’affaire, les exploitants de la concurrence, comme les historiques ! Enfin, ces canaux SIP sont facturés en fonction du volume de données réellement transmis. Aussi, une norme de fait commence à émerger (SIPConnect), qui tend à fédérer au sein du "SIP Forum" les grands acteurs industriels du domaine afin de régler les problèmes d’interface entre PBX et les différents réseaux des exploitants (y compris les nouveaux acteurs industriels impliqués dans le développement du Cloud Computing).
Deux aspects sont à considérer à ce propos, les connexions entre centraux des grands réseaux pour lesquelles le protocole de signalisation n’a pas besoin de messages complexes pour assurer les connexions à grande distance (en SIP Trunking, de préférence au protocole international QSIG), et les connexions entre PBX d’origine industrielle différente. Ce dernier aspect est bien entendu le plus ardu, puisqu’il fait intervenir des centaines de spécifications différentes, chacune liée à un constructeur spécifique, attachées à des messages, des modes opératoires différents et des fonctionnalités complexes. Il existe donc des terminaux IP et des PBX qui sont bon marché parce qu’ils ne mettent en jeu que peu de fonctionnalités de signalisation, et d’autres qui sont six fois plus coûteux, parce qu’ils sont attachés à des systèmes complexes assurant une signalisation enrichie et propriétaire.
Quid des PBX ?
La difficulté est donc reportée aujourd’hui sur la définition des PBX, lesquels vivent sans norme complète et officielle depuis que la technique numérique est apparue, il y a une trentaine d’années. Chaque industriel de PBX est libre de réaliser ses PBX à sa façon, sous réserve d’assurer un minimum de fonctionnalités définies. Actuellement, l’adoption de SIP (mais lequel ?) au sein des PBX est laissée à la discrétion des industriels. Imposer au sein des PBX une terminaison SIP supposerait de la définir avec précision (mais il faudrait trouver un consensus de niveau suffisant !). Autre aspect plus concret des choses, les fonctionnalités des PBX apportent aujourd’hui de possibles applications qui peuvent être liées à des rétributions de services récurrentes. L’industriel et l’exploitant aiment à recevoir des rémunérations périodiques liées à l’exploitation des équipements placés chez les clients. Aussi, chacun recherche l’application majeure qui le placera seul en tête des usages et des ventes (par exemple, Skype for Asterisk). D’autres vont adopter les protocoles, plus coûteux, mais plus stables et plus éprouvés, tels que MGCP ou H.323, avec des "adaptations clients", quitte à voir leur volume des ventes diminuer (Siemens illustrerait le propos).
Les solutions en vue
Comment faire simple avec une situation aussi compliquée ? Les anciens de la commutation avaient coutume de rappeler l’alternative suivante : "en matière de réseau, il faut soit concevoir un réseau bête reliant des terminaux intelligents, soit édifier un réseau super intelligent pour desservir des terminaux d’intelligence frustre". Dans le cas présent, les terminaux disposent de capacités intrinsèques fort différentes et il est sans doute logique d’abandonner le rêve d’unification des caractéristiques des PBX pour aborder une solution faisant appel aux capacités d’adaptation offertes par les systèmes d’exploitation des nouveaux terminaux.
Trois issues à ce problème semblent apparaître. Mitel, Avaya et Google proposent d’utiliser assez classiquement les ressources des applications API du RTPC par numérotation interne au PBX (direct inward dialing, DID). Digium et Siemens souhaiteraient utiliser un portail en XML limité aux fonctions jugées les plus fréquemment nécessaires (mais lesquelles ?). Et pourquoi ne pas utiliser systématiquement l’interface radioélectrique nouvelle proposée par les femtocellules, se demande Free, "l’agitateur des technologies" ? L’avenir précisera un jour l’intérêt du modèle proposé par l’iPhone et par l’Android pour toutes les applications, à moins que les clés USB ou d’autres développements encore ne viennent enrichir encore la panoplie des solutions miraculeuses et éphémères, parce que imparfaites ! (Le Diable ou le Bon Dieu sont dans les détails !).
Salon INTERNET WORLD , Du 24 au 26 Avril 2012 à Londres, INTERNET WORLD : l’évènement ... [suite]
Séminaire IPv6, Le 11 Avril 2012, à Telecom ParisTech., Le G6 organise un séminaire ... [suite]
