Brevet FR2894418A1 — publié le 20070608

La présente invention a pour objet un procédé permettant d'assurer l'acheminement sécurisé de messages sur des réseaux informatiques en assurant le franchissement de dispositifs tels que des routeurs, des coupe-feu et des serveurs proxys. 15 Elle concerne notamment le transport de la parole sur les réseaux IP que l'on désigne sous l'appellation VoIP (Voice over Internet Protocol). D'une façon générale, le transport de la voix téléphonique sur IP nécessite de pouvoir franchir les routeurs, les coupe-feu et les serveurs proxys présents sur 20 les réseaux afin de pouvoir acheminer les messages de parole à son destinataire. On sait que pour franchir des routeurs effectuant de la NAT (Network Address Translation) ou translation d'adresses réseau, on a proposé des solutions qui ont été synthétisées dans le document de l'IETF : Best Current Practices for NAT Traversal for SIP, draft - ietf ù sipping-nat- 25 scenarios-02, C. Boulton et J. Rosenberg . Parmi ces solutions, figurent : • L'utilisation du protocole STUN (a Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NAT) - RFC 3489) qui permet à des applications de découvrir la présence et le type de routeurs NAT (ou plus généralement de 30 dispositifs effectuant de la NAT) qui séparent le réseau privé et le réseau public. Ce protocole permet également aux applications de 1 - 2 déterminer les adresses IP et les ports publiques qui lui ont été assignés par lesdits routeurs NAT. De cette façon, un téléphone supportant le protocole STUN peut indépendamment remplacer son adresse IP et son port sources par l'adresse IP et le port publics assignés par le routeur NAT. Ainsi, après avoir pris connaissance de son adresse IP et de son port publics grâce à une requête STUN émise à destination d'un serveur STUN, un client de VoIP pourra les intégrer dans sa requête INVITE SIP afin que les requêtes / réponses ultérieures du destinataire soient dirigées vers cette adresse et ce port publics. Ce protocole STUN présente néanmoins l'inconvénient de ne pas fonctionner à travers un dispositif effectuant de la NAT symétrique. En effet, dans ce cas, un nouveau couple spécifique adresse IP / port publics est créé pour chaque nouvelle destination par conséquent, en utilisant le protocole STUN, les requêtes/réponses émises par le destinataire ne pourront être dirigées vers ce couple spécifique. • L'utilisation du protocole TURN ( Traversa/ Using Relay NAT ) qui permet à un client de VoIP envoyant une requête TURN à un serveur TURN d'obtenir en réponse un couple adresse IP / port publics permettant de joindre ledit serveur TURN, celui-ci établissant une relation entre ce - dit couple et le couple adresse IP / port publics affecté par le routeur effectuant de la NAT symétrique. De cette manière, les messages à destination dudit client VoIP seront dirigés vers le serveur TURN qui les redirigera ensuite vers ledit routeur NAT. Le protocole TURN présente néanmoins l'inconvénient de ne pas permettre à un client VoIP de commander un serveur tel qu'un serveur Web ou SMTP en utilisant l'adresse IP publique affectée par le serveur TURN. • L'utilisation de la méthodologie ICE (Interactive Connectivity Establishment) qui a recours à différents protocoles tels que les protocoles STUN et TURN afin de proposer une solution unifiée. Cette méthodologie consiste pour le client VoIP à récupérer plusieurs couples adresse IP / port publics en émettant des requêtes STUN et TURN. Ces couples sont ensuite intégrés par ledit client de VoIP dans des paramètres candidate de l'application SDP de sa requête INVITE SIP. Chaque candidate comprend notamment un niveau de priorité et au moins un couple adresse IP / port lié à un protocole (RTP, RTCP) de cette façon, après avoir testé chacun de ces couples adresse IP / port avec son destinataire (en envoyant et en recevant des requêtes STUN), le client VoIP et son destinataire pourront communiquer en échangeant de la parole dans les deux sens. Néanmoins, tout comme le protocole TURN, la méthodologie ICE ne permet pas à un client VoIP de commander un serveur tel qu'un serveur Web ou SMTP en utilisant l'adresse IP publique affectée par le serveur TURN. De plus, cette méthodologie tout comme les protocoles STUN et TURN n'offre pas de solution de cryptage et ne résout pas le problème du franchissement des coupe-feu. On sait également que pour franchir les coupe-feu, on a recours à la mise en place de tunnels. Cette technique qui est désignée sous l'appellation "tunneling" consiste à transporter un protocole et ses données dans un autre : les paquets d'un protocole donné font l'objet éventuellement d'une transformation réversible, puis sont encapsulés par un protocole de niveau équivalent dans le modèle OSI, voire inférieur ; ce protocole d'encapsulation permettant de protéger les données qu'il transporte. Une des solutions de "tunneling" consiste à envoyer des données vers un Client Tunnel - HTTP qui les encapsule dans des tunnels HTTP et les dirige vers les serveurs Tunnel - HTTP . Ces serveurs transmettent ensuite ces données vers la destination désirée et dirigent les réponses vers le Client Tunnel HTTP . Toutefois, ce type de technologie présente au moins l'un des inconvénients suivants : • la difficulté de procéder à un cryptage sélectif des flux ; • une possibilité d'utilisation réduite à un nombre limité de systèmes d'exploitation ; • la nécessité d'utiliser des API ( Application Programming Interface ) qui ne sont disponibles que pour des plateformes spécifiques ; 5 • l'augmentation de la consommation de la bande passante ; • une sollicitation accrue des ressources machine. L'invention a donc plus particulièrement pour but de supprimer ces inconvénients. 10 A cet effet, elle propose un procédé permettant d'acheminer un flux de données sur les réseaux IP en assurant le franchissement de tous les routeurs quel que soit le type de NAT mis en oeuvre, de la plupart des coupe-feu et des serveurs proxys ; cet acheminement des données par la mise en oeuvre dudit 15 procédé pouvant s'effectuer de manière sécurisée tout en optimisant la bande passante. Selon l'invention, ledit procédé comprend la réalisation des étapes suivantes : • l'ouverture d'un tunnel entre un client de tunnel A et un serveur de 20 tunnel A' ; • l'émission d'une requête par le client de tunnel A vers le serveur de tunnel A' ayant pour objet d'obtenir les références du couple constitué par l'adresse IP et le port publics qui devront être utilisés par le destinataire du client de tunnel A afin de lui acheminer des messages ; 25 • l'accomplissement préalable et éventuel d'un traitement spécifique d'encapsulation des données constituant ladite requête à transmettre ; ce traitement consistant à encapsuler la requête dans une trame dont la structure permet de garantir la communication entre le client de tunnel A et le serveur de tunnel A'; ce traitement spécifique pouvant 30 comprendre une étape supplémentaire consistant à encapsuler ladite trame dans une trame http afin de permettre le franchissement de la plupart des coupe - feu ; • la réception de cette requête par le serveur de tunnel A', la décapsulation éventuelle des paquets la constituant et l'émission d'une réponse à destination du client de tunnel A dans laquelle figure ce couple adresse IP / port publics, cette réponse étant acheminée dans ledit tunnel après avoir éventuellement procédé audit traitement spécifique d'encapsulation ; • la réception de cette réponse par le client de tunnel A et l'accomplissement éventuel d'une décapsulation des paquets la constituant ; • l'envoi par le client de tunnel A d'une requête à destination d'une entité déterminée contenant l'instruction de diriger les réponses à cette requête en utilisant l'adresse IP et le port publics constituant ledit couple ; cette requête étant acheminée entre le client de tunnel A et le serveur de tunnel A' dans ledit tunnel après avoir éventuellement procédé audit traitement spécifique d'encapsulation ; • la décapsulation partielle éventuelle des paquets constituant ladite requête au niveau du serveur de tunnel A' ; • la transmission par le serveur de tunnel A' de cette requête modifiée vers ladite entité déterminée ; • l'émission d'une réponse éventuelle par cette entité déterminée en utilisant les références dudit couple constitué par ladite adresse IP et ledit port publics ; • la réception par le serveur de tunnel A' de cette réponse ; • l'accomplissement éventuel dudit traitement spécifique d'encapsulation par le serveur A' ; • la transmission de cette réponse modifiée par le serveur de tunnel A' à destination du client de tunnel A, cette réponse étant acheminée dans ledit tunnel ; • la réception de cette réponse modifiée par le client de tunnel A et l'accomplissement éventuel d'une décapsulation des paquets la constituant. De manière avantageuse, le client de tunnel A et le serveur de tunnel A' pourront chacun comprendre au moins une interface de communication (une interface "socket"), cette particularité combinée à la mise en oeuvre dudit procédé permet au client de tunnel A, par l'intermédiaire du serveur de tunnel A', de commander un serveur tel qu'un serveur Web ou SMTP en utilisant l'adresse IP publique affectée par ledit serveur de tunnel A'. Avantageusement, selon une variante d'exécution de l'invention, le traitement spécifique d'encapsulation pourra également comprendre une étape consistant à crypter le message à transmettre afin de sécuriser la communication. Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence aux dessins annexés dans lesquels : La figure 1 est une représentation schématique des différents dispositifs 20 nécessaires à la mise en oeuvre du procédé selon l'invention. La figure 2 est une représentation schématique d'une trame émise dans le cadre d'une communication entre un client de tunnel, un serveur de tunnel et un client de voix sur IP, ladite communication étant établie 25 dans le cadre de la mise en oeuvre du procédé selon l'invention. La figure 3 est une représentation schématique d'une trame émise dans le cadre d'une communication entre un client de tunnel, un serveur de tunnel et un serveur SIP, ladite communication étant établie dans le 30 cadre de la mise en oeuvre du procédé selon l'invention.15 La figure 4 est une représentation schématique des interfaces de communication, du tunnel, du client de tunnel A, du serveur de tunnel A' et des entités destinataires des requêtes du client de tunnel A. La figure 5 est une représentation schématique de la trame permettant de garantir la communication entre le client de tunnel A et le serveur de tunnel A'. La figure 6 est une représentation schématique d'une requête et d'une réponse émises entre le client de tunnel A et un serveur SIP avec une mise en évidence au niveau du serveur de tunnel A' du mécanisme de décapsulation partielle et de réencapsulation de ladite requête / réponse. La figure 7 est une représentation schématique d'une requête et d'une réponse émises entre le client de tunnel A et un destinataire avec une mise en évidence au niveau du serveur de tunnel A' du mécanisme de décapsulation partielle et de réencapsulation de ladite requête / réponse. Tel que représenté sur les figures 1 et 4, un client A placé derrière un dispositif effectuant de la NAT 1 sollicite l'ouverture d'un tunnel T avec un serveur de tunnel A' qui comprend au moins une interface de communication PCA' (une interface "socket"). Ce client A est muni d'un dispositif 2 permettant le transport de la parole sur les réseaux IP qui comprend au moins une interface de communication PCA (une interface "socket") et ayant dans cet exemple l'adresse IP "a.b.c.d" et le port source "x" ; la communication entre le client A et le serveur de tunnel A' s'établissant grâce à la présence des interfaces de communications PCA et PCA'. Le dispositif 2 permettant le transport de la parole sur les réseaux IP peut être 30 notamment un ordinateur ou un téléphone intégrant la technologie VoIP (Voix -8- sur IP) tel qu'un téléphone de type "smartphone" (marque enregistrée). Le dispositif 1 permettant d'effectuer de la NAT peut être un routeur. Une requête est ensuite émise par le client de tunnel A vers le serveur de tunnel A', cette requête ayant pour objet d'obtenir les références d'un couple constitué par une adresse IP publique et par un port public. Ce couple constitué dans cet exemple par l'adresse IP publique "f.g.h.i" et par le port public "y" qui est spécifique au serveur de tunnel A', est transmis par celui-ci au client de tunnel A qui indiquera aux entités avec lesquelles il souhaite établir une communication, de lui envoyer des messages en utilisant ladite adresse publique "f.g.h.i" et ledit port public "y". Ainsi, le serveur de tunnel A' sert de relais entre le client de tunnel A et toutes les entités avec lesquelles ce dernier communique en effet, ces entités adresseront leurs messages à destination du client de tunnel A en utilisant l'adresse IP "f.g.h.i" et le port "y", lesdits messages seront alors dirigés vers le serveur de tunnel A' qui les redirigera vers le client de tunnel A. De manière avantageuse, toutes les requêtes et les réponses émises entre le client de tunnel A et le serveur de tunnel A' pourront faire l'objet d'un traitement spécifique d'encapsulation. Ce traitement d'encapsulation consiste à encapsuler les requêtes ou les réponses transmises ou véhiculant par le serveur de tunnel A', dans une trame spécifique TS dont l'en-tête présente une structure qui fait l'objet d'une représentation schématique sur la figure 5. Ainsi, l'en- tête de cette trame spécifique TS comprend notamment : • deux champs comprenant chacun un caractère tel que par exemple la lettre " A " et la lettre " Z " : ces deux caractères, en l'espèce " A " et Z ", permettent d'indiquer le début de cette trame spécifique TS ; et/ou • un champ " Version " qui comprend un numéro associé à un traitement déterminé des paquets ; et/ou • un champ " Type " qui comporte le type de données du champ " Data ", ces données pouvant être notamment des données classiques ou des données de contrôle ; et/ou • un champ " Subtype " qui comprend le sous-type des données du champ " Data " ; et/ou • un champ " Encryption Type " qui comporte le type d'algorithme de cryptage utilisé pour chiffrer le champ " Data " ; et/ou • un champ " Data length " qui indique la longueur du champ " Données " ; et/ou • un champ " Data offset " qui indique l'emplacement du champ " Data ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options length " qui indique la longueur du champ " Options " ; et/ou • un champ " Options offset " qui indique l'emplacement du champ " Options ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options " qui comprend des options éventuelles ; le champ pouvant être complété de zéro afin que le champ " Data " débute sur un octet multiple de 4, le premier octet étant à la position 0 ; et/ou • un champ " Data " qui comprend des données éventuelles. Les données qui figurent dans le champ "Data" peuvent être notamment des données classiques (une requête spécifique ou une réponse à une telle requête par exemple) ou des données de contrôle qui permettent d'une part, de vérifier et de contrôler le bon fonctionnement de la communication et d'autre part, de commander des mécanismes de rafraîchissement des connexions si cela est nécessaire. L'indication de la nature des données figurant dans le champ - 10- "Data" est donnée par la valeur du champ "Type" ainsi, à titre d'exemple, ce dernier champ peut comprendre : • la valeur "DATA" si le champ "Data" comprend des données classiques; et • la valeur "CONTROL" si le champ "Data" comprend des données de contrôle. Dans l'hypothèse où le champ "Data" comprend des données classiques, le champ " Subtype " peut indiquer par exemple, s'il s'agit d'une trame contenant une requête spécifique ou d'une réponse à une requête spécifique. De manière avantageuse, le champ " Data " peut faire l'objet d'un traitement de cryptage en utilisation un algorithme de cryptage dont le type est spécifié dans le champ " Encryption Type ". Ainsi, à tire d"exemple, l'algorithme de cryptage peut être le DES (Data Encryption Standard) ou l'AES (Advanced Encryption Standard). A titre d'exemple, le champ "Options" peut comprendre une instruction selon laquelle un ou des paquet(s) spécifique(s) doit (doivent) être stocké(s) et conservé(s) pendant un délai déterminé par exemple, au sein du serveur de tunnel A'. Avantageusement, selon une variante d'exécution de l'invention, le traitement spécifique d'encapsulation peut comprendre une étape supplémentaire consistant à encapsuler ladite trame spécifique TS dans une trame http afin de permettre le franchissement de la plupart des coupe -feu CF et des serveurs proxys en effet, en théorie, seul un coupe û feu CF effectuant un filtrage applicatif pourrait bloquer le trafic. De cette façon, ce traitement d'encapsulation combiné notamment à l'étape ayant pour objet l'ouverture d'un tunnel T entre un client de tunnel A et un -11- serveur de tunnel A' permet de garantir la communication entre ledit client de tunnel A et ledit serveur de tunnel A'. L'exemple tel que représenté sur la figure 2, illustre la structure d'une trame circulant entre le client de tunnel A et le serveur de tunnel A', dans le cadre d'une tentative de communication entre le client de tunnel A et un client de voix sur IP. Les paquets DATA et RTP/RTCP sont encapsulés dans la susdite trame spécifique TS qui est elle-même encapsulée dans une trame http avant d'être remise à la couche transport à savoir, TCP. L'exemple représenté sur la figure 3, illustre la structure d'une trame circulant entre le client de tunnel A et le serveur de tunnel A', dans le cadre d'une tentative de communication entre le client de tunnel A et un serveur SIP. Ainsi, les paquets SIP/SDP sont encapsulés dans la susdite trame spécifique TS qui est elle-même encapsulée dans une trame http avant d'être remise à la couche transport en l'espèce, TCP. La requête émise par le client de tunnel A est reçue par le serveur de tunnel A'. Un traitement de décapsulation des paquets la constituant est effectué au sein du serveur de tunnel A', cette opération consistant à prélever la trame spécifique TS et la trame http puis à traiter les données figurant dans le champ " Data " de l'en û tête de la trame spécifique TS. Après avoir traité ces données, le serveur de tunnel A' émet une réponse à destination du client de tunnel A dans laquelle figure le couple adresse IP publique " f.g.h.i " / port public " y ", cette réponse faisant l'objet du traitement spécifique d'encapsulation. Cette réponse est reçue par le client de tunnel A et fait l'objet dudit traitement de décapsulation.30 - 12- Le client de tunnel A peut ensuite émettre une requête à destination d'une entité déterminée avec l'instruction de diriger les réponses en utilisant le couple adresse IP publique " f.g.h.i " / port public " y ". Cette requête est acheminée entre le client de tunnel A et le serveur de tunnel A' dans ledit tunnel T après avoir procédé audit traitement spécifique d'encapsulation. La requête émise par le client de tunnel A est reçue par le serveur de tunnel A' qui procède audit traitement de décapsulation des paquets puis la dirige à destination de l'entité déterminée. Cette entité déterminée peut être notamment, mais non exclusivement : • un serveur SIP; ou • un serveur TCP; ou • un serveur UDP; ou • un serveur RTP / RTCP ; ou • un client TCP; ou • un client UDP ; ou • un client RTP / RTCP. Dans l'hypothèse où il s'agit d'un serveur SIP, la procédure classique d'établissement d'une communication selon le protocole SIP est mise en oeuvre. Ainsi, avantageusement, le procédé selon l'invention permet par l'intermédiaire du serveur de tunnel A' et des points de communication PCA et PCA' ainsi que de la trame spécifique TS de commander à distance une entité déterminée telle qu'un serveur Web ou SMTP en utilisant un couple adresse IP publique / port public. Dans le cadre de l'établissement d'une telle communication, le serveur de tunnel A' et ladite entité peuvent également respectivement comprendre au moins une interface de communication PCA" (une interface "socket") distincte de l'interface de communication PCA' et au -13- moins une interface de communication (une interface "socket" non représentée). Une réponse éventuelle est émise par cette entité déterminée en utilisant les 5 références dudit couple constitué par ladite adresse IP publique " f.g.h.i " et ledit port "y" public. Cette réponse est reçue par le serveur de tunnel A' qui procède éventuellement audit traitement spécifique d'encapsulation puis est transmise à destination du 10 client de tunnel A dans le tunnel T. Cette réponse est reçue par le client de tunnel A qui procède éventuellement au traitement de décapsulation partielle des paquets la constituant. 15 Lorsque la communication entre le client de tunnel A et son destinataire est terminée, le tunnel T est fermé. Revendications 1. Procédé permettant d'acheminer un flux de données sur les réseaux IP, caractérisé en ce qu'il comprend la réalisation des étapes suivantes : • l'ouverture d'un tunnel (T) entre un client de tunnel (A) et un serveur de tunnel (A') ; • l'émission d'une requête par le client de tunnel (A) vers le serveur de tunnel (A') ayant pour objet d'obtenir les références du couple constitué par l'adresse IP ("f.g.h.i") et le port ("y") publics qui doivent être utilisés par le destinataire du client de tunnel (A) afin de lui acheminer des messages ; • l'accomplissement préalable et éventuel d'un traitement spécifique d'encapsulation des données constituant ladite requête à transmettre ; ce traitement consistant à encapsuler la requête dans une trame spécifique (TS) ; • la réception de cette requête par le serveur de tunnel (Al), la décapsulation éventuelle des paquets la constituant et l'émission d'une réponse à destination du client de tunnel (A) dans laquelle figure ce couple adresse IP ("f.g.h.i") / port ("y") publics, cette réponse étant acheminée dans ledit tunnel (T) après avoir éventuellement procédé audit traitement spécifique d'encapsulation ; • la réception de cette réponse par le client de tunnel (A) et l'accomplissement éventuel d'une décapsulation des paquets la constituant ; • l'envoi par le client de tunnel (A) d'une requête à destination d'une entité déterminée contenant l'instruction de diriger les réponses à cette requête en utilisant l'adresse IP ("f.g.h.i") et le port ("y") publics constituant ledit couple ; cette requête étant acheminée entre le client de tunnel (A) et le serveur de tunnel (A') dans ledit tunnel (T) après avoir éventuellement procédé audit traitement spécifique d'encapsulation ;-15-• la décapsulation partielle éventuelle des paquets constituant ladite requête au niveau du serveur de tunnel (A') ; • la transmission par le serveur de tunnel (A') de cette requête modifiée vers ladite entité déterminée ; • l'émission d'une réponse éventuelle par cette entité déterminée en utilisant les références dudit couple constitué par ladite adresse IP ("f.g.h.i") et ledit port ("y") publics • la réception par le serveur de tunnel (A') de cette réponse ; • l'accomplissement éventuel dudit traitement spécifique d'encapsulation l0 par le serveur (A') ; • la transmission de cette réponse modifiée par le serveur de tunnel (A') à destination du client de tunnel (A), cette réponse étant acheminée dans ledit tunnel (T) ; • la réception de cette réponse modifiée par le client de tunnel (A) et 15 l'accomplissement éventuel d'une décapsulation des paquets la constituant. 2. Procédé selon la revendication 1, caractérisé en ce que l'en-tête de la trame spécifique (TS) comprend : 20 • deux champs comprenant chacun un caractère : ces deux caractères permettant d'indiquer le début de cette trame spécifique (TS) ; et/ou • un champ " Version " qui comprend un numéro associé à un traitement déterminé des paquets ; et/ou • un champ " Type " qui comporte le type de données du champ " Data ", 25 ces données pouvant être notamment des données classiques ou des données de contrôle ; et/ou • un champ " Subtype " qui comprend le sous-type des données du champ " Data " ; et/ou • un champ " Encryption Type " qui comporte le type d'algorithme de 30 cryptage utilisé pour chiffrer le champ " Data " ; et/ou- 16- • un champ " Data length " qui indique la longueur du champ " Données " ; et/ou • un champ " Data offset " qui indique l'emplacement du champ " Data ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options length " qui indique la longueur du champ " Options " ; et/ou • un champ " Options offset " qui indique l'emplacement du champ " Options ", à savoir le nombre d'octets de décalage par rapport à la fin de l'en-tête de la trame ; et/ou • un champ " Options " qui comprend des options éventuelles ; le champ pouvant être complété de zéro afin que le champ " Data " débute sur un octet multiple de 4, le premier octet étant à la position 0 ; et/ou • un champ " Data " qui comprend des données éventuelles. 3. Procédé selon la revendication 2, caractérisé en ce que les données qui figurent dans le champ "Data" sont des données classiques ou des données de contrôle permettant d'une part, de vérifier et de contrôler le bon fonctionnement de la communication et d'autre part, de commander des mécanismes de rafraîchissement des connexions si cela est nécessaire. 4. Procédé selon l'une des revendications 2 et 3, caractérisé en ce que l'algorithme de cryptage dont le type est spécifié dans le 25 champ " Encryption Type " est l'algorithme DES ou AES. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que le traitement spécifique d'encapsulation comprend une étape supplémentaire consistant à encapsuler ladite trame spécifique (TS) dans 30 une trame http afin de permettre le franchissement de la plupart des coupe - feu (CF) et des serveurs proxys. 2894418 -17- 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'opération de décapsulation des paquets consiste à prélever la trame spécifique (TS) et la trame http puis à traiter les données 5 figurant dans le champ " Data " de l'en û tête de la trame spécifique (TS). 7. Dispositif pour la mise en oeuvre du procédé selon la revendication 1, caractérisé en ce que le serveur de tunnel (A') comprend au moins une interface de communication (PCA') et en ce que le client (A) est muni d'un 10 dispositif (2) permettant le transport de la parole sur les réseaux IP qui comprend au moins une interface de communication (PCA). 8. Dispositif selon la revendication 7, caractérisé en ce que l'entité déterminée est : 15 • un serveur SIP; ou • un serveur TCP; ou • un serveur UDP; ou • un serveur RTP / RTCP ; ou • un client TCP; ou 20 • un client UDP ; ou • un client RTP / RTCP. 9. Dispositif selon l'une des revendications 7 et 8, caractérisé en ce que le serveur de tunnel (A') comprend au moins une interface de communication (PCA") distincte de l'interface de communication (PCA') et en ce que l'entité déterminée comprend au moins une interface de communication qui participent à l'élaboration d'une communication entre le serveur de tunnel (A') et l'entité déterminée.