FR2962281A1

FR2962281A1 - Procede de configuration d'un terminal pour le maintien d'une porte dans un equipement mettant en oeuvre une fonction de traduction d'adresses

Info

Publication number: FR2962281A1
Application number: FR1002735A
Authority: FR
Inventors: Sebastien Cubaud; Jose Doree
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2010-06-30
Filing date: 2010-06-30
Publication date: 2012-01-06

Abstract

Ce procédé de configuration d'au moins un terminal (T1, T2) est mis en œuvre par une entité (ENT) gérant la signalisation dans un réseau de télécommunications. Il comporte : - une étape de réception d'un message de signalisation (M1) émis par un premier terminal (T1) à destination d'un deuxième terminal (T2), ces terminaux étant situés dans des réseaux séparés par au moins un équipement (NAT) apte à mettre en œuvre une fonction de traduction d'adresses ; - une étape d'obtention d'une valeur de temporisation choisie en fonction d'une durée utilisée par l'équipement de traduction d'adresses pour le maintien d'une porte ouverte pour le passage d'un flux de données ; - une étape d'insertion de cette valeur de temporisation dans le message de signalisation (M2), cette valeur devant être interprétée par le premier et/ou par le deuxième terminal comme la durée maximum à respecter entre l'émission de deux paquets de données successifs dans le flux de données (M9); et - une étape d'envoi du message de signalisation modifié (M2) à destination dudit deuxième terminal.

Description

Arrière-plan de l'invention

La présente invention se situe dans le domaine des réseaux de télécommunication.

Elle s'applique en particulier, mais de façon non limitative dans les réseaux de voix sur IP (VoIP pour « Voice over IP » en anglais). Dans de tels réseaux, il est d'usage, notamment pour des raisons qui tiennent à la politique de gestion des adresses IP, d'implémenter, en frontière de réseau, un équipement apte à mettre en oeuvre une fonction de traduction d'adresses.

De tels équipements sont connus de l'homme du métier sous l'appellation NAT (« network address translators »). De façon connue, la fonction de traduction d'adresses NAT permet de modifier le plan de numérotation utilisé de part et d'autre de la frontière précitée au niveau de la couche 3 du modèle OSI.

Eventuellement, cette fonction de traduction modifie en outre les numéros de port de part et d'autre de la frontière (couche 4 du modèle OSI) ; on parle alors dans ce cas de fonction NAPT (Network Address and Port Translators). Cette fonction de traduction d'adresses de niveau 3 (ou a fortiori de niveau 4) permet notamment de passer d'un adressage privé dans un réseau interne d'opérateur à 20 un adressage public vers le réseau Internet. Les équipements de traduction d'adresses peuvent être implémentés sous différents types d'équipements et ce entre plusieurs segments du réseau. En particulier, un routeur ou un modem routeur peuvent implémenter une fonction de traduction d'adresses entre un réseau domestique et un réseau d'accès 25 opérateur. Dans un réseau local d'accès, un équipement A-SBC (« Access Session Border Controler » en anglais) ou un équipement C-BGF (« Core Border Gateway Function ») peuvent aussi implémenter cette fonction en frontière d'un réseau coeur de l'opérateur. Entre deux réseaux coeur, cette fonction peut également être implantée dans 30 un équipement I-SBC (« Interconnect Session Border Controller »), dans un équipement I-BGF (Interconnect Border Gateway Function) ou dans un routeur d'interconnection. Les équipements de traduction d'adresses peuvent être cascadés. De façon connue, lorsqu'un flux de données doit être établi, l'équipement de traduction d'adresses ouvre une porte pour le passage du flux de données, cette porte 35 étant caractérisée par un quadruplet (IP_SRC, port_SRC, IP_DST, port_DST), dans lequel IP_SRC et port_SRC désignent l'adresse IP et le numéro de port côté source et IP_DST, port_DST désignent l'adresse IP et le numéro de port côté destination. Pour des raisons de sécurité notamment, la durée d'ouverture de cette porte (durée pendant laquelle la porte est maintenue ouverte par l'équipement) est bornée 5 dans le temps. Dans l'état actuel de la technique, cette durée d'ouverture est configurée de façon statique dans l'équipement de traduction d'adresses. A cet effet, cet équipement entretient un temporisateur local qui surveille l'activité d'échange des paquets de données à travers la porte précitée. Si aucun échange 10 n'est observé sur cette porte pendant la durée d'ouverture, l'équipement de traduction d'adresses considère que le flux de données a cessé et ferme la porte. Si cette durée est mal choisie, il se peut que l'équipement de traduction d'adresses ferme la porte de façon prématurée, c'est-à-dire avant que le flux de données ne soit effectivement terminé. Ceci est très dommageable, notamment dans le cas d'un 15 flux de données de voix sur IP, pour lesquels une rupture prématurée est notamment probable : - dans le cas où le flux des données est établi avec une fonction de détection de silence ; ou - dans les cas d'invocation de services, par exemple pour la mise en garde d'un 20 appel; ou - dans le cas où le flux des données tarde à être réellement établi. Dans un réseau de voix sur IP, il est usuel d'utiliser le protocole RTP au dessous des protocoles IP et UDP. Le protocole RTCP est utilisé pour le contrôle des flux RTP. L'état actuel de la technique et notamment le document IEfF draft-ietf-avt-app- 25 rtp-keepalive-07 recommande deux méthodes pour prévenir l'expiration de ce temporisateur. La première méthode (dite "rtcp-mux") propose de multiplexer sur la même porte le flux de données RTP et le flux de contrôle RTCP de manière à ce que même en cas d'interruption du flux de données, par exemple à cause d'un silence, la séquence des 30 paquets RTCP supposée plus élevée que le temporisateur, permette de maintenir la porte ouverte. La solution « rtcp-mux » fait par conséquent l'hypothèse que des flux de contrôle rtcp sont envoyés ce qui n'est pas toujours le cas. Par ailleurs, la solution « rtcpmux » nécessite le support d'une extension définie dans le document http://tools.ietf.org/html/draft-ietf-avt-rtp-and-rtcp-mux-07. 35 La seconde méthode (dite « rtp-keepalive ») propose d'émettre avec une certaine périodicité des paquets erronés dans le flux de données dans le seul but de maintenir la porte ouverte, l'hypothèse étant faite que cette périodicité est inférieure à la durée du temporisateur maintenu par l'équipement de traduction d'adresses. Les paquets étant erronés, cette deuxième solution ne passe pas les entités intermédiaires du réseau, par exemple les entités IMS c-BGF & i-BGF, celles-ci contrôlant la validité du flux.

Objet et résumé de l'invention L'invention propose une solution au problème du maintien de l'ouverture de porte dans un équipement mettant en oeuvre une fonction de traduction d'adresses ; cette solution ne présente pas les inconvénients des techniques connues à ce jour. Plus particulièrement, et selon un premier aspect, l'invention concerne un procédé de configuration d'au moins un terminal apte à émettre ou recevoir un flux de données dans un réseau de télécommunication, ce procédé pouvant être mis en oeuvre par une entité gérant la signalisation dans ledit réseau.

Ce procédé comporte : - une étape de réception d'un message de signalisation émis par un premier terminal à destination d'un deuxième terminal, ces terminaux étant situés dans des réseaux séparés par au moins un équipement apte à mettre en oeuvre une fonction de traduction d'adresses ; - une étape d'obtention d'une valeur de temporisation choisie en fonction d'une durée utilisée par l'équipement de traduction d'adresses pour le maintien d'une porte ouverte pour le passage d'un flux de données ; - une étape d'insertion de cette valeur de temporisation dans le message de signalisation, cette valeur devant être interprétée par le premier et/ou par le deuxième terminal comme la durée maximum à respecter entre l'émission de deux paquets de données successifs dans le flux de données ; et - une étape d'envoi du message de signalisation modifié à destination du deuxième terminal. Corrélativement, l'invention concerne également une entité apte à gérer la signalisation dans un réseau de télécommunication, cette entité comportant : - des moyens de réception d'un message de signalisation émis par un premier terminal à destination d'un deuxième terminal, ces terminaux étant situés dans des réseaux séparés par au moins un équipement apte à mettre en oeuvre une fonction de traduction d'adresses ; - des moyens d'obtention d'une valeur de temporisation choisie en fonction d'une durée utilisée par l'équipement de traduction d'adresses pour le maintien d'une porte ouverte pour le passage d'un flux de données ; - des moyens d'insertion de ladite valeur de temporisation dans le message de signalisation, cette valeur devant être interprétée par le premier et/ou par le deuxième terminal comme la durée maximum à respecter entre l'émission de deux paquets de données successifs dans le flux de données; et - des moyens d'envoi du message de signalisation modifié à destination du deuxième terminal.

Selon un deuxième aspect, l'invention vise également un procédé de gestion de flux pouvant être mis en oeuvre par un terminal apte à émettre ou recevoir un flux de données dans un réseau de télécommunication, ce procédé comportant : - une étape de réception d'un message de signalisation émis par une entité gérant la signalisation dans le réseau ; - une étape d'obtention, dans ce message de signalisation, d'une valeur de temporisation définissant la durée maximum à respecter par ce terminal entre l'émission de deux paquets de données successifs dans le flux de données; et - une étape de configuration du terminal dans le respect de cette valeur de temporisation.

Corrélativement, selon ce second aspect, l'invention concerne également un terminal apte à émettre ou recevoir un flux de données dans un réseau de télécommunication, ce terminal comportant : - des moyens de réception d'un message de signalisation émis par une entité gérant la signalisation dans ledit réseau ; - des moyens d'obtention, dans ce message de signalisation, d'une valeur de temporisation définissant la durée maximum à respecter par ce terminal entre l'émission de deux paquets de données successifs dans le flux de données ; et - des moyens de configuration dudit terminal dans le respect de ladite valeur de temporisation.

Autrement dit, et d'une façon générale, l'invention propose une solution dans laquelle la valeur de temporisation utilisée par les équipements terminaux est transmise ou ajustée par une entité gérant la signalisation dans le réseau. Très avantageusement, cette valeur peut être choisie par l'opérateur de façon optimisée en fonction de la durée utilisée par l'équipement de traduction d'adresses pour maintenir la porte ouverte pour le passage du flux de données.

La valeur de temporisation étant acquise dynamiquement par les terminaux (équipements d'extrémité), il n'est pas nécessaire de configurer ces équipements de façon statique. Par ailleurs, dans le cas d'un flux de données bidirectionnel, le procédé de configuration selon l'invention permet d'utiliser des valeurs de temporisation indépendantes à chacune de ces deux extrémités. Cette option peut être utile dans le cas où ledit équipement de traduction d'adresses présente une durée de maintien d'ouverture de porte qui dépend de la nature du flux qui traverse cet équipement. Il est très intéressant de noter que la valeur de temporisation peut être ajustée dynamiquement tout au long du chemin de signalisation, y compris lorsque ce chemin traverse différents réseaux, même exploités par des opérateurs différents. La valeur est donc optimisée pour un chemin donné entre deux terminaux. Dans un mode particulier de réalisation de l'invention, le flux de données est conforme au protocole RTP et le message de signalisation utilisé pour transmettre la valeur de temporisation est un message d'établissement de session conforme au protocole SIP. Il peut par exemple s'agir du message SIP INVITE. - Dans un mode particulier de réalisation de l'invention, l'entité gérant la signalisation obtient la valeur de temporisation à transmettre aux terminaux extrémités dans un message émis par l'équipement de traduction d'adresses lui-même.

Plusieurs protocoles peuvent être envisagés pour ce mécanisme optionnel, par exemple un mécanisme de diffusion de la valeur de temporisation par les équipements de traduction d'adresses, ou un mécanisme d'interrogation de ces équipements par l'entité gérant la signalisation dans le réseau. Dans un mode de réalisation de l'invention, le message de signalisation émis par le premier terminal ne comporte aucune valeur de temporisation, la valeur de temporisation étant insérée dans le message de signalisation la première fois par l'entité gérant la signalisation. Dans un autre mode de réalisation, le terminal émetteur du message de signalisation insère dans le message une valeur de temporisation largement excessive, l'insertion de la valeur de temporisation par l'entité gérant la signalisation consistant dans ce cas à diminuer la valeur de temporisation. Ce mode de réalisation est préférable lorsque le protocole ou la syntaxe utilisée pour la signalisation nécessite la présence d'un champ pour la valeur de temporisation. L'invention peut être mise en oeuvre avec différents modes de réalisation.

Par exemple, le protocole SDP peut être utilisé pour spécifier la valeur du temporisateur.

Une première méthode consiste à transmettre la valeur, dans le protocole SDP, sous la forme d'un attribut d'un nouveau format de données. Une seconde méthode consiste à transmettre la valeur de temporisation sous la forme d'un événement spécifique de l'un des formats de données définis par le document 5 RFC 4733, ce format de données pouvant être par exemple le codec virtuel (codeur/décodeur) « telephone-event ». Une troisième méthode consiste à transmettre le paramètre de temporisation sous la forme d'un attribut SDP. Ces trois méthodes seront décrites ultérieurement de façon détaillée. On peut 10 d'ores et déjà noter que pour chacune de ces méthodes, les messages de signalisation utilisés dans l'invention sont conformes au protocole RTP. Ils ne sont donc pas rejetés par les entités intermédiaires du réseau qui contrôlent la validité du flux, contrairement aux messages de maintien de porte invalides utilisés dans l'art antérieur « rtpkeepalive ». 15 Dans un mode particulier de réalisation, les différentes étapes du procédé de configuration sont déterminées par des instructions de programmes d'ordinateurs. En conséquënce, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du 20 procédé de configuration tels que mentionné ci-dessus. De même, dans un mode particulier de réalisation, les différentes étapes du procédé de gestion de flux sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un 25 ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé de gestion de flux tels que mentionnés ci-dessus. L'un ou l'autre de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement 30 compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de 35 stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins et annexes qui illustrent un 15 exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente un réseau de télécommunication comportant des terminaux et une entité gérant la signalisation dans le réseau, ces terminaux et cette entité étant conformes à un mode particulier de réalisation de l'invention ; 20 - la figure 2 représente l'architecture matérielle des terminaux de la figure 1 ; la figure 3 représente l'architecture matérielle de l'entité de la figure 1 ; et - la figure 4 représente, sous forme d'organigramme, les principales 25 étapes d'un procédé de configuration et d'un procédé dé gestion de flux conformes à un mode particulier de réalisation de l'invention. Les annexes sont des exemples de messages pouvant être utilisés dans l'invention.

30 Description détaillée de l'invention

La figure 1 représente un réseau de télécommunication. Plus précisément, sur cette figure, on a représenté un réseau domestique RD, un réseau opérateur RO et un réseau tiers RT. 35 Une passerelle domestique HGW réalise l'interface entre le réseau domestique RD et le réseau opérateur RO. 10 Cette passerelle domestique incorpore une fonction NAT de traduction d'adresses. Sur cette figure, on a représenté en traits fins, le flux de signalisation et en traits épais le flux de données entre un premier terminal Tl et un deuxième terminal T2.

Le flux de signalisation traverse la fonction NAT de traduction d'adresses de la passerelle domestique HGW et les entités IMS de l'opérateur du client desservi avant d'atteindre le réseau tiers RT via un équipement SBC (Session Border Controller). Dans cet exemple, le flux de données (flux média) traverse la fonction NAT de la passerelle domestique HGW, une entité C-BGF faisant office de relais média et le SBC à la frontière du réseau tiers RT. Dans l'exemple de réalisation décrit ici, la passerelle domestique HGW, l'équipement P-CSCF et l'entité SBC mettent en oeuvre le procédé de configuration selon l'invention. Les terminaux Tl et T2 sont également des terminaux conformes à l'invention. 15 La figure 2 représente l'architecture matérielle d'un terminal TRM identique à celles des terminaux Ti et T2. L'architecture matérielle du terminal TRM est celle d'un ordinateur conventionnel. Elle comporte un processeur 110, une mémoire morte de type ROM 120, une mémoire morte de type RAM 130 et des moyens 140 de communication. La mémoire 20 morte de type ROM 120 est un support d'enregistrement lisible par le processeur 110 sur lequel est enregistré un programme d'ordinateur PG1 comprenant des instructions pour l'exécution des étapes du procédé de gestion de flux qui sera décrit en référence à la figure 4. La figure 3 représente l'architecture matérielle d'une entité ENT apte à gérer 25 la signalisation dans le réseau de télécommunication, cette entité ENT étant conforme à l'invention. Dans l'exemple de réalisation décrit ici, la passerelle domestique HGW et l'entité P-CSCF et l'entité SBC ont une architecture matérielle identique à celle de l'entité ENT. Il s'agit d'une architecture d'un ordinateur conventionnel. L'entité ENT comporte 30 un processeur 210, une mémoire morte de type ROM 220, une mémoire vive de type RAM 230 et des moyens 240 de communications. La mémoire morte 220 est un support d'enregistrement lisible par le processeur 210 sur lequel est enregistré un programme d'ordinateur PG2 comprenant des instructions pour l'exécution des étapes du procédé de configuration dont les principes 35 étapes sont représentées sur l'organigramme à la figure 4.

En référence à la figure 4, dans le mode de réalisation décrit ici, le terminal Ti envoie un message de signalisation M1 pour établir un appel vers le terminal T2 au cours d'une étape E10. Il s'agit dans cet exemple d'un message SIP de type INVITE.

Ce message M1 est reçu par la passerelle domestique HGW au cours d'une étape F10 de son procédé de configuration. Conformément à l'invention, la passerelle domestique obtient, au cours d'une étape F20 de son procédé de configuration, une valeur de temporisation, cette valeur étant choisie en fonction de la durée utilisée par la fonction de traduction d'adresses NAT de la passerelle domestique HGW. Puis, au cours d'une étape F30, de son procédé de configuration, la passerelle domestique HGW insère cette valeur de temporisation TP dans le message de signalisation M1 reçu à l'étape F10. Elle transmet ensuite au cours d'une étape F40 le message de signalisation modifié, dénommé M2 à destination du deuxième terminal T2.

Le message de signalisation M2 après insertion de la valeur de temporisation par la passerelle domestique HGW est donné à titre d'exemple à l'annexe 1. Dans cet exemple, on utilise un nouveau paramètre "nat-keepalive" pour spécifier la valeur de temporisation. Dans cet exemple, la valeur de temporisation est fixée égale à 300 000 ms.

Lorsque ce message de signalisation est reçu par l'entité P-CSCF, celle-ci met également en oeuvre son procédé de configuration. On suppose dans cet exemple, que l'entité P-CSCF a connaissance que la temporisation appliquée à l'entité C-BGF est de 3 minutes. Par conséquent, elle diminue la valeur de temporisation TP du message M2.

Le message modifié dénommé « M3 » est représenté à l'annexe 2. Le message M4 n'est pas modifié dans cet exemple. On suppose également que la temporisation locale à l'entité SBC est supérieure à 3 minutes, de sorte que celle-ci ne modifie pas le message lors du transit par cette entité.

Le message M5 d'acquittement positif qui remonte vers le terminal Ti est représenté à l'annexe 3 ; il s'agit d'un message de type 200 0K qui indique que le terminal T2 acquitte la demande initiale. Par la suite, les entités de signalisation ne modifient pas le message d'acquittement (messages M6 et M7). Sur réception de ce message de signalisation 200 0K (message M8) le terminal Ti établit le flux de données média (M9) représenté en trait épais sur la figure 1.

La valeur de temporisation est ajustée à 3 minutes à chaque extrémité Tl, T2 de ce flux. Aux annexes 1 à 3, on a supposé que les entités gérant la signalisation dans le réseau utilisaient, pour spécifier la valeur de temporisation TP, un nouveau paramètre « nat-keepalive ». L'annexe 4 donne un exemple dans lequel on utilise, pour spécifier la valeur de temporisation, un attribut d'un nouvel identifiant de format de données 103. Dans l'exemple de l'annexe 4, la temporisation est forcée à une valeur très grande à savoir 1000000 millisecondes.

Dans le mode de réalisation de l'invention donné à l'annexe 5, on utilise cette fois un nouvel évènement "RTP keepalive" affecté au code 17 dans cet exemple. La méthode de l'annexe 5 présente les mêmes avantages que celle de l'annexe 4 ainsi que de ne pas nécessiter de nouveau format de données. Elle présente cependant l'inconvénient de nécessiter l'ajout d'un évènement dont la liste des évènements "telephone-event" décrite dans le document RFC 4733 et l'extension de l'attribut SDP fmtp. - La méthode de l'annexe 4 présente l'inconvénient de nécessiter la déclaration d'un nouveau format de données ainsi que l'extension de l'attribut SDP fmtp. (Dans chacun des modes de réalisation, il est possible de prévoir une position de repli vers les solutions existantes, par exemple vers l'une ou l'autre des deux solutions (« rtcp-mux », « rtcp-keepalive ») mentionnées précédemment et décrites dans le document draft-ietf-avt-app-rtp-keepalive-07 lorsqu'un terminal du réseau n'est pas en mesure de mettre en oeuvre l'invention. Le terminal Tl reçoit, dans l'exemple de réalisation décrit ici, la réponse SIP 200 0K au cours d'une étape E20 de son procédé de gestion de flux. Conformément à l'invention, il obtient, dans ce message de signalisation, la valeur de temporisation fixée ou ajustée par le réseau (étape E30) et se configure, au cours d'une étape E40, en enregistrant la valeur de temporisation TP contenue dans ce message SIP 200 0K.

Au moins l'un des deux terminaux, par exemple le terminal T2, respecte alors, entre l'émission de deux paquets de données successifs, une durée inférieure à cette valeur de temporisation TP (de préférence, juste inférieure afin de limiter la charge de ce terminal et des réseaux traversés).35 ANNEXE 1

INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call ID. a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (partially shown : ) v=0 m=audio RTP/AVP 43210 8 a=nat-keepalive: 300000; ANNEXE 2

INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP pcscf.operateur.com;branch=z9hG4bKlodhds8 Max-Forwards: 69 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 CaII-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (partially shown : ) v=0 m=audio RTP/AVP 43210 8 a = n at- kee pa l i ve: 180000 ANNEXE 3

SIP/2.0 200 0K Via: SIP/2.0/UDPserverlO.biloxi.com;branch=z9hG4bKb43s8 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call ID. a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 131 (partially shown : ) v=0 m=audio RTP/AVP 5412 8 a=nat-keepalive: 180000 ANNEXE 4

INVITE sip:bob@biloxi.com SIP/2,0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (partially shown : ) v=0 m=audio RTP/AVP 43210 8 103 a=rtpmap:103 keepalive/8000 a=fmtp:103 refresh = 1000000 ANNEXE 5

INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 Tc): Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (partially shown : ) v=0 m=audio RTP/AVP 43210 8 103 a=rtpmap:103 telephone-event/8000 a=fmtp:103 17 refresh = 1000000

Claims

REVENDICATIONS1. Procédé de configuration d'au moins un terminal (Ti, T2) apte à émettre ou recevoir un flux de données (M9) dans un réseau de télécommunication, ce procédé pouvant être mis en oeuvre par une entité (ENT) gérant la signalisation dans ledit réseau, ledit procédé comportant : - une étape (F10) de réception d'un message de signalisation (Ml) émis par un premier terminal (Tl) à destination d'un deuxième terminal (T2), les terminaux étant situés dans des réseaux séparés par au moins un équipement (NAT) apte à mettre en oeuvre une fonction de traduction d'adresses ; - une étape (F20) d'obtention d'une valeur de temporisation (TP) choisie en fonction d'une durée utilisée par ledit équipement de traduction d'adresses pour le maintien d'une porte ouverte pour le passage d'un flux de données ; - une étape (F30) d'insertion de ladite valeur de temporisation dans ledit message de signalisation (M2), cette valeur devant être interprétée par le premier et/ou par le deuxième terminal comme la durée maximum à respecter entre l'émission de deux paquets de données successifs dans le flux de données (M9); et - une étape (F40) d'envoi dudit message de signalisation modifié (M2) à destination dudit deuxième terminal.
2. Procédé de configuration selon la revendication 1, caractérisé en ce que ledit flux de données (M9) est conforme au protocole RTP et en ce que ledit message de signalisation (Ml) est un message d'établissement de session conforme au protocole SIP.
3. Procédé de configuration selon la revendication 1, dans lequel ladite étape d'insertion consiste à diminuer ladite valeur de temporisation (TP) lorsque ledit message d'établissement d'appel reçu par ladite entité comporte déjà une telle valeur. 30
4. Procédé de configuration selon la revendication 1, caractérisé en ce ladite valeur de temporisation (TP) est fournie à ladite entité (ENT) par ledit équipement (NAT).
5. Procédé de configuration selon la revendication 1 ou 2, dans lequel ladite valeur est transmise, dans le protocole SDP, sous forme d'un attribut d'un nouveau 35 format de données.25
6. Procédé de configuration selon la revendication 1 ou 2, dans lequel ladite valeur est transmise, dans le protocole SDP, sous forme d'un événement spécifique de l'un des formats de données définis par le document RFC 4733.
7. Procédé de configuration selon la revendication 6, dans lequel ledit format de données est le codeur/décodeur virtuel « telephone-event ».
8. Procédé de configuration selon la revendication 1 ou 2, dans lequel ladite valeur de temporisation est transmise, dans le protocole SDP, sous forme d'un attribut SDP.
9. Entité (ENT) apte à gérer la signalisation dans un réseau de télécommunication, cette entité comportant : - des moyens (240) de réception d'un message de signalisation émis par un premier terminal à destination d'un deuxième terminal, les terminaux étant situés dans des réseaux séparés par au moins un équipement apte à mettre en oeuvre une fonction de traduction d'adresses ; - des moyens (210) d'obtention d'une valeur de temporisation choisie en fonction d'une durée utilisée par ledit équipement de traduction d'adresses pour le maintien d'une porte ouverte pour le passage d'un flux de données ; - des moyens (210) d'insertion de ladite valeur de temporisation dans ledit message de signalisation, cette valeur devant être interprétée par le premier et/ou par le deuxième terminal comme la durée maximum à respecter entre l'émission de deux paquets de données successifs dans le flux de données (M9); et - des moyens (240) d'envoi dudit message de signalisation modifié à destination dudit deuxième terminal (T2).
10. Programme d'ordinateur (PG2) comportant des instructions pour l'exécution des étapes d'un procédé de configuration selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté par un ordinateur.
11. Support d'enregistrement (220) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de configuration selon l'une quelconque des revendications 1 à 8.35
12. Procédé de gestion de flux pouvant être mis en oeuvre par un terminal apte à émettre ou recevoir un flux de données (M9) dans un réseau de télécommunication, ce procédé comportant - une étape (E20) de réception d'un message de signalisation (M8) émis par une entité gérant la signalisation dans ledit réseau ; - une étape (E30) d'obtention, dans ce message de signalisation, d'une valeur de temporisation (TP) définissant la durée maximum à respecter par ledit terminal entre l'émission de deux paquets de données successifs dans ledit flux de données (M9) ; et - une étape (E40) de configuration dudit terminal dans le respect de ladite valeur de temporisation (TP).
13. Terminal (Tl, T2) apte à émettre ou recevoir un flux de données dans un réseau de télécommunication, ce terminal comportant : - des moyens (140) de réception d'un message de signalisation (M8) émis par une entité gérant la signalisation dans ledit réseau ; - des moyens (110) d'obtention, dans ce message de signalisation, d'une valeur de temporisation (TP) définissant la durée maximum à respecter par ledit terminal entre l'émission de deux paquets de données successifs dans ledit flux de données (M9) ; et - des moyens (110) de configuration dudit terminal dans le respect de ladite valeur de temporisation (TP).
14. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes d'un procédé de gestion de flux selon la revendication 12 lorsque ledit programme est exécuté par un ordinateur.
15. Support d'enregistrement (120) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion de flux selon la revendication 12.25