EP1221250A2 - Procede d'etablissement de communication entre des terminaux relies a un systeme de commutation, et systeme de commutation mettant en oeuvre le procede - Google Patents

Procede d'etablissement de communication entre des terminaux relies a un systeme de commutation, et systeme de commutation mettant en oeuvre le procede

Info

Publication number
EP1221250A2
EP1221250A2 EP00966266A EP00966266A EP1221250A2 EP 1221250 A2 EP1221250 A2 EP 1221250A2 EP 00966266 A EP00966266 A EP 00966266A EP 00966266 A EP00966266 A EP 00966266A EP 1221250 A2 EP1221250 A2 EP 1221250A2
Authority
EP
European Patent Office
Prior art keywords
terminal
network
gateway
call processing
call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00966266A
Other languages
German (de)
English (en)
Inventor
Jean-Pierre Mercuriali
Daniel Jacob
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EADS Telecom SAS
Original Assignee
EADS Defence and Security Networks SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EADS Defence and Security Networks SAS filed Critical EADS Defence and Security Networks SAS
Publication of EP1221250A2 publication Critical patent/EP1221250A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/64—Distributing or queueing
    • H04Q3/66—Traffic distributors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13034—A/D conversion, code compression/expansion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13148—Maximum profit routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet

Definitions

  • the present invention relates to a method for establishing communications between terminals in a switching system.
  • the invention applies more particularly to a switching system in which the access points (lines to terminals or radio terminals, connections to networks or to dedicated lines, etc.) are organized in clusters each managed by a cluster control unit (UCG).
  • Each cluster control unit has a certain autonomy to manage communications or other provision of services involving the access points which depend on it.
  • the UCG has a memory in which tables are stored containing various data relating to the terminals which are connected to it and in particular making it possible to manage the faculties which the terminals have.
  • Signaling processing concerning the establishment of a communication (or other provision of service) through an access point includes on the one hand control tasks of the access point to identify events (off-hook, on-hook, numbering , occupation ...) from the access point and translate them into messages from the switching system and to address various commands to the access point (ringtone, tones, displays ...), and on the other hand call management to process requests concerning the access point (in particular according 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.
  • 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 account of the specific characteristics of the different types of terminals. or of networks likely to be connected.
  • 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 visited UCGs distinct from their reference UCGs, the UCG of reference of a terminal is generally that where the relevant data concerning this terminal are stored.
  • IP Internet Protocol
  • RTP Real-time protocols
  • RTCP Real Time Protocol
  • RTCP Real Time Control Protocol
  • IP terminals which connect to such networks
  • These IP terminals can in particular take the form of conventional telephones associated with appropriate adapters, telephone terminals connectable directly to the IP network (for example “Webphone”), or even microcomputers equipped with telephony software (for example “Netmeeting”). marketed by Microsoft).
  • IP networks The success of IP networks suggests on the other hand to use them in the field of enterprise switching, to link together different entities of the switching system.
  • a company's local IP network (Intranet) can thus be used to interconnect separate branch exchanges.
  • IP network can advantageously provide a connection means for IP terminals managed by the system.
  • Some of the UCGs are then equipped with gateway interfaces with the IP network, and can serve as a reference UCG for IP terminals connected to this network.
  • Such a terminal a priori only knows the IP address of the gateway interface of its reference UCG, and it sends its requests to this UCG, which then relays the signals to the destination.
  • This process uses resources from the gateway UCG during communication.
  • An object of the present invention is to optimize, in a switching system, the use of resources mobilized by communications involving IP terminals connected to the system by a local network.
  • a method of establishing communication between terminals connected to a switching system comprising several interconnected cluster control units each providing access points to the system.
  • Each terminal is respectively associated, among the cluster control units, with a reference unit which stores data specific to said terminal, used to carry out signaling processing relating to it.
  • At least some of the cluster control units are gateway units respectively equipped with gateway interfaces with an IP network.
  • Some of the terminals are IP type terminals connected to the system via the IP network.
  • the switching system comprises at least one call configuration manager arranged to deliver call configuration data in response to two sets of parameters relating to calling and called terminals, respectively, said set of parameters relating to a terminal including an indication of the connection type of the terminal, which differs depending on whether the terminal is of the IP type or not.
  • the method according to the invention comprises the following steps for establishing communication between first and second terminals comprising calling and called terminals: creation of a first call processing task in the reference unit of the calling terminal;
  • the method minimizes the resources required in the switching system to support communication between an IP-type terminal and a “conventional” (not IP-type) terminal.
  • the system can in each case adopt an appropriate behavior and take full advantage of the routing capabilities of the IP network when possible.
  • the method can comprise an exchange of signaling between the first and second call processing tasks, to provide the second terminal with addressing data from the first terminal in the IP network, and to provide the first terminal with addressing data from the second terminal in the IP network.
  • the two terminals communicate directly through the IP network, while maintaining the link with their reference units only with regard to the signaling functions.
  • the set of parameters relating to an IP type terminal taken into account by the configuration manager, includes information on coding capacities of said terminal, and preferably location information allowing identify a subnetwork of the IP network to which said terminal is connected.
  • the configuration manager then acts as a topology server for the IP network.
  • the selection of the voice path establishment mode by the configuration manager is made according to the coding capacities of the IP terminals and the speed resources available in the IP network (for a simple reason of technical capacity and / or account given the choices made by the network administrator).
  • the configuration manager can also take account of the state of charge of the IP network in order to favor the use of a minimum bit rate coding for voice communications which must pass through this network when it is relatively congested.
  • Another aspect of the present invention relates to a switching system comprising several interconnected cluster control units each providing access points to the system, some at least cluster control units being gateway units respectively equipped with gateway interfaces with an IP network, the system being arranged to implement a method as defined above for establishing communication between terminals connected to it .
  • - Figure 1 is a diagram of a switching system according to the invention
  • - Figure 2 is a block diagram of a cluster control unit of the system of Figure 1;
  • FIGS. 3 to 6 are diagrams illustrating examples of call signaling in the system of Figure 1, respectively between two conventional terminals, from an IP terminal to a conventional terminal, from a conventional terminal to an IP terminal , and between two IP terminals.
  • FIG. 1 shows, by way of illustration, an example of a switching system constructed from three automatic exchanges (PABX) 10, 20, 30.
  • PABX automatic exchanges
  • Each PABX has an organization in clusters. It thus comprises one or more cluster control units (UCG) 11 -13, 21 -25, 30 each comprising a set of access points to the system.
  • the access points can be used to interface with different types of lines, depending on the desired compatibility of the system.
  • One can in particular provide access points for the connection of conventional telephony terminals 32-35, analog (simple S63 terminals or "intelligent" terminals) or digital (X.25 terminals, ISDN, etc.).
  • At least some of the UCGs 13, 22 have access points connected for example to lines of the public switched telephone network (PSTN) 50, of a digital integrated services network (ISDN) and / or of a digital packet switching network (X.25).
  • PSTN public switched telephone network
  • ISDN digital integrated services network
  • X.25 digital packet switching network
  • some of the UCGs may include radio access points connected to respective radio terminals 37, 38.
  • Each UCG has sufficient resources to support communications between its own access points.
  • Each PABX 10, 20 comprising several UCGs is equipped with a transport loop 18, 28, allowing inter-UCG exchanges so as to support communications between several access points belonging to this PABX.
  • the loop 18, 28 can be a digital line at 40 Mbits / s organized in timeshare to support 512 circuit-switched channels ("circuit channels") and 70 packet-switched channels ("packet channels"). ").
  • Circuit channels are provided for access points whose operation requires the reservation of a circuit resource, while packet channels are provided for access points used by packet-switched communications and for command exchanges specific to the switching system (in particular the signaling functions).
  • Control units not shown are provided in PABX 10, 20 to supervise the operation of the transport loops 18, 28.
  • inter-PABX lines 52 are possibly provided between some of their UCGs 25, 30.
  • the switching system cooperates with a computer network supporting the IP protocol.
  • this IP network incorporates two local networks (LAN) 54, 55 linked together via a wide area network (WAN) 56.
  • the WAN 56 plays the role of interconnection between the sub-networks formed by the LANs 54, 55.
  • the PABX 10 is connected to the LAN 54 by an access point of its UCG 11.
  • the PABX 20 is connected to LAN 55 by an access point of its UCG 21.
  • the PABX 30 consisting of a single UCG is connected to LAN 55 by one of its access points.
  • These UCGs 11, 21, 30 provided with IP interfaces are hereinafter called "gateway UCGs".
  • Some of the terminals managed by one or more of the PABXs are terminals of the IP 40-43 type, which are connected to the system via the IP network.
  • a terminal 40 can be a conventional telephone 47 associated with an adapter 48 for connection to the network. It can also be a telephone terminal 41, 42 (“Webphone” for example) incorporating an IP interface, or even a microcomputer 43 executing a telephony application (“Netmeeting” for example).
  • the reference UCG of each IP terminal is a gateway UCG. Without being mandatory, this simplifies the architecture of the system.
  • the UCG 11 is for example the reference UCG of the IP terminals 40 and 41 connected to the LAN 54
  • the UCG 21 is the reference UCG of the IP terminals 42 and 43 connected to LAN 55.
  • Each IP terminal stores the address in the IP network of a gateway interface of its reference UCG, to which it addresses all of its requests.
  • FIG. 2 is a block diagram of a UCG 11 having for example access points for analog terminals 32 and for the connection of radio terminals 37 and a gateway access point for connection to the LAN 54.
  • the UCG 11 includes an interface 60 with the transport loop 18 of the PABX, consisting 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 insertion of signals concerning the UCG.
  • Each access point of the UCG consists of a physical interface 61, 62, 63, which performs the physical signaling functions (event detection, commands, ...), translation and formatting necessary for the compatibility of the devices connected to the access points with the formats used in the switching system.
  • the interface 63 with the LAN 54 can provide signaling and formatting functions according to a standardized protocol, for example according to ITU Recommendations H.225, H.245 and H.323 -T.
  • a standardized protocol for example according to ITU Recommendations H.225, H.245 and H.323 -T.
  • code presentation patterns defined for the switching system by means of a page description language such as XML (“eXtended Markup Language”), as described in French patent application 99 06159.
  • the terminal is suitable for this type of presentation, it displays the system-specific patterns described in the XML messages constructed by its gateway interface, and it can provide the signaling information required in response to these messages.
  • Signaling is transmitted over the IP network using sessions of the Transmission Control Protocol (TCP) established between two gateway UCGs or between an IP terminal and its gateway UCG.
  • TCP Transmission Control Protocol
  • the usual protocol is the UDP transport protocol ("User Datagram Protocol") and the real-time protocols RTP and RTCP.
  • the gateway interfaces 63 are therefore able to construct and retrieve UDP / IP datagrams in accordance with the RTP and RTCP protocols.
  • Different speech coding / decoding modes can be used by IP terminals 40-43 and gateway interfaces 63.
  • the audio coding may be in accordance with one of ITU-T Recommendations G.711, G.722, G.723.1, G.728 and G.729.
  • an IP terminal can transmit and receive speech coded in G.711 (PCM coding at 64 kbit / s), and possibly in G.723.1 (compression by predictive coding at 6.4 or 5.3 kbit / s), and that speech transmission within PABX, between PABX and conventional terminals 32-35 and between PABX and radio terminals 37, 38 is in the form G.711.
  • the gateway interface 63 is arranged to perform a G.711 / G.723.1 transcoding when it is required for an IP terminal operating in G.723.1.
  • the various interfaces 60-63 are connected to a switching matrix 64 which ensures the routing of the signals.
  • the operation of the UCG 11 is controlled by a processor 65 associated with a memory 66.
  • the processor 65 controls the interfaces 60-63 via its bus 67 either directly (interfaces 60, 62, 63 in the example of Figure 2) either through the switching matrix 64 (interfaces 61).
  • the processor 65 provides in particular the signaling processing concerning the access points of the UCG: it is informed of the events detected by the interfaces 60-63 and performs the appropriate processing to configure the switching matrix 64, to send signaling messages to interface 60 and commands to physical interfaces 61-63.
  • processor 65 For the interface with the transport loop of the PABX, processor 65 has two software utilities: the GIC (Inter Communications Manager) which manages the packet channels and the GIM (Multisite Time Interval Manager) which manages the channels circuits.
  • the GIC Inter Communications Manager
  • the GIM Multisite Time Interval Manager
  • the call processing is addressed to the GIC in the form of primitives.
  • the GIC manages the routing of messages.
  • the call processing is addressed to the GIM also in the form of primitives.
  • the GIM utilities of the two half-calls interact directly with each other.
  • Different types of software modules are used by processor 65 to perform signaling processing. A half appeal concerning a terminal thus involves the creation of the following tasks:
  • the MGO Organic Management Monitor
  • MAS level the higher level
  • IGO Organic Management Interface
  • the GO detects the elementary events produced by the terminal, processes them and translates them into telephone events transmitted to the MAS by messages conforming to the internal signaling standard of the system. It passes on to the terminal the commands expressed by the
  • the MAS Simple Call Monitor
  • the MAS consults tables stored in memory 66 and in particular defining the rights of the user and the faculties accessible by the terminal.
  • the MAS controls the Organ Manager.
  • the organ manager is adapted to the type of organ it controls, the MAS is independent of the type of organ. This independence is preserved by the MAS / MGO interface, the formats of which are standardized within the system.
  • MGO is common to a family of applications while IGO is more specific.
  • each half call concerning a terminal is managed by a call processing task (TAP) executed by the processor 65 of the reference UCG of the terminal.
  • TAP call processing task
  • This TAP task groups together the aforementioned MAS and MGO / IGO tasks, between which the distinction is not made to simplify the representation of the call scenarios.
  • the left part of each diagram corresponds to the requesting half call, and the right part to the requested half call.
  • Each represented call scenario begins with an exchange of information between the calling terminal 70, 170 and the call processing task 71, 171 which corresponds to it.
  • This task 71, 171 has for example been created by the processor 65 of the reference UCG of the calling terminal 70, 170 on reception of a message signaling the line seizure by this terminal. It sends the test patterns coding the information to be presented to the user to the terminal (displays, tones, ...), and retrieves the data provided by the user to define his request (choice of functions, numbering, ).
  • the UCG broadcasts in the system an establishment message (SET_UP), comprising in particular the following elements: - the directory number of the terminal called 80, 180, defined directly or indirectly by the the user of the calling terminal 70, 170;
  • the location of the calling terminal 70, 170 in the system namely the site number of the reference UCG (a site which may correspond to a PABX 10, 20, 30) and the number of this reference UCG in the site ;
  • the UCGs to which this message is broadcast analyze the number of the called terminal.
  • This task 81, 181 interrogates a topology server 90 to determine a configuration of the call. In the example shown in FIG.
  • the system comprises two topology servers 90, one connected to an access point of the UCG 13 of the PABX 10, and the other connected to an access point of UCG 25 of PABX 20.
  • These two servers contain essentially the same data, one or the other being interrogated according to the UCG where task 81, 181 is executed. It should be noted that many other implementations would be possible, for example providing a single topology server or more, connecting a topology server to the IP network, or even create the topology server in the form of tables simply stored in each UCG capable of interrogating it.
  • the topology server 90 is interrogated on the basis of two sets of parameters, one relating to the calling terminal 70, 170 and the other relating to the terminal called 80, 180.
  • Each set of parameters relating to a terminal comprises:
  • these parameters are obtained by the TAP task 81, 181 in the establishment message received.
  • these parameters are read from the terminal-specific data stored in the UCG, by means of the directory number obtained in the establishment message received.
  • the call configuration designated by the topology server 90 in response to its interrogation corresponds to the diagram in FIG. 3.
  • the TAP task 81 of the incoming half-call executed in the reference UCG of the called terminal 80, commands the establishment of a communication path between the access points of the calling and called terminals 70, 80. If applicable (multi-site call), this communication path can partly borrow the IP network between two UCG gateways.
  • the TAP task 81 sends directly to the called terminal 80, if available, the test pattern indicating the incoming call, and it returns to the TAP task 71 of the outgoing half-call an alert message to signal the start of ringing. terminal called.
  • This alert message is retransmitted in the form of a test pattern to the calling terminal 70, via the line connecting this terminal to its reference UCG, which is the one that performs the TAP task 71.
  • the called terminal takes the line, the event is reported to the TAP task 81 which informs the TAP task 71 thereof in a connection message retransmitted in the form of a test pattern to the calling terminal 70.
  • the communication can then take place conventionally.
  • one of the terminals is hung up, the other is informed thereof via the TAP tasks 71, 81 before they are withdrawn.
  • the call configuration designated by the topology server 90 in response to its interrogation can correspond to the diagram in FIG. 4.
  • the arrival side TAP 81 task does not immediately have a physical equipment number for the calling terminal, since the latter is connected by an IP network in which there is no notion of connection. It then sends the TAP task 171 of the other half-call an event request message, in which it indicates the configuration of the call in progress as well as the location (site, UCG) of the terminal called 80.
  • the task 171 consults a gateway designation table 92 to identify the UCG of at least one gateway interface from which the called terminal 80 is accessible without going through the IP network.
  • the table 92 is constructed during the configuration of the system. It corresponds to each cluster control unit 11-13, 21-25, 30 a gateway unit (or even several) whose gateway interface can, depending on the system configuration, connect with the access points of said cluster control unit without going through the IP network.
  • the table 92 can for example be stored in each gateway UCG, in order to be able to be consulted in the processing of each half-call concerning an IP terminal.
  • When setting up a new gateway to the IP network it broadcasts over the IP network, intended for all UCGs comprising gateways, its location (site, UCG) as well as location (site, UCG ) of each UCG to which it has access inside the PABX system without going through the IP network.
  • the gateway table 92 could be stored in a server accessible within the PABX or on the IP network.
  • the TAP task 171 when it receives an event request message indicating the location (site, UCG) of a terminal called of the conventional type, the TAP task 171 can obtain in the table 92 the location (site, UCG) of each appropriate gateway. It then sends a second establishment message, which it directs to the UCG (s) designated by table 92, including the IP address of the calling terminal 170 and the UDP port numbers that it uses for the protocols. RTP and RTCP.
  • the gateway management task 95 executed by the processor of a gateway UCG concerned examines whether the gateway interface has resources for the communication being established.
  • Task 171 reserves two UDP port numbers for the RTP and RTCP links, and responds to task 171 by returning the physical equipment number of the available gateway interface, its IP address in the network and the two numbers reserved UDP port.
  • Task 171 can then respond to task 81 by providing the physical equipment number of a gateway interface.
  • task 81 commands, using the GIM utility, the establishment of a communication path, which does not pass through the IP network, between the gateway interface and the access point of the terminal called 80.
  • this terminal 80 sends this terminal 80, if it is available, the test pattern indicating the incoming call, and it returns to the TAP task 171 of the outgoing half-call the alert message signaling the start of ringing at the called terminal.
  • This alert message is retransmitted in the form of a test chart to the calling 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 in it for communication.
  • the called terminal 80 takes the line, the event is signaled to the TAP task 81 which informs the TAP task 171 in a connection message retransmitted in the form of a test pattern to the calling terminal 170.
  • the 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 reconstructs the coded speech signal flow, operates the if necessary a transcoding, and retransmits the speech coded in G.711 to the conventional terminal 80;
  • the G.711 coded speech sent by the classic 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 second establishment message;
  • TAP tasks 171 and 81 (more precisely GO tasks) remain in force until the end of the communication, as does the TCP / IP session transporting the signaling between the IP 170 terminal and its reference UCG.
  • the call configuration designated by the topology server 90 in response to its interrogation can correspond to the diagram in FIG. 5.
  • the TAP task 181 executed in the gateway UCG on the arrival side does not immediately have a physical equipment number for the terminal called. She then consults the gateway designation table 92 based on the location (site, UCG) of the calling terminal 70, which it obtained in the establishment message, to identify the UCG of at least one gateway interface from which the calling terminal 70 is accessible without passing through the IP network.
  • the TAP task 181 then sends a second establishment message, which it directs to the UCG (s) designated by table 92, including the IP address of the terminal called 180 and the UDP port numbers that it uses for the RTP and RTCP protocols (the UCG executing task 181 has these address and port numbers in the tables which it stores about the called terminal whose number appeared in the first establishment message).
  • the gateway organ management module 96 (GO-P) executed by the processor of a gateway UCG concerned 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 181 by returning the physical equipment number of the available gateway interface, its IP address in the network and the two numbers reserved UDP port.
  • the task 181 commands, using the GIM utility, the establishment of a communication path, which does not pass through the IP network, between the gateway interface and the access point of the calling terminal 70. It sends to the IP address of the called terminal 180, if available, the test pattern indicating the incoming call, with the IP address of the gateway interface to be used and the UDP ports reserved in it for communication, and it returns to task TAP 71 of the half call start the alert message signaling the start of ringing at the called terminal. This alert message is retransmitted in the form of a test pattern to the calling terminal 70.
  • the called terminal 180 takes the line, the event is signaled to the TAP task 181 which informs the TAP task 71 thereof in a retransmitted connection message. in the form of a test pattern at the terminal calling 70. Communication can then take place:
  • the speech coded in G.71 1 transmitted by the conventional terminal 70 is routed to the gateway interface within one or more PABX, possibly transcoded, then sent over the IP network to the UDP port which has been specified in the second establishment message;
  • 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 destination gateway interface reconstitutes the coded speech signal flow, operates if necessary a transcoding, and retransmits the speech coded in G.711 to the conventional terminal 70;
  • the call configuration designated by the topology server 90 in response to its interrogation can correspond to the diagram in FIG. 6. In this configuration, the coded speech is exchanged between the terminals directly on the IP 54-56 network.
  • the TAP task 181 executed in the gateway UCG on the arrival side, sends to the IP address of the called terminal 180, if available, the test pattern indicating the incoming call, with the IP address of the calling terminal 170 and the UDP ports used by the latter for the communication, which it obtained in the establishment message. In addition, it returns to the TAP task 171 of the half-call start the alert message signaling the start of ringing at the called terminal, with the IP address of the called terminal 180 and the UDP ports used by the latter for the communication. . This alert message is retransmitted in the form of a test pattern to the calling terminal 170, with the IP address of the called terminal 180 and the UDP ports used.
  • the event is signaled to the TAP task 181 which informs the TAP task 171 in a connection message retransmitted in the form of a test pattern to the calling terminal 70.
  • the communication can then take place, directly between the UDP ports for the traffic part, and in the context of TCP / IP sessions between the terminals and their reference UCGs for the signaling part.
  • the decision between the four call configurations illustrated in Figures 3 to 6 can be taken by the topology server 90 on the sole basis of the connection types of the calling and called terminals.
  • a refinement consists in taking into account the coding capacities of IP terminals.
  • the configuration data returned by the server 90 can thus include instructions to use this or that type of coding in IP terminals, which the call processing tasks transmit to the terminals and gateway interfaces concerned.
  • the system administrator can therefore favor low-speed transmissions (for example G.723.1 rather than G.711) over the IP network to limit its congestion by telephone traffic. It can also possibly avoid transcoding at the level of the gateways if there are constraints on the computation capacities of these (favor the use of G.711 by the terminals if the congestion of the network allows it).
  • the configuration retained by the server for each call can depend on dynamic parameters on the congestion of the IP network or the load of the interfaces.
  • the coding capacities of the IP terminals can also be taken into account in the choice of the coding scenario according to FIG. 4, 5 or 6, particularly in the case where the location of the terminals is also taken into account.
  • This location information makes it possible, for an IP terminal, to identify a subnetwork of the IP network, that is to say one of the LANs 54, 55, to which this terminal is connected.
  • the topology server 90 can order the implementation of the configuration Figure 4, 5 or 6 as long as the communication can take place without going through the WAN. But if the other terminal involved is on another site and requires passage through WAN 56, a G.711 / G.723.1 transcoding will have to be carried out, which requires a different call configuration.
  • the topology server 90 responds to the games parameters presented to it by controlling the configuration according to FIG. 5 (and not according to FIG. 6, although the two terminals are of the IP type).
  • the gateway interface of the reference UCG 11 of terminal 41 will play the same role as the connection interface of a conventional terminal: during communication, it will operate transcoding, and will dialogue in G.711 with terminal 41 and in G.723.1 with terminal 42 through the IP network.
  • the conventional terminal 34 is the terminal called by the terminal 41
  • the topology server 90 controls the configuration according to FIG. 3, and not according to FIG. 4.
  • the topology server 90 responds to the sets of parameters presented to it by controlling the configuration according to FIG. 4 (and not according to FIG. 6, although the two terminals are of the IP type). Similarly, if the conventional terminal 32 is the terminal calling the terminal 43, the topology server 90 controls the configuration according to FIG. 3, and not according to FIG. 5.
  • the server 90 includes tables constructed by integrating the knowledge of the topology of the switching system and of the IP network, which make it possible to associate the configuration data appropriate to each pair of sets of parameter parameters calling / terminal called.

Landscapes

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

Abstract

Les points d'accès au système sont organisés en unités de contrôle de grappe interconnectées (11-13, 21-25, 30). Certaines de ces unités (11, 21, 30) sont équipées d'interfaces passerelles avec un réseau IP (54-56). Certains des terminaux sont de type IP (40-43) et reliés au système par l'intermédiaire du réseau IP. Le système comporte un gestionnaire de configuration d'appel (90) qui délivre des données de configuration en réponse à deux jeux de paramètres relatifs à des terminaux appelant et appelé, respectivement, le jeu de paramètres relatifs à un terminal incluant une indication de type de raccordement IP/non IP du terminal. Au moyen de ce gestionnaire (90), le procédé minimise les ressources requises pour supporter la communication entre un terminal IP et un terminal 'classique'. En distinguant différentes configurations d'appel, le système peut dans chaque cas profiter au maximum des capacités de routage du réseau IP lorsque c'est possible.

Description

PROCEDE D'ETABLISSEMENT DE COMMUNICATION ENTRE DES TERMINAUX RELIES A UN SYSTEME DE COMMUTATION. ET SYSTEME DE COMMUTATION METTANT EN ŒUVRE LE PROCEDE
La présente invention concerne un procédé d'établissement de communications entre terminaux dans un système de commutation
L'invention s'applique plus particulièrement à un système de commutation dans lequel les points d'accès (lignes vers des terminaux ou des bornes radio, raccordements à des réseaux ou à des lignes spécialisées...) sont organisés en grappes gérées chacune par une unité de contrôle de grappe (UCG). Chaque unité de contrôle de grappe possède une certaine autonomie pour gérer les communications ou autres fournitures de services impliquant les points d'accès qui en dépendent. En particulier, l'UCG comporte une mémoire où sont stockées des tables contenant diverses données relatives aux terminaux qui lui sont reliés et permettant notamment de gérer les facultés dont les terminaux disposent.
Cette architecture matérielle induit le concept logiciel de demi-appel.
Les traitements de signalisation concernant l'établissement d'une communication (ou autre fourniture de service) à travers un point d'accès comprennent d'une part des tâches de contrôle du point d'accès pour identifier des événements (décroché, raccroché, numérotation, occupation...) issus du point d'accès et les traduire en messages du système de commutation et pour adresser diverses commandes au point d'accès (sonnerie, tonalités, affichages...), et d'autre part des tâches de gestion d'appel pour traiter les requêtes concernant le point d'accès (en fonction notamment des droits définis dans les tables) et pour superviser les tâches de contrôle du point d'accès. La signalisation relative à une communication entre plusieurs points d'accès procède par des échanges de messages entre les demi-appels concernés.
Avantageusement, les tâches de gestion d'appel utilisent des messages selon des formats et protocoles standardisés dans le système de commutation, tandis que les tâches de contrôle de points d'accès assurent les traductions nécessaires pour tenir compte des spécificités propres aux différents types de terminaux ou de réseaux susceptibles d'être raccordés.
L'architecture ci-dessus est bien adaptée au cas de terminaux fixes reliés aux UCG à des adresses invariables. Le demi-appel concernant un tel terminal peut être entièrement exécuté au niveau de l'UCG à laquelle il est raccordé (UCG de référence). La demande de brevet EP-A-0 790 748 décrit une manière de l'adapter au cas de terminaux radio mobiles susceptibles d'entrer en communication au moyen de bornes radio reliées à des UCG visitées distinctes de leurs UCG de référence, l'UCG de référence d'un terminal étant généralement celle où sont stockées les données pertinentes concernant ce terminal.
Le succès des réseaux fonctionnant selon le protocole IP (« Internet Protocol ») a conduit à développer des protocoles en temps réel (RTP, « Real Time Protocol », et RTCP, « Real Time Control Protocol ») capables de supporter du trafic de téléphonie. On dispose maintenant de terminaux de téléphonie qui se raccordent à de tels réseaux (« terminaux IP »). Ces terminaux IP peuvent notamment prendre la forme de téléphones classiques associés à des adaptateurs appropriés, de terminaux téléphoniques raccordables directement au réseau IP (par exemple « Webphone »), ou encore de micro-ordinateurs équipés de logiciels de téléphonie (par exemple « Netmeeting » commercialisé par la société Microsoft).
Le succès des réseaux IP suggère d'autre part de les utiliser dans le domaine de la commutation d'entreprise, pour relier entre elles différentes entités du système de commutation. Le réseau local IP d'une entreprise (Intranet) peut ainsi servir à interconnecter des autocommutateurs distincts. En outre, il peut avantageusement fournir un moyen de liaison pour des terminaux IP gérés par le système.
Dans l'architecture évoquée ci-dessus, certaines des UCG sont alors équipées d'interfaces passerelles avec le réseau IP, et peuvent servir d'UCG de référence pour des terminaux IP raccordés à ce réseau. Un tel terminal ne connaît a priori que l'adresse IP de l'interface passerelle de son UCG de référence, et il adresse ses requêtes à cette UCG, laquelle relaie ensuite les signaux vers la destination. Ce processus utilise des ressources de l'UCG passerelle en cours de communication. Un but de la présente invention est d'optimiser, dans un système de commutation, l'utilisation des ressources mobilisées par des communications faisant intervenir des terminaux IP raccordés au système par un réseau local.
Selon l'invention, il est proposé un procédé d'établissement d'une communication entre des terminaux reliés à un système de commutation, le système de commutation comprenant plusieurs unités de contrôle de grappe interconnectées fournissant chacune des points d'accès au système. Chaque terminal est respectivement associé, parmi les unités de contrôle de grappe, à une unité de référence qui mémorise des données propres audit terminal, servant à effectuer des traitements de signalisation le concernant. Certaines au moins des unités de contrôle de grappe sont des unités passerelles respectivement équipées d'interfaces passerelles avec un réseau IP. Certains des terminaux sont des terminaux de type IP reliés au système par l'intermédiaire du réseau IP. Le système de commutation comporte au moins un gestionnaire de configuration d'appel agencé pour délivrer des données de configuration d'appel en réponse à deux jeux de paramètres relatifs à des terminaux appelant et appelé, respectivement, ledit jeu de paramètres relatifs à un terminal incluant une indication de type de raccordement du terminal, qui diffère selon que le terminal est ou non de type IP. Le procédé selon l'invention comprend les étapes suivantes pour établir une communication entre des premier et second terminaux comprenant des terminaux appelant et appelé : - création d'une première tâche de traitement d'appel dans l'unité de référence du terminal appelant ;
- formation, par la première tâche de traitement d'appel, d'un message d'établissement incluant au moins le numéro du terminal appelé et l'indication de type de raccordement du terminal appelant ; - en réponse à la réception dudit message d'établissement, création d'une seconde tâche de traitement d'appel dans l'unité de référence du terminal appelé ;
- interrogation du gestionnaire de configuration par la seconde tâche de traitement d'appel, sur la base d'un jeu de paramètres relatifs au terminal appelant extraits du message d'établissement et d'un jeu de paramètres relatifs au terminal appelé déduits par la seconde tâche de traitement d'appel à partir du numéro reçu dans le message d'établissement ; et
- lorsque les données de configuration d'appel retournées par le gestionnaire de configuration correspondent à une possibilité d'échanger, directement à travers le réseau IP, du trafic entre ledit premier terminal et au moins une interface passerelle depuis laquelle ledit second terminal est accessible sans passer par le réseau IP, échange de signalisation entre les première et seconde tâches de traitement d'appel et une tâche de gestion d'une interface passerelle, afin d'établir entre ladite interface passerelle et le second terminal un chemin de communication ne passant pas par le réseau IP, de fournir à ladite interface passerelle des données d'adressage du premier terminal dans le réseau IP, et de fournir au premier terminal des données d'adressage ladite interface passerelle dans le réseau IP.
Le procédé minimise les ressources requises dans le système de commutation pour supporter la communication entre un terminal de type IP et un terminal « classique » (qui n'est pas de type IP). En distinguant différentes configurations d'appel, le système peut dans chaque cas adopter un comportement approprié et profiter au maximum des capacités de routage du réseau IP lorsque c'est possible. Ainsi, lorsque les données de configuration d'appel retournées par le gestionnaire de configuration correspondent à une possibilité d'échanger, directement à travers le réseau IP, du trafic entre lesdits premier et second terminaux, le procédé peut comprendre un échange de signalisation entre les première et seconde tâches de traitement d'appel, afin de fournir au second terminal des données d'adressage du premier terminal dans le réseau IP, et de fournir au premier terminal des données d'adressage du second terminal dans le réseau IP. Dans ce cas, les deux terminaux dialoguent directement par le réseau IP, en ne conservant la liaison avec leurs unités de référence qu'en ce qui concerne les fonctions de signalisation. Dans un mode d'exécution avantageux du procédé, le jeu de paramètres relatifs à un terminal de type IP, pris en compte par le gestionnaire de configuration, inclut une information sur des capacités de codage dudit terminal, et de préférence une information de localisation permettant d'identifier un sous-réseau du réseau IP auquel ledit terminal est raccordé. Le gestionnaire de configuration joue alors un rôle de serveur de topologie pour le réseau IP. La sélection du mode d'établissement du chemin de phonie par le gestionnaire de configuration s'opère en fonction des capacités de codage des terminaux IP et des ressources de débit disponibles dans le réseau IP (pour un simple raison de capacité technique et/ou compte tenu des choix effectués par l'administrateur du réseau). Le gestionnaire de configuration peut également tenir compte de l'état de charge du réseau IP pour privilégier l'emploi d'un codage à débit minimal pour les communications de phonie devant emprunter ce réseau alors qu'il est relativement encombré.
Un autre aspect de la présente invention se rapporte à un système de commutation comprenant plusieurs unités de contrôle de grappe interconnectées fournissant chacune des points d'accès au système, certaines au moins des unités de contrôle de grappe étant des unités passerelles respectivement équipées d'interfaces passerelles avec un réseau IP, le système étant agencé pour mettre en œuvre un procédé tel que défini ci- dessus pour établir une communication entre des terminaux qui lui sont reliés. D'autres particularités et avantages de l'invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :
- la figure 1 est un schéma d'un système de commutation selon l'invention ; - la figure 2 est un schéma synoptique d'une unité de contrôle de grappe du système de la figure 1 ; et
- les figures 3 à 6 sont des diagrammes illustrant des exemples de signalisation d'appel dans le système de la figure 1 , respectivement entre deux terminaux classiques, d'un terminal IP vers un terminal classique, d'un terminal classique vers un terminal IP, et entre deux terminaux IP.
La figure 1 montre, à titre illustratif, un exemple de système de commutation construit à partir de trois autocommutateurs (PABX) 10, 20, 30. Chaque PABX a une organisation en grappes. Il comprend ainsi une ou plusieurs unités de contrôle de grappe (UCG) 11 -13, 21 -25, 30 comportant chacune un ensemble de points d'accès au système. Les points d'accès peuvent servir d'interface avec différents types de lignes, selon les compatibilités désirées du système. On peut notamment prévoir des points d'accès pour le raccordement de terminaux de téléphonie classiques 32-35, analogiques (terminaux S63 simples ou terminaux "intelligents") ou numériques (terminaux X.25, RNIS...). Pour les communications extérieures, certaines au moins des UCG 13, 22 ont des points d'accès reliés par exemple à des lignes du réseau téléphonique public commuté (RTC) 50, d'un réseau numérique à intégration de services (RNIS) et/ou d'un réseau numérique à commutation de paquets (X.25). Pour éventuellement permettre des communications avec des terminaux mobiles 36 (par exemple CT2 ou DECT), certaines des UCG peuvent comporter des points d'accès radio reliés à des bornes radio respectives 37, 38.
Chaque UCG possède des ressources suffisantes pour supporter les communications entre ses propres points d'accès. Chaque PABX 10, 20 comportant plusieurs UCG est équipé d'une boucle de transport 18, 28, permettant les échanges inter-UCG de manière à supporter les communications entre plusieurs points d'accès appartenant à ce PABX. A titre d'exemple, la boucle 18, 28 peut être une ligne numérique à 40 Mbits/s organisée en temps partagé pour supporter 512 canaux à commutation de circuits ("canaux circuits") et 70 canaux à commutation de paquets ("canaux paquets"). Les canaux circuits sont prévus pour les points d'accès dont le fonctionnement requiert la réservation d'une ressource circuit, tandis que les canaux paquets sont prévus pour les points d'accès utilisés par des communications à commutation de paquets et pour les échanges de commandes propres au système de commutation (notamment les fonctions de signalisation). Des unités de contrôle non représentées sont prévues dans les PABX 10, 20 pour superviser le fonctionnement des boucles de transport 18, 28.
Lorsque le système comporte plusieurs PABX, des lignes inter-PABX 52 (par exemple des lignes MIC privées ou louées à un opérateur public) sont éventuellement prévues entre certaines de leurs UCG 25, 30.
Le système de commutation coopère avec un réseau informatique supportant le protocole IP. Dans l'exemple de la figure 1 , ce réseau IP incorpore deux réseaux locaux (LAN) 54, 55 reliés entre eux par l'intermédiaire d'un réseau étendu (WAN) 56. Le WAN 56 joue le rôle d'interconnexion entre les sous-réseaux formés par les LAN 54, 55. Le PABX 10 est relié au LAN 54 par un point d'accès de son UCG 11. Le PABX 20 est relié au LAN 55 par un point d'accès de son UCG 21. Le PABX 30 consistant en une seule UCG est relié au LAN 55 par un de ses points d'accès. Ces UCG 11 , 21 , 30 pourvues d'interfaces IP sont appelées ci-après « UCG passerelles ». Certains des terminaux gérés par un ou plusieurs des PABX sont des terminaux de type IP 40-43, qui sont raccordés au système par l'intermédiaire du réseau IP. Un tel terminal 40 peut être un téléphone conventionnel 47 associé à un adaptateur 48 pour le raccordement au réseau. Il peut également être un terminal téléphonique 41 , 42 (« Webphone » par exemple) incorporant une interface IP, ou encore un micro-ordinateur 43 exécutant une application de téléphonie (« Netmeeting » par exemple).
Dans la réalisation considérée ici à titre d'exemple, l'UCG de référence de chaque terminal IP est une UCG passerelle. Sans être obligatoire, ceci simplifie l'architecture du système. Dans le cas représenté sur la figure 1 , l'UCG 11 est par exemple l'UCG de référence des terminaux IP 40 et 41 reliés au LAN 54, tandis que l'UCG 21 est l'UCG de référence des terminaux IP 42 et 43 reliés au LAN 55. Chaque terminal IP mémorise l'adresse dans le réseau IP d'une interface passerelle de son UCG de référence, à laquelle il adresse toutes ses requêtes.
La figure 2 est un schéma de principe d'une UCG 11 ayant par exemple des points d'accès pour terminaux analogiques 32 et pour le raccordement de bornes radio 37 et un point d'accès passerelle pour le raccordement au LAN 54. L'UCG 11 comporte une interface 60 avec la boucle de transport 18 du PABX, consistant par exemple en des répéteurs pour retransmettre les trames circulant sur la boucle 18, associés à un automate de séparation des canaux paquets et des canaux circuits et à des mémoires tampon pour l'extraction et l'insertion des signaux concernant l'UCG.
Chaque point d'accès de l'UCG consiste en une interface physique 61 , 62, 63, qui assure les fonctions physiques de signalisation (détection d'événements, commandes, ...), de traduction et de mise en forme nécessaires à la compatibilité des organes raccordés aux points d'accès avec les formats utilisés dans le système de commutation.
En ce qui concerne les terminaux IP, l'interface 63 avec le LAN 54 peut assurer les fonctions de signalisation et de mise en forme selon un protocole normalisé, par exemple selon les Recommandations H.225, H.245 et H.323 de UIT-T. Une autre possibilité est de coder des mires de présentation définies pour le système de commutation au moyen d'un langage de description de page tel que XML (« eXtended Markup Language »), comme décrit dans la demande de brevet français 99 06159. Si le terminal est adapté à ce type de présentation, il affiche les mires propres au système décrites dans les messages XML construits par son interface passerelle, et il peut fournir les informations de signalisation requises en réponse à ces messages. La transmission de la signalisation sur le réseau IP s'effectue selon des sessions du protocole de transport TCP (« Transmission Control Protocol ») établies entre deux UCG passerelle ou entre un terminal IP et son UCG passerelle. Pour la transmission de la parole codée sur le réseau IP, on utilise comme il est usuel, le protocole de transport UDP (« User Datagram Protocol ») et les protocoles temps réel RTP et RTCP. Les interfaces passerelles 63 sont donc aptes à construire et récupérer des datagrammes UDP/IP conformément aux protocoles RTP et RTCP. Différents modes de codage/décodage de la parole peuvent être utilisés par les terminaux IP 40-43 et les interfaces passerelles 63. Dans le cas de H.323, le codage audio peut être conforme à l'une des Recommandations G.711 , G.722, G.723.1 , G.728 et G.729 de l'UlT-T.
Dans la suite de la présente description, on suppose, sans que ceci soit limitatif, qu'un terminal IP peut émettre et recevoir de la parole codée en G.711 (codage PCM à 64 kbit/s), et éventuellement en G.723.1 (compression par codage prédictif à 6,4 ou 5,3 kbit/s), et que la transmission de parole au sein des PABX, entre les PABX et les terminaux classiques 32-35 et entre les PABX et les bornes radio 37, 38 est sous la forme G.711. Ainsi, l'interface passerelle 63 est agencée pour effectuer un transcodage G.711/G.723.1 lorsque c'est requis pour un terminal IP fonctionnant en G.723.1.
Les différentes interfaces 60-63 sont reliées à une matrice de commutation 64 qui assure l'acheminement des signaux.
Le fonctionnement de l'UCG 11 est contrôlé par un processeur 65 associé à une mémoire 66. Le processeur 65 pilote les interfaces 60-63 par l'intermédiaire de son bus 67 soit directement (interfaces 60, 62, 63 dans l'exemple de la figure 2) soit à travers la matrice de commutation 64 (interfaces 61 ). Le processeur 65 assure notamment les traitements de signalisation concernant les points d'accès de l'UCG : il est informé des événements détectés par les interfaces 60-63 et effectue les traitements appropriés pour configurer la matrice de commutation 64, adresser des messages de signalisation vers l'interface 60 et des commandes aux interfaces physiques 61-63.
Pour l'interface avec la boucle de transport du PABX, le processeur 65 dispose de deux utilitaires logiciels : le GIC (Gestionnaire d'Inter Communications) qui gère les canaux paquets et le GIM (Gestionnaire d'Intervalle de temps Multisite) qui gère les canaux circuits. Pour l'émission et la réception de ses messages, le traitement d'appel s'adresse au GIC sous forme de primitives. Par le choix d'un message dirigé ou d'un message diffusé, il est possible de s'adresser à une UCG ou à toutes les UCG d'un PABX. En liaison avec le système opérationnel, le GIC gère l'acheminement des messages. Pour la prise/libération et la connexion/déconnexion du chemin phonique, le traitement d'appel s'adresse au GIM également sous forme de primitives. Lorsqu'il s'agit de réserver un chemin, les utilitaires GIM des deux demi-appels dialoguent directement entre eux. Différents types de modules logiciels sont utilisés par le processeur 65 pour effectuer les traitements de signalisation. Un demi-appel concernant un terminal comporte ainsi la création des tâches suivantes :
- le GO (Gestionnaire d'Organe) jouant le rôle de contrôleur du terminal, subdivisé en un MGO et un IGO. Le MGO (Moniteur de Gestion d'Organe) réalise de façon plus particulière les fonctions d'interface avec le niveau supérieur (niveau MAS), tandis que l'IGO (Interface de Gestion d'Organe) tient compte des détails spécifiques à chaque type de terminal. Le GO détecte les événements élémentaires produits par le terminal, les traite et les traduit en événements téléphoniques transmis au MAS par des messages conformes au standard de la signalisation interne du système. Il répercute vers le terminal les commandes exprimées par le
MAS dans des messages conformes au standard de la signalisation interne du système.
- le Moniteur d'Appel Simple (MAS) qui réalise toutes les fonctions d'analyse et de décision (acheminement d'appel, demande de faculté,...) intervenant dans la gestion d'appel. Pour ces fonctions, le MAS consulte des tables stockées dans la mémoire 66 et définissant notamment les droits de l'utilisateur et les facultés accessibles par le terminal. Le MAS pilote le Gestionnaire d'Organe.
Le gestionnaire d'organe est adapté au type d'organe qu'il contrôle, le MAS est indépendant du type d'organe. Cette indépendance est préservée par l'interface MAS/MGO dont les formats sont standardisés au sein du système.
Le MGO est commun à une famille d'applicatifs alors que l'IGO est plus spécifique.
Dans les diagrammes des figures 3 à 6, chaque demi-appel concernant un terminal est géré par une tâche de traitement d'appel (TAP) exécutée par le processeur 65 de l'UCG de référence du terminal. Cette tâche TAP regroupe les tâches MAS et MGO/IGO précitées, entre lesquelles la distinction n'est pas faite pour simplifier la représentation des scénarios d'appel. La partie gauche de chaque diagramme correspond au demi-appel demandeur, et la partie droite au demi-appel demandé.
Chaque scénario d'appel représenté commence par un échange d'informations entre le terminal appelant 70, 170 et la tâche de traitement d'appel 71 , 171 qui lui correspond. Cette tâche 71 , 171 a par exemple été créée par le processeur 65 de l'UCG de référence du terminal appelant 70, 170 à réception d'un message signalant la prise de ligne par ce terminal. Elle adresse au terminal les mires codant les informations à présenter à l'utilisateur (affichages, tonalités, ... ), et récupère les données fournies par l'utilisateur pour définir sa requête (choix de fonctions, numérotation, ... ). Lorsqu'elle dispose d'informations suffisantes, l'UCG diffuse dans le système un message d'établissement (SET_UP), comportant notamment les éléments suivants : - le numéro d'annuaire du terminal appelé 80, 180, défini directement ou indirectement par l'utilisateur du terminal appelant 70, 170 ;
- la localisation du terminal appelant 70, 170 dans le système, à savoir le numéro de site de l'UCG de référence (un site pouvant correspondre à un PABX 10, 20, 30) et le numéro de cette UCG de référence dans le site ;
- le type de raccordement du terminal appelant, figurant dans les tables de son UCG de référence exécutant la tâche TAP 71 , 171 ; cet élément permet en particulier de distinguer les terminaux « classiques » des terminaux IP ; - pour un terminal appelant de type classique, un numéro d'équipement physique correspondant désignant l'interface du PABX à laquelle le terminal est relié ;
- pour un terminal appelant de type IP, une indication des codages et des débits avec lesquels il est compatible (dans l'exemple simplifié évoqué précédemment, G.711 seulement ou G.711 +G.723.1 ) ;
- pour un terminal appelant de type IP, l'adresse IP du terminal dans le réseau 54-56, un numéro de port UDP qu'il consacre à la transmission de phonie selon le protocole RTP et un autre numéro de port UDP pour la transmission des informations de contrôle selon le protocole RTCP. Les UCG vers lesquelles ce message est diffusé analysent le numéro du terminal appelé. La seule UCG qui prend en compte le message, en créant une tâche 81 , 181 de traitement du demi-appel côté arrivée (TAP), est l'UCG de référence du terminal appelé. Cette tâche 81 , 181 interroge un serveur de topologie 90 pour déterminer une configuration de l'appel. Dans l'exemple représenté sur la figure 1 , le système comporte deux serveurs de topologie 90, l'un relié à un point d'accès de l'UCG 13 du PABX 10, et l'autre relié à un point d'accès de l'UCG 25 du PABX 20. Ces deux serveurs contiennent essentiellement les mêmes données, l'un ou l'autre étant interrogé selon l'UCG où la tâche 81 , 181 est exécutée. On notera que de nombreuses autres implementations seraient possibles, par exemple prévoir un seul serveur de topologie ou davantage, raccorder un serveur de topologie au réseau IP, ou encore réaliser le serveur de topologie sous forme de tables simplement mémorisées dans chaque UCG susceptible de l'interroger.
Le serveur de topologie 90 est interrogé sur la base de deux jeux de paramètres, l'un relatif au terminal appelant 70, 170 et l'autre relatif au terminal appelé 80, 180. Chaque jeu de paramètres relatif à un terminal comprend :
- le type de raccordement du terminal ;
- la localisation dans le système (numéros de site de l'UCG de référence et numéro de cette UCG de référence dans le site) ;
- pour un terminal de type IP, l'indication des codages et des débits avec lesquels il est compatible.
Pour le terminal appelant, ces paramètres sont obtenus par la tâche TAP 81 , 181 dans le message d'établissement reçu. Pour le terminal appelé, ils sont lus dans les données propres au terminal stockées dans l'UCG, au moyen du numéro d'annuaire obtenu dans le message d'établissement reçu. Dans le cas d'un appel entre deux terminaux 70, 80 de type classique
(non IP), la configuration d'appel désignée par le serveur de topologie 90 en réponse à son interrogation correspond au diagramme de la figure 3. A l'aide de l'utilitaire GIM, la tâche TAP 81 du demi-appel arrivée, exécutée dans l'UCG de référence du terminal appelé 80, commande l'établissement d'un chemin de communication entre les points d'accès des terminaux appelant et appelé 70, 80. Le cas échéant (appel multisite), ce chemin de communication peut en partie emprunter le réseau IP entre deux UCG passerelles. La tâche TAP 81 envoie directement au terminal appelé 80, s'il est disponible, la mire indiquant l'appel entrant, et elle retourne à la tâche TAP 71 du demi-appel départ un message d'alerte pour signaler le début de sonnerie au terminal appelé. Ce message d'alerte est retransmis sous forme d'une mire au terminal appelant 70, par l'intermédiaire de la ligne reliant ce terminal à son UCG de référence, laquelle est celle qui exécute la tâche TAP 71. Lorsque le terminal appelé prend la ligne, l'événement est signalé à la tâche TAP 81 qui en informe la tâche TAP 71 dans un message de connexion retransmis sous forme d'une mire au terminal appelant 70. La communication peut alors se dérouler classiquement. Lorsque l'un des terminaux est raccroché, l'autre en est informé par l'intermédiaire des tâches TAP 71 , 81 avant que celles-ci se retirent.
Dans le cas d'un appel d'un terminal IP 170 vers un terminal de type classique 80, la configuration d'appel désignée par le serveur de topologie 90 en réponse à son interrogation peut correspondre au diagramme de la figure 4. La tâche TAP 81 du côté arrivée ne dispose pas immédiatement d'un numéro d'équipement physique pour le terminal appelant, étant donné que celui-ci est raccordé par un réseau IP dans lequel il n'y a pas de notion de connexion. Elle adresse alors à la tâche TAP 171 de l'autre demi-appel un message de requête d'événement, dans lequel elle indique la configuration d'appel en cours ainsi que la localisation (site, UCG) du terminal appelé 80. A réception de ce message, la tâche 171 consulte une table de désignation de passerelles 92 pour identifier l'UCG d'au moins une interface passerelle depuis laquelle le terminal appelé 80 est accessible sans passer par le réseau IP. La table 92 est construite lors de la configuration du système. Elle fait correspondre à chaque unité de contrôle de grappe 11-13, 21-25, 30 une unité passerelle (voire plusieurs) dont l'interface passerelle peut, d'après la configuration du système, entrer en liaison avec les points d'accès de ladite unité de contrôle de grappe sans passer par le réseau IP. La table 92 peut par exemple être mémorisée dans chaque UCG passerelle, afin de pouvoir être consultée dans le traitement de chaque demi-appel concernant un terminal IP. Lors de la mise en place d'une nouvelle passerelle vers le réseau IP, celle-ci diffuse sur le réseau IP, à destination de toutes les UCG comportant des passerelles, sa localisation (site, UCG) ainsi que la localisation (site, UCG) de chaque UCG à laquelle elle a accès à l'intérieur du système de PABX sans passer par le réseau IP. En variante, la table des passerelles 92 pourrait être stockée dans un serveur accessible au sein des PABX ou sur le réseau IP.
Ainsi, dans le scénario d'appel de la figure 4, lorsqu'elle reçoit un message de requête d'événement indiquant la localisation (site, UCG) d'un terminal appelé de type classique, la tâche TAP 171 peut obtenir dans la table 92 la localisation (site, UCG) de chaque passerelle appropriée. Elle émet alors un second message d'établissement, qu'elle dirige vers la ou les UCG désignée(s) par la table 92, incluant l'adresse IP du terminal appelant 170 et les numéros de port UDP qu'il utilise pour les protocoles RTP et RTCP. A réception de ce message, la tâche 95 de gestion d'organe passerelle (GO-P) exécutée par le processeur d'une UCG passerelle concernée examine si l'interface passerelle dispose de ressources pour la communication en cours d'établissement. Dans l'affirmative, elle réserve deux numéros de port UDP pour les liaisons RTP et RTCP, et répond à la tâche 171 en retournant le numéro d'équipement physique de l'interface passerelle disponible, son adresse IP dans le réseau et les deux numéros de port UDP réservés. La tâche 171 peut alors répondre à la tâche 81 en fournissant le numéro d'équipement physique d'une interface passerelle. Disposant des deux numéros d'équipements physiques (celui de l'interface passerelle à employer, et celui du terminal appelé 80 qu'elle connaît d'après les tables stockées dans l'UCG), la tâche 81 commande, à l'aide de l'utilitaire GIM, l'établissement d'un chemin de communication, qui ne passe pas par le réseau IP, entre l'interface passerelle et le point d'accès du terminal appelé 80. Elle envoie à ce terminal 80, s'il est disponible, la mire indiquant l'appel entrant, et elle retourne à la tâche TAP 171 du demi-appel départ le message d'alerte signalant le début de sonnerie au terminal appelé. Ce message d'alerte est retransmis sous forme d'une mire au terminal appelant 170, dans un ou plusieurs segments TCP/IP adressés au terminal par son UCG de référence, avec l'adresse IP de l'interface passerelle à utiliser et les ports UDP réservés dans celle-ci pour la communication. Lorsque le terminal appelé 80 prend la ligne, l'événement est signalé à la tâche TAP 81 qui en informe la tâche TAP 171 dans un message de connexion retransmis sous forme d'une mire au terminal appelant 170. La communication peut alors se dérouler :
- le terminal IP 170 envoie sa parole codée sous forme de paquets RTP à destination du port UDP/IP qui lui a été indiqué avec la mire d'alerte, et l'interface passerelle destinataire reconstitue le flux de signal de parole codé, opère le cas échéant un transcodage, et retransmet la parole codée en G.711 jusqu'au terminal classique 80 ;
- la parole codée en G.711 émise par le terminal classique 80 est acheminée jusqu'à l'interface passerelle au sein d'un ou plusieurs PABX, éventuellement transcodée, puis envoyée sur le réseau IP au port UDP qui a été spécifié dans le second message d'établissement ;
- les tâches TAP 171 et 81 (plus précisément les tâches GO) restent en vigueur jusqu'à la fin de la communication, de même que la session TCP/IP transportant la signalisation entre le terminal IP 170 et son UCG de référence.
Dans le cas d'un appel d'un terminal de type classique 70 vers un terminal IP 180, la configuration d'appel désignée par le serveur de topologie 90 en réponse à son interrogation peut correspondre au diagramme de la figure 5. La tâche TAP 181 exécutée dans l'UCG passerelle du côté arrivée ne dispose pas immédiatement d'un numéro d'équipement physique pour le terminal appelé. Elle consulte alors la table de désignation de passerelles 92 sur la base de la localisation (site, UCG) du terminal appelant 70, qu'elle a obtenue dans le message d'établissement, pour identifier l'UCG d'au moins une interface passerelle depuis laquelle le terminal appelant 70 est accessible sans passer par le réseau IP. La tâche TAP 181 émet alors un second message d'établissement, qu'elle dirige vers la ou les UCG désignée(s) par la table 92, incluant l'adresse IP du terminal appelé 180 et les numéros de port UDP qu'il utilise pour les protocoles RTP et RTCP (l'UCG exécutant la tâche 181 dispose de ces adresse et numéros de port dans les tables qu'elle mémorise au sujet du terminal appelé dont le numéro figurait dans le premier message d'établissement). A réception de ce message, le module 96 de gestion d'organe passerelle (GO-P) exécuté par le processeur d'une UCG passerelle concernée examine si l'interface passerelle dispose de ressources pour la communication en cours d'établissement. Dans l'affirmative, il réserve deux numéros de port UDP pour les liaisons RTP et RTCP, et répond à la tâche 181 en retournant le numéro d'équipement physique de l'interface passerelle disponible, son adresse IP dans le réseau et les deux numéros de port UDP réservés. Disposant des deux numéros d'équipements physiques (celui de l'interface passerelle à employer, et celui du terminal appelant 70 qu'elle a obtenu dans le premier message d'établissement), la tâche 181 commande, à l'aide de l'utilitaire GIM, l'établissement d'un chemin de communication, qui ne passe pas par le réseau IP, entre l'interface passerelle et le point d'accès du terminal appelant 70. Elle envoie à l'adresse IP du terminal appelé 180, s'il est disponible, la mire indiquant l'appel entrant, avec l'adresse IP de l'interface passerelle à utiliser et les ports UDP réservés dans celle-ci pour la communication, et elle retourne à la tâche TAP 71 du demi- appel départ le message d'alerte signalant le début de sonnerie au terminal appelé. Ce message d'alerte est retransmis sous forme d'une mire au terminal appelant 70. Lorsque le terminal appelé 180 prend la ligne, l'événement est signalé à la tâche TAP 181 qui en informe la tâche TAP 71 dans un message de connexion retransmis sous forme d'une mire au terminal appelant 70. La communication peut alors se dérouler :
- la parole codée en G.71 1 émise par le terminal classique 70 est acheminée jusqu'à l'interface passerelle au sein d'un ou plusieurs PABX, éventuellement transcodée, puis envoyée sur le réseau IP au port UDP qui a été spécifié dans le second message d'établissement ; - le terminal IP 180 envoie sa parole codée sous forme de paquets RTP à destination du port UDP/IP qui lui a été indiqué avec la mire d'appel entrant, et l'interface passerelle destinataire reconstitue le flux de signal de parole codé, opère le cas échéant un transcodage, et retransmet la parole codée en G.711 jusqu'au terminal classique 70 ;
- les tâches TAP 71 et 181 (plus précisément les tâches GO) restent en vigueur jusqu'à la fin de la communication, de même que la session TCP/IP transportant la signalisation entre le terminal IP 180 et son UCG de référence. Dans le cas d'un appel entre deux terminaux IP 170, 180, la configuration d'appel désignée par le serveur de topologie 90 en réponse à son interrogation peut correspondre au diagramme de la figure 6. Dans cette configuration, la parole codée est échangée entre les terminaux directement sur le réseau IP 54-56. La tâche TAP 181 , exécutée dans l'UCG passerelle du côté arrivée, envoie à l'adresse IP du terminal appelé 180, s'il est disponible, la mire indiquant l'appel entrant, avec l'adresse IP du terminal appelant 170 et les ports UDP utilisés par celui-ci pour la communication, qu'elle a obtenus dans le message d'établissement. En outre, elle retourne à la tâche TAP 171 du demi- appel départ le message d'alerte signalant le début de sonnerie au terminal appelé, avec l'adresse IP du terminal appelé 180 et les ports UDP utilisés par celui-ci pour la communication. Ce message d'alerte est retransmis sous forme d'une mire au terminal appelant 170, avec l'adresse IP du terminal appelé 180 et les ports UDP utilisés. Lorsque le terminal appelé 180 prend la ligne, l'événement est signalé à la tâche TAP 181 qui en informe la tâche TAP 171 dans un message de connexion retransmis sous forme d'une mire au terminal appelant 70. La communication peut alors se dérouler, directement entre les ports UDP pour la partie trafic, et dans le cadre des sessions TCP/IP entre les terminaux et leurs UCG de référence pour la partie signalisation.
Dans le cas où les LAN 54, 55 et le WAN 56 sont toujours capables du supporter n'importe quel débit et où les terminaux IP sont tous compatibles entre eux, la décision entre les quatre configurations d'appel illustrées par les figures 3 à 6 peut être prise par le serveur de topologie 90 sur la seule base des types de raccordement des terminaux appelant et appelé.
Un raffinement consiste à prendre en compte les capacités de codage des terminaux IP. Les données de configuration retournées par le serveur 90 peuvent ainsi inclure des instructions d'utiliser tel ou tel type de codage dans les terminaux IP, que les tâches de traitement d'appel transmettent aux terminaux et interfaces passerelles concernés. L'administrateur du système peut ainsi privilégier les transmissions à bas débit (par exemple G.723.1 plutôt que G.711 ) sur le réseau IP pour limiter l'encombrement de celui-ci par le trafic téléphonique. Il peut aussi éventuellement éviter les transcodages au niveau des passerelles s'il y a des contraintes sur les capacités de calcul de celles-ci (privilégier l'utilisation de G.711 par les terminaux si l'encombrement du réseau le permet). La configuration retenue par le serveur pour chaque appel peut dépendre de paramètres dynamiques sur l'encombrement du réseau IP ou la charge des interfaces.
La prise en compte les capacités de codage des terminaux IP peut en outre intervenir dans le choix du scénario de codage selon la figure 4, 5 ou 6, particulièrement dans le cas où la localisation des terminaux est également prise en compte. Cette information de localisation permet, pour un terminal IP, d'identifier un sous-réseau du réseau IP, c'est-à-dire l'un des LAN 54, 55, auquel ce terminal est raccordé.
Considérons par exemple le cas où il n'y aurait aucun problème d'encombrement pour transmettre la parole codée à 64 kbit/s (G.711 ) sur les LAN 54, 55, mais où il serait souhaité de minimiser le débit sur le WAN 56, pour des raisons de facturation par un opérateur gérant le WAN. Pour établir une communication mettant en jeu un terminal IP appelant ou appelé, non équipé du codée G.723.1 (ce qui apparaît dans les jeux de paramètres fournis au serveur 90), le serveur de topologie 90 pourra commander la mise en œuvre de la configuration d'appel selon la figure 4, 5 ou 6 tant que la communication peut avoir lieu sans passer par le WAN. Mais si l'autre terminal impliqué se trouve sur un autre site et nécessite un passage par le WAN 56, un transcodage G.711/G.723.1 devra être effectué, ce qui requiert une configuration d'appel différente.
Par exemple, si le terminal IP 41 de la figure 1 est le terminal appelant qui supporte G.711 seulement et si le terminal IP 42 est le terminal appelé qui supporte G.711 et G.723.1 , le serveur de topologie 90 répond aux jeux de paramètres qui lui sont présentés en commandant la configuration selon la figure 5 (et non selon la figure 6, bien que les deux terminaux soient de type IP). L'interface passerelle de l'UCG de référence 11 du terminal 41 jouera le même rôle que l'interface de raccordement d'un terminal classique : en cours de communication, elle opérera un transcodage, et dialoguera en G.711 avec le terminal 41 et en G.723.1 avec le terminal 42 à travers le réseau IP. De même, si le terminal classique 34 est le terminal appelé par le terminal 41 , le serveur de topologie 90 commande la configuration selon la figure 3, et non selon la figure 4. Symétriquement, si le terminal IP 43 de la figure 1 est le terminal appelé qui supporte G.711 seulement et si le terminal IP 40 est le terminal appelant qui supporte G.711 et G.723.1 , le serveur de topologie 90 répond aux jeux de paramètres qui lui sont présentés en commandant la configuration selon la figure 4 (et non selon la figure 6, bien que les deux terminaux soient de type IP). De même, si le terminal classique 32 est le terminal appelant le terminal 43, le serveur de topologie 90 commande la configuration selon la figure 3, et non selon la figure 5.
Pour prendre ce type de décision, le serveur 90 comporte des tables construites en intégrant la connaissance de la topologie du système de commutation et du réseau IP, qui permettent d'associer les données de configuration appropriées à chaque couple de jeux de paramètres terminal appelant / terminal appelé.

Claims

R E V E N D I C A T I O N S
1. Procédé d'établissement d'une communication entre des terminaux
(32-36, 40-43) reliés à un système de commutation, le système de commutation comprenant plusieurs unités de contrôle de grappe interconnectées (11 -13, 21-25, 30) fournissant chacune des points d'accès au système, dans lequel chaque terminal est respectivement associé, parmi les unités de contrôle de grappe, à une unité de référence qui mémorise des données propres audit terminal, servant à effectuer des traitements de signalisation le concernant, dans lequel certaines au moins des unités de contrôle de grappe sont des unités passerelles (11 , 21 , 30) respectivement équipées d'interfaces passerelles avec un réseau IP (54-56), et certains des terminaux sont des terminaux de type IP (40-43) reliés au système par l'intermédiaire du réseau IP, et dans lequel le système de commutation comporte au moins un gestionnaire de configuration d'appel (90) agencé pour délivrer des données de configuration d'appel en réponse à deux jeux de paramètres relatifs à des terminaux appelant et appelé, respectivement, ledit jeu de paramètres relatifs à un terminal incluant une indication de type de raccordement du terminal, qui diffère selon que le terminal est ou non de type IP, le procédé comprenant les étapes suivantes pour établir une communication entre des premier et second terminaux comprenant des terminaux appelant et appelé : - création d'une première tâche de traitement d'appel (71 , 171 ) dans l'unité de référence du terminal appelant (70, 170) ;
- formation, par la première tâche de traitement d'appel, d'un message d'établissement incluant au moins le numéro du terminal appelé et l'indication de type de raccordement du terminal appelant ; - en réponse à la réception dudit message d'établissement, création d'une seconde tâche de traitement d'appel (81 , 181 ) dans l'unité de référence du terminal appelé (80, 180) ;
- interrogation du gestionnaire de configuration par la seconde tâche de traitement d'appel, sur la base d'un jeu de paramètres relatifs au terminal appelant extraits du message d'établissement et d'un jeu de paramètres relatifs au terminal appelé déduits par la seconde tâche de traitement d'appel à partir du numéro reçu dans le message d'établissement ; et
- lorsque les données de configuration d'appel retournées par le gestionnaire de configuration correspondent à une possibilité d'échanger, directement à travers le réseau IP, du trafic entre ledit premier terminal et au moins une interface passerelle depuis laquelle ledit second terminal est accessible sans passer par le réseau IP, échange de signalisation entre les première et seconde tâches de traitement d'appel et une tâche de gestion d'une interface passerelle, afin d'établir entre ladite interface passerelle et le second terminal un chemin de communication ne passant pas par le réseau IP, de fournir à ladite interface passerelle des données d'adressage du premier terminal dans le réseau IP, et de fournir au premier terminal des données d'adressage ladite interface passerelle dans le réseau IP.
2. Procédé selon la revendication 1 , comprenant l'étape suivante lorsque les données de configuration d'appel retournées par le gestionnaire de configuration (90) correspondent à une possibilité d'échanger, directement à travers le réseau IP, du trafic entre lesdits premier et second terminaux (170, 180) :
- échange de signalisation entre les première et seconde tâches de traitement d'appel (171 , 181 ), afin de fournir au second terminal des données d'adressage du premier terminal dans le réseau IP, et de fournir au premier terminal des données d'adressage du second terminal dans le réseau IP.
3. Procédé selon la revendication 1 ou 2, dans lequel ledit jeu de paramètres relatifs à un terminal de type IP (40-43) inclut une information sur des capacités de codage dudit terminal.
4. Procédé selon la revendication 3, dans lequel les données de configuration d'appel retournées par le gestionnaire de configuration (90) pour une communication mettant en jeu un terminal de type IP (40-43) comprennent une instruction d'utiliser un codage particulier.
5. Procédé selon la revendication 3 ou 4, dans lequel ledit jeu de paramètres relatifs à un terminal inclut une information de localisation permettant, dans le cas d'un terminal de type IP (40-43), d'identifier un sous- réseau (54, 55) du réseau IP auquel ledit terminal est raccordé.
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel chaque terminal de type IP (40-43) a pour unité de référence une unité de contrôle de grappe (11 , 21 , 30) équipée d'une interface passerelle avec le réseau IP (54-56).
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel chaque unité passerelle (11 , 21 , 30) dispose d'une table de désignation des passerelles (92) faisant correspondre à chaque unité de contrôle de grappe (11 -13, 21-25, 30) au moins une unité passerelle dont l'interface passerelle peut, d'après la configuration du système, entrer en liaison avec les points d'accès de ladite unité de contrôle de grappe sans passer par le réseau IP.
8. Procédé selon la revendication 7, dans lequel, lorsque les données de configuration d'appel retournées par le gestionnaire de configuration (90) correspondent à une possibilité d'échanger, directement à travers le réseau IP (54-56), du trafic entre ledit premier terminal et au moins une interface passerelle depuis laquelle ledit second terminal est accessible sans passer par le réseau IP, ledit premier terminal (170) étant le terminal appelant de type IP, et ledit second terminal (80) étant le terminal appelé qui n'est pas de type IP, ledit échange de signalisation comporte les étapes suivantes :
- la seconde tâche de traitement d'appel (81 ) adresse un message de requête à la première tâche de traitement d'appel (170), incluant une identification de l'unité de contrôle de grappe de référence du terminal appelé ;
- la première tâche de traitement d'appel consulte la table de désignation des passerelles (92) sur la base de l'unité de contrôle de grappe identifiée dans le message de requête, pour déterminer une unité passerelle depuis laquelle le terminal appelé est accessible sans passer par le réseau IP ;
- la première tâche de traitement d'appel adresse un message, incluant une adresse IP et au moins un numéro de port UDP du terminal appelant, à une tâche (95) de gestion d'une interface passerelle de l'unité passerelle déterminée ;
- la tâche de gestion de l'interface passerelle réserve au moins un numéro de port UDP pour la communication et retourne à la première tâche de traitement d'appel un numéro d'équipement et une adresse IP de l'interface passerelle et chaque numéro de port UDP réservé ;
- la première tâche de traitement d'appel communique à la seconde tâche de traitement d'appel le numéro d'équipement et l'adresse IP de l'interface passerelle et chaque numéro de port UDP réservé ; - la seconde tâche de traitement d'appel commande l'établissement d'un chemin de communication ne passant pas par le réseau IP entre ladite interface passerelle et le point d'accès du terminal appelé, envoie vers le terminal appelé (80) une signalisation d'appel incluant l'adresse IP et chaque numéro de port UDP du terminal appelant, obtenus dans le message d'établissement, et retourne un message d'alerte à la première tâche de traitement d'appel ; et
- la première tâche de traitement d'appel adresse au terminal appelant (170) un message d'alerte avec l'adresse IP de l'interface passerelle et chaque numéro de port UDP réservé.
9. Procédé selon la revendication 7 ou 8, dans lequel, lorsque les données de configuration d'appel retournées par le gestionnaire de configuration (90) correspondent à une possibilité d'échanger, directement à travers le réseau IP (54-56), du trafic entre ledit premier terminal et au moins une interface passerelle depuis laquelle ledit second terminal est accessible sans passer par le réseau IP, ledit premier terminal (70) étant le terminal appelé de type IP, et ledit second terminal (180) étant le terminal appelant qui n'est pas de type IP, ledit échange de signalisation comporte les étapes suivantes :
- la seconde tâche de traitement d'appel (181) consulte la table de désignation des passerelles (92) sur la base de l'unité de contrôle de grappe de référence du terminal appelé, pour déterminer une unité passerelle depuis laquelle le terminal appelant est accessible sans passer par le réseau IP ;
- la seconde tâche de traitement d'appel adresse un message, incluant une adresse IP et au moins un numéro de port UDP du terminal appelé, à une tâche (96) de gestion d'une interface passerelle de l'unité passerelle déterminée ;
- la tâche de gestion de l'interface passerelle réserve au moins un numéro de port UDP pour la communication et retourne à la seconde tâche de traitement d'appel un numéro d'équipement et une adresse IP de l'interface passerelle et chaque numéro de port UDP réservé ;
- la seconde tâche de traitement d'appel commande l'établissement d'un chemin de communication ne passant pas par le réseau IP entre ladite interface passerelle et le point d'accès du terminal appelant, envoie vers le terminal appelé (180) une signalisation d'appel incluant l'adresse IP de l'interface passerelle et chaque numéro de port UDP réservé, et retourne un message d'alerte à la première tâche de traitement d'appel ; et
- la première tâche de traitement d'appel adresse un message d'alerte au terminal appelant (70).
10. Système de commutation comprenant plusieurs unités de contrôle de grappe interconnectées (11-13, 21-25, 30) fournissant chacune des points d'accès au système, certaines au moins des unités de contrôle de grappe étant des unités passerelles (11 , 21 , 30) respectivement équipées d'interfaces passerelles avec un réseau IP (54-56), le système étant agencé pour mettre en œuvre un procédé selon l'une quelconque des revendications précédentes pour établir une communication entre des terminaux qui lui sont reliés.
EP00966266A 1999-10-05 2000-10-03 Procede d'etablissement de communication entre des terminaux relies a un systeme de commutation, et systeme de commutation mettant en oeuvre le procede Withdrawn EP1221250A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9912393A FR2799324B1 (fr) 1999-10-05 1999-10-05 Procede d'etablissement de communication entre des terminaux relies a un systeme de commutation, et systeme de commutation mettant en oeuvre le procede
FR9912393 1999-10-05
PCT/FR2000/002740 WO2001026351A2 (fr) 1999-10-05 2000-10-03 Procede d'etablissement de communication entre des terminaux relies a un systeme de commutation, et systeme de commutation mettant en oeuvre le procede

Publications (1)

Publication Number Publication Date
EP1221250A2 true EP1221250A2 (fr) 2002-07-10

Family

ID=9550577

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00966266A Withdrawn EP1221250A2 (fr) 1999-10-05 2000-10-03 Procede d'etablissement de communication entre des terminaux relies a un systeme de commutation, et systeme de commutation mettant en oeuvre le procede

Country Status (4)

Country Link
EP (1) EP1221250A2 (fr)
AU (1) AU7671400A (fr)
FR (1) FR2799324B1 (fr)
WO (1) WO2001026351A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2818854B1 (fr) 2000-12-22 2003-03-28 Matra Nortel Communications Procede d'etablissement de chemins de communication entre des points d'acces d'un systeme de commutation, et systeme de commutation mettant en oeuvre le procede

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2745140B1 (fr) * 1996-02-15 1998-04-24 Matra Communication Procede de gestion de signalisation dans un systeme d'autocommutation equipe de bornes radio
US5892764A (en) * 1996-09-16 1999-04-06 Sphere Communications Inc. ATM LAN telephone system

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2001026351A2 (fr) 2001-04-12
WO2001026351A3 (fr) 2002-01-17
FR2799324A1 (fr) 2001-04-06
AU7671400A (en) 2001-05-10
FR2799324B1 (fr) 2001-12-28

Similar Documents

Publication Publication Date Title
US6266340B1 (en) Systems and methods for multiple voice data communication which includes interface cards including configurable clocks that are dynamically coupled to a TDS bus
US6298045B1 (en) Systems and methods for multiple mode voice and data communications using intelligently bridged TDM and packet buses and methods for performing telephony and data functions using the same
US20030147381A1 (en) Systems and methods for multiple mode voice and data communications using intelligenty bridged TDM and packet buses and methods for performing telephony and data functions using the same
EP1119148A1 (fr) Protection de l'intégrité d'un réseau de communication
US6343074B1 (en) Systems and methods for multiple mode voice and data communications using intelligenty bridged TDM and packet buses and methods for performing telephony and data functions using the same
EP1051046A2 (fr) Procédé pour fournir des services de réseau intelligent dans un réseau IP
WO2000019677A2 (fr) Gestionnaire de connexion pour telecommunications
EP1299986B1 (fr) Procede d'etablissement de communications dans un systeme a commutation de paquets
WO1998044703A1 (fr) Interconnexion de centraux telephoniques via un reseau d'ordinateurs
EP1344384B1 (fr) Procede d'etablissement de chemins de communication entre des points d'acces d'un systeme de commutation, et systeme de commutation mettant en oeuvre le procede
EP1221250A2 (fr) Procede d'etablissement de communication entre des terminaux relies a un systeme de commutation, et systeme de commutation mettant en oeuvre le procede
EP1380143B1 (fr) Procede d'etablissement de communication dans un reseau multimedia
JP2001274906A (ja) 交換機とサービスコンピュータの間で通信サービスデータを送信する方法、交換機、サービスコンピュータ、プログラムモジュールおよびインターフェースデバイス
AU741494B2 (en) Procedure for the switching of data traffic in a data communication system
EP0998109B1 (fr) Réseau de communications utilisant de serveurs autonomes pour l'établissment d' une session de communication
KR100474702B1 (ko) 다이얼러 서버의 실시간 모니터링 기능을 갖는 교환시스템및 그 모니터링 방법
FR2786970A1 (fr) Procede d'etablissement d'une communication entre deux terminaux a travers l'internet par un serveur d'appel et de mise en communication, terminal et serveur associes
CA2347405A1 (fr) Gestionnaire de connexion pour telecommunications
EP1655936A1 (fr) Système et procédé de télécommunication pour la transmission de voix et de données
WO2001022641A2 (fr) Procede de transmission de paquets, dispositifs d'interface et equipements de communication pour la mise en oeuvre du procede
KR20060069668A (ko) 사설 교환 시스템의 호 레코드 관리 장치 및 그 방법

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020430

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: EADS TELECOM

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

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

18D Application deemed to be withdrawn

Effective date: 20060503