Method for setting up communication paths between access points of a switching system, and switching system implementing said method

CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 METHOD FOR ESTABLISHING COMMUNICATION PATHS BETWEEN ACCESS POINTS OF A SWITCHING SYSTEM, AND SWITCHING SYSTEM IMPLEMENTING THE PROCESS The present invention relates to a method of establishing communications between access points of a switching system The invention applies in particular, but not exclusively, to a branch office network (PABX) in which access points (lines to terminals or radio terminals, connections to networks or to specialized lines, etc.) are organized in clusters each managed by a 1o control unit cluster control (UCG).

Each cluster control unit has some autonomy to manage communications or other service supplies involving the access points that depend on it.

In particular, the UCG comprises a memory where tables are stored containing various data relating to the terminals which are connected to it and making it possible in particular to manage the faculties available to the terminals.

This hardware architecture induces the software concept of half-call.

Signaling processing relating to the establishment of a communication (or other service provision) through an access point comprises on the one hand access point control tasks to identify events (off-hook, on-hook, dialing , busy, etc.) from the access point and translate them into messages from the switching system and to send various commands to the access point (ringing, tones, displays, etc.), and on the other hand call management tasks to process the requests concerning the access point (according in particular to the rights defined in the tables) and to supervise the access point control tasks.

The signaling relating to a communication between several access points proceeds by exchanges of messages between the half-calls concerned.

Advantageously, the call management tasks use messages according to formats and protocols standardized in the switching system, while the access point control tasks provide the translations necessary to take into account the specific features of the different types of terminals. or networks likely to be connected.

The above architecture is well suited to the case of fixed terminals CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -2 linked to the UCGs at invariable addresses.

The half-call concerning such a terminal can be entirely executed at the level of the UCG to which it is connected (reference UCG).

Patent application EP-A-0 790 748 describes a way of adapting it to the case of mobile radio terminals capable of entering into communication by means of radio terminals connected to UCGs visited which are distinct from their reference UCGs, the UCG. reference point of a terminal being generally that where the relevant data concerning this terminal are stored.

The success of networks operating according to the IP protocol (Internet 1o Protocol, Request For Comment (RFC) 791 published by the Internet Engineering Task Force (IETF) in September 1981) has led to the development of protocols in real time (RTP, Real Time Protocol and RTCP, Real Time Control Protocol, RFC 1889, IETF, January 1996) capable of supporting telephony traffic.

Telephony terminals are now available which are connected to such networks (IP terminals).

These IP terminals can in particular take the form of conventional telephones associated with appropriate adapters, of telephone terminals that can be connected directly to the IP network (for example Webphone), or even of microcomputers equipped with telephony software (for example Netmeeting marketed by the company Microsoft).

The success of IP networks suggests on the other hand to use them in the field of switching, and more particularly in the field of enterprise switching, to interconnect different entities of the switching system.

A company's local IP network (Intranet) can thus be used to interconnect separate PBXs.

In addition, an IP network can advantageously provide a means of connection for IP terminals, so that the implementation of voice and data communication systems operating entirely according to the IP protocol can be envisaged.

The IP terminals are then managed by call servers directly connected to the IP network.

French patent application No. 00 08897 describes an example of the architecture of such systems.

The coexistence of the two architectures mentioned above is made essential by the need to take into account the current infrastructures CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -3 in the process of migration to networks operating entirely according to the IP protocol.

In an architecture combining PABX networks of the type indicated above and packet switched networks, some of the UCGs ("gateway UCG") are then equipped with gateway interfaces with a packet switched network such as a network. IP.

These gateway interfaces convert the flows exchanged between the two types of network, in accordance with the operation of a media gateway ("Media GateWay", or MGW) and of its controller ("Media Gateway Controller" or MGC) as described in the TIPHON project ("Telecommunications and Internet Protocol Harmonization Over Networks) of ETSI (" European Telecommunication Standard Institute ").

Such a gateway interface provides an access point connected to the IP network, and also allows the implementation of communications on the IP network involving conventional terminals, analog or digital, which are not directly connected to the IP network. , without however necessarily including an access point for these "classic" terminals. Conversely, an MGW typically provides an access point for different types of "classic" terminals, and includes an access point connected to the IP network.

It is thus possible to envisage the establishment of communication paths between all types of terminals whether or not carried by the IP network.

Patent application PCT / FROO / 02740 describes a way of optimizing the establishment of the communication path when a gateway interface with an IP network intervenes.

The choice of the communication path can be made on request by a topology server, as a function of criteria specific to the system, and of the location information of the terminals involved in the communication.

This process, when leading to the establishment of a communication path between the PABX network and the packet switched network, uses resources of the gateway UCG during communication.

However, such flexibility gives rise to cost constraints, in particular from the perspective of a rapid increase in traffic on the CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -4 packet switched networks.

Indeed, the large number of conventional terminals installed on existing traditional networks benefiting from an update with interfaces to packet transmission networks makes it possible to provide for a massive use of gateway interfaces, so that it is desirable to optimize the switching systems with a view to optimal use of these gateways, the unit cost of which is relatively high.

For example, the possibility of making multiple simultaneous calls from the same terminal, conventional or IP, can lead to the reservation of 1o several gateways, each for a single call, while the user will only use them. 'only one at a given time.

This example is particularly that of operator stations in a switching system.

An aim of the present invention is to optimize the use of the resources mobilized by communications in networks using gateways of the type indicated above.

The invention thus proposes a method for establishing communication paths between access points of a switching system, the switching system comprising a packet transmission network providing a first family of access points, means switching devices equipped with connection interfaces providing a second family of access points and at least one gateway interface with the packet transmission network, and call processing means for storing configuration data and context data relating to terminals connected to the system through the access points, and for performing signaling processing relating to said terminals. The establishment of a first communication path between access points to link first and second terminals respectively connected to said access points comprises the following steps when the first path comprises at least a first portion belonging to the network of transmission of packets and a second portion belonging to the switching means with a gateway interface between said first and second portions:

CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -5- associating with said first portion an addressing resource of the gateway interface in the packet transmission network for the link with the first terminal;

- Associating with said second portion an addressing resource of the gateway interface in the switching means for the link with the second terminal; and memorizing, in the context data relating to the second terminal, an identification of said addressing resource of the gateway interface in the packet transmission network.

Thus, the second terminal may have a dual appearance vis-à-vis the other access points of the system, namely the native appearance of its access point, and the complementary appearance corresponding to the other family of points. access.

This complementary appearance is achieved by storing in the context data of the terminal an addressing resource of a gateway which is associated with it during the establishment of the first communication path.

The call processing executed for another terminal having to enter into communication with it will thus be able to choose, among these two appearances, the one which allows the most judicious use of the resources of the gateways.

In particular, to link the second terminal with a third terminal without cutting off the link with the first terminal, the call processing means can read in the context data relating to the second terminal the stored identification of said resource. addressing of the gateway interface in the packet transmission network, and establishing a second communication path including the second portion of the first path and at least one other portion belonging to the packet transmission network, with which they associate the addressing resource read from the gateway interface for the link with the third terminal .

The process is symmetrical, so that, alternatively or cumulatively, the establishment of the first communication path can include the storage, in the context data relating to the first terminal, of an identification of said addressing resource of the network. 'gateway interface in the switching means.

CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -6 Another aspect of the present invention relates to a switching system comprising a packet transmission network providing a first family of access points, means switching devices equipped with connection interfaces providing a second family of access points and at least one gateway interface with the packet transmission network, and call processing means for storing configuration data and context data relating to terminals connected to the system through the access points, and for performing signaling processing relating to said terminals in accordance with a method such as defined above.

Other features and advantages of the invention will appear in the following description of non-limiting embodiments, with reference to the appended drawings, in which:

- Figure 1 is a diagram of a switching system according to the invention;

FIG. 2 is a block diagram of a cluster control unit of the system of FIG. 1; and - Figures 3 to 7 are diagrams illustrating examples of call signaling in the system of Figure 1.

FIG. 1 shows an example of a communication system built from an IP network made up of two local networks (LAN, Local Area Network) 54, 55 linked together by means of a wide area network (WAN, Wide Area Network) 56.

The WAN plays the role of interconnection between the subnetworks 54, 55 formed by the LANs.

It could advantageously be replaced by a backbone network if the load constraints of the system justify it.

The system also integrates one or more automatic exchanges (PABX) or sites 10, 20, 30, 40.

Each site has a cluster organization.

It thus comprises one or more cluster control units (UCG) 11-13, 21-25, 31-34, 40.

Each UCG has sufficient resources to support communications between its own access points.

Each site 10, 20, 30 comprising several UCGs is equipped with a transport loop 18, 28, 38 allowing inter-UCG exchanges in a CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -7 to be supported communications between several access points belonging to the same site. By way of example, the loop 18, 28, 38 can be a 40 Mbits / s digital line organized in timeshare to support 512 circuit switched channels (circuit channels) and 70 packet switched channels (packet channels) .

Circuit channels are intended for access points whose operation requires the reservation of a circuit resource, while packet channels are intended for access points used by packet-switched communications and for the exchange of commands. specific to the switching system (in particular the signaling functions).

Control units (not shown) are provided in the sites 10, 20, 30 to supervise the operation of the transport loops 18, 28, 38.

When the system has several sites, inter-site lines 52, 53 (for example private MIC lines or leased to a public operator) are possibly provided between some of their UCGs 25, 32, 34, 40.

Various IP terminals 41-44 are directly connected to LAN 54, 55.

An IP terminal 44 can be a conventional telephone 47 associated with an adapter 48 for connection to the IP network, a telephone terminal 41, 42 incorporating an IP interface or else a microcomputer 43 executing a telephony application on an IP network. In a manner known per se, the adapter 48 may consist of a media gateway (MGW), optionally driven by a media gateway controller (MGC) (not shown in the figure) supporting protocols such as Megaco (see Megaco Protocol, Internet draft, IETF, February 21, 2000).

In the example shown, each cluster control unit comprises a set of access points to the system, which can serve as an interface with different types of lines, according to the desired compatibilities.

Access points can in particular be provided for the connection of conventional telephony terminals (that is to say non-IP) 35, analog (simple S63 terminals or intelligent terminals) or digital (X.25 terminals, ISDN, etc. .).

For external communications, one or more UCG 13, 40 can also include interfaces for connection to external networks such as a switched telephone network (PSTN) 50, a CA 02432822 2003-06-20 WO 02 / 052826 PCT / FR01 / 03918 -8 integrated services digital network (ISDN) and / or a digital packet switched network (X.25).

To possibly allow communications with mobile terminals 36 (for example CT2 or DECT), some UCGs can include radio access points connected to respective radio terminals 37.

In this case, such an access point is of the conventional type.

If the terminal is connected to the system via the IP network, the corresponding access point will be of the IP type.

Certain UCGs 11, 21, 40, known as gateway UCGs, are also connected to LAN 54, 55.

Each gateway UCG is provided with one or more gateway interfaces each having a determined address in the IP network.

In the example shown, the sites 10, 20 and 40 are respectively connected to the LANs 54, 55 and 55 by their UCG gateways 11, 21 and 40.

FIG. 2 is a block diagram of a gateway UCG 11, which comprises a set of access points, as well as, where appropriate, an interface 111 with the transport loop 18 of the site. The UCG 11 incorporates access points for analogue terminals 32, ISDN 34 and for the connection of radio terminals 37, as well as a gateway access point for connection to LAN 54. The interface 111 with the transport loop 18 of the site consists, for example, of repeaters for retransmitting the frames circulating on the loop 18, associated with an automaton for separating the packet channels and the circuit channels and with buffer memories for the extraction. and inserting signals relating to the UCG.

Each access point of a UCG 11 has a physical interface 112-115, which provides the physical signaling functions (detection of events, commands, etc.), translation and formatting necessary for the compatibility of devices connected to the access points with the formats used in the switching system.

Each of the interfaces 111-115 is connected to the bus 116 of a processor 118 associated with a memory 119.

They are on the other hand connected to a switching matrix 117, which operates a physical switching, under the control of the processor 118, between time multiplexed channels in accordance with a multiplexing scheme specific to the UCG.

The processor 118 provides CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -9 in particular the signaling processing concerning the access points of the UCG: it is informed of the events detected by the interfaces 111-115 and performs the appropriate processing to configure the switch matrix 117, address signaling messages to interface 111 and commands to physical interfaces 112-115.

The IP interface 112 is connected to the LAN 54, to an IP address allocated to the gateway UCG.

Under this address, it uses one or more logical TCP ports (Transmission Control Protocol, RFC 793, IETF, September 1981) for signaling exchanges, and UDP (User Datagram Protocol, RFC 768, IETF, August 1980) logical ports for the various RTP-RTCP sessions opened to transport coded speech.

The RTP / UDP ports are associated with translation modules linked to the switching matrix 117.

The IP terminals 41-44 are advantageously managed by two call servers 57, 58 directly connected to the IP network 54-56 according to standardized protocols, for example in accordance with the H.323 standard of the ITU (International Telecommunications Union) , directly or through proxy servers (see French patent application No. 00 05824).

There could also be a single call server for the entire IP network.

In a second embodiment of the invention, each of these call servers corresponds to the call server of a gateway UCG 11, 21, 40.

Such UCGs then serve as reference UCGs for IP terminals, which a priori only know the IP address of the gateway interface of their reference UCG, to which they send their requests, and whose gateway interface relays then, if necessary depending on the configuration of the communication path, the voice signals to the destination. Conversely, in a third embodiment of the invention, the conventional terminals 35-36, which can only reach the IP network through the PABXs 10, 20, 30, 40, can be attached to a server. call located on the IP network.

It suffices for this that the UCGs relay the signaling between these terminals and the gateway interfaces. Ultimately, a single call server on the IP network could be used for all the terminals.

A terminal connected to the IP network knows a priori only the IP address CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -10 of its call server, and it sends its requests to this server.

A terminal connected to the PABX network, for its part, knows its reference UCG, which it always knows how to reach (via the packet channels of the PABX network).

In the remainder of the present description, it is assumed, without this being limiting, that an IP terminal can send and receive speech coded according to the ITU-T G.729 standards (8 kbit / s coding by linear prediction with excitation by coded sequences with conjugated algebraic structure - CSACELP), ITU-T G.723.1 (compression by predictive coding at 6.4 or 5.3 kbit / s), 1o and possibly ITU-T G.711 (PCM coding at 64 kbit / s), and that the transmission of speech within the PABX sites, between the PABX sites and the conventional terminals 35 and between the PABXs and the radio terminals 37 is in the form G.711.

Thus the gateway interface 112 is designed to perform G.711 / G.723.1 or G.711 / G.729 transcoding when this is required for an IP terminal operating in G.723.1 or G.729.

Two software utilities, the GIC (Inter Communications Manager) and the GCC (Communication Path Manager), perform, on request from call processing tasks, the management of signaling channels and communication paths, respectively.

For the transmission and reception of its messages, the call processing is addressed to the GIC in the form of primitives.

By addressing mechanisms known per se (point-to-point addressing, broadcasting, selective broadcasting, etc.), it is possible to reach one, several, or all of the call servers of the system.

In conjunction with the operational system of the call server on which it is installed, the GIC manages the routing of messages.

For seizure / release and connection / disconnection of the communication path, the call processing is addressed to the GCC also in the form of primitives.

When it comes to reserving a path, the GCC utilities of the two half-calls dialogue directly with each other.

A half-call concerning a terminal comprises the creation of a task called Simple Call Monitor (T_MAS) in a call server associated with the terminal, whether or not it is integrated into a UCG of a PABX.

This T_MAS task performs all the analysis and decision functions (routing CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -11 of call, faculty request, etc.) involved in call management .

For these functions, the T_MAS task consults tables stored in the call server, notably containing the association between the directory number of the terminal and a corresponding IP address, at which this terminal can be reached.

This address can be the terminal's own IP address if it is of the IP type, or the IP address of a gateway interface otherwise.

These tables also define the rights of the user.

In the remainder of the description, it will be considered that when a call server, associated with a terminal, is integrated into a UCG of a PABX 10, 20, 30, 40, this server is located in the reference UCG from the terminal.

Thus, each telephone terminal 35-36 directly connected to the PABX network has a -U-CG-de-attached (reference UCG) which, in the case of a wired terminal, is typically the one to which it is connected.

This home UCG notably handles signaling processing concerning the terminals.

Each terminal of the system is managed by a call server, organized according to the various possibilities described above, which has location information relating to each supervised terminal.

This location information consists of the identification of a UCG of the PABX network, called a “topology reference UCG”. The topology reference UCG coincides with the reference UCG, if applicable.

When no reference UCG is attached to a terminal connected to an access point of the IP network, the topology reference UCG is also chosen from the gateway UCGs connected to the same sub-network as the terminal.

In the case shown in FIG. 1, the gateway UCG 11 is for example the topology reference UCG of the IP terminals 41 and 44 connected to the LAN 54, while the gateway UCG 21 is the topology reference UCG of the terminals. IP 42 and 43 connected to LAN 55.

As seen above, the call server of a terminal connected to an access point of the IP network can be, in the second embodiment of the invention, the server integrated into one of the UCGs. of the PABX network, called the terminal reference UCG, in which case all the terminals of the system have a reference UCG. The reference UCG of a terminal connected to an access point of the IP network then preferably coincides with the reference UCG of the terminal.

Each IP terminal stores the address CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -12 in the IP network of a gateway interface of its reference UCG, to which it sends all its requests.

For example, signaling is transmitted over the IP network in accordance with the ITU-T H.323 standard in TCP transport protocol sessions established between two call servers or between an IP terminal and its call server. .

In the second embodiment of the invention, the gateway UCG then plays, seen from the IP network, a gatekeeper role within the meaning of H. 323.

Another possibility is to code presentation patterns defined 1o for the switching system by means of a page description language such as XML (eXtended Markup Language), as described in patent application WO 00/70844.

If the terminal is suitable for this type of presentation, it displays the test patterns specific to the system described in the XML messages constructed by its gateway interface, and it can provide the signaling information required in response to these messages.

Different types of software modules are used to perform signaling processing.

A half-call thus comprises the creation of a T_MGC task which performs the interface functions with the T_MAS task of the call server, while a T_MGW task manages the details specific to each type of access point.

Thus, the T_MAS task executed in the call server does not manipulate. only terminal equipment identified by IP addresses and / or directory numbers.

In the diagrams of FIGS. 3 to 7, the establishment of communication paths between two terminals, one requesting (dr) and the other requested (d), is considered.

It will be observed that the call scenario is essentially the same when one of the access points concerned is connected to a network external to the system and not to a terminal: the external correspondent can be calling or called, and the half-call corresponding will typically be executed in the UCG equipped with the interface for connection to the external network.

Each half-call concerning a terminal involves the execution of a call processing task (T_TAP), which combines the aforementioned T_MAS and T_MGC / T_MGW tasks.

Depending on the architecture of the call servers, these CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -13 T_MAS and T MGC / T_MGW tasks can be executed at the level of different entities communicating with each other according to protocols appropriate. It is for the sake of clarification of the presentation of the call scenarios that the invention is illustrated in the particular case where the whole of the T TAP task is executed in a reference UCG, which avoids making the distinction. between T_MAS, T_MGC and T MGW.

The left part of each diagram corresponds to the calling half-call, and the right part to the requested half-call.

Each call scenario represented begins with an exchange of information between the requesting terminal 70, 170 and the T TAP task 71, 171 1o which corresponds to it.

This T_TAP task was for example created by the call server of the requesting terminal 70, 170 on receipt of a message indicating that the line was seized by this terminal.

It sends the terminal the test patterns encoding the information to be presented to the user (displays, tones, etc.), and retrieves the data provided by the user to define his request (choice of functions, numbering, etc.).

When the exchange with the requesting terminal 70, 170 allows it to have sufficient information, the T TAP task 71, 171 broadcasts in the system a setup message (SET UP) comprising in particular the following elements:

- the directory number of the calling terminal 70, 170;

the directory number of the requested terminal 80, 180, defined directly or indirectly by the user of the requesting terminal 70, 170;

the location of the requesting terminal 70, 170 in the system, namely the site number of the topology reference UCG and the number of this UCG in the site;

- the type of connection of the requesting terminal, appearing in the tables of its reference UCG whose call server executes the T_TAP task 71, 171; this element makes it possible in particular to distinguish conventional terminals from IP terminals.

For a requesting terminal of conventional type, the establishment message 3o also includes a physical equipment number designating the site interface to which the terminal is connected.

In some cases, it also includes the IP address of at least one gateway interface of a UCG temporarily associated with the terminal in the 54-56 network and two CA numbers 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -14 UDP ports reserved under this interface for this terminal, one dedicated to the transmission of speech according to the RTP protocol and the other to the transmission of control information according to the RTCP protocol.

For an IP type requesting terminal, the setup message includes an indication of the encodings and rates with which it is compatible (in the simplified example mentioned above, G.711 only, G.711 + G.723.1, G. 711 + G.723.1 + G.729 or G.711 + G.729), the IP address of the terminal in the 54-56 network, a UDP port number that it devotes to the transmission of speech according to the RTP protocol and another UDP port number 1o for the transmission of control information according to the RTCP protocol.

The call servers to which this message is broadcast analyze the number of the requested terminal.

The only server which takes the message into account, by creating a task T_TAP 81, 181 for processing the half-call on the arrival side, is the call server which supervises the requested terminal.

This task 81, 181 queries a topology server 90 to determine a configuration of the call.

In the example shown in FIG. 1, the system comprises three topology servers 90, two of which are connected to access points, respectively of the UCG 13 of the site 10 and of the UCG 23 of the site 20, and the third directly to the IP 54-56 network.

These servers contain essentially the same data. One of them is selected by the running call processing task.

It will be noted that many other implementations would be possible, for example providing a single topology server or more, or even producing the topology server in the form of tables simply stored in each call server capable of interrogating it.

The topology server 90 is interrogated on the basis of two sets of parameters, one relating to the requesting terminal 70, 170 and the other relating to the requested terminal 80, 180.

Each set of parameters relating to a terminal includes:

- the type of terminal connection (IP or classic);

- the location in the system (site numbers of the topology reference UCG and number of this UCG in the site);

CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -15- for an IP type terminal, the indication of the codings and the bit rates with which it is compatible.

For the requesting terminal, these parameters are obtained by the T TAP task 81, 181 in the establishment message received.

For the requested terminal, they are read in the data specific to the terminal stored in the server of the UCG, by means of the directory number obtained in the establishment message received.

The topology server receives requests sent by the call processing task on the arrival (requested) side in response to the reception of the 1o communication establishment message (SET-UP).

The call configuration designated by the topology server 90 in response to its interrogation leads in certain cases to the establishment of a communication path using the IP network, including when one of the requesting and requested terminals is of type classic. Conversely, the topology server may have to request the establishment of a communication path carried by the network of PABX sites, including omitted when one of the requesting and requested terminals is of the IP type.

The invention provides for the possibility for each terminal to present, in addition to its native type, a complementary type (IP for a conventional terminal, and conventional for a native IP terminal).

The presentation of this double appearance can occur a priori, that is to say prior to the request for establishment of the call on the calling side.

It can also intervene on request, that is to say to serve a call configuration selected by the topology server.

At the time when the presentation of the IP appearance is decided for a conventional terminal, the call processing task of the reference UCG of the terminal consults a gateway designation table 92 to identify a gateway enabling the terminal to be reached.

Table 92 is built during system configuration.

It corresponds to each cluster control unit 11-13, 21-25, 31-34, 40 a gateway UCG (or even several) whose gateway interface can, depending on the configuration of the system, enter into link with the access points of said cluster control unit without going through the IP network.

The table 92 can by CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -16example be stored in each UCG, in order to be able to be consulted in the processing of each half-call.

When setting up a new gateway to the IP network, it broadcasts on the IP network, to all UCGs, its location (site, UCG) as well as the location (site, UCG) of each UCG to which it has access inside the PABX system without going through the IP network.

As a variant, the gateways table 92 could be stored in a server accessible within the PABXs or on the IP network.

The call processing task of the reference UCG of the conventional terminal can thus obtain a list of locations (site number, UCG number in the site) of appropriate gateways UCG in order to be able to present the IP appearance.

Preferably, the gateway UCGs accessible from the reference UCG without going through the IP network, and in particular the gateway UCGs belonging to the same site as the reference UCG, if any exist.

The T_TAP task then sends another setup message (SET_UP), which it directs to the UCG (s) designated by the gateways table 92. On receipt of this message, the gateway unit management task 96 (T_MGK) executed by the processor of a concerned gateway UCG examines whether the gateway interface has resources for the communication being established (FIGS. 4 and 7).

If so, it reserves two UDP port numbers for the RTP and RTCP links, and responds to the T_TAP call processing task by returning the physical equipment number of the available gateway interface, its IP address in the network and the two reserved UDP port numbers.

The call server of the conventional terminal having the IP appearance then writes these parameters in memory 119 in a table of resources 97, so that these parameters can be used again in the event of one or more calls established while the first call, which led to the reservation of these resources, is still in progress. Whenever a conventional terminal participates in a call whose configuration requires the reservation of communication path resources on the IP network giving it the appearance of an IP terminal temporarily, a single set of parameters (gateway IP address, UDP ports) is thus kept in table 97 and CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -17 used until deletion of the last call context for this terminal.

Such a terminal thus has a dual appearance, one native (conventional), and the other virtual (IP).

As shown in FIGS. 4 and 5, the resource table 97 is consulted by the call processing task on the requesting side before the broadcast of the call establishment message (SET UP).

The calling half-call can have, where appropriate, a dual appearance of the calling terminal to the requested half-call, which simplifies the process of establishing the call according to the configuration designated by the topology server, and minimizes unnecessary use of the system's gateway interfaces.

A preferred embodiment of the invention, illustrated in the diagrams of FIGS. 3 to 7, favors the acquisition of a double appearance for conventional terminals.

A systematic double-appearance search can be implemented, in a very similar manner, for all the terminals of the system, or only for the IP terminals, in order to give them a classic appearance.

Thus, in the diagrams of FIGS. 4 to 7, the T TAP task 71, 81 relating to the conventional terminal interrogates, on the basis of the directory number of the calling party (FIGS. 4 and 5) or of the called party (FIGS. 6 and 7), its resource table 97, to check whether a resource corresponding to the IP type is not already used for a communication in progress in which the conventional terminal is participating.

In the examples of Figures 4 to 7, the T TAP task concerned verifies that a gateway interface has not already been reserved for use by the terminal (Figures 4 and 5) or requested (Figures 6 and 7), that is, this terminal has not already taken on an IP appearance.

If so, it immediately has a double set of parameters corresponding to the temporary duality of types available for the terminal, which it can if necessary (Figures 4 and 5) transmit in the 3o establishment message to the destination of the requested half-call.

In the example of FIG. 5, it thus transmits the UCG number of the gateway interface in which the voice over IP transport resources are reserved, the IP address and the UDP port numbers temporarily allocated to the terminal. for its or CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -18 its communications in progress.

The resource table 97 is updated (FIGS. 4 and 7) once the call server has presented the complementary appearance of the terminal, in order to make available the parameters in use for possible subsequent simultaneous calls. concerning the terminal.

At the end of each communication, the call processing task checks that the current call context is not the last for the terminal for which it manages the half-call.

If this is the case, it removes the double-appearing data since this data has become obsolete given that the terminal no longer participates in any communication and it is desired to minimize the unnecessary reservation of resources in the gateways.

In the case of a call between two IP terminals 170, 180, the call configuration designated by the topology server 90 in response to its interrogation may correspond to the diagram in FIG. 3.

In this configuration, the coded speech is exchanged between the terminals directly on the IP network 54-56.

The T TAP task 181, executed in the call server (gateway UCG) on the arrival side, sends to the IP address of the requested terminal 180, if it is available, the pattern indicating the incoming call, with the address IP of the requesting terminal 170 and the UDP ports used by the latter for the communication, which it a.obtu in the setup message.

In addition, it returns to the T TAP task 171 of the outgoing half-call the alert message signaling the start of ringing to the requested terminal, with the IP address of the requested terminal 180 and the UDP ports used by it for the call. communication.

This alert message is retransmitted in the form of a test pattern to the requesting terminal 170, with the IP address of the requested terminal 180 and the UDP ports used.

When the requested terminal 180 takes the line, the event is signaled to the T_TAP 181 task which informs the T_TAP 171 task in a connection message retransmitted in the form of a test pattern to the requesting terminal 170.

Communication can then take place, 3o directly between the UDP ports for the traffic part, and within the framework of the TCP / IP sessions between the terminals and their reference UCGs for the signaling part.

In the case where the dual appearance can be presented for the CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -19 IP terminals, the transmission of the SET_UP message by the TAP task 171 is preceded by a consultation of the resource table 97 of the call server (not shown in FIG. 3).

Where appropriate, the parameters relating to the conventional appearance of the terminal 170 (coordinates of one or more gateways) are then included in the SET_UP message.

In the case of a call from a conventional type terminal 70 to an IP terminal 180, the call configuration designated by the topology server 90 in response to its interrogation may correspond to the diagram of FIG. 4, in the case of an initial call, and in the diagram of FIG. 5, in the first case of simultaneous multiple calls.

Preferably, the topology server 90 favors in these two cases a communication path carried by the IP network.

In the diagram of FIG. 4, the task T_TAP 181 on the arrival side, which receives the response from the topology server, requests the presentation of the complementary appearance by the requesting terminal, given that it has not received in the message establishment that the parameters relating to the latter corresponding to its conventional type.

For this, it sends the T TAP task 71 of the other half-call an event request message (EVENT_REQUEST), in which it indicates the configuration designated by the topology server 90.

On receipt of this message indicating to it that an IP appearance is necessary, the T_TAP task 71 consults the gateway designation table 92 on the basis of the location (site, UCG) of the requesting terminal 70 to identify the UCG of at at least one gateway interface from which the requesting terminal 70 is accessible without going through the IP network.

The T TAP task 71 then sends a resource reservation request message, which it directs to the UCG (s) designated by the table 92. On receipt of this message, the gateway unit management task 96 ( T_MGK) executed by the processor of a concerned gateway UCG examines whether the gateway interface has 3o resources for the communication being established.

If so, it reserves two UDP port numbers for the RTP and RTCP links, and responds to task 71 by returning the physical equipment number of the available gateway interface, its IP address in the network 54-56 and the CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -20 two reserved UDP port numbers.

The task 71 then sends an EVENT REPLY message to the task 181 which contains the voice transport parameters on the IP network for the requesting terminal, that is to say the physical equipment number of the interface. available gateway, its IP address in the network and the two reserved UDP port numbers it received from the gateway UCG.

In the diagram of FIG. 5, the T TAP task 181 on the arrival side which receives the response from the topology server already has the parameters describing the double appearance of the requesting terminal since it received them 1o in the SET_UP establishment message .

It thus has the parameters necessary for establishing the call configuration designated by the topology server.

The call establishment phase then continues in both cases as follows: the T_TAP task 181, executed in the gateway UCG on the arrival side, sends to the IP address of the requested terminal 180, if it is available, the pattern indicating the incoming call, with the IP address relating to the requesting terminal 70 and the UDP ports used by the gateway under this address for communication.

The T_TAP 181 task controls, using the GCC utility, the establishment of a communication path in the PABX network, then returns to the T_TAP 71 task of the outgoing half-call the alert message signaling the start of ringing at the requested terminal, with the IP address of the requested terminal 180 and the UDP ports used by the latter for communication.

This alert message is retransmitted in the form of a test pattern to the requesting terminal 70 and communicated to the gateway interface management task 96, with the IP address of the requested terminal 180 and the UDP ports used.

The task T MGK 96 of the UCG of the gateway interface completes the communication path on the requesting side by controlling the IP interface 112, the switching matrix 117 and the interface 111-115 to which the terminal is connected so that the interfaces ensure the required translations and that the matrix 117 make them communicate with each other.

When the requested terminal 180 takes the line, the event is signaled to the T TAP 181 task which informs the T_TAP 71 task in a CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -21 connection message (CONNECT) retransmitted in the form of a test pattern to the requesting terminal 70.

Communication can then take place:

- the speech encoded in G.711 transmitted by the conventional terminal 70 is routed to the gateway interface within one or more PABXs, possibly transcoded, then sent over the IP network to the IP address and to the UDP port associated with the requested IP terminal:

- the IP terminal 180 sends its coded speech in the form of RTP packets to the UDP / IP port which has been indicated to it with the incoming call pattern, and the organ management task T_MGK of the destination gateway interface reconstitutes the encoded speech signal flow, if necessary performs a transcoding, and retransmits the speech encoded in G.711 to the conventional terminal 70;

- the T_TAP 71 and 181 tasks (more precisely the T MGW and / or T MGC tasks) remain in effect until the end of the communication, as does the TCP / IP session carrying the signaling between the IP terminal 180 and its UCG reference.

In the case of a call from an IP terminal 170 to a conventional type terminal 80, the call configuration designated by the topology server 90 in response to its interrogation by the task 81 on the arrival side can correspond to the flow diagram. FIG. 7 in the case of an initial call, and to the diagram of FIG. 6 in the case of simultaneous multiple calls.

Preferably, the topology server 90 favors a communication path carried by the IP network.

The response from the topology server is equivalent in this case to an IP appearance request for any terminal participating in the communication being set up which is not of the IP type.

The call processing task T_TAP 81 on the arrival side therefore consults its resource table 97, to check whether a resource corresponding to the type complementary to the native type of the requested terminal, in this case an IP gateway, is not already used. for an ongoing call in which the called party is participating.

If so (diagram in figure 6), it immediately has the UCG number of a gateway interface, the IP address and the UDP port numbers temporarily allocated to the terminal for its CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -22 Communication in progress.

If not (diagram in FIG. 7), it consults the gateway designation table 92 to identify the UCG of at least one gateway interface from which the requested terminal 80 would be accessible without leaving the PABX network.

It then sends a resource reservation request message, which it directs to the UCG (s) designated by table 92, including the IP address of the requesting terminal 170 and the UDP port numbers that it uses for the RTP protocols. and RTCP. On receipt of this message, the gateway unit management task 96 (T_MGK) executed by the processor of a concerned gateway UCG examines whether the gateway interface has resources for the communication being established.

If so, it reserves two UDP port numbers for the RTP and RTCP links, and responds to task 81 by returning the physical equipment number of the available gateway interface, its IP address in the network and the two numbers. UDP port reserved.

The call establishment phase then continues in both cases as follows: the T TAP task 81, executed in the gateway UCG on the arrival side, sends to the requested terminal 80, if it is available, the test pattern indicating the incoming call, as well as the indication of the gateway interface associated with it.

Task 81 controls, using the GCC utility, the establishment of a communication path.

It returns to the T TAP 171 task of the outgoing half-call the alert message (ALERT) signaling the start of ringing to the requested terminal, a message which provides task 171 with the IP address and the temporarily allocated UDP port numbers. at the terminal.

This alert message is retransmitted in the form of a test pattern to the requesting terminal 170, in one or more TCP / IP segments addressed to the terminal by its reference UCG, with the IP address of the gateway interface to be used and the ports UDP reserved on the requested side for communication.

When the requested terminal 80 takes the line, the event is signaled to the T_TAP task 81 which informs the T TAP task 171 in a connection message (CONNECT) retransmitted in the form of a test pattern to the requesting terminal 170.

The task T_MGK of the UCG of the gateway interface completes the path CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -23 of communication on the requested side by controlling the IP interface 112, the switching matrix 117 and the interface 111-115 to which the terminal is connected so that the interfaces provide the required translations and that the matrix 117 makes them communicate with each other.

Communication can then take place:

- the IP terminal 170 sends its coded speech in the form of RTP packets to the UDP / IP port which has been indicated to it with the alert pattern, and the destination gateway interface reconstitutes the coded speech signal flow, operates the where appropriate, transcoding, and retransmits the speech encoded in G.711 to the conventional terminal 80;

- the speech encoded in G.711 transmitted by the conventional terminal 80 is routed to the gateway interface within one or more PABXs, possibly transcoded, then sent over the IP network to the UDP port which has been specified in the establishment message;

- the T_TAP 171 and 81 tasks (more precisely the T MGW and / or T MGC tasks) remain in force until the end of the communication, as does the TCP / IP session carrying the signaling between the IP terminal 170 and its UCG reference.

In another embodiment of the invention, the double appearance is taken a priori for a requesting terminal, that is to say before knowing the call configuration designated by the topology server 90 .

In this case, the consultation of the resource table 97 takes place as soon as a call setup request is received by the call server of the requesting terminal, and is immediately followed if necessary by a resource reservation by consultation of the table of gateways 92 and of the T MGK task 96.

On the requested side, it is also possible to envisage taking a double appearance a priori, that is to say without having knowledge of the call configuration designated by the topology server 90.

The multiplicity of appearances offered on the requesting and / or requested side may possibly be taken into account in the decision of the topology server.

In this embodiment, it is desirable to free the resources reserved a priori and which prove to be unnecessary in view of the call configuration selected.

The call processing task concerned will therefore send a CA 02432822 2003-06-20 WO 02/052826 PCT / FR01 / 03918 -24 command to update the resource table 97 for the case where there is no longer any context. call other than that of the call in progress for the terminal for which the resource reservation was made.

It should be noted that the IP appearance can be adopted for a conventional terminal even in cases where it would communicate with another conventional terminal.

This occurs in particular if the communication path passes through a gateway interface with the IP network, either because the two classic terminals cannot join without going through the IP network, or because this has been imposed by the topology server. .