EP2014031A1

EP2014031A1 - Method for selecting a telephony route withing an ip telephony domain, corresponding device and computer programme

Info

Publication number: EP2014031A1
Application number: EP07731924A
Authority: EP
Inventors: Mohamed Boucadair
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2006-04-21
Filing date: 2007-04-20
Publication date: 2009-01-14
Also published as: WO2007122353A1; US20090086724A1; US7990892B2

Abstract

The invention concerns a method for selecting a telephony route of at least one digital stream serving a telephony destination, within a first locating server belonging to a first IP telephony domain deployed on at least one autonomous system, said autonomous system exchanging with its neighbours IP routing data indicating at least one IP destination for updating an IP routing table. According to the invention, said method includes the following steps: finding with the locating first server said IP routing data, said IP routing data comprising an identifier of the second IP telephony domain with which is associated said at least one IP telephony destination, or destination identifier; selecting said IP telephony route to reach said at least one telephony destination, based on a predetermined criterion for selecting the second telephony domain, based on said destination identifier.

Description

A method of selecting a telephony route within an IP telephony domain, corresponding device and computer program.

1 FIELD OF THE INVENTION

The present invention relates to the field of telephony on Internet type networks. Telephony is understood to mean both conventional telephony services or integrating advanced services such as video telephony or the synchronous digital data transfer service.

The present invention relates more particularly to the exchange of information to allow the synchronization between the service layer (that is to say that dealing with call routing) and the network layer (that is to say that the occupying IP datagram transfer) for routing information flows between IP telephony domains.

The 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.

The deployment of these real-time voice and video applications to all-IP and dial-up migration, traditionally referred to by the RTC, forces operators to provide global coverage of these services globally. This is not just about providing points of presence around the globe, but also offering customers the ability to reach any destination (ie customers of other operators).

This overall coverage is achievable through the establishment of interconnection agreements with other third-party service providers to extend the reach of a service outside the administrative boundaries of a single service provider.

In the wake of this dynamic, it is expected that cooperation between VoIP / ToIP ("Telephony over IP") service providers will intensify in the short and medium term. This intensification must allow the evacuation of the traffic linked to the \ oix towards endpoints outside IP telephony domains (also known as IP Telephony Administrative Domain (ITAD)). These cooperations between suppliers are all the more strategic as conventional agreements of bilateral type do not provide the overall coverage required by operators.

In addition, 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. In the remainder of this document we will use indifferently the terms of

"Quality of Service" or "QoS" which designate the same notion. Reference is also made to the following terms:

LS ("Location Server" for "Local Server"): This is an entity of a telephony domain (ITAD) that manages the location of clients 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 BGP inter-domain routing protocol (Border Gateway

Protocol ", [RFC 1771]), each AS is identified by a unique identifier.

This AS is also called "IP Transfer Domain" .. q-BGP: an advanced version of the BGP protocol for exchanging routes that value QoS parameters. 2 SOLUTIONS OF THE PRIOR ART

2.1 Prior Art

In "classic" telephony (PSTN world, switched telephone network). the telephone operators establish bilateral agreements to extend the overall coverage of the telephone service. The level of coverage achieved depends primarily on the number of agreements reached. We can very schematically consider that two categories of telecommunications operators exist: local and / or national operators and global operators. Large global operators establish a large number of agreements and can thus join most existing destinations. Local operators establish only a limited number of agreements of which only one or two with large operators. For example, a national incumbent operator in a developing country will establish agreements with other national operators and one or two agreements with global operators to evacuate communications to the rest of the world. Currently, most operators are migrating their PSTN networks to solutions and infrastructures based on the "IP" protocol. To support the deployment of "VoIP" services, the IETF ("Internet Engineering Task Force" for "Internet Development Group") has carried out a great deal of standardization work. Several protocols have been specified among which SIP (Session Initiation Protocol), SDP (Session Description Protocol for Session Description Protocol), RTP (Real-Time time transfer protocol "for" real-time transfer protocol "), RTCP (" Real-time Transfer Control Protocol "for" Real-time Transfer Control Protocol "), MGCP (" Multimedia Gateway Control Protocol "for" Protocol for control ^of multimedia backbone "), SAP (" session announcement Protocol "to" session announcement Protocol ") and TRIP (telephony Routing Over IP, [RFC3219J for" IP telephony Routing "). These protocols respond to different needs and include in particular signaling and call control, the exchange of media flows and their control and the exchange of call routing information.

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 put implemented by LS ("Location Servers" for "Location Servers") that propagate TRlP 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 basic routing is powered by received listings of neighboring LS ^(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 the LSs of the same domain or a neighboring domain of the available routes.

In connection with FIG. 1, the activation of the TRlP protocol between different ITADs is described (for the sake of simplicity, the term "domain" is also used to denote an ITAD), each ITAD being administered by a single telephone operator. IP. These operators each have one or more LSs. Each LS maintains a routing base that it feeds with advertisements received from its neighbors (ie other domains) and LSs from its own domain. These ads are updated and redistributed to other neighbors if interconnection agreements allow.

Thus the 11TAD4 LS 14, for example, updates the advertisements received from the T1TAD5 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 ".

From the routing point of view, an LS treats three types of routes: the external routes ("External Routes"), received from LS located in

ITAD neighbors; - internal routes (Internai Routes), received from LS located in the same ITAD; Local Routes, configured locally in each LS for injection into TRlP processes. This operation is performed either by static configuration or by redistributing information from other routing protocols.

These routes are managed in routing tables named "TRlB"

( "Telephony Routing Information Base" for "Base ^of the telephone routing information"). Thus, four types of "TRIB" are managed by an LS as shown in Figure 2. These tables exist for the same LS, the relationships between these tables are illustrated in connection with Figure 2.

"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 21 ("Decision Process"). A given LS maintains a table "Adj-TRIB-In" 22 (for adjacent TRIB in which stores the set of route advertisements received from an adjacent LS) by neighbor LS;

"Ext-TRIB" 24: only one "Ext-TRIB" ("external TRIB") 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"). The techniques of the prior art 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: These are the routes that the local LS will announce to their peers.

In the transport layer, the QoS-Enhanced Border Gateway Protocol (Q-BGP) can be used to determine the QoS processing that will be reserved for voice streams by the QoS. transport layer. 2.2 Disadvantages of the Prior Art

A disadvantage of this technique of the prior art is related to the lack of synchronization between the service layer and the network layer in order to route the media streams. Indeed, in the context of the deployment of the TRIP protocol between neighboring ITADs, the media streams follow either the path determined by the IP routing protocols such as the BGP protocol or the one imposed by the telephony platforms of each ITAD. This last possibility requires, in the context of the use of the SIP protocol for example, to modify several times the content of the SDP part of these messages. A corollary disadvantage of these transfer techniques of the prior art stems from the processing of the media streams by the ASs. Indeed, as these flows follow a path determined by the BGP protocol, NTAD does not have the ability to control the path taken by the stream. Thus, flows may follow an optimum path (for example, better QoS) at the ITAD level, but not at the inter-AS path. This amounts to negating negotiations and agreements between neighboring ITADs if the QoS clauses are not met.

In the case of a static configuration of the AS path to be taken by the media streams, this possibility requires, in the context of the use of the SIP protocol for example and during the actual transfer of the streams, to modify several times the content the SDP part of SIP messages. This processing can lead to additional delays in the case where several AS have to be crossed and can affect the quality of service perceived by the end customer.

Another disadvantage of this technique of the prior art is related to the spiral ^phenomenon AS. This spiral phenomenon of AS is presented in relation to FIG.

A spiral ^of AS occurs when, after a negotiation between ITAD for the delivery of a media stream, that stream takes several times the same

AS before arriving at destination. Assume that ITTADl 31 1 uses ASl 321 to evacuate its voice traffic, that TITAD2 312 uses AS2 322. ITT AD3 313 uses ASl 321, that 1TTAD4 314 uses AS4 324. I ¹ ITADS 315 uses AS3 323 and ITTAD6 316 uses AS6 326. Suppose also that the best route to reach D 302 from S 301 is via {AS1, AS4, AS5, AS6}.

Suppose that a client S 301 wants to make a call to D 302 and riTAD1111 has chosen the route through ITAD2 312 and 1TAD3 313 to reach ITADό 316 to which destination D 302 is attached. This telephone-level route assumes the existence of an IP route (at the level of the transfer layer) traversing the domains: AS1, AS2, AS1, AS6. We therefore note that we pass several times by the same AS, in this case ASl. This is a spiral at the IP level and can affect the IP transfer performance because we go through the ASl several times. This phenomenon can be avoided, however, if the media flows follow the BOP path and not the one imposed by the service platforms.

In order to illustrate this phenomenon again, it is now assumed that the path chosen by ITAD1 to join D is (ITAD1, ITAD4, ITAD5, ITAD6) .This means that the followed AS path will be {AS1, AS4, AS3, As there is no direct link between AS4 and AS3, this AS path becomes either (AS1, AS4, AS5, AS6, AS3, AS6) or (AS1, AS4, AS1, AS2, AS3, AS6} In both cases, these paths are not optimal at the IP transfer level and are different from the one chosen by BGP.

Another disadvantage of this technique of the prior art is related to the lack of synchronization between the service layer and the transfer plane. This phenomenon is described in connection with FIG. 4, in the case of IP telephony.

It is assumed here that ITADl is deployed on the two AS, AS1 and AS2, and that ITAD2 is deployed on the AS4 domain and that the two IP telephony operators managing the two ITADs, ITAD1 and ITAD2, have concluded an agreement to interconnect their platforms. services and extend the reach of their voice services to quality of service.

To evacuate its voice traffic, ITADl is based on a premium class (ie a class that guarantees an IP transfer with a better quality of service, for example guarantees a loss rate of 99.999% or a maximum delay of less than 50ms) offered by ASl and AS2; Similarly, ITAD2 uses another premium class offered by AS4. At the IP level. IP network service providers exchange routing information to help build routes in coherent and consistent QoS plans. Thus, the premium class of the AS4 is linked to the premium class of 1ΑS2 through a dedicated inter-domain route. Thus, to join C2 from Cl, two best effort routes (ie the routes available thanks to the activation of a routing protocol such as the BGP (Border Gateway Protocol) exist: that which crosses AS1, AS2 and AS4, and the one that crosses ASl, AS3 and AS4, but only one premium route exists.This road crosses ASl, AS2 and AS4 .To ensure the coherence of the service, voice traffic from C 1 to destination of C2 for the telephone service offered by ITADl uses the premium route and not the best effort route, but, unless a static configuration is implemented, the assurance of obtaining an AS1, AS2 traversing route AS4 can not be certain to be obtained by riTADl, so that it is very likely that, at the moment of the actual transfer of the media streams, they pass through AS1, AS3 and AS4. signaling does not have a direct interface to the IP routing protocols that p support the routing of IP packets. Thus the path of the signaling packets may be different from that of the media packets. In this case, the guarantees negotiated during the establishment of the call are obsolete.

In addition, these centralized and bilateral configuration techniques have the drawback of no longer being in adequacy with the need for coverage, since the number of agreements to be established to offer global coverage becomes important. Furthermore. bilateral agreements at the service level are not enough to offer a quality service. This is because the quality of services received by ^the user also includes that provided by the transfer layer. To support this mode, network operators must then establish IP connectivity agreements of the same nature, with the same level of quality of service. However, given the large number of SAs (more than 17000), such agreements can not be put in place.

3 SUMMARY OF THE INVENTION

The solution proposed by the invention makes it possible to overcome these drawbacks of the prior art, by means of a method for selecting a telephony route of at least one digital stream serving a telephony destination, within a first server. of location belonging to a first telephony domain

IP deployed on at least one autonomous system, said autonomous system exchanging with its neighbors IP routing information designating at least one IP destination to update an IP routing table.

According to the invention, said method comprises the following steps: search by the first location server of said IP routing information, said IP routing information comprising an identifier of a second IP telephony domain with which said at least one destination is associated IP telephony, called destination identifier; selecting said IP telephony route to reach said at least one telephony destination, according to a predetermined second telephony domain selection criterion, according to said destination identifier.

Thus, it is possible to take into account, during the selection of the telephony routes, IP routing information related to the transfer layer. This allows the location server that performs the selection to ^be informed by the autonomic system, IP routes actually used by digital flow during transfer. Autonomous systems therefore communicate with each other IP routes and the locating servers can use this information to perform the selection of the telephony routes.

According to an original feature of the invention, said routing information comprising a list of autonomous system identifiers crossed to reach the telephony destination associated with said identifier of destination, the step of searching for said routing information consists in extracting from said routing table of said autonomous system said list of autonomous system identifiers crossed.

Thus, the invention allows the location server to access a managed routing table at the transfer layer. He can therefore know the roads

IPs chosen to convey media flows to a telephony destination and retrieve the list of autonomous systems traversed.

According to an original characteristic of the invention, said method comprises the following steps: receiving at least one route update message from a second location server, said message defining at least one updated telephony route; comprising a list of traversed autonomous system identifiers and a list of IP telephony domains traversed from said telephony destination; extracting from said list of IP telephony domains the identifier of an IP telephony domain with which said telephony destination is associated, said destination identifier; obtaining a set of at least one telephony route, previously stored in said first location server, serving said telephony destination; search, within said at least one autonomous system, of at least one IP route whose said at least one IP destination is identical to said destination identifier, said IP routes searched; selecting ^a telephony route, within said set of telephony roads, including a list of autonomous systems traversed includes the same identifiers of autonomous systems that the list of autonomous systems identifiers of said at least one searched route, when such a road exists; selecting a telephony route from said set of telephony routing routes, when there is no route of which a list traversed autonomous systems comprises the same identifiers of autonomous systems as said list of autonomous system identifiers, according to at least one predetermined criterion; storing said selected telephony route. The location server performing the selection of the route therefore implements a method that makes it possible to choose a route taking into account the routing information. This method is based on the reception, by the location server, of update messages. These messages include a list of autonomous system identifiers inserted into the telephony route. Thus the telephony route includes information identifying the route

IP borrowed. The location server retrieves the identifier of the telephony domain of the destination and obtains a telephony route list that serves that destination. This obtaining enables him to search, within his own autonomous system, at least one IP route (at the transfer level) which serves this destination. The system can therefore select a route according to two channels or selection criteria: if it identifies, within the set of telephony routes, a route whose list of autonomous systems crossed includes the same autonomous system identifiers as the list autonomous system identifiers of the searched route, then it selects this identified route; if not, it selects a route that serves the same destination according to another criterion. It can, for example, be the first telephony route found.

The server then stores this selected route. It will then be used for the routing of digital flows during a routing process.

According to a particular aspect of the invention, such a method comprises a step of transmitting at least one route update message to a location server, said message defining at least one updated telephony route comprising at least one identifier of at least one autonomous system and at least one identifier of at least one IP telephony domain. Thus, the location server keeps its peers informed of the selection it has made. The other location servers are therefore able to use and take into account this route.

According to a particular characteristic of the invention, such a method comprises the following steps: receiving at least one route update message from a second location server located in said first telephony domain, said message defining at least one updated telephony route comprising a list of traversed autonomous system identifiers and a list of IP telephony domains traversed from said destination; storing said at least one updated telephony route.

The location server therefore has the ability to receive updated telephony routes by its peers located in the same telephony domain as itself. It can therefore realize an immediate storage of this road.

According to a particular aspect of the invention, said list of autonomous system identifiers is ordered according to at least one predetermined scheduling criterion and said selection step takes account of said at least one predetermined scheduling criterion. The list of identifiers allows the location server to identify the autonomous systems used by the telephony route. This list, for a given route, can be ordered, namely to indicate, for example, the order in which the autonomous systems are traversed by the digital stream. Thus the location server is aware ^of the standard of scheduling and the order given to autonomous road systems. The selection of the telephony route by the autonomous system can take into account this scheduling, in order, for example, to optimize the telephony path.

According to an original feature of ^the invention, the list of independent identifiers servers ^is not orderly and said selection step takes into account the first identifier of said autonomous system identifier list. When the list is not ordered, the process selection step implemented by the location server is only the first identifier of the list. So even if a location server transmits a road that ^is not ordered, the location server that processes this information is able to realize a route selection based on the road that has been provided by the message update.

The invention also relates to a device for selecting a telephony route of at least one digital stream serving a telephony destination within a first location server belonging to a first IP telephony domain deployed on at least one system. autonomous transfer system, said autonomous system exchanging with its neighbors IP routing information designating at least one IP destination to update an IP routing table,

According to ^the invention, said device comprises the means of: searching said IP routing information, said IP routing information comprising an identifier of a second IP telephony domain which is associated with said at least one destination IP telephony, said identifier destination; selecting said IP telephony route to reach said at least one telephony destination, according to a predetermined second telephony domain selection criterion, according to said destination identifier.

More generally, such a device comprises means for implementing the steps of the method of selecting telephony routes, as described above. In another embodiment, the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.

According to the invention, in at least one embodiment, such a computer program product includes program code instructions for ^the execution of the telephony route selection process as described above.

The invention also relates to a propagation signal for implementing the routing route propagation method. According to ^the invention, such a signal comprises a route update message including data representative of a list of identifiers of crossed autonomous systems and a list of IP telephony domains traversed from said destination.

4 LIST OF FIGURES Other features and advantages of the invention will emerge more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and nonlimiting example, and the appended drawings, among which: : Figure 1, already commented, shows an example of telephony domain architecture (ITAD); 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; FIG. 3 describes the spiral phenomenon of the AS occurring during the choice of a telephony route according to the techniques of the prior art; FIG. 4 illustrates the need to obtain synchronization between the transport layer and the service layer;

Figure 5 depicts the new routing database structure for an LS according to the invention; FIG. 6 illustrates an example of synchronization realized using the method according to the invention.

DETAILED DESCRIPTION OF THE INVENTION 5.1 Recall of the principle of invention

The invention therefore proposes to perform a synchronization between the transfer layer and the service layer in order to avoid the AS spiral phenomena and the quality of service depreciation. The general principle of the invention rests on the taking into account by a

ITAD, new routing parameters related to the particular AS borrowed by the media stream when selecting ^a route for a destination. This is made possible by the modification of the structure of the routing information management database (TRJB). In relation with FIG. 5, the new organization of the TRIP routing tables is presented.

"Adj-TRIBs-In" 22: stores the routing information conveyed by UPDATE messages. These routing infoπnations, also called "routes", are the inputs of a route selection process 21 ("Decision Process"). A given LS maintains a table "Adj-TRIB-In" 22 (for adjacent TRIB in which stores the set of route advertisements received from an adjacent LS) by neighbor LS;

"Ext-TRIB" 24: only one "Ext-TRIB" table ("TRIB externat") is maintained by LS. This table contains the result of a route selection process applied to the external roads ("Adj-TRIBs-fN") and local roads 26 ("Local Routes"). The techniques of the prior art only allow to choose one route 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 TRlB out"): These are the routes that the local LS will announce to their peers.

We introduce a new table called "Cache Local_RIB" 27. This cache is provided by the IP connectivity provider (Administrative Entity managing an AS) either as a set of permissions to access the routing tables or by l intermediate of an "looking glass" (process for visualizing IP routes on IP backbones). This table can be, for example, the copy of the routing tables (RIB,

Route Information Base for ASBR

("Autonomous System Border Router" for "Autonomous System Border Routers") of the I ¹ AS managed by the IP Network Service Provider in question.

This new table is used, for example, by a TRIP route selection process to ensure synchronization between the transport layer and the service layer.

5.2 Description of an embodiment In the standard version of the "TRIP" protocol, provision is made for the exchange of routing information between two neighboring LSs by means of an update "UPDATE" message. This UPDATE message has a number of attributes. One of these "TRIP route" attributes contains routes associated with given destinations. The prior art only makes it possible to announce one route per destination because the conventional route selection process allows only one route to be selected (also known as the best route).

For each "TRIP Route" we associate specific route attributes such as the path of the ITADs (the two attributes that inform this type of information are "AdvertisementPath" and "RoutedPath"), the next hop (indicated by the attribute " NextHopServer "), etc.

To allow synchronization between the two Service and Transport layers, the following configuration procedure is implemented:

Each ITAD has an identifier in the form of an AS number or a routable IP address; - This identifier is the same as that used by the TRIP protocol to provide the attributes "AdvertisementPath" and "RoutedPath";

ITAD identifiers are announced in an interdomain routing protocol such as BGP or q-BGP. These identifiers may not be the true IP addresses of the LSs; - Each IP connectivity service provider (administrative entity managing the AS) provides IP telephony operators (managing an ITAD) an interface or a cache of its local routing table (Cache_Local_RlB) filled in by an inter-domain routing protocol such as BGP or q-BGP. This cache is updated at the request of IP telephony service providers or dynamically through another mechanism;

The spirals that could be created at the IP level are eliminated at the service layer by each LS by activating a mechanism for identifying the ASs borrowed by a given route (see 5.4). Thus the TRJP roads no longer contain AS spirals; Subsequently, the following route selection procedure is applied:

On receipt of a TRJP "UPDATE" message from a neighboring LS, the local LS extracts:

The last element of the "RoutedPath" attribute for each "TRIP Route" contained in the UPDATE message. This element is the identifier of the ITAD with which the prefix of the road in question is associated, which is noted ITADid. For all routes that serve prefixes attached to the same ITAD, ITADid is identical; The destination of the road, noted DEST;

The local LS queries the local RIB cache (ie Cache_Local_RIB) between domains to find the path to join

ITADid. If a route exists, then the LS retrieves the BGP attribute

"AS_PATH" (BGP specific attribute) This attribute informs the list of IP domains traversed by the BGP route in question.

If the attribute "AS-PATH" is of type "AS_SET" (that is to say not ordered), the local LS searches in its "Adj_TRIB_In" the existence of other routes towards DEST, whose list of AS used to carry voice traffic with identical characteristics to

"I'AS_PATH". This route is then selected by the TRIP route selection process and stored in the "Local_TRIB" table. If no route exists then the LS executes a standard selection process or other local politics;

If the ASJPATH attribute is of type AS_SEQUENCE (that is to say, ordered), the LS extracts the identifier of the first AS from the list, that is to say the identifier of the next AS, denoted ASid. The LS then searches, among the routes to DEST, contained in the Adj_TRIB_ln, the one whose next provider of IP connectivity is identical to ASid. This route is then stored in the "Local_TRIB" table. If no route exists then the LS executes a standard selection process or other local policies; 5.3 Example of implementation To illustrate the synchronization procedure, consider the example illustrated in Figure 6. Suppose that ITADl 61 1 uses ASl 621 to evacuate its voice traffic, that ITAD2 612 uses AS2 622, that ITAD3 613 uses ASl

621, ITAD4 614 uses AS2 622, ITAD5 615 uses AS3 623 and ITADό 616 uses AS6 626. It is assumed that to join D 602 from S 601, the AS path chosen by Inter-domain routing protocol is ASl, AS2, AS3, AS6 (621,

622, 623, 626). It is also assumed that all ITADs apply the procedure described above.

ITAD6 announces its prefixes to ITAD5 and ITAD3; - ITAD3 and ITAD5 have no routes other than those received from ITAD6 to serve ITADό prefixes including D. Therefore, ITAD3 and ITAD5 store these routes in their local TRlBs and announce (through UPDATE messages). These prefixes to ITAD4 for rITAD5 and ITAD2 for TITAD3; - The same procedure applies for ITAD4 and ITAD2 from FITAD3 and riTAD5. These propagate the prefixes of ITAD6 to ITADl; ITADl receives two routes to serve the same prefixes, it consults the cache of local routing tables provided by I ^" ASl to find the route selected by the inter-domain routing protocol to the ITADô identifier .This query returns the path { AS2, AS3, AS6}. ITADl chooses the TRlP route received from ITAD4 and stores it in its table

Local TRIB.

Thus, both transfer and service plans are synchronized.

5.4 Identification mechanism of the ASs borrowed by a given route To enable the transfer of quality of service parameters and the selection of QoS routes, a new attribute is introduced, containing information on the list of AS crossed for route voice traffic. More clearly, the invention allows the service layer to identify the ASs, or IP connectivity operator used for voice traffic. Knowledge and propagation of such information at the level of a

LS allows many applications and optimizations for the management of the TRIP protocol. For example, in a particular implementation, this information can improve the quality of service. Moreover, always thanks to this information, 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 the data travels.

The present application describes only the principle of information feedback, ^or identifiers for the IP layer. A list of identifiers relating to the IP layer is obtained, and then propagated between the LSs implemented by the ITADs.

Specifically, a new attribute containing an AS number is now described. It identifies the IP connectivity provider at the transport layer to carry voice. This number is provided to an administrative management domain (ITAD) which forwards it to a neighboring domain.

This document presents an embodiment based on the location servers LS. It is understood that this embodiment is ^that an example of implementation. Especially. the invention can quite be implemented using proximity servers (also called "proxy" servers).

5.4.1 Format

Conventionally, it is recalled that the TRlP protocol is implemented by the LS (location servers) that propagate TRIP routes, containing attributes to qualify the routes exchanged.

Specifically, the standard version of the TRIP protocol (detailed in Rosenberg et al .: RFC3219: "Telephony Routing over IP (TRlP)" of January 2002) provides for alternate routing information between two neighboring LSs via the UPDATE message. which has a number of attributes.

In order to know the IP connectivity service provider used to route the voice traffic of an ITAD, a new attribute named ASJP ATH is introduced. This attribute includes the following attributes:

Conditional Mandatory; True TRIP Code Type: To be defined by IANA.

Conditional Mandatory: This attribute indicates whether the attribute in question should be filled in or not in a TRIP message.

TRIP Type Code: The unique identifier of the TRlP message in question. The purpose of this attribute is to create and store a list of traversed ASs to reach the destination in question. In ^other words, it is an attribute of the service layer which contains information relating to the transport layer. It is then propagated from an IP telephony domain (ITAD) to a neighboring IP telephony domain.

The AS_PATH attribute is composed of a sequence of segments, or fields, "AS path". Each segment "AS path" is composed of a triplet <path segment type, path segment length. path segment value>, defined as follows: each "path segment type" has a length of 1 byte which can take the following values:

I I I

I Value i Type of segment each path segment length has a length of 1 byte and contains the number of AS 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.

5.4.2 Procedure

It is recalled that the operators each have one or more LSs. Each LS maintains a routing table that it feeds with the announcements received from the neighbors and LSs of its own domain. These ads are updated and redistributed to other neighbors if the agreements allow.

According to the invention, when an LS propagates a TRIP route that it has learned in an UPDATE message from another neighboring LS, it is expected that it modifies the new AS_PATH attribute of the route according to the type of LS to which it is to re - propagate the route, according to the following procedure.

When a given LS announces the route to another TRIP LS peer located in its own ITAD, this LS does not modify the AS_PATH attribute related to that route.

If the LS to which the route is advertised (LS peer) is not located in the same ITAD, two cases arise for the update of the attribute AS_PATH: if the first segment of the AS_PATH is of type AS_SEQUENCR, the local system adds the number of its IP connectivity service provider as the last element of the sequence; if the first segment of the AS_PATH is of type AS_SET, the local system adds a new segment of type AS_SEQUENCE at the beginning of the AS_PATH; this new segment contains the domain number of its IP connectivity service provider.

If the LS is the origin of the advertisement, 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. In addition, the LS includes an empty AS P ATH in all UPDATE messages to send to its TRIP peers in its own ITAD.

Claims

A method of selecting a telephony route of at least one digital stream serving a telephony destination, within a first location server belonging to a first IP telephony domain deployed on at least one autonomous system, said autonomous system exchanging with its neighbors IP routing information designating at least one IP destination to update an IP routing table, characterized in that said method comprises the following steps: search by the first location server of said routing information IP, said IP routing information comprising an identifier of a second IP telephony domain which is associated with said at least one IP telephony destination, said destination identifier; selecting said IP telephony route to reach said at least one telephony destination, according to a predetermined second telephony domain selection criterion, according to said destination identifier.

A selection method according to claim 1, wherein said routing information comprises a list of traversed autonomous system identifiers making it possible to reach the telephony destination associated with said destination identifier, said method being characterized in that the step searching for said routing information consists in extracting from said routing table of said autonomous system said list of autonomous system identifiers crossed.

3. A selection method according to claims 1 and 2, characterized in that it comprises the following steps of: receiving at least one route update message from a second location server, said message defining at least one updated telephony route comprising a list of traversed autonomous system identifiers and a list of IP telephony domains traversed from said telephony destination; extracting from said list of IP telephony domains the identifier of an IP telephony domain with which said telephony destination is associated, said destination identifier; obtaining a set of at least one telephony route, previously stored in said first location server, serving said telephony destination; search, within said at least one autonomous system, of at least one IP route whose said at least one IP destination is identical to said destination identifier, said IP routes searched; selecting a telephony route within said set of telephony routing routes, a list of autonomous systems traversed comprising the same autonomous system identifiers as said list of autonomous system identifiers of said at least one route; when such a road exists; selecting a telephony route from said set of telephony routing routes, when there is no route whose list of autonomous systems traversed comprises the same autonomous system identifiers as said list of autonomous system identifiers. according to at least one predetermined criterion; storage of said selected telephony route.

4. Selection method according to any one of claims 1 to 3, characterized in that it comprises a step of transmitting at least one route update message to a location server, said message defining the at least one updated telephony route comprising at least one identifier of at least one autonomous system and at least one identifier of at least one IP telephony domain.

5. Selection method according to any one of claims 1 to 4, characterized in that it comprises the following steps: receiving at least one route update message from a second location server located in said first domain of telephony, said message defining at least one updated telephony route comprising a list of traversed autonomous system identifiers and a list of IP telephony domains traversed from said destination; storage of said at least one updated telephony route,

6. A selection method according to any one of claims 1 to 5, characterized in that said list of autonomous system identifiers is ordered according to at least one predetermined scheduling criterion, and in that said selection step takes account of said at least one predetermined scheduling criterion.

7. A selection method according to any one of claims 1 to 6, characterized in that said list of autonomous server identifiers is not ordered, and in that said selection step takes into account the first identifier of said list of servers. autonomous system identifiers.

8. A device for selecting a telephony route of at least one digital stream serving a telephony destination within a first location server belonging to a first IP telephony domain deployed on at least one autonomous transfer system, said autonomous system exchanging with its neighbors IP routing information designating at least one IP destination for updating an IP routing table, characterized in that it comprises means for: searching for said IP routing information, said routing information IP comprising an identifier of a second IP telephony domain which is associated with said at least one IP telephony destination, said destination identifier; selecting said IP telephony route to reach said at least one telephony destination, according to a predetermined second telephony domain selection criterion, according to said destination identifier.

9. Computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of the method production according ^to at least one of claims 1 to 7 when executed on a computer.

10. Selection signal for the implementation of the method according to any one of claims 3 to 7, characterized in that it comprises a route update message comprising data representative of a list of identifiers of traversed autonomous systems and a list of IP telephony domains traversed from said destination.