EP2014030A1 - Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants - Google Patents

Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants

Info

Publication number
EP2014030A1
EP2014030A1 EP07731922A EP07731922A EP2014030A1 EP 2014030 A1 EP2014030 A1 EP 2014030A1 EP 07731922 A EP07731922 A EP 07731922A EP 07731922 A EP07731922 A EP 07731922A EP 2014030 A1 EP2014030 A1 EP 2014030A1
Authority
EP
European Patent Office
Prior art keywords
propagation
location server
information
list
telephony
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
EP07731922A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Pierrick Morand
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 EP2014030A1 publication Critical patent/EP2014030A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • 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/80—Responding to QoS

Definitions

  • a method of propagating IP connectivity information between separate IP telephony domains, location server and corresponding computer program is described.
  • Telephony is understood to mean both conventional telephony services or integrating advanced services such as video telephony or digital data transfer.
  • the present invention is in the context of the exchange of information concerning datagram transport services used to route information flows between IP telephony domain management entities.
  • the invention relates to the transfer of domain identifiers
  • IP Internet Protocol
  • BGP Border Gateway Protocol
  • Interdomain Routing Protocol IP telephony domains
  • IP network is the backbone adopted by operators to pool their heterogeneous service offerings including IP telephony commonly referenced by the abbreviation VoIP (or "Voice over IP” for “Voice over IP”) or more generally grouped under the topic of conversational services.
  • VoIP Voice over IP
  • VoIP over IP Voice over IP
  • telephony offers deployed over an IP network must meet quality constraints such as high availability and high fault tolerance.
  • the availability constraint of the service does not only concern the service layer but also the transport layer.
  • LS ( "Location Server” for “Location Server”) is an entity of a telephony domain (ITAD) that manages customer locations and routes of a local ITAD. This equipment can interface with a neighboring LS to learn the location of clients managed by other ITADs; AS (“Autonomous System” for “Autonomous System”): It is a set of IP resources managed by a single administrative entity, also called “IP connectivity provider”. As part of the Border Gatevvaj Protocol, [RFC 1771], each AS is identified by a unique identifier. An AS is also referred to as the "IP Transfer Domain” as it refers to the Network and Transport layers of the OSI model. 2 SOLUTIONS OF THE PRIOR ART 2.1 Prior Art
  • TRlP allows interconnected ITADs to exchange all the destinations they can reach and in particular facilitates the selection of the most appropriate "Gateway” or "backbone” to evacuate IP telephony traffic to the RTC network.
  • the TRIP protocol is implemented by LS ("Location Servers” for “Location Servers”) that propagate TRJP routes containing attributes to qualify the routes in question. The use of this particular protocol is independent of the type of signaling protocol deployed for the actual establishment of calls. TRIP can be used in conjunction with SIP, H.323, or any other signaling protocol.
  • Each LS maintains a local routing database called TRIB ("Telephony Routing Information Database” for "Telephony Routing Information Database”).
  • This routing base is powered by advertisements received from neighboring LSs (from another telephony domain, for example).
  • the operation of the TRIP protocol is similar to that of the Border Gateway Protocol (BGP). Advertisements between neighboring LSs are performed as route update messages, called UPDATE messages. These messages are defined by the TRIP protocol and are exchanged between the LSs to inform a neighboring domain of the available routes.
  • each ITAD being administered by a single telephone operator.
  • IP IP
  • These operators each have one or more LSs.
  • Each LS maintains a database of routing it feeds with advertisements received from its neighbors (ie other areas) and LS its own domain. These ads are updated and redistributed to other neighbors if interconnection agreements allow.
  • the T1TAD4 LS 14 for example, updates the advertisements received from the FITAD5 LS 15 and re-propagates them to ITAD3 13. It should be noted that an ITAD is not necessarily deployed on a single AS or " IP transfer domain ".
  • an LS treats three types of routes: - external routes, received from LS located in neighboring ITADs; internal routes (Internai Routes), received from LS located in the same
  • ITAD Local Routes, configured locally in each LS for injection into TRIP processes. This operation is performed either by static configuration or by redistributing information from other routing protocols.
  • Adj-TRIBs-In 22 stores the routing information conveyed by UPDATE messages. This routing information, also called “routes”, is the input to a route selection process.
  • Ext-TRIB 24 Only one "Ext-TRIB” (“external TRlB”) table is maintained by LS. This table contains the result of a route selection process applied to the external roads 25 ("Adj-TRIBs-IN”) and local roads 26 ("Local Routes"). Prior art techniques allow only one route to be chosen per destination;
  • Loc-TRIB 20 (“Local TRIB”): This table contains local routes resulting from the application of local routing policies to each LS; “Adj-TRIBs-Out” 23 (“Adjacent TRIB out”): These are the roads that the
  • the QoS-Enhanced Border Gateway Protocol can be used to determine the QoS processing that will be reserved for voice streams by the layers. network / Transport.
  • the service layer managed by the TRIP protocol, for example, does not have any information on the status of the transfer of data at the level of the transport layer, and even less on the crossed AS for the placement.
  • an LS does not have means to select a data transfer path based on the IP connectivity operator that supports the routing of the traffic.
  • the TRIP protocol is able to maintain the path of crossed ITADs (service layer) but not that of traversed AS (network / transport layers).
  • a provider or operator of telephony services has, so far, no way of knowing by which AS, the voice data transit, and can thus ensure that they transit through AS of a competitor, even if the path to the "service" level is determined.
  • the ITADl 31 1 on which the client S 301 depends chooses the telephone level route through ITAD2 312, ITAD3 313 and finally ITAD6 316 on which the recipient D 302 depends, to control the transfer of the voice data.
  • this telephone-level route assumes the existence of an IP route traversing AS1 domains 321, AS2 322.
  • the solution proposed by the invention makes it possible to overcome these disadvantages of the prior art, by means of a method for propagating at least one routing route of at least one digital stream between a first location server of a first IP telephony domain and a second location server of a second IP telephony domain, said first location server belonging to an autonomous system, for transferring said at least one digital stream, according to the invention, such a method comprises a phase propagating at least one identification information relating to said autonomous system of said first location server to said second server.
  • the invention is based on an approach quite the propagation of routes routing, enabling a location server to obtain the identity of the loaded autonomous system to perform the actual transfer Datas.
  • location servers propagate telephony routes that may not be associated with actual data transport routes.
  • the method according to the invention makes it possible to obtain the identification of the autonomous systems used during transport at the level of the telephony routes.
  • the telephony domain entity may be any system for transferring / advertising / exchanging telephony routes in telephony domains.
  • said propagation phase comprises the following steps: identification of said autonomous system; composing a propagation message comprising said identification information relating to said autonomous system to said second location server; transmitting said propagation message to said second location server.
  • the propagation of a road is carried out in three stages.
  • the step of identification of the autonomous system (AS) by the entity of the first IP telephony domain allows the recovery of the identity of the autonomous system.
  • This identity is then inserted into a route propagation message, announcing or updating a telephony route to a given destination and transmitted to the second location server.
  • This second location server thus becomes aware of the autonomous system of the first location server (or of the list of autonomous systems to join said destination).
  • said composing step comprises the following steps: obtaining a list of propagation information within said first location server; modifying said propagation information list obtained by adding the identification information relating to said system standalone if said second IP telephony domain of said second location server is different from said first IP telephony domain of said first location server inserting said modified list of propagation information in said propagation message.
  • the composition of the propagation message to said second telephony domain location server begins with obtaining a list of propagation information.
  • This list previously present in said first location server is updated if the second location server is different from the first if a route is already present in the LS, otherwise the list is initialized to the value of the local autonomous system.
  • This update consists of adding the autonomous system identifier of the first location server to the propagation list.
  • the propagation list thus makes it possible to broadcast the identification data of the crossed ASs to reach the destination, to the telephony domain entities (local or neighbor).
  • said propagation information list comprises a sequence of propagation information segments, and one of said propagation information segments contains attributes belonging to the group comprising at least: information representative of a scheduling of propagation information autonomous systems; information representative of a number of autonomous systems; at least one identification information of an autonomous system.
  • the propagation list therefore contains data segments. These segments gather information about autonomous systems. The information may contain this segment allow to know the scheduling of autonomous systems, the number of systems in the segment and the identification of autonomous systems. Thus, the domain entity of telephony that receives this list is able to build a database of routing routes identifying the autonomous systems to borrow to reach a given destination.
  • said step of obtaining said list of propagation information comprises: a copying step of said propagation information list if said propagation information list exists; a step of creating a new list of propagation information if said list of propagation information does not exist.
  • the telephony domain entity can still provide a list of propagation information to another telephony domain entity if the latter requests it.
  • the invention also relates to a location server of a first IP telephony domain, capable of propagating at least one of at least routing route a digital stream to a second location server of a second domain IP telephony, said first location server belonging to an autonomous system, for transferring said at least one digital stream,
  • a location server comprises means for propagating at least one identification information of said autonomous system from said first location server to said second location server.
  • the location server is able to provide information identifying autonomous systems to cross during the actual transfer of digital streams.
  • such a location server comprises means for implementing the steps of the method of propagation of routing routes.
  • the invention also relates to a program product downloadable from a computer network communication and / or stored on a computer readable medium and / or executable by a microprocessor.
  • such a computer program product includes program code instructions for executing the routing route propagation method as described above.
  • FIG. 1 presented in relation with the prior art, presents an exemplary architecture of a network managed by the TRIP protocol;
  • FIG. 2 illustrates the structure of the routing databases (TRIB) used by the location servers (LS) routing the calls in the telephony domains (ITAD) presented in FIG. 1;
  • Figure 3 already introduced, illustrates one of the disadvantages of the state of the art, such as spirals;
  • Figure 4 describes the route propagation between two location servers.
  • the invention therefore proposes to improve the operation of the TRIP protocol and thus to allow new functionalities.
  • the general principle of the invention is based in particular on the introduction of a new attribute, in which are contained information on the IP connectivity service providers used to route the voice traffic. More clearly, the invention allows the service layer to identify the ASs, or IP connectivity operators used for the routing of voice traffic.
  • this information can be used to improve the quality of service of inter-domain telephone calls.
  • an LS has a simple and effective way to optimize an end-to-end path for a given destination.
  • This same information also makes it possible to detect anomalies, such as IP spirals, for example, since the service layer is aware of the ASs through which data travels to reach the final destination of a given call.
  • the present application details only the principle of the feedback of information, or identifiers, relating to the transport layer.
  • a list of identifiers relating to the transport layer is obtained, then to be propagated between the LSs implemented by the ITADs. More precisely, a new attribute containing one or more numbers (identifiers) of AS is now described. It makes it possible to identify the traversed AS to convey voice to a given destination. This number / identifier is provided to an administrative management domain (ITAD) which transmits it to a neighboring domain.
  • ITAD administrative management domain
  • This document presents an embodiment based on the location servers LS. It is understood that this embodiment is only an example of implementation. In particular, the invention can be implemented entirely using proxy servers (also called servers "Proxy”) or other functional element defined in a future protocol but whose features incorporate those defined for an LS in the context of this invention.
  • the TRIP protocol is implemented by the LS (location servers) that propagate TRIP routes, containing attributes to qualify the routes exchanged.
  • TRlP Transcription Routing over IP
  • AS_PATH In order to know the IP connectivity service providers used to route voice traffic from an ITAD to a given destination, a new attribute named AS_PATH is introduced. This attribute is defined as follows: Conditional Mandatory; true
  • TRIP Type Code To be defined by IANA.
  • This parameter indicates whether the attribute in question should be filled in or not in a TRIP message.
  • TRIP Type Code This parameter indicates a unique identifier of the TRiP message in question.
  • This attribute is to create and store a list of traversed ASs to reach the destination in question.
  • U is then propagated an IP telephony domain (ITAD) to a neighboring IP telephony domain and so on.
  • ITID IP telephony domain
  • the AS-PATH attribute consists of a sequence of segments, or fields, "AS path".
  • Each "AS path” segment is composed of a ⁇ path segment type, path segment length, and path segment value> triplet, defined as follows: each "path segment type” has a length of 1 byte which can take the following values:
  • AS_SET Unordered series of AS traversed by a route contained in an UPDATE TRJP message.
  • AS_SEQUENCE An ordered series of AS traversed by a route contained in an UPDATE TRJP message.
  • each path segment length has a length of 1 byte and contains the number of ASs contained in the path segment value; the field "path segment value" contains one or more AS numbers, each encoded as a field of 2 bytes long.
  • This new attribute therefore lists the succession of AS traversed by the data associated with a call.
  • Each LS maintains a routing table that it feeds with advertisements received from LSs of neighboring domains or those of its own domain. These ads are updated and redistributed to other neighbors if interconnection agreements allow. The procedure is described in connection with FIG.
  • an LS 41 when an LS 41 propagates (41 1) a TRIP 412 route that it has learned in an UPDATE message 410 from another neighbor LS 40, it is expected that it modifies the new attribute AS_PATH 413 of the route depending on the type of LS 42 to which it must re-propagate the route, according to the following procedure.
  • a given LS announces the route to another TRlP LS peer located in its own ITAD, this LS does not modify the AS_PATH attribute related to that route.
  • the local system adds the number of its IP connectivity service provider (ie the AS identifier) as the last element of the sequence; if the first segment of AS_PATH is of type AS_SET, the local system adds a new segment of type AS_SEQUENCE at the beginning of I 1 ASJPATH; this new segment contains the domain number of its IP connectivity service provider.
  • the advertisement includes the IP connectivity service provider's number in the AS PATH attribute of all UPDATE messages to be sent to its TRIP peers in neighboring ITADs.
  • the LS includes an empty AS_PATH in all UPDATE messages to send to its TRIP peers located in its own ITAD.
  • This attribute can be exploited by the route selection process to eliminate routes containing spirals at the IP level.
  • this attribute can be used by an ITAD to guide the process of updating Quality of Service information contained in TRIP routes.
  • This attribute can also be used to determine the IP processing associated with a given call.
  • an ITAD In the case where an ITAD is attached to several ASs, it can advertise some of its prefixes by indicating that these prefixes are managed (at the IP level) by a provider X and another part of its prefixes indicating that these prefixes are managed by a supplier Y.
  • New alphanumeric numbers are introduced here. Such numbers allow the routing of calls to numbers other than those defined by E.164. With this extension, VoIP service platforms such as those that do not use traditional telephone numbers can interconnect with other operators to provide a global voice service.
  • the "Address Family" field of a TRIP route can take the value
  • DIGIT mark
  • separators alpha lowalpha
  • upalpha upalpha "A" I "B” I "C” I "D” I "E” I "F”
  • New numbers proposed to be propagated using the TRIP protocol can then have the following format; 1. medf @ franceteleeom

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé de propagation d'au moins une route d'acheminement d'au moins un flux numérique entre un premier serveur de localisation d'un premier domaine de téléphonie IP et un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un système autonome, pour transférer ledit au moins un flux numérique, caractérisé en ce qu'il comprend une phase de propagation d'au moins une information d'identification dudit système autonome dudit premier serveur de localisation à destination dudit second serveur.

Description

Procédé de propagation d'information de connectivité IP entre domaines de téléphonie IP distinct, serveur de localisation et programme d'ordinateur correspondants.
1 DOMAINE DE L'INVENTION La présente invention se rapporte au domaine de la téléphonie sur des réseaux de type Internet (i.e. basés sur le protocole IP). Par téléphonie, on entend tout aussi bien les services de téléphonie classiques ou intégrant des services évolués tels que la visiophonie ou le transfert de données numériques.
Plus précisément, la présente invention se place dans le cadre de l'échange d'information concernant des services de transport de datagrammes utilisés pour router des flux d'information entre des entités de gestion de domaines de téléphonie IP.
En particulier, l'invention concerne le transfert d'identifiants des domaines
IP (de l'anglais « Internet Protocol » pour « Protocole Internet », au sens BGP (« Border Gateway Protocol » pour « Protocole de Routage Interdomaine »)) dans les annonces de routage entre domaines de téléphonie IP (aussi appelé ITAD pour
IP Telephony Administrative Domain).
Le réseau IP est le réseau fédérateur adopté par les opérateurs pour mutualiser leurs offres de service hétérogènes dont la téléphonie IP couramment référencée par le sigle VoIP (de l'anglais « Voice over IP » pour « Voix sur IP ») ou plus généralement groupée sous le thème des services conversationnels.
Le déploiement de ces applications de voix ou de vidéo en temps réel vers le tout IP ainsi que la migration du réseau commuté, traditionnellement désigné par le RTC, contraint les opérateurs à fournir une couverture globale, à l'échelle mondiale, de ces services. Ceci ne se résume pas seulement à assurer des points de présence aux quatre coins du globe mais à offrir aux clients la possibilité de joindre n'importe quelle destination (à savoir les clients des autres opérateurs). Cette couverture globale est réalisable grâce à l'établissement d'accords d'interconnexion avec d'autres fournisseurs de service tiers afin de pouvoir étendre la portée d'un service en dehors des bordures administratives d'un seul fournisseur de service.
Dans le fil de cette dynamique, on prévoit que la coopération entre les fournisseurs de service de VolP/TolP (« Telephony over IP » pour « Téléphonie sur IP ») s'intensifiera dans le court et le moyen terme. Cette intensification doit permettre l'évacuation du trafic lié à la voix vers des points de terminaison se trouvant en dehors des domaines de téléphonie IP (encore appelés « ITAD » de l'anglais « IP Telephony Administrative Domain ») des opérateurs. Ces coopérations entre fournisseurs sont d'autant plus stratégiques que les accords classiques de type bilatéraux ne permettent pas d'assurer la couverture globale requise par les opérateurs.
De plus, les offres de téléphonie déployées au dessus d'un réseau IP doivent répondre à des contraintes de qualité telles que la haute disponibilité et la forte tolérance aux pannes. La contrainte de disponibilité du service ne concerne pas uniquement la couche service mais également la couche transport.
Dans la suite de ce document on emploiera indifféremment les termes de « Qualité de Service » ou de « QoS » qui désignent la même notion. On fait également référence aux termes suivants :
LS (« Location Server » pour « Serveur de Localisation ») : c'est une entité d'un domaine de téléphonie (ITAD) qui gère les localisations des clients et des routes d'un ITAD local. Cet équipement peut s'interfacer avec un LS voisin pour apprendre la localisation des clients gérés par d'autres ITAD ; AS (« Autonomous System » pour « Système Autonome ») : C'est un ensemble de ressources IP gérées par une seule entité administrative, également appelée « fournisseur de connectivité IP ». Dans le cadre du protocole de routage inter domaines BGP (de l'anglais « Border Gatevvaj Protocol », [RFC 1771 ]), chaque AS est identifié par un identifiant unique. Un AS est également appelé « Domaine de Transfert IP » dans la mesure où il se réfère aux couches Réseau et Transport du modèle OSI. 2 SOLUTIONS DE L'ART ANTERIEUR 2.1 Art antérieur
En téléphonie « classique » (monde RTC, réseau téléphonique commuté), les opérateurs de téléphonie établissent des accords bilatéraux pour étendre la couverture globale du service téléphonique. Le niveau de couverture atteint dépend essentiellement du nombre d'accords établis. On peut très schématiquement considérer que deux catégories d'opérateurs de télécommunications existent : les opérateurs locaux et/ou nationaux et les opérateurs mondiaux. Les grands opérateurs mondiaux établissent un grand nombre d'accords et peuvent ainsi joindre la plupart des destinations existantes. Les opérateurs locaux établissent seulement un nombre limité d'accords dont seulement un ou deux avec de grands opérateurs. Ainsi, un opérateur national historique d'un pays en voie de développement va établir des accords avec d'autres opérateurs nationaux et un ou deux accords avec des opérateurs mondiaux pour évacuer les communications vers le reste du monde. Actuellement, la plupart des opérateurs migrent leurs réseaux RTC vers des solutions et des infrastructures basées sur le protocole « IP ». Pour accompagner le déploiement de services de « VoIP », l'IETF (« Internet Engineering Task Force » pour « Groupe de développement de V internet ») a porté de nombreux travaux de standardisation. Plusieurs protocoles ont été spécifiés parmi lesquels on peut citer SIP (« Session Initiation Protocol » pour « Protocole d'initialisation de session »), SDP (« Session Description Protocol » pour « protocole de description de session »), RTP (« Real-time Transfer Protocol » pour « Protocole de transfert en temps réel »), RTCP (« Real-time Transfer Control Protocol » pour « Protocole de contrôle de transfert en temps réel »), MGCP (« Multimedia Gateway Control Protocol » pour « Protocole de contrôle d'épine dorsale multimédia »), SAP (« Session Announcement Protocol » pour « Protocole d'annonce de session ») et TRIP (Telephony Routing Over IP, [RFC3219] pour « Routage de la téléphonie IP »). Ces protocoles répondent à des besoins différents et intègrent en particulier la signalisation et la commande des appels, l'échange des flux média et leur contrôle et l'échange d'informations de routage des appels.
TRlP permet à des ITAD interconnectés d'échanger l'ensemble des destinations qu'ils peuvent joindre et facilite en particulier la sélection des « Gateway » (« Autoroute » ou « épine dorsale ») les plus appropriées pour évacuer du trafic de téléphonie IP vers le réseau RTC. Le protocole TRIP est mis en œuvre par des LS (« Location Servers » pour « Serveurs de localisation ») qui propagent des routes TRJP contenant des attributs permettant de qualifier les routes en question. L'utilisation de ce protocole particulier est indépendante du type du protocole de signalisation déployé pour l'établissement effectif des appels. Le protocole TRIP peut être utilisé conjointement avec SIP, H.323 ou tout autre protocole de signalisation. Chaque LS maintient une base de données de routage locale dite TRIB (« Telephony Routing Information Database » pour « Base de données d'information de routage de téléphonie »). Cette base de routage est alimentée par des annonces reçues des LS voisins (d'un autre domaine de téléphonie, par exemple). Le fonctionnement du protocole TRIP est similaire à celui du protocole BGP (« Border Gateway Protocol »). Les annonces entre LS voisins sont effectuées sous la forme de messages de mise à jour de route, nommés messages «UPDATE ». Ces messages sont définis par le protocole TRIP et sont échangés entre les LS pour informer un domaine voisin des routes disponibles.
On décrit, en relation avec la figure 1 , l'activation du protocole TRlP entre différents ITAD (pour des raisons de simplicité, on utilise également le terme « domaine » pour dénoter un ITAD), chaque ITAD étant administré par un seul opérateur de téléphonie IP. Ces opérateurs disposent chacun d'un ou plusieurs LS. Chaque LS maintient une base de routage qu'il alimente avec des annonces reçues de ses voisins (i.e. d'autres domaines) et des LS de son propre domaine. Ces annonces sont mises à jour et redistribuées à d'autres voisins si les accords d'interconnexion le permettent. Ainsi le LS de T1TAD4 14, par exemple, met à jour les annonces reçues du LS de FITAD5 15 et les re-propage à ITAD3 13. Il convient de noter qu'un ITAD n'est pas nécessairement déployé sur un seul AS ou « domaine de Transfert IP».
Du point de vue routage, un LS traite trois types de routes: - les routes externes (External Routes), reçues de LS situés dans des ITAD voisins ; les routes internes (Internai Routes), reçues de LS situés dans le même
ITAD ; les routes locales (Local Routes), configurées localement dans chaque LS pour être injectées dans les processus TRIP. Cette opération est réalisée soit par configuration statique ou par redistribution d'informations provenant d'autres protocoles de routage.
Ces routes sont gérées dans des tables de routage nommées « TRlB »
(« Telephony Routing Information Base » pour « Base d'information de routage de la téléphonie »). Ainsi, quatre types de « TRIB » sont gérés par un LS comme l'illustre Ia figure 2. Ces tables existent pour un même LS, les relations entre ces tables sont illustrées en relation avec la figure 2.
« Adj-TRIBs-In » 22 : stocke les informations de routage véhiculées par des messages UPDATE. Ces informations de routage, également appelées « routes », sont les entrées d'un processus de sélection 21 de routes
(« Décision Process »). Un LS donné maintient une table « Adj-TRIB-In »
22 (pour adjacent TRIB in qui stocke l'ensemble d'annonces de routes reçues de la part d'un LS adjacent) par LS voisin ;
« Ext-TRIB » 24: une seule table « Ext-TRIB » (« external TRlB ») est maintenue par LS. Cette table contient le résultat d'un processus de sélection de routes appliqué aux routes externes 25 (« Adj-TRIBs-IN ») et locales 26 (« Local Routes »). Les techniques de Fart antérieur ne permettent de choisir qu'une seule route par destination ;
« Loc-TRIB » 20 (« Local TRIB »): cette table contient les routes locales résultant de l'application des politiques de routage locales à chaque LS ; « Adj-TRIBs-Out » 23 (« Adjacent TRIB out »): Ce sont les routes que le
LS local annoncera à ses pairs.
Au niveau IP, on peut utiliser le protocole q-BGP (« QoS-Enhanced Border Gateway Protocol » pour « Protocole de Routage Interdomaine à Qualité de Service Augmentée ») afin de connaître le traitement de QoS qui sera réservé aux flux voix par les couches réseau/transport.
2.2 Inconvénients de l'art antérieur
Cependant, les inventeurs ont constaté qu'il n'existe pas, à ce stade d'évolution du protocole TRIP, de prise en compte de la corrélation avec la couche de transport des données, via notamment les protocoles BGP et q-BGP ou tout autre protocole de routage IP.
En d'autres termes, la couche de service, gérée par le protocole TRIP par exemple, ne dispose d'aucune information de l'état du transfert des données au niveau de la couche transport, et encore moins sur les AS traversés pour le placement d'un appel de téléphonie IP.
De façon plus générale, les spécifications actuelles décrivant les protocoles mis en œuvre pour le transfert de données IP ne corrèlent pas les couches réseau/transport et service.
Ainsi, à ce jour, un LS ne dispose pas de moyens pour sélectionner un chemin de transfert des données en fonction de l'opérateur de connectivité IP qui prend en charge l'acheminement du trafic. En effet, le protocole TRIP est en mesure de maintenir le chemin des ITAD traversés (couche service) mais pas celui des AS traversés (couches réseau/transport).
En d'autres termes, un fournisseur ou opérateur de service de téléphonie ne dispose, à ce jour, d'aucun moyen de connaître par quels AS, les données de voix transitent, et ne peut ainsi s'assurer qu'elles transitent par des AS d'un concurrent, et ce même si le chemin au niveau « service » est déterminé.
Concrètement, ces inconvénients sont illustrés en relation avec la figure 3, présentant les dépendances d'un réseau IP à la fois « verticalement », c'est-à-dire entre ITAD et AS qui en dépendent, et à la fois « horizontalement », c'est-à-dire entre domaines (service) et opérateurs de connectivités (niveau IP).
On suppose qu'un client S 301 communique avec un client destinataire D
302. Pour ce faire, l'ITADl 31 1 dont dépend le client S 301 choisit la route de niveau téléphonique passant par ITAD2 312, ITAD3 313 et enfin ITAD6 316 dont dépend le destinataire D 302, pour commander le transfert des données de voix.
Cependant, les données elles-mêmes transitent au niveau de la couche IP par les AS, dont dépendent chacun de plusieurs ITAX). Une spirale d'AS se produit quand, à l'issue d'une négociation entre ITADs pour l'acheminement d'un flux média, ce flux emprunte plusieurs fois un même AS avant d'arriver à destination.
Dans le cas illustré par Ia figure 3, cette route de niveau téléphonique suppose l'existence d'une route IP traversant les domaines ASl 321, AS2 322.
ASl 321 et enfin AS6 326. On parle alors de spirale au niveau IP. L'existence d'une spirale peut nuire aux performances de transfert des datagrammes IP car on passe plusieurs fois par PASl .
3 RESUME DE L'INVENTION
La solution proposée par l'invention permet de pallier ces inconvénients de l'art antérieur, grâce à un procédé de propagation d'au moins une route d'acheminement d'au moins un flux numérique entre un premier serveur de localisation d'un premier domaine de téléphonie IP et un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un système autonome, pour transférer ledit au moins un flux numérique, Selon l'invention, un tel procédé comprend une phase de propagation d'au moins une information d'identification relative audit système autonome dudit premier serveur de localisation à destination dudit second serveur.
Ainsi, l'invention repose sur une approche tout à fait de la propagation de routes d'acheminement, en permettant à un serveur de localisation, d'obtenir l'identité du système autonome chargé d'effectuer le transfert effectif des données. En effet, selon l'art antérieur, les serveurs de localisation propagent des routes de téléphonie qui peuvent ne pas être associées à des routes de transport effectif des données. Le procédé selon l'invention permet d'obtenir l'identification des systèmes autonomes empruntés lors du transport au niveau des routes de téléphonie. L'entité de domaine de téléphonie peut être tout système chargé de transférer/annoncer/échanger des routes de téléphonie dans des domaines de téléphonie.
Selon un aspect particulier de l'invention, ladite phase de propagation comprend les étapes suivantes : - identification dudit système autonome ; composition d'un message de propagation comprenant ladite information d'identification relative audit système autonome à destination dudit deuxième serveur de localisation ; émission dudit message de propagation à destination dudit deuxième serveur de localisation.
Ainsi, la propagation d'une route est réalisée en trois temps. L'étape d'identification du système autonome (AS) par l'entité du premier domaine de téléphonie IP permet la récupération de l'identité du système autonome. Cette identité est ensuite insérée dans un message de propagation de route, annonçant ou mettant à jour une route de téléphonie vers une destination donnée et émis en direction du deuxième serveur de localisation. Ce deuxième serveur de localisation prend ainsi connaissance du système autonome du premier serveur de localisation (ou de la liste des systèmes autonomes pour joindre ladite destination). Selon un mode de mise en œuvre particulier, ladite étape de composition comprend les étapes suivantes : obtention d'une liste d'informations de propagation au sein dudit premier serveur de localisation ; modification de ladite liste d'informations de propagation obtenue par ajout de l'information d'identification relative audit système autonome si ledit deuxième domaine de téléphonie IP dudit deuxième serveur de localisation est différent dudit premier domaine de téléphonie IP dudit premier serveur de localisation insertion de ladite liste d'informations de propagation modifiée dans ledit message de propagation.
Ainsi, la composition du message de propagation à destination dudit deuxième serveur de localisation de domaine de téléphonie débute par l'obtention d'une liste d'information de propagation. Cette liste préalablement présente au sein dudit premier serveur de localisation fait l'objet d'une mise à jour si le deuxième serveur de localisation est différent du premier si une route est déjà présente dans le LS, sinon, la liste est initialisée à la valeur du système autonome locale. Cette mise à jour consiste en l'ajout de l'identifiant du système autonome du premier serveur de localisation à la liste de propagation. La liste de propagation permet de donc de diffuser les données d'identification des AS traversés pour joindre la destination, aux entités de domaines de téléphonie (local ou voisin).
Selon une caractéristique originale, ladite liste d'informations de propagation comprend une séquence de segments d'informations de propagation, et un desdits segments d'informations de propagation contient des attributs appartenant au groupe comprenant au moins : une information représentative d'un ordonnancement de systèmes autonomes ; une information représentative d'un nombre de systèmes autonomes ; - au moins une information d'identification d'un système autonome.
La liste de propagation contient donc des segments de données. Ces segments rassemblent des informations relatives à des systèmes autonomes. Les informations que peuvent contenir ce segment permettent de connaître l'ordonnancement des systèmes autonomes, le nombre de systèmes dans le segment et l'identification des systèmes autonomes. Ainsi, l'entité de domaine de téléphonie qui reçoit cette liste est à même de construire une base de données de routes d'acheminement identifiant les systèmes autonomes à emprunter pour joindre une destination donnée.
Selon un aspect particulier de l'invention, ladite étape d'obtention de ladite liste d'informations de propagation comprend : une étape de copie de ladite liste d'informations de propagation si ladite liste d'information de propagation existe ; une étape de création d'une nouvelle liste d'informations de propagation si ladite liste d'informations de propagation n'existe pas.
A l'aide de ces étapes, l'entité de domaine de téléphonie peut toujours fournir une liste d'information de propagation à une autre entité de domaine de téléphonie si cette dernière en fait la demande.
L'invention concerne également un serveur de localisation d'un premier domaine de téléphonie IP, apte à propager au moins une route d'acheminement d'au moins un flux numérique à destination d'un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un système autonome, pour transférer ledit au moins un flux numérique, Selon l'invention, un tel serveur de localisation comprend des moyens de propagation d'au moins une information d'identification dudit système autonome, dudit premier serveur de localisation à destination dudit deuxième serveur de localisation.
Ainsi, le serveur de localisation selon l'invention est à même de fournir des informations identifiant les systèmes autonomes à traverser lors du transfert effectif des flux numériques.
Plus généralement, un tel serveur de localisation comprend des moyens de mise en œuvre des étapes du procédé de propagation de routes d'acheminement.
Dans un autre mode de réalisation, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur.
Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de propagation de routes d'acheminements tel que décrit précédemment.
4 LISTE DES FIGURES
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 , présentée en relation avec l'art antérieur, présente un exemple d'architecture d'un réseau géré par le protocole TRIP ; la figure 2 illustre la structure des bases de données de routage (TRIB) utilisées par les serveurs de localisation (LS) routant les appels dans les domaines de téléphonie (ITAD) présentés en figure 1 ; la figure 3 déjà introduite, illustre l'un des inconvénients de l'état de la technique, tel que les spirales ;
La figure 4 décrit la propagation de route entre deux serveurs de localisation.
5 DESCRIPTION DETAILLEE DE L'INVENTION
Pour plus de clarté, on présente ci-après un mode de réalisation de l'invention mettant en œuvre le protocole TRIP au niveau de la couche service.
Cependant, il est clair que l'invention ne se limite pas à ce protocole particulier, mais peut également s'appliquer à tout nouveau protocole d'échange de routes entre opérateurs de téléphonie IP.
5.1 Rappel du principe de l'invention
L'invention propose donc d'améliorer le fonctionnement du protocole TRIP et ainsi permettre de nouvelles fonctionnalités. Pour ce faire, le principe général de l'invention repose notamment sur l'introduction d'un nouvel attribut, dans lequel sont contenues des infoπnations sur les fournisseurs de service de connectivité IP utilisé pour acheminer le trafic voix. Plus clairement, l'invention permet à la couche service d'identifier les AS, ou opérateurs de connectivité IP utilisés pour le routage du trafic voix.
La connaissance et la propagation d'une telle information au niveau d'un
LS permet alors de nombreuses applications et optimisations pour la gestion du service de téléphonie inter domaines. Par exemple, dans une mise en œuvre particulière, cette information peut être utilisée pour améliorer la qualité de service des appels téléphoniques inter domaines. Par ailleurs, toujours grâce à cette information, un LS possède un moyen simple et efficace pour optimiser un chemin de bout en bout pour une destination donnée. Cette même information permet de plus de détecter les anomalies, telles que les spirales IP par exemple, puisque la couche service a connaissance des AS par lesquels transitent les données pour joindre la destination finale d'un appel donné.
La présente demande détaille uniquement le principe de la remontée d'informations, ou d'identifiants, relatives à la couche transport. Une liste d'identifiants relatifs à la couche transport est obtenue, pour ensuite être propagée entre les LS mis en œuvre par les ITADs. Plus précisément, on décrit maintenant un nouvel attribut contenant un ou plusieurs numéros (identifiants) d'AS. Il permet d'identifier les AS traversés pour acheminer de la voix vers une destination donnée. Ce numéro/identifiant est fourni à un domaine de gestion administrative (ITAD) qui le transmet à un domaine voisin. On présente dans ce document un mode de réalisation basé sur les serveurs de localisation LS. Il est bien entendu que ce mode de réalisation n'est qu'un exemple de mise en œuvre. Notamment, l'invention peut tout à fait être implémentée en utilisant des serveurs de proximité (également appelés serveurs « Proxy ») ou tout autre élément fonctionnel défini par un futur protocole mais dont les fonctionnalités intègrent celles définies pour un LS dans le cadre cette invention.
5.2 Format
Classiquement, on rappelle que le protocole TRIP est mis en œuvre par les LS (serveurs de localisation) qui propagent des routes TRIP, contenant des attributs permettant de qualifier les routes échangées.
Plus précisément, la version standard du protocole TRlP (détaillée dans le document RFC3219 de Rosenberg et al. : « Telephony Routing over IP (TRIP) » de janvier 2002) prévoit l'échange d'informations de routage entre deux LS voisins (ces LS peuvent appartenir au même ITAD ou à des ITAD voisins) via le message UPDATE, qui comporte un certain nombre d'attributs.
Afin de connaître les fournisseurs de service de connectivité IP utilisés pour acheminer le trafic voix d'un ITAD vers une destination donnée, on introduit un nouvel attribut nommé AS_PATH. Cet attribut est défini comme suit : Conditional Mandatory ; True
TRIP Type Code : To be defined by IANA.
Conditional Mandatory : ce paramètre indique si l'attribut en question doit être renseigné ou pas dans un message TRIP.
TRIP Type Code : ce paramètre indique une identifiant unique du message TRiP en question.
Cet attribut a pour but de créer et de stocker une liste des AS traversés pour joindre la destination en question. En d'autres termes, c'est un attribut de la couche service qui contient des informations, relatives à la couche IP. U est alors propagé d'un domaine de téléphonie IP (ITAD) à un domaine de téléphonie IP voisin et ainsi de suite.
L'attribut AS-PATH est composé d'une séquence de segments, ou champs, « AS path » (chemin d'AS). Chaque segment « AS path » est composé d'un triplet <path segment type, path segment length, path segment value>, défini comme suit : chaque "path segment type" a une longueur de 1 octet qui peut prendre les valeurs suivantes :
Valeur Type de segment
AS_SET: Série non ordonnée des AS traversés par une route contenue dans un message UPDATE TRJP.
AS_SEQUENCE: Série ordonnée des AS traversés par une route contenue dans un message UPDATE TRJP. chaque « path segment length » a une longueur de 1 octet et contient le nombre d'AS contenus dans Ie « path segment value » ; - le champ « path segment value » contient un ou plusieurs numéros d'AS, chacun codé comme un champ d'une longueur de 2 octets.
Ce nouvel attribut liste donc la succession des AS traversés par les données associées à un appel.
5.3 Procédure On rappelle que les opérateurs de téléphonie disposent chacun d'un ou plusieurs LS. Chaque LS maintient une table de routage qu'il alimente avec les annonces reçues des LS des domaines voisins ou de ceux de son propre domaine. Ces annonces sont mises à jour et redistribuées à d'autres voisins si les accords d'interconnexion le permettent. La procédure est décrite en relation avec la figure 4.
Selon l'invention, quand un LS 41 propage (41 1) une route TRIP 412 qu'il a apprise dans un message UPDATE 410 d'un autre LS voisin 40, on prévoit qu'il modifie le nouvel attribut AS_PATH 413 de la route selon le type de LS 42 auquel il doit re-propager la route, selon la procédure suivante. Quand un LS donné annonce la route à un autre pair TRlP LS situé dans son propre ITAD, ce LS ne modifie pas l'attribut AS_PATH lié à cette route.
Si le LS à qui Ia route est annoncée (LS pair) n'est pas situé dans le même ITAD, deux cas de figure se présentent pour la mise à jour de l'attribut AS PATH : si le premier segment de l'ASJPATH est de type AS_SEQUENCE, le système local ajoute le numéro de son fournisseur de service de connectivité IP (i.e. l'identifiant d'AS) comme dernier élément de la séquence ; - si le premier segment de l'AS_PATH est de type AS_SET, le système local ajoute un nouveau segment de type AS_SEQUENCE au début de I1ASJPATH ; ce nouveau segment contient le numéro du domaine de son fournisseur de service de connectivité IP.
Si le LS est l'origine de l'annonce, ce dernier inclut le numéro de son fournisseur de service de connectivité IP dans l'attribut AS PATH de tous les messages UPDATE à envoyer à ses pairs TRIP situés dans les ITAD voisins. De plus, le LS inclut un AS_PATH vide dans tous les messages UPDATE à envoyer à ses pairs TRIP situés dans son propre ITAD.
2.3 Exploitation Cet attribut peut être exploité par le processus de sélection de route pour éliminer les routes contenant des spirales au niveau IP. De plus, cet attribut peut être utilisé par un ITAD pour guider le processus de mise à jour des informations de Qualité de Service contenues dans les routes TRIP. Cet attribut peut être aussi utilisé pour déterminer le traitement IP associé à un appel donné. Dans le cas où un ITAD est attaché à plusieurs AS, il peut annoncer une partie de ses préfixes en indiquant que ces préfixes sont gérés (au niveau IP) par un fournisseur X et une autre partie de ses préfixes en indiquant que ces préfixes sont gérés par un fournisseur Y.
On détaille un nouvel attribut de gestion des préfixes de téléphonie dans la partie suivante. Il est clair que ces exemples d'applications ne sont donnés qu'à titre illustratif et non exhaustif ou limitatif.
2.4 Numéros de téléphonie pour l'extension des numéros de type E 164 Le protocole « TRIP » ne permet d'échanger que des numéros de type
E.164 ou des numéros de type décimal. Ceci pose un obstacle pour les nouveaux acteurs qui ne disposent que des noms de domaines et qui veulent activer le protocole TRlP afin de s'interconnecter avec d'autres opérateurs.
On introduit ici de nouveaux numéros de type alphanumérique. De tels numéros permettent le routage des appels vers des numéros autres ceux définis par E.164. Grâce à cette extension, des plateformes de service « VoIP » telles que celles n'utilisant pas les numéros de téléphones traditionnels peuvent s'interconnecter avec d'autres opérateurs pour offrir un service de voix global.
Afin de permettre d'échanger des informations de routage autres que les numéros de type E.164 ou ceux définit dans la RFC3219, on introduit un autre type de numéro défini comme suit :
Code Address Family
4 Alpha Numeric Routing numbers
Ainsi, le champ "Address Family" d'une route TRIP peut prendre la valeur
4 pour désigner un numéro de type alpha numérique. Ce numéro, définit par une grammaire BNF classique, prend le format suivant :
Alpha-numeric-routing-number = *alpha-numeric alpha-numeric = alpha | DIGIT | mark | separators alpha = lowalpha | upalpha upalpha = "A" I "B" I "C" I "D" I "E" I "F" | "G" | "H" | "I" | "J" | "K"
I "L" I "M" I "N" I "O" I "P" I "Q" | "R" | "S" | "T" | "U" | "V" I ..w., i ,,χl, i ,,γ), i ,,z,, lowalpha = "a" I "b" I "c" I "d" | "e" | "f" | "g" | "h" | "i" | "j" I "k" | "I" I "m" I "n" I "o" I "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" I "x" I "y" I "z" DIGIT = HQM I U1,, I H2,, I „3,, I ,,4,, I ,,5,, I ,,g,, I ,,J,, | Hg,, | ,,Q,, mark _ H_ll I „^,1 I ,, U I M , ,, I ,,^1, I „*„ I „,„ I „£„ j M^1, separators ≈ τ j «)B ! »< n ( B > n j «@« j „ « j ..... ! „ . ,. ! ,γ j τ j τ j
"]" I "?" I "=" I "{" I "}"
Les nouveaux numéros qu'on propose de propager à l'aide du protocole TRIP peuvent alors avoir Ie format suivant ; 1. medf@franceteleeom
2. uri:med@192.165.56.3:5632
3. med.francetelecom.com:4578
4. userid=med, host=125.12.25.265, port=2178
Le format de ces numéros est négocié lors de l'établissement de l'accord d'interconnexion entre deux ITAD voisins.

Claims

REVENDICATIONS
1. Procédé de propagation d'au moins une route d'acheminement d'au moins un flux numérique entre un premier serveur de localisation d'un premier domaine de téléphonie IP et un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un système autonome, pour transférer ledit au moins un flux numérique, caractérisé en ce qu'il comprend une phase de propagation d'au moins une information d'identification relative audit système autonome dudit premier serveur de localisation à destination dudit second serveur.
2. Procédé de propagation selon la revendication 1 , caractérisé en ce que ladite phase de propagation comprend les étapes suivantes : identification dudit système autonome ; composition d'un message de propagation comprenant ladite information d'identification relative audit système autonome à destination dudit deuxième serveur de localisation ; émission dudit message de propagation à destination dudit deuxième serveur de localisation.
3. Procédé de propagation selon la revendication 2, caractérisé en ce que ladite étape de composition comprend les étapes suivantes : obtention d'une liste d'informations de propagation au sein dudit premier serveur de localisation ; modification de ladite liste d'informations de propagation obtenue par ajout de l'information d'identification relative audit système autonome si ledit deuxième domaine de téléphonie IP dudit deuxième serveur de localisation est différent dudit premier domaine de téléphonie IP dudit premier serveur de localisation insertion de ladite liste d'informations de propagation modifiée dans ledit message de propagation.
4. Procédé selon la revendication 3, caractérisé en ce que ladite liste d'informations de propagation comprend une séquence de segments d'informations de propagation, et en ce qu'un desdits segments d'informations de propagation contient des attributs appartenant au groupe comprenant au moins : - une information représentative d'un ordonnancement de systèmes autonomes ; une information représentative d'un nombre de systèmes autonomes ; au moins une information d'identification d'un système autonome.
5. Procédé selon l'une quelconque des revendications 3 et 4, caractérisé en ce que ladite étape d'obtention de ladite liste d'informations de propagation comprend : une étape de copie de ladite liste d'informations de propagation si ladite liste d'information de propagation existe ; - une étape de création d'une nouvelle liste d'informations de propagation si ladite liste d'informations de propagation n'existe pas.
6. Serveur de localisation d'un premier domaine de téléphonie IP, apte à propager au moins une route d'acheminement d'au moins un flux numérique à destination d'un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un système autonome, pour transférer ledit au moins un flux numérique, caractérisé en ce qu'il comprend de moyens de propagation d'au moins une information d'identification relative audit système autonome à destination dudit deuxième serveur de localisation.
7. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de production selon l'une au moins des revendications 1 à 5, lorsqu'il est exécuté sur un ordinateur.
EP07731922A 2006-04-21 2007-04-20 Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants Withdrawn EP2014030A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0603624 2006-04-21
PCT/FR2007/051147 WO2007122352A1 (fr) 2006-04-21 2007-04-20 Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP2014030A1 true EP2014030A1 (fr) 2009-01-14

Family

ID=37546331

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07731922A Withdrawn EP2014030A1 (fr) 2006-04-21 2007-04-20 Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants

Country Status (3)

Country Link
US (1) US8457105B2 (fr)
EP (1) EP2014030A1 (fr)
WO (1) WO2007122352A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007122352A1 (fr) 2006-04-21 2007-11-01 France Telecom Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants
US7990892B2 (en) * 2006-04-21 2011-08-02 France Telecom Method of selecting a telephony route within an IP telephony domain, and corresponding apparatus and computer program

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
US6741585B1 (en) * 2000-05-05 2004-05-25 Lucent Technologies Inc. Interworking of addressing in an internetwork
US7072303B2 (en) * 2000-12-11 2006-07-04 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks
US7002973B2 (en) * 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
US7565448B1 (en) * 2004-02-03 2009-07-21 Sprint Communications Company L.P. Network control system for a communication network
US7756998B2 (en) * 2004-02-11 2010-07-13 Alcatel Lucent Managing L3 VPN virtual routing tables
US7814227B2 (en) * 2005-03-04 2010-10-12 Cisco Technology, Inc. Computation of a shortest inter-domain TE-LSP across a set of autonomous systems
US20060262776A1 (en) * 2005-05-23 2006-11-23 Pollock Graham S System and method for auto-discovery of peering and routing in a combined circuit -switched/packet-switched communication network using trip protocol
US8761155B2 (en) * 2006-04-21 2014-06-24 France Telecom Method of taking account of quality of service between distinct IP telephony domains, and a corresponding location server and computer program
WO2007122352A1 (fr) 2006-04-21 2007-11-01 France Telecom Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants
FR2900300A1 (fr) * 2006-04-21 2007-10-26 France Telecom Procede de propagation de routes de telephonie ip multiples, dispositif et programme d'ordinateur correspondants
US7565488B2 (en) * 2006-07-26 2009-07-21 International Business Machines Corporation Apparatus, system, and method for integrated blade raid controller and storage
WO2008110723A2 (fr) * 2007-02-16 2008-09-18 France Telecom Optimisation de l ' acheminement de communications entre une pluralite de domaines de telephonie

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
US8457105B2 (en) 2013-06-04
WO2007122352A1 (fr) 2007-11-01
US20090175267A1 (en) 2009-07-09

Similar Documents

Publication Publication Date Title
EP2014031A1 (fr) Procede de selection d&#39;une route de telephonie au sein d&#39;un domaine de telephonie ip, dispositif et programme d&#39;ordinateur correspondants
EP2469428B1 (fr) Exploration de données pour services
EP3085065B1 (fr) Procédé de mise a jour dynamique d&#39;informations obtenues de la part d&#39;un serveur dns
EP3732829B1 (fr) Procédé d&#39;acheminement de données d&#39;une session initialisée entre un terminal et un serveur
WO2009125158A2 (fr) Procede de routage d&#39;un paquet de donnees dans un reseau et dispositif associe
US20070280225A1 (en) Extended services and recommendations
EP2057795B1 (fr) Procédé de propagation de routes de téléphonie ip multiples, serveur de localisation et programme d&#39;ordinateur correspondants
EP2109991B1 (fr) Optimisation de l&#39;acheminement de communications entre une pluralite de domaines de telephonie
EP2052505A1 (fr) Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d&#39;ordinateur correspondants
WO2007122352A1 (fr) Procede de propagation d&#39;information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d&#39;ordinateur correspondants
EP2984786B1 (fr) Architecture centralisée pour l&#39;établissement de fédérations de distributeurs de contenus
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
Bons et al. IPv6: Drivers and Barriers for Adopting
FR2872369A1 (fr) Procede de gestion d&#39;une interconnexion entre reseaux de telecommunication et dispositif mettant en oeuvre ce procede
US20100067399A1 (en) Method and apparatus for analyzing proposed service features in a communication network
EP2254288B1 (fr) Procédé de prévention et d&#39;évitement de boucles en inter-domaine
US20060165065A1 (en) Communications address provisioning system and method therefor
EP3815316A1 (fr) Procédé de communication mis en oeuvre par un premier routeur d&#39;un système autonome utilisant un protocole de routage interne
George et al. Shared Transition Space: Is it necessary?
WO2007063211A1 (fr) Declenchement automatique de communications

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: 20081114

AK Designated contracting states

Kind code of ref document: A1

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)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

17Q First examination report despatched

Effective date: 20160311

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: 20171103