FR3029379A1 - METHOD OF COMMUNICATING BETWEEN A TERMINAL EQUIPPED WITH A WEBRTC CLIENT AND AN ACCESSIBLE TERMINAL VIA A IMS NETWORK HEART - Google Patents

Abstract

A method of communication between a terminal equipped with a WebRTC client and a terminal accessible via an IMS core network, this method being implemented by an application server configured to provide communication services on the IMS core network. The method comprises steps of: - receiving (S41) from a bidirectional message conversion entity according to a first WebRTC compatible signaling protocol into messages according to a second IMS compatible signaling protocol, of a first request (RQT1) communication device according to the second protocol, transmitted by a terminal of a caller (U1) identified by a WebRTC identifier (URI-U1_2), and intended for a called party (U3) identified by an IMS reachability identifier (URI-U3); processing (S43) the first request to obtain an IMS reachability identifier (URI-U1_1) from the caller's WebRTC identifier (URI-U1_2); - transmission (S45) on the IMS core network, to the called party (U3), a second request (RQT2) communication according to the second protocol containing the IMS reachability identifier (URI-U1_1) of the calling, in order to establish a media communication (S47) through the conversion entity, between the caller terminal and a called party terminal.

Description

The invention relates to the field of IMS (IP Multimedia Subsystem) type telecommunication networks as defined by the 3GPP. (Third Generation Partnership Project). The invention relates in particular to a method of communication between a terminal equipped with a WebRTC client and a terminal accessible via an IMS core network, this method being implemented by an application server configured to provide communication services over a network. the IMS core network. STATE OF THE ART One of the objectives of the IMS is to enable a user to access different services regardless of his type of Internet Protocol (IP) connectivity.

IMS is a standardized architecture for telephony operators that provides fixed and mobile multimedia services. In particular, this architecture uses Voice Over 'F (VoIP) technology and the Session Initiation Protocol (SIP), which allows voice, text and multimedia services to traverse all networks connected to an IMS backbone. The IMS standardized with 3GPP is described in particular in document 3GPP TS 23.228, entitled "Technical Specification Group Services and System Aspects, IP Multimedia Subsystem (IMS), Stage 2" (Release 13), V13.0.0, September 2014. In recent years, a new real-time communication technology between Web browsers, designated WebRTC (Web Real-Time Communication), has been jointly developed by the Internet Engineering Task Force (IETF) and the World Wide Web (W3C). Web Consortium) and is subject to two specifications: a protocol specification developed by the IETF (RTCWEB) and a specification of JavaScriptTM APIs developed by W3C, which are described in the following documents respectively: - WebRTC 1.0: Real-time Communication Between Browsers - W3C Working Draft 10 September 2013, accessible at the following web address: http://www.w3.org/TR/webrtc/ - Overview: Real Time Protocols for Browser-based Applic ations - draft-ietf-rtcweboverview-11 - August 18, 2014, accessible at the following web address: https://tools.ietf.org/html/draft-ietf-dcweb-overview-11 WebRTC technology enables web browsers compatible with the aforementioned 35 specifications to be able to communicate in real time (audio, video, etc.) directly between them, without requiring the downloading of additional applications such as plugins or executable programs in the browser or in the terminal of the user. Generally speaking, when a first user wishes to establish an audio or video communication, from his web browser compatible WebRTC, with a second user on the Internet, he starts by connecting via his browser to a web server providing the communication service. WebRTC. After a possible authentication operation, the browser loads, via a web page, the web application (JavaScript application) that conforms to the RTCWEB specifications and adapted to interact with WebRTC compliant APIs that are natively embedded in the browser. Then, the first user chooses, via the web server connection web page, an identifier of the second user, then enters a command - for example by clicking on an action button displayed in the open web page in the browser - for trigger the audio or video call to the second user. Therefore, a computer device simply equipped with a web browser (WebRTC compatible) - designated by client or WebRTC agent - and having access to the Internet becomes an interpersonal communication terminal as a mobile phone or a landline phone (VoIP, for example). In this context, it is desirable that WebRTC clients can access the services provided by an IMS core network so that they can communicate or be reachable via the IMS network.

The 3GPP organization is currently proposing such a solution allowing access of a WebRTC client to an IMS core network; this is described in Appendix U of the technical specification 3GPP TS 23.228 mentioned above. Figure 1 illustrates the IPS WebRTC architecture provided by 3GPP. In Figure 1, the WWSF (WebRTC Web Server Function) entity corresponds to the web server contacted by the user's web browser after clicking on a link or entering a URL (Uniform Resource Locator) in the browser - this is the classic WebRTC operating mode. The eP-CSCF, on the other hand, corresponds to the IMS network's Proxy-Call Session Control Function (P-CSCF) entity, "enriched" (enhanced) to provide WebRTC access, ie say by implementing a WebRTC-SIP signaling conversion gateway functionality. As a reminder, the P-CSCF entity functions as a proxy server for a user equipment. All SIP signaling traffic originating from or destined for the user equipment must pass through the P-CSCF entity, which validates and transmits requests received from the user equipment, then processes and transmits the responses to the user equipment.

The implementation of a WebRTC / SIP conversion gateway in the IMS network, within or directly connected to the P-CSCF entity, requires a specific allocation and processing of credentials. for WebRTC access to the core of the IMS network. In fact, registering a WebRTC client associated with an IMS subscriber on the IMS core requires the gateway to behave like a SIP endpoint (endpoinl) and to be seen as such in the IMS core. This involves, on the one hand, an additional configuration (provisioning) of the IMS subscriber profile in an IMS core home server (HSS), with WebRTC access-specific credentials (credentials). IMS heart for this subscriber; and dynamic gateway management of the SIP registration, de-registration, and re-registration procedures, as well as the WebRTC client authentication (SIP DIGEST) procedure (with its own authentication data). ) on the IMS core through the P-CSCF entity. Furthermore, in the case of communication services rendered to a subscriber via an application server connected to the IMS core network, a declaration of a new user identity corresponding to a webRTC client would also be necessary. Thus, the WebRTC access solution to an IMS core network, as proposed by the 3GPP, requiring a modification of the IMS architecture and multiple network entity configurations, seems complex and technically constraining, and relatively costly for the network. enforce. DESCRIPTION OF THE INVENTION The present invention proposes a technical access solution for a WebRTC client to an IMS core network, not having the disadvantages described above related to the approach proposed by the 3GPP. For this purpose, the invention relates to a method of communication between a terminal equipped with a WebRTC client and a terminal accessible via an IMS core network, this method being implemented by an application server configured to provide services of communication on the IMS core network.

According to the invention, the communication method comprises the steps of: receiving, from a bidirectional message conversion entity according to a first WebRTC compatible signaling protocol, messages according to a second IMS compatible signaling protocol, a first communication request according to the second protocol, sent by a terminal of a caller identified by a WebRTC identifier, and intended for a called party identified by an IMS reachability identifier; processing the first request to obtain an IMS reachability identifier from the caller's WebRTC identifier; transmitting a second communication request on the IMS network core to the called party according to the second protocol containing the caller's IMS reachability identifier, with a view to establishing a media communication through the conversion entity, between the caller's terminal and a terminal of the called party.

Such a communication method according to the invention advantageously makes it possible to establish a direct connection between the WebRTC-IMS conversion entity and the application server providing the communication services on the IMS core network, which renders the entity transparent to the IMS core. It is therefore not necessary, as is the case with the solution proposed by the 3GPP, to specifically configure, for each WebRTC user likely to access the IMS core network, a specific IMS subscriber profile in a server. such as an IMS core subscriber server (HSS), with SIP authentication data making WebRTC access to the IMS network possible.

Furthermore, advantageously, the conversion entity is released from the dynamic management of SIP registration, de-registration and re-registration procedures, as well as from the authentication procedure of a WebRTC client considered on the IMS core at the same time. through a P-CSCF entity, as is the case with the aforementioned "3GPP solution". Thus, according to the present invention, it is the application server (AS) that is the real interface between the "web world" and the "IMS world", without constraining configuration of the IMS architecture or mandatory access by equipment. input (P-CSCF for example) from the IMS core network. According to a particular implementation of the invention, the above-mentioned communication method comprises steps of: - receiving a first communication request according to the second protocol transmitted via the IMS core network by a terminal of a caller identified by an IMS reachability identifier, intended for a called party identified by an IMS reachability identifier; processing of the first request to determine whether the caller's reachability identifier IMS corresponds or not to a subscriber having a WebRTC identifier, and if this is the case, transmission to the entity for converting a second communication request containing the determined WebRTC identifier, for the purpose of establishing, through the conversion entity, a communication communication between the caller's terminal and a terminal corresponding to the WebRTC identifier of the called party. Thus, consider a communication request sent by a terminal of a caller identified by a WebRTC identifier (for example an email address) or by a terminal of a caller identified by an IMS reachability identifier (for example a SIP address), the application server makes it possible to establish a communication between a terminal of a web network environment with a terminal of an IMS network environment, in particular by means of a mapping of a WebRTC identifier with an IMS reachability identifier for the calling or called user, as the case may be.

According to a particular characteristic of implementation, the processing of the first request comprises consulting a database of subscriber profiles containing for each subscriber at least one service implemented by the application server, at least one identifier of IMS reachability, and if necessary at least one corresponding WebRTC identifier.

Thus, the use of such a database of subscriber profiles makes it possible, in particular, to define mechanisms for subscribing users to particular communications services, including the possibility of joining IMS users and / or being reachable by IMS users via a simple WebRTC-compliant web browser. According to another embodiment, the communication method according to the invention comprises a step of authenticating a caller identified by a WebRTC identifier contained in a first communication request from the conversion entity. Such a step notably makes it possible to secure access, via a web browser, to an IMS core network from the Internet.

According to a particular embodiment, the first protocol is the WebSocket protocol and the second protocol is the Session Initiation Protocol (SIP). According to a second aspect, the invention relates correspondingly to an application server (AS) configured to provide communication services on an IMS core network. According to the invention, such an application server comprises: - first reception means from a bidirectional message conversion entity according to a first WebRTC compatible signaling protocol, in messages according to a second IMS compatible signaling protocol, a first communication request according to the second protocol, sent by a terminal of a caller identified by a WebRTC identifier, to a called party identified by an IMS reachability identifier; first request processing means, configured to obtain an IMS reachability identifier of the caller from the caller's WebRTC identifier; first transmission means on the IMS network core, intended for the called party, of a second communication request according to the second protocol, containing the caller's IMS reachability identifier, for the purpose of establishing , through the conversion entity, a communication media between the caller terminal and a terminal of the called party. According to a particular implementation of the invention, the application server further comprises: second means for receiving a first communication request according to the second protocol transmitted via the IMS core network by a terminal of a caller identified by an IMS reachability identifier, to a called party identified by an IMS reachability identifier; second request processing means, configured to determine whether the caller's reachability identifier IMS corresponds to a subscriber having a WebRTC identifier; second transmission means intended for the conversion entity, of a second communication request containing a WebRTC identifier determined by the second request processing means, following the reception of the first request, in view of the establishing a media communication between the caller's terminal and a terminal corresponding to the caller's WebRTC identifier, through the conversion entity. According to a particular embodiment, the first and second request processing means are configured to consult a database of subscriber profiles containing for each subscriber at least one service implemented by the application server, at least one IMS reachability identifier, and if necessary at least one corresponding WebRTC identifier. According to a particular embodiment, such an application server according to the invention includes the WebRTC-IMS conversion entity. According to another characteristic of the invention, the application server further comprises authentication means of a caller identified by a WebRTC identifier contained in a first communication request from the conversion entity. In the embodiment chosen and described, the communication method according to the invention is implemented in substantially software form. Therefore, according to a third aspect, the present invention relates to one or more computer programs comprising program instructions, the execution of which by a processor incorporated in an application server implements a communication method such as briefly exposed upper. In practice, such a computer program is constituted by modules or functional blocks performing all or part of the aforementioned steps of the method according to the invention. Each of the modules or function blocks can use any programming language, and include one or more subroutines in the form of source code, object code, or intermediate code between source code and object code, such as in a form partially compiled, or in any other desirable form. The invention therefore also aims at a computer-readable information recording medium, comprising the code of the program or programs according to the invention. Such a recording medium may be constituted by any entity or device capable of storing such a code. For example, the medium may include storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a removable recording means such as a USB key or a recording medium magnetic, such as a hard disk. On the other hand, such a computer program can be downloaded in particular on an Internet type network. The advantages provided by an application server and a computer program, according to the invention, are identical to those, described above, in relation to a communication method according to the invention, and will therefore not be recalled here. . BRIEF DESCRIPTION OF THE FIGURES Other features and advantages of the present invention will emerge from the detailed description which follows, which refers to the appended drawings in which: FIG. 1 already described illustrates a WebRTC-IMS architecture in accordance with a published 3GPP specification. ; FIG. 2 illustrates a network environment in which the present invention is implemented, according to one embodiment; FIG. 3 illustrates the hardware architecture of an application server according to the invention; FIG. 4 is a flowchart illustrating the main steps of a communication method according to the invention between a calling terminal equipped with a WebRTC client and a called terminal accessible via an IMS core network; FIG. 5 is a flowchart illustrating the main steps of a communication method according to the invention between a calling terminal accessible via an IMS core network and a called terminal equipped with a WebRTC client; FIG. 6 represents, in the form of a message exchange diagram, an exemplary implementation of a communication method according to the invention between a calling terminal equipped with a WebRTC client and a called terminal accessible via a heart. IMS network; and FIG. 7 represents, in the form of a message exchange diagram, an exemplary implementation of a communication method according to the invention between a calling terminal accessible via an IMS core network and a called terminal equipped with a WebRTC client.

DETAILED DESCRIPTION In the context of the present description, the expression "IMS reachability identifier" of a subscriber to a communication service designates an identifier making it possible to communicate with this subscriber through an IMS core network, either directly-in In this case, the identifier is an IMS identifier such as a SIP identifier, or indirectly, that is to say via an external network at the heart of the IMS network but connected by an interconnection device with the IMS core network. .

In other words, a called party or a caller reachable by an IMS reachability identifier on an IMS core network, is either an IMS subscriber, that is to say a subscriber to a communication service provided by a server. application on the IMS core network, ie a subscriber to a communication service on an external network at the core of the IMS network - for example a subscriber to a PSTN switched network or a subscriber to a fixed or wireless local area network. In the latter case, the subscriber has a subscriber identifier to the external network considered (for example a telephone number) reachable via the IMS core network via interconnection equipment of this network external to the network. IMS network core (eg MGCF entities, P-CSCF, ...).

Figure 2 illustrates a network environment in which the present invention is implemented, according to one embodiment. The network environment represented comprises a first web browser BRW1 of a first user terminal T1, a second browser BRW2 of a second user terminal T2. The aforementioned user terminals may be in a connected state or not connected to an Internet-type INT communication network, that is to say a network based on the communication technologies implemented in the Internet network, in particular the INT network can also be a corporate network commonly called intranet. The browsers BRW1 and BRW2 are WebRTC / RTCWEB compatible browsers, designated by "WebRTC clients", and as such respectively have a set 12, 22 APIs compliant with WebRTC specifications, and a functional module RTC 11 , 21 complies with RTCWEB specifications. The sets APIs 12 and 22 are respectively able to interact with a web application APP - whose code uses languages such as HTML, JavaScript and CSS (Cascading Style Sheets) - embedded in WP1 and WP2 web pages downloaded respectively by browsers BRW1 and BRW2 to a web address pointing to resources hosted by a WS web server on the INT network. The web server WS provides more precisely to the aforementioned web address a home page of a communication environment allowing users U1, U2 of terminals T1 and T2 to be able to communicate with each other in the WebRTC mode or to communicate with each other. remote terminals accessible via an IMS core network. The APP application provides in accordance with WebRTC / RTCWEB specifications, RTC communication functionalities related to the communication environment provided by the WS server, as well as the signaling to establish such communication between browsers.

Thus, as shown in the example of FIG. 2, if the two browsers BRW1 and BRW2 have each downloaded a web page (WP1 and WP2) containing the application APP of the communication service according to the invention, then they can establish a real-time peer-to-peer communication, particularly of the voice or video type, as illustrated by the double-dotted arrow C1. Still in FIG. 2, the network environment comprises an IMS 2 core network to which servers are connected in a conventional manner or equipment providing functionalities defined in accordance with 3GPP specification TS 23.228, such as: - a set of equipment providing I-CSCF (Call Session Control Function), S-CSCF (Serving-CSCF), P -CSCF (Proxy-CSCF); to the latter is connected a gateway (BOX 431) to a private local area network, for example, to which are connected communication terminals T5, T6; a media gate control function (MGCF) 45 connecting to the core of the IMS network, a public switched telephone network PSTN 431 (Public Switched Telephone Network) to which fixed terminals T3 and mobile T4 are connected. The environment of FIG. 2 furthermore comprises: an application server 31 connected to the core of the IMS network and providing communication services and notably IP telephony services via the IMS core network; - A bidirectional conversion entity (GW, 33) of messages according to a WebRTC compatible signaling protocol into messages according to an IMS compatible signaling protocol.

In practice, in the exemplary embodiment described, the WebRTC compatible signaling protocol ("first protocol") is chosen as the WebSocket protocol associated with the JSON (JavaScript Object Notation) data format and the IMS compatible signaling protocol (" second protocol ") is the Session Initiation Protocol (SIP). The conversion entity 33, again designated by WebRTC-IMS gateway, is connected on the one hand to the Internet network 1, and on the other hand, in accordance with the invention, to the application server AS (31). The interconnection between the conversion entity GW and the server AS can be carried out via an NW network such as an IP network of a network operator or by a direct connection, for example when the conversion entity (33) is included in the AS application server (31) to thereby form application server 3 including such a conversion entity. The application server (AS) 31 is intended to provide communication services on the IMS core network (4). For this purpose, the server AS conventionally uses a communication interface with the core network IMS, designated by the abbreviation ISC for "IP Multimedia Subsystem Service Control Intefface", and described in the document 3GPP TS 23.228 section 4.2.4. according to the invention, the AS server 31 also comprises a second communication interface, this time with the conversion entity 33.

This second interface notably comprises, from a functional point of view, a module for receiving first communication requests according to a predetermined communication protocol ("first protocol"), coming from the conversion entity, each of these first requests. being sent by a calling terminal identified by a WebRTC identifier, to a called party identified by an IMS reachability identifier. The first communication protocol may be a protocol such as SIP when the conversion entity, separate from the application server (31), is connected to the latter via an IP network (NW), or a proprietary protocol when the conversion entity (33) is included in the AS application server (31).

In addition, the application server (AS) 31 comprises: a first request processing module, configured to obtain, after receiving a first request as defined above, an IMS reachability identifier of the caller from its WebRTC ID; a first request transmission module, configured to transmit accordingly, on the IMS network core to the called party, a second communication request according to the SIP protocol containing the caller's IMS reachability identifier - obtained by the first request processing module -, in order to establish through the conversion entity, a communication media between the caller terminal and a terminal of the called party.

The application server (AS) furthermore comprises: a second module for receiving first communication requests according to the SIP protocol ("first protocol"), originating from the first communication interface, each of which being transmitted via the core an IMS network by a caller terminal identified by an IMS reachability identifier, to a called party identified by an IMS reachability identifier; a second request processing module, configured to determine following reception of a first request as defined above, if the caller's reachability identifier IMS corresponds or not to a subscriber having an identifier WebRTC; a second request transmission module, configured to transmit if the aforementioned subscriber has a WebRTC identifier, to the conversion entity, a second communication request containing the determined WebRTC identifier, in order to establish processing of this second request by the conversion entity, a communication media between the caller terminal and a terminal corresponding to the caller's WebRTC identifier, through the conversion entity.

According to the embodiment chosen, the application server AS further comprises a caller authentication module identified by a WebRTC identifier contained in a first communication request from the conversion entity.

According to the embodiment described, the aforementioned request processing modules are configured to consult a database of subscriber profiles containing for each subscriber at least one service implemented by the application server, at least one identifier of IMS reachability, and if necessary at least one corresponding WebRTC identifier. This database (not shown in FIG. 2) may be incorporated in a memory of the application server or accessible by the latter via the IMS core network or another network. According to a chosen embodiment, the database of subscriber profiles is filled during a preliminary configuration operation (provisioning) of the application server AS.

The application server (31) thus manages the SIP connectivity of the web clients via the GW gateway (WebRTC-IMS), according to a dynamic or static mode, according to the embodiment chosen. In dynamic mode, the application server performs the SIP registration server function with the SIP interface of the GW gateway, and the GW gateway registers the web clients with the AS application server by the intermediary of the subscriber profiles database. In static mode, the application server has the IP address (via DNS, static IP route, for example) of the GW gateway and vice versa, and can exchange SIP requests (for example INVITE) on UDP / TCP ports. (User Datagram Protocol / Transmissbn Control Protocol) predefined. From the point of view of the authentication of a subscriber corresponding to a web client, at the heart of the IMS network, several embodiments are possible. According to a first mode, called trusted mode, the authentication of a web client is carried out beforehand on the web via an interface with the application server AS or with the web server. WS in connection with the gateway GW, any request from the latter being then automatically authorized by the application server. This first embodiment can be applied both for static connectivity and for dynamic IP connectivity between the GW gateway and the AS application server. According to a second embodiment, the authentication of a web client vis-à-vis the IMS core network can be done during the SIP registration of the GW gateway on the application server with authentication data. specific credentials declared in the user profile stored in the profile database associated with the application server. This second embodiment is applicable only if the IP connectivity between the WebRTC gateway (GW) and the application server is dynamic. In both cases, no user registration of a web client is done directly on the IMS core network. FIG. 3 illustrates the hardware architecture of an application server AS according to the invention. In the embodiment described here, the application server has the hardware architecture of a computer; it comprises in particular a processor 3A, a read-only memory (ROM) 3B, a random access memory (RAM) 3C, a nonvolatile memory 3D (hard disk for example) and communication means 3E with, in particular, the entities of the core network IMS, in particular the set of functions CSCF 41, and with the protocol conversion entity GW 33. These communication means 3E include for example a network card, known per se and not detailed here.

The read-only memory 3B of the application server (AS) constitutes a recording medium readable by the processor 3A and on which is recorded the code of a computer program whose execution causes the implementation of a method communication device according to the invention. This computer program correspondingly defines functional modules of the AS server as defined above.

FIG. 4 is a flowchart illustrating the main steps of a communication method according to the invention, according to a first example, implemented in the network environment of FIG. 2, between a calling terminal (Ti) equipped with a WebRTC client (BRW1 browser) and a called terminal (T3-T6) accessible via the core network IMS 4. The method is implemented by the application server 31, providing communication services (audio, video, data. ..) on the IMS 4 core network via its ICS interface. Initially, the terminal Ti transmits to the gateway WebRTC-IMS 33 (protocol conversion entity) a communication request to the terminal T3. This request sent according to a WebRTC compatible P1 signaling protocol is converted by the gateway 33 into a RQT1 request according to an IMS-compatible P2 protocol.

In step S41, the server AS receives from the gateway 33 the communication request RQT1 according to the protocol P2, which contains a WebRTC identifier (URI-U1_2) associated with the user U1 (caller) and a reachability identifier IMS (URI-U3) associated with the user U3 (called) of the terminal T3. In step S43, the server AS 31 processes the request in order to obtain an IMS reachability identifier (URI-U1_1) from the caller U1 from its WebRTC identifier (URI-U1_2). For this purpose, the server AS consults a database of subscriber profiles, with in input data the WebRTC identifier (URI-U1_2) of the subscriber U1, and obtains at its output its reachability identifier IMS (URI -U1_1) as well as the data relating to the services to which subscriber U1 has subscribed.

Then, in step S45, a second communication request (RQT2) according to the P2 protocol is created, containing the IMS reachability identifier (URI-U1_1) of the caller U1 and the IMS reachability identifier ( URI-U3) of the called U3, then the request is transmitted on the core network IMS, to the terminal T3 of U3. If the user U2 picks up his terminal T3 then, in step S47, a media communication (voice, video, ...) is established through the gateway GW 33, between the terminal T1 of the user U1 and the terminal T3 of the user U3.

FIG. 5 is a flowchart illustrating the main steps of a communication method according to the invention, according to a second example, implemented in the network environment of FIG. 2, between a calling terminal (T3-T6) accessible via the IMS network core 4, and a called terminal (Ti, T2) equipped with a WebRTC client (browsers BRW1, BRW2). The method is implemented by the application server 31, providing communication services (audio, video, data, etc.) on the IMS 4 core network via its ICS interface. In step S51, the application server AS receives a first communication request (RQT1) according to the P2 protocol (IMS-compatible signaling protocol, for example SIP). This request RQT1 was sent via the core network IMS by the terminal T3 of the user U3 (calling party) identified by its reachability identifier IMS (URI-U3), to the user U1 also identified by its identifier of IMS reachability (URI-U1_1). In step S53, the server AS 31 processes the request RQT1 in order to determine whether the reachability identifier IMS (URI-U1_1) of the called party U1 corresponds to a subscriber having a WebRTC identifier. For this purpose, the server AS consults the subscriber profile database mentioned above, with the input data IMS reachability identifier (URI-U1_1) of the user called U1. In this example, the user U1 has a WebRTC identifier (URIU1_2) which is thus obtained from the database of profiles. Consequently, in step S55, a second communication request (RQT2) according to the P2 protocol is created, containing the IMS reachability identifier (URI-U3) of the caller U3 and the WebRTC identifier (URI -U1_2) obtained for the called party U1, then the request is transmitted to the GW gateway 33. The gateway GW 33 then translates the request RQT2 into a request according to the protocol P1 (compatible WebRTC) and transmits it via the Internet network INT, to the browser BRW1 of the terminal (Ti) of the called user (U1).

If the user U1 picks up his terminal (Ti) then, in step S57, a media communication (voice, video, ...) is established through the gateway GW 33, between the terminal T3 of the user U3 and the terminal T1 of the user U1. In relation with FIG. 6, the communication process according to the invention will now be described in detail between a calling terminal equipped with a WebRTC client and a called terminal accessible via an IMS core network. This process has already been briefly discussed in connection with FIG. 4. In this exemplary implementation of the invention, it is assumed that the user U1 has two identities: an IMS reachability identifier (URI-U1_1), in this example a SIP identity known to the IMS and public, that is to say "routable" from interconnection networks such as a PSTN network (431) or a private enterprise network connected by a gateway ( BOX 411) at the IMS; and a web identifier known by the application server AS (database profiles) and by equipment connected to the web (web servers, etc.).

The user U1 (calling) connects beforehand (connection not shown in Figure 6) via its terminal Ti (equipped with the web browser BRW1) to the web server WS, to download a web page access to a communication environment , and selects via a graphical interface displayed on the screen of its terminal, an identifier associated with the user U3 (called) in order to establish a media communication from his browser. The identifier selected for the user U3 is for example his phone number on the PSTN telephony network (431), which is transmitted to the WebRTC gateway (GW 33) by the terminal Ti, in a request message M601. In the exemplary embodiment described, the message M601 is a message in JSON format using the WebSocket communication protocol over the HTTP protocol (HyperText Transfer Protocol). This message is of the following form: {request "offer" calier 1.JRI-1.J1 2, callee: ID 113} where URI-U1_2 designates the web identifier associated with the calling web user Ul (caller), by example an email address (userU1@orange.fr); and ID_U3 denotes the network identifier associated with the user U3 called (callee) in the PSTN network, for example a telephone number: +33123456789. The request message M601 is received by the gateway GW which converts it into an M603 request message conforming to the SIP protocol, which is then transmitted to the application server AS. The SIP message M603 is of the following form: INVITE [SDP U.1] R-URI URI-1J3 From: URI-1J1 2 TB URI-U3 Contact <SIP URI GW> Where URI-U3 is the IMS reachability ID of the user U3 obtained from the network identifier ID_U3 of the user U3. For example, if ID_U3 = +33123456789, then URI-U3 = "sip: +33123456789@sip.osp.com; user = phone"; in general, URI-U3 is of the general form ID_U3 @ domain, where domain is a SIP domain.

When the request message M603 is received by the application server AS, it applies a processing S605 which corresponds to the step S43 described in connection with FIG. 4, consisting in obtaining from the URI-web identifier. U1_2 of the user U1 (calling) a corresponding IMS reachability identifier URI-U1_1. In practice, URI-U1_1 is of the general form: 1.JRI-1.J1 .1 = "sip" userUl @ domain "Where 'UserU1' means an IMS identifier.

The IMS identifier 'UserU1' may be a public identity, that is to say, routable in the IMS network from external networks (PSTN ...), such as a long telephone number (for example, URI or SIP URI with a user prefix containing a number in the global format e164). An example of public IMS ID is given below: sip +33145294795@orange.com; user = phone The IMS identifier 'UserU1' can also be a private IMS identity, that is to say known only to the IMS for routing calls to another IMS subscriber; such a private IMS identifier may be for example a short number or a SIP URI extension whose user prefix is not necessarily a number, etc.

Then, the application server AS creates a second request, M607, according to the SIP protocol, at the initiative of the server AS to transmit in the heart of the network the call to the user U3 on behalf of the user U1. In practice, this second request is a request in which the server acts in the "originatine" mode as defined in particular in section 5.7.3 of the 3GPP specification TS 24.229 V12.6.0 (2014-09) - Technical Specification Group Core Network and The second M607 request is of the following form: INVITE [SDP 111] R-URI URI -113 From: URI-U1 1 PAI URI-U1 1 TB URI-113 Route: URI-ICSCF; orig; no services The M607 request is then transmitted to the ICSCF of the IMS core network. a corresponding M609 request, destined for the terminal T3 of the user U3 (called), via BGCF entities (Breakout Gateway Control Function) and MGCF of the IMS core network The request M609 is of the following form: INVITE [SDP 111 ] R-URI URI-113 From: URI-U1 1 PAI URI-U1 1 TB URI-113 Route: URI-MGCF Following the receipt of the request M609, the terminal T3 sends a ringback message to the MGCF entity which converts it into a message M611 SIP response type '180 RINGING indicating good reception of the communication request (M609 ) by the recipient T3. The ICSCF receives the message M611 and in turn transmits an M613 message to the application server AS. The latter changes in the received message the IMS reachability identifier (URI-U1_1) of the U1 user by the corresponding web identifier (URI-U1_2) and transmits a modified message M615 to the GW gateway. The latter then converts the message of the type '180 RINGING' received (M615) into a response message (M617) according to the corresponding web compatible protocol, that is to say a message in JSON format according to the WebSocket protocol, and the transmits to the terminal Ti (browser BRW1). The response message M617 has the following form: {request "initial answer to call7 The M619-M625 messages are similarly SIP messages '200 OK' which are propagated from the called terminal T3 to the calling terminal Ti to indicate that the communication request has succeeded, the last message, M625, being of the following form: {request "final answer to call7 The communication request from the terminal Ti to the terminal T3 ends with the sending of a message of acknowledgment (ACK), indicating that the communication request is complete, propagated in the form of successive messages (M629-M633) by the different devices (GW, AS, CSCF, MGCF) located between the terminal Ti and the terminal T3, from an initial message M627 issued by the terminal Ti, of the form: {request "call complete7.

The terminal called T3 having responded favorably to the communication request, a media communication (voice and / or video, for example) is established (S635, S637) between the terminal T1 and the terminal T3, notably via the gateway GW and the IMS equipment involved. in the routing of the media stream (media proxy ...). In practice, the media flow between the terminal T3 and the gateway GW is established according to the Real-time Transport Protocol (RTP), while the media flow established between the gateway GW and the terminal Ti is established according to the protocol SRTP (Secure RTP). With reference to FIG. 7, a communication process according to the invention will now be described between a calling terminal accessible via an IMS core network and a called terminal equipped with a WebRTC client. This process has already been described briefly in connection with FIG. 5. In this exemplary implementation of the invention, it is still assumed that the user U1 has two identities: an IMS reachability identifier (URI-U1_1), in this example, a SIP identity known to the IMS and public, that is to say "routable" from interconnection networks such as a PSTN network (431) or a private enterprise network connected by a gateway (BOX 411) at the IMS; and a web identifier known by the application server AS (database profiles) and by equipment connected to the web (web servers, etc.).

It is assumed that the subscriber profile of the user U1 has been activated in advance with the application server AS, which makes it possible to automatically route calls from the core network IMS to its web browser (BRW1). In FIG. 7, the user U3 (calling party) transmits via his telephone terminal T3, identified by the URI-U3 identifier on the PSTN network 431, a call destined for a public identifier (IMS reachability identifier: URI- U1_1) of the user U1, known from the network core IMS and the application server AS, for example a direct telephone number (using the SDA technique - Direct Selection on Arrival). The call is expressed at the level of the MGCF equipment by an M701 SIP INVITE request message of the following form: INVITE [SDP 113] R-URI URI-U1 1 From: URI-113 To URI-1J1 1 The message of Request M701 is received by the I / S-CSCF entity of the IMS core network, which in turn sends a M703 SIP INVITE message in terminating mode to the AS application server. The message M703 is of the following form: INVITE [SDP 113] R-URI URI-U1 1 From: URI-113 To URI-1J1 1 Route: URI-AS; Mode = terminating The message M703 is received by the ISC interface of the application server AS which performs S705 processing in which it consults the subscriber profile database and determines that the called party U1 identified in the message of request by its reachability identifier IMS 'URI-U1_1 also has the WebRTC identifier' URI-U1_2 '; and transmits to the gateway GW, an M707 SIP INVITE request message, in which the WebRTC identifier of the called party U1 replaces its IMS reachability identifier. The message M707 has the following form: INVITE [SDP 113] R-URI URI-111 2 From: URI-113 To URI-1J1 2 Contact: URFAS The GW gateway receives the SIP message M707 and performs a SIP signaling conversion to WebRTC, and sends on the web (Internet) a message M709 request in JSON format using the WebSocket communication protocol (above the HTTP protocol) to the browser terminal T1 called U1. The message M709 is of the following form: {request "offer" calier: 1.JRI-113, callee 1.JRI-1.J1 2} The web browser of the terminal Ti then issues an M711 response JSON message of the following form is sent to the GW gateway: {request "initial answer to call7 The M711 message is received by the GW gateway which converts it into a RINGING type M713 SIP message of the form: 180 RINGING From: URI-113 To URI-U1 2 The message M713 is received by the application server AS which in turn sends to the I / S-CSCF entity a message M715 SIP '180 RINGING in which the webRTC identifier (URI-U1_2) of the called party U1 is replaced by the corresponding IMS reachability identifier (URI-U1_1) Message M715 and of the following form: 180 RINGING From: URI-113 To URI-U1 1 SIP message M715 is received by the entity I / S-CSCF which in turn sends a SIP RINGING message, M717, to the T3 terminal of the caller U3 via the MGCF If the called party U1 accepts the request communication via the web browser of its terminal, an M719 response JSON message of the following form is then sent to the gateway GW: {request "final answer to call7 The message M719 is received by the gateway GW which converts it into a message SIP, M721, of type '200 OK next: 200 OK SDP [SDP 111] From: URI-113 To URI-U1 2 The message M721 is received by the server AS which in turn sends to the entity I / S-CSCF a message, M723, SIP 200 OK in which the webRTC identifier (URI-U1_2) of the called U1 is replaced by the corresponding IMS reachability identifier (URI-U1_1). The message M723 and of the following form: 200 OK SDP [SDP 111] From: URI-113 To URI-11.1 1 The SIP message M723 is received by the I / S-CSCF entity which in turn transmits a SIP message 200 OK, M725, to the T3 terminal of the caller U3 via the MGCF entity. The terminal T3 then transmits an acknowledgment message (ACK) M727 which is propagated in the form of successive messages (M729-M731) by the various devices (MGCF, I / S-CSCF, AS) to the GW gateway which converts the last message ACK (M731) in WebRTC message M733, sent to the terminal T3. The message M733 has the following form: {request "call complete7 The media communication (voice and / or video, for example) can then be established (S735, S737) between the terminal T3 and the terminal Ti via, in particular, the gateway GW and the IMS equipment involved in the routing of the media stream (proew media ...) In practice, the media flow between the terminal T3 and the gateway GW is established according to the protocol RTP (Real-time Transport Protocol), while the media flow established between the gateway GW and the terminal Ti is established according to the protocol SRTP (Secure RTP).

The communication method according to the invention thus makes it possible, in particular, to provide a terminal equipped with a client of the WebRTC type, connected to a first network, of the Internet type, access to a communication service provided via the Internet. an application server on a second network, of the IMS type, via a WebRTC signaling translation gateway in IMS signaling. 30

Claims (11)

REVENDICATIONS1. A method of communication between a terminal (T1, T2) equipped with a WebRTC client and a terminal (T3-T6) accessible via an IMS core network (4), said method being implemented by an application server ( 31) configured to provide communication services on the IMS core network, said method being characterized in that it comprises steps of: - receiving (S41) from an entity (33) for bidirectional conversion of messages according to a first WebRTC compatible signaling protocol in messages according to a second IMS-compatible signaling protocol, a first communication request (RQT1) according to the second protocol, sent by a terminal (Ti) equipped with a WebRTC client, a caller (U1) identified by a WebRTC identifier (URI-U1_2), and intended for a called party (U3) identified by an IMS reachability identifier (URI-U3); processing (S43) the first request to obtain an IMS reachability identifier (URI-U1_1) from the caller's WebRTC identifier (URI-U1_2); - transmission (S45) on the IMS core (4), to the called party (U3), a second request (RQT2) communication according to the second protocol containing the IMS reachability identifier (URI-U1_1 ) of the caller, in order to establish a media communication (S47) through the conversion entity (GW), between the terminal (Ti) of the caller and a terminal (T3) of the called party. 2. The method as claimed in claim 1, comprising the steps of: receiving (S51) a first communication request according to the second protocol transmitted via the IMS core network by a terminal of a caller identified by an IMS reachability identifier. , to a called party identified by an IMS reachability identifier; processing (S53) of the first request to determine whether or not the IMS reachability identifier of the called party corresponds to a subscriber having a WebRTC identifier, and if so, - transmission (S55) to destination of the conversion entity of a second communication request containing the determined WebRTC identifier, for the establishment, through the conversion entity, of a media communication (S57) between the terminal of the calling and a terminal corresponding to the called WebRTC identifier of the called party. 3. Method according to claim 1 or 2, wherein the processing of the first request comprises consulting a database of subscriber profiles containing for each subscriber at least one service implemented by the application server, to least an IMS reachability identifier, and if necessary at least one corresponding WebRTC identifier. 4. Method according to one of the preceding claims, comprising a step of authenticating a caller identified by a WebRTC identifier contained in a first communication request from the conversion entity. 5. Method according to one of the preceding claims, wherein the first protocol is the WebSocket protocol and the second protocol is the Session Initiation Protocol (SIP). 6. Application server (AS) configured to provide communication services on an IMS core network, characterized in that it comprises: - first reception means from a bidirectional message conversion entity according to a first WebRTC compatible signaling protocol, in messages according to a second IMS compatible signaling protocol, a first communication request according to the second protocol, sent by a terminal of a caller identified by a WebRTC identifier, to a called party identified by an IMS reachability ID; first request processing means, configured to obtain an IMS reachability identifier of the caller from the caller's WebRTC identifier; first transmission means on the IMS network core, intended for the called party, of a second communication request according to the second protocol, containing the caller's IMS reachability identifier, for the purpose of establishing , through the conversion entity, a communication media between the caller terminal and a terminal of the called party. 7. Server according to claim 6, further comprising: second means for receiving a first communication request according to the second protocol transmitted via the IMS core network by a terminal of a caller identified by an IMS reachability identifier; , to a called party identified by an IMS reachability identifier; second request processing means, configured to determine whether the caller's reachability identifier IMS corresponds to a subscriber having a WebRTC identifier; second means for transmitting to the conversion entity, a second communication request containing a WebRTC identifier determined by the second request processing means, following the reception of the first request, for the establishment a communication media between the caller terminal and a terminal corresponding to the caller's WebRTC identifier, through the conversion entity. 8. Server according to one of claims 6 or 7, wherein the first and second request processing means are configured to consult a database of subscriber profiles containing for each subscriber at least one service implemented by the application server, at least one IMS reachability identifier, and if necessary at least one corresponding WebRTC identifier. 9. Server according to any one of claims 6 to 8, including said conversion entity. 10. Server according to any one of claims 6 to 9, further comprising means for authenticating a caller identified by a WebRTC identifier contained in a first communication request from the conversion entity. A computer program comprising program instructions, the execution of which by a processor incorporated in an application server implements a communication method according to any of the claims therein.