Brevet FR2963861A1 — publié le 20120217

Procédé et architecture de système d'ouverture de canaux sur établissement de communication VoIP en mode clair p BGAN, SwiftBroadband et FleetBroadband L'invention concerne un procédé et une architecture système permettant d'ouvrir de manière dynamique des canaux de communication de dimensions optimisées à débit garanti d'Inmarsat par exemple. L'architecture est, par exemple, mise en oeuvre pour l'ouverture de canaux sur établissement de communication voix sur IP « VoIP » en mode clair BGAN (un service IP et voix délivré simultanément en haut débit à travers le réseau 3 G d'Inmarsat), pour des services connus sous l'acronyme anglo-saxon « SwiftBroadband » et « FleetBroadband » (service de communications maritime d'Inmarsat). L'architecture système se présente, par exemple, sous la forme d'une plate-forme embarquée qui peut être à bord d'un aéronef, d'un navire, d'un véhicule ou dans une valise, et d'une plate-forme sol qui s'interface avec les réseaux publics ou privés. La plate-forme embarquée sert un réseau utilisant le protocole Internet IP sur lequel sont connectés des équipements informatiques (données, voix ou phonie, vidéo, etc....). Définitions Dans la suite de la description, les abréviations suivantes et leurs définitions seront utilisés : PDP : protocole de données paquet ou Packet Data Protocol, un contexte PDP vient de la technologie GPRS connue de l'Homme du métier, c'est un ensemble d'informations qui caractérise un service de transmission de base; il regroupe des paramètres qui permettent à un abonné de communiquer avec une adresse PDP bien définie, suivant un profil de Qualité de Service déterminé (délai, priorité, débit, ..) RTP : protocole temps réel ou Real Time Protocol. Protocole sur IP qui permet d'identifier le type de l'information transportée, d'ajouter des marqueurs, des numéros de séquence et de contrôler l'arrivée à destination des paquets. TFT : initiales qui désignent une série de filtre qui assure un chemin déterminé pour des applications dont le flux est identifié par les filtres TFT, Traffic Flow Template. Par exemple, la technologie d'Inmarsat utilise des TFT. VoIP : voix sur IP ou en anglo-saxon Voice over IP SIP : protocole initialisation de service ou Session Initiation Protocol. Ce protocole est normalisé et standardisé. Il se charge de l'authentification et de la localisation des multiples participants. Il se charge également de la négociation sur tous les types de média utilisables par les différents participants en encapsulant des messages SDP (Session Description Protocol). SIP ne transporte pas les données échangées durant la session comme la voix ou la vidéo. SIP étant indépendant de la transmission des données, tout type de données et de protocoles peut être utilisé pour cet échange. Cependant le protocole RTP assure le plus souvent les sessions audio et vidéo. Le mot « streaming » désigne une classe de services Satcom 15 garantissant un débit garanti (utilisé principalement pour les applications temps-réel). Le mot « transceiver » est utilisé pour désigner un transcepteur ayant notamment pour fonction de diffuser un signal d'entrée vers plusieurs sorties. 20 L'expression « Bord » correspond aux équipements disposés à bord d'un satellite ou d'un aéronef et l'expression « sol » aux équipements situés dans une station sol. L'expression « route externe » concerne les mécanismes de routage mis en oeuvre par la fonction SIP du « redirect Proxy ». Il s'agit de 25 rediriger des appels non trouvés localement vers un autre proxy via la route définie. L'expression « Inbound call » correspond à un appel entrant en contraste avec l'expression « outbound call » correspondant à un appel sortant. 30 Dans les réseaux de télécommunication utilisant notamment un satellite, deux types de catégorie de services sont en général proposés : - un service de type « Best Effort » où l'utilisateur paye au Méga Octet consommé, mais il n'a pas de garantie de Qualité de Service. C'est-à-35 dire que s'il y a beaucoup d'utilisations simultanées sur le lien satellite, la qualité est fortement dégradée. Pour des services de téléphonie sur IP (Internet Protocol) ou pour de la visioconférence, cela est rédhibitoire. - un service de type streaming pour lequel l'utilisateur paye à la durée de connexion (prix très élevé), mais qui a, en contrepartie, une garantie de service qui lui permet d'assurer des services temps réels, comme la voix ou la vidéo ou encore une liaison prioritaire de la ressource satellite. Mécanisme Bord-Sol Dans l'état de l'art, l'établissement d'une communication entre une plateforme sol et un système embarqué sur aéronef ou sur satellite nécessitant une qualité de service s'effectue par l'ouverture préalable d'un canal streaming à 32 K ou 64 K ou 128 K ne préjugeant pas du volume réel de la bande utilisée et consommant la ressource dès l'ouverture. Le canal « streaming » (lecture en flux continu) est ouvert, avec paiement dès l'ouverture, afin de permettre le passage de la signalisation. Si le destinataire de l'appel ne décroche pas, la communication est facturée jusqu'à la libération du canal. De plus, l'absence de gestion fine des vocodeurs au niveau des équipements de communications et l'absence d'optimisation du cadencement dans la transmission de paquets voix sur IP ne permettent d'effectuer que des communications utilisant en moyenne 80 Kbps (Vocodeur de type G711) de bande passante par communication. Néanmoins, certaines architectures offrent la possibilité de concaténer plusieurs communications dans un canal de « streaming » préalablement activé sans maîtrise du vocodeur et du cadencement (nombre de trames dans une « payload » ou données acheminées). Ce mécanisme peut s'avérer intéressant si le canal ouvert est toujours occupé par un volume de communications significatif, dans le cas contraire, un canal est ouvert avec un trafic insuffisant et son coût d'exploitation peut être très élevé. Le mécanisme est illustré en figure 1 où l'on retrouve des échanges de communications émis par un premier terminal TI disposé sur aéronef ou satellite ou « Bord » vers le Sol par l'intermédiaire d'un premier serveur SIP situé au niveau du Bord d'un aéronef I, d'une liaison ou module Satcom Il transmettant les données en utilisant le protocole PDP, d'un deuxième serveur SIP situé au niveau d'une station sol III en liaison avec un terminal T2, d'une passerelle circuit P, d'un réseau de téléphonie commuté Rc. La figure 2 schématise les échanges de données lors d'une 5 communication établie dans le sens inverse à celui décrit à la figure 1, à savoir, du sol vers le bord entre un terminal TI et un terminal T2. Dans l'état de l'art, une communication établie depuis le sol est systématiquement réalisée dans le Best Effort. Si l'on souhaite depuis le sol une communication de qualité streaming, le canal doit être préalablement 10 ouvert depuis l'avion. L'objet de l'invention concerne une architecture système permettant d'ouvrir de manière dynamique des canaux de communication de dimension optimisée à débit garanti, le protocole de communication utilisé étant le protocole RTP, ladite architecture système étant destinée à être 15 positionnée dans un aéronef, une valise et/ou un navire, et/ou une station sol comprenant un ou plusieurs terminaux voix sur IP, ladite architecture comprenant au moins les éléments suivants : - Un serveur SIP sol ou bord comprenant au moins les éléments suivants : - Un module adaptateur de débit qui contrôle, cadence, adapte le débit du 20 flux RTP reçu par un terminal, - Un module de contrôle de la signalisation incluse dans les flux de données, ledit module de contrôle comportant un module d'interception de signalisation, un module de modification de la signalisation, ledit module d'interception de signalisation recevant les informations de la part d'un 25 terminal émetteur des données et d'un module de contrôle d'accès. Le terminal de données est, par exemple, un terminal voix sur IP transmettant des données D en parallèle aux données phonie à un module de routage qui communique avec le terminal IP phonie. 30 Le module de routage applique, par exemple, les règles TFT, le système de communication étant un système satellitaire (BGAN, SwiftBroadband et FleetBroaband ou GPRS). Le module adaptateur de débit peut être un module permettant une adaptation d'un codec bas débit G729 vers le codec G711 et vice et 35 versa. L'invention concerne aussi un procédé permettant une ouverture dynamique de canaux de communications au sein d'un système de communication utilisant le protocole RTP, entre au moins deux terminaux de phonie, ledit procédé étant mis en oeuvre au sein de l'architecture précitée, ledit procédé étant caractérisé en ce qu'il comporte au moins les étapes suivantes : 1) intercepter le message « INVITE » au moyen d'un serveur SIP, émis dans le flux de données, 2) déterminer le codeur-décodeur utilisé au sein d'un terminal de phonie TI, 1 o T2, 3) si le codeur est un codeur bas débit, alors laisser passer la communication sans modifier les données, 4) sinon transcoder les appels émis en haut débit en bas débit dès la Demande d'appel en repérant les codecs demandés par les terminaux dès 15 l'établissement des flux média réels reçus par l'un des terminaux. Selon un mode de réalisation du procédé le système de communication utilise un terminal de données voix sur IP transmettant des données D en parallèle aux données phonie à un module de routage qui communique avec le terminal IP phonie. 20 Le procédé peut mettre en oeuvre un module de routage appliquant les règles TFT, le système de communication étant un système satellitaire de type BGAN, SwiftBroadband et FleetBroaband ou GPRS. Le procédé peut utiliser un adaptateur de débit permettant une adaptation du codec G729 vers le codec G711 et vice et versa. 25 D'autres caractéristiques et avantages du dispositif selon l'invention apparaîtront mieux à la lecture de la description qui suit d'un exemple de réalisation donné à titre illustratif et nullement limitatif annexé des figures qui représentent : 30 - La figure 1, une représentation de l'état de l'art d'un mécanisme de transmission de données du Bord vers le Sol, - La figure 2, une représentation de l'état de l'art d'un mécanisme de transmission de données du Sol vers le Bord, - La figure 3, un exemple d'architecture permettant de mettre en oeuvre 35 le procédé selon la présente demande de brevet, - La figure 4, un exemple de transcodage transparent, - La figure 5A un exemple d'étapes mises en oeuvre pour la suppression des vocodeurs Haut débit et le recadencement des paquets voix sur IP et la figure 5B, un exemple d'étapes mises en oeuvre pour le transcodage des paquets voix sur IP, - La figure 6, une illustration de la succession des étapes pour l'établissement d'un appel VoIP Outbound, et - La figure 7, une illustration de la succession des étapes pour l'établissement d'un appel VoIP Inbound. Afin de mieux faire comprendre le procédé et l'architecture selon l'invention, la description qui suit est basée sur l'utilisation du protocole standard SIP. Les mécanismes mis en oeuvre sont donc transparents pour tout terminal compatible du protocole. La figure 3 représente un exemple d'architecture du système selon l'invention, comprenant un terminal de données IP 1, qui transmet des données D à un module de routage ou routeur 2, et un terminal de phonie 3 qui communique en parallèle avec un serveur SIP 4 pour la signalisation et le flux RTP. Une telle architecture peut être disposée aussi bien dans des équipements dits « à Bord » d'un véhicule, navire ou d'un aéronef, que dans des équipements ou station sol. Le serveur SIP 4 comporte un module 5 adaptateur de débit qui, contrôle, transcode, adapte et recadence le débit du protocole RTP, un module de contrôle de la signalisation 6, comprenant lui-même un module 7 d'interception de la signalisation et un module 8 de modification de la signalisation. Le module 7 d'interception de la signalisation reçoit des informations de la part du terminal IP mais aussi du module de contrôle d'accès 9. Le module de modification de la signalisation va transmettre les signalisations modifiées d'une part au terminal IP, d'autre part au module 9 de contrôle d'accès et au module 5 adaptateur de débit. Le routeur 2 échange des données avec le module 9 de contrôle d'accès et avec le Modem Satcom 10 ou tout autre modem mis en oeuvre pour une communication entre une station Sol et un aéronef ou satellite quelconque Le terminal IP sur cette figure représente par exemple le terminal de téléphonie bord, TI sur la figure 1. Le module de routage 2 a notamment pour fonction de router différents flux de données sur les bonnes ressources Satcom, c'est-à-dire le ou les PDP contexte primaires contenant les PDP secondaires associés aux règles TFT en appliquant les règles TFT. Le module 6 de contrôle de la signalisation, SIG, est une fonction qui analyse la signalisation SIP présente dans un paquet de données ou dans un flux de données, afin de contrôler et modifier les numéros de port RTP et les codeurs-décodeurs ou codec mis en oeuvre par les terminaux TI, T2. II pilote le module 5 adaptateur de débit. Les codecs ne sont pas représentés sur les figures pour des raisons de simplification. L'architecture décrite en figure 3 s'applique aussi bien pour des segments sol que pour des segments Bord. On utilisera les références ` pour différencier les éléments du segment Bord par rapport au segment sol. Les règles de gestion des ressources Satcom imposent que, du 20 point de vue du module de routage, les ports RTP utilisés par les communications téléphoniques correspondent aux règles TFT. La gestion automatique du trafic présente plusieurs problématiques : - L'application de la règle TFT doit être faite sur la connaissance des 25 ports avant l'établissement de la communication entre deux terminaux. - La connaissance des ports n'est possible qu'à l'établissement de la communication. - L'affectation des ports est dynamique. Les modules de contrôle de la signalisation 6 et d'adaptation du 30 débit 5 permettent d'effectuer une translation de port pour les messages d'appel (INVITE) et d'acceptation d'appel (200 OK) les traversant. Ceci permet de masquer la combinatoire des numéros de port des différents combinés SIP utilisés dans le réseau et de n'utiliser qu'un faible nombre de ports RTP (un numéro de port par communications voix Outbound et 35 Inbound). Concrètement, le module de contrôle de signalisation 6 analyse la signalisation pour une communication donnée, ou flux de données à transmettre, pour connaître le numéro de port RTP annoncé dans le paquet d'appel (INVITE) du terminal émetteur TI et par le terminal récepteur T2 lors de la réponse (200 OK). Ce numéro est propre à chaque terminal et n'est pas configurable. Pour remédier à ce problème technique, le procédé et l'architecture selon l'invention utilisent des mécanismes de terminaux virtuels implémentés dans une application qui utilise les services du serveur IP. C'est par l'intermédiaire de ces terminaux virtuels qu'il va y avoir possibilité d'adapter une allocation dynamique et non contrôlée aux règles statiques des TFT. Sur réception d'un appel, le serveur SIP (bord ou sol selon le sens de l'appel) fournit un N° de port RTP libre (défini par configuration), puis ouvre le paquet d'appel et remplace le numéro de port demandé par le terminal TI par celui qui vient d'être affecté. Le paquet d'appel est ensuite émis vers la route externe avec un nouveau numéro de port. Adaptation de la Bande consommée Dans le protocole SIP, les terminaux peuvent négocier entre eux 20 le meilleur codec possible. Dans l'exemple donné, le vocodeur choisi est le G729, de façon à être sûr qu'une communication passe dans un canal streaming de 32Kbits/s. Le module de contrôle de la signalisation a aussi pour rôle de retirer du message d'appel les vocodeurs à haut débit. Soit dans le cadre de 25 l'exemple, supérieur à 32 Kbits/s (IP+UDP+RTP+payload) De fait, comme il est illustré à la figure 4 représentant une communication d'une station embarquée vers une station sol, un codec bas débit sera choisi s'il est présent dans l'équipement sol et dans l'équipement 30 embarqué. Dans le cas où un codec bas débit est présent de bout en bout dans le système de communication, si un message « INVITE » au départ d'une route externe (signal émis par le terminal TI) possède un vocodeur bas débit, alors le procédé n'aura pas à transcoder ou modifier de manière plus 35 général le flux de données. Dans le cas où un codec bas débit n'est pas présent dans les équipements, le procédé et l'architecture selon l'invention vont utiliser le codec G711 64kbits/s présent dans tous les terminaux, et faire un transcodage vers un codec bas débit. C'est le module 5 adaptateur de débit qui a en charge ce transcodage comme il est illustré à la figure 5B. Les étapes mises en oeuvre par le procédé dans ce cas sont par exemple les suivantes : dans le cas où l'architecture système au niveau du sol et au niveau du bord ne dispose pas de vocodeur bas débit, Si un message « INVITE » au départ d'une route externe ne 10 possède pas de vocodeur bas débit, Appel outbound (figures 3 et 4) Le serveur SIP bord 4 accepte les appels en G711 par exemple et les transpose en G729. C'est le module 5 Adaptateur de débit qui a en charge ce transcodage. 15 Le serveur SIP sol effectue une opération inverse en acceptant les appels en G729 via le module de contrôle de signalisation et de RTP et les transcode en G711 vers le terminal demandé T2. Le flux de communication transcodée est ensuite transmise par la passerelle circuit P, puis par des réseaux commutés Rc. 20 Appel inbound Le serveur SIP sol accepte les appels en G711 et les transcode en G729. Le transcodage est effectué grâce au module adaptateur de débit situé dans l'équipement Sol. Le serveur SIP bord accepte les appels en G729 et les transcode 25 en G711 vers le terminal demandé. Le transcodage est effectué grâce au module adaptateur de débit situé dans l'équipement Bord. Module Adaptateur de débit, 5 Le rôle de ce module adaptateur de débit est d'être placé en coupure sur les flux RTP pour recadencer les flux et effectuer un 30 transcodage si nécessaire. Ceci signifie que le module est situé entre les deux terminaux TI et T2 de l'exemple donné. Le fait de recadencer les flux permet notamment d'obtenir une excellente qualité voix pour une bande passante minimale réelle inférieure à 32 kbits par seconde. Ce module adaptateur de débit 5, comme il a été décrit précédemment, a aussi en charge de transcoder les paquets émis en codec haut débit par les terminaux en paquet voix bas débit pour émission sur une connexion satellite (réseau local et réseau sol). L'adaptateur de débit est une fonction logicielle intelligente portée par le serveur SIP. L'adaptateur de débit permet de réduire le débit VoIP de manière intelligente afin de permettre l'usage de liens bas débit en optimisant : - Le débit maximal sur les liens utilisés - La qualité de voix - Le CPU utilisé pour les opérations L'adaptateur de débit travaille en deux étapes schématisées aux figures 5A, 5B: 1. dès la demande d'appel émise par un terminal en repérant les codecs demandés par les terminaux, en en proposant ou en supprimant certains, 2. dès l'établissement des flux média réels reçus par les terminaux Il est aussi conçu pour travailler dans les deux sens de communication Bord-2o Sol et Sol-Bord. Ces deux étapes permettent enfin de travailler suivant deux modes : 1. Le recadencement de paquets voix adapté aux faibles et moyennes demandes de compressions schématisé à la figure 5A. Sur cet 25 exemple, on voit que la trame de paquets voix sur IP est recadencé de 30ms à 60ms. 2. Le transcodage de paquets adapté aux fortes demandes de compression schématisé à la figure 5B, par exemple en passage d'un débit de codage de type G711, codage à débit élevé à un codage à 30 débit faible de type G729. Il est bien entendu que les types de codage G711 et G729 sont donnés uniquement à titre illustratif et nullement limitatifs. Le travail sur la signalisation porte sur le forçage, si possible, des terminaux à utiliser le même codec bas débit ( Dans le cas où un des terminaux ne peut supporter un tel codec, cela est détecté dans cette première phase et le transcodage va s'appliquer. Appel outbound La figure 6 schématise l'établissement d'un appel VoIP Outbound sur un segment de bout en bout. Sont présentés, en particulier, les traitements liés à l'échange par les deux téléphones ou terminaux appelant, TI dans cet exemple, et appelé T2, des messages initiaux « INVITE » et 200 OK ». Que l'appel soit identifié en Outbound ou Inbound, c'est aux 10 serveurs SIP de se substituer aux terminaux TI, T2 et de les leurrer afin de pouvoir modifier leurs ports RTP. Un exemple de chronologie des étapes mises en oeuvre dans le cas d'un appel outbound, est donné ci-après. BORD 15 Ex : le terminal émetteur TI présente l'appel au serveur SIP Bord avec : Port RTP 50000 Le serveur SIP Bord capture le message d'INVITE. 20 L'appel est pour une route externe Vérification par le module de contrôle d'accès du nombre d'appels Inbound et Outbound sur cette route Vérification de la présence du vocodeur bas débit (ex ; G729) 25 dans le message d'INVITE Le serveur SIP émet un message «200 trying » vers le terminal demandeur de l'appel TI Le serveur Bord SIP demande un numéro de port RTP externe Le premier N° de port externe libre est attribué 30 Le serveur Bord SIP poursuit l'appel vers le routeur L'appel est poursuivi dans le « best effort », 30, 31, c'est-à-dire que l'appel est transmis vers les équipements SOL en utilisant le mode « best effort » 31 via un module de routage 30. 35 12 SOL Le serveur sol 4' SIP reçoit un message d'INVITE sur sa route externe (Trunk de liaison entre le serveur SIP Bord et le serveur SIP Sol) Marquage d'un appel sur cette route en Inbound, marquage de 5 l'appel qui est effectué par le module de contrôle d'accès Poursuite de l'appel par récupération de l'adresse IP issue du numéro d'appel et contenue dans la base d'enregistrement (REGISTRAR) des terminaux connectés au serveur SIP du Sol vers le terminal demandé T2 Le terminal demandé répond par un 200 0K avec le port qu'il souhaite 10 utiliser pour le RTP (40000) Le serveur sol SIP capture le message d'acceptation d'appel (200 OK) Le serveur SIP sol demande un numéro de port RTP externe Le premier port externe libre est attribué (30200) ; le serveur sol poursuit l'appel vers le routeur du SOL. 15 BORD Le serveur bord SIP reçoit le 200 0K et poursuit l'appel vers le terminal TI sans modification du message de confirmation (200 OK) Le terminal demandeur TI émet les trames RTP avec comme port source 50000 et comme port destination 30200. 20 Le module 5 adaptateur de débit est en coupure, c'est-à-dire entre les terminaux TI et T2, Réception des trames et modification du port source en 30200 Les trames sont envoyées au module de routage selon l'invention avec comme port source 30200 et destination 30200 25 Le trafic montant et descendant est maintenant affecté sur un port RTP maîtrisé et connu dans les règles TFT. Le trafic est maintenant affecté automatiquement à un canal streaming par une correspondance parfaite avec les règles TFT. Appel Inbound 30 Pour éviter l'affectation d'un port Sol et Bord identique, le procédé permet de les affecter automatiquement et par configuration de façon décroissante Bord vers Sol et de façon croissante de Sol vers Bord. Une plage de port est définie (par configuration) dans le serveur SIP du Bord et dans celui du Sol. Cette plage commence par ex : - Port 30200 à 30250 avec une affectation de 30200 vers 30250 depuis le Bord - Port 30200 à 30250 avec une affectation de 30250 vers 30200 depuis le Sol Si un appel est initialisé depuis le Bord, le serveur SIP du Bord affecte le port 30200 s'il est libre dans le paquet d'appel. Si un appel est initialisé depuis le Sol, le serveur SIP du Sol affecte le port 30250 s'il est libre dans le paquet d'appel. Cette mécanique d'affectation croissante (depuis le Bord) et 10 décroissante (depuis le Sol) et répétitive jusqu'à l'occupation de tous les ports. Un port libéré (Raccroché de la communication) et ré-affecté si une autre communication s'initialise. 15 L'invention est transparente pour les appels en provenance du SOL. Ceux-ci sont effectués dans le mode Best Effort (pour la signalisation) avec changement des ports au SOL pour vérifier ou respecter les règles TFT de l'aéronef ou de l'avion. La chronologie des étapes peut être la suivante, selon la figure 7 : 20 SOL Le terminal demandeur T1,émet un appel avec comme numéro de port RTP 40000 Port RTP 40000 Codec G711A, G711 U, G729, G723.1 25 Le serveur sol SIP 4 capture le message d'INVITE L'appel est pour une route externe Vérification du nombe d'appels Inbound et Outbound sur cette route par le module de contrôle d'accès, Si Un appel est possible, marquage d'un appel en Outbound 30 Vérification de la présence du vocodeur bas débit (ex ; G729) dans le message d'INVITE Le serveur sol SIP émet un « trying » vers le terminal T, demandeur de l'appel 35 Le serveur sol SIP demande un numéro de port RTP externe Le premier port externe libre est attribué (30210) Le serveur sol SIP poursuit l'appel L'appel est poursuivi dans le Best Effort BORD Le serveur Bord SIP 4' reçoit un message d'invite sur sa route externe Marquage d'un appel sur cette route en Inbound Poursuite de l'appel vers le terminal demandé Le terminal T2 demandé répond par un 200 0K avec le port qu'il souhaite utiliser pour le RTP (50000) Le serveur Bord SIP 4' capture le message d'INVITE Le serveur bord SIP 4' modifie le port RTP en 30210. SOL Sur réception du 200 OK, le terminal TI émet les trames RTP vers le destinataire T2 dans le Best effort. BORD Sur réception des trames en 30210, le module de routage situé dans le système Bord affecte l'appel automatiquement à un canal streaming défini. Le procédé et l'architecture système selon l'invention permettent 20 donc : De générer la signalisation dans le mode Best Effort, De générer la voix dans le streaming, D'ouvrir un canal streaming optimisé pour chaque communication de façon automatique pour un appel qui sort du système plus connu sous 25 l'abréviation anglo-saxonne « outbound » ou un appel qui rentre dans le système ou « In-Bound ». De forcer les terminaux à négocier en G729 (codage de la parole à 8 kbit/s par prédiction linéaire avec excitation par séquences codées à structure algébrique conjuguée) ou un autre codec de bas débit si ce 30 vocodeur est présent De transcoder en bas débit si le vocodeur n'est pas présent dans les terminaux, D'optimiser le cadencement des trames voix, De garantir que le nombre de communications (entrante et 35 sortante) autorisées par la Bande passante ne sera pas dépassé. La compatibilité avec le standard SIP. Ils offrent aussi la possibilité de s'adapter à des contraintes fortes en bande passante. La contrainte est de garantir qu'une communication passera toujours dans un canal de taille le plus petit possible, cette taille 5 étant fixe quels que soient les terminaux utilisés. REVENDICATIONS1 - Architecture système permettant d'ouvrir de manière dynamique des canaux de communication de dimension optimisée à débit garanti, le protocole de communication utilisé étant le protocole RTP, ladite architecture système étant destinée à être positionnée dans un aéronef, une valise et/ou un navire, et/ou une station sol comprenant un ou plusieurs terminaux voix sur IP, ladite architecture comprenant au moins les éléments suivants : - Un serveur SIP(4) sol ou bord comprenant au moins les éléments suivants : - Un module adaptateur de débit (5) qui contrôle, cadence, adapte le débit du flux RTP reçu par un terminal, - Un module de contrôle (6) de la signalisation incluse dans les flux de données, ledit module de contrôle (6) comportant un module (7) d'interception de signalisation, un module (8) de modification de la signalisation, ledit module d'interception de signalisation recevant les informations de la part d'un terminal émetteur des données et d'un module de contrôle d'accès (9). 2 - Architecture selon la revendication 1 caractérisée en ce que le terminal de données est un terminal voix sur IP transmettant des données D en parallèle aux données phonie à un module de routage qui communique avec le terminal IP phonie. 3 - Architecture selon la revendication 1 caractérisée en ce que le module de routage applique les règles TFT, le système de communication étant un système satellitaire de type BGAN, SwiftBroadband et FleetBroaband ou GPRS. 4 - Architecture selon la revendication 1 caractérisé en ce que le module adaptateur de débit est un module permettant une adaptation d'un codec bas débit G729 vers le codec G711 et vice et versa.35 5 - Procédé permettant une ouverture dynamique de canaux de communications au sein d'un système de communication utilisant le protocole RTP, entre au moins deux terminaux de phonie, ledit procédé étant mis en oeuvre au sein de l'architecture selon l'une des revendications 1 à 4, ledit procédé étant caractérisé en ce qu'il comporte au moins les étapes suivantes : 1) intercepter le message « INVITE » au moyen d'un serveur SIP, émis dans le flux de données, 2) déterminer le codeur-décodeur utilisé au sein d'un terminal de phonie TI, 1 o T2, 3) si le codeur est un codeur bas débit, alors laisser passer la communication sans modifier les données, 4) sinon transcoder les appels émis en haut débit en bas débit dès la Demande d'appel en repérant les codecs demandés par les terminaux dès 15 l'établissement des flux média réels reçus par l'un des terminaux. 6 - Procédé selon la revendication 5 caractérisé en ce que le système de communication utilise un terminal de données voix sur IP transmettant des données D en parallèle aux données phonie à un module de routage qui 20 communique avec le terminal IP phonie. 7 - Procédé selon la revendication 5 caractérisé en ce qu'il met en oeuvre un module de routage appliquant les règles TFT, le système de communication étant un système satellitaire de type BGAN, SwiftBroadband et 25 FleetBroaband ou GPRS. 8 - Procédé selon la revendication 5 caractérisé en ce qu'il utilise un module adaptateur de débit permettant une adaptation du codec G729 vers le codec G711 et vice et versa. 30