WO2004100492A1

WO2004100492A1 - Method and device for synchronisation of data streams

Info

Publication number: WO2004100492A1
Application number: PCT/FR2004/000967
Authority: WO
Inventors: Bertrand Bouvet
Original assignee: France Telecom
Priority date: 2003-04-29
Filing date: 2004-04-20
Publication date: 2004-11-18
Also published as: FR2854523A1

Abstract

The invention relates to a device for the synchronisation of a multimedia stream, comprising two distinct multimedia streams in a telecommunication network with a synchronous telecommunication network and an asynchronous telecommunication network, one of said streams passing through the asynchronous telecommunication network and the other passing through the synchronous telecommunication network, characterised in that said device comprises means for obtaining delay information representative of the delay in the transmission of the stream passing through the asynchronous network and means for modifying the delay of transmission of the multimedia stream passing through the synchronous network, based on the obtained delay information. The invention further relates to the corresponding synchronisation method.

Description

Data stream synchronization method and device

The present invention relates to a method and a device for synchronizing data flows.

More specifically, the invention relates to the field of synchronization of at least two streams, for example and without limitation an audio data stream and a video data stream. One of the flows is carried on an asynchronous packet telecommunications network, at least one other of the flows is carried on a synchronous telecommunications network.

Audio and video data transfer devices on the same telecommunications network are known. The exchange of data flows between videophones on a PSTN type telecommunications network allows owners of such videophones to be able to communicate by voice and image with their correspondent if the latter of course has an equivalent terminal.

The transfer of the image over a switched network nevertheless requires a sharp reduction in the quality of the image transmitted. This penalizes the use of such services.

CQPΕ DE € OWFMATtûi Many people around the world have computers connected to a network such as the Internet, hence the growing interest in using the Internet as a medium for transmitting audio video data streams for video conferencing applications. The very nature of the Internet makes it unsuitable for real-time data transmission. This network does not guarantee a quality of service, the quality of transmission remains imperfect.

Protocols such as the Real Time Protocol (RTP) and Real Time Transfer Control Protocol (RTCP) try to solve the problems associated with using the Internet as a medium. of transmission.

The RTP protocol provides a uniform means of transmitting data subject to real-time constraints. It identifies the type of information being transported, adding time markers and sequence numbers to the information it carries. When multimedia data is transmitted according to the RTP protocol, an RTP channel is established for each of the video and audio streams for each direction of transmission between the parties. Indeed, the RTP protocol is intended to transport only one type of information at a time.

Multiplexing, demultiplexing and synchronization of audio and video streams is carried out at the level of the application receiving audio and video streams.

The RTCP protocol makes it possible to control the data flows exchanged according to the RTP protocol. It also makes it possible to convey information on the quality of service of the data flows exchanged with the RTP protocol.

However, these RTP and RTCP protocols do not guarantee quality of service.

Methods of transferring audio and video data are known in which the audio signal is transmitted over a telephone network while the video is transmitted via the Internet. This is particularly the case when two correspondents are on a telephone call and at the same time exchange video information captured by their video cameras (webcam) on their computers.

The problem with these data transfers using different transmission media is a lack of synchronization when receiving data. This problem is all the more important if the subscribers use two different devices independent of each other to receive the video data streams and the audio data streams.

The invention aims to solve the drawbacks of the prior art by proposing a device for synchronizing a multimedia stream consisting of two separate multimedia streams in a telecommunications network consisting of a synchronous telecommunications network and a network. of asynchronous telecommunication, one of said flows transiting on the asynchronous telecommunication network, the other flux transiting on the synchronous telecommunication network, characterized in that the device comprises:

means for obtaining delay information representative of the delay in transmitting the flow passing over the asynchronous network,

- Means for modifying the delay of transmission of the multimedia stream transiting on the synchronous network from the delay information obtained. Correlatively, the invention provides a method of synchronizing a multimedia stream consisting of two separate multimedia streams in a telecommunications network consisting of a synchronous telecommunications network and an asynchronous telecommunications network (160, 260), one of said flow passing through the asynchronous telecommunications network, the other flow passing through the synchronous telecommunications network, characterized in that the method comprises the steps of:

- obtaining delay information representative of the delay in transmitting the flow passing over the asynchronous network,

- modification of the delay of transmission of the multimedia stream transiting on the synchronous network from the delay information obtained.

Thus, the invention by using two different networks and their respective specificities makes it possible to transfer a multimedia stream while guaranteeing by synchronization an optimal quality of reception.

We understand by synchronous telecommunications network, a network which guarantees the delay of transmission of the data transmitted on this network. A part of this synchronous telecommunication network may consist of an asynchronous telecommunication network with which there are associated means for controlling the delay in receiving data. This is for example the case of a fixed telephone network of the company France Telecom. More specifically, the asynchronous telecommunications network is connected to a computer device comprising at least one client-client application receiving a video data stream and the synchronous telecommunications network is connected to a telephone handset receiving an audio data stream. Thus, a person accustomed to using their telephone handset to communicate does not have to change their habits. Indeed, it is difficult for an individual to speak in front of a computer device, the same individual is however used to stand in front of a computer device to view information such as video streams. In addition, people using systems such as videophones prefer first to establish a telephone communication before doubling the communication by a video stream.

The device according to the invention also makes it possible to synchronize audio and video streams received by different devices without these same devices being connected to each other or exchanging information. The computer devices as well as the telephone handsets do not need to be modified to allow the invention to be carried out.

More particularly, the information representative of the transmission delay of the stream passing over the asynchronous network is obtained from control packets of the video data stream passing over the asynchronous network.

Thus, synchronization is carried out in a simple manner, only the control packets are used for synchronization and thus the synchronization device is simplified.

More precisely, the information representative of the delay of transmission of the flow passing through the asynchronous network is obtained by memorizing the instants of reception of the control packets of the video data flow passing through the asynchronous network, by reading at least one predetermined field of the packets of control of the video data flow and by calculating the delay from the memorized instants and from the at least one predetermined field read. Thus, synchronization is carried out in a simple manner.

Advantageously, the transmission delay of the stream passing over the synchronous network is modified by memorizing the data of the audio stream passing over the synchronous network, by determining the address for reading the data from the information. obtained and by transferring, from the determined address, the data stored on the synchronous network to the telephone handset.

Thus, the synchronization of the audio stream is carried out in a simple manner by determining a memory read address of the data of the stored audio stream. Advantageously, control packets of the video data flow passing over the asynchronous network are received and control packets of the video data flow passing over the asynchronous network are generated.

More specifically, the synchronization device comprises means for receiving at least one call from a telephone handset, means for obtaining at least one identifier for a telephone handset with which the calling telephone handset wishes to establish a telephone communication and means for matching the computer device associated with the user associated with the calling telephone handset with the computer device associated with the user with the telephone handset with which the calling telephone handset wishes to establish a telephone communication.

Thus, the user does not need to know the electronic address of the computer device of his correspondent, only the telephone number of the latter needs to be known.

The advantages of the methods being identical to those mentioned for the devices, these will not be recalled.

The invention also relates to the computer program stored on an information medium, said program comprising instructions making it possible to implement the processing method described above, when it is loaded and executed by a computer system. The characteristics of the invention mentioned above, as well as others, will appear more clearly on reading the following description of an exemplary embodiment, said description being made in relation to the accompanying drawings, among which: FIG. . 1 shows a first embodiment of the invention in a telecommunications network comprising a service node architecture; Fig. 2 represents the service registration algorithm as provided by the invention in the telecommunications network; Fig. 3 represents an algorithm describing the kinematics of activation of a client-client type application in parallel with a telephone communication; Fig. 4 represents an RTCP SR transmitter report packet conforming to the RTCP protocol; Fig. 5a represents an algorithm describing the determination of the delay on the packet telecommunications network according to the first embodiment of the invention; Fig. 5b represents an algorithm describing the application of the delay on the telephone voice flows carried out by the voice and delay management module; Fig. 6 shows a second embodiment of the invention in a telecommunication network comprising a service node architecture within the framework of a service for connecting subscribers in conference; Fig. 7 shows an algorithm describing the kinematics of activating a conference call between three subscribers, coupled with a client-client type application managed within the framework of a service node type architecture; Fig. 8 represents an algorithm describing the determination of the delay on the packet telecommunications network according to the second embodiment of the invention.

Fig. 1 shows a first embodiment of the invention in a telecommunications network comprising a service node architecture. In a service node architecture, the server connects to the network in the same way as a subscriber terminal.

The telecommunications network includes an ASP application service provider noted 190 which is for example associated with a telecommunications operator 140, a switched telephone network 141, a network of mobile telephones 148, of GSM type acronym of Global System Mobile or UMTS type acronym of Universal Mobile Telecommunications System, an ISP 150 network (Internet service provider) and a public Internet network 160.

The switched telephone network 141, the mobile telephone network 148, of GSM type acronym of Global System Mobile or of UMTS type acronym of Universal Mobile Telecommunications System constitute the synchronous telecommunications network.

The public Internet 160 is here the asynchronous telecommunications network. The switched telephone network 141 is associated with a autonomy switch CAA noted 142 allowing the provision of conventional telephone service to a subscriber 100.

The switched telephone network 141 is linked to the mobile telephone network 148.

The ASP application service provider 190 includes a local area network 184.

The local network 184 is also connected to the public Internet network 160 through a Firewall router 185 also ensuring the security of information exchanges between the networks 184 and 160 while ensuring that no intrusion can be carried out in the network 184.

A server 170 is connected to this local network 184. The server 170 is also connected to the telephone network 141 via the routing autonomy switch 142. The server 170 is either centralized on a single device, or distributed over different devices placed or not on the same site.

The server 170 consists of a service database 171 in which are stored information necessary for the execution of the services according to the invention. This information is, for example and without limitation, information permanently stored such as the subscription profiles of subscribers to the services according to the invention.

The database 171 also includes temporary information linked to the subscribers' sessions. This information is, for example and without limitation, the telephone number (s) associated with the service, the Internet address of the subscribers 'computers, the port numbers of the client-client applications available to the subscribers' computers.

The server 170 also includes a recording module 172 of the client software of the subscribers to the service. This client software will be described later.

The server 170 also includes a module 173 for notification of network events and information from the client software 107 and 124.

The server 170 also includes an IP interface 178 of the Ethernet type allowing the server 170 to connect with the local network 184. The server 170 comprises an automatic call module 179 which processes the signaling of incoming and outgoing telephone calls.

The server 170 comprises a telephone interface PSTN 180 of the ISUP type (ISDN user signaling protocol), ISDN being the acronym of Digital Network with Services Integration which allows the connection of the server 170 with the telephone network 141 via the CAA 142 of the telecommunications operator 140.

It should be noted that the interface 180 can also be an interface conforming to the standard SS7 (signaling code 7).

The server 170 also includes a module 181 for managing the PSTN telephone voice streams allowing the media channels of the incoming telephone communication and the outgoing telephone communication to be matched. The module 181 also allows the generation of delay between the incoming voice flows and the outgoing voice flows, these delays being able to be different according to the direction of the communication. The server 170 also includes a module 183 called proxy used by client-client type applications (or even client-server type).

Generally, a proxy is a server that acts as an interface between a subscriber and another remote subscriber. The proxy forwards messages generated by the subscriber to the recipient. The recipient replies to the proxy as if it were the generator of the message. The proxy then forwards the response to the subscriber.

The signaling flows as well as the media control flows according to the Internet protocol will pass through this module. According to a particular mode, and for performance aspects, the IP media streams according to the Internet protocol may not borrow the module 183. For example, the module 183 can process several types of applications such as video streams encoded according to the formats H323 or SIP.

The server 170 also includes a module 182 for analyzing IP media flow control packets passing through the module 183.

For example, if the data communication is of the video over IP type, the video media packets transported according to the RTP protocol (real-time transport protocol) may or may not pass through the IP proxy 183.

The control packets for video media packets conforming to the RTCP protocol (real-time transport control protocol) pass through the proxy 183 adapted to this video application. The media flow control packet analysis module extracts the RTCP control packets and analyzes their content.

Among the information, one can find for each direction of communication, the transmission delay, the packet loss rate, the bit rate and the jitter. With this information, the delay generated by the voice delay module 181 is adapted.

The subscriber 100 has equipment such as a telephone handset 103, fixed or mobile, connected directly or by means of a PABX 102 to the switched telephone network 141 via a CAA 142. It is to note that the telephone number can be the telephone number of a telephone handset 103 placed on the same site as the computer device or on a different site.

The subscriber 100 also has a computer 104 connected to a local network 105. The local network 105 is connected to an Internet type network 160 by means of a gateway 106 or firewall router capable of routing the data in network 105 and to act as a gateway between network 105 and the Internet 160. It should be noted that the Firewall router 106 can ensure the security of information exchanges between networks 105 and 160 by ensuring that no intrusion can be made into the network 105. The computer 104 has in its memory programs capable of implementing the invention. It includes software 107, and 110.

The software 110 is client-client type applications which communicate with a computer 123 via the local network 105, the Firewall router 106, the Internet network 160, the router 151, the ISP network 150 and a modem 121 The software 107 said client software is the software which dialogs with the server 170 according to the invention and proposes the activation of one or more client-client applications 110 to the subscriber 100 or automatically activates a client-client application.

The subscriber 120 has equipment such as a mobile telephone handset 122 connected to the mobile network 148. The subscriber 120 furthermore has a computer 123 connected by means of a modem 121, to the Internet network 160 by through the network 150 of its Internet service provider, and a router 151.

Modem 121 is a conventional PSTN or ISDN modem. Modem 121 can also be an ADSL (Asynchronous Digital Subscriber Line) type modem or a telecommunication device allowing the transfer of information on the cable or satellite broadcasting network or even a Wifi network (high speed wireless local area network).

The computer 123 has programs 124 and 127 in its memory capable of implementing the invention and offering the same functionalities as the respective software 107 and 110 present on the computer 104 of the subscriber 100.

Fig. 2 shows the service registration algorithm as provided by the invention in the telecommunications network.

A subscriber to the service, for example subscriber 100 in FIG. 1, wishes to establish the telephone / data coupling according to the invention.

For this, the computer 104 of the subscriber 100 executes the client software program 107.

The computer 104 connects via the local network 105, the Firewall router 106, the public Internet network 160, the Firewall router 185 and the local network 184 to the client registration module 172 of the server 170 of the ASP 190 .

The client software program 107 requests in step E100 its registration with the client software registration module 172.

To do this, the client software 107 supplies the client registration module 172 with its user name and the password associated with the name of the user previously assigned when the subscriber 100 has registered for the service. The client software 107 also provides the IP address (Internet protocol address) of the computer 104, the telephone number (s) of the telephone handset (s) used to access the service.

It should be noted that the telephone number can be the telephone number of a telephone handset 103 placed on the same site as the computer device or on a different site.

The client software 107 also provides its user profile, that is to say the port number of the client-client type applications 10 which it has.

It should be noted that, as a variant, the profile of the user can also be produced in a predetermined manner by the ASP 190 providing the service. The client software 107, in this variant, no longer has to provide the user profile, this being created by the ASP 190 and stored in the database 171 of the server 170.

The client software registration module 172 of the server 170 interrogates the database 171 of the server 170 in step E101 in order to authenticate it. This authentication is performed by checking if the user name is recognized as a client and if their password is correct. If not, the connection is rejected, the program stops.

In the affirmative, the client software registration module 172 confirms to the client software 107 the registration in step El 02.

When the registration is confirmed, the server 170 activates a periodic verification procedure for maintaining the connection of the computer 104 to the public Internet network 160.

Periodically, the network event and client software information notification module 173 transmits a request in step E103 to the client software 107. As long as the computer 104 is always connected to the network 160 and the client software 107 is always active, the client software 107 responds to the request by sending to the module for notifying network events and information of the client software 173, in step E1 04, an activity confirmation message. The module for notifying network events and information of client software 173 checks, after having waited for a predetermined period, the reception of the message in step El 05, and in the event of confirmation, returns to step El 03.

On the non-reception of a response to a request transmitted in step El 03, the module for notification of network events and information from client software 173 stops the current session.

According to a particular mode, the connection between the client software 107 and the server of the invention 170 is not permanent. A connection of the TCP (transport control protocol) type is established on the initiative of the client software 107 during the recording phase and is released so as to best share the resources between all of the subscribers.

Thus, when a notification by the server 170 must be transmitted to the client software 107, the server 170 establishes a TCP connection to the client software 107.

According to another variant, the method uses the UDP protocol (User Data Protocol) faster than the TCP protocol. In this case, in order to overcome the reliability problems of the UDP protocol, the client software 107 and the server 170 must guarantee this reliability by generating confirmation messages.

Fig. 3 represents an algorithm describing the kinematics of activation of a client-client type application in parallel with a telephone communication. According to this application, the activation of the client-client application is managed by a service node type architecture, with signaling, media flows and control flows of the client-client application media flows passing through of a proxy module 183. In this example, the IP application is synchronized with the telephone voice application by performing a delay measurement on the IP network and by applying a similar delay to the voice flow carried by the PSTN network.

Prior to a telephone call, the subscriber 100 registers for the service as provided by the invention in the network according to the first embodiment.

The computer 104 connects via the local network 105, the Firewall router 106, the public Internet network 160, the router 185 and the local network 184 to the client registration module 172 of the server 170 of the ASP 190.

The client software program 107, the client software recording module 172 of the server 170 execute the recording algorithm as described previously with reference to FIG. 2.

Once the registration has been made, the subscriber 100 picks up, at step E300, his telephone terminal 103 and dials the telephone number of the service allowing the telephony-data application coupling. This telephone number is associated with the telephone interface 180.

A message for requesting the establishment of a telephone call is transmitted in step E301 to the automatic call module 179.

The automatic call module 179 automatically accepts the incoming telephone call in step E302. As a variant, the automatic call module 179 generates an "Alert" message, or even a message prior to the "Connection" message intended for the telephone terminal 103.

The automatic call module 179, in order to check whether the client software 107 of the subscriber 100 is registered at the server 170, generates a request in step E303 to the database 171 using the telephone number calling in as a search key.

The client software 107 being recorded, the call controller 179 requests the activation of the voice management module and delay 181 in step E304. The voice and delay management module 181 being activated in step E305, the call controller 179 requests the broadcast, by the voice and delay management module 181, of a voice announcement in step E306 asking it to enter the telephone number 122 of his correspondent 120 using the voice frequency dialing of his handset 103.

Note that if the client software 107 has not been previously registered, the voice announcement first asks the caller to activate its client software 107, and then to enter the telephone number 122 of its correspondent 120.

Following the entry of the telephone number of the subscriber 120, by the subscriber 100 in step E307, the number is communicated to the automatic call module 179.

The automatic call module 179 requests, in step E308, the voice management and delay module 181 to broadcast in step E309 a waiting message to the caller 100.

The automatic call module 179 interrogates, in step E310, the database 171, supplying it as primary key the telephone number of the called party 120, in order to check whether the client software 124 is registered.

After confirmation, in step E311, the automatic call module 179 establishes an outgoing telephone call to the subscriber 120 on his telephone 122 via the CAA 142 and the networks 141 and 148. When the subscriber 120 takes the call at step E312, the automatic call module 179 notifies, at step E313, the voice and delay management module 181 so that the latter broadcasts, at the same step, a voice announcement to subscriber 120.

This voice announcement indicates to the called party 120 that the caller 100 wishes to reach him by telephone with the implementation of a client-client application in parallel.

If the called party 120 accepts the communication, and if the client software 124 of the subscriber 120 is not registered with the server 170, the voice message also requests during step E313 the called party 120 to activate its client software 124.

The subscriber 120 activates, in step E314, his software 124 in the same manner as that described for the subscriber 100 with the only difference that the operation is carried out via his ISP 150 and the router 151.

Once the message broadcast to the called party 120, the subscriber side waiting message 100 is stopped and the voice streams are matched without applying delay in step E315. The client software notification module 173 transfers in step E316 to the client software 124 the following notifications: subscriber telephone number 100, subscriber telephone number 120, computer IP address 104, the one or more port numbers of the client-client applications 110 of the subscriber 100 compatible with those of the subscriber 120 and / or the IP address of the proxy 183, the number (s) of its ports compatible with the applications.

As a variant, the module for notifying network events and information of client software 173 transfers in step E316 to client software 124 the port numbers of client-client applications 110 present on the computer 104 of subscriber 100 .

After receiving the event notification sent by the client software notification module 173 in step E316, the client software 124 checks in step E317 using its local configuration stored on the computer 123 the list of actions to be performed . Client software 124 displays on the computer screen 123 at the same stage

E317 the list of possible actions, for example displays an invitation to activate a client type application "Activate Microsoft Netmeeting H323", and / or activate "FTR & D eConf SIP".

If in accordance with the aforementioned variant, the module for notifying network events and information of client software 173 has transferred in step E316 to client software 124 the port numbers of the client-client applications present on the computer 104 of the subscriber 100, the client software 124 further verifies whether the port numbers of the client-client applications 127 are compatible with the port numbers of the client-client applications 110 present on the computer 104 of the subscriber 100. When compatibility exists, the client software 124 performs for example conditional actions on the compatible port numbers.

Of course, the client-client applications 127 compatible with the client-client applications 110 can be activated automatically. This operation carried out, the client-client application 127 puts itself on hold on the TCP / UDP port (s) of the computer 123 assigned to this type of application. This is for example the TCP port 1720 for applications conforming to the H323 format or the TCP / UDP port 5060 for SIP type applications. It should be noted that the IP address of the computer 104 and / or the IP address of the proxy 183 previously received makes it possible to filter incoming calls from other computers than the computer 104.

In addition to the called side registration confirmation 120, the client software registration module 172 informs the client software notification module 173 of the confirmation in step E318. The latter transmits in step E319 to the client software 107 the following information: telephone events "Connection" with the arguments telephone number of the caller, telephone number of the called party, the port number (s) of the client applications compatible client (s) between the caller and the called party and the IP address (es) of the IP proxy (s) 183 compatible with the client-client application (s) and or the IP address of the computer 123.

On receipt of this information, the client software 107 verifies, using its local configuration stored on the computer 104, the list of actions to be performed.

In step E320, the client software 107 displays on the screen of the computer 104 the list of possible actions, for example displays an invitation to activate an application of the client-client type "Activate Microsoft Netmeeting H323", and / or activate "FTR & D eConf SIP". It should also be noted that the activation of the application can be automatic.

When the client-client software application 110 is activated, it sends at step E321 a request depending on the protocol of the client-client application 110 (for example sending a SETUP message H323) to the compatible proxy 183.

On receipt of this request, the proxy 183 interrogates, in step E322, the database 171 in order to obtain the context linked to the IP session between the subscribers 100 and 120. The proxy 183 thus obtains the IP address from computer 123.

To do this, the proxy 183 uses the IP address of the computer 104 as the search key.

The proxy 183 adapted to client-client applications 110 and 127 creates a context comprising the IP address of the computer 104, the original TCP / UDP port number (s) used, the IP address of the computer 123 , the TCP / UDP port number (s) from the IP 183 proxy used.

The proxy 183 then extends, in step E323, the request to the subscriber 120 by using the TCP / UDP port number or numbers linked to the client-client application. On receipt of this request, the client-client application 127 sends a confirmation message, at step E324, to the proxy 183, which extends this confirmation at step E325, to the client-client application 110 , using the information present in the previously created context. The media stream (s) can then transit between client-client applications

127 and 110 in step E326, whether or not passing through the proxy 183. It should nevertheless be noted that the control stream or streams of media streams must necessarily pass in step E326 through the proxy 183. The control streams , more precisely the flow control packets, are received by the IP proxy 183. On receipt of these control flows, the proxy 183 interrogates in step E327, using the IP address of the computers 104 or 123, the database 171 to retrieve the context of the telephony-data session as well as the identifier of the telephone communication and of the voice resources.

Once this information has been obtained, the information on control of the media flow and of the telephone-data session context is transmitted, in step E328, by the proxy 183 to the packet analysis module 182.

The packet analysis module 182, in step E329, analyzes the media flow control packets, obtains information representative of the delay in the media flow, and according to the delay information obtained, generates a request intended for the voice management module and delay 181, so that it applies the same delay previously obtained on the telephone voice flows.

The voice and delay management module 181 applies the delay to the voice flows in step E330.

This system for analyzing IP media flow control packets and voice delay delay applications is periodic. The delays are calculated by the packet analysis module 182 in the following manner in the case of an H323 or SIP video transmission with an RTCP type protocol: the delay TA of the RTCP packets between the computer 104 and is determined. the proxy 183, the delay TB of the RTCP packets between the proxy 183 and the computer 123 is determined, the delays TA and TB are added and a request is sent to the voice management module and delay 181 so that it applies the sum of the delays on the voice stream transmitted by the telephone 103 transmitted to the telephone 122. the RB delay of the RTCP packets between the computer 123 and the proxy 183 is determined, the RA delay of the RTCP packets between the proxy 183 and the computer 104 is determined, the delays RA and RB are added and a request is sent to the destination of the voice and delay management module 181 so that the latter applies the sum of the delays on the voice flow transmitted by the telephone 122 transmitted to the telephone 103.

It should be noted that the voice and delay management module 181 takes into account in the application of the delay, the standard delay of a PSTN telephone communication between the handset 103 and the voice and delay management module 181 and also of the standard delay of PSTN telephone communication between the voice and delay management module 181 and the handset 122.

Fig. 4 represents an SR transmitter report packet conforming to the RTCP protocol. According to the invention, the data flow transmitted between subscribers 100 and 120 through the public Internet network 160 conforms to the H323 protocol.

The H323 protocol uses the RTP (Real time Transport Protocol) protocol to transport the data stream.

The RTP protocol is a multimedia data transport protocol, it does not provide any guarantee as to the quality of service and is placed above the protocol.

UDP or TCP. The RTP protocol allows an application to reconstruct a sequence of multimedia data, in this case the video signals received by the client-client application software 110 and 127.

The RTCP protocol (Real Time Control Protocol) is a protocol which makes it possible to obtain various information on a current RTP session. The RTCP protocol provides information on the quality of data transfer.

More specifically, the RTCP acronym Sender Report SR report packets include information such as reception and transmission statistics of session participants who transfer data over the public Internet 160.

The RTCP SR packets according to the invention allow the server to determine the delays on the data flows circulating on the Internet 160.

RTCP SR packets consist of several fields, field 600 defines the version number of the RTCP protocol. Field 601 is a field for specifying whether the data bytes have a padding portion.

Field 602 is a field intended to contain the number of reports contained in the packet. It should be noted that a report is normally intended for each IT device sending and / or receiving the data stream.

Field 603 identifies the type of packet. It should be noted that according to the RTCP protocol there are five different types of packets. The SR, RR (Receiver Report) packets which are used by the server 170 of the invention to determine the delay on the public Internet network 160, the SDES (Source Description) packets which contain a list of information identifying an RTP source, BYE which indicates that a participant is leaving the call and APP (specific to an application). The last three types of packets are not used for synchronization according to the invention.

Field 604 indicates the total length of the RTCP packet. Field 605 identifies the source, i.e. the originator of the RTCP packet in question. According to the invention, this field allows the server 170 according to the invention to determine the origin of the RTCP packet.

Fields 606 and 607 contain the date and time of sending the message in NTP (Network Time Protocol) format. The NTP provides the number of seconds since ¹ January 1900 OOHOO. Field 606 contains the most significant bits on 32 bits and representative of the whole part of elapsed seconds, field 607 contains the least significant bits on 32 bits and representative of the decimal part of elapsed seconds.

These fields 606 and 607 can be used according to the invention to determine the delay in the flows exchanged by computers 104 and 123 on the Internet 160.

Field 608 contains the sender's clock for RTP packets sent by the sender.

Field 609 includes the total number of payload packets sent by the transmitter from the start of the session until the transmission of the RTCP packet.

Field 610 includes the total number of payload bytes transmitted by the transmitter from the start of the session until the transmission of the RTCP packet. The information contained in this field 610 allows the server 170 of the invention to determine the average bit rate of this source.

Field 611 identifies the source object of this report, that is to say the transmitter of the RTP data relating to the RTCP packet in question. According to the invention, this field allows the server 170 according to the invention to determine the sender of the RTP packets considered.

Field 612 contains statistics on the percentage of packets lost since the last RTCP SR packet was sent.

Field 613 contains the cumulative number, since the start of the session, of lost packets coming from the source that sent the packets in question. It should be noted that packets arriving late are not considered as lost packets while duplicate packets are counted at each duplication.

Field 614 contains the last received sequence number. This consists of 32 bits, the 16 least significant bits contain the largest sequence number received while the 16 most significant bits contain the number of cycles of past sequence numbers.

Field 615 includes an estimate of the variance of the time between the arrival of RTP packets. This calculation is performed by the transmitter of the RTCP SR packet from the information contained in field 608 and from its internal clock. Field 616 LSR (Last Sender Report timestamp) contains the value of the field

607 of the last RTCP SR packet sent by the recipient of the RTCP SR packet in question.

Field 617 DLSR (Delay Since Last Sender Report) contains the delay between the reception of the last SR packet from the recipient of the RTCP SR packet in question and the transmission of the RTCP SR packet in question.

The server 170 according to the invention uses the field 617 to determine the propagation delay in the network or RTT (Round Trip Time).

Note that RTCP SR packets are broadcast to all computers in the session. An RTCP SR packet can contain information for multiple sources. For each other source, fields 611 to 617 are then duplicated in the RTCP SR packet.

The RTCP RR packet contains information similar to that contained in an RTCP SR packet, so it will not be described in detail. In the following description, we will only describe the invention with RTCP SR packets, it is understood that the invention also alternatively uses RTCP RR packets in the same way as that which will be described with RTCP packets

SR thereafter. Fig. 5a represents an algorithm describing the determination of the delay on the public Internet network 160 according to the first embodiment of the invention.

According to this first embodiment, the media stream transmitted by a computer as well as the media stream control stream, more particularly the RTCP packets, are transmitted to the proxy 183 of the server 170 which then extends the media stream to the other computer.

By way of example, the computer 104 of the subscriber 100 sends a data stream to the proxy 183, the proxy 183 then extends this data stream to the computer 123 of the subscriber 120.

Also the computer 123 of the subscriber 120 transmits a data stream intended for the proxy 183, the proxy 183 then extends this data stream intended for the computer 104 of the subscriber 100.

The algorithm of FIG. 5a describes an exchange of RTCP SR packets between the subscriber 100 and the proxy 183. From this exchange of packets the server 170 according to the invention determines the delay RA of the packets between the proxy 183 and the computer 104. The delay TA of the packets between the computer 104 and the proxy 183 is here considered to be identical to the delay RA.

The determination of the delay RB of the packets between the proxy 183 and the computer 123 is carried out in a similar manner, it will therefore not be described in more detail. Similarly, the delay TB of packets between the computer 123 and the proxy 183 is here considered to be identical to the delay RB.

In step E501, the proxy 183 generates an RTCP SR packet intended for the computer 104 of the subscriber 100.

The proxy 183 inserts into the RTCP SR packet, inter alia, its identifier in field 605, the date and time noted Hl of the sending of the RTCP SR message in fields 606 and 607, the identifier of the computer 104 of subscriber 100 in field 611. In the following step E502, the proxy 183 transmits this packet to the computer 104 via the local network 184, the Firewall router 185, the public Internet network 160, the router 106 and the local network 105.

The computer 104 receives the RTCP SR packet in step E503. On receipt of the RTCP SR packet, the computer 104 stores in step E504 the time of its internal clock for receiving the packet denoted H2.

This operation carried out, the computer 104 stores in other things the content of the fields 606 and 607 of the RTCP SR packet received in step E505.

Step E506 consists of a waiting loop for the computer 104 to generate an RTCP SR packet for controlling the data flow received from the proxy 183.

When the computer 104 wishes to transmit an RTCP SR packet, this stores in step E507, the time of its internal clock.

The computer 104 inserts in step E508 the content of the field 607 stored in step E505 in the field 616 of the RTCP SR packet to be transmitted. The computer 104 inserts in step E509 the difference in hours H3-H2 stored in steps E504 and E507 in field 617 of the RTCP SR packet to be transmitted.

Of course, the computer inserts other information into the different fields of the RTCP SR packet, this is not described. The packet thus formed is transmitted in step E510 by the computer 104 of the subscriber 100 to the proxy 183 of the server 170 via the local network 105, the firewall router 106, the public Internet network 160, the firewall router. 185 and the local network 184.

The proxy 183 of the server 170 receives the RTCP SR packet in step E511. On receipt of the RTCP SR packet, the proxy 183 queries the database

171 to retrieve the context of the telephony-data session as well as the identifier of the telephone communication and of the voice resources associated with the data flow.

Once this information has been obtained, the media flow and telephone-data session context control information is transmitted by the proxy 183 to the packet analysis module 182 in accordance with step E328 of FIG. 3 previously described.

The packet analysis module 182 stores in step E512 the time denoted H4 of its internal clock for receiving the packet. This operation performed, the packet analysis module 182, in step E513, stores the content of field 617 of the RTCP SR packet received in step E511.

The packet analysis module 182 also stores in step E514 the content of the field 616 of the received RTCP SR packet. The packet analysis module 182 of the server 170 obtains in step E515 the delay of the RTCP packets between the proxy 183 and the computer 104 by subtracting from the time H4 stored in step E512 the contents of the fields 617 and 616 previously stored in the respective steps E513 and E514.

The packet delay thus calculated, for example 200 ms, is equal to the sum of the delays TA and RA previously mentioned with reference to FIG. 3.

For the sake of simplicity these are considered to be equal. Thus TA = RA = 100ms.

The determination of the RB delay of the RTCP packets between the proxy 183 and the computer 123 is carried out in a similar manner to that described with reference to steps E501 to E516, the RTCP control packets SR are sent by the proxy 183 to the computer 123 from subscriber 120 in step E502 and RTCP SR control packets are sent by computer 123 from subscriber 120 to proxy 183 in step E510.

The packet delay thus calculated, here 240ms, is equal to the sum of the delays TB and RB previously mentioned with reference to FIG. 3. For the sake of simplicity these are considered to be equal. So

TB = RB = 120ms.

The packet analysis module 182 generates in step E516 a request intended for the voice management module and delay 181, so that the latter applies the delays TA + TB previously obtained on the voice flow transmitted from the telephone 103 to the phone 122.

The packet analysis module 182 generates in the same way in step E516 a request intended for the voice management module and delay 181, so that the latter applies the delays RA + RB previously obtained on the voice flow transmitted from the phone 122 to phone 103. Fig. 5b represents an algorithm describing the application of the delay on the telephone voice flows carried out by the voice and delay management module.

The voice and delay management module 181 controls one or more telephone interface cards, for example of the DTI300SC-E1 type manufactured by the company Dialogic-intel or of the AGS-1000 type of the company Natural Micro System. These cards have an ISDN type B interface at a speed of 64Kbit / s and a signaling channel D at a speed of 64Kbit / s. Cards with T0 / S0 interfaces that have two B channels at a rate of 64Kbit / s and a signaling channel D at a rate of 16Kbit / s can also be used. These cards include buffer memories, for each voice stream and in each direction of the voice stream, which memorize the audio streams received and / or to be transmitted.

Each voice stream obtained from the PSTN network 141 is for example stored in a respective circular memory having a storage capacity of the order of 500 milliseconds (ms) or even 1 second of voice stream. For example, the synchronous speed of a G711 law A type telephone communication being 64 Kbit / s, the data is written and read in the circular memory every 20 ms.

We will now describe the application of the voice delay to a single voice stream, when several voice streams are simultaneously to be delayed, the voice management module 181 performs the algorithm of FIG. 5b for each of the voice streams to be processed.

The voice and delay management module 181 receives in step E520 from the packet analysis module 182 the delay to be applied to a voice stream. This delay is for example equal to 220 ms. The voice and delay management module 181 obtains in step E521 the address

Ptr_ec of the write pointer of the circular memory containing the incoming voice stream.

The write pointer storing the data every 20 ms, the voice and delay management module 181 determines in step E522 the duration of the voice stream stored in the circular memory by multiplying the address Ptr_ec by 20 ms. For example, the Ptr_ec write pointer being at address 14, the duration of the voice stream stored in the circular memory is 280 ms.

The voice and delay management module 181, in step E523, makes the difference between the delay RA received in step E520 and the duration of voice flow stored in the circular memory determined in step E522. According to our example the difference Dvx is equal to 60 ms.

The voice and delay management module 181, in step E524, determines the address of the pointer for reading the circular memory Ptr_lec by determining the integer part of the division of the difference Dvx by the reading rhythm of the circular memory which is 20 ms according to our example. According to our example, the address of the read pointer of the circular memory Ptr_lec is equal to 60ms / 20ms or 3.

The voice and delay management module 181, in step E525 transfers the value of the read pointer Ptr_lec to the telephone interface card managing the audio stream on the PSTN network 141.

Thus, the voice streams transmitted over the switched network 141 are delayed in the same way as the media streams are delayed by the public Internet network 160.

Fig. 6 shows a second embodiment of the invention in a telecommunications network comprising a service node architecture or service node in the context of a service for connecting subscribers in conference.

The telecommunications network includes an ASP application service provider denoted 290 which can for example be associated with a telecommunications operator 240. The telecommunications network also comprises a switched telephone network 241 and a public Internet network 260. The switched telephone network is here considered to be a synchronous telecommunications network, the public Internet network 260 being the asynchronous telecommunications network.

The switched telephone network 241 is associated with a range autonomy switch CAA denoted 242 allowing the provision of conventional telephone service to a subscriber 200 and a subscriber 291. The PSTN network 241 is also associated with a range switch CAA noted 245 allowing the provision of conventional telephone service to a subscriber 220.

The ASP 290 application service provider includes a local network 284. The local network 284 is also connected to the public Internet network 260 through a firewall router 285 also ensuring the security of information exchanges between networks 284 and 260 ensuring that no intrusion can be made into network 284.

A server 270 is connected to this local network 284. The server 270 or conference bridge is also connected to the telephone network 241 via the routing autonomy switch 242.

The server 270 is either centralized on a single device or distributed over different devices placed or not on the same site. The server 270 consists of a service database 271 identical to the database 171 in FIG.

The server 270 also includes a recording module 272 of the client software of the subscribers to the service identical to the recording module 172 of the client software of the subscribers of FIG. 1.

The server 270 also includes a module 273 for notification of network events and information from client software identical to the module 173 for notification of network events and information from client software in FIG. 1.

The server 270 also includes an IP interface 278 of Ethernet type which allows the server 270 to connect with the local network 284.

The server 270 includes a telephone answering module 279 which processes the signaling of incoming and outgoing telephone calls and their acceptance.

The server 270 comprises a telephone interface PSTN 280 of the ISUP type or of the SS7 type which allows the connection of the server 270 with the telephone network 241 via the CAA 242 of the telecommunications operator 240.

The server 270 also includes a module 281 for mixing the PSTN and delay telephone voice flows allowing the generation of delay between the active incoming voice flows and the outgoing voice flows. The delays can be different depending on the direction of the communication. We mean here as active incoming voice stream, the voice stream which contains information representative of a higher activity compared to the other streams. It is for example the voice stream which has the highest sound level. The voice stream of the conference initiator or the voice stream of the conference master can also be considered as the active incoming voice stream in a predetermined manner. This active voice stream can also be defined according to the period of activity or inactivity of the stream. The active voice stream is determined by the module 281 for mixing PSTN and delay voice voice streams.

The server 270 also includes a module 282 for mixing analysis of IP media flows, for example of packet type of video RTP type managed by the H323 / SIP protocols. The mixing is dependent on the supported applications. The mixing module 282 extracts and analyzes the IP media flow control packets, for example video RTCP packets of the H323 / SIP type. Among the analyzed information, one can find for each direction of transmission, the delay, the rate of loss of packets, the jitter and the bit rate. The information obtained at the level of mixing module 282 will make it possible to apply delays to the PSTN voice flows via the module 281 for mixing the PSTN telephone voice flows and delay.

The server 270 also includes an IP applications responder module 283 which processes the signaling signals of the communications. The IP 283 applications answering module includes a plurality of modules each capable of processing signals (H323 or SIP) by type of application.

Subscriber 200 has equipment such as a telephone terminal 203 connected to the switched telephone network 241 through the CAA 242.

Subscriber 200 also has a computer 204 connected to the Internet 260.

The computer 204 has in its memory programs capable of implementing the invention. It includes software 207 and 210 offering the same functionalities as the respective software 107 and 110 in Fig.l.

Subscriber 220 has equipment such as a telephone terminal 222 connected to the switched telephone network 241 via a CAA 245.

Subscriber 220 also has a computer 223 connected to the Internet 260.

The computer 223 has in its memory programs capable of implementing the invention. It includes software 224 and 227 offering the same functionalities as the respective software 124 and 127 in FIG. 1.

The subscriber 291 has equipment such as a telephone terminal 292 connected to the switched telephone network 241 via the CAA 242.

The subscriber 291 also has a computer 295 connected to the Internet type network 260. The computer 295 has in its memory programs capable of implementing the invention. It includes software 294 and 293 offering the same functionalities as the respective software 107 and 110 in FIG.

Fig. 7 represents an algorithm describing the kinematics of activation of a conference call between three subscribers, coupled with a client-client type application managed within the framework of a service node type architecture in the network of FIG. 6.

Prior to a telephone call, subscriber 200 registers for the service as provided by the invention in the network according to the second embodiment. For this, the computer 204 of the subscriber 200 executes the client software program 207.

The computer 204 connects via the public Internet network 260 to the client registration module 272 of the server 270 of the ASP 290. The client software program 207, the client software registration module 272 of the server 270 execute the algorithm. as previously described with reference to FIG. 2.

Once the registration has been made, subscriber 200 picks up his telephone terminal 203 and dials, in step E700, the telephone number of the service allowing the telephony-data application coupling. This telephone number is associated with the telephone interface 280.

A message for requesting establishment of a telephone call is transmitted, in step E701, to the telephone answering module 279.

The telephone answering module 279 automatically accepts the incoming telephone call in step E702.

As a variant, the telephone answering module 279 generates an "Alert" message, prior to the "Connection" message intended for the telephone handset 203.

The telephone answering module 279, in order to obtain the context of the session, generates a request, in step E703, to the database 271 which uses the calling telephone number as a search key. Note that the session context includes the voice channel number available for the application as well as the IP address of computer 204.

This context having been obtained, the telephone answering module 279 generates a request to activate the mixer and delay module 281 in step E704. The mixer and delay module 281 being activated, the telephone answering module 279 requests the broadcast, by the mixer and delay 281, of a voice announcement, intended for subscriber 200, on the voice channel of the selected context.

This voice announcement is a welcome and wait voice announcement. It is broadcast in step E705. In addition to the telephone call, the telephone answering module 279 informs the client software notification module 273 of the call. The latter transmits, in step E706, to the client software 207, the following information: telephone events "Connection" with the arguments telephone number of the caller, telephone number of the telephone answering machine 279, the IP address or addresses of the IP 283 answering machines and the port number (s) of IP283 answering machines compatible with the client-client application (s) of subscriber 200.

For example, the client software notification module 273 transmits to the client software the following port numbers 194.254.161.225: 1720, 194.254.161.226: 5060 and 194.254.161.227: 1503.

These port numbers are used to indicate to the client software 207 that the server 270 is able to support an H323 answering application if the client software uses the IP address 194.254.161.225, that the server 270 is able to support a SIP application if the client software uses the IP address 194.254.161.226 and the server 270 is capable of supporting an answering application sharing application of the type conforming to the standard T120 if the client software uses the IP address 194.254.161.227.

On receipt of this information, in step E707, the client software 207 verifies, using its local configuration stored on the computer 204, the list of actions to be performed. The client software 207 displays on the screen of the computer 204 the list of client-client applications compatible with those managed by the conference bridge or server 270, for example displays an invitation to activate a client-client type application "Activate Microsoft Netmeeting H323 ", and / or activate" FTR & D eConf SIP ". Note that the activation of the application can be automatic. When the client-client software application 210 is activated, the latter issues in step E708 a request dependent on the protocol of the client-client application 210 (example sending a SETUP message H323) to the compatible IP responder module 283.

On receipt of this request, the IP responder module 283 interrogates, in step E709, the database 271 in order to obtain the context linked to the IP session between the subscriber 200 and the server or server conference bridge 270 .

To do this, the IP responder module uses the IP address of computer 204 as the search key.

In addition, it is verified in particular that the telephone communication between the subscriber 200 and the server of the invention 270 is always active and that IP media resources are available.

If so, the IP responder module 283 confirms, in step E710, the IP request generated in step E708 and transmits the IP address or addresses of the mixer module analyzing IP media flows 282 as well as the TCP port (s) / UDP to use. The IP responder module 283 requests, in step E711, the IP media analysis mixer module 282 to put itself on hold for a call.

The client-client application 210 then establishes, in step E712, the media channel and IP media control channels with the mixer module analyzing IP media flows 282.

It should be noted that the call of the subscriber 200 corresponds to the first call on the conference bridge 270, information of the welcome announcement type, of the video on hold type can be broadcast to the subscriber 200 if the application is of client-client video H323 / SIP type. Regularly, the mixer module for analyzing IP media flows 282 obtains information for controlling IP media flows exchanged with the client-client application 210 and interrogates the database 271 in step E713.

The mixer module for analyzing IP media flows 282 thus obtains, using the IP address of computer 204 as a primary key, the context of the session comprising the references of the incoming and outgoing telephone channels.

Once this information has been obtained, the IP 282 media flow analysis module analyzes the media flow control packets, obtains information representative of the delay, jitter, packet loss of the media flow and, based on this information, controls step E714, the mixer and vocal delay module 281.

Thus, the telephone voice stream, which is for example music on hold, synchronized with the H323 / SIP video transmitted by the server of the invention 270 to the subscriber 200, is more or less delayed. This delay is applied in step E715.

When subscriber 220 picks up his telephone terminal 222 and dials the telephone number of the service allowing the telephony-data application coupling, this telephone number being associated with the telephone interface 280, a call establishment request message telephone is transmitted, at step

E716, to the answering machine module 279.

The telephone answering module 279 accepts the incoming telephone call in step E717.

Then, the telephone answering module 279 consults, in step E718, the database 271 with the primary key calling telephone number in order to obtain the context of the session comprising the number of an available voice channel, and the IP address of computer 223 if client software 224 is enabled. If the client software 224 is not activated, the IP address of the computer 223 of subscriber 220 will not be provided. In this case, in step E719, the telephone answering machine 279 generates a message, intended for the voice delay and mixer module 281 so that the latter broadcasts, in step E720, intended for subscriber 220, a voice announcement. welcome as well as a voice announcement message inviting subscriber 220 to activate his client software 224. The voice connection in conference mode between subscribers 200 and 220 is then activated on the selected voice channel.

If the client software 224 of subscriber 220 is not activated and registered, the latter is activated and registered. The 224 client software is activated manually or automatically. The IP call signaling is exchanged with the compatible IP 283 answering module. The media channel (s), as well as the IP media control channel (s) are established with the IP media flow analysis mixer module 282 in the same way as that described above for the subscriber 200.

Subscriber 220 being the second subscriber to have called the service, client-client applications 210 and 227 of subscribers 200 and 220 are connected via the conference bridge or IP 270 server. The mixer module analyzes media flows

IP 282 obtains the media flow control information exchanged by client-client applications 210 and 227.

The mixer module analyzes IP media flows 282 interrogates the database 271 in step E721 in order to obtain the two session contexts and more particularly the references of the telephone channels of the communications between the subscriber 200 and the server of the invention 270 and between subscriber 220 and the server of invention 270.

Once this information has been obtained, the IP 282 media flow analysis mixer module analyzes the media flow control packets, obtains information representative of the delay, jitter, packet loss of the media flow, and based on this information, checks to step E722 the mixer and vocal delay module

281.

Thus, at this same stage, the telephone voice flow transmitted by the server 270 to the subscriber 200 is more or less delayed. In the same way, the telephone voice flow transmitted by the server 270 to the subscriber 220 is also more or less delayed. More precisely, the delay is applied to the voice stream considered as a slave voice stream, the master voice stream being the voice stream considered to be active. The delays are calculated as follows in the case of an H323 or SIP video transmission with an RTCP type protocol: the TA delay resulting from the RTCP packets between the computer 204 and the mixer module analyzes the IP media flows is determined 282, the delay TB from the RTCP packets is determined between the IP media flow analysis mixer module 282 and the computer 223, the TA and TB delays are added and a request is sent to the voice mixer and delay module 281 so that the latter applies the sum of the delays on the voice stream transmitted by the telephone 203 and transmitted to the telephone 222. the delay RB from the RTCP packets between the computer 223 and the mixer module analyzes the IP media flows 282 is determined, it is determined the delay RA originating from the RTCP packets between the mixer module analyzing IP media flows 282 and the computer 204, adding the delays RA and RB and generating a request intended for the voice mixer module and delay 281 so that this it applies the sum of the delays on the voice flow transmitted by the telephone 222 and transmitted to the telephone 203.

It should be noted that the voice and delay mixer module 281 takes into account in the application of the delay, the standard delay of a telephone call.

PSTN between handset 203 and voice mixer module and delay 281 and also the standard delay for a PSTN telephone call between voice mixer module and delay 281 and handset 222.

When a third subscriber dials, via his telephone handset 292, the telephone number associated with the telephone interface 280, the telephone module performs the same operations as those described for calling subscriber 220 to the number associated with the telephone interface 280.

The third subscriber 291 activates his client software 294 which registers with the recording module 272. The client-client software 293 is then activated manually or automatically, the IP call signaling is exchanged with the compatible IP responder module 283, the media channel (s), the IP media control channel (s) are established with the IP media flow analysis mixer module 282 in the same way as that described above for subscriber 200. These procedures will therefore not be described further detail.

Then, the connection in voice conference mode is established for subscribers 200, 220 and 291. As regards the third call on the IP 270 conference bridge, the client-client applications 210, 227 and 293 compatible with subscribers 200, 220 and 291 are found in connection through the server or IP 270 conference bridge.

The IP 282 media flow analysis mixer module periodically obtains media flow control information exchanged with client-client applications 210, 227 and 293.

The mixer module analyzes IP media flows 282 interrogates the database 271 in order to obtain the three session contexts using the IP addresses of computer 204, computer 223 and computer 295 as primary key and more particularly the references of the incoming and outgoing telephone channels of the communications between the subscriber 200 and the server 270, between the subscriber 220 and the server 270 and between the subscriber 291 and the server 270.

The mixer module analyzes IP media flows 282 analyzes the media flow control packets, obtains information representative of delay, jitter, loss of packets from the media flow, and as a function of this information, checks in step E723 , the mixer and voice delay module 281.

Thus, the telephone voice flow transmitted by the server 270 to the subscriber 200 is more or less delayed in step E724.

In the same way, the telephone voice stream sent by the server 270 to the subscriber 220 is more or less delayed in step E725 and the telephone voice stream sent by the server 270 to the subscriber 291 is more or less delayed at step E726.

Three subscribers being in conference, only one of the three subscribers at a given time speaks. The other two subscribers listen to the voice stream broadcast by this subscriber. The delays are calculated as follows in the case of an H323 or SIP video transmission with an RTCP protocol:

If subscriber 200 transmits a voice stream: the RAM delay from the RTCP packets between the computer 204 and the IP media stream analysis mixer module 282 is determined, the RMB delay from the RTCP packets between the mixer analysis analysis is determined IP media flow 282 and the computer 223, the RAM and RMB delays are added together and a request is sent to the voice mixer and delay module 281 so that the latter applies the sum of the delays to the voice flow transmitted by the telephone 203 and transmitted to phone 222, the RMC delay resulting from the RTCP packets between the mixer module for analyzing IP media flows 282 and the computer 295 is determined, the RAM and RMC delays are added and a request is sent to the voice mixer and delay module 281 so that it this applies the sum of the delays on the voice flow transmitted by the telephone 203 and transmitted to the telephone 292,

If subscriber 220 transmits a voice stream: the RBM delay from the RTCP packets between the computer 223 and the IP media stream analysis mixer module 282 is determined, the RMA delay from the RTCP packets between the mixer analysis analysis parameters is determined IP media flow 282 and the computer 204, the RBM and RMA delays are added and a request is sent to the voice mixer and delay module 281 so that the latter applies the sum of the delays to the voice flow transmitted by the telephone 222 and transmitted to the telephone 203. the RMC delay resulting from the RTCP packets is determined between the IP media flow analysis mixer module 282 and the computer 295, the RBM and RMC delays are added and a request is sent to the voice mixer module and delay 281 so that the latter applies the sum of the delays on the voice stream transmitted by the telephone 222 and transmitted to the telephone 292,

If subscriber 291 transmits a voice stream: the RCM delay from the RTCP packets between the computer 295 and the IP media stream analysis mixer module 282 is determined, the RMA delay from the RTCP packets between the mixer analysis module is determined IP media flow 282 and the computer 204, the RCM and RMA delays are added and a request is sent to the voice mixer and delay module 281 so that the latter applies the sum of the delays to the voice flow transmitted by the telephone 292 and transmitted to the telephone 203, the RMB delay from the RTCP packets is determined between the IP media flow analysis mixer module 282 and the computer 223, the RCM and RMB delays are added and a request is sent to the voice mixer module and delay 281 so that the latter applies the sum of the delays on the voice stream transmitted by the telephone 292 and transmitted to the telephone 222,

Fig. 8 represents an algorithm describing the determination of the delay on the packet telecommunications network according to the second embodiment of the invention. Since the client-client applications 210 and 227 compatible with subscribers 200 and 220 are connected through the server or IP conference bridge 270, the mixer module for analyzing the IP media flows 282 periodically obtains information for controlling the media flows of the client applications. client 210 and 227. The media flow transmitted by a computer as well as the media flow control flow, more particularly the RTCP packets, are transmitted to the IP media flow analysis mixer module 282 of the server 270 which then extends the media flow to destination other computer (s).

For example, the subscriber computer 204 of the subscriber 200 sends a data stream to the IP media stream analysis mixer 282, the IP media analysis mixer module 282 interrogates the database 271 in order to obtain the two session contexts using the IP addresses of computer 204 and computer 223 as primary key and more particularly the references of the incoming and outgoing telephone channels of communications between subscriber 200 and server 270 and between subscriber 220 and the server 270, the mixer analyzes IP media flows 282 then extends this data flow to the computer 223 of subscriber 220.

In step E801, the mixer module analyzing IP media flows 282 receives a media flow control packet, for example an RTCP SR packet sent by the client-client application 210 relating to a transfer of data streams between the client-client application 210 and the mixer module analyzes IP media flows 282.

The mixer module for analyzing IP media flows 282 determines in step E802 the sender of this message by reading the identifier contained in field 605 of the RTCP SR packet shown in FIG. 4. This identifier corresponds, for example, to that of the client-client application 210. The IP media flow analysis mixer module 282 checks in the next step E803 whether it has previously transmitted an RTCP SR packet to the client application. client 210.

If not, the IP media flow analysis mixer module 282 goes to step E804. At this stage, the IP media flow analysis mixer module 282 waits, if necessary, for a predetermined time before proceeding to steps E805 to E806. In fact, in order not to have too great a relationship between the control packets and the RTP stream packets, the IP 282 media stream analysis mixer module may have to wait a more or less significant time before generating itself. an RTCP packet. In step E805, the IP media flow analysis mixer module 282 generates an RTCP SR packet intended for the client-client application 210.

The IP 282 media flow analysis mixer module inserts in its RTCP SR packet among other things its identifier in field 605, the date and time noted Hi of the sending of the RTCP SR message in fields 606 and 607, the identifier of the computer 204 of the subscriber 200 in the field 611. It should be noted that i is an index associated with the computer 204 and / or with the client-client application 210.

In the next step E806, the IP media flow analysis mixer module 282 stores the time denoted Hi and proceeds to step E807 to the transfer of the RTCP SR packet previously generated in step E805 via the interface IP 278, local network 284, firewall router 285, and public Internet network 260.

Once the transfer has been made, the IP media flow analysis mixer module 282 returns to step E801 and receives a new RTCP SR packet at this step.

The IP media flow analysis mixer module 282 determines in step E802 the sender of this message by reading the identifier contained in field 605 of the RTCP SR packet, this is for example the identifier of the client application - customer 227.

The IP media flow analysis mixer module 282 checks in the next step E803 whether it has previously transmitted an RTCP SR packet to the client-client application 227. In our example, the verification is negative, the flow analysis mixer module IP media 282 performs steps E805 to E807 in the same manner as that previously described, it then stores the corresponding time Hi where i is the index associated with the computer 220 or with the client-client application 227.

These operations carried out the IP media flow analysis mixer module 282 returns to step E801 and receives at this step a new RTCP SR packet. The IP media flow analysis mixer module 282 determines in step E802 the sender of this message, this is for example the identifier of the client-client application 210.

The IP 282 media flow analysis mixer module checks in the next step E803 whether it has previously transmitted an RTCP SR packet to the client-client application 210. In our example, this is the case, one hour Hi, with i computer index 204, was previously stored.

The mixer module analyzes IP media flows 282 then goes to step E808 and stores the time Ti at which the packet was received. It should be noted that i is here an index associated with the computer 204 and / or with the client-client application 210. The mixer module analyzes IP media flows 282 reads and stores, in the next step E809, the content of field 617 of the RTCP SR packet shown in FIG. 4. In our example, this corresponds to the time elapsed between the time at which the client-client application 210 received an RTCP SR packet from the IP media flow analysis mixer module 282 and the time at which the client-client application 210 issued the RTCP SR packet being processed.

Once this operation has been completed, the mixer module analyzes IP media flows 282 calculates in step E810 the propagation delay noted DIP existing between the client-client application in question, in this case the client-client application 210 and the module IP 282 media flow analysis mixer.

The IP media flow analysis mixer module 282 calculates the DIP propagation delay by subtracting from the time Ti stored in step E808 the time Hi stored in step E806 as well as the content of the field 617 stored in step E809.

The DIP delay thus obtained is thus representative of a round trip of a packet between the client-client application 210 and the mixer module analyzing IP media flows 282 through the Internet network 260, the router 285 and the local network. 284.

It should be noted that the DIP delay is equal to the sum of the RMA delays from the RTCP packets between the mixer module for analyzing IP media flows 282 and the computer 204 and RAM from the RTCP packets between the computer 204 and the mixer module IP 282 media flow analysis.

For the sake of simplification, each of the RMA and RAM delays is considered equal to half of the DIP delay.

Once this operation has been completed, the mixer module analyzes IP media flows 282 then goes to step E811 which consists in interrogating the database 271 in order to obtain the session contexts using the IP addresses of the computer 204, of the computer 223 as primary key and more particularly the references of the incoming and outgoing telephone channels of the communications between the subscriber 200 and the server 270 and between the subscriber 220 and the server 270.

The mixer module analyzes IP media flows 282 knowing the references of the incoming and outgoing telephone channels of communications between subscriber 200 and server 270 and between subscriber 220 and server 270, adds the RAM and RMB delays and generates step E812, a request to the voice mixer and delay module 281 so that the latter applies the sum of the delays on the voice flow transmitted by the telephone 203 and transmitted to the telephone 222. The mixer module analyzes IP media flows 282 adds the RBM and RMB delays and at the same step E812 generates a request for the voice mixer module and delay 281 so that the latter applies the sum of the delays on the voice flow transmitted by the telephone 222 and transmitted to telephone 203. It should be noted here that, as a variant, the mixer module analyzes media flows

IP 282 interrogates the voice mixer and delay module 281 so as to determine the active voice flow, that is to say which subscriber is transmitting the voice flow. Depending on the response, if for example the subscriber 200 is speaking, the mixer module analyzes IP media flows 282 generates only one request to the voice mixer module and delay 281 so that the latter applies the sum of the delays on the voice stream transmitted by the telephone 203 and transmitted to the telephone 222.

It should be noted that according to our example, the RBM and RMB delays have not yet been calculated, they are therefore considered to be zero. As a variant, they can be fixed at a predetermined value representative of average delays evaluated during previous sessions.

Once this operation has been carried out, the mixer module analyzes IP media flows 282 returns to step E804 previously described and performs steps E805 to E807 to finally return to step E801 to receive a new packet.

It should be noted that when the mixer module analyzes IP media flows 282 receives an RTCP SR packet from the application 227 from the computer 223, the latter performs the steps E801 to E803 and E808 to E812 in the same way and determines thus in step E810, the delay equal to the sum of the RMB delays originating from the RTCP packets between the mixer module analyzing IP media flows 282 and the computer 223 and RBM originating from the RTCP packets between the computer 223 and the mixer mixing module IP 282 media streams. These RMB and RBM delays are considered equal to half the DIP delay.

The mixer module analyzes IP media flows 282 adds the RAM and RMB delays and generates in step E812 a request to the voice mixer and delay module 281 so that the latter applies the sum of the delays to the voice flow transmitted by the telephone 203 and transmitted to telephone 222. It adds the RBM and RMB delays and generates, at the same step E812, a request intended for the voice mixer and delay module 281 so that the latter applies the sum of the delays on the voice stream transmitted by telephone 222 and transmitted to telephone 203. It should be noted here that, if the client-client application 227 of subscriber 220 is a non-active application in the sense that it does not transfer a video stream, this instead of generating RTCP SR packets generates RTCP RR (receiver report) packets which are similar to RTCP SR packets and treated by the IP 282 media stream analysis mixer module in the same way as RTCP SR packets.

If the subscriber 291 joins the conference bridge in the meantime, the mixer module analyzes the IP media flows 282 adds the RAM and RMC delays and at step E812 generates a request intended for the voice mixer and delay module 281 so that the one - this applies the sum of the delays on the voice flow transmitted by the telephone 203 and transmitted to the telephone 292.

The mixer module analyzes IP media flows 282 adds the RBM and RMC delays and generates in step E812 a request intended for the voice mixer and delay module 281 so that the latter applies the sum of the delays on the voice flow transmitted by the telephone 222 and transmitted to telephone 292. The delays between RCM and RMC are determined in the same way as that previously described. They will not be described further.

It should be noted here that, as a variant, the mixer module analyzes IP media flows 282 interrogates the voice mixer module and delays 281 so as to determine the active voice flow, that is to say which subscriber is in the process of play the voice stream. Depending on the response, if for example the subscriber 200 is speaking, the mixer module analyzes IP media flows 282 only generates two requests to the voice mixer module and delay 281 so that the latter applies the sum delays on the voice stream sent by the phone 203 and transmitted to the phone 222 and so that the latter applies the sum of the delays on the voice stream sent by the phone 203 and transmitted to the phone 292

The voice mixer and delay module 281 applies each delay to the telephone voice flows in the same way as that described by the voice management and delay module 181 with reference to FIG. 5b.

The voice mixer and delay module 281 applies the delays corresponding to the delays transmitted by the IP media flow analysis mixer module 282 if these delays are to be applied to the active voice flows, or alternatively the voice mixer and delay module 281 applies the corresponding delays delays transmitted by the IP 282 media flow analysis mixer module. As a variant, the media stream mixing module 282 reads from the RTCP SR packets received the field 615 comprising information on the variance of the time spent between the arrival of the RTP packets. If the variance is relatively large, for example of the order of a hundred milliseconds, the media stream mixing module 282 corrects the delays to be applied as a function thereof. In fact, computers 204, 223 and 295 adjust the size of their respective reception buffers to overcome this problem of variance or jitter, which of course delays the restitution of the video stream.

The media stream mixing module 282 on the basis of this variance information then increases the delay on the corresponding audio stream, for example by an additional delay of the order of 40 milliseconds.

According to another variant, the audio data stream is transmitted over the asynchronous network while the video data stream is transmitted over the synchronous network. The video stream is then delayed in the same way as that described above. Synchronization as described above is carried out from packets conforming to the RTCP protocol. Of course, other types of packets conforming to other protocols can be used to determine the delay on the asynchronous network.

By way of example, the server according to the invention can also operate with proprietary client-client applications different from the "Microsoft Netmeeting H323", or "FTR & D eConf SIP" applications.

The server according to the invention can also use packets of the ICMP (Internet Control and Error Message Protocol) type. To do this, periodically, for example every second, the server generates ICMP packets to subscribers' computers and stores the time at which they are sent. The server also memorizes the time at which each response sent by the computer is received and thus calculates the round trip delay of transfer between the server and each computer. Note that in this case, computers must respond immediately upon receipt of ICMP packets. The invention as described can also synchronize two audio streams, one of the streams being carried on an asynchronous telecommunications network and the other being carried on a synchronous telecommunications network. The invention can also synchronize in the same way two video streams or any type of stream passing over different telecommunication networks. Of course, the present invention is not limited to the embodiments described here, but encompasses, quite the contrary, any variant within the reach of ordinary skill in the art.

Claims

1) Device for synchronizing (190, 290) a multimedia stream made up of two separate multimedia streams in a telecommunication network made up of a synchronous telecommunication network (141, 148, 241) and an asynchronous telecommunication network ( 160, 260), one of said flows passing through the asynchronous telecommunications network, the other flow passing through the synchronous telecommunications network, characterized in that the device comprises:

- means (182, 183, 282, 283) for obtaining delay information representative of the delay in transmitting the stream passing over the asynchronous network,

- means for modifying (181, 281) the delay of transmission of the multimedia stream transiting on the synchronous network from the delay information obtained.

2) synchronization device according to claim 1, characterized in that the asynchronous telecommunications network is connected to a computer device (104, 123, 204, 223, 295) comprising at least one client-client application receiving a stream of video data and the synchronous telecommunications network is connected to a telephone handset (103, 122, 203, 222, 292) receiving an audio data stream.

3) Device according to claim 2, characterized in that the information representative of the transmission delay of the stream passing over the asynchronous network is obtained from control packets of the video data stream passing over the asynchronous network.

4) Device according to claim 3, characterized in that the means for obtaining information representative of the delay of transmission of the flow passing over the asynchronous network are constituted by means for memorizing the instants of reception of the control packets of the flow of video data flow passing through on the asynchronous network, means for reading at least one predetermined field from video data flow control packets and means for calculating the delay from the instants stored and from the at least one predetermined field read. 5) Device according to any one of claims 1 to 4, characterized in that the means for modifying the transmission delay of the stream passing over the synchronous network comprise means for temporarily storing the data of the audio stream passing over the synchronous network and means for determining the address for reading the data contained in the temporary storage means from the information obtained and means for transferring, from the determined address, the data read in the temporary storage means over the network synchronous to the telephone handset.

6) Device according to any one of claims 2 to 5, characterized in that the asynchronous telecommunications network is connected to a computer device comprising at least one client-client application (110, 127, 210, 227, 293) transmitting the video data stream, the synchronous telecommunications network is connected to a telephone handset transmitting the audio data stream.

7) Device according to claim 6, characterized in that the means for obtaining information representative of the transmission delay of the flow passing over the asynchronous network determine the transmission delay between the synchronization device (190, 290) and each of the computer devices (104, 123, 204, 223, 295) connected to the network and in that a delay is applied to the voice stream transmitted by each telephone handset to each telephone handset receiving the audio stream.

8) Device according to claim 7, characterized in that it further comprises means (183, 282) for receiving control packets of the video data flow passing over the asynchronous network and means for generating control packets of the video data flow passing through the asynchronous network.

9) Device according to any one of claims 1 to 8, characterized in that it further comprises means (171, 271) for storing a profile for each user comprising inter alia an identifier of the user, at at least one telephone handset associated with the user, at least one address of a computing device associated with the user and at least one client-client application identifier present on the at least one computing device associated with the user. 10) Device according to claim 9, characterized in that it further comprises means for receiving at least one call from a telephone handset (180, 280), means for obtaining at least one identifier a telephone handset with which the calling telephone handset wishes to establish a telephone call and means for matching the computer device associated with the user associated with the calling telephone handset with the computer device associated with the user with the telephone handset with which the calling telephone handset wishes to establish a telephone call.

11) Device according to any one of claims 3 to 10, characterized in that the flow passing over the asynchronous telecommunication network conforms to the RTP protocol and the control packets of the data flow passing over the asynchronous network conform to the protocol RTCP.

12) Device according to any one of claims 10 to 11 characterized in that the device is a conference bridge.

13) Method for synchronizing a multimedia stream made up of two separate multimedia streams in a telecommunication network made up of a synchronous telecommunication network (141, 148, 241) and an asynchronous telecommunication network (160, 260), one of said flows passing through the asynchronous telecommunications network, the other flow passing through the synchronous telecommunications network, characterized in that the method comprises the steps of: - obtaining (E329, E810) delay information representative of the delay transmission of the flow passing through the asynchronous network,

- modification (E330, E812) of the delay of transmission of the multimedia stream transiting on the synchronous network from the delay information obtained.

14) synchronization method according to claim 13, characterized in that the asynchronous telecommunications network is connected to a computer device comprising at least one client-client application receiving a video data stream and the synchronous telecommunications network is connected to a handset telephone receiving an audio data stream. 15) Method according to claim 14, characterized in that the information representative of the transmission delay of the stream passing over the asynchronous network is obtained from control packets of the video data stream passing over the asynchronous network.

16) Method according to claim 13, characterized in that the step of obtaining information representative of the delay in transmitting the stream passing over the asynchronous network comprises a step of memorizing the reception times (E504, E507, E512, E806, E808) video data flow control packets passing over the asynchronous network, a step of reading at least one predetermined field of video data flow control packets (E513, E514, E809) and a calculation step ( E515, E809, E810) of the delay from the memorized instants and from the at least one predetermined field read.

17) Method according to any one of claims 13 to 16, characterized in that the step of modifying the delay of transmission of the stream passing over the synchronous network comprises a step of temporary storage of the data of the audio stream passing over the synchronous network , a step of determining the address for reading the stored data from the information obtained and a step of transferring, from the determined address, the data stored on the synchronous network to the telephone handset.

18) Method according to any one of claims 14 to 17, characterized in that the asynchronous telecommunications network is connected to a computer device comprising at least one client-client application transmitting the video data stream, the synchronous telecommunications network is connected to a telephone handset transmitting the audio data stream.

19) Method according to claim 18, characterized in that the method is implemented in a synchronization device of a telephone operator and in that the information representative of the transmission delay of the flow passing over the asynchronous network determines the transmission delay between the synchronization device and each of the computer devices connected to the network and in that a delay is applied to the voice stream transmitted by a telephone handset to each telephone handset receiving the audio stream.

20) Method according to claim 19, characterized in that it further comprises a step of receiving (E801) control packets of the video data stream passing over the asynchronous network and a step of generating (E805) control packets of the video data flow passing over the asynchronous network.

21) Method according to any one of claims 13 to 20, characterized in that it further comprises the steps of memorizing a profile for each user comprising inter alia an identifier of the user, the telephone number from to at least one telephone handset associated with the user, at least one address of a computing device associated with the user and at least one client-client application identifier present on the at least one computing device associated with the user.

22) Method according to claim 21, characterized in that it further comprises the steps of receiving at least one call from a telephone handset, of obtaining at least one identifier of a telephone handset to which the the calling telephone handset wishes to establish a telephone communication and to match the computer device associated with the user associated with the calling telephone handset with the computer device associated with the user to the telephone handset with which the calling telephone handset wishes to establish a telephone communication.

23) Method according to any one of claims 15 to 22, characterized in that the flow passing over the asynchronous telecommunications network conforms to the RTP protocol and the control packets of the data flow passing over the asynchronous network conforms to the protocol RTCP.

24) A computer program stored on an information medium, said program comprising instructions making it possible to implement the processing method according to any one of claims 13 to 23, when it is loaded and executed by a computer system .