EP2036301A2 - 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

Info

Publication number
EP2036301A2
EP2036301A2 EP07803947A EP07803947A EP2036301A2 EP 2036301 A2 EP2036301 A2 EP 2036301A2 EP 07803947 A EP07803947 A EP 07803947A EP 07803947 A EP07803947 A EP 07803947A EP 2036301 A2 EP2036301 A2 EP 2036301A2
Authority
EP
European Patent Office
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.)
Withdrawn
Application number
EP07803947A
Other languages
German (de)
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
Publication of EP2036301A2 publication Critical patent/EP2036301A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

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

Definitions

  • the invention lies in the field of telecommunications, and more particularly in the field of IP telephony.
  • IP communication protocol abbreviation well known to those skilled in the art of the English term "Internet Protocol”
  • IP protocol played a unifying role with multiple operators who chose this protocol to pool previously disparate service offerings.
  • RTP session parameters are pre-negotiated via SIP signaling messages, especially in the SDP part. These parameters are mainly termination addresses and port numbers that will be used on both sides.
  • the proxy server PS can nevertheless join the location address of the first user agent A and that of the second user agent B, another SIP message exchange is observed, when the second user agent B tries to call the first user agent A, as shown in FIG. 1b.
  • the concerned SIP telephony service operator may have recourse to ALG applications (abbreviation well known to the man of the English-language "Application Layer Gateway”), to modify the SDP offers to ensure coherence between the type of address supported and that contained in the received SIP messages.
  • ALG applications abbreviation well known to the man of the English-language "Application Layer Gateway”
  • SIP servers use transport-layer-related, non-SIP-specific information to route calls or to determine the use of ALG applications to alter the content of SDP offers. Such behavior of SIP servers is not described in the standard.
  • IP telephony commonly referred to as VoIP for Voice over] P_ in English, or generally grouped under the topic of conversational services.
  • the invention is part of the general problem of transmission services based on the SIP protocol defined by RFC 3261 and deployed for both IPv4 clients and IPv6 clients. These services may be voice, video, presence, etc.
  • Another object of the present invention is furthermore the implementation of a method of addressing SIP servers for the interworking of heterogeneous SIP nodes making it possible to simplify and thus facilitate the routing of calls.
  • Another object of the present invention is, finally, the implementation of implementation of a method of addressing SIP servers to optimize the use of IP addresses.
  • the method of addressing SIP servers for the interworking of heterogeneous SIP nodes of a first respectively of a second IP type, object of the invention is remarkable in that it includes at least the allocation to any SIP server, operating in an IP environment of either type IP and provided with an IP address of origin of an IP type, an auxiliary address of the same IP type as the type of IP original address and corresponding to a distinct IP type communication address, the provision as a call address, to any SIP node of the same IP type as that SIP server of that originating address in that IP environment and to any node SIP, of IP type other than the IP type of this SIP server, of this communication address, the translation of this communication address of one or the other IP type into this auxiliary address of the same IP type as the IP type from this original address.
  • the addressing method that is the subject of the invention is finally remarkable in that the SIP servers include any recording server or any proxy server of one or the other of the IP environments.
  • This communication method is remarkable in that it comprises the following steps, allocation to the server of at least two addresses in the determined IP type environment, comprising a so-called origin address and a so-called auxiliary address, to which is associated by translation a communication address in an environment of IP type distinct from the determined IP type, supplying to this node, as the server call address of this original address, if the node is of the same IP type as the determined IP type, respectively of this communication address, if the node is of IP type distinct from the determined IP type, and, on call of this server by this node, the discrimination of the IP type of this node as a function of the original or auxiliary address of the server on which this call is received. .
  • the communication method which is the subject of the invention, is furthermore remarkable in that, since the server is a recording server, this method also comprises a step of recording the node as a function of the IP type discriminated in at least one base. of data.
  • the communication method which is the subject of the invention, is also remarkable in that the node having at least two IP types, namely the determined IP type and at least one IP type distinct from this determined IP type, this method comprises a step transmission by this node of a registration request to the original address of the registration server, and a step of transmission by this node of at least one registration request to the communication address of the server , intended to be received after translation on the auxiliary address of the server.
  • the communication method that is the subject of the invention is also remarkable in that the server is a proxy server and the proxy server is called by the node implementing a transmission to the server.
  • this method also comprises a first step of transmitting the proxy server to the registration server of an IP request of the called node, a second transmission step from the registration server to the proxy server of the IP type of the called node registered in the database and from an address of the called node and a step of routing this call from the calling node to the called node, depending on the IP type the calling node discriminated by the proxy server and the IP type of the called node transmitted by the registration server.
  • the method which is the subject of the invention is finally remarkable in that during the second transmission step, the address of the called node transmitted by the registration server is an address in the determined IP environment in which the server operates. proxy.
  • the invention also covers a recording SIP server operating in a determined IP-type IP environment in the presence of another distinct IP-type IP environment and having input-output members connected to a central processing unit and a working memory, remarkable in that it comprises, in addition to an original IP address, an IP-type auxiliary IP address corresponding to this IP environment, IP-type discrimination means of any SIP node operating a recording as a function of the original call or communication address corresponding to this auxiliary address used by this SIP node, in a registration request transmitted to this registration SIP server, means of first and second database of recording of each candidate SIP node, corresponding to a node SIP of the same IP type as the IP type of this recording SIP server, whose calling address is the IP address of the latter, respectively IP type distinct from the IP type of this SIP recording server , whose calling address is the auxiliary address of this registration SIP server via this communication address.
  • FIG. 2a represents, for purely illustrative purposes, a flowchart of the essential steps the SIP server addressing method, object of the present invention
  • FIG. 3b represents, by way of illustration, a specific flowchart for implementing the registration process illustrated in FIG. 3a, in the case where the SIP node is a SIP node of the double-stack IP type;
  • FIG. 4a represents, by way of illustration, a flowchart of the essential steps of a method of transmitting a call between a calling SIP node and a SIP node called via a SIP proxy by means of the addressing method and the registration process object of the present invention
  • FIG. 4b represents, by way of illustration, a flowchart of the essential steps of a communication method according to the subject of the present invention, between a server operating in a specific IP type environment and at least one node of a network
  • FIG. 4c represents by way of illustration an alternative implementation of the communication method illustrated in FIG. 4b, in which the IP type of the calling node and the called node is established by a recording server on request of a proxy server
  • FIGS. 5a to 5c represent, by way of illustration, a call transmission protocol between SIP node of the same IP type, IPv4 FIG. 5a, IPv6 FIG. 5b and of distinct IP type, IPv4-IPv6 FIG. 5c;
  • step A of FIG. 2a the R 2 @ v4 auxiliary address is allocated to the recording server R and the auxiliary address P 2 @ v 4 is allocated to the SIP proxy server P.
  • the auxiliary address is associated an IP type communication address different from the type of the auxiliary address.
  • Step B is then followed by a step B of providing to each SIP node, of the same IP type as the SIP server, the original address of each SIP server in the corresponding IP environment, and to any node
  • IP type SIP other than the IP type of the SIP proxy server, a communication address corresponding to the auxiliary address allocated to each SIP server.
  • step B of FIG. 2a after the provision of the abovementioned addresses, the SIP nodes A and B are placed in communication:
  • a node or terminal A of one of the IPv4 or IPv6 types is considered, to this terminal A being thus allocated an A @ vx address, where x denotes either the IPv4 type or the IPv6 type or else the double-stack type as described previously in the description.
  • the method that is the subject of the invention consists, at least, in transmitting a registration request denoted RR (R @ vx), of discriminating the IP type of the SIP node A, as a function of the respectively original or auxiliary call address corresponding to the communication address initially used by the SIP node A to transmit the registration request.
  • the aforementioned communication address corresponds, of course, to the auxiliary address R 2 @ v4 allocated to the recording server R as mentioned previously in the description.
  • the transmission operation is noted by the symbolic relation:
  • step L of the IP type of node A 1 as a function of the original address Si @ v4 or auxiliary S 2 @ v4 of the server on which this call was received.
  • the test step L is represented by the relation:
  • the calling SIP node such as node A
  • the SIP node called B is a node.
  • SIP IP type also determined, identical or distinct from the type of the calling SIP node.
  • the address of the called SIP node is noted as B @ vy.
  • step U the discrimination can be directly performed by the SIP proxy server P based on the call in the call request, or the original address of the proxy server SIP, in which case the calling SIP node A corresponds to a node of IP type identical to that of the SIP proxy P, or conversely, to a SIP node of IP type distinct from that of the SIP proxy server P, when the address of call of the latter corresponds, after translation, to the auxiliary address P 2 @ v4.
  • step W is then followed by a step X of transmission of the registration server to the SIP proxy server of the IP type discriminated for the called terminal B and the communication address of the SIP node called for qualification and routing of the call request in step Y shown in FIG. 4b.
  • the transmission operation is represented by a service message according to the relationship: R ⁇ * & ">> p.
  • step Y the routing operation in step Y is represented by the relation: CR (P @ v4, B @ vy, A @ vx, ALG (SDP)) v _ PT o.
  • the SIP proxy server P can therefore deduce that a SIP node is of dual-stack type when this SIP node has been referenced in each of the recording databases previously described.
  • any dual stack SIP node uses the attribute "ANAT" to populate these two addresses.
  • the intermediate proxy server contacts the registration server so that the latter provide the address with which the called SIP node B has previously registered.
  • the registration server R returns to the SIP proxy server P the required address after consulting its registration database.
  • the method which is the subject of the invention introduces an additional element into these exchanges.
  • the SIP proxy server P additionally requires the IP type of the SIP node called in step V.
  • the registration server R relies on its registration databases, since the type IP of the reference of the registered SIP node is the criterion of registration in the registration database in which the latter has been registered.
  • the SIP proxy server P When this operation has been executed, that is to say after step W of FIG. 4b, the SIP proxy server P therefore has the necessary elements to qualify the call, which in step Y allows this last to route the call optimally.
  • the communication method that is the subject of the invention can furthermore comprise at least the transmission step V, from the proxy server P to the server d R record, of a request of type IP of the node called B according to the relation: TYPR (B @ vy) >
  • Step U discrimination of the IP type of the node called by the server recording R
  • the transmission step X from the recording server R to the proxy server P 1 of the type IP, vy, the called node B, registered in the database and a B @ vy address of the called node.
  • Step X is followed by the routing step Y of the call from the calling node A to the called node B, depending on the type IP, vx, of the calling node discriminated by the proxy server P in step U and of the type IP, vy, of the called node B transmitted by the recording server R in step X.
  • the steps U and V of FIG. 4b are replaced by a step U 'of transmission by the proxy P of a request of type of the calling node A and the called node B noted: TYPR (A @ vx, B @ yy) ) R
  • Step W is followed by a step X 'of transmission from the recording server R to the proxy server P of a service message comprising the respective IP types vx, vy of the calling terminal A and the called terminal B, accompanied by the communication address of the terminal called B @ vx according to the relation: p SM (v ⁇ , vy, B @ vx). _
  • Step X ' is followed by the routing step Y described in connection with FIG. 4b.
  • the type of the calling node A and the called node B is determined by the registration server R, on the request of the proxy P.
  • Not routing the call to adaptation functions typically implementing an ALG application also makes it possible to maintain the establishment of RTP streams within the IPv6 environment, without passing through an intermediate node.
  • the service elements and in particular those represented at the intermediate node IN are in principle located in an IPv4 IP environment. As a result, the signaling of the call goes through a simple relay function from a transport point of view between the IPv4 environment and the IPv6 environment.
  • the IP proxy routes the call to the adaptation functions, which typically implement an ALG SIP application.
  • ALG SIP application make it possible, among other things, to modify the content of the message SDP field to include information elements relevant to the SIP node receiving the message.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (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 noeds SIP (A, B) d'un type IP déterminé dans lequel on alloue (A) à tout serveur SIP (P, R) une adresse auxiliaire (R<SUB>2</SUB>@v4, P<SUB>2</SUB>@v4) de même type IP que leur adresse d'origine (R<SUB>1</SUB>@v4, P<SUB>1</SUB>@v4), l'adresse auxiliaire correspondant à une adresse de communication de type IP distinct, on fournit (B) à tout noed SIP du même type IP que ce serveur SIP l'adresse d'origine et à tout noed 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

PROCÉDÉ D'ADRESSAGE DES ELEMENTS DE SERVICE ET DE TRANSMISSION D'APPEL ENTRE NŒUDS HÉTÉROGÈNES
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 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. 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 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 interopérabilité et un interfonctionnement du protocole IPv6 et du protocole
!Pv4 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 à I1IETF (abréviation bien connue de l'homme du métier de l'expression anglaise "Internet Engineering Task Force") tels qu'une 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 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, PIETF 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 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 1a, 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 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 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 entre les premier et deuxième agents utilisateurs A et B. Ce message d'erreur est noté (2) 404 « No Route » sur la figure 1a,
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 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 1 b.
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 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 1b, cette adresse est de type IPv6. Ainsi, lorsque l'agent utilisateur A reçoit ce message « 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 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 1a et 1b, les sessions SIP ne peuvent ainsi pas être établies.
Une coexistence d'adresses IP de types différents pourra affecter 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 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 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 IPvδ. Grâce à cette technique, tous les appels de/vers un agent utilisateur de type DS vers des/de clients mono version (i.e. 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 nœuds 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 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 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. 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 une partie du problème, il n'existe en particulier pas de document de I1IETF 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 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 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 à 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 expliquant pourquoi la plupart des techniques de gestion de communications entre nœuds 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 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. 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 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 ]P_ en anglais, ou généralement groupée sous le thème des services conversationnels. 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 rétablissement de sessions SIP entre deux clients ou nœuds SIP hétérogènes, un attaché à un domaine IPv4 et l'autre à un domaine !Pv6 par exemple.
La présente invention a, notamment, en conséquence pour objet la mise en œuvre d'un procédé d'adressage de serveurs SIP pour l'inter- fonctionnement de nœuds 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 œuvre par l'intermédiaire de la ou des interfaces réseaux dont dispose le nœud SIP qui l'abrite. Des nœuds SIP hétérogènes sont donc des nœuds 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 œuvre d'un procédé d'adressage de serveurs SIP pour l'inter- fonctionnement de nœuds 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 œuvre 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 nœuds SIP hétérogènes d'un premier respectivement 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 type IP distinct, la fourniture comme adresse d'appel, à tout nœud SIP du même type IP que ce serveur SIP de cette adresse d'origine dans cet environnement IP et à tout nœud 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 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 nœud SIP à partir d'un environnement IP d'un type IP correspondant à celui des serveurs SIP ou d'un type IP distinct. 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 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 déterminé et au moins un nœud du réseau, ce nœud é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 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 type IP distinct du type IP déterminé, la fourniture à ce nœud, comme adresse d'appel du serveur de cette adresse d'origine, si le nœud est de même type IP que le type IP déterminé, respectivement de cette adresse de communication, si le nœud est de type IP distinct du type IP déterminé, et, sur appel de ce serveur par ce nœud, la discrimination du type IP de ce nœud 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 nœud en 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 nœuds de même type IP que le type IP déterminé et les nœuds de type IP distincts du type IP déterminé. Les 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 nœud 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é, ce procédé comprend une étape de transmission par ce nœud d'une requête d'enregistrement vers l'adresse d'origine du serveur d'enregistrement, et une étape de transmission par ce nœud 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. 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 nœud mettant en œuvre une transmission au serveur proxy d'une requête d'appel du nœud appelant vers un nœud 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 nœud appelé, une deuxième étape de transmission du serveur d'enregistrement vers le serveur proxy du type IP du nœud appelé enregistré dans la base de données et d'une adresse du nœud appelé et une étape de routage de cet appel du nœud appelant vers le nœud appelé, en fonction du type IP du nœud appelant discriminé par le serveur proxy et du type IP du nœud appelé transmis par le serveur d'enregistrement. Le procédé objet de l'invention est enfin remarquable en ce que lors de la deuxième étape de transmission, l'adresse du nœud 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 remarquable en ce que au cours de l'exécution de l'étape d'enregistrement,, pour tout nœud SIP de type IP déterminé, l'adresse IP enregistrée pour ledit nœud 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 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 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 nœud 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 nœud 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 nœud SIP candidat, correspondant à un nœud 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 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 nœud SIP appelé par un nœud 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 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.
Il 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 moyens de discrimination, à partir de la requête d'appel du type IP de tout nœud 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 nœud SIP appelé, et des moyens de transmission et de routage de cette requête d'appel, compte tenu du type IP du nœud SIP appelé.
Ils seront mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels, outre les figures 1a et 1b relatives à l'art antérieur : - 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 environnement IP de type IP distinct, IPv6, interconnectés par un nœud intermédiaire ;
- la figure 3a représente, à titre illustratif, un organigramme des étapes essentielles d'un processus d'enregistrement de nœud SIP auprès d'un serveur d'enregistrement SIP, grâce à la mise en œuvre 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 mise en œuvre du processus d'enregistrement illustré en figure 3a, dans le cas où le nœud SIP est un nœud 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 nœud SIP appelant et un nœud SIP appelé par l'intermédiaire d'un proxy SIP grâce 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 type IP déterminé et au moins un nœud d'un réseau ; la figure 4c représente à titre illustratif une variante de mise en œuvre du procédé de communication illustré en figure 4b, dans lequel le type IP du nœud appelant et du nœud appelé est établi par un serveur d'enregistrement sur requête d'un serveur proxy ; - les figures 5a à 5c représentent, à titre illustratif, un protocole de transmission d'appel entre nœud 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 ; - 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 nœuds SIP d'un premier respectivement d'un deuxième type IP sera maintenant donnée en liaison avec la figure 2a 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 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 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 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 nœud intermédiaire IN représenté en figure 2b pour « jntermediate Node » en anglais situé à la frontière des environnements !Pv4 et !Pv6. Ce nœud 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 fonctions / traitements / opérations exécutés par le nœud 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 R!@v4, d'un serveur proxy SIP P d'adresse d'origine Pi@v4, d'un nœud SIP A d'adresse A@v4 dans l'environnement IPv4 et d'un nœud 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 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. 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. L'étape A est alors suivie d'une étape B consistant à fournir à tout nœud 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 nœud
SIP.de type IP autre que le type IP du serveur proxy SIP, une adresse de communication correspondant à l'adresse auxiliaire allouée à chaque 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 nœuds SIP A et B :
Nœud SIP A : - A@v4, adresse du nœud 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 ; Nœud SIP B :
- B@v6, adresse du nœud 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 é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 : P2@v6 *» P2@v4
R2@v6 «-* R2@v4. On comprend ainsi que, grâce au processus d'allocation d'adresses auxiliaires et en fait de double adressage de chaque serveur SIP mis en jeu, l'intercommunication entre tout nœud 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 R-ι@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.
Il en est de même en ce qui concerne les adresses de communication R2@v6 et P2@v6 lesquelles peuvent être configurées 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. Un processus d'enregistrement d'un nœud SlP 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 nœud SIP précité peut être constitué par un nœud 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 nœud 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 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 nœud ou terminal A 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. 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 nœud SIP A, en fonction de l'adresse d'appel d'origine respectivement auxiliaire correspondant à l'adresse de communication utilisée initialement par le nœud SIP A pour transmettre Ia 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 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. A l'étape D de la figure 3a, l'opération de transmission est notée par la relation symbolique :
A RR(Ji @ vx) y R
L'étape D est alors suivie d'une étape E consistant à discriminer le type IP du nœud SIP A en fonction de l'adresse d'appel d'origine respectivement de communication correspondant à l'adresse auxiliaire utilisée par le nœud 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=v6 si R@vx≡R2@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 nœud intermédiaire IN.
En effet, on comprend que lorsque l'adresse d'appel est une adresse de communication, celle-ci est transformée en adresse auxiliaire ce qui permet bien entendu de discriminer le type IP du nœud SIP à l'enregistrement. 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 DBi(v4) et une deuxième DE$2(v6) bases de données de l'enregistrement de chaque nœud SIP.
On comprend en effet, que suite à la discrimination réalisée à l'étape E1 chaque nœud SIP correspond à un nœud 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 dernier.
Au contraire, un nœud 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. 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 nœud 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 DBi(v4), et A@vx=A'@v4, l'adresse A@v6 ayant été traduite en cours de route en cette adresse A'@v4, lorsque l'adresse du nœud SIP correspondant, correspond à un nœud 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 objet de l'invention est mis en œuvre en raison du fait que tous les nœuds
SIP de type IPv4, par configuration, contactent le serveur d'enregistrement R sur son adresse d'origine exclusivement, alors que tous les nœuds SIP de type IPv6 prennent contact avec le serveur d'enregistrement R uniquement par l'adresse de communication R2@v6, laquelle est bien entendu 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. Dans le cas d'un terminal SIP double pile AQS, 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. 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 nœud 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 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 :
A /tt, ((Λ® v*), ΛΛ. (Λ @ vy)) ) R
Dans la relation précédente, on comprend que RRi(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. 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 nœud SIP à partir de chacune des deux requêtes d'enregistrement émises précitée. A l'étape E1 présentée en figure 3b, la discrimination des types vx et vy, est représentée par la relation symbolique : vy=v6 si R@vy^2@v4. De même que dans le cas de la figure 3a, le signe Ξ représente l'identité des adresses après traduction, par le nœud 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 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 d'enregistrement DBi(v4) et DB2(v6) pour le nœud SIP de type double pile, à partir des deux types IP discriminés.
On comprend ainsi que, par la mise en œuvre du processus d'enregistrement selon l'invention représentée en figure 3b et pour un nœud SIP double pile, ce dernier est alors présent dans les deux bases de données d'enregistrement.
En outre, on indique que tout nœud 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 nœud SIP de type IPv6 dans son environnement IP d'origine. La requête d'enregistrement d'un nœud SIP de type IPv6 arrive donc sur l'adresse auxiliaire F?2@v4 du serveur d'enregistrement R et l'adresse !Pv4 représentant le nœud SIP de type !Pv6 dans l'environnement IPv4 est alors disponible pour l'opération d'enregistrement puisque fournie par les fonctions d'adaptation mises en œuvre par ailleurs par l'opérateur du réseau IPv4. 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 opérant dans un environnement de type IP déterminé, pris à titre d'exemple non limitatif comme le type IPv4, et au moins un nœud A du réseau, ce nœud A pouvant être de même type IP, IPv4, ou de type IP distinct, IPvβ, que le type IP déterminé, IPv4, du serveur S sera maintenant décrit en liaison avec la figure 4a. 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 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 nœud A, comme adresse d'appel du serveur S, soit l'adresse d'origine, Si@v4, si le nœud A est du même type IP déterminé, IPv4, soit l'adresse de communication, S2@v6, si le nœud 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 un0 nœud 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 nœud A, par la comparaison :
Vx = V4 ?
Sur réponse positive au test H, on fournit à l'étape I l'adresse5 d'origine Si@v4 comme adresse d'appel du serveur S au nœud A, selon la relation :
A <- S-ι@v4 A@vx
Sinon, sur réponse négative au test H, on fournit à l'étape J o l'adresse de communication, S2@v6, distinct du type IP déterminé, IPv4.
Sur appel à l'étape K du serveur S par le nœud A, par transmission d'une requête d'appel représentée par la relation
A Cφ> @v4) ) S, où CR(Sy@v4) désigne la requête d'appel, Sy@v4 désigne soit l'adresse 5 d'origine S-ι@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 nœud A1 en fonction de l'adresse d'origine Si@v4 ou auxiliaire S2@v4 du serveur sur laquelle ce appel a été reçu. o 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 nœud A est discriminé, à l'étape M, comme appartenant au type IP déterminé IPv4, A | A@vx = A@v4. Sinon, sur réponse négative au test L, le nœud A est discriminé à l'étape N comme appartenant au type IP distinct, IPv6, du type IP déterminé A | A@vx = A'@v4 qui est la traduction de A@v6 par IN, car Sy@v4 = S2@v4 lorsque 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 d'appel d'un nœud SIP appelé par un nœud 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 nœud SIP appelant, tel que le nœud A, est d'un type IP déterminé, l'adresse de ce nœud étant désignée A@vx et le nœud SIP appelé B est un nœud SIP de type IP également déterminé, identique ou distinct du type du nœud SIP appelant. L'adresse du nœud 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 nœud SIP appelant. 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. En outre, on considère que le nœud SIP appelant A et le nœud
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. 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 nœud SIP appelant au serveur proxy SIP, cette requête d'appel étant notée :
CR(P@v4, B@vy), la discrimination, au niveau du serveur proxy SIP, du type du nœud SIP appelant à partir de l'adresse d'appel d'origine respectivement de l'adresse 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, auquel cas le nœud SIP appelant A correspond à un nœud de type IP identique à celui du proxy SIP P, ou au contraire, à un nœud 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 à discriminer au niveau du serveur d'enregistrement R, le type IP du nœud SIP appelé à partir des bases d'enregistrement DBi(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 du terminal appelé est donnée par la relation symbolique : 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 le terminal appelé B et de l'adresse de communication du nœud 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 : R ^ *&"> > p.
Enfin, l'opération de routage à l'étape Y est représentée par la relation : CR(P@ v4, B@ vy, A @ vx, ALG(SDP)) v _ P T o.
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. 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 nœud SIP appelant respectivement appelé afin d'optimiser les choix de routage et notamment le recours aux fonctions d'adaptation précitées. A l'étape U, le serveur proxy SIP détermine le type IP du nœud
SIP appelant A. Dans ce but, il s'appuie sur la connaissance des adresses utilisées par les nœuds SIP pour le contacter.
En effet, par configuration, tous les nœuds SIP de type IPv4 contactent le serveur proxy SIP P sur son adresse d'origine exclusivement. Par ailleurs, les nœuds 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 service mis en œuvre 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 nœud 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 nœud SIP est de type double pile lorsque ce nœud SIP a été référencé dans chacune des bases de données d'enregistrement précédemment décrites.
De plus, tout nœud 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 du nœud 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 fournisse l'adresse avec laquelle le nœud 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 supplémentaire dans ces échanges. En effet, le serveur proxy SIP P requiert en plus le type IP du nœud 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 nœud SIP enregistré est le critère d'enregistrement dans la base de données d'enregistrement en laquelle, ce 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 nœud SIP appelé B.
Lorsque cette opération a été exécutée, c'est-à-dire après l'étape 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 nœud SIP appelant et un nœud SIP appelé de type IP distinct, le serveur proxy SIP route l'appel par 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 nœud 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 nœud A met en œuvre une transmission T au serveur proxy d'une requête d'appel
CR(P@v4, B@vy) du nœud appelant A vers le nœud 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 nœud appelé B selon la relation : p TYPR(B@ vy) >
suite à l'étape U de discrimination du type IP du nœud appelé par le serveur d'enregistrement R, puis l'étape X de transmission, du serveur d'enregistrement R vers le serveur proxy P1 du type IP, vy, du nœud appelé B, enregistré dans la base de données et d'une adresse B@vy du nœud appelé. L'étape X est suivie de l'étape de routage Y de l'appel du nœud 5 appelant A vers le nœud appelé B, en fonction du type IP, vx, du nœud appelant discriminé par le serveur proxy P à l'étape U et du type IP, vy, du nœud 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 le0 proxy P d'une requête de type du nœud appelant A et du nœud appelé B notée : p TYPR(A@vx, B@ yy) ) 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 appelant5 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 DB-ι(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 o 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 : p SM (vκ,vy,B@ vx) . _
5 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 œuvre de la figure 4c, le type du nœud appelant A et du nœud 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 o maintenant décrite en liaison avec les figures 5a à 5c.
Figure 5a : cas où les nœuds SIP appelant et appelé sont de même type IP, ou l'un des deux est de type double pile. 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 nœuds SIP considérés appelant et appelé. La figure 5a illustre le cas de l'appel entre deux nœuds SIP de même type IPv4 entre le nœud SIP A et l'agent utilisateur UA de même type d'un nœud SIP C.
Les messages SIP successifs sont les suivants :
- 1) transmission de la requête d'appel du nœud SIP A au serveur proxy 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 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 nœud SIP C, puis échange des flux RTP.
Figure 5b : transmission d'un appel entre nœuds SIP de même type IPvβ. Dans cette situation, la mise en œuvre 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 nœuds SIP qui sont de même type SIP IPv6.
Ne pas router l'appel vers des fonctions d'adaptation mettant typiquement en œuvre une application ALG permet en outre de maintenir l'établissement des flux RTP au sein de l'environnement IPv6, sans passer par un nœud intermédiaire. Toutefois, les éléments de service et en particulier ceux représentés au nœud intermédiaire IN, sont en principe situés en environnement IP IPv4. En conséquence, la signalisation de l'appel 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 dessin de la figure 5b.
Figure 5c : cas d'un appel entre clients hétérogènes de type IP distinct.
Dans le cas où les nœuds SIP appelant et appelé A et B 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 œuvre 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 nœud SIP destinataire du 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 l'invention, dépendent de l'implémentation. En particulier, de nombreuses implémentations ont la particularité de faire résider ie 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é, 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. 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 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. En outre, ainsi que représenté en figure 6a, Ie serveur d'enregistrement objet de l'invention comprend un module Mo de discrimination de type IP de tout nœud SIP candidat à un enregistrement, en fonction de l'adresse d'appel d'origine respectivement de l'adresse de communication correspondant à l'adresse auxiliaire précitée, utilisée par le nœud 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 première et deuxième bases de données d'enregistrement DBi(v4) et DB2(v6), de chaque nœud SIP candidat à l'enregistrement correspondant à un nœud 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 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'enregistrement objet de l'invention, on indique que pour tout nœud SIP de type IP double pile, la première base de données d'enregistrement DBi(v4) comprend une référence à l'adresse IP du nœud 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 nœud SIP de type IP distinct du type IP du serveur proxy de type IP. 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 nœud SIP appelé par un nœud 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. 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 implanté le serveur proxy, et une adresse auxiliaire de même 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.
Il comprend enfin un module Mi de discrimination, à partir de la requête d'appel, du type IP de tout nœud SIP appelant à partir de l'adresse 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 comporte, en outre, un module M2 de discrimination par interrogation d'un serveur SIP d'enregistrement du type IP du nœud SIP 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 nœud SIP appelé.
En particulier, lorsque le nœud SIP appelant et le nœud SIP 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 nœud SIP appelé.
L'invention couvre également 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 SIP d'enregistrement. Le serveur SIP d'enregistrement opère l'enregistrement d'un nœud SIP de type IP déterminé dans un environnement IP de même type ou d'un autre type IP. 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. Il est remarquable en ce que lors de son exécution, ce programme exécute le processus d'enregistrement d'un nœud 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 module M0 décrit 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 SIP, opérant en transmission d'une requête d'appel d'un nœud SIP appelé par un nœud SIP 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 description en liaison avec les figures 2a et 2b. Les nœuds SIP appelant et appelé ont satisfait au processus d'enregistrement de nœuds SIP, tel que décrit précédemment dans la description en liaison avec les figures 3a et 3b.
Il 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 précédemment dans la description en liaison avec la figure 4b. Ce programme peut être mis en œuvre sous forme de modules logiciels distincts tels que les modules M1 à M3 décrits en liaison avec la figure 6b.

Claims

REVENDICATIONS
1. Procédé d'adressage de serveurs pour l'inter-fonctioπnement de nœuds 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é, 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 nœud du même type IP que ledit serveur, de ladite adresse d'origine et à tout nœud hétérogène, de 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.
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 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 nœud d'un réseau, ledit nœud é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 : - 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 traduction une adresse de communication dans un environnement de type IP distinct du type IP déterminé ;
- fourniture audit nœud, comme adresse d'appel dudit serveur :
• de ladite adresse d'origine si ledit nœud est de même type IP que ledit type IP déterminé ;
• de ladite adresse de communication si ledit nœud est de type IP distinct dudit type IP déterminé ;
- sur appel dudit serveur par ledit nœud, discrimination du type IP dudit nœud en fonction de l'adresse d'origine ou auxiliaire dudit serveur sur 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 nœud en fonction dudit type IP discriminé dans au moins une base de données.
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 nœuds de même type IP que ledit type IP déterminé et lesdits nœuds de type IP distinct dudit type IP déterminé.
7. Procédé de communication selon l'une quelconque des revendications 5 et 6, caractérisé en ce que ledit nœud 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 nœud d'une requête d'enregistrement vers ladite adresse d'origine dudit serveur d'enregistrement ;
- une étape de transmission par ledit nœud 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.
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 nœud mettant en œuvre une transmission audit serveur proxy d'une requête d'appel dudit nœud appelant vers un nœud 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 nœud appelé ;
5 - une deuxième étape de transmission dudit serveur d'enregistrement vers ledit serveur proxy du type IP dudit nœud appelé enregistré dans ladite base de données et d'une adresse dudit nœud appelé ;
- une étape de routage dudit appel dudit nœud appelant vers ledit nœud appelé, en fonction du type IP dudit nœud appelé transmis par ledit o 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 nœud appelé transmise par ledit serveur d'enregistrement est une adresse dans ledit environnement de type IP déterminé dans lequel 5 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 0 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 : 5 - des moyens de discrimination du type IP d'un nœud 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 nœud candidat ;
- des moyens d'enregistrement dudit nœud en fonction dudit type IP o 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 nœud dans au moins une première et une deuxième bases de données comprenant respectivement iesdits nœuds de même type IP que ledit type IP déterminé et Iesdits nœuds de type IP distinct dudit type IP déterminé.
12. Serveur d'enregistrement selon la revendication 11 , caractérisé en ce que pour un nœud de type IP double pile, ladite première base de données d'enregistrement comprend :
- une référence à l'adresse IP dudit nœud 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 nœud 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 nœud appelé par un nœud 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 nœud appelant, en fonction de l'adresse d'appel d'origine ou auxiliaire dudit serveur sur 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 nœud appelé ;
- des moyens de transmission et de routage de ladite requête d'appel, compte tenu du type IP et de l'adresse de communication dudit nœud appelé.
14. Serveur proxy selon la revendication 13, caractérisé en ce que, pour un nœud appelant et un nœud 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 nœud 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 nœud de type IP déterminé 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 nœud 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 transmission d'une requête d'appel d'un nœud appelé par un nœud 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 nœud appelant et ledit nœud 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 nœud du réseau selon l'une des revendications 4 à 9.
EP07803947A 2006-06-30 2007-06-26 Procede d'adressage des elements de service et de transmission d'appel entre noeuds heterogenes Withdrawn EP2036301A2 (fr)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP2036301A2 true EP2036301A2 (fr) 2009-03-18

Family

ID=37807951

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07803947A Withdrawn EP2036301A2 (fr) 2006-06-30 2007-06-26 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
ATE557514T1 (de) 2008-06-30 2012-05-15 France Telecom Verfahren für den empfang eines datenpakets in einer ipv6-domäne sowie zugehörige vorrichtung und residential gateway
JP5693065B2 (ja) * 2010-07-06 2015-04-01 キヤノン株式会社 通信端末、通信端末の制御方法及びプログラム
CN114244755B (zh) * 2021-12-15 2023-11-14 北京恒安嘉新安全技术有限公司 一种资产探测方法、装置、设备及存储介质

Family Cites Families (19)

* 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 株式会社日立製作所 ＩＰｖ４−ＩＰｖ６マルチキャスト通信方法および装置
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
JP2005086467A (ja) * 2003-09-09 2005-03-31 Hitachi Ltd セッション制御装置、情報通信端末、サーバ、及び端末
US7372840B2 (en) * 2003-11-25 2008-05-13 Nokia Corporation Filtering of dynamic flows
KR20050079420A (ko) * 2004-02-05 2005-08-10 삼성전자주식회사 터널링 서비스 방법 및 시스템
KR100607993B1 (ko) * 2004-07-16 2006-08-02 삼성전자주식회사 이종 네트워크간 통신 시스템 및 방법
JP2006087039A (ja) * 2004-09-17 2006-03-30 Fujitsu Ltd モバイルｉｐ通信端末装置およびモバイルｉｐ通信方法
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 한국전자통신연구원 맵핑 테이블을 이용한 ＩＰｖ４／ＩＰｖ６ 단말 또는 응용프로그램간 프로토콜 변환 장치 및 방법과, 프로토콜 변환장치의 맵핑 테이블 생성 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008001007A3 *

Also Published As

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

Similar Documents

Publication Publication Date Title
EP1994724B1 (fr) Procede et systeme de caracterisation de noeuds de communication heterogenes
EP2297928B1 (fr) Procede de reception d&#39;un paquet de donnees dans un domaine ipv6, dispositif et passerelle residentielle associes
EP3745674B1 (fr) Procédé et système de transmission de données entre noeuds attachés à des environnements ip distincts par affectation d&#39;adresses fictives
CN1327355C (zh) 地址变换装置、消息处理方法及服务器
EP2297927B1 (fr) Procede de reception d&#39;un paquet de donnees en provenance d&#39;un domaine ipv4 dans un domaine ipv6, dispositif et equipement d&#39;acces associes
EP3987752B1 (fr) Procede et dispositif d&#39;obtention d&#39;une adresse ip
EP1950926B1 (fr) Architecture IMS utilisant une table de hachage distribuée
EP3549368B1 (fr) Procédé de fractionnement de messages applicatifs dans un réseau ip
WO2016083751A1 (fr) Procede de communication entre un terminal equipe d&#39;un client webrtc et un terminal accessible via un cœur de reseau ims
EP2036301A2 (fr) Procede d&#39;adressage des elements de service et de transmission d&#39;appel entre noeuds heterogenes
EP3373558B1 (fr) Procédé de communication pour assurer le maintien d&#39;une session applicative entre un terminal et un serveur d&#39;application
EP2169903A1 (fr) Dispositif et procédé de routage permettant des traductions d&#39;adresses en cascade dans un réseau
EP3560168B1 (fr) Classification et aiguillage de messages de contrôle d&#39;une infrastructure de communications
EP3235217B1 (fr) Procédé d&#39;échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d&#39;ordinateur et support d&#39;informations corespondants
EP1964368B1 (fr) Procede et passerelle de raccordement d&#39;entites de communication ip par l&#39;intermediaire d&#39;une passerellle residentielle
WO2008145901A1 (fr) Procede et dispositif d&#39;interface entre les protocoles udp ou tcp et sctp
EP1879368A1 (fr) Enregistrement de communications dans un réseau de télécommunications
WO2003071759A1 (fr) Systeme de transmission de contenus multimedias apte a accorder les contenus au cours de leur transmission
FR3018411A1 (fr) Procede et systeme de traitement d&#39;une requete dns emise par un noeud reseau au cours d&#39;une tentative dacces par une application cliente a un serveur distant sur un reseau ip
FR2887724A1 (fr) Dispositif de gestion de connexion(s) client(s)/serveur(s), en presence de conditions hostiles dans des reseaux ip interconnectes

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081224

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

DAX Request for extension of the european patent (deleted)
RTI1 Title (correction)

Free format text: METHOD FOR ADDRESSING SERVICE ELEMENTS AND TRANSMITTING CALLS BETWEEN HETEROGENEOUS NODES

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20101112