FR2903263A1 - Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes - Google Patents

Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes Download PDF

Info

Publication number
FR2903263A1
FR2903263A1 FR0605945A FR0605945A FR2903263A1 FR 2903263 A1 FR2903263 A1 FR 2903263A1 FR 0605945 A FR0605945 A FR 0605945A FR 0605945 A FR0605945 A FR 0605945A FR 2903263 A1 FR2903263 A1 FR 2903263A1
Authority
FR
France
Prior art keywords
type
node
address
server
sip
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR0605945A
Other languages
English (en)
Inventor
Mohamed Boucadair
Yoann Noisette
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR0605945A priority Critical patent/FR2903263A1/fr
Priority to PCT/FR2007/051531 priority patent/WO2008001007A2/fr
Priority to US12/308,889 priority patent/US20090187664A1/en
Priority to EP07803947A priority patent/EP2036301A2/fr
Publication of FR2903263A1 publication Critical patent/FR2903263A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/251Translation of Internet protocol [IP] addresses between different IP versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • H04L61/2564NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • H04L61/2578NAT traversal without involvement of the NAT server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • H04L61/2585NAT traversal through application level gateway [ALG]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Un procédé d'adressage de serveurs SIP pour l'inter-fonctionnement de noeuds SIP (A, B) d'un type IP déterminé dans lequel on alloue (A) à tout serveur SIP (P, R) une adresse auxiliaire (R2@v4, P2@v4) de même type IP que leur adresse d'origine (R1@v4, P1@v4), l'adresse auxiliaire correspondant à une adresse de communication de type IP distinct, on fournit (B) à tout noeud SIP du même type IP que ce serveur SIP l'adresse d'origine et à tout noeud SIP de type IP distinct du type IP de ce serveur SIP cette adresse de communication et on traduit (C) l'adresse de communication de l'un ou l'autre type IP en l'adresse auxiliaire, de même type IP que le type IP de l'adresse d'origine.

Description

1 PROCÉDÉ D'ADRESSAGE DES ELEMENTS DE SERVICE ET DE TRANSMISSION D'APPEL
ENTRE NOEUDS HÉTÉROGÈNES s L'invention se situe dans le domaine des télécommunications, et plus particulièrement dans celui de la téléphonie sur IP. Des réseaux conformes à un protocole de communication dit IP (abréviation bien connue de l'homme du métier de l'expression anglaise "Internet Protocol") sont de plus en plus souvent utilisés en tant que supports io universels d'une multitude de services et applications. Ce protocole IP a joué un rôle fédérateur auprès de multiples opérateurs qui ont choisi ce protocole pour mutualiser des offres de service jusqu'alors disparates. IPv4 est une version du protocole de communication IP qui est utilisée depuis des années. 15 Pour satisfaire des contraintes imposées par de tels services de communication et plus particulièrement pour répondre aux besoins accrus en termes d'adresses, des opérateurs et des constructeurs d'équipements réseau se sont unis pour spécifier un protocole de communication de nouvelle génération, communément référencé IPv6, défini par des 20 spécifications ainsi que des documents d'analyse qui sont à un stade de développement suffisamment avancé pour permettre à présent d'envisager un déploiement opérationnel dans les réseaux des opérateurs. Néanmoins, l'introduction de cette nouvelle génération de protocole pose des problèmes significatifs liés à un besoin de garantir une 25 interopérabilité et un interfonctionnement du protocole IPv6 et du protocole IPv4 qui est déjà déployé dans les réseaux IP. Dans la couche transport, des mécanismes ont été proposés, voire standardisés à l'IETF (abréviation bien connue de l'homme du métier de l'expression anglaise "Internet Engineering Task Force") tels qu'une 30 technique dite NAT-PT et diverses techniques connues sous le vocable anglais tunneling et consistant à encapsuler des données IPv6 dans des datagrammes IPv4 ou inversement. En outre, des mises à jour et des adaptations d'architectures et 2903263 2 de plateformes de services sont nécessaires pour permettre un interfonctionnement entre clients situés dans des environnements IP de nature différente (IPv4 ou IPv6), et ceci d'une manière aussi transparente que possible pour le client final.
Parmi ses activités multimédia, l'IETF a standardisé un protocole appelé SIP (abréviation bien connue de l'homme du métier de l'expression anglaise "Session Initiation Protocol") offrant pour principales fonctions l'initiation, la modification et la terminaison de sessions multimédia. Le protocole SIP constitue un exemple intéressant d'application de la présente invention. Le protocole SIP s'appuie sur un protocole SDP (abréviation bien connue de l'homme du métier de l'expression anglaise "Session Description Protocol") pour produire une description de paramètres associés à la session concernée. Une fois une négociation réussie entre deux parties participant à un appel, ces dernières peuvent échanger des flux média grâce à une activation d'un protocole RTP (abréviation bien connue de l'homme du métier de l'expression anglaise "Real time Transport Protocol"). Des paramètres de sessions RTP sont pré-négociés via des messages de signalisation SIP, notamment dans la partie SDP. Ces paramètres sont principalement des adresses de terminaison et des numéros de port qui seront utilisés de part et d'autre. Depuis la première version du protocole SIP, décrite dans un document référencé RFC 2543 (RFC signifiant "requête pour commentaires" ou "Request For Comment" en anglais), ce dernier supporte le protocole IPv6. Une implémentation conforme à la RFC2543, ou à sa mise à jour RFC3261, décode en principe facilement des adresses conformes aux protocoles IPv4 et IPv6. Une telle adresse peut être introduite dans un champ spécifique tel un entête CONTACT ou dans des en-têtes de la partie SDP. Cependant, la présence de telles adresses peut empêcher l'établissement des appels SIP dans le cas où les deux terminaux ne sont pas joignables dans un même environnement IP, à savoir si l'une dispose d'une adresse IPv4 et l'autre d'une adresse IPv6. Ainsi quand un agent utilisateur de type IPv4 A initie une session SIP vers un agent utilisateur de 2903263 3 type IPv6 qui s'est enregistré auprès d'un serveur de localisation (noté R ci-après) IPv4, l'échange de messages SIP produit est décrit dans la figure la, où un premier agent utilisateur A désireux d'entrer en contact avec un deuxième agent utilisateur B envoie un message INVITE vers un serveur 5 de proximité dit serveur proxy (noté PS ci-après) en utilisant une adresse IPv4 propre à ce dernier. Le serveur proxy PS est ici un serveur attaché à un environnement IPv4 exclusivement. Une fois le message reçu par le serveur proxy PS, ce dernier effectue une requête auprès d'un serveur de localisation encore appelé serveur d'enregistrement et récupère ainsi 10 l'adresse du deuxième agent utilisateur B. Cette adresse étant par hypothèse une adresse IPv6, le serveur proxy PS ne connaît pas de route vers cette destination étant donné que ce serveur proxy PS est exclusivement de type IPv4. Un message d'erreur est alors envoyé vers l'agent utilisateur A concluant à une impossibilité d'établir une session SIP 15 entre les premier et deuxième agents utilisateurs A et B. Ce message d'erreur est noté (2) 404 No Route sur la figure la. Si l'on suppose maintenant que le serveur proxy PS peut néanmoins joindre l'adresse de localisation du premier agent utilisateur A ainsi que celle du deuxième agent utilisateur B, un autre échange de 20 messages SIP est observé, quand le deuxième agent utilisateur B essaye d'appeler le premier agent utilisateur A, ainsi que représenté en figure lb. Dans ce cas de figure, le serveur proxy PS achemine un message INVITE reçu du deuxième agent utilisateur B vers l'adresse de localisation du premier agent utilisateur A. Ce message INVITE contient 25 une offre SDP décrivant, outre des capacités offertes par le premier agent utilisateur B en termes de CODEC (pour "codeur/décodeur"), un numéro de port RTP et une adresse qu'utilisera le deuxième agent utilisateur B pour émettre/recevoir des flux RTP. Dans le cas de la figure lb, cette adresse est de type IPv6. Ainsi, lorsque l'agent utilisateur A reçoit ce message 30 INVITE , il ne peut que refuser l'ouverture de la session car cet agent utilisateur est un client IPv4. Au mieux pourra-t-il, selon les implémentations, renvoyer un message d'erreur indiquant qu'il ne supporte pas les connexions 2903263 4 réseaux vers l'adresse IP de l'agent utilisateur B. Dans les deux exemples précédents, décrits en liaison avec les figures 1 a et 1 b, les sessions SIP ne peuvent ainsi pas être établies. Une coexistence d'adresses IP de types différents pourra affecter 5 d'autres appels que ceux ayant fait l'objet de la représentation graphique décrite ci-dessus. Ainsi, des appels destinés à des clients de type IP double pile, DS, (abréviation bien connue de l'homme du métier de l'expression anglaise "Dual Stack"), peuvent aussi ne pas aboutir à des échanges de flux média, les agents utilisateurs de type DS étant en mesure de traiter les deux 10 types d'adresse IPv4 et IPv6. Ceci est dû au fait que le protocole SIP de base ne permet de renseigner qu'une seule adresse IP pour l'émission ou la réception des flux média. Pour pallier ce problème, des documents référencés RFC 4092 et RFC 4091 introduisent une nouvelle sémantique consistant, entre autres, à définir un indicateur dénoté sdp-anat . Cette 15 nouvelle sémantique permet à un agent utilisateur, d'annoncer et/ou de découvrir un ou plusieurs types d'adresse. Ainsi, des agents utilisateurs de type double pile sont en mesure d'indiquer dans leur offre SDP leurs deux adresses IPv4 et IPv6. Grâce à cette technique, tous les appels de/vers un agent utilisateur de type DS vers des/de clients mono version (i.e. 20 compatibles avec le protocole IPv4 seulement ou avec le protocole IPv6 seulement) peuvent donner lieu à des sessions SIP réussies. Dans un cas où deux noeuds formant des extrémités d'une liaison de communication destinée à véhiculer un appel donné sont mono version, l'opérateur de service de téléphonie SIP concerné peut avoir recours à des 25 applications ALG (abréviation bien connue de l'homme du métier de l'expression anglaise "Application Layer Gateway"), pour modifier les offres SDP afin d'assurer une cohérence entre le type d'adresse supporté et celui contenu dans les messages SIP reçus. Pour ce faire les serveurs SIP utilisent des informations relatives à la couche transport, et non propres au 30 protocole SIP, pour router les appels ou pour déterminer le recours à des applications ALG pour altérer le contenu des offres SDP. Un tel comportement des serveurs SIP n'est pas décrit dans la norme. 2903263 5 D'une manière générale le problème lié aux interconnexions de deux agents utilisateurs hétérogènes (c'est-à-dire de types IP distincts) n'a pas été étudié en détail par la communauté des télécommunications. Excepté une proposition ANAT décrite par (RFC 4091, RFC 4092) qui résout 5 une partie du problème, il n'existe en particulier pas de document de l'IETF décrivant le comportement des serveurs SIP pour acheminer des appels reliant deux agents utilisateurs appartenant à deux environnements IP différents. En outre, les techniques existantes présentent les inconvénients 10 suivants : le recours aux applications ALG et aux fonctions supplémentaires n'est pas documenté. Le serveur proxy PS ne dispose pas de moyens prévus par la RFC 3261 pour faciliter cette tâche ; la solution n'est pas générique: la philosophie de routage d'appel et 15 d'intervention du serveur proxy PS dépend de la solution d'interconnexion déployée au niveau transport ; le serveur proxy PS ne dispose pas de moyens pour déterminer si un agent utilisateur est de type IPv4, IPv6 ou double pile. Les travaux conduits par les inventeurs ont mené ceux-ci à 20 conclure que, nonobstant un besoin qui ressort de l'étude qui précède, il n'existe dans l'état de la technique aucune disposition visant à permettre à un moyen de communication appartenant à un réseau de communication conforme à un protocole IP d'identifier de manière simple et générique le type IP d'adresse associé à un agent utilisateur donné, une telle carence 25 expliquant pourquoi la plupart des techniques de gestion de communications entre noeuds hétérogènes actuellement à l'étude sont insuffisantes et ne répondent pas aux besoins de service consistant à permettre des communications hétérogènes. La présente invention a pour objet de remédier aux inconvénients 30 et limitations des techniques actuelles, compte tenu de la présence conjointe des protocoles de communication IPv4, IPv6 ou IP ISO défini par la norme ISO 8473 dans les réseaux IP. 2903263 6 Plus précisément, un objet de l'invention est de permettre aux serveurs SIP, de connaître le type IP d'agents utilisateurs cherchant à communiquer, afin de permettre l'établissement réussi de sessions entre ces agents, qu'ils soient ou non de même type, de faciliter le routage des appels 5 et d'optimiser l'usage d'adresses IP. Conformément à l'invention exposée dans la présente demande de brevet, on considère à titre de seul exemple, la téléphonie sur IP désignée couramment par VoIP pour Voice over IP en anglais, ou généralement groupée sous le thème des services conversationnels. 1 o L'invention s'inscrit dans la problématique générale des services de transmission basés sur le protocole SIP défini par la RFC 3261 et déployés à la fois pour des clients IPv4 et des clients IPv6. Ces services peuvent être des services de voix, de vidéo, de présence, etc. L'invention propose un mécanisme simple pour faciliter 15 l'établissement de sessions SIP entre deux clients ou noeuds SIP hétérogènes, un attaché à un domaine IPv4 et l'autre à un domaine IPv6 par exemple. La présente invention a, notamment, en conséquence pour objet la mise en oeuvre d'un procédé d'adressage de serveurs SIP pour l'inter- 20 fonctionnement de noeuds SIP hétérogènes permettant d'allouer aux serveurs SIP des ressources pour reconnaître le type IP des agents utilisateurs UA. Par type IP d'un agent utilisateur, on entend la ou les versions de protocole IP (par exemple IPv4, IPv6) que cet agent utilisateur est à même de mettre en oeuvre par l'intermédiaire de la ou des interfaces 25 réseaux dont dispose le noeud SIP qui l'abrite. Des noeuds SIP hétérogènes sont donc des noeuds SIP qui comprennent des agents utilisateurs de types IP différents. Un autre objet de la présente invention est en outre la mise en oeuvre d'un procédé d'adressage de serveurs SIP pour l'inter- 30 fonctionnement de noeuds SIP hétérogènes permettant de simplifier et ainsi de faciliter le routage des appels. Un autre objet de la présente invention est, enfin, la mise en 2903263 7 oeuvre d'un procédé d'adressage de serveurs SIP permettant d'optimiser l'usage d'adresses IP. Le procédé d'adressage de serveurs SIP pour l'inter-fonctionnement de noeuds SIP hétérogènes d'un premier respectivement 5 d'un deuxième type IP, objet de l'invention, est remarquable en ce qu'il inclut au moins l'allocation à tout serveur SIP, opérant dans un environnement IP de l'un ou l'autre type IP et muni d'une adresse d'origine d'un type IP déterminé, d'une adresse auxiliaire de même type IP que le type de l'adresse d'origine et correspondant à une adresse de communication de 10 type IP distinct, la fourniture comme adresse d'appel, à tout noeud SIP du même type IP que ce serveur SIP de cette adresse d'origine dans cet environnement IP et à tout noeud SIP, de type IP autre que le type IP de ce serveur SIP, de cette adresse de communication, la traduction de cette adresse de communication de l'un ou l'autre type IP en cette adresse 15 auxiliaire de même type IP que le type IP de cette adresse d'origine. Le mode opératoire du procédé d'adressage objet de l'invention permet d'assurer l'intercommunication de tout noeud SIP à partir d'un environnement IP d'un type IP correspondant à celui des serveurs SIP ou d'un type IP distinct. 20 Le procédé d'adressage objet de l'invention est en outre remarquable en ce que cette adresse de communication est configurée comme entrée DNS de l'environnement IP de type IP distinct de celui de ce serveur SIP. Le procédé d'adressage objet de l'invention est enfin 25 remarquable en ce que les serveurs SIP incluent tout serveur d'enregistrement respectivement tout serveur proxy de l'un ou l'autre des environnements IP. L'invention couvre également un procédé de communication entre au moins un serveur opérant dans un environnement de type IP 30 déterminé et au moins un noeud du réseau, ce noeud étant de même type IP ou de type IP distinct du type IP déterminé. Ce procédé de communication est remarquable en ce qu'il 2903263 8 comprend les étapes suivantes, allocation au serveur d'au moins deux adresses dans l'environnement de type IP déterminé, comprenant une adresse dite d'origine et une adresse dite auxiliaire, à laquelle est associée par traduction une adresse de communication dans un environnement de 5 type IP distinct du type IP déterminé, la fourniture à ce noeud, comme adresse d'appel du serveur de cette adresse d'origine, si le noeud est de même type IP que le type IP déterminé, respectivement de cette adresse de communication, si le noeud est de type IP distinct du type IP déterminé, et, sur appel de ce serveur par ce noeud, la discrimination du type IP de ce 10 noeud en fonction de l'adresse d'origine ou auxiliaire du serveur sur laquelle est reçu cet appel. Le procédé de communication, objet de l'invention, est en outre remarquable en ce que, le serveur étant un serveur d'enregistrement, ce procédé comprend également une étape d'enregistrement du noeud en 15 fonction du type IP discriminé dans au moins une base de données. Le procédé objet de l'invention est en outre remarquable en ce que ce serveur d'enregistrement maintient au moins deux bases de données comprenant respectivement les noeuds de même type IP que le type IP déterminé et les noeuds de type IP distincts du type IP déterminé. Les 20 adresses stockées dans ces bases de données sont de même type que celui du serveur proxy. Le procédé de communication, objet de l'invention, est également remarquable en ce que le noeud présentant au moins deux types IP, à savoir le type IP déterminé et au moins un type IP distinct de ce type IP déterminé, 25 ce procédé comprend une étape de transmission par ce noeud d'une requête d'enregistrement vers l'adresse d'origine du serveur d'enregistrement, et une étape de transmission par ce noeud d'au moins une requête d'enregistrement vers l'adresse de communication du serveur, destinée à être reçue après traduction sur l'adresse auxiliaire du serveur. 30 Le procédé de communication objet de l'invention est également remarquable en ce que le serveur étant un serveur proxy et l'appel du serveur proxy par le noeud mettant en oeuvre une transmission au serveur 2903263 9 proxy d'une requête d'appel du noeud appelant vers un noeud appelé, ce procédé comprend également une première étape de transmission du serveur proxy vers le serveur d'enregistrement d'une requête de type IP du noeud appelé, une deuxième étape de transmission du serveur 5 d'enregistrement vers le serveur proxy du type IP du noeud appelé enregistré dans la base de données et d'une adresse du noeud appelé et une étape de routage de cet appel du noeud appelant vers le noeud appelé, en fonction du type IP du noeud appelant discriminé par le serveur proxy et du type IP du noeud appelé transmis par le serveur d'enregistrement. 1 o Le procédé objet de l'invention est enfin remarquable en ce que lors de la deuxième étape de transmission, l'adresse du noeud appelé transmise par le serveur d'enregistrement est une adresse dans l'environnement de type IP déterminé dans lequel opère le serveur proxy. Le procédé de communication objet de l'invention est également 15 remarquable en ce que au cours de l'exécution de l'étape d'enregistrementä pour tout noeud SIP de type IP déterminé, l'adresse IP enregistrée pour ledit noeud dans la base de données par le serveur d'enregistrement est systématiquement du même type IP que le serveur proxy utilisé par le service, ceci afin d'assurer l'exploitation ultérieure de ladite adresse par ledit 20 serveur proxy et en particulier pour le routage de l'appel. L'invention couvre également un serveur SIP d'enregistrement opérant dans un environnement IP de type IP déterminé en présence d'un autre environnement IP de type IP distinct et comportant des organes d'entrée sortie reliés à une unité centrale de traitement et à une mémoire de 25 travail, remarquable en ce qu'il comporte, outre une adresse IP d'origine, une adresse IP auxiliaire de type IP correspondant à cet environnement IP, des moyens de discrimination du type IP de tout noeud SIP opérant un enregistrement en fonction de l'adresse d'appel d'origine respectivement de communication correspondant à cette adresse auxiliaire utilisée par ce noeud 30 SIP, dans une requête d'enregistrement transmise à ce serveur SIP d'enregistrement, des moyens de première et de deuxième base de données d'enregistrement de chaque noeud SIP candidat, correspondant à un noeud 2903263 10 SIP de même type IP que le type IP de ce serveur SIP d'enregistrement, dont l'adresse d'appel est l'adresse d'origine de ce dernier, respectivement de type IP distinct du type IP de ce serveur SIP d'enregistrement, dont l'adresse d'appel est l'adresse auxiliaire de ce serveur SIP d'enregistrement 5 par l'intermédiaire de cette adresse de communication. L'invention couvre enfin un serveur proxy SIP opérant en transmission d'une requête d'appel d'un noeud SIP appelé par un noeud SIP appelant, de type IP déterminé identique ou distinct, dans un environnement IP de type IP déterminé en présence d'un autre environnement IP de type IP io distinct, ce serveur proxy SIP comportant des organes d'entrée û sortie reliés à une unité centrale de traitement et à une mémoire de travail. II est remarquable en ce qu'il inclut, outre une adresse IP d'origine correspondant à cet environnement IP de type IP déterminé, une adresse auxiliaire de même type IP que le type IP de l'adresse d'origine, des 15 moyens de discrimination, à partir de la requête d'appel du type IP de tout noeud SIP appelant, en fonction de l'adresse d'appel qui peut être soit l'adresse d'origine, soit une adresse auxiliaire de ce serveur proxy SIP qui correspond à l'adresse d'appel initiale, des moyens de discrimination, par un serveur SIP d'enregistrement objet de l'invention précité, du type IP du noeud 20 SIP appelé, et des moyens de transmission et de routage de cette requête d'appel, compte tenu du type IP du noeud SIP appelé. Ils seront mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels, outre les figures la et 1 b relatives à l'art antérieur : 25 la figure 2a représente à titre purement illustratif un organigramme des étapes essentielles du procédé d'adressage de serveur SIP, objet de la présente invention ; la figure 2b représente, à titre illustratif, une configuration réseau IP en présence d'un premier environnement IP de type IPv4 et d'un deuxième 30 environnement IP de type IP distinct, IPv6, interconnectés par un noeud intermédiaire ; la figure 3a représente, à titre illustratif, un organigramme des étapes 2903263 11 essentielles d'un processus d'enregistrement de noeud SIP auprès d'un serveur d'enregistrement SIP, grâce à la mise en oeuvre du procédé d'adressage conforme à l'objet de la présente invention ; la figure 3b représente, à titre illustratif, un organigramme spécifique de 5 mise en oeuvre du processus d'enregistrement illustré en figure 3a, dans le cas où le noeud SIP est un noeud SIP de type IP double pile ; la figure 4a représente, à titre illustratif, un organigramme des étapes essentielles d'un procédé de transmission d'un appel entre un noeud SIP appelant et un noeud SIP appelé par l'intermédiaire d'un proxy SIP grâce 1 o au procédé d'adressage et au processus d'enregistrement objets de la présente invention ; - la figure 4b représente, à titre illustratif, un organigramme des étapes essentielles d'un procédé de communication conforme à l'objet de la présente invention, entre un serveur opérant dans un environnement de 15 type IP déterminé et au moins un noeud d'un réseau ; la figure 4c représente à titre illustratif une variante de mise en oeuvre du procédé de communication illustré en figure 4b, dans lequel le type IP du noeud appelant et du noeud appelé est établi par un serveur d'enregistrement sur requête d'un serveur proxy ; 20 les figures 5a à 5c représentent, à titre illustratif, un protocole de transmission d'appel entre noeud SIP de même type IP, IPv4 figure 5a, IPv6 figure 5b et de type IP distinct, IPv4 - IPv6 figure 5c ; la figure 6a représente, à titre illustratif, un schéma fonctionnel d'un serveur d'enregistrement SIP conforme à l'objet de la présente invention ; 25 la figure 6b représente, à titre illustratif, un schéma fonctionnel d'un serveur proxy SIP conforme à l'objet de la présente invention. Une description plus détaillée du procédé d'adressage de serveur SIP pour l'inter-fonctionnement de noeuds SIP d'un premier respectivement d'un deuxième type IP sera maintenant donnée en liaison avec la figure 2a 30 et la figure 2b. En référence aux figures précitées, on considère à titre d'exemple un premier environnement IP de type IPv4 et un deuxième environnement IP 2903263 12 de type IPv6. Ainsi que représenté en figure 2b, on indique que, de manière non limitative, la présente description est établie dans le contexte où l'ensemble des éléments constituant la plateforme de service SIP réside 5 dans l'environnement IPv4 et en conséquence, les éléments précités, c'est-à-dire le serveur d'enregistrement R et le serveur proxy SIP P sont représentés dans l'environnement IPv4. On indique toutefois que le procédé objet de la présente invention est tout à fait applicable en inversant les rôles entre lo l'environnement IPv4 et l'environnement IPv6, les éléments serveur d'enregistrement R et serveur proxy SIP P étant alors placés dans l'environnement IPv6 dans cette hypothèse. En outre, on considère à titre d'exemple non limitatif et afin de faciliter la compréhension de l'ensemble, l'existence d'un noeud 15 intermédiaire IN représenté en figure 2b pour Intermediate Node en anglais situé à la frontière des environnements IPv4 et IPv6. Ce noeud intermédiaire représente fonctionnellement les éléments requis pour l'interconnexion des domaines IPv6 et IPv4 tels que les éléments NAT-PT précédemment cités dans la description. Toutefois, on indique que les 20 fonctions / traitements / opérations exécutés par le noeud intermédiaire IN peuvent être répartis dans le réseau en fonction de l'implémentation du service mis en place par un opérateur de ce dernier. En référence aux figures 2a et 2b, on dispose donc d'un serveur d'enregistrement R d'adresse d'origine RI@v4, d'un serveur proxy SIP P 25 d'adresse d'origine Pi@v4, d'un noeud SIP A d'adresse A@v4 dans l'environnement IPv4 et d'un noeud SIP B d'adresse B@v6 dans l'environnement IPv6. Ainsi que représenté en figure 2a, le procédé objet de l'invention consiste à allouer en une étape A, à tout serveur SIP, i.e. serveur 30 d'enregistrement R et serveur proxy SIP P, opérant dans un environnement IP de l'un ou l'autre type IP, une adresse auxiliaire de même type IP que le type de l'adresse d'origine. 2903263 13 Ainsi à l'étape A de la figure 2a, au serveur d'enregistrement R est allouée l'adresse auxiliaire R2@v4 et au serveur proxy SIP P est allouée l'adresse auxiliaire P2@v4. A l'adresse auxiliaire précitée on associe une adresse de communication de type IP distinct du type de l'adresse auxiliaire. 5 L'étape A est alors suivie d'une étape B consistant à fournir à tout noeud SIP, du même type IP que le serveur SIP, l'adresse d'origine de chaque serveur SIP dans l'environnement IP correspondant, et à tout noeud SIP,de type IP autre que le type IP du serveur proxy SIP, une adresse de communication correspondant à l'adresse auxiliaire allouée à chaque 10 serveur SIP. Ainsi que représenté à l'étape B de la figure 2a, on dispose après la fourniture des adresses précitées, afin de mettre en communication les noeuds SIP A et B : Noeud SIP A : 15 - A@v4, adresse du noeud SIP A dans l'environnement IPv4 ; RI@v4, adresse d'origine du serveur d'enregistrement R dans l'environnement IPv4 ; Pi@v4, adresse d'origine du serveur proxy SIP P dans l'environnement IPv4; 20 Noeud SIP B : B@v6, adresse du noeud SIP B dans l'environnement IPv6 ; R2@v6, adresse de communication du serveur d'enregistrement R ; P2@v6, adresse de communication du serveur proxy SIP P. L'étape de fourniture d'adresses précitées est alors suivie d'une 25 étape C consistant à traduire l'adresse de communication de l'un ou l'autre type IP en l'adresse auxiliaire de même type IP que le type IP de l'adresse d'origine des serveurs SIP. A l'étape C de la figure 2a, l'opération de traduction est notée selon les relations : 30 P2@v6 -> P2@v4 R2@v6 H R2@v4. On comprend ainsi que, grâce au processus d'allocation 2903263 14 d'adresses auxiliaires et en fait de double adressage de chaque serveur SIP mis en jeu, l'intercommunication entre tout noeud SIP de l'un et/ou de l'autre environnement IP, IPv4 ou IPv6, peut ainsi être exécutée. D'une manière générale, on indique que les adresses d'origine 5 RI@v4 et Pi@v4 des serveurs SIP sont configurées dans les entrées DNS désignées entrées de nommage de noms de domaines dans un environnement IP correspondant, IPv4. II en est de même en ce qui concerne les adresses de communication R2@v6et P2@v6 lesquelles peuvent être configurées 10 comme entrée DNS pour l'environnement IPv6. Enfin, on indique que les serveurs SIP objets du double adressage, conformément au procédé d'adressage objet de l'invention, incluent tout serveur d'enregistrement respectivement tout serveur proxy SIP de l'un ou l'autre des environnements IP. 15 Un processus d'enregistrement d'un noeud SIP de type IP déterminé auprès d'un serveur d'enregistrement, tel que le serveur R représenté en figure 2b, sera maintenant décrit en liaison avec les figures 3a et 3b. En référence à la figure 3a précitée, on indique que le noeud SIP 20 précité peut être constitué par un noeud SIP de type IPv4 ou IPv6, le serveur d'enregistrement R opérant dans un environnement IP d'un même type IP ou d'un autre type IP que celui du noeud SIP considéré. Ainsi que représenté en figure 3a, le serveur d'enregistrement R comporte bien entendu une adresse d'origine RI@v4 dans l'exemple non 25 limitatif de la figure 2b, et une adresse auxiliaire de type IP correspondant à cet environnement IP, c'est-à-dire l'adresse R2@v4 allouée conformément au procédé d'adressage tel que décrit précédemment dans la description avec la figure 2a et la figure 2b. En référence à la figure 3a, on considère un noeud ou terminal A 30 de l'un des types IPv4 ou IPv6, à ce terminal A étant ainsi allouée une adresse A@vx, x désignant soit le type IPv4, soit le type IPv6 ou encore le type double pile tel que décrit précédemment dans la description. 2903263 15 En référence à la figure 3a, le procédé objet de l'invention consiste au moins, sur transmission d'une requête d'enregistrement notée RR(R@vx), à discriminer le type IP du noeud SIP A, en fonction de l'adresse d'appel d'origine respectivement auxiliaire correspondant à l'adresse de 5 communication utilisée initialement par le noeud SIP A pour transmettre la requête d'enregistrement. On comprend en particulier que, dans la requête d'enregistrement, R@vx désigne soit l'adresse d'origine RI@v4 du serveur d'enregistrement soit au contraire une adresse de communication telle que 10 l'adresse R2@v6 mentionnée précédemment dans la description en liaison avec la figure 2a. L'adresse de communication précitée correspond bien entendu à l'adresse auxiliaire R2@v4 allouée au serveur d'enregistrement R ainsi que mentionné précédemment dans la description. 15 A l'étape D de la figure 3a, l'opération de transmission est notée par la relation symbolique : A RR(R@vx) > R. L'étape D est alors suivie d'une étape E consistant à discriminer le type IP du noeud SIP A en fonction de l'adresse d'appel d'origine 20 respectivement de communication correspondant à l'adresse auxiliaire utilisée par le noeud SIP dans la requête d'enregistrement précitée. A l'étape E de la figure 3a, l'opération de discrimination est donnée par les relations : vx=v4 si R@vx=R1@v4, 25 vx=v6 si R@vx et2@v4. Dans les relations précédentes et dans la suite de la description, le signe = représente l'identité directe des adresses et le signe représente l'identité des adresses après traduction, par le noeud intermédiaire IN. En effet, on comprend que lorsque l'adresse d'appel est une 30 adresse de communication, celle-ci est transformée en adresse auxiliaire ce qui permet bien entendu de discriminer le type IP du noeud SIP à l'enregistrement. 2903263 16 Dans les relations précédentes, vx désigne en fait le type IP discriminé du terminal SIP. L'étape E est alors suivie d'une étape F consistant à établir et maintenir une première DB1(v4) et une deuxième DB2(v6) bases de données 5 de l'enregistrement de chaque noeud SIP. On comprend en effet, que suite à la discrimination réalisée à l'étape E, chaque noeud SIP correspond à un noeud SIP de même type IP que le type IP du serveur proxy, de type v4 dans l'exemple donné, en liaison avec la figure 2b et pour lequel l'adresse d'appel est l'adresse d'origine de ce 1 o dernier. Au contraire, un noeud SIP est de type IP distinct du type IP du serveur proxy, lorsque l'adresse d'appel correspond à l'adresse auxiliaire de ce serveur d'enregistrement par l'intermédiaire de l'adresse de communication. 15 L'établissement des bases de données d'enregistrement précitées peut correspondre à l'insertion d'une référence à l'adresse de chaque noeud SIP correspondant, notée pour cette raison A@vx=A@v4 lorsque le terminal candidat A est inscrit dans la première base de données d'enregistrement DB1(v4), et A@vx=A'@v4, l'adresse A@v6 ayant été 20 traduite en cours de route en cette adresse A'@v4, lorsque l'adresse du noeud SIP correspondant, correspond à un noeud SIP de type v6, l'adresse correspondante A'@v4 étant inscrite dans la deuxième base de données d'enregistrement DB2(v6). On comprend, en particulier, que le processus d'enregistrement 25 objet de l'invention est mis en oeuvre en raison du fait que tous les noeuds SIP de type IPv4, par configuration, contactent le serveur d'enregistrement R sur son adresse d'origine exclusivement, alors que tous les noeuds SIP de type IPv6 prennent contact avec le serveur d'enregistrement R uniquement par l'adresse de communication R2@v6, laquelle est bien entendu 30 transformée en adresse auxiliaire R2@v4. Le serveur d'enregistrement reçoit donc toute requête émise par un terminal SIP de type IPv6 exclusivement sur son adresse auxiliaire. 2903263 17 Dans le cas d'un terminal SIP double pile Aos, c'est, de préférence, l'adresse utilisée par ce dernier pour s'enregistrer auprès du serveur d'enregistrement R qui permet de déterminer la base dans laquelle il apparaît. 5 En outre, et dans un mode de réalisation préférentiel non limitatif, on indique que pour une procédure d'enregistrement optimisée et dans le cas d'un noeud SIP de type IP double pile, le processus peut consister en outre, ainsi que représenté en figure 3b, à transmettre en une étape D' une requête d'enregistrement de type IP correspondant au type IP du serveur 10 proxy et à transmettre une requête d'enregistrement de type IP distinct du type IP du serveur proxy. Cette opération à l'étape D' de la figure 3b est notée par la relation : RRA ((R @ vx ), RR2 (R @ vy R ADS 15 Dans la relation précédente, on comprend que RR1(R@vx) désigne la requête d'enregistrement de type IP correspondant au type IP du serveur proxy par exemple et que RR2(R@vy) désigne une requête d'enregistrement de type IP distinct du type IP du serveur proxy par exemple. 20 Les types IP des deux requêtes peuvent bien entendu être intervertis. L'étape D' est alors suivie d'une étape E' consistant à discriminer le type IP du noeud SIP à partir de chacune des deux requêtes d'enregistrement émises précitée. 25 A l'étape E' présentée en figure 3b, la discrimination des types vx et vy, est représentée par la relation symbolique : vx=v4 si R@vx=R1@v4, vy=v6 si R@vy2@v4. De même que dans le cas de la figure 3a, le signe E représente 30 l'identité des adresses après traduction, par le noeud intermédiaire IN. Dans les relations précédentes, l'identité de l'adresse d'appel du serveur d'enregistrement et de l'adresse auxiliaire du serveur 2903263 18 d'enregistrement s'entend de l'identité après transformation de l'adresse de communication formant l'adresse d'appel. L'étape E' est alors suivie d'une étape F' consistant à établir et maintenir conjointement la première et la deuxième bases de données 5 d'enregistrement DB1(v4) et DB2(v6) pour le noeud SIP de type double pile, à partir des deux types IP discriminés. On comprend ainsi que, par la mise en oeuvre du processus d'enregistrement selon l'invention représentée en figure 3b et pour un noeud SIP double pile, ce dernier est alors présent dans les deux bases de 1 o données d'enregistrement. En outre, on indique que tout noeud SIP de type IPv6, est représenté dans l'environnement IPv4 par une adresse IPv4 pour laquelle une correspondance est réalisée avec l'adresse IPv6 du noeud SIP de type IPv6 dans son environnement IP d'origine. La requête d'enregistrement d'un 15 noeud SIP de type IPv6 arrive donc sur l'adresse auxiliaire R2@v4 du serveur d'enregistrement R et l'adresse IPv4 représentant le noeud SIP de type IPv6 dans l'environnement IPv4 est alors disponible pour l'opération d'enregistrement puisque fournie par les fonctions d'adaptation mises en oeuvre par ailleurs par l'opérateur du réseau IPv4. 20 De ce fait, les bases d'enregistrement maintenues par le serveur d'enregistrement R peuvent alors ne contenir que des adresses IPv4 ce qui bien entendu assure une cohérence totale du service de transmission réseau. Un procédé de communication entre au moins un serveur S 25 opérant dans un environnement de type IP déterminé, pris à titre d'exemple non limitatif comme le type IPv4, et au moins un noeud A du réseau, ce noeud A pouvant être de même type IP, IPv4, ou de type IP distinct, IPv6, que le type IP déterminé, IPv4, du serveur S sera maintenant décrit en liaison avec la figure 4a. 30 En référence à la figure 4a précitée, on alloue, à l'étape G, au moins deux adresses au serveur S, dans l'environnement de type IP déterminé IPv4. Ces adresses comprennent une adresse d'origine, notée 2903263 19 SI@v4 et une adresse auxiliaire, notée S2@v4. A cette adresse auxiliaire est associée par traduction une adresse de communication dans un environnement de type IP, IPv6, distinct du type IP déterminé, IPv4. L'adresse de communication à l'étape G est notée S2@v6. 5 On fournit ensuite au noeud A, comme adresse d'appel du serveur S, soit l'adresse d'origine, SI@v4, si le noeud A est du même type IP déterminé, IPv4, soit l'adresse de communication, S2@v6, si le noeud A est de type IP, IPv6, distinct du type IP déterminé, IPv4. L'opération correspondante est représentée en figure 4a, pour un 10 noeud A d'adresse A@vx a priori de l'un ou l'autre type IP, IPv4 ou IPv6, par un test H de vérification du type IP de l'adresse du noeud A, par la comparaison : Vx=V4? Sur réponse positive au test H, on fournit à l'étape I l'adresse 15 d'origine SI@v4 comme adresse d'appel du serveur S au noeud A, selon la relation : AEùSi@v4 A@vx Sinon, sur réponse négative au test H, on fournit à l'étape J 20 l'adresse de communication, S2@v6, distinct du type IP déterminé, IPv4. Sur appel à l'étape K du serveur S par le noeud A, par transmission d'une requête d'appel représentée par la relation A CR(S),@v4) S où CR(Sy@v4) désigne la requête d'appel, Sy@v4 désigne soit l'adresse 25 d'origine SI@v4, soit l'adresse de communication S2@v6 qui est traduite en cours de route par IN en adresse auxiliaire S2@v4 du serveur S, on procède à la discrimination, à l'étape L, du type IP du noeud A, en fonction de l'adresse d'origine SI@v4 ou auxiliaire S2@v4 du serveur sur laquelle ce appel a été reçu. 30 Sur la figure 4a, l'étape de test L est représentée par la relation : Sy@v4 = SI@v4. Sur réponse positive au test L, le noeud A est discriminé, à l'étape 2903263 20 M, comme appartenant au type IP déterminé IPv4, A 1 A@vx = A@v4. Sinon, sur réponse négative au test L, le noeud A est discriminé à l'étape N comme appartenant au type IP distinct, IPv6, du type IP déterminé A 1 A@vx = A'@v4 qui est la traduction de A@v6 par IN, car Sy@v4 = S2@v4 lorsque 5 l'appel est reçu par P. Lorsque le serveur S est un serveur d'enregistrement, le procédé de communication comprend également une étape d'enregistrement, ainsi que décrit en liaison avec les figures 3a et 3b. Une description plus détaillée d'un procédé de transmission 10 d'appel d'un noeud SIP appelé par un noeud SIP appelant est maintenant donnée en liaison avec la figure 4b. En référence à la figure 4b précitée, on indique que le noeud SIP appelant, tel que le noeud A, est d'un type IP déterminé, l'adresse de ce noeud étant désignée A@vx et le noeud SIP appelé B est un noeud SIP de 15 type IP également déterminé, identique ou distinct du type du noeud SIP appelant. L'adresse du noeud SIP appelé est notée B@vy. La transmission de l'appel est effectuée par l'intermédiaire d'un serveur proxy SIP noté P opérant dans un environnement IP de même type IP ou de type IP distinct du type IP du noeud SIP appelant. 20 A titre d'exemple, on considère le serveur proxy SIP P lequel comporte alors une adresse d'origine Pi@v4 et une adresse auxiliaire P2@v4 de type IP correspondant à cet environnement IP et allouées conformément au procédé d'adressage objet de l'invention, tel que décrit précédemment dans la description en liaison avec les figures 2a et 2b. 25 En outre, on considère que le noeud SIP appelant A et le noeud SIP appelé B ont satisfait au processus d'enregistrement auprès du serveur R lequel dispose lui-même de son adresse d'origine RI@v4 et de son adresse auxiliaire R2@v4 ainsi que décrit précédemment dans la description, en liaison avec les figures 3a et 3b. 30 Le procédé de transmission d'appel objet de l'invention comprend au moins, ainsi que représenté sur la figure 4b, suite à la transmission à l'étape T d'une requête d'appel du noeud SIP appelant au serveur proxy SIP, 2903263 21 cette requête d'appel étant notée : CR(P@v4, B@vy), la discrimination, au niveau du serveur proxy SIP, du type du noeud SIP appelant à partir de l'adresse d'appel d'origine respectivement de l'adresse 5 de communication correspondant à l'adresse auxiliaire allouée au serveur proxy SIP. On comprend, en particulier, qu'à l'étape U la discrimination peut être directement effectuée par le serveur proxy SIP P sur la base de l'appel dans la requête d'appel, soit de l'adresse d'origine du serveur proxy SIP, 10 auquel cas le noeud SIP appelant A correspond à un noeud de type IP identique à celui du proxy SIP P, ou au contraire, à un noeud SIP de type IP distinct de celui du serveur proxy SIP P, lorsque l'adresse d'appel de ce dernier correspond, après traduction, à l'adresse auxiliaire P2@v4. L'étape U peut alors être suivie d'une étape W consistant à 15 discriminer au niveau du serveur d'enregistrement R, le type IP du noeud SIP appelé à partir des bases d'enregistrement DB1(v4) et DB2(v6). Cette opération est exécutée par un appel V du serveur d'enregistrement R par le serveur proxy SIP P ainsi qu'il sera décrit ultérieurement dans la description. A l'étape W de la figure 4b, l'opération de discrimination de type 20 du terminal appelé est donnée par la relation symbolique : vy=v4 si B@vy E DB1(v4), vy=v6 si B@vy E DB2(v6). L'étape W précitée est alors suivie d'une étape X de transmission du serveur d'enregistrement au serveur proxy SIP du type IP
discriminé pour 25 le terminal appelé B et de l'adresse de communication du noeud SIP appelé pour qualification et routage de la requête d'appel à l'étape Y représentée en figure 4b. A l'étape X de transmission, l'opération de transmission est représentée par un message de service selon la relation : 30 R SM(vy,B@vx) > Enfin, l'opération de routage à l'étape Y est représentée par la relation : 2903263 22 P CR(P@v4, B@vy, A@vx, ALG(SDP)) > B. Le mode opératoire de la transmission d'appel selon le procédé objet de l'invention tel que représenté en figure 4b, peut alors être explicité de la manière ci-après.
5 Lors de l'établissement d'un appel, le procédé objet de l'invention permet à tout serveur proxy SIP de déterminer, simplement dans le contexte de l'appel, notamment le type IP du noeud SIP appelant respectivement appelé afin d'optimiser les choix de routage et notamment le recours aux fonctions d'adaptation précitées.
10 A l'étape U, le serveur proxy SIP détermine le type IP du noeud SIP appelant A. Dans ce but, il s'appuie sur la connaissance des adresses utilisées par les noeuds SIP pour le contacter. En effet, par configuration, tous les noeuds SIP de type IPv4 contactent le serveur proxy SIP P sur son adresse d'origine exclusivement.
15 Par ailleurs, les noeuds SIP de type IP distincts, soit de type IPv6 dans l'exemple donné, contactent le serveur proxy précité sur son adresse de communication P2@v6. Cette dernière adresse correspond ainsi que décrit précédemment à l'adresse auxiliaire P2@v4 du serveur proxy P considéré puisqu'une correspondance est assurée entre ces deux adresses par le 20 service mis en oeuvre par ailleurs par l'opérateur du réseau IP. Le serveur proxy SIP P considéré reçoit donc toute requête émise par un noeud SIP de type distinct du type IP de ce serveur SIP exclusivement sur son adresse auxiliaire. Le serveur proxy SIP P peut donc déduire qu'un noeud SIP est de type double pile lorsque ce noeud SIP a été 25 référencé dans chacune des bases de données d'enregistrement précédemment décrites. De plus, tout noeud SIP double pile utilise l'attribut ANAT pour renseigner ces deux adresses. A l'étape W, le serveur d'enregistrement R détermine le type IP 30 du noeud SIP appelé P. Lors d'un traitement classique d'un appel SIP, le serveur proxy intermédiaire contacte le serveur d'enregistrement pour que ce dernier 2903263 23 fournisse l'adresse avec laquelle le noeud SIP appelé B s'est au préalable enregistré. Le serveur d'enregistrement R retourne au serveur proxy SIP P l'adresse requise après avoir consulté sa base d'enregistrement. Au contraire, le procédé objet de l'invention introduit un élément 5 supplémentaire dans ces échanges. En effet, le serveur proxy SIP P requiert en plus le type IP du noeud SIP appelé à l'étape V. Pour répondre, le serveur d'enregistrement R s'appuie sur ses bases de données d'enregistrement, puisque le type IP de la référence du noeud SIP enregistré est le critère d'enregistrement dans la base de données d'enregistrement en laquelle, ce 1 o dernier a été enregistré. Lorsque cette information a été déterminée, le serveur d'enregistrement R transmet cette dernière à l'étape X, typiquement en même temps que la fourniture de l'adresse du noeud SIP appelé B. Lorsque cette opération a été exécutée, c'est-à-dire après l'étape 15 W de la figure 4b, le serveur proxy SIP P dispose donc des éléments nécessaires pour qualifier l'appel, ce qui à l'étape Y permet à ce dernier de router l'appel de façon optimale. En particulier, pour un noeud SIP appelant et un noeud SIP appelé de type IP distinct, le serveur proxy SIP route l'appel par 20 l'intermédiaire de fonctions d'adaptation ALG permettant de modifier le contenu du champ SDP de la requête d'appel et d'y intégrer des informations destinées au noeud SIP appelé. Ainsi, en référence aux figures 4a et 4b, lorsque le serveur S est un serveur proxy P et lorsque l'appel du serveur proxy P par le noeud A met 25 en oeuvre une transmission T au serveur proxy d'une requête d'appel CR(P@v4, B@vy) du noeud appelant A vers le noeud appelé B, le procédé de communication objet de l'invention peut comprendre en outre au moins l'étape V de transmission, du serveur proxy P vers le serveur d'enregistrement R, d'une requête de type IP du noeud appelé B selon la 3o relation : P TYPR(B@vy) > R suite à l'étape U de discrimination du type IP du noeud appelé par le serveur 2903263 24 d'enregistrement R, puis l'étape X de transmission, du serveur d'enregistrement R vers le serveur proxy P, du type IP, vy, du noeud appelé B, enregistré dans la base de données et d'une adresse B@vy du noeud appelé. L'étape X est suivie de l'étape de routage Y de l'appel du noeud 5 appelant A vers le noeud appelé B, en fonction du type IP, vx, du noeud appelant discriminé par le serveur proxy P à l'étape U et du type IP, vy, du noeud appelé B transmis par le serveur d'enregistrement R à l'étape X. En variante, ainsi que représenté en figure 4c, les étapes U et V de la figure 4b sont remplacées par une étape U' de transmission par le 1 o proxy P d'une requête de type du noeud appelant A et du noeud appelé B notée : P TYPR(A@vx, B@vy) > R. Les étapes U et V de la figure 4b sont supprimées. L'étape U' est suivie d'une W' de discrimination des types IP, vx, vy du terminal appelant 15 A@vx et du terminal appelé B@vy par le serveur d'enregistrement R selon la relation : vx/y = v4 si A/B@vx/y E DB1(v4) vx/y = v6 si A/B@vx/y e DB2(v6). L'étape W' est suivie d'une étape X' de transmission du serveur 20 d'enregistrement R au serveur proxy P d'un message de service comportant les types IP respectifs vx, vy du terminal appelant A et du terminal appelé B, accompagnés de l'adresse de communication du terminal appelé B@vx selon la relation : R SM (vx,vy ,B @ vx ) > P 25 L'étape X' est suivie de l'étape Y de routage décrite en liaison avec la figure 4b. Dans la variante de mise en oeuvre de la figure 4c, le type du noeud appelant A et du noeud appelé B est déterminé par le serveur d'enregistrement R, sur requête du proxy P. Une représentation des différents cas de transmission d'appel est 30 maintenant décrite en liaison avec les figures 5a à 5c. Fiqure 5a : cas où les noeuds SIP appelant et appelé sont de même type IP, ou l'un des deux est de type double pile.
2903263 25 Dans cette situation, le serveur proxy SIP P n'a pas recours aux fonctions d'adaptation ALG, puisque les informations contenues dans le champ SDP de la requête d'appel vont être pertinentes pour les deux noeuds SIP considérés appelant et appelé.
5 La figure 5a illustre le cas de l'appel entre deux noeuds SIP de même type IPv4 entre le noeud SIP A et l'agent utilisateur UA de même type d'un noeud SIP C. Les messages SIP successifs sont les suivants : 1) transmission de la requête d'appel du noeud SIP A au serveur proxy lo SIP P ; 2) transmission d'un message de service entre le serveur proxy SIP P et le serveur d'enregistrement R pour interrogation des types selon les étapes U et V ; 3) transmission d'un message de service entre le serveur 15 d'enregistrement R et le serveur proxy SIP P selon l'étape W ; - 4) transmission d'un message INVITE par le serveur proxy SIP vers l'agent utilisateur UA du noeud SIP C, puis échange des flux RTP. Fiqure 513 : transmission d'un appel entre noeuds SIP de même type IPv6.
20 Dans cette situation, la mise en oeuvre des fonctions d'adaptation ALG n'est également pas requise. En effet, les informations IPv6 contenues dans le champ SDP des messages SIP sont pertinentes pour les deux noeuds SIP qui sont de même type SIP IPv6. Ne pas router l'appel vers des fonctions d'adaptation mettant 25 typiquement en oeuvre une application ALG permet en outre de maintenir l'établissement des flux RTP au sein de l'environnement IPv6, sans passer par un noeud intermédiaire. Toutefois, les éléments de service et en particulier ceux représentés au noeud intermédiaire IN, sont en principe situés en environnement IP IPv4. En conséquence, la signalisation de l'appel 30 traverse une simple fonction relais du point de vue du transport entre l'environnement IPv4 et l'environnement IPv6. L'échange des messages SIP successifs 1 à 4 est représenté au 2903263 26 dessin de la figure 5b. Fiqure 5c : cas d'un appel entre clients hétérogènes de type IP distinct. Dans le cas où les noeuds SIP appelant et appelé A et B 5 représentés en figure 5c sont de type IP distinct, le proxy IP route l'appel vers les fonctions d'adaptation, lesquelles mettent typiquement en oeuvre une application ALG SIP. De telles applications permettent, entre autre, de modifier le contenu du champ SDP des messages pour y intégrer des éléments d'informations pertinents pour le noeud SIP destinataire du 1 o message. L'échange des messages SIP successifs 1 à 4 est également représenté en figure 5c dans cette situation. Le procédé et le protocole utilisés pour les échanges entre serveur proxy SIP et serveur d'enregistrement conformes à l'objet de 15 l'invention, dépendent de l'implémentation. En particulier, de nombreuses implémentations ont la particularité de faire résider le serveur d'enregistrement R et le proxy SIP au sein de la même entité physique, ce qui permet d'alléger la réalisation globale de la fonction supplémentaire de détermination des types IP du terminal appelant et du terminal appelé, 20 conformément à l'objet de la présente invention. Une description plus détaillée d'un serveur SIP d'enregistrement opérant dans un environnement IP de type IP déterminé, en présence d'un autre environnement IP de type IP distinct, conforme à l'objet de l'invention, sera maintenant donnée en liaison avec la figure 6a.
25 De manière classique, un tel serveur comporte des organes d'entrée ù sortie, notés I/O, reliés à une unité centrale de traitement CPU et à une mémoire de travail RAM. Il est remarquable en ce qu'il comporte, en outre, une adresse IP d'origine notée RI@v4 sur la figure 6a et une adresse auxiliaire de type IP 30 correspondant à cet environnement IP et notée R2@v4. Ces deux adresses peuvent avantageusement être mémorisées dans une mémoire programmable par exemple.
2903263 27 En outre, ainsi que représenté en figure 6a, le serveur d'enregistrement objet de l'invention comprend un module Mo de discrimination de type IP de tout noeud SIP candidat à un enregistrement, en fonction de l'adresse d'appel d'origine respectivement de l'adresse de 5 communication correspondant à l'adresse auxiliaire précitée, utilisée par le noeud SIP dans une requête d'enregistrement auprès de ce serveur d'enregistrement. Enfin, ainsi que représenté en outre sur la figure 6a, le serveur SIP d'enregistrement objet de l'invention comprend des ressources de lo première et deuxième bases de données d'enregistrement DB1(v4) et DB2(v6), de chaque noeud SIP candidat à l'enregistrement correspondant à un noeud SIP d'un même type IP que le type IP du serveur proxy dont l'adresse d'appel est l'adresse d'origine de ce dernier RI@v4, respectivement de type IP distinct du type IP du serveur SIP 15 d'enregistrement, dont l'adresse d'appel est l'adresse auxiliaire de ce serveur SIP d'enregistrement, adresse R2@v4, par l'intermédiaire de l'adresse de communication. En outre, et selon une caractéristique remarquable du serveur SIP d'enregistrerent objet de l'invention, on indique que pour tout noeud SIP 20 de type IP double pile, la première base de données d'enregistrement DB1(v4) comprend une référence à l'adresse IP du noeud SIP de type IP correspondant au type IP du serveur proxy de type IP et la deuxième base de données d'enregistrement DB2(v6) comprend une référence à l'adresse IP du noeud SIP de type IP distinct du type IP du serveur proxy de type IP.
25 La figure 6b représente un serveur proxy SIP conforme à l'objet de la présente invention et opérant en transmission d'une requête d'appel d'un noeud SIP appelé par un noeud SIP appelant. Il comporte des organes d'entrée ù sortie I/O reliés à une unité centrale de traitement CPU et à une mémoire de travail RAM.
30 II est en outre remarquable en ce qu'il inclut une adresse IP d'origine Pi@v4 correspondant à l'environnement IP de type IP déterminé, dans lequel est irnplanté le serveur proxy, et une adresse auxiliaire de même 2903263 28 type IP que le type IP de l'adresse d'origine, adresse notée P2@v4. Ces adresses peuvent être mémorisées dans une mémoire programmable. II comprend enfin un module MI de discrimination, à partir de la requête d'appel, du type IP de tout noeud SIP appelant à partir de l'adresse 5 d'appel d'origine respectivement de communication correspondant à l'adresse auxiliaire du serveur proxy SIP, ainsi que décrit précédemment dans la description. Il corporte, en outre, un module M2 de discrimination par interrogation d'un serveur SIP d'enregistrement du type IP du noeud SIP 1 o appelé ainsi que décrit précédemment dans la description. Il comprend enfin un module M3 de transmission et de routage de la requête d'appel compte tenu du type IP et de l'adresse de communication du noeud SIP appelé. En particulier, lorsque le noeud SIP appelant et le noeud SIP 15 appelé sont de type IP distinct, le module M3 précité exécute le routage de la requête d'appel par l'intermédiaire de fonctions d'adaptations permettant de modifier le contenu du champ SDP de la requête d'appel et d'y intégrer des informations destinées au noeud SIP appelé. L'invention couvre égalementun programme d'ordinateur 20 comportant une suite d'instructions mémorisées sur un support de mémorisation et exécutables par un ordinateur ou un dispositif dédié, tel qu'un serveur SIP d'enregistrement. Le serveur SIP d'enregistrement opère l'enregistrement d'un noeud SIP de type IP déterminé dans un environnement IP de même type ou d'un autre type IP.
25 Ce serveur SIP d'enregistrement comporte une adresse d'origine et une adresse auxiliaire de type IP et une adresse auxiliaire de type IP correspondant à l'environnement IP, cette adresse auxiliaire étant allouée ainsi que décrit précédemment dans la description en liaison avec les figures 2a et 2b. II est remarquable en ce que lors de son exécution, ce programme 30 exécute le processus d'enregistrement d'un noeud SIP ainsi que décrit précédemment dans la description en liaison avec les figures 3a et 3b. Ce programme d'ordinateur peut consister en un module logiciel, tel que le 2903263 29 module Mo décril: précédemment en liaison avec la figure 6a. L'invention couvre enfin un programme d'ordinateur comportant une suite d'instructions mémorisées sur un support de mémorisation et exécutables par un ordinateur ou un dispositif dédié, tel qu'un serveur proxy 5 SIP, opérant en transmission d'une requête d'appel d'un noeud SIP appelé par un noeud SIF' appelant de type IP déterminé identique ou distinct. Le serveur proxy SIP comporte une adresse d'origine et une adresse auxiliaire de type IP correspondant à l'environnement IP et allouées conformément au procédé d'adressage tel que décrit précédemment dans la 10 description en liaison avec les figures 2a et 2b. Les noeuds SIP appelant et appelé ont satisfait au processus d'enregistrement de noeuds SIP, tel que décrit précédemment dans la description en liaison avec les figures 3a et 3b. II est remarquable en ce que, lors de son exécution ce programme exécute le procédé de transmission d'appel ainsi que décrit 15 précédemment dans la description en liaison avec la figure 4b. Ce programme peut être mis en oeuvre sous forme de modules logiciels distincts tels que les modules MI à M3 décrits en liaison avec la figure 6b.

Claims (16)

REVENDICATIONS
1. Procédé d'adressage de serveurs pour l'inter-fonctionnement de noeuds d'un premier respectivement d'un deuxième type IP, caractérisé en ce qu'il inclut au moins : l'allocation à tout serveur, opérant dans un environnement IP de l'un ou l'autre type IP et muni d'une adresse d'origine d'un type IP déterminé, lo d'une adresse auxiliaire de même type IP que le type IP de l'adresse d'origine, à ladite adresse auxiliaire correspondant une adresse de communication de type IP distinct de ce type IP déterminé ; la fourniture, comme adresse d'appel, à tout noeud du même type IP que ledit serveur, de ladite adresse d'origine et à tout noeud hétérogène, de 15 type IP autre que le type IP dudit serveur, de ladite adresse de communication ; la traduction de ladite adresse de communication de l'un ou l'autre type IP en ladite adresse auxiliaire, de même type IP que le type IP de l'adresse d'origine. 20
2. Procédé selon la revendication 1, caractérisé en ce que ladite adresse de communication est configurée comme entrée DNS de l'environnement IP de type IP distinct de celui dudit serveur.
3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que lesdits serveurs incluent tout serveur d'enregistrement 25 respectivement tout serveur proxy de l'un ou l'autre des environnements IP.
4. Procédé de communication entre au moins un serveur opérant dans un environnement de type IP déterminé et au moins un noeud d'un réseau, ledit noeud étant de même type IP ou de type IP distinct dudit type IP déterminé, caractérisé en ce qu'il comprend les étapes suivantes : 30 allocation audit serveur d'au moins deux adresses dans ledit environnement de type IP déterminé, comprenant une adresse dite d'origine et une adresse dite auxiliaire, à laquelle est associée par 2903263 31 traduction une adresse de communication dans un environnement de type IP distinct du type IP déterminé ; fourniture audit noeud, comme adresse d'appel dudit serveur : • de ladite adresse d'origine si ledit noeud est de même type IP que 5 ledit type IP déterminé ; • de ladite adresse de communication si ledit noeud est de type IP distinct dudit type IP déterminé ; sur appel dudit serveur par ledit noeud, discrimination du type IP dudit noeud en fonction de l'adresse d'origine ou auxiliaire dudit serveur sur 10 laquelle est reçu ledit appel.
5. Procédé de communication selon la revendication 4, caractérisé en ce que, ledit serveur étant un serveur d'enregistrement, le procédé comprend également une étape d'enregistrement dudit noeud en fonction dudit type IP discriminé dans au moins une base de données. 15
6. Procédé de communication selon la revendication 4, caractérisé en ce que ledit serveur d'enregistrement maintient au moins deux bases de données comprenant respectivement lesdits noeuds de même type IP que ledit type IP déterminé et lesdits noeuds de type IP distinct dudit type IP déterminé. 20
7. Procédé de communication selon l'une quelconque des revendications 5 et 6, caractérisé en ce que ledit noeud présentant au moins deux types IP, à savoir ledit type IP déterminé et au moins un type IP distinct dudit type IP déterminé, ledit procédé comprend : une étape de transmission par ledit noeud d'une requête d'enregistrement 25 vers ladite adresse d'origine dudit serveur d'enregistrement ; une étape de transmission par ledit noeud d'au moins une requête d'enregistrement vers ladite adresse de communication dudit serveur, destinée à être reçue après traduction sur ladite adresse auxiliaire dudit serveur. 30
8. Procédé de communication selon l'une quelconque des revendications 5 à 7, caractérisé en ce que, ledit serveur étant un serveur proxy, et ledit appel dudit serveur proxy par ledit noeud mettant en oeuvre 2903263 32 une transmission audit serveur proxy d'une requête d'appel dudit noeud appelant vers un noeud appelé, le procédé comprend également : une première étape de transmission dudit serveur proxy vers ledit serveur d'enregistrement d'une requête de type IP dudit noeud appelé ; 5 une deuxième étape de transmission dudit serveur d'enregistrement vers ledit serveur proxy du type IP dudit noeud appelé enregistré dans ladite base de données et d'une adresse dudit noeud appelé ; - une étape de routage dudit appel dudit noeud appelant vers ledit noeud appelé, en fonction du type IP dudit noeud appelé transmis par ledit 10 serveur d'enregistrement.
9. Procédé de communication selon la revendication 8, caractérisé en ce que, lors de ladite deuxième étape de transmission, l'adresse dudit noeud appelé transmise par ledit serveur d'enregistrement est une adresse dans ledit environnement de type IP déterminé dans lequel 15 opère ledit serveur proxy.
10. Serveur d'enregistrement opérant dans un environnement de type IP déterminé, dans un réseau comprenant un autre environnement de type IP distinct du type IP déterminé, ledit serveur comportant des organes d'entrée ù sortie reliés à une unité centrale de traitement et à une mémoire 20 de travail, caractérisé en ce qu'il comporte au moins deux adresses dans ledit environnement de type IP déterminé, comprenant une adresse dite d'origine et une adresse dite auxiliaire, à laquelle est associée par traduction une adresse de communication dans ledit environnement de type IP distinct, et. 25 des moyens de discrimination du type IP d'un noeud candidat à un enregistrement, en fonction de l'adresse d'appel d'origine ou auxiliaire dudit serveur sur laquelle est reçue une requête d'enregistrement transmise à ce serveur d'enregistrement par ledit noeud candidat ; des moyens d'enregistrement dudit noeud en fonction dudit type IP 30 discriminé dans au moins une base de données.
11. Serveur d'enregistrement selon la revendication 10, caractérisé en ce qu'il comprend des moyens d'enregistrement dudit noeud 2903263 33 dans au moins une première et une deuxième bases de données comprenant respectivement lesdits noeuds de même type IP que ledit type IP déterminé et lesdits noeuds de type IP distinct dudit type IP déterminé.
12. Serveur d'enregistrement selon la revendication 11, 5 caractérisé en ce que pour un noeud de type IP double pile, ladite première base de données d'enregistrement comprend : une référence à l'adresse IP dudit noeud de type IP correspondant au type IP déterminé dudit serveur d'enregistrement ; et, en ce que ladite deuxième base de données d'enregistrement comprend : une référence à l'adresse IP dudit noeud de type IP distinct du type IP déterminé dudit serveur d'enregistrement.
13.Serveur proxy opérant dans un environnement de type IP déterminé, dans un réseau comprenant un autre environnement de type IP distinct du type IP déterminé, ledit serveur opérant en transmission d'une requête d'appel d'un noeud appelé par un noeud appelant, de types IP identique ou distinct dudit type IP déterminé, et comportant des organes d'entrée ù sortie reliés à une unité centrale de traitement et à une mémoire de travail, caractérisé en ce qu'il comporte au moins deux adresses dans ledit environnement de type IP déterminé, comprenant une adresse dite d'origine et une adresse dite auxiliaire, à laquelle est associée par traduction une adresse de communication dans ledit environnement de type IP distinct et des moyens de discrimination du type IP dudit noeud appelant, en fonction de l'adresse d'appel d'origine ou auxiliaire dudit serveur sur 25 laquelle est reçue ladite requête d'appel ; des moyens de discrimination, par interrogation d'un serveur d'enregistrement selon l'une des revendications 10 à 12, du type IP dudit noeud appelé ; des moyens de transmission et de routage de ladite requête d'appel, 3o compte tenu clu type IP et de l'adresse de communication dudit noeud appelé.
14. Serveur proxy selon la revendication 13, caractérisé en ce 2903263 34 que, pour un nceud appelant et un noeud appelé de type IP distinct, ledit serveur proxy exécute le routage de ladite requête d'appel par l'intermédiaire de fonctions d'adaptation permettant de modifier le contenu du champ SDP de ladite requête d'appel et d'y intégrer des informations destinées audit s noeud appelé.
15. Programme d'ordinateur comportant une suite d'instructions mémorisées sur un support de mémorisation et exécutable par un ordinateur ou un dispositif dédié tel qu'un serveur d'enregistrement, ledit serveur d'enregistrement opérant l'enregistrement d'un noeud de type IP déterminé 10 dans un environnement IP de même type ou d'un autre type IP, ce serveur d'enregistrement comportant une adresse d'origine et une adresse auxiliaire de type IP correspondant à cet environnement IP allouée conformément au procédé selon les revendications 1 à 3, caractérisé en ce que lors de son exécution ledit programme exécute une étape d'enregistrement d'un noeud 15 en fonction du type IP de ce dernier discriminé dans au moins une base de données.
16. Programme d'ordinateur comportant une suite d'instructions mémorisées sur un support de mémorisation et exécutables par un ordinateur ou un dispositif dédié tel qu'un serveur proxy opérant en 20 transmission d'une requête d'appel d'un noeud appelé par un noeud appelant, de type IP déterminé identique ou distinct, dans un environnement IP de type IP déterminé en présence d'un autre environnement IP de type IP distinct, ce serveur proxy comportant une adresse d'origine et une adresse auxiliaire de type IP correspondant à cet environnement IP allouée conformément au procédé d'adressage selon l'une des revendications 1 à 3, ledit noeud appelant et ledit noeud appelé ayant satisfait à un processus d'enregistrement, caractérisé en ce que lors de son exécution ledit programme exécute le procédé de communication entre au moins un serveur opérant dans un environnement de type IP déterminé et au moins un 3o noeud du réseau selon l'une des revendications 4 à 9.
FR0605945A 2006-06-30 2006-06-30 Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes Pending FR2903263A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR0605945A FR2903263A1 (fr) 2006-06-30 2006-06-30 Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes
PCT/FR2007/051531 WO2008001007A2 (fr) 2006-06-30 2007-06-26 Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes
US12/308,889 US20090187664A1 (en) 2006-06-30 2007-06-26 Method for addressing call transmission and service elements between heterogenous nodes
EP07803947A EP2036301A2 (fr) 2006-06-30 2007-06-26 Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0605945A FR2903263A1 (fr) 2006-06-30 2006-06-30 Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes

Publications (1)

Publication Number Publication Date
FR2903263A1 true FR2903263A1 (fr) 2008-01-04

Family

ID=37807951

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0605945A Pending FR2903263A1 (fr) 2006-06-30 2006-06-30 Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes

Country Status (4)

Country Link
US (1) US20090187664A1 (fr)
EP (1) EP2036301A2 (fr)
FR (1) FR2903263A1 (fr)
WO (1) WO2008001007A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5607617B2 (ja) 2008-06-30 2014-10-15 オランジュ IPv6ドメインでデータパケットを受信する方法、ならびに関連するデバイスおよび住居用ゲートウェイ
JP5693065B2 (ja) * 2010-07-06 2015-04-01 キヤノン株式会社 通信端末、通信端末の制御方法及びプログラム
CN114244755B (zh) * 2021-12-15 2023-11-14 北京恒安嘉新安全技术有限公司 一种资产探测方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1515508A2 (fr) * 2003-09-09 2005-03-16 Hitachi, Ltd. Systéme de commande de session, terminal de télécommunication et serveurs
US20060015647A1 (en) * 2004-07-16 2006-01-19 Samsung Electronics Co., Ltd. System and method for communication between heterogeneous networks

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7385989B2 (en) * 1996-07-04 2008-06-10 Hitachi, Ltd. Packet communication method and apparatus and a recording medium storing a packet communication program
US6690669B1 (en) * 1996-11-01 2004-02-10 Hitachi, Ltd. Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus
JP4347497B2 (ja) * 2000-04-03 2009-10-21 株式会社日立製作所 通信制御装置及びパケット変換方法
JP4501230B2 (ja) * 2000-05-30 2010-07-14 株式会社日立製作所 IPv4−IPv6マルチキャスト通信方法および装置
US6862274B1 (en) * 2000-10-26 2005-03-01 Industrial Technology Research Institute Method and system capable of providing mobility support for IPv4/IPv6 inter-networking
JP4075318B2 (ja) * 2001-04-18 2008-04-16 株式会社日立製作所 プロトコル変換方法,及びアドレス変換サーバ
JP3857183B2 (ja) * 2002-05-24 2006-12-13 株式会社日立コミュニケーションテクノロジー アドレス変換機能を備えたパケット転送装置
JP4045936B2 (ja) * 2002-11-26 2008-02-13 株式会社日立製作所 アドレス変換装置
JP4271988B2 (ja) * 2003-05-19 2009-06-03 株式会社日立コミュニケーションテクノロジー パケット通信装置
US7277453B2 (en) * 2003-05-30 2007-10-02 Motorola, Inc. Inter private network communications between IPv4 hosts using IPv6
US7440466B2 (en) * 2003-08-05 2008-10-21 Intel Corporation Method, apparatus and system for accessing multiple nodes on a private network
US7372840B2 (en) * 2003-11-25 2008-05-13 Nokia Corporation Filtering of dynamic flows
KR20050079420A (ko) * 2004-02-05 2005-08-10 삼성전자주식회사 터널링 서비스 방법 및 시스템
JP2006087039A (ja) * 2004-09-17 2006-03-30 Fujitsu Ltd モバイルip通信端末装置およびモバイルip通信方法
US7599289B2 (en) * 2005-05-13 2009-10-06 Lockheed Martin Corporation Electronic communication control
JP4639152B2 (ja) * 2006-01-20 2011-02-23 株式会社日立製作所 通信システム
KR100817552B1 (ko) * 2006-09-29 2008-03-27 한국전자통신연구원 맵핑 테이블을 이용한 IPv4/IPv6 단말 또는 응용프로그램간 프로토콜 변환 장치 및 방법과, 프로토콜 변환장치의 맵핑 테이블 생성 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1515508A2 (fr) * 2003-09-09 2005-03-16 Hitachi, Ltd. Systéme de commande de session, terminal de télécommunication et serveurs
US20060015647A1 (en) * 2004-07-16 2006-01-19 Samsung Electronics Co., Ltd. System and method for communication between heterogeneous networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KAWARASAKI Y ET AL: "IPv4/IPv6 SIP interworking methods in dual-stack network", COMMUNICATIONS, 2003. APCC 2003. THE 9TH ASIA-PACIFIC CONFERENCE ON 21-24 SEPT. 2003, PISCATAWAY, NJ, USA,IEEE, vol. 3, 21 September 2003 (2003-09-21), pages 1124 - 1128, XP010687978, ISBN: 0-7803-8114-9 *

Also Published As

Publication number Publication date
WO2008001007A2 (fr) 2008-01-03
US20090187664A1 (en) 2009-07-23
EP2036301A2 (fr) 2009-03-18
WO2008001007A3 (fr) 2008-03-13

Similar Documents

Publication Publication Date Title
EP1994724B1 (fr) Procede et systeme de caracterisation de noeuds de communication heterogenes
EP3745674B1 (fr) Procédé et système de transmission de données entre noeuds attachés à des environnements ip distincts par affectation d'adresses fictives
EP2297928B1 (fr) Procede de reception d'un paquet de donnees dans un domaine ipv6, dispositif et passerelle residentielle associes
EP2297927B1 (fr) Procede de reception d'un paquet de donnees en provenance d'un domaine ipv4 dans un domaine ipv6, dispositif et equipement d'acces associes
FR2853187A1 (fr) Systeme permettant a toute application reseau de fonctionner de facon transparente a travers un dispositif de traduction d'adresse de reseau
EP3987752A1 (fr) Procede et dispositif d'obtention d'une adresse ip
EP2294798B1 (fr) Procede de routage d'un paquet de donnees dans un reseau et dispositif associe
EP1950926B1 (fr) Architecture IMS utilisant une table de hachage distribuée
FR2903263A1 (fr) Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes
FR3029379A1 (fr) Procede de communication entre un terminal equipe d' un client webrtc et un terminal accessible via un coeur de reseau ims
EP3373558B1 (fr) Procédé de communication pour assurer le maintien d'une session applicative entre un terminal et un serveur d'application
FR3059504A1 (fr) Procede de fractionnement de messages applicatifs dans un reseau ip
EP3235217B1 (fr) Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants
WO2010072953A1 (fr) SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4
EP1998514B1 (fr) Traitement de paquets en vue de communiquer avec une machine à travers un ou plusieurs réseaux secondaires
FR2903841A1 (fr) Enregistrement de communications dans un reseau de telecommunications
WO2022084606A1 (fr) Procédé et dispositif de médiation d'un ensemble d'applications
FR3115644A1 (fr) Procédé et dispositif d’aiguillage d’une donnée applicative
FR2836318A1 (fr) Systeme de transmission de contenus mutimedias apte a accorder les contenus au cours de leur transmission
FR2865595A1 (fr) Procede de filtrage de paquets de flux media ip echanges dans un reseau de telecommunication
WO2008065294A1 (fr) Procede de transmission d'informations fonctionnelles, equipement de terminaison, signaux et produit programme d'ordinateur correspondants
FR3018411A1 (fr) Procede et systeme de traitement d'une requete dns emise par un noeud reseau au cours d'une tentative dacces par une application cliente a un serveur distant sur un reseau ip
FR3019703A1 (fr) Dispositif et procede d'adressage d'equipements embarques a bord d'un vehicule
FR2887724A1 (fr) Dispositif de gestion de connexion(s) client(s)/serveur(s), en presence de conditions hostiles dans des reseaux ip interconnectes