OA19745A - Real-time communication process between web browsers. - Google Patents

Abstract

The invention relates to a real-time communication method according to a WebRTC type technology, between web browsers on an Internet-type communication network, comprising: the prior loading (S20) by a first web browser of a first terminal associated with a first user, of a web application provided by an application server, the web application providing functionalities for real-time communication between web browsers; the sending (S21) by the first browser, via this web application, to the application server, of a call establishment request including an identifier of a user to whom the call is to be made, called the second user ; This method is remarkable in that it further comprises steps of: determining (S22, S23, S24) a state of availability of the second user to respond to the call establishment request; automatic redirection (S25) to a web address of a messaging service associated with the second user, when the second user is in the unavailable state.

Description

TITLE OF THE INVENTION

Real-time communication process between web browsers

ABREGE TEXT

The invention relates to a real-time communication method according to a WebRTC type technology, between web browsers on an Internet-type communication network, comprising: the prior loading (S20) by a first web browser of a first terminal associated with a first user, of a web application provided by an application server, the web application providing functionalities for real-time communication between web browsers; the sending (S21) by the first browser, via this web application, to the application server, of a call establishment request including an identifier of a user to whom the call is to be made, known as the second user ;

This process is remarkable in that it further comprises steps of:

- determination (S22, S23, S24) of an availability state of the second user to respond to the call establishment request;

- automatic redirection (S25) to a web address of a messaging service associated with the second user, when the second user is in the unavailable state.

Real-time communication process between web browsers

The invention relates generally to real-time communication between web browsers over a communication network such as the Internet.

More specifically, the invention relates to the technology of real-time communication between web browsers currently being standardized, jointly by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF), and referred to as WebRTC {Web Real-Time Communication) at W3C and RTCWEB at IETF.

The last few years have seen the emergence of a new platform for the development of services based on web applications - that is, applications downloaded by a browser by consulting a web page -: the web browser. Indeed, as long as the browser platform has the necessary interfaces to operate with these web applications, it is possible to deliver almost any type of service via a browser.

Traditionally, the aforementioned interfaces are provided to the browser in the form of extension modules, commonly referred to as a plugin in English, and which must be downloaded and then installed separately from the browser.

. We can cite, for example, on the market for real-time communication (RTC) web services between browsers, the products known under the names Skype ™, Facebook ™ (which uses Skype) and Google Hangouts ™ (which uses the Google Talk ™ plugin. ). Mention may also be made of the Flash Player ™ product from the company Adobe.

All of the above products require downloads, native applications or plugins external to the browser. However, downloading, installing and updating plugins is complex, a source of errors and inconvenience. Furthermore, the design, testing, updating and deployment of plugins is complex and expensive.

With the development of HTML5 (HyperText Markup Language 5) new perspectives are opening up to application developers with the possibility of making interfaces (API - Application Programming Interface) with web applications accessible in a standardized way within the browser. .

This is the path followed by the IETF and the W3C with the RTCWEB / WebRTC standard which aims to provide two types of specifications:

- a protocol specification, carried out at the IETF;

.....- a specification of JavaScript APIs, carried out at W3C .____________ 'The two aforementioned specifications aim to provide an environment according to which, An .application..Javascript incorporated into any web page, read by 5 n 'any compatible browser, and appropriately authorized by its user, is capable of establishing communication using audio, video (and ancillary data), without the browser platform limiting the types of application in which this communication functionality can be used.

According to the current RTCWEB / WebRTC standard, a web browser must implement three APIs to be able to receive and transmit data in streaming mode (sometimes called streaming or streaming in French), these APIs are as follows:

- MediaStream: allows the browser to access data streams such as those coming from the camera (web cam) and the microphone of the user's terminal;

- RTCPeerConnection: provides audio or video calls, with encryption and bandwidth management mechanisms;

- RTCDataChannel: provides peer-to-peer communication of generic data.

To obtain more information concerning the RTCWEB / 20 WebRTC specifications, the following documents may be consulted in particular:

- WebRTC 1.0: Real-time Communication Between Browsers - W3C Editor's Draft 22 March 2013 - available on the Internet at the following address:

http://dev.w3.org/2011/webrÎc/editor/webrtc.html#rtcpeerconnection-interface

- OverView: Real Time Protocols for Brower-based Applications - draft-ietf- rtcweb-overview-06 - February 20, 2013 - available on the Internet at the following address:

http://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/

Currently, web browser vendors are offering experimental versions of this new cross-browser service, for example Google with the Chrome ™ browser, Mozilla with the Firefox ™ browser, Ericsson with the browser called Bowser ™ developed for mobile phones.

In the versions proposed to date, which comply with the RTCWEB / WebRTC specifications, when a first user wishes to establish an audio or video communication, from his WebRTC compatible web browser, with a second user on the Internet network, he begins with connect via its browser to an application server providing the WebRTC communication service. After a possible authentication operation, the browser loads, via a web page, the web application (Javascript application) conforming to the RTCWEB specifications and adapted to interact with the aforementioned APIs (conforming to the specifications

WebRTC) which are natively embedded in the browser.

Then, the first user chooses, via the web page of connection to the application server, an identifier of the second user, then enters a command - for example by clicking on an action button displayed in the web page opened in the browser - to initiate the audio or video call to the second user. Typically, the web page opened in the browser then displays a message indicating that the connection is being established.

If the second user, recipient of the call, is also connected to the same WebRTC communication service provided by the application server, then he can accept the audio or video call from the first user, and communication can then be established. .

On the contrary, in the case where the browser of the second user's terminal is not active, or in the case where the web page of the WebRTC service is not open in the browser of the second user, or if the terminal of the second user is not connected to the network, then the audio or video communication between the first and the second user cannot be established, and this without the first user being informed of the reason for the failure of the communication .

The object of the present invention is in particular to remedy the situation described above. To this end, the invention relates, according to a first aspect, to a method of real-time communication according to a technology of WebRTC type, between web browsers on a communication network of Internet type.

By WebRTC type technology is meant a real-time communication technology between web browsers based on the same principles as that defined by the RTCWEB / WebRTC specifications, that is to say based on standard web browsers, without it being it is necessary to add extension modules (plugins) to these browsers.

According to the invention, the aforementioned method comprises:

the prior loading, by a first web browser, of a first terminal associated with a first user, of a web application supplied by an application server, the web application providing real-time communication functionalities between web browsers;

, - the sending by the first browser, via the web application, to the application server, of a call establishment request including an identifier of a user to whom the call is to be made, called second user ;

In accordance with the invention, this method further comprises the following steps: determining a state of availability of the second user to respond to the call set-up request;

- Automatic redirection to a web address of a messaging service 10 associated with the second user, when the second user is in the unavailable state.

Thus, according to the invention, when the second user is determined to be unavailable to answer the call, the browser of the first user is automatically redirected to a web address (URL - Uniform Resource Locator) of a messaging service, which allows the first user not to be left without information relating to the communication failure.

Thus, according to the invention, if the call establishment request does not succeed after a period of time determined in the first browser, measured by a timer for example, the browser of the first user is automatically redirected to a web address (URL - Uniform Resource Locator) 20 of a messaging service, which allows the first user not to remain without information relating to the failure of the communication.

According to one embodiment of the invention, the step of determining an availability state of the second user, includes the evaluation of a time elapsed since the sending of the call establishment request, and The availability state of the second user is then determined to be unavailable, when the elapsed time reaches a determined duration.

According to another embodiment which can be combined with the previous one, the step of determining an availability state of the second user, includes obtaining presence information of the second user for the real-time communication service. between browsers, and if this presence information indicates that the second user is absent for the service, then the availability state of the second user is determined to be unavailable.

In practice, according to an exemplary embodiment, obtaining presence information comprises consulting a user presence table for the real-time communication service between web browsers.

Thus, in the case where the WebRTC communication service ensures the management of a subscriber presence state for the service, if the second user is determined to be absent for the communication service at the time when the call request is transmitted by the first user, then the browser of the first browser is immediately redirected to the web address of the messaging service.

In particular, according to one characteristic of the invention, following the redirection to the messaging service, the first browser displays a web page rendering a message from the second user.

In practice, the restored message from the second user can be an audio, video, and / or text message.

Thus, following the redirection to the messaging service, the first user will be informed, by means of the message from the second user, of the fact that the latter cannot be contacted and possibly of the reasons for which he is not reachable.

Moreover, according to an additional characteristic of the invention, the web page displayed in the first browser, and which renders the message of the second user, also offers the first user a functionality for submitting a message intended for the second user.

This message from the second user can be, according to different embodiments, a message of audio, video, and / or textual type.

Thus, such a messaging service according to the invention will be able to render, within the framework of the WebRTC communication between browsers, not only a service similar to that provided within the framework of conventional telephony (mobile or fixed), but also with more possibilities. regarding the types of messages that can be posted.

According to a particular characteristic of the invention, following the submission of a message by the first user, the submitted message is transmitted by the first browser to a messaging server, the messaging server then transmitting to a terminal associated with the second user, a notification indicative of the receipt of the message posted by the first user.

According to a particular implementation of the invention, the aforementioned notification comprises an SMS or MMS type message transmitted to a mobile telephone identifier associated with the second user. Provision can also be made for the notification to include an electronic message transmitted to an electronic mail address of the second user. The notification can also, depending on the embodiment considered, consist in the simultaneous sending of several messages of different types corresponding to distinct communication terminals (PC, mobile telephone, etc.), used by the second user.

It is also possible to envisage using, by way of notification, a message waiting indicator, of the MWI type (Message-Waiting Indicator).

In practice, the aforementioned notification may include, depending on the embodiment chosen, all or part of the following information:

- the identity of the caller;

- the type of message submitted (audio, video, text, ...);

- the duration of the message;

- the number of characters used by the message (text message);

- the urgent or non-urgent nature of the message.

In this way, the second user, even if he is not connected to the Internet or else if he does not connect to the messaging server according to the invention, can be notified of the arrival of a message from the Internet. 'a user who tried to reach him by WebRTC communication.

According to a first embodiment of the communication method according to the invention, the steps of determining a time elapsed since the sending of a call establishment request, and of automatic redirection to a voice mailbox, when the elapsed time reaches a specified time, are implemented by the web application loaded in the first browser. In this embodiment, the web application is typically a Javascript application incorporated into the HTML code of the web page provided by the application server offering the real-time communication service between browsers.

This first embodiment is particularly suitable in the case where the provider of the real-time communication service between browsers also provides the associated WebRTC messaging service, or else in the case where the provider of the real-time communication service between browsers provides only the functionality to redirect to a WebRTC mail server managed by a third-party service provider.

According to a second embodiment, the steps of determining an elapsed time since the sending of a request for establishment of a call, and of automatic redirection to a voice mailbox, are implemented by a programming interface ( API) natively incorporated in the first browser.

This second embodiment is suitable for the case where the provider of the real-time communication service between browsers and the provider of the associated messaging service are separate entities. The API implementing the messaging service in the browser then allows the browser user to configure the web address (URL) of the messaging system to be opened by the browser, in the event of no response from a recipient browser, when 'an attempt to set up a call.

Correlatively, according to a second aspect, the subject of the invention is therefore a web application providing functionalities for real-time communication between web browsers. This web application according to the invention comprises program instructions whose execution by a processor, triggered by a web browser of a communication terminal, causes the implementation of the steps for determining a time elapsed since the sending a request for establishment of a call, and for redirection to a voice mailbox when the elapsed time reaches a determined duration, according to the communication method according to the invention as briefly described above.

Such a web application is therefore particularly suitable for the first embodiment mentioned above.

According to a third aspect, the invention also relates to a web browser comprising a programming interface (API) including a computer program code, the execution of which by a processor of a communication terminal in which the web browser is installed. , causes the implementation of the steps of determining an elapsed time since the sending of a request for establishment of a call, and of redirection to a voice mailbox when the elapsed time reaches a determined duration, in accordance with the method of communication according to the invention as briefly described above.

Such a browser is therefore particularly suitable for the second embodiment mentioned above.

Finally, according to a fourth and a fifth aspect respectively, the present invention also relates to:

a messaging server accessible by a web browser, via a web address, this messaging server providing a messaging service for the implementation of a communication method according to the invention as explained above;

an application server providing a real-time communication service between web browsers, this application server comprising a web server hosting at least one web page including a web application in accordance with the second aspect of the invention, mentioned above.

According to a particular embodiment of the invention, the messaging server can be included in the application server according to the invention.

Other features and advantages of the present invention will emerge from the following detailed description, which refers to the accompanying drawings in which:

FIG. 1 illustrates a network environment in which the present invention can be implemented;

FIG. 2 represents in the form of a flowchart the main steps of the communication method according to the invention;

FIG. 3 is a diagram representing the exchanges between the different entities represented in FIG. 1 according to an exemplary implementation of a communication method according to the invention;

FIG. 4 represents a dialog box opened in a browser, making it possible to configure the forwarding address to a messaging system and the timeout period before forwarding, according to one embodiment of the invention;

FIG. 5 represents an example of a graphical interface obtained by a user's browser after connection to a WebRTC messaging server according to the invention, allowing the user to consult the messages he has received;

FIG. 6 represents an example of a graphical interface obtained by a user's browser after connection to a WebRTC messaging server according to the invention, in order to allow the user to configure his personal messaging; and

FIG. 7 represents an example of a graphical interface obtained by a browser of a first user after redirection to a WebRTC messaging server according to the invention, following the absence of response to a call to a second user .

Figure 1 illustrates a network environment in which the present invention can be implemented.

The environment shown comprises a first web browser BRW1 of a first user terminal (user U1), a second browser BRW2 of a second user terminal (user U2). The aforementioned user terminals can be in a state connected or not connected to a communication network NW which is an Internet type network, that is to say a network based on the communication technologies implemented in the network. The Internet, in particular the NW network, can also be a corporate network commonly called an intranet.

BRW1 and BRW2 browsers are compatible browsers

WebRTC / RTCWEB, and as such, have respectively a set 12, 22 of API interfaces conforming to the WebRTC specifications, and an RTC functional module 11, 21 conforming to the RTCWEB specifications. The APIs 12 and 22 sets are respectively able to interact with a Javascript APP application incorporated in WP1 and WP2 web pages downloaded respectively by the browsers BRW1 and BRW2 to a web address of resources hosted by an application server AS on the network NW.

The APP application provides, in accordance with the WebRTC / RTCWEB specifications, RTC communication functionalities in particular relating to access to the WebRTC real-time communication service provided by the AS server, and to the signaling making it possible to establish such communication between browsers. .

Thus, in the example illustrated in Figure 1, if the two browsers BRW1 and BRW2 have each downloaded the web page (WP1 and WP2) containing the APP application of the WebRTC service then they can establish a real-time peer-to-peer communication at 20 even, C1, in particular of voice or video type.

On the other hand, if the browser BRW1 tries to establish a call with the terminal in which the browser BRW2 is installed and the latter is closed or is not connected to the AS server and has not opened the WP2 web page of the service , or if the corresponding terminal is not connected to the network or if the user (U2) of the terminal 25 simply does not answer the call, then the communication C1 cannot be established between the two browsers BRW1 and BRW2 (hence the dotted representation of page WP2 and the double arrow C1).

Also in FIG. 1, a WebRTC messaging server VM_S is also represented, according to the invention, associated with a server MSG_S for storing 30 messages - the respective role of which will be explained in more detail in the remainder of the description -, as well as a mobile terminal T2 associated with the user (U2) of the second browser, and connected to a second, third or fourth generation MN mobile telephone network (2G, 3G, 4G) itself connected to a GW gateway making it possible to connect the MN mobile network to the NW network.

In relation to FIG. 2 which represents in the form of a flowchart the main steps of a communication method according to the invention, implemented in an environment such as illustrated in FIG. 1.

During step S20, the browser BRW1 of the user U1 accesses a web address of a WebRTC service provided by the application server AS. After a possible service authentication phase, the browser loads the WP1 web page containing the APP application (Javascript).

In the following step S21, the browser BRW1 via ΓΑΡΙ RTCPeerConnection transmits to the server AS a call establishment request intended for the user U2.

The sending of the call establishment request triggers the step S23 of testing a presence state of the second user for the WebRTC service. This test is implemented for example by sending a command to a presence server in which a presence table of users subscribed to the WebRTC service is regularly updated. If the second user is determined to be absent (S22, No) for the WebRTC service, then the browser BRW1 is automatically redirected (step S25) to a WebRTC messaging web address hosted by the VMS messaging server. On the other hand, if the second user is determined to be present for the WebRTC service then one proceeds to the timing step S23 to determine the time elapsed since the sending of the call establishment request.

He noted that in the chosen embodiment, the step (S23) of testing a presence state of the second user is implemented, but in the event that such presence information cannot be obtained then the step S23 for triggering a time delay is directly executed.

In step S24 which follows, the time elapsed since the sending of the call establishment request is tested. As long as the elapsed time does not reach a determined duration, the placing on hold of the browser continues (S24, No). The timeout period can be, depending on the embodiment chosen, set beforehand by the user U1 of the browser BRW1 (in particular in the case of an implementation of the invention at API level) or else set by the supplier of the service through the JavaScript APP application.

During step S24, if the connection is established with the destination browser BRW2 then step S24 is interrupted and communication (FIG. 1, C1) is established with the destination browser BRW2.

When, on the contrary, the elapsed time reaches the determined timeout period, then the call establishment request is interrupted and the browser

BRW1 is automatically redirected (step S25) to a web mail address

WebRTC hosted by the VMS mail server.

A web page originating from the messaging system is then displayed by the browser BRW1, this web page then restores (step S26) a message recorded beforehand by the user to whom the call is to be made (user U2), in the same way as a classic telephone answering machine. However, this message can advantageously be recorded, at the choice of the user (U2), in different forms: audio, video or text message, or audio and text, or video and text.

The messaging web page displayed by the browser BRW1 of the user U1 also offers the latter the possibility of posting a message (step S27), which message can also post in different forms: audio, video or text or audio and text message. , or video and text.

Finally, following the submission of a message by the user U1, the messaging server VM_S then transmits, in step S28, to a communication terminal (PC, mobile telephone terminal, landline, etc. ) associated with the second user (U2), a notification indicative of the receipt of the message submitted by the first user (U1).

In the embodiment described, the terminal or terminals associated with the second user U2 to which to transmit a notification of receipt of a message, as well as the type of notification, can be configured beforehand by the second user as parameters associated with his messaging system. , managed by the mail server. For example, the user U2 can configure that such a notification is sent to a mobile telephone identifier which is specific to him, so the user U2 can receive this notification in the form of an SMS or MMS (Short Message Service, Multimedia) text message. Messaging Service) on his terminal T2.

FIG. 3 is a diagram representing the exchanges between the different entities represented in FIG. 1 according to an exemplary implementation of a communication method according to the invention.

As represented in FIG. 3, the exchanges take place between the different entities exposed in relation with FIG. 1: the two browsers BRW1, BRW2, the application server AS, the messaging server VM_S, and the message storage server MSG_S. The vertical line corresponding to the BRW2 browser is initially represented in dotted lines indicating that the BRW2 browser is not active with respect to the PSTN communication service provided by the AS server - or that the browser is not connected to the AS server , either that it is not open in the associated terminal, or that the terminal itself is not connected to the network NW.

According to the first embodiment introduced above in the description, the functionalities for determining an elapsed time since the sending of a request for establishment of a call and for automatic redirection to a voice mailbox, when the elapsed time reaches a fixed period, are implemented by the web application loaded in a browser with the web page provided by the application server AS.

In practice, the web application (APP, FIG. 1) is a Javascript application, and it can be enriched in this embodiment with a function of the type defined by the following pseudo code, given by way of example:

SetTimeout (function ()) {

If no response during the call then Redirection to URL_MES with parameters (called party ID (email address, etc.)}

Thus in this embodiment if, following the triggering of the call, a period of time (defined by the SetTimeout function) elapses without a response from the called party, then a browser redirection is automatically carried out to the URL_MES address of messaging, with in particular the identifier of the called party used during the call, for example an electronic mail address (email).

Depending on the embodiment chosen, other information can be attached as parameters during the redirection operation, for example the type of terminal used by the calling user (U1).

According to the second embodiment introduced above in the description, the determination of a time elapsed since the sending of a request for establishment of a call, and for automatic redirection to a voice mailbox, are implemented by a programming interface (API) natively incorporated into browsers. In practice, the new functionalities provided by the present invention are implemented in the RTCPeerConnection API interface.

More precisely, according to the WebRTC / RTCWEB specifications, when establishing a WebRTC communication between two browsers, there is an exchange of messages according to an offer / answer model within the framework of the SDP protocol. (Session Description Protocol).

In this context, according to the second embodiment, provision is made to modify the RTCPeerConnection API interface, by introducing a new function, designated in this example by SetRedirectionMevo (noanswer) (in bold below), for redirection to a messaging system. in the event of no response from the called browser, and this with recovery of the called party's identifier, and, if applicable, other information, to allow messages to be posted on their mailbox:

Caller transition:

• new PeerConnection (): stable • setLocal (offer): have-local-offer • SetRedirectionMevo (noanswer): caller has no answer from callee “setRemote (pranswer): have-remote-pranswer • setRemote (answer): stable • closeQ : closed

For more information about the RTCPeerConnection interface, see the document: WebRTC 1.0: Real-time Communication Between Browsers -W3C Editor's Draft 22 March 2013; at the following web address:

http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcpeerconnection-interface (in particular, see section 4.4.1 RTCPeerState Enum).

In this embodiment, the browsers BRW1 and BRW2 are configured beforehand by their user, so as to configure the e-mail address to which the browser should be redirected in the event of no response from the called party, as well as the duration of no response. of the called party, from which the redirection should be triggered.

The configuration of a browser according to this embodiment is illustrated by FIG. 4 which represents a dialog box opened in a browser, making it possible to configure the forwarding address to a messaging system and the timeout period before forwarding. In Figure 4, we can see that the redirect web address (URL) is voicewebrtc.orange.com on port 80, and the timeout is set to 5 seconds.

In addition, each user who has subscribed to the WebRTC service according to the invention has previously configured his personal messaging, directly with the VM_S messaging server, or indirectly, through the application server AS. This prior configuration consists in particular, on the one hand, of recording one or more messages (voice, video and / or text) intended to be returned in the event of the user's unavailability during an incoming call, and on the other part, where appropriate, in choosing a storage space to store in particular the messages which are intended for the user from other users of the WebRTC service according to the invention. This storage space can be hosted directly by the messaging server VM_S, or else by a dedicated storage server MSG_S, or even be a storage space specific to the user, subscribed to another service provider, such as for example, Dropbox ™ from the company Dropbox, or Le Cloud d'Orange ™ from the Orange company. User configuration with remote storage providers is performed through specific API interfaces provided by these providers.

Returning to FIG. 3, in step S301, the user U1 of the browser BRW1 connects to the WebRTC service according to the invention, provided by the server AS, according to a procedure specific to the service itself, which may include a user authentication operation. It is possible to envisage a procedure for connecting to the AS server, of the type 15 of that offered by Facebook® with the Facebook Connect APIs. This step includes the loading by the browser of the web page containing the Javascript application of the WebRTC service.

Then (step S303), the user U1 initiates via his browser a call (for example video) to the user U2 of the browser BRW2, and receives in return (step S305) a text message in his browser indicating to him that the call is in progress. In parallel, the server AS tries to reach the browser BRW2 to send it the call request (step S307), the browser BRW2 then being inactive (dotted line).

In the first browser BRW1, the sending of the establishment request 25 triggers the timing step S309 according to the invention. The waiting time having elapsed without the call being established with the browser BRW2, during step S311, the browser BRW1 is automatically redirected, in accordance with the invention, to the messaging server VM_S. Moreover, the browser BRW1 transmits to the server AS a command to cut off the call in progress (step S313).

In step S315, the browser BRW1 loads, from the mail server

VM_S, the web page displaying the answering machine of the user U2 recipient of the unsuccessful call, and automatically reproduces the unavailability message of this user (video message for example).

Following the restitution of the unavailability message of the user U2, during step S317, the user U1 records a message for the attention of the user U2 (a voice message for example). Step S317. Uses in particular, depending on the embodiment chosen, ΓΑΡΙ MediaStream (also designated by getUserMedia) of the browser BRW1, or else a function of the web application (Javascript) contained in the web page provided by the server of VM_S messaging, for example a WebRTC primitive denoted by RecordRTC.

In the next step S319, the message recorded by the user U1 is transmitted to the messaging server VM_S. The latter then transmits this message (step S321) to the message storage server MSG_S.

Then in step S323, the messaging server consults the messaging configuration data of the user U2, and determines an identifier of the user U2 (or of a terminal, for example an IP address), and a notification format, in order to send the user U2 a notification informing him of the arrival of a new message. In this example, the identifier is an email address, and when the user U2 connects (step S325) to the network NW with his terminal (a PC for example) he can then consult his email and read the notification message.

In step S327, the user U2 connects via the browser BRW2 - for example by clicking on a URL link present in the notification message - to the messaging server VM_S, and takes note of the new message. The VM_S server, from an identifier of the user U2, updates, by connecting (step S329) to the storage server MSG_S, a messaging graphical interface associated with the user U2 with the links (URL ) access to new messages.

Finally, in step S331, the user U2 via the messaging interface displayed by his browser (BRW2) can, by clicking on the corresponding links, trigger the playback in streaming mode of the new messages, and in particular that of the message submitted by user U1.

With reference to FIGS. 5 to 7, examples of graphical interfaces obtained by connecting a web browser to a WebRTC messaging server according to the invention are given.

FIG. 5 represents an example of a graphical interface obtained by a user's browser after connection to a WebRTC messaging server according to the invention, allowing the user to consult the messages he has received. In this example, only voice messages are shown.

FIG. 6 represents an example of a graphical interface obtained by a user's browser after connection to a WebRTC messaging server according to the invention, in order to allow the user to configure his personal messaging. In this example, only a response text message was configured by the user.

FIG. 7 represents an example of an interface, an example of a graphical interface obtained by a browser from a first user after redirection to a WebRTC messaging server according to the invention, following the absence of response to a call to the destination of 'a second user.

On the interface shown, we can see the text message of absence of the second user: Hello (...) video whenever you want; as well as, below, the window displaying the video being recorded which corresponds to the message submitted by the first user.

Claims (17)

1. A method of real-time communication according to a WebRTC type technology, between web browsers on an Internet type communication network, comprising: - the prior loading (S20) by a first web browser of a first terminal associated with a first user, of a web application supplied by an application server, said web application providing real-time communication functionalities between web browsers; the sending (S21) by the first browser, via said web application, to the application server, of a call establishment request including an identifier of a user to whom the call is to be made, called second user ; said method being characterized in that it further comprises the following steps: - determination (S22, S23, S24) of an availability state of the second user to respond to the call establishment request; - Automatic redirection (S25) to a web address of a messaging service associated with said second user, when the second user is in the unavailable state. The method of claim 1, wherein the step of determining an availability state of the second user includes evaluating (S23, S24) a time elapsed since sending the request to set up a second user. 'call, and the availability state of the second user is then determined to be unavailable, when the elapsed time reaches a determined duration. The method of claim 1 or 2, wherein the step of determining an availability state of the second user includes obtaining (S22) presence information of the second user for the real-time communication service. between browsers, and if said presence information indicates that the second user is absent for said service, then the availability state of the second user is determined to be unavailable. 4. Method according to any one of claims 1 to 3, wherein, following the redirection to said messaging service, the first browser displays a web page rendering a message from the second user. 5. The method of claim 4, wherein the restored message of the second user is an audio, video, and / or text message. 6. The method of claim 4 or 5, wherein said web page displayed in the first browser offers the first user a functionality of depositing (S27) a message intended for the second user. 7. The method of claim 6, wherein a message submitted by the first user is a message of audio, video, and / or text type. 8. The method of claim 6 or 7, wherein following the submission of a message by the first user, the posted message is transmitted by the first browser to a mail server, said mail server transmitting (S28) then to the destination. from a terminal associated with said second user, a notification indicative of the receipt of the message submitted by the first user. 9. The method of claim 8, wherein said notification comprises an SMS or MMS type message transmitted to a mobile telephone identifier associated with the second user. 10. The method of claim 8 or 9, wherein said notification comprises an electronic message transmitted to an electronic mail address of the second user. 11. The method of claim 2, wherein said steps of determining an elapsed time since sending a call setup request, and automatic redirection to a voicemail, when the elapsed time reaches a duration. determined, are implemented by said web application loaded in the first browser. 12. The method of claim 2, wherein said steps of determining a time elapsed since the sending of a call establishment request, and automatic redirection to a voicemail, are implemented by an interface. programming (API) natively incorporated into the 5 first browser. 13. Web application providing functionalities for real-time communication between web browsers, characterized in that it comprises program instructions whose execution by a processor, triggered by a web browser of a communication terminal, causes the setting. implementation of the steps of determining a time elapsed since the sending of a call set-up request, and of redirection to a voice mailbox when the elapsed time reaches a determined duration, according to a communication method according to one any of claims 1 to 12. 14. Web browser characterized in that it comprises a programming interface (API) including a computer program code, whose execution by a processor of a communication terminal in which the web browser is installed, causes the implementation of the steps of determining an elapsed time since the sending of a call establishment request, and of redirection to a voice mailbox when the elapsed time reaches a determined duration, according to a compliant communication method to any one of claims 1 to 12. 15. Messaging server accessible by a web browser, via a web address, characterized in that it provides a messaging service for the implementation of a communication method according to any one of claims 1 to 12. 16. Application server providing a real-time communication service between web browsers, characterized in that it includes a web server hosting at least one web page including a web application according to claim 13. 17. The application server of claim 16, including a server ~. messaging according to claim 15.